[Wed May 29 00:20:16 2013] I have a hypothesis: "exists a: b = f a" [Wed May 29 00:20:28 2013] how do I get hypothesis of the forms "a0 \n b = f a0" ? [Wed May 29 00:20:38 2013] there should be a simple tactic for this, but I can't think of it [Wed May 29 03:25:26 2013] When thm_prover gets back, someone tell him destruct H. [Wed May 29 03:50:48 2013] is there something in coq like let..in or where known from haskell? [Wed May 29 04:18:13 2013] thorsten: Coq has [let foo := bar in baz] (and fancier versions), though it's really just syntatic sugar for a match. [Wed May 29 04:27:16 2013] let are not syntactic sugar for match in Coq [Wed May 29 04:28:36 2013] ah, I see what you mean [Wed May 29 04:29:01 2013] okey, thanks. i want to use it to avoid mentioning the same subterm multiple times [Wed May 29 04:29:22 2013] and now i also get the comparison to "match" [Wed May 29 04:40:31 2013] is there a way in Coq to do "hint unfold .... "? [Wed May 29 04:40:57 2013] dumb question on my part [Wed May 29 04:41:01 2013] Google says "Hint Unfold ... " [Wed May 29 04:41:31 2013] thm_prover: more generaly http://coq.inria.fr/refman/command-index.html [Wed May 29 04:46:27 2013] rks: noted, thanks! [Wed May 29 04:46:37 2013] I should set that as my homepage. :-) [Wed May 29 04:50:38 2013] sgnb: [Set Printing All. Check let (a, b) return nat := (1, 2) in a.] tells me "match @pair nat nat (S O) (S (S O)) return nat with | pair a _ => a end". So, at least, the more complicated versions of "let" are just sugar for "match". [Wed May 29 04:52:15 2013] yes, I know... I only think about the "let id := term in term" form when I hear about let [Wed May 29 04:52:53 2013] and actually this use of let is different from match because it infers the type [Wed May 29 04:53:13 2013] I mean, you don't need to give the constructor name [Wed May 29 04:53:25 2013] I see it as a pretyping feature [Wed May 29 04:58:25 2013] @check (match 1 with a => a end) [Wed May 29 04:59:42 2013] Hmmm.... does lambdabot not like that? Anyway, you don't have to give the constructor name in a match, either. You can have a variable name that stands in for all the remaining cases. [Wed May 29 05:01:08 2013] jgross: lambdabot isn't in here, is it? [Wed May 29 05:17:19 2013] @print eq [Wed May 29 05:17:47 2013] Maybe I mean roosterbot? There was definately something at one point which responded to commands like @print. [Wed May 29 06:21:02 2013] jgross: the binding let (let foo := bar in baz) is a specific construction in Coq [Wed May 29 06:21:55 2013] kernel terms include let bindings [Wed May 29 06:22:20 2013] however, there is also this destructuring let, like you wrote let (a, b) return nat := (1, 2) in a. [Wed May 29 06:22:29 2013] which is indeed syntactic sugar for a match [Wed May 29 06:23:25 2013] one last remark: match x with _ => _ end is actually removed by the preprocessing done on pattern matching [Wed May 29 06:23:48 2013] so it's not always equivalent to write a default case in a match, or to enumerate the constructors [Wed May 29 06:24:42 2013] particularly when matching a coinductive type [Wed May 29 06:28:20 2013] hm [Wed May 29 06:28:26 2013] im trying to write a recursive function [Wed May 29 06:28:44 2013] Coq complains that it cannot guess the decreasing argument of fix [Wed May 29 06:28:58 2013] but it seems pretty obvious to me that the recursion is decreasing [Wed May 29 06:29:14 2013] anyone can explain why perhaps? [Wed May 29 06:29:37 2013] roosbeef: "obvious" leaves a lot of room for leeway :] [Wed May 29 06:29:53 2013] https://privatepaste.com/e6ea9cffe1 [Wed May 29 06:29:54 2013] if it's not structurally recursive, or something close to that, probably going to have issues [Wed May 29 06:30:02 2013] the (mutually recursive) function im trying to define is at the bottom [Wed May 29 06:30:30 2013] it seems close enough to structural recursion to me [Wed May 29 06:30:40 2013] only thing is it has some if then else ladders in it [Wed May 29 06:30:49 2013] hmm [Wed May 29 06:30:51 2013] but i dont see how that makes it any less structurally recursive [Wed May 29 06:32:53 2013] Yes, it looks like it would work. I'm not an expert in how Coq does those kind of checks. Probably mutual recursion causes a problem somehow. [Wed May 29 06:32:58 2013] I would post on the mailing list [Wed May 29 06:33:36 2013] hm [Wed May 29 06:34:09 2013] As an alternative, you might try using Program Fixpoint and see what kind of obligations it asks for [Wed May 29 06:34:26 2013] maybe i can do without mutual recursion [Wed May 29 06:35:14 2013] somehow :p [Wed May 29 06:45:49 2013] how does 'Program Fixpoint' work? [Wed May 29 06:58:32 2013] hm, apparently, Coq thinks that: Recursive call to ft_compare has principal argument equal to "h1" instead of "t1". [Wed May 29 06:59:30 2013] does it consider the if-then-else ladder when deciding what 'the principal argument' is? Or does it just look at the first argument occurence [Wed May 29 07:07:50 2013] did you try to specify the decreasing with {struct }? [Wed May 29 07:11:21 2013] yes, {struct ft1} [Wed May 29 07:11:46 2013] it only works for the parameters, right? Ive tried to tell it {struct tail1} too but it doesnt know what I mean by that [Wed May 29 07:12:12 2013] yeah, I think it only works for the parameters of the function [Wed May 29 07:27:57 2013] just curious, is this not working a shortcoming of Coq? [Wed May 29 07:28:20 2013] or is the recursion im trying potentially non-decreasing [Wed May 29 07:41:03 2013] going to try again tomorrow [Wed May 29 07:41:14 2013] thanks for your help guys [Wed May 29 08:06:11 2013] https://privatepaste.com/6d83e8f7e7 [Wed May 29 08:06:15 2013] oh, he's gone already [Wed May 29 13:54:18 2013] Hmmm. [Wed May 29 13:54:38 2013] In Coq, is it possible to prove that there are more than two propositions? [Wed May 29 13:55:09 2013] That there exists a proposition that is equal neither to False nor to True? [Wed May 29 13:55:39 2013] it is consistent to add forall P : Prop, (P = False) \/ (P = True) as an axiom [Wed May 29 13:55:50 2013] * nods. [Wed May 29 13:55:51 2013] so no [Wed May 29 13:56:05 2013] you get it from excluded middle + propositional extensionality, of course [Wed May 29 13:56:56 2013] I kind of like the gamut of consistency that Coq provides. [Wed May 29 14:07:26 2013] So is there a straightforward way to prove the consistency of axioms like that one? Do you construct a model of Coq with the axiom, or simply prove that you can't prove a contradiction from it, or what? [Wed May 29 14:09:11 2013] well, I don't know if propositional extensionality has actually been proved consistent with coq [Wed May 29 14:09:30 2013] take a look here http://cstheory.stackexchange.com/questions/4905/where-is-the-proof-that-coq-excluded-middle-is-consistent [Wed May 29 16:37:36 2013] hello [Wed May 29 18:20:19 2013] in Coq, is the following lemma provable?: "Lemma silly: (true=true) = True" [Wed May 29 18:24:32 2013] Sorry, got disconnected [Wed May 29 18:24:50 2013] prev question: in Coq, is the following lemma true? Lemma silly: (true=true) = True. [Wed May 29 18:25:12 2013] I don't think it's true [Wed May 29 18:25:17 2013] I used to think it was true, but now I'm starting to feel that "True" and "true=true" have different types, thus implying they're not equal. [Wed May 29 18:25:23 2013] Ptival: why? [Wed May 29 18:25:28 2013] no they have the same type [Wed May 29 18:25:41 2013] otherwise you wouldn't even be able to state their equality in the system [Wed May 29 18:26:00 2013] In that case, I'm even more confused. [Wed May 29 18:26:04 2013] Why is it not provable> [Wed May 29 18:27:46 2013] because not all true propositions are equal to True [Wed May 29 18:28:15 2013] you can add as an axiom that (P <-> Q) -> P = Q for propositions P and Q ("propositional extensionality") and then it's true [Wed May 29 18:28:35 2013] remember that True refers to one _specific_ true proposition, rather than the general idea of something being true [Wed May 29 18:29:05 2013] because all we have is some Inductive Bool : Set = True | False. [Wed May 29 18:29:15 2013] and anything that can not, by CoC, reduce to "True", is not provably equaly to True ? [Wed May 29 18:29:16 2013] no... [Wed May 29 18:29:30 2013] True and False aren't booleans [Wed May 29 18:29:34 2013] If you have time, I'd like you to help debug where my idiocy is. [Wed May 29 18:29:40 2013] Coq < Print True. [Wed May 29 18:29:40 2013] Inductive True : Prop := I : True [Wed May 29 18:29:40 2013] Coq < Print False. [Wed May 29 18:29:40 2013] Inductive False : Prop := [Wed May 29 18:29:49 2013] they are propositions declared inductively, just like any other [Wed May 29 18:29:53 2013] (and hence, types) [Wed May 29 18:30:02 2013] true and false (lowercase) are booleans: Inductive bool : Set := true : bool | false : bool [Wed May 29 18:30:33 2013] okay, so there is an inductive type Prop, which describes all possible ways in which propositions can be composed together [Wed May 29 18:30:42 2013] Prop isn't inductive, it just contains inductive types [Wed May 29 18:30:55 2013] Coq's equality is "intensional", so basically x = y only if you can compute/rewrite both halves to be the same; there's no way to rewrite (true = true) to be True [Wed May 29 18:31:19 2013] in fact, equality is itself defined by an inductive proposition: Inductive eq (A : Type) (x : A) : A -> Prop := eq_refl : x = x [Wed May 29 18:33:38 2013] okay, so "A = B" iff there exists some sequence of steps which by A can be rewritten into B [Wed May 29 18:33:41 2013] I can accept that. [Wed May 29 18:34:24 2013] right, and those steps are essentially just computation when you get round to it [Wed May 29 18:34:33 2013] 1 + 1 = 2 because evaluating 1 + 1 reduces it to 2 [Wed May 29 18:35:00 2013] sure, 1 + 1 = (S 0) + (S 0) = S (S 0) + 0 = S (S 0) = 2 [Wed May 29 18:35:04 2013] or something like that :-) [Wed May 29 18:35:25 2013] so "true = true" is just some "Prop", and there's no way I can rewrite it to True [Wed May 29 18:35:32 2013] and you can prove (forall (x : option nat), match x with | None => 123 | Some _ => 123 end = 123) by destructing "x", and then in each branch (x being None and x being Some y for some y), the match evaluates to 123 [Wed May 29 18:35:34 2013] I can accept this, but it's still weird. [Wed May 29 18:36:01 2013] well, you can't even prove two functions that aren't "identical" are equal, even if they agree on each values [Wed May 29 18:36:03 2013] the confusion might be from the choice of names [Wed May 29 18:36:08 2013] (that's called "functional extensionality" and there's a module that exports it as an axiom) [Wed May 29 18:36:13 2013] *on every value [Wed May 29 18:36:36 2013] rmk0: you mean I'm much more willing to accept "(foo = foo) = Foo" being unprovable? [Wed May 29 18:36:46 2013] yeah, I am much willing to accept the later being unprovable :-) [Wed May 29 18:36:47 2013] rmk0: i mean the use of the names True and False [Wed May 29 18:36:55 2013] ... didn't mean to talk to myself there [Wed May 29 18:37:18 2013] thm_prover: compare the definitions of 'unit' and 'True' [Wed May 29 18:37:26 2013] and also 'Empty_set' and 'False' [Wed May 29 18:37:35 2013] right, yeah [Wed May 29 18:37:50 2013] you could also call True, say, "Trivial"; it's just a proposition defined to be trivially true [Wed May 29 18:38:00 2013] and False is trivially uninhabited [Wed May 29 18:38:21 2013] so they're the "simplest" propositions that are provable/unprovable in a sense, and that's the only reason they have those names [Wed May 29 18:38:22 2013] okay [Wed May 29 18:38:27 2013] I thikn I'm ahppy now. [Wed May 29 18:38:40 2013] Thanks for both of your time. Very helpful. :-) [Wed May 29 18:38:44 2013] you could just as well ask, e.g. "why can't I prove is_even 2 = 123 > 4", because both of them are true :) [Wed May 29 18:39:05 2013] (some systems, e.g. observational type theory, *do* let you prove that two propositions are equal if they imply each other) [Wed May 29 18:39:13 2013] (because they support extensional equality) [Wed May 29 21:23:40 2013] Hmmmm. Now I wonder if you can consistently assume that if a proposition is true, then it has a proof. [Wed May 29 21:24:03 2013] Seems like you could diagonalize here. [Wed May 29 21:26:00 2013] Construct a statement that amounts to "this statement has no proof". So... if you prove that it's true, you can then prove that it's false, by the contrapositive of that axiom there. If it has no proof, then it is false. [Wed May 29 21:26:49 2013] In order to prove that it's true, you'd have to assume that it's provable and derive a contradiction. But provability doesn't lead you anywhere; there's nothing that says that provability implies truth. [Wed May 29 21:27:02 2013] Or is there? [Thu May 30 04:37:16 2013] tswett: how would you formulate "if a │ [Thu May 30 04:37:18 2013] | proposition is true, then it has a proof" [Thu May 30 04:40:19 2013] hm? i don't think that propositions are "true" or "false". A Proposition itself is the proof [Thu May 30 04:45:52 2013] it should be an inhabitant of the proposition is a proof. "False" is a Proposition, but "False" itself is not a proof. [Thu May 30 04:47:52 2013] so, what does tswett mean by being true? Being inhabited? Being true in some model of pCiC (which does not have to imply being inhabited)? Being true in all models of pCiC (which implies it's inhabited) [Thu May 30 04:47:55 2013] oh, right [Thu May 30 05:52:07 2013] robbert: A distinction between truth and provability only makes sense when you're doing something model theoretic in nature - formalising one theory inside another and providing an interpretation of its statements as statements of the outer theory. [Thu May 30 05:52:51 2013] That said, I don't really know what tswett was referring to [Thu May 30 07:13:59 2013] is it possible in coq to prove a statement like " (0 <= x < b \/ x = b) = (0 <= x < b + 1) [Thu May 30 07:14:17 2013] " - or is that impossible? [Thu May 30 07:15:07 2013] <-> is obviously possible [Thu May 30 07:17:41 2013] it's not possible in general, but if equality and order are decidable in your context, you should use boolean operators to write this kind of things [Thu May 30 07:18:32 2013] basti_: you can add propositional extensionality as an axiom [Thu May 30 07:18:34 2013] hmm. that is in Z, so equality and order are decideable, and i think i could do this with boolean operators. [Thu May 30 07:18:44 2013] but quite simply, only things you can make the same on both sides are equal [Thu May 30 07:18:52 2013] * nods [Thu May 30 07:18:55 2013] (huh, this question has come up 2, 3? times today/yesterday) [Thu May 30 07:19:04 2013] i don't want prop. ext. [Thu May 30 07:19:05 2013] it has? [Thu May 30 07:19:10 2013] I'm just having fun [Thu May 30 07:19:17 2013] no connection i think. [Thu May 30 07:20:31 2013] if it's over Z, it's usually convenient to use boolean comparisons to allow this kind of rewriting [Thu May 30 07:20:33 2013] yeah, it's just odd :) [Thu May 30 07:22:35 2013] with "boolean comparisons" you mean to use lemmas like "eqb_eq"? [Thu May 30 07:28:53 2013] well, eqb_eq allows you to reduce an equality goal in Prop to a boolean one [Thu May 30 07:29:12 2013] but you can also use boolean functions for order (not only equality) and so on [Thu May 30 07:29:33 2013] In case of Z, "<" is proof irrelevant, "<=" is not [Thu May 30 07:29:35 2013] @print Z.le [Thu May 30 07:29:45 2013] ah, roosterbot is broken [Thu May 30 07:30:10 2013] "Z.le = λ x y, (x ?= y) ≠ Gt" [Thu May 30 07:31:05 2013] oh [Thu May 30 07:31:17 2013] i see. [Thu May 30 07:32:40 2013] what do you mean, robbert? "<" is proof irrelevant whereas "<=" is not [Thu May 30 07:33:08 2013] That you can prove "forall (x y : Z) (p1 p2 : x < y), p1 = p2" [Thu May 30 07:33:15 2013] but not "forall (x y : Z) (p1 p2 : x <= y), p1 = p2" [Thu May 30 07:34:16 2013] I really wonder why Z.le is defined like that [Thu May 30 07:34:37 2013] Me too, it's quite annoying [Thu May 30 07:35:16 2013] so if i use only "<", the proof will be possible? [Thu May 30 07:35:30 2013] depends, you also have disjunctions [Thu May 30 07:35:38 2013] okay. [Thu May 30 07:35:47 2013] these are generally not proof irrelevant [Thu May 30 07:35:55 2013] unless both sides are exclusive [Thu May 30 07:35:59 2013] also, this is about equality of two propositions rather than equality of their proofs [Thu May 30 07:36:06 2013] okay. [Thu May 30 07:36:07 2013] even more confusing :) [Thu May 30 07:36:30 2013] oops, you are right, then my remarks are probably useless :) [Thu May 30 07:36:47 2013] -.- [Thu May 30 07:37:06 2013] ;) [Thu May 30 07:37:35 2013] so, generally it might be possible to prove to propositions acutally equal. [Thu May 30 07:37:41 2013] *to be [Thu May 30 07:37:48 2013] yes, so either use <->, in which case you can use the setoid machinery for rewriting with such equations [Thu May 30 07:37:54 2013] or use booleans, as mdenes suggested [Thu May 30 07:38:13 2013] I already came to like "setoid". [Thu May 30 07:39:21 2013] basti_: if you write all the comparisons as boolean functions and then do something like "forall x, is_true (0 <= x) = is_true (x > -1)" or whatever then you could do it [Thu May 30 07:39:33 2013] (having rewritten <= and > to be functions returning booleans) [Thu May 30 07:39:59 2013] hmm [Thu May 30 07:40:07 2013] robbert: if Z.le was defined as Z.le x y := (x ?= y) = Lt /\ (x ?=y = Eq), it would be proof irrelevant, right? [Thu May 30 07:40:07 2013] because you *do* have bi-implication implying equality on booleans: either both are false or both are true, so it reduces to is_true false = is_true false or is_true true = is_true true [Thu May 30 07:40:15 2013] not that I suggest such a definition either :D [Thu May 30 07:40:24 2013] that's what mdenes was suggesting, I believe [Thu May 30 07:40:34 2013] and you can define a coercion from bool to Prop that lets you omit the "is_true" there. [Thu May 30 07:40:43 2013] maybe i just started out wrong ^^ [Thu May 30 07:41:06 2013] my suggestion is not to try proving propositions equal :) [Thu May 30 07:41:13 2013] ;) [Thu May 30 07:41:18 2013] mdenes: isn't that definition just wrong? You need a disjunction instead of a conjunction [Thu May 30 07:41:23 2013] robbert: I meant an or, not an and of course [Thu May 30 07:41:30 2013] but in that case, I think so, as both sides are exclusive [Thu May 30 07:42:03 2013] ok [Thu May 30 07:44:34 2013] i'm addicted to coq. [Thu May 30 07:49:01 2013] mdenes: http://hpaste.org/88891, there you go :) [Thu May 30 07:49:46 2013] thanks :) [Thu May 30 08:06:57 2013] basti_: that's why they named it coq, so that it sounds funny when someone says that ;) [Thu May 30 08:07:12 2013] actually? [Thu May 30 08:08:38 2013] probably not, i haven't found a serious source for why they chose that name [Thu May 30 08:10:01 2013] well, wiki says a lot of research tools developed in france are named after animals [Thu May 30 08:10:33 2013] * nods [Thu May 30 08:31:44 2013] okay, i made a mistake. I didn't use Extensionality_Ensembles. When I do, I do not need to prove the statement above. [Thu May 30 09:06:15 2013] basti_: note, Extensionality_Ensembles is an axiom! [Thu May 30 09:07:38 2013] hmm. since i'd only use it in proofs I hope I can keep it irrelevant. [Thu May 30 09:07:56 2013] what do you mean by that? [Thu May 30 09:09:35 2013] well I think i can write definitions of functions (which i'd intend to extract eg.), prove them to be correct, and then use the correctness in equality proofs without ever touching the axiomatic set equality. [Thu May 30 09:09:39 2013] can't i? [Thu May 30 09:10:35 2013] i'd just use the proof and not depend a result on it. [Thu May 30 09:10:46 2013] *not have a result depend on it [Thu May 30 09:10:56 2013] if you intend to use extraction, you can assume anything in Prop that does not yield inconsistencies [Thu May 30 09:11:02 2013] extraction will remove all proofs [Thu May 30 09:11:12 2013] if you want to compute inside Coq, axioms can make computation block [Thu May 30 09:11:19 2013] yes, that i understand [Thu May 30 09:11:26 2013] you can assume things that lead to inconsistencies too! [Thu May 30 09:11:31 2013] for additional fun. [Thu May 30 09:11:39 2013] then extraction is no longer sound [Thu May 30 09:11:43 2013] yep [Thu May 30 09:11:51 2013] and may yield non terminating functions as well [Thu May 30 09:12:02 2013] robbert: but on the other hand, it makes the correctnes proofs so easy. [Thu May 30 09:12:21 2013] i realize that you can extract a broken program. [Thu May 30 09:12:50 2013] i don't realize how an endless loop could hapen [Thu May 30 09:13:14 2013] elliott: http://www.inutile.ens.fr/estatis/falso/ is my favorite proof assistant [Thu May 30 09:13:39 2013] however, I intend to just prove properties of the program in question, and that should work, and i don't think extensionality is not sound [Thu May 30 09:13:51 2013] basti_: you can prove non-terminating functions to be terminating using Falso [Thu May 30 09:14:32 2013] e.g, with inconsistent functions you can prove (fun _ _, True) to be well-founded [Thu May 30 09:14:36 2013] presumably if you use Acc and stuff [Thu May 30 09:14:38 2013] *inconsistent axioms [Thu May 30 09:14:41 2013] right. [Thu May 30 09:14:57 2013] hmmm. [Thu May 30 09:15:39 2013] falso is funny, yes. [Thu May 30 09:16:28 2013] of course, if you assume false, which is equal to assuming a contradiction, which is equal to writing a broken function, then you can prove everything. [Thu May 30 09:19:13 2013] http://hpaste.org/88898 for extracting a looping function [Thu May 30 11:44:24 2013] robbert: when I say "if a proposition is true, it has a proof", I'm referring to an axiom along the lines of "forall P : FolProp, isTrue P -> exists p : Proof, isProofOf p P". [Thu May 30 11:44:56 2013] Where "FolProp" is a type representing sentences in first-order logic, isTrue converts a FolProp into a Prop, and "Proof" is a type representing proofs of sentences in first-order logic. [Thu May 30 12:02:11 2013] tswett: Are you assuming LEM? [Thu May 30 12:02:37 2013] No. [Thu May 30 12:02:44 2013] Then I think no. [Thu May 30 12:04:03 2013] tswett: This problem has a name, it's called the Entscheidungsproblem, and it was answered negatively and independently by Church and Turing in 1936 and 1937 respectively :) [Thu May 30 12:05:19 2013] Oh, you need at least one predicate symbol of arity at least 2, other than equality [Thu May 30 12:05:29 2013] In order for that to apply [Thu May 30 12:05:59 2013] Hm. The Entscheidungsproblem entails that there is no algorithm that determines the truth value of a statement. Would this axiom entail the existence of such an algorithm? [Thu May 30 12:06:34 2013] Seems like it would. The algorithm is just "enumerate all proofs on both sides, stop when you get to the one you want", and this axiom entails that that algorithm always halts. [Thu May 30 12:06:36 2013] tswett: The existential there is really a pait [Thu May 30 12:06:38 2013] pair* [Thu May 30 12:07:22 2013] Where the fst is a Proof, and the snd is a proof that the Proof proves the FolProp? [Thu May 30 12:07:29 2013] yeah [Thu May 30 12:07:47 2013] and so you're asking for an effective way to compute the proof [Thu May 30 12:08:24 2013] (at least, so long as you're not taking LEM or something else that isn't computable as an axiom) [Thu May 30 12:09:44 2013] Some first order logical theories are decidable in this way though [Thu May 30 12:09:58 2013] Ah, true. [Thu May 30 12:10:18 2013] exists x, True. forall x y, x = y. [Thu May 30 12:10:48 2013] I think any first-order statement in that system is decidable. [Thu May 30 12:11:17 2013] In fact, if you just have no relation symbols other than equality, I think it's decidable. [Thu May 30 12:11:30 2013] (and probably no function symbols either...) [Thu May 30 12:12:12 2013] http://en.wikipedia.org/wiki/Presburger_arithmetic -- this is a decidable theory -- it's statements of arithmetic about addition [Thu May 30 12:12:45 2013] and that would include all the statements which didn't actually mention addition [Thu May 30 12:16:58 2013] Heh, right, the worst-case runtime of any decision algorithm for Presburger arithmetic is at least doubly exponential. [Thu May 30 12:20:18 2013] http://coq.inria.fr/pylons/pylons/contribs/view/Presburger/v8.4 :D [Thu May 30 12:20:26 2013] Hm. So that page states that Presburger arithmetic is complete and decidable. Doesn't completeness imply decidability? [Thu May 30 12:21:24 2013] And what would decidable mean in an incomplete theory? [Thu May 30 12:22:50 2013] It's perhaps a bit easier to see the difference between completeness and decidability in classical logic [Thu May 30 12:23:38 2013] Completeness means that for every statement P in the language, either there's a proof of P or a proof of not P (but note, our ambient logic has LEM, so we might be able to prove this without being able to say which) [Thu May 30 12:23:56 2013] Decidability means we can say which. [Thu May 30 12:24:23 2013] You could formalise completeness inside an intuitionistic system by double negation. [Thu May 30 12:25:11 2013] But doesn't the statement "either there's a proof of P or there's a proof of not P" imply that searching through all possible proofs will eventually find you one, thus meaning that all statements are decidable? [Thu May 30 12:27:36 2013] Be back soon; shower. [Thu May 30 12:27:41 2013] Hmm! You might be right :) [Thu May 30 12:28:48 2013] Oh, right... [Thu May 30 12:29:12 2013] This is model theoretic completeness we're talking about now [Thu May 30 12:30:19 2013] So, "complete" here means that every statement which is true in every interpretation of the system is a theorem. [Thu May 30 12:31:43 2013] http://en.wikipedia.org/wiki/Completeness#Logical_completeness -- somewhat annoyingly, there are a lot of different concepts for which people use this word. [Thu May 30 12:32:01 2013] (within logic, even) [Thu May 30 12:44:34 2013] erm... rather bizarre error: [Thu May 30 12:44:35 2013] http://waste.io7m.com/2013/05/30/ouch.v [Thu May 30 12:45:03 2013] this is with 8.4pl2 [Thu May 30 12:46:12 2013] rewrite gives that error in the comment, "assumption" claims there's no such hypothesis [Thu May 30 12:46:33 2013] replacing the last "exists e" with "exists f" results in Failure f = Failure f, which is solvable trivially [Thu May 30 13:20:58 2013] Ah fudge, right, there are two meanings of completeness. [Thu May 30 13:21:20 2013] So essentially, one means "every statement is either necessarily true or necessarily false", and the other means "every necessarily true statement has a proof"? [Thu May 30 13:22:32 2013] And Gödel's completeness theorem states that the latter is true in certain systems. I've forgotten which systems those are (and I'd forgotten that it wasn't true for *all* systems). [Fri May 31 11:47:46 2013] hm, i have the following error monad definition and a function find_m that works with them: [Fri May 31 11:47:49 2013] http://waste.io7m.com/2013/05/31/in.txt [Fri May 31 11:48:13 2013] i'm trying to state (not prove, but state) a lemma that says that each value of type S that's passed to f is taken from ts [Fri May 31 11:48:28 2013] find myself unable to actually phrase the lemma... [Fri May 31 11:49:05 2013] it's obviously trivially true, but if the definition of find_m is opaque, it's impossible to know from outside [Fri May 31 11:49:32 2013] i suppose i mean abstract, not opaque [Fri May 31 11:49:36 2013] It's not opaque though [Fri May 31 11:49:45 2013] hehe, got there before me [Fri May 31 11:49:56 2013] (or abstract) [Fri May 31 11:49:57 2013] it's not opaque there, no, but there'll be a module signature that makes it abstract [Fri May 31 11:50:09 2013] So, prove the theorem inside the module? [Fri May 31 11:50:31 2013] please re-read what i wrote... it's not the proving that's the issue, but the actual writing of the lemma [Fri May 31 11:50:43 2013] i'm not sure how to refer to the parameter of f in the lemma [Fri May 31 11:51:53 2013] ah, okay [Fri May 31 11:52:49 2013] Well, you could apply find_m to an f which only produces Success in the case where it's applied to an element of the list [Fri May 31 11:53:34 2013] hm [Fri May 31 11:53:56 2013] hmm [Fri May 31 11:54:28 2013] Ah, but you're manipulating that too... [Fri May 31 11:56:22 2013] hm... i suppose i could write another definition of find_m that also passes in a proof that List.In x ts [Fri May 31 11:56:34 2013] and then prove that it gives the same results for all f [Fri May 31 11:57:14 2013] not exactly ideal [Fri May 31 11:58:41 2013] by gives the same results, i obviously mean "prove the two are equivalent" so that i can rewrite occurrences of find_m in proofs [Fri May 31 12:04:02 2013] I guess we're trying to formalise parametricity for this case. [Fri May 31 12:09:01 2013] I asked lambdabot: @free find_m :: (s -> Either f (Maybe t)) -> [s] -> Either f (Maybe t) [Fri May 31 12:09:21 2013] and it gave me $map_Either g ($map_Maybe h) . k = p . f => $map_Either g ($map_Maybe h) . find_m k = find_m p . $map f [Fri May 31 12:09:53 2013] hm, right [Fri May 31 12:10:58 2013] So, let me restate that in coq... [Fri May 31 12:18:37 2013] you'll want to eta expand that, most likely [Fri May 31 12:18:44 2013] yes [Fri May 31 12:48:50 2013] http://hpaste.org/89027 [Fri May 31 12:48:53 2013] rmk0: ^^ [Fri May 31 12:48:57 2013] * eyes it [Fri May 31 12:49:14 2013] hehe, ouch [Fri May 31 12:49:27 2013] thanks for putting in the effort :) [Fri May 31 12:49:40 2013] * dissects it [Fri May 31 12:49:43 2013] Well, this might be somewhat more general than what you actually need... [Fri May 31 12:52:14 2013] But it's sort of a way of saying that find_m doesn't know or care about what its type parameters are. [Fri May 31 12:52:43 2013] right [Fri May 31 17:17:52 2013] Isn't there a version of Coq which doesn't require one to write all those useless quantified variables? [Fri May 31 17:18:23 2013] idris? ;) [Fri May 31 17:19:11 2013] Well, I like idris, but probably the ecosystem isn't as developed. [Fri May 31 17:19:26 2013] Idris is not 'proven technology' ;) [Fri May 31 17:19:49 2013] There is Generalizable Variables and ` [Fri May 31 17:20:06 2013] tomprince: `, list more [Fri May 31 17:20:26 2013] * was mostly trolling, which I usually do in reverse on #idris [Fri May 31 17:20:48 2013] tomprince: how do I google for `? [Fri May 31 17:21:49 2013] Lookin the index of the coq manual? [Fri May 31 17:26:43 2013] tomprince: I did now. [Fri May 31 17:26:52 2013] tomprince: ` cannot be found by the pdf search. [Fri May 31 17:27:07 2013] tomprince: and it's also not near the symbols at the start of the global index. [Fri May 31 17:27:23 2013] tomprince: that's wherer it should have been listed, if the manual was sane. [Fri May 31 17:34:09 2013] They are called generalizing binders... [Fri May 31 18:15:53 2013] Cale: i think i understand your 'find' theorem, but i'm having trouble seeing how to apply it to my original problem. i've got an example here that tries to explain why i was doing this in the first place: [Fri May 31 18:15:56 2013] http://waste.io7m.com/2013/05/31/find.txt [Fri May 31 18:16:25 2013] basically, i'd written 'decide0' and was calling it via find_m. unfortunately, i needed more information when doing proofs about decide0, so i needed to add some preconditions in the form of proofs [Fri May 31 18:16:46 2013] unfortunately, i couldn't then actually pass the proof arguments, for obvious reasons [Fri May 31 18:17:00 2013] am not sure if there's a better way to achieve this [Fri May 31 18:17:50 2013] Er, sorry, what are you actually trying to prove? Maybe a concrete example would help. [Fri May 31 18:18:12 2013] er, it's more the problem that the original is hundreds of lines [Fri May 31 18:18:27 2013] i didn't think you'd really want to sift through all of that nonsense [Fri May 31 18:18:38 2013] The theorem statement is? [Fri May 31 18:19:02 2013] it's actually not even a theorem that's the problem... it's "find1" in that example [Fri May 31 18:19:13 2013] oh [Fri May 31 18:19:15 2013] i have List.Forall P xs, and decide1 requires P x [Fri May 31 18:19:26 2013] i can show P x if i can show List.In x xs [Fri May 31 18:19:34 2013] but i lose that information via find_m, i think [Fri May 31 18:20:01 2013] Well, where did you get x from? [Fri May 31 18:20:12 2013] You should be able to build a proof of In x xs while traversing xs [Fri May 31 18:20:27 2013] does that not need to be done inside the find_m function? [Fri May 31 18:20:30 2013] maybe i'm missing something obvious [Fri May 31 18:20:40 2013] um... [Fri May 31 18:20:53 2013] Okay, maybe it does [Fri May 31 18:21:07 2013] Let me fire up coq again :) [Fri May 31 18:21:26 2013] i'm entirely willing to entertain the suggestion that there's a stupid answer staring me right in the face :) [Fri May 31 18:21:29 2013] it wouldn't be the first [Fri May 31 18:22:06 2013] We can add the proof as a parameter to f [Fri May 31 18:22:11 2013] I think [Fri May 31 18:22:21 2013] If that will be useful... [Fri May 31 18:22:35 2013] pretty sure that'd work [Fri May 31 18:22:50 2013] and T can become some type which contains that proof if you need it beyond that [Fri May 31 18:23:53 2013] errr [Fri May 31 18:24:31 2013] hmm, there might be a better way to do this than I'm thinking, but screw it, I'm adding a new inductive type :) [Fri May 31 18:24:36 2013] hehe [Fri May 31 18:25:28 2013] essentially, the proof argument to decide1 isn't actually used inside decide1, i don't think, but it is used when proving things about decide1 [Fri May 31 18:25:37 2013] doubt that matters [Fri May 31 18:26:15 2013] ... that statement may be wrong [Fri May 31 18:26:24 2013] *ahem* [Fri May 31 19:16:48 2013] rmk0: lol, I AM NOT GOOD AT COQ... but I did this clumsy thing which might help [Fri May 31 19:17:14 2013] hehe [Fri May 31 19:18:02 2013] actually, I'm pretty sure one could write these definitions in a fixpoint style, but screw it, having lists of subgoals is nice sometimes... [Fri May 31 19:18:12 2013] http://hpaste.org/89045 [Fri May 31 19:18:36 2013] thanks... eyeing it now [Fri May 31 19:18:38 2013] So, what this does, is to turn a plain list into a list of elements together with proofs that those elements belong to the whole list [Fri May 31 19:19:04 2013] ah yeah, i wondered about doing something like this [Fri May 31 19:19:08 2013] I'm sure that this needn't be quite as awkward as I've made it [Fri May 31 19:19:09 2013] a "zip" for propositions [Fri May 31 19:20:13 2013] thanks again, it's definitely something to try [Fri May 31 19:20:16 2013] I also defined a mapping from my own inductive definition of proofs that elements belong to lists to the usual one, because meh. [Fri May 31 19:20:38 2013] I didn't really bother trying to figure out how to work with the definition of In [Fri May 31 19:20:45 2013] can often be less painful than the standard library [Fri May 31 19:22:50 2013] Compute InProofs (1 :: 2 :: nil). [Fri May 31 19:22:53 2013] gives: [Fri May 31 19:23:04 2013] exist (fun x : nat => InProof x (1 :: 2 :: nil)) 1 Here :: exist (fun x : nat => InProof x (1 :: 2 :: nil)) 2 (There Here) :: nil [Fri May 31 19:23:23 2013] I should probably swap the args to InProof [Fri May 31 19:23:43 2013] right [Fri May 31 19:25:02 2013] heh, doesn't really help the display, because it's eta expanded by definition [Fri May 31 19:31:27 2013] So anyway, we can now write: [Fri May 31 19:31:30 2013] Definition Ins {A} (xs : list A) : list {x : A | In x xs} := map (ProofMapExist (fun x => InProofToIn A x xs)) (InProofs xs). [Fri May 31 19:32:02 2013] and, I swapped the parameters to find_m around because I'm going to write find_m' which needs a dependency: [Fri May 31 19:32:09 2013] Definition find_m' {F S T} (ts : list S) (f : { x : S | In x ts } -> t F (option T)) : t F (option T) := [Fri May 31 19:32:10 2013] find_m (Ins ts) f. [Fri May 31 19:32:55 2013] rmk0: and so there you go :) [Fri May 31 19:33:26 2013] nice [Fri May 31 19:33:53 2013] thanks, will try to integrate this [Fri May 31 19:35:13 2013] http://24.media.tumblr.com/tumblr_m82svgRg7a1qmn40mo1_500.gif -- Accurate depiction of how I write programs in Coq [Fri May 31 19:35:31 2013] hehe [Fri May 31 19:35:56 2013] it can be nasty when you've written something that works, and then come to do the _last_ proof and find that you need some extra fact passed through the program [Fri May 31 19:36:24 2013] it... tends to snowball [Fri May 31 19:36:31 2013] as this did [Fri May 31 19:38:18 2013] It might be worth figuring out how to translate away my InProof type, because it ought to slow things down a good bit if you're actually computing with this stuff. [Fri May 31 19:38:27 2013] er [Fri May 31 19:38:29 2013] yeah [Fri May 31 19:38:30 2013] won't be, thankfully [Fri May 31 19:39:20 2013] This is the most elaborate implementation of zip [0..] I've ever written. [Fri May 31 19:39:26 2013] hehe, yep [Fri May 31 19:40:33 2013] it's a very neurotic zip [Fri May 31 19:40:39 2013] has to prove to itself that it does zip [Fri May 31 19:41:33 2013] the whole point of this was to attempt to formalize the semantics of http://io7m.com/software/jvvfs [Fri May 31 19:42:05 2013] ran into a nasty inconsistency, so i decided to tear the whole thing down, write the semantics, then reimplement [Fri May 31 19:42:12 2013] is long overdue, really [Fri May 31 19:42:38 2013] discovered a few other minor issues in the process, so it was time well spent regardless [Fri May 31 19:43:23 2013] so, er... won't actually be computing with the result [Fri May 31 19:43:28 2013] or even extracting a program from it [Fri May 31 19:43:47 2013] minor sadness about the latter, but i'll live [Sat Jun 1 02:55:38 2013] simpl can reduce "length (1::2::3::nil)" to 3. [Sat Jun 1 02:56:02 2013] is there some functino which will take "(length (1::2:;3::nil))" as an input and return me a nat as output? [Sat Jun 1 02:56:21 2013] there are situations where I can apply a tactic on "3", but not on "(length (1::2::3::nil))" [Sat Jun 1 02:56:24 2013] sure... id :P [Sat Jun 1 02:56:50 2013] perhaps "change (length (1::2::3::nil)) with 3." [Sat Jun 1 02:57:27 2013] nothign liek "eval simpl" or "eval compute" ? [Sat Jun 1 02:57:34 2013] if I could have that embeeded in a tactic, I'd be happy [Sat Jun 1 02:58:22 2013] well, there's the "simpl" tactic... [Sat Jun 1 02:58:25 2013] and the "compute" tactic [Sat Jun 1 03:01:19 2013] here is a minimal fail case: http://hpaste.org/89053 [Sat Jun 1 03:01:24 2013] the first call to "silly" works. [Sat Jun 1 03:01:26 2013] the second does not [Sat Jun 1 03:01:30 2013] how do I make the second call work? :-) [Sat Jun 1 03:04:39 2013] oh, I don't know about in ltac [Sat Jun 1 03:06:16 2013] well, I don't need it in ltac [Sat Jun 1 03:06:28 2013] I just need Coq to change (length (1::2::3::nil)) to "3" before ltac gets it [Sat Jun 1 03:08:34 2013] thus, i feel there is some solution involving simpl and compute [Sat Jun 1 16:58:52 2013] I notice that Type = Type : Prop. Do instances of the word "Prop" have universes associated with them just like instances of Type? [Sat Jun 1 17:56:39 2013] I guess that shouldn't be surprising at all. If a record type has a Type as one of its fields, then certainly instances of the name of the record type would have to have universes. [Sat Jun 1 18:33:11 2013] So I'm trying to define everything in Coq. [Sat Jun 1 18:33:26 2013] Two concepts down, and, uh... infinitely many to go! [Sat Jun 1 19:34:36 2013] Now, if you're in the middle of defining something, is there a way to say "instead of stating what this thing is now, I'm going to provide a proof at the end of the definition"? [Sat Jun 1 19:34:43 2013] I seem to remember a way you could do that. [Sat Jun 1 19:35:21 2013] Maybe that way was just to do the entire definition as a Theorem. [Sat Jun 1 20:07:41 2013] Program does that. [Sat Jun 1 20:08:47 2013] Hmm. [Sun Jun 2 12:38:50 2013] if i have an hyptheses "forall x : X, somestatement". how can i create a new hyptheses with a concrete x = x0? [Sun Jun 2 12:39:52 2013] thorsten`: apply it, it's a function [Sun Jun 2 12:40:56 2013] how? [Sun Jun 2 12:42:27 2013] a hypothesis H : forall x : X, ... is just like H : X -> ... [Sun Jun 2 12:42:30 2013] except that ... can mention x, of course [Sun Jun 2 12:42:39 2013] so H v : ... where v : X [Sun Jun 2 12:44:45 2013] but it seems i can't just use (H v). [Sun Jun 2 12:45:26 2013] what happens? [Sun Jun 2 12:45:57 2013] rewrite <- Bla in (H v). gives me: Syntax error: 'type' 'of' expected after '(' (in [hypident]). [Sun Jun 2 12:46:34 2013] you can e.g. pose proof (H v) as Hv. [Sun Jun 2 12:46:41 2013] or pose (H v) as Hv. if you want to keep it transparent [Sun Jun 2 12:47:38 2013] nice [Sun Jun 2 12:47:45 2013] that's what i was looking for [Sun Jun 2 15:36:42 2013] ugh, any idea how i might crush this "ill-typed" error?: [Sun Jun 2 15:36:47 2013] http://waste.io7m.com/2013/06/02/illtyped.txt [Sun Jun 2 15:37:05 2013] it's taken from a larger development (which i've stripped out and replaced with axioms so that nobody has to read thousands of lines of coq) [Sun Jun 2 15:37:29 2013] am running into a problem trying to rewrite with an equality there, most likely because of the dependent match in lookup_ex [Sun Jun 2 15:47:30 2013] rmk0: which version of Coq? [Sun Jun 2 15:52:10 2013] Ptival: 8.4pl2 [Sun Jun 2 16:14:18 2013] rmk0: that is weird [Sun Jun 2 16:14:23 2013] even if x is equal to x0 [Sun Jun 2 16:14:47 2013] why would k1 be equal to k0? [Sun Jun 2 16:20:04 2013] .. i see what you mean [Sun Jun 2 16:23:00 2013] if x = x0, they k1 = k0 if i allow proof irrelevance [Sun Jun 2 16:23:04 2013] *then [Sun Jun 2 16:23:42 2013] sure [Sun Jun 2 16:23:43 2013] but i obviously can't do that rewrite either (as k1 is used in the goal) [Sun Jun 2 16:23:55 2013] yeah the rewrite has a dependency [Sun Jun 2 17:09:58 2013] ugh... that lookup_ex definition seems extremely hard to work with [Sun Jun 2 17:10:05 2013] almost any theorem i attempt runs into that problem [Sun Jun 2 17:10:17 2013] am just trying to show that it gives the same results as 'lookup' [Sun Jun 2 17:10:42 2013] is there some trick to working with dependent matches like that? [Sun Jun 2 18:22:48 2013] rmk0: [subst] will perform the rewrite you need [Sun Jun 2 18:47:14 2013] robbert: ah, yes, thank you [Sun Jun 2 18:47:41 2013] i always forget that subst exists [Mon Jun 3 09:10:51 2013] hi! [Mon Jun 3 09:12:00 2013] I have an hypothesis of the form "H: (x, y) = (Term1, Term2)", is there some way to get "H1 : x = Term1 /\ H2: y = Term2" ? [Mon Jun 3 09:12:27 2013] ... yes, inversion [Mon Jun 3 09:12:34 2013] sorry, for the noise [Mon Jun 3 09:15:18 2013] "injection H" is the simplest form I think [Mon Jun 3 09:15:43 2013] oh, ok [Mon Jun 3 12:45:35 2013] If I have something of the style "Definition A := B -> Type." and a "b : B", how can I define something to be of type "A b"? [Mon Jun 3 12:46:53 2013] I tried with a "fun b => Blah", but I'm asked to provide a Type for Blah. [Mon Jun 3 13:01:59 2013] ryanakca: difficult to reply with so few context... where does Blah come from? [Mon Jun 3 13:23:51 2013] ryanakca, since A : Type, A b is not well typed, so you certainly won't be able to give an inhabitant of it [Mon Jun 3 14:45:37 2013] sgnb: "Blah" was just a placeholder for a series of random stabs in the dark to try to find something that typechecked. I've got something working-ish now, thanks [Mon Jun 3 14:48:15 2013] robbert: I'm having a bit of conceptual difficulty here, since I thought that "A" was something that took a "B" and became a Type, e.g., for all b : B, (A b) is of type Type. What does the "B -> Type" stand for, if not that? [Mon Jun 3 15:36:24 2013] an element of A, is an element of B -> Type (since A is defined as such). Hence an element of A is something that takes a b : B [Mon Jun 3 15:36:33 2013] ryanakca: ^^ [Mon Jun 3 15:47:26 2013] robbert: Aha, thanks! [Tue Jun 4 07:49:27 2013] Hi guys. I have a question for ya. I'd like to turn "fs ++ nil" into fs, where fs is a list of something. For that I'm trying to do "rewrite (app_nil_r fs)." but that gives me "Error: Found no subterm matching "fs ++ Datatypes.nil"" presumably because nil and Datatypes.nil are not the same.. [Tue Jun 4 07:49:53 2013] Also, reflexivity will not prove "Datatypes.nil = nil", so I assume it's a matter of more than unfolding. [Tue Jun 4 07:50:26 2013] have you redefined nil or something? [Tue Jun 4 07:50:53 2013] Nope [Tue Jun 4 07:53:07 2013] I am confused too, do you have a file that reproduces this error? [Tue Jun 4 07:54:06 2013] I'll try to extract it now. [Tue Jun 4 07:56:39 2013] Hmm, it works immediately outside the lemma I'm working on, but not inside. This is wierd. [Tue Jun 4 08:34:02 2013] 'lo. i'm almost ready to release my first non-trivial coq development: https://github.com/io7m/jvvfs-model2 [Tue Jun 4 08:34:38 2013] i have three Admitted proofs in PathVirtual.v and one in ListAux.v, was wondering if i somebody in here would be kind enough to assist in crushing them [Tue Jun 4 09:38:24 2013] rmk0: prefixes_correct is false. List.In nil (prefixes nil), but (nil <> nil) is false. [Tue Jun 4 09:42:04 2013] ah, yes [Tue Jun 4 09:42:43 2013] hm... wonder what i meant there [Tue Jun 4 09:43:30 2013] lonkz: you probably have a hypothesis called nil [Tue Jun 4 09:44:41 2013] looks like i only depend on prefixes_correct in one other lemma, and nothing depends on that [Tue Jun 4 09:44:58 2013] i could probably cheat and eliminate both [Tue Jun 4 09:46:25 2013] perhaps prefixes nil should be nil [Tue Jun 4 09:47:41 2013] yeah, that seems like a harmless change [Tue Jun 4 09:48:03 2013] i use it to calculate the ancestors of paths (see PathVirtual.v#enumeration) [Tue Jun 4 09:48:13 2013] and i'm explicitly not passing nil there anyway... [Tue Jun 4 14:17:01 2013] I can't compile software foundations source, here's the error log with coqc version details: http://hpaste.org/89297 can anyone help ? [Wed Jun 5 15:15:42 2013] I have a function defined like [Wed Jun 5 15:15:42 2013] Fixpoint f x := g (match x with ... end) [Wed Jun 5 15:15:42 2013] when I do "unfold f." in proof mode, a term like "f foo" becomes "(fix f x := g (match x with ... end)) foo" [Wed Jun 5 15:15:42 2013] how do I get it to actually apply the argument one recursive step, and get "g (match foo with ... end)" ? [Wed Jun 5 15:15:45 2013] and does that even make sense? [Wed Jun 5 15:46:46 2013] kini: This isn't really an answer, but my usual approach is to try simpl, and if it doesn't simplify, use induction. [Wed Jun 5 15:47:48 2013] (i.e. if you can actually match foo with one of the patterns, then it ought to be able to reduce somewhat) [Wed Jun 5 15:49:59 2013] that's a good idea, thanks Cale :) [Wed Jun 5 15:50:02 2013] let's see... [Wed Jun 5 15:50:45 2013] yup, destruct works perfectly :D [Wed Jun 5 15:50:48 2013] thanks! [Wed Jun 5 15:51:00 2013] You also usually shouldn't have to unfold recursive definitions manually like that. [Wed Jun 5 15:52:09 2013] why's that? [Wed Jun 5 15:52:22 2013] Try the same proof without the unfold [Wed Jun 5 15:52:34 2013] basically I wanted to use a lemma which said that g was idempotent, to show that g (f (...)) = f (...) [Wed Jun 5 15:52:48 2013] and I didn't think the lemma would match unless there was a literal g (g (...)) [Wed Jun 5 15:53:08 2013] ah, but apparently you're right, it does :) [Wed Jun 5 15:53:23 2013] I did have to destruct first, otherwise it gets stuck (but in that case it gets stuck even if I do unfold) [Fri Jun 7 06:29:51 2013] Hi. [Fri Jun 7 10:59:09 2013] ugh, very frustrating [Fri Jun 7 10:59:27 2013] still stuck on those same few proofs [Fri Jun 7 10:59:59 2013] have tried several implementations of the list "prefixes" function (called "inits" in haskell) [Fri Jun 7 11:00:06 2013] they all seem brutally difficult to reason about [Fri Jun 7 11:02:54 2013] two of the admitted theorems seemed false, those have been adjusted now [Fri Jun 7 11:18:53 2013] http://waste.io7m.com/2013/06/07/prefixes.v [Fri Jun 7 11:19:00 2013] these are the two that are causing aggravation right now [Fri Jun 7 11:20:28 2013] i have no idea how to proceed... in both cases the difficulty comes from showing that 'map' ends up building prefixes of the original list [Fri Jun 7 11:20:46 2013] other implementations that didn't use List.map seemed no easier to reason about [Fri Jun 7 11:41:45 2013] ah, just solved the first one [Sat Jun 8 18:17:07 2013] ugh, anyone able to assist? stuck on "prefixes_including_self_last_self": http://waste.io7m.com/2013/06/08/prefixes3.v [Sat Jun 8 18:17:14 2013] the induction hypothesis is deeply unhelpful [Sat Jun 8 18:17:54 2013] "last (prefixes_including_self xs)" is basically (Some . id) [Sat Jun 8 18:29:21 2013] doesn't seem very inductive [Sat Jun 8 18:32:21 2013] not really, no [Sat Jun 8 18:39:29 2013] http://paste.awesom.eu/Ptival/pZG this works [Sat Jun 8 18:40:11 2013] ah, thank you [Sat Jun 8 18:40:16 2013] * studies it [Sat Jun 8 18:40:56 2013] the proofs in this file have cost me blood [Sat Jun 8 18:41:27 2013] have so far taken almost as long as the rest of the development [Sat Jun 8 18:41:32 2013] not sure why [Sat Jun 8 19:27:18 2013] rmk0: maybe because you stopped implementing all the boring boilerplate and started implementing the logic of your application, which might be more complicated and less general :-) [Sat Jun 8 19:32:58 2013] ah, this is actually one function of one tiny piece [Sat Jun 8 19:33:25 2013] http://github.com/io7m/jvvfs-model2/tree/alt-prefixes [Sat Jun 8 19:33:27 2013] it's that pile [Sat Jun 8 19:34:45 2013] rmk0: may I ask what kind of project is it, you are working on? [Sat Jun 8 19:35:06 2013] out of curiosity [Sat Jun 8 19:35:13 2013] well, the story is that i initially wrote: http://mvn.io7m.com/jvvfs [Sat Jun 8 19:35:22 2013] I'd like to know if many people actually write real code in Coq [Sat Jun 8 19:35:28 2013] and "write semantics for jvvfs" had been on the todo list for 18 months [Sat Jun 8 19:35:52 2013] about a month ago, i found a nasty inconsistency in the implementation of jvvfs, so i decided to get the semantics done and rewrite the implementation from scratch [Sat Jun 8 19:36:22 2013] unfortunately i won't be able to formally verify the java code against the specification, but it's better than nothing [Sat Jun 8 19:37:25 2013] have found a few other faulty assumptions in the implementation in the process of writing this, so it was definitely time well spent [Sat Jun 8 19:38:29 2013] do you use ocaml-java after extraction? [Sat Jun 8 19:39:13 2013] there's no extraction, unfortunately [Sat Jun 8 19:39:20 2013] when ocaml-java matures, i'll be looking into it [Sat Jun 8 19:39:33 2013] nice [Sat Jun 8 19:39:50 2013] now I started to see a real benefit of ocaml-java :-) [Sat Jun 8 19:39:54 2013] it'll just be hand-written java, informally checked against the coq specification until then [Sat Jun 8 19:40:13 2013] better than nothing! [Sat Jun 8 19:40:16 2013] yep [Sat Jun 8 19:40:20 2013] ocaml on the jvm would be nice [Sat Jun 8 19:40:46 2013] i miss algebraic types and pattern matching whenever i work with java [Sat Jun 8 19:40:54 2013] Scala is fine though [Sat Jun 8 19:41:06 2013] i couldn't get along with it [Sat Jun 8 19:41:15 2013] subtyping + implicits are ... chaotic [Sat Jun 8 19:41:29 2013] and the tool support is extremely poor... broken IDE and very long compilation times, etc [Sat Jun 8 19:41:52 2013] yes, it has quirkiness but it's good when you realise that it allows functional code [Sat Jun 8 19:42:06 2013] think most of the problems with it are down to the fact that they wanted strong interoperability with java [Sat Jun 8 19:42:08 2013] the code is quite dense though [Sat Jun 8 19:42:16 2013] have to inherit most of java's type system damage [Sat Jun 8 19:42:39 2013] yep, they did achieve that, and what i can say, it's almost flawless [Sat Jun 8 19:42:52 2013] (to defend Scala; not my favourite language, but still sane) [Sat Jun 8 19:43:04 2013] there are certainly worse options than scala [Sat Jun 8 19:43:33 2013] yes, indeed [Sat Jun 8 20:15:46 2013] rmk0: Yeah, I was actually going to suggest doing that. The inductive definitions of predicates seem to be easier to work with. [Sat Jun 8 20:16:13 2013] Cale: much easier, yes [Sat Jun 8 20:16:47 2013] lovely to work with using the inversion tactic, too [Sat Jun 8 21:21:29 2013] [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp [Sat Jun 8 21:32:57 2013] [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup [Sat Jun 8 21:33:53 2013] [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Sun Jun 9 15:04:37 2013] Can anyone help me prove "forall (objD : Type) (o0 : objD) (H1 : @eq objD o0 o0) (T : objD -> Type) (m : T o0), @eq (T o0) match H1 in (@eq _ _ o) return (T o0) with | eq_refl => m end match H1 in (@eq _ _ y) return (T y) with | eq_refl => m end."? [Sun Jun 9 15:04:37 2013] Can anyone help me prove "forall (objD : Type) (o0 : objD) (H1 : @eq objD o0 o0) (T : objD -> Type) (m : T o0), @eq (T o0) match H1 in (@eq _ _ o) return (T o0) with | eq_refl => m end match H1 in (@eq _ _ y) return (T y) with | eq_refl => m end."? [Sun Jun 9 19:28:03 2013] Okay, I'm trying to make a type that is (list nat, nat) with the property that all elements in the list are less than a certain number (the second element). I would expect to be able to write this as `Inductive MaxList (n:nat) : Type := max_list : list nat -> n -> Maxlist n`, but that is disallowed, as `n` is not a Type. Can someone either explain how I'm thinking wrong, or point me at some similar [Sun Jun 9 19:28:03 2013] Okay, I'm trying to make a type that is (list nat, nat) with the property that all elements in the list are less than a certain number (the second element). I would expect to be able to write this as `Inductive MaxList (n:nat) : Type := max_list : list nat -> n -> Maxlist n`, but that is disallowed, as `n` is not a Type. Can someone either explain how I'm thinking wrong, or point me at some similar [Sun Jun 9 19:28:06 2013] example code? [Sun Jun 9 19:28:06 2013] example code? [Sun Jun 9 19:28:59 2013] (I stared at the code for vector for a while, but they explicitly list 0 for nil, and `forall (n:nat), n -> (S n)` after that, so they seem to dodge the issue.) [Sun Jun 9 19:28:59 2013] (I stared at the code for vector for a while, but they explicitly list 0 for nil, and `forall (n:nat), n -> (S n)` after that, so they seem to dodge the issue.) [Sun Jun 9 19:29:33 2013] you can just omit "n ->" [Sun Jun 9 19:29:33 2013] you can just omit "n ->" [Sun Jun 9 19:35:50 2013] miller: not sure if you're aware, but there's some stuff in the standard library you can use here: https://outland.arc7.info/2013/06/09/Less.v [Sun Jun 9 19:35:50 2013] miller: not sure if you're aware, but there's some stuff in the standard library you can use here: https://outland.arc7.info/2013/06/09/Less.v [Sun Jun 9 19:36:21 2013] so "lessers 23" would denote the type of lists where all elements are less than 23 [Sun Jun 9 19:36:21 2013] so "lessers 23" would denote the type of lists where all elements are less than 23 [Sun Jun 9 19:36:23 2013] etc [Sun Jun 9 19:36:23 2013] etc [Sun Jun 9 19:36:53 2013] or you can bundle the list, or bundle both the list and the bound: [Sun Jun 9 19:36:53 2013] or you can bundle the list, or bundle both the list and the bound: [Sun Jun 9 19:36:55 2013] Record foo := { foo_car : list nat; foo_bound : nat; [Sun Jun 9 19:36:55 2013] Record foo := { foo_car : list nat; foo_bound : nat; [Sun Jun 9 19:36:57 2013] foo_prf : Forall (fun x => x < foo_bound) foo_car }. [Sun Jun 9 19:36:57 2013] foo_prf : Forall (fun x => x < foo_bound) foo_car }. [Sun Jun 9 19:36:59 2013] Record bar (n : nat) := { bar_car : list nat; [Sun Jun 9 19:36:59 2013] Record bar (n : nat) := { bar_car : list nat; [Sun Jun 9 19:37:01 2013] bar_prf : Forall (fun x => x < n) bar_car }. [Sun Jun 9 19:37:01 2013] bar_prf : Forall (fun x => x < n) bar_car }. [Sun Jun 9 19:43:46 2013] elliott: Well I feel silly now. How does that magically appear as an argument? Is `Inductive X (n:nat) : Type := foo : X` the same as `Inductive X : Type := foo : forall (n:nat), n -> X` ? [Sun Jun 9 19:43:46 2013] elliott: Well I feel silly now. How does that magically appear as an argument? Is `Inductive X (n:nat) : Type := foo : X` the same as `Inductive X : Type := foo : forall (n:nat), n -> X` ? [Sun Jun 9 19:44:02 2013] rmk0: Was not aware, and is much appreciated. [Sun Jun 9 19:44:02 2013] rmk0: Was not aware, and is much appreciated. [Sun Jun 9 19:44:43 2013] * sits and processes the record idea [Sun Jun 9 19:44:44 2013] * sits and processes the record idea [Sun Jun 9 19:44:56 2013] miller: in "forall n, ...", n is an argument. [Sun Jun 9 19:44:56 2013] miller: in "forall n, ...", n is an argument. [Sun Jun 9 19:45:04 2013] A -> B is just short for forall (_:A), B [Sun Jun 9 19:45:05 2013] A -> B is just short for forall (_:A), B [Sun Jun 9 19:45:20 2013] Oh. [Sun Jun 9 19:45:20 2013] Oh. [Sun Jun 9 19:45:42 2013] in particular, having n as an argument to MaxList means your max_list basically has an implicit "forall n," in front of it [Sun Jun 9 19:45:42 2013] in particular, having n as an argument to MaxList means your max_list basically has an implicit "forall n," in front of it [Sun Jun 9 19:45:50 2013] max_list : forall n, list nat -> MaxList n [Sun Jun 9 19:45:50 2013] max_list : forall n, list nat -> MaxList n [Sun Jun 9 19:46:12 2013] you could make it more explicit like this: Inductive MaxList : nat -> Type := max_list : forall n, list nat -> MaxList n (but I don't recommend doing so) [Sun Jun 9 19:46:12 2013] you could make it more explicit like this: Inductive MaxList : nat -> Type := max_list : forall n, list nat -> MaxList n (but I don't recommend doing so) [Sun Jun 9 20:00:00 2013] miller: your "inductive X"s are not the same. In the first "n" is called a parameter, and in the second an index. Parameters should appear exactly as such in the types of the conclusion of each constructor. [Sun Jun 9 20:00:00 2013] miller: your "inductive X"s are not the same. In the first "n" is called a parameter, and in the second an index. Parameters should appear exactly as such in the types of the conclusion of each constructor. [Sun Jun 9 20:00:38 2013] Indexes can be different in each constructor's conclusion. [Sun Jun 9 20:00:38 2013] Indexes can be different in each constructor's conclusion. [Sun Jun 9 20:01:13 2013] robbert`: it isn't even an index in the second [Sun Jun 9 20:01:13 2013] robbert`: it isn't even an index in the second [Sun Jun 9 20:01:19 2013] it doesn't appear in the resulting type [Sun Jun 9 20:01:19 2013] it doesn't appear in the resulting type [Sun Jun 9 20:01:20 2013] Declaring an argument of an inductive as a parameter (on the left hand side of the ":") instead of an index (on the right hand side) is generally prefered as it gives a stronger elimination principle [Sun Jun 9 20:01:21 2013] Declaring an argument of an inductive as a parameter (on the left hand side of the ":") instead of an index (on the right hand side) is generally prefered as it gives a stronger elimination principle [Sun Jun 9 20:01:50 2013] oh, wait, I misread your second X [Sun Jun 9 20:01:50 2013] oh, wait, I misread your second X [Sun Jun 9 20:02:15 2013] I thought I read Inductive X : nat -> Type [Sun Jun 9 20:02:15 2013] I thought I read Inductive X : nat -> Type [Sun Jun 9 20:02:22 2013] it's late... [Sun Jun 9 20:02:22 2013] it's late... [Mon Jun 10 01:16:48 2013] my god, `coqtop -emacs-U` is taking more than 500 MB of memory? what? [Mon Jun 10 01:16:48 2013] my god, `coqtop -emacs-U` is taking more than 500 MB of memory? what? [Mon Jun 10 01:16:58 2013] surprising, considering I'm not doing anything particularly heavy duty... [Mon Jun 10 01:16:58 2013] surprising, considering I'm not doing anything particularly heavy duty... [Mon Jun 10 06:23:33 2013] kini: same effect here. coqtop (when using with proof general) uses about 400 mb (on some 64 bit system) [Mon Jun 10 06:23:33 2013] kini: same effect here. coqtop (when using with proof general) uses about 400 mb (on some 64 bit system) [Mon Jun 10 06:37:42 2013] how strange [Mon Jun 10 06:37:42 2013] how strange [Mon Jun 10 08:29:34 2013] i have List.NoDup for some xs, and am trying to show that for any two elements x and y in xs, x <> y [Mon Jun 10 08:29:34 2013] i have List.NoDup for some xs, and am trying to show that for any two elements x and y in xs, x <> y [Mon Jun 10 08:29:42 2013] any idea if this is actually provable? [Mon Jun 10 08:29:42 2013] any idea if this is actually provable? [Mon Jun 10 08:29:52 2013] i'm not entirely sure how to phrase the theorem to begin with... [Mon Jun 10 08:29:52 2013] i'm not entirely sure how to phrase the theorem to begin with... [Mon Jun 10 08:30:20 2013] i don't have decidable equality on elements of the list [Mon Jun 10 08:30:20 2013] i don't have decidable equality on elements of the list [Mon Jun 10 08:31:47 2013] rmk0: perhaps: forall xs, NoDup xs -> forall i j, i <> j -> i < length xs -> j < length xs -> nth_error xs i <> nth_error xs j [Mon Jun 10 08:31:47 2013] rmk0: perhaps: forall xs, NoDup xs -> forall i j, i <> j -> i < length xs -> j < length xs -> nth_error xs i <> nth_error xs j [Mon Jun 10 08:32:39 2013] rmk0: or the other way around (less negation...): forall xs, NoDup xs -> forall i j, i < length xs -> j < length xs -> nth_error xs i = nth_error xs j -> i = j [Mon Jun 10 08:32:39 2013] rmk0: or the other way around (less negation...): forall xs, NoDup xs -> forall i j, i < length xs -> j < length xs -> nth_error xs i = nth_error xs j -> i = j [Mon Jun 10 08:33:02 2013] hm [Mon Jun 10 08:33:02 2013] hm [Mon Jun 10 08:33:29 2013] ugly, admittedly [Mon Jun 10 08:33:29 2013] ugly, admittedly [Mon Jun 10 08:34:23 2013] thanks, will try it [Mon Jun 10 08:34:23 2013] thanks, will try it [Mon Jun 10 08:34:30 2013] maybe something like... [Mon Jun 10 08:34:30 2013] maybe something like... [Mon Jun 10 08:35:38 2013] Inductive El {A} : list A -> Type := here : forall x xs, El x (x :: xs) | there : forall x y xs, El x xs -> El x (y :: xs); at : El xs -> A; pos : El xs -> nat; forall xs, NoDup xs -> forall i j : El xs, at i = at j -> pos i = pos j [Mon Jun 10 08:35:38 2013] Inductive El {A} : list A -> Type := here : forall x xs, El x (x :: xs) | there : forall x y xs, El x xs -> El x (y :: xs); at : El xs -> A; pos : El xs -> nat; forall xs, NoDup xs -> forall i j : El xs, at i = at j -> pos i = pos j [Mon Jun 10 08:35:50 2013] where El is just an existential version of the inductive version of In of course [Mon Jun 10 08:35:50 2013] where El is just an existential version of the inductive version of In of course [Mon Jun 10 08:35:54 2013] in fact maybe using In would be best [Mon Jun 10 08:35:54 2013] in fact maybe using In would be best [Mon Jun 10 08:36:00 2013] right [Mon Jun 10 08:36:00 2013] right [Mon Jun 10 08:36:28 2013] ooh [Mon Jun 10 08:36:28 2013] ooh [Mon Jun 10 08:36:44 2013] how about this: forall xs, NoDup xs -> forall x (Hx1 Hx2 : In x xs), pos Hx1 = pos Hx2 [Mon Jun 10 08:36:44 2013] how about this: forall xs, NoDup xs -> forall x (Hx1 Hx2 : In x xs), pos Hx1 = pos Hx2 [Mon Jun 10 08:36:49 2013] where pos is defined in the obvious manner [Mon Jun 10 08:36:49 2013] where pos is defined in the obvious manner [Mon Jun 10 08:37:06 2013] then you can derive the consequence [Mon Jun 10 08:37:06 2013] then you can derive the consequence [Mon Jun 10 08:37:27 2013] hm, yes [Mon Jun 10 08:37:27 2013] hm, yes [Mon Jun 10 08:37:29 2013] forall xs, NoDup xs -> forall x y (Hx : In x xs) (Hy : In y xs), pos Hx <> pos Hy -> x <> y [Mon Jun 10 08:37:29 2013] forall xs, NoDup xs -> forall x y (Hx : In x xs) (Hy : In y xs), pos Hx <> pos Hy -> x <> y [Mon Jun 10 08:37:39 2013] (I think) [Mon Jun 10 08:37:39 2013] (I think) [Mon Jun 10 08:37:40 2013] has the benefit of being the shortest :) [Mon Jun 10 08:37:40 2013] has the benefit of being the shortest :) [Mon Jun 10 08:37:50 2013] I think it specifies the property in the nicest way too [Mon Jun 10 08:37:50 2013] I think it specifies the property in the nicest way too [Mon Jun 10 08:38:04 2013] "given a list with no duplicates, two occurrences of an element in that list must share position" [Mon Jun 10 08:38:04 2013] "given a list with no duplicates, two occurrences of an element in that list must share position" [Mon Jun 10 08:38:30 2013] hence "given a list with no duplicates, two occurrences of two separate elements in that list at different positions must have unequal values" [Mon Jun 10 08:38:30 2013] hence "given a list with no duplicates, two occurrences of two separate elements in that list at different positions must have unequal values" [Mon Jun 10 08:52:47 2013] hm, not so obvious how to define 'pos' actually, given that List.In isn't inductive [Mon Jun 10 08:52:47 2013] hm, not so obvious how to define 'pos' actually, given that List.In isn't inductive [Mon Jun 10 08:53:11 2013] rmk0: can do induction on the list? [Mon Jun 10 08:53:11 2013] rmk0: can do induction on the list? [Mon Jun 10 08:53:12 2013] I think [Mon Jun 10 08:53:12 2013] I think [Mon Jun 10 08:53:23 2013] * thinks In should be inductive [Mon Jun 10 08:53:23 2013] * thinks In should be inductive [Mon Jun 10 08:53:28 2013] it should be, yes [Mon Jun 10 08:53:28 2013] it should be, yes [Mon Jun 10 08:53:52 2013] doing induction on the list gives an error when trying to destruct the In, because the function is in Set [Mon Jun 10 08:53:52 2013] doing induction on the list gives an error when trying to destruct the In, because the function is in Set [Mon Jun 10 08:54:48 2013] rmk0: let me give it a try, I think there's a nice way to do it [Mon Jun 10 08:54:48 2013] rmk0: let me give it a try, I think there's a nice way to do it [Mon Jun 10 08:54:53 2013] ok, thanks [Mon Jun 10 08:54:54 2013] ok, thanks [Mon Jun 10 08:54:58 2013] though maybe not without decidable equality on the A? :/ [Mon Jun 10 08:54:58 2013] though maybe not without decidable equality on the A? :/ [Mon Jun 10 08:55:02 2013] I'll try anyway [Mon Jun 10 08:55:02 2013] I'll try anyway [Mon Jun 10 08:58:33 2013] rmk0: do you care if "pos" is really inefficient? [Mon Jun 10 08:58:33 2013] rmk0: do you care if "pos" is really inefficient? [Mon Jun 10 08:58:56 2013] oh hm [Mon Jun 10 08:58:56 2013] oh hm [Mon Jun 10 08:59:10 2013] not at all [Mon Jun 10 08:59:10 2013] not at all [Mon Jun 10 08:59:41 2013] it might be worth explaining why i'm doing this in the first place [Mon Jun 10 08:59:42 2013] it might be worth explaining why i'm doing this in the first place [Mon Jun 10 09:00:18 2013] i'm trying to prove things about a function that calculates all prefixes of a list: [Mon Jun 10 09:00:18 2013] i'm trying to prove things about a function that calculates all prefixes of a list: [Mon Jun 10 09:00:21 2013] https://outland.arc7.info/2013/06/10/prefixes5.v [Mon Jun 10 09:00:21 2013] https://outland.arc7.info/2013/06/10/prefixes5.v [Mon Jun 10 09:00:40 2013] is_prefix gives the meaning of "being a prefix" [Mon Jun 10 09:00:40 2013] is_prefix gives the meaning of "being a prefix" [Mon Jun 10 09:00:54 2013] "prefixes_including_self" calculates all prefixes of a list, but the result includes the original list [Mon Jun 10 09:00:54 2013] "prefixes_including_self" calculates all prefixes of a list, but the result includes the original list [Mon Jun 10 09:01:07 2013] nothing is a prefix of itself, so the "prefixes" function simply removes the last element from the results [Mon Jun 10 09:01:07 2013] nothing is a prefix of itself, so the "prefixes" function simply removes the last element from the results [Mon Jun 10 09:01:27 2013] am then trying to show that all lists returned by "prefixes" ... are prefixes [Mon Jun 10 09:01:27 2013] am then trying to show that all lists returned by "prefixes" ... are prefixes [Mon Jun 10 09:01:33 2013] *nod* [Mon Jun 10 09:01:33 2013] *nod* [Mon Jun 10 09:01:46 2013] I don't quite see where this lemma comes in but it's an interesting exercise all the same ;) [Mon Jun 10 09:01:46 2013] I don't quite see where this lemma comes in but it's an interesting exercise all the same ;) [Mon Jun 10 09:01:58 2013] hehe, i'm trying to see what led me to it yesterday [Mon Jun 10 09:01:58 2013] hehe, i'm trying to see what led me to it yesterday [Mon Jun 10 09:02:16 2013] ah... List.In xs (List.removelast (prefixes_including_self ys)) -> xs <> ys [Mon Jun 10 09:02:16 2013] ah... List.In xs (List.removelast (prefixes_including_self ys)) -> xs <> ys [Mon Jun 10 09:03:17 2013] wanted to show that all of the "prefixes_including_self" were different to each other, so that i could show that with the last element removed, none of the lists equalled the original list [Mon Jun 10 09:03:17 2013] wanted to show that all of the "prefixes_including_self" were different to each other, so that i could show that with the last element removed, none of the lists equalled the original list [Mon Jun 10 09:03:32 2013] so that i could then pass that fact to prefixes_including_self_correct_0 [Mon Jun 10 09:03:32 2013] so that i could then pass that fact to prefixes_including_self_correct_0 [Mon Jun 10 09:03:41 2013] there may be a better way to do this [Mon Jun 10 09:03:41 2013] there may be a better way to do this [Mon Jun 10 09:05:25 2013] the ultimate goal is obviously to prove "prefixes_correct" without admissions [Mon Jun 10 09:05:25 2013] the ultimate goal is obviously to prove "prefixes_correct" without admissions [Mon Jun 10 09:08:08 2013] looks like an inductive definition of In is the right way to go, tho still some issues with keeping the lists connected/equal when doing the induction (isn't it always the same issue?!) [Mon Jun 10 09:08:08 2013] looks like an inductive definition of In is the right way to go, tho still some issues with keeping the lists connected/equal when doing the induction (isn't it always the same issue?!) [Mon Jun 10 09:11:35 2013] hehe [Mon Jun 10 09:11:35 2013] hehe [Mon Jun 10 09:11:54 2013] no idea why they made In a fixpoint [Mon Jun 10 09:11:54 2013] no idea why they made In a fixpoint [Mon Jun 10 09:12:13 2013] seems like a perfect textbook example of something that shouldn't be one [Mon Jun 10 09:12:13 2013] seems like a perfect textbook example of something that shouldn't be one [Mon Jun 10 09:12:37 2013] well, frankly I have no idea why half the lines in the standard library are the way they are [Mon Jun 10 09:12:37 2013] well, frankly I have no idea why half the lines in the standard library are the way they are [Mon Jun 10 09:12:53 2013] it's quite messy [Mon Jun 10 09:12:53 2013] it's quite messy [Mon Jun 10 09:13:08 2013] The naming and organisation of the coq standard library is completely mysterious to me [Mon Jun 10 09:13:08 2013] The naming and organisation of the coq standard library is completely mysterious to me [Mon Jun 10 09:13:19 2013] think it just sort of accumulated junk [Mon Jun 10 09:13:19 2013] think it just sort of accumulated junk [Mon Jun 10 09:13:23 2013] nobody designed it, obviously [Mon Jun 10 09:13:23 2013] nobody designed it, obviously [Mon Jun 10 09:19:15 2013] rmk0: ok, I have proved it for my own version of In/NoDup [Mon Jun 10 09:19:15 2013] rmk0: ok, I have proved it for my own version of In/NoDup [Mon Jun 10 09:19:17 2013] will clean up & show [Mon Jun 10 09:19:17 2013] will clean up & show [Mon Jun 10 09:19:26 2013] ooh! [Mon Jun 10 09:19:26 2013] ooh! [Mon Jun 10 09:24:30 2013] very ugly proof :/ [Mon Jun 10 09:24:30 2013] very ugly proof :/ [Mon Jun 10 09:25:29 2013] that's no problem... this one function has been holding up my work for about a week now [Mon Jun 10 09:25:29 2013] that's no problem... this one function has been holding up my work for about a week now [Mon Jun 10 09:25:34 2013] will be happy to see it eliminated [Mon Jun 10 09:25:34 2013] will be happy to see it eliminated [Mon Jun 10 09:27:45 2013] rmk0: well, here is the hideous proof: http://sprunge.us/YShS [Mon Jun 10 09:27:45 2013] rmk0: well, here is the hideous proof: http://sprunge.us/YShS [Mon Jun 10 09:27:57 2013] if you use it without cleaning it up, shame on you :) [Mon Jun 10 09:27:57 2013] if you use it without cleaning it up, shame on you :) [Mon Jun 10 09:28:20 2013] hehe, thanks [Mon Jun 10 09:28:20 2013] hehe, thanks [Mon Jun 10 09:28:21 2013] oh, Uniq should be in Prop probably [Mon Jun 10 09:28:21 2013] oh, Uniq should be in Prop probably [Mon Jun 10 09:29:41 2013] * picks it apart [Mon Jun 10 09:29:41 2013] * picks it apart [Mon Jun 10 09:32:15 2013] elliott: i'd like to put you in the contributors file for this project... any particular name i should use? [Mon Jun 10 09:32:15 2013] elliott: i'd like to put you in the contributors file for this project... any particular name i should use? [Mon Jun 10 09:33:36 2013] if you'd like to remain anonymous, that's no problem [Mon Jun 10 09:33:36 2013] if you'd like to remain anonymous, that's no problem [Mon Jun 10 09:33:59 2013] oh, dear, don't credit me for that awful proof :) [Mon Jun 10 09:33:59 2013] oh, dear, don't credit me for that awful proof :) [Mon Jun 10 09:34:03 2013] but seriously, no need [Mon Jun 10 09:34:03 2013] but seriously, no need [Mon Jun 10 09:34:07 2013] hehe [Mon Jun 10 09:34:07 2013] hehe [Mon Jun 10 09:34:29 2013] (here's a slightly cleaned up version that shows the structure, btw: http://sprunge.us/iJES... I wonder if there isn't some destructing tactic that does what I want here) [Mon Jun 10 09:34:29 2013] (here's a slightly cleaned up version that shows the structure, btw: http://sprunge.us/iJES... I wonder if there isn't some destructing tactic that does what I want here) [Mon Jun 10 09:35:20 2013] you mean a "destruct" that doesn't "forget"? [Mon Jun 10 09:35:20 2013] you mean a "destruct" that doesn't "forget"? [Mon Jun 10 09:35:41 2013] vaguely wonder if "inversion" would do it [Mon Jun 10 09:35:41 2013] vaguely wonder if "inversion" would do it [Mon Jun 10 09:35:43 2013] right... I thought "inversion" would work here but it doesn't [Mon Jun 10 09:35:43 2013] right... I thought "inversion" would work here but it doesn't [Mon Jun 10 09:35:47 2013] oh [Mon Jun 10 09:35:47 2013] oh [Mon Jun 10 09:36:05 2013] is annoying behaviour [Mon Jun 10 09:36:05 2013] is annoying behaviour [Mon Jun 10 09:36:09 2013] because it doesn't destruct it in the goal [Mon Jun 10 09:36:09 2013] because it doesn't destruct it in the goal [Mon Jun 10 09:36:14 2013] so to speak [Mon Jun 10 09:36:14 2013] so to speak [Mon Jun 10 09:37:17 2013] at least the proof term is relatively small [Mon Jun 10 09:37:17 2013] at least the proof term is relatively small [Mon Jun 10 10:52:19 2013] ow, run into an issue [Mon Jun 10 10:52:20 2013] ow, run into an issue [Mon Jun 10 10:53:13 2013] https://outland.arc7.info/2013/06/10/elimination.v [Mon Jun 10 10:53:14 2013] https://outland.arc7.info/2013/06/10/elimination.v [Mon Jun 10 10:53:24 2013] elliott: InPT is equivalent to your El definition [Mon Jun 10 10:53:24 2013] elliott: InPT is equivalent to your El definition [Mon Jun 10 10:53:33 2013] right [Mon Jun 10 10:53:33 2013] right [Mon Jun 10 10:53:45 2013] you... may see the problem there [Mon Jun 10 10:53:45 2013] you... may see the problem there [Mon Jun 10 10:53:49 2013] * opens proofgenearl [Mon Jun 10 10:53:49 2013] * opens proofgenearl [Mon Jun 10 10:53:51 2013] *general [Mon Jun 10 10:53:51 2013] *general [Mon Jun 10 10:53:54 2013] Error: Inversion would require case analysis on sort Type which is not [Mon Jun 10 10:53:54 2013] Error: Inversion would require case analysis on sort Type which is not [Mon Jun 10 10:53:55 2013] allowed for inductive definition InP. [Mon Jun 10 10:53:55 2013] allowed for inductive definition InP. [Mon Jun 10 10:54:46 2013] oh, that's easy [Mon Jun 10 10:54:46 2013] oh, that's easy [Mon Jun 10 10:54:50 2013] just do exfalso first [Mon Jun 10 10:54:50 2013] just do exfalso first [Mon Jun 10 10:55:14 2013] * looks it up [Mon Jun 10 10:55:14 2013] * looks it up [Mon Jun 10 10:55:17 2013] if you can derive False (and when deriving False you can of course destruct propositions) then you're OK for a result even in type [Mon Jun 10 10:55:17 2013] if you can derive False (and when deriving False you can of course destruct propositions) then you're OK for a result even in type [Mon Jun 10 10:55:20 2013] exfalso is just elimtype False [Mon Jun 10 10:55:20 2013] exfalso is just elimtype False [Mon Jun 10 10:55:23 2013] i.e. apply False_rect [Mon Jun 10 10:55:23 2013] i.e. apply False_rect [Mon Jun 10 10:55:28 2013] i.e. replace goal with False no matter what the goal is [Mon Jun 10 10:55:28 2013] i.e. replace goal with False no matter what the goal is [Mon Jun 10 10:56:10 2013] now, the next goal you'll find harder [Mon Jun 10 10:56:10 2013] now, the next goal you'll find harder [Mon Jun 10 10:56:16 2013] ah, interesting... didn't realize that was possible [Mon Jun 10 10:56:16 2013] ah, interesting... didn't realize that was possible [Mon Jun 10 10:56:21 2013] in fact, I believe it is impossible without decidable equality on A or something, even if that [Mon Jun 10 10:56:21 2013] in fact, I believe it is impossible without decidable equality on A or something, even if that [Mon Jun 10 10:56:29 2013] InPT is less proof irrelevant than InP [Mon Jun 10 10:56:29 2013] InPT is less proof irrelevant than InP [Mon Jun 10 10:56:36 2013] yep [Mon Jun 10 10:56:36 2013] yep [Mon Jun 10 10:56:41 2013] in essence, proof irrelevance hides the "pos" of InP [Mon Jun 10 10:56:41 2013] in essence, proof irrelevance hides the "pos" of InP [Mon Jun 10 10:56:50 2013] and you can never hope to recover it back to InPT without more information [Mon Jun 10 10:56:50 2013] and you can never hope to recover it back to InPT without more information [Mon Jun 10 10:57:00 2013] my suggestion is to just use InPT throughout unless you have a good reason not to [Mon Jun 10 10:57:00 2013] my suggestion is to just use InPT throughout unless you have a good reason not to [Mon Jun 10 10:57:11 2013] right [Mon Jun 10 10:57:11 2013] right [Mon Jun 10 10:57:24 2013] it's probably enough that i can get back to InP [Mon Jun 10 10:57:24 2013] it's probably enough that i can get back to InP [Mon Jun 10 10:58:50 2013] am quite amused at how tricky this "prefixes" function has been [Mon Jun 10 10:58:50 2013] am quite amused at how tricky this "prefixes" function has been [Mon Jun 10 10:59:15 2013] has easily been the hardest part of the entire development [Mon Jun 10 10:59:15 2013] has easily been the hardest part of the entire development [Mon Jun 10 11:00:50 2013] that's computerised proof for you [Mon Jun 10 11:00:50 2013] that's computerised proof for you [Mon Jun 10 11:00:59 2013] 90% annoying boilerplate :P [Mon Jun 10 11:00:59 2013] 90% annoying boilerplate :P [Mon Jun 10 11:01:13 2013] \o/ [Mon Jun 10 11:01:13 2013] \o/ [Mon Jun 10 11:12:26 2013] think it'd introduce inconsistency to take InP -> InPT as an axiom, if it becomes necessary? [Mon Jun 10 11:12:26 2013] think it'd introduce inconsistency to take InP -> InPT as an axiom, if it becomes necessary? [Mon Jun 10 11:12:42 2013] ... might take that one to the mailing list, actually [Mon Jun 10 11:12:42 2013] ... might take that one to the mailing list, actually [Mon Jun 10 11:12:54 2013] they usually know immediately exactly which axiom would be implied [Mon Jun 10 11:12:54 2013] they usually know immediately exactly which axiom would be implied [Mon Jun 10 11:16:35 2013] rmk0: uh, I guess it's not inconsistent [Mon Jun 10 11:16:35 2013] rmk0: uh, I guess it's not inconsistent [Mon Jun 10 11:16:40 2013] you can add stuff where Prop affects Type as an axiom [Mon Jun 10 11:16:40 2013] you can add stuff where Prop affects Type as an axiom [Mon Jun 10 11:16:45 2013] like, weird choice stuff. [Mon Jun 10 11:16:45 2013] like, weird choice stuff. [Mon Jun 10 11:16:49 2013] yep [Mon Jun 10 11:16:49 2013] yep [Mon Jun 10 11:16:53 2013] I recommend you don't, it's not very constructive :P [Mon Jun 10 11:16:53 2013] I recommend you don't, it's not very constructive :P [Mon Jun 10 11:16:59 2013] yep! [Mon Jun 10 11:16:59 2013] yep! [Mon Jun 10 11:17:07 2013] am hoping it won't be necessary [Mon Jun 10 11:17:07 2013] am hoping it won't be necessary [Mon Jun 10 11:17:43 2013] i almost always rely on proof irrelevance though, which isn't very constructive either [Mon Jun 10 11:17:43 2013] i almost always rely on proof irrelevance though, which isn't very constructive either [Mon Jun 10 11:20:11 2013] sure proof irrelevance is constructive enough [Mon Jun 10 11:20:11 2013] sure proof irrelevance is constructive enough [Mon Jun 10 11:20:20 2013] just close your eyes and pretend it's epigram 2 [Mon Jun 10 11:20:20 2013] just close your eyes and pretend it's epigram 2 [Mon Jun 10 11:20:48 2013] * squints [Mon Jun 10 11:20:48 2013] * squints [Mon Jun 10 11:26:05 2013] rmk0: a silly list type that makes this proof trivial: http://sprunge.us/hiId [Mon Jun 10 11:26:05 2013] rmk0: a silly list type that makes this proof trivial: http://sprunge.us/hiId [Mon Jun 10 11:27:02 2013] ah, yes [Mon Jun 10 11:27:02 2013] ah, yes [Mon Jun 10 20:10:07 2013] ugh, oh dear [Mon Jun 10 20:10:07 2013] ugh, oh dear [Mon Jun 10 20:10:33 2013] in using this definition of In that's in Type, it's having the knock-on effect of pushing everything else into Type as well [Mon Jun 10 20:10:33 2013] in using this definition of In that's in Type, it's having the knock-on effect of pushing everything else into Type as well [Mon Jun 10 20:11:56 2013] i don't think i can use this approach [Mon Jun 10 20:11:56 2013] i don't think i can use this approach [Tue Jun 11 01:06:16 2013] I'm having trouble with induction over mutually recursive types. [Tue Jun 11 01:06:16 2013] I'm having trouble with induction over mutually recursive types. [Tue Jun 11 01:06:20 2013] http://www.nomorepasting.com/getpaste.php?pasteid=39436 [Tue Jun 11 01:06:20 2013] http://www.nomorepasting.com/getpaste.php?pasteid=39436 [Tue Jun 11 01:06:38 2013] Simple example which illustrates the problem. [Tue Jun 11 01:06:38 2013] Simple example which illustrates the problem. [Tue Jun 11 01:31:18 2013] The problem, in this case, is that I'd like to do induction on t, but there isn't a "correct" induction hypothesis. [Tue Jun 11 01:31:18 2013] The problem, in this case, is that I'd like to do induction on t, but there isn't a "correct" induction hypothesis. [Tue Jun 11 01:41:21 2013] Pseudonym: I'm not sure I can help. But I also don't see mutual recursion there. [Tue Jun 11 01:41:21 2013] Pseudonym: I'm not sure I can help. But I also don't see mutual recursion there. [Tue Jun 11 01:42:01 2013] dolio: Imagine if instead of list ty, you had a custom list type. [Tue Jun 11 01:42:01 2013] dolio: Imagine if instead of list ty, you had a custom list type. [Tue Jun 11 01:42:52 2013] Inductive ty : Set := ... TyList ... with TyList := | TyNil : TyList | TyCons : ty -> TyList -> TyList. [Tue Jun 11 01:42:52 2013] Inductive ty : Set := ... TyList ... with TyList := | TyNil : TyList | TyCons : ty -> TyList -> TyList. [Tue Jun 11 01:43:01 2013] Then it would be clearly mutual recursion. [Tue Jun 11 01:43:01 2013] Then it would be clearly mutual recursion. [Tue Jun 11 01:43:05 2013] Yeah. [Tue Jun 11 01:43:05 2013] Yeah. [Tue Jun 11 01:43:16 2013] And it still wouldn't work. [Tue Jun 11 01:43:16 2013] And it still wouldn't work. [Tue Jun 11 01:43:30 2013] There has to be a "right" way to express it. [Tue Jun 11 01:43:30 2013] There has to be a "right" way to express it. [Tue Jun 11 01:43:32 2013] Which part doesn't work? Proving the last part? [Tue Jun 11 01:43:32 2013] Which part doesn't work? Proving the last part? [Tue Jun 11 01:43:37 2013] Right. [Tue Jun 11 01:43:37 2013] Right. [Tue Jun 11 01:43:54 2013] If you do induction on t, you don't get a hypothesis that helps you with finding the type in the list. [Tue Jun 11 01:43:54 2013] If you do induction on t, you don't get a hypothesis that helps you with finding the type in the list. [Tue Jun 11 01:44:57 2013] What does it give you instead? [Tue Jun 11 01:44:57 2013] What does it give you instead? [Tue Jun 11 01:46:18 2013] In this example, or the mutual recursion example? [Tue Jun 11 01:46:18 2013] In this example, or the mutual recursion example? [Tue Jun 11 01:46:41 2013] Either, if neither works. [Tue Jun 11 01:46:41 2013] Either, if neither works. [Tue Jun 11 01:47:03 2013] No induction hypothesis at all. [Tue Jun 11 01:47:03 2013] No induction hypothesis at all. [Tue Jun 11 01:47:11 2013] Oh. [Tue Jun 11 01:47:11 2013] Oh. [Tue Jun 11 01:48:15 2013] Are you using a tactic that turns the <-> obligation into two -> obligations first? [Tue Jun 11 01:48:15 2013] Are you using a tactic that turns the <-> obligation into two -> obligations first? [Tue Jun 11 01:48:50 2013] It doesn't actually matter in this case, but yes, it also doesn't work in that case. [Tue Jun 11 01:48:50 2013] It doesn't actually matter in this case, but yes, it also doesn't work in that case. [Tue Jun 11 01:49:22 2013] Okay. I have no further advice, then. :) [Tue Jun 11 01:49:22 2013] Okay. I have no further advice, then. :) [Tue Jun 11 01:49:32 2013] Have you tried replacing In with something easier to work with? [Tue Jun 11 01:49:32 2013] Have you tried replacing In with something easier to work with? [Tue Jun 11 01:50:12 2013] Yes. As previously noted, I also trued "pure" mutual recursion. [Tue Jun 11 01:50:12 2013] Yes. As previously noted, I also trued "pure" mutual recursion. [Tue Jun 11 01:50:31 2013] I can quickly hack up a script to prove it if this will help/ [Tue Jun 11 01:50:31 2013] I can quickly hack up a script to prove it if this will help/ [Tue Jun 11 01:57:27 2013] http://www.nomorepasting.com/getpaste.php?pasteid=39437 <- No induction hypothesis here either. [Tue Jun 11 01:57:27 2013] http://www.nomorepasting.com/getpaste.php?pasteid=39437 <- No induction hypothesis here either. [Tue Jun 11 02:11:54 2013] Pseudonym: I don't really know what I'm doing, but perhaps you need something like: [Tue Jun 11 02:11:54 2013] Pseudonym: I don't really know what I'm doing, but perhaps you need something like: [Tue Jun 11 02:11:57 2013] Scheme ty_tylist_ind := Induction for ty Sort Set [Tue Jun 11 02:11:57 2013] Scheme ty_tylist_ind := Induction for ty Sort Set [Tue Jun 11 02:11:57 2013] with tylist_ty_ind := Induction for tylist Sort Set. [Tue Jun 11 02:11:57 2013] with tylist_ty_ind := Induction for tylist Sort Set. [Tue Jun 11 02:12:41 2013] er, that should probably be Prop in both cases [Tue Jun 11 02:12:41 2013] er, that should probably be Prop in both cases [Tue Jun 11 02:13:19 2013] I did play with Scheme a bit. [Tue Jun 11 02:13:19 2013] I did play with Scheme a bit. [Tue Jun 11 02:13:21 2013] I don't know how to get the induction tactic to actually use the mutual induction scheme that it generates [Tue Jun 11 02:13:21 2013] I don't know how to get the induction tactic to actually use the mutual induction scheme that it generates [Tue Jun 11 02:13:36 2013] (Or generate something similar) [Tue Jun 11 02:13:36 2013] (Or generate something similar) [Tue Jun 11 02:13:39 2013] But I couldn't get it to work. That doesn't mean it can't work, of course, it could just mean I'm not familiar/smart enough. [Tue Jun 11 02:13:39 2013] But I couldn't get it to work. That doesn't mean it can't work, of course, it could just mean I'm not familiar/smart enough. [Tue Jun 11 02:15:46 2013] I basically like to pretend that Coq is a fancy Haskell extension and mash my keyboard until it accepts things :) [Tue Jun 11 02:15:46 2013] I basically like to pretend that Coq is a fancy Haskell extension and mash my keyboard until it accepts things :) [Tue Jun 11 02:16:01 2013] If it type checks, ship it! [Tue Jun 11 02:16:01 2013] If it type checks, ship it! [Tue Jun 11 02:17:10 2013] Agda with an ML syntax, yeah. [Tue Jun 11 02:17:10 2013] Agda with an ML syntax, yeah. [Tue Jun 11 02:22:02 2013] The thing is, even if you could get Scheme to work, there should be a way to do it with the built-in list. [Tue Jun 11 02:22:02 2013] The thing is, even if you could get Scheme to work, there should be a way to do it with the built-in list. [Tue Jun 11 02:22:10 2013] Otherwise the built-in list isn't very useful. [Tue Jun 11 02:22:10 2013] Otherwise the built-in list isn't very useful. [Tue Jun 11 02:38:55 2013] Well, when I originally made that suggestion, I meant something a little less drastic than your transformation [Tue Jun 11 02:38:55 2013] Well, when I originally made that suggestion, I meant something a little less drastic than your transformation [Tue Jun 11 02:39:05 2013] I just meant making In itself into an inductive type [Tue Jun 11 02:39:05 2013] I just meant making In itself into an inductive type [Tue Jun 11 02:39:12 2013] Oh, I see≥ [Tue Jun 11 02:39:12 2013] Oh, I see≥ [Tue Jun 11 02:39:34 2013] but... it still seems difficult [Tue Jun 11 02:39:34 2013] but... it still seems difficult [Tue Jun 11 02:41:44 2013] i.e. this one: [Tue Jun 11 02:41:44 2013] i.e. this one: [Tue Jun 11 02:41:46 2013] Inductive Elem {t} : t -> list t -> Prop := [Tue Jun 11 02:41:46 2013] Inductive Elem {t} : t -> list t -> Prop := [Tue Jun 11 02:41:46 2013] | Here {x xs} : Elem x (x :: xs) [Tue Jun 11 02:41:46 2013] | Here {x xs} : Elem x (x :: xs) [Tue Jun 11 02:41:46 2013] | There {x a xs} : Elem x xs -> Elem x (a :: xs). [Tue Jun 11 02:41:46 2013] | There {x a xs} : Elem x xs -> Elem x (a :: xs). [Tue Jun 11 02:42:17 2013] I think I've hit on one thing that I'm definitely doing wrong. [Tue Jun 11 02:42:17 2013] I think I've hit on one thing that I'm definitely doing wrong. [Tue Jun 11 02:42:36 2013] If you're doing double induction, you need a double-induction-like theorem to prove. [Tue Jun 11 02:42:36 2013] If you're doing double induction, you need a double-induction-like theorem to prove. [Tue Jun 11 02:42:48 2013] That is, you can't prove on just types. you need to prove something like this: [Tue Jun 11 02:42:48 2013] That is, you can't prove on just types. you need to prove something like this: [Tue Jun 11 02:42:54 2013] Lemma occurs_correct' : forall (v : b), (forall (t : ty), VarInTy v t <-> occurs v t = true) /\ (forall (ts : tylist), VarInTyList v ts <-> occurs_tylist v ts = true). [Tue Jun 11 02:42:54 2013] Lemma occurs_correct' : forall (v : b), (forall (t : ty), VarInTy v t <-> occurs v t = true) /\ (forall (ts : tylist), VarInTyList v ts <-> occurs_tylist v ts = true). [Tue Jun 11 02:43:32 2013] The Combined Scheme that you get if you merge the two induction schemes gives you something like that as a conclusion. [Tue Jun 11 02:43:32 2013] The Combined Scheme that you get if you merge the two induction schemes gives you something like that as a conclusion. [Tue Jun 11 02:43:43 2013] That makes sense. [Tue Jun 11 02:43:43 2013] That makes sense. [Tue Jun 11 02:44:12 2013] Yeah [Tue Jun 11 02:44:12 2013] Yeah [Tue Jun 11 02:44:19 2013] In the general case, you couldn't really infer the form of the "list" case. [Tue Jun 11 02:44:19 2013] In the general case, you couldn't really infer the form of the "list" case. [Tue Jun 11 02:49:44 2013] Cale Pseudonym: Something like 'induction with ' [Tue Jun 11 02:49:44 2013] Cale Pseudonym: Something like 'induction with ' [Tue Jun 11 02:50:12 2013] tomprince: There's a problem with that. [Tue Jun 11 02:50:12 2013] tomprince: There's a problem with that. [Tue Jun 11 02:50:24 2013] For mutual recursion, there is no single . [Tue Jun 11 02:50:24 2013] For mutual recursion, there is no single . [Tue Jun 11 02:57:36 2013] There is, though. You need to start somewhere. [Tue Jun 11 02:57:36 2013] There is, though. You need to start somewhere. [Tue Jun 11 03:01:26 2013] OK, I can't get Combined Scheme to work wither. [Tue Jun 11 03:01:26 2013] OK, I can't get Combined Scheme to work wither. [Tue Jun 11 03:01:28 2013] eitehr [Tue Jun 11 03:01:28 2013] eitehr [Tue Jun 11 03:01:35 2013] Scheme ty_tylist_ind := Induction for ty Sort Prop with tylist_ty_ind := Induction for tylist Sort Prop. [Tue Jun 11 03:01:35 2013] Scheme ty_tylist_ind := Induction for ty Sort Prop with tylist_ty_ind := Induction for tylist Sort Prop. [Tue Jun 11 03:01:38 2013] Combined Scheme ty_tylist_mutind from ty_tylist_ind, tylist_ty_ind. [Tue Jun 11 03:01:38 2013] Combined Scheme ty_tylist_mutind from ty_tylist_ind, tylist_ty_ind. [Tue Jun 11 03:02:12 2013] I've actually worked out how to apply the scheme, though Adam would not approve of exactly how I did it. [Tue Jun 11 03:02:12 2013] I've actually worked out how to apply the scheme, though Adam would not approve of exactly how I did it. [Tue Jun 11 03:02:25 2013] But you still don't get a good induction hypothesis. [Tue Jun 11 03:02:25 2013] But you still don't get a good induction hypothesis. [Tue Jun 11 03:04:33 2013] * will try doing induction on VarInTy instead of the type [Tue Jun 11 03:04:33 2013] * will try doing induction on VarInTy instead of the type [Tue Jun 11 03:20:37 2013] Nope. Not smart enough to do that. [Tue Jun 11 03:20:37 2013] Nope. Not smart enough to do that. [Tue Jun 11 06:11:00 2013] It is always possible to write an induction principle by hand too, right? [Tue Jun 11 06:11:00 2013] It is always possible to write an induction principle by hand too, right? [Tue Jun 11 06:11:56 2013] (Meaning that Combine Scheme, Scheme, etc. in the end don't provide anything which you couldn't have achieved in some other way) [Tue Jun 11 06:11:56 2013] (Meaning that Combine Scheme, Scheme, etc. in the end don't provide anything which you couldn't have achieved in some other way) [Tue Jun 11 06:53:20 2013] fasta: for nested induction these commands do not do what you wish, so sometimes you indeed have to do it by hand [Tue Jun 11 06:53:20 2013] fasta: for nested induction these commands do not do what you wish, so sometimes you indeed have to do it by hand [Tue Jun 11 10:07:05 2013] so what're the limitations imposed by the calculus of constructions (on the space of things which can be proven in coq)? does it simply restrict one to constructive proofs? [Tue Jun 11 10:07:05 2013] so what're the limitations imposed by the calculus of constructions (on the space of things which can be proven in coq)? does it simply restrict one to constructive proofs? [Tue Jun 11 10:07:14 2013] can all constructive proofs be represented in coq? [Tue Jun 11 10:07:14 2013] can all constructive proofs be represented in coq? [Tue Jun 11 10:13:16 2013] shergill: if you're asking for a completeness proof of Gallina, I don't think there is one yet. [Tue Jun 11 10:13:16 2013] shergill: if you're asking for a completeness proof of Gallina, I don't think there is one yet. [Tue Jun 11 10:14:23 2013] and when you say "all proofs" you really need to specify in which logic. [Tue Jun 11 10:14:23 2013] and when you say "all proofs" you really need to specify in which logic. [Tue Jun 11 10:14:50 2013] context tells me that you likely mean Gallina. [Tue Jun 11 10:14:50 2013] context tells me that you likely mean Gallina. [Tue Jun 11 10:15:23 2013] i did mean gallina, sorry [Tue Jun 11 10:15:23 2013] i did mean gallina, sorry [Tue Jun 11 10:15:51 2013] we don't even now if it's strongly normalizing. [Tue Jun 11 10:15:51 2013] we don't even now if it's strongly normalizing. [Tue Jun 11 10:16:23 2013] A bug in the termination checker that robbert showed me would be a counter-example to that. [Tue Jun 11 10:16:23 2013] A bug in the termination checker that robbert showed me would be a counter-example to that. [Tue Jun 11 10:16:32 2013] this was mostly musing on my part last night while making my way through a dense maths proof. i was wishing the author had released it as a coq program since it would've required less mental bookkeeping [Tue Jun 11 10:16:32 2013] this was mostly musing on my part last night while making my way through a dense maths proof. i was wishing the author had released it as a coq program since it would've required less mental bookkeeping [Tue Jun 11 10:17:33 2013] that made me wonder about the completeness of gallina [Tue Jun 11 10:17:33 2013] that made me wonder about the completeness of gallina [Tue Jun 11 10:17:59 2013] shergill: my hand-written proofs look like Agda programs. Dependent types have changed me deeply. Not sure if that's a good thing. [Tue Jun 11 10:17:59 2013] shergill: my hand-written proofs look like Agda programs. Dependent types have changed me deeply. Not sure if that's a good thing. [Tue Jun 11 10:18:34 2013] shergill: only recently did we find a completeness proof for intensional FOL. It might be a while. [Tue Jun 11 10:18:34 2013] shergill: only recently did we find a completeness proof for intensional FOL. It might be a while. [Tue Jun 11 10:20:23 2013] ianjneu: could you point me to the reference? [Tue Jun 11 10:20:23 2013] ianjneu: could you point me to the reference? [Tue Jun 11 10:29:04 2013] shergill: http://www.nuprl.org/KB/show.php?ShowPub=Con11 [Tue Jun 11 10:29:04 2013] shergill: http://www.nuprl.org/KB/show.php?ShowPub=Con11 [Tue Jun 11 10:32:00 2013] thanks [Tue Jun 11 10:32:00 2013] thanks [Tue Jun 11 10:33:32 2013] shergill: I haven't read it. I just heard Bob talking about it last summer. [Tue Jun 11 10:33:32 2013] shergill: I haven't read it. I just heard Bob talking about it last summer. [Tue Jun 11 12:39:55 2013] Is there a web interface to Coq? [Tue Jun 11 12:39:55 2013] Is there a web interface to Coq? [Tue Jun 11 13:02:32 2013] possibly silly question... when using a tactic such as inversion, i often do "inversion H as [Hx Hy Hz]" [Tue Jun 11 13:02:32 2013] possibly silly question... when using a tactic such as inversion, i often do "inversion H as [Hx Hy Hz]" [Tue Jun 11 13:02:51 2013] if i only want to specify names Hx and Hz, how do i avoid giving Hy? [Tue Jun 11 13:02:51 2013] if i only want to specify names Hx and Hz, how do i avoid giving Hy? [Tue Jun 11 13:04:18 2013] [Hx ? Hz] [Tue Jun 11 13:04:18 2013] [Hx ? Hz] [Tue Jun 11 13:04:30 2013] or [Hx _ Hz] [Tue Jun 11 13:04:30 2013] or [Hx _ Hz] [Tue Jun 11 13:04:36 2013] oh, maybe inversion doesn't support ? and _? I forget [Tue Jun 11 13:04:36 2013] oh, maybe inversion doesn't support ? and _? I forget [Tue Jun 11 13:04:43 2013] heh, was about to say that [Tue Jun 11 13:04:43 2013] heh, was about to say that [Tue Jun 11 13:04:57 2013] but fwiw, ? gives new name, _ discards the binding [Tue Jun 11 13:04:57 2013] but fwiw, ? gives new name, _ discards the binding [Tue Jun 11 13:05:02 2013] _ might not always be allowed [Tue Jun 11 13:05:02 2013] _ might not always be allowed [Tue Jun 11 13:05:02 2013] for ? it says "Anonymous pattern not allowed" and for _ it says "Discarded pattern not allowed" [Tue Jun 11 13:05:02 2013] for ? it says "Anonymous pattern not allowed" and for _ it says "Discarded pattern not allowed" [Tue Jun 11 13:05:10 2013] ok, then tough, you have to say Hy :) [Tue Jun 11 13:05:10 2013] ok, then tough, you have to say Hy :) [Tue Jun 11 13:05:14 2013] hehe [Tue Jun 11 13:05:14 2013] hehe [Tue Jun 11 13:05:21 2013] * learns to live with it [Tue Jun 11 13:05:21 2013] * learns to live with it [Tue Jun 11 13:06:43 2013] Or, file bugs about it. [Tue Jun 11 13:06:43 2013] Or, file bugs about it. [Tue Jun 11 13:07:51 2013] is it a bug? [Tue Jun 11 13:07:51 2013] is it a bug? [Tue Jun 11 13:08:31 2013] it's not exactly a high priority problem [Tue Jun 11 13:08:31 2013] it's not exactly a high priority problem [Tue Jun 11 13:28:56 2013] Well, not a bug, but it seems like a reasonable enhancment. [Tue Jun 11 13:28:56 2013] Well, not a bug, but it seems like a reasonable enhancment. [Tue Jun 11 16:07:23 2013] Psycho_pr: http://proofweb.cs.ru.nl [Tue Jun 11 16:07:23 2013] Psycho_pr: http://proofweb.cs.ru.nl [Tue Jun 11 16:30:50 2013] robbert`: That's from 2007.. [Tue Jun 11 16:30:51 2013] robbert`: That's from 2007.. [Tue Jun 11 17:05:12 2013] elliott: any idea if element_unique_eq is actually provable? -> http://waste.io7m.com/2013/06/11/element2.v [Tue Jun 11 17:05:12 2013] elliott: any idea if element_unique_eq is actually provable? -> http://waste.io7m.com/2013/06/11/element2.v [Tue Jun 11 17:05:21 2013] feel like i'm missing decidable equality [Tue Jun 11 17:05:21 2013] feel like i'm missing decidable equality [Tue Jun 11 17:06:51 2013] rmk0: I bet you can convert (element xs n = Some x) into my inductive (in Type not Prop) version of In [Tue Jun 11 17:06:51 2013] rmk0: I bet you can convert (element xs n = Some x) into my inductive (in Type not Prop) version of In [Tue Jun 11 17:06:56 2013] and then apply the proof I gave [Tue Jun 11 17:06:56 2013] and then apply the proof I gave [Tue Jun 11 17:07:36 2013] the problem i had with that is that once i'd moved InP to Type, i then couldn't complete existing proofs i had without moving a ton of other stuff into Type too [Tue Jun 11 17:07:36 2013] the problem i had with that is that once i'd moved InP to Type, i then couldn't complete existing proofs i had without moving a ton of other stuff into Type too [Tue Jun 11 17:07:45 2013] would have had a huge ripple effect on the existing development [Tue Jun 11 17:07:45 2013] would have had a huge ripple effect on the existing development [Tue Jun 11 17:10:40 2013] rmk0: don't move it [Tue Jun 11 17:10:40 2013] rmk0: don't move it [Tue Jun 11 17:10:43 2013] just create a duplicate [Tue Jun 11 17:10:43 2013] just create a duplicate [Tue Jun 11 17:10:51 2013] it's only needed locally for this proof [Tue Jun 11 17:10:51 2013] it's only needed locally for this proof [Tue Jun 11 17:12:04 2013] well, unless i'm mistaken: [Tue Jun 11 17:12:04 2013] well, unless i'm mistaken: [Tue Jun 11 17:12:17 2013] http://waste.io7m.com/2013/06/11/prefixes7.v [Tue Jun 11 17:12:17 2013] http://waste.io7m.com/2013/06/11/prefixes7.v [Tue Jun 11 17:12:51 2013] that was the last version i was working on... the proof prefixes_including_self_correct_1 is now not usable ("Inversion would require case analysis on sort Type...") [Tue Jun 11 17:12:51 2013] that was the last version i was working on... the proof prefixes_including_self_correct_1 is now not usable ("Inversion would require case analysis on sort Type...") [Tue Jun 11 17:13:10 2013] i assumed that meant moving is_prefix into Type, which is what would cause most of the disruption [Tue Jun 11 17:13:10 2013] i assumed that meant moving is_prefix into Type, which is what would cause most of the disruption [Tue Jun 11 17:13:51 2013] is_prefix has rather a lot of dependencies in the actual development [Tue Jun 11 17:13:51 2013] is_prefix has rather a lot of dependencies in the actual development [Tue Jun 11 17:15:27 2013] i'm not absolutely sure that using InPT in prefixes_correct_0 and prefixes_correct_1 won't cause issues yet... [Tue Jun 11 17:15:27 2013] i'm not absolutely sure that using InPT in prefixes_correct_0 and prefixes_correct_1 won't cause issues yet... [Tue Jun 11 17:17:00 2013] the element2.v development was the beginning of an attempt to try a similar idea but without moving into Type [Tue Jun 11 17:17:00 2013] the element2.v development was the beginning of an attempt to try a similar idea but without moving into Type [Tue Jun 11 17:18:16 2013] i'll try to prove your thm in element2.v [Tue Jun 11 17:18:16 2013] i'll try to prove your thm in element2.v [Tue Jun 11 17:18:20 2013] to show what i mean [Tue Jun 11 17:18:20 2013] to show what i mean [Tue Jun 11 17:18:36 2013] ok, thank you [Tue Jun 11 17:18:36 2013] ok, thank you [Tue Jun 11 17:19:40 2013] Psycho_pr: well you can use it with Coq 8.4 beta... But yeah, it is pretty undermaintained at the moment. However, the source is there, so feel free to improve it. [Tue Jun 11 17:19:40 2013] Psycho_pr: well you can use it with Coq 8.4 beta... But yeah, it is pretty undermaintained at the moment. However, the source is there, so feel free to improve it. [Tue Jun 11 17:20:54 2013] Ok thanks:) [Tue Jun 11 17:20:54 2013] Ok thanks:) [Tue Jun 11 17:35:58 2013] rmk0: proven [Tue Jun 11 17:35:58 2013] rmk0: proven [Tue Jun 11 17:36:15 2013] http://sprunge.us/EOKi [Tue Jun 11 17:36:15 2013] http://sprunge.us/EOKi [Tue Jun 11 17:36:24 2013] it is very ugly. I bet you can inline all the conversion and stuff. [Tue Jun 11 17:36:24 2013] it is very ugly. I bet you can inline all the conversion and stuff. [Tue Jun 11 17:36:41 2013] perhaps even do away with InPT entirely [Tue Jun 11 17:36:41 2013] perhaps even do away with InPT entirely [Tue Jun 11 17:36:56 2013] thank you! [Tue Jun 11 17:36:56 2013] thank you! [Tue Jun 11 17:36:58 2013] * eyes it [Tue Jun 11 17:36:58 2013] * eyes it [Tue Jun 11 17:37:15 2013] you might want to consider just using InPT directly instead of more cumbersome (element n xs = Some x) proofs, they give more information [Tue Jun 11 17:37:15 2013] you might want to consider just using InPT directly instead of more cumbersome (element n xs = Some x) proofs, they give more information [Tue Jun 11 17:37:21 2013] but that might require more changes than you want to deal with [Tue Jun 11 17:37:21 2013] but that might require more changes than you want to deal with [Tue Jun 11 17:37:39 2013] hehe, yes, i'm extremely nervous about disruptive changes [Tue Jun 11 17:37:39 2013] hehe, yes, i'm extremely nervous about disruptive changes [Tue Jun 11 17:37:45 2013] i'm about three weeks over the deadline i'd set for myself as it is [Tue Jun 11 17:37:46 2013] i'm about three weeks over the deadline i'd set for myself as it is [Tue Jun 11 17:38:37 2013] i see what you mean about keeping that stuff local [Tue Jun 11 17:38:37 2013] i see what you mean about keeping that stuff local [Tue Jun 11 17:39:00 2013] I basically distrust equalities that you have to use "injection" on to be useful (because they reduce to Some x = Some y), etc. [Tue Jun 11 17:39:00 2013] I basically distrust equalities that you have to use "injection" on to be useful (because they reduce to Some x = Some y), etc. [Tue Jun 11 17:39:05 2013] I think that's when you want to start using an inductive Prop [Tue Jun 11 17:39:05 2013] I think that's when you want to start using an inductive Prop [Tue Jun 11 17:39:13 2013] yeah, i agree [Tue Jun 11 17:39:13 2013] yeah, i agree [Tue Jun 11 17:39:23 2013] to record the "trace" of what information caused the function to "succeed" [Tue Jun 11 17:39:23 2013] to record the "trace" of what information caused the function to "succeed" [Tue Jun 11 17:39:28 2013] i knew it was unpleasant when i wrote it, but couldn't think of a more pleasant way [Tue Jun 11 17:39:28 2013] i knew it was unpleasant when i wrote it, but couldn't think of a more pleasant way [Tue Jun 11 17:39:35 2013] yeah [Tue Jun 11 17:39:35 2013] yeah [Tue Jun 11 17:40:02 2013] element could take a Fin.t (length xs), that'd at least ease the pain of the option result [Tue Jun 11 17:40:02 2013] element could take a Fin.t (length xs), that'd at least ease the pain of the option result [Tue Jun 11 17:40:14 2013] right [Tue Jun 11 17:40:14 2013] right [Tue Jun 11 17:41:23 2013] well, this is much appreciated [Tue Jun 11 17:41:23 2013] well, this is much appreciated [Tue Jun 11 17:41:35 2013] think this may be enough to finally crush the prefixes function [Tue Jun 11 17:41:35 2013] think this may be enough to finally crush the prefixes function [Tue Jun 11 17:41:53 2013] it was just copy-paste work once I verified that you could convert the proof :) [Tue Jun 11 17:41:53 2013] it was just copy-paste work once I verified that you could convert the proof :) [Tue Jun 11 17:42:04 2013] right [Tue Jun 11 17:42:04 2013] right [Tue Jun 11 17:45:42 2013] nice that sprunge serves plaintext [Tue Jun 11 17:45:42 2013] nice that sprunge serves plaintext [Tue Jun 11 17:45:53 2013] hadn't heard of it before you posted those [Tue Jun 11 17:45:53 2013] hadn't heard of it before you posted those [Tue Jun 11 17:49:33 2013] I like being able to do "curl -F 'sprunge=<-' sprunge.us I like being able to do "curl -F 'sprunge=<-' sprunge.us yep [Tue Jun 11 17:49:42 2013] yep [Tue Jun 11 17:49:53 2013] well, that could be "curl -F 'sprunge= well, that could be "curl -F 'sprunge= $ echo hello | curl -F 'sprunge=<-' http://sprunge.us [Tue Jun 11 17:50:46 2013] $ echo hello | curl -F 'sprunge=<-' http://sprunge.us [Tue Jun 11 17:50:48 2013] http://sprunge.us/eULD [Tue Jun 11 17:50:48 2013] http://sprunge.us/eULD [Tue Jun 11 17:50:55 2013] $ curl http://sprunge.us/eULD [Tue Jun 11 17:50:55 2013] $ curl http://sprunge.us/eULD [Tue Jun 11 17:50:58 2013] hello [Tue Jun 11 17:50:58 2013] hello [Tue Jun 11 17:50:59 2013] lovely [Tue Jun 11 17:50:59 2013] lovely [Tue Jun 11 17:53:41 2013] :) [Tue Jun 11 17:53:41 2013] :) [Wed Jun 12 05:42:16 2013] does someone has a clue for proving this theorem ? http://jpdeplaix.dyndns.org/inf.txt [Wed Jun 12 05:42:16 2013] does someone has a clue for proving this theorem ? http://jpdeplaix.dyndns.org/inf.txt [Wed Jun 12 06:19:46 2013] you could do a case distinction (i.e. destruct) on (nat_compare x 100) and in the _-case you probably need to unfold nat_compare to get the (g x <= 100) result [Wed Jun 12 06:19:46 2013] you could do a case distinction (i.e. destruct) on (nat_compare x 100) and in the _-case you probably need to unfold nat_compare to get the (g x <= 100) result [Wed Jun 12 06:30:47 2013] jpdeplaix: do you prefer tips or entire solutions? You can find the entire proof at http://wwwcip.cs.fau.de/~re06huxa/p/5d86288105f213e29c86e6bf7b8b9698 [Wed Jun 12 06:30:47 2013] jpdeplaix: do you prefer tips or entire solutions? You can find the entire proof at http://wwwcip.cs.fau.de/~re06huxa/p/5d86288105f213e29c86e6bf7b8b9698 [Wed Jun 12 06:32:00 2013] thorsten`: no, only tips for the moment :) It's just an exercice for myself [Wed Jun 12 06:32:00 2013] thorsten`: no, only tips for the moment :) It's just an exercice for myself [Wed Jun 12 06:32:45 2013] jpdeplaix: ok, do you know the "remember TERM as Identifier" tactic? [Wed Jun 12 06:32:45 2013] jpdeplaix: ok, do you know the "remember TERM as Identifier" tactic? [Wed Jun 12 06:33:22 2013] thorsten`: yes, but I never used it [Wed Jun 12 06:33:22 2013] thorsten`: yes, but I never used it [Wed Jun 12 06:33:43 2013] then this is a perfect exercise for you :) [Wed Jun 12 06:33:43 2013] then this is a perfect exercise for you :) [Wed Jun 12 06:34:31 2013] jpdeplaix: so as already told, you somehow have to do an case distinction on (nat_compare x 100) [Wed Jun 12 06:34:31 2013] jpdeplaix: so as already told, you somehow have to do an case distinction on (nat_compare x 100) [Wed Jun 12 06:38:06 2013] intuitively: if you're in the Gt-case, then you only need to show (100 <= 100). there's als othe case where x equals 100 and x is lower than x, which both need some theorems which put the Proposition "le" with the computational comparison nat_compare in relation [Wed Jun 12 06:38:06 2013] intuitively: if you're in the Gt-case, then you only need to show (100 <= 100). there's als othe case where x equals 100 and x is lower than x, which both need some theorems which put the Proposition "le" with the computational comparison nat_compare in relation [Wed Jun 12 06:41:21 2013] oh I didn't know that we can destruct on any terms ! [Wed Jun 12 06:41:21 2013] oh I didn't know that we can destruct on any terms ! [Wed Jun 12 06:50:01 2013] mmmh I get stuck on « x <= 100 » :/ [Wed Jun 12 06:50:01 2013] mmmh I get stuck on « x <= 100 » :/ [Wed Jun 12 06:53:13 2013] jpdeplaix: Do you have Le imported? [Wed Jun 12 06:53:13 2013] jpdeplaix: Do you have Le imported? [Wed Jun 12 06:53:31 2013] You'll likely want to use some lemmas from that module [Wed Jun 12 06:53:31 2013] You'll likely want to use some lemmas from that module [Wed Jun 12 06:55:39 2013] oh, actually, the thing you might need is nat_compare_le rather. [Wed Jun 12 06:55:39 2013] oh, actually, the thing you might need is nat_compare_le rather. [Wed Jun 12 06:56:05 2013] That's just in Coq.Arith.Compare_dec which you definitely have imported :) [Wed Jun 12 06:56:05 2013] That's just in Coq.Arith.Compare_dec which you definitely have imported :) [Wed Jun 12 07:08:50 2013] ok. I've reduce to « 100 <= 100 » for when Eq \o/ Now: Lt ! [Wed Jun 12 07:08:50 2013] ok. I've reduce to « 100 <= 100 » for when Eq \o/ Now: Lt ! [Wed Jun 12 07:20:45 2013] mmmh how to finish the subgoal when « Heqy : x < 100 » and the subgoal is « x <= 100 » ? [Wed Jun 12 07:20:46 2013] mmmh how to finish the subgoal when « Heqy : x < 100 » and the subgoal is « x <= 100 » ? [Wed Jun 12 07:21:22 2013] rewriting doesn't work :/ [Wed Jun 12 07:21:22 2013] rewriting doesn't work :/ [Wed Jun 12 07:22:38 2013] apply lt_le_weak. ? [Wed Jun 12 07:22:38 2013] apply lt_le_weak. ? [Wed Jun 12 07:23:07 2013] er, apply (lt_le_weak x 100 Heqy). [Wed Jun 12 07:23:07 2013] er, apply (lt_le_weak x 100 Heqy). [Wed Jun 12 07:23:54 2013] I didn't quite get to that point in my proof [Wed Jun 12 07:23:54 2013] I didn't quite get to that point in my proof [Wed Jun 12 07:24:05 2013] (I didn't need to use strict inequalities at all) [Wed Jun 12 07:24:05 2013] (I didn't need to use strict inequalities at all) [Wed Jun 12 07:25:07 2013] I used nat_compare_le, and then from there, obtained a proof that Lt = Gt and used discriminate on it. [Wed Jun 12 07:25:07 2013] I used nat_compare_le, and then from there, obtained a proof that Lt = Gt and used discriminate on it. [Wed Jun 12 07:26:00 2013] (but I have no idea if that's the cleanest way) [Wed Jun 12 07:26:00 2013] (but I have no idea if that's the cleanest way) [Wed Jun 12 07:27:54 2013] Finished \o/ http://jpdeplaix.dyndns.org/inf.txt [Wed Jun 12 07:27:54 2013] Finished \o/ http://jpdeplaix.dyndns.org/inf.txt [Wed Jun 12 07:28:05 2013] thanks ! [Wed Jun 12 07:28:05 2013] thanks ! [Wed Jun 12 07:37:21 2013] jpdeplaix: here's how mine went if you're curious :) http://pastebin.com/ArewuTEq [Wed Jun 12 07:37:21 2013] jpdeplaix: here's how mine went if you're curious :) http://pastebin.com/ArewuTEq [Wed Jun 12 08:08:26 2013] thanks Cale. What is « Defined » ? An equivalent for « Qed » ? [Wed Jun 12 08:08:26 2013] thanks Cale. What is « Defined » ? An equivalent for « Qed » ? [Wed Jun 12 08:08:55 2013] oh, yeah [Wed Jun 12 08:08:55 2013] oh, yeah [Wed Jun 12 08:09:03 2013] Well, not quite equivalent [Wed Jun 12 08:09:03 2013] Well, not quite equivalent [Wed Jun 12 08:10:35 2013] It declares the proof as transparent, making it possible to unfold the definition. I wanted to peek at the proof term which was generated. [Wed Jun 12 08:10:35 2013] It declares the proof as transparent, making it possible to unfold the definition. I wanted to peek at the proof term which was generated. [Wed Jun 12 08:12:40 2013] (If you do Compute test, you can see exactly what code was generated from the proof if it was Defined rather than Qed'ed) [Wed Jun 12 08:12:40 2013] (If you do Compute test, you can see exactly what code was generated from the proof if it was Defined rather than Qed'ed) [Wed Jun 12 08:15:25 2013] ok. Thanks [Wed Jun 12 08:15:25 2013] ok. Thanks [Wed Jun 12 10:20:17 2013] Cale: you can do that without Defined [Wed Jun 12 10:20:17 2013] Cale: you can do that without Defined [Wed Jun 12 10:20:21 2013] Qed. and then Print test. [Wed Jun 12 10:20:21 2013] Qed. and then Print test. [Wed Jun 12 10:20:37 2013] elliott: cool [Wed Jun 12 10:20:37 2013] elliott: cool [Wed Jun 12 10:21:37 2013] elliott: To be honest, I'm not entirely certain of all the differences between Defined and Qed, apart from the fact that proofs that were Defined expand when displayed like that. [Wed Jun 12 10:21:37 2013] elliott: To be honest, I'm not entirely certain of all the differences between Defined and Qed, apart from the fact that proofs that were Defined expand when displayed like that. [Wed Jun 12 10:22:04 2013] i think it's solely a matter of controlling unfolding [Wed Jun 12 10:22:04 2013] i think it's solely a matter of controlling unfolding [Wed Jun 12 10:22:19 2013] transparent/opaque proofs/terms unfold differently when simplifying [Wed Jun 12 10:22:19 2013] transparent/opaque proofs/terms unfold differently when simplifying [Wed Jun 12 10:22:35 2013] so as to avoid getting a thousand lines of gibberish in the current goal when simplifying [Wed Jun 12 10:22:35 2013] so as to avoid getting a thousand lines of gibberish in the current goal when simplifying [Wed Jun 12 10:22:47 2013] Cale: well, opaque stuff won't be computed with, of course [Wed Jun 12 10:22:47 2013] Cale: well, opaque stuff won't be computed with, of course [Wed Jun 12 10:23:11 2013] so if you have proofs that no computation depends on (they can depend one quality proofs, Acc stuff for recursion etc.) then making them opaque can save time/space/clutter [Wed Jun 12 10:23:11 2013] so if you have proofs that no computation depends on (they can depend one quality proofs, Acc stuff for recursion etc.) then making them opaque can save time/space/clutter [Wed Jun 12 10:25:58 2013] ah, okay, I was wondering why you'd ever want to explicitly make something impossible to compute with [Wed Jun 12 10:25:58 2013] ah, okay, I was wondering why you'd ever want to explicitly make something impossible to compute with [Wed Jun 12 10:26:07 2013] But yeah, saving space seems kind of reasonable [Wed Jun 12 10:26:07 2013] But yeah, saving space seems kind of reasonable [Wed Jun 12 10:26:14 2013] Especially if things are strict. [Wed Jun 12 10:26:14 2013] Especially if things are strict. [Wed Jun 12 10:29:21 2013] Cale: by default yes [Wed Jun 12 10:29:21 2013] Cale: by default yes [Wed Jun 12 10:29:28 2013] you can use cbn instead though [Wed Jun 12 10:29:28 2013] you can use cbn instead though [Fri Jun 14 07:51:58 2013] Is there any way to program imperatively in Coq? [Fri Jun 14 07:51:58 2013] Is there any way to program imperatively in Coq? [Fri Jun 14 07:52:21 2013] There have been research projects, but all of them are unmaintained, AFAIK. [Fri Jun 14 07:52:21 2013] There have been research projects, but all of them are unmaintained, AFAIK. [Fri Jun 14 08:44:24 2013] Well, what do you mean program imperatively? One of the first things I did in Coq (just for fun) was to make a small monad library. [Fri Jun 14 08:44:24 2013] Well, what do you mean program imperatively? One of the first things I did in Coq (just for fun) was to make a small monad library. [Fri Jun 14 09:09:15 2013] fasta: you can use a state monad [Fri Jun 14 09:09:15 2013] fasta: you can use a state monad [Fri Jun 14 09:09:38 2013] CompCert does use a state monad at various places for example [Fri Jun 14 09:09:38 2013] CompCert does use a state monad at various places for example [Fri Jun 14 09:09:40 2013] robbert: state monads don't allow mutable variables. [Fri Jun 14 09:09:40 2013] robbert: state monads don't allow mutable variables. [Fri Jun 14 09:09:53 2013] robbert: or mutable arrays. [Fri Jun 14 09:09:53 2013] robbert: or mutable arrays. [Fri Jun 14 09:10:05 2013] you will not get either in Coq [Fri Jun 14 09:10:05 2013] you will not get either in Coq [Fri Jun 14 09:10:22 2013] robbert: there have been libraries which did that. [Fri Jun 14 09:10:22 2013] robbert: there have been libraries which did that. [Fri Jun 14 09:10:34 2013] robbert: in Coq you can express such semantics. [Fri Jun 14 09:10:34 2013] robbert: in Coq you can express such semantics. [Fri Jun 14 09:10:51 2013] you can define the semantics of a programming language with such features [Fri Jun 14 09:10:51 2013] you can define the semantics of a programming language with such features [Fri Jun 14 09:10:59 2013] but if you program in Coq _itself_ you won't have such features [Fri Jun 14 09:11:00 2013] but if you program in Coq _itself_ you won't have such features [Fri Jun 14 09:11:06 2013] because Coq does not have these features [Fri Jun 14 09:11:06 2013] because Coq does not have these features [Fri Jun 14 10:41:23 2013] robbert: sure, but Coq can talk about expressions written in those target languages. [Fri Jun 14 10:41:52 2013] robbert: and there have been research projects providing such libraries, but they all have been abandoned, unless a new one has popped up again. [Fri Jun 14 10:42:05 2013] robbert: and we are now talking in a cycle again. [Fri Jun 14 10:49:10 2013] fasta: only library i know of that does exactly what you want is ynot. [Fri Jun 14 10:49:16 2013] i don't think it's unmaintained [Fri Jun 14 10:55:23 2013] fasta: I don't know much about it, but "Idris" seems like a pretty neat language - dependent types + tactics + able to write real world code [Fri Jun 14 11:15:55 2013] rmk0: it is unmaintained. [Fri Jun 14 11:17:16 2013] mgsloan: how is Idris in any way more expressive than Coq? [Fri Jun 14 11:17:47 2013] To me it just seems a one man show version of Coq that looks like Haskell. [Fri Jun 14 11:18:27 2013] fasta: Oh, it just seems to more readily compile to stuff you can run (without extraction) [Fri Jun 14 11:18:31 2013] Not a bad thing per se, but no reason to introduce incompatibility, [Fri Jun 14 11:18:35 2013] there's also a javascript backend [Fri Jun 14 11:18:43 2013] this isn't about expressiveness, but tools [Fri Jun 14 11:18:56 2013] mgsloan: writing an extraction tool is simple for Coq, from what I have seen. [Fri Jun 14 11:19:04 2013] Sure, but you need to trust it [Fri Jun 14 11:19:23 2013] Most extractions are extremely trivial. [Fri Jun 14 11:19:33 2013] I mean, same for a compiler, but that seems more reasonable than an ad-hoc application-specific extraction [Fri Jun 14 11:19:51 2013] I'd say most uses of extraction are probably trivial [Fri Jun 14 11:20:06 2013] but then again, I'm not well versed in this stuff, so I'm probably wrong [Fri Jun 14 11:20:09 2013] Sure, if you are interested in JavaScript as a backend, that would be useful. [Fri Jun 14 11:20:12 2013] I just find it interesting [Fri Jun 14 11:20:37 2013] The value in Coq would be that you can just prove that your program works and then how long the extraction takes doesn't matter a whole lot. [Fri Jun 14 11:20:55 2013] It's not a matter of how long the extraction takes, it's a matter of how correct it is [Fri Jun 14 11:21:44 2013] mgsloan: sure, but that part of a program is usually the easy part. [Fri Jun 14 11:22:14 2013] Uhh, isn't that the point of proof about that part of the program? [Fri Jun 14 11:22:29 2013] mgsloan: no [Fri Jun 14 11:22:33 2013] that it's not really all that easy, and it'd be good to have some mechanical verification [Fri Jun 14 11:22:54 2013] mgsloan: sure, that kind of verification would be useful too. [Sun Jun 16 03:39:01 2013] alright, I've decided to learn proof general [Sun Jun 16 03:39:01 2013] alright, I've decided to learn proof general [Sun Jun 16 03:39:10 2013] I'm on osx, which has emacs 22.* which proof general does not like [Sun Jun 16 03:39:11 2013] I'm on osx, which has emacs 22.* which proof general does not like [Sun Jun 16 03:39:27 2013] what version of Emacs should I be using? (and is there a *.dmg I can download -- or do I have to compile emacs from scratch to make proof general happy) ? [Sun Jun 16 03:39:27 2013] what version of Emacs should I be using? (and is there a *.dmg I can download -- or do I have to compile emacs from scratch to make proof general happy) ? [Mon Jun 17 08:12:01 2013] hello, has anyone else experienced the Coq binary distribution for mac os x hanging on launch? [Mon Jun 17 08:12:01 2013] hello, has anyone else experienced the Coq binary distribution for mac os x hanging on launch? [Mon Jun 17 08:56:16 2013] Good morning. Does anyone know if le n m has unique proofs, or how to prove it? [Mon Jun 17 08:56:16 2013] Good morning. Does anyone know if le n m has unique proofs, or how to prove it? [Mon Jun 17 08:59:12 2013] my beliefs: yes; induction and it might be in the stdlib somewhere [Mon Jun 17 08:59:13 2013] my beliefs: yes; induction and it might be in the stdlib somewhere [Mon Jun 17 08:59:26 2013] the dependent induction is a bit tricky [Mon Jun 17 08:59:26 2013] the dependent induction is a bit tricky [Mon Jun 17 08:59:57 2013] my beliefs are often wrong :) [Mon Jun 17 08:59:57 2013] my beliefs are often wrong :) [Mon Jun 17 09:00:39 2013] I think you can do it [Mon Jun 17 09:00:39 2013] I think you can do it [Mon Jun 17 09:00:55 2013] * tries [Mon Jun 17 09:00:55 2013] * tries [Mon Jun 17 09:02:25 2013] well, I got forall x y (H : x = y) (P : x <= y), P = eq_rec _ (le x) (le_n x) _ H. [Mon Jun 17 09:02:26 2013] well, I got forall x y (H : x = y) (P : x <= y), P = eq_rec _ (le x) (le_n x) _ H. [Mon Jun 17 09:02:49 2013] using UIP_dec to show eq_refl is the only equality proof over nat in the base case [Mon Jun 17 09:02:49 2013] using UIP_dec to show eq_refl is the only equality proof over nat in the base case [Mon Jun 17 09:03:04 2013] err, that's just a proof that all x <= x are unique, no? [Mon Jun 17 09:03:04 2013] err, that's just a proof that all x <= x are unique, no? [Mon Jun 17 09:03:10 2013] yeah [Mon Jun 17 09:03:10 2013] yeah [Mon Jun 17 09:03:23 2013] It's the simpler case I got on induction [Mon Jun 17 09:03:23 2013] It's the simpler case I got on induction [Mon Jun 17 09:03:29 2013] (match P in _ <= y return (forall (Q : x <= y), P = Q) with ... [Mon Jun 17 09:03:29 2013] (match P in _ <= y return (forall (Q : x <= y), P = Q) with ... [Mon Jun 17 09:04:59 2013] right [Mon Jun 17 09:04:59 2013] right [Mon Jun 17 09:07:35 2013] this does seem unusually hard to prove [Mon Jun 17 09:07:35 2013] this does seem unusually hard to prove [Mon Jun 17 09:16:22 2013] how is le defined? [Mon Jun 17 09:16:22 2013] how is le defined? [Mon Jun 17 09:16:35 2013] le_n : n <= n | le_S : forall m : nat, n <= m -> n <= S m [Mon Jun 17 09:16:35 2013] le_n : n <= n | le_S : forall m : nat, n <= m -> n <= S m [Mon Jun 17 09:17:40 2013] perhaps the easiest way: [Mon Jun 17 09:17:40 2013] perhaps the easiest way: [Mon Jun 17 09:17:46 2013] wait, nm [Mon Jun 17 09:17:46 2013] wait, nm [Mon Jun 17 09:17:53 2013] what I was thinking of required propositional extensionality or such [Mon Jun 17 09:17:53 2013] what I was thinking of required propositional extensionality or such [Mon Jun 17 09:18:09 2013] although hm [Mon Jun 17 09:18:09 2013] although hm [Mon Jun 17 09:18:11 2013] maybe it still holds [Mon Jun 17 09:18:11 2013] maybe it still holds [Mon Jun 17 09:18:23 2013] the idea was, prove m <= n <-> exists k, m+k = n [Mon Jun 17 09:18:23 2013] the idea was, prove m <= n <-> exists k, m+k = n [Mon Jun 17 09:18:33 2013] since I think proving unicity of the latter would be a lot easier [Mon Jun 17 09:18:33 2013] since I think proving unicity of the latter would be a lot easier [Mon Jun 17 09:18:39 2013] yeah, I'm trying to see if, like eq, you can prove propositional extensionality because nat is well-behaved [Mon Jun 17 09:18:39 2013] yeah, I'm trying to see if, like eq, you can prove propositional extensionality because nat is well-behaved [Mon Jun 17 09:32:15 2013] looks like le_ind isn't actually the induction principle for le [Mon Jun 17 09:32:15 2013] looks like le_ind isn't actually the induction principle for le [Mon Jun 17 09:34:39 2013] napping: by propositional extensionality i mean (P <-> Q) -> P = Q [Mon Jun 17 09:34:39 2013] napping: by propositional extensionality i mean (P <-> Q) -> P = Q [Mon Jun 17 09:37:10 2013] yeah [Mon Jun 17 09:37:10 2013] yeah [Mon Jun 17 09:37:46 2013] oh, maybe that's a different level than unicity [Mon Jun 17 09:37:46 2013] oh, maybe that's a different level than unicity [Mon Jun 17 09:38:02 2013] defining a full induction scheme on le looks promising. [Mon Jun 17 09:38:02 2013] defining a full induction scheme on le looks promising. [Mon Jun 17 09:39:35 2013] at least I get a goal [Mon Jun 17 09:39:35 2013] at least I get a goal [Mon Jun 17 09:39:50 2013] le_S n m l = Q, and a hypothesis forall P : n <= m, l = P [Mon Jun 17 09:39:51 2013] le_S n m l = Q, and a hypothesis forall P : n <= m, l = P [Mon Jun 17 09:40:26 2013] so some kind of destruction lemma saying n <= m implies Q : n <= S m is built from le_S would finish the proof [Mon Jun 17 09:40:27 2013] so some kind of destruction lemma saying n <= m implies Q : n <= S m is built from le_S would finish the proof [Mon Jun 17 09:40:42 2013] anyway, gotta go for a bit [Mon Jun 17 09:40:42 2013] anyway, gotta go for a bit [Mon Jun 17 12:17:10 2013] Hello! Can somebody help me with little problem? http://pastebin.com/hG9HQjPH - any hints (pun intended) how to debug this behavior? [Mon Jun 17 12:17:10 2013] Hello! Can somebody help me with little problem? http://pastebin.com/hG9HQjPH - any hints (pun intended) how to debug this behavior? [Mon Jun 17 12:17:29 2013] you can "debug eauto" at least [Mon Jun 17 12:17:29 2013] you can "debug eauto" at least [Mon Jun 17 12:18:07 2013] OK, I am newbie, I didn't know this command. I am going to check it. [Mon Jun 17 12:18:07 2013] OK, I am newbie, I didn't know this command. I am going to check it. [Mon Jun 17 12:18:12 2013] Thanks. [Mon Jun 17 12:18:12 2013] Thanks. [Mon Jun 17 12:18:53 2013] The output is "1 depth=5" and nothing more. I guess I must try something else. [Mon Jun 17 12:18:54 2013] The output is "1 depth=5" and nothing more. I guess I must try something else. [Mon Jun 17 12:28:34 2013] not very helpful output there, yes :) [Mon Jun 17 12:28:34 2013] not very helpful output there, yes :) [Mon Jun 17 12:28:41 2013] perhaps try it with "auto" [Mon Jun 17 12:28:41 2013] perhaps try it with "auto" [Mon Jun 17 12:29:43 2013] I have tried it: now it shows 'apply my_ind_constructor (* fail *)', but when i replace auto with constructor. trivial. everything works. It's some kind of black magic ;) [Mon Jun 17 12:29:43 2013] I have tried it: now it shows 'apply my_ind_constructor (* fail *)', but when i replace auto with constructor. trivial. everything works. It's some kind of black magic ;) [Mon Jun 17 12:30:48 2013] Oh, I guess that wasn't very readable, another try: When i replace 'auto' with 'constructor. trivial.' everything works. [Mon Jun 17 12:30:48 2013] Oh, I guess that wasn't very readable, another try: When i replace 'auto' with 'constructor. trivial.' everything works. [Mon Jun 17 12:31:17 2013] perhaps "apply my_ind_constructor" does not work but "constructor" does [Mon Jun 17 12:31:17 2013] perhaps "apply my_ind_constructor" does not work but "constructor" does [Mon Jun 17 12:31:21 2013] because "constructor" is doing something fanceir? [Mon Jun 17 12:31:21 2013] because "constructor" is doing something fanceir? [Mon Jun 17 12:31:23 2013] *fancier [Mon Jun 17 12:31:23 2013] *fancier [Mon Jun 17 12:32:38 2013] Nope, 'apply my_ind_constructor. trivial.' works too :) [Mon Jun 17 12:32:39 2013] Nope, 'apply my_ind_constructor. trivial.' works too :) [Mon Jun 17 12:33:02 2013] interesting [Mon Jun 17 12:33:02 2013] interesting [Mon Jun 17 12:33:13 2013] so, er, just checking, "apply my_ind_constructor. auto" works right :P [Mon Jun 17 12:33:13 2013] so, er, just checking, "apply my_ind_constructor. auto" works right :P [Mon Jun 17 12:33:18 2013] *, right [Mon Jun 17 12:33:18 2013] *, right [Mon Jun 17 12:33:40 2013] Yep, that one works too. [Mon Jun 17 12:33:41 2013] Yep, that one works too. [Mon Jun 17 12:34:53 2013] I have tried see something with 'Set Ltac Debug', but it just skips auto in one step... [Mon Jun 17 12:34:53 2013] I have tried see something with 'Set Ltac Debug', but it just skips auto in one step... [Mon Jun 17 13:13:37 2013] I have solved that problem: After apply I had something with 'length nil' and *nearly* the same goal but with 0 in place of 'length nil'. It turns out that (e)auto cannot handle that. :) [Mon Jun 17 13:13:37 2013] I have solved that problem: After apply I had something with 'length nil' and *nearly* the same goal but with 0 in place of 'length nil'. It turns out that (e)auto cannot handle that. :) [Mon Jun 17 13:13:54 2013] simpl in * before auto solved the problem. [Mon Jun 17 13:13:54 2013] simpl in * before auto solved the problem. [Mon Jun 17 13:19:50 2013] yeah, these things happen :( [Mon Jun 17 13:19:51 2013] yeah, these things happen :( [Mon Jun 17 14:42:22 2013] well, napping isn't here, but for the curious, it is possible: http://sprunge.us/PUTO [Mon Jun 17 14:42:22 2013] well, napping isn't here, but for the curious, it is possible: http://sprunge.us/PUTO [Mon Jun 17 14:42:26 2013] a simpler proof would be interesting to see! [Mon Jun 17 14:42:27 2013] a simpler proof would be interesting to see! [Mon Jun 17 14:42:41 2013] (proof is axiom-free) [Mon Jun 17 14:42:41 2013] (proof is axiom-free) [Mon Jun 17 18:11:53 2013] napping, elliott: see https://sympa.inria.fr/sympa/arc/coq-club/2013-04/msg00034.html for a short proof [Mon Jun 17 18:11:53 2013] napping, elliott: see https://sympa.inria.fr/sympa/arc/coq-club/2013-04/msg00034.html for a short proof [Mon Jun 17 18:12:00 2013] it's axiom free, of course [Mon Jun 17 18:12:00 2013] it's axiom free, of course [Mon Jun 17 18:12:41 2013] robbert: oh, that is clever [Mon Jun 17 18:12:41 2013] robbert: oh, that is clever [Mon Jun 17 18:12:56 2013] just extending the "decidable K" use to the whole thing [Mon Jun 17 18:12:56 2013] just extending the "decidable K" use to the whole thing [Mon Jun 17 18:14:52 2013] the nice thing of this approach is that it easily extends to all kinds of other inductives [Mon Jun 17 18:14:52 2013] the nice thing of this approach is that it easily extends to all kinds of other inductives [Mon Jun 17 21:10:03 2013] How would I notate something of type: A -> option (B c d), where the type B is parametrised by (c : C) and (d : D), but where the c and d are dependent on the (a : A) passed to the function? [Mon Jun 17 21:10:04 2013] How would I notate something of type: A -> option (B c d), where the type B is parametrised by (c : C) and (d : D), but where the c and d are dependent on the (a : A) passed to the function? [Mon Jun 17 21:11:02 2013] More specifically, how would I notate that type [Mon Jun 17 21:11:03 2013] More specifically, how would I notate that type [Mon Jun 17 21:17:31 2013] forall a : A, option (B (c a) (d a)) ? [Mon Jun 17 21:17:32 2013] forall a : A, option (B (c a) (d a)) ? [Mon Jun 17 21:18:13 2013] Sorry, I should have written: where the choice of c and d are depedent on the a passed to the function [Mon Jun 17 21:18:13 2013] Sorry, I should have written: where the choice of c and d are depedent on the a passed to the function [Mon Jun 17 21:18:27 2013] cale's answer seems right to me [Mon Jun 17 21:18:27 2013] cale's answer seems right to me [Mon Jun 17 21:18:29 2013] c and d don't "depend" on a in a dependent typed manner [Mon Jun 17 21:18:29 2013] c and d don't "depend" on a in a dependent typed manner [Mon Jun 17 21:18:37 2013] wat [Mon Jun 17 21:18:37 2013] wat [Mon Jun 17 21:18:55 2013] You just described what it would mean for them to depend on a in a dependent typed manner [Mon Jun 17 21:18:55 2013] You just described what it would mean for them to depend on a in a dependent typed manner [Mon Jun 17 21:19:00 2013] and then said that they don't [Mon Jun 17 21:19:00 2013] and then said that they don't [Mon Jun 17 21:22:51 2013] (Maybe you can provide a more concrete example of what you're trying to type?) [Mon Jun 17 21:22:51 2013] (Maybe you can provide a more concrete example of what you're trying to type?) [Mon Jun 17 21:22:53 2013] I'm not sure I follow. I'm looking for the type of (assume A = string): fun a : string => if string_dec a "abc" then b1 else if string_dec a "def" then b2. where b1 : B c1 d1, and b2 : B c2 d2, with c1 c2 : C, d1 d2 : D, and both C and D are unparametrised types [Mon Jun 17 21:22:53 2013] I'm not sure I follow. I'm looking for the type of (assume A = string): fun a : string => if string_dec a "abc" then b1 else if string_dec a "def" then b2. where b1 : B c1 d1, and b2 : B c2 d2, with c1 c2 : C, d1 d2 : D, and both C and D are unparametrised types [Mon Jun 17 21:23:26 2013] Sorry, with a "Some" wrapping b1, b2, and a final "else None" clause. So: [Mon Jun 17 21:23:26 2013] Sorry, with a "Some" wrapping b1, b2, and a final "else None" clause. So: [Mon Jun 17 21:24:24 2013] fun a : string => if (string_dec a "abc") then (Some b1) else (if (string_dec a "def") then (Some b2) else None). [Mon Jun 17 21:24:24 2013] fun a : string => if (string_dec a "abc") then (Some b1) else (if (string_dec a "def") then (Some b2) else None). [Mon Jun 17 21:25:01 2013] Clearer? [Mon Jun 17 21:25:01 2013] Clearer? [Mon Jun 17 21:29:16 2013] I thought of something along the lines of: A -> option { cd : (C * D) & B (fst cd) (snd cd) }, but that doesn't seem quite right, because it lets in any (C * D), instead of one specific to the given A. [Mon Jun 17 21:29:16 2013] I thought of something along the lines of: A -> option { cd : (C * D) & B (fst cd) (snd cd) }, but that doesn't seem quite right, because it lets in any (C * D), instead of one specific to the given A. [Mon Jun 17 21:31:09 2013] forall (a : string), option (if string_dec a "abc" then B c1 d1 else B c2 d2) ? [Mon Jun 17 21:31:10 2013] forall (a : string), option (if string_dec a "abc" then B c1 d1 else B c2 d2) ? [Mon Jun 17 21:34:31 2013] Cale: And if I want to make this generic to an arbitrary (but finite) number of such combinations? Create a new type that takes in a list (A * C * D), and builds the appropriate type from this? [Mon Jun 17 21:34:31 2013] Cale: And if I want to make this generic to an arbitrary (but finite) number of such combinations? Create a new type that takes in a list (A * C * D), and builds the appropriate type from this? [Mon Jun 17 21:34:50 2013] I guess? I don't know what you're trying to do [Mon Jun 17 21:34:50 2013] I guess? I don't know what you're trying to do [Mon Jun 17 21:37:06 2013] It could be that you're actually not interested in the precise type of the value, but only that it has certain properties [Mon Jun 17 21:37:06 2013] It could be that you're actually not interested in the precise type of the value, but only that it has certain properties [Mon Jun 17 21:37:54 2013] and you might want to instead define what those are and an injection from the various types into a more general type that expresses that certain operations are available [Mon Jun 17 21:37:54 2013] and you might want to instead define what those are and an injection from the various types into a more general type that expresses that certain operations are available [Mon Jun 17 21:40:16 2013] ryanakca: this works: http://hpaste.org/90070 [Mon Jun 17 21:40:16 2013] ryanakca: this works: http://hpaste.org/90070 [Mon Jun 17 21:41:03 2013] Cale: Thanks [Mon Jun 17 21:41:03 2013] Cale: Thanks [Mon Jun 17 21:41:09 2013] (I'm terrible at coq, so I didn't want to bother figuring out the syntax to convince it that Some b1 was well typed in context) [Mon Jun 17 21:41:09 2013] (I'm terrible at coq, so I didn't want to bother figuring out the syntax to convince it that Some b1 was well typed in context) [Mon Jun 17 21:42:19 2013] (for that matter, destruct would probably have worked as well as case_eq) [Mon Jun 17 21:42:19 2013] (for that matter, destruct would probably have worked as well as case_eq) [Mon Jun 17 21:43:01 2013] yeah, it does [Mon Jun 17 21:43:01 2013] yeah, it does [Mon Jun 17 21:43:21 2013] lol, the code that it generates is bizarrely enormous for some reason [Mon Jun 17 21:43:21 2013] lol, the code that it generates is bizarrely enormous for some reason [Mon Jun 17 21:45:31 2013] http://hpaste.org/90071 [Mon Jun 17 21:45:31 2013] http://hpaste.org/90071 [Mon Jun 17 21:46:53 2013] I guess it's just inlining [Mon Jun 17 21:46:53 2013] I guess it's just inlining [Mon Jun 17 22:02:57 2013] ryanakca: btw, this is how to convince it directly that the types line up: http://hpaste.org/90073 [Mon Jun 17 22:02:57 2013] ryanakca: btw, this is how to convince it directly that the types line up: http://hpaste.org/90073 [Tue Jun 18 01:48:34 2013] Where can I read the Inductive definition for Prop ? [Tue Jun 18 01:48:34 2013] Where can I read the Inductive definition for Prop ? [Tue Jun 18 01:48:39 2013] i.e. the set of all posisble ways to build up a Prop in coq [Tue Jun 18 01:48:39 2013] i.e. the set of all posisble ways to build up a Prop in coq [Tue Jun 18 02:10:30 2013] Prop isn't inductively defined. [Tue Jun 18 02:10:30 2013] Prop isn't inductively defined. [Tue Jun 18 02:11:01 2013] There are some typing rules in ch2 (I think) of the manual. [Tue Jun 18 02:11:01 2013] There are some typing rules in ch2 (I think) of the manual. [Tue Jun 18 02:39:05 2013] tomprince: noted, thanks! [Tue Jun 18 02:39:05 2013] tomprince: noted, thanks! [Tue Jun 18 04:50:00 2013] in standard coq, (without law of excluded middlees), is the following even true? [Tue Jun 18 04:50:00 2013] in standard coq, (without law of excluded middlees), is the following even true? [Tue Jun 18 04:50:01 2013] Lemma lem1: forall (A: Type) (f1: A -> Prop) (f2: A -> Prop), (forall x, f1(x) /\ f2(x)) = (forall x, f1(x)) /\ (forall x, f2(x)). [Tue Jun 18 04:50:01 2013] Lemma lem1: forall (A: Type) (f1: A -> Prop) (f2: A -> Prop), (forall x, f1(x) /\ f2(x)) = (forall x, f1(x)) /\ (forall x, f2(x)). [Tue Jun 18 04:50:17 2013] http://hpaste.org/90092 <-- non ugly version [Tue Jun 18 04:50:17 2013] http://hpaste.org/90092 <-- non ugly version [Tue Jun 18 04:52:42 2013] those propositions are the same. and it doesn't have much to do with excluded middle. [Tue Jun 18 04:52:42 2013] those propositions are the same. and it doesn't have much to do with excluded middle. [Tue Jun 18 04:52:57 2013] are [Tue Jun 18 04:52:58 2013] are [Tue Jun 18 04:52:59 2013] er [Tue Jun 18 04:52:59 2013] er [Tue Jun 18 04:53:00 2013] *are not [Tue Jun 18 04:53:00 2013] *are not [Tue Jun 18 04:53:03 2013] perhaps instead of = (strict equality), you mean <-> (bi-implication) [Tue Jun 18 04:53:03 2013] perhaps instead of = (strict equality), you mean <-> (bi-implication) [Tue Jun 18 04:53:08 2013] in which case it is provable [Tue Jun 18 04:53:08 2013] in which case it is provable [Tue Jun 18 04:53:15 2013] no, I want = [Tue Jun 18 04:53:15 2013] no, I want = [Tue Jun 18 04:53:18 2013] so I can use rewrite [Tue Jun 18 04:53:18 2013] so I can use rewrite [Tue Jun 18 04:53:23 2013] unless I can also use rewrite with <-> [Tue Jun 18 04:53:23 2013] unless I can also use rewrite with <-> [Tue Jun 18 04:53:41 2013] well, you can't have it. unless you add propositional extensionality as an axiom. [Tue Jun 18 04:53:41 2013] well, you can't have it. unless you add propositional extensionality as an axiom. [Tue Jun 18 04:53:41 2013] how do I prove it? [Tue Jun 18 04:53:41 2013] how do I prove it? [Tue Jun 18 04:53:52 2013] * googles propositional extensionality [Tue Jun 18 04:53:52 2013] * googles propositional extensionality [Tue Jun 18 04:54:08 2013] where are you trying to rewrite it exactly? [Tue Jun 18 04:54:08 2013] where are you trying to rewrite it exactly? [Tue Jun 18 04:55:21 2013] I'm trying to promote a forall and and [Tue Jun 18 04:55:21 2013] I'm trying to promote a forall and and [Tue Jun 18 04:55:29 2013] so something like forall a b c d e f g , P1 /\ P2 [Tue Jun 18 04:55:29 2013] so something like forall a b c d e f g , P1 /\ P2 [Tue Jun 18 04:55:38 2013] gets split into "forall a b c d e f g, P1" and "foral a b c d e f g, P2" [Tue Jun 18 04:55:38 2013] gets split into "forall a b c d e f g, P1" and "foral a b c d e f g, P2" [Tue Jun 18 04:55:43 2013] for var-length "a b c d e f g" [Tue Jun 18 04:55:43 2013] for var-length "a b c d e f g" [Tue Jun 18 04:56:22 2013] gallina_newb: that's easy. use the "split" tactic. [Tue Jun 18 04:56:22 2013] gallina_newb: that's easy. use the "split" tactic. [Tue Jun 18 04:56:53 2013] it can split across a forall? [Tue Jun 18 04:56:53 2013] it can split across a forall? [Tue Jun 18 04:57:10 2013] sorry, this is a _hypothesis_, not a goal [Tue Jun 18 04:57:10 2013] sorry, this is a _hypothesis_, not a goal [Tue Jun 18 04:57:18 2013] so I have "H: forall ab c d e f g, P1 /\ P2" [Tue Jun 18 04:57:18 2013] so I have "H: forall ab c d e f g, P1 /\ P2" [Tue Jun 18 04:57:22 2013] and I want to generate H1 and H2 [Tue Jun 18 04:57:22 2013] and I want to generate H1 and H2 [Tue Jun 18 04:58:28 2013] ah. [Tue Jun 18 04:58:28 2013] ah. [Tue Jun 18 04:58:41 2013] I'm not sure you'd be able to do that rewrite even if you had it, given that it's under a binder. [Tue Jun 18 04:58:41 2013] I'm not sure you'd be able to do that rewrite even if you had it, given that it's under a binder. [Tue Jun 18 04:59:00 2013] I think there might be shorthand syntax for introducting H in the split form? [Tue Jun 18 04:59:00 2013] I think there might be shorthand syntax for introducting H in the split form? [Tue Jun 18 04:59:06 2013] you can just write it in the ugly long form way. [Tue Jun 18 04:59:06 2013] you can just write it in the ugly long form way. [Tue Jun 18 04:59:47 2013] elliott: what's the ugly long form way? [Tue Jun 18 04:59:47 2013] elliott: what's the ugly long form way? [Tue Jun 18 05:00:19 2013] pose proof (fun a b c d e f g => proj1 (H a b c d e f g)) as H1. [Tue Jun 18 05:00:19 2013] pose proof (fun a b c d e f g => proj1 (H a b c d e f g)) as H1. [Tue Jun 18 05:00:24 2013] pose proof (fun a b c d e f g => proj2 (H a b c d e f g)) as H2. [Tue Jun 18 05:00:24 2013] pose proof (fun a b c d e f g => proj2 (H a b c d e f g)) as H2. [Tue Jun 18 05:00:27 2013] clear H. [Tue Jun 18 05:00:27 2013] clear H. [Tue Jun 18 05:02:03 2013] yes, but I'm trying to write a tactic :-) [Tue Jun 18 05:02:03 2013] yes, but I'm trying to write a tactic :-) [Tue Jun 18 05:02:10 2013] and I'd like it to handle arbitrary number of a b c d e f g [Tue Jun 18 05:02:10 2013] and I'd like it to handle arbitrary number of a b c d e f g [Tue Jun 18 05:02:21 2013] though in reality, I doubt I'll make it past more than 10 [Tue Jun 18 05:02:21 2013] though in reality, I doubt I'll make it past more than 10 [Tue Jun 18 05:04:56 2013] * knows nothin about ltac programming, thankfully [Tue Jun 18 05:04:56 2013] * knows nothin about ltac programming, thankfully [Wed Jun 19 03:06:14 2013] I know how to define "max (lst: list Z): Z := ... " [Wed Jun 19 03:06:14 2013] I know how to define "max (lst: list Z): Z := ... " [Wed Jun 19 03:06:24 2013] however, I want to define a function "max" whose inputs are _non-empty_ lists [Wed Jun 19 03:06:24 2013] however, I want to define a function "max" whose inputs are _non-empty_ lists [Wed Jun 19 03:06:38 2013] in Coq, how do I specify somethign like "max (lst: list Z, lst is not nil) : Z := ... " [Wed Jun 19 03:06:38 2013] in Coq, how do I specify somethign like "max (lst: list Z, lst is not nil) : Z := ... " [Wed Jun 19 03:06:50 2013] and then have Coq not complain to me about "match lst with ... " not matching against nil list [Wed Jun 19 03:06:50 2013] and then have Coq not complain to me about "match lst with ... " not matching against nil list [Wed Jun 19 03:06:51 2013] thanks [Wed Jun 19 03:06:51 2013] thanks [Wed Jun 19 03:30:51 2013] gallina_newb: https://paste.debian.net/11246/ [Wed Jun 19 03:30:51 2013] gallina_newb: https://paste.debian.net/11246/ [Wed Jun 19 03:31:50 2013] (using the proof mode) [Wed Jun 19 03:31:50 2013] (using the proof mode) [Wed Jun 19 03:32:36 2013] so : refine (let m := IHlst _ in _) <-- this is the same as "m = max of rest of list" ? [Wed Jun 19 03:32:36 2013] so : refine (let m := IHlst _ in _) <-- this is the same as "m = max of rest of list" ? [Wed Jun 19 03:32:47 2013] and "z" is the first element of "lst" ? [Wed Jun 19 03:32:47 2013] and "z" is the first element of "lst" ? [Wed Jun 19 03:32:53 2013] I've never seen a function defined this way. [Wed Jun 19 03:32:53 2013] I've never seen a function defined this way. [Wed Jun 19 03:34:14 2013] oh wait [Wed Jun 19 03:34:14 2013] oh wait [Wed Jun 19 03:34:26 2013] the "exact a" <-- this is the line where I define that a list of element is the avlue of that element [Wed Jun 19 03:34:26 2013] the "exact a" <-- this is the line where I define that a list of element is the avlue of that element [Wed Jun 19 03:35:08 2013] you have to execute it interactively to understand [Wed Jun 19 03:35:08 2013] you have to execute it interactively to understand [Wed Jun 19 03:35:41 2013] just did so [Wed Jun 19 03:35:41 2013] just did so [Wed Jun 19 03:36:01 2013] so after you do "destruct lst" [Wed Jun 19 03:36:01 2013] so after you do "destruct lst" [Wed Jun 19 03:36:11 2013] there's two cases, one case is the [a]; the other is x::xs [Wed Jun 19 03:36:11 2013] there's two cases, one case is the [a]; the other is x::xs [Wed Jun 19 03:36:17 2013] "exact a" handles the [a] case [Wed Jun 19 03:36:17 2013] "exact a" handles the [a] case [Wed Jun 19 03:36:35 2013] It's still not clear to me why you're using a refine (let m: ... ) [Wed Jun 19 03:36:35 2013] It's still not clear to me why you're using a refine (let m: ... ) [Wed Jun 19 03:42:13 2013] to have the opportunity to give the missing argument to the recursive call as a proof (with tactics) [Wed Jun 19 03:42:13 2013] to have the opportunity to give the missing argument to the recursive call as a proof (with tactics) [Wed Jun 19 03:42:59 2013] (the missing argument has type "(z::lst) <> nil") [Wed Jun 19 03:42:59 2013] (the missing argument has type "(z::lst) <> nil") [Wed Jun 19 03:44:23 2013] unerstood now. [Wed Jun 19 03:44:23 2013] unerstood now. [Wed Jun 19 03:44:28 2013] Thanks for the code, this was very enlightening. [Wed Jun 19 03:44:28 2013] Thanks for the code, this was very enlightening. [Wed Jun 19 03:49:27 2013] gallina_newb: alternatively, https://paste.debian.net/11250/ [Wed Jun 19 03:49:27 2013] gallina_newb: alternatively, https://paste.debian.net/11250/ [Wed Jun 19 03:49:32 2013] (without proof mode) [Wed Jun 19 03:49:33 2013] (without proof mode) [Wed Jun 19 06:51:19 2013] hi all [Wed Jun 19 06:51:19 2013] hi all [Wed Jun 19 06:51:57 2013] suppose i would like to prove something like this https://privatepaste.com/10be873a32 [Wed Jun 19 06:51:57 2013] suppose i would like to prove something like this https://privatepaste.com/10be873a32 [Wed Jun 19 06:52:37 2013] which is quite trivial on paper but in Coq im a bit unsure on what angle to tackle it from [Wed Jun 19 06:52:37 2013] which is quite trivial on paper but in Coq im a bit unsure on what angle to tackle it from [Wed Jun 19 06:53:36 2013] the basic idea is that s ++ x is greater than s ++ y, simply because we have the assumption that x is greater than y [Wed Jun 19 06:53:36 2013] the basic idea is that s ++ x is greater than s ++ y, simply because we have the assumption that x is greater than y [Wed Jun 19 06:53:44 2013] the s part is therefore redundant [Wed Jun 19 06:53:44 2013] the s part is therefore redundant [Wed Jun 19 06:53:57 2013] any hints? [Wed Jun 19 06:53:57 2013] any hints? [Wed Jun 19 07:02:20 2013] maybe someone knows of a lemma/theorem from the libraries that looks similar? [Wed Jun 19 07:02:20 2013] maybe someone knows of a lemma/theorem from the libraries that looks similar? [Wed Jun 19 07:11:29 2013] I guess this is the kind of property you'd usually want to prove as a separate lemma for the usual orderings of lists. [Wed Jun 19 07:11:29 2013] I guess this is the kind of property you'd usually want to prove as a separate lemma for the usual orderings of lists. [Wed Jun 19 07:12:29 2013] I don't think there's a lemma for this kind of thing already, but it should be rather simple to prove by induction over s [Wed Jun 19 07:12:29 2013] I don't think there's a lemma for this kind of thing already, but it should be rather simple to prove by induction over s [Wed Jun 19 07:15:17 2013] yea im making a seperate lemma out of it [Wed Jun 19 07:15:17 2013] yea im making a seperate lemma out of it [Wed Jun 19 07:16:08 2013] hm [Wed Jun 19 07:16:08 2013] hm [Wed Jun 19 07:16:25 2013] rather simple you say? :p [Wed Jun 19 07:16:25 2013] rather simple you say? :p [Wed Jun 19 07:18:30 2013] well, it looks like it, at least :) [Wed Jun 19 07:18:30 2013] well, it looks like it, at least :) [Wed Jun 19 07:18:46 2013] yep that was my impression too [Wed Jun 19 07:18:46 2013] yep that was my impression too [Wed Jun 19 07:19:18 2013] in the base case you have the assumption, in the inductive step -- I figure, the compare is defined inductively on the list, so you should be able to use the induction hypothesis [Wed Jun 19 07:19:18 2013] in the base case you have the assumption, in the inductive step -- I figure, the compare is defined inductively on the list, so you should be able to use the induction hypothesis [Wed Jun 19 07:21:29 2013] the compare is defined by a fixpoint [Wed Jun 19 07:21:29 2013] the compare is defined by a fixpoint [Wed Jun 19 07:22:11 2013] https://privatepaste.com/a6fe9a9d3a [Wed Jun 19 07:22:11 2013] https://privatepaste.com/a6fe9a9d3a [Wed Jun 19 07:24:21 2013] yeah, so in the inductive step you get a (ltr_compare l l), for which you should have a lemma stating it's always Eq, the ifs simplify, and you should be able to apply IH [Wed Jun 19 07:24:21 2013] yeah, so in the inductive step you get a (ltr_compare l l), for which you should have a lemma stating it's always Eq, the ifs simplify, and you should be able to apply IH [Wed Jun 19 07:24:44 2013] (where l is the first letter of s, on which the induction is happening) [Wed Jun 19 07:24:44 2013] (where l is the first letter of s, on which the induction is happening) [Wed Jun 19 07:25:32 2013] yes [Wed Jun 19 07:25:32 2013] yes [Wed Jun 19 07:25:49 2013] and that lemma stating its always Eq is the one im trying to construct :p [Wed Jun 19 07:25:49 2013] and that lemma stating its always Eq is the one im trying to construct :p [Wed Jun 19 07:28:00 2013] my battery is running low, gotta move to a spot with an electricity socket, back in a bit [Wed Jun 19 07:28:00 2013] my battery is running low, gotta move to a spot with an electricity socket, back in a bit [Wed Jun 19 07:41:31 2013] hi [Wed Jun 19 07:41:31 2013] hi [Wed Jun 19 07:57:57 2013] fisi, still here? [Wed Jun 19 07:57:57 2013] fisi, still here? [Wed Jun 19 07:59:03 2013] suppose i have this definition of ltr_compare https://privatepaste.com/c83ee4e96c (upper part) and in proof mode i have the bottom part. How do i replace "ltr_compare l l" with Eq? [Wed Jun 19 07:59:03 2013] suppose i have this definition of ltr_compare https://privatepaste.com/c83ee4e96c (upper part) and in proof mode i have the bottom part. How do i replace "ltr_compare l l" with Eq? [Wed Jun 19 08:04:41 2013] is it possible to add a proven lemma to the list of assumptions? [Wed Jun 19 08:04:41 2013] is it possible to add a proven lemma to the list of assumptions? [Wed Jun 19 08:10:30 2013] roosbeef: e.g. "pose proof my_lemma." [Wed Jun 19 08:10:30 2013] roosbeef: e.g. "pose proof my_lemma." [Wed Jun 19 08:10:57 2013] ha thanks :) [Wed Jun 19 08:10:57 2013] ha thanks :) [Wed Jun 19 08:11:54 2013] roosbeef: but generally you shouldn't need to... [Wed Jun 19 08:11:54 2013] roosbeef: but generally you shouldn't need to... [Wed Jun 19 08:12:00 2013] elliott why is that? [Wed Jun 19 08:12:00 2013] elliott why is that? [Wed Jun 19 08:12:30 2013] well, i have this lemma proven, H0 : forall x : letter, ltr_compare x x = Eq [Wed Jun 19 08:12:30 2013] well, i have this lemma proven, H0 : forall x : letter, ltr_compare x x = Eq [Wed Jun 19 08:12:30 2013] and this is nested inside a proof im working on: [Wed Jun 19 08:12:30 2013] and this is nested inside a proof im working on: [Wed Jun 19 08:12:35 2013] ltr_compare l l [Wed Jun 19 08:12:35 2013] ltr_compare l l [Wed Jun 19 08:12:41 2013] id like to replace the latter with Eq [Wed Jun 19 08:12:41 2013] id like to replace the latter with Eq [Wed Jun 19 08:13:11 2013] well, you can usually use "apply" or "contradict" or so on rather than needing it as an assumption [Wed Jun 19 08:13:11 2013] well, you can usually use "apply" or "contradict" or so on rather than needing it as an assumption [Wed Jun 19 08:13:21 2013] here it sounds like what you want is "rewrite H0" [Wed Jun 19 08:13:21 2013] here it sounds like what you want is "rewrite H0" [Wed Jun 19 08:13:26 2013] (I thought you meant a lemma defined separately) [Wed Jun 19 08:13:26 2013] (I thought you meant a lemma defined separately) [Wed Jun 19 08:13:55 2013] ha yep that works :) thank you [Wed Jun 19 08:13:55 2013] ha yep that works :) thank you [Wed Jun 19 08:24:36 2013] sorry, been afk for a while. [Wed Jun 19 08:24:36 2013] sorry, been afk for a while. [Wed Jun 19 08:24:59 2013] I think in this case you can just use `rewrite lemma_name' [Wed Jun 19 08:24:59 2013] I think in this case you can just use `rewrite lemma_name' [Wed Jun 19 08:25:50 2013] (and in the more complicates cases, if it can't figure out the instantiation, you can just apply the arguments, like in `rewrite (lemma_name l)' [Wed Jun 19 08:25:50 2013] (and in the more complicates cases, if it can't figure out the instantiation, you can just apply the arguments, like in `rewrite (lemma_name l)' [Wed Jun 19 08:28:18 2013] cool thanks :) [Wed Jun 19 08:28:18 2013] cool thanks :) [Wed Jun 19 08:28:23 2013] gotta run, bbl [Wed Jun 19 08:28:23 2013] gotta run, bbl [Tue Jun 25 10:04:22 2013] ok so suppose we have [Tue Jun 25 10:04:22 2013] ok so suppose we have [Tue Jun 25 10:04:24 2013] plus_0_r : forall n : nat, n + 0 = n [Tue Jun 25 10:04:24 2013] plus_0_r : forall n : nat, n + 0 = n [Tue Jun 25 10:04:47 2013] and somewhere nested is fs_countgrave x' + 0 [Tue Jun 25 10:04:47 2013] and somewhere nested is fs_countgrave x' + 0 [Tue Jun 25 10:04:54 2013] * engages the full extent of his supposition [Tue Jun 25 10:04:55 2013] * engages the full extent of his supposition [Tue Jun 25 10:05:03 2013] how to rewrite the nested statement to fs_countgrave x'? [Tue Jun 25 10:05:03 2013] how to rewrite the nested statement to fs_countgrave x'? [Tue Jun 25 10:05:09 2013] (removing the + 0 part) [Tue Jun 25 10:05:10 2013] (removing the + 0 part) [Tue Jun 25 10:05:33 2013] rewrite plus_0_r [Tue Jun 25 10:05:34 2013] rewrite plus_0_r [Tue Jun 25 10:05:50 2013] er, or is it rewrite <- plus_0_r. I always mix the directions up. [Tue Jun 25 10:05:50 2013] er, or is it rewrite <- plus_0_r. I always mix the directions up. [Tue Jun 25 10:05:54 2013] wow that simple? :p [Tue Jun 25 10:05:54 2013] wow that simple? :p [Tue Jun 25 10:05:58 2013] thanks lol [Tue Jun 25 10:05:58 2013] thanks lol [Tue Jun 25 10:06:10 2013] didnt think it would be that simple for some reason ;p [Tue Jun 25 10:06:10 2013] didnt think it would be that simple for some reason ;p [Tue Jun 25 10:06:38 2013] :) [Tue Jun 25 10:06:39 2013] :) [Wed Jun 26 00:06:41 2013] is there a type for a function of the form "Keq: K -> K -> bool" where forall k1 k2, Keq k1 k2 = true <-> k1 = k2 ? [Wed Jun 26 00:06:41 2013] is there a type for a function of the form "Keq: K -> K -> bool" where forall k1 k2, Keq k1 k2 = true <-> k1 = k2 ? [Wed Jun 26 00:07:08 2013] I want something more restrictive than "K -> K -> bool"; i.e. something that also satisfies "is the same as =" [Wed Jun 26 00:07:08 2013] I want something more restrictive than "K -> K -> bool"; i.e. something that also satisfies "is the same as =" [Wed Jun 26 00:07:31 2013] for example, "leb" and "ltb" both satisfy "nat -> nat -> bool", but they don't satisfy "=" [Wed Jun 26 00:07:31 2013] for example, "leb" and "ltb" both satisfy "nat -> nat -> bool", but they don't satisfy "=" [Wed Jun 26 00:13:18 2013] thm_prover: forall a b : K, { a = b } + { a <> b } [Wed Jun 26 00:13:18 2013] thm_prover: forall a b : K, { a = b } + { a <> b } [Wed Jun 26 00:13:44 2013] this is a sum-bool right? [Wed Jun 26 00:13:44 2013] this is a sum-bool right? [Wed Jun 26 00:13:56 2013] although I'm sure you're right, can you explain wtf is going on? [Wed Jun 26 00:13:56 2013] although I'm sure you're right, can you explain wtf is going on? [Wed Jun 26 00:14:14 2013] how does having this type, without specifying how it's defined, allow me to use it within functions that must terminate [Wed Jun 26 00:14:14 2013] how does having this type, without specifying how it's defined, allow me to use it within functions that must terminate [Wed Jun 26 00:14:22 2013] I fail to understand all the black magic behind the scenes [Wed Jun 26 00:14:22 2013] I fail to understand all the black magic behind the scenes [Wed Jun 26 00:14:28 2013] Er, what? [Wed Jun 26 00:14:28 2013] Er, what? [Wed Jun 26 00:14:30 2013] the truth is, bool is rarely what you want [Wed Jun 26 00:14:30 2013] the truth is, bool is rarely what you want [Wed Jun 26 00:14:39 2013] thm_prover: you want a type that says "either equal or not equal" [Wed Jun 26 00:14:39 2013] thm_prover: you want a type that says "either equal or not equal" [Wed Jun 26 00:14:43 2013] and that is literally what Cale's type says [Wed Jun 26 00:14:43 2013] and that is literally what Cale's type says [Wed Jun 26 00:14:51 2013] well, I ned to use this ina function [Wed Jun 26 00:14:51 2013] well, I ned to use this ina function [Wed Jun 26 00:15:00 2013] i.e. Function blah blah blah = if (TEST ...) then ... else ... [Wed Jun 26 00:15:00 2013] i.e. Function blah blah blah = if (TEST ...) then ... else ... [Wed Jun 26 00:15:04 2013] If you have a term of that type, what it does is for every a and b of type K to produce either a proof that a = b, or a proof that a <> b. [Wed Jun 26 00:15:04 2013] If you have a term of that type, what it does is for every a and b of type K to produce either a proof that a = b, or a proof that a <> b. [Wed Jun 26 00:15:10 2013] iirc, if magically works on that type [Wed Jun 26 00:15:10 2013] iirc, if magically works on that type [Wed Jun 26 00:15:12 2013] so I think I need K -> K -> bool; ... unless I compeltely fail to understand how functions work [Wed Jun 26 00:15:12 2013] so I think I need K -> K -> bool; ... unless I compeltely fail to understand how functions work [Wed Jun 26 00:15:18 2013] This is the case whether it's a function parameter or not. [Wed Jun 26 00:15:18 2013] This is the case whether it's a function parameter or not. [Wed Jun 26 00:15:35 2013] You can always turn a sum like this into a bool [Wed Jun 26 00:15:35 2013] You can always turn a sum like this into a bool [Wed Jun 26 00:16:05 2013] But you can't necessarily go the other way -- the value of the sum type will actually contain the proof of equality or inequality. [Wed Jun 26 00:16:05 2013] But you can't necessarily go the other way -- the value of the sum type will actually contain the proof of equality or inequality. [Wed Jun 26 00:16:21 2013] Coq is complaingn to me [Wed Jun 26 00:16:21 2013] Coq is complaingn to me [Wed Jun 26 00:16:29 2013] that I have a type {k1 = k2} + {k1 <> k2} rather than bool [Wed Jun 26 00:16:29 2013] that I have a type {k1 = k2} + {k1 <> k2} rather than bool [Wed Jun 26 00:16:35 2013] how do I force this into a bool? [Wed Jun 26 00:16:35 2013] how do I force this into a bool? [Wed Jun 26 00:16:37 2013] in which context? [Wed Jun 26 00:16:37 2013] in which context? [Wed Jun 26 00:17:02 2013] let me produce minimal example [Wed Jun 26 00:17:02 2013] let me produce minimal example [Wed Jun 26 00:17:25 2013] You can usually use this in an if as well... as you can with any inductive type with two constructors [Wed Jun 26 00:17:25 2013] You can usually use this in an if as well... as you can with any inductive type with two constructors [Wed Jun 26 00:17:54 2013] http://hpaste.org/90436 [Wed Jun 26 00:17:54 2013] http://hpaste.org/90436 [Wed Jun 26 00:17:54 2013] hmm [Wed Jun 26 00:17:54 2013] hmm [Wed Jun 26 00:17:57 2013] I should minimize it more [Wed Jun 26 00:17:57 2013] I should minimize it more [Wed Jun 26 00:18:11 2013] So you could write if b then true else false, where b : {x = y} + {x <> y} [Wed Jun 26 00:18:11 2013] So you could write if b then true else false, where b : {x = y} + {x <> y} [Wed Jun 26 00:18:32 2013] and that'll throw away the information about which things were equal or not [Wed Jun 26 00:18:32 2013] and that'll throw away the information about which things were equal or not [Wed Jun 26 00:19:13 2013] this is one place where if x then true else false is not a nop! :P [Wed Jun 26 00:19:13 2013] this is one place where if x then true else false is not a nop! :P [Wed Jun 26 00:19:32 2013] well, in practice, the generated code might be I guess [Wed Jun 26 00:19:32 2013] well, in practice, the generated code might be I guess [Wed Jun 26 00:20:02 2013] Well, it's only not a nop because coq has generalised if/then/else :) [Wed Jun 26 00:20:02 2013] Well, it's only not a nop because coq has generalised if/then/else :) [Wed Jun 26 00:21:09 2013] I'm an idiot [Wed Jun 26 00:21:09 2013] I'm an idiot [Wed Jun 26 00:21:11 2013] it works now [Wed Jun 26 00:21:11 2013] it works now [Wed Jun 26 00:21:12 2013] thanks! [Wed Jun 26 00:21:12 2013] thanks! [Wed Jun 26 00:21:36 2013] thm_prover: use in_dec from List [Wed Jun 26 00:21:36 2013] thm_prover: use in_dec from List [Wed Jun 26 00:21:48 2013] rather than whatever in_listb is [Wed Jun 26 00:21:48 2013] rather than whatever in_listb is [Wed Jun 26 00:22:00 2013] Cale: I hereby double your commission [Wed Jun 26 00:22:00 2013] Cale: I hereby double your commission [Wed Jun 26 00:32:03 2013] :O [Wed Jun 26 00:32:03 2013] :O [Wed Jun 26 09:35:38 2013] in proof mode, why does unfolding a function f inside an assumption lead to a "fix f ..." structure? [Wed Jun 26 09:35:38 2013] in proof mode, why does unfolding a function f inside an assumption lead to a "fix f ..." structure? [Wed Jun 26 09:36:22 2013] (whereas, unfolding the same function inside a goal just leads to the function being reducted) [Wed Jun 26 09:36:22 2013] (whereas, unfolding the same function inside a goal just leads to the function being reducted) [Wed Jun 26 09:38:26 2013] nm, guess i have to destruct it as well [Wed Jun 26 09:38:26 2013] nm, guess i have to destruct it as well [Wed Jun 26 09:39:01 2013] need to feed it enough information to reduce [Wed Jun 26 09:39:01 2013] need to feed it enough information to reduce [Wed Jun 26 09:40:56 2013] whats up elliot :) [Wed Jun 26 09:40:56 2013] whats up elliot :) [Wed Jun 26 09:48:03 2013] can i do implicit args in coq? [Wed Jun 26 09:48:03 2013] can i do implicit args in coq? [Wed Jun 26 09:48:13 2013] it keeps expecting them when i pattern match [Wed Jun 26 09:48:14 2013] it keeps expecting them when i pattern match [Wed Jun 26 09:54:00 2013] hm does "destruct f x" actually compute the result of "f x" as a specific instance, or just replace it with the possible values of f (suppose f has 3 possible outcomes, it would split the goal three way) [Wed Jun 26 09:54:00 2013] hm does "destruct f x" actually compute the result of "f x" as a specific instance, or just replace it with the possible values of f (suppose f has 3 possible outcomes, it would split the goal three way) [Wed Jun 26 09:56:08 2013] you probably mean destruct (f x) [Wed Jun 26 09:56:08 2013] you probably mean destruct (f x) [Wed Jun 26 09:56:15 2013] in which case it does not "remember" that the result comes from f, yes [Wed Jun 26 09:56:15 2013] in which case it does not "remember" that the result comes from f, yes [Wed Jun 26 09:56:20 2013] you can do: remember (f x) as foo; destruct foo [Wed Jun 26 09:56:20 2013] you can do: remember (f x) as foo; destruct foo [Wed Jun 26 09:56:28 2013] and then you get an equality showing that the result is equal to f x [Wed Jun 26 09:56:29 2013] and then you get an equality showing that the result is equal to f x [Wed Jun 26 09:56:33 2013] which you can then do inversion type things on [Wed Jun 26 09:56:33 2013] which you can then do inversion type things on [Wed Jun 26 09:58:56 2013] i did mean destruct (f x) [Wed Jun 26 09:58:56 2013] i did mean destruct (f x) [Wed Jun 26 09:59:13 2013] let me see [Wed Jun 26 09:59:13 2013] let me see [Wed Jun 26 10:01:05 2013] hm [Wed Jun 26 10:01:05 2013] hm [Wed Jun 26 10:01:07 2013] that doesnt help much [Wed Jun 26 10:01:07 2013] that doesnt help much [Wed Jun 26 10:01:15 2013] it still splits the goal three way [Wed Jun 26 10:01:15 2013] it still splits the goal three way [Wed Jun 26 10:01:56 2013] and each subgoal has foo = a, foo = b, or foo = c (a, b, c being the possible outcomes of f) [Wed Jun 26 10:01:56 2013] and each subgoal has foo = a, foo = b, or foo = c (a, b, c being the possible outcomes of f) [Wed Jun 26 10:02:16 2013] f x has a static value though, it simply computes to a for example [Wed Jun 26 10:02:16 2013] f x has a static value though, it simply computes to a for example [Wed Jun 26 10:02:22 2013] when you follow the definition of f [Wed Jun 26 10:02:22 2013] when you follow the definition of f [Wed Jun 26 10:02:34 2013] its almost as if Coq fully ignores x in doing destruct (f x) [Wed Jun 26 10:02:34 2013] its almost as if Coq fully ignores x in doing destruct (f x) [Wed Jun 26 10:02:58 2013] except that it removes it along with f [Wed Jun 26 10:02:58 2013] except that it removes it along with f [Wed Jun 26 10:05:51 2013] huh? [Wed Jun 26 10:05:51 2013] huh? [Wed Jun 26 10:05:53 2013] it shouldn't... [Wed Jun 26 10:05:53 2013] it shouldn't... [Wed Jun 26 10:05:53 2013] well, [Wed Jun 26 10:05:53 2013] well, [Wed Jun 26 10:06:00 2013] anyway I don't think you want destruct here [Wed Jun 26 10:06:01 2013] im doing "destruct (ltr_compare l l)" [Wed Jun 26 10:06:01 2013] im doing "destruct (ltr_compare l l)" [Wed Jun 26 10:06:01 2013] anyway I don't think you want destruct here [Wed Jun 26 10:06:05 2013] why not use "simpl" or "compute"? [Wed Jun 26 10:06:05 2013] why not use "simpl" or "compute"? [Wed Jun 26 10:06:13 2013] ltr_compare checks the order of two letters [Wed Jun 26 10:06:13 2013] ltr_compare checks the order of two letters [Wed Jun 26 10:06:22 2013] and if they are the same, it should return Eq [Wed Jun 26 10:06:22 2013] and if they are the same, it should return Eq [Wed Jun 26 10:06:34 2013] ok, so it sounds like you need to do destruct or induction on l [Wed Jun 26 10:06:34 2013] ok, so it sounds like you need to do destruct or induction on l [Wed Jun 26 10:06:40 2013] so i dont see why Coq would split the goal into three cases, Lt, Eq and Gt [Wed Jun 26 10:06:40 2013] so i dont see why Coq would split the goal into three cases, Lt, Eq and Gt [Wed Jun 26 10:06:42 2013] so it computes to Eq in all cases [Wed Jun 26 10:06:42 2013] so it computes to Eq in all cases [Wed Jun 26 10:06:48 2013] because Coq is not a mind-reader [Wed Jun 26 10:06:48 2013] because Coq is not a mind-reader [Wed Jun 26 10:06:58 2013] perhaps you should prove, as a lemma, that forall l, ltr_compare l l = Eq [Wed Jun 26 10:06:59 2013] perhaps you should prove, as a lemma, that forall l, ltr_compare l l = Eq [Wed Jun 26 10:07:03 2013] then you can rewrite with that lemma [Wed Jun 26 10:07:03 2013] then you can rewrite with that lemma [Wed Jun 26 10:07:08 2013] hm [Wed Jun 26 10:07:08 2013] hm [Wed Jun 26 10:07:17 2013] Coq cant see that? [Wed Jun 26 10:07:18 2013] Coq cant see that? [Wed Jun 26 10:07:26 2013] it follows from the definition [Wed Jun 26 10:07:26 2013] it follows from the definition [Wed Jun 26 10:07:36 2013] no, Coq cannot automatically deduce arbitrary theorems about the functions you define :) [Wed Jun 26 10:07:36 2013] no, Coq cannot automatically deduce arbitrary theorems about the functions you define :) [Wed Jun 26 10:07:47 2013] its not an arbitrary theorem! :P [Wed Jun 26 10:07:47 2013] its not an arbitrary theorem! :P [Wed Jun 26 10:07:56 2013] if it computes like you say it does, then "destruct l; auto" should be enough to prove the lemma. [Wed Jun 26 10:07:56 2013] if it computes like you say it does, then "destruct l; auto" should be enough to prove the lemma. [Wed Jun 26 10:08:01 2013] ok fair point i guess [Wed Jun 26 10:08:01 2013] ok fair point i guess [Wed Jun 26 10:08:22 2013] thanks let me look into that :) [Wed Jun 26 10:08:22 2013] thanks let me look into that :) [Wed Jun 26 10:13:02 2013] elliott, so i did "pose ltr_compare_l_l_is_Eq" (which is the lemma proving that for all l, ltr_compare l l = Eq) [Wed Jun 26 10:13:02 2013] elliott, so i did "pose ltr_compare_l_l_is_Eq" (which is the lemma proving that for all l, ltr_compare l l = Eq) [Wed Jun 26 10:13:17 2013] adding to the assumptions e0 := ltr_compare_l_l_is_Eq : forall l : letter, ltr_compare l l = Eq [Wed Jun 26 10:13:17 2013] adding to the assumptions e0 := ltr_compare_l_l_is_Eq : forall l : letter, ltr_compare l l = Eq [Wed Jun 26 10:13:23 2013] "rewrite ltr_compare_l_l_is_Eq" [Wed Jun 26 10:13:23 2013] "rewrite ltr_compare_l_l_is_Eq" [Wed Jun 26 10:13:34 2013] btw, I suggest a more concise name, like ltr_compare_diag :p [Wed Jun 26 10:13:34 2013] btw, I suggest a more concise name, like ltr_compare_diag :p [Wed Jun 26 10:13:43 2013] dont even need to pose it? [Wed Jun 26 10:13:43 2013] dont even need to pose it? [Wed Jun 26 10:13:47 2013] no [Wed Jun 26 10:13:47 2013] no [Wed Jun 26 10:13:57 2013] don't need to pose things to "apply" them either [Wed Jun 26 10:13:57 2013] don't need to pose things to "apply" them either [Wed Jun 26 10:14:00 2013] haha why more concise :p this says exactly what it does [Wed Jun 26 10:14:00 2013] haha why more concise :p this says exactly what it does [Wed Jun 26 10:14:18 2013] so does "ltr_compare_diag", and it's less typing, and it's more consistent with names used in the standard library [Wed Jun 26 10:14:18 2013] so does "ltr_compare_diag", and it's less typing, and it's more consistent with names used in the standard library [Wed Jun 26 10:14:25 2013] though the standard library's names aren't really very consistent... [Wed Jun 26 10:14:25 2013] though the standard library's names aren't really very consistent... [Wed Jun 26 10:14:37 2013] hm what does diag stand for then? [Wed Jun 26 10:14:37 2013] hm what does diag stand for then? [Wed Jun 26 10:16:03 2013] diagonal [Wed Jun 26 10:16:03 2013] diagonal [Wed Jun 26 10:16:17 2013] imagine a table of letters as the rows and columns [Wed Jun 26 10:16:17 2013] imagine a table of letters as the rows and columns [Wed Jun 26 10:16:25 2013] and ltr_compare row col as the squares [Wed Jun 26 10:16:25 2013] and ltr_compare row col as the squares [Wed Jun 26 10:16:32 2013] ah [Wed Jun 26 10:16:32 2013] ah [Wed Jun 26 10:16:38 2013] :p [Wed Jun 26 10:16:38 2013] :p [Wed Jun 26 10:16:40 2013] then the two letters are equal on the "diagonal" [Wed Jun 26 10:16:40 2013] then the two letters are equal on the "diagonal" [Wed Jun 26 10:17:14 2013] (you can also phrase Cantor's diagonal argument in a way that maxes use of an (f x x) type expression) [Wed Jun 26 10:17:14 2013] (you can also phrase Cantor's diagonal argument in a way that maxes use of an (f x x) type expression) [Wed Jun 26 10:21:02 2013] if anyone could help i have P : xs = f (f xs) and i need to solve G xs = f (f (G xs)) [Wed Jun 26 10:21:02 2013] if anyone could help i have P : xs = f (f xs) and i need to solve G xs = f (f (G xs)) [Wed Jun 26 10:21:10 2013] can i do rewrite or something [Wed Jun 26 10:21:10 2013] can i do rewrite or something [Wed Jun 26 10:21:40 2013] uh, that depends on the definition of G surely [Wed Jun 26 10:21:40 2013] uh, that depends on the definition of G surely [Wed Jun 26 10:21:55 2013] if you can prove G (f (f xs)) = f (f (G xs)) then you could do it [Wed Jun 26 10:21:55 2013] if you can prove G (f (f xs)) = f (f (G xs)) then you could do it [Wed Jun 26 10:34:18 2013] im trying to prove xs = reverse (reverse xs) [Wed Jun 26 10:34:18 2013] im trying to prove xs = reverse (reverse xs) [Wed Jun 26 10:34:48 2013] where reverse (cons x xs) = append (reverse xs) x [Wed Jun 26 10:34:48 2013] where reverse (cons x xs) = append (reverse xs) x [Wed Jun 26 10:34:58 2013] any tips? [Wed Jun 26 10:34:58 2013] any tips? [Wed Jun 26 10:36:42 2013] well, by induction nil = reverse (reverse nil) should be trivial, and then cons x xs = reverse (reverse (cons x xs)) should follow by reverse (reverse (cons x xs)) reducing to reverse (append (reverse xs) x) and a lemma like reverse (append xs x) = cons x (reverse xs) [Wed Jun 26 10:36:42 2013] well, by induction nil = reverse (reverse nil) should be trivial, and then cons x xs = reverse (reverse (cons x xs)) should follow by reverse (reverse (cons x xs)) reducing to reverse (append (reverse xs) x) and a lemma like reverse (append xs x) = cons x (reverse xs) [Wed Jun 26 10:38:45 2013] elliott, i have a question [Wed Jun 26 10:38:45 2013] elliott, i have a question [Wed Jun 26 10:39:02 2013] allow me to repost something [Wed Jun 26 10:39:03 2013] allow me to repost something [Wed Jun 26 10:39:18 2013] im trying to prove the following [Wed Jun 26 10:39:18 2013] im trying to prove the following [Wed Jun 26 10:39:19 2013] take the string slr, composed of strings s, l, r, respectively, and the string s{l>}r [Wed Jun 26 10:39:19 2013] it holds that slr > s{l>}r, where {l>} is a string such that {l>} < l [Wed Jun 26 10:39:19 2013] take the string slr, composed of strings s, l, r, respectively, and the string s{l>}r [Wed Jun 26 10:39:19 2013] it holds that slr > s{l>}r, where {l>} is a string such that {l>} < l [Wed Jun 26 10:40:44 2013] im a bit confused, to begin, should i prove (l :: x) > (l :: y) -> x > y, or x > y -> (l :: x) > (l :: y) [Wed Jun 26 10:40:44 2013] im a bit confused, to begin, should i prove (l :: x) > (l :: y) -> x > y, or x > y -> (l :: x) > (l :: y) [Wed Jun 26 10:41:09 2013] to remove s from slr > s{l>}r [Wed Jun 26 10:41:09 2013] to remove s from slr > s{l>}r [Wed Jun 26 10:42:09 2013] (attempting to prove the latter right now) [Wed Jun 26 10:42:09 2013] (attempting to prove the latter right now) [Wed Jun 26 10:43:31 2013] probably the latter [Wed Jun 26 10:43:31 2013] probably the latter [Wed Jun 26 10:43:46 2013] since your goal is that (s :: ...) > (s :: ...) [Wed Jun 26 10:43:46 2013] since your goal is that (s :: ...) > (s :: ...) [Wed Jun 26 10:44:00 2013] thus you want a proof which yields that [Wed Jun 26 10:44:00 2013] thus you want a proof which yields that [Wed Jun 26 10:44:03 2013] yea [Wed Jun 26 10:44:03 2013] yea [Wed Jun 26 10:44:13 2013] ok so im on the right track :) [Wed Jun 26 10:44:13 2013] ok so im on the right track :) [Wed Jun 26 10:44:26 2013] you should be able to prove x > y <-> (l :: x) > (l :: y) though, and then just "apply [<- | ->] prf" whenever you need either direction [Wed Jun 26 10:44:26 2013] you should be able to prove x > y <-> (l :: x) > (l :: y) though, and then just "apply [<- | ->] prf" whenever you need either direction [Wed Jun 26 10:44:29 2013] but it's more work if you only need one way [Wed Jun 26 10:44:29 2013] but it's more work if you only need one way [Wed Jun 26 11:01:13 2013] why do assumptions unfold differently from goals? [Wed Jun 26 11:01:13 2013] why do assumptions unfold differently from goals? [Wed Jun 26 11:02:20 2013] im unfolding the exact same function: https://privatepaste.com/e004b85bbe [Wed Jun 26 11:02:20 2013] im unfolding the exact same function: https://privatepaste.com/e004b85bbe [Wed Jun 26 11:03:15 2013] once ive managed to remove the l :: part, it wont match the assumption [Wed Jun 26 11:03:15 2013] once ive managed to remove the l :: part, it wont match the assumption [Wed Jun 26 11:05:02 2013] because it has enough of a concrete argument to reduce in the goal [Wed Jun 26 11:05:02 2013] because it has enough of a concrete argument to reduce in the goal [Wed Jun 26 11:05:05 2013] not in the assumption [Wed Jun 26 11:05:05 2013] not in the assumption [Wed Jun 26 11:05:24 2013] hm [Wed Jun 26 11:05:24 2013] hm [Wed Jun 26 11:07:01 2013] why is it not enough of a concrete argument [Wed Jun 26 11:07:01 2013] why is it not enough of a concrete argument [Wed Jun 26 11:07:44 2013] because of the {struct fs1} [Wed Jun 26 11:07:45 2013] because of the {struct fs1} [Wed Jun 26 11:07:52 2013] why is fs_compare even defined as a fixpoint? [Wed Jun 26 11:07:52 2013] why is fs_compare even defined as a fixpoint? [Wed Jun 26 11:07:57 2013] it doesn't appear to recurse [Wed Jun 26 11:07:57 2013] it doesn't appear to recurse [Wed Jun 26 11:08:20 2013] hm youre right it doesnt [Wed Jun 26 11:08:20 2013] hm youre right it doesnt [Wed Jun 26 11:08:29 2013] better to use Definition? [Wed Jun 26 11:08:29 2013] better to use Definition? [Wed Jun 26 11:08:35 2013] if you make it a plain Definition coq will be more liberal about unfolding its definition [Wed Jun 26 11:08:35 2013] if you make it a plain Definition coq will be more liberal about unfolding its definition [Wed Jun 26 11:08:47 2013] with fixpoints it has to be very careful that it only unfolds when you give it "more structure" [Wed Jun 26 11:08:48 2013] with fixpoints it has to be very careful that it only unfolds when you give it "more structure" [Wed Jun 26 11:08:50 2013] to ensure termination [Wed Jun 26 11:08:51 2013] to ensure termination [Wed Jun 26 11:09:22 2013] cool, good tip :) [Wed Jun 26 11:09:22 2013] cool, good tip :) [Wed Jun 26 11:09:38 2013] let me check if i did more of that [Wed Jun 26 11:09:38 2013] let me check if i did more of that [Wed Jun 26 11:10:03 2013] btw, you can say "unfold foo in *" [Wed Jun 26 11:10:03 2013] btw, you can say "unfold foo in *" [Wed Jun 26 11:10:05 2013] to do it in one step [Wed Jun 26 11:10:05 2013] to do it in one step [Wed Jun 26 11:12:17 2013] ha nice [Wed Jun 26 11:12:17 2013] ha nice [Wed Jun 26 11:14:45 2013] cool problem fixed! :D [Wed Jun 26 11:14:45 2013] cool problem fixed! :D [Wed Jun 26 11:15:02 2013] it no longer adds the fix in assumptions [Wed Jun 26 11:15:02 2013] it no longer adds the fix in assumptions [Wed Jun 26 11:15:09 2013] thanks elliott! [Wed Jun 26 11:15:09 2013] thanks elliott! [Wed Jun 26 11:18:13 2013] :) [Wed Jun 26 11:18:14 2013] :) [Thu Jun 27 00:15:42 2013] is this channel logged? [Thu Jun 27 00:15:42 2013] is this channel logged? [Thu Jun 27 00:15:49 2013] (there is a paste someone made weeks ago I'd like to dig up) [Thu Jun 27 00:15:49 2013] (there is a paste someone made weeks ago I'd like to dig up) [Thu Jun 27 00:15:51 2013] but don't have the url [Thu Jun 27 00:15:51 2013] but don't have the url [Thu Jun 27 00:18:53 2013] n/m, found it :-) [Thu Jun 27 00:18:53 2013] n/m, found it :-) [Thu Jun 27 03:23:58 2013] http://lists.debian.org/debian-devel/2013/06/msg00720.html [Thu Jun 27 03:23:58 2013] http://lists.debian.org/debian-devel/2013/06/msg00720.html [Thu Jun 27 03:24:03 2013] (coq is in the list) [Thu Jun 27 03:24:03 2013] (coq is in the list) [Thu Jun 27 03:25:37 2013] I know, but don't hold your breath: https://lists.debian.org/debian-ocaml-maint/2013/06/msg00189.html [Thu Jun 27 03:25:37 2013] I know, but don't hold your breath: https://lists.debian.org/debian-ocaml-maint/2013/06/msg00189.html [Thu Jun 27 10:35:47 2013] what does "fix" do as a tactic, in particular "fix 2" ? [Thu Jun 27 10:35:47 2013] what does "fix" do as a tactic, in particular "fix 2" ? [Thu Jun 27 10:37:37 2013] it constructs a function that recurses on the second parameter of the current goal [Thu Jun 27 10:37:37 2013] it constructs a function that recurses on the second parameter of the current goal [Thu Jun 27 10:38:55 2013] you generally revert all parameters that could change in the different cases and recurse on the parameter that decreases structurally [Thu Jun 27 10:38:55 2013] you generally revert all parameters that could change in the different cases and recurse on the parameter that decreases structurally [Thu Jun 27 10:39:13 2013] that's why you can select the position of the parameter.. there might be more than one [Thu Jun 27 10:39:13 2013] that's why you can select the position of the parameter.. there might be more than one [Thu Jun 27 10:44:21 2013] in essence you claim that you can solve the current goal by recursion on the 2nd parameter [Thu Jun 27 10:44:21 2013] in essence you claim that you can solve the current goal by recursion on the 2nd parameter [Thu Jun 27 10:44:55 2013] and coq will gladly provide you with such function which you can then use, but only if you feed it structurally smaller terms in the 2nd position every time you use it [Thu Jun 27 10:44:55 2013] and coq will gladly provide you with such function which you can then use, but only if you feed it structurally smaller terms in the 2nd position every time you use it [Thu Jun 27 10:45:43 2013] thm_prover, would you like to see an example? [Thu Jun 27 10:45:43 2013] thm_prover, would you like to see an example? [Thu Jun 27 10:45:55 2013] actually, I have an example; let me paste it [Thu Jun 27 10:45:55 2013] actually, I have an example; let me paste it [Thu Jun 27 10:46:00 2013] sorry, was afk (reading Coq code) [Thu Jun 27 10:46:00 2013] sorry, was afk (reading Coq code) [Thu Jun 27 10:46:03 2013] [reading your responses now] [Thu Jun 27 10:46:03 2013] [reading your responses now] [Thu Jun 27 10:46:42 2013] http://hpaste.org/90512 so I'm studing this example here [Thu Jun 27 10:46:42 2013] http://hpaste.org/90512 so I'm studing this example here [Thu Jun 27 10:51:19 2013] okay, in this case fix 2 will provide you with a function that solves the current goal for all lists that structurally smaller than the given list [Thu Jun 27 10:51:19 2013] okay, in this case fix 2 will provide you with a function that solves the current goal for all lists that structurally smaller than the given list [Thu Jun 27 10:53:12 2013] if you want to know that your current use of the provided function is valid, you can use "Guarded." and it will tell you if you violated the conditions on the usage of the recursive function [Thu Jun 27 10:53:12 2013] if you want to know that your current use of the provided function is valid, you can use "Guarded." and it will tell you if you violated the conditions on the usage of the recursive function [Thu Jun 27 10:54:19 2013] i.e. if you were to solve the goal right after fix 2. with exact f. you could try Guarded. to see if thats legal. At Qed., coq will complain if its not valid [Thu Jun 27 10:54:19 2013] i.e. if you were to solve the goal right after fix 2. with exact f. you could try Guarded. to see if thats legal. At Qed., coq will complain if its not valid [Thu Jun 27 10:54:36 2013] damnit, sentences with so many dots in them are hard to read [Thu Jun 27 10:54:36 2013] damnit, sentences with so many dots in them are hard to read [Thu Jun 27 10:58:29 2013] http://hpaste.org/90512 this would be the equivalent proof using induction [Thu Jun 27 10:58:29 2013] http://hpaste.org/90512 this would be the equivalent proof using induction [Thu Jun 27 10:59:35 2013] you can see how I extracted the parameter on which I wanted to do induction and reverted the parameters over which I wanted to generalize [Thu Jun 27 10:59:35 2013] you can see how I extracted the parameter on which I wanted to do induction and reverted the parameters over which I wanted to generalize [Thu Jun 27 11:00:51 2013] there is only a slight difference in the application of z_nth in line 10. induction will give a function that can only be applied to xs [Thu Jun 27 11:00:51 2013] there is only a slight difference in the application of z_nth in line 10. induction will give a function that can only be applied to xs [Thu Jun 27 11:01:07 2013] fix, on the other hand, constructs functions that can be applied to all subterms of the original list [Thu Jun 27 11:01:07 2013] fix, on the other hand, constructs functions that can be applied to all subterms of the original list [Thu Jun 27 11:01:37 2013] I am not sure why one would use fix in this example [Thu Jun 27 11:01:37 2013] I am not sure why one would use fix in this example [Thu Jun 27 11:02:10 2013] however, there are situations where the proof will be much easier with the fix tactic [Thu Jun 27 11:02:10 2013] however, there are situations where the proof will be much easier with the fix tactic [Thu Jun 27 11:14:32 2013] http://hpaste.org/90512 here is an example in which I do not see a way to proceed with induction. fix, however, enables us to apply the recursive function even after 2x destruct [Thu Jun 27 11:14:32 2013] http://hpaste.org/90512 here is an example in which I do not see a way to proceed with induction. fix, however, enables us to apply the recursive function even after 2x destruct [Thu Jun 27 11:46:12 2013] Eruquen: I got disconencted, just wnated to say thanks for the descriptions / code snipplets. [Thu Jun 27 11:46:12 2013] Eruquen: I got disconencted, just wnated to say thanks for the descriptions / code snipplets. [Thu Jun 27 11:46:23 2013] no problem :) [Thu Jun 27 11:46:23 2013] no problem :) [Thu Jun 27 12:33:15 2013] Eruquen: I have another dumb question. In http://hpaste.org/90520 [Thu Jun 27 12:33:15 2013] Eruquen: I have another dumb question. In http://hpaste.org/90520 [Thu Jun 27 12:33:25 2013] do you know where the "l" comes from? (in the goal state) [Thu Jun 27 12:33:25 2013] do you know where the "l" comes from? (in the goal state) [Thu Jun 27 12:33:31 2013] in particular, the "match lst as l ... " [Thu Jun 27 12:33:31 2013] in particular, the "match lst as l ... " [Thu Jun 27 12:34:01 2013] line 36: match lst as l return (0 <= i < Z.of_nat (length l) -> nat) with [Thu Jun 27 12:34:01 2013] line 36: match lst as l return (0 <= i < Z.of_nat (length l) -> nat) with [Thu Jun 27 12:34:47 2013] I'll have a look at it [Thu Jun 27 12:34:47 2013] I'll have a look at it [Thu Jun 27 12:35:25 2013] actually, it looks to me like a new varaible introduced on the fly [Thu Jun 27 12:35:25 2013] actually, it looks to me like a new varaible introduced on the fly [Thu Jun 27 12:35:26 2013] have you read about dependent matches [Thu Jun 27 12:35:26 2013] have you read about dependent matches [Thu Jun 27 12:35:39 2013] ? [Thu Jun 27 12:35:39 2013] ? [Thu Jun 27 12:35:47 2013] this sounds like something mentioned in Chlipala's CPDT, but went over my head when I tried to read it 3 months ago [Thu Jun 27 12:35:47 2013] this sounds like something mentioned in Chlipala's CPDT, but went over my head when I tried to read it 3 months ago [Thu Jun 27 12:36:02 2013] so, no, I don't know what they are [Thu Jun 27 12:36:02 2013] so, no, I don't know what they are [Thu Jun 27 12:36:13 2013] I can't cite their definition, and I don't know what properties / quirks they have. [Thu Jun 27 12:36:13 2013] I can't cite their definition, and I don't know what properties / quirks they have. [Thu Jun 27 12:36:14 2013] basically, you want to destruct a variable and return different things in every case [Thu Jun 27 12:36:14 2013] basically, you want to destruct a variable and return different things in every case [Thu Jun 27 12:36:32 2013] how is this different from a match? [Thu Jun 27 12:36:32 2013] how is this different from a match? [Thu Jun 27 12:36:39 2013] does "different things" mean "different Types" ? [Thu Jun 27 12:36:39 2013] does "different things" mean "different Types" ? [Thu Jun 27 12:36:43 2013] well, the return type may depend on the variable you match on [Thu Jun 27 12:36:43 2013] well, the return type may depend on the variable you match on [Thu Jun 27 12:36:46 2013] yup [Thu Jun 27 12:36:46 2013] yup [Thu Jun 27 12:37:13 2013] "dependent match" := "a match statement where different branches can return different _TYPES_" ? [Thu Jun 27 12:37:13 2013] "dependent match" := "a match statement where different branches can return different _TYPES_" ? [Thu Jun 27 12:37:37 2013] I am not sure how much more there is to it [Thu Jun 27 12:37:37 2013] I am not sure how much more there is to it [Thu Jun 27 12:37:46 2013] but you can do at least that [Thu Jun 27 12:37:46 2013] but you can do at least that [Thu Jun 27 12:38:41 2013] there are two different version afaik [Thu Jun 27 12:38:41 2013] there are two different version afaik [Thu Jun 27 12:39:10 2013] match x as y return .., and match x in y return .. [Thu Jun 27 12:39:10 2013] match x as y return .., and match x in y return .. [Thu Jun 27 12:39:35 2013] I will have to look it up so that I don't say any nonsense [Thu Jun 27 12:39:35 2013] I will have to look it up so that I don't say any nonsense [Thu Jun 27 12:40:52 2013] the second version allows you to use the parameters of the type of x in the return statement [Thu Jun 27 12:40:52 2013] the second version allows you to use the parameters of the type of x in the return statement [Thu Jun 27 12:41:52 2013] with the first one, the type can only depend on the value of x [Thu Jun 27 12:41:52 2013] with the first one, the type can only depend on the value of x [Thu Jun 27 12:44:16 2013] Eruquen: are you reading CPDT or the Coq reference manual> [Thu Jun 27 12:44:16 2013] Eruquen: are you reading CPDT or the Coq reference manual> [Thu Jun 27 12:44:17 2013] ? [Thu Jun 27 12:44:17 2013] ? [Thu Jun 27 12:44:26 2013] coq reference manual [Thu Jun 27 12:44:26 2013] coq reference manual [Thu Jun 27 12:44:33 2013] http://coq.inria.fr/V8.1/refman/Reference-Manual018.html [Thu Jun 27 12:44:33 2013] http://coq.inria.fr/V8.1/refman/Reference-Manual018.html [Thu Jun 27 12:45:26 2013] I might be slightly of in the sense that both versions can actually be used in the same match [Thu Jun 27 12:45:26 2013] I might be slightly of in the sense that both versions can actually be used in the same match [Thu Jun 27 12:45:29 2013] *off [Thu Jun 27 12:45:29 2013] *off [Thu Jun 27 12:45:43 2013] 15.3.2 introduces the general syntax with both "as" and "in" [Thu Jun 27 12:45:43 2013] 15.3.2 introduces the general syntax with both "as" and "in" [Thu Jun 27 12:46:43 2013] the most mind-blowing thing for me was the dependent match equivalent to the rewrite tactic [Thu Jun 27 12:46:43 2013] the most mind-blowing thing for me was the dependent match equivalent to the rewrite tactic [Thu Jun 27 12:46:58 2013] I will see if I can reconstruct it [Thu Jun 27 12:46:58 2013] I will see if I can reconstruct it [Thu Jun 27 12:53:43 2013] Definition eq_sym' {X: Type} {x y: X}: x = y -> y = x :=fun (H: x = y) => match H in eq _ z return eq z x with eq_refl => eq_refl end. [Thu Jun 27 12:53:43 2013] Definition eq_sym' {X: Type} {x y: X}: x = y -> y = x :=fun (H: x = y) => match H in eq _ z return eq z x with eq_refl => eq_refl end. [Thu Jun 27 12:54:05 2013] usually one would use "intros H. rewrite H. reflexivity." to proof this [Thu Jun 27 12:54:05 2013] usually one would use "intros H. rewrite H. reflexivity." to proof this [Thu Jun 27 12:55:31 2013] yea, intros H gets "H: x = y" [Thu Jun 27 12:55:31 2013] yea, intros H gets "H: x = y" [Thu Jun 27 12:55:38 2013] rewrite H changes the goal to "y = y" [Thu Jun 27 12:55:38 2013] rewrite H changes the goal to "y = y" [Thu Jun 27 12:55:41 2013] and reflexivitity solves it. [Thu Jun 27 12:55:41 2013] and reflexivitity solves it. [Thu Jun 27 12:55:44 2013] yup [Thu Jun 27 12:55:44 2013] yup [Thu Jun 27 12:55:55 2013] reflexivity is the same as "exact eq_refl" [Thu Jun 27 12:55:55 2013] reflexivity is the same as "exact eq_refl" [Thu Jun 27 12:56:00 2013] (more or less) [Thu Jun 27 12:56:00 2013] (more or less) [Thu Jun 27 12:57:49 2013] Eruquen: are you familiar with subset types by any chance? [Thu Jun 27 12:57:49 2013] Eruquen: are you familiar with subset types by any chance? [Thu Jun 27 12:57:51 2013] I have http://hpaste.org/90521 [Thu Jun 27 12:57:51 2013] I have http://hpaste.org/90521 [Thu Jun 27 12:57:57 2013] and I want to do something similar to 'exists (i-1)' [Thu Jun 27 12:57:57 2013] and I want to do something similar to 'exists (i-1)' [Thu Jun 27 12:58:08 2013] I understand why it doesnt work (I don't have a proof taht it satisfies the subset type) [Thu Jun 27 12:58:08 2013] I understand why it doesnt work (I don't have a proof taht it satisfies the subset type) [Thu Jun 27 12:58:18 2013] but I'm wondering if there's seomthing similar to "apply exists i-1" [Thu Jun 27 12:58:18 2013] but I'm wondering if there's seomthing similar to "apply exists i-1" [Thu Jun 27 12:58:28 2013] where it accepts i-1, then generates new goal requiring me to prove that i-1 satisfies the conditions [Thu Jun 27 12:58:28 2013] where it accepts i-1, then generates new goal requiring me to prove that i-1 satisfies the conditions [Thu Jun 27 12:59:36 2013] there is always "exists (i-1)" [Thu Jun 27 12:59:36 2013] there is always "exists (i-1)" [Thu Jun 27 13:00:41 2013] i'm a dumbass, not sure why it didn't work last time [Thu Jun 27 13:00:41 2013] i'm a dumbass, not sure why it didn't work last time [Thu Jun 27 13:00:46 2013] I think I typed "exact (i-1)"\ [Thu Jun 27 13:00:46 2013] I think I typed "exact (i-1)"\ [Thu Jun 27 13:01:49 2013] well, I'm off to watch a movie [Thu Jun 27 13:01:49 2013] well, I'm off to watch a movie [Thu Jun 27 13:02:58 2013] thanks for all your help [Thu Jun 27 13:02:58 2013] thanks for all your help [Thu Jun 27 13:13:22 2013] In https://gist.github.com/anonymous/1ac368a2dfc0e0788134 -- I have proved all my goals, but I can't execute "Defined." Anyone know what I'm doing wrong? [Thu Jun 27 13:13:22 2013] In https://gist.github.com/anonymous/1ac368a2dfc0e0788134 -- I have proved all my goals, but I can't execute "Defined." Anyone know what I'm doing wrong? [Thu Jun 27 13:13:29 2013] Eruquen: in case you're still around, please see above [Thu Jun 27 13:13:29 2013] Eruquen: in case you're still around, please see above [Thu Jun 27 13:13:42 2013] What error do you get? [Thu Jun 27 13:13:42 2013] What error do you get? [Thu Jun 27 13:14:08 2013] no error at atll [Thu Jun 27 13:14:08 2013] no error at atll [Thu Jun 27 13:14:12 2013] which makes it hard to Google [Thu Jun 27 13:14:12 2013] which makes it hard to Google [Thu Jun 27 13:14:26 2013] Probably due to fix. It is dangerous, and you need to be careful what you do after having used it. [Thu Jun 27 13:14:26 2013] Probably due to fix. It is dangerous, and you need to be careful what you do after having used it. [Thu Jun 27 13:14:36 2013] how can I prove this without using fix ? [Thu Jun 27 13:14:36 2013] how can I prove this without using fix ? [Thu Jun 27 13:14:49 2013] oh, induction lst [Thu Jun 27 13:14:49 2013] oh, induction lst [Thu Jun 27 13:14:50 2013] let me try that [Thu Jun 27 13:14:50 2013] let me try that [Thu Jun 27 13:15:44 2013] okay, fixed [Thu Jun 27 13:15:44 2013] okay, fixed [Thu Jun 27 13:15:49 2013] noted: "don't use fix" [Thu Jun 27 13:15:49 2013] noted: "don't use fix" [Thu Jun 27 13:38:45 2013] http://hpaste.org/90523 [Thu Jun 27 13:38:45 2013] http://hpaste.org/90523 [Thu Jun 27 13:39:03 2013] now, this code isn't exactly waht I wanted to prove [Thu Jun 27 13:39:03 2013] now, this code isn't exactly waht I wanted to prove [Thu Jun 27 13:39:21 2013] what I really want to prove is to say: if $z is of type rangeT a2 b2, then $z$ is also of type rangeT a1 b1 [Thu Jun 27 13:39:21 2013] what I really want to prove is to say: if $z is of type rangeT a2 b2, then $z$ is also of type rangeT a1 b1 [Thu Jun 27 13:39:32 2013] instead, I'm saying: give a rangeT a2 b2, I can construct a rangeT a1 b1 [Thu Jun 27 13:39:32 2013] instead, I'm saying: give a rangeT a2 b2, I can construct a rangeT a1 b1 [Thu Jun 27 13:39:51 2013] things only have one type [Thu Jun 27 13:39:51 2013] things only have one type [Thu Jun 27 13:40:07 2013] perhaps you mean to say that given a rangeT a2 b2, there is a rangeT a1 b1 with the same "z" [Thu Jun 27 13:40:07 2013] perhaps you mean to say that given a rangeT a2 b2, there is a rangeT a1 b1 with the same "z" [Thu Jun 27 13:41:14 2013] elliott: so I'm writing a proofs, and at some point, I have (z: rangeT a2 b2) ... but then somewhere else, I need to plug in the z, but it has to be a (rangeT a1 b1) [Thu Jun 27 13:41:14 2013] elliott: so I'm writing a proofs, and at some point, I have (z: rangeT a2 b2) ... but then somewhere else, I need to plug in the z, but it has to be a (rangeT a1 b1) [Thu Jun 27 13:41:26 2013] yeah, there's a ranteT a1 b1 with the same 'z" [Thu Jun 27 13:41:26 2013] yeah, there's a ranteT a1 b1 with the same 'z" [Thu Jun 27 13:41:28 2013] how do I say that? [Thu Jun 27 13:41:28 2013] how do I say that? [Thu Jun 27 13:42:06 2013] proj1_sig (lem_000 p q r) = proj1_sig r or such [Thu Jun 27 13:42:06 2013] proj1_sig (lem_000 p q r) = proj1_sig r or such [Thu Jun 27 13:42:10 2013] proj1 z1 = proj1 ... ah [Thu Jun 27 13:42:10 2013] proj1 z1 = proj1 ... ah [Thu Jun 27 13:49:27 2013] elliott: https://gist.github.com/anonymous/5878677 [Thu Jun 27 13:49:27 2013] elliott: https://gist.github.com/anonymous/5878677 [Thu Jun 27 13:49:34 2013] should I force my way through this, or am I being a dumbass [Thu Jun 27 13:49:34 2013] should I force my way through this, or am I being a dumbass [Thu Jun 27 13:54:40 2013] heh, yikes [Thu Jun 27 13:54:40 2013] heh, yikes [Thu Jun 27 13:54:54 2013] try destructing z first [Thu Jun 27 13:54:54 2013] try destructing z first [Thu Jun 27 13:54:57 2013] then simpl instead of any unfolding [Thu Jun 27 13:54:57 2013] then simpl instead of any unfolding [Thu Jun 27 13:55:05 2013] should get the proof terms out of the way [Thu Jun 27 13:55:05 2013] should get the proof terms out of the way [Thu Jun 27 13:55:17 2013] yow! [Thu Jun 27 13:55:17 2013] yow! [Thu Jun 27 13:57:15 2013] was disconnected [Thu Jun 27 13:57:15 2013] was disconnected [Fri Jun 28 12:43:14 2013] does it ever make sense to have a Coq Inductive with only one constructor? [Fri Jun 28 12:43:14 2013] does it ever make sense to have a Coq Inductive with only one constructor? [Fri Jun 28 12:43:28 2013] Inductive Foo := makeFoo ... ? [Fri Jun 28 12:43:28 2013] Inductive Foo := makeFoo ... ? [Fri Jun 28 12:45:29 2013] well, unit is defined that way :P [Fri Jun 28 12:45:29 2013] well, unit is defined that way :P [Fri Jun 28 12:46:56 2013] hmm :-) [Fri Jun 28 12:46:56 2013] hmm :-) [Fri Jun 28 12:47:05 2013] elliott: are you familiar with subset types? [Fri Jun 28 12:47:05 2013] elliott: are you familiar with subset types? [Fri Jun 28 12:47:14 2013] I'm looking at chatper 6 of CPDT [Fri Jun 28 12:47:14 2013] I'm looking at chatper 6 of CPDT [Fri Jun 28 12:47:22 2013] and I'm completely confused on how I'm supposed to be using them [Fri Jun 28 12:47:22 2013] and I'm completely confused on how I'm supposed to be using them [Fri Jun 28 12:47:35 2013] as in regular old sig {x:A | ...} things? [Fri Jun 28 12:47:35 2013] as in regular old sig {x:A | ...} things? [Fri Jun 28 12:47:36 2013] (the above question comes from trying to define "validIndex" with respect ato a list) [Fri Jun 28 12:47:36 2013] (the above question comes from trying to define "validIndex" with respect ato a list) [Fri Jun 28 12:47:46 2013] elliott: as in how to use them in practice, [Fri Jun 28 12:47:46 2013] elliott: as in how to use them in practice, [Fri Jun 28 12:48:02 2013] well, you can think of it just like a fancy tuple [Fri Jun 28 12:48:02 2013] well, you can think of it just like a fancy tuple [Fri Jun 28 12:48:06 2013] where one element is a proof relating to the other [Fri Jun 28 12:48:06 2013] where one element is a proof relating to the other [Fri Jun 28 12:48:46 2013] so it's like a (i: Z) * (H: 0 <= i < Zlength (lst)) ? [Fri Jun 28 12:48:46 2013] so it's like a (i: Z) * (H: 0 <= i < Zlength (lst)) ? [Fri Jun 28 12:49:25 2013] right [Fri Jun 28 12:49:25 2013] right [Fri Jun 28 12:49:35 2013] just one half has to be in Prop [Fri Jun 28 12:49:35 2013] just one half has to be in Prop [Fri Jun 28 12:50:07 2013] (there's sigT, {x:A & ...} for when you want a dependent tuple with all non-Prop elements) [Fri Jun 28 12:50:07 2013] (there's sigT, {x:A & ...} for when you want a dependent tuple with all non-Prop elements) [Fri Jun 28 15:12:08 2013] hi [Fri Jun 28 15:12:08 2013] hi [Fri Jun 28 18:19:28 2013] http://hpaste.org/90588 <-- why does this not ocmpile in Coq? [Fri Jun 28 18:19:28 2013] http://hpaste.org/90588 <-- why does this not ocmpile in Coq? [Fri Jun 28 18:26:57 2013] resolved it [Fri Jun 28 18:26:57 2013] resolved it [Fri Jun 28 18:27:00 2013] Is it possible to prove that the CiC, with the universe hierarchy is cut off at some finite level, is consistent, and is it possible to formalize this proof inside of Coq? [Fri Jun 28 18:27:00 2013] Is it possible to prove that the CiC, with the universe hierarchy is cut off at some finite level, is consistent, and is it possible to formalize this proof inside of Coq? [Fri Jun 28 19:44:48 2013] how is Z / positive defined in Coq, and why is it so com[licated? [Fri Jun 28 19:44:48 2013] how is Z / positive defined in Coq, and why is it so com[licated? [Fri Jun 28 19:45:19 2013] this is what "Print positive" looks like: [Fri Jun 28 19:45:19 2013] this is what "Print positive" looks like: [Fri Jun 28 19:45:19 2013] Warning: query commands should not be inserted in scripts Inductive positive : Set := xI : positive -> positive | xO : positive -> positive | xH : positive For xI: Argument scope is [positive_scope] For xO: Argument scope is [positive_scope] [Fri Jun 28 19:45:19 2013] Warning: query commands should not be inserted in scripts Inductive positive : Set := xI : positive -> positive | xO : positive -> positive | xH : positive For xI: Argument scope is [positive_scope] For xO: Argument scope is [positive_scope] [Fri Jun 28 19:45:27 2013] why do we have xI, xO, and xH ? [Fri Jun 28 19:45:27 2013] why do we have xI, xO, and xH ? [Fri Jun 28 19:45:37 2013] why not just n > 0 ? [Fri Jun 28 19:45:37 2013] why not just n > 0 ? [Fri Jun 28 20:00:58 2013] what does the ~ mean in https://gist.github.com/anonymous/54a5b056a5411372012e ? [Fri Jun 28 20:00:58 2013] what does the ~ mean in https://gist.github.com/anonymous/54a5b056a5411372012e ? [Fri Jun 28 20:22:43 2013] xH [Fri Jun 28 20:22:43 2013] xH [Fri Jun 28 20:22:45 2013] and xO apparently [Fri Jun 28 20:22:45 2013] and xO apparently [Fri Jun 28 20:22:47 2013] figured it out :-) [Fri Jun 28 20:22:47 2013] figured it out :-) [Fri Jun 28 23:15:48 2013] is the "extract" function written in OCaml or Gallina ? [Fri Jun 28 23:15:48 2013] is the "extract" function written in OCaml or Gallina ? [Fri Jun 28 23:15:54 2013] I'd like to add a new backend for Coq extract. [Fri Jun 28 23:15:54 2013] I'd like to add a new backend for Coq extract. [Sat Jun 29 13:43:25 2013] hi [Sat Jun 29 13:43:25 2013] hi [Sat Jun 29 15:43:22 2013] Y'know, what would be useful for my silly category theory stuff is the ability to import a single library more than once. [Sat Jun 29 15:43:22 2013] Y'know, what would be useful for my silly category theory stuff is the ability to import a single library more than once. [Sat Jun 29 15:44:06 2013] If I wanted to talk about the category of categories, I could import the library that defines categories twice, and talk about the category-from-one-library of categories-from-the-other-library. [Sat Jun 29 15:44:06 2013] If I wanted to talk about the category of categories, I could import the library that defines categories twice, and talk about the category-from-one-library of categories-from-the-other-library. [Sat Jun 29 17:07:28 2013] maybe you need universe polymorphism for that? [Sat Jun 29 17:07:28 2013] maybe you need universe polymorphism for that? [Sat Jun 29 17:58:24 2013] Hey guys, I'm trying to understand what happens internally when you run 'destruct x' where x is present in other hypothesis [Sat Jun 29 17:58:24 2013] Hey guys, I'm trying to understand what happens internally when you run 'destruct x' where x is present in other hypothesis [Sat Jun 29 17:59:06 2013] how does Coq arranging for everything to get refined in the proof terms? [Sat Jun 29 17:59:06 2013] how does Coq arranging for everything to get refined in the proof terms? [Sat Jun 29 18:19:09 2013] tswett: (1) What category theory stuff are you working on? I'm mainly asking because I have my own category theory library that I'm working on at https://bitbucket.org/JasonGross/catdb. [Sat Jun 29 18:19:09 2013] tswett: (2) You can try using records and sticking the type of objects in the arguments to the record to get partial universe polymorphism in coq 8.4; or, you can try using HoTT/coq (available on github) to get much better universe polymorphism. [Sat Jun 29 18:19:09 2013] tswett: (1) What category theory stuff are you working on? I'm mainly asking because I have my own category theory library that I'm working on at https://bitbucket.org/JasonGross/catdb. [Sat Jun 29 18:19:09 2013] tswett: (2) You can try using records and sticking the type of objects in the arguments to the record to get partial universe polymorphism in coq 8.4; or, you can try using HoTT/coq (available on github) to get much better universe polymorphism. [Sat Jun 29 18:20:25 2013] ezyang: Are you asking (1) how is destruct implemented in ocaml, and how could I fake it for a particular inductive type using only, e.g., refine? or (2) what does the resulting proof term look like so that things are well typed? (or something else?) [Sat Jun 29 18:20:25 2013] ezyang: Are you asking (1) how is destruct implemented in ocaml, and how could I fake it for a particular inductive type using only, e.g., refine? or (2) what does the resulting proof term look like so that things are well typed? (or something else?) [Sat Jun 29 18:25:02 2013] (2) I think [Sat Jun 29 18:25:02 2013] (2) I think [Sat Jun 29 18:56:20 2013] ezyang: You can [Print] and [Show Proof] to see what it does. The basic idea is that it reverts all of the relevant hypotheses before destructing, and then introduces them all again afterwards. So if you are destructing [H : x = y] and you have a hypothesis [z : P y], then the resulting proof term will be something like [match H in _ = y' return P y' -> with eq_refl => (fun z : P x => _) end z]. [Sat Jun 29 18:56:20 2013] ezyang: You can [Print] and [Show Proof] to see what it does. The basic idea is that it reverts all of the relevant hypotheses before destructing, and then introduces them all again afterwards. So if you are destructing [H : x = y] and you have a hypothesis [z : P y], then the resulting proof term will be something like [match H in _ = y' return P y' -> with eq_refl => (fun z : P x => _) end z]. [Sat Jun 29 18:57:49 2013] eugh [Sat Jun 29 18:57:49 2013] eugh [Sat Jun 29 18:58:21 2013] actually, I'm not sure that it needs to do that kind of fancy stuff for simple things; the kernel logic might be advanced enough to just make all of the hypotheses look different inside of the match. But that's the most general form, and that's what it does when your types are sufficiently dependent. [Sat Jun 29 18:58:21 2013] actually, I'm not sure that it needs to do that kind of fancy stuff for simple things; the kernel logic might be advanced enough to just make all of the hypotheses look different inside of the match. But that's the most general form, and that's what it does when your types are sufficiently dependent. [Sat Jun 29 19:04:02 2013] ezyang: [Sat Jun 29 19:04:02 2013] Goal forall T (x y : T) (P : T -> Type) (H : x = y) (z : P y), True. [Sat Jun 29 19:04:02 2013] intros. [Sat Jun 29 19:04:03 2013] ezyang: [Sat Jun 29 19:04:02 2013] destruct H. [Sat Jun 29 19:04:02 2013] Show Proof. [Sat Jun 29 19:04:02 2013] (* (fun (T : Type) (x y : T) (P : T -> Type) (H : x = y) (z : P y) => [Sat Jun 29 19:04:03 2013] Goal forall T (x y : T) (P : T -> Type) (H : x = y) (z : P y), True. [Sat Jun 29 19:04:02 2013] match H in (_ = y0) return (P y0 -> True) with [Sat Jun 29 19:04:02 2013] | eq_refl => fun z0 : P x => ?504 [Sat Jun 29 19:04:03 2013] intros. [Sat Jun 29 19:04:03 2013] destruct H. [Sat Jun 29 19:04:02 2013] end z) *) [Sat Jun 29 19:04:03 2013] Show Proof. [Sat Jun 29 19:04:03 2013] (* (fun (T : Type) (x y : T) (P : T -> Type) (H : x = y) (z : P y) => [Sat Jun 29 19:04:03 2013] match H in (_ = y0) return (P y0 -> True) with [Sat Jun 29 19:04:04 2013] | eq_refl => fun z0 : P x => ?504 [Sat Jun 29 19:04:04 2013] end z) *) [Sat Jun 29 19:24:20 2013] OK, let's see, maybe I can get more concrete here. [Sat Jun 29 19:24:20 2013] OK, let's see, maybe I can get more concrete here. [Sat Jun 29 19:24:38 2013] Essentially, I have a simple example which I think shouldn't need this encoding tick [Sat Jun 29 19:24:38 2013] Essentially, I have a simple example which I think shouldn't need this encoding tick [Sat Jun 29 19:25:31 2013] Ugh, this is a little complicated because I'm using the HoTT base library/Coq version [Sat Jun 29 19:25:31 2013] Ugh, this is a little complicated because I'm using the HoTT base library/Coq version [Sat Jun 29 19:27:00 2013] Do you have a copy of one of those handy? :) [Sat Jun 29 19:27:00 2013] Do you have a copy of one of those handy? :) [Sat Jun 29 19:32:25 2013] OK, here is the translated example for normal Coq http://pastebin.com/u3udaTDu [Sat Jun 29 19:32:25 2013] OK, here is the translated example for normal Coq http://pastebin.com/u3udaTDu [Sat Jun 29 19:32:41 2013] What I would like to do is run this proof, /without/ calling the 'destruct' tactic [Sat Jun 29 19:32:41 2013] What I would like to do is run this proof, /without/ calling the 'destruct' tactic [Sat Jun 29 19:33:08 2013] and in a way that results in a cleaner proof term than what htis spits out [Sat Jun 29 19:33:08 2013] and in a way that results in a cleaner proof term than what htis spits out [Sat Jun 29 20:02:20 2013] jgross_: well, so far, all I've done is defined categories and functors, and then proved that functors behave like arrows in a category. [Sat Jun 29 20:02:20 2013] jgross_: well, so far, all I've done is defined categories and functors, and then proved that functors behave like arrows in a category. [Sat Jun 29 20:02:40 2013] And I don't know where I want to go after that. [Sat Jun 29 20:02:40 2013] And I don't know where I want to go after that. [Sat Jun 29 20:02:41 2013] ezyang: Sorry, I disappeared for a bit; I'm working on speeding up my category theory library; it used to be ~10x slower with HoTT/coq than with Coq 8.4, now it's only ~2x slower. Anyway, here's a "cleaner" version of your proof: http://pastebin.com/czcTpVH8. I put quotes arount "cleaner" because my version is identical with yours, up to eta reduction, as you can see in the [Eval cbv ...] lines. [Sat Jun 29 20:02:41 2013] ezyang: Sorry, I disappeared for a bit; I'm working on speeding up my category theory library; it used to be ~10x slower with HoTT/coq than with Coq 8.4, now it's only ~2x slower. Anyway, here's a "cleaner" version of your proof: http://pastebin.com/czcTpVH8. I put quotes arount "cleaner" because my version is identical with yours, up to eta reduction, as you can see in the [Eval cbv ...] lines. [Sat Jun 29 20:04:57 2013] ah yes, when you eval it out, the lambda factors in, which helps a bit [Sat Jun 29 20:04:57 2013] ah yes, when you eval it out, the lambda factors in, which helps a bit [Sat Jun 29 20:05:29 2013] * notes that in the future, he can give jgross HoTT/coq code :) [Sat Jun 29 20:05:29 2013] * notes that in the future, he can give jgross HoTT/coq code :) [Sat Jun 29 20:06:21 2013] jgross_: so if I use HoTT/coq, will my definitions magically become universe-polymorphic? [Sat Jun 29 20:06:21 2013] jgross_: so if I use HoTT/coq, will my definitions magically become universe-polymorphic? [Sat Jun 29 20:07:49 2013] ezyang: Also, the only two differences (AFAIK) between coq trunk and HoTT/coq (other than that HoTT/coq doesn't get rebased against trunk very often, so is somewhat behind it) is that HoTT/coq has typical ambiguity/full universe polymorphism, and HoTT/coq has the private types extension, which lets you fake higher inductive types in an (IMO) ugly way, by simply disallowing the match construct on the HIT after you define the eliminator you want [Sat Jun 29 20:07:49 2013] to use. (I think a much prettier way would be to extend the match construct so that it requires you to send paths to paths, if such a thing can be done.) [Sat Jun 29 20:07:49 2013] ezyang: Also, the only two differences (AFAIK) between coq trunk and HoTT/coq (other than that HoTT/coq doesn't get rebased against trunk very often, so is somewhat behind it) is that HoTT/coq has typical ambiguity/full universe polymorphism, and HoTT/coq has the private types extension, which lets you fake higher inductive types in an (IMO) ugly way, by simply disallowing the match construct on the HIT after you define the eliminator you want [Sat Jun 29 20:07:50 2013] to use. (I think a much prettier way would be to extend the match construct so that it requires you to send paths to paths, if such a thing can be done.) [Sat Jun 29 20:09:11 2013] jgross: Well, in this case, the standard library differences are the big thing [Sat Jun 29 20:09:11 2013] jgross: Well, in this case, the standard library differences are the big thing [Sat Jun 29 20:09:18 2013] e.g. "Bool" or "bool" [Sat Jun 29 20:09:18 2013] e.g. "Bool" or "bool" [Sat Jun 29 20:09:32 2013] tswett: There is a [Polymorphic] flag (and [Monomorphic]) so that you can do [Polymorphic Definition ...] and [Polymorphic Record], etc. There is also [Set Universe Polymorphism.] and [Unset Universe Polymorphism.], which are like global [Polymorphic]/[Monomorphic] flags. [Sat Jun 29 20:09:32 2013] tswett: There is a [Polymorphic] flag (and [Monomorphic]) so that you can do [Polymorphic Definition ...] and [Polymorphic Record], etc. There is also [Set Universe Polymorphism.] and [Unset Universe Polymorphism.], which are like global [Polymorphic]/[Monomorphic] flags. [Sat Jun 29 20:09:43 2013] jgross_: *nod* Sounds pretty awesome. [Sat Jun 29 20:09:43 2013] jgross_: *nod* Sounds pretty awesome. [Sat Jun 29 20:09:59 2013] ezyang: Oh, you mean you're building on top of HoTT/HoTT, rather than just using HoTT/coq? [Sat Jun 29 20:09:59 2013] ezyang: Oh, you mean you're building on top of HoTT/HoTT, rather than just using HoTT/coq? [Sat Jun 29 20:10:17 2013] I'm working on mechanizing the HoTT/book exercises [Sat Jun 29 20:10:17 2013] I'm working on mechanizing the HoTT/book exercises [Sat Jun 29 20:10:24 2013] mostly for fun [Sat Jun 29 20:10:24 2013] mostly for fun [Sat Jun 29 20:10:28 2013] jgross_: do you know if an OS X version of this is already available? [Sat Jun 29 20:10:28 2013] jgross_: do you know if an OS X version of this is already available? [Sat Jun 29 20:10:40 2013] we should get someone to PPA HoTT/coq [Sat Jun 29 20:10:40 2013] we should get someone to PPA HoTT/coq [Sat Jun 29 20:10:48 2013] tswett: Yes, it is pretty sweet. Except for when it makes your code 10x slower. [Sat Jun 29 20:10:48 2013] tswett: Yes, it is pretty sweet. Except for when it makes your code 10x slower. [Sat Jun 29 20:10:55 2013] or make übercoq which is mtac+hott [Sat Jun 29 20:10:55 2013] or make übercoq which is mtac+hott [Sat Jun 29 20:12:18 2013] HoTT/coq is still very much developmental; see the 5-10 issues I still have open on the github, ranging from things like "Variables A B : Category" should be the same as "Variable A : Category. Variable B : Category." to more complicated problems. But you should be able to compile it yourself for OS X, if you have OCaml. [Sat Jun 29 20:12:18 2013] HoTT/coq is still very much developmental; see the 5-10 issues I still have open on the github, ranging from things like "Variables A B : Category" should be the same as "Variable A : Category. Variable B : Category." to more complicated problems. But you should be able to compile it yourself for OS X, if you have OCaml. [Sat Jun 29 20:15:38 2013] Compilation is proceeding smoothly so far. [Sat Jun 29 20:15:38 2013] Compilation is proceeding smoothly so far. [Sat Jun 29 20:16:19 2013] Hmm. It seems to me that it's a lot nicer dealing with dependent types in the tactic language than in the term language [Sat Jun 29 20:16:19 2013] Hmm. It seems to me that it's a lot nicer dealing with dependent types in the tactic language than in the term language [Sat Jun 29 20:16:32 2013] except that Coq has been adding heaps of heuristics on how to add in all of the annotations [Sat Jun 29 20:16:32 2013] except that Coq has been adding heaps of heuristics on how to add in all of the annotations [Sat Jun 29 20:17:12 2013] ezyang: I haven't tried mtac, but it looks promising. Have you tried it? (I think I want coq which is ssreflect+mtac+HoTT+higher inductive types via match+keywords for hSet and hProp and built-in match support for axiom K when you're matching on an hProp (a la http://coq.inria.fr/files/adt-2fev10-corbineau.pdf or similar). Oh, and also a computational version of univalence and some type of proof erasure support for hProps. But Bob Harper [Sat Jun 29 20:17:12 2013] tells me that erasing all hProps is like assuming that everything is strict, which it's not necessarily, so I'm still trying to figure out how to make the last one work .) [Sat Jun 29 20:17:12 2013] ezyang: I haven't tried mtac, but it looks promising. Have you tried it? (I think I want coq which is ssreflect+mtac+HoTT+higher inductive types via match+keywords for hSet and hProp and built-in match support for axiom K when you're matching on an hProp (a la http://coq.inria.fr/files/adt-2fev10-corbineau.pdf or similar). Oh, and also a computational version of univalence and some type of proof erasure support for hProps. But Bob Harper [Sat Jun 29 20:17:12 2013] tells me that erasing all hProps is like assuming that everything is strict, which it's not necessarily, so I'm still trying to figure out how to make the last one work .) [Sat Jun 29 20:17:39 2013] hahaha [Sat Jun 29 20:17:39 2013] hahaha [Sat Jun 29 20:18:24 2013] That's like saying, "I'd like a Coq with a good chrome finish. And a fusion reactor." [Sat Jun 29 20:18:24 2013] That's like saying, "I'd like a Coq with a good chrome finish. And a fusion reactor." [Sat Jun 29 20:18:39 2013] Are people making progress on computational univalence? [Sat Jun 29 20:18:39 2013] Are people making progress on computational univalence? [Sat Jun 29 20:19:27 2013] I wonder if erasure is related to truncation [Sat Jun 29 20:19:27 2013] I wonder if erasure is related to truncation [Sat Jun 29 20:22:28 2013] LOL this quote "With a (non-Adamized) Coq tactic proof I can at least step through it and see what each piece does." [Sat Jun 29 20:22:28 2013] LOL this quote "With a (non-Adamized) Coq tactic proof I can at least step through it and see what each piece does." [Sat Jun 29 20:24:52 2013] "Adamized"? [Sat Jun 29 20:24:52 2013] "Adamized"? [Sat Jun 29 20:25:16 2013] The Adam Chlipala style of theorem proving [Sat Jun 29 20:25:16 2013] The Adam Chlipala style of theorem proving [Sat Jun 29 20:27:27 2013] ezyang: tactic support for dependent types is much, much nicer than term support. Except when you're like "destruct foo." and Coq is like "Error: ". Because then, if you know enough to do it yourself with match, the error messages you get won't be incomprehensible. ;-) But, yeah, there's been at least one time where I got so fed up with dependent matches that I write the matcher in Ltac and then wrote Ltac to [Sat Jun 29 20:27:27 2013] turn the Ltac into gallina. (This is in https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/LtacReifiedSimplification.v?at=default. The method is ReifiedMorphismSimplifyWithProof. The Ltac match is do_simplification. I know the Ltac to turn Ltac into gallina is horrible, but, trust me, the gallina match is worse.) [Sat Jun 29 20:27:27 2013] ezyang: tactic support for dependent types is much, much nicer than term support. Except when you're like "destruct foo." and Coq is like "Error: ". Because then, if you know enough to do it yourself with match, the error messages you get won't be incomprehensible. ;-) But, yeah, there's been at least one time where I got so fed up with dependent matches that I write the matcher in Ltac and then wrote Ltac to [Sat Jun 29 20:27:28 2013] turn the Ltac into gallina. (This is in https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/LtacReifiedSimplification.v?at=default. The method is ReifiedMorphismSimplifyWithProof. The Ltac match is do_simplification. I know the Ltac to turn Ltac into gallina is horrible, but, trust me, the gallina match is worse.) [Sat Jun 29 20:29:02 2013] ezyang: googling "univalence for free" gives a result which suggests (IIUC) some progress on computational univalence. [Sat Jun 29 20:29:02 2013] ezyang: googling "univalence for free" gives a result which suggests (IIUC) some progress on computational univalence. [Sat Jun 29 20:29:52 2013] ezyang: "I wonder if erasure is related to truncation" <- What do you mean? [Sat Jun 29 20:29:52 2013] ezyang: "I wonder if erasure is related to truncation" <- What do you mean? [Sat Jun 29 20:54:07 2013] Compilation is still proceeding smoothly. [Sat Jun 29 20:54:07 2013] Compilation is still proceeding smoothly. [Sat Jun 29 20:54:22 2013] I guess I kind of expected it to be faster than this. [Sat Jun 29 20:54:22 2013] I guess I kind of expected it to be faster than this. [Sat Jun 29 20:55:04 2013] I guess right now it's literally proving hundreds or thousands of the most important theorems in mathematics. [Sat Jun 29 20:55:04 2013] I guess right now it's literally proving hundreds or thousands of the most important theorems in mathematics. [Sat Jun 29 21:22:13 2013] Woo, finally installed. Now I can run it by running this short command: [Sat Jun 29 21:22:13 2013] Woo, finally installed. Now I can run it by running this short command: [Sat Jun 29 21:22:20 2013] /Users/tswett/Documents/Hobbies/Programming/OCaml/coq/bin/coqtop -coqlib /Users/tswett/Documents/Hobbies/Programming/OCaml/coq [Sat Jun 29 21:22:20 2013] /Users/tswett/Documents/Hobbies/Programming/OCaml/coq/bin/coqtop -coqlib /Users/tswett/Documents/Hobbies/Programming/OCaml/coq [Sat Jun 29 21:22:26 2013] Or by using the alias I just defined. [Sat Jun 29 21:22:26 2013] Or by using the alias I just defined. [Sat Jun 29 21:26:23 2013] hobbies is _under_ documents? :P [Sat Jun 29 21:26:23 2013] hobbies is _under_ documents? :P [Sat Jun 29 21:27:49 2013] Not all documents are hobbies, but all hobbies are documents... I guess. [Sat Jun 29 21:27:49 2013] Not all documents are hobbies, but all hobbies are documents... I guess. [Sat Jun 29 21:28:18 2013] Apparently I have an extremely boring life. [Sat Jun 29 21:28:18 2013] Apparently I have an extremely boring life. [Sun Jun 30 00:16:22 2013] How do you prove the cut rule for linear logic, which has ten connectives, given that the cut rule has three parameters? [Sun Jun 30 00:16:22 2013] How do you prove the cut rule for linear logic, which has ten connectives, given that the cut rule has three parameters? [Sun Jun 30 00:16:28 2013] Easy. Do induction on all three parameters. http://pastie.org/8096007 [Sun Jun 30 00:16:28 2013] Easy. Do induction on all three parameters. http://pastie.org/8096007 [Sun Jun 30 00:16:47 2013] "1000 subgoals" [Sun Jun 30 00:16:47 2013] "1000 subgoals" [Sun Jun 30 00:43:25 2013] you guys all know that there is a ##hott channel right? [Sun Jun 30 00:43:25 2013] you guys all know that there is a ##hott channel right? [Sun Jun 30 00:44:11 2013] I don't actually know what HoTT is. [Sun Jun 30 00:44:11 2013] I don't actually know what HoTT is. [Sun Jun 30 00:48:40 2013] homotopy type theory [Sun Jun 30 00:48:40 2013] homotopy type theory [Sun Jun 30 00:52:22 2013] I don't know what that is, either. [Sun Jun 30 00:52:22 2013] I don't know what that is, either. [Sun Jun 30 00:54:32 2013] http://en.wikipedia.org/wiki/Homotopy_type_theory [Sun Jun 30 00:54:32 2013] http://en.wikipedia.org/wiki/Homotopy_type_theory [Sun Jun 30 01:35:31 2013] I'm somewhat new to coq. I have a recursive function (defined with Fixpoint) and I'm getting an error about types not matching, but I have a lemma which shows that what it expects and what it is given are the same type. Can I actually use this lemma to make it typecheck? [Sun Jun 30 01:35:31 2013] I'm somewhat new to coq. I have a recursive function (defined with Fixpoint) and I'm getting an error about types not matching, but I have a lemma which shows that what it expects and what it is given are the same type. Can I actually use this lemma to make it typecheck? [Sun Jun 30 01:35:59 2013] Pretty sure there's a way to make it work, yeah. [Sun Jun 30 01:35:59 2013] Pretty sure there's a way to make it work, yeah. [Sun Jun 30 01:36:43 2013] I don't know how it actually works, but I know that tactics can produce a function that makes it work. Lemme see here. [Sun Jun 30 01:36:43 2013] I don't know how it actually works, but I know that tactics can produce a function that makes it work. Lemme see here. [Sun Jun 30 01:38:09 2013] All right, here's what I did: http://pastie.org/8096148 [Sun Jun 30 01:38:09 2013] All right, here's what I did: http://pastie.org/8096148 [Sun Jun 30 01:40:36 2013] So it looks like you can use eq_rect (or eq_rec or eq_ind) in order to "convert" a value between two equal types. [Sun Jun 30 01:40:36 2013] So it looks like you can use eq_rect (or eq_rec or eq_ind) in order to "convert" a value between two equal types. [Sun Jun 30 01:43:12 2013] So what you want to do is, for some reason, this: eq_rect (old type) id (value of the old type) (new type) (proof that old type = new type) [Sun Jun 30 01:43:12 2013] So what you want to do is, for some reason, this: eq_rect (old type) id (value of the old type) (new type) (proof that old type = new type) [Sun Jun 30 01:43:22 2013] Replacing eq_rect with eq_rec or eq_ind if necessary. [Sun Jun 30 01:43:22 2013] Replacing eq_rect with eq_rec or eq_ind if necessary. [Sun Jun 30 01:43:30 2013] thanks [Sun Jun 30 01:43:30 2013] thanks [Sun Jun 30 01:43:44 2013] I guess that if a and b are Sets, you use eq_rec, and if they're Props, you use eq_ind. [Sun Jun 30 01:43:44 2013] I guess that if a and b are Sets, you use eq_rec, and if they're Props, you use eq_ind. [Sun Jun 30 01:43:50 2013] But yeah, you're welcome. [Sun Jun 30 01:43:50 2013] But yeah, you're welcome. [Sun Jun 30 03:27:02 2013] greenrd: No, I didn't. Thanks! [Sun Jun 30 03:27:02 2013] greenrd: No, I didn't. Thanks! [Sun Jun 30 23:17:47 2013] is there anything like (list Type -> Type) so if I had "[nat; nat]" it would be eg "(nat * nat)"? [Sun Jun 30 23:17:47 2013] is there anything like (list Type -> Type) so if I had "[nat; nat]" it would be eg "(nat * nat)"? [Sun Jun 30 23:18:27 2013] or should I just use fold_left .. (*) unit [Sun Jun 30 23:18:27 2013] or should I just use fold_left .. (*) unit [Sun Jun 30 23:47:02 2013] Yep, just fold'em [Sun Jun 30 23:47:02 2013] Yep, just fold'em [Mon Jul 1 01:02:53 2013] I'm conflicted between defining mutually recursive inductive types where one is equivalent to "list blah", or just writing a custom induction scheme [Mon Jul 1 01:02:53 2013] I'm conflicted between defining mutually recursive inductive types where one is equivalent to "list blah", or just writing a custom induction scheme [Mon Jul 1 01:02:57 2013] neither is particularly appealing [Mon Jul 1 01:02:57 2013] neither is particularly appealing [Mon Jul 1 01:04:05 2013] amosr: defined the induction scheme [Mon Jul 1 01:04:05 2013] amosr: defined the induction scheme [Mon Jul 1 01:04:14 2013] It's less painful that rewriting all of the standard list functions [Mon Jul 1 01:04:14 2013] It's less painful that rewriting all of the standard list functions [Mon Jul 1 01:04:42 2013] Otherwise you need different versions of get/insert/update/filter etc etc for every list-like data structure [Mon Jul 1 01:04:42 2013] Otherwise you need different versions of get/insert/update/filter etc etc for every list-like data structure [Mon Jul 1 01:05:22 2013] The Forall and Forall2 functions are also useful, but only work with standard lists [Mon Jul 1 01:05:22 2013] The Forall and Forall2 functions are also useful, but only work with standard lists [Mon Jul 1 01:07:22 2013] yeah, I just had to rewrite something from Forall2 to my own definition … annoying [Mon Jul 1 01:07:22 2013] yeah, I just had to rewrite something from Forall2 to my own definition … annoying [Mon Jul 1 01:07:43 2013] is there any technical reason that eg Scheme/Combine Scheme couldn't handle list as well? [Mon Jul 1 01:07:43 2013] is there any technical reason that eg Scheme/Combine Scheme couldn't handle list as well? [Mon Jul 1 01:15:11 2013] not that I know of [Mon Jul 1 01:15:11 2013] not that I know of [Mon Jul 1 02:24:36 2013] It might just be my inexperience with Coq, but I've noticed that the list library and others often chooses not to give inductive definitions of predicates, and those definitions seem to magically work out better for me when I try them. [Mon Jul 1 02:24:36 2013] It might just be my inexperience with Coq, but I've noticed that the list library and others often chooses not to give inductive definitions of predicates, and those definitions seem to magically work out better for me when I try them. [Mon Jul 1 02:25:00 2013] Like, using an inductive definition of list membership, for example [Mon Jul 1 02:25:00 2013] Like, using an inductive definition of list membership, for example [Mon Jul 1 02:25:25 2013] (which essentially looks like a fancy version of natural numbers) [Mon Jul 1 02:25:25 2013] (which essentially looks like a fancy version of natural numbers) [Mon Jul 1 02:37:08 2013] Cale: hmm, could you give a specific example? I don't really understand [Mon Jul 1 02:37:08 2013] Cale: hmm, could you give a specific example? I don't really understand [Mon Jul 1 02:43:26 2013] amosr: For instance, the List library defines a predicate In using a Fixpoint, while I'd usually prefer to have something like: http://paste.tryhaskell.org/90630 [Mon Jul 1 02:43:26 2013] amosr: For instance, the List library defines a predicate In using a Fixpoint, while I'd usually prefer to have something like: http://paste.tryhaskell.org/90630 [Mon Jul 1 02:43:57 2013] amosr: They're equivalent, but having constructors and being able to do induction on the structure of the proof seems handy. [Mon Jul 1 02:43:57 2013] amosr: They're equivalent, but having constructors and being able to do induction on the structure of the proof seems handy. [Mon Jul 1 02:45:55 2013] hmm, I imagine you'd want both? [Mon Jul 1 02:45:55 2013] hmm, I imagine you'd want both? [Mon Jul 1 02:46:20 2013] Maybe! [Mon Jul 1 02:46:20 2013] Maybe! [Mon Jul 1 02:46:31 2013] I haven't really had a need for the other one [Mon Jul 1 02:46:31 2013] I haven't really had a need for the other one [Mon Jul 1 02:48:32 2013] It's actually kind of funny. In is mainly the sore point there, Exists, Forall, Forall2, etc. are all inductive. [Mon Jul 1 02:48:32 2013] It's actually kind of funny. In is mainly the sore point there, Exists, Forall, Forall2, etc. are all inductive. [Mon Jul 1 02:49:53 2013] right, yes, inducting over the structure of a Forall2 is very useful [Mon Jul 1 02:49:53 2013] right, yes, inducting over the structure of a Forall2 is very useful [Mon Jul 1 16:55:56 2013] I think that inversion is not given the credit it deserves [Mon Jul 1 16:55:56 2013] I think that inversion is not given the credit it deserves [Mon Jul 1 16:57:32 2013] heh, what do you mean by that? [Mon Jul 1 16:57:32 2013] heh, what do you mean by that? [Mon Jul 1 17:30:35 2013] hi [Mon Jul 1 17:30:35 2013] hi [Mon Jul 1 17:31:35 2013] wmeyer hi !! [Mon Jul 1 17:31:35 2013] wmeyer hi !! [Mon Jul 1 17:32:04 2013] Cale the inversion tactic is very fundamental for people used to OCaml types [Mon Jul 1 17:32:04 2013] Cale the inversion tactic is very fundamental for people used to OCaml types [Mon Jul 1 17:33:31 2013] Anarchos: ho! [Mon Jul 1 17:33:31 2013] Anarchos: ho! [Mon Jul 1 17:34:23 2013] hi wmeyer [Mon Jul 1 17:34:23 2013] hi wmeyer [Tue Jul 2 21:24:24 2013] How do you ask Coq what a notation means? [Tue Jul 2 21:24:24 2013] How do you ask Coq what a notation means? [Tue Jul 2 21:24:38 2013] (there was a query but I can't remember what it is spelled and chapter 11 of the manual is not helping) [Tue Jul 2 21:25:07 2013] (there was a query but I can't remember what it is spelled and chapter 11 of the manual is not helping) [Tue Jul 2 23:04:22 2013] I want to show that language A and language B have some correspondence. I feel like using big step semantics would be easier than small step, but then I can't prove progress? (without implementing small step as well, and proving equivalence) [Tue Jul 2 23:04:22 2013] I want to show that language A and language B have some correspondence. I feel like using big step semantics would be easier than small step, but then I can't prove progress? (without implementing small step as well, and proving equivalence) [Tue Jul 2 23:05:59 2013] or I could just use small step and transitive closure, but my gut feeling is that'd make it harder to prove [Tue Jul 2 23:05:59 2013] or I could just use small step and transitive closure, but my gut feeling is that'd make it harder to prove [Tue Jul 2 23:07:03 2013] I've always found choosing the right representation for a proof, and showing the reps are equivalent, is the right way to do things. [Tue Jul 2 23:07:03 2013] I've always found choosing the right representation for a proof, and showing the reps are equivalent, is the right way to do things. [Tue Jul 2 23:08:43 2013] okay. I think I'll try with big step, then [Tue Jul 2 23:08:43 2013] okay. I think I'll try with big step, then [Wed Jul 3 00:16:58 2013] "try apply X; try apply Y; try apply Z" is there a better way to do this? [Wed Jul 3 00:16:58 2013] "try apply X; try apply Y; try apply Z" is there a better way to do this? [Wed Jul 3 01:53:14 2013] Well, if you can finish the proof, auto works great for this sort of thing [Wed Jul 3 01:53:14 2013] Well, if you can finish the proof, auto works great for this sort of thing [Wed Jul 3 02:12:17 2013] ezyang: Locate [Wed Jul 3 02:12:17 2013] ezyang: Locate [Wed Jul 3 02:13:28 2013] argh, why do I always try 'Search' :-( [Wed Jul 3 02:13:28 2013] argh, why do I always try 'Search' :-( [Wed Jul 3 02:15:58 2013] amosr: not necessarily equivalent, but there is first [apply X | apply Y | apply Z] [Wed Jul 3 02:15:58 2013] amosr: not necessarily equivalent, but there is first [apply X | apply Y | apply Z] [Wed Jul 3 02:16:23 2013] or solve [apply X | apply Y | apply Z] if you want to apply only when it kills the goal [Wed Jul 3 02:16:23 2013] or solve [apply X | apply Y | apply Z] if you want to apply only when it kills the goal [Wed Jul 3 02:17:44 2013] but if they're really meant to be applies on top of each other, as long as progress can be made, then I think you have to write it your way [Wed Jul 3 02:17:44 2013] but if they're really meant to be applies on top of each other, as long as progress can be made, then I think you have to write it your way [Wed Jul 3 02:17:51 2013] applied* [Wed Jul 3 02:17:51 2013] applied* [Wed Jul 3 02:19:06 2013] hmm.. perhaps I should look into how the hint databases work [Wed Jul 3 02:19:06 2013] hmm.. perhaps I should look into how the hint databases work [Wed Jul 3 02:20:27 2013] CPDT ca give you some ideas on how to pull these things together [Wed Jul 3 02:20:27 2013] CPDT ca give you some ideas on how to pull these things together [Wed Jul 3 02:20:58 2013] ah, I haven't really read CPDT. only snippets. maybe I'll have to go through it [Wed Jul 3 02:20:58 2013] ah, I haven't really read CPDT. only snippets. maybe I'll have to go through it [Wed Jul 3 09:09:38 2013] hi [Wed Jul 3 09:09:38 2013] hi [Wed Jul 3 09:10:14 2013] im proving this lemma, where both arguments are being converted to another format inside a comparison [Wed Jul 3 09:10:14 2013] im proving this lemma, where both arguments are being converted to another format inside a comparison [Wed Jul 3 09:10:49 2013] the conversion function is a bit complex when fully unfolded [Wed Jul 3 09:10:49 2013] the conversion function is a bit complex when fully unfolded [Wed Jul 3 09:11:10 2013] is there a way to work with the converted format and not have to delve into the conversion function itself? [Wed Jul 3 09:11:10 2013] is there a way to work with the converted format and not have to delve into the conversion function itself? [Wed Jul 3 09:30:01 2013] brb [Wed Jul 3 09:30:01 2013] brb [Wed Jul 3 10:14:14 2013] ezyang @ 21:25 yesterday: To find Notations, try something like [Locate "=".] [Wed Jul 3 10:14:15 2013] ezyang @ 21:25 yesterday: To find Notations, try something like [Locate "=".] [Wed Jul 3 10:23:57 2013] Oops, Ptival already said that. [Wed Jul 3 10:23:57 2013] Oops, Ptival already said that. [Wed Jul 3 13:08:10 2013] I'm reading the book "Certified Programming With Dependent Types" and one thing confuses me. At first it's said that by Curry-Howard correspondence, proofs == programs, but now it says "the key to telling what is a proof and what is a program is lies between distinction of Proof and Set types" (not exact sentence). now, are programs and proofs equal or not? [Wed Jul 3 13:08:10 2013] I'm reading the book "Certified Programming With Dependent Types" and one thing confuses me. At first it's said that by Curry-Howard correspondence, proofs == programs, but now it says "the key to telling what is a proof and what is a program is lies between distinction of Proof and Set types" (not exact sentence). now, are programs and proofs equal or not? [Wed Jul 3 13:10:08 2013] Yes. [Wed Jul 3 13:10:08 2013] Yes. [Wed Jul 3 13:11:29 2013] To be less facetious, the difference in the later is mostly one of intent. [Wed Jul 3 13:11:29 2013] To be less facetious, the difference in the later is mostly one of intent. [Wed Jul 3 13:11:54 2013] ah [Wed Jul 3 13:11:54 2013] ah [Wed Jul 3 13:12:10 2013] "Proof type"; do you mean the "Prop type"? [Wed Jul 3 13:12:10 2013] "Proof type"; do you mean the "Prop type"? [Wed Jul 3 13:12:19 2013] So, you can always interpret a program as a proof. [Wed Jul 3 13:12:19 2013] So, you can always interpret a program as a proof. [Wed Jul 3 13:12:26 2013] ezyang: yes, sorry [Wed Jul 3 13:12:26 2013] ezyang: yes, sorry [Wed Jul 3 13:13:23 2013] But, for example, considering + as proof, it means that if you have two proofs of 'nat', then you can construct another. Which, from a prrof point of view isn't very interesting. [Wed Jul 3 13:13:23 2013] But, for example, considering + as proof, it means that if you have two proofs of 'nat', then you can construct another. Which, from a prrof point of view isn't very interesting. [Wed Jul 3 13:13:35 2013] Well, there is an important difference between Prop and Set, regarding impredicativity [Wed Jul 3 13:13:35 2013] Well, there is an important difference between Prop and Set, regarding impredicativity [Wed Jul 3 13:13:51 2013] But I would not worry about it for now, and Adam does explain it a bit [Wed Jul 3 13:13:51 2013] But I would not worry about it for now, and Adam does explain it a bit [Wed Jul 3 13:14:25 2013] ok [Wed Jul 3 13:14:25 2013] ok [Wed Jul 3 13:17:52 2013] is 'tt' (the value of type unit) shorthand of something? [Wed Jul 3 13:17:52 2013] is 'tt' (the value of type unit) shorthand of something? [Wed Jul 3 13:19:25 2013] no [Wed Jul 3 13:19:25 2013] no [Wed Jul 3 13:19:26 2013] @print unit [Wed Jul 3 13:19:26 2013] @print unit [Wed Jul 3 13:19:53 2013] tomprince: where is roosterbot ;) [Wed Jul 3 13:19:53 2013] tomprince: where is roosterbot ;) [Wed Jul 3 13:20:02 2013] what does it stand for? [Wed Jul 3 13:20:02 2013] what does it stand for? [Wed Jul 3 13:30:05 2013] @print unit [Wed Jul 3 13:30:05 2013] @print unit [Wed Jul 3 13:30:06 2013] osa1: tt is the constructor of the unit type [Wed Jul 3 13:30:06 2013] osa1: tt is the constructor of the unit type [Wed Jul 3 13:30:08 2013] Inductive unit : Set := tt : unit [Wed Jul 3 13:30:08 2013] Inductive unit : Set := tt : unit [Wed Jul 3 13:30:11 2013] Inductive unit : Set := tt : () [Wed Jul 3 13:30:11 2013] Inductive unit : Set := tt : () [Wed Jul 3 13:30:58 2013] roosterbot: yes, my question was regarding the `tt` name, does that stand for anything? [Wed Jul 3 13:30:58 2013] roosterbot: yes, my question was regarding the `tt` name, does that stand for anything? [Wed Jul 3 13:31:07 2013] robbert: ^ [Wed Jul 3 13:31:07 2013] robbert: ^ [Wed Jul 3 13:32:27 2013] ah, no idea [Wed Jul 3 13:32:27 2013] ah, no idea [Wed Jul 3 13:50:27 2013] osa1: I would say it's t for "top" but doubled so that "t" isn't taken by the system libraries. [Wed Jul 3 13:50:27 2013] osa1: I would say it's t for "top" but doubled so that "t" isn't taken by the system libraries. [Wed Jul 3 15:23:11 2013] hello [Wed Jul 3 15:23:11 2013] hello [Wed Jul 3 15:27:34 2013] hi [Wed Jul 3 15:27:34 2013] hi [Wed Jul 3 16:05:39 2013] Are there any tactic libraries for temporal logic? [Wed Jul 3 16:05:39 2013] Are there any tactic libraries for temporal logic? [Wed Jul 3 16:08:32 2013] I've defined the semantics of various operators (forever, eventually, next, etc), but reasoning under them can't take advantage of things like tauto [Wed Jul 3 16:08:32 2013] I've defined the semantics of various operators (forever, eventually, next, etc), but reasoning under them can't take advantage of things like tauto [Wed Jul 3 16:26:33 2013] napping: Seeing as temporal logic is only useful on finite structures, I'm guessing no. [Wed Jul 3 16:26:33 2013] napping: Seeing as temporal logic is only useful on finite structures, I'm guessing no. [Wed Jul 3 16:27:18 2013] For the rest of us, we just use path constructions, quantifiers and a reduction relation. [Wed Jul 3 16:27:18 2013] For the rest of us, we just use path constructions, quantifiers and a reduction relation. [Wed Jul 3 16:27:20 2013] I'm actually working on potentially infinite structures, what's the problem? [Wed Jul 3 16:27:20 2013] I'm actually working on potentially infinite structures, what's the problem? [Wed Jul 3 16:28:18 2013] I'm building things on paths and a reachability relation also, but there are tons of constructions like forall state1, Path state0 state1 -> ?P state1 [Wed Jul 3 16:28:18 2013] I'm building things on paths and a reachability relation also, but there are tons of constructions like forall state1, Path state0 state1 -> ?P state1 [Wed Jul 3 16:28:31 2013] napping: "Temporal logic" in full first-order (or higher) logic does not add expressivity. There are specific modalities that you can express just with quantifiers and the reduction relation. [Wed Jul 3 16:28:31 2013] napping: "Temporal logic" in full first-order (or higher) logic does not add expressivity. There are specific modalities that you can express just with quantifiers and the reduction relation. [Wed Jul 3 16:29:12 2013] I'm not trying to add expressivity, but to take advantage of restrictions to impose tractability [Wed Jul 3 16:29:12 2013] I'm not trying to add expressivity, but to take advantage of restrictions to impose tractability [Wed Jul 3 16:29:28 2013] firstorder can handle simple cases, but explodes as formulas grows [Wed Jul 3 16:29:28 2013] firstorder can handle simple cases, but explodes as formulas grows [Wed Jul 3 16:30:17 2013] So you want to prove certain identities on temporal logic formulae to help reduce goals? [Wed Jul 3 16:30:17 2013] So you want to prove certain identities on temporal logic formulae to help reduce goals? [Wed Jul 3 16:30:39 2013] there are tons of little lemmas like forall P Q x, always (fun x' => P x' -> Q x') x -> eventually P x -> eventually Q x [Wed Jul 3 16:30:39 2013] there are tons of little lemmas like forall P Q x, always (fun x' => P x' -> Q x') x -> eventually P x -> eventually Q x [Wed Jul 3 16:31:56 2013] pretty sure you'll have to prove those yourself. Preferably on a simple set + action structure. [Wed Jul 3 16:31:57 2013] pretty sure you'll have to prove those yourself. Preferably on a simple set + action structure. [Wed Jul 3 16:32:09 2013] ie reduction relation. [Wed Jul 3 16:32:09 2013] ie reduction relation. [Wed Jul 3 16:32:10 2013] I've proved some lemmas like that myself [Wed Jul 3 16:32:10 2013] I've proved some lemmas like that myself [Wed Jul 3 16:32:33 2013] it's applying those lemmas to help solve larger problems that seems fairly mechanical [Wed Jul 3 16:32:33 2013] it's applying those lemmas to help solve larger problems that seems fairly mechanical [Wed Jul 3 16:33:07 2013] The property you posed is not something one can state in propositional temporal logics (the ones that people use model-checkers for) [Wed Jul 3 16:33:07 2013] The property you posed is not something one can state in propositional temporal logics (the ones that people use model-checkers for) [Wed Jul 3 16:33:47 2013] that comes from the encoding of temporal formulas as (state -> Prop) [Wed Jul 3 16:33:47 2013] that comes from the encoding of temporal formulas as (state -> Prop) [Wed Jul 3 16:34:02 2013] without making that explicit it would be "[](P -> Q) -> <>P -> <>Q) [Wed Jul 3 16:34:02 2013] without making that explicit it would be "[](P -> Q) -> <>P -> <>Q) [Wed Jul 3 16:36:05 2013] Since you're working in the rich logic of Gallina, why not use nicer temporal semantics, like Cousot's mu-reverse calculus? [Wed Jul 3 16:36:05 2013] Since you're working in the rich logic of Gallina, why not use nicer temporal semantics, like Cousot's mu-reverse calculus? [Wed Jul 3 16:36:36 2013] the "option" type lets me return "Some _ | None" [Wed Jul 3 16:36:36 2013] the "option" type lets me return "Some _ | None" [Wed Jul 3 16:36:42 2013] is there a way to return "one of two values" ? [Wed Jul 3 16:36:42 2013] is there a way to return "one of two values" ? [Wed Jul 3 16:36:49 2013] i.e. "Left T1 | Right T2" ? [Wed Jul 3 16:36:49 2013] i.e. "Left T1 | Right T2" ? [Wed Jul 3 16:36:56 2013] i.e. when I return, I either return something of type T1 or something of type T2. [Wed Jul 3 16:36:56 2013] i.e. when I return, I either return something of type T1 or something of type T2. [Wed Jul 3 16:37:00 2013] I can define this inductively myself [Wed Jul 3 16:37:00 2013] I can define this inductively myself [Wed Jul 3 16:37:09 2013] but I feel like there is something like this in sthe standard library (but I can't thikn of its name) [Wed Jul 3 16:37:09 2013] but I feel like there is something like this in sthe standard library (but I can't thikn of its name) [Wed Jul 3 16:38:11 2013] +? [Wed Jul 3 16:38:11 2013] +? [Wed Jul 3 16:38:15 2013] ianjneu: I don't need a stronger logic, does it have nicer semantics? [Wed Jul 3 16:38:15 2013] ianjneu: I don't need a stronger logic, does it have nicer semantics? [Wed Jul 3 16:38:41 2013] or a proof system / better interaction with existing tactics [Wed Jul 3 16:38:41 2013] or a proof system / better interaction with existing tactics [Wed Jul 3 16:38:52 2013] napping: Indeed it does. It deals with traces as temporal logics /should/. [Wed Jul 3 16:38:52 2013] napping: Indeed it does. It deals with traces as temporal logics /should/. [Wed Jul 3 16:39:27 2013] hmm no proof system past the theorems proved in the temporal abstract interpretation paper. [Wed Jul 3 16:39:27 2013] hmm no proof system past the theorems proved in the temporal abstract interpretation paper. [Wed Jul 3 16:41:53 2013] inl: A B A -> A + B [Wed Jul 3 16:41:53 2013] inl: A B A -> A + B [Wed Jul 3 16:42:00 2013] what takes A+B to an A ? [Wed Jul 3 16:42:00 2013] what takes A+B to an A ? [Wed Jul 3 16:42:11 2013] Definition t = @inl nat String 20. [Wed Jul 3 16:42:11 2013] Definition t = @inl nat String 20. [Wed Jul 3 16:42:16 2013] how, how do I extract the "20" from t ? [Wed Jul 3 16:42:16 2013] how, how do I extract the "20" from t ? [Wed Jul 3 16:44:51 2013] thm_prover: do you know how to use Locate/Print/SearchAbout/etc ? [Wed Jul 3 16:44:51 2013] thm_prover: do you know how to use Locate/Print/SearchAbout/etc ? [Wed Jul 3 16:45:03 2013] napping SearchAbout / Print yes, [Wed Jul 3 16:45:03 2013] napping SearchAbout / Print yes, [Wed Jul 3 16:45:08 2013] Locate not so much, always get type errors back [Wed Jul 3 16:45:08 2013] Locate not so much, always get type errors back [Wed Jul 3 16:45:17 2013] thm_prover: Match on v : A + B with contructors left and right [Wed Jul 3 16:45:17 2013] thm_prover: Match on v : A + B with contructors left and right [Wed Jul 3 16:45:18 2013] SearchAbout( ?A + ?B) however [Wed Jul 3 16:45:18 2013] SearchAbout( ?A + ?B) however [Wed Jul 3 16:45:27 2013] returns mostly stuff about arithmetric and not "sum" [Wed Jul 3 16:45:27 2013] returns mostly stuff about arithmetric and not "sum" [Wed Jul 3 16:45:27 2013] Locate "_ + _". will find the notation [Wed Jul 3 16:45:27 2013] Locate "_ + _". will find the notation [Wed Jul 3 16:46:18 2013] napping: SearchAbout(sum) gives me inl/inr [Wed Jul 3 16:46:18 2013] napping: SearchAbout(sum) gives me inl/inr [Wed Jul 3 16:46:23 2013] napping: where ar eyou getting left/right from? [Wed Jul 3 16:46:23 2013] napping: where ar eyou getting left/right from? [Wed Jul 3 16:47:04 2013] right, there is no simple projection function [Wed Jul 3 16:47:04 2013] right, there is no simple projection function [Wed Jul 3 16:47:05 2013] napping: http://coq.inria.fr/stdlib/Coq.Init.Datatypes.html also has left/right [Wed Jul 3 16:47:05 2013] napping: http://coq.inria.fr/stdlib/Coq.Init.Datatypes.html also has left/right [Wed Jul 3 16:47:37 2013] that has inl/inr [Wed Jul 3 16:47:37 2013] that has inl/inr [Wed Jul 3 16:48:50 2013] You can't project, since you don't necesarily have a value of the given type. [Wed Jul 3 16:48:50 2013] You can't project, since you don't necesarily have a value of the given type. [Wed Jul 3 16:49:10 2013] You could have 'A + B -> option A' though. [Wed Jul 3 16:49:10 2013] You could have 'A + B -> option A' though. [Wed Jul 3 16:49:43 2013] But you probably don't want that. [Wed Jul 3 16:49:43 2013] But you probably don't want that. [Wed Jul 3 16:52:15 2013] tomprince: this makes sense [Wed Jul 3 16:52:15 2013] tomprince: this makes sense [Wed Jul 3 16:52:19 2013] tomprince: thanks [Wed Jul 3 16:52:19 2013] tomprince: thanks [Wed Jul 3 17:02:38 2013] dumb question: "Transparent foo." did not work <-- is there a database of comamnds where I tell Coq: anytime you can "unfold Foo", do "unfold Foo" ? [Wed Jul 3 17:02:38 2013] dumb question: "Transparent foo." did not work <-- is there a database of comamnds where I tell Coq: anytime you can "unfold Foo", do "unfold Foo" ? [Wed Jul 3 17:02:46 2013] simpl is too powerful -- it's unfolding stuff I don't wnated unfolded. [Wed Jul 3 17:02:46 2013] simpl is too powerful -- it's unfolding stuff I don't wnated unfolded. [Wed Jul 3 17:04:10 2013] I haven't tried it, but you might look into autounfold [Wed Jul 3 17:04:10 2013] I haven't tried it, but you might look into autounfold [Wed Jul 3 19:09:45 2013] is there a way to define some type of tuples as follows: [Wed Jul 3 19:09:45 2013] is there a way to define some type of tuples as follows: [Wed Jul 3 19:09:53 2013] (nat, H: proof that given nat is > 5) ? [Wed Jul 3 19:09:53 2013] (nat, H: proof that given nat is > 5) ? [Wed Jul 3 19:10:00 2013] i.e. I want stuff like (6, H: 6 > 5) [Wed Jul 3 19:10:00 2013] i.e. I want stuff like (6, H: 6 > 5) [Wed Jul 3 19:10:04 2013] (7, H: 7 > 5), ... [Wed Jul 3 19:10:04 2013] (7, H: 7 > 5), ... [Wed Jul 3 19:10:13 2013] is there a way to define tuples in such a way so that one arg is dependent on another arg? [Wed Jul 3 19:10:13 2013] is there a way to define tuples in such a way so that one arg is dependent on another arg? [Wed Jul 3 19:11:10 2013] thm_prover: Check out http://coq.inria.fr/distrib/current/stdlib/Coq.Init.Specif.html [Wed Jul 3 19:11:10 2013] thm_prover: Check out http://coq.inria.fr/distrib/current/stdlib/Coq.Init.Specif.html [Wed Jul 3 19:11:36 2013] damn it, [Wed Jul 3 19:11:36 2013] damn it, [Wed Jul 3 19:11:41 2013] dependent tuples = depdnent types ? [Wed Jul 3 19:11:41 2013] dependent tuples = depdnent types ? [Wed Jul 3 19:13:07 2013] thm_prover: that's what {n : nat | n > 5} is [Wed Jul 3 19:13:07 2013] thm_prover: that's what {n : nat | n > 5} is [Wed Jul 3 19:13:31 2013] I have one more dumb question. [Wed Jul 3 19:13:31 2013] I have one more dumb question. [Wed Jul 3 19:13:43 2013] Suppose I have something like (n, H1: n > 5, H2: H2: n < 10), [Wed Jul 3 19:13:43 2013] Suppose I have something like (n, H1: n > 5, H2: H2: n < 10), [Wed Jul 3 19:13:54 2013] it's easy for me to write: let (m, H1, H2) := ... [Wed Jul 3 19:13:54 2013] it's easy for me to write: let (m, H1, H2) := ... [Wed Jul 3 19:14:09 2013] now, when I get dependent types, I have stuff everything into one Prop, which means I use /\ [Wed Jul 3 19:14:09 2013] now, when I get dependent types, I have stuff everything into one Prop, which means I use /\ [Wed Jul 3 19:14:15 2013] how do I break apart that /\ efficiently ? [Wed Jul 3 19:14:15 2013] how do I break apart that /\ efficiently ? [Wed Jul 3 22:23:45 2013] I have a like "match goal with | [ H : TYPE … |- _ ] => inversion H end" [Wed Jul 3 22:23:45 2013] I have a like "match goal with | [ H : TYPE … |- _ ] => inversion H end" [Wed Jul 3 22:24:21 2013] a tactic like [Wed Jul 3 22:24:21 2013] a tactic like [Wed Jul 3 22:25:06 2013] and I want to repeat it, but I want only the first matches to be inverted, since "inversion H" will introduce more goals : TYPE ... [Wed Jul 3 22:25:06 2013] and I want to repeat it, but I want only the first matches to be inverted, since "inversion H" will introduce more goals : TYPE ... [Wed Jul 3 22:26:27 2013] something like find a list of all hypotheses that match "H : TYPE …", then invert on only those [Wed Jul 3 22:26:27 2013] something like find a list of all hypotheses that match "H : TYPE …", then invert on only those [Thu Jul 4 05:36:00 2013] osa1: Locate "=". Check eq. [Thu Jul 4 05:36:00 2013] osa1: Locate "=". Check eq. [Thu Jul 4 05:36:15 2013] you need to look up the notation first to see what it's actually called [Thu Jul 4 05:36:15 2013] you need to look up the notation first to see what it's actually called [Thu Jul 4 05:36:51 2013] thanks [Thu Jul 4 05:36:51 2013] thanks [Thu Jul 4 13:14:33 2013] hello [Thu Jul 4 13:14:33 2013] hello [Thu Jul 4 13:15:25 2013] I have a hypothesis Constant <> Constant, is there something shorter than "assert (contra : Constant = Constant). { reflexivity. } contradiction."? [Thu Jul 4 13:15:25 2013] I have a hypothesis Constant <> Constant, is there something shorter than "assert (contra : Constant = Constant). { reflexivity. } contradiction."? [Thu Jul 4 13:15:41 2013] discriminate [Thu Jul 4 13:15:41 2013] discriminate [Thu Jul 4 13:15:50 2013] uh, I think. [Thu Jul 4 13:15:50 2013] uh, I think. [Thu Jul 4 13:16:09 2013] wait, no. [Thu Jul 4 13:16:09 2013] wait, no. [Thu Jul 4 13:16:22 2013] nox: you can apply H; reflexivity at least, but I think there's a shorter way. [Thu Jul 4 13:16:22 2013] nox: you can apply H; reflexivity at least, but I think there's a shorter way. [Thu Jul 4 13:16:39 2013] exfalso; auto should do it too [Thu Jul 4 13:16:39 2013] exfalso; auto should do it too [Thu Jul 4 13:17:31 2013] ok, that was nice; yet another tactic I didn't know about :) [Thu Jul 4 13:17:31 2013] ok, that was nice; yet another tactic I didn't know about :) [Thu Jul 4 13:19:35 2013] elliott: and slightly related, I have a hypothesis f x = true and I can assert that f x = false, how do I prove that it is a contradiction? [Thu Jul 4 13:19:35 2013] elliott: and slightly related, I have a hypothesis f x = true and I can assert that f x = false, how do I prove that it is a contradiction? [Thu Jul 4 13:19:55 2013] ah, congruence handles x <> x [Thu Jul 4 13:19:55 2013] ah, congruence handles x <> x [Thu Jul 4 13:20:08 2013] and it should handle that case too I think? [Thu Jul 4 13:20:08 2013] and it should handle that case too I think? [Thu Jul 4 13:20:15 2013] ok I will try [Thu Jul 4 13:20:15 2013] ok I will try [Thu Jul 4 13:21:06 2013] elliott: indeed, thank you! [Thu Jul 4 13:21:06 2013] elliott: indeed, thank you! [Thu Jul 4 13:21:13 2013] :) [Thu Jul 4 13:21:13 2013] :) [Thu Jul 4 13:22:02 2013] I'm learning Coq while trying to describe the semantics of Erlang [Thu Jul 4 13:22:02 2013] I'm learning Coq while trying to describe the semantics of Erlang [Thu Jul 4 13:22:44 2013] ambitious! [Thu Jul 4 13:22:44 2013] ambitious! [Thu Jul 4 13:23:12 2013] elliott: especially while being distracted by shiny things along the process [Thu Jul 4 13:23:12 2013] elliott: especially while being distracted by shiny things along the process [Thu Jul 4 13:25:22 2013] elliott: is there an assert tactic that automatically prove the subgoal with reflexivity? [Thu Jul 4 13:25:22 2013] elliott: is there an assert tactic that automatically prove the subgoal with reflexivity? [Thu Jul 4 13:26:24 2013] you can "assert foo by reflexivity", but you should not need to use an assert here I think? [Thu Jul 4 13:26:24 2013] you can "assert foo by reflexivity", but you should not need to use an assert here I think? [Thu Jul 4 14:03:49 2013] can I transform a P1 x > P2 x goal into P2 x < P1 x ? [Thu Jul 4 14:03:49 2013] can I transform a P1 x > P2 x goal into P2 x < P1 x ? [Thu Jul 4 14:08:12 2013] yes. [Thu Jul 4 14:08:12 2013] yes. [Thu Jul 4 14:09:40 2013] how do I do that? [Thu Jul 4 14:09:40 2013] how do I do that? [Thu Jul 4 14:11:06 2013] Proof by induction, usually. I kid. Which numbers are you using? [Thu Jul 4 14:11:06 2013] Proof by induction, usually. I kid. Which numbers are you using? [Thu Jul 4 14:12:10 2013] Actually, unfold gt. [Thu Jul 4 14:12:10 2013] Actually, unfold gt. [Thu Jul 4 14:14:27 2013] x is a real [Thu Jul 4 14:14:27 2013] x is a real [Thu Jul 4 14:19:42 2013] okay. unfold Rgt. [Thu Jul 4 14:19:42 2013] okay. unfold Rgt. [Thu Jul 4 14:25:03 2013] the goal remains P1 x > P2 x when I do that [Thu Jul 4 14:25:03 2013] the goal remains P1 x > P2 x when I do that [Thu Jul 4 14:28:55 2013] sorry it's actually P2 x < P1 x to P1 x > P2 x, so I tried Rlt and then it produces Error: Cannot coerce Rlt to an evaluable reference. [Thu Jul 4 14:28:55 2013] sorry it's actually P2 x < P1 x to P1 x > P2 x, so I tried Rlt and then it produces Error: Cannot coerce Rlt to an evaluable reference. [Thu Jul 4 14:32:51 2013] fold Rgt? [Thu Jul 4 14:32:51 2013] fold Rgt? [Thu Jul 4 14:33:23 2013] that doesn't seem to do anything [Thu Jul 4 14:33:23 2013] that doesn't seem to do anything [Thu Jul 4 14:34:20 2013] If there's anything I learned from working with ACL2, it's never phrase theorems in terms of simple functions. [Thu Jul 4 14:34:20 2013] If there's anything I learned from working with ACL2, it's never phrase theorems in terms of simple functions. [Thu Jul 4 14:34:33 2013] simple being non-recursive. [Thu Jul 4 14:34:33 2013] simple being non-recursive. [Thu Jul 4 14:35:30 2013] You should just assert the implication, prove it with auto and then use the assertion. [Thu Jul 4 14:35:30 2013] You should just assert the implication, prove it with auto and then use the assertion. [Thu Jul 4 14:42:26 2013] that's what I did before, can I use the hypothesis generated by assert more than one? [Thu Jul 4 14:42:26 2013] that's what I did before, can I use the hypothesis generated by assert more than one? [Thu Jul 4 15:02:32 2013] qqpp: Sure. Make it a theorem. [Thu Jul 4 15:02:32 2013] qqpp: Sure. Make it a theorem. [Thu Jul 4 15:10:24 2013] ok [Thu Jul 4 15:10:24 2013] ok [Thu Jul 4 15:11:42 2013] another thing, how does `do` work? what if I want to repeat a certain tactic twice? say assumption. assumption. assumption., can I shorten this? [Thu Jul 4 15:11:42 2013] another thing, how does `do` work? what if I want to repeat a certain tactic twice? say assumption. assumption. assumption., can I shorten this? [Thu Jul 4 15:14:21 2013] s/twice/three times [Thu Jul 4 15:14:21 2013] s/twice/three times [Thu Jul 4 15:16:32 2013] qqpp: ya, do is "apply the following tactic n times" whereas repeat is "apply this tactic repeatedly until it fails." [Thu Jul 4 15:16:32 2013] qqpp: ya, do is "apply the following tactic n times" whereas repeat is "apply this tactic repeatedly until it fails." [Thu Jul 4 15:16:58 2013] both finish if they manage to prove the goal, though. [Thu Jul 4 15:16:58 2013] both finish if they manage to prove the goal, though. [Thu Jul 4 15:17:21 2013] so would that be do 3 assumption.? [Thu Jul 4 15:17:21 2013] so would that be do 3 assumption.? [Thu Jul 4 15:18:13 2013] like I said, you can't use do 3 assumption because the first one will succeed, stopping the next two from running. [Thu Jul 4 15:18:13 2013] like I said, you can't use do 3 assumption because the first one will succeed, stopping the next two from running. [Thu Jul 4 15:19:04 2013] right [Thu Jul 4 15:19:04 2013] right [Thu Jul 4 15:19:32 2013] It's something I wish coq would let me do, but there really isn't a way. [Thu Jul 4 15:19:32 2013] It's something I wish coq would let me do, but there really isn't a way. [Thu Jul 4 15:19:52 2013] so there's nothing that allows you to apply the same tactic to multiple goals at once [Thu Jul 4 15:19:52 2013] so there's nothing that allows you to apply the same tactic to multiple goals at once [Thu Jul 4 15:20:13 2013] You'd have to put after the goal that generates everything you'd want to solve with assumption, "try solve [assumption]." [Thu Jul 4 15:20:13 2013] You'd have to put after the goal that generates everything you'd want to solve with assumption, "try solve [assumption]." [Thu Jul 4 15:20:15 2013] or consecutively rather [Thu Jul 4 15:20:15 2013] or consecutively rather [Thu Jul 4 15:20:42 2013] qqpp: not true. You can use T0;T1 to apply T1 to all goals generated by T0. [Thu Jul 4 15:20:42 2013] qqpp: not true. You can use T0;T1 to apply T1 to all goals generated by T0. [Thu Jul 4 15:21:27 2013] You can also case split on all the goals generated by T0 (say there are n of them) by doing T0;[T1 | ... | Tn]. [Thu Jul 4 15:21:27 2013] You can also case split on all the goals generated by T0 (say there are n of them) by doing T0;[T1 | ... | Tn]. [Thu Jul 4 15:22:30 2013] well I have a goal that is generated multiple times... [Thu Jul 4 15:22:30 2013] well I have a goal that is generated multiple times... [Thu Jul 4 15:23:21 2013] I tried to create a theorem for it but then I still get other goals I need to call assumption for and it doesn't actually reduce the size of the proof [Thu Jul 4 15:23:21 2013] I tried to create a theorem for it but then I still get other goals I need to call assumption for and it doesn't actually reduce the size of the proof [Thu Jul 4 15:23:28 2013] Have you read Coq'art or Adam Chlipala's book on using Coq? [Thu Jul 4 15:23:28 2013] Have you read Coq'art or Adam Chlipala's book on using Coq? [Thu Jul 4 15:25:57 2013] no [Thu Jul 4 15:25:57 2013] no [Thu Jul 4 15:29:49 2013] qqpp: You might want to. Or perhaps Software Foundations by Pierce et. al. The latter two are free online. [Thu Jul 4 15:29:49 2013] qqpp: You might want to. Or perhaps Software Foundations by Pierce et. al. The latter two are free online. [Thu Jul 4 15:31:53 2013] alright [Thu Jul 4 15:31:53 2013] alright [Thu Jul 4 15:31:57 2013] thanks for your help! [Thu Jul 4 15:31:57 2013] thanks for your help! [Thu Jul 4 15:54:02 2013] Is there any tactic that, given "A, B : Type", "x : A" and "p : A = B", lets me conclude "x : B"? [Thu Jul 4 15:54:02 2013] Is there any tactic that, given "A, B : Type", "x : A" and "p : A = B", lets me conclude "x : B"? [Thu Jul 4 15:54:22 2013] rewrite p in x. ? [Thu Jul 4 15:54:22 2013] rewrite p in x. ? [Thu Jul 4 15:54:30 2013] Okay, thanks! [Thu Jul 4 15:54:30 2013] Okay, thanks! [Thu Jul 4 15:54:39 2013] destruct p. ? [Thu Jul 4 15:54:39 2013] destruct p. ? [Fri Jul 5 03:04:02 2013] Saizan: well, lambdabot just gave me a message from one year and three months ago [Fri Jul 5 03:04:02 2013] Saizan: well, lambdabot just gave me a message from one year and three months ago [Fri Jul 5 03:04:09 2013] so that's useful to me now :) [Fri Jul 5 03:04:09 2013] so that's useful to me now :) [Fri Jul 5 03:05:20 2013] * once saw someone ask how to send a message to someone with lambdabot, get notified they have new messages immediately after, and upon doing @messages their single message was from a year ago, saying "you use @tell" [Fri Jul 5 03:05:20 2013] * once saw someone ask how to send a message to someone with lambdabot, get notified they have new messages immediately after, and upon doing @messages their single message was from a year ago, saying "you use @tell" [Fri Jul 5 03:05:32 2013] that was the day I started believing in miracles [Fri Jul 5 03:05:32 2013] that was the day I started believing in miracles [Fri Jul 5 03:31:49 2013] hah [Fri Jul 5 03:31:49 2013] hah [Fri Jul 5 03:50:16 2013] haha [Fri Jul 5 03:50:17 2013] haha [Fri Jul 5 19:25:32 2013] Hi everybody. Is there a way to force Coq to put all parentheses explicitly? [Fri Jul 5 19:25:32 2013] Hi everybody. Is there a way to force Coq to put all parentheses explicitly? [Fri Jul 5 23:00:31 2013] Hrm. So I'd like to use Coq to define a miniature programming language. Each value in the language should have a type of the form LinearValue t, and LinearValue t should have the type Set, so that it can be extracted. [Fri Jul 5 23:00:31 2013] Hrm. So I'd like to use Coq to define a miniature programming language. Each value in the language should have a type of the form LinearValue t, and LinearValue t should have the type Set, so that it can be extracted. [Fri Jul 5 23:01:28 2013] t has type LinearType. One of the constructors for LinearType is Data : Set -> LinearType, and one of the constructors for LinearValue is wrap : forall {a : Set}, a -> LinearValue (Data a). [Fri Jul 5 23:01:28 2013] t has type LinearType. One of the constructors for LinearType is Data : Set -> LinearType, and one of the constructors for LinearValue is wrap : forall {a : Set}, a -> LinearValue (Data a). [Fri Jul 5 23:01:34 2013] Like so: http://pastie.org/8114496 [Fri Jul 5 23:01:34 2013] Like so: http://pastie.org/8114496 [Fri Jul 5 23:03:22 2013] But this gives me "Error: Large non-propositional inductive types must be in Type." on line 14. [Fri Jul 5 23:03:22 2013] But this gives me "Error: Large non-propositional inductive types must be in Type." on line 14. [Fri Jul 5 23:04:20 2013] Which, yeah, wrap depends on Set, so of course its type has to be in Type, not in Set. Is there any way to, like, make it be in Set anyway? [Fri Jul 5 23:04:20 2013] Which, yeah, wrap depends on Set, so of course its type has to be in Type, not in Set. Is there any way to, like, make it be in Set anyway? [Sat Jul 6 06:16:58 2013] I'm having trouble understanding `forall` keyword, what is different between `forall n : nat, n = n` and `fun n : nat => n = n` ? [Sat Jul 6 06:16:58 2013] I'm having trouble understanding `forall` keyword, what is different between `forall n : nat, n = n` and `fun n : nat => n = n` ? [Sat Jul 6 06:20:07 2013] the latter is a type parametrized on 'n', the former is the propositions that says n = n holds for every choice of n [Sat Jul 6 06:20:07 2013] the latter is a type parametrized on 'n', the former is the propositions that says n = n holds for every choice of n [Sat Jul 6 06:48:35 2013] Saizan: then how does that work: http://paste.tryhaskell.org/90708 here a value(a function) is applied to a 'proposition'? (in line 16) [Sat Jul 6 06:48:35 2013] Saizan: then how does that work: http://paste.tryhaskell.org/90708 here a value(a function) is applied to a 'proposition'? (in line 16) [Sat Jul 6 06:54:13 2013] nat_rec is a value of type "forall n, ...", it's not "forall n, .." itself [Sat Jul 6 06:54:13 2013] nat_rec is a value of type "forall n, ...", it's not "forall n, .." itself [Sat Jul 6 06:54:36 2013] and value of that type are functions [Sat Jul 6 06:54:36 2013] and value of that type are functions [Sat Jul 6 06:55:19 2013] dependent functions, in particular [Sat Jul 6 06:55:19 2013] dependent functions, in particular [Sat Jul 6 06:58:08 2013] because if you want to prove "forall n : nat, P n" you need something that provides a proof of (P n) for every given n [Sat Jul 6 06:58:08 2013] because if you want to prove "forall n : nat, P n" you need something that provides a proof of (P n) for every given n [Sat Jul 6 06:58:50 2013] and in Coq you do that by a function which takes n as arugment and has P n as result [Sat Jul 6 06:58:50 2013] and in Coq you do that by a function which takes n as arugment and has P n as result [Sat Jul 6 06:59:00 2013] *and has a value of type P n as result [Sat Jul 6 06:59:00 2013] *and has a value of type P n as result [Sat Jul 6 06:59:35 2013] also, "A -> B" is the same as "forall _ : A, B" [Sat Jul 6 06:59:35 2013] also, "A -> B" is the same as "forall _ : A, B" [Sat Jul 6 07:00:32 2013] same reasoning, except the type of the result B is independent of the argument of type A [Sat Jul 6 07:00:32 2013] same reasoning, except the type of the result B is independent of the argument of type A [Sat Jul 6 07:08:44 2013] Saizan: so there are two different uses of forall keyword, is that correct? one in type context and one in term context [Sat Jul 6 07:08:44 2013] Saizan: so there are two different uses of forall keyword, is that correct? one in type context and one in term context [Sat Jul 6 07:08:56 2013] in type context, it means type of a function [Sat Jul 6 07:08:56 2013] in type context, it means type of a function [Sat Jul 6 07:12:39 2013] osa1: no [Sat Jul 6 07:12:39 2013] osa1: no [Sat Jul 6 07:12:47 2013] osa1: where are you seeing this difference? [Sat Jul 6 07:12:47 2013] osa1: where are you seeing this difference? [Sat Jul 6 07:12:59 2013] [07:52] nat_rec is a value of type "forall n, ...", it's not "forall n, .." itself [Sat Jul 6 07:12:59 2013] [07:52] nat_rec is a value of type "forall n, ...", it's not "forall n, .." itself [Sat Jul 6 07:13:31 2013] both those forall mean the same thing [Sat Jul 6 07:13:31 2013] both those forall mean the same thing [Sat Jul 6 07:13:58 2013] it's like saying "zero is a value of type "nat", it's not "nat" itself" [Sat Jul 6 07:13:58 2013] it's like saying "zero is a value of type "nat", it's not "nat" itself" [Sat Jul 6 07:15:06 2013] (maybe replace zero with O for concreteness) [Sat Jul 6 07:15:06 2013] (maybe replace zero with O for concreteness) [Sat Jul 6 07:17:28 2013] Saizan: I think I get it. is that conversion of arrow types correct: http://paste.tryhaskell.org/90709 ? [Sat Jul 6 07:17:28 2013] Saizan: I think I get it. is that conversion of arrow types correct: http://paste.tryhaskell.org/90709 ? [Sat Jul 6 07:17:39 2013] notice that "Check nat_rec." is giving you the type of nat_rec, not its definition [Sat Jul 6 07:17:39 2013] notice that "Check nat_rec." is giving you the type of nat_rec, not its definition [Sat Jul 6 07:18:12 2013] osa1: yeah [Sat Jul 6 07:18:12 2013] osa1: yeah [Sat Jul 6 07:20:17 2013] Saizan: well it could be a lot easier to understand if `forall` syntax had been using -> instead of , [Sat Jul 6 07:20:17 2013] Saizan: well it could be a lot easier to understand if `forall` syntax had been using -> instead of , [Sat Jul 6 07:28:32 2013] this syntax is taken quite directly from first order logic, in type theory something like (n : nat) -> P n is fairly common though [Sat Jul 6 07:28:32 2013] this syntax is taken quite directly from first order logic, in type theory something like (n : nat) -> P n is fairly common though [Sat Jul 6 13:26:31 2013] I have a function apply : forall a b, LinearValue (Lolly a b) -> LinearValue a -> LinearValue b. [Sat Jul 6 13:26:31 2013] I have a function apply : forall a b, LinearValue (Lolly a b) -> LinearValue a -> LinearValue b. [Sat Jul 6 13:26:55 2013] Can I declare apply as a coercion, so that values of type LinearValue (Lolly a b) are automatically coerced to LinearValue a -> LinearValue b? [Sat Jul 6 13:26:55 2013] Can I declare apply as a coercion, so that values of type LinearValue (Lolly a b) are automatically coerced to LinearValue a -> LinearValue b? [Sat Jul 6 13:46:35 2013] Coercion apply : LinaerValue >-> Funclass or something [Sat Jul 6 13:46:35 2013] Coercion apply : LinaerValue >-> Funclass or something [Sat Jul 6 13:46:38 2013] might need to make a b implicit [Sat Jul 6 13:46:38 2013] might need to make a b implicit [Sat Jul 6 15:26:45 2013] I have a "| H: a = b |- Some a = Some b" [Sat Jul 6 15:26:45 2013] I have a "| H: a = b |- Some a = Some b" [Sat Jul 6 15:26:52 2013] without doing "rewrite H; reflexivity", how do I prove this? [Sat Jul 6 15:26:52 2013] without doing "rewrite H; reflexivity", how do I prove this? [Sat Jul 6 15:26:57 2013] I think there is a constructor tactic of some sort? [Sat Jul 6 15:26:57 2013] I think there is a constructor tactic of some sort? [Sat Jul 6 15:27:01 2013] I want to use that tactic (the constructor one) [Sat Jul 6 15:27:01 2013] I want to use that tactic (the constructor one) [Sat Jul 6 15:27:06 2013] but typing "constructor" gives me an error [Sat Jul 6 15:27:06 2013] but typing "constructor" gives me an error [Sat Jul 6 15:38:21 2013] f_equal [Sat Jul 6 15:38:21 2013] f_equal [Sat Jul 6 15:47:36 2013] noted, thanks [Sat Jul 6 15:47:36 2013] noted, thanks [Sat Jul 6 16:53:34 2013] thm_prover: Other options include: [apply f_equal; reflexivity.]; [case H; reflexivity.]; [destruct H; reflexivity.]; [induction H; reflexivity.]; [subst; reflexivity.]; [exact match H with eq_refl => eq_refl end.]; [exact match H in _ = y return Some a = Some y with eq_refl => eq_refl end.]. In all of these instances (and your [rewrite H; reflexivity.] one), [reflexivity] can be replaced by [constructor]. [Sat Jul 6 16:53:34 2013] thm_prover: Other options include: [apply f_equal; reflexivity.]; [case H; reflexivity.]; [destruct H; reflexivity.]; [induction H; reflexivity.]; [subst; reflexivity.]; [exact match H with eq_refl => eq_refl end.]; [exact match H in _ = y return Some a = Some y with eq_refl => eq_refl end.]. In all of these instances (and your [rewrite H; reflexivity.] one), [reflexivity] can be replaced by [constructor]. [Tue Jul 9 16:14:59 2013] How does the rewrite database work? [Tue Jul 9 16:14:59 2013] How does the rewrite database work? [Tue Jul 9 16:15:09 2013] is it basically jsut "anytime you can rewrite one of the following forms, rewrite it" ? [Tue Jul 9 16:15:09 2013] is it basically jsut "anytime you can rewrite one of the following forms, rewrite it" ? [Tue Jul 9 16:15:13 2013] is itused by anything besudes auto? [Tue Jul 9 16:15:13 2013] is itused by anything besudes auto? [Tue Jul 9 16:20:36 2013] is there some tactic to "unfold" some notation to its original meaning? [Tue Jul 9 16:20:36 2013] is there some tactic to "unfold" some notation to its original meaning? [Tue Jul 9 16:22:00 2013] unfold? [Tue Jul 9 16:22:00 2013] unfold? [Tue Jul 9 16:22:18 2013] unfold "+" or such? [Tue Jul 9 16:22:18 2013] unfold "+" or such? [Tue Jul 9 16:22:23 2013] yes [Tue Jul 9 16:22:23 2013] yes [Tue Jul 9 16:22:33 2013] that will unfold plus itself though [Tue Jul 9 16:22:33 2013] that will unfold plus itself though [Tue Jul 9 16:22:43 2013] I think you have to do Set Printing All. or whatever to just see the notations and nothing else [Tue Jul 9 16:22:43 2013] I think you have to do Set Printing All. or whatever to just see the notations and nothing else [Tue Jul 9 16:23:02 2013] since if it just unfolded the notation it'd do nothing because it'd get printed again in the notated form, I think [Tue Jul 9 16:23:02 2013] since if it just unfolded the notation it'd do nothing because it'd get printed again in the notated form, I think [Tue Jul 9 16:23:16 2013] unless it was set as parsing only or such in which case you wouldn't see it in the first place [Tue Jul 9 16:23:16 2013] unless it was set as parsing only or such in which case you wouldn't see it in the first place [Tue Jul 9 16:24:02 2013] it's just temporary so that i can unify two terms by hand [Tue Jul 9 16:24:02 2013] it's just temporary so that i can unify two terms by hand [Tue Jul 9 16:24:46 2013] thorsten`: The notations aren't "real" [Tue Jul 9 16:24:46 2013] thorsten`: The notations aren't "real" [Tue Jul 9 16:24:58 2013] yeah, you can turn off their display in coqide [Tue Jul 9 16:24:58 2013] yeah, you can turn off their display in coqide [Tue Jul 9 16:25:11 2013] or with that command [Tue Jul 9 16:25:11 2013] or with that command [Tue Jul 9 16:25:15 2013] how can i disable them? (only temporarily) [Tue Jul 9 16:25:15 2013] how can i disable them? (only temporarily) [Tue Jul 9 16:25:34 2013] "Set Printing All." does not seem to work (i'm using proofgeneral btw) [Tue Jul 9 16:25:34 2013] "Set Printing All." does not seem to work (i'm using proofgeneral btw) [Tue Jul 9 16:25:37 2013] View -> Display Notations [Tue Jul 9 16:25:37 2013] View -> Display Notations [Tue Jul 9 16:25:39 2013] oh [Tue Jul 9 16:25:39 2013] oh [Tue Jul 9 16:25:45 2013] I don't know in proofgeneral [Tue Jul 9 16:25:45 2013] I don't know in proofgeneral [Tue Jul 9 16:25:55 2013] But presumably it'd have something similar [Tue Jul 9 16:25:55 2013] But presumably it'd have something similar [Tue Jul 9 16:26:56 2013] thorsten`: Set Printing All. idtac. [Tue Jul 9 16:26:56 2013] thorsten`: Set Printing All. idtac. [Tue Jul 9 16:27:00 2013] you have to get it to refresh sometimes [Tue Jul 9 16:27:00 2013] you have to get it to refresh sometimes [Tue Jul 9 16:27:13 2013] or put Set Printing All. above your tactics and then back up before it and down to them again [Tue Jul 9 16:27:14 2013] or put Set Printing All. above your tactics and then back up before it and down to them again [Tue Jul 9 16:31:48 2013] ok, i got "Set Printing All". (there's a lot of stuff..). That's fine for me, thanks! :) [Tue Jul 9 16:31:48 2013] ok, i got "Set Printing All". (there's a lot of stuff..). That's fine for me, thanks! :) [Tue Jul 9 16:34:23 2013] :) [Tue Jul 9 16:34:23 2013] :) [Tue Jul 9 16:34:34 2013] thorsten`: if the notations are yours you can also just put ", parsing only" in their definitions temporarily [Tue Jul 9 16:34:34 2013] thorsten`: if the notations are yours you can also just put ", parsing only" in their definitions temporarily [Tue Jul 9 16:35:11 2013] yes, they are. [Tue Jul 9 16:35:11 2013] yes, they are. [Tue Jul 9 21:02:02 2013] this is purely for exploration and not actual proofs; is there a way to reorder the goals [Tue Jul 9 21:02:02 2013] this is purely for exploration and not actual proofs; is there a way to reorder the goals [Tue Jul 9 21:02:08 2013] i.e. I'm at goal 1/ 17 [Tue Jul 9 21:02:09 2013] i.e. I'm at goal 1/ 17 [Tue Jul 9 21:02:19 2013] however, I'd like to look at goals 3-5 because I think I can trivially solve them with automated techniques [Tue Jul 9 21:02:19 2013] however, I'd like to look at goals 3-5 because I think I can trivially solve them with automated techniques [Wed Jul 10 04:11:11 2013] in case anyone else is interested in the answer: Focus n. will switch to subgoal n [Wed Jul 10 04:11:11 2013] in case anyone else is interested in the answer: Focus n. will switch to subgoal n [Wed Jul 10 16:50:20 2013] [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup [Thu Jul 11 06:55:57 2013] how can define, that a Tactic Notation gets some (in my case arithmetic) term as a parameter? [Thu Jul 11 06:55:57 2013] how can define, that a Tactic Notation gets some (in my case arithmetic) term as a parameter? [Thu Jul 11 07:02:41 2013] thorsten`: Tactic Notation "foo" constr(H) := blaat [Thu Jul 11 07:02:41 2013] thorsten`: Tactic Notation "foo" constr(H) := blaat [Thu Jul 11 07:55:42 2013] robbert: thanks! [Thu Jul 11 07:55:42 2013] robbert: thanks! [Fri Jul 12 19:32:32 2013] Hey folks, suppose I have match ??? with | con -> X; I'd like to simplify this to X, how can I do that? [Fri Jul 12 19:32:32 2013] Hey folks, suppose I have match ??? with | con -> X; I'd like to simplify this to X, how can I do that? [Fri Jul 12 19:33:06 2013] When I try to destruct ??? I get 'Abstracting over the terms "m" and "p" leads to a term "fun (m : myprod A B) (p : mymkprod (mypr1 m) (mypr2 m) = m) => match p in (_ = a) return (C a) with | 1%path => g (mypr1 m) (mypr2 m) end = g a b" which is ill-typed.' [Fri Jul 12 19:33:07 2013] When I try to destruct ??? I get 'Abstracting over the terms "m" and "p" leads to a term "fun (m : myprod A B) (p : mymkprod (mypr1 m) (mypr2 m) = m) => match p in (_ = a) return (C a) with | 1%path => g (mypr1 m) (mypr2 m) end = g a b" which is ill-typed.' [Fri Jul 12 19:34:11 2013] can you use the replace tactic? [Fri Jul 12 19:34:11 2013] can you use the replace tactic? [Fri Jul 12 19:34:28 2013] Hmm, let's give it a try [Fri Jul 12 19:34:28 2013] Hmm, let's give it a try [Fri Jul 12 19:37:13 2013] "Terms do not have convertible types" [Fri Jul 12 19:37:13 2013] "Terms do not have convertible types" [Fri Jul 12 19:39:49 2013] is ??? something like "asdf = qwer" ? [Fri Jul 12 19:39:49 2013] is ??? something like "asdf = qwer" ? [Fri Jul 12 19:40:31 2013] comparing to https://sympa.inria.fr/sympa/arc/coq-club/2013-02/msg00041.html [Fri Jul 12 19:40:31 2013] comparing to https://sympa.inria.fr/sympa/arc/coq-club/2013-02/msg00041.html [Fri Jul 12 19:40:50 2013] Yep, it's an equality type [Fri Jul 12 19:40:50 2013] Yep, it's an equality type [Fri Jul 12 19:40:59 2013] you can try e.g. subst [Fri Jul 12 19:40:59 2013] you can try e.g. subst [Fri Jul 12 19:42:46 2013] Oops, looks like subst doesn't work in HoTT Coq :) [Fri Jul 12 19:42:46 2013] Oops, looks like subst doesn't work in HoTT Coq :) [Fri Jul 12 19:44:08 2013] when dealing with equalities you should always be mindful of the possibility that what you want is unprovable [Fri Jul 12 19:44:08 2013] when dealing with equalities you should always be mindful of the possibility that what you want is unprovable [Fri Jul 12 19:46:01 2013] ezyang: are you sure it's not a dependent match in disguise? [Fri Jul 12 19:46:01 2013] ezyang: are you sure it's not a dependent match in disguise? [Fri Jul 12 19:46:12 2013] ...I /think/ my definition is right [Fri Jul 12 19:46:12 2013] ...I /think/ my definition is right [Fri Jul 12 19:46:21 2013] Oh, it is a dependent match, I forgot to mention that [Fri Jul 12 19:46:21 2013] Oh, it is a dependent match, I forgot to mention that [Fri Jul 12 19:47:45 2013] so yeah you probably need more care to perform the inversion [Fri Jul 12 19:47:45 2013] so yeah you probably need more care to perform the inversion [Fri Jul 12 19:47:55 2013] I was considering writing a blog post about that this week-end [Fri Jul 12 19:47:55 2013] I was considering writing a blog post about that this week-end [Fri Jul 12 19:48:11 2013] but maybe you're doing this in a setting more complex than the ones I'm used to [Fri Jul 12 19:48:11 2013] but maybe you're doing this in a setting more complex than the ones I'm used to [Fri Jul 12 19:48:20 2013] since HoTT :p [Fri Jul 12 19:48:20 2013] since HoTT :p [Fri Jul 12 19:48:28 2013] It is differently complex ;) [Fri Jul 12 19:48:28 2013] It is differently complex ;) [Fri Jul 12 19:51:17 2013] oh actually you mentioned it was a dependent match indirectly [Fri Jul 12 19:51:17 2013] oh actually you mentioned it was a dependent match indirectly [Fri Jul 12 19:51:22 2013] it's there in your error message [Fri Jul 12 19:51:22 2013] it's there in your error message [Fri Jul 12 19:51:22 2013] Hmm, maybe I can do this with univalence [Fri Jul 12 19:51:22 2013] Hmm, maybe I can do this with univalence [Fri Jul 12 19:51:29 2013] yeah [Fri Jul 12 19:51:29 2013] yeah [Fri Jul 12 19:54:22 2013] usually I solve these by using "dependent inversion" in the easy cases, and writing my own dependent-pattern-matching in the more complicated cases [Fri Jul 12 19:54:22 2013] usually I solve these by using "dependent inversion" in the easy cases, and writing my own dependent-pattern-matching in the more complicated cases [Fri Jul 12 19:54:35 2013] I'm actually trying to find ways to not do that for the more complicated [Fri Jul 12 19:54:35 2013] I'm actually trying to find ways to not do that for the more complicated [Fri Jul 12 19:54:41 2013] because it's extremely brittle [Fri Jul 12 19:54:41 2013] because it's extremely brittle [Fri Jul 12 19:54:56 2013] and just horrible in fact [Fri Jul 12 19:54:56 2013] and just horrible in fact [Fri Jul 12 19:55:05 2013] there was some blog post about a more advanced destruction/inversion tactic going to be released? [Fri Jul 12 19:55:05 2013] there was some blog post about a more advanced destruction/inversion tactic going to be released? [Fri Jul 12 19:58:24 2013] oh, yeah Thomas Braibant wrote about it [Fri Jul 12 19:58:24 2013] oh, yeah Thomas Braibant wrote about it [Fri Jul 12 19:58:51 2013] http://gallium.inria.fr/blog/a-new-Coq-tactic-for-inversion/ [Fri Jul 12 19:58:51 2013] http://gallium.inria.fr/blog/a-new-Coq-tactic-for-inversion/ [Fri Jul 12 20:00:42 2013] yes [Fri Jul 12 20:00:42 2013] yes [Fri Jul 12 20:53:12 2013] When do I want to use "Transparent" vs "Hint Unfold" ? [Fri Jul 12 20:53:12 2013] When do I want to use "Transparent" vs "Hint Unfold" ? [Fri Jul 12 21:00:54 2013] how do I create a new hint database in Coq? [Fri Jul 12 21:00:54 2013] how do I create a new hint database in Coq? [Fri Jul 12 21:02:09 2013] Hint ... : dbname. [Fri Jul 12 21:02:09 2013] Hint ... : dbname. [Fri Jul 12 21:14:00 2013] Thanks, didn't realize databases were created by "adding a new entry to an empty database" [Fri Jul 12 21:14:00 2013] Thanks, didn't realize databases were created by "adding a new entry to an empty database" [Fri Jul 12 22:11:08 2013] That inver tactic looks great [Fri Jul 12 22:11:08 2013] That inver tactic looks great [Fri Jul 12 22:11:17 2013] s/inver/invert [Fri Jul 12 22:11:17 2013] s/inver/invert [Fri Jul 12 22:11:22 2013] Any updates since that blog post? [Fri Jul 12 22:11:22 2013] Any updates since that blog post? [Sat Jul 13 00:09:51 2013] Hm, I have this mysterious situation where coq claims "no subterm matching" [Sat Jul 13 00:09:51 2013] Hm, I have this mysterious situation where coq claims "no subterm matching" [Sat Jul 13 00:10:06 2013] But I literally copy pasted the subterm into the equality that I'm trying to do the rewrite with [Sat Jul 13 00:10:06 2013] But I literally copy pasted the subterm into the equality that I'm trying to do the rewrite with [Sat Jul 13 00:10:12 2013] What other factors can cause this to fail? [Sat Jul 13 00:10:12 2013] What other factors can cause this to fail? [Sat Jul 13 00:10:21 2013] implicit arguments. [Sat Jul 13 00:10:21 2013] implicit arguments. [Sat Jul 13 00:10:31 2013] oh ho, very clever [Sat Jul 13 00:10:31 2013] oh ho, very clever [Sat Jul 13 00:11:57 2013] Hmm, no implicit parameters that I can see. [Sat Jul 13 00:11:57 2013] Hmm, no implicit parameters that I can see. [Sat Jul 13 00:15:31 2013] oh this is not fair [Sat Jul 13 00:15:31 2013] oh this is not fair [Sat Jul 13 00:15:47 2013] Coq is printing out a term that when I Check x it is rejecting as ill-typed [Sat Jul 13 00:15:47 2013] Coq is printing out a term that when I Check x it is rejecting as ill-typed [Sat Jul 13 00:19:03 2013] Well, 'Check' can have holes. [Sat Jul 13 00:19:03 2013] Well, 'Check' can have holes. [Sat Jul 13 00:22:31 2013] https://dl.dropboxusercontent.com/u/361503/Your-Argument-is-Irrelephant.gif [Sat Jul 13 00:22:31 2013] https://dl.dropboxusercontent.com/u/361503/Your-Argument-is-Irrelephant.gif [Sat Jul 13 05:01:46 2013] I wonder if there is a way to rewrite any proof script that uses rewrite into one that doesn't. Besides the degenerate methods. [Sat Jul 13 05:01:46 2013] I wonder if there is a way to rewrite any proof script that uses rewrite into one that doesn't. Besides the degenerate methods. [Sat Jul 13 05:22:16 2013] I find myself in a situation where I need to unfold to expose rewriting opportunities. Is there any easy way to automate this away? IIRC the Unfold database is for auto only. [Sat Jul 13 05:22:16 2013] I find myself in a situation where I need to unfold to expose rewriting opportunities. Is there any easy way to automate this away? IIRC the Unfold database is for auto only. [Sat Jul 13 06:01:42 2013] Oh, this can be stated very concisely [Sat Jul 13 06:01:42 2013] Oh, this can be stated very concisely [Sat Jul 13 06:02:01 2013] Given P : a = b |- C a = C b, prove this without using rewrite. [Sat Jul 13 06:02:01 2013] Given P : a = b |- C a = C b, prove this without using rewrite. [Sat Jul 13 06:03:11 2013] Aha, this is the 'ap' lemma. [Sat Jul 13 06:03:11 2013] Aha, this is the 'ap' lemma. [Sat Jul 13 06:03:37 2013] ezyang: f_equal [Sat Jul 13 06:03:37 2013] ezyang: f_equal [Sat Jul 13 06:03:42 2013] at least in standard Coq [Sat Jul 13 06:03:42 2013] at least in standard Coq [Sat Jul 13 06:03:46 2013] both function and tactic [Sat Jul 13 06:03:46 2013] both function and tactic [Sat Jul 13 06:03:55 2013] I think the function is ap in HoTT. don't know if they use the tactic [Sat Jul 13 06:03:55 2013] I think the function is ap in HoTT. don't know if they use the tactic [Sat Jul 13 06:05:35 2013] Got it. [Sat Jul 13 06:05:35 2013] Got it. [Sat Jul 13 06:23:15 2013] Hmm, I wonder, what about x = y -> x' = y' -> f x x' = f y y' [Sat Jul 13 06:23:15 2013] Hmm, I wonder, what about x = y -> x' = y' -> f x x' = f y y' [Sat Jul 13 06:23:26 2013] I guess... if you do it twice that should be enough? [Sat Jul 13 06:23:26 2013] I guess... if you do it twice that should be enough? [Sat Jul 13 06:25:27 2013] f_equal handles that [Sat Jul 13 06:25:27 2013] f_equal handles that [Sat Jul 13 06:25:33 2013] it'll generate x = y and x' = y' as subgoals [Sat Jul 13 06:25:33 2013] it'll generate x = y and x' = y' as subgoals [Sat Jul 13 06:26:00 2013] basically it turns (f x = f' x') into (f = f') and (x = x') and recurses on the former and tries to solve as many as it can automatically [Sat Jul 13 06:26:00 2013] basically it turns (f x = f' x') into (f = f') and (x = x') and recurses on the former and tries to solve as many as it can automatically [Sat Jul 13 06:28:45 2013] Hmmk. [Sat Jul 13 06:28:45 2013] Hmmk. [Sat Jul 13 06:30:15 2013] Why doesn't HoTT have an f_equal tactic :-( [Sat Jul 13 06:30:15 2013] Why doesn't HoTT have an f_equal tactic :-( [Sat Jul 13 06:32:12 2013] perhaps "repeat apply ap." suffices? not sure if that'd work [Sat Jul 13 06:32:12 2013] perhaps "repeat apply ap." suffices? not sure if that'd work [Sat Jul 13 06:32:45 2013] apply ap won't unify [Sat Jul 13 06:32:45 2013] apply ap won't unify [Sat Jul 13 06:32:56 2013] ohhhh [Sat Jul 13 06:32:56 2013] ohhhh [Sat Jul 13 06:33:02 2013] but maybe a different ap variant will work [Sat Jul 13 06:33:02 2013] but maybe a different ap variant will work [Sat Jul 13 06:33:48 2013] got it: ap11 [Sat Jul 13 06:33:48 2013] got it: ap11 [Sat Jul 13 06:34:39 2013] * wonders what the 11 stands for [Sat Jul 13 06:34:39 2013] * wonders what the 11 stands for [Sat Jul 13 06:34:53 2013] oh, probably ap requires the same f and 11 has the f = f' part? [Sat Jul 13 06:34:53 2013] oh, probably ap requires the same f and 11 has the f = f' part? [Sat Jul 13 06:37:47 2013] yeppers [Sat Jul 13 06:37:47 2013] yeppers [Sat Jul 13 06:37:50 2013] ap = ap01 [Sat Jul 13 06:37:50 2013] ap = ap01 [Sat Jul 13 06:44:01 2013] Hmmk [Sat Jul 13 06:44:01 2013] Hmmk [Sat Jul 13 06:44:21 2013] Now, let's see, we want to prove 'snd p = x' and we have 'p = (n, x)' [Sat Jul 13 06:44:21 2013] Now, let's see, we want to prove 'snd p = x' and we have 'p = (n, x)' [Sat Jul 13 06:44:32 2013] rewrite forbidden :^) [Sat Jul 13 06:44:32 2013] rewrite forbidden :^) [Sat Jul 13 06:44:54 2013] This sort of feels like I have to subst, and then apply. [Sat Jul 13 06:44:54 2013] This sort of feels like I have to subst, and then apply. [Sat Jul 13 06:46:44 2013] Did I say subst? I meant replace. [Sat Jul 13 06:46:44 2013] Did I say subst? I meant replace. [Sat Jul 13 06:54:28 2013] well, concat seems to have done the trick. [Sat Jul 13 06:54:28 2013] well, concat seems to have done the trick. [Sat Jul 13 06:55:48 2013] ezyang: HoTT really doesn't allow you to rewrite a simple variable = expr? [Sat Jul 13 06:55:49 2013] ezyang: HoTT really doesn't allow you to rewrite a simple variable = expr? [Sat Jul 13 06:55:57 2013] maybe destruct or elim or some other such tactic on the equality? [Sat Jul 13 06:55:57 2013] maybe destruct or elim or some other such tactic on the equality? [Sat Jul 13 06:56:05 2013] once you do that it'd end up snd (n, x) = x [Sat Jul 13 06:56:05 2013] once you do that it'd end up snd (n, x) = x [Sat Jul 13 06:56:08 2013] which is definitionally equal [Sat Jul 13 06:56:08 2013] which is definitionally equal [Sat Jul 13 06:56:58 2013] elliott: HoTT can rewrite [Sat Jul 13 06:56:58 2013] elliott: HoTT can rewrite [Sat Jul 13 06:57:18 2013] But they don't really like it; Coq generates terrible proof terms when you use rewrite. [Sat Jul 13 06:57:18 2013] But they don't really like it; Coq generates terrible proof terms when you use rewrite. [Sat Jul 13 06:57:26 2013] So I'm getting a feel for what things are like without rewrite. [Sat Jul 13 06:57:26 2013] So I'm getting a feel for what things are like without rewrite. [Sat Jul 13 06:58:24 2013] destructing on the equality doesn't seem to do anything [Sat Jul 13 06:58:24 2013] destructing on the equality doesn't seem to do anything [Sat Jul 13 07:00:17 2013] right. [Sat Jul 13 07:00:17 2013] right. [Sat Jul 13 07:00:39 2013] sort of feel like Coq tactics are kind of at odds of the HoTT view of the world [Sat Jul 13 07:00:39 2013] sort of feel like Coq tactics are kind of at odds of the HoTT view of the world [Sat Jul 13 07:00:41 2013] vs. a more Agda type thing [Sat Jul 13 07:00:41 2013] vs. a more Agda type thing [Sat Jul 13 07:02:25 2013] That's terrible. Coq tactics are awesome :-( [Sat Jul 13 07:02:25 2013] That's terrible. Coq tactics are awesome :-( [Sat Jul 13 07:04:38 2013] Well, if you really care about *which* proof you're getting, then the fancier tactics are probably going to be annoying. [Sat Jul 13 07:04:39 2013] Well, if you really care about *which* proof you're getting, then the fancier tactics are probably going to be annoying. [Sat Jul 13 07:05:15 2013] Maybe it just requires more geometrically-inspired tactics... I'm not even sure what those would look like :) [Sat Jul 13 07:05:15 2013] Maybe it just requires more geometrically-inspired tactics... I'm not even sure what those would look like :) [Sat Jul 13 07:06:26 2013] hee [Sat Jul 13 07:06:26 2013] hee [Sat Jul 13 07:06:57 2013] http://pastebin.com/trDAV2cA god I'm such a terrible person [Sat Jul 13 07:06:57 2013] http://pastebin.com/trDAV2cA god I'm such a terrible person [Sat Jul 13 07:07:04 2013] but Adamizing proofs is just too much fun [Sat Jul 13 07:07:04 2013] but Adamizing proofs is just too much fun [Sat Jul 13 07:08:40 2013] I see more than one ".". you're clearly not trying hard enough. [Sat Jul 13 07:08:40 2013] I see more than one ".". you're clearly not trying hard enough. [Sat Jul 13 07:09:39 2013] haha [Sat Jul 13 07:09:39 2013] haha [Sat Jul 13 07:12:58 2013] remind me, how do I add a global theorem to my context? [Sat Jul 13 07:12:58 2013] remind me, how do I add a global theorem to my context? [Sat Jul 13 07:13:12 2013] um, "pose proof"? [Sat Jul 13 07:13:13 2013] um, "pose proof"? [Sat Jul 13 07:13:17 2013] depends why you're doing it [Sat Jul 13 07:13:17 2013] depends why you're doing it [Sat Jul 13 07:13:28 2013] I have some automation which only looks in the context [Sat Jul 13 07:13:28 2013] I have some automation which only looks in the context [Sat Jul 13 07:13:38 2013] cheap and cheerful hint database [Sat Jul 13 07:13:38 2013] cheap and cheerful hint database [Sat Jul 13 07:14:27 2013] :( [Sat Jul 13 07:14:27 2013] :( [Sat Jul 13 07:14:43 2013] this doesn't make me cheerful at all. [Sat Jul 13 07:14:43 2013] this doesn't make me cheerful at all. [Sat Jul 13 09:01:20 2013] ezyang: You should pull a more recent version of HoTT/HoTT. I recently got an [f_ap] tactic merged which replaces [f_equal] (as far as I understand [f_equal], having never read the ml code). [Sat Jul 13 09:01:21 2013] ezyang: You should pull a more recent version of HoTT/HoTT. I recently got an [f_ap] tactic merged which replaces [f_equal] (as far as I understand [f_equal], having never read the ml code). [Sat Jul 13 09:03:02 2013] ezyang: Does [Goal forall A B (x y x' y' : A) (f : A -> B), x = y -> x' = y' -> f x x' = f y y'. intros. path_induction. reflexivity. Qed.] work? [Sat Jul 13 09:03:03 2013] ezyang: Does [Goal forall A B (x y x' y' : A) (f : A -> B), x = y -> x' = y' -> f x x' = f y y'. intros. path_induction. reflexivity. Qed.] work? [Sat Jul 13 09:07:57 2013] ezyang: http://pastebin.com/trDAV2cA might be nicer with things like "transitivity (snd (mynat_rec' C c0 cs n))" (which seems to be approximattely what you're trying to do?). [Sat Jul 13 09:07:58 2013] ezyang: http://pastebin.com/trDAV2cA might be nicer with things like "transitivity (snd (mynat_rec' C c0 cs n))" (which seems to be approximattely what you're trying to do?). [Sat Jul 13 09:11:06 2013] ezyang: [Check] might loop forever on a term if typeclass resolution has a loop and you haven't instantiated all the typeclasses. Or if you [Set Printing All] and have so many terms that your pasting that Coq's parser or whatever stack overflows. However, usually, if you [Set Printing All.], whatever output comes out should be [Check]able. (Perhaps [Set Printing Implicits. Unset Printing Notations.] would be sufficient?) [Sat Jul 13 09:11:06 2013] ezyang: [Check] might loop forever on a term if typeclass resolution has a loop and you haven't instantiated all the typeclasses. Or if you [Set Printing All] and have so many terms that your pasting that Coq's parser or whatever stack overflows. However, usually, if you [Set Printing All.], whatever output comes out should be [Check]able. (Perhaps [Set Printing Implicits. Unset Printing Notations.] would be sufficient?) [Sat Jul 13 09:14:09 2013] I think the HoTT view of the world is that you most often care about which proofs you get when things are not mere propositions. Once you've proven something to be a mere proposition (like equality of [nat]s), then you don't care anymore (unless you're doing fancy things and need your proofs to syntatically unify), and can [reqwrite] and [Qed] to your heart's content. [Sat Jul 13 09:14:10 2013] I think the HoTT view of the world is that you most often care about which proofs you get when things are not mere propositions. Once you've proven something to be a mere proposition (like equality of [nat]s), then you don't care anymore (unless you're doing fancy things and need your proofs to syntatically unify), and can [reqwrite] and [Qed] to your heart's content. [Sat Jul 13 12:35:33 2013] how can i tell "unfold" to unfold a fixpoint at most once? [Sat Jul 13 12:35:33 2013] how can i tell "unfold" to unfold a fixpoint at most once? [Sat Jul 13 12:37:51 2013] hm it seems "simpl" did it for my concrete case [Sat Jul 13 12:37:51 2013] hm it seems "simpl" did it for my concrete case [Sat Jul 13 12:47:24 2013] throsten`: try manually cbv delta, perhaps, or lazy [Sat Jul 13 12:47:24 2013] throsten`: try manually cbv delta, perhaps, or lazy [Sat Jul 13 12:47:37 2013] jgross: Thanks! I will do so. [Sat Jul 13 12:47:37 2013] jgross: Thanks! I will do so. [Sat Jul 13 12:48:04 2013] okey, i will look for those things. [Sat Jul 13 12:48:04 2013] okey, i will look for those things. [Sat Jul 13 12:50:19 2013] jgross: So, have you made a true 'crush' tactic for HoTT proofs, yet? :) [Sat Jul 13 12:50:19 2013] jgross: So, have you made a true 'crush' tactic for HoTT proofs, yet? :) [Sat Jul 13 14:02:39 2013] When Set Printing Universes is on, what does this mean: http://pastebin.com/DtLDKSrM [Sat Jul 13 14:02:39 2013] When Set Printing Universes is on, what does this mean: http://pastebin.com/DtLDKSrM [Sat Jul 13 14:03:21 2013] I feel like it's a constraint of some sort [Sat Jul 13 14:03:21 2013] I feel like it's a constraint of some sort [Sat Jul 13 14:03:51 2013] But I don't recall how to read it. [Sat Jul 13 14:03:51 2013] But I don't recall how to read it. [Sat Jul 13 15:23:22 2013] ezyang: I don't do arithmetic often; I've mostly worked in category theory. I've made a more powerful variant of path_induction which will also remove equalities by, e.g., looking for ways to prove the equality equal to idpath via contractibility. But no crush tactic. (I've never actually used crush, and only looked at it's definition briefly, so I don't know what exactly it can do.) [Sat Jul 13 15:23:23 2013] ezyang: I don't do arithmetic often; I've mostly worked in category theory. I've made a more powerful variant of path_induction which will also remove equalities by, e.g., looking for ways to prove the equality equal to idpath via contractibility. But no crush tactic. (I've never actually used crush, and only looked at it's definition briefly, so I don't know what exactly it can do.) [Sat Jul 13 15:24:24 2013] Well, the particulars of CPDT crush are not particularly important, since (as Adam says) you really ought to define your own tactic for your own developments [Sat Jul 13 15:24:24 2013] Well, the particulars of CPDT crush are not particularly important, since (as Adam says) you really ought to define your own tactic for your own developments [Sat Jul 13 15:24:25 2013] ezyang: I think http://pastebin.com/DtLDKSrM means that your definition introduced or uses those two universes, and imposes no constraints between them. (I think constraints get listed after the |=, or something.) [Sat Jul 13 15:24:26 2013] ezyang: I think http://pastebin.com/DtLDKSrM means that your definition introduced or uses those two universes, and imposes no constraints between them. (I think constraints get listed after the |=, or something.) [Sat Jul 13 15:24:43 2013] jgross: OK, that's what I expected. [Sat Jul 13 15:24:43 2013] jgross: OK, that's what I expected. [Sat Jul 13 15:25:04 2013] HoTT-crush would just be some tactic which tries all of the "automatic" inferences HoTTheorists do :^) [Sat Jul 13 15:25:04 2013] HoTT-crush would just be some tactic which tries all of the "automatic" inferences HoTTheorists do :^) [Sat Jul 13 15:27:32 2013] Well, I've been trying to figure out how to make IsTrunc typeclass resolution better (the first step was making all of their instances global, rather than local, which I think they did by accident, and I'm waiting for the pull request to be merged). I haven't figured out a good way to classify "information flow", though, in such a way that typeclass resolution won't go around in circles. [Sat Jul 13 15:27:32 2013] Well, I've been trying to figure out how to make IsTrunc typeclass resolution better (the first step was making all of their instances global, rather than local, which I think they did by accident, and I'm waiting for the pull request to be merged). I haven't figured out a good way to classify "information flow", though, in such a way that typeclass resolution won't go around in circles. [Sat Jul 13 15:29:53 2013] I've also been trying to figure out if the [decide equality] tactic is definable in Ltac. [Sat Jul 13 15:29:53 2013] I've also been trying to figure out if the [decide equality] tactic is definable in Ltac. [Mon Jul 15 03:48:34 2013] when I have a Hypothesis of the form "H: None = Some x" [Mon Jul 15 03:48:34 2013] when I have a Hypothesis of the form "H: None = Some x" [Mon Jul 15 03:48:37 2013] how do I derive "False" ? [Mon Jul 15 03:48:37 2013] how do I derive "False" ? [Mon Jul 15 04:08:10 2013] thm_prover: congruence or inversion H. [Mon Jul 15 04:08:10 2013] thm_prover: congruence or inversion H. [Mon Jul 15 04:09:50 2013] gdsfh: nice, thanks [Mon Jul 15 04:09:50 2013] gdsfh: nice, thanks [Mon Jul 15 05:02:53 2013] looks like http://coq.inria.fr/ is down [Mon Jul 15 05:02:53 2013] looks like http://coq.inria.fr/ is down [Mon Jul 15 09:05:24 2013] If I have a hypothesis of the form "Hypothesis h : (f A) = B", is there a way to tell Coq that something 'v : (f A)' can be used when it's expecting something of type B? [Mon Jul 15 09:05:24 2013] If I have a hypothesis of the form "Hypothesis h : (f A) = B", is there a way to tell Coq that something 'v : (f A)' can be used when it's expecting something of type B? [Mon Jul 15 09:56:57 2013] ryanakca: Can you just eliminate the hypothesis (induction h)? [Mon Jul 15 09:56:57 2013] ryanakca: Can you just eliminate the hypothesis (induction h)? [Mon Jul 15 10:01:37 2013] if I have two hypotheses dependent on the same variable (foo: Bar), is there a way to forget that they depend on the same foo? [Mon Jul 15 10:01:37 2013] if I have two hypotheses dependent on the same variable (foo: Bar), is there a way to forget that they depend on the same foo? [Mon Jul 15 10:01:58 2013] oh, rather, one occurence of foo is in my hypothesis, and one in my goal [Mon Jul 15 10:01:58 2013] oh, rather, one occurence of foo is in my hypothesis, and one in my goal [Mon Jul 15 10:03:53 2013] I might be able to pose an equality and forget it? [Mon Jul 15 10:03:53 2013] I might be able to pose an equality and forget it? [Mon Jul 15 10:07:05 2013] jonsterling: This is in the context of a "Definition a : C := ..." not type checking. [Mon Jul 15 10:07:05 2013] jonsterling: This is in the context of a "Definition a : C := ..." not type checking. [Mon Jul 15 10:10:28 2013] ryanakca: You should be able to coerce v across that equality either way, unless I am misunderstanding your problem... [Mon Jul 15 10:10:28 2013] ryanakca: You should be able to coerce v across that equality either way, unless I am misunderstanding your problem... [Mon Jul 15 10:26:34 2013] jonsterling: In short, is there a way to get around the need for eq_rect_r and eq_rect? See http://paste.debian.net/16179/ for an example of what I mean. [Mon Jul 15 10:26:34 2013] jonsterling: In short, is there a way to get around the need for eq_rect_r and eq_rect? See http://paste.debian.net/16179/ for an example of what I mean. [Mon Jul 15 10:33:28 2013] ryanakca: Oh, I see what you want... I think that would require equality reflection, something intentional type theories don't have. Unless I'm much mistaken, you're probably going to have to use one of the eq induction principles as you surmise. [Mon Jul 15 10:33:28 2013] ryanakca: Oh, I see what you want... I think that would require equality reflection, something intentional type theories don't have. Unless I'm much mistaken, you're probably going to have to use one of the eq induction principles as you surmise. [Mon Jul 15 10:33:35 2013] *intensional [Mon Jul 15 10:33:35 2013] *intensional [Mon Jul 15 10:33:56 2013] you can make the invocation shorter by using _ parameters though [Mon Jul 15 10:33:56 2013] you can make the invocation shorter by using _ parameters though [Mon Jul 15 10:34:09 2013] to omit (fun B => B) [Mon Jul 15 10:34:09 2013] to omit (fun B => B) [Mon Jul 15 10:41:51 2013] Is there any way to use a Coercion? [Mon Jul 15 10:41:51 2013] Is there any way to use a Coercion? [Mon Jul 15 10:51:43 2013] ryanakca: Well, if it is indeed possible, it would still result in more code than just the identity elimination. [Mon Jul 15 10:51:43 2013] ryanakca: Well, if it is indeed possible, it would still result in more code than just the identity elimination. [Tue Jul 16 02:40:51 2013] https://gist.github.com/anonymous/0b02f3ad30e154515b87 [Tue Jul 16 02:40:51 2013] https://gist.github.com/anonymous/0b02f3ad30e154515b87 [Tue Jul 16 02:41:07 2013] in this code sample, (1) why is no substitution happening? and (2) how can I force a substitution? [Tue Jul 16 02:41:07 2013] in this code sample, (1) why is no substitution happening? and (2) how can I force a substitution? [Tue Jul 16 02:43:39 2013] hmm [Tue Jul 16 02:43:39 2013] hmm [Tue Jul 16 02:43:45 2013] I think what I want is called a "beta" reduction [Tue Jul 16 02:43:45 2013] I think what I want is called a "beta" reduction [Tue Jul 16 02:45:48 2013] coq_newb_234: I don't know, but does just 'reflexivity' work? it tends to do a bit of simplification itself [Tue Jul 16 02:45:48 2013] coq_newb_234: I don't know, but does just 'reflexivity' work? it tends to do a bit of simplification itself [Tue Jul 16 06:03:05 2013] waht is the type of {_} + {_} ? [Tue Jul 16 06:03:06 2013] waht is the type of {_} + {_} ? [Tue Jul 16 06:03:08 2013] I know that it's a sumbool [Tue Jul 16 06:03:08 2013] I know that it's a sumbool [Tue Jul 16 06:03:11 2013] but I can't match it with ltac [Tue Jul 16 06:03:11 2013] but I can't match it with ltac [Tue Jul 16 06:05:53 2013] actually, this is what I'm really dealing with [Tue Jul 16 06:05:53 2013] actually, this is what I'm really dealing with [Tue Jul 16 06:05:56 2013] {a} + {b} + {c} [Tue Jul 16 06:05:56 2013] {a} + {b} + {c} [Tue Jul 16 06:05:58 2013] is this a sumbool [Tue Jul 16 06:05:58 2013] is this a sumbool [Tue Jul 16 06:06:01 2013] or is this something else? [Tue Jul 16 06:06:01 2013] or is this something else? [Tue Jul 16 08:13:38 2013] The_third_man: I'm not sure how to match it with ltac, but when I match it in regular definitions, I match for 'left EQ' and 'right NEQ' [Tue Jul 16 08:13:38 2013] The_third_man: I'm not sure how to match it with ltac, but when I match it in regular definitions, I match for 'left EQ' and 'right NEQ' [Tue Jul 16 08:14:02 2013] (assuming the sumbool is over equality, pick suitable names for the variables EQ and NEQ otherwise) [Tue Jul 16 08:14:02 2013] (assuming the sumbool is over equality, pick suitable names for the variables EQ and NEQ otherwise) [Tue Jul 16 10:25:30 2013] thm_prover: It should be a nested sumbool. You can [Set Printing All.], or just [Unset Printing Notations.], to figure out what it is. [Tue Jul 16 10:25:30 2013] thm_prover: It should be a nested sumbool. You can [Set Printing All.], or just [Unset Printing Notations.], to figure out what it is. [Tue Jul 16 10:26:21 2013] thm_prover: It's possible that your problem is that ltac is picking the wrong scope for the notation. Does matching ({_} + {_})%type rather than ({_} + {_}) work? [Tue Jul 16 10:26:21 2013] thm_prover: It's possible that your problem is that ltac is picking the wrong scope for the notation. Does matching ({_} + {_})%type rather than ({_} + {_}) work? [Tue Jul 16 10:27:35 2013] Oh, actually, nvm, I think there's a separate notation for [{_} + _]. So you have a sumbool inside, but a something else outside. I don't recall what it's called, but [Unset Printing Notations.] will tell you. [Tue Jul 16 10:27:35 2013] Oh, actually, nvm, I think there's a separate notation for [{_} + _]. So you have a sumbool inside, but a something else outside. I don't recall what it's called, but [Unset Printing Notations.] will tell you. [Tue Jul 16 12:22:20 2013] hi - so I'm just starting to use coq, and I've come across what's probably an obvious beginner mistake: I have a subgoal beginning with an existential qualification, how do I 'select' a value? [Tue Jul 16 12:22:20 2013] hi - so I'm just starting to use coq, and I've come across what's probably an obvious beginner mistake: I have a subgoal beginning with an existential qualification, how do I 'select' a value? [Tue Jul 16 12:30:38 2013] prophile: exists . [Tue Jul 16 12:30:38 2013] prophile: exists . [Tue Jul 16 12:40:58 2013] jgross: lovely, thanks [Tue Jul 16 12:40:58 2013] jgross: lovely, thanks [Wed Jul 17 16:18:56 2013] w/ 24 [Wed Jul 17 16:18:56 2013] w/ 24 [Wed Jul 17 16:18:58 2013] argh [Wed Jul 17 16:18:58 2013] argh [Wed Jul 17 22:40:51 2013] no, I [Wed Jul 17 22:40:51 2013] no, I [Wed Jul 17 22:40:55 2013] nevermind [Wed Jul 17 22:40:55 2013] nevermind [Fri Jul 19 03:21:52 2013] how important is the book coq'art to learning coq? [Fri Jul 19 03:21:52 2013] how important is the book coq'art to learning coq? [Fri Jul 19 04:40:47 2013] wagle: I have not read it yet, but have been meaning to get a copy. I've read most of ben pierce's software foundations course and a little bit of adam chlipala's cpdt [Fri Jul 19 04:40:47 2013] wagle: I have not read it yet, but have been meaning to get a copy. I've read most of ben pierce's software foundations course and a little bit of adam chlipala's cpdt [Sun Jul 21 02:26:43 2013] What is the SSReflect 'homepage'? [Sun Jul 21 02:26:43 2013] What is the SSReflect 'homepage'? [Sun Jul 21 02:28:03 2013] The mathematical-components page looks dead [Sun Jul 21 02:28:03 2013] The mathematical-components page looks dead [Sun Jul 21 02:28:17 2013] or maybe not? [Sun Jul 21 02:28:17 2013] or maybe not? [Sun Jul 21 05:39:13 2013] ezyang_: nowadays, probably that one http://www.msr-inria.fr/projects/mathematical-components/ but it's really a mess :( [Sun Jul 21 05:39:13 2013] ezyang_: nowadays, probably that one http://www.msr-inria.fr/projects/mathematical-components/ but it's really a mess :( [Sun Jul 21 16:02:41 2013] [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Wed Jul 24 08:40:01 2013] hey people... how do i go about proving things in the field of complex numbers in coq? [Wed Jul 24 08:40:01 2013] hey people... how do i go about proving things in the field of complex numbers in coq? [Wed Jul 24 08:40:16 2013] there does not appear to be a library supplied [Wed Jul 24 08:40:16 2013] there does not appear to be a library supplied [Wed Jul 24 08:40:46 2013] i found something via google, but it appeared to be an incomplete and confusing package [Wed Jul 24 08:40:46 2013] i found something via google, but it appeared to be an incomplete and confusing package [Wed Jul 24 08:40:58 2013] ("c-corn") [Wed Jul 24 08:40:58 2013] ("c-corn") [Wed Jul 24 08:42:04 2013] of course, everything in coq is incomplete. [Wed Jul 24 08:42:04 2013] of course, everything in coq is incomplete. [Wed Jul 24 08:42:05 2013] basti_: you could just use pairs of Rs from the stdlib [Wed Jul 24 08:42:05 2013] basti_: you could just use pairs of Rs from the stdlib [Wed Jul 24 08:42:38 2013] if there's no other package that has complex numbers yet [Wed Jul 24 08:42:38 2013] if there's no other package that has complex numbers yet [Wed Jul 24 08:43:13 2013] no i can't ;) i need a few functions and their properties... I'm working with 3rd order polynomials... [Wed Jul 24 08:43:13 2013] no i can't ;) i need a few functions and their properties... I'm working with 3rd order polynomials... [Wed Jul 24 08:43:40 2013] so at least some exponentiation laws should be included [Wed Jul 24 08:43:40 2013] so at least some exponentiation laws should be included [Wed Jul 24 08:45:14 2013] you can just assume what laws you need [Wed Jul 24 08:45:15 2013] you can just assume what laws you need [Wed Jul 24 08:49:53 2013] hmm [Wed Jul 24 08:49:53 2013] hmm [Wed Jul 24 10:01:46 2013] Eelis: bah! If not careful, you assume something inconsistent [Wed Jul 24 10:01:46 2013] Eelis: bah! If not careful, you assume something inconsistent [Wed Jul 24 10:03:35 2013] basti_: are algebraic complex numbers sufficient? In case so, you may want to look at the work of Cyril Cohen (it may be part of Ssreflect). [Wed Jul 24 10:03:35 2013] basti_: are algebraic complex numbers sufficient? In case so, you may want to look at the work of Cyril Cohen (it may be part of Ssreflect). [Wed Jul 24 10:03:47 2013] i think so. [Wed Jul 24 10:03:47 2013] i think so. [Wed Jul 24 10:06:50 2013] robbert: well i don't advocate assuming things carelessly :) [Wed Jul 24 10:06:50 2013] robbert: well i don't advocate assuming things carelessly :) [Wed Jul 24 10:10:27 2013] basti_: http://coqfinitgroup.gforge.inria.fr/doc/complex.html [Wed Jul 24 10:10:27 2013] basti_: http://coqfinitgroup.gforge.inria.fr/doc/complex.html [Wed Jul 24 10:29:01 2013] thank you for your hints :) [Wed Jul 24 10:29:01 2013] thank you for your hints :) [Thu Jul 25 00:59:48 2013] are the paperback and hardback editions of coq'art the same or different? [Thu Jul 25 00:59:48 2013] are the paperback and hardback editions of coq'art the same or different? [Thu Jul 25 10:39:12 2013] When I use proj_1 on an element of {s | P x} I get a let (a,_) := ... in a, even when using compute. Is this the expected behavior? [Thu Jul 25 10:39:12 2013] When I use proj_1 on an element of {s | P x} I get a let (a,_) := ... in a, even when using compute. Is this the expected behavior? [Thu Jul 25 10:39:28 2013] (I assume it is, but I don't know what reduction I have to do, and therefore assume I must be misunderstanding something.) [Thu Jul 25 10:39:28 2013] (I assume it is, but I don't know what reduction I have to do, and therefore assume I must be misunderstanding something.) [Thu Jul 25 10:40:51 2013] kmicinski: you probably want proj_sig1 or proj1_sig or something like that here, don't you? [Thu Jul 25 10:40:51 2013] kmicinski: you probably want proj_sig1 or proj1_sig or something like that here, don't you? [Thu Jul 25 10:40:57 2013] (I don't remember the exact name) [Thu Jul 25 10:40:57 2013] (I don't remember the exact name) [Thu Jul 25 10:42:07 2013] kmicinski: what is ...? [Thu Jul 25 10:42:07 2013] kmicinski: what is ...? [Thu Jul 25 10:43:01 2013] yes, I'm using proj1. ... is the fixpoint which constructs the proof for that proposition [Thu Jul 25 10:43:01 2013] yes, I'm using proj1. ... is the fixpoint which constructs the proof for that proposition [Thu Jul 25 10:43:15 2013] in my case, it proves the final store from a bigstep semantics [Thu Jul 25 10:43:15 2013] in my case, it proves the final store from a bigstep semantics [Thu Jul 25 10:43:25 2013] I'm trying to extract the final store in Set, rather than pro [Thu Jul 25 10:43:25 2013] I'm trying to extract the final store in Set, rather than pro [Thu Jul 25 10:43:50 2013] (I'm using sig rather than exists because I want to do computation with them, rather than proofs.) [Thu Jul 25 10:43:50 2013] (I'm using sig rather than exists because I want to do computation with them, rather than proofs.) [Thu Jul 25 10:45:44 2013] let (a, _) := exists_ending_state_bad1 [(0, 0), (1, 1)] in a [Thu Jul 25 10:45:44 2013] let (a, _) := exists_ending_state_bad1 [(0, 0), (1, 1)] in a [Thu Jul 25 10:45:47 2013] is what I end up with [Thu Jul 25 10:45:47 2013] is what I end up with [Thu Jul 25 10:45:51 2013] I want to end up with just the list. [Thu Jul 25 10:45:51 2013] I want to end up with just the list. [Thu Jul 25 10:46:07 2013] I understand this is equivalent (I *think*), but is there another reduction that needs to be performed? [Thu Jul 25 10:46:07 2013] I understand this is equivalent (I *think*), but is there another reduction that needs to be performed? [Thu Jul 25 10:47:27 2013] if you do [Thu Jul 25 10:47:27 2013] if you do [Thu Jul 25 10:47:28 2013] unfold exists_ending_state_bad1. [Thu Jul 25 10:47:28 2013] unfold exists_ending_state_bad1. [Thu Jul 25 10:47:34 2013] what is the result? [Thu Jul 25 10:47:34 2013] what is the result? [Thu Jul 25 10:54:07 2013] I get "Cannot coerce exists_ending_state_bad1 to an evaluable reference." [Thu Jul 25 10:54:07 2013] I get "Cannot coerce exists_ending_state_bad1 to an evaluable reference." [Thu Jul 25 10:54:15 2013] This was basically where I got stuck [Thu Jul 25 10:54:15 2013] This was basically where I got stuck [Thu Jul 25 10:55:19 2013] (This most confuses me because I can do "Print exists_end...." and get what I'd expect.) [Thu Jul 25 10:55:19 2013] (This most confuses me because I can do "Print exists_end...." and get what I'd expect.) [Thu Jul 25 10:55:53 2013] uh, do you have some kind of weird notations? [Thu Jul 25 10:55:54 2013] uh, do you have some kind of weird notations? [Thu Jul 25 10:56:34 2013] hm... I don't believe I've added anything nonstandard: if that's what you're asking. (I assume you think I may be clashing with Coq?) [Thu Jul 25 10:56:34 2013] hm... I don't believe I've added anything nonstandard: if that's what you're asking. (I assume you think I may be clashing with Coq?) [Thu Jul 25 10:57:02 2013] well, that error confuses me. are you using proofgeneral or something? maybe exit and reopen and try again? [Thu Jul 25 10:57:02 2013] well, that error confuses me. are you using proofgeneral or something? maybe exit and reopen and try again? [Thu Jul 25 10:57:28 2013] Ah, yes indeed I am. Thanks for the advice: I didn't think to check that and ProofGeneral does seem to be finicky sometimes :-) [Thu Jul 25 10:57:28 2013] Ah, yes indeed I am. Thanks for the advice: I didn't think to check that and ProofGeneral does seem to be finicky sometimes :-) [Thu Jul 25 10:59:23 2013] Hm, restarting ProofGeneral does no good. [Thu Jul 25 10:59:23 2013] Hm, restarting ProofGeneral does no good. [Thu Jul 25 10:59:38 2013] I'll try googling more and perhaps post to coq-club if I find no solution. [Thu Jul 25 10:59:38 2013] I'll try googling more and perhaps post to coq-club if I find no solution. [Thu Jul 25 11:01:37 2013] Aw heck, it was a stupid mistake, I typed Qed rather than Defined, making the definition opaque! [Thu Jul 25 11:01:37 2013] Aw heck, it was a stupid mistake, I typed Qed rather than Defined, making the definition opaque! [Thu Jul 25 11:01:52 2013] oh! [Thu Jul 25 11:01:52 2013] oh! [Thu Jul 25 11:01:53 2013] duh [Thu Jul 25 11:01:53 2013] duh [Thu Jul 25 11:01:56 2013] that explains everything [Thu Jul 25 11:01:56 2013] that explains everything [Thu Jul 25 11:02:13 2013] Yeah, just a force of habit I guess. [Thu Jul 25 11:02:13 2013] Yeah, just a force of habit I guess. [Thu Jul 25 11:03:45 2013] Thanks for entertaining my questions, all. [Thu Jul 25 11:03:45 2013] Thanks for entertaining my questions, all. [Thu Jul 25 14:26:57 2013] Is there a way to get both the notation "p ^" and "p ^ q" working at the same time, if they're in different scopes? [Thu Jul 25 14:26:58 2013] Is there a way to get both the notation "p ^" and "p ^ q" working at the same time, if they're in different scopes? [Thu Jul 25 14:28:49 2013] It only works if they're at the same level, right? [Thu Jul 25 14:28:49 2013] It only works if they're at the same level, right? [Thu Jul 25 19:22:06 2013] does anyone have a PDF version of SF book? [Thu Jul 25 19:22:06 2013] does anyone have a PDF version of SF book? [Fri Jul 26 08:55:39 2013] does anyone know of any automatic support, or clever tricks, to easily define a total order on some inductive type (just the standard subterm order, something like derive Ord in Haskell does) [Fri Jul 26 08:55:39 2013] does anyone know of any automatic support, or clever tricks, to easily define a total order on some inductive type (just the standard subterm order, something like derive Ord in Haskell does) [Fri Jul 26 17:37:14 2013] is Reset command removed? [Fri Jul 26 17:37:14 2013] is Reset command removed? [Fri Jul 26 18:45:35 2013] http://coq.inria.fr/distrib/V8.4/CHANGES Ctrl+F Reset [Fri Jul 26 18:45:35 2013] http://coq.inria.fr/distrib/V8.4/CHANGES Ctrl+F Reset [Fri Jul 26 19:48:24 2013] [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup [Sat Jul 27 11:44:58 2013] I don't understand how can simpl tactic move the goal from `S n' * 0 = 0' to `n' * 0 = 0' .. how does that work?? [Sat Jul 27 11:44:59 2013] I don't understand how can simpl tactic move the goal from `S n' * 0 = 0' to `n' * 0 = 0' .. how does that work?? [Sat Jul 27 11:47:08 2013] presumably it turns into 0 + n' * 0 = 0 by reduction [Sat Jul 27 11:47:09 2013] presumably it turns into 0 + n' * 0 = 0 by reduction [Sat Jul 27 11:47:17 2013] and then 0 + n' * 0 turns into n' * 0 by reduction [Sat Jul 27 11:47:17 2013] and then 0 + n' * 0 turns into n' * 0 by reduction [Sat Jul 27 11:50:38 2013] elliott: "presumably it turns into 0 + n' * 0 = 0 by reduction" where is 0 + n' * 0 ? [Sat Jul 27 11:50:39 2013] elliott: "presumably it turns into 0 + n' * 0 = 0 by reduction" where is 0 + n' * 0 ? [Sat Jul 27 11:52:05 2013] I presume mult is defined so that S m * n = n + m * n [Sat Jul 27 11:52:05 2013] I presume mult is defined so that S m * n = n + m * n [Sat Jul 27 11:52:18 2013] therefore S n' * 0 = 0 + n' * 0 [Sat Jul 27 11:52:18 2013] therefore S n' * 0 = 0 + n' * 0 [Sat Jul 27 11:52:27 2013] and 0 + n' * 0 = n' * o because 0 + n = n [Sat Jul 27 11:52:27 2013] and 0 + n' * 0 = n' * o because 0 + n = n [Sat Jul 27 11:52:29 2013] *0 [Sat Jul 27 11:52:29 2013] *0 [Sat Jul 27 11:54:25 2013] hmm, that makes sense [Sat Jul 27 11:54:25 2013] hmm, that makes sense [Sat Jul 27 11:54:31 2013] thanks [Sat Jul 27 11:54:32 2013] thanks [Sat Jul 27 11:54:41 2013] (also, you're right about mult's definition) [Sat Jul 27 11:54:41 2013] (also, you're right about mult's definition) [Sat Jul 27 11:58:34 2013] :) [Sat Jul 27 11:58:34 2013] :) [Sat Jul 27 12:09:37 2013] am I missing something or does SF book really have some exercises that require use of previously defined proofs before teaching how to use previously defined proofs? [Sat Jul 27 12:09:37 2013] am I missing something or does SF book really have some exercises that require use of previously defined proofs before teaching how to use previously defined proofs? [Sat Jul 27 18:09:56 2013] is `replace a with b' same as `assert (a = b) as H' and then proving H ? [Sat Jul 27 18:09:56 2013] is `replace a with b' same as `assert (a = b) as H' and then proving H ? [Sat Jul 27 18:42:39 2013] is there a way to search in standard libraries? for example I'm looking for functions like is_odd : nat -> bool and is_even : nat -> bool [Sat Jul 27 18:42:39 2013] is there a way to search in standard libraries? for example I'm looking for functions like is_odd : nat -> bool and is_even : nat -> bool [Sun Jul 28 11:09:27 2013] Ptival: I replied to your mail on Coqlist [Sun Jul 28 11:09:27 2013] Ptival: I replied to your mail on Coqlist [Sun Jul 28 11:11:12 2013] I think we do not have the same version of Coq, as I had to remove the " '{Denoted desc} " in your hvec'_ith definition. [Sun Jul 28 11:11:12 2013] I think we do not have the same version of Coq, as I had to remove the " '{Denoted desc} " in your hvec'_ith definition. [Sun Jul 28 11:12:45 2013] And I "cheated" as I did not start from your 166 line, but a little higher. [Sun Jul 28 11:12:45 2013] And I "cheated" as I did not start from your 166 line, but a little higher. [Sun Jul 28 11:19:11 2013] Ptival: are you still connected? [Sun Jul 28 11:19:11 2013] Ptival: are you still connected? [Sun Jul 28 11:27:09 2013] Zedrikov: yes [Sun Jul 28 11:27:09 2013] Zedrikov: yes [Sun Jul 28 11:27:13 2013] reading your answer now [Sun Jul 28 11:27:13 2013] reading your answer now [Sun Jul 28 11:27:24 2013] since the proof seems shorter, I am happy already :) [Sun Jul 28 11:27:24 2013] since the proof seems shorter, I am happy already :) [Sun Jul 28 11:28:55 2013] yes [Sun Jul 28 11:28:55 2013] yes [Sun Jul 28 11:29:08 2013] I have 8.3pl5 here so yeah, it's getting old [Sun Jul 28 11:29:08 2013] I have 8.3pl5 here so yeah, it's getting old [Sun Jul 28 11:32:50 2013] I think I am using 8.4, and my proof can be shortened by not defining P (thus writing directly the "change" with P inlined). That is not a great improvement though. [Sun Jul 28 11:32:50 2013] I think I am using 8.4, and my proof can be shortened by not defining P (thus writing directly the "change" with P inlined). That is not a great improvement though. [Sun Jul 28 11:45:03 2013] hmmm [Sun Jul 28 11:45:03 2013] hmmm [Sun Jul 28 11:45:13 2013] so if I just defined this thing, it would make everything easier> [Sun Jul 28 11:45:13 2013] so if I just defined this thing, it would make everything easier> [Sun Jul 28 11:45:14 2013] ? [Sun Jul 28 11:45:14 2013] ? [Sun Jul 28 11:46:04 2013] I see [Sun Jul 28 11:46:04 2013] I see [Sun Jul 28 11:58:56 2013] Ptival: so, will it help for your blog post? [Sun Jul 28 11:58:56 2013] Ptival: so, will it help for your blog post? [Sun Jul 28 12:00:44 2013] maybe I will reconsider the post :p [Sun Jul 28 12:00:44 2013] maybe I will reconsider the post :p [Sun Jul 28 12:00:56 2013] Zedrikov: so something I'm still missing is what case does [Sun Jul 28 12:00:56 2013] Zedrikov: so something I'm still missing is what case does [Sun Jul 28 12:01:03 2013] because destruct fails here [Sun Jul 28 12:01:03 2013] because destruct fails here [Sun Jul 28 12:02:05 2013] and it's weird how case turned a 'P natD ...' into a 'P boolD ...' for the bool case [Sun Jul 28 12:02:05 2013] and it's weird how case turned a 'P natD ...' into a 'P boolD ...' for the bool case [Sun Jul 28 12:04:17 2013] case is more low level than destruct. [Sun Jul 28 12:04:17 2013] case is more low level than destruct. [Sun Jul 28 12:05:04 2013] As far as I understand, "destruct" = "revert all hypothesis involving the destructured term; case term; intros all reverted hypothesis" [Sun Jul 28 12:05:04 2013] As far as I understand, "destruct" = "revert all hypothesis involving the destructured term; case term; intros all reverted hypothesis" [Sun Jul 28 12:06:38 2013] maybe that the "natD" inside of P is the problem. [Sun Jul 28 12:06:38 2013] maybe that the "natD" inside of P is the problem. [Sun Jul 28 12:08:05 2013] for the 'P natD' replaced into a 'P boolD' that is normal [Sun Jul 28 12:08:05 2013] for the 'P natD' replaced into a 'P boolD' that is normal [Sun Jul 28 12:09:05 2013] destruct on "t : term envD natD" has a consequence of replacing "natD" with "boolD" in some branches and "natD" in other, according to the inductive definition. [Sun Jul 28 12:09:05 2013] destruct on "t : term envD natD" has a consequence of replacing "natD" with "boolD" in some branches and "natD" in other, according to the inductive definition. [Sun Jul 28 12:10:17 2013] The heuristic of case/destruct is "generalize occurences as most as possible before destruct" [Sun Jul 28 12:10:17 2013] The heuristic of case/destruct is "generalize occurences as most as possible before destruct" [Sun Jul 28 12:10:58 2013] thus any occurence of "natD" will be generalized (as it is involved in the type dependences of t) before pattern matching. [Sun Jul 28 12:10:58 2013] thus any occurence of "natD" will be generalized (as it is involved in the type dependences of t) before pattern matching. [Sun Jul 28 12:11:43 2013] The difference between case and destruct is that 'case' won't generalize over hypothesis, whereas 'destruct' first does it. [Sun Jul 28 12:11:43 2013] The difference between case and destruct is that 'case' won't generalize over hypothesis, whereas 'destruct' first does it. [Sun Jul 28 12:11:54 2013] Most of the time 'destruct' is what you want. [Sun Jul 28 12:11:54 2013] Most of the time 'destruct' is what you want. [Sun Jul 28 12:12:43 2013] So when I said "my proof can be shortened by not defining P (thus writing directly the "change" with P inlined)", I was wrong. [Sun Jul 28 12:12:43 2013] So when I said "my proof can be shortened by not defining P (thus writing directly the "change" with P inlined)", I was wrong. [Sun Jul 28 12:13:00 2013] (as P contains an occurence of natD) [Sun Jul 28 12:13:00 2013] (as P contains an occurence of natD) [Sun Jul 28 12:13:14 2013] Ptival: does it answer some of your questions? [Sun Jul 28 12:13:14 2013] Ptival: does it answer some of your questions? [Sun Jul 28 12:14:38 2013] part of it yes [Sun Jul 28 12:14:38 2013] part of it yes [Sun Jul 28 12:15:43 2013] oh so the problem is that destruct catches the P := in context and tries to abstract over it [Sun Jul 28 12:15:43 2013] oh so the problem is that destruct catches the P := in context and tries to abstract over it [Sun Jul 28 12:16:26 2013] replacing the occurence of natD in it [Sun Jul 28 12:16:26 2013] replacing the occurence of natD in it [Sun Jul 28 12:16:28 2013] I see [Sun Jul 28 12:16:28 2013] I see [Sun Jul 28 12:16:40 2013] so in fact, I defined your P as a function earlier [Sun Jul 28 12:16:40 2013] so in fact, I defined your P as a function earlier [Sun Jul 28 12:16:48 2013] function that I can use in the definition of all_nats [Sun Jul 28 12:16:48 2013] function that I can use in the definition of all_nats [Sun Jul 28 12:17:09 2013] and which makes destruct behave like case, since now the definition isn't in the proof context [Sun Jul 28 12:17:09 2013] and which makes destruct behave like case, since now the definition isn't in the proof context [Sun Jul 28 12:17:13 2013] it's quite neat [Sun Jul 28 12:17:13 2013] it's quite neat [Sun Jul 28 12:32:42 2013] oh so the problem is that destruct catches the P := in context and tries to abstract over it ← Technically, it is not abstracted, but rather "let bound", that is, the goal is changed into a "let P := … in …", so there is no loss of information [Sun Jul 28 12:32:42 2013] oh so the problem is that destruct catches the P := in context and tries to abstract over it ← Technically, it is not abstracted, but rather "let bound", that is, the goal is changed into a "let P := … in …", so there is no loss of information [Sun Jul 28 12:35:57 2013] Oh, and I confirm that the natD inside of P is the problem. "Definition trick := natD." then "set (P := … fun (e:[[trick]]) => …" allows you to perform a "destruct t." instead of "case t." [Sun Jul 28 12:35:57 2013] Oh, and I confirm that the natD inside of P is the problem. "Definition trick := natD." then "set (P := … fun (e:[[trick]]) => …" allows you to perform a "destruct t." instead of "case t." [Sun Jul 28 13:06:57 2013] yes [Sun Jul 28 13:06:57 2013] yes [Sun Jul 28 13:07:04 2013] I answered on the list [Sun Jul 28 13:07:04 2013] I answered on the list [Sun Jul 28 13:07:06 2013] thanks! [Sun Jul 28 13:07:06 2013] thanks! [Sun Jul 28 13:12:40 2013] So, no blog post? [Sun Jul 28 13:12:40 2013] So, no blog post? [Sun Jul 28 16:00:05 2013] Zedrikov: not sure :\ [Sun Jul 28 16:00:05 2013] Zedrikov: not sure :\ [Sun Jul 28 16:00:07 2013] maybe [Sun Jul 28 16:00:07 2013] maybe [Sun Jul 28 16:01:07 2013] I kinda want to post so that when someone googles the error message, they can find explanations of the mechanism and examples of solutions [Sun Jul 28 16:01:07 2013] I kinda want to post so that when someone googles the error message, they can find explanations of the mechanism and examples of solutions [Sun Jul 28 16:01:37 2013] I never use your "dependant inversion" tactic. [Sun Jul 28 16:01:37 2013] I never use your "dependant inversion" tactic. [Sun Jul 28 16:01:59 2013] Mainly because I dislike the way inversion works. [Sun Jul 28 16:01:59 2013] Mainly because I dislike the way inversion works. [Sun Jul 28 16:02:13 2013] what do you not like? [Sun Jul 28 16:02:13 2013] what do you not like? [Sun Jul 28 16:02:26 2013] The generated term. [Sun Jul 28 16:02:26 2013] The generated term. [Sun Jul 28 16:02:31 2013] oh [Sun Jul 28 16:02:31 2013] oh [Sun Jul 28 16:02:52 2013] Often, it is easy to make things a lot cleaner by manually doing it. [Sun Jul 28 16:02:52 2013] Often, it is easy to make things a lot cleaner by manually doing it. [Sun Jul 28 16:03:09 2013] well usually when I care about the term I write it myself :s [Sun Jul 28 16:03:09 2013] well usually when I care about the term I write it myself :s [Sun Jul 28 16:03:30 2013] I guess that's why you use case :) [Sun Jul 28 16:03:30 2013] I guess that's why you use case :) [Sun Jul 28 16:03:34 2013] Yes, and I tend to always care about my terms ^^ [Sun Jul 28 16:03:34 2013] Yes, and I tend to always care about my terms ^^ [Sun Jul 28 16:03:49 2013] I also use destruct. [Sun Jul 28 16:03:49 2013] I also use destruct. [Sun Jul 28 16:04:14 2013] what are you working on that your terms matter? [Sun Jul 28 16:04:14 2013] what are you working on that your terms matter? [Sun Jul 28 16:04:30 2013] Nothing. It is just a game for me. [Sun Jul 28 16:04:34 2013] Nothing. It is just a game for me. [Sun Jul 28 16:04:47 2013] I do not like to produce terms I am unable to read. [Sun Jul 28 16:04:59 2013] But that is rather personal. [Sun Jul 28 16:05:23 2013] well, whatever floats your boat [Sun Jul 28 16:05:32 2013] I don't think it is bad practice to use inversion. It is just that I don't like to do it. [Sun Jul 28 16:05:34 2013] I've met all kinds of users [Sun Jul 28 16:06:29 2013] And in your problem, I do not see the practical gain in using "dependant inversion". [Sun Jul 28 16:06:55 2013] It seems my solution was about the same in length and idea. [Sun Jul 28 16:07:04 2013] oh yeah there's not much difference [Sun Jul 28 16:08:23 2013] Still, I always have hard time to figure out how to perform good inversion with dependant terms. [Sun Jul 28 16:09:51 2013] I solved your problem, but had to spend some time on it. It is rather frustrating to find out that you still have the same difficulties as when you began. And the final solution often does not seem that hard. [Sun Jul 28 16:09:51 2013] I solved your problem, but had to spend some time on it. It is rather frustrating to find out that you still have the same difficulties as when you began. And the final solution often does not seem that hard. [Sun Jul 28 16:11:46 2013] So at first glance I thought that the solution you choosed was exactly the same "dependant inversion" as the wrong you used at start. In fact there was a difference which looks rather a minor one. [Sun Jul 28 16:11:46 2013] So at first glance I thought that the solution you choosed was exactly the same "dependant inversion" as the wrong you used at start. In fact there was a difference which looks rather a minor one. [Sun Jul 28 16:12:41 2013] Correcting such an error should be easy, but still I took some time to me. [Sun Jul 28 16:12:41 2013] Correcting such an error should be easy, but still I took some time to me. [Sun Jul 28 16:24:22 2013] yeah now that I look at the answer I wonder how come I did not try that [Sun Jul 28 16:24:22 2013] yeah now that I look at the answer I wonder how come I did not try that [Sun Jul 28 16:27:06 2013] I thought I would learn some magic hackery by asking this question, instead I learned that I was being stupid :) [Sun Jul 28 16:27:06 2013] I thought I would learn some magic hackery by asking this question, instead I learned that I was being stupid :) [Sun Jul 28 16:48:19 2013] Hey don't say that. That would mean I am stupid too… [Sun Jul 28 16:48:19 2013] Hey don't say that. That would mean I am stupid too… [Mon Jul 29 15:53:56 2013] huh, I find it very hard to use tactics with storng dependent types, let alone making the generated term nice :s [Mon Jul 29 15:53:56 2013] huh, I find it very hard to use tactics with storng dependent types, let alone making the generated term nice :s [Mon Jul 29 18:15:04 2013] anyone happen to know if any cryptographic ciphers have been developed in coq? [Mon Jul 29 18:15:04 2013] anyone happen to know if any cryptographic ciphers have been developed in coq? [Mon Jul 29 18:15:11 2013] or any typed theorem provers, for that matter [Mon Jul 29 18:15:11 2013] or any typed theorem provers, for that matter [Mon Jul 29 18:15:33 2013] suppose noone has a good way to get directly from those definitions to efficient C, currently [Mon Jul 29 18:15:33 2013] suppose noone has a good way to get directly from those definitions to efficient C, currently [Mon Jul 29 18:17:24 2013] by designed, i mean "formulated in coq (or another system), proved to be free of known classes of vulnerabilities, and then somehow extracted an implementation" [Mon Jul 29 18:17:24 2013] by designed, i mean "formulated in coq (or another system), proved to be free of known classes of vulnerabilities, and then somehow extracted an implementation" [Mon Jul 29 18:17:57 2013] perhaps Galois' Cryptol is relevant to you, though it is not what you asked for. [Mon Jul 29 18:17:57 2013] perhaps Galois' Cryptol is relevant to you, though it is not what you asked for. [Mon Jul 29 18:18:21 2013] or at least, perhaps not quite directly [Mon Jul 29 18:18:21 2013] or at least, perhaps not quite directly [Mon Jul 29 18:18:30 2013] it's not for anything i'm working on, to clarify. just curious [Mon Jul 29 18:18:30 2013] it's not for anything i'm working on, to clarify. just curious [Mon Jul 29 18:18:34 2013] * eyes cryptol [Mon Jul 29 18:18:34 2013] * eyes cryptol [Mon Jul 29 18:19:18 2013] that's more or less what i'd pictured [Mon Jul 29 18:19:18 2013] that's more or less what i'd pictured [Mon Jul 29 18:19:43 2013] yes, perhaps it is closer than I thought [Mon Jul 29 18:19:43 2013] yes, perhaps it is closer than I thought [Mon Jul 29 18:20:07 2013] http://corp.galois.com/blog/category/cryptol has stuff. [Mon Jul 29 18:20:07 2013] http://corp.galois.com/blog/category/cryptol has stuff. [Mon Jul 29 18:20:28 2013] it is also at least slightly dependently-typed, IIRC [Mon Jul 29 18:20:28 2013] it is also at least slightly dependently-typed, IIRC [Mon Jul 29 18:21:27 2013] glad someone's at least trying it [Mon Jul 29 18:21:28 2013] glad someone's at least trying it [Tue Jul 30 03:04:15 2013] A language with dependent types may include references to programs inside of types. For instance, the type of an array might include a program expression giving the size of the array, making it possible to verify absence of out-of-bounds accesses statically. [Tue Jul 30 03:04:15 2013] A language with dependent types may include references to programs inside of types. For instance, the type of an array might include a program expression giving the size of the array, making it possible to verify absence of out-of-bounds accesses statically. [Tue Jul 30 03:04:16 2013] :O [Tue Jul 30 03:04:16 2013] :O [Tue Jul 30 03:16:51 2013] SrPx: cool huh? [Tue Jul 30 03:16:51 2013] SrPx: cool huh? [Tue Jul 30 14:24:33 2013] I want to write a match, but inside the match, I want to know something about the value, which sounds like a dependent match. [Tue Jul 30 14:24:33 2013] I want to write a match, but inside the match, I want to know something about the value, which sounds like a dependent match. [Tue Jul 30 14:25:13 2013] e.g., match e with | C x => ??? | D x => ??? end. I want ??? to be a proof that e = C x [Tue Jul 30 14:25:13 2013] e.g., match e with | C x => ??? | D x => ??? end. I want ??? to be a proof that e = C x [Tue Jul 30 14:25:21 2013] kmicinski: Chipala's book CPDT has patterns for that. [Tue Jul 30 14:25:21 2013] kmicinski: Chipala's book CPDT has patterns for that. [Tue Jul 30 14:25:43 2013] does it? I thought I'd read through and none applied, but I will read again. [Tue Jul 30 14:25:43 2013] does it? I thought I'd read through and none applied, but I will read again. [Tue Jul 30 14:25:50 2013] thanks, will check. [Tue Jul 30 14:25:50 2013] thanks, will check. [Tue Jul 30 14:25:54 2013] It's call the convey pattern [Tue Jul 30 14:25:54 2013] It's call the convey pattern [Tue Jul 30 14:25:58 2013] convoy* [Tue Jul 30 14:25:58 2013] convoy* [Tue Jul 30 14:26:04 2013] Ah, okay, thanks for the pointer! [Tue Jul 30 14:26:04 2013] Ah, okay, thanks for the pointer! [Tue Jul 30 14:26:38 2013] Thanks! I see it now. [Tue Jul 30 14:26:38 2013] Thanks! I see it now. [Tue Jul 30 14:31:27 2013] yeah it's there everywhere [Tue Jul 30 14:31:27 2013] yeah it's there everywhere [Tue Jul 30 14:32:06 2013] match e as _e return e = _e -> _ with C x => fun EQ => ... end (eq_refl e) [Tue Jul 30 14:32:06 2013] match e as _e return e = _e -> _ with C x => fun EQ => ... end (eq_refl e) [Tue Jul 30 14:34:38 2013] Damn, guess I haven't read that in a while. It definitely struck me as something I'd seen in CPDT, so I probably should have checked first. [Tue Jul 30 14:34:38 2013] Damn, guess I haven't read that in a while. It definitely struck me as something I'd seen in CPDT, so I probably should have checked first. [Tue Jul 30 14:36:23 2013] yeah it's used all over in CPDT [Tue Jul 30 14:36:23 2013] yeah it's used all over in CPDT [Tue Jul 30 14:36:31 2013] it's fairly common with dependent types [Tue Jul 30 14:36:31 2013] it's fairly common with dependent types [Tue Jul 30 14:36:59 2013] Right, I understand that it would definitely be something you want [Tue Jul 30 14:36:59 2013] Right, I understand that it would definitely be something you want [Tue Jul 30 14:37:11 2013] especially since I use it quite a bit and have to hack it up each time. [Tue Jul 30 14:37:11 2013] especially since I use it quite a bit and have to hack it up each time. [Tue Jul 30 21:12:22 2013] I feel the fact I want to do this implies there's something I'm not understanding, but is it possible to show Coq assignments to existential variables from (e.g.,) eapply? [Tue Jul 30 21:12:22 2013] I feel the fact I want to do this implies there's something I'm not understanding, but is it possible to show Coq assignments to existential variables from (e.g.,) eapply? [Tue Jul 30 21:13:01 2013] e.g., if I have as a hypothesis something x and a goal something ?234 [Tue Jul 30 21:13:01 2013] e.g., if I have as a hypothesis something x and a goal something ?234 [Tue Jul 30 21:13:36 2013] and I want to say "?234 := x". I assume the fact that nothing works implies that I'm misunderstanding these placeholders. [Tue Jul 30 21:13:36 2013] and I want to say "?234 := x". I assume the fact that nothing works implies that I'm misunderstanding these placeholders. [Tue Jul 30 21:15:34 2013] (I should say, that doing an "apply H", for example, doesn't work with a unification failure.) [Tue Jul 30 21:15:34 2013] (I should say, that doing an "apply H", for example, doesn't work with a unification failure.) [Tue Jul 30 21:17:13 2013] try "eapply" and such? [Tue Jul 30 21:17:13 2013] try "eapply" and such? [Tue Jul 30 21:17:39 2013] Hm, I got these metavariables from eapply [Tue Jul 30 21:17:39 2013] Hm, I got these metavariables from eapply [Tue Jul 30 21:18:44 2013] the FAQ hints at a solution: eapply might choose the wrong thing, and suggests using try solve [ ... ] [Tue Jul 30 21:18:44 2013] the FAQ hints at a solution: eapply might choose the wrong thing, and suggests using try solve [ ... ] [Tue Jul 30 21:19:39 2013] (actually, I get them from refine...) [Tue Jul 30 21:19:39 2013] (actually, I get them from refine...) [Tue Jul 30 21:53:45 2013] Ah, my problem is that I was changing the environment before trying to instantiate, an obviously bad thing. [Tue Jul 30 21:53:45 2013] Ah, my problem is that I was changing the environment before trying to instantiate, an obviously bad thing. [Wed Jul 31 02:47:45 2013] yeah you cannot instantiate existentials with variables that have appeared by manipulations later than the existential's creation [Wed Jul 31 02:47:46 2013] yeah you cannot instantiate existentials with variables that have appeared by manipulations later than the existential's creation [Wed Jul 31 02:48:08 2013] because obviously the value needs to exist at the moment the existential is introduced [Wed Jul 31 02:48:08 2013] because obviously the value needs to exist at the moment the existential is introduced [Wed Jul 31 05:03:47 2013] hello. I've got tired writing and debugging some highly-imperative (because of performance constraints) code, so I decided to write it in Coq, proving its properties. [Wed Jul 31 05:03:47 2013] hello. I've got tired writing and debugging some highly-imperative (because of performance constraints) code, so I decided to write it in Coq, proving its properties. [Wed Jul 31 05:03:57 2013] The whole idea of this code is: I have 3 arrays, I'm blitting from 1st array to 2nd and then from 2nd to 3rd, I have to minimize count and number of copied elements from 1st to 2nd array [Wed Jul 31 05:03:57 2013] The whole idea of this code is: I have 3 arrays, I'm blitting from 1st array to 2nd and then from 2nd to 3rd, I have to minimize count and number of copied elements from 1st to 2nd array [Wed Jul 31 05:04:05 2013] (while sometimes it's better to copy more elements to reduce the count of copy-command), and 3rd array should "receive" elements in the same order as they are in 1st array. (so 2nd array is a buffer.) [Wed Jul 31 05:04:05 2013] (while sometimes it's better to copy more elements to reduce the count of copy-command), and 3rd array should "receive" elements in the same order as they are in 1st array. (so 2nd array is a buffer.) [Wed Jul 31 05:04:11 2013] I need to reason about order (if 1st array contains [| 1; 2; 3 |], 3rd array "requested" 2 elements then 1 element, it should get [| 1; 2 |] and [| 3 |]). [Wed Jul 31 05:04:11 2013] I need to reason about order (if 1st array contains [| 1; 2; 3 |], 3rd array "requested" 2 elements then 1 element, it should get [| 1; 2 |] and [| 3 |]). [Wed Jul 31 05:04:12 2013] I need to prove that blits will respect arrays' sizes, and no uninitialized elements will be copied ever. How will you suggest me to approach this problem? [Wed Jul 31 05:04:12 2013] I need to prove that blits will respect arrays' sizes, and no uninitialized elements will be copied ever. How will you suggest me to approach this problem? [Wed Jul 31 05:05:22 2013] so, I'm planning to write code in Coq and then translate it to OCaml. [Wed Jul 31 05:05:22 2013] so, I'm planning to write code in Coq and then translate it to OCaml. [Wed Jul 31 05:06:19 2013] I understand that state of all arrays will be represented as some kind of { arr : list (option A) ; len : nat }. It will be explicitely passed everywhere. [Wed Jul 31 05:06:19 2013] I understand that state of all arrays will be represented as some kind of { arr : list (option A) ; len : nat }. It will be explicitely passed everywhere. [Wed Jul 31 05:06:50 2013] maybe I need some kind of regions with initialized data bound to each array. [Wed Jul 31 05:06:50 2013] maybe I need some kind of regions with initialized data bound to each array. [Wed Jul 31 05:17:57 2013] gdsfh: I don't understand the substance of your problem... what is the 2nd array for? [Wed Jul 31 05:17:57 2013] gdsfh: I don't understand the substance of your problem... what is the 2nd array for? [Wed Jul 31 05:27:05 2013] sgnb: 1st array is a file, 2nd array is a buffer, 3rd array is "consumer". [Wed Jul 31 05:27:05 2013] sgnb: 1st array is a file, 2nd array is a buffer, 3rd array is "consumer". [Wed Jul 31 05:27:57 2013] I have some knowledge about data stored in file, so I know how to cache it better than OS does. [Wed Jul 31 05:27:57 2013] I have some knowledge about data stored in file, so I know how to cache it better than OS does. [Wed Jul 31 05:31:10 2013] also in some cases I need to read a small number of bytes (because it's probable that I won't need to read more), in some cases I need to read whole clusters. [Wed Jul 31 05:31:10 2013] also in some cases I need to read a small number of bytes (because it's probable that I won't need to read more), in some cases I need to read whole clusters. [Wed Jul 31 05:32:32 2013] also there are cases when I need to bypass buffer (2nd array). So the code is complicated, with all these offsets and lengths. [Wed Jul 31 05:32:32 2013] also there are cases when I need to bypass buffer (2nd array). So the code is complicated, with all these offsets and lengths. [Wed Jul 31 17:51:56 2013] why adding X as first argument in recursive length' call here doesn't work: http://lpaste.net/91395 [Wed Jul 31 17:51:56 2013] why adding X as first argument in recursive length' call here doesn't work: http://lpaste.net/91395 [Wed Jul 31 17:53:21 2013] ? [Wed Jul 31 17:53:21 2013] ? [Wed Jul 31 17:54:32 2013] also I don't understand why this works: Check (cons 1 (nil nat)). but this doesn't Check (cons nat 1 (nil nat)). [Wed Jul 31 17:54:32 2013] also I don't understand why this works: Check (cons 1 (nil nat)). but this doesn't Check (cons nat 1 (nil nat)). [Wed Jul 31 17:56:04 2013] another example for things I don't undestand is why type argument to length' fails here Check (length' nat (cons 1 (nil nat))). removing that makes it working [Wed Jul 31 17:56:04 2013] another example for things I don't undestand is why type argument to length' fails here Check (length' nat (cons 1 (nil nat))). removing that makes it working [Wed Jul 31 18:33:44 2013] I hate it when I'm working on a proof, and I can't apply something, and then I try to do [admit] as a sanity check, and I get an "Illegal Application" error. [Wed Jul 31 18:33:44 2013] I hate it when I'm working on a proof, and I can't apply something, and then I try to do [admit] as a sanity check, and I get an "Illegal Application" error. [Wed Jul 31 18:36:32 2013] Gah, it was a [simpl in *]. [Wed Jul 31 18:36:33 2013] Gah, it was a [simpl in *]. [Wed Jul 31 18:55:02 2013] does anyone have comperssed/lower resolution versions of that videos http://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html [Wed Jul 31 18:55:02 2013] does anyone have comperssed/lower resolution versions of that videos http://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html [Wed Jul 31 20:43:53 2013] Is there a way to ask the typeclasses hint database for the priorities of all the lemmas in it? [Wed Jul 31 20:43:53 2013] Is there a way to ask the typeclasses hint database for the priorities of all the lemmas in it? [Thu Aug 1 02:15:42 2013] osa1: q1, you probably have "Set Implicit Arguments." somewhere, so Coq inferred that X can be deduced from lst, and does not ask for it [Thu Aug 1 02:15:42 2013] osa1: q1, you probably have "Set Implicit Arguments." somewhere, so Coq inferred that X can be deduced from lst, and does not ask for it [Thu Aug 1 02:17:20 2013] osa1: q2 is for same reason, nil cannot guess the type argument and needs it (in general, even though in this context it could guess it), while cons can figure it out from the parameter [Thu Aug 1 02:17:20 2013] osa1: q2 is for same reason, nil cannot guess the type argument and needs it (in general, even though in this context it could guess it), while cons can figure it out from the parameter [Thu Aug 1 02:18:18 2013] osa1: if you want to call a function with all its parameters, you can prefix it with @: Check (@length' nat (cons 1 (nil nat))). should work [Thu Aug 1 02:18:18 2013] osa1: if you want to call a function with all its parameters, you can prefix it with @: Check (@length' nat (cons 1 (nil nat))). should work [Thu Aug 1 05:23:22 2013] Ptival: thanks. you're right, I had "Set Implicit Arguments" in my code [Thu Aug 1 05:23:22 2013] Ptival: thanks. you're right, I had "Set Implicit Arguments" in my code [Thu Aug 1 05:56:23 2013] hello. I'm trying to work on problem I've asked about yesterday (file/buffer/consumer). https://gist.github.com/gdsfh/c8419599ec810af8caa6 -- I don't like existentials here. Local question: how can I turn them into subgoals? Global question: I'm not sure I chose a right way to represent data structures and invariants, could you please suggest something better? [Thu Aug 1 05:56:23 2013] hello. I'm trying to work on problem I've asked about yesterday (file/buffer/consumer). https://gist.github.com/gdsfh/c8419599ec810af8caa6 -- I don't like existentials here. Local question: how can I turn them into subgoals? Global question: I'm not sure I chose a right way to represent data structures and invariants, could you please suggest something better? [Thu Aug 1 07:24:04 2013] https://gist.github.com/gdsfh/74ac36c8f8dbf46d2373 -- why the body of ba' is hidden? It is required to prove current goal. How to proceed? [Thu Aug 1 07:24:04 2013] https://gist.github.com/gdsfh/74ac36c8f8dbf46d2373 -- why the body of ba' is hidden? It is required to prove current goal. How to proceed? [Thu Aug 1 07:36:08 2013] forget it; going to ask in coq-club. [Thu Aug 1 07:36:08 2013] forget it; going to ask in coq-club. [Thu Aug 1 07:50:30 2013] gdsfh: splitting the refine works, I guess you're hitting some kind of heuristic concerning Props [Thu Aug 1 07:50:30 2013] gdsfh: splitting the refine works, I guess you're hitting some kind of heuristic concerning Props [Thu Aug 1 07:51:27 2013] sgnb: "splitting the refine" -- please explain a bit, I can't understand what you mean. [Thu Aug 1 07:51:27 2013] sgnb: "splitting the refine" -- please explain a bit, I can't understand what you mean. [Thu Aug 1 07:51:38 2013] I'll answer on coq-club [Thu Aug 1 07:51:38 2013] I'll answer on coq-club [Thu Aug 1 07:53:27 2013] sgnb: thanks! [Thu Aug 1 07:53:27 2013] sgnb: thanks! [Thu Aug 1 07:58:27 2013] done [Thu Aug 1 07:58:27 2013] done [Thu Aug 1 08:13:44 2013] sgnb: it works! Great! I'll try to prove all subgoals here and then will answer in coq-club. [Thu Aug 1 08:13:44 2013] sgnb: it works! Great! I'll try to prove all subgoals here and then will answer in coq-club. [Thu Aug 1 12:45:52 2013] what is the difference between evidence and proof? are those same things? [Thu Aug 1 12:45:52 2013] what is the difference between evidence and proof? are those same things? [Thu Aug 1 12:52:20 2013] same thing. [Thu Aug 1 12:52:20 2013] same thing. [Thu Aug 1 12:52:43 2013] in type theory at least. [Thu Aug 1 12:52:43 2013] in type theory at least. [Thu Aug 1 13:03:05 2013] If there's any difference at all, I think it's that "evidence" places some emphasis on the fact that the proof is a concrete object of some sort to be manipulated or passed around. [Thu Aug 1 13:03:05 2013] If there's any difference at all, I think it's that "evidence" places some emphasis on the fact that the proof is a concrete object of some sort to be manipulated or passed around. [Thu Aug 1 13:04:27 2013] right, so evidence is relevant and proof need not be relevent. [Thu Aug 1 13:04:27 2013] right, so evidence is relevant and proof need not be relevent. [Thu Aug 1 15:19:57 2013] I often find myself wanting to apply an inductive hypothesis which requires proving the head of the hypothesis (possibly with automation), but I'm required to assert something I've copied and pasted: this feels kludegy [Thu Aug 1 15:20:23 2013] is it common to code up a tactic such as assert_head H; (possible automation here) [Thu Aug 1 15:21:06 2013] I guess it's not head, really, it's ... whatever the opposite is. [Thu Aug 1 15:22:01 2013] I've found myself having to do this several times too. Perhaps eapply IH would allow you to fill in the head afterwards? [Thu Aug 1 15:23:07 2013] hm, hadn't thought of that. I will try it! [Thu Aug 1 15:26:38 2013] ah hm, yes that works quite well in the case the head immediately applies to the goal, but there are also cases where I just want it in the context to apply to other things (about which I might not immediately foresee). [Thu Aug 1 15:27:08 2013] thanks however, ianjneu. [Thu Aug 1 15:19:58 2013] I often find myself wanting to apply an inductive hypothesis which requires proving the head of the hypothesis (possibly with automation), but I'm required to assert something I've copied and pasted: this feels kludegy [Thu Aug 1 15:20:23 2013] is it common to code up a tactic such as assert_head H; (possible automation here) [Thu Aug 1 15:21:06 2013] I guess it's not head, really, it's ... whatever the opposite is. [Thu Aug 1 15:22:01 2013] I've found myself having to do this several times too. Perhaps eapply IH would allow you to fill in the head afterwards? [Thu Aug 1 15:23:07 2013] hm, hadn't thought of that. I will try it! [Thu Aug 1 15:26:38 2013] ah hm, yes that works quite well in the case the head immediately applies to the goal, but there are also cases where I just want it in the context to apply to other things (about which I might not immediately foresee). [Thu Aug 1 15:27:08 2013] thanks however, ianjneu. [Fri Aug 2 19:36:46 2013] osa1 pasted “statement without assumptions” at http://lpaste.net/91465 [Fri Aug 2 19:37:14 2013] hi all. I'm trying to do an exercise from SF book, can anyone help me with this: http://lpaste.net/91465 (my problem is written in comments) [Fri Aug 2 19:38:22 2013] (btw, it's not clear from the pasted code but the error is thrown in line 6 -- in apply tactic) [Fri Aug 2 20:31:56 2013] Cale annotated “statement without assumptions” with “statement without assumptions (annotation)” at http://lpaste.net/91465#a91466 [Sat Aug 3 02:44:18 2013] hello [Sat Aug 3 10:06:37 2013] hello [Sat Aug 3 12:31:07 2013] Hi ezyang, just wanted to say I have learned a lot from your blog posts. Thank you. :) [Sat Aug 3 12:32:47 2013] bigos: Yay! :) [Sat Aug 3 13:06:34 2013] hey adrien, sorry afternoon nap [Sat Aug 3 13:06:46 2013] well, [make boot] will generate it [Sat Aug 3 13:07:08 2013] and we want to get rid of this code [Sat Aug 3 13:07:23 2013] and actually use just plain makefiles to compile ocamlbuild [Sat Aug 3 13:07:32 2013] without *any* bootstrapping [Sat Aug 3 13:10:13 2013] sorry not this channel! [Sat Aug 3 13:25:11 2013] apparently, CoRN is very brittle to build. I'm currently trying to do that. Sometimes a file fails, but this often does not appear to be reproducible [Sat Aug 3 15:50:08 2013] by using a recent version of math-classes, i can have corn build. It's still working. [Sun Aug 4 09:47:08 2013] for some reason I can't ever use apply tactic. even if if I can use rewrite -> H. reflexivity. I can't use apply H, it fails with some error messages. (I don't have a concrete example in mind right now) [Sun Aug 4 09:57:13 2013] osa1: if apply fails with some error message, then you need to modify its invocation somehow. It's obvious! [Sun Aug 4 09:58:20 2013] gdsfh: I don't think it's so obvious. rewrite -> H . reflexivity. works without and modifications on rewrite's invocation. why doesn't apply work then? (btw, I'm just a beginner) [Sun Aug 4 09:59:46 2013] (rough picture: ) rewrite H works when H : a = b, and it changes a to b in goal. "apply" does a different thing. If your H has type a = b, you don't need apply, you need rewrite. [Sun Aug 4 10:01:29 2013] osa1: maybe http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic8 will be interesting. If you don't understand it anyway, I'll construct a simple example of "what apply does". [Sun Aug 4 10:04:04 2013] I think I got it. it replaces goal with premises of applied term if the goal matches with applied term's conclusion. [Sun Aug 4 10:05:17 2013] I think what confused me is that the sentence in SF book saying something like "here apply does something similar like rewrite ... reflexivity." [Sun Aug 4 10:09:04 2013] yes, you've got it. I hadn't read SF, maybe someone will explain what is meant here. [Sun Aug 4 10:16:36 2013] gdsfh: are there any other good Coq books(in English, other than SF and Certified Programming ... books) [Sun Aug 4 10:21:21 2013] osa1: I don't know. Probably not. But why other books? Get a real problem and try to solve it! (looking in Coq manual and reading pieces of SF and CPDT you understand. (if you don't understand something, then get more practice and try it later.)) [Sun Aug 4 10:26:55 2013] uh. induction H as [|||a b]. fails with syntax error but induction H as [| | |a b] works ... [Sun Aug 4 10:26:57 2013] Hi. Can anyone tell me if it is possible, in Coq, to specify how to use case on a varible? Eg. telling Coq to try the values 8 and not 8 for a nat. [Sun Aug 4 10:27:48 2013] osa1: probably it finds token "|||" or "||" instead of single "|"'s. [Sun Aug 4 10:31:43 2013] lonkz: http://paste.in.ua/8533/ [Sun Aug 4 10:32:20 2013] gdsfh: what would be a nice motivating real problem to solve in Coq for a beginner? my main goal is to formalize programming languages and prove some useful theorems using that formalizations but that's probably too hard goal for a starter [Sun Aug 4 10:39:49 2013] osa1: don't know. Formalizing programming languages is a hard task for beginner (and for me too). I've tried to solve my current problems, sometimes "as in plain ML" but with some proofs. [Sun Aug 4 10:39:54 2013] osa1: but it'll be better if you'll ask this question in coq-club (I'm interested in simple problems too, for me and for some friends who are trying to learn Coq but have no interesting problems). [Sun Aug 4 10:42:36 2013] Thanks gdsfh, I'll have a look at it. [Sun Aug 4 10:45:39 2013] lonkz: anyway try to stick with "eq-dec"-returning functions (like "eq_nat_dec", look at its type) rather than bool-returning, since former functions return proofs that are usually useful later in developement. [Sun Aug 4 10:47:04 2013] something I did for practice was proving that there are infinitely many primes [Sun Aug 4 10:47:43 2013] I wasn't really looking for casing on nats but a more general approach that will work with my inductives. I think I'll just destruct everything to the largest component that I can do equality on and try "case (x == y)." [Sun Aug 4 10:49:41 2013] lonkz: maybe simple "match .. with" will help, if you are writing code, and case/destruct in proof mode? [Sun Aug 4 10:55:56 2013] gdsfh: That sounds interesting. I don't think I've tried it before. I'll give it a shot. Thanks. [Sun Aug 4 11:03:29 2013] lonkz: btw you can mix proof/code modes with "refine". Something like "refine (match H with | A a1 => _ | B b1 b2 => _ end)." and then add proofs for both cases. Arguments (a1, b1, b2) will be present in hypotheses. To gain more control on which goal you are proving, you can use "named goals" like here: https://gist.github.com/gdsfh/4578089 [Sun Aug 4 11:10:21 2013] Hah, that makes it much nicer. Thank you gdsfh. [Sun Aug 4 11:11:27 2013] but you can emulate this with "destruct H as [ [a1] [b1 b2] ]" or like. [Sun Aug 4 12:30:50 2013] I managed to compile CoRN now. However, there is not an "install" script supplied? How can I make it available to all users? [Sun Aug 4 15:28:41 2013] I want to a variant of refine which lets me fill in dependent arguments rather than just evar'ing them [Sun Aug 4 15:29:05 2013] I heard the new tactical libraries is supposed to let you do that, but I was wondering if I could hack around it in the meantime [Sun Aug 4 17:44:27 2013] does anyone know a mirror of this videos: http://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html it's just too slow from here [Sun Aug 4 17:46:41 2013] osa1: usually i just download them and watch from disk [Sun Aug 4 17:47:48 2013] Saizan: yeah I do that too but right now it says 5 hours to finish to download. (I downloaded some chapters before and it was fast but now for some reason it's very slow, maybe because I'm in some other place right now) [Sun Aug 4 18:29:43 2013] Why is not coq ridiculously fast? It seems to be the most analyzable language out there. I guess you could strip down an absurd amount of code with a good compiler [Sun Aug 4 18:49:56 2013] because it does not use a sufficiently good compiler? [Sun Aug 4 18:50:54 2013] first, it extracts to OCaml and Haskell, so probably different things happen and have to be taken care of [Sun Aug 4 18:51:32 2013] (Haskell's laziness might help...) [Sun Aug 4 18:52:05 2013] then it depends how well your types are mapped to the backend types [Sun Aug 4 18:52:09 2013] I guess [Sun Aug 4 19:06:24 2013] extracted code doesn't get optimized that well from the respective compilers, either, because of all the coercions [Sun Aug 4 19:34:41 2013] am I missing something or first part of "logical relations" course here http://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html missing few minutes in the beginning? [Sun Aug 4 20:39:41 2013] It might be [Sun Aug 4 21:30:20 2013] osnr: one of the logical relations lectures (maybe the first one) was missing the audio for the first few minutes because the lapel mic's battery was dead and someone had to go find a replacement [Sun Aug 4 21:30:41 2013] possibly they removed the corresponding video as well [Mon Aug 5 08:08:19 2013] are there plans to add ssreflect to opam? [Mon Aug 5 17:27:30 2013] so by curry-howard correspondence we know types in programming languages corresponds to proofs in logics, but then what does normalization(or evaluation, or reduction, or whatever) of types corresponds to in logic? [Mon Aug 5 17:28:27 2013] s/proofs/propositions [Mon Aug 5 17:28:27 2013] Cut-elimination [Mon Aug 5 17:28:40 2013] specifically, beta-reduction is cut-elimination [Mon Aug 5 17:28:52 2013] and normalization is cut-elimination from the entire proof [Mon Aug 5 17:29:13 2013] hmm, I know cuts from Prolog but not sure if it's related with cuts in real logic systems :-) where can I learn more about cuts in logics? [Mon Aug 5 17:29:21 2013] Nope, it's different [Mon Aug 5 17:29:43 2013] try this: http://www.cs.cmu.edu/~fp/courses/15317-f09/schedule.html [Mon Aug 5 17:30:10 2013] The basic idea is pretty simple though http://en.wikipedia.org/wiki/Cut-elimination_theorem [Mon Aug 5 17:32:05 2013] ezyang: so beta reduction corresponds to cut-elimination, does alpha conversion also apply to propositions/types? what does that corresponds to? [Mon Aug 5 17:33:04 2013] In logic, propositions are not named, so there is no to alpha-convert them [Mon Aug 5 17:33:10 2013] *way [Mon Aug 5 17:36:17 2013] ok so another question that stucked in my mind while watching some lectures from oragon plt school is predicativities of type systems. what does that mean, how do coq/agda/etc. handle that, does that only apply to dependent types etc. where can I learn more about that? [Mon Aug 5 17:36:21 2013] in FOL you still have binders (i.e. the quantifiers) and i think there's something similar to alpha-conversion for those if you get really formal [Mon Aug 5 17:37:16 2013] what would be eta reduction? that given P you can prove P? [Mon Aug 5 17:38:42 2013] osa1: Predicativity is a tricky one, I picked up what was going on from a variety of sources and I don't have something good to point you to. [Mon Aug 5 17:38:46 2013] Saizan: speaking of FOL, is being "constructive" logic or not orthogonal concept with FOL/other logics? what do we call logics that are not "constructive" ? [Mon Aug 5 17:38:53 2013] But I think understanding what it means for a type system to be impredicative is a good first step. [Mon Aug 5 17:39:56 2013] osa1: historically the opposition has been between constructive and classical, though the exact negation is just non-constructive [Mon Aug 5 17:41:13 2013] Saizan: ah so we categorize logics as being constructive or non-constructive? [Mon Aug 5 17:41:15 2013] osa1: often FOL will refer to the classical version, but you can have constructive first order logic just fine [Mon Aug 5 17:41:20 2013] hmm [Mon Aug 5 17:41:41 2013] so what about intuitionistic logics? [Mon Aug 5 17:42:33 2013] shergill: eta reduction also talks about terms, and doesn't show up when you don't have them. [Mon Aug 5 17:45:34 2013] osa1: intuitionistic X is most usually X but without excluded middle or equivalent, so it's often more specific than "constructive" which is basically "what a constructivist would accept" :) [Mon Aug 5 17:46:13 2013] Saizan: I thought constructive logics also don't have excluded middle [Mon Aug 5 17:47:32 2013] sorry if I'm asking too much unrelated questions but, what would happen if we suddenly have a proof of excluded middle in Coq? [Mon Aug 5 17:47:38 2013] osa1: yeah, but they might or might not have other principles, even ones you inconsistent with the corresponding classical logic [Mon Aug 5 17:48:15 2013] It is known that excluded middle is independent of constructive logic [Mon Aug 5 17:48:30 2013] what was the question re: predicativity? [Mon Aug 5 17:48:37 2013] So a non-axiomatic proof would probably imply it was inconsistent [Mon Aug 5 17:49:27 2013] Coq + EM is a consistent theory, but yeah there's something wrong if you can actually prove EM in Coq [Mon Aug 5 17:49:52 2013] (just phrasing it differently) [Mon Aug 5 17:50:08 2013] Predicativity goes back to Russell and Poincaré and has to do with disallowing circular definitions. [Mon Aug 5 17:50:54 2013] Original naive set theoretic paradoxes came about because of circularity that should be ruled out by predicative approach [Mon Aug 5 17:51:16 2013] which is why Russell introduced ramified type theory and Principia [Mon Aug 5 17:51:36 2013] But fascinatingly enough, it is OK to have impredicativity in a constructive logic [Mon Aug 5 17:51:58 2013] Coquand did work in this area and found a way to have an impredicative type theory stronger than system F, but you have to give up propositions-as-sets (or types) [Mon Aug 5 17:52:03 2013] hence Coq [Mon Aug 5 17:52:32 2013] ezyang: okay if you give up prop-as-type and do some "maintenance" to keep things sane [Mon Aug 5 17:53:09 2013] funnily enough, Coquand does not even prefer impredicative approach anymore allegedly (talking to him and others about it) [Mon Aug 5 17:53:21 2013] yeah I remember reading in some book that Principia Mathematica basically a work to remove circularities in mathematics ... ramified types is that infinite type tower thing, right? like we have in agda/coq [Mon Aug 5 17:53:23 2013] it clashes with sigmas too, iirc [Mon Aug 5 17:53:41 2013] as far as I understand, the original _use_ for impredicativity in Coq was because when it was first introduced there were no inductive types or pattern matching [Mon Aug 5 17:53:49 2013] so you had to use, e.g., "church encodings" [Mon Aug 5 17:53:54 2013] you often need impredicativity to make those work [Mon Aug 5 17:55:24 2013] There is kind of an open question as to whether "predicative maths" is powerful enough to do most of what we want in mathematics. I think Feferman wrote about this. Comparatively, predicative systems are weak. But so far it seems like it's enough for most major fields of math, with some reworking [Mon Aug 5 17:55:55 2013] osa1: yes, the type hierarchy we see in modern type systems goes back to Russell [Mon Aug 5 17:57:51 2013] another reason to prefer predicativity for a type theory or logical framework is because it is more conservative and becomes inconsistent with fewer axioms [Mon Aug 5 17:58:03 2013] OK, I should go learn more about this predicativity stuff. designing dependently typed language class in plt school also mentions that stuff but I don't understand anything. [Mon Aug 5 17:58:26 2013] (which is similar to the idea behind constructivism being more conservative than classicism) [Mon Aug 5 18:00:54 2013] Saizan: wasn't there some fuss about impredicative Set and inconsistency when EM was added? I don't remember for sure but thought I saw something about that a long time ago [Mon Aug 5 18:01:14 2013] or AC and some others even [Mon Aug 5 18:01:25 2013] darinm: i remember something like that too, tbh [Mon Aug 5 18:01:25 2013] (some version of AC) [Mon Aug 5 18:01:35 2013] what is AC? [Mon Aug 5 18:01:41 2013] axiom of choice [Mon Aug 5 18:02:06 2013] so anyway, take away is that impredicativity is less compatible with extra axioms [Mon Aug 5 18:02:46 2013] okay, thanks for all the answers [Mon Aug 5 18:03:08 2013] I'm going to learn more about impredicativity and continue watching plt school lectures later [Mon Aug 5 18:03:31 2013] one hopefully last question that stuck in my mind is that what makes Coq a convenient system to prove useful theorems .. for example, why Haskell isn't used for same purposes? [Mon Aug 5 18:04:31 2013] ezyang: one good way to see where impredicativity pops up is trying to write a system F interpreter in agda :] You can do it easily for STLC… [Mon Aug 5 18:04:37 2013] Haskell does not have dependent types. Haskell is not total so undefined is a proof of every theorem [Mon Aug 5 18:04:45 2013] both of these make it more or less completely useless for proving [Mon Aug 5 18:05:04 2013] right, any theorem is proved with 'undefined' in Haskell :] [Mon Aug 5 18:05:13 2013] elliott: let's exclude "undefined", can I then give proofs for some simple propositions? [Mon Aug 5 18:05:13 2013] osa1: in terms of logics you could say that haskell is propositional rather than predicative, hence all the pain of encoding stuff through GHC extensions [Mon Aug 5 18:05:34 2013] of course, Coq has some escape hatches too, but fewer… and they show up in RED in Proof General :] [Mon Aug 5 18:06:03 2013] I think not supporting dependent types only makes it less powerful theorem prover, right? because I cannot represent some propositions .. [Mon Aug 5 18:06:23 2013] osa1: you can use Haskell to write "proofs", sure. But you have no termination checker or productivity so you have less confidence. [Mon Aug 5 18:06:46 2013] osa1: you can prove a bunch of propositional stuff, e.g. ?djinn will search for proofs for propositional intuitionistic logic as haskell programs [Mon Aug 5 18:06:48 2013] and as Saizan pointed out, no dependency of types on terms means you can't encode much that's useful directly [Mon Aug 5 18:06:50 2013] osa1: if you want to write proofs that you can't verify the truth of, use pen and paper. [Mon Aug 5 18:07:02 2013] as a bonus, you won't have to fight Haskell's incredible limitations in what you can express [Mon Aug 5 18:07:10 2013] yeah [Mon Aug 5 18:07:21 2013] :-) [Mon Aug 5 18:07:39 2013] also, Coq or Agda's UI are way way better for proving [Mon Aug 5 18:07:58 2013] from something as simple as Agda's interactive holes and type display to Proof General's three-window mode and interactive tactics etc. [Mon Aug 5 18:09:19 2013] well that UI stuff doesn't work for me because I hate emacs and cannot use it ... Coq's vim plugin is pretty good though [Mon Aug 5 18:13:14 2013] agda has vim functionality too now allegedly [Mon Aug 5 18:21:00 2013] I use Emacs almost exclusively for proof general. it is worth it. [Mon Aug 5 21:25:39 2013] I have some ?A = ?B, where after reduction ?A and ?B are definitionally equal. [Mon Aug 5 21:26:00 2013] I would like to use this to type eq_refl, but Coq is rejecting it. What do I have to do to "make it compute"? [Mon Aug 5 21:43:24 2013] maybe simpl; reflexivity. and look at the proof term or something? [Mon Aug 5 21:43:31 2013] I don't quite know what you want [Mon Aug 5 21:44:49 2013] This ended up being a case of "Coq needs to infer a different definitionally equal term for an argument" [Mon Aug 5 22:32:01 2013] Well, this is a terrible error messagE: The term "q" has type "transport P p x .2 = y .2" while it is expected to have type "?756 = ?757". [Mon Aug 5 22:38:43 2013] ezyang: Try [Set Printing All]. My guess is that you'll find that you gave it a dependent function where it was expecting a non-dependent one. Also, by replacing [h] with [(h _)], I get the message """The term "ap (h y .1) q" has type "h y .1 (transport P p x .2) = h y .1 y .2" while it is expected to have type "transport P' (ap g p) (h x .1 x .2) = h y .1 y .2".""" [Mon Aug 5 22:39:16 2013] Well, I got further by filling in the implicit parameters [Mon Aug 5 22:40:50 2013] Also, here's a trick: When your types aren't type-checking, replace the last part of it with [Type], and then fill in your type bit by bit with [refine]. Like: [Mon Aug 5 22:40:50 2013] Theorem theorem2_6_5' {A A'} {P : A -> Type} {P' : A' -> Type} (g : A -> A') (h : forall a, P a -> P' (g a)) (x y : sigT P) (p : x.1 = y.1) (q : transport _ p x.2 = y.2) : Type. [Mon Aug 5 22:40:50 2013] pose (fun z => (g z.1; h z.1 z.2)) as f. [Mon Aug 5 22:40:50 2013] refine (ap f (path_sigma P x y p q) = _). [Mon Aug 5 22:40:50 2013] refine (path_sigma P' (f x) (f y) (ap g p) _). [Mon Aug 5 22:40:50 2013] unfold f; simpl. [Mon Aug 5 22:40:50 2013] exact (ap (h _) q). [Mon Aug 5 22:42:55 2013] Nifty! [Mon Aug 5 22:43:23 2013] I assume that the proofscript you pasted isn't supposed to work? [Mon Aug 5 22:44:20 2013] correct. It gave me the error message I mentioned. But it might help you to figure out what you want, because it's more interactive. [Mon Aug 5 22:46:12 2013] So, I should be able to get this from q. [Mon Aug 5 22:50:10 2013] ho ho ho [Mon Aug 5 23:11:17 2013] Ohhh I screwed up my dfn's [Mon Aug 5 23:16:19 2013] Wait, no, these are equivalent [Tue Aug 6 06:56:38 2013] let's say I have a goal something like `some_constructor arg1 arg2 = some_constructor arg3 arg4` is there a way to reduce it to two goals `arg1 = arg3` and `arg2 = arg4` ? [Tue Aug 6 07:00:05 2013] hello. I have something like "Require Import ZArith. Open Scope Z_scope. Goal forall (n : Z) (H1 : n >= 3) (H2 : n <= 5), Z.", I want to match 3, 4, 5 and to prove that for other cases "False_rect _ _" is a proof of their impossibility. [Tue Aug 6 07:00:09 2013] But matching "Z_dec n 3", then "Z_dec n 4", then "Z_dec n 5" is a boring task. Do you know any nice ways to write this code? [Tue Aug 6 07:32:09 2013] osa1: there's a tactic called "f_equal", which will do exactly this [Tue Aug 6 07:33:19 2013] (as a matter of fact, it's a little more general: for any goal of the form "f x = g y", it'll produce the goals "f = g" and "x = y" -- but yours is a special case of this) [Tue Aug 6 07:38:24 2013] fisi: thanks [Tue Aug 6 07:38:36 2013] no problem [Tue Aug 6 07:42:33 2013] can anyone help me with this http://lpaste.net/91595 [Tue Aug 6 07:50:58 2013] osal: can't you just apply beq_nat_refl? [Tue Aug 6 07:52:26 2013] beta: that works but I'm wondering how to do what I wrote in the comment [Tue Aug 6 07:54:09 2013] I think you're question can be generalized into "how can I apply a lemma P -> Q on the goal P" [Tue Aug 6 07:54:13 2013] is it true? [Tue Aug 6 07:56:41 2013] yeah, I guess [Tue Aug 6 07:58:07 2013] whoa, won't you need the implication to go in the other direction? [Tue Aug 6 07:58:13 2013] well, that's not logically possible :-) [Tue Aug 6 07:58:23 2013] sorry, I mean, impossible [Tue Aug 6 07:58:56 2013] ah yes, I misread beta's comment, and he's right, that's not possible. [Tue Aug 6 08:00:39 2013] when applying a lemma in a goal one is doing "backward reasoning", that is, if you have a lemma L : P -> Q and goal Q, by applying L you are left to prove P [Tue Aug 6 08:01:12 2013] yeah, that makes sense. I'm a bit confused, thanks for explanation. [Tue Aug 6 08:01:52 2013] with respect to the problem at hand, you can still use the lemma [Tue Aug 6 08:01:53 2013] Lemma beq_nat_true_iff : forall x y, beq_nat x y = true <-> x=y. [Tue Aug 6 08:02:10 2013] to *rewrite* your goal into p = p [Tue Aug 6 08:17:30 2013] I'm having trouble understanding inductives, http://lpaste.net/91600 why I'm getting this error here [Tue Aug 6 08:17:39 2013] I'm trying to do palindrome exercise from Software Foundations book [Tue Aug 6 08:18:41 2013] (btw, first constructor in this code should be pal_empty : pal nil) [Tue Aug 6 08:21:24 2013] the reason is because you're making both X and the list parameters of the inductive type [Tue Aug 6 08:22:03 2013] but you want to provide the list yourself, that is, the type is not parametric on the list [Tue Aug 6 08:22:04 2013] try changing the first line of declaration to "Inductive pal (X : Set) : list' X -> Prop :="; as far as I recall, there's some restrictions on what you can do with binding arguments outside the constructors of the inductive definitions [Tue Aug 6 08:23:30 2013] yeah, that worked [Tue Aug 6 08:23:44 2013] but I don't understand why [Tue Aug 6 08:24:13 2013] to me this two kinds of declarations specifies same types [Tue Aug 6 08:24:20 2013] but probably I'm wrong [Tue Aug 6 08:27:18 2013] nah, it's like what beta said: the parameters of an inductive type are not allowed to change between the constructors. It's really a shorthand (everything that's expressible with the parameters is also expressible without using them) -- and a sort of sanity check if you want the inductive type to be parametric in one of the arguments. [Tue Aug 6 08:28:02 2013] as a (probably dry) source of information you can check http://coq.inria.fr/distrib/current/refman/Reference-Manual006.html#sec186 [Tue Aug 6 09:59:18 2013] it's very annoying that Coq doesn't allow name shadowing, if I have a 'a' in a pattern match and I also have a 'a' as a constructor I get weird error messages when I use that matched name 'a' [Tue Aug 6 10:00:28 2013] osa1: how would Coq know the difference? [Tue Aug 6 10:01:30 2013] nonlinear patterns kind of ruin that expectation. [Tue Aug 6 10:01:37 2013] ianjneu: same as how other languages(for instance Haskell) that know the difference know the difference [Tue Aug 6 10:01:46 2013] what is a nonlinear pattern? [Tue Aug 6 10:02:44 2013] a matching pattern that allows duplicate binders, which introduces the constraint that whatever matches both must be equal. [Tue Aug 6 10:03:12 2013] hmm [Tue Aug 6 10:03:53 2013] Racket's pattern matching allows what you want, but only because it doesn't allow binders as match heads. [Tue Aug 6 10:04:59 2013] This is why I want prefix notation as the default syntax for languages, and fancy syntax just built on top. [Tue Aug 6 10:05:47 2013] It makes the language design much more flexible and structured. [Tue Aug 6 10:10:56 2013] Just checked - Coq doesn't allow nonlinear patterns. Yup, just turns out to be bad design. [Tue Aug 6 10:22:21 2013] ianjneu: "constraint that whatever matches both must be equal" -- maybe it's because of a flexible approach to equality? Often " = " is not what one wants. [Tue Aug 6 10:26:07 2013] gdsfh: I wasn't saying the lack of nonlinear patterns is a bad design decision. [Tue Aug 6 10:26:36 2013] HoTT wasn't around when Coq was first created ;) [Tue Aug 6 10:27:29 2013] ianjneu: interesting, what HoTT provides for such patterns? [Tue Aug 6 10:29:51 2013] Well, you would be able to use equivalences instead of definitional equality. It still would be trickily behaved, since you'd need to inform the unifier of equivalence proof constructors in order for the match to happen (or have a cumbersome syntax for constructing the proof within the match pattern itself) [Tue Aug 6 10:32:38 2013] I suppose the same is the case for propositional equality too. [Tue Aug 6 10:32:51 2013] I just really like the univalence axiom. [Tue Aug 6 11:42:07 2013] Haskell knows the difference because the names available to variables and the names available to constructors are disjoint. [Tue Aug 6 11:42:40 2013] (in particular, because constructors must start with an uppercase letter, and variables must not) [Tue Aug 6 11:43:02 2013] same as ocaml... i found the behaviour in coq quite surprising [Tue Aug 6 11:43:14 2013] But yeah, you'd expect shadowing to occur. [Tue Aug 6 12:35:54 2013] are there any reading on simulation of digital circuits in Coq? I've tried to use corecursive streams, but got stuck on RS-trigger (all my CoFixpoints I've tried to write were not accepted by Coq). Also I don't know whether I'm going a right thing, so I'd prefer to read something useful on this topic. [Tue Aug 6 13:09:52 2013] gdsfh: write a step function for your circuit and reason about subject reduction. [Tue Aug 6 13:22:21 2013] ianjneu: thanks for suggestion. It would be much easier. Also it's interesting to know what I lose here, compared to coinductive streams? (and what I gain, except ease?) [Tue Aug 6 13:52:05 2013] gdsfh: I don't think you lose anything. I don't know what your input stream would be, or if you expect to produce a stream of machine states, but to reason about steps of a circuit, you need more sophisticated methods than just coinduction on infinite traces. What I've seen is more refinement-based bisimulations based on a well-founded measure and a step function. [Tue Aug 6 13:54:41 2013] c.f. Pete Manolios' dissertation on WEB refinement in the ACL2 theorem prover. [Tue Aug 6 13:55:22 2013] ianjneu: good, I'll try to write code with step functions (at least I'll be able express RS-trigger, I think). Also will read the paper you've noted. [Tue Aug 6 13:56:34 2013] if you plan on verifying a circuit with out-of-order multi-instruction retirement, there is nothing yet published on what is the proper correctness criteria. [Tue Aug 6 13:57:09 2013] Pete's student Mitesh Jain is working on that, but his work is currently unpublished. [Tue Aug 6 14:06:49 2013] ianjneu: no, I want to play with simple circuits only. For now, what I want to prove that given scheme will stabilize and give reasonable output within N clock ticks after inputs were changed. (but I need to _construct_ the scheme first, here's the problem... now solved with your help, I think.) [Tue Aug 6 14:09:45 2013] Usually it's easier to verify the circuit-constructing functions with respect to the circuit evaluation function than individual circuits. [Tue Aug 6 14:18:08 2013] ianjneu: noted, thanks. But I need to read that paper and implement these step functions and evaluator first. [Tue Aug 6 14:24:57 2013] gdsfh: Pete has some homework assignments for our freshmen that have them build a netlist for an adder, and an evaluator for a netlist, and then show that addition of encoded numbers is equivalent to real addition of those numbers (within the proper size bounds). [Tue Aug 6 14:25:16 2013] Might be a good exercise for you. [Tue Aug 6 14:26:12 2013] ianjneu: really, I'll need adders anyway. [Tue Aug 6 14:40:47 2013] ianjneu: I'm looking at http://www.ccs.neu.edu/home/pete/research.html and can't find anything about simple circuits like NOR/NAND gates, RS-triggers and so on; here are more high-level things, with processor instructions at least. Either I've failed to find the right paper (please help, in this case), or his works won't help me at all. [Tue Aug 6 14:49:15 2013] how to covert goals from [a /\ b] to goals [a; b] ? [Tue Aug 6 14:55:55 2013] osa1: "split." [Tue Aug 6 14:57:23 2013] thanks. now I'm trying to unfold '<' but cannot find it's name .. how can I unfold '<' ? [Tue Aug 6 15:07:48 2013] lt [Tue Aug 6 15:10:20 2013] hmm, unfold lt does do anything [Tue Aug 6 15:14:42 2013] osa1: which theory of numbers are you using? [Tue Aug 6 15:15:21 2013] gdsfh: It's been given as a homework, so it's not a research paper. Just go from what I said as a spec. [Tue Aug 6 18:12:38 2013] can anyone recommend me some papers to help me understand how to make inference rules "syntax driven", why do we need to have distinct type inferable and type checkable terms(or alternatively annotate every term) etc. [Tue Aug 6 18:15:08 2013] osa1: Honestly, you should just try to implement it for yourself and see. [Wed Aug 7 01:18:03 2013] This looks very wrong... https://gist.github.com/leroux/6171397 [Wed Aug 7 01:18:11 2013] Any suggestions to remedy this incomplete proof? [Wed Aug 7 01:56:46 2013] leroux: be lazier. http://sprunge.us/WDNK [Wed Aug 7 01:57:43 2013] elliott: Is there a way for me to expand to something I can understand right now? I started working through Software Foundations today. [Wed Aug 7 01:58:00 2013] I don't think auto will be introduced for awhile. [Wed Aug 7 02:00:26 2013] sure, one second [Wed Aug 7 02:02:37 2013] leroux: http://sprunge.us/ULeX [Wed Aug 7 02:03:09 2013] Thanks elliott. [Wed Aug 7 02:03:20 2013] So, intros are not always needed? [Wed Aug 7 02:03:37 2013] if you introduce parameters before the colon, yeah. [Wed Aug 7 02:03:51 2013] you can also "destruct x" if you named "x" with a "forall" in your current type and it'll automatically be introduced [Wed Aug 7 02:04:47 2013] Ahh, okay, thanks. [Wed Aug 7 02:06:34 2013] btw, maybe the book wants you to prove this in some other way. but I think it's better to "discriminate" when possible rather than taking advantage of inconsistent equalities less directly [Wed Aug 7 02:06:55 2013] and I don't see much point in using lemmas for things that can be proved so easily with simple computation [Wed Aug 7 02:08:35 2013] Ahh, okay. [Wed Aug 7 02:08:42 2013] So.. I see that you use p || q. [Wed Aug 7 02:08:52 2013] In a way, it can be seen as automation. [Wed Aug 7 02:09:02 2013] Not in the sense of 'auto'. [Wed Aug 7 02:09:40 2013] sure [Wed Aug 7 02:09:45 2013] (p; q) is automation too [Wed Aug 7 02:09:55 2013] but tactics are all about automation, the alternative is crafting proof terms by hand :) [Wed Aug 7 02:10:15 2013] I've only been using intros, destruct, rewrite, reflexivity, simpl. [Wed Aug 7 02:11:18 2013] you can probably do it with rewrite if you really want to [Wed Aug 7 02:11:19 2013] The exercises are so trivial that I'd think that they are supposed to be solved with a limited set of keywords. [Wed Aug 7 02:11:29 2013] So, I was using rewrites... [Wed Aug 7 02:11:35 2013] But it looked very...wrong. [Wed Aug 7 02:11:44 2013] I think discriminate is a great thing to learn early :) [Wed Aug 7 02:11:56 2013] I was doing an intros H every time there was a contradiction. [Wed Aug 7 02:12:02 2013] And then I would rewrite with H. [Wed Aug 7 02:12:18 2013] https://gist.github.com/leroux/6171397 [Wed Aug 7 02:12:50 2013] Is that what you mean by it could possibly be done by rewrites? [Wed Aug 7 02:15:01 2013] Anyways, thanks elliott. I'll start using discriminate now. [Wed Aug 7 02:15:29 2013] I mean that you have false = true or true = false in context [Wed Aug 7 02:15:33 2013] and your goal is either false = true or true = false [Wed Aug 7 02:15:49 2013] so it should be easy if you don'tw ant to just reject the contradiction outright. [Wed Aug 7 02:16:00 2013] Ahh, okay. [Wed Aug 7 08:35:51 2013] I have a question about the HoTT branch, what is the "rigid" type in evd.mli ? [Wed Aug 7 08:36:34 2013] I need to create a new unification variable, and I need to specify how "rigid" it has to be [Wed Aug 7 13:49:58 2013] strange thing. "subst." gives "Error: enr is used in conclusion.", while "subst enr." works ok. Now I'm using 8.3pl4, probably it's fixed now with new tactics system, but maybe you know why it happens? (now I'm using "Ltac subst_all := match goal with A := _ |- _ => subst A; subst_all | _ => idtac end.", it works.) [Wed Aug 7 13:50:47 2013] (also I can't construct simple example where "subst." fails but "subst that_identifier." succeeds.) [Wed Aug 7 14:01:50 2013] beta: My guess is that rigid means ones of the following: (1) it's [Set] or [Prop], i.e., it's a fixed universe; or (2) it's universe monomorphic, i.e., all the universes that appear in it are fixed. In both cases, I'd guess that you want it to be not rigid, unless you pick up whether or not you're in a rigid context from the environment, somehow. But I haven't looked at the code, so I might be completely wrong. [Wed Aug 7 14:04:59 2013] Thanks jgross, that was my guess. But the story is a bit more complicated, because you can either have a rigid, flexible, and "flexible alg" variable [Wed Aug 7 14:05:25 2013] the distinction among the last two is a mystery to me [Wed Aug 7 14:07:43 2013] Perhaps flexible means that it's a non-fixed universe (like [Type_n]), and flexible alg means that it's something like [max(Type_n, Type_{m + 1})] (i.e., not rigid, and not a single universe variable, but an algebraic expression of other universe variables)? [Wed Aug 7 14:07:59 2013] But I have to run. I'll check my logs later and reply to anything you say. [Wed Aug 7 14:08:35 2013] thanks [Wed Aug 7 14:45:46 2013] I don't understand what is asked in Software Foundations classical axioms exercise. is it possible to prove equalities of propositions? [Wed Aug 7 14:46:27 2013] this chapter: http://www.cis.upenn.edu/~bcpierce/sf/Logic.html classical_axioms exercise [Wed Aug 7 14:46:56 2013] Your theorems will look like [Wed Aug 7 14:47:08 2013] Theorem f1 : peirce -> classic [Wed Aug 7 14:47:14 2013] Theorem f2 : classic -> excluded_middle [Wed Aug 7 14:47:15 2013] etc [Wed Aug 7 14:48:00 2013] can also use <-> [Wed Aug 7 14:48:25 2013] hmm, let me try [Wed Aug 7 14:49:46 2013] elliott: Well, <-> is kind of inefficient [Wed Aug 7 14:50:25 2013] ok so in logic context equality means <-> ? [Wed Aug 7 14:51:25 2013] Well, for some very expansive definition of "equality" [Wed Aug 7 14:58:33 2013] inefficient? [Wed Aug 7 14:58:50 2013] osa1: (p <-> q) means (p -> q /\ q -> p), bi-implication. [Wed Aug 7 14:59:08 2013] it's true that considering propositions as booleans this corresponds to equality (as xor does to inequality), and that <-> is an equivalence relation [Wed Aug 7 14:59:22 2013] and that in homotopy type theory you get something very like <-> for equality on propositions. [Wed Aug 7 14:59:53 2013] elliott: As in, amount of proof effort necessary ;-) [Wed Aug 7 15:00:07 2013] If you want to show A B C D E equiv, usual method is to do a chain of some sort [Wed Aug 7 15:00:16 2013] well, sure [Wed Aug 7 18:00:37 2013] osa1 pasted “how does destruct tactic work?” at http://lpaste.net/91640 [Wed Aug 7 18:00:48 2013] can anyone help me with this: http://lpaste.net/91640 [Wed Aug 7 18:10:40 2013] another question: let's say I'm looking for a proof for `forall n m, S n = S m -> n = m`, is there a command for search this? (I'm looking for an easier way than searching through documentation manually) [Wed Aug 7 18:14:29 2013] osa1: when the hypothesis being destructed is of form "... -> False" [Wed Aug 7 18:14:50 2013] then Coq assumes that you're trying to prove false, and simply requests you to show that 0 = 0 is true [Wed Aug 7 18:14:57 2013] It's like exfalso and then apply [Wed Aug 7 18:15:22 2013] it doesn't matter what your goal was, if you find a contradiction, the principle of explosion applies [Wed Aug 7 18:15:42 2013] Try SearchPattern [Wed Aug 7 18:15:52 2013] Though I find it to be rather finicky [Wed Aug 7 18:18:56 2013] ezyang: what is principle of explosion? prove anything from contradiction? [Wed Aug 7 18:19:46 2013] yeppers [Wed Aug 7 18:22:22 2013] ok, thanks. another question: if I remove `forall` keyword from Coq, does that give me a ML type system? [Wed Aug 7 18:22:57 2013] Ill-formed. Am I allowed to do: Definition foo (x : nat) := ...? [Wed Aug 7 18:23:40 2013] yes [Wed Aug 7 18:24:04 2013] Well, it's equivalent to Definition foo := forall x : nat, ;-) [Wed Aug 7 18:26:34 2013] hmm. [Wed Aug 7 18:27:14 2013] If you sufficiently make your requirement more stringent, yes, Coq will no longer be a dependently typed language [Wed Aug 7 18:27:27 2013] Though it's probably not true that it would have ML's type system. [Wed Aug 7 18:28:45 2013] yeah it probably wouldn't be exactly the ML type system, I meant something similar. "make your requirement more stringent" what do you mean by that? [Wed Aug 7 18:29:09 2013] Well, you could say, "No pi-types, only arrow types" [Wed Aug 7 18:29:11 2013] ezyang: "Definition foo (a : A) := B a" is equivalent to "Definition foo := fun a : A => B a", not "Definition foo := forall a : A, B a" [Wed Aug 7 18:29:24 2013] oh oops -_- [Wed Aug 7 18:30:00 2013] ezyang: actually I was trying to say that but couldn't figure out how to remove pi-types [Wed Aug 7 18:30:11 2013] I thought forall was for specifying pi types [Wed Aug 7 18:30:20 2013] Yeah, it is [Wed Aug 7 18:30:44 2013] then removing it gives me a language without dependent types? [Wed Aug 7 18:40:02 2013] you also end up without polymorphism. [Wed Aug 7 18:40:38 2013] btw, I don't know what ezyang is saying. [Wed Aug 7 18:40:42 2013] those two definitions are not equivalent. [Wed Aug 7 18:40:47 2013] oh [Wed Aug 7 18:40:49 2013] jgross said so [Wed Aug 7 18:50:27 2013] ezyang: https://gist.github.com/JasonGross/6179650 <- the type of theorem2_6_5'. At least if you're willing to use [match]. I'll leave it up to you to translate that back into transports :-P [Wed Aug 7 18:51:06 2013] :-P [Wed Aug 7 18:51:19 2013] What an ugly theorem. [Wed Aug 7 18:59:56 2013] Indeed. Maybe favonia or someone else has an idea of how it's supposed to look homotopically. [Wed Aug 7 19:01:47 2013] If you're willing to cheat, you can look at projT2_path_sigma, which might be what you're looking for here. Or maybe ap_functor_sigma. [Wed Aug 7 19:03:04 2013] I looked through the standard library and didn't see anything that fit the right form. [Wed Aug 7 19:03:35 2013] I'm uselessly spinning my wheels on the problem and would like to get unstuck as quickly as possible ^_^ [Wed Aug 7 19:07:05 2013] Are you sure? ap_functor_sigma seems to be the theorem, up to alpha conversion, with functor_sigma being your f. [Wed Aug 7 19:08:21 2013] (Found via "SearchAbout path_sigma ap.") [Wed Aug 7 19:08:49 2013] Oh, you're right! [Wed Aug 7 19:09:10 2013] Hmm, maybe the separation of functor_sigma threw me off. [Thu Aug 8 01:55:00 2013] "type theory was originally invented ... it was later developed as a rigorous formal system in ints own right (under the name lambda calculus)" <- is that quote correct? I thought lambda calculus is a formal system to model function applications and has nothing to do with type theory. [Thu Aug 8 01:57:45 2013] I think Church's original calculus was simply typed [Thu Aug 8 01:58:15 2013] osa1: maybe read about Church's theorem [Thu Aug 8 02:00:48 2013] benl23: this Church's theorem http://en.wikipedia.org/wiki/Church%27s_theorem ? how is that related with type theory? [Thu Aug 8 02:05:04 2013] because the problem asks about first order logic, and lambda calculus can be used to model that [Thu Aug 8 02:05:35 2013] do you know about the "Curry-Howard correspondence"? [Thu Aug 8 02:06:00 2013] yeah, I'm programming Coq [Thu Aug 8 02:08:16 2013] benl23: I'm still having trouble seeing the relation between lambda calculus and type theory [Thu Aug 8 02:08:27 2013] btw, that quote is from HoTT book [Thu Aug 8 02:09:18 2013] ah, those guys probably made that statement with the benefit of hindsight, then. [Thu Aug 8 02:11:08 2013] lambda calculus + logic + type theory are basically the same thing, though the original inventors took some time to realise it. [Thu Aug 8 02:12:09 2013] I think the original statement is true with the benefit of hindsight, but the original people that worked on lambda calculus may not have been thinking "I'm really doing logic and type theory as well". [Thu Aug 8 02:18:54 2013] .. hmm original LC wasn't simply typed [Thu Aug 8 02:19:05 2013] Church's paper came before Gentzen, at least [Thu Aug 8 02:19:43 2013] hmm. well it had to be turing complete, didn't it :-) [Thu Aug 8 02:20:26 2013] .. :-P [Thu Aug 8 02:22:49 2013] http://maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf has the story [Thu Aug 8 03:41:46 2013] I thought Church's original version of the lambda calculus was untyped [Thu Aug 8 03:41:59 2013] and he developed the typed variant due to the discovery of paradoxes [Thu Aug 8 03:42:16 2013] even the original variant was meant as a language for mathematics [Thu Aug 8 03:42:47 2013] and the typed variant was intended as a response to Russell [Thu Aug 8 06:11:35 2013] anyone in here familiar with ad-hoc proof automation by canonical structures? [Thu Aug 8 06:12:01 2013] here [Thu Aug 8 06:12:36 2013] msrcptival: I'm going to lunch now, but you can post the question and I'll respond later on [Thu Aug 8 06:51:51 2013] beta: http://paste.awesom.eu/Ptival/MeD [Thu Aug 8 06:53:34 2013] if you cannot run this, you should know it fails to apply getPos in the proof of where_is_1, with error: Impossible to unify "findHere 1 ?1762" with "findThere ?1738 ?1739". [Thu Aug 8 06:58:28 2013] beta: maybe what's going on is that this first resolution fails, and the error message is a later try :\ but then I don't know why the first one fails... [Thu Aug 8 07:02:09 2013] (also I realize the resolution I give is when I do 'exists 0.' instead of 'eexists.', the error is identical though [Thu Aug 8 07:22:37 2013] msrcptival: two things: first, the description of how unification works with Canonical Structures does not quite work for Coq's apply. [Thu Aug 8 07:22:56 2013] Second, you need to provide the target before the triggering of the search [Thu Aug 8 07:24:23 2013] when you apply [getPos] to [nth default mySeq position = 3], the unification and triggering of [untag_seq (seq_of f) = mySeq] happens before [target_of f = 3] [Thu Aug 8 07:24:27 2013] so you don't have a target [Thu Aug 8 07:25:21 2013] and, BTW, you should probably move the target as a parameter of the structure, otherwise [target_of f = 3] will trigger the execution without having the seq [Thu Aug 8 07:25:54 2013] that said, I noticed that [apply:] is not working properly in this case [Thu Aug 8 07:50:44 2013] this is how I made it work: [Thu Aug 8 07:50:45 2013] http://paste.awesom.eu/98m [Thu Aug 8 08:41:55 2013] beta: for the unification order, I thought it would still work thanks to backtracking, even though it might have taken more time [Thu Aug 8 08:43:41 2013] it might work in some cases, but as a general pattern, you should always make sure that the inputs of your algorithm are defined before the CS resolution engine gets triggered [Thu Aug 8 08:44:01 2013] ok [Thu Aug 8 08:44:29 2013] so one thing I'm still unclear about is this decision of what to put as parameters of the structure and what to put inside the structure [Thu Aug 8 08:44:51 2013] do I only put the term driving resolution and the expected properties of the result inside the structure? [Thu Aug 8 08:51:35 2013] I don't think I have a good answer for this. Inputs should go as parameters for sure, except perhaps if you don't have that option (in which case you need the "parametrized tagging" pattern, see the noalias example from our journal paper) [Thu Aug 8 08:52:42 2013] outputs can be parameters or fields, but making sure they do not end up being used as triggers (for instance, making them anonymous "_") [Thu Aug 8 08:56:15 2013] ok, thanks for the help! [Thu Aug 8 08:56:25 2013] I'm going to try a more complicated attempt now :) [Thu Aug 8 08:58:12 2013] if you have specific questions you can ask me directly: beta@mpi-sws.org [Thu Aug 8 08:58:49 2013] oh, and Georges told me that apply: does not work if it has to assign an existential created before [Thu Aug 8 09:22:00 2013] msrcptival: I'm interested in canonical structures too, but had bad internet connection; can you please post chat log from your first question to this message? (using any paste service, for example) [Thu Aug 8 09:23:56 2013] gdsfh: http://paste.awesom.eu/DBt [Thu Aug 8 09:24:10 2013] msrcptival: thanks! [Thu Aug 8 13:43:07 2013] Does anyone have a good replacement for (e)rewrite? I thought agda equational reasoning was painful, but trying to prove things in Coq without rewrite is even more painful. [Thu Aug 8 13:43:07 2013] Does anyone have a good replacement for (e)rewrite? I thought agda equational reasoning was painful, but trying to prove things in Coq without rewrite is even more painful. [Thu Aug 8 13:56:30 2013] beta: do you have an example that does what I'm trying to do in the second part of this? http://paste.awesom.eu/Ptival/4Th [Thu Aug 8 13:56:30 2013] beta: do you have an example that does what I'm trying to do in the second part of this? http://paste.awesom.eu/Ptival/4Th [Thu Aug 8 13:57:11 2013] there might be a better way to force target and the (Logic.eq_refl mySeq) business [Thu Aug 8 13:57:11 2013] there might be a better way to force target and the (Logic.eq_refl mySeq) business [Thu Aug 8 16:25:44 2013] join logic [Thu Aug 8 16:25:44 2013] join logic [Thu Aug 8 16:25:51 2013] \quit [Thu Aug 8 16:25:51 2013] \quit [Fri Aug 9 18:37:37 2013] Hello :) [Fri Aug 9 18:37:37 2013] Hello :) [Sat Aug 10 10:24:14 2013] are those two types equal? `forall (y : yesno) (b1 b2 : byntree), P b1 -> P b2 -> P (nbranch y b1 b2)` and `forall (y : yesno) (b1 : byntree), P b1 -> forall b2 : byntree, P b2 -> P (nbranch y b1 b2)` [Sat Aug 10 10:24:15 2013] are those two types equal? `forall (y : yesno) (b1 b2 : byntree), P b1 -> P b2 -> P (nbranch y b1 b2)` and `forall (y : yesno) (b1 : byntree), P b1 -> forall b2 : byntree, P b2 -> P (nbranch y b1 b2)` [Sat Aug 10 14:36:17 2013] osa1: no [Sat Aug 10 14:36:17 2013] osa1: no [Sat Aug 10 14:37:50 2013] osa1: but a way to check is to try to prove it by reflexivity [Sat Aug 10 14:37:50 2013] osa1: but a way to check is to try to prove it by reflexivity [Sat Aug 10 14:40:44 2013] osa1: They are equal if you assume univalence, but not otherwise. [Sat Aug 10 14:40:44 2013] osa1: They are equal if you assume univalence, but not otherwise. [Sat Aug 10 15:43:02 2013] I have no idea what is univalence. [Sat Aug 10 15:43:02 2013] I have no idea what is univalence. [Sat Aug 10 17:49:25 2013] Uh oh, Coq reports no more goals, but refuses to let me Qed [Sat Aug 10 17:49:25 2013] Uh oh, Coq reports no more goals, but refuses to let me Qed [Sat Aug 10 17:50:02 2013] http://lpaste.net/91725 [Sat Aug 10 17:50:02 2013] http://lpaste.net/91725 [Sat Aug 10 17:53:38 2013] you used tactics to generate the proof term ? [Sat Aug 10 17:53:38 2013] you used tactics to generate the proof term ? [Sat Aug 10 17:54:08 2013] Yeppers [Sat Aug 10 17:54:09 2013] Yeppers [Sat Aug 10 17:54:27 2013] "Qed" typecheck the proof term generated by tactics, and it happens that a tactic generate a wrong term [Sat Aug 10 17:54:27 2013] "Qed" typecheck the proof term generated by tactics, and it happens that a tactic generate a wrong term [Sat Aug 10 17:54:42 2013] (so its a bug in a tactic implementation…) [Sat Aug 10 17:54:42 2013] (so its a bug in a tactic implementation…) [Sat Aug 10 17:54:54 2013] makes sense [Sat Aug 10 17:54:54 2013] makes sense [Sat Aug 10 17:56:25 2013] Gah, this proof term is so big [Sat Aug 10 17:56:25 2013] Gah, this proof term is so big [Sat Aug 10 17:57:21 2013] Hm. [Sat Aug 10 17:57:21 2013] Hm. [Sat Aug 10 17:57:28 2013] It appears the /theorem statement itself/ is ill-typed [Sat Aug 10 17:57:29 2013] It appears the /theorem statement itself/ is ill-typed [Sat Aug 10 17:57:54 2013] http://lpaste.net/91727 [Sat Aug 10 17:57:54 2013] http://lpaste.net/91727 [Sat Aug 10 17:59:29 2013] Dammit, I wish match had better support for multi-matches :-( [Sat Aug 10 17:59:29 2013] Dammit, I wish match had better support for multi-matches :-( [Sat Aug 10 18:03:18 2013] hmmmm this doesn't type check either http://lpaste.net/91728 [Sat Aug 10 18:03:18 2013] hmmmm this doesn't type check either http://lpaste.net/91728 [Sat Aug 10 18:06:07 2013] Ah, and once I put in /all/ of the annotations it goes through [Sat Aug 10 18:06:07 2013] Ah, and once I put in /all/ of the annotations it goes through [Sat Aug 10 18:09:25 2013] :-( Now I can't destruct x and y anymore [Sat Aug 10 18:09:25 2013] :-( Now I can't destruct x and y anymore [Sat Aug 10 18:12:04 2013] ezyang: you may want to paste self contained code here: "Error: The reference Empty was not found ..." [Sat Aug 10 18:12:04 2013] ezyang: you may want to paste self contained code here: "Error: The reference Empty was not found ..." [Sat Aug 10 18:12:54 2013] Well, you'll need to be on HoTT coq [Sat Aug 10 18:12:54 2013] Well, you'll need to be on HoTT coq [Sat Aug 10 18:13:42 2013] well, cannot help you in that case [Sat Aug 10 18:13:42 2013] well, cannot help you in that case [Mon Aug 12 02:11:58 2013] Notation "e :? pf" := (eq_rect _ (fun X : Set => X) e _ pf) (no associativity, at level 90). [Mon Aug 12 02:11:58 2013] Notation "e :? pf" := (eq_rect _ (fun X : Set => X) e _ pf) (no associativity, at level 90). [Mon Aug 12 02:12:01 2013] what does this notation mean? [Mon Aug 12 02:12:01 2013] what does this notation mean? [Mon Aug 12 02:12:07 2013] I have read "Check eq_rect" [Mon Aug 12 02:12:07 2013] I have read "Check eq_rect" [Mon Aug 12 02:12:16 2013] but I don't see all the parts are supposed to figut together [Mon Aug 12 02:12:16 2013] but I don't see all the parts are supposed to figut together [Mon Aug 12 02:13:47 2013] Try "Print eq_rect" or "Eval compute in fun e pf => e :? pf" [Mon Aug 12 02:13:47 2013] Try "Print eq_rect" or "Eval compute in fun e pf => e :? pf" [Mon Aug 12 02:16:37 2013] match pf in (_ = y) return y with ... [Mon Aug 12 02:16:37 2013] match pf in (_ = y) return y with ... [Mon Aug 12 02:17:03 2013] I understand you're trying to teach me to fish [Mon Aug 12 02:17:03 2013] I understand you're trying to teach me to fish [Mon Aug 12 02:17:11 2013] but this might work slightly better once I know what type of fish I'm going after [Mon Aug 12 02:17:12 2013] but this might work slightly better once I know what type of fish I'm going after [Mon Aug 12 02:17:29 2013] I know that eq_rect is realted to the "rewrite" tactic [Mon Aug 12 02:17:29 2013] I know that eq_rect is realted to the "rewrite" tactic [Mon Aug 12 02:18:38 2013] Well, eq_rect is the recursion/induction principle for equality, and is defined using [match]. [Mon Aug 12 02:18:38 2013] Well, eq_rect is the recursion/induction principle for equality, and is defined using [match]. [Mon Aug 12 02:20:12 2013] In this particular example, if [pf] is of type [A = B], and you have [x : A], then [match pf in (_ = y) return y with eq_refl => x end] has type [B]; you can think of this match as transporting/casting [x] along/by the equality [pf]. [Mon Aug 12 02:20:12 2013] In this particular example, if [pf] is of type [A = B], and you have [x : A], then [match pf in (_ = y) return y with eq_refl => x end] has type [B]; you can think of this match as transporting/casting [x] along/by the equality [pf]. [Mon Aug 12 02:21:50 2013] so this is just "A -> A = B -> B" ? [Mon Aug 12 02:21:50 2013] so this is just "A -> A = B -> B" ? [Mon Aug 12 02:22:11 2013] Why can't this be better stated as lem_simp : forall (A B: Type), A -> A = B -> B . [Mon Aug 12 02:22:11 2013] Why can't this be better stated as lem_simp : forall (A B: Type), A -> A = B -> B . [Mon Aug 12 02:22:27 2013] Because [eq_rect] is more powerful than that. [Mon Aug 12 02:22:34 2013] Because [eq_rect] is more powerful than that. [Mon Aug 12 02:23:39 2013] It also captures [forall A B (x y : A) (f : A -> B), x = y -> f x = f y], I believe. [Mon Aug 12 02:23:39 2013] It also captures [forall A B (x y : A) (f : A -> B), x = y -> f x = f y], I believe. [Mon Aug 12 02:23:54 2013] hmm, I was going to ask if it was "P A -> A = B -> P B" [Mon Aug 12 02:23:54 2013] hmm, I was going to ask if it was "P A -> A = B -> P B" [Mon Aug 12 02:24:43 2013] That too, for appropriate arguments to [eq_rect]. [Mon Aug 12 02:24:43 2013] That too, for appropriate arguments to [eq_rect]. [Mon Aug 12 02:26:23 2013] oh, I think I got it [Mon Aug 12 02:26:23 2013] oh, I think I got it [Mon Aug 12 02:26:29 2013] this is bascailly "rewrite pf in e" right? [Mon Aug 12 02:26:29 2013] this is bascailly "rewrite pf in e" right? [Mon Aug 12 02:26:48 2013] pf has to be something of the form A = B, and A has to appear in e, and we just repalce A with B [Mon Aug 12 02:26:48 2013] pf has to be something of the form A = B, and A has to appear in e, and we just repalce A with B [Mon Aug 12 02:27:31 2013] Yes, that's about right. But you can also control which occurances of [A] in [e] get replaced with [B] (if [A] shows up multiple times) [Mon Aug 12 02:27:32 2013] Yes, that's about right. But you can also control which occurances of [A] in [e] get replaced with [B] (if [A] shows up multiple times) [Mon Aug 12 02:28:12 2013] But [match] is more general than that, and is used for things like natural numbers and strings and lists, too. [Mon Aug 12 02:28:12 2013] But [match] is more general than that, and is used for things like natural numbers and strings and lists, too. [Mon Aug 12 02:33:40 2013] noted, thanks [Mon Aug 12 02:33:40 2013] noted, thanks [Mon Aug 12 03:25:43 2013] https://gist.github.com/anonymous/6208808 [Mon Aug 12 03:25:43 2013] https://gist.github.com/anonymous/6208808 [Mon Aug 12 03:25:58 2013] in this block of code, (with the only comment "varaible-length tuples") [Mon Aug 12 03:25:58 2013] in this block of code, (with the only comment "varaible-length tuples") [Mon Aug 12 03:26:16 2013] what is index, first, and next supposed to mean intuitively? [Mon Aug 12 03:26:16 2013] what is index, first, and next supposed to mean intuitively? [Mon Aug 12 03:26:27 2013] they do not match any intuition of index/first/next I'm familiar with [Mon Aug 12 03:26:27 2013] they do not match any intuition of index/first/next I'm familiar with [Mon Aug 12 14:40:04 2013] in Coq, what does "fun idx => match idx with end" mean ? [Mon Aug 12 14:40:04 2013] in Coq, what does "fun idx => match idx with end" mean ? [Mon Aug 12 14:40:10 2013] it's a function which takes input idx, [Mon Aug 12 14:40:10 2013] it's a function which takes input idx, [Mon Aug 12 14:40:17 2013] but the "match idx with end" part seems to not even compile on its own [Mon Aug 12 14:40:17 2013] but the "match idx with end" part seems to not even compile on its own [Mon Aug 12 14:41:11 2013] I'd have to guess that idx is of type False [Mon Aug 12 14:41:11 2013] I'd have to guess that idx is of type False [Mon Aug 12 14:41:31 2013] the inductive type with no constructor (hence a pattern matching with no patterns) [Mon Aug 12 14:41:31 2013] the inductive type with no constructor (hence a pattern matching with no patterns) [Mon Aug 12 14:42:17 2013] idx has type Empty_Set [Mon Aug 12 14:42:17 2013] idx has type Empty_Set [Mon Aug 12 14:42:21 2013] which does have no constructors [Mon Aug 12 14:42:21 2013] which does have no constructors [Mon Aug 12 14:42:25 2013] good call; thanks [Mon Aug 12 14:42:25 2013] good call; thanks [Mon Aug 12 14:42:40 2013] what is the type of "match idx with end" ? [Mon Aug 12 14:42:40 2013] what is the type of "match idx with end" ? [Mon Aug 12 14:43:01 2013] or does the type not exist since there are no constructors [Mon Aug 12 14:43:01 2013] or does the type not exist since there are no constructors [Mon Aug 12 14:44:45 2013] in a context where "idx: Empty_Set", "match idx with end" has type "forall A : Type, A" [Mon Aug 12 14:44:45 2013] in a context where "idx: Empty_Set", "match idx with end" has type "forall A : Type, A" [Mon Aug 12 14:45:22 2013] or "forall {A : Type}, A" to be precise (A is implicit) [Mon Aug 12 14:45:22 2013] or "forall {A : Type}, A" to be precise (A is implicit) [Mon Aug 12 14:51:05 2013] this makes sense [Mon Aug 12 14:51:05 2013] this makes sense [Mon Aug 12 14:51:11 2013] it reminds me of forall P, False -> {P [Mon Aug 12 14:51:11 2013] it reminds me of forall P, False -> {P [Mon Aug 12 14:51:28 2013] in the sense that if I can construct you a object of type Empty_Set, then you can return me any type I wanted [Mon Aug 12 14:51:28 2013] in the sense that if I can construct you a object of type Empty_Set, then you can return me any type I wanted [Mon Aug 12 14:51:36 2013] thanks [Mon Aug 12 14:51:36 2013] thanks [Mon Aug 12 14:52:15 2013] It might be more accurate to say that the type of "match idx return _ with end" (which is equivalent to "match idx with end") can't be inferred, but if you fill in the "_", then the type of "match idx return A with end" (which is roughly equivalent to "match idx with end : A") is "A". [Mon Aug 12 14:52:16 2013] It might be more accurate to say that the type of "match idx return _ with end" (which is equivalent to "match idx with end") can't be inferred, but if you fill in the "_", then the type of "match idx return A with end" (which is roughly equivalent to "match idx with end : A") is "A". [Mon Aug 12 14:54:17 2013] what is Admitted? is it something like `undefined` in Haskell? (undefined :: forall a. a) [Mon Aug 12 14:54:17 2013] what is Admitted? is it something like `undefined` in Haskell? (undefined :: forall a. a) [Mon Aug 12 14:54:24 2013] yes, I was hoping for a formal statement like that :-) [Mon Aug 12 14:54:24 2013] yes, I was hoping for a formal statement like that :-) [Mon Aug 12 14:54:25 2013] Essentially. [Mon Aug 12 14:54:25 2013] Essentially. [Mon Aug 12 14:54:29 2013] (re osa1) [Mon Aug 12 14:54:29 2013] (re osa1) [Mon Aug 12 14:55:29 2013] My understanding of "Admitted." is -- I don't want to prove this, just pretend I proved this. [Mon Aug 12 14:55:29 2013] My understanding of "Admitted." is -- I don't want to prove this, just pretend I proved this. [Mon Aug 12 14:55:50 2013] or "just assume this as an axiom" ? [Mon Aug 12 14:55:50 2013] or "just assume this as an axiom" ? [Mon Aug 12 14:56:13 2013] there's "Axiom" for "assume this is an axiom" [Mon Aug 12 14:56:13 2013] there's "Axiom" for "assume this is an axiom" [Mon Aug 12 14:56:18 2013] "Admitted." is used in teh context of a proof [Mon Aug 12 14:56:18 2013] "Admitted." is used in teh context of a proof [Mon Aug 12 14:56:21 2013] oh [Mon Aug 12 14:56:21 2013] oh [Mon Aug 12 14:56:24 2013] to say "assume I proved this" [Mon Aug 12 14:56:24 2013] to say "assume I proved this" [Mon Aug 12 14:57:31 2013] hmm according to my syntax highlighter, Axiom is just another word like Theorem/Definition/Lemma/etc. so it's not a tactic. [Mon Aug 12 14:57:31 2013] hmm according to my syntax highlighter, Axiom is just another word like Theorem/Definition/Lemma/etc. so it's not a tactic. [Mon Aug 12 14:57:47 2013] Lemma forall a b c n, n >= 3 -> a <> 0 -> b <> 0 -> a ^ n + b ^ n = c ^n -> False. Proof. Admitted. Qed. [Mon Aug 12 14:57:47 2013] Lemma forall a b c n, n >= 3 -> a <> 0 -> b <> 0 -> a ^ n + b ^ n = c ^n -> False. Proof. Admitted. Qed. [Mon Aug 12 14:58:21 2013] Axiom is not a tactic [Mon Aug 12 14:58:21 2013] Axiom is not a tactic [Mon Aug 12 14:58:36 2013] use it in place for Lemma/Theorem for "this is an axiom, accept it without proof" [Mon Aug 12 14:58:36 2013] use it in place for Lemma/Theorem for "this is an axiom, accept it without proof" [Mon Aug 12 15:06:36 2013] Admitted is not a tactic either. The tactic is "admit". Admitted is used in place of "Qed" or "Defined" to say "forget the proof I'm trying to do, pretend that instead of Lemma/Theorem/Definition/etc, I said Axiom". "admit" does not forget the work that you've done on the proof so far, but instead proves your current goal with a fresh axiom added to the global context. [Mon Aug 12 15:06:36 2013] Admitted is not a tactic either. The tactic is "admit". Admitted is used in place of "Qed" or "Defined" to say "forget the proof I'm trying to do, pretend that instead of Lemma/Theorem/Definition/etc, I said Axiom". "admit" does not forget the work that you've done on the proof so far, but instead proves your current goal with a fresh axiom added to the global context. [Mon Aug 12 15:08:44 2013] what do I need to read to understand sigT ? [Mon Aug 12 15:08:44 2013] what do I need to read to understand sigT ? [Mon Aug 12 15:08:50 2013] I've seen it show up multiple times [Mon Aug 12 15:08:50 2013] I've seen it show up multiple times [Mon Aug 12 15:08:55 2013] it has a simple type [Mon Aug 12 15:08:55 2013] it has a simple type [Mon Aug 12 15:08:59 2013] yet I still have no idea what it does [Mon Aug 12 15:08:59 2013] yet I still have no idea what it does [Mon Aug 12 15:09:19 2013] why do I want (forall A, (A -> Type) -> Type) ? [Mon Aug 12 15:09:19 2013] why do I want (forall A, (A -> Type) -> Type) ? [Mon Aug 12 16:05:50 2013] Have you tried 'Print sigT.', and have you tried understanding inductive types and constructors in general, and 'existT' in particular? [Mon Aug 12 16:05:50 2013] Have you tried 'Print sigT.', and have you tried understanding inductive types and constructors in general, and 'existT' in particular? [Mon Aug 12 16:21:03 2013] clj_newb_2345 needs to learn how to idle ;) [Mon Aug 12 16:21:03 2013] clj_newb_2345 needs to learn how to idle ;) [Mon Aug 12 16:22:03 2013] * awoke from his idle slumber [Mon Aug 12 16:22:03 2013] * awoke from his idle slumber [Mon Aug 12 16:22:04 2013] ya. [Mon Aug 12 16:22:04 2013] ya. [Tue Aug 13 00:33:00 2013] [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup [Tue Aug 13 10:25:41 2013] How can I create a finite map (preferably using FMapAVL) where the type of the value is parametrized by the key? [Tue Aug 13 10:25:41 2013] How can I create a finite map (preferably using FMapAVL) where the type of the value is parametrized by the key? [Tue Aug 13 10:26:34 2013] ryanakca: I've wanted so much to do that before. [Tue Aug 13 10:26:34 2013] ryanakca: I've wanted so much to do that before. [Tue Aug 13 10:27:05 2013] I came to the conclusion that it couldn't be done, since the value type expected is not a family of types over the keys. [Tue Aug 13 10:27:05 2013] I came to the conclusion that it couldn't be done, since the value type expected is not a family of types over the keys. [Tue Aug 13 10:28:55 2013] It would require an entire rewrite of the theory and implementations :/ [Tue Aug 13 10:28:55 2013] It would require an entire rewrite of the theory and implementations :/ [Tue Aug 13 10:29:00 2013] I see, bummer :/ [Tue Aug 13 10:29:00 2013] I see, bummer :/ [Tue Aug 13 10:29:41 2013] The problem with dependently-typed languages is library design. No one knows how to do it adequately yet. [Tue Aug 13 10:29:41 2013] The problem with dependently-typed languages is library design. No one knows how to do it adequately yet. [Tue Aug 13 10:38:59 2013] ianjneu: Did you end up working out an alternate solution? [Tue Aug 13 10:38:59 2013] ianjneu: Did you end up working out an alternate solution? [Tue Aug 13 10:43:17 2013] ryanakca: Do proofs by hand and keep doing my research. [Tue Aug 13 10:43:17 2013] ryanakca: Do proofs by hand and keep doing my research. [Tue Aug 13 10:43:38 2013] I've not touched a proof assistant in about a year :/ [Tue Aug 13 10:43:38 2013] I've not touched a proof assistant in about a year :/ [Tue Aug 13 10:44:52 2013] Higher-order logic is not good at modular proofs of termination, so a lot of my programs got heavily first-order-ized [Tue Aug 13 10:44:52 2013] Higher-order logic is not good at modular proofs of termination, so a lot of my programs got heavily first-order-ized [Tue Aug 13 10:44:56 2013] it was painful. [Tue Aug 13 10:44:56 2013] it was painful. [Tue Aug 13 10:46:00 2013] Consider type family s-expression(X), which is either an atom : X -> s-expression(X) or lst : list(s-expression X) -> s-expression X [Tue Aug 13 10:46:00 2013] Consider type family s-expression(X), which is either an atom : X -> s-expression(X) or lst : list(s-expression X) -> s-expression X [Tue Aug 13 10:46:39 2013] Write a recursive function f on an s-expression(X) s, that uses map f. [Tue Aug 13 10:46:39 2013] Write a recursive function f on an s-expression(X) s, that uses map f. [Tue Aug 13 10:46:45 2013] Can't prove termination. [Tue Aug 13 10:46:45 2013] Can't prove termination. [Tue Aug 13 10:48:46 2013] I have similar problems when representing closures and want to write folds over the enviroment, using the function I'm defining. [Tue Aug 13 10:48:46 2013] I have similar problems when representing closures and want to write folds over the enviroment, using the function I'm defining. [Tue Aug 13 10:54:16 2013] * nods, it sounds rather unpleasant to prove [Tue Aug 13 10:54:16 2013] * nods, it sounds rather unpleasant to prove [Tue Aug 13 11:04:22 2013] It's structural, but due to the theory making the implementations opaque, there's no way to know. [Tue Aug 13 11:04:22 2013] It's structural, but due to the theory making the implementations opaque, there's no way to know. [Tue Aug 13 12:04:35 2013] ianjneu: here is such a recursive function http://lpaste.net/91822 [Tue Aug 13 12:04:35 2013] ianjneu: here is such a recursive function http://lpaste.net/91822 [Tue Aug 13 12:04:38 2013] works just fine [Tue Aug 13 12:04:38 2013] works just fine [Tue Aug 13 12:05:52 2013] ryanakca: the problem is that FmapAVL uses the module system to abstract over the type over keys. Unfortunatelly, the module system is not first class, so you cannot do what you want. [Tue Aug 13 12:05:52 2013] ryanakca: the problem is that FmapAVL uses the module system to abstract over the type over keys. Unfortunatelly, the module system is not first class, so you cannot do what you want. [Tue Aug 13 12:06:49 2013] but you can of course make your own implementation (for example using type classes or canonical structures) that will do what you want. [Tue Aug 13 12:06:49 2013] but you can of course make your own implementation (for example using type classes or canonical structures) that will do what you want. [Tue Aug 13 12:19:49 2013] robbert: right, the sexp was a bad example. It was really the closure represented via abstract finite function that I wanted to use a fold over. [Tue Aug 13 12:19:49 2013] robbert: right, the sexp was a bad example. It was really the closure represented via abstract finite function that I wanted to use a fold over. [Tue Aug 13 12:46:48 2013] are there any tips etc to get more idiomatic haskell code from the extraction mechanism? (remove unnecessary unsafeCoerce etc) [Tue Aug 13 12:46:48 2013] are there any tips etc to get more idiomatic haskell code from the extraction mechanism? (remove unnecessary unsafeCoerce etc) [Tue Aug 13 13:10:45 2013] ianjneu: I think you mentioned something like that a year ago, I believe that was indeed harder (or even not very possible ;)). Maybe sized types as in for example MiniAgda will help? If so, maybe we'll get those in Coq at some day too :) [Tue Aug 13 13:10:45 2013] ianjneu: I think you mentioned something like that a year ago, I believe that was indeed harder (or even not very possible ;)). Maybe sized types as in for example MiniAgda will help? If so, maybe we'll get those in Coq at some day too :) [Tue Aug 13 16:32:03 2013] I don't understand how can ; tactical be used without first writing the long, repetitive and boring form of the proof and then seeing repetition explicitly and moving to ; tactical. and in that case it'd be better to not to use ; because you already wrote the boring code and to reader ; makes proof more magical. [Tue Aug 13 16:32:03 2013] I don't understand how can ; tactical be used without first writing the long, repetitive and boring form of the proof and then seeing repetition explicitly and moving to ; tactical. and in that case it'd be better to not to use ; because you already wrote the boring code and to reader ; makes proof more magical. [Tue Aug 13 16:34:16 2013] You can use it in your custom tactics, for example (which could be quite magical, granted). Also, quite often you actually know what goals a tactic would produce (and so ; makes sense), it kind of comes with practice. [Tue Aug 13 16:34:16 2013] You can use it in your custom tactics, for example (which could be quite magical, granted). Also, quite often you actually know what goals a tactic would produce (and so ; makes sense), it kind of comes with practice. [Tue Aug 13 16:36:05 2013] is it widely used in practical proofs? [Tue Aug 13 16:36:06 2013] is it widely used in practical proofs? [Tue Aug 13 16:36:10 2013] s/practical/real [Tue Aug 13 16:36:10 2013] s/practical/real [Tue Aug 13 16:36:34 2013] I'd say it depends on your style. [Tue Aug 13 16:36:34 2013] I'd say it depends on your style. [Tue Aug 13 16:38:31 2013] For example, consider an inductive proof with a lot of cases, but mostly simple, that could be solved in a similar way. [Tue Aug 13 16:38:31 2013] For example, consider an inductive proof with a lot of cases, but mostly simple, that could be solved in a similar way. [Tue Aug 13 16:39:18 2013] Why not use a semicolon and a tactic to discharge, say, 80% of the cases? [Tue Aug 13 16:39:18 2013] Why not use a semicolon and a tactic to discharge, say, 80% of the cases? [Tue Aug 13 16:41:12 2013] what if inductive definition is given in a way that even though 80% of the cases are similar, different cases are placed in a way that you cannot automatically eliminate 80% cases because that 20% part just come in your way and stop your ; proof? is there a way to reorder inductive cases? [Tue Aug 13 16:41:12 2013] what if inductive definition is given in a way that even though 80% of the cases are similar, different cases are placed in a way that you cannot automatically eliminate 80% cases because that 20% part just come in your way and stop your ; proof? is there a way to reorder inductive cases? [Tue Aug 13 16:43:28 2013] Well, I'd usually consider a tactic that can't fail but can solve a goal, in the style of `auto' for that kind of use [Tue Aug 13 16:43:28 2013] Well, I'd usually consider a tactic that can't fail but can solve a goal, in the style of `auto' for that kind of use [Tue Aug 13 16:44:21 2013] osa1: for instance, I'm using a custom logic where term manipulations often involve the composition of many theorems, and I'm juggling with many facts [Tue Aug 13 16:44:21 2013] osa1: for instance, I'm using a custom logic where term manipulations often involve the composition of many theorems, and I'm juggling with many facts [Tue Aug 13 16:45:03 2013] doing things manually would require a lot of fiddling with associativity, commutativity, adjunctions, morphisms... [Tue Aug 13 16:45:03 2013] doing things manually would require a lot of fiddling with associativity, commutativity, adjunctions, morphisms... [Tue Aug 13 16:45:52 2013] writing a tactic that knows how to manipulate these things is very useful [Tue Aug 13 16:45:52 2013] writing a tactic that knows how to manipulate these things is very useful [Tue Aug 13 16:46:17 2013] oh wait, you're talking just about semicolon in particular? [Tue Aug 13 16:46:18 2013] oh wait, you're talking just about semicolon in particular? [Tue Aug 13 16:47:07 2013] yeah [Tue Aug 13 16:47:07 2013] yeah [Tue Aug 13 16:47:22 2013] well I use it a lot, but try not to make the chains longer than 1 when possible [Tue Aug 13 16:47:22 2013] well I use it a lot, but try not to make the chains longer than 1 when possible [Tue Aug 13 16:48:07 2013] or only when I kinda want to see the thing as one composition of manipulations [Tue Aug 13 16:48:07 2013] or only when I kinda want to see the thing as one composition of manipulations [Tue Aug 13 16:48:39 2013] btw, this is interesting: http://lpaste.net/91825 in the first proof that 2 different cases occured in the middle of the proof but in the second proof, it eliminated all cases and when it failed it just tried for remaining cases so in the end it eliminated all the similar cases [Tue Aug 13 16:48:39 2013] btw, this is interesting: http://lpaste.net/91825 in the first proof that 2 different cases occured in the middle of the proof but in the second proof, it eliminated all cases and when it failed it just tried for remaining cases so in the end it eliminated all the similar cases [Tue Aug 13 16:50:01 2013] thanks for your comments. [Tue Aug 13 16:50:01 2013] thanks for your comments. [Tue Aug 13 16:50:43 2013] which of these do you prefer? [Tue Aug 13 16:50:43 2013] which of these do you prefer? [Tue Aug 13 16:50:48 2013] yup, it does use the tactic on all the goals, the goal does not have to become completely solved. So as long as the tactic doesn't *fail*, you're good. [Tue Aug 13 16:50:48 2013] yup, it does use the tactic on all the goals, the goal does not have to become completely solved. So as long as the tactic doesn't *fail*, you're good. [Tue Aug 13 16:53:10 2013] Ptival: in this particular problem I prefer second one, but if you look at optimize_0plus proofs in SF book you'll see that ; actually makes the proof worse, or at least it didn't help to make proof more readable. and after ; tactic ends, it's hard to predict where is your automated proof ended, except if you defined a tactic notation to automatically give labels to cases etc. [Tue Aug 13 16:53:10 2013] Ptival: in this particular problem I prefer second one, but if you look at optimize_0plus proofs in SF book you'll see that ; actually makes the proof worse, or at least it didn't help to make proof more readable. and after ; tactic ends, it's hard to predict where is your automated proof ended, except if you defined a tactic notation to automatically give labels to cases etc. [Tue Aug 13 16:53:31 2013] osa1: your tacticals should be fairly agnostic to the order of constructors anyway [Tue Aug 13 16:53:31 2013] osa1: your tacticals should be fairly agnostic to the order of constructors anyway [Tue Aug 13 16:54:33 2013] sure it can lead you to states whose origin you are unable to figure out [Tue Aug 13 16:54:34 2013] sure it can lead you to states whose origin you are unable to figure out [Tue Aug 13 17:13:36 2013] robbert: I'm reading through the miniAgda paper. I'm curious why sizes are limited to natural numbers rather than ordinal numbers (up to epsilon_0, say) [Tue Aug 13 17:13:36 2013] robbert: I'm reading through the miniAgda paper. I'm curious why sizes are limited to natural numbers rather than ordinal numbers (up to epsilon_0, say) [Tue Aug 13 18:03:33 2013] ahh .. after Imp chapter SF book becomes impossible to read on my kindle because all proofs are hidden in a button .. [Tue Aug 13 18:03:33 2013] ahh .. after Imp chapter SF book becomes impossible to read on my kindle because all proofs are hidden in a button .. [Tue Aug 13 18:16:02 2013] not sure you want to read proofs on a kindle :\ [Tue Aug 13 18:16:02 2013] not sure you want to read proofs on a kindle :\ [Tue Aug 13 18:18:40 2013] it's actually very comfortable .. mine is a very old kindle dx, which has big screen so proofs isn't really a problem. [Tue Aug 13 18:18:40 2013] it's actually very comfortable .. mine is a very old kindle dx, which has big screen so proofs isn't really a problem. [Tue Aug 13 18:26:54 2013] what I mean is Coq proofs are not really to be consumed as text [Tue Aug 13 18:26:54 2013] what I mean is Coq proofs are not really to be consumed as text [Wed Aug 14 08:30:05 2013] hello [Wed Aug 14 08:30:05 2013] hello [Wed Aug 14 08:30:30 2013] is (fun {T: Type} (_ _: T) => True) defined somewhere in the standard library or ssreflect? [Wed Aug 14 08:30:30 2013] is (fun {T: Type} (_ _: T) => True) defined somewhere in the standard library or ssreflect? [Wed Aug 14 08:32:37 2013] or alternatively, fun {A B: Type} (f: A -> B) => (forall (x y : A), f x = f y) [Wed Aug 14 08:32:37 2013] or alternatively, fun {A B: Type} (f: A -> B) => (forall (x y : A), f x = f y) [Wed Aug 14 11:19:15 2013] Any suggestions on how to merge two disjoin finite maps (I'm currently using FMapAVL)? [Wed Aug 14 11:19:15 2013] Any suggestions on how to merge two disjoin finite maps (I'm currently using FMapAVL)? [Wed Aug 14 11:19:26 2013] msrcptival: Ooh, you're at MSRC? I was there in the fall :) [Wed Aug 14 11:19:26 2013] msrcptival: Ooh, you're at MSRC? I was there in the fall :) [Wed Aug 14 11:31:09 2013] ryanakca: yes, here for the summer [Wed Aug 14 11:31:09 2013] ryanakca: yes, here for the summer [Wed Aug 14 11:31:12 2013] can't you use map2? [Wed Aug 14 11:31:12 2013] can't you use map2? [Wed Aug 14 11:45:35 2013] ryanakca: you'll still have to prove that each map's keys map to the same values that they did prior to merging, using the disjointness property. This isn't already in the facts library? [Wed Aug 14 11:45:35 2013] ryanakca: you'll still have to prove that each map's keys map to the same values that they did prior to merging, using the disjointness property. This isn't already in the facts library? [Wed Aug 14 11:47:34 2013] hmm, apparently not. [Wed Aug 14 11:47:34 2013] hmm, apparently not. [Wed Aug 14 11:48:26 2013] they kinda gave up on map2 [Wed Aug 14 11:48:26 2013] they kinda gave up on map2 [Wed Aug 14 11:48:34 2013] I had written my own map2i and some properties [Wed Aug 14 11:48:34 2013] I had written my own map2i and some properties [Wed Aug 14 11:48:42 2013] https://github.com/Ptival/compcert-alias/blob/alias/backend/AliasFMapAVLPlus.v [Wed Aug 14 11:48:42 2013] https://github.com/Ptival/compcert-alias/blob/alias/backend/AliasFMapAVLPlus.v [Wed Aug 14 11:49:16 2013] great naming conventions [Wed Aug 14 11:49:16 2013] great naming conventions [Wed Aug 14 11:49:22 2013] _1 _2 _3 _4 _5 :) [Wed Aug 14 11:49:22 2013] _1 _2 _3 _4 _5 :) [Wed Aug 14 11:50:35 2013] union_map m0 m1 := fold Add m0 m1 (adds m0's bindings to m1's) [Wed Aug 14 11:50:35 2013] union_map m0 m1 := fold Add m0 m1 (adds m0's bindings to m1's) [Wed Aug 14 11:52:39 2013] Theorem maps_preserved : forall m0 m1, Disjoint m0 m1 -> (forall k e, MapsTo k e m0 -> MapsTo k e (union_map m0 m1)) /\ (forall k e, MapsTo k e m1 -> MapsTo k e (union_map m0 m1)) [Wed Aug 14 11:52:59 2013] Theorem maps_preserved : forall m0 m1, Disjoint m0 m1 -> (forall k e, MapsTo k e m0 -> MapsTo k e (union_map m0 m1)) /\ (forall k e, MapsTo k e m1 -> MapsTo k e (union_map m0 m1)) [Wed Aug 14 11:54:35 2013] And you'll need to write the converse, that if k e is mapped in the union, then k e is mapped in the map m such that In k m. [Wed Aug 14 11:54:35 2013] And you'll need to write the converse, that if k e is mapped in the union, then k e is mapped in the map m such that In k m. [Wed Aug 14 14:10:08 2013] ianjneu: I get http://lpaste.net/91842 with your union_map; any suggestions ? [Wed Aug 14 14:10:08 2013] ianjneu: I get http://lpaste.net/91842 with your union_map; any suggestions ? [Wed Aug 14 14:13:13 2013] ryanakca: do you have "Set Implicit Arguments." in your file? I would expect it to infer elt from the maps you give. [Wed Aug 14 14:13:13 2013] ryanakca: do you have "Set Implicit Arguments." in your file? I would expect it to infer elt from the maps you give. [Wed Aug 14 14:13:57 2013] otherwise, use (M.add model) instead of M.add [Wed Aug 14 14:13:57 2013] otherwise, use (M.add model) instead of M.add [Wed Aug 14 14:13:59 2013] I do [Wed Aug 14 14:13:59 2013] I do [Wed Aug 14 14:16:33 2013] ryanakca: does (M.add model) work? [Wed Aug 14 14:16:33 2013] ryanakca: does (M.add model) work? [Wed Aug 14 14:17:03 2013] Trying (M.add string) (the keys are of type string, the values are of type model) gives: The term "string" has type "Set" while it is expected to have type [Wed Aug 14 14:17:03 2013] Trying (M.add string) (the keys are of type string, the values are of type model) gives: The term "string" has type "Set" while it is expected to have type [Wed Aug 14 14:17:06 2013] "M.key". [Wed Aug 14 14:17:06 2013] "M.key". [Wed Aug 14 14:17:30 2013] Trying with (M.add model) gives the same error, but with type "Type [Wed Aug 14 14:17:30 2013] Trying with (M.add model) gives the same error, but with type "Type [Wed Aug 14 14:18:09 2013] M.add expects the type of values as the first argument, not the type of the keys (that was already given to the Make functor) [Wed Aug 14 14:18:09 2013] M.add expects the type of values as the first argument, not the type of the keys (that was already given to the Make functor) [Wed Aug 14 14:18:56 2013] (@M.add model) [Wed Aug 14 14:18:56 2013] (@M.add model) [Wed Aug 14 14:18:56 2013] worked [Wed Aug 14 14:18:56 2013] worked [Wed Aug 14 14:19:04 2013] good show. [Wed Aug 14 14:19:04 2013] good show. [Wed Aug 14 14:19:13 2013] Thanks for the help :) [Wed Aug 14 14:19:13 2013] Thanks for the help :) [Wed Aug 14 14:19:19 2013] np [Wed Aug 14 14:19:19 2013] np [Thu Aug 15 07:31:36 2013] I have proof of a <-> b, how can I get proof of a -> b from that? [Thu Aug 15 07:31:37 2013] I have proof of a <-> b, how can I get proof of a -> b from that? [Thu Aug 15 07:40:19 2013] A <-> B is defined as A -> B /\ B -> A, so just project out the appropriate implication [Thu Aug 15 07:40:19 2013] A <-> B is defined as A -> B /\ B -> A, so just project out the appropriate implication [Thu Aug 15 07:40:36 2013] (or, you know, destruct the equivalence) [Thu Aug 15 07:40:36 2013] (or, you know, destruct the equivalence) [Thu Aug 15 07:42:12 2013] "project out the appropriate implication" how? [Thu Aug 15 07:42:13 2013] "project out the appropriate implication" how? [Thu Aug 15 07:45:17 2013] it depends what exactly you want to do. If you have H : A <-> B, then proj1 H : A -> B, so that's one option. [Thu Aug 15 07:45:17 2013] it depends what exactly you want to do. If you have H : A <-> B, then proj1 H : A -> B, so that's one option. [Thu Aug 15 07:45:41 2013] (and proj2 H : B -> A) [Thu Aug 15 07:45:41 2013] (and proj2 H : B -> A) [Thu Aug 15 07:51:31 2013] fisi: that worked, thanks. [Thu Aug 15 07:51:31 2013] fisi: that worked, thanks. [Thu Aug 15 07:51:37 2013] so I'm working on an exercise from SF book [Thu Aug 15 07:51:38 2013] so I'm working on an exercise from SF book [Thu Aug 15 07:51:39 2013] http://lpaste.net/91861 [Thu Aug 15 07:51:39 2013] http://lpaste.net/91861 [Thu Aug 15 07:51:56 2013] is there a way to simplify that `apply`s ? [Thu Aug 15 07:51:56 2013] is there a way to simplify that `apply`s ? [Thu Aug 15 07:53:40 2013] yeah, I think so. [Thu Aug 15 07:53:41 2013] yeah, I think so. [Thu Aug 15 07:54:38 2013] There is a variant of apply where you specify a direction for things you can apply both ways (like an iff), which goes "apply -> foo" (or "apply <- foo") [Thu Aug 15 07:54:38 2013] There is a variant of apply where you specify a direction for things you can apply both ways (like an iff), which goes "apply -> foo" (or "apply <- foo") [Thu Aug 15 07:57:20 2013] also, there's a way of *rewriting* with things other than equality (e.g., iff), but that's a slightly more advanced topic. [Thu Aug 15 07:57:20 2013] also, there's a way of *rewriting* with things other than equality (e.g., iff), but that's a slightly more advanced topic. [Thu Aug 15 08:05:25 2013] yeah, apply -> worked in this case. thanks. [Thu Aug 15 08:05:26 2013] yeah, apply -> worked in this case. thanks. [Thu Aug 15 08:05:44 2013] no problem. [Thu Aug 15 08:05:44 2013] no problem. [Thu Aug 15 08:39:33 2013] osa1 you can specify the direction of each command with <- or -> [Thu Aug 15 08:39:33 2013] osa1 you can specify the direction of each command with <- or -> [Thu Aug 15 10:47:13 2013] How can I use proofs from the "Proofs" module of http://coq.inria.fr/stdlib/Coq.FSets.FMapAVL.html ? I can't access them directly after a "Require Import FMapAVL." [Thu Aug 15 10:47:14 2013] How can I use proofs from the "Proofs" module of http://coq.inria.fr/stdlib/Coq.FSets.FMapAVL.html ? I can't access them directly after a "Require Import FMapAVL." [Thu Aug 15 10:50:41 2013] The submodule is within the module that results from calling the Make functor, right? [Thu Aug 15 10:50:41 2013] The submodule is within the module that results from calling the Make functor, right? [Thu Aug 15 10:51:39 2013] So your Map instance (say, M) should have a M.Proofs scope that I think you can Require Import [Thu Aug 15 10:51:39 2013] So your Map instance (say, M) should have a M.Proofs scope that I think you can Require Import [Thu Aug 15 10:52:16 2013] Are you sure you need AVL facts and not just facts about maps in general? [Thu Aug 15 10:52:16 2013] Are you sure you need AVL facts and not just facts about maps in general? [Thu Aug 15 10:56:16 2013] ryanakca: ^ [Thu Aug 15 10:56:17 2013] ryanakca: ^ [Thu Aug 15 10:57:14 2013] To prove your maps_preserved theorem, I'm afraid that I might be [Thu Aug 15 10:57:14 2013] To prove your maps_preserved theorem, I'm afraid that I might be [Thu Aug 15 10:58:27 2013] That doesn't sound right. You might need FMapFacts, though [Thu Aug 15 10:58:27 2013] That doesn't sound right. You might need FMapFacts, though [Thu Aug 15 10:58:37 2013] Alright, I'll look at that [Thu Aug 15 10:58:38 2013] Alright, I'll look at that [Thu Aug 15 11:00:39 2013] (I got the impression I'd need AVL facts when I unfolded M.fold and had to do a case_eq on a (M.t elt) to simplify things) [Thu Aug 15 11:00:39 2013] (I got the impression I'd need AVL facts when I unfolded M.fold and had to do a case_eq on a (M.t elt) to simplify things) [Thu Aug 15 11:01:31 2013] No, fold's dependent elimination should handle that. [Thu Aug 15 11:01:31 2013] No, fold's dependent elimination should handle that. [Thu Aug 15 11:01:43 2013] That's given by the FMap interface. [Thu Aug 15 11:01:43 2013] That's given by the FMap interface. [Thu Aug 15 11:02:26 2013] It's an abstract guarantee that you can induct over folds regardless of the map's representation. [Thu Aug 15 11:02:26 2013] It's an abstract guarantee that you can induct over folds regardless of the map's representation. [Fri Aug 16 10:58:56 2013] wtf are coq meta varaibles and what have I gotten myself into? [Fri Aug 16 10:58:56 2013] wtf are coq meta varaibles and what have I gotten myself into? [Fri Aug 16 10:59:12 2013] "can not ... becuase a metavaraible has several occurences" (on a rewrite) [Fri Aug 16 10:59:12 2013] "can not ... becuase a metavaraible has several occurences" (on a rewrite) [Fri Aug 16 11:57:23 2013] okay, resolved (despite not knowing why it works) :-) [Fri Aug 16 11:57:23 2013] okay, resolved (despite not knowing why it works) :-) [Fri Aug 16 19:43:09 2013] Can someone explain to me how [Identity Coercion]s are used? I can declare one easily enough, but I cannot think of a use-case. That is, I cannot find a statement that will typecheck/run when I have declared a constant as an identity coercion, but which will fail if I have defined that constant, but not declared it as an identity coercion. Can someone show me such a statement, or else explain to me what [Identity Coercion] is supposed to do if [Fri Aug 16 19:43:09 2013] no such statement exists? [Fri Aug 16 19:43:09 2013] Can someone explain to me how [Identity Coercion]s are used? I can declare one easily enough, but I cannot think of a use-case. That is, I cannot find a statement that will typecheck/run when I have declared a constant as an identity coercion, but which will fail if I have defined that constant, but not declared it as an identity coercion. Can someone show me such a statement, or else explain to me what [Identity Coercion] is supposed to do if [Fri Aug 16 19:43:09 2013] no such statement exists? [Sat Aug 17 18:22:00 2013] let's say I have `H : no_whiles c1 && no_whiles c2 = true` as hyphothesis, how can I generate H1 : no_whiles c1 = true and H2 : no_whiles c2 = true from that? [Sat Aug 17 18:22:01 2013] let's say I have `H : no_whiles c1 && no_whiles c2 = true` as hyphothesis, how can I generate H1 : no_whiles c1 = true and H2 : no_whiles c2 = true from that? [Sat Aug 17 23:02:43 2013] does anyone here have coq installed via homebrew on mac os x? im trying to get coqide to install with it but no go so far.. [Sat Aug 17 23:02:43 2013] does anyone here have coq installed via homebrew on mac os x? im trying to get coqide to install with it but no go so far.. [Sat Aug 17 23:42:23 2013] i have coq installed, but i never tried using coqide [Sat Aug 17 23:42:24 2013] i have coq installed, but i never tried using coqide [Sun Aug 18 00:14:08 2013] anyone use coqide here? i just decided to install it from the dmg on the coq website, but upon running it in hangs.. :-( [Sun Aug 18 00:14:08 2013] anyone use coqide here? i just decided to install it from the dmg on the coq website, but upon running it in hangs.. :-( [Sun Aug 18 00:15:08 2013] * doesn't use coqide, the obvious alternative is proof general in emacs [Sun Aug 18 00:15:08 2013] * doesn't use coqide, the obvious alternative is proof general in emacs [Sun Aug 18 00:16:31 2013] gienah: you use proof general? [Sun Aug 18 00:16:31 2013] gienah: you use proof general? [Sun Aug 18 00:16:39 2013] adelbertc: yeah [Sun Aug 18 00:16:40 2013] adelbertc: yeah [Sun Aug 18 02:28:40 2013] i installed the dmg from the website on mtn lion, and coqide "just works" [Sun Aug 18 02:28:40 2013] i installed the dmg from the website on mtn lion, and coqide "just works" [Sun Aug 18 05:30:11 2013] wow, for some reason my copy of imp.v has more additional exercises than online SF book's Imp chapter [Sun Aug 18 05:30:11 2013] wow, for some reason my copy of imp.v has more additional exercises than online SF book's Imp chapter [Sun Aug 18 05:59:47 2013] I'm reading about coq dependent type checking. In particualr, google found https://sympa.inria.fr/sympa/arc/coq-club/2013-02/msg00041.html [Sun Aug 18 05:59:47 2013] I'm reading about coq dependent type checking. In particualr, google found https://sympa.inria.fr/sympa/arc/coq-club/2013-02/msg00041.html [Sun Aug 18 05:59:50 2013] which leads to teh question: what is ssreflect, and how does it relate to dependent types? [Sun Aug 18 05:59:50 2013] which leads to teh question: what is ssreflect, and how does it relate to dependent types? [Sun Aug 18 06:03:34 2013] alright [Sun Aug 18 06:03:34 2013] alright [Sun Aug 18 06:03:40 2013] where can I even download ssreflect ? :-) [Sun Aug 18 06:03:40 2013] where can I even download ssreflect ? :-) [Sun Aug 18 06:04:03 2013] http://ssr.msr-inria.inria.fr/ <-- is this the right site? [Sun Aug 18 06:04:03 2013] http://ssr.msr-inria.inria.fr/ <-- is this the right site? [Sun Aug 18 06:07:11 2013] http://www.msr-inria.inria.fr/Projects/math-components <-- linked from main page of Coq, appears to be dead [Sun Aug 18 06:07:11 2013] http://www.msr-inria.inria.fr/Projects/math-components <-- linked from main page of Coq, appears to be dead [Sun Aug 18 06:22:21 2013] http://www.msr-inria.fr/projects/mathematical-components/ [Sun Aug 18 06:22:21 2013] http://www.msr-inria.fr/projects/mathematical-components/ [Sun Aug 18 06:47:30 2013] Ptival: what is the "software foudnations / cpdt" equiv for ssreflect? [Sun Aug 18 06:47:30 2013] Ptival: what is the "software foudnations / cpdt" equiv for ssreflect? [Sun Aug 18 08:38:07 2013] (that would be a nice-to-have :)) [Sun Aug 18 08:38:07 2013] (that would be a nice-to-have :)) [Sun Aug 18 11:04:47 2013] What is the purpsoe of ssreflect? [Sun Aug 18 11:04:47 2013] What is the purpsoe of ssreflect? [Sun Aug 18 11:08:59 2013] Does ssreflect compile with Ocmal 4.00.1 + Coq 8.4 pl2? [Sun Aug 18 11:08:59 2013] Does ssreflect compile with Ocmal 4.00.1 + Coq 8.4 pl2? [Sun Aug 18 11:09:10 2013] I'm getting an "Preprocessor error for file src/ssrmatching.ml4" [Sun Aug 18 11:09:10 2013] I'm getting an "Preprocessor error for file src/ssrmatching.ml4" [Sun Aug 18 12:39:23 2013] doies Coq have supprot for strings [Sun Aug 18 12:39:23 2013] doies Coq have supprot for strings [Sun Aug 18 12:39:35 2013] as in: >> Eval simpl in "Hello World" . [Sun Aug 18 12:39:35 2013] as in: >> Eval simpl in "Hello World" . [Sun Aug 18 12:39:41 2013] If so, what library do I need to include? [Sun Aug 18 12:39:41 2013] If so, what library do I need to include? [Sun Aug 18 12:48:57 2013] Open Local Scope string_scope. :-) [Sun Aug 18 12:48:57 2013] Open Local Scope string_scope. :-) [Sun Aug 18 17:46:20 2013] having a bit of trouble understanding somes tuff in SOftware Foundations. http://pastebin.com/YpHA8E3M why is minusTwo of O, O? [Sun Aug 18 17:46:20 2013] having a bit of trouble understanding somes tuff in SOftware Foundations. http://pastebin.com/YpHA8E3M why is minusTwo of O, O? [Sun Aug 18 17:49:55 2013] These are naturals, not integers! [Sun Aug 18 17:49:55 2013] These are naturals, not integers! [Sun Aug 18 17:52:22 2013] hmmmm [Sun Aug 18 17:52:22 2013] hmmmm [Sun Aug 18 17:53:05 2013] i see.. kind of [Sun Aug 18 17:53:05 2013] i see.. kind of [Sun Aug 18 17:53:50 2013] there's nowhere to go so you stay at zero :) [Sun Aug 18 17:53:50 2013] there's nowhere to go so you stay at zero :) [Sun Aug 18 17:54:12 2013] Yeah, subtraction of naturals isn't very natural [Sun Aug 18 17:54:12 2013] Yeah, subtraction of naturals isn't very natural [Sun Aug 18 17:55:20 2013] ah.. [Sun Aug 18 17:55:20 2013] ah.. [Sun Aug 18 17:55:28 2013] interesting [Sun Aug 18 17:55:28 2013] interesting [Sun Aug 18 19:33:34 2013] adelbertc : truncating subtraction, aka monus, see e.g. "Equationally complete classes of commutative monoids with monus" in 1984 by K. Amer. often written as a minus sign with a dot above it, `∸' [Sun Aug 18 19:33:34 2013] adelbertc : truncating subtraction, aka monus, see e.g. "Equationally complete classes of commutative monoids with monus" in 1984 by K. Amer. often written as a minus sign with a dot above it, `∸' [Sun Aug 18 19:35:39 2013] ski: awesome, thanks! [Sun Aug 18 19:35:39 2013] ski: awesome, thanks! [Sun Aug 18 19:35:40 2013] monus satisfies the adjunction `minuend ∸ subtrahend ≤ remainder ⇔ minuend ≤ remainder + subtrahend' [Sun Aug 18 19:35:40 2013] monus satisfies the adjunction `minuend ∸ subtrahend ≤ remainder ⇔ minuend ≤ remainder + subtrahend' [Sun Aug 18 19:38:00 2013] (instead of "adjunction", you can say "(monotone) Galois connection") [Sun Aug 18 19:38:00 2013] (instead of "adjunction", you can say "(monotone) Galois connection") [Sun Aug 18 19:41:45 2013] interesting.. that's getting a bit ahead of my math background (which im trying to improve) at the moment, but will keep that in mind :-) [Sun Aug 18 19:41:45 2013] interesting.. that's getting a bit ahead of my math background (which im trying to improve) at the moment, but will keep that in mind :-) [Sun Aug 18 19:41:46 2013] thanks ski [Sun Aug 18 19:41:46 2013] thanks ski [Sun Aug 18 19:48:54 2013] (also ) [Sun Aug 18 19:48:54 2013] (also ) [Sun Aug 18 20:11:15 2013] rofl "monus" [Sun Aug 18 20:11:15 2013] rofl "monus" [Sun Aug 18 20:17:03 2013] I wonder where that paper is which argued strongly in favour of truncating subtraction for natural numbers and gave lots of examples where laws work out nicely with it. [Sun Aug 18 20:17:03 2013] I wonder where that paper is which argued strongly in favour of truncating subtraction for natural numbers and gave lots of examples where laws work out nicely with it. [Sun Aug 18 21:41:11 2013] hm, i don't think i've seen that one [Sun Aug 18 21:41:11 2013] hm, i don't think i've seen that one [Sun Aug 18 21:42:30 2013] (hm, for some reason i forgot to give the URL for the above paper) [Sun Aug 18 21:42:31 2013] (hm, for some reason i forgot to give the URL for the above paper) [Sun Aug 18 21:52:44 2013] Cale: lemme know if you find it [Sun Aug 18 21:52:44 2013] Cale: lemme know if you find it [Sun Aug 18 22:29:47 2013] code review on proving a simple theorey that forall x, the identity applied twice is x? http://pastebin.com/iXdJ36qe i feel like there should be a better/more succinct way to write this (this is an exercise from ch1 of software foundations) [Sun Aug 18 22:29:47 2013] code review on proving a simple theorey that forall x, the identity applied twice is x? http://pastebin.com/iXdJ36qe i feel like there should be a better/more succinct way to write this (this is an exercise from ch1 of software foundations) [Sun Aug 18 22:30:49 2013] adelbertc: software foundations attempts to teach you the long way to do some things before showing you the shorter way [Sun Aug 18 22:30:49 2013] adelbertc: software foundations attempts to teach you the long way to do some things before showing you the shorter way [Sun Aug 18 22:31:39 2013] even so, I have a shorter solution than that one just using stuff from the first chapter [Sun Aug 18 22:31:39 2013] even so, I have a shorter solution than that one just using stuff from the first chapter [Sun Aug 18 22:32:02 2013] kini: would be interested in seeing it [Sun Aug 18 22:32:03 2013] kini: would be interested in seeing it [Sun Aug 18 22:32:38 2013] adelbertc: as soon as you've intros'd b, you can already use rewrite -> H. No need to destruct b. [Sun Aug 18 22:32:38 2013] adelbertc: as soon as you've intros'd b, you can already use rewrite -> H. No need to destruct b. [Sun Aug 18 22:32:59 2013] note that H doesn't care about which bool value the x is, only that it is a bool [Sun Aug 18 22:32:59 2013] note that H doesn't care about which bool value the x is, only that it is a bool [Sun Aug 18 22:33:18 2013] ahh [Sun Aug 18 22:33:18 2013] ahh [Sun Aug 18 22:33:19 2013] got it. [Sun Aug 18 22:33:19 2013] got it. [Sun Aug 18 22:33:22 2013] thanks! [Sun Aug 18 22:33:22 2013] thanks! [Sun Aug 18 23:35:01 2013] hm.. could use some hints on proving this theorem: http://pastebin.com/E0mUkKii [Sun Aug 18 23:35:01 2013] hm.. could use some hints on proving this theorem: http://pastebin.com/E0mUkKii [Sun Aug 18 23:35:24 2013] i tried applying demorgans, but didnt get very far [Sun Aug 18 23:35:24 2013] i tried applying demorgans, but didnt get very far [Mon Aug 19 00:26:09 2013] adelbertc: ugly as it is, try just destructing both b and c [Mon Aug 19 00:26:10 2013] adelbertc: ugly as it is, try just destructing both b and c [Mon Aug 19 00:26:19 2013] and then showing all four cases by simplification [Mon Aug 19 00:26:19 2013] and then showing all four cases by simplification [Mon Aug 19 00:26:58 2013] kini: so just intros b c. destruct b. destruct c. ? [Mon Aug 19 00:26:58 2013] kini: so just intros b c. destruct b. destruct c. ? [Mon Aug 19 00:27:05 2013] try it and see :) [Mon Aug 19 00:27:05 2013] try it and see :) [Mon Aug 19 00:27:08 2013] because that gets me into a case of true = false [Mon Aug 19 00:27:08 2013] because that gets me into a case of true = false [Mon Aug 19 00:27:22 2013] really? [Mon Aug 19 00:27:22 2013] really? [Mon Aug 19 00:27:44 2013] kini: http://pastebin.com/rs5PwsSv [Mon Aug 19 00:27:44 2013] kini: http://pastebin.com/rs5PwsSv [Mon Aug 19 00:27:45 2013] so it does [Mon Aug 19 00:27:45 2013] so it does [Mon Aug 19 00:27:51 2013] subgoal 2 [Mon Aug 19 00:27:51 2013] subgoal 2 [Mon Aug 19 00:27:56 2013] well, I actually destructed b right after introsing it [Mon Aug 19 00:27:56 2013] well, I actually destructed b right after introsing it [Mon Aug 19 00:28:26 2013] doing what you did doesn't actually make the problem unsolvable, you just haven't learned how to do the magic poof on false hypotheses yet ;) [Mon Aug 19 00:28:26 2013] doing what you did doesn't actually make the problem unsolvable, you just haven't learned how to do the magic poof on false hypotheses yet ;) [Mon Aug 19 00:28:57 2013] (if you can show that one of your hypotheses -- something above the line -- is false, that's as good as showing that what's below the line is true, and you can make the goal disappear) [Mon Aug 19 00:28:57 2013] (if you can show that one of your hypotheses -- something above the line -- is false, that's as good as showing that what's below the line is true, and you can make the goal disappear) [Mon Aug 19 00:29:16 2013] ah interesting [Mon Aug 19 00:29:16 2013] ah interesting [Mon Aug 19 00:29:18 2013] dont think ive learned that yet [Mon Aug 19 00:29:18 2013] dont think ive learned that yet [Mon Aug 19 00:29:22 2013] (so if you have something that looks obviously impossible to prove to be true under the line, try to prove something above the line false instead) [Mon Aug 19 00:29:22 2013] (so if you have something that looks obviously impossible to prove to be true under the line, try to prove something above the line false instead) [Mon Aug 19 00:29:26 2013] yeah you don't learn that until several chapters in [Mon Aug 19 00:29:26 2013] yeah you don't learn that until several chapters in [Mon Aug 19 00:29:32 2013] but there's a way to solve this problem without running into that [Mon Aug 19 00:29:32 2013] but there's a way to solve this problem without running into that [Mon Aug 19 00:30:13 2013] i would hope so :-) [Mon Aug 19 00:30:13 2013] i would hope so :-) [Mon Aug 19 00:30:22 2013] been trying to tackle this on and off the psat hour or so [Mon Aug 19 00:30:22 2013] been trying to tackle this on and off the psat hour or so [Mon Aug 19 00:32:19 2013] this is 2star, next one is 3, not looking forward to it [Mon Aug 19 00:32:19 2013] this is 2star, next one is 3, not looking forward to it [Mon Aug 19 00:33:18 2013] hehe [Mon Aug 19 00:33:19 2013] hehe [Mon Aug 19 00:34:39 2013] kini: any hints? [Mon Aug 19 00:34:39 2013] kini: any hints? [Mon Aug 19 00:35:21 2013] oh, actually you're not even stuck in what you did [Mon Aug 19 00:35:21 2013] oh, actually you're not even stuck in what you did [Mon Aug 19 00:36:20 2013] for that sticky second subgoal, just try doing simpl and see if you can't work out something [Mon Aug 19 00:36:20 2013] for that sticky second subgoal, just try doing simpl and see if you can't work out something [Mon Aug 19 00:37:21 2013] "stuck in what you did" - as in doing the destruct on both b and c? [Mon Aug 19 00:37:21 2013] "stuck in what you did" - as in doing the destruct on both b and c? [Mon Aug 19 00:37:30 2013] yeah [Mon Aug 19 00:37:30 2013] yeah [Mon Aug 19 00:37:38 2013] intros b c. destruct b. destruct c. [Mon Aug 19 00:37:38 2013] intros b c. destruct b. destruct c. [Mon Aug 19 00:38:39 2013] woa. simpl made some stuff dissappear [Mon Aug 19 00:38:39 2013] woa. simpl made some stuff dissappear [Mon Aug 19 00:38:42 2013] hadn't used simpl like that yet [Mon Aug 19 00:38:42 2013] hadn't used simpl like that yet [Mon Aug 19 00:40:08 2013] simpl will compute down simple non-recursive functions (like andb and orb) for you [Mon Aug 19 00:40:08 2013] simpl will compute down simple non-recursive functions (like andb and orb) for you [Mon Aug 19 00:40:34 2013] woot got it! [Mon Aug 19 00:40:34 2013] woot got it! [Mon Aug 19 00:40:44 2013] simpl. intros H. rewrite -> H. reflexivity. [Mon Aug 19 00:40:44 2013] simpl. intros H. rewrite -> H. reflexivity. [Mon Aug 19 04:20:39 2013] is there a tactic for "unfold notation" ? [Mon Aug 19 04:20:39 2013] is there a tactic for "unfold notation" ? [Mon Aug 19 04:20:55 2013] so I'm using "do X <- blah; f blah" (as a notation for Monads in Coq) [Mon Aug 19 04:20:55 2013] so I'm using "do X <- blah; f blah" (as a notation for Monads in Coq) [Mon Aug 19 04:21:06 2013] and I'd like to have the notation "unfold" [Mon Aug 19 04:21:06 2013] and I'd like to have the notation "unfold" [Mon Aug 19 04:21:13 2013] (for the sake of proving things) [Mon Aug 19 04:21:13 2013] (for the sake of proving things) [Mon Aug 19 11:40:07 2013] anyone to point out what I'm doing wrong here? :) http://paste.awesom.eu/Ptival/wSB [Mon Aug 19 11:40:07 2013] anyone to point out what I'm doing wrong here? :) http://paste.awesom.eu/Ptival/wSB [Mon Aug 19 12:06:44 2013] msrcptival: I think the way ltac works, you need to evaluate the variable "t" before calling the tactic on it [Mon Aug 19 12:06:44 2013] msrcptival: I think the way ltac works, you need to evaluate the variable "t" before calling the tactic on it [Mon Aug 19 12:07:13 2013] in particular, this seems to work: "let u := eval cbv in t in let s := recompute_size in pose s as S1." [Mon Aug 19 12:07:13 2013] in particular, this seems to work: "let u := eval cbv in t in let s := recompute_size in pose s as S1." [Mon Aug 19 12:14:24 2013] also, it's consistent with other tactics: if, in the setting pasted there, you call "let s := t in idtac s", you'll get "t" printed out, while if you bind "eval cbv in t", you'll get the contents. I guess the reason for this behaviour is that in ltac sometimes you might want not to unfold the definitions of Gallina variables. [Mon Aug 19 12:14:24 2013] also, it's consistent with other tactics: if, in the setting pasted there, you call "let s := t in idtac s", you'll get "t" printed out, while if you bind "eval cbv in t", you'll get the contents. I guess the reason for this behaviour is that in ltac sometimes you might want not to unfold the definitions of Gallina variables. [Mon Aug 19 12:17:17 2013] fisi: oh right, thanks [Mon Aug 19 12:17:17 2013] fisi: oh right, thanks [Mon Aug 19 13:12:22 2013] Why does "case_eq (@M.find T a A)" (where M is given by "Module M := FMapAVL.Make(StringDecOrd)") give me something of the form "forall t : T, M.find (elt:=T) a A = Some t", which strikes me as patently false? Shouldn't I have something of type "exists t : T, M.find (elt:=T) a A = Some t"? [Mon Aug 19 13:12:22 2013] Why does "case_eq (@M.find T a A)" (where M is given by "Module M := FMapAVL.Make(StringDecOrd)") give me something of the form "forall t : T, M.find (elt:=T) a A = Some t", which strikes me as patently false? Shouldn't I have something of type "exists t : T, M.find (elt:=T) a A = Some t"? [Mon Aug 19 13:43:01 2013] how to learn names of notations like - + etc. ? [Mon Aug 19 13:43:01 2013] how to learn names of notations like - + etc. ? [Mon Aug 19 13:43:32 2013] Locate "_ + _" [Mon Aug 19 13:43:32 2013] Locate "_ + _" [Mon Aug 19 13:44:07 2013] thanks [Mon Aug 19 13:44:07 2013] thanks [Mon Aug 19 13:46:18 2013] you can also just Locate "+". [Mon Aug 19 13:46:19 2013] you can also just Locate "+". [Mon Aug 19 13:46:21 2013] any token will do [Mon Aug 19 13:46:21 2013] any token will do [Mon Aug 19 13:57:41 2013] thanks [Mon Aug 19 13:57:41 2013] thanks [Mon Aug 19 14:44:45 2013] ryanakca: You're doing a kind of induction [Mon Aug 19 14:44:45 2013] ryanakca: You're doing a kind of induction [Mon Aug 19 14:45:00 2013] ryanakca: That's an assumption which holds in one case, and not in the other. [Mon Aug 19 14:45:00 2013] ryanakca: That's an assumption which holds in one case, and not in the other. [Mon Aug 19 14:46:30 2013] ryanakca: I assume you see two cases when you do that, right? [Mon Aug 19 14:46:30 2013] ryanakca: I assume you see two cases when you do that, right? [Mon Aug 19 14:48:34 2013] Yes, but the other case is obviously false and easily disposed of :) [Mon Aug 19 14:48:34 2013] Yes, but the other case is obviously false and easily disposed of :) [Mon Aug 19 14:50:51 2013] ryanakca: Oh, I see, you mistyped it. [Mon Aug 19 14:50:51 2013] ryanakca: Oh, I see, you mistyped it. [Mon Aug 19 14:51:09 2013] ryanakca: you cut off your goal halfway through when you put it into IRC :) [Mon Aug 19 14:51:09 2013] ryanakca: you cut off your goal halfway through when you put it into IRC :) [Mon Aug 19 14:51:19 2013] Yes. [Mon Aug 19 14:51:19 2013] Yes. [Mon Aug 19 14:51:37 2013] Which is why you're confused about the universal vs. existential quantifier. [Mon Aug 19 14:51:37 2013] Which is why you're confused about the universal vs. existential quantifier. [Mon Aug 19 14:51:50 2013] I get "CASE_EQ_STUFF -> MY_OLD_GOAL" [Mon Aug 19 14:51:50 2013] I get "CASE_EQ_STUFF -> MY_OLD_GOAL" [Mon Aug 19 14:52:31 2013] The forall captures the whole rest of the type. [Mon Aug 19 14:52:31 2013] The forall captures the whole rest of the type. [Mon Aug 19 14:53:33 2013] You're meant to prove forall t : T, ((... = Some t) -> (...)) [Mon Aug 19 14:53:34 2013] You're meant to prove forall t : T, ((... = Some t) -> (...)) [Mon Aug 19 14:54:06 2013] Ah, I see, sorry, I missparsed it :) [Mon Aug 19 14:54:07 2013] Ah, I see, sorry, I missparsed it :) [Mon Aug 19 14:54:20 2013] So when you do intros, you'll get a binding t : T, as well as a hypothesis that find ... gives Some t [Mon Aug 19 14:54:20 2013] So when you do intros, you'll get a binding t : T, as well as a hypothesis that find ... gives Some t [Mon Aug 19 17:44:09 2013] does adding excluded middle to Coq make it inconsistent? if not, why we don't have it by default? [Mon Aug 19 17:44:09 2013] does adding excluded middle to Coq make it inconsistent? if not, why we don't have it by default? [Mon Aug 19 17:45:38 2013] osa1: no, but it is inconsistent with the univalence axiom. [Mon Aug 19 17:45:38 2013] osa1: no, but it is inconsistent with the univalence axiom. [Mon Aug 19 17:45:55 2013] It is also not constructive, with is an anti-pattern. [Mon Aug 19 17:45:55 2013] It is also not constructive, with is an anti-pattern. [Mon Aug 19 17:46:02 2013] because it breaks canonicity. [Mon Aug 19 17:46:03 2013] because it breaks canonicity. [Mon Aug 19 17:46:19 2013] hmm. I don't understand most of these arguments (univalence, canonicity etc.) [Mon Aug 19 17:46:19 2013] hmm. I don't understand most of these arguments (univalence, canonicity etc.) [Mon Aug 19 17:46:22 2013] but thanks [Mon Aug 19 17:46:22 2013] but thanks [Mon Aug 19 17:46:41 2013] excluded middle isn't computable [Mon Aug 19 17:46:41 2013] excluded middle isn't computable [Mon Aug 19 17:46:47 2013] you can't evaluate stuff down fully any more. [Mon Aug 19 17:46:47 2013] you can't evaluate stuff down fully any more. [Mon Aug 19 17:46:47 2013] so I'm reading SF book and at one point an axiom is added. what I don't understand here is, we have proof objects for theorems, which as far as I understand like a ordinary functions from premises of the theorems to conclusion of the theorem. but what is a proof object for an axiom? [Mon Aug 19 17:46:47 2013] so I'm reading SF book and at one point an axiom is added. what I don't understand here is, we have proof objects for theorems, which as far as I understand like a ordinary functions from premises of the theorems to conclusion of the theorem. but what is a proof object for an axiom? [Mon Aug 19 17:47:15 2013] opaque [Mon Aug 19 17:47:15 2013] opaque [Mon Aug 19 17:47:18 2013] it simply won't evaluate. [Mon Aug 19 17:47:18 2013] it simply won't evaluate. [Mon Aug 19 17:47:26 2013] that's why axioms aren't very nice :) [Mon Aug 19 17:47:27 2013] that's why axioms aren't very nice :) [Mon Aug 19 17:47:30 2013] oh [Mon Aug 19 17:47:30 2013] oh [Mon Aug 19 17:47:39 2013] it just gets "stuck" whenever you rely on an axiom [Mon Aug 19 17:47:39 2013] it just gets "stuck" whenever you rely on an axiom [Mon Aug 19 17:47:57 2013] researchers are currently looking for a computational aspect to univalence to remove the need for an axiom. [Mon Aug 19 17:47:57 2013] researchers are currently looking for a computational aspect to univalence to remove the need for an axiom. [Mon Aug 19 17:48:19 2013] is this a problem? do we need to "run" proofs? as far as I understand type checking is enough for showing them valid [Mon Aug 19 17:48:19 2013] is this a problem? do we need to "run" proofs? as far as I understand type checking is enough for showing them valid [Mon Aug 19 17:49:25 2013] I think this is the sortest wikipedia page I've ever seen http://en.wikipedia.org/wiki/Univalence_axiom [Mon Aug 19 17:49:25 2013] I think this is the sortest wikipedia page I've ever seen http://en.wikipedia.org/wiki/Univalence_axiom [Mon Aug 19 17:49:26 2013] Fully constructive proofs can be normalized and checked. It's why Voevodsky suggested that type theory doesn't have the "problems of inconsistency" [Mon Aug 19 17:49:26 2013] Fully constructive proofs can be normalized and checked. It's why Voevodsky suggested that type theory doesn't have the "problems of inconsistency" [Mon Aug 19 17:50:23 2013] I understand that but I don't understand why we need to "normalize" them. it looks to me that only type checking is enough. [Mon Aug 19 17:50:24 2013] I understand that but I don't understand why we need to "normalize" them. it looks to me that only type checking is enough. [Mon Aug 19 17:50:48 2013] it is nice that a proof of (exists n : nat, ...) can be computed to give a natural number which satisfies the proposition. [Mon Aug 19 17:50:48 2013] it is nice that a proof of (exists n : nat, ...) can be computed to give a natural number which satisfies the proposition. [Mon Aug 19 17:51:14 2013] (and philosophically, constructivists wouldn't be happy if it can't necessarily) [Mon Aug 19 17:51:14 2013] (and philosophically, constructivists wouldn't be happy if it can't necessarily) [Mon Aug 19 17:51:29 2013] For some people, sure. For full peace of mind, you may wish that your statement does need appeals to some oracle. [Mon Aug 19 17:51:30 2013] For some people, sure. For full peace of mind, you may wish that your statement does need appeals to some oracle. [Mon Aug 19 17:51:38 2013] [2013-08-19 16:47:57] researchers are currently looking for a computational aspect to univalence to remove the need for an axiom. [Mon Aug 19 17:51:38 2013] [2013-08-19 16:47:57] researchers are currently looking for a computational aspect to univalence to remove the need for an axiom. [Mon Aug 19 17:51:38 2013] how does that "remove the need for an axiom"? [Mon Aug 19 17:51:38 2013] how does that "remove the need for an axiom"? [Mon Aug 19 17:51:52 2013] or do you just mean that the axiom will be built into the system computationally, and not be opaque anymore? [Mon Aug 19 17:51:52 2013] or do you just mean that the axiom will be built into the system computationally, and not be opaque anymore? [Mon Aug 19 17:52:12 2013] well, type theory is generally not considered to have any axioms per se [Mon Aug 19 17:52:12 2013] well, type theory is generally not considered to have any axioms per se [Mon Aug 19 17:52:55 2013] hmmm [Mon Aug 19 17:52:55 2013] hmmm [Mon Aug 19 17:53:31 2013] there are ways to construct and destruct data. The introduction and elimination rules. It's all definitional. If you have a computation rule for univalence, then you can interpret it as just another object. [Mon Aug 19 17:53:31 2013] there are ways to construct and destruct data. The introduction and elimination rules. It's all definitional. If you have a computation rule for univalence, then you can interpret it as just another object. [Mon Aug 19 17:57:54 2013] I myself am skeptical that there's a nice computational interpretation for univalence. I interpret it as the theory's internalizing the indistinguishability of isomorphic types, which is similar to the reasoning that we use for free theorems via parametricity. It's a meta-level property, and crossing phases could cause foundational issues. [Mon Aug 19 17:57:54 2013] I myself am skeptical that there's a nice computational interpretation for univalence. I interpret it as the theory's internalizing the indistinguishability of isomorphic types, which is similar to the reasoning that we use for free theorems via parametricity. It's a meta-level property, and crossing phases could cause foundational issues. [Mon Aug 19 17:59:54 2013] ianjneu: you can internalise parametricity (computably) [Mon Aug 19 17:59:54 2013] ianjneu: you can internalise parametricity (computably) [Mon Aug 19 18:00:07 2013] elliott: interesting. source? [Mon Aug 19 18:00:07 2013] elliott: interesting. source? [Mon Aug 19 18:00:12 2013] let me dig it up. [Mon Aug 19 18:00:12 2013] let me dig it up. [Mon Aug 19 18:00:30 2013] http://hackage.haskell.org/package/uAgda is an implementation [Mon Aug 19 18:00:30 2013] http://hackage.haskell.org/package/uAgda is an implementation [Mon Aug 19 18:00:35 2013] paper I read is by the same author [Mon Aug 19 18:00:35 2013] paper I read is by the same author [Mon Aug 19 18:00:48 2013] neelk and derek dreyer. Of course. Those guys rock. [Mon Aug 19 18:00:49 2013] neelk and derek dreyer. Of course. Those guys rock. [Mon Aug 19 18:01:26 2013] ianjneu: http://publications.lib.chalmers.se/publication/153094 I think [Mon Aug 19 18:01:26 2013] ianjneu: http://publications.lib.chalmers.se/publication/153094 I think [Mon Aug 19 18:01:45 2013] Okay, so multiple sources. [Mon Aug 19 18:01:45 2013] Okay, so multiple sources. [Mon Aug 19 18:02:26 2013] ianjneu: that, http://homotopytypetheory.org/2011/07/27/canonicity-for-2-dimensional-type-theory/ and http://twanvl.nl/blog/agda/subst-from-cong all increased my confidence that a computational interpretation for univalence exists. (but I am just an amateur; take it with a grain of salt) [Mon Aug 19 18:02:26 2013] ianjneu: that, http://homotopytypetheory.org/2011/07/27/canonicity-for-2-dimensional-type-theory/ and http://twanvl.nl/blog/agda/subst-from-cong all increased my confidence that a computational interpretation for univalence exists. (but I am just an amateur; take it with a grain of salt) [Mon Aug 19 18:02:42 2013] (er, follow-up to the latter: http://twanvl.nl/blog/agda/cong-from-refl) [Mon Aug 19 18:02:42 2013] (er, follow-up to the latter: http://twanvl.nl/blog/agda/cong-from-refl) [Mon Aug 19 18:15:53 2013] is there a way to do "Hint Extern num context[ ... ]" ... or do I have to do "Hint Extern num match goal with |- context ... end" ? [Mon Aug 19 18:15:53 2013] is there a way to do "Hint Extern num context[ ... ]" ... or do I have to do "Hint Extern num match goal with |- context ... end" ? [Mon Aug 19 18:24:32 2013] I have a goal on the form (c t1 t2) = (c t1' t2'), where c is a constructor for an inductivly defined type. What is the best way to reduce this to two subgoals, t1 = t1' and t2 = t2'? I've not found any tactic doing that. [Mon Aug 19 18:24:32 2013] I have a goal on the form (c t1 t2) = (c t1' t2'), where c is a constructor for an inductivly defined type. What is the best way to reduce this to two subgoals, t1 = t1' and t2 = t2'? I've not found any tactic doing that. [Mon Aug 19 18:24:52 2013] fequal [Mon Aug 19 18:24:52 2013] fequal [Mon Aug 19 18:25:05 2013] "apply f_equal2" [Mon Aug 19 18:25:06 2013] "apply f_equal2" [Mon Aug 19 18:25:15 2013] I can start paying my debt to #coq :-) [Mon Aug 19 18:25:15 2013] I can start paying my debt to #coq :-) [Mon Aug 19 18:25:51 2013] Thanks :) [Mon Aug 19 18:25:51 2013] Thanks :) [Mon Aug 19 18:33:25 2013] you can also just "f_equal" [Mon Aug 19 18:33:25 2013] you can also just "f_equal" [Mon Aug 19 18:33:28 2013] as a tactic [Mon Aug 19 18:33:28 2013] as a tactic [Mon Aug 19 18:34:09 2013] alright, I'm now going to back to 0 for the day: [Mon Aug 19 18:34:10 2013] alright, I'm now going to back to 0 for the day: [Mon Aug 19 18:34:39 2013] instead of a Rewrite database, is it possible to create a "tactic" database -- i.e. a list of tactics, where it's like a repeat ( tac1 || tac2 || tac3 || ...... ) [Mon Aug 19 18:34:40 2013] instead of a Rewrite database, is it possible to create a "tactic" database -- i.e. a list of tactics, where it's like a repeat ( tac1 || tac2 || tac3 || ...... ) [Mon Aug 19 18:34:47 2013] basically, if you can apply any of the tactics in this databse, apply it [Mon Aug 19 18:34:47 2013] basically, if you can apply any of the tactics in this databse, apply it [Mon Aug 19 18:34:58 2013] I tried "Hint Extern" [Mon Aug 19 18:34:58 2013] I tried "Hint Extern" [Mon Aug 19 18:35:05 2013] but it appears auto only uses it if the tactic can solve the entire goal [Mon Aug 19 18:35:05 2013] but it appears auto only uses it if the tactic can solve the entire goal [Mon Aug 19 18:35:13 2013] (in my case, it can't ... my tactic introduces new goals) [Mon Aug 19 18:35:13 2013] (in my case, it can't ... my tactic introduces new goals) [Mon Aug 19 19:35:06 2013] can ocaml tactics generate fake proofs [Mon Aug 19 19:35:06 2013] can ocaml tactics generate fake proofs [Mon Aug 19 19:35:24 2013] or does "Qed" in Coq also verify the terms generated by the ocaml tactics? [Mon Aug 19 19:35:24 2013] or does "Qed" in Coq also verify the terms generated by the ocaml tactics? [Mon Aug 19 19:42:10 2013] clj_newb_2345: Qed should verify, yes [Mon Aug 19 19:42:10 2013] clj_newb_2345: Qed should verify, yes [Mon Aug 19 19:46:08 2013] okay, so in theory, if I screw up my OCaml tactic, [Mon Aug 19 19:46:08 2013] okay, so in theory, if I screw up my OCaml tactic, [Mon Aug 19 19:46:13 2013] Qed will go "you srewed up" [Mon Aug 19 19:46:13 2013] Qed will go "you srewed up" [Mon Aug 19 19:46:17 2013] rather than letting me create a fake proof [Mon Aug 19 19:46:17 2013] rather than letting me create a fake proof [Tue Aug 20 10:58:46 2013] I can't find a syntax to cancel the implicitness of some arguments [Tue Aug 20 10:58:46 2013] I can't find a syntax to cancel the implicitness of some arguments [Tue Aug 20 10:59:12 2013] rather, of all arguments [Tue Aug 20 10:59:12 2013] rather, of all arguments [Tue Aug 20 10:59:38 2013] maybe because @ does that job :\ [Tue Aug 20 10:59:38 2013] maybe because @ does that job :\ [Tue Aug 20 10:59:43 2013] but still [Tue Aug 20 10:59:43 2013] but still [Tue Aug 20 11:01:33 2013] msrcptival: you can change the implicitness of any given arguments with the "Arguments" command (8.4, I believe), but that's a Vernacular-level thing. I don't think there's anything other then '@' at the Gallina level (not even sure how this would be supposed to work). [Tue Aug 20 11:01:33 2013] msrcptival: you can change the implicitness of any given arguments with the "Arguments" command (8.4, I believe), but that's a Vernacular-level thing. I don't think there's anything other then '@' at the Gallina level (not even sure how this would be supposed to work). [Tue Aug 20 11:01:59 2013] fisi: yes but [Tue Aug 20 11:01:59 2013] fisi: yes but [Tue Aug 20 11:02:11 2013] say f : {a b} c [Tue Aug 20 11:02:11 2013] say f : {a b} c [Tue Aug 20 11:02:28 2013] Arguments f [a] b c. makes it f : {a} b c [Tue Aug 20 11:02:28 2013] Arguments f [a] b c. makes it f : {a} b c [Tue Aug 20 11:02:41 2013] Arguments f a b c. leaves it f : {a b} c [Tue Aug 20 11:02:42 2013] Arguments f a b c. leaves it f : {a b} c [Tue Aug 20 11:03:40 2013] I can't find a way to make all the arguments explicit again [Tue Aug 20 11:03:41 2013] I can't find a way to make all the arguments explicit again [Tue Aug 20 11:04:23 2013] okay, that's weird. [Tue Aug 20 11:04:23 2013] okay, that's weird. [Tue Aug 20 11:09:35 2013] ha, got it! [Tue Aug 20 11:09:35 2013] ha, got it! [Tue Aug 20 11:09:59 2013] "Arguments qualid : clear implicits" [Tue Aug 20 11:09:59 2013] "Arguments qualid : clear implicits" [Tue Aug 20 11:10:04 2013] ah [Tue Aug 20 11:10:04 2013] ah [Tue Aug 20 11:10:08 2013] so quirky [Tue Aug 20 11:10:08 2013] so quirky [Tue Aug 20 11:10:17 2013] yup [Tue Aug 20 11:10:17 2013] yup [Tue Aug 20 11:10:57 2013] I guess it *is* shorter then spelling out everything, but still no clue why the syntax you've given doesn't clear the implicitness [Tue Aug 20 11:10:57 2013] I guess it *is* shorter then spelling out everything, but still no clue why the syntax you've given doesn't clear the implicitness [Tue Aug 20 17:18:39 2013] when trying to install coq via opam I get: Application of .opam/4.00.1/build/coq.8.4pl2/CAML_LD_LIBRARY_PATH.patch failed: can not determine the correct patch level. [Tue Aug 20 17:18:39 2013] when trying to install coq via opam I get: Application of .opam/4.00.1/build/coq.8.4pl2/CAML_LD_LIBRARY_PATH.patch failed: can not determine the correct patch level. [Tue Aug 20 17:18:44 2013] any idea how to approach this? [Tue Aug 20 17:18:44 2013] any idea how to approach this? [Tue Aug 20 18:52:50 2013] sometimes I find myself using apply tactic with all parameters specified like this: apply (E_Seq c1 c2 st st'0 st') . is there a way to infer those parameters? obviously I'm specifying parameters because plain "apply E_Seq" doesn't work. [Tue Aug 20 18:52:51 2013] sometimes I find myself using apply tactic with all parameters specified like this: apply (E_Seq c1 c2 st st'0 st') . is there a way to infer those parameters? obviously I'm specifying parameters because plain "apply E_Seq" doesn't work. [Tue Aug 20 18:55:14 2013] You can try leaving some of them as underscores, and see if [apply] can infer them. You can see if [eapply E_Seq] works. You can see if sticking all of them in as underscores and doing something like [refine (E_Seq _ _ _ _ _)] works ([refine] and [apply] use different unification engines, much to my annoyance) [Tue Aug 20 18:55:14 2013] You can try leaving some of them as underscores, and see if [apply] can infer them. You can see if [eapply E_Seq] works. You can see if sticking all of them in as underscores and doing something like [refine (E_Seq _ _ _ _ _)] works ([refine] and [apply] use different unification engines, much to my annoyance) [Tue Aug 20 18:56:23 2013] You can also do [apply (E_Seq c1 c2)] and see if Coq can infer the rest of the parameters. [Tue Aug 20 18:56:23 2013] You can also do [apply (E_Seq c1 c2)] and see if Coq can infer the rest of the parameters. [Tue Aug 20 18:56:37 2013] hmm, never heard of refine before [Tue Aug 20 18:56:38 2013] hmm, never heard of refine before [Tue Aug 20 18:57:03 2013] I didn't know about _ , thanks. I'll try that in my next proofs [Tue Aug 20 18:57:03 2013] I didn't know about _ , thanks. I'll try that in my next proofs [Tue Aug 20 19:01:40 2013] I'm trying to compile coq but it complains about not finding dlllablgtk2.so, which I do have under .opam/4.00.1/lib/stublibs [Tue Aug 20 19:01:41 2013] I'm trying to compile coq but it complains about not finding dlllablgtk2.so, which I do have under .opam/4.00.1/lib/stublibs [Tue Aug 20 19:02:05 2013] any idea how to approach this problem? [Tue Aug 20 19:02:05 2013] any idea how to approach this problem? [Tue Aug 20 19:09:27 2013] have you tried using opam? [Tue Aug 20 19:09:27 2013] have you tried using opam? [Tue Aug 20 19:14:01 2013] hi (on an unstable connection, forgive me if i've already asked), i'm trying to learn coq, and i'm stuck on a proof. http://codepad.org/ogRDxYIM would anyone mind giving me a hint? [Tue Aug 20 19:14:01 2013] hi (on an unstable connection, forgive me if i've already asked), i'm trying to learn coq, and i'm stuck on a proof. http://codepad.org/ogRDxYIM would anyone mind giving me a hint? [Tue Aug 20 19:14:30 2013] osa1: yes it fails with Application of .opam/4.00.1/build/coq.8.4pl2/CAML_LD_LIBRARY_PATH.patch failed: can not determine the correct patch level. [Tue Aug 20 19:14:30 2013] osa1: yes it fails with Application of .opam/4.00.1/build/coq.8.4pl2/CAML_LD_LIBRARY_PATH.patch failed: can not determine the correct patch level. [Tue Aug 20 19:20:55 2013] ah, okay than. I'm not very experienced with this stuff but I remember having lots of problems about compiling coq until I discovered opam. then it worked without problems. [Tue Aug 20 19:20:55 2013] ah, okay than. I'm not very experienced with this stuff but I remember having lots of problems about compiling coq until I discovered opam. then it worked without problems. [Tue Aug 20 19:26:31 2013] I just managed :) [Tue Aug 20 19:26:31 2013] I just managed :) [Tue Aug 20 19:28:14 2013] I just linked the .so files which were in .opam/4.00.1/lib/stublibs in their respective lablgtk2 dir also in .opam [Tue Aug 20 19:28:14 2013] I just linked the .so files which were in .opam/4.00.1/lib/stublibs in their respective lablgtk2 dir also in .opam [Tue Aug 20 19:28:20 2013] and coq was happy [Tue Aug 20 19:28:20 2013] and coq was happy [Tue Aug 20 23:21:03 2013] I suspect proof general is ignoring ./_CoqProject [Tue Aug 20 23:21:03 2013] I suspect proof general is ignoring ./_CoqProject [Tue Aug 20 23:21:16 2013] how do I check this (to see where proof general read _CoqProject from) ? [Tue Aug 20 23:21:16 2013] how do I check this (to see where proof general read _CoqProject from) ? [Wed Aug 21 00:00:10 2013] resolved [Wed Aug 21 00:00:10 2013] resolved [Wed Aug 21 00:00:20 2013] apparently needed to confitgure meacs instead of run it as "proof general" [Wed Aug 21 00:00:20 2013] apparently needed to confitgure meacs instead of run it as "proof general" [Wed Aug 21 00:07:25 2013] nope, false hope [Wed Aug 21 00:07:25 2013] nope, false hope [Wed Aug 21 06:31:41 2013] I am able to install coq but it uses camlp4 rather than 5 [Wed Aug 21 06:31:41 2013] I am able to install coq but it uses camlp4 rather than 5 [Wed Aug 21 06:32:21 2013] ./configure -usecamlp5 complains about no camlp5 being found... I do have it though [Wed Aug 21 06:32:21 2013] ./configure -usecamlp5 complains about no camlp5 being found... I do have it though [Wed Aug 21 06:32:33 2013] any idea how what may be going on [Wed Aug 21 06:32:33 2013] any idea how what may be going on [Wed Aug 21 06:33:34 2013] I wouldn't care about it normaly, but then why3 compilation is failing and it seems due to the fact that why3 is being compiled with camlp5 [Wed Aug 21 06:33:35 2013] I wouldn't care about it normaly, but then why3 compilation is failing and it seems due to the fact that why3 is being compiled with camlp5 [Wed Aug 21 07:17:31 2013] watermind: in Debian I use apt-get build-dep coqide to get all dependencies installed, and then a plain ./configure -opt -local; make -j4 works [Wed Aug 21 07:17:31 2013] watermind: in Debian I use apt-get build-dep coqide to get all dependencies installed, and then a plain ./configure -opt -local; make -j4 works [Wed Aug 21 07:49:41 2013] robbert: thank you I'm not using debian though, but I managed meanwhile tio install it with opam [Wed Aug 21 07:49:41 2013] robbert: thank you I'm not using debian though, but I managed meanwhile tio install it with opam [Wed Aug 21 07:49:53 2013] my system was missing the patch utility [Wed Aug 21 07:49:53 2013] my system was missing the patch utility [Wed Aug 21 11:32:41 2013] Any suggestions on why line 11 breaks sigT1 notation? http://paste.debian.net/28033/ It's a simple definition sigT3 which does the obvious thing, and the notation is an extension of that for sigT2 from trunk/Theories/Init/Specif.v . [Wed Aug 21 11:32:41 2013] Any suggestions on why line 11 breaks sigT1 notation? http://paste.debian.net/28033/ It's a simple definition sigT3 which does the obvious thing, and the notation is an extension of that for sigT2 from trunk/Theories/Init/Specif.v . [Wed Aug 21 11:33:09 2013] I'm using sets via FSetInterface and doing some dependently typed programming, and I'd like a decision procedure for subsets, but notice that FSetInterface doesn't have one, am I missing something? [Wed Aug 21 11:33:09 2013] I'm using sets via FSetInterface and doing some dependently typed programming, and I'd like a decision procedure for subsets, but notice that FSetInterface doesn't have one, am I missing something? [Wed Aug 21 11:55:17 2013] kmicinski: Parameter subset : t -> t -> bool. [Wed Aug 21 11:55:17 2013] kmicinski: Parameter subset : t -> t -> bool. [Wed Aug 21 11:55:59 2013] also Sdep has Parameter subset : forall s s' : t, {Subset s s'} + {~ Subset s s'}. [Wed Aug 21 11:55:59 2013] also Sdep has Parameter subset : forall s s' : t, {Subset s s'} + {~ Subset s s'}. [Wed Aug 21 12:41:07 2013] msrcptival: right, I need Sdep, but I wondered why this wasn't a parameter of fsetinterface [Wed Aug 21 12:41:07 2013] msrcptival: right, I need Sdep, but I wondered why this wasn't a parameter of fsetinterface [Wed Aug 21 12:41:25 2013] i.e., can't it be done without sdep's assumptions [Wed Aug 21 12:41:25 2013] i.e., can't it be done without sdep's assumptions [Wed Aug 21 12:43:09 2013] my guess is it can [Wed Aug 21 12:43:09 2013] my guess is it can [Wed Aug 21 12:43:30 2013] since you have the non-dependent subset and the theorem subset_2 [Wed Aug 21 12:43:30 2013] since you have the non-dependent subset and the theorem subset_2 [Wed Aug 21 14:37:25 2013] ryanakca: You want to put your notation "(at level 0, x at level 99)", to fator correctly with the notations for sigT, sigT2. I don't know exactly how notation factoring works, but it's a bit wonky. See theories/Init/Notations.v for the reserved notation lines (with levels), and theories/Init/Specif.v for the actual definitions. [Wed Aug 21 14:37:25 2013] ryanakca: You want to put your notation "(at level 0, x at level 99)", to fator correctly with the notations for sigT, sigT2. I don't know exactly how notation factoring works, but it's a bit wonky. See theories/Init/Notations.v for the reserved notation lines (with levels), and theories/Init/Specif.v for the actual definitions. [Wed Aug 21 15:44:39 2013] so apparently proof general gives infinitey better error msgs on "abstracting foo over bar gives ill-typed term" [Wed Aug 21 15:44:39 2013] so apparently proof general gives infinitey better error msgs on "abstracting foo over bar gives ill-typed term" [Wed Aug 21 18:45:49 2013] Ptival_: ping [Wed Aug 21 18:45:49 2013] Ptival_: ping [Wed Aug 21 19:33:17 2013] pong [Wed Aug 21 19:33:17 2013] pong [Wed Aug 21 20:01:14 2013] Say I want to assert some propositions p1, p2, ..., pn of type Prop. How would I do a forall or exists on them? [Wed Aug 21 20:01:14 2013] Say I want to assert some propositions p1, p2, ..., pn of type Prop. How would I do a forall or exists on them? [Wed Aug 21 20:02:20 2013] hey rola, could you elaborate what you mean by "do a forall or exists"? [Wed Aug 21 20:02:20 2013] hey rola, could you elaborate what you mean by "do a forall or exists"? [Wed Aug 21 20:06:01 2013] Sure. suppose I have "Variables p1 p2 p3 p4 p5 p6 : Prop." and I was wondering how I could state this more consisely using an exists: "Hypothesis h0 : p1 \/ p2 \/ p3 \/ p4 \/ p5 \/ p6." [Wed Aug 21 20:06:01 2013] Sure. suppose I have "Variables p1 p2 p3 p4 p5 p6 : Prop." and I was wondering how I could state this more consisely using an exists: "Hypothesis h0 : p1 \/ p2 \/ p3 \/ p4 \/ p5 \/ p6." [Wed Aug 21 20:11:28 2013] oops. I didn't mean to include 'Hypothesis h0 :' [Wed Aug 21 20:11:28 2013] oops. I didn't mean to include 'Hypothesis h0 :' [Wed Aug 21 20:12:04 2013] kini, Is that a little clearer? [Wed Aug 21 20:12:04 2013] kini, Is that a little clearer? [Wed Aug 21 20:30:08 2013] rola: hmm, I still don't really understand what you want to do, but I'm pretty much a coq beginner myself. Maybe wait for someone else to read your question :) [Wed Aug 21 20:30:08 2013] rola: hmm, I still don't really understand what you want to do, but I'm pretty much a coq beginner myself. Maybe wait for someone else to read your question :) [Wed Aug 21 20:54:32 2013] rola: Well, if they were actually parameterised by some other type, you could then use forall... [Wed Aug 21 20:54:33 2013] rola: Well, if they were actually parameterised by some other type, you could then use forall... [Wed Aug 21 21:01:15 2013] rola: http://lpaste.net/92052 [Wed Aug 21 21:01:15 2013] rola: http://lpaste.net/92052 [Wed Aug 21 21:03:04 2013] rola: Does that make sense? [Wed Aug 21 21:03:04 2013] rola: Does that make sense? [Wed Aug 21 21:09:23 2013] Cale, I think so. So "Fin 6 -> Prop" is a map from the set of 6 elements to Prop? [Wed Aug 21 21:09:24 2013] Cale, I think so. So "Fin 6 -> Prop" is a map from the set of 6 elements to Prop? [Wed Aug 21 21:10:08 2013] yeah [Wed Aug 21 21:10:08 2013] yeah [Wed Aug 21 21:11:08 2013] So you'll have p F0, p (FS F0), p (FS (FS F0)), ... p (FS (FS (FS (FS (FS F0))))) [Wed Aug 21 21:11:08 2013] So you'll have p F0, p (FS F0), p (FS (FS F0)), ... p (FS (FS (FS (FS (FS F0))))) [Wed Aug 21 21:11:29 2013] and H says that one of those is true [Wed Aug 21 21:11:30 2013] and H says that one of those is true [Thu Aug 22 09:12:03 2013] in proof general, how do I hide the "=>" [Thu Aug 22 09:12:03 2013] in proof general, how do I hide the "=>" [Thu Aug 22 09:12:15 2013] it's stupidly annoying for hidng the first 2 characters of what I'm typing [Thu Aug 22 09:12:15 2013] it's stupidly annoying for hidng the first 2 characters of what I'm typing [Thu Aug 22 09:12:28 2013] and also absolutely useless given that the color separation already tells me what's going to be processed next [Thu Aug 22 09:12:28 2013] and also absolutely useless given that the color separation already tells me what's going to be processed next [Thu Aug 22 20:18:46 2013] what is the inverse of intros [Thu Aug 22 20:18:46 2013] what is the inverse of intros [Thu Aug 22 20:18:54 2013] i.e. I wnat to move a hypothesis into the goal as a (hyp -> goal) [Thu Aug 22 20:18:54 2013] i.e. I wnat to move a hypothesis into the goal as a (hyp -> goal) [Thu Aug 22 20:31:29 2013] kini pasted “No title” at http://lpaste.net/92089 [Thu Aug 22 20:31:29 2013] kini pasted “No title” at http://lpaste.net/92089 [Thu Aug 22 20:31:38 2013] clj_newb_2345: ↑ [Thu Aug 22 20:31:39 2013] clj_newb_2345: ↑ [Thu Aug 22 20:38:49 2013] kini: nice, thanks! [Thu Aug 22 20:38:50 2013] kini: nice, thanks! [Thu Aug 22 20:39:01 2013] sure :) [Thu Aug 22 20:39:01 2013] sure :) [Fri Aug 23 11:31:49 2013] so I'm reading about "ex" and "ex_intro" in the Logic chapter of software foundations -- and -- WTF -- is "exist ... ," just a coq notation? [Fri Aug 23 11:31:49 2013] so I'm reading about "ex" and "ex_intro" in the Logic chapter of software foundations -- and -- WTF -- is "exist ... ," just a coq notation? [Fri Aug 23 11:35:46 2013] exist is a tactic to apply ex_intro to the value you give it, and it tries to find the proof that it satisfies the property of the Sigma type [Fri Aug 23 11:35:46 2013] exist is a tactic to apply ex_intro to the value you give it, and it tries to find the proof that it satisfies the property of the Sigma type [Fri Aug 23 11:36:12 2013] sorry, I had a typo [Fri Aug 23 11:36:12 2013] sorry, I had a typo [Fri Aug 23 11:36:17 2013] I meant "exists x, x + 2 = 4" [Fri Aug 23 11:36:17 2013] I meant "exists x, x + 2 = 4" [Fri Aug 23 11:36:25 2013] not "exist 2" (as my original post suggested) [Fri Aug 23 11:36:25 2013] not "exist 2" (as my original post suggested) [Fri Aug 23 11:36:33 2013] so the "exists ... ," = notation [Fri Aug 23 11:36:33 2013] so the "exists ... ," = notation [Fri Aug 23 11:36:36 2013] that's notation for the sigma type. [Fri Aug 23 11:36:36 2013] that's notation for the sigma type. [Fri Aug 23 11:36:50 2013] and 'exist ... ' = tactic for (apply ex ex_intro ... ) [Fri Aug 23 11:36:51 2013] and 'exist ... ' = tactic for (apply ex ex_intro ... ) [Fri Aug 23 11:37:05 2013] and by sigma type, you mean " ex_intro : forall (witness:X), P witness -> ex X P. " right? [Fri Aug 23 11:37:05 2013] and by sigma type, you mean " ex_intro : forall (witness:X), P witness -> ex X P. " right? [Fri Aug 23 11:37:39 2013] That's the introduction rule for the sigma type, ex. [Fri Aug 23 11:37:40 2013] That's the introduction rule for the sigma type, ex. [Fri Aug 23 11:38:38 2013] Inductive types are used in Coq as a replacement for identity types, dependent sums, sums, products and W types that one would find in Martin Lof type theory. [Fri Aug 23 11:38:38 2013] Inductive types are used in Coq as a replacement for identity types, dependent sums, sums, products and W types that one would find in Martin Lof type theory. [Fri Aug 23 11:38:56 2013] I did not understand your last sentence [Fri Aug 23 11:38:56 2013] I did not understand your last sentence [Fri Aug 23 11:39:14 2013] but I think it's okay, basically there is "->", "functions", and Inductive types [Fri Aug 23 11:39:14 2013] but I think it's okay, basically there is "->", "functions", and Inductive types [Fri Aug 23 11:39:18 2013] all else can be built in terms of those [Fri Aug 23 11:39:18 2013] all else can be built in terms of those [Fri Aug 23 11:39:54 2013] essentially. There are lots of nuances with termination checking. [Fri Aug 23 11:39:54 2013] essentially. There are lots of nuances with termination checking. [Fri Aug 23 11:40:18 2013] otherwise, infinite loops can have type "False" [Fri Aug 23 11:40:18 2013] otherwise, infinite loops can have type "False" [Fri Aug 23 11:40:23 2013] so we need to prove that every function terminates [Fri Aug 23 11:40:23 2013] so we need to prove that every function terminates [Fri Aug 23 11:40:25 2013] Coinductive types are also a thing in Coq. [Fri Aug 23 11:40:25 2013] Coinductive types are also a thing in Coq. [Fri Aug 23 11:41:24 2013] There are safe non-terminating programs (tail-recursive functions, for instance), but for a nice meta-theory, strong normalization is a good property for the language to have. [Fri Aug 23 11:41:24 2013] There are safe non-terminating programs (tail-recursive functions, for instance), but for a nice meta-theory, strong normalization is a good property for the language to have. [Fri Aug 23 11:42:15 2013] You can only "construct" False by promising to do so and just never getting there, all other rules being consistent. [Fri Aug 23 11:42:15 2013] You can only "construct" False by promising to do so and just never getting there, all other rules being consistent. [Fri Aug 23 11:46:01 2013] hmm [Fri Aug 23 11:46:01 2013] hmm [Fri Aug 23 11:46:06 2013] is this what the mtac stuff is based upon? [Fri Aug 23 11:46:06 2013] is this what the mtac stuff is based upon? [Fri Aug 23 11:46:13 2013] i.e. you can have a function of type "M False" [Fri Aug 23 11:46:13 2013] i.e. you can have a function of type "M False" [Fri Aug 23 11:46:22 2013] but when you run it, you don't get there,and thus can't construct the False ? [Fri Aug 23 11:46:22 2013] but when you run it, you don't get there,and thus can't construct the False ? [Fri Aug 23 11:46:29 2013] I'm not familiar with mtac [Fri Aug 23 11:46:29 2013] I'm not familiar with mtac [Fri Aug 23 11:47:56 2013] http://plv.mpi-sws.org/mtac/ [Fri Aug 23 11:47:56 2013] http://plv.mpi-sws.org/mtac/ [Fri Aug 23 11:48:15 2013] oh wow, [Fri Aug 23 11:48:15 2013] oh wow, [Fri Aug 23 11:48:20 2013] so "=" is just shorthand for "eq" [Fri Aug 23 11:48:20 2013] so "=" is just shorthand for "eq" [Fri Aug 23 11:48:25 2013] which only has type constructor refl_equal [Fri Aug 23 11:48:25 2013] which only has type constructor refl_equal [Fri Aug 23 11:48:28 2013] this is starting to make so much sense now [Fri Aug 23 11:48:28 2013] this is starting to make so much sense now [Fri Aug 23 11:48:53 2013] :) [Fri Aug 23 11:48:53 2013] :) [Fri Aug 23 14:21:00 2013] yeah this one is nice :) [Fri Aug 23 14:21:00 2013] yeah this one is nice :) [Fri Aug 23 14:29:10 2013] Ptival: eh? [Fri Aug 23 14:29:10 2013] Ptival: eh? [Fri Aug 23 14:46:52 2013] the inductive definition of equality [Fri Aug 23 14:46:52 2013] the inductive definition of equality [Fri Aug 23 14:49:15 2013] Do you know why Bob Harper & co want to interpret equality coinductively? [Fri Aug 23 14:49:15 2013] Do you know why Bob Harper & co want to interpret equality coinductively? [Fri Aug 23 15:40:08 2013] no [Fri Aug 23 15:40:08 2013] no [Sat Aug 24 09:15:02 2013] Can someone point me at documentation (besides the COq tactics description) of how inversion and destruct differ? [Sat Aug 24 09:15:02 2013] Can someone point me at documentation (besides the COq tactics description) of how inversion and destruct differ? [Sat Aug 24 11:51:47 2013] clj_newb_2345: Have you looked at the reference manual (http://coq.inria.fr/refman/general-index.html)? [Sat Aug 24 11:51:48 2013] clj_newb_2345: Have you looked at the reference manual (http://coq.inria.fr/refman/general-index.html)? [Sat Aug 24 12:13:02 2013] jgross_: he left before you were able to lay information on him [Sat Aug 24 12:13:03 2013] jgross_: he left before you were able to lay information on him [Sat Aug 24 14:30:06 2013] https://gist.github.com/anonymous/3cb996e6beb94c17782d <-- why is this even true? (taken from http://www.cis.upenn.edu/~bcpierce/sf/Equiv.html ) [Sat Aug 24 14:30:06 2013] https://gist.github.com/anonymous/3cb996e6beb94c17782d <-- why is this even true? (taken from http://www.cis.upenn.edu/~bcpierce/sf/Equiv.html ) [Sat Aug 24 14:49:14 2013] clj_newb_2345: without I/O it doesn't matter _how_ you diverge [Sat Aug 24 14:49:14 2013] clj_newb_2345: without I/O it doesn't matter _how_ you diverge [Sat Aug 24 14:57:11 2013] right [Sat Aug 24 14:57:11 2013] right [Sat Aug 24 14:57:25 2013] the equiv definition is that for all states, one side termiantes to it iff the otehr side termiantes to it [Sat Aug 24 14:57:25 2013] the equiv definition is that for all states, one side termiantes to it iff the otehr side termiantes to it [Sat Aug 24 14:57:27 2013] in this case, [Sat Aug 24 14:57:27 2013] in this case, [Sat Aug 24 14:57:30 2013] for all states, neither side terminates [Sat Aug 24 14:57:30 2013] for all states, neither side terminates [Sat Aug 24 14:57:37 2013] I'm an idiot :-_) [Sat Aug 24 14:57:37 2013] I'm an idiot :-_) [Sun Aug 25 14:02:46 2013] Hello, everyone. I want to ask a question. I am trying to prove a theorem. The script as follows: Lemma bool_not_eq_True_or_False: ~ (bool=True\/bool=False). [Sun Aug 25 14:02:47 2013] Hello, everyone. I want to ask a question. I am trying to prove a theorem. The script as follows: Lemma bool_not_eq_True_or_False: ~ (bool=True\/bool=False). [Sun Aug 25 14:02:47 2013] Proof. [Sun Aug 25 14:02:47 2013] intros [A|A]. [Sun Aug 25 14:02:47 2013] Proof. [Sun Aug 25 14:02:47 2013] - pose (p X := forall x y:X, x=y). [Sun Aug 25 14:02:47 2013] intros [A|A]. [Sun Aug 25 14:02:47 2013] assert (H: ~ p bool). [Sun Aug 25 14:02:47 2013] - pose (p X := forall x y:X, x=y). [Sun Aug 25 14:02:47 2013] assert (H: ~ p bool). [Sun Aug 25 14:02:48 2013] { intro B. specialize (B true false). discriminate B. } [Sun Aug 25 14:02:48 2013] { intro B. specialize (B true false). discriminate B. } [Sun Aug 25 14:02:50 2013] apply H. rewrite A. [Sun Aug 25 14:02:50 2013] apply H. rewrite A. [Sun Aug 25 14:02:52 2013] intros [] []. reflexivity. [Sun Aug 25 14:02:52 2013] intros [] []. reflexivity. [Sun Aug 25 14:02:54 2013] - pose (p X := forall x : X, False). (*** X is empty ***) [Sun Aug 25 14:02:54 2013] - pose (p X := forall x : X, False). (*** X is empty ***) [Sun Aug 25 14:02:56 2013] assert (H: ~p bool). [Sun Aug 25 14:02:56 2013] assert (H: ~p bool). [Sun Aug 25 14:02:58 2013] { intros B. contradiction (B false). } [Sun Aug 25 14:02:58 2013] { intros B. contradiction (B false). } [Sun Aug 25 14:03:00 2013] apply H. rewrite A. [Sun Aug 25 14:03:00 2013] apply H. rewrite A. [Sun Aug 25 14:03:02 2013] intros []. [Sun Aug 25 14:03:02 2013] intros []. [Sun Aug 25 14:03:04 2013] Qed. [Sun Aug 25 14:03:04 2013] Qed. [Sun Aug 25 14:03:06 2013] Goal (forall X:Type, X = True \/ X = False) -> False. [Sun Aug 25 14:03:06 2013] Goal (forall X:Type, X = True \/ X = False) -> False. [Sun Aug 25 14:03:08 2013] Proof. [Sun Aug 25 14:03:08 2013] Proof. [Sun Aug 25 14:03:10 2013] intro A. specialize (A bool). apply bool_not_eq_True_or_False. exact A. I am stuck here. Why does this happen? [Sun Aug 25 14:03:10 2013] intro A. specialize (A bool). apply bool_not_eq_True_or_False. exact A. I am stuck here. Why does this happen? [Sun Aug 25 16:06:30 2013] I can't compile Coq 8.4: make[1]: *** [doc/stdlib/Library.dvi] Error 1 [Sun Aug 25 16:06:30 2013] I can't compile Coq 8.4: make[1]: *** [doc/stdlib/Library.dvi] Error 1 [Sun Aug 25 16:06:56 2013] I have compiled it when hevea and lablgtk was not installed [Sun Aug 25 16:06:57 2013] I have compiled it when hevea and lablgtk was not installed [Sun Aug 25 16:40:46 2013] in Coq, I know how to say (exists (n: Z), n + 10 = 20). [Sun Aug 25 16:40:46 2013] in Coq, I know how to say (exists (n: Z), n + 10 = 20). [Sun Aug 25 16:40:55 2013] however, how do I say: "there exists an object of type Foo" ? [Sun Aug 25 16:40:55 2013] however, how do I say: "there exists an object of type Foo" ? [Sun Aug 25 16:41:01 2013] I wnat (exists (h: Foo)) [Sun Aug 25 16:41:01 2013] I wnat (exists (h: Foo)) [Sun Aug 25 16:41:06 2013] taht's all, no post conditions after that. [Sun Aug 25 16:41:06 2013] taht's all, no post conditions after that. [Sun Aug 25 16:41:41 2013] just say Foo [Sun Aug 25 16:41:41 2013] just say Foo [Sun Aug 25 16:41:57 2013] if you really want to conceal the value of the Foo outside of Prop, you can say (exists (_ : Foo), True). [Sun Aug 25 16:41:57 2013] if you really want to conceal the value of the Foo outside of Prop, you can say (exists (_ : Foo), True). [Sun Aug 25 16:42:05 2013] or define [Sun Aug 25 16:42:05 2013] or define [Sun Aug 25 16:42:09 2013] Inductive inhabited A : Prop := [Sun Aug 25 16:42:09 2013] Inductive inhabited A : Prop := [Sun Aug 25 16:42:12 2013] erm [Sun Aug 25 16:42:12 2013] erm [Sun Aug 25 16:42:17 2013] Inductive inhabited A : Prop := witness : A -> inhabited A. [Sun Aug 25 16:42:17 2013] Inductive inhabited A : Prop := witness : A -> inhabited A. [Sun Aug 25 16:44:18 2013] ah, I get it now [Sun Aug 25 16:44:18 2013] ah, I get it now [Sun Aug 25 16:44:22 2013] thanks [Sun Aug 25 16:44:22 2013] thanks [Sun Aug 25 17:06:25 2013] Why does Coq build fail on compiling something tex? [Sun Aug 25 17:06:25 2013] Why does Coq build fail on compiling something tex? [Sun Aug 25 17:06:58 2013] I'm trying to rebuild removing hevea-2.09 [Sun Aug 25 17:06:58 2013] I'm trying to rebuild removing hevea-2.09 [Sun Aug 25 17:07:18 2013] Maybe it will finish now [Sun Aug 25 17:07:19 2013] Maybe it will finish now [Sun Aug 25 18:00:41 2013] I have fake_ide compiled, but there seem no coq-ide [Sun Aug 25 18:00:41 2013] I have fake_ide compiled, but there seem no coq-ide [Sun Aug 25 19:39:19 2013] do you have ocaml gtk? [Sun Aug 25 19:39:19 2013] do you have ocaml gtk? [Sun Aug 25 19:39:23 2013] also, use proof general [Sun Aug 25 19:39:23 2013] also, use proof general [Sun Aug 25 19:39:33 2013] I wish I listened to the "listen proof general" 6 months ago [Sun Aug 25 19:39:33 2013] I wish I listened to the "listen proof general" 6 months ago [Mon Aug 26 08:20:32 2013] I'm having trouble defining map for my dependently typed binary tree... [Mon Aug 26 08:20:32 2013] I'm having trouble defining map for my dependently typed binary tree... [Mon Aug 26 08:20:59 2013] Get this weird error: The term "l" has type "bvec T n" while it is expected to have type "bvec T ?4". [Mon Aug 26 08:20:59 2013] Get this weird error: The term "l" has type "bvec T n" while it is expected to have type "bvec T ?4". [Mon Aug 26 08:25:36 2013] Hmm I think my definition of binary trees was a bit wrong [Mon Aug 26 08:25:36 2013] Hmm I think my definition of binary trees was a bit wrong [Mon Aug 26 08:27:07 2013] nope still same issue [Mon Aug 26 08:27:07 2013] nope still same issue [Mon Aug 26 08:34:46 2013] bam got it, the dependent variable was quantified in the wrong place [Mon Aug 26 08:34:46 2013] bam got it, the dependent variable was quantified in the wrong place [Mon Aug 26 08:35:35 2013] ColonelJ: \o/ [Mon Aug 26 08:35:35 2013] ColonelJ: \o/ [Mon Aug 26 08:38:19 2013] unrelated: "BNode (log2len : nat) : ..." vs "BNode : forall log2len : nat, ..." which is preferred? [Mon Aug 26 08:38:19 2013] unrelated: "BNode (log2len : nat) : ..." vs "BNode : forall log2len : nat, ..." which is preferred? [Mon Aug 26 08:40:05 2013] Even though the argument is implicit it counts as one of the constructor arguments either way... which makes me lean towards the more concise form [Mon Aug 26 08:40:05 2013] Even though the argument is implicit it counts as one of the constructor arguments either way... which makes me lean towards the more concise form [Mon Aug 26 08:57:32 2013] It doesn't seem to understand that two trees of the same size are the same size and use the same constructor... this is a bit crap [Mon Aug 26 08:57:32 2013] It doesn't seem to understand that two trees of the same size are the same size and use the same constructor... this is a bit crap [Mon Aug 26 09:00:23 2013] you can omit :nat with forall [Mon Aug 26 09:00:24 2013] you can omit :nat with forall [Mon Aug 26 09:00:26 2013] usually [Mon Aug 26 09:00:26 2013] usually [Mon Aug 26 09:01:03 2013] Actually I can omit on the other side too so the question remains [Mon Aug 26 09:01:03 2013] Actually I can omit on the other side too so the question remains [Mon Aug 26 09:01:13 2013] thanks though [Mon Aug 26 09:01:13 2013] thanks though [Mon Aug 26 09:02:18 2013] Anyway that doesn't really matter, how can I match two of these together so I don't get (BLeaf _, BNode _ _ _) which is impossible since they're the same size [Mon Aug 26 09:02:18 2013] Anyway that doesn't really matter, how can I match two of these together so I don't get (BLeaf _, BNode _ _ _) which is impossible since they're the same size [Mon Aug 26 09:02:34 2013] I mean "Error: Non exhaustive pattern-matching: no clause found for pattern (BLeaf _, BNode _ _ _)" [Mon Aug 26 09:02:34 2013] I mean "Error: Non exhaustive pattern-matching: no clause found for pattern (BLeaf _, BNode _ _ _)" [Mon Aug 26 09:03:35 2013] I may well be going about this the wrong way by pairing them [Mon Aug 26 09:03:35 2013] I may well be going about this the wrong way by pairing them [Mon Aug 26 09:05:17 2013] ColonelJ: i prefer first form for BNode (log2len :nat) [Mon Aug 26 09:05:17 2013] ColonelJ: i prefer first form for BNode (log2len :nat) [Mon Aug 26 09:08:04 2013] "Fixpoint zip (T U V : Set) (f : T -> U -> V) n (l : bvec T n) (r : bvec U n) := match (l, r) with ..." anyone know how to do this so it works/ [Mon Aug 26 09:08:04 2013] "Fixpoint zip (T U V : Set) (f : T -> U -> V) n (l : bvec T n) (r : bvec U n) := match (l, r) with ..." anyone know how to do this so it works/ [Mon Aug 26 09:11:56 2013] mmh I'll try matching on n instead [Mon Aug 26 09:11:56 2013] mmh I'll try matching on n instead [Mon Aug 26 09:14:25 2013] I still need to be able to deconstruct the vectors somehow... [Mon Aug 26 09:14:25 2013] I still need to be able to deconstruct the vectors somehow... [Mon Aug 26 09:17:20 2013] no I don't want deconstructed coq au vin, thanks google [Mon Aug 26 09:17:20 2013] no I don't want deconstructed coq au vin, thanks google [Mon Aug 26 09:36:08 2013] ended up just writing my own deconstructors [Mon Aug 26 09:36:09 2013] ended up just writing my own deconstructors [Mon Aug 26 09:36:11 2013] using let [Mon Aug 26 09:36:11 2013] using let [Mon Aug 26 09:36:23 2013] which for some bizarre reason actually works [Mon Aug 26 09:36:23 2013] which for some bizarre reason actually works [Mon Aug 26 09:37:23 2013] Definition bvec_leaf T (v : bvec T 0) := let 'BLeaf a := v in a. [Mon Aug 26 09:37:23 2013] Definition bvec_l T n (v : bvec T (S n)) := let 'BNode n l _ := v in l. [Mon Aug 26 09:37:23 2013] Definition bvec_leaf T (v : bvec T 0) := let 'BLeaf a := v in a. [Mon Aug 26 09:37:23 2013] Definition bvec_l T n (v : bvec T (S n)) := let 'BNode n l _ := v in l. [Mon Aug 26 09:42:58 2013] I think binding the vectors before the match is causing the problem... maybe [Mon Aug 26 09:42:58 2013] I think binding the vectors before the match is causing the problem... maybe [Mon Aug 26 09:43:18 2013] I'll move them inside the match [Mon Aug 26 09:43:18 2013] I'll move them inside the match [Mon Aug 26 09:45:52 2013] "Unable to communicate with coqtop, restarting coqtop." [Mon Aug 26 09:45:53 2013] "Unable to communicate with coqtop, restarting coqtop." [Mon Aug 26 09:46:00 2013] this is really fun this [Mon Aug 26 09:46:00 2013] this is really fun this [Mon Aug 26 09:50:52 2013] New idea: make an inductive type to represent a pair of vectors so I can actually match it [Mon Aug 26 09:50:52 2013] New idea: make an inductive type to represent a pair of vectors so I can actually match it [Mon Aug 26 09:54:15 2013] oh wait BNode already does that :D [Mon Aug 26 09:54:15 2013] oh wait BNode already does that :D [Mon Aug 26 10:00:17 2013] Damn this awesome hack requires that the lists are of the same type, I guess I can live with that for this proof.. [Mon Aug 26 10:00:17 2013] Damn this awesome hack requires that the lists are of the same type, I guess I can live with that for this proof.. [Mon Aug 26 10:02:20 2013] incredibly somehow it manages to still not work [Mon Aug 26 10:02:21 2013] incredibly somehow it manages to still not work [Mon Aug 26 10:03:43 2013] Possibly because it's too stupid to realise that matching an expression which is even lexically determinable to be a BNode still might be a BLeaf by some kind of magic but it's hard to tell due to the complete lack of detail in the error [Mon Aug 26 10:03:44 2013] Possibly because it's too stupid to realise that matching an expression which is even lexically determinable to be a BNode still might be a BLeaf by some kind of magic but it's hard to tell due to the complete lack of detail in the error [Mon Aug 26 10:04:04 2013] "Error: Non exhaustive pattern-matching: no clause found for pattern BLeaf _" thanks [Mon Aug 26 10:04:04 2013] "Error: Non exhaustive pattern-matching: no clause found for pattern BLeaf _" thanks [Mon Aug 26 10:09:43 2013] So lets go back to the original idea and have a different constructor for a pair of leaves versus a pair of trees... [Mon Aug 26 10:09:43 2013] So lets go back to the original idea and have a different constructor for a pair of leaves versus a pair of trees... [Mon Aug 26 10:10:25 2013] and of course remove the same type restriction [Mon Aug 26 10:10:25 2013] and of course remove the same type restriction [Mon Aug 26 10:16:55 2013] And then I need a function that will pick the constructor based on the size of the lists... [Mon Aug 26 10:16:55 2013] And then I need a function that will pick the constructor based on the size of the lists... [Mon Aug 26 10:20:35 2013] lol that issue with match not restricting the domain again [Mon Aug 26 10:20:36 2013] lol that issue with match not restricting the domain again [Mon Aug 26 10:21:16 2013] if I try to split it inside coqtop will probably crash again [Mon Aug 26 10:21:17 2013] if I try to split it inside coqtop will probably crash again [Mon Aug 26 10:21:24 2013] no harm in trying [Mon Aug 26 10:21:24 2013] no harm in trying [Mon Aug 26 10:23:11 2013] yup as expected [Mon Aug 26 10:23:11 2013] yup as expected [Mon Aug 26 11:34:07 2013] Anyone now how to define any sensible version of zip for some type of length indexed lists? Just need any one as an example... [Mon Aug 26 11:34:07 2013] Anyone now how to define any sensible version of zip for some type of length indexed lists? Just need any one as an example... [Mon Aug 26 11:51:08 2013] zip as in map cons over two lists of the same size? [Mon Aug 26 11:51:08 2013] zip as in map cons over two lists of the same size? [Mon Aug 26 11:51:42 2013] It doesn't even have to be cons but yea. [Mon Aug 26 11:51:42 2013] It doesn't even have to be cons but yea. [Mon Aug 26 11:54:00 2013] I basically want it by induction on the length so that you can't cheat and define junk values for zip on lists of different length (though it's getting to the point where that's the route I want to go down) [Mon Aug 26 11:54:01 2013] I basically want it by induction on the length so that you can't cheat and define junk values for zip on lists of different length (though it's getting to the point where that's the route I want to go down) [Mon Aug 26 11:54:27 2013] a regular definition would just truncate one of the lists if the lengths are different [Mon Aug 26 11:54:27 2013] a regular definition would just truncate one of the lists if the lengths are different [Mon Aug 26 11:57:25 2013] ColonelJ: Agda's dependent pattern matching is great for this. In Coq, you have to use the convoy pattern and convince the type system that ill-matched lengths are absurd, and thus admits the result type. [Mon Aug 26 11:57:25 2013] ColonelJ: Agda's dependent pattern matching is great for this. In Coq, you have to use the convoy pattern and convince the type system that ill-matched lengths are absurd, and thus admits the result type. [Mon Aug 26 11:57:50 2013] Convoy pattern: http://adam.chlipala.net/cpdt/html/MoreDep.html [Mon Aug 26 11:57:50 2013] Convoy pattern: http://adam.chlipala.net/cpdt/html/MoreDep.html [Mon Aug 26 11:57:54 2013] yea I saw a paper for Agda on this but nothing on Coq [Mon Aug 26 11:57:54 2013] yea I saw a paper for Agda on this but nothing on Coq [Mon Aug 26 11:58:37 2013] Ya, you match on both arguments but have to maintain a proof of equality between the length indices with the convoy pattern. [Mon Aug 26 11:58:37 2013] Ya, you match on both arguments but have to maintain a proof of equality between the length indices with the convoy pattern. [Mon Aug 26 11:58:58 2013] I thought you'd have to do something like that but had no idea how to go about it [Mon Aug 26 11:58:58 2013] I thought you'd have to do something like that but had no idea how to go about it [Mon Aug 26 11:59:17 2013] actually I've been working through CPDT but I'm only on chapter 4 [Mon Aug 26 11:59:17 2013] actually I've been working through CPDT but I'm only on chapter 4 [Mon Aug 26 12:00:42 2013] It's rather clunky. There is an extension to Coq called "equations" that has Agda-style dependent pattern matching. I'm not sure if it postulates Axiom K the way Agda does. [Mon Aug 26 12:00:42 2013] It's rather clunky. There is an extension to Coq called "equations" that has Agda-style dependent pattern matching. I'm not sure if it postulates Axiom K the way Agda does. [Mon Aug 26 12:01:43 2013] Axiom K is equivalent to uniqueness of identity proofs, which essentially means all types have discrete topology (i.e. are sets). [Mon Aug 26 12:01:43 2013] Axiom K is equivalent to uniqueness of identity proofs, which essentially means all types have discrete topology (i.e. are sets). [Mon Aug 26 12:02:44 2013] Homotopy type theory explores the world without UIP, but there is yet evidence that it helps programmers whatsoever. [Mon Aug 26 12:02:44 2013] Homotopy type theory explores the world without UIP, but there is yet evidence that it helps programmers whatsoever. [Mon Aug 26 12:03:24 2013] The univalence axiom is really nice, however, but I'm pretty sure it's not consistent with Axiom K. [Mon Aug 26 12:03:24 2013] The univalence axiom is really nice, however, but I'm pretty sure it's not consistent with Axiom K. [Mon Aug 26 12:06:07 2013] CPDT seems to touch on this in chapter 10 so I guess it can wait :P [Mon Aug 26 12:06:07 2013] CPDT seems to touch on this in chapter 10 so I guess it can wait :P [Mon Aug 26 12:09:04 2013] "this" is? [Mon Aug 26 12:09:04 2013] "this" is? [Mon Aug 26 12:09:39 2013] Axiom K and UIP [Mon Aug 26 12:09:40 2013] Axiom K and UIP [Mon Aug 26 12:09:45 2013] ah [Mon Aug 26 12:09:45 2013] ah [Mon Aug 26 12:10:20 2013] anyway I'm mostly trying to learn all this stuff since I'm trying to create what could potentially be a stack-oriented dependent programming language [Mon Aug 26 12:10:20 2013] anyway I'm mostly trying to learn all this stuff since I'm trying to create what could potentially be a stack-oriented dependent programming language [Mon Aug 26 12:10:33 2013] Honestly they're nice shortcuts, just like LEM. We just need to learn to live without them to get better things in life. [Mon Aug 26 12:10:33 2013] Honestly they're nice shortcuts, just like LEM. We just need to learn to live without them to get better things in life. [Mon Aug 26 12:10:37 2013] though the loss of Turing completeness remains to be the main concern [Mon Aug 26 12:10:38 2013] though the loss of Turing completeness remains to be the main concern [Mon Aug 26 12:10:57 2013] I see [Mon Aug 26 12:10:58 2013] I see [Mon Aug 26 12:11:35 2013] Turing-completeness is inconsequential if you work in the non-termination monad and just keep pulling on your computation. [Mon Aug 26 12:11:35 2013] Turing-completeness is inconsequential if you work in the non-termination monad and just keep pulling on your computation. [Mon Aug 26 12:12:17 2013] I honestly have no idea whether or not that's a joke... [Mon Aug 26 12:12:17 2013] I honestly have no idea whether or not that's a joke... [Mon Aug 26 12:12:33 2013] Run TM for n steps for fixed n is not Turing-complete, but you as the user can input n. [Mon Aug 26 12:12:33 2013] Run TM for n steps for fixed n is not Turing-complete, but you as the user can input n. [Mon Aug 26 12:12:57 2013] Ah right I already know about that one [Mon Aug 26 12:12:57 2013] Ah right I already know about that one [Mon Aug 26 12:13:34 2013] but if you can prove the upper bound works then you already know it's not terminating [Mon Aug 26 12:13:35 2013] but if you can prove the upper bound works then you already know it's not terminating [Mon Aug 26 12:13:47 2013] s/not// [Mon Aug 26 12:13:47 2013] s/not// [Mon Aug 26 12:13:48 2013] Loss of Turing-completeness is not a cause for concern. Cause for concern is having to ask people how the hell to program in the language because the type system is so hard to use. [Mon Aug 26 12:13:48 2013] Loss of Turing-completeness is not a cause for concern. Cause for concern is having to ask people how the hell to program in the language because the type system is so hard to use. [Mon Aug 26 12:14:23 2013] I/O-ful programs are codata, Agda program can easily spin forever [Mon Aug 26 12:14:23 2013] I/O-ful programs are codata, Agda program can easily spin forever [Mon Aug 26 12:14:26 2013] *programs [Mon Aug 26 12:14:26 2013] *programs [Mon Aug 26 12:14:31 2013] no loss of turing completeness [Mon Aug 26 12:14:31 2013] no loss of turing completeness [Mon Aug 26 12:14:51 2013] witness https://github.com/wouter-swierstra/Brainfuck [Mon Aug 26 12:14:51 2013] witness https://github.com/wouter-swierstra/Brainfuck [Mon Aug 26 12:14:56 2013] that sounds more useful [Mon Aug 26 12:14:56 2013] that sounds more useful [Mon Aug 26 12:15:02 2013] Usually to write the function to calculate the upper-bound of the number of steps requires the same termination argument for the original function. [Mon Aug 26 12:15:02 2013] Usually to write the function to calculate the upper-bound of the number of steps requires the same termination argument for the original function. [Mon Aug 26 12:16:14 2013] would make sense [Mon Aug 26 12:16:14 2013] would make sense [Mon Aug 26 12:16:18 2013] e.g. how many steps does the Ackermann function take to terminate? The function to compute that number has just about the same recursion scheme. [Mon Aug 26 12:16:18 2013] e.g. how many steps does the Ackermann function take to terminate? The function to compute that number has just about the same recursion scheme. [Mon Aug 26 12:16:57 2013] This is why we use ordinal numbers to justify termination, since natural numbers are far too weak. [Mon Aug 26 12:16:57 2013] This is why we use ordinal numbers to justify termination, since natural numbers are far too weak. [Mon Aug 26 12:22:42 2013] haven't really done anything with those, sounds a bit crazy [Mon Aug 26 12:22:42 2013] haven't really done anything with those, sounds a bit crazy [Mon Aug 26 12:24:25 2013] well luckily I'm the only intended user of this language and I ought to be able to understand it be definiton since I would have made it... [Mon Aug 26 12:24:25 2013] well luckily I'm the only intended user of this language and I ought to be able to understand it be definiton since I would have made it... [Mon Aug 26 12:30:58 2013] Would you say Agda is more practical for programming then? [Mon Aug 26 12:30:58 2013] Would you say Agda is more practical for programming then? [Mon Aug 26 12:31:49 2013] Does it have considerable downsides compared to Coq? [Mon Aug 26 12:31:49 2013] Does it have considerable downsides compared to Coq? [Mon Aug 26 12:33:27 2013] It's better on the surface, like for demos and such, but any time you use sufficiently complicated types, you end up needing to do theorem proving, and Agda is very poorly equipped to handle large proof efforts as it currently is. I think tactics are considered an anti-pattern and they don't want to add support for them. [Mon Aug 26 12:33:27 2013] It's better on the surface, like for demos and such, but any time you use sufficiently complicated types, you end up needing to do theorem proving, and Agda is very poorly equipped to handle large proof efforts as it currently is. I think tactics are considered an anti-pattern and they don't want to add support for them. [Mon Aug 26 12:33:56 2013] that's funny [Mon Aug 26 12:33:56 2013] that's funny [Mon Aug 26 12:34:23 2013] I thought tactics were the only thing that made this kind of programming barely tolerable [Mon Aug 26 12:34:23 2013] I thought tactics were the only thing that made this kind of programming barely tolerable [Mon Aug 26 12:35:01 2013] doesn't that imply you have to write out pretty much everything? [Mon Aug 26 12:35:01 2013] doesn't that imply you have to write out pretty much everything? [Mon Aug 26 12:35:11 2013] Agda isn't against tactics in general [Mon Aug 26 12:35:11 2013] Agda isn't against tactics in general [Mon Aug 26 12:36:32 2013] but it'd like reflection based "solvers" more than arbitrary proof search, though the support for reflection is not quite there either [Mon Aug 26 12:36:32 2013] but it'd like reflection based "solvers" more than arbitrary proof search, though the support for reflection is not quite there either [Mon Aug 26 12:37:10 2013] I'm not a fan of reflection at all [Mon Aug 26 12:37:10 2013] I'm not a fan of reflection at all [Mon Aug 26 12:37:46 2013] much rather have everything within a self-consistent framework [Mon Aug 26 12:37:46 2013] much rather have everything within a self-consistent framework [Mon Aug 26 12:38:25 2013] by reflection i mean something like mtac in Coq [Mon Aug 26 12:38:25 2013] by reflection i mean something like mtac in Coq [Mon Aug 26 12:40:11 2013] so you actually get to write Coq programs that generate your proofs, rather than using ltac, but you have extra support for looking at your types in a more intensional way [Mon Aug 26 12:40:11 2013] so you actually get to write Coq programs that generate your proofs, rather than using ltac, but you have extra support for looking at your types in a more intensional way [Mon Aug 26 12:42:01 2013] I still get the feeling of something 'other' which is outside of your regular code, the whole use of the monad to wrap everything supports this interpretation [Mon Aug 26 12:42:01 2013] I still get the feeling of something 'other' which is outside of your regular code, the whole use of the monad to wrap everything supports this interpretation [Mon Aug 26 12:42:24 2013] oh, sure [Mon Aug 26 12:42:24 2013] oh, sure [Mon Aug 26 12:42:38 2013] but Ltac is completely other, for comparison :) [Mon Aug 26 12:42:38 2013] but Ltac is completely other, for comparison :) [Mon Aug 26 12:43:32 2013] Ltac has nothing to do with runtime so I see it as more of a code generator, which is not reflection nor a problem [Mon Aug 26 12:43:32 2013] Ltac has nothing to do with runtime so I see it as more of a code generator, which is not reflection nor a problem [Mon Aug 26 12:43:49 2013] Ltac gives a human interface to automate the efforts of proving things [Mon Aug 26 12:43:49 2013] Ltac gives a human interface to automate the efforts of proving things [Mon Aug 26 12:44:12 2013] well, the reflection stuff that is 'other' is not runtime either [Mon Aug 26 12:44:13 2013] well, the reflection stuff that is 'other' is not runtime either [Mon Aug 26 12:44:26 2013] you just get to use within the same language that you also use for runtime [Mon Aug 26 12:44:26 2013] you just get to use within the same language that you also use for runtime [Mon Aug 26 12:45:08 2013] fine, but then the question remains of why this is a good thing? [Mon Aug 26 12:45:08 2013] fine, but then the question remains of why this is a good thing? [Mon Aug 26 12:45:10 2013] How does the phasing work, then? [Mon Aug 26 12:45:10 2013] How does the phasing work, then? [Mon Aug 26 12:45:10 2013] there's still a phase distinction, hence the typechecker executing mtac's run [Mon Aug 26 12:45:10 2013] there's still a phase distinction, hence the typechecker executing mtac's run [Mon Aug 26 12:48:18 2013] there are various points, essentially if you like the expressivity of a dependently typed functional language it seems weird to go back to a mostly untyped logic one to write your macros, even if richer types are not always better [Mon Aug 26 12:48:18 2013] there are various points, essentially if you like the expressivity of a dependently typed functional language it seems weird to go back to a mostly untyped logic one to write your macros, even if richer types are not always better [Mon Aug 26 12:49:09 2013] I am an extremely big fan of the choice to use untyped variants, since it only has to work for my input, not generally. [Mon Aug 26 12:49:09 2013] I am an extremely big fan of the choice to use untyped variants, since it only has to work for my input, not generally. [Mon Aug 26 12:49:33 2013] also traditionally these macros tend to have more of a declarative meaning than other tactics [Mon Aug 26 12:49:34 2013] also traditionally these macros tend to have more of a declarative meaning than other tactics [Mon Aug 26 12:50:17 2013] I do most of my real programming in Racket, since its macro system is sooooo powerful - static typing pretty much breaks down since you end up having to prove compiler-correctness for each macro, which is untenable. [Mon Aug 26 12:50:18 2013] I do most of my real programming in Racket, since its macro system is sooooo powerful - static typing pretty much breaks down since you end up having to prove compiler-correctness for each macro, which is untenable. [Mon Aug 26 12:50:57 2013] if you look at mtac's examples you don't need that deep of a verification to use them [Mon Aug 26 12:50:57 2013] if you look at mtac's examples you don't need that deep of a verification to use them [Mon Aug 26 12:51:49 2013] I don't think understand the extent of craziness I'm used to being allowed to do. [Mon Aug 26 12:51:49 2013] I don't think understand the extent of craziness I'm used to being allowed to do. [Mon Aug 26 12:53:22 2013] well, there's always a tension between power and ability to reason about the code [Mon Aug 26 12:53:23 2013] well, there's always a tension between power and ability to reason about the code [Mon Aug 26 12:53:52 2013] I suspect you don't need nukes most of the time and can enjoy some more well-behavedness then [Mon Aug 26 12:53:52 2013] I suspect you don't need nukes most of the time and can enjoy some more well-behavedness then [Mon Aug 26 12:55:32 2013] I get the feeling that this reflection based stuff is not really giving you any separation of concerns and implies that you actually care about your tactics always working when in actual fact you don't care about that and are just trying to speed up the proof effort [Mon Aug 26 12:55:32 2013] I get the feeling that this reflection based stuff is not really giving you any separation of concerns and implies that you actually care about your tactics always working when in actual fact you don't care about that and are just trying to speed up the proof effort [Mon Aug 26 12:55:46 2013] Meta-programming is a realm that's very poorly understood (and thus there are no good type systems for them), so I'd prefer to have a dynamically-typed system than something too weak to do anything. [Mon Aug 26 12:55:46 2013] Meta-programming is a realm that's very poorly understood (and thus there are no good type systems for them), so I'd prefer to have a dynamically-typed system than something too weak to do anything. [Mon Aug 26 12:56:11 2013] ianjneu: have you looked at mtac? [Mon Aug 26 12:56:11 2013] ianjneu: have you looked at mtac? [Mon Aug 26 12:56:14 2013] ColonelJ: that is my sentiment as well. [Mon Aug 26 12:56:14 2013] ColonelJ: that is my sentiment as well. [Mon Aug 26 12:56:37 2013] Saizan: I haven't used Coq in a while. Too busy writing code that I can actually run. [Mon Aug 26 12:56:37 2013] Saizan: I haven't used Coq in a while. Too busy writing code that I can actually run. [Mon Aug 26 12:56:50 2013] that was a bit of a troll, sorry. [Mon Aug 26 12:56:50 2013] that was a bit of a troll, sorry. [Mon Aug 26 12:58:10 2013] ColonelJ: you don't need a language barrier to separate concerns, and caring about always working is entirely up to the type you want to give to your macro [Mon Aug 26 12:58:10 2013] ColonelJ: you don't need a language barrier to separate concerns, and caring about always working is entirely up to the type you want to give to your macro [Mon Aug 26 12:59:16 2013] actually in mtac failure is integrated in the monad so you don't get to specify your macro will always work for some class of inputs, but that's up to them [Mon Aug 26 12:59:17 2013] actually in mtac failure is integrated in the monad so you don't get to specify your macro will always work for some class of inputs, but that's up to them [Mon Aug 26 12:59:45 2013] ianjneu: well, i guess you can see reflection as research into meta-programming [Mon Aug 26 12:59:45 2013] ianjneu: well, i guess you can see reflection as research into meta-programming [Mon Aug 26 13:01:07 2013] Saizan: indeed. I'm excited about the frontier in this direction. I just don't want a dependence on an unknown frontier for the work I'm currently doing. [Mon Aug 26 13:01:07 2013] Saizan: indeed. I'm excited about the frontier in this direction. I just don't want a dependence on an unknown frontier for the work I'm currently doing. [Mon Aug 26 13:04:40 2013] if to quote CPTD we "require semi-automated proving, to protect the sanity of the programmer" then maybe having a language barrier to at least divide the brain processes a bit wouldn't half help [Mon Aug 26 13:04:40 2013] if to quote CPTD we "require semi-automated proving, to protect the sanity of the programmer" then maybe having a language barrier to at least divide the brain processes a bit wouldn't half help [Mon Aug 26 13:06:08 2013] Adam can say many provocative things, but that quote I wholeheartedly agree with. [Mon Aug 26 13:06:08 2013] Adam can say many provocative things, but that quote I wholeheartedly agree with. [Mon Aug 26 13:16:17 2013] maybe lacking the language barrier can be mind bending at first, but honestly that's how macro systems are done in many languages already, but ultimately it just seems a simpler system to me [Mon Aug 26 13:16:17 2013] maybe lacking the language barrier can be mind bending at first, but honestly that's how macro systems are done in many languages already, but ultimately it just seems a simpler system to me [Mon Aug 26 13:16:47 2013] anyhow i wouldn't take ltac away from anyone :) [Mon Aug 26 13:16:47 2013] anyhow i wouldn't take ltac away from anyone :) [Mon Aug 26 13:18:17 2013] ianjneu: my friend says you can do dependent matching using the "match in return with" syntax. Any comments? [Mon Aug 26 13:18:18 2013] ianjneu: my friend says you can do dependent matching using the "match in return with" syntax. Any comments? [Mon Aug 26 13:19:04 2013] ColonelJ: That is exactly right (see previous comment about the convoy pattern). It's just really cumbersome and requires repeating binders. [Mon Aug 26 13:19:04 2013] ColonelJ: That is exactly right (see previous comment about the convoy pattern). It's just really cumbersome and requires repeating binders. [Mon Aug 26 13:20:12 2013] He seemed to be implying that the convoy pattern is overkill but it might just be he doesn't know what it is (I still don't). [Mon Aug 26 13:20:12 2013] He seemed to be implying that the convoy pattern is overkill but it might just be he doesn't know what it is (I still don't). [Mon Aug 26 13:20:29 2013] yeah, i think there's code by roconnorfor zipping size-indexed vectors together which shows how ugly it can be for even simple stuff [Mon Aug 26 13:20:29 2013] yeah, i think there's code by roconnorfor zipping size-indexed vectors together which shows how ugly it can be for even simple stuff [Mon Aug 26 13:20:31 2013] Anyway I'll have to come back to this another day, there's no time left [Mon Aug 26 13:20:31 2013] Anyway I'll have to come back to this another day, there's no time left [Mon Aug 26 14:02:49 2013] I have OCaml GTK (lablgtk-2.14.2), but CoqIde is not compiled anyway. Include files present. [Mon Aug 26 14:02:49 2013] I have OCaml GTK (lablgtk-2.14.2), but CoqIde is not compiled anyway. Include files present. [Mon Aug 26 15:21:34 2013] ColonelJ: still looking for an indexed list zip> [Mon Aug 26 15:21:34 2013] ColonelJ: still looking for an indexed list zip> [Mon Aug 26 15:24:06 2013] here's one for ilist from CPDT: https://gist.github.com/anonymous/6345513 [Mon Aug 26 15:24:06 2013] here's one for ilist from CPDT: https://gist.github.com/anonymous/6345513 [Mon Aug 26 15:53:23 2013] or the generalized version of map2: https://gist.github.com/anonymous/6345872 [Mon Aug 26 15:53:23 2013] or the generalized version of map2: https://gist.github.com/anonymous/6345872 [Mon Aug 26 15:55:18 2013] the trick is to delay binding the length of the second list until after matching on the first list so that the type is refined [Mon Aug 26 15:55:18 2013] the trick is to delay binding the length of the second list until after matching on the first list so that the type is refined [Mon Aug 26 16:13:21 2013] Hi guys. I started learning Coq yesterday, I am trying to prove some propositional logic stuff and I'm stuck about what tactic I should use next: http://lpaste.net/92199 [Mon Aug 26 16:13:21 2013] Hi guys. I started learning Coq yesterday, I am trying to prove some propositional logic stuff and I'm stuck about what tactic I should use next: http://lpaste.net/92199 [Mon Aug 26 16:14:50 2013] I guess I should use the fact that bool has decidable equality and then do some proof by cases, but I just fail :( [Mon Aug 26 16:14:50 2013] I guess I should use the fact that bool has decidable equality and then do some proof by cases, but I just fail :( [Mon Aug 26 16:30:24 2013] karlicoss: not really. if you look at the second rule of the "eval" fixpoint, you'll notice it matches the pab hypothesis in your context. [Mon Aug 26 16:30:24 2013] karlicoss: not really. if you look at the second rule of the "eval" fixpoint, you'll notice it matches the pab hypothesis in your context. [Mon Aug 26 16:31:15 2013] now, this means that pab really says something about implb. Try to see what kind of lemmas you have about implb. [Mon Aug 26 16:31:15 2013] now, this means that pab really says something about implb. Try to see what kind of lemmas you have about implb. [Mon Aug 26 16:33:01 2013] Coq < Eval compute in (factorial 10). [Mon Aug 26 16:33:02 2013] Coq < Eval compute in (factorial 10). [Mon Aug 26 16:33:02 2013] rlwrap: warning: coqtop killed by SIGSEGV. [Mon Aug 26 16:33:02 2013] rlwrap: warning: coqtop killed by SIGSEGV. [Mon Aug 26 16:33:09 2013] Am I doing something wrong? [Mon Aug 26 16:33:09 2013] Am I doing something wrong? [Mon Aug 26 16:33:29 2013] I'm trying to play with factorial recursive definition [Mon Aug 26 16:33:29 2013] I'm trying to play with factorial recursive definition [Mon Aug 26 18:17:17 2013] gereedy: thanks a lot! Your 'trick' didn't work out for me though (maybe I didn't do it correctly?) but I did find something with did https://gist.github.com/ColonelJ/6347203. However my working solution does have the unwanted side effect of making the length an explicit argument. Anyway it looks pretty simple after all and I don't see any of those repeated binder problems or any such thing. [Mon Aug 26 18:17:17 2013] gereedy: thanks a lot! Your 'trick' didn't work out for me though (maybe I didn't do it correctly?) but I did find something with did https://gist.github.com/ColonelJ/6347203. However my working solution does have the unwanted side effect of making the length an explicit argument. Anyway it looks pretty simple after all and I don't see any of those repeated binder problems or any such thing. [Mon Aug 26 18:22:52 2013] ColonelJ: You program like a Schemer [Mon Aug 26 18:22:52 2013] ColonelJ: You program like a Schemer [Mon Aug 26 18:23:13 2013] :( [Mon Aug 26 18:23:13 2013] :( [Mon Aug 26 18:23:28 2013] Not meant to be a bad thing! [Mon Aug 26 18:23:28 2013] Not meant to be a bad thing! [Mon Aug 26 18:23:47 2013] I just meant that you seem to prefer projections to pattern matching. [Mon Aug 26 18:23:47 2013] I just meant that you seem to prefer projections to pattern matching. [Mon Aug 26 18:24:03 2013] I did that because I couldn't get pattern matching to work [Mon Aug 26 18:24:03 2013] I did that because I couldn't get pattern matching to work [Mon Aug 26 18:24:33 2013] weird. [Mon Aug 26 18:24:33 2013] weird. [Mon Aug 26 18:24:49 2013] I can maybe get it to work now but I think the code would end up being longer for that function at least [Mon Aug 26 18:24:49 2013] I can maybe get it to work now but I think the code would end up being longer for that function at least [Mon Aug 26 18:25:17 2013] 'fun' doesn't seem to accept patterns [Mon Aug 26 18:25:17 2013] 'fun' doesn't seem to accept patterns [Mon Aug 26 18:25:27 2013] well I must head home. [Mon Aug 26 18:25:28 2013] well I must head home. [Mon Aug 26 18:25:33 2013] if it did that would be the obvious way to do it [Mon Aug 26 18:25:34 2013] if it did that would be the obvious way to do it [Mon Aug 26 18:29:56 2013] heh, I managed to make n explicit by putting {} round it [Mon Aug 26 18:29:56 2013] heh, I managed to make n explicit by putting {} round it [Mon Aug 26 18:30:09 2013] s/explicit/implicit/ [Mon Aug 26 18:30:09 2013] s/explicit/implicit/ [Mon Aug 26 18:30:53 2013] what does 'maximally inserted' mean here though [Mon Aug 26 18:30:53 2013] what does 'maximally inserted' mean here though [Mon Aug 26 18:31:51 2013] ColonelJ: I didn't have any problem to make the match on the first bvec [Mon Aug 26 18:31:51 2013] ColonelJ: I didn't have any problem to make the match on the first bvec [Mon Aug 26 18:32:29 2013] I got a weird error where it invented an n0 and n1 that it couldn't unify [Mon Aug 26 18:32:29 2013] I got a weird error where it invented an n0 and n1 that it couldn't unify [Mon Aug 26 18:32:41 2013] I might have made a mistake though, I can have another go [Mon Aug 26 18:32:41 2013] I might have made a mistake though, I can have another go [Mon Aug 26 18:35:32 2013] yea I got it to work this time [Mon Aug 26 18:35:32 2013] yea I got it to work this time [Mon Aug 26 18:35:39 2013] if you use a match to destruct the second bvec that will happen [Mon Aug 26 18:35:39 2013] if you use a match to destruct the second bvec that will happen [Mon Aug 26 18:35:51 2013] Yea that's what happened last time I used let [Mon Aug 26 18:35:51 2013] Yea that's what happened last time I used let [Mon Aug 26 18:36:17 2013] but why does it accept this function which has let in its definition and not let directly? [Mon Aug 26 18:36:17 2013] but why does it accept this function which has let in its definition and not let directly? [Mon Aug 26 18:37:11 2013] Though "Print bvec_l." looks pretty funky so there's probably a lot of stuff going on behind the scenes there... [Mon Aug 26 18:37:11 2013] Though "Print bvec_l." looks pretty funky so there's probably a lot of stuff going on behind the scenes there... [Mon Aug 26 18:39:10 2013] I don't fully understand the specifics myself [Mon Aug 26 18:39:10 2013] I don't fully understand the specifics myself [Mon Aug 26 18:40:23 2013] Gist is updated with my new definition [Mon Aug 26 18:40:23 2013] Gist is updated with my new definition [Mon Aug 26 18:40:46 2013] yes, that is what mine looked like as well [Mon Aug 26 18:40:46 2013] yes, that is what mine looked like as well [Mon Aug 26 18:40:54 2013] indeed [Mon Aug 26 18:40:54 2013] indeed [Mon Aug 26 18:41:30 2013] ok finally I can continue transcribing my proof that I did with good old pen 'n' paper [Mon Aug 26 18:41:30 2013] ok finally I can continue transcribing my proof that I did with good old pen 'n' paper [Mon Aug 26 18:42:06 2013] where arguments like 'it's obvious' are perfectly valid [Mon Aug 26 18:42:06 2013] where arguments like 'it's obvious' are perfectly valid [Mon Aug 26 18:42:21 2013] 'crush' [Mon Aug 26 18:42:21 2013] 'crush' [Mon Aug 26 18:43:14 2013] for some reason the author said not to use crush in your own work and to write something more applicable to your own problems [Mon Aug 26 18:43:14 2013] for some reason the author said not to use crush in your own work and to write something more applicable to your own problems [Mon Aug 26 18:43:41 2013] Well, it's true [Mon Aug 26 18:43:41 2013] Well, it's true [Mon Aug 26 18:43:57 2013] But CPDT's version is a good starting point, often [Mon Aug 26 18:43:57 2013] But CPDT's version is a good starting point, often [Mon Aug 26 18:44:49 2013] the thing is, if you've already done a proof by hand, why would you bother trying to get a computer to do parts of it automatically that you've already figured out all the steps for [Mon Aug 26 18:44:49 2013] the thing is, if you've already done a proof by hand, why would you bother trying to get a computer to do parts of it automatically that you've already figured out all the steps for [Mon Aug 26 18:45:12 2013] but if you wrote "it's trivial", you really didn't, did you? [Mon Aug 26 18:45:12 2013] but if you wrote "it's trivial", you really didn't, did you? [Mon Aug 26 18:46:12 2013] I never actually wrote it at all, but it was implicit in the definition of zip that it was obvious that the only two valid cases were Leaf & Leaf or Node & Node, and you could see this directly from the fact that n was equal for both and the way bvec was constructed [Mon Aug 26 18:46:12 2013] I never actually wrote it at all, but it was implicit in the definition of zip that it was obvious that the only two valid cases were Leaf & Leaf or Node & Node, and you could see this directly from the fact that n was equal for both and the way bvec was constructed [Mon Aug 26 19:20:37 2013] I guess it's nice though to see things which you overlooked or didn't think worth proving [Mon Aug 26 19:20:37 2013] I guess it's nice though to see things which you overlooked or didn't think worth proving [Mon Aug 26 19:21:04 2013] or just plain omitted out of laziness [Mon Aug 26 19:21:04 2013] or just plain omitted out of laziness [Mon Aug 26 19:22:35 2013] ColonelJ: Because maybe next time you'll need to do a similar proof, but maybe not realize it, and maybe you can save yourself a lot of effort by throwing the tactic at it. Or maybe you'll decide to refactor your code, and then you'll happily discover that your general tactic works just fine (while your hand-proof wouldn't). Or maybe you want to only look at the main ideaas of a proof, and have a brute-force tactic that hides away the [Mon Aug 26 19:22:35 2013] unimportant details. [Mon Aug 26 19:22:36 2013] ColonelJ: Because maybe next time you'll need to do a similar proof, but maybe not realize it, and maybe you can save yourself a lot of effort by throwing the tactic at it. Or maybe you'll decide to refactor your code, and then you'll happily discover that your general tactic works just fine (while your hand-proof wouldn't). Or maybe you want to only look at the main ideaas of a proof, and have a brute-force tactic that hides away the [Mon Aug 26 19:22:36 2013] unimportant details. [Mon Aug 26 19:25:17 2013] very good points, but therein lies the extra challenge of writing the tactics themselves [Mon Aug 26 19:25:17 2013] very good points, but therein lies the extra challenge of writing the tactics themselves [Mon Aug 26 19:25:54 2013] I expect you'd have it be applicable to other problems by design rather than by accident however... [Mon Aug 26 19:25:55 2013] I expect you'd have it be applicable to other problems by design rather than by accident however... [Mon Aug 26 19:26:25 2013] you seems to be falling into the whole re-use ideology [Mon Aug 26 19:26:25 2013] you seems to be falling into the whole re-use ideology [Mon Aug 26 19:27:29 2013] except on that last point of course, that seems like a pretty good reason to use powerful tactics [Mon Aug 26 19:27:29 2013] except on that last point of course, that seems like a pretty good reason to use powerful tactics [Mon Aug 26 19:27:48 2013] That's I think what CPDT is trying to prove [Mon Aug 26 19:27:48 2013] That's I think what CPDT is trying to prove [Mon Aug 26 19:28:49 2013] though it doesn't seem clear to me how you could follow a proof by hand when it is done using such tactics, you'd have to be stepping it through in CoqIde or something surely? [Mon Aug 26 19:28:49 2013] though it doesn't seem clear to me how you could follow a proof by hand when it is done using such tactics, you'd have to be stepping it through in CoqIde or something surely? [Mon Aug 26 19:33:01 2013] If you have a proof that there exists an identity element for a function on some domain is it possible to extract any one of these values from the domain? [Mon Aug 26 19:33:01 2013] If you have a proof that there exists an identity element for a function on some domain is it possible to extract any one of these values from the domain? [Mon Aug 26 19:38:05 2013] The idea behind CPDT is that machine checked proofs are not to be followed by hand. Rather than proving a theorem by a long chain of reasoning, instead factor it into many small lemmas, so that all of the instresting insights of a proof are instead made explicit in lemma statements or definitions. (e.g., if it's tricky to show that two sets are isomorphic, maybe first you define the tricky isomorphism, and then you state your theorem as "that [Mon Aug 26 19:38:05 2013] function is an iso", rather than bundle them up in the proof). What I look for in an automated proof are, roughly, just "what lemmas does it use?". I think that most tactic reasoning beyond "apply/rewrite this lemma, possibly with creative inference of arguments so you don't spend too much time finding dead ends" is a failure in coming up with sublemmas. Exceptions might be things like omega, i.e., total (or, I suppose, partial) solvers for [Mon Aug 26 19:38:05 2013] goals of a certain shape, according to a specified algorithm. Ideally, IMO, your proof script should be a big [repeat match goal with ... end], where the ordering should only matter for speed. [Mon Aug 26 19:38:06 2013] The idea behind CPDT is that machine checked proofs are not to be followed by hand. Rather than proving a theorem by a long chain of reasoning, instead factor it into many small lemmas, so that all of the instresting insights of a proof are instead made explicit in lemma statements or definitions. (e.g., if it's tricky to show that two sets are isomorphic, maybe first you define the tricky isomorphism, and then you state your theorem as "that [Mon Aug 26 19:38:06 2013] function is an iso", rather than bundle them up in the proof). What I look for in an automated proof are, roughly, just "what lemmas does it use?". I think that most tactic reasoning beyond "apply/rewrite this lemma, possibly with creative inference of arguments so you don't spend too much time finding dead ends" is a failure in coming up with sublemmas. Exceptions might be things like omega, i.e., total (or, I suppose, partial) solvers for [Mon Aug 26 19:38:06 2013] goals of a certain shape, according to a specified algorithm. Ideally, IMO, your proof script should be a big [repeat match goal with ... end], where the ordering should only matter for speed. [Mon Aug 26 19:42:26 2013] I guess that makes sense then, but I think the lemmas you'd define would be the same in either case, but in one case you explicitly write the order they are used and in the other case you just say "use these and a proof will come out somehow or other" [Mon Aug 26 19:42:26 2013] I guess that makes sense then, but I think the lemmas you'd define would be the same in either case, but in one case you explicitly write the order they are used and in the other case you just say "use these and a proof will come out somehow or other" [Mon Aug 26 19:43:15 2013] the benefit of machine checking of course being that no one has to check anything in either case [Mon Aug 26 19:43:15 2013] the benefit of machine checking of course being that no one has to check anything in either case [Mon Aug 26 19:44:36 2013] the problem I see here is that you can't really know which lemmas you need until you actually try to do the proof by hand. You come across something that looks like it should be obvious, then write a lemma for it so you can do it in one step of the proof. [Mon Aug 26 19:44:36 2013] the problem I see here is that you can't really know which lemmas you need until you actually try to do the proof by hand. You come across something that looks like it should be obvious, then write a lemma for it so you can do it in one step of the proof. [Mon Aug 26 19:45:06 2013] My experience is that you come up with lemmas as you go proving [Mon Aug 26 19:45:06 2013] My experience is that you come up with lemmas as you go proving [Mon Aug 26 19:45:14 2013] Right. And I'm arguing that most people aren't terribly interested in the order, and maybe the order will change if you refactor the code, so automate away the order, because computers are good at brute force. [Mon Aug 26 19:45:14 2013] Right. And I'm arguing that most people aren't terribly interested in the order, and maybe the order will change if you refactor the code, so automate away the order, because computers are good at brute force. [Mon Aug 26 19:45:15 2013] But isn't that true for pencil and paper too? [Mon Aug 26 19:45:15 2013] But isn't that true for pencil and paper too? [Mon Aug 26 19:45:28 2013] Exactly. As part of this process you already know the order in which the lemmas are applied, so again why not just provide this information as part of your proof [Mon Aug 26 19:45:28 2013] Exactly. As part of this process you already know the order in which the lemmas are applied, so again why not just provide this information as part of your proof [Mon Aug 26 19:46:05 2013] I suppose if the order changing is something that is likely to happen it makes sense then [Mon Aug 26 19:46:05 2013] I suppose if the order changing is something that is likely to happen it makes sense then [Mon Aug 26 19:47:03 2013] As for which lemmas you need, I'd say you can start with a big [repeat match goal with ... end] with all the lemmas you guess you'll need (maybe from previous similar proofs), and see where that gets you. If it doesn't solve it, then you come up with another lemma, and add that to the brute force tactic. [Mon Aug 26 19:47:03 2013] As for which lemmas you need, I'd say you can start with a big [repeat match goal with ... end] with all the lemmas you guess you'll need (maybe from previous similar proofs), and see where that gets you. If it doesn't solve it, then you come up with another lemma, and add that to the brute force tactic. [Mon Aug 26 19:48:36 2013] I think I agree with you now, you're better off having something where the machine can do the proof by itself. [Mon Aug 26 19:48:36 2013] I think I agree with you now, you're better off having something where the machine can do the proof by itself. [Mon Aug 26 19:51:12 2013] Would I be right in saying you want you lemmas to be as generic as possible to enable the machine to do more proofs? [Mon Aug 26 19:51:12 2013] Would I be right in saying you want you lemmas to be as generic as possible to enable the machine to do more proofs? [Mon Aug 26 20:44:44 2013] Axiom mult_id_exists : { mult_id : dom | forall x, mult x mult_id = x }. [Mon Aug 26 20:44:44 2013] Axiom mult_id_exists : { mult_id : dom | forall x, mult x mult_id = x }. [Mon Aug 26 20:44:58 2013] Then I can use proj1_sig to get the actual element? [Mon Aug 26 20:44:58 2013] Then I can use proj1_sig to get the actual element? [Mon Aug 26 20:46:20 2013] No. [Mon Aug 26 20:46:20 2013] No. [Mon Aug 26 20:46:30 2013] Axioms are not computational [Mon Aug 26 20:46:30 2013] Axioms are not computational [Mon Aug 26 20:47:14 2013] If they were, I could claim there is a proof of property X, and just project a proof out of nothing. [Mon Aug 26 20:47:14 2013] If they were, I could claim there is a proof of property X, and just project a proof out of nothing. [Mon Aug 26 20:47:49 2013] I'm doing this in a section [Mon Aug 26 20:47:49 2013] I'm doing this in a section [Mon Aug 26 20:47:53 2013] so I can give the proof later [Mon Aug 26 20:47:53 2013] so I can give the proof later [Mon Aug 26 20:48:04 2013] Unless you mean something else? [Mon Aug 26 20:48:04 2013] Unless you mean something else? [Mon Aug 26 20:48:40 2013] The domain here is a parameter so I can't know what the identity is, I want to pass it in with a proof that it's valid [Mon Aug 26 20:48:40 2013] The domain here is a parameter so I can't know what the identity is, I want to pass it in with a proof that it's valid [Mon Aug 26 20:48:57 2013] which seems to be what this dependent product thing allows you to do [Mon Aug 26 20:48:57 2013] which seems to be what this dependent product thing allows you to do [Mon Aug 26 20:49:26 2013] Then sure, there shouldn't be a problem with that, unless Coq has some weird safeguards in it [Mon Aug 26 20:49:27 2013] Then sure, there shouldn't be a problem with that, unless Coq has some weird safeguards in it [Mon Aug 26 20:49:30 2013] I'm hoping that you can use the proof to do computations on it without knowing what it is [Mon Aug 26 20:49:30 2013] I'm hoping that you can use the proof to do computations on it without knowing what it is [Mon Aug 26 20:49:44 2013] You can't within the section. [Mon Aug 26 20:49:44 2013] You can't within the section. [Mon Aug 26 20:50:00 2013] the functions are parameterized as well [Mon Aug 26 20:50:00 2013] the functions are parameterized as well [Mon Aug 26 20:50:15 2013] bleh I didn't mean computations I meant proofs [Mon Aug 26 20:50:15 2013] bleh I didn't mean computations I meant proofs [Mon Aug 26 20:50:30 2013] in this case I want to prove that two computations will give the same result [Mon Aug 26 20:50:30 2013] in this case I want to prove that two computations will give the same result [Mon Aug 26 20:52:42 2013] yea I've sort of half convinced myself that this will work somehow but I really need to go to bed so the rest of the exercise can be left till another day [Mon Aug 26 20:52:42 2013] yea I've sort of half convinced myself that this will work somehow but I really need to go to bed so the rest of the exercise can be left till another day [Mon Aug 26 20:53:03 2013] thanks all! [Mon Aug 26 20:53:03 2013] thanks all! [Mon Aug 26 21:18:46 2013] minimal failure example: https://gist.github.com/anonymous/adf7d4c7edfd0f999741 <-- how do I figure out how to get notation " [1, 2] " -- "1 :: 2 :: nil" works, but "[1, 2]" does not work [Mon Aug 26 21:18:46 2013] minimal failure example: https://gist.github.com/anonymous/adf7d4c7edfd0f999741 <-- how do I figure out how to get notation " [1, 2] " -- "1 :: 2 :: nil" works, but "[1, 2]" does not work [Mon Aug 26 21:28:59 2013] clj_newb_2345: github isn't responding :/ [Mon Aug 26 21:30:59 2013] Require Import ZArith. Require Import List. Local Open Scope list_scope. Locate " [ ] ". Eval compute in 1::2::nil. Eval compute in [1; 2]. [Mon Aug 26 21:33:40 2013] https://gist.github.com/anonymous/6348730 [Mon Aug 26 21:33:49 2013] I think part of the problem is that my original gist was a secret gist [Tue Aug 27 03:26:51 2013] fisi: thanks for the answer (for the question at 0:30)! I actually did the same thing in Agda and found out, that I had managed to prove that in Agda since it normalized the "eval v (impl a b) = true" expression, thus making it easy to prove, however, Coq hadn't, so after I had used "simpl.", I proved it. [Tue Aug 27 03:26:51 2013] fisi: thanks for the answer (for the question at 0:30)! I actually did the same thing in Agda and found out, that I had managed to prove that in Agda since it normalized the "eval v (impl a b) = true" expression, thus making it easy to prove, however, Coq hadn't, so after I had used "simpl.", I proved it. [Tue Aug 27 03:30:00 2013] What is annoying is such a thing: suppose I have a goal (2 + 2 = 4) -> Whatever. If I type "simpl., I get a goal "4 = 4 -> Whatever", as expected. However, suppose I typed "intro." first, thus getting the context {2 + 2 = 4} and the goad Whatever. [Tue Aug 27 03:30:00 2013] What is annoying is such a thing: suppose I have a goal (2 + 2 = 4) -> Whatever. If I type "simpl., I get a goal "4 = 4 -> Whatever", as expected. However, suppose I typed "intro." first, thus getting the context {2 + 2 = 4} and the goad Whatever. [Tue Aug 27 03:30:22 2013] How do I normalize the expression "2 + 2 = 4", when it is in the context? [Tue Aug 27 03:30:22 2013] How do I normalize the expression "2 + 2 = 4", when it is in the context? [Tue Aug 27 03:30:46 2013] if you have hyp : 2 + 2 = 4, you can do "simpl in hyp" [Tue Aug 27 03:30:46 2013] if you have hyp : 2 + 2 = 4, you can do "simpl in hyp" [Tue Aug 27 03:31:01 2013] and simpl in * simplifies everywhere in the goal & context [Tue Aug 27 03:31:01 2013] and simpl in * simplifies everywhere in the goal & context [Tue Aug 27 03:32:28 2013] ah, I suppose I skipped it somehow while reading the tactics reference. Thanks! [Tue Aug 27 03:32:28 2013] ah, I suppose I skipped it somehow while reading the tactics reference. Thanks! [Tue Aug 27 03:33:15 2013] no problem [Tue Aug 27 03:33:15 2013] no problem [Tue Aug 27 03:50:53 2013] And one more: suppose I have "ab : A -> B" and "a : A" in the context and the goal is Whatever. I want to add "b : B" to the context, I can deduce it by the application (ab a). The way I am doing it now is "cut B." and then proving the subgoal B by "apply ab." . Is there a way to modify the context directly, without splitting the goal? [Tue Aug 27 03:50:53 2013] And one more: suppose I have "ab : A -> B" and "a : A" in the context and the goal is Whatever. I want to add "b : B" to the context, I can deduce it by the application (ab a). The way I am doing it now is "cut B." and then proving the subgoal B by "apply ab." . Is there a way to modify the context directly, without splitting the goal? [Tue Aug 27 03:53:29 2013] apply ab in a. ? [Tue Aug 27 03:53:29 2013] apply ab in a. ? [Tue Aug 27 03:54:00 2013] or `specialize (ab a)', both should work [Tue Aug 27 03:54:00 2013] or `specialize (ab a)', both should work [Tue Aug 27 03:54:58 2013] oh, thanks. I was doing "apply a in ab." :) [Tue Aug 27 03:54:58 2013] oh, thanks. I was doing "apply a in ab." :) [Tue Aug 27 11:52:04 2013] I can't compile CoqIde. LablGtk2 is installed, ./configure script tries to perform test: [Tue Aug 27 11:52:04 2013] I can't compile CoqIde. LablGtk2 is installed, ./configure script tries to perform test: [Tue Aug 27 11:52:11 2013] '[' '' = '' -a -f /usr/lib64/ocaml/lablgtk2/glib.mli -a -f /usr/lib64/ocaml/glib.mli ']' [Tue Aug 27 11:52:11 2013] '[' '' = '' -a -f /usr/lib64/ocaml/lablgtk2/glib.mli -a -f /usr/lib64/ocaml/glib.mli ']' [Tue Aug 27 11:52:37 2013] Test failed because I have /usr/lib64/ocaml/lablgtk2/glib.mli but do not have /usr/lib64/ocaml/glib.mli [Tue Aug 27 11:52:37 2013] Test failed because I have /usr/lib64/ocaml/lablgtk2/glib.mli but do not have /usr/lib64/ocaml/glib.mli [Tue Aug 27 11:55:29 2013] Relevant code from ./configure: 629: if [ -f "$lablgtkdirtmp/glib.cmi" -a -f "$lablgtkdirtmp/glib.mli" ]; then [Tue Aug 27 11:55:29 2013] Relevant code from ./configure: 629: if [ -f "$lablgtkdirtmp/glib.cmi" -a -f "$lablgtkdirtmp/glib.mli" ]; then [Tue Aug 27 11:55:31 2013] 630- lablgtkdirfoundmsg="LabelGtk2 found by ocamlfind" [Tue Aug 27 11:55:31 2013] 630- lablgtkdirfoundmsg="LabelGtk2 found by ocamlfind" [Tue Aug 27 11:56:18 2013] Oh, not this [Tue Aug 27 11:56:18 2013] Oh, not this [Tue Aug 27 11:57:47 2013] Anyway, I think the problem is in configure script, -a instead of -o [Tue Aug 27 11:57:47 2013] Anyway, I think the problem is in configure script, -a instead of -o [Tue Aug 27 12:00:29 2013] I have pointed configure script, now it accepts it [Tue Aug 27 12:00:29 2013] I have pointed configure script, now it accepts it [Tue Aug 27 15:21:03 2013] Does anyone know what are holes in Agda? Is there some similar concept in Coq? [Tue Aug 27 15:21:03 2013] Does anyone know what are holes in Agda? Is there some similar concept in Coq? [Tue Aug 27 15:23:15 2013] holes are parts of program/proof that you still have to provide -- basically the equivalent of the goals of your proof (or program, if you're programming with tactics). [Tue Aug 27 15:23:15 2013] holes are parts of program/proof that you still have to provide -- basically the equivalent of the goals of your proof (or program, if you're programming with tactics). [Tue Aug 27 15:24:28 2013] so, it kind of depends on how you look at it: there's a lot of support, but not quite of the same variety. ;) [Tue Aug 27 15:24:28 2013] so, it kind of depends on how you look at it: there's a lot of support, but not quite of the same variety. ;) [Tue Aug 27 15:26:36 2013] Yeah, I know what they are, I used them in Agda. In Agda, I could put a question mark as a placeholder, then typecheck and then ask a hole, what type it wants to be filled with. Is there some similar tactic/proof technique? [Tue Aug 27 15:26:36 2013] Yeah, I know what they are, I used them in Agda. In Agda, I could put a question mark as a placeholder, then typecheck and then ask a hole, what type it wants to be filled with. Is there some similar tactic/proof technique? [Tue Aug 27 15:28:16 2013] that *kind of* corresponds to proving stuff/programming using only the "refine" tactic -- which you can do, but is not very convenient. Also, the Program package lets you write programs with holes (underscores), and leaves what it cannot infer as obligations. [Tue Aug 27 15:28:16 2013] that *kind of* corresponds to proving stuff/programming using only the "refine" tactic -- which you can do, but is not very convenient. Also, the Program package lets you write programs with holes (underscores), and leaves what it cannot infer as obligations. [Tue Aug 27 15:29:28 2013] Guess it's settled, then: https://twitter.com/raichoo/status/372439552775835648 [Tue Aug 27 15:29:28 2013] Guess it's settled, then: https://twitter.com/raichoo/status/372439552775835648 [Tue Aug 27 15:29:38 2013] :P [Tue Aug 27 15:29:38 2013] :P [Tue Aug 27 15:31:33 2013] Also I liked I could skip some part of proof in Agda by making a hole and returning to it later, however, I couldn't find a way to skip through a goal and return to it later. Is there some way? [Tue Aug 27 15:31:33 2013] Also I liked I could skip some part of proof in Agda by making a hole and returning to it later, however, I couldn't find a way to skip through a goal and return to it later. Is there some way? [Tue Aug 27 15:35:05 2013] `admit'? [Tue Aug 27 15:35:05 2013] `admit'? [Tue Aug 27 15:36:25 2013] fisi: yeah, that's it! thanks! [Tue Aug 27 15:36:25 2013] fisi: yeah, that's it! thanks! [Tue Aug 27 19:19:34 2013] What's better to learn, ATS, Coq, Adga or any other similar language? [Tue Aug 27 19:19:34 2013] What's better to learn, ATS, Coq, Adga or any other similar language? [Tue Aug 27 19:23:13 2013] Coq is the most mature for serious theorem proving [Tue Aug 27 19:23:13 2013] Coq is the most mature for serious theorem proving [Tue Aug 27 19:23:34 2013] ATS is so weak and difficult to use that even its authors have trouble using it. [Tue Aug 27 19:23:35 2013] ATS is so weak and difficult to use that even its authors have trouble using it. [Tue Aug 27 19:23:48 2013] Agda is cute for demos, but nothing really serious. [Tue Aug 27 19:23:48 2013] Agda is cute for demos, but nothing really serious. [Tue Aug 27 19:25:23 2013] * senses some bias :p [Tue Aug 27 19:25:23 2013] * senses some bias :p [Tue Aug 27 19:25:46 2013] There's also Idris [Tue Aug 27 19:25:46 2013] There's also Idris [Tue Aug 27 19:26:04 2013] What other language support complete lambda cube? [Tue Aug 27 19:26:04 2013] What other language support complete lambda cube? [Tue Aug 27 19:26:14 2013] * es [Tue Aug 27 19:26:14 2013] * es [Tue Aug 27 19:26:27 2013] Epigram perhaps, but I've never actually seen it. [Tue Aug 27 19:26:27 2013] Epigram perhaps, but I've never actually seen it. [Wed Aug 28 09:19:01 2013] Hi guys. I am stuck at proving by case analysis, here is the code http://lpaste.net/92239 [Wed Aug 28 09:19:01 2013] Hi guys. I am stuck at proving by case analysis, here is the code http://lpaste.net/92239 [Wed Aug 28 09:19:33 2013] what should I use instead of destruct? And how should I interpret this error? [Wed Aug 28 09:19:33 2013] what should I use instead of destruct? And how should I interpret this error? [Wed Aug 28 09:24:08 2013] (the same thing in Agda works just fine: http://lpaste.net/92240 ) [Wed Aug 28 09:24:08 2013] (the same thing in Agda works just fine: http://lpaste.net/92240 ) [Wed Aug 28 09:39:11 2013] the gist of it is that Coq's treatment of equality is different than Agda's, and in general the one in Coq does not admit Agda's pattern-matching rule (it assumes an additional axiom, equivalent to Streicher's K or Uniqueness of Identity Proofs). [Wed Aug 28 09:39:11 2013] the gist of it is that Coq's treatment of equality is different than Agda's, and in general the one in Coq does not admit Agda's pattern-matching rule (it assumes an additional axiom, equivalent to Streicher's K or Uniqueness of Identity Proofs). [Wed Aug 28 09:40:55 2013] I think the chapters on dependent types (More Dependent Types, Dependent Data Structures, Reasoning about Equality Proofs) of CPDT should be helpful in understanding how Coq treats this stuff [Wed Aug 28 09:40:55 2013] I think the chapters on dependent types (More Dependent Types, Dependent Data Structures, Reasoning about Equality Proofs) of CPDT should be helpful in understanding how Coq treats this stuff [Wed Aug 28 09:41:12 2013] (the book is available here: http://adam.chlipala.net/cpdt/) [Wed Aug 28 09:41:12 2013] (the book is available here: http://adam.chlipala.net/cpdt/) [Wed Aug 28 10:05:10 2013] karlicoss: in Coq you need to use more advanced things [Wed Aug 28 10:05:10 2013] karlicoss: in Coq you need to use more advanced things [Wed Aug 28 10:05:19 2013] huh I still haven't written my blog post about this [Wed Aug 28 10:05:19 2013] huh I still haven't written my blog post about this [Wed Aug 28 10:18:36 2013] Ptival: what are you waiting for :) [Wed Aug 28 10:18:36 2013] Ptival: what are you waiting for :) [Wed Aug 28 10:37:16 2013] thanks! [Wed Aug 28 10:37:16 2013] thanks! [Wed Aug 28 10:44:13 2013] rks`: heh! :) [Wed Aug 28 10:44:13 2013] rks`: heh! :) [Wed Aug 28 11:02:31 2013] karlicoss: here is one way to do it http://paste.awesom.eu/Ptival/dG8 [Wed Aug 28 11:02:31 2013] karlicoss: here is one way to do it http://paste.awesom.eu/Ptival/dG8 [Wed Aug 28 11:13:12 2013] Prival: thanks! I've managed to use dependent destruction actually [Wed Aug 28 11:13:12 2013] Prival: thanks! I've managed to use dependent destruction actually [Wed Aug 28 11:14:00 2013] karlicoss: wow, I don't think that's ever worked for me! (not that I've tried in the last couple years or so) [Wed Aug 28 11:14:00 2013] karlicoss: wow, I don't think that's ever worked for me! (not that I've tried in the last couple years or so) [Wed Aug 28 11:18:16 2013] fisi: it's said it is experimental for some reason [Wed Aug 28 11:18:16 2013] fisi: it's said it is experimental for some reason [Wed Aug 28 11:18:43 2013] yeah, I know. Still, good it's worked for you [Wed Aug 28 11:18:43 2013] yeah, I know. Still, good it's worked for you [Wed Aug 28 11:20:07 2013] don't you know why it's experimental? It could be unsound or what? [Wed Aug 28 11:20:07 2013] don't you know why it's experimental? It could be unsound or what? [Wed Aug 28 11:20:26 2013] karlicoss: can you post me your code then? [Wed Aug 28 11:20:26 2013] karlicoss: can you post me your code then? [Wed Aug 28 11:20:32 2013] I never used dependent destruction [Wed Aug 28 11:20:32 2013] I never used dependent destruction [Wed Aug 28 11:22:13 2013] I don't know why; probably not any kind of unsoundness, though. [Wed Aug 28 11:22:13 2013] I don't know why; probably not any kind of unsoundness, though. [Wed Aug 28 11:23:15 2013] Prival: sure http://lpaste.net/92246 [Wed Aug 28 11:23:15 2013] Prival: sure http://lpaste.net/92246 [Wed Aug 28 11:23:45 2013] karlicoss: oh ok... [Wed Aug 28 11:23:45 2013] karlicoss: oh ok... [Wed Aug 28 11:23:50 2013] they must have fixed it in 8.4 [Wed Aug 28 11:23:50 2013] they must have fixed it in 8.4 [Wed Aug 28 11:23:54 2013] this does not work here :) [Wed Aug 28 11:23:54 2013] this does not work here :) [Wed Aug 28 11:24:04 2013] and what was wrong with it? [Wed Aug 28 11:24:04 2013] and what was wrong with it? [Wed Aug 28 11:24:22 2013] I've got 8.3 [Wed Aug 28 11:24:22 2013] I've got 8.3 [Wed Aug 28 11:24:23 2013] actually dependent destruction isn't syntactically valid [Wed Aug 28 11:24:23 2013] actually dependent destruction isn't syntactically valid [Wed Aug 28 11:24:35 2013] do I have to import something? [Wed Aug 28 11:24:35 2013] do I have to import something? [Wed Aug 28 11:24:45 2013] oh right [Wed Aug 28 11:24:45 2013] oh right [Wed Aug 28 11:24:55 2013] Require Import Coq.Program.Equality. line 14 [Wed Aug 28 11:24:55 2013] Require Import Coq.Program.Equality. line 14 [Wed Aug 28 11:25:00 2013] yes :) [Wed Aug 28 11:25:00 2013] yes :) [Wed Aug 28 11:25:04 2013] ok it works, nice [Wed Aug 28 11:25:04 2013] ok it works, nice [Wed Aug 28 11:25:23 2013] oooh, does that mean it requires K? [Wed Aug 28 11:25:23 2013] oooh, does that mean it requires K? [Wed Aug 28 11:27:23 2013] maybe. As far as I remember, K is something from homotopy type theory, so I don't know what is it :( [Wed Aug 28 11:27:23 2013] maybe. As far as I remember, K is something from homotopy type theory, so I don't know what is it :( [Wed Aug 28 11:27:58 2013] Print Assumptions OnlyOne. [Wed Aug 28 11:27:58 2013] Print Assumptions OnlyOne. [Wed Aug 28 11:27:59 2013] Axioms: JMeq_eq : forall (A : Type) (x y : A), x ~= y -> x = y [Wed Aug 28 11:27:59 2013] Axioms: JMeq_eq : forall (A : Type) (x y : A), x ~= y -> x = y [Wed Aug 28 11:28:25 2013] yup, that would be that then [Wed Aug 28 11:28:25 2013] yup, that would be that then [Wed Aug 28 11:31:54 2013] (as far as I recall these things, at least) [Wed Aug 28 11:31:54 2013] (as far as I recall these things, at least) [Wed Aug 28 13:37:50 2013] karlicoss: dependent destruction is kind of a strange tactic. I may silently dependent on the JMeq_eq axiom (which is logically equivalent to K and uniqueness of identity proofs). These axioms are independent of the current type theory of Coq, but unsound in homotopy type theory. [Wed Aug 28 13:37:50 2013] karlicoss: dependent destruction is kind of a strange tactic. I may silently dependent on the JMeq_eq axiom (which is logically equivalent to K and uniqueness of identity proofs). These axioms are independent of the current type theory of Coq, but unsound in homotopy type theory. [Wed Aug 28 13:38:02 2013] *it may [Wed Aug 28 13:38:02 2013] *it may [Wed Aug 28 13:40:03 2013] many kinds of dependent pattern matching can be done without such axioms (by using approriate return clauses, or using eq_dep in case the indexes of the dependent type have decidable equality) [Wed Aug 28 13:40:03 2013] many kinds of dependent pattern matching can be done without such axioms (by using approriate return clauses, or using eq_dep in case the indexes of the dependent type have decidable equality) [Wed Aug 28 13:41:45 2013] robbert: thanks! [Wed Aug 28 13:41:45 2013] robbert: thanks! [Wed Aug 28 13:46:46 2013] karlicoss: your Agda code btw has another lemma, which is also trivially provable in Coq :) [Wed Aug 28 13:46:46 2013] karlicoss: your Agda code btw has another lemma, which is also trivially provable in Coq :) [Wed Aug 28 13:48:03 2013] robbert: which lemma do you mean? [Wed Aug 28 13:48:03 2013] robbert: which lemma do you mean? [Wed Aug 28 13:48:09 2013] onlyone : (x : Fin (S Z)) → x ≡ x [Wed Aug 28 13:48:09 2013] onlyone : (x : Fin (S Z)) → x ≡ x [Wed Aug 28 13:48:20 2013] yeah, that one is just refl [Wed Aug 28 13:48:20 2013] yeah, that one is just refl [Wed Aug 28 13:48:38 2013] maybe you meant (x y : Fin (S Z) -> x ≡ y [Wed Aug 28 13:48:38 2013] maybe you meant (x y : Fin (S Z) -> x ≡ y [Wed Aug 28 13:49:02 2013] (with one more closing paren ) [Wed Aug 28 13:49:02 2013] (with one more closing paren ) [Wed Aug 28 13:49:03 2013] oh crap. I mistyped :) [Wed Aug 28 13:49:03 2013] oh crap. I mistyped :) [Wed Aug 28 13:49:24 2013] I meant (x : Fin (S Z)) → x ≡ fzero 0 [Wed Aug 28 13:49:24 2013] I meant (x : Fin (S Z)) → x ≡ fzero 0 [Wed Aug 28 13:52:39 2013] well, it's still provable in two lines, just the second case is absurd now as expected [Wed Aug 28 13:52:39 2013] well, it's still provable in two lines, just the second case is absurd now as expected [Wed Aug 28 13:55:11 2013] karlicoss: another solution in Coq: http://lpaste.net/92253 [Wed Aug 28 13:55:11 2013] karlicoss: another solution in Coq: http://lpaste.net/92253 [Wed Aug 28 13:55:30 2013] this one may be more generic, and is axiom free of course :) [Wed Aug 28 13:55:30 2013] this one may be more generic, and is axiom free of course :) [Wed Aug 28 14:40:14 2013] Suppose I have "H : forall x : X, exists y : Y, P y" in the context. I want to throw off the "P y" part, that is, just make a function "f : X -> Y" from the H. How should I do that? [Wed Aug 28 14:40:14 2013] Suppose I have "H : forall x : X, exists y : Y, P y" in the context. I want to throw off the "P y" part, that is, just make a function "f : X -> Y" from the H. How should I do that? [Wed Aug 28 14:40:22 2013] It would look somethig like specialize (fun (x : X) => ??? H x) I guess, but what should I use instead of ??? ? [Wed Aug 28 14:40:22 2013] It would look somethig like specialize (fun (x : X) => ??? H x) I guess, but what should I use instead of ??? ? [Wed Aug 28 14:44:44 2013] karlicoss: that [Wed Aug 28 14:44:44 2013] karlicoss: that [Wed Aug 28 14:44:51 2013] that's axiom of choice, it's independent of CiC [Wed Aug 28 14:44:51 2013] that's axiom of choice, it's independent of CiC [Wed Aug 28 14:45:17 2013] unless Y is countable and P is decidable [Wed Aug 28 14:45:17 2013] unless Y is countable and P is decidable [Wed Aug 28 14:45:32 2013] ah, indeed [Wed Aug 28 14:45:32 2013] ah, indeed [Wed Aug 28 14:46:07 2013] if you would have forall x : X, { y : Y | P y } instead, you can do what you wish to do though [Wed Aug 28 14:46:07 2013] if you would have forall x : X, { y : Y | P y } instead, you can do what you wish to do though [Wed Aug 28 14:46:21 2013] then you can just use proj1_sig [Wed Aug 28 14:46:21 2013] then you can just use proj1_sig [Wed Aug 28 15:01:46 2013] however.. if I want to prove some general topology, I guess I'm gonna need axiom of choice anyway :) [Wed Aug 28 15:01:46 2013] however.. if I want to prove some general topology, I guess I'm gonna need axiom of choice anyway :) [Wed Aug 28 15:06:11 2013] karlicoss: you mean classical topology. [Wed Aug 28 15:06:11 2013] karlicoss: you mean classical topology. [Wed Aug 28 15:07:55 2013] ianjneu: I've heard about constructive, but never studied further. Would you recommend something to read about it? [Wed Aug 28 15:07:55 2013] ianjneu: I've heard about constructive, but never studied further. Would you recommend something to read about it? [Wed Aug 28 15:20:32 2013] karlicoss: synthetic topology is the earlier work, but I'm not sure it's entirely constructive. The best I know right now is homotopy type theory. [Wed Aug 28 15:20:32 2013] karlicoss: synthetic topology is the earlier work, but I'm not sure it's entirely constructive. The best I know right now is homotopy type theory. [Wed Aug 28 17:21:19 2013] What are people's feelings on using the UTF8 encoded unicode symbols for forall etc. in source files [Wed Aug 28 17:21:19 2013] What are people's feelings on using the UTF8 encoded unicode symbols for forall etc. in source files [Wed Aug 28 17:24:03 2013] And in a similar vein, why is the handling of unicode characters so inconsistent and restrictive? [Wed Aug 28 17:24:03 2013] And in a similar vein, why is the handling of unicode characters so inconsistent and restrictive? [Wed Aug 28 17:25:39 2013] ColonelJ: camlp5 has suuuuuuuuper weak macros. There doesn't seem to be a way to make a rename-transformer (to use Racket macro terms) to make ∀ always mean forall [Wed Aug 28 17:25:39 2013] ColonelJ: camlp5 has suuuuuuuuper weak macros. There doesn't seem to be a way to make a rename-transformer (to use Racket macro terms) to make ∀ always mean forall [Wed Aug 28 17:26:03 2013] and similarly for exists. [Wed Aug 28 17:26:03 2013] and similarly for exists. [Wed Aug 28 17:26:36 2013] ocaml suffers with anything that came into existence later than about 1998 [Wed Aug 28 17:26:36 2013] ocaml suffers with anything that came into existence later than about 1998 [Wed Aug 28 17:26:41 2013] * dives for cover [Wed Aug 28 17:26:41 2013] * dives for cover [Wed Aug 28 17:26:48 2013] I guess the question is whether I should be bothering with it or not, or just stick with good old ASCII... [Wed Aug 28 17:26:48 2013] I guess the question is whether I should be bothering with it or not, or just stick with good old ASCII... [Wed Aug 28 17:31:56 2013] ColonelJ: don't bother. [Wed Aug 28 17:31:56 2013] ColonelJ: don't bother. [Wed Aug 28 17:32:42 2013] You can use xsymbol in emacs and have forall get rendered as the unicode, and similarly for identifiers such as \cup and \to [Wed Aug 28 17:32:42 2013] You can use xsymbol in emacs and have forall get rendered as the unicode, and similarly for identifiers such as \cup and \to [Wed Aug 28 17:33:10 2013] I'm using CoqIde unfortunately [Wed Aug 28 17:33:10 2013] I'm using CoqIde unfortunately [Wed Aug 28 17:33:33 2013] That is quite unfortunate. Wonks and crashes abound. [Wed Aug 28 17:33:33 2013] That is quite unfortunate. Wonks and crashes abound. [Wed Aug 28 17:33:50 2013] actually it seems pretty stable [Wed Aug 28 17:33:50 2013] actually it seems pretty stable [Wed Aug 28 17:33:59 2013] Even if coqtop crashes [Wed Aug 28 17:33:59 2013] Even if coqtop crashes [Wed Aug 28 17:34:11 2013] which is a lot more common [Wed Aug 28 17:34:11 2013] which is a lot more common [Wed Aug 28 17:35:29 2013] Anyway I'm gonna continue using the unicode until it bites me [Wed Aug 28 17:35:29 2013] Anyway I'm gonna continue using the unicode until it bites me [Wed Aug 28 17:36:17 2013] ColonelJ: ∀ x (y : A) [Wed Aug 28 17:36:17 2013] ColonelJ: ∀ x (y : A) [Wed Aug 28 17:36:35 2013] yup that showed up correctly in my ancient IRC client [Wed Aug 28 17:36:35 2013] yup that showed up correctly in my ancient IRC client [Wed Aug 28 17:37:41 2013] unicode-forall x (y : A) doesn't work because the unicode macros only handle x:id ... and x:id ... : A, not any mixture. [Wed Aug 28 17:37:41 2013] unicode-forall x (y : A) doesn't work because the unicode macros only handle x:id ... and x:id ... : A, not any mixture. [Wed Aug 28 17:38:15 2013] because who ever thought non-terminals when parsing would be a good idea? [Wed Aug 28 17:38:15 2013] because who ever thought non-terminals when parsing would be a good idea? [Wed Aug 28 17:44:17 2013] not sure I understand what you're getting at here, it worked fine for me [Wed Aug 28 17:44:18 2013] not sure I understand what you're getting at here, it worked fine for me [Wed Aug 28 17:46:23 2013] Axiom derp : ? A, ? x (y : A), x = y. [Wed Aug 28 17:46:23 2013] Axiom derp : ? A, ? x (y : A), x = y. [Wed Aug 28 17:46:46 2013] Axiom derp : ∀ A, ∀ x (y : A), x = y. [Wed Aug 28 17:46:46 2013] Axiom derp : ∀ A, ∀ x (y : A), x = y. [Wed Aug 28 17:46:58 2013] lol stupid client [Wed Aug 28 17:46:59 2013] lol stupid client [Wed Aug 28 17:47:41 2013] default setting is decode UTF8 but don't encode it [Wed Aug 28 17:47:41 2013] default setting is decode UTF8 but don't encode it [Wed Aug 28 17:59:42 2013] ColonelJ: hmm, they must have fixed it since 8.3 [Wed Aug 28 17:59:42 2013] ColonelJ: hmm, they must have fixed it since 8.3 [Wed Aug 28 19:03:50 2013] I don't really understand how to choose between the various assumption keywords [Wed Aug 28 19:03:50 2013] I don't really understand how to choose between the various assumption keywords [Wed Aug 28 19:04:17 2013] Knowing that they all do essentially the same thing doesn't help matters [Wed Aug 28 19:04:17 2013] Knowing that they all do essentially the same thing doesn't help matters [Wed Aug 28 19:04:41 2013] Parameter is the only one that seems obvious [Wed Aug 28 19:04:41 2013] Parameter is the only one that seems obvious [Wed Aug 28 19:05:21 2013] I don't even see what Conjecture even has any use for in a PROOF system [Wed Aug 28 19:05:22 2013] I don't even see what Conjecture even has any use for in a PROOF system [Wed Aug 28 19:07:39 2013] i think they were supposed to be used by tools that produced documentation, but i'm not sure anything ever did [Wed Aug 28 19:07:39 2013] i think they were supposed to be used by tools that produced documentation, but i'm not sure anything ever did [Wed Aug 28 19:07:51 2013] think the existing tools basically treat them all the same way [Wed Aug 28 19:07:51 2013] think the existing tools basically treat them all the same way [Wed Aug 28 19:08:19 2013] they do carry some semantic distinction even if the tools treat them the same [Wed Aug 28 19:08:19 2013] they do carry some semantic distinction even if the tools treat them the same [Wed Aug 28 19:08:30 2013] which makes it more of a style thing, hence why I asked [Wed Aug 28 19:08:30 2013] which makes it more of a style thing, hence why I asked [Wed Aug 28 19:10:22 2013] I nice keyword to have would be Assumption... [Wed Aug 28 19:10:22 2013] I nice keyword to have would be Assumption... [Wed Aug 28 19:11:50 2013] all I want to do is state some property a parameter already passed in, none of the keywords really seem right, gonna have to use axiom again [Wed Aug 28 19:11:50 2013] all I want to do is state some property a parameter already passed in, none of the keywords really seem right, gonna have to use axiom again [Wed Aug 28 19:12:28 2013] I suppose axioms do have to be assumed [Wed Aug 28 19:12:28 2013] I suppose axioms do have to be assumed [Wed Aug 28 19:29:40 2013] nice list here http://quizlet.com/363753/algebra-1-properties-and-axioms-flash-cards/ [Wed Aug 28 19:29:40 2013] nice list here http://quizlet.com/363753/algebra-1-properties-and-axioms-flash-cards/ [Wed Aug 28 19:31:55 2013] not sure I trust it though [Wed Aug 28 19:31:55 2013] not sure I trust it though [Wed Aug 28 21:10:54 2013] Don't suppose anyone can tell me how you can prove something with a certain dependent type arose from a certain constructor? [Wed Aug 28 21:10:54 2013] Don't suppose anyone can tell me how you can prove something with a certain dependent type arose from a certain constructor? [Wed Aug 28 21:11:33 2013] destruct tactic doesn't work because it tries to generalise the index which is the only useful piece of info [Wed Aug 28 21:11:33 2013] destruct tactic doesn't work because it tries to generalise the index which is the only useful piece of info [Thu Aug 29 04:43:48 2013] ColonelJ: your question is similar to the one I asked yesterday, as I understand: http://lpaste.net/92239. Possible solutions are: http://paste.awesom.eu/Ptival/dG8 , http://lpaste.net/92246 , http://lpaste.net/92253 [Thu Aug 29 04:43:48 2013] ColonelJ: your question is similar to the one I asked yesterday, as I understand: http://lpaste.net/92239. Possible solutions are: http://paste.awesom.eu/Ptival/dG8 , http://lpaste.net/92246 , http://lpaste.net/92253 [Thu Aug 29 05:24:50 2013] where can i find information on the parsing of Notations ? [Thu Aug 29 05:24:50 2013] where can i find information on the parsing of Notations ? [Thu Aug 29 06:34:49 2013] Anarchos: what do you mean by parsing, the formal grammar for Norations? Or just a user reference? [Thu Aug 29 06:34:49 2013] Anarchos: what do you mean by parsing, the formal grammar for Norations? Or just a user reference? [Thu Aug 29 06:35:21 2013] I've seen user reference in the Coq manual, however, coq.inria.fr seems to be down at the moment. [Thu Aug 29 06:35:21 2013] I've seen user reference in the Coq manual, however, coq.inria.fr seems to be down at the moment. [Thu Aug 29 06:35:23 2013] i want to add similar features to my program that coq has with Notations [Thu Aug 29 06:35:23 2013] i want to add similar features to my program that coq has with Notations [Thu Aug 29 06:35:41 2013] i considered dypgen but not sure which way gives me the more flexibility [Thu Aug 29 06:35:41 2013] i considered dypgen but not sure which way gives me the more flexibility [Thu Aug 29 07:20:50 2013] http://pastebin.com/ZYqNyt9d I got this code in Coq, it works. But can I make Coq generate all necessary code, including type conversion and printf call? [Thu Aug 29 07:20:50 2013] http://pastebin.com/ZYqNyt9d I got this code in Coq, it works. But can I make Coq generate all necessary code, including type conversion and printf call? [Thu Aug 29 07:27:48 2013] no idea [Thu Aug 29 07:27:48 2013] no idea [Thu Aug 29 07:34:38 2013] Can I implement Fibonacci's in one match like in other languages? [Thu Aug 29 07:34:39 2013] Can I implement Fibonacci's in one match like in other languages? [Thu Aug 29 08:06:58 2013] Necrosporus: it was you who asked it on the conference.jabber.ru server, right? I get error messages while posing there for some reason. [Thu Aug 29 08:06:58 2013] Necrosporus: it was you who asked it on the conference.jabber.ru server, right? I get error messages while posing there for some reason. [Thu Aug 29 08:07:22 2013] Necrosporus: this seems to work: http://lpaste.net/92279 [Thu Aug 29 08:07:22 2013] Necrosporus: this seems to work: http://lpaste.net/92279 [Thu Aug 29 08:07:35 2013] ah [Thu Aug 29 08:07:35 2013] ah [Thu Aug 29 08:07:39 2013] sorry [Thu Aug 29 08:07:39 2013] sorry [Thu Aug 29 08:07:41 2013] mistyped [Thu Aug 29 08:07:41 2013] mistyped [Thu Aug 29 08:08:04 2013] yeah, that doesn't seem to work :) [Thu Aug 29 08:08:04 2013] yeah, that doesn't seem to work :) [Thu Aug 29 08:08:56 2013] also, you asked for Agda, yeah, in Agda that works http://lpaste.net/92278 [Thu Aug 29 08:08:56 2013] also, you asked for Agda, yeah, in Agda that works http://lpaste.net/92278 [Thu Aug 29 08:10:33 2013] I guess the reason is Agda developers have to implement a smart termination checker due to the lack of tactics [Thu Aug 29 08:10:33 2013] I guess the reason is Agda developers have to implement a smart termination checker due to the lack of tactics [Thu Aug 29 08:27:06 2013] karlicoss i will go with dypgen first as it is close to ocamlyacc syntax :) [Thu Aug 29 08:27:06 2013] karlicoss i will go with dypgen first as it is close to ocamlyacc syntax :) [Thu Aug 29 10:37:37 2013] Necrosporus, karlicoss: http://lpaste.net/92282 [Thu Aug 29 10:37:37 2013] Necrosporus, karlicoss: http://lpaste.net/92282 [Thu Aug 29 10:38:27 2013] Notice that at the level of the underlaying CiC term, there are still two pattern matches. [Thu Aug 29 10:38:27 2013] Notice that at the level of the underlaying CiC term, there are still two pattern matches. [Thu Aug 29 10:40:09 2013] a reason that Coq's pattern matching and termination checker is more limited than Agda's, is because they try to keep foundations small (and thus the kernel), whereas Agda does not care too much about that. [Thu Aug 29 10:40:09 2013] a reason that Coq's pattern matching and termination checker is more limited than Agda's, is because they try to keep foundations small (and thus the kernel), whereas Agda does not care too much about that. [Thu Aug 29 10:43:10 2013] They'll have to bite the bullet some time. Modular proof development is impossible currently. [Thu Aug 29 10:43:10 2013] They'll have to bite the bullet some time. Modular proof development is impossible currently. [Thu Aug 29 10:44:06 2013] You can fake it with typeclasses that just import absolutely everything, but your proof details might end up depending on implementation details inadvertently. [Thu Aug 29 10:44:06 2013] You can fake it with typeclasses that just import absolutely everything, but your proof details might end up depending on implementation details inadvertently. [Thu Aug 29 10:45:49 2013] robbert`, why do you use n in last match? [Thu Aug 29 10:45:49 2013] robbert`, why do you use n in last match? [Thu Aug 29 10:46:33 2013] Necrosporus: what do you mean? [Thu Aug 29 10:46:33 2013] Necrosporus: what do you mean? [Thu Aug 29 10:52:54 2013] robbert`, match n with S (S n as n') [Thu Aug 29 10:52:54 2013] robbert`, match n with S (S n as n') [Thu Aug 29 10:53:15 2013] So n in this case has other meaning as in function definition [Thu Aug 29 10:53:15 2013] So n in this case has other meaning as in function definition [Thu Aug 29 10:53:35 2013] I guess, it's better to use S (S n'' as n') [Thu Aug 29 10:53:35 2013] I guess, it's better to use S (S n'' as n') [Thu Aug 29 10:54:03 2013] So n'' = n - 2 and n' as n - 1 [Thu Aug 29 10:54:03 2013] So n'' = n - 2 and n' as n - 1 [Thu Aug 29 10:54:19 2013] instead of n as n - 2 and n' as n - 1 [Thu Aug 29 10:54:19 2013] instead of n as n - 2 and n' as n - 1 [Thu Aug 29 10:54:50 2013] But thanks, it seem good enough [Thu Aug 29 10:54:50 2013] But thanks, it seem good enough [Thu Aug 29 10:55:11 2013] you're right [Thu Aug 29 10:55:11 2013] you're right [Thu Aug 29 15:50:03 2013] the website coq.inria.fr seems to be down, does anyone know what's up/when it's going to be up again? [Thu Aug 29 15:50:03 2013] the website coq.inria.fr seems to be down, does anyone know what's up/when it's going to be up again? [Thu Aug 29 16:07:09 2013] jlp_ no idea [Thu Aug 29 16:07:09 2013] jlp_ no idea [Thu Aug 29 16:19:38 2013] jlp_: the Coq website is awfully often down... Best to get a local copy of the docs (or verify their webserver using Coq so that it does not crash that often :P) [Thu Aug 29 16:19:38 2013] jlp_: the Coq website is awfully often down... Best to get a local copy of the docs (or verify their webserver using Coq so that it does not crash that often :P) [Thu Aug 29 16:28:09 2013] robbert`: thanks, unfortunately I'm a TA for a class using Coq, so all the student want to install it right about now! hopefully it will be back soon! [Thu Aug 29 16:28:09 2013] robbert`: thanks, unfortunately I'm a TA for a class using Coq, so all the student want to install it right about now! hopefully it will be back soon! [Thu Aug 29 16:38:27 2013] there is a mirror of the sources on github: https://github.com/coq/coq/tree/v8.4 (although that will probably not really help your windows and mac students :)) [Thu Aug 29 16:38:27 2013] there is a mirror of the sources on github: https://github.com/coq/coq/tree/v8.4 (although that will probably not really help your windows and mac students :)) [Thu Aug 29 16:39:32 2013] awesome, thanks! [Thu Aug 29 16:39:32 2013] awesome, thanks! [Fri Aug 30 09:26:31 2013] if i understand, coqide communicates with a coqtop via a spawned process [Fri Aug 30 09:26:31 2013] if i understand, coqide communicates with a coqtop via a spawned process [Fri Aug 30 09:26:43 2013] and commands are sent, results are read via XML ? [Fri Aug 30 09:26:43 2013] and commands are sent, results are read via XML ? [Fri Aug 30 09:27:43 2013] I believe so. Also, this is relatively new development. (8.4?) [Fri Aug 30 09:27:43 2013] I believe so. Also, this is relatively new development. (8.4?) [Fri Aug 30 09:29:25 2013] yes it is 8.4 ; do you know how it was made before ? [Fri Aug 30 09:29:25 2013] yes it is 8.4 ; do you know how it was made before ? [Fri Aug 30 09:29:36 2013] i hate xml for communication between processes [Fri Aug 30 09:29:36 2013] i hate xml for communication between processes [Fri Aug 30 09:30:23 2013] well, there's the other way -- the one that ProofGeneral uses -- but I hear the xml is much easier to deal with [Fri Aug 30 09:30:23 2013] well, there's the other way -- the one that ProofGeneral uses -- but I hear the xml is much easier to deal with [Fri Aug 30 09:31:13 2013] fisi how works ProofGeneral ? [Fri Aug 30 09:31:13 2013] fisi how works ProofGeneral ? [Fri Aug 30 09:31:18 2013] and before coqide was running in the same process (at the very least up until 8.2), which caused a whole lot of problems when tactics looped and the like. [Fri Aug 30 09:31:18 2013] and before coqide was running in the same process (at the very least up until 8.2), which caused a whole lot of problems when tactics looped and the like. [Fri Aug 30 09:31:55 2013] fisi ok. I am developing a program with a GUI, which the business logic is done in an isolated OCaml program [Fri Aug 30 09:31:55 2013] fisi ok. I am developing a program with a GUI, which the business logic is done in an isolated OCaml program [Fri Aug 30 09:32:09 2013] so i have same problems of architecture [Fri Aug 30 09:32:09 2013] so i have same problems of architecture [Fri Aug 30 09:32:41 2013] hah, that's a good question! I don't know how exactly the communication is handled in PG; generally, emacs communicates w/ processes using the stdIn/Out/Err streams [Fri Aug 30 09:32:41 2013] hah, that's a good question! I don't know how exactly the communication is handled in PG; generally, emacs communicates w/ processes using the stdIn/Out/Err streams [Fri Aug 30 09:33:16 2013] and this can easily become mighty messy, you have to deal with buffering and whatnot [Fri Aug 30 09:33:16 2013] and this can easily become mighty messy, you have to deal with buffering and whatnot [Fri Aug 30 09:33:33 2013] fisi but i have the source of the gui and the program since i write them, so i wonder if there is not a better solution than encode/communicate/decode and so on [Fri Aug 30 09:33:33 2013] fisi but i have the source of the gui and the program since i write them, so i wonder if there is not a better solution than encode/communicate/decode and so on [Fri Aug 30 09:33:44 2013] yes buffering is a pain [Fri Aug 30 09:33:44 2013] yes buffering is a pain [Fri Aug 30 09:34:45 2013] I guess, unless your memory representations on both sides coincide, you *will* have to transcode in some way, won't you? [Fri Aug 30 09:34:45 2013] I guess, unless your memory representations on both sides coincide, you *will* have to transcode in some way, won't you? [Fri Aug 30 09:35:54 2013] fisi i don't know yet :) [Fri Aug 30 09:35:54 2013] fisi i don't know yet :) [Fri Aug 30 09:39:39 2013] but at the user part, formulas are LaTeX strings, so why transcode to XML to send them ?? [Fri Aug 30 09:39:39 2013] but at the user part, formulas are LaTeX strings, so why transcode to XML to send them ?? [Fri Aug 30 09:41:42 2013] you'd probably still want to know where they begin and end, and the likes -- but basically you can go with any home-brewed protocol you want, I guess. It's just that for xml you have libraries already there. [Fri Aug 30 09:41:42 2013] you'd probably still want to know where they begin and end, and the likes -- but basically you can go with any home-brewed protocol you want, I guess. It's just that for xml you have libraries already there. [Fri Aug 30 09:42:25 2013] begin and ends : newlines :) [Fri Aug 30 09:42:25 2013] begin and ends : newlines :) [Fri Aug 30 09:43:20 2013] if you're certain there are no newlines inside the strings, it'd probably work, why not? [Fri Aug 30 09:43:20 2013] if you're certain there are no newlines inside the strings, it'd probably work, why not? [Fri Aug 30 09:47:03 2013] speaking about proof general: there should be an emacs config setting for the path to the Coq binaries, right? Can't find anything :( [Fri Aug 30 09:47:03 2013] speaking about proof general: there should be an emacs config setting for the path to the Coq binaries, right? Can't find anything :( [Fri Aug 30 09:49:25 2013] ah, finally found it, I guess [Fri Aug 30 09:49:25 2013] ah, finally found it, I guess [Fri Aug 30 09:49:58 2013] seems like coq-prog-env [Fri Aug 30 09:49:58 2013] seems like coq-prog-env [Sat Aug 31 10:36:29 2013] OK I'm really stuck on what seems like it should be a trivial proof. [Sat Aug 31 10:36:29 2013] OK I'm really stuck on what seems like it should be a trivial proof. [Sat Aug 31 10:36:52 2013] Inductive bvec (T : Set) : nat -> Set := [Sat Aug 31 10:36:52 2013] Inductive bvec (T : Set) : nat -> Set := [Sat Aug 31 10:36:52 2013] | BLeaf : T -> bvec T O [Sat Aug 31 10:36:52 2013] | BLeaf : T -> bvec T O [Sat Aug 31 10:36:52 2013] | BNode n : bvec T n -> bvec T n -> bvec T (S n). [Sat Aug 31 10:36:52 2013] | BNode n : bvec T n -> bvec T n -> bvec T (S n). [Sat Aug 31 10:36:52 2013] Definition bvec_leaf T (v : bvec T O) := let 'BLeaf a := v in a. [Sat Aug 31 10:36:52 2013] Definition bvec_leaf T (v : bvec T O) := let 'BLeaf a := v in a. [Sat Aug 31 10:36:52 2013] Lemma leaf_reconstruct : forall T (v : bvec T O), BLeaf (bvec_leaf v) = v. [Sat Aug 31 10:36:52 2013] Lemma leaf_reconstruct : forall T (v : bvec T O), BLeaf (bvec_leaf v) = v. [Sat Aug 31 10:43:10 2013] I'm surprised that the [bvec_leaf] definition was accepted. I guess that Coq team has been busy adding dependent typing heuristics. [Sat Aug 31 10:43:10 2013] I'm surprised that the [bvec_leaf] definition was accepted. I guess that Coq team has been busy adding dependent typing heuristics. [Sat Aug 31 10:44:07 2013] Have you read CPDT? [Sat Aug 31 10:44:07 2013] Have you read CPDT? [Sat Aug 31 10:46:01 2013] I'm part way through it [Sat Aug 31 10:46:01 2013] I'm part way through it [Sat Aug 31 10:46:18 2013] I don't want to have to read the entire thing to be able to do anything [Sat Aug 31 10:46:18 2013] I don't want to have to read the entire thing to be able to do anything [Sat Aug 31 10:46:25 2013] even if I will in time [Sat Aug 31 10:46:25 2013] even if I will in time [Sat Aug 31 10:47:04 2013] Well, [dependent destruction] makes your lemma easy, but it uses an axiom. [Sat Aug 31 10:47:04 2013] Well, [dependent destruction] makes your lemma easy, but it uses an axiom. [Sat Aug 31 10:47:53 2013] The whole thing is easy to do without axioms, and it's basically Chapters 8 and 9 of CPDT that explain how. [Sat Aug 31 10:47:53 2013] The whole thing is easy to do without axioms, and it's basically Chapters 8 and 9 of CPDT that explain how. [Sat Aug 31 10:51:07 2013] yea they seem quite important chapters might be more productive to read at least that far [Sat Aug 31 10:51:07 2013] yea they seem quite important chapters might be more productive to read at least that far [Sat Aug 31 10:55:40 2013] it's kinda disappointing that this whole thing turns out much less intuitive to use than you'd hope for [Sat Aug 31 10:55:40 2013] it's kinda disappointing that this whole thing turns out much less intuitive to use than you'd hope for [Sat Aug 31 10:57:49 2013] The sort of magic easy dependent typing that you're hoping for is provably impossible, because of undecidability results. [Sat Aug 31 10:57:49 2013] The sort of magic easy dependent typing that you're hoping for is provably impossible, because of undecidability results. [Sat Aug 31 10:58:02 2013] Is there any way to do induction over a pair of bvecs without needing that dependent destruction/induction? [Sat Aug 31 10:58:02 2013] Is there any way to do induction over a pair of bvecs without needing that dependent destruction/induction? [Sat Aug 31 10:58:03 2013] I'd rather that Coq had kept not accepting definitions like your [bvec_leaf] above. [Sat Aug 31 10:58:03 2013] I'd rather that Coq had kept not accepting definitions like your [bvec_leaf] above. [Sat Aug 31 10:58:26 2013] That way, you'd realize that you need to do a bit more work, and that work would make obvious which induction strategy will work. [Sat Aug 31 10:58:26 2013] That way, you'd realize that you need to do a bit more work, and that work would make obvious which induction strategy will work. [Sat Aug 31 10:58:54 2013] In general, induction is only allowed over inductive families applied only to _variables_. [Sat Aug 31 10:58:54 2013] In general, induction is only allowed over inductive families applied only to _variables_. [Sat Aug 31 10:58:59 2013] Above you're applying a family to [0]. [Sat Aug 31 10:58:59 2013] Above you're applying a family to [0]. [Sat Aug 31 10:59:20 2013] See CPDT for the design patterns to deal with this restriction. [Sat Aug 31 10:59:20 2013] See CPDT for the design patterns to deal with this restriction. [Sat Aug 31 13:58:27 2013] btw, I just used 'induction xs; dependent induction ys; simpl; congruence.' to solve the thing I was trying to do in the first place, I didn't need any special strategy or axioms, it Just Works (TM). [Sat Aug 31 13:58:28 2013] btw, I just used 'induction xs; dependent induction ys; simpl; congruence.' to solve the thing I was trying to do in the first place, I didn't need any special strategy or axioms, it Just Works (TM). [Sat Aug 31 13:59:07 2013] Also I think that the definition of bvec_leaf is very easy to understand and makes a lot of sense to use if Coq can provide that as an option [Sat Aug 31 13:59:07 2013] Also I think that the definition of bvec_leaf is very easy to understand and makes a lot of sense to use if Coq can provide that as an option [Sat Aug 31 14:02:07 2013] Actually reading back I probably misunderstood on the axioms thing if it uses one internally... [Sat Aug 31 14:02:07 2013] Actually reading back I probably misunderstood on the axioms thing if it uses one internally... [Sat Aug 31 14:06:13 2013] I'm guessing it's that JMeq_eq one you mean [Sat Aug 31 14:06:13 2013] I'm guessing it's that JMeq_eq one you mean [Sat Aug 31 14:09:05 2013] hmm that's chapter 10 in CPDT [Sat Aug 31 14:09:05 2013] hmm that's chapter 10 in CPDT [Sat Aug 31 15:39:36 2013] I think I need the function_extensionality for this proof as well, otherwise I can't rewrite anything inside a lambda? [Sat Aug 31 15:39:36 2013] I think I need the function_extensionality for this proof as well, otherwise I can't rewrite anything inside a lambda? [Sat Aug 31 15:51:37 2013] not even sure what the Ltac command is to do rewriting using that.. [Sat Aug 31 15:51:37 2013] not even sure what the Ltac command is to do rewriting using that.. [Sat Aug 31 16:03:32 2013] rewrite <- (functional_extensionality (λ n, n) (λ n, n + O) (plus_n_O)). [Sat Aug 31 16:03:32 2013] rewrite <- (functional_extensionality (λ n, n) (λ n, n + O) (plus_n_O)). [Sat Aug 31 16:04:54 2013] umm no that's not it [Sat Aug 31 16:04:54 2013] umm no that's not it [Sat Aug 31 16:57:19 2013] I've found you can do "rewrite <- (functional_extensionality this_function that_function)." to get a goal where the function has been replaced and another goal where you prove the outputs of the functions are equal. Downside is you have to write the functions out in full I think.. [Sat Aug 31 16:57:19 2013] I've found you can do "rewrite <- (functional_extensionality this_function that_function)." to get a goal where the function has been replaced and another goal where you prove the outputs of the functions are equal. Downside is you have to write the functions out in full I think.. [Sat Aug 31 18:21:57 2013] I feel like the goals that come out of that should be the other way round [Sat Aug 31 18:21:57 2013] I feel like the goals that come out of that should be the other way round [Sat Aug 31 18:23:16 2013] it would be nicer to prove the functions equal and then continue with your proof [Sat Aug 31 18:23:16 2013] it would be nicer to prove the functions equal and then continue with your proof [Sat Aug 31 19:27:16 2013] yea it's much better to do the other side of the proof backwards and then use the extensionality tactic [Sat Aug 31 19:27:16 2013] yea it's much better to do the other side of the proof backwards and then use the extensionality tactic [Sat Aug 31 19:27:40 2013] I ended up having to do "f_equal; f_equal; extensionality x" [Sat Aug 31 19:27:40 2013] I ended up having to do "f_equal; f_equal; extensionality x" [Sat Aug 31 19:29:01 2013] there must be a better way than having to f_equal multiple times to get down to the core structure surely? [Sat Aug 31 19:29:01 2013] there must be a better way than having to f_equal multiple times to get down to the core structure surely? [Sat Aug 31 19:33:18 2013] this is what my proof looks like currently [Sat Aug 31 19:33:18 2013] this is what my proof looks like currently [Sat Aug 31 19:33:19 2013] autounfold; induction s; simpl; autorewrite with lemmas; autounfold; auto. [Sat Aug 31 19:33:19 2013] autounfold; induction s; simpl; autorewrite with lemmas; autounfold; auto. [Sat Aug 31 19:33:19 2013] simpl; rewrite IHs1, IHs2; autorewrite with lemmas; autounfold. [Sat Aug 31 19:33:19 2013] simpl; rewrite IHs1, IHs2; autorewrite with lemmas; autounfold. [Sat Aug 31 19:33:20 2013] f_equal; f_equal; extensionality x; autorewrite with lemmas; auto. [Sat Aug 31 19:33:19 2013] f_equal; f_equal; extensionality x; autorewrite with lemmas; auto. [Sat Aug 31 19:40:04 2013] new version [Sat Aug 31 19:40:04 2013] new version [Sat Aug 31 19:40:04 2013] solve; induction s; repeat solve; rewrite IHs1, IHs2; solve. [Sat Aug 31 19:40:05 2013] solve; induction s; repeat solve; rewrite IHs1, IHs2; solve. [Sat Aug 31 19:40:05 2013] f_equal; f_equal; extensionality x; solve. [Sat Aug 31 19:40:05 2013] f_equal; f_equal; extensionality x; solve. [Sat Aug 31 19:41:15 2013] new new version [Sat Aug 31 19:41:15 2013] new new version [Sat Aug 31 19:41:16 2013] solve; induction s; repeat solve; rewrite IHs1, IHs2; solve. [Sat Aug 31 19:41:16 2013] solve; induction s; repeat solve; rewrite IHs1, IHs2; solve. [Sat Aug 31 19:41:16 2013] repeat f_equal; extensionality x; solve. [Sat Aug 31 19:41:16 2013] repeat f_equal; extensionality x; solve. [Sat Aug 31 20:56:08 2013] mmh how do you create an empty hint database for rewrites? [Sat Aug 31 20:56:08 2013] mmh how do you create an empty hint database for rewrites? [Sun Sep 1 04:52:35 2013] How can I omit writing the body for an impossible case in the Definition? For instance, I have Lemma lemma : exists b, a = Some b. , and I am pattern matching on a in some function. How do I discard the None case? [Sun Sep 1 04:52:35 2013] How can I omit writing the body for an impossible case in the Definition? For instance, I have Lemma lemma : exists b, a = Some b. , and I am pattern matching on a in some function. How do I discard the None case? [Sun Sep 1 04:54:53 2013] my guess is there should be some built-in like forall T : Set, forall p : Prop, p -> ~ p -> T for handling that. [Sun Sep 1 04:54:53 2013] my guess is there should be some built-in like forall T : Set, forall p : Prop, p -> ~ p -> T for handling that. [Sun Sep 1 04:55:22 2013] Well, the signature you just wrote is just application plus explosion (since ~ p = p -> False) [Sun Sep 1 04:55:22 2013] Well, the signature you just wrote is just application plus explosion (since ~ p = p -> False) [Sun Sep 1 04:55:34 2013] But in general if you want an impossible case you'll need a dependent pattern match [Sun Sep 1 04:55:34 2013] But in general if you want an impossible case you'll need a dependent pattern match [Sun Sep 1 06:05:05 2013] karlicos: False_rec lets you handle that [Sun Sep 1 06:05:05 2013] karlicos: False_rec lets you handle that [Sun Sep 1 06:05:13 2013] as soon as you get a False [Sun Sep 1 06:05:13 2013] as soon as you get a False [Sun Sep 1 10:30:09 2013] I can't seem to get "proj1_sig signature" to evaluate using simpl even if I do "Arguments proj1_sig [A] [P] !e /." and "Arguments signature /." [Sun Sep 1 10:30:09 2013] I can't seem to get "proj1_sig signature" to evaluate using simpl even if I do "Arguments proj1_sig [A] [P] !e /." and "Arguments signature /." [Sun Sep 1 10:34:22 2013] actually you can't even unfold a signature.. [Sun Sep 1 10:34:22 2013] actually you can't even unfold a signature.. [Sun Sep 1 11:22:35 2013] ok I guess I'll have to accept it's not 'evaluable' whatever that means [Sun Sep 1 11:22:35 2013] ok I guess I'll have to accept it's not 'evaluable' whatever that means [Sun Sep 1 15:42:32 2013] Notation "( R ) + ( I )j" := (Cplx R I) (at level 45, format [Sun Sep 1 15:42:32 2013] Notation "( R ) + ( I )j" := (Cplx R I) (at level 45, format [Sun Sep 1 15:42:32 2013] "'[hv ' '(' R ')' '/' '+' '/ ' '(' I ')j' ']'") : program_scope. [Sun Sep 1 15:42:32 2013] "'[hv ' '(' R ')' '/' '+' '/ ' '(' I ')j' ']'") : program_scope. [Sun Sep 1 15:42:34 2013] heehee [Sun Sep 1 15:42:34 2013] heehee [Sun Sep 1 15:49:55 2013] I should really use a cplx_scope eh [Sun Sep 1 15:49:55 2013] I should really use a cplx_scope eh [Sun Sep 1 16:33:10 2013] Definition mult_cplx x y := let '(xr)+(xi)j := x in let '(yr)+(yi)j := y in [Sun Sep 1 16:33:10 2013] Definition mult_cplx x y := let '(xr)+(xi)j := x in let '(yr)+(yi)j := y in [Sun Sep 1 16:33:10 2013] (xr * yr + - xi * yi) + (xr * yi + xi * yr)j. [Sun Sep 1 16:33:10 2013] (xr * yr + - xi * yi) + (xr * yi + xi * yr)j. [Sun Sep 1 16:34:22 2013] This complex notation seems to stop me putting xr * yr as (xr * yr) for example so yes things are a bit fraught... [Sun Sep 1 16:34:22 2013] This complex notation seems to stop me putting xr * yr as (xr * yr) for example so yes things are a bit fraught... [Sun Sep 1 16:36:08 2013] Not sure if the problem is the underlying parser engine or Coq's use of it. LALR is a bit crap though. [Sun Sep 1 16:36:08 2013] Not sure if the problem is the underlying parser engine or Coq's use of it. LALR is a bit crap though. [Sun Sep 1 16:37:39 2013] oh camlp4 is recursive descent [Sun Sep 1 16:37:39 2013] oh camlp4 is recursive descent [Sun Sep 1 16:40:48 2013] Lemma mult_id_exists_cplx : {mult_id_cplx | ∀ x, mult_cplx x mult_id_cplx = x}. [Sun Sep 1 16:40:48 2013] Lemma mult_id_exists_cplx : {mult_id_cplx | ∀ x, mult_cplx x mult_id_cplx = x}. [Sun Sep 1 16:40:48 2013] exists ((1 - 0) + (0 - 0)j); destruct x; destruct r, i; solve. [Sun Sep 1 16:40:48 2013] exists ((1 - 0) + (0 - 0)j); destruct x; destruct r, i; solve. [Sun Sep 1 16:40:48 2013] Qed. [Sun Sep 1 16:40:48 2013] Qed. [Sun Sep 1 16:41:56 2013] That - is my constructor for type int :P [Sun Sep 1 16:41:56 2013] That - is my constructor for type int :P [Sun Sep 1 16:45:02 2013] Lemma mult_id_exists_cplx : {mult_id_cplx | ∀ x, x * mult_id_cplx = x}. [Sun Sep 1 16:45:02 2013] Lemma mult_id_exists_cplx : {mult_id_cplx | ∀ x, x * mult_id_cplx = x}. [Sun Sep 1 16:46:56 2013] - ((p - n) + (p0 - n0)j) + - ((p1 - n1) + (p2 - n2)j) = [Sun Sep 1 16:46:56 2013] - ((p - n) + (p0 - n0)j) + - ((p1 - n1) + (p2 - n2)j) = [Sun Sep 1 16:46:56 2013] - ((p - n) + (p0 - n0)j + (p1 - n1) + (p2 - n2)j) [Sun Sep 1 16:46:56 2013] - ((p - n) + (p0 - n0)j + (p1 - n1) + (p2 - n2)j) [Sun Sep 1 16:50:51 2013] x * - y = [Sun Sep 1 16:50:51 2013] x * - y = [Sun Sep 1 16:51:01 2013] (p * n1 + n * p1 + (n0 * n2 + p0 * p2) - [Sun Sep 1 16:51:01 2013] (p * n1 + n * p1 + (n0 * n2 + p0 * p2) - [Sun Sep 1 16:51:01 2013] (p * p1 + n * n1 + (n0 * p2 + p0 * n2))) [Sun Sep 1 16:51:01 2013] (p * p1 + n * n1 + (n0 * p2 + p0 * n2))) [Sun Sep 1 16:51:01 2013] + [Sun Sep 1 16:51:01 2013] + [Sun Sep 1 16:51:01 2013] (p * n2 + n * p2 + (p0 * n1 + n0 * p1) - [Sun Sep 1 16:51:01 2013] (p * n2 + n * p2 + (p0 * n1 + n0 * p1) - [Sun Sep 1 16:51:01 2013] (p * p2 + n * n2 + (p0 * p1 + n0 * n1)))j = [Sun Sep 1 16:51:01 2013] (p * p2 + n * n2 + (p0 * p1 + n0 * n1)))j = [Sun Sep 1 16:51:14 2013] - (x * y) [Sun Sep 1 16:51:14 2013] - (x * y) [Sun Sep 1 19:05:54 2013] hello. i'm reading http://www.cis.upenn.edu/~bcpierce/sf/Induction.html now, and just stuck on one sentence: "Define a function normalize from binary numbers to binary numbers such that for any binary number b, converting to a natural and then back to binary yields (normalize b)". what's meant by last words, "yields (normalize b)."? [Sun Sep 1 19:07:06 2013] I think 'yields' means produces the same value as [Sun Sep 1 19:07:35 2013] i.e. back_to_binary(convert_to_natural b) = normalize b [Sun Sep 1 19:07:45 2013] oh, thank you [Sun Sep 1 19:08:09 2013] i've thought that those function should yield it somehow [Sun Sep 1 19:08:33 2013] That sentence is very badly written to be honest [Sun Sep 1 19:11:09 2013] ColonelJ yes i had to read it twice before completing the exercise [Sun Sep 1 19:34:28 2013] Polished version of my first proof written into Coq if anyone wants to have a look http://paste.mnus.de/view/f399a3cd [Sun Sep 1 19:36:05 2013] It's a proof that the Fast Hadamard Transform does a Hadamard Transform [Mon Sep 2 13:47:34 2013] Hi guys. I'm stuck at proving Theorem ind_step2 : forall P : nat -> Prop, P 0 -> P 1 -> (forall n, P n -> P (S (S n))) -> forall n, P n. Any advice? [Mon Sep 2 13:49:21 2013] where are you stuck? [Mon Sep 2 13:54:28 2013] Well, I guess I should prove it by induction, so I am stuck at proving the induction step [Mon Sep 2 13:55:04 2013] However, I suspect I should not use induction. directly, but rather use it as nat_ind with a different predicate. [Mon Sep 2 13:57:02 2013] My proofgeneral is having trouble starting coqtop :/ [Mon Sep 2 14:07:58 2013] karlicos: I'm assuming you're having trouble, since after applying the induction hypothesis you're left with the P (S n) in the assumptions, and P n to prove [Mon Sep 2 14:08:10 2013] Yeah [Mon Sep 2 14:08:21 2013] I've done it actually, my idea was kind of right [Mon Sep 2 14:08:28 2013] ah, OK [Mon Sep 2 14:08:51 2013] http://lpaste.net/92461 [Mon Sep 2 14:08:52 2013] well, you can still do it using induction tactic, but for a different proposition [Mon Sep 2 14:09:11 2013] kind of ugly, but I'll prettify it later :) [Mon Sep 2 14:10:14 2013] yeah. The thing is, to do this without calling out to nat_ind explicitly, you can use "assert (HInd: P n /\ P (S n))." [Mon Sep 2 14:10:37 2013] and one of the goals that you're left with is trivial ("destruct HInd; assumption") [Mon Sep 2 14:11:47 2013] while on the other you can call "induction n", and it will give you the IH that's strong enough (I actually overkilled in this example, and used "forall k, k <= n -> P k" -- which also works ;)) [Mon Sep 2 14:16:41 2013] fisi: thanks, now it's indeed better :) http://lpaste.net/92462 [Mon Sep 2 14:18:34 2013] yeah, so the additional trick with assert is that using the syntax "assert (FOO : expr)" you can name the hyp (and -- since you know the name, in a case like this easily kill off the remaining goal after semicolon). [Mon Sep 2 14:19:41 2013] in this case, for example, like that: "assert (HPair : P n /\ P (S n)); [| destruct HPair as [HT _]; assumption]." [Mon Sep 2 14:20:34 2013] I guess it's a matter of personal taste how the script looks, but I prefer to kill off the easy goals fast, so there's less clutter. [Mon Sep 2 14:24:11 2013] update: ooh, it's even better! You can do assert (expr) as intro_pattern, which allows you to destruct stuff like existentials and con-/disjunctions [Mon Sep 2 14:24:43 2013] (so: "assert (P n /\ P (S n)) as [HGoal _]; [| assumption].") [Mon Sep 2 14:38:27 2013] intros; assert (P n /\ P (S n)); induction n; firstorder. [Mon Sep 2 14:38:46 2013] Had to rebuild Coq from scratch. [Mon Sep 2 14:38:54 2013] bah, firstorder, anyone can do firstorder! ;) [Mon Sep 2 18:04:55 2013] so I've recently been convinced by a friend that formally-proven code is not actually a massive, impractical waste of time ;) [Mon Sep 2 18:05:59 2013] * is now attempting to understand how it works [Mon Sep 2 18:12:38 2013] lupine: It *does* have a time cost. [Mon Sep 2 18:13:10 2013] But it's not *totally* impractical, and there're really a spectrum there of how much time/effort you want to put into statically verifying things. [Mon Sep 2 18:14:50 2013] lupine: The nice thing about dependently typed systems is that you put as much information into the types as you want, and get results back based on that. If you want to verify more properties, you'll probably have to encode more information about the values into the types, and spend more time working on it, but at least you have the option. [Mon Sep 2 18:22:01 2013] mm, I'm not expecting it to be magic :) but it's certainly intriguing [Mon Sep 2 18:22:28 2013] if only I had what seems to be the necessary mathematics and functional programming backgrounds [Tue Sep 3 08:01:30 2013] "assumption. assumption. assumption." finishes my proof but "repeat assumption." doesn't, why is that? looks like "repeat assumption." applies assumption only one time. [Tue Sep 3 08:03:57 2013] osa1: any tactic application works on the one goal with which you start that stage of proof. [Tue Sep 3 08:04:59 2013] now, in your case, each of the "assumption"s solves a subgoal (as, indeed, assumption can only either completely solve a subgoal or fail). [Tue Sep 3 08:05:20 2013] so "repeat assumption" only works on the first of your subgoals -- which it manages to solve [Tue Sep 3 08:05:37 2013] does this make sense to you? [Tue Sep 3 08:07:04 2013] ah, got it. thanks. [Tue Sep 3 08:07:31 2013] no problem [Tue Sep 3 08:17:26 2013] osa1: you're gonna need something like tactic; assumption. [Tue Sep 3 08:17:52 2013] where "tactic" is the name of the tactic which yielded these three subgoals [Tue Sep 3 08:18:21 2013] (in assumption they were produced by one tactic, of course) [Tue Sep 3 08:18:57 2013] tactic1; tactic2. is "apply tactic1 and then tactic2 for each subgoal" [Tue Sep 3 11:57:29 2013] Do I need to type "Local Open Scope list_scope." if I want to use :: instead of cons? Or I am doing something wrong? [Tue Sep 3 12:00:23 2013] It's Import List_Notation. or something [Tue Sep 3 12:00:36 2013] Once you've required the list library, of course. [Tue Sep 3 12:04:28 2013] ah, Require Import List seems to be enough [Tue Sep 3 12:04:32 2013] thanks [Wed Sep 4 09:34:42 2013] what is the reduction rule to reason (let (a, b) := p in (a, b)) = p ? [Wed Sep 4 09:43:27 2013] try destructing p [Wed Sep 4 09:45:42 2013] elliott: yeah, I got the answer already, it indeed works. Thanks! [Wed Sep 4 09:45:52 2013] :) [Wed Sep 4 10:36:01 2013] is there some shorthand for "specialize (something); intro hyp." ? [Wed Sep 4 10:37:47 2013] ah, I guess pose proof something as hyp. [Wed Sep 4 14:23:26 2013] I've got a context "a : A", "f : A -> A", "p : P (f a)". How can I transform it into "a : A", "f : A -> A", "b : A", "eq : b = f a", "p : P b"? [Wed Sep 4 14:27:53 2013] I've managed to do that using assert (exists b, b = f a). exists (f a). reflexivity. though, but isn't there a simpler way? [Wed Sep 4 14:36:50 2013] pose (b := f a); assert (eq : b = f a) by reflexivity. [Wed Sep 4 14:37:00 2013] It seems I needed remember (f a) as b. [Wed Sep 4 14:37:34 2013] karlicos: ah, yes that's better. [Thu Sep 5 16:24:29 2013] How am I supposed to install Coq contributions? [Thu Sep 5 17:35:29 2013] Do I have to add a contrib to the load bath explicitly, or I am doing something wrong while installing it? [Thu Sep 5 22:07:57 2013] do I need to know about Hoare logic if I'm only interested in meta-level theorems(i.e. theorems about the language) and not theorems about programs written in the language? [Thu Sep 5 22:20:19 2013] which language? [Thu Sep 5 22:20:54 2013] Saizan: my language -- but does that really matter? [Thu Sep 5 22:21:02 2013] but hoare logic, afaik, is mostly useful to prove properties of programs which make use of mutation [Thu Sep 5 22:23:48 2013] can anyone recommend me Coq formalizations of some simple languages so that I can have some ideas about what should I know? [Thu Sep 5 22:25:08 2013] I'm following Software Foundations book(in which I'm at Hoare Logic chapter) and it will eventually capture all required techniques but I still want to see a full implementation before finishing SF book(because it may take a long time for me -- I'm self studying) [Thu Sep 5 22:46:15 2013] how does reflection / reification relate to each other? [Fri Sep 6 19:58:40 2013] I had this crazy idea that lambda and forall could actually be the same thing allowing dependent arguments to transcend the whole type universes thing and allowing functions to recursively typed in terms of themselves e.g. the type of id is id, and the type of apply is apply. [Fri Sep 6 19:59:21 2013] as before if the dependent argument isn't used it just becomes a normal function arrow [Fri Sep 6 20:00:02 2013] non-termination in a term can mean non-termination in its type meaning that whole problem goes away [Fri Sep 6 20:33:35 2013] hmm no that doesn't work for apply at all, I think I need to think this through a bit more :) [Sat Sep 7 08:55:14 2013] ColonelJ: in some version of automath, Pi and lambda used to be the same [Sat Sep 7 08:56:15 2013] ah, he's not here... [Sat Sep 7 08:58:37 2013] i wonder what `(Natural -> Boolean) Boolean' would represent, then .. [Sat Sep 7 10:04:09 2013] How can I put the "n = S n'" equation in the context? http://lpaste.net/92689 [Sat Sep 7 11:25:11 2013] Goal (nat -> nat) : Set. [Sat Sep 7 11:25:15 2013] what do? [Sat Sep 7 11:30:42 2013] ColonelJ: "exact (fun n => n)." for example. [Sat Sep 7 11:38:24 2013] and this is unprovable because all elements of s would have to be instantiable? Goal forall s : Set, s. [Sat Sep 7 11:39:54 2013] would be the idea, i think [Sat Sep 7 11:51:48 2013] Goal (forall s : Set, s) -> False. [Sat Sep 7 11:51:48 2013] intro X; apply X. [Sat Sep 7 11:51:48 2013] Qed. [Sat Sep 7 11:51:57 2013] Well that was easy [Sat Sep 7 11:54:54 2013] I didn't know False was in Set [Sat Sep 7 11:58:24 2013] What actually is False? [Sat Sep 7 12:16:06 2013] I'm still thinking into my idea of last night, what I want is a system where the type of a list of 1s is a list of nats, the type of that is a list of Sets, the type of that is a list of Types etc. [Sat Sep 7 12:16:38 2013] I'm guessing it's not possible to make anything like this in Coq? [Sat Sep 7 12:18:17 2013] also I'd want a possibility of dependent type for an index on those lists so a list3 of 1s is a list3 of nats is a list3 of Sets... [Sat Sep 7 16:54:27 2013] hi why can't tauto with Classical module prove [Sat Sep 7 16:54:28 2013] Goal forall a : Prop, ~ ~ a <-> a. [Sun Sep 8 05:16:05 2013] Is there some kind of Search over all libraries in the library path, not only in the current environment? [Sun Sep 8 05:16:42 2013] or some Proof general feature, implementing this functionality [Mon Sep 9 15:13:17 2013] What are the news around coq ? [Mon Sep 9 15:52:57 2013] did you see the news about the Quark verified web browser? [Mon Sep 9 15:53:36 2013] no [Mon Sep 9 15:54:29 2013] http://goto.ucsd.edu/quark/ [Mon Sep 9 15:54:35 2013] newsham pointed me to it. [Mon Sep 9 15:55:16 2013] i am abit hurt by such announce like this ' In this way, Quark is able to make strong guarantees about a million lines of code (e.g., the renderer, JavaScript implementation, JPEG decoders, etc.)' [Mon Sep 9 15:55:26 2013] hello everyone, im a coq-newbie - can i ask a question about the "Case" strategy here? [Mon Sep 9 15:55:39 2013] did they really proved a million line of code ? [Mon Sep 9 15:55:52 2013] willem sure, don't ask to ask :) [Mon Sep 9 15:56:35 2013] ok, im following this tutorial: http://www.cis.upenn.edu/~bcpierce/sf/Induction.html [Mon Sep 9 15:56:58 2013] willem i did it too [Mon Sep 9 15:57:10 2013] and im at the theorem called andb_true_elim1 [Mon Sep 9 15:57:20 2013] willem: I think this is an error in Software Foundations, or some base library they failed to mention. [Mon Sep 9 15:57:28 2013] You can find the necessary code here: http://coq.inria.fr/cocorico/Case%20%28tactic%29 [Mon Sep 9 15:57:36 2013] ah, thank you [Mon Sep 9 15:57:43 2013] Anarchos: They specifically say they make guarantees about other code that wasn't formally proven through the exposed interfaces of the smaller kernel they did prove. [Mon Sep 9 15:57:51 2013] willem: I just ran into this last week :) [Mon Sep 9 15:58:06 2013] What good that is in practice is still to be determined, I think, but it's a decent PoC with comparatively little effort. [Mon Sep 9 15:58:31 2013] what would be a nice way to include this piece of code ystael? [Mon Sep 9 15:59:11 2013] willem: Paste that first box into TacticUtil.v, compile it with coqc, then you can Require Export TacticUtil at the top of each module. [Mon Sep 9 15:59:26 2013] cheers ;) [Mon Sep 9 16:00:51 2013] good luck! [Mon Sep 9 16:02:54 2013] ystael, do you also know by any chance of a command in proof general that lets me check an entire coq file at once? [Mon Sep 9 16:03:12 2013] I just do M-> C-RET [Mon Sep 9 16:03:22 2013] sorry, M-> C-c C-RET [Mon Sep 9 16:03:41 2013] thank you (eternally) :D [Mon Sep 9 16:50:25 2013] how can I see definitions of notations? [Mon Sep 9 16:54:05 2013] osa1: Locate "bla". [Mon Sep 9 16:54:15 2013] where "bla" cam be some token of the notation [Mon Sep 9 16:54:52 2013] willem: C-c C-b should process the entire buffer [Tue Sep 10 10:42:35 2013] I'm having trouble understanding difference between induction and inversion .. both generates goals for each constructor but induction provides induction hypothesis but that shouldn't be the only difference because otherwise inversion would be same as destruct, can anyone help me clarify these things? [Tue Sep 10 10:57:30 2013] osa1: inversion also tries to create equality hypotheses between variables introducted and the thing being destructed [Tue Sep 10 10:59:30 2013] sgnb: hmm.. can you give me a specific example of generated equality hypotheses? [Tue Sep 10 11:05:26 2013] osa1: http://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_tactic89 [Tue Sep 10 11:08:33 2013] and try to use "destruct" instead of "inversion"... you'll see the difference [Tue Sep 10 11:09:43 2013] also, inversion solves by itself cases that are obviously impossible [Tue Sep 10 11:12:04 2013] what is "obviously impossible" ? [Tue Sep 10 11:13:36 2013] osa1: like the things which were constructred by different constructors [Tue Sep 10 11:13:38 2013] btw, what's about work on "invert" tactic that could replace "inversion"? there was a post on gagalium about it. [Tue Sep 10 11:14:29 2013] for instance, in general, you'll use inverse H if you have "H : true = false" in the context to solve current subgoal [Tue Sep 10 11:16:46 2013] inversion H of course [Tue Sep 10 11:20:39 2013] osa1: in the example linked above, the "in_hd" is impossible because it would imply "0 = 1" [Tue Sep 10 11:21:26 2013] all cases with an hypothesis like that (equality of different constructors) are automatically discarded [Tue Sep 10 11:21:52 2013] gdsfh: gagalium? [Tue Sep 10 11:22:35 2013] sgnb: sorry, gagallium. http://gallium.inria.fr/blog/a-new-Coq-tactic-for-inversion/ [Tue Sep 10 11:23:46 2013] anyway, inversion is constantly being criticized and there have been talks on replacing it since I started doing Coq in 2007 [Tue Sep 10 11:24:05 2013] sgnb: why is that? [Tue Sep 10 11:24:23 2013] osa1: why is what? [Tue Sep 10 11:24:44 2013] inversion criticized? [Tue Sep 10 11:24:47 2013] yes [Tue Sep 10 11:25:14 2013] I guess because it is (sometimes) difficult to predict [Tue Sep 10 11:25:44 2013] I don't know, I'm not part of the criticizers ;-) [Tue Sep 10 11:26:31 2013] okay [Tue Sep 10 11:36:04 2013] i prefer destruct to inversion, it gives more clue on what is going [Wed Sep 11 07:00:43 2013] I'm trying to prove that <-> is associative in coq. Am I stating this correctly? Lemma equivassoc : forall p q r : Prop, (p <-> (q <-> r)) <-> ((p <-> q) <-> r). [Wed Sep 11 07:48:15 2013] Will I be able to prove this lemma without using extentionality axioms? Inductive single : Set := [Wed Sep 11 07:48:15 2013] | ss : single. [Wed Sep 11 07:48:15 2013] Lemma bbb : forall f : single -> bool, (forall x, f x = true) \/ (forall x, f x = false). [Wed Sep 11 07:48:15 2013] intro f. [Wed Sep 11 07:48:15 2013] [Wed Sep 11 07:48:21 2013] Ah, sorry [Wed Sep 11 07:48:53 2013] http://lpaste.net/92848 [Wed Sep 11 09:43:11 2013] is it just me or differences between small-step and big-step operational semantics are really not well-defined? [Wed Sep 11 10:58:16 2013] you? [Wed Sep 11 10:58:37 2013] that's a strange utterance for 30 minutes of silence. [Wed Sep 11 10:59:20 2013] AFAIU, big-step tells you under what conditions an expression reduces to a certain result, and small-step just tells you how an expression evolves step by step in its evaluation [Wed Sep 11 11:00:52 2013] but the line might be blurry sometimes? [Wed Sep 11 11:05:06 2013] It's not blurry. Big step semantics are passe since they don't define limiting behavior. [Wed Sep 11 11:06:44 2013] It doesn't really matter for strongly normalizing languages, but often you want to prove preservation properties for such languages, so you might as well use small-step semantics to begin with. [Wed Sep 11 11:08:48 2013] "such languages"? [Wed Sep 11 11:09:25 2013] proven strongly normalizing, like points on the lambda cube. [Wed Sep 11 11:12:13 2013] what is limiting behavior? [Wed Sep 11 11:14:51 2013] behavior of functions at their limits? [Wed Sep 11 11:14:55 2013] osa1: what happens to program evaluation when it's diverging/not terminating [Wed Sep 11 11:15:21 2013] they're different due to the difference between productivity and non-productivity. [Wed Sep 11 11:16:08 2013] You still might want to know if a term is growing without bound, say, instead of just spinning (like Omega). [Wed Sep 11 11:16:50 2013] ianjneu: is it possible to know if a term is growing without bound? [Wed Sep 11 11:17:13 2013] osa1: not in a big-step semantics, since it's just not defined. [Wed Sep 11 11:17:59 2013] You'd have to use a co-inductive big-step semantics, which pretty much duplicates the entire relation. It's really silly and unnecessary. [Wed Sep 11 11:18:43 2013] yeah and I don't know co-induction [Wed Sep 11 11:55:42 2013] <3 [Wed Sep 11 12:44:27 2013] can coq talk with ocaml? like an ffi? [Wed Sep 11 12:45:55 2013] ollehar: yes, it can. Via "Axiom"s. [Wed Sep 11 12:46:20 2013] ollehar: http://coq.inria.fr/refman/Reference-Manual025.html [Wed Sep 11 12:46:37 2013] gdsfh: thx [Wed Sep 11 12:48:40 2013] ollehar: the whole idea: you define axioms with right types (note that Prop erasure works both ways), then tell coq how to "extract" them, then use them in your coq code, and after extraction these axioms will be present as calls to some ocaml functions. it's very textual, sometimes it's subtle, sometimes it's great. [Wed Sep 11 12:49:46 2013] gdsfh: to be more concrete: I have a Lua library in OCaml. Can I make a wrapper module around it in Coq? [Wed Sep 11 12:50:21 2013] Or use the Lua module in Coq? [Wed Sep 11 12:55:39 2013] ollehar: you can. I've described the simplest way. But if the number of definitions you want to be present in coq is great, maybe it's worth to automatize the generation of "Axiom"s, at least partially. [Wed Sep 11 12:56:01 2013] Details can be found in manual (link's above) and by experimenting. I have a coq code that interacts heavily with ocaml code, and everything works fine, just look carefully at extraction's results until you'll understand how extraction works. [Wed Sep 11 12:56:38 2013] gdsfh: ok thanks, will read some more :) [Wed Sep 11 17:08:52 2013] I think I'll just ignore all proof automation stuff (try/repeat, auto etc.) because they look just too meaningless to me. how can I know that `auto` will work before manually writing the proof? and after writing the proof, what's the point of replacing it with auto? [Wed Sep 11 17:11:07 2013] osa1: Adam Chlipala's book Certified programming with dependent types has a fairly convincing exposition of the opposite point of view [Wed Sep 11 17:11:20 2013] (convincing to me, definitely a novice, anyway) [Wed Sep 11 17:11:57 2013] namely, that you should automate _all_ the trivial parts of your proofs so far as you can, leaving only the essentials (like 'induction') [Wed Sep 11 17:12:16 2013] because that way your proofs are robust against small changes in the shape of their hypotheses or changes in the implementation of Coq [Wed Sep 11 17:13:32 2013] ystael: oh my god I had started that book but left it after seeing the crush tactic [Wed Sep 11 17:13:38 2013] Proof Riemann_conjecture. auto. Qed. [Wed Sep 11 17:13:40 2013] well ... [Wed Sep 11 17:15:35 2013] I mean let's say auto/crush/whatever-mega-automation-tactic-you-like failed, how can you know if your theorem is not really a theorem or your automation tactic is simply not powerful enough? [Wed Sep 11 17:17:24 2013] osa1: hopefully they make progress as they fail [Wed Sep 11 17:17:56 2013] or if they don't make progress it's because there is a non-trivial decision to be made (or a need for a lemma) [Wed Sep 11 17:18:01 2013] I think part of the point is that you need to understand enough Ltac to know what crush (or your magical proof search of choice) is really doing [Wed Sep 11 17:18:14 2013] yeah I don't think you can use it as a black box [Wed Sep 11 17:18:28 2013] I audited that class when he gave it in 2009? (i think) and learned an awful lot about Ltac automation [Wed Sep 11 17:18:29 2013] since you have to help it [Wed Sep 11 17:18:32 2013] (which I have since forgotten :( ) [Wed Sep 11 17:18:39 2013] (for your own good? :D) [Wed Sep 11 17:18:45 2013] no, i had a baby :p [Wed Sep 11 17:18:59 2013] nothing that happened more than 48 hours ago exists any longer [Wed Sep 11 17:19:09 2013] :) [Wed Sep 11 17:20:05 2013] If you don't build proof search carefully then it leaves really obnoxious crap all over your context when it fails [Wed Sep 11 17:23:28 2013] osa1: Adam Chlipala's tutorial is focused more on code verification rather than on proving (imho), that's why the crush tactic [Wed Sep 11 17:24:06 2013] While following that tutorial, I didn't use crush at all and proved myself the parts he proved with crush. [Wed Sep 11 17:24:38 2013] as a hobbyist who self-studies all this, I prefer learning principles instead of automation stuff and magic. [Wed Sep 11 17:26:09 2013] yeah, me too :) So at some point I stopped reading Adam Chipilata's guide since I just couldn't understand some parts of proofs :) [Wed Sep 11 17:26:21 2013] try Pierce's "Software Foundations" [Wed Sep 11 17:26:44 2013] It is a lot more detailed [Wed Sep 11 17:26:55 2013] yeah I'm already doing that (in fact, I'm about to finish SF) [Wed Sep 11 17:27:31 2013] osa1: Even given that, I think some stuff (try, try solve, etc) is still useful [Wed Sep 11 17:27:44 2013] It makes it easier to write proofs or sections of proofs as ; chains instead of . chains [Wed Sep 11 17:28:06 2013] I don't think that's really too magic [Wed Sep 11 17:28:30 2013] ok thanks for the discussion .. I have to leave now [Wed Sep 11 17:35:16 2013] and thanks for the book tips ;) [Wed Sep 11 22:21:02 2013] we can have different proof objects for same theorem, right? [Thu Sep 12 01:51:42 2013] osa1: yes [Thu Sep 12 01:52:00 2013] Goal bool. exact true. Goal bool. exact false. [Thu Sep 12 13:03:01 2013] hi everyone! [Thu Sep 12 13:03:17 2013] I can't find how to do an "import qualified" in coq [Thu Sep 12 13:03:34 2013] i.e. give a short name to a module [Thu Sep 12 13:03:53 2013] ia0: Require A.B.LongName; Module M := LongName; [Thu Sep 12 13:03:55 2013] should do it [Thu Sep 12 13:04:15 2013] Thanks! [Thu Sep 12 13:05:25 2013] (it works) [Thu Sep 12 15:42:33 2013] anyone know of a simple example showing operational semantics for left-to-right evaluation of arguments to n-ary functions? [Thu Sep 12 15:42:46 2013] i don't mean in coq, just a written example [Thu Sep 12 15:42:56 2013] small step [Thu Sep 12 15:43:32 2013] i'm attempting to formalize a small language i've been working on, i'd like to see how other authors have documented [Thu Sep 12 15:43:57 2013] rmk0 did you look the boof "software foundations" of B. C. Pierce online ? There is such a sample in it [Thu Sep 12 15:45:04 2013] Anarchos: i'm familar with the book... i don't remember that being in there. will check again! [Thu Sep 12 15:45:15 2013] it was near the end [Thu Sep 12 15:45:25 2013] you can look at compcert too [Thu Sep 12 15:45:59 2013] does it use left-to-right evaluation for C? [Thu Sep 12 15:53:28 2013] can't seem to find n-ary functions in SF... [Thu Sep 12 23:39:12 2013] do we have any other alternatives to defining operational semantics as logical relations? [Thu Sep 12 23:40:20 2013] probably not. I was trying to ask for different kind of relations than explained in SF book ... [Thu Sep 12 23:40:44 2013] actually what I'm really asking is probably that what are alternative models for programming languages that can be applied in Coq environment .... [Thu Sep 12 23:40:58 2013] maybe I should go sleep [Fri Sep 13 09:25:45 2013] how to generate glob files for coqdoc ? [Fri Sep 13 09:42:45 2013] how to place links to arbitrary html pages in coqdoc? [Fri Sep 13 09:52:18 2013] anyone? [Fri Sep 13 10:42:52 2013] how is notations in software foundations book translated to symbols in html documents? like ||, ->, =>, <-> etc. [Fri Sep 13 10:48:27 2013] (** printing ~ ~ *) [Fri Sep 13 10:48:51 2013] you can add these kinds of comments in the source code to display some constructs using utf8 [Fri Sep 13 10:49:38 2013] gallais: can you give me a concrete example? let's say I want to print '||' as that fat down arrow like in SF book [Fri Sep 13 10:59:32 2013] http://lpaste.net/92946 [Fri Sep 13 10:59:52 2013] the relevant part of the manual: http://coq.inria.fr/V8.2pl1/refman/Reference-Manual018.html [Fri Sep 13 11:00:55 2013] how to test strings for equality? [Fri Sep 13 11:01:01 2013] gallais: thanks, looking now [Fri Sep 13 11:02:15 2013] gallais: your lpaste code doesn't work for me. it prints vv in the code [Fri Sep 13 11:07:20 2013] can't find string_eq_bool in standard library [Fri Sep 13 11:28:29 2013] osa1: are you looking for Coq.Strings.String.string_dec ? [Fri Sep 13 11:31:40 2013] ystael: just saw that but didn't understand how does that work [Fri Sep 13 11:35:12 2013] osa1: The return type of string_dec is a decidable equality proof: {s1 = s2} + {s1 <> s2} is a tagged disjoint union which you can pattern match to get either a proof of s1 = s2 or a proof of s1 <> s2 [Fri Sep 13 11:36:10 2013] ystael: yeah and how can I get a bool from that? (to be used in a if conditional) [Fri Sep 13 11:36:19 2013] also, where should I look for a division function? [Fri Sep 13 11:37:27 2013] replace the if with a pattern match: match (string_dec s1 s2) with | left _ => (truecode) | right _ => (falsecode) end [Fri Sep 13 11:38:22 2013] or you can put that pattern match into a function string_eq_bool and then use if on the result of that [Fri Sep 13 11:39:10 2013] ystael: wow ... this worked "if string_dec id' id then Some n else lookup rest id" [Fri Sep 13 11:39:12 2013] how can this work?? [Fri Sep 13 11:41:20 2013] ... oh, right, i forgot [Fri Sep 13 11:41:33 2013] 'if' is syntactic sugar for *any* pattern match on two-constructor datatypes with irrelevant arguments [Fri Sep 13 11:41:38 2013] see Coq reference manual sectino 2.2.2 [Fri Sep 13 11:41:57 2013] it works exactly the same on bool as on decidable equality types, if you don't care about the proof terms [Fri Sep 13 11:43:42 2013] where you should look for a division function depends on the number type you'er using [Fri Sep 13 11:44:21 2013] ystael: ok so we have decidable equality proof that says for every strings s1 and s2 we know they are either equal or not but for two particular strings how do we know whether or not they're equal? [Fri Sep 13 11:44:24 2013] ystael: nat [Fri Sep 13 11:46:52 2013] osa1: you apply string_dec to your particular strings. the type of string_dec is forall s1 s2 : string, {s1 = s2} + {s1 <> s2}, so the type of (string_dec mystring mystring') is {mystring = mystring'} + {mystring <> mystring'} [Fri Sep 13 11:47:17 2013] you pattern match on that (or use if) to get a proof of {mystring = mystring'} or a proof of {mystring <> mystring'} [Fri Sep 13 11:48:58 2013] ystael: about division, I have proof of my divisor <> 0, is there a function for me to divide two nats? [Fri Sep 13 11:49:19 2013] If the standard library has division for Peano naturals (the primitive 'nat') I don't know where it is [Fri Sep 13 11:49:43 2013] 16:36 < osa1> ystael: yeah and how can I get a bool from that? (to be used in a if conditional) [Fri Sep 13 11:49:57 2013] i think there's an implicit coercion from dec to bool [Fri Sep 13 11:52:01 2013] ok so what numeric type work for me? I have a proof of divisor <> 0 and I want to make division [Fri Sep 13 11:53:34 2013] you can _write_ division on nat, I just don't know whether it's in the standard library somewhere [Fri Sep 13 11:54:15 2013] Look through the standard library, you may try N from BinNat [Fri Sep 13 12:09:17 2013] hello. I am new to coq. I have the following problem. I have the goal "x R z" and the assumptions "x R y" and "y R z" and "transitive R". What tactic finishes the proof? [Fri Sep 13 12:30:58 2013] anders__: if you declared the transitivity of R as an instance of Transitive, 'transitivity y; assumption' should finish it [Fri Sep 13 12:31:28 2013] otherwise, you probably want to 'eapply ; eassumption.' [Fri Sep 13 12:32:06 2013] Ptival: what do you mean by "instance" ? do we have interfaces or typeclasses in Coq? [Fri Sep 13 12:35:32 2013] osa1: http://coq.inria.fr/V8.4pl2/refman/Reference-Manual022.html <- Typeclasses [Fri Sep 13 12:37:24 2013] Ptival: thanks! the latter approach worked. the relation R is transitive by virtue of being the transitive reflexive closure of another relation S, obtained by R := clos_refl_trans S. the transitivity is proved by clos_rt_is_preorder. how would I do to declare R as an instance of Transitive? [Fri Sep 13 12:47:09 2013] Another question: if I have "same_relation R S" how do I get "R = S" ? [Fri Sep 13 12:51:25 2013] anders__: this is not true [Fri Sep 13 12:51:39 2013] ok. why not? [Fri Sep 13 12:52:24 2013] Coq's notion of equality is not "extensional", meaning that the fact that two things behave exactly the same is not sufficient for them to be equal [Fri Sep 13 12:54:19 2013] oh god I'm searching through documentation for a function for divide ... I can use any numeric types can anyone help me? [Fri Sep 13 12:54:22 2013] for instance, "being an even number >= 0" and "being an even number >= 1" are two different relations intensionally, even though they are the same relation extensionally [Fri Sep 13 12:56:24 2013] osa1: there seems to be a Z.div in BinInt [Fri Sep 13 12:56:54 2013] is Z a module? [Fri Sep 13 12:57:16 2013] yes [Fri Sep 13 12:57:29 2013] I see. So then if I have "same_relation R S" how do I prove something true of R if I have that it is true of S? [Fri Sep 13 12:58:28 2013] same_relation R S := inclusion R S /\ inclusion S R [Fri Sep 13 12:58:37 2013] yes [Fri Sep 13 12:58:45 2013] inclusion A B := forall x y, A x y -> B x y [Fri Sep 13 12:59:16 2013] yes [Fri Sep 13 12:59:45 2013] so you can "apply (proj1 ) in ." to make a [Fri Sep 13 13:00:01 2013] so you can "apply (proj2 ) in ." to make a [Fri Sep 13 15:51:22 2013] oh wow [Fri Sep 13 15:51:32 2013] why is it broken now http://lpaste.net/92951 ? [Fri Sep 13 15:51:42 2013] oh right because I imported string library [Fri Sep 13 15:51:52 2013] is there a way to fix this without removing the lib [Fri Sep 13 16:18:43 2013] maybe put an Opaque string. somewhere? [Fri Sep 13 16:18:45 2013] not sure [Fri Sep 13 16:30:55 2013] osa1: maybe the problem is that string_scope is open so when you write a quoted string for the Case tactic it gets interpreted into string_scope? [Fri Sep 13 16:31:11 2013] maybe the problem is the open notation scope rather than the library itself? [Fri Sep 13 16:34:50 2013] yeah [Fri Sep 13 17:04:38 2013] ystael: probably. how can I close notation scope? [Fri Sep 13 17:07:28 2013] osa1: Close Scope string_scope [Fri Sep 13 17:07:39 2013] maybe then you will see a difference between "label" and "label"%string [Fri Sep 13 17:12:50 2013] ystael: after close_scope I'm getting "no interpretation for string" error [Fri Sep 13 17:15:39 2013] hm, that clearly wasn't the right thing to do then [Fri Sep 13 17:19:17 2013] osa1: I don't have much more insight to offer. I wonder if adding the String notation makes Ltac and Gallina 'argue' over who owns the interpretation of strings? [Fri Sep 13 17:19:39 2013] like when the "" string notation is there, "label" is parsed as a Gallina term, but when it's not there, it goes intact to Ltac and the Case tactic does what you expect [Fri Sep 13 17:19:49 2013] I'm just whistling in the dark here [Fri Sep 13 17:21:08 2013] seriously [Fri Sep 13 17:21:27 2013] how do people use Case tactics with string library imported [Fri Sep 13 17:21:52 2013] the answer may very well be "they don't" [Fri Sep 13 17:21:58 2013] not like Case is part of the standard library [Fri Sep 13 17:21:59 2013] yeah [Fri Sep 13 17:22:31 2013] maybe Case tactics aren't that much useful .. I find them very very useful when combined with some Ltacs to generate them automatically, [Fri Sep 13 17:22:45 2013] Software Foundations style [Fri Sep 13 17:24:02 2013] Have you tried something like "Local Close Scope string_scope."? [Fri Sep 13 17:24:14 2013] no. one sec. [Fri Sep 13 17:24:55 2013] jgross_: same error ("no interpretation for string") [Fri Sep 13 17:27:02 2013] Sorry, what code is this that you're having trouble with? [Fri Sep 13 17:29:33 2013] jgross_: just import String [Fri Sep 13 17:29:38 2013] and then use Case tactic [Fri Sep 13 17:32:55 2013] Can you paste the line of code you use to call "Case" and also the output of "Print Ltac Case."? (Also, see if "Local Open Scope string_scope." works (Open rather than Close) [Fri Sep 13 17:40:40 2013] hmm wait. I think I found a bug in my editor's coq plugin and it doesn't undo some commands. [Fri Sep 13 17:41:43 2013] ok yeah I reloaded my editor and now it works. [Sat Sep 14 02:17:49 2013] http://www.cis.upenn.edu/~bcpierce/sf/Prop.html -- I'm proving those theorems from additional exercises with "forall (X: Type) (l: list X)" instead of just "forall l". Is it right, or something is wrong with my palindrome definition? [Sat Sep 14 02:17:58 2013] was not able to state them without Type [Sat Sep 14 02:19:04 2013] like this: Inductive pal {X: Type} : list X -> Prop [Sat Sep 14 11:06:43 2013] defanor: no you are right, you need to pass the type of the list [Sat Sep 14 11:10:20 2013] thanks [Sat Sep 14 17:03:39 2013] my proofs look so bad it's depressing [Sat Sep 14 17:05:39 2013] what is that ... syntax? [Sat Sep 14 17:06:36 2013] I don't remember SF explaining that but suddenly it's used [Sat Sep 14 18:34:00 2013] osa1: if I understand your question correctly [Sat Sep 14 18:34:08 2013] you can do Proof with (some tactics). [Sat Sep 14 18:34:30 2013] and in the proof, every time you want to '; some tactics.' you can just '...' [Sat Sep 14 18:38:35 2013] Ptival: and how does that fill "some tactics" part ? [Sat Sep 14 23:17:49 2013] osa1: you have to write what you want there [Sat Sep 14 23:18:07 2013] it's basically a shortcut to call some tactics that will occur frequently during that proof [Sun Sep 15 19:32:36 2013] I'm reading Software Foundations and working through the examples. I am stuck on the mult_comm question, but I have a smaller question that I ran into when trying to figure out mult_comm. [Sun Sep 15 19:33:08 2013] I can't figure out how to prove something very simple, that forall n : nat, S n = n + 1. [Sun Sep 15 19:34:38 2013] I don't know very many tactics. Just simpl. reflexivity. rewrite. destruct. and induction. [Sun Sep 15 19:36:16 2013] I just don't see how this simply follows from the definition of S. [Sun Sep 15 19:36:39 2013] That was confusingly worded. It seems like this _does_ follow simply from the definition of S. [Sun Sep 15 19:37:14 2013] samg_: you should do induction on n. [Sun Sep 15 19:38:09 2013] samg_: http://lpaste.net/93034 [Sun Sep 15 19:39:06 2013] I got it :) [Sun Sep 15 19:39:40 2013] samg_: if you had defined + by the induction on the second argument, it would have been by the definition indeed [Sun Sep 15 19:40:22 2013] Interesting. I defined it by induction on the first argument. [Sun Sep 15 19:40:35 2013] yeah, it's usually on the first [Sun Sep 15 19:40:53 2013] If I have plus_comm, then, I should be able to prove this without induction? [Sun Sep 15 19:41:00 2013] Hold on, that was lazy. Let me try. [Sun Sep 15 19:41:24 2013] you should be able to prove forall n, S n = 1 + n without induction, this is indeed by the definition [Sun Sep 15 19:42:11 2013] Indeed. [Sun Sep 15 20:20:34 2013] Hmm... I'm stuck again. http://lpaste.net/93035 [Sun Sep 15 21:21:07 2013] Cool! I proved mult_comm :) [Sun Sep 15 21:21:29 2013] I'm sure it seems simple to you all, but it's taken me 2 days. [Sun Sep 15 21:47:19 2013] congratulations samg_ :) [Mon Sep 16 01:32:23 2013] I'm having trouble defining addition for a binary number representation, described in Software Foundations. [Mon Sep 16 01:32:26 2013] http://lpaste.net/93040 [Mon Sep 16 01:33:11 2013] The error is "Error: Cannot guess decreasing argument of fix." The book mentions this, and mentions that this might require me to write things in an unusual way. [Mon Sep 16 01:34:49 2013] Can someone help me understand why Coq can't guess the decreasing argument, so I might work around it? [Mon Sep 16 01:38:32 2013] Coq's termination checker is very simple. [Mon Sep 16 01:38:56 2013] It looks to see if there is some argument, for which it *always* gets smaller in the recursive call. [Mon Sep 16 01:39:12 2013] In your bin_plus, what argument is always decreasing? [Mon Sep 16 01:39:31 2013] It's not b, because in the Twice case it gets bigger: (bin_plus b' b') [Mon Sep 16 01:39:38 2013] Ah. I thought it was b, but now I see that it becomes bigger. [Mon Sep 16 01:39:50 2013] It's not c, because it always stays the same [Mon Sep 16 01:45:18 2013] That was just what I needed to know. I haven't proved it yet, but I got PG to accept my definition. :) [Mon Sep 16 02:19:52 2013] ezyang: ping? [Mon Sep 16 02:19:59 2013] pong [Mon Sep 16 02:20:17 2013] HiW? [Mon Sep 16 02:20:26 2013] yep ? [Mon Sep 16 02:20:51 2013] Ryan Newton said that he was going to post the program, so I think if you can get in touch with him it will go up [Mon Sep 16 02:21:08 2013] how long ago did he say that? [Mon Sep 16 02:21:13 2013] A while ago ^^ [Mon Sep 16 02:21:19 2013] weeks? [Mon Sep 16 02:21:33 2013] Aug 23 [Mon Sep 16 02:21:51 2013] hrm. [Mon Sep 16 02:22:00 2013] Though, I'm pretty sure we notified all the speakers [Mon Sep 16 02:22:09 2013] If you know who is speaking someone else from the PC should at least post the list of talks [Mon Sep 16 02:22:19 2013] OK, I'll go ahead and do that [Mon Sep 16 02:22:20 2013] otherwise attendees don't know what they're in for [Mon Sep 16 02:22:46 2013] you can just say "schedule yet to be determined", but still post the names of the speakers and talk titles [Mon Sep 16 02:22:52 2013] Yep, that's pretty reasonable [Mon Sep 16 02:22:55 2013] ok, thanks. [Mon Sep 16 02:27:28 2013] benl23: OK, done [Mon Sep 16 02:27:35 2013] I'll incrementally post the abstracts [Mon Sep 16 02:27:54 2013] ezyang: cool, thanks. [Mon Sep 16 02:27:58 2013] abstracts would also be good [Mon Sep 16 02:28:45 2013] Without abstracts you won't get a good turnout [Mon Sep 16 02:29:15 2013] gotcha [Mon Sep 16 02:38:27 2013] benl23: OK, all done. Thanks for poking! [Mon Sep 16 02:38:35 2013] :) [Mon Sep 16 02:39:22 2013] * sprinkles wiki magic to get the author names linkified... I wish [Mon Sep 16 02:43:37 2013] i'm stuck on palindrome_converse from http://www.cis.upenn.edu/~bcpierce/sf/Prop.html, need some advice. i have already proved that 'forall (X : Type) (x : X) (l : list X), pal (l ++ rev (snoc l x))' and 'forall (X : Type) (x : X) (l : list X), pal (l ++ [x] ++ rev l)', and googled the 'exists' tactic, but not sure if it's the right way ('exists' was not introduced in the book yet) [Mon Sep 16 02:47:38 2013] oh, the first one is not important. i've thoight about using a theorem from previous exercise (pal (l ++ rev l)) and the second one (pal (l ++ [x] ++ rev l)) [Mon Sep 16 02:48:53 2013] and googled 'exists' to prove that one of such lists exists for any l = rev l [Mon Sep 16 02:49:30 2013] but have trouble with that proof too. did not learned 'exists' and disjunction yet [Mon Sep 16 05:19:02 2013] having "match ... in T return (F T) with ...", what should I apply to (F T) to make it compute its result (normalize?); for example, if F T = R, I would like to be able to return r : R in each branch (instead of r : F T) [Mon Sep 16 18:21:59 2013] is there a case where inversion helps solving the proof but destruct combined with some other tactics cannot help? [Mon Sep 16 18:24:02 2013] osa1: destruct abstracts over concrete indices, forgetting their values [Mon Sep 16 18:24:12 2013] but you can sort of do inversion by using remember before [Mon Sep 16 18:24:19 2013] I believe [Mon Sep 16 18:24:55 2013] hmm [Mon Sep 16 18:25:18 2013] you can probably simulate inversion entirely with rememer, destruct, and something like discriminate [Mon Sep 16 18:25:56 2013] okay so what does "concrete indices" mean? [Mon Sep 16 18:26:20 2013] if you destruct an indexed type [Mon Sep 16 18:27:17 2013] by concrete I mean that there is at least a head constructor in an index [Mon Sep 16 18:27:20 2013] for instance [Mon Sep 16 18:27:34 2013] T : bool -> Type [Mon Sep 16 18:27:48 2013] b : bool, t : T b (* the index is not concrete *) [Mon Sep 16 18:27:57 2013] t : T true (* the index is concrete *) [Mon Sep 16 18:28:44 2013] if you destruct the latter, Coq will forget that the index was the concrete value 'true', and replace it with some unknown boolean [Mon Sep 16 18:29:39 2013] so sometimes you might lose information, or have spurious cases that don't even have type 'T true' [Mon Sep 16 18:30:12 2013] inversion will not generate such spurious cases, and will introduce equalities to save the information about partially-concrete indices [Mon Sep 16 18:30:26 2013] it looks like discriminate is building the kind of diagonal arguments Monin was advocating for in the "small inversion" paper (http://hal.archives-ouvertes.fr/docs/00/48/94/12/PDF/paper_1.pdf) [Mon Sep 16 18:36:27 2013] gallais: oh that's interesting, thanks [Mon Sep 16 20:26:51 2013] Ptival: after trying on a few examples I think I got it. thanks. [Mon Sep 16 20:27:06 2013] so is there a case that one should need to use destruct but inversion doesn't work? [Mon Sep 16 20:34:57 2013] I was going to say no, but I seem to remember problems with dependent types where inversion is ill-typed but destruction is fine (well, it's fine but it loses information) [Mon Sep 16 20:35:57 2013] hmm [Mon Sep 16 20:36:06 2013] http://lpaste.net/93071 how to do this* [Mon Sep 16 20:36:55 2013] ahhhhh [Mon Sep 16 20:36:56 2013] sorry [Mon Sep 16 20:37:07 2013] nevermind. please forget my last question :p [Tue Sep 17 10:33:55 2013] what's special about this type: forall P . (P -> P) -> P ? [Tue Sep 17 10:35:00 2013] it's the type of fix? [Tue Sep 17 10:35:32 2013] hm [Tue Sep 17 10:44:42 2013] I'm reading some papers about dependent types and I'm confused -- let's say we allow general recursion on type level but never write non-terminating type level expressions. does that still make our type system unsound or broken in some other sense? [Tue Sep 17 10:52:09 2013] that's kind of what systems with termination checking do, ensure you only write stuff with a normal form even if the grammar/types allow unrestricted recursion [Tue Sep 17 10:52:22 2013] and it seems to be fine [Tue Sep 17 10:52:50 2013] oh, but i guess you want to allow non-terminating stuff at the value level? [Tue Sep 17 10:52:55 2013] then you can prove false [Tue Sep 17 10:54:41 2013] yeah .. then how does Agda handle this? does that allow type level general recursion but no term level general recursion? [Tue Sep 17 10:55:28 2013] osa1: Agda does not allow general recursion. It just has a more powerful termination checker than Coq [Tue Sep 17 10:55:52 2013] which is still pretty weak when compared to Vroon and Manolios' stuff. [Tue Sep 17 10:56:03 2013] But theirs is for a first-order language. [Tue Sep 17 10:56:40 2013] osa1: agda has some flags to make it accept programs which the termination checker doesn't approve of, but you do that at your own risk [Tue Sep 17 10:56:46 2013] ianjneu: can we have that kind of more powerful termination checker in Coq without giving up soundness of our system? [Tue Sep 17 10:57:03 2013] Saizan: and in that case does that mean I can prove false? [Tue Sep 17 10:57:12 2013] osa1: yep [Tue Sep 17 10:57:20 2013] hmm [Tue Sep 17 10:58:00 2013] Termination checkers can always be more powerful, by the full employment theorem. [Tue Sep 17 10:58:39 2013] okay so I don't really understand how can non-terminating program prove falsity. I mean I understand how can I do that in programming languages but what I don't really understand is "what does it actually mean" or what are consequences of this [Tue Sep 17 10:58:48 2013] the termination checker is run over everything, btw, doesn't matter if type or value level (the distinction often depends on context anyway) [Tue Sep 17 10:58:58 2013] ianjneu: is there a theorem like that :-D [Tue Sep 17 10:59:06 2013] define f(x) = not f(x) [Tue Sep 17 10:59:26 2013] like in "full employement for PL designers" [Tue Sep 17 10:59:37 2013] osa1: if you have fix : forall P . (P -> P) -> P, then fix id : forall P. P which lets you prove anything [Tue Sep 17 10:59:41 2013] including False [Tue Sep 17 11:00:00 2013] osa1: full employment theorems exist for any realm that is trying to carve out decidable subsets of undecidable problems. [Tue Sep 17 11:00:03 2013] Saizan: I know this stuff... I think I couldn't express myself [Tue Sep 17 11:00:10 2013] fix id doesn't have a normal form though [Tue Sep 17 11:01:03 2013] osa1: oh, i guess the missing link is that there's no closed normal form which has the type "False" so no closed term of that type can have a normal form [Tue Sep 17 11:01:11 2013] hence they must be non-terminating [Tue Sep 17 11:01:30 2013] wow [Tue Sep 17 11:01:38 2013] Due to the full employment theorem for logicians, there will never be a best logic to work in. Type theorists cannot claim to have described, "all of math" because math includes the informal boundary-pushing for better logics. [Tue Sep 17 11:02:14 2013] Saizan: that's really a good insight and will probably help me get a better understanding after some thinking [Tue Sep 17 11:10:16 2013] so about my early questions: is it sensible to allow non-terminating programs in type level but disallow them in term level? I mean does such a sentence even make sense? because as far as I can understand type and term level distinction are really blurry in dependently typed PLs so I though maybe there is no distinction at all [Tue Sep 17 11:18:25 2013] is there such a thing like "running a Coq program" or all we can do is to type check them? [Tue Sep 17 11:19:03 2013] if you allow me to define and use D : Set; D = D -> D; i can embed the untyped lambda calculus [Tue Sep 17 11:19:18 2013] osa1: yeah, in fact if you can't run coq programs you can't typecheck them [Tue Sep 17 11:19:28 2013] osa1: Compute allows you to get normal forms, and you can also extract Coq programs into OCaml, and to some extent Haskell and Scheme. [Tue Sep 17 11:19:46 2013] well, i mean typechecking a program is probably going to involve running of other programs [Tue Sep 17 11:21:34 2013] " D : Set; D = D -> D;" what syntax is that? how does this work? [Tue Sep 17 11:21:57 2013] that's Agda, sorry [Tue Sep 17 11:22:22 2013] is there a Coq equivalent :-) [Tue Sep 17 11:22:38 2013] i guess in Coq it'd be "Definition D : Type := D -> D;" ? [Tue Sep 17 11:23:38 2013] osa1: anyhow i think you might be interested in the trelly project [Tue Sep 17 11:24:30 2013] Saizan: this https://code.google.com/p/trellys/ ? [Tue Sep 17 11:24:39 2013] osa1: from what i've heard they aim to have a good story to handle not-necessarily-terminating definitions while keeping consistency, i guess they have some way to restrict their use [Tue Sep 17 11:24:53 2013] osa1: yep! [Tue Sep 17 11:26:22 2013] there are some publications on it [Tue Sep 17 11:26:31 2013] now I wonder what is Idris' position in this terminating/non-terminating discussion because it claims to be _practical_ so I guess it needs to have some way of implementing general recursion while keeping the system sound? [Tue Sep 17 11:26:46 2013] Saizan: that definitely looks interesting. thanks. [Tue Sep 17 11:29:13 2013] osa1: Idris is not that far from Agda, i guess it has 3 levels: total, partial, asserted total [Tue Sep 17 11:29:59 2013] partial stuff is not unfolded at typechecking but it's still there, if you want to be sure a proof is valid you have to require it to be total [Tue Sep 17 11:30:21 2013] asserted total is when you think you know better than the checker and override it [Tue Sep 17 11:34:24 2013] are total and terminating same things? [Tue Sep 17 11:37:30 2013] well, terminating is more operational i guess, while total is more denotational and in general use total is more likely to cover the coinductive case [Tue Sep 17 11:38:35 2013] where can I learn more about coinduction? [Tue Sep 17 11:41:13 2013] good question, i don't really know though [Tue Sep 17 11:41:25 2013] osa1: http://adam.chlipala.net/cpdt/html/Coinductive.html [Tue Sep 17 11:58:03 2013] sorry for repetition, but i'm stuck on palindrome_converse exercise from http://www.cis.upenn.edu/~bcpierce/sf/Prop.html and need some hint/advice about it [Tue Sep 17 12:10:32 2013] defanor_: if you show how far you got it'll be easier to give hints, i think [Tue Sep 17 12:14:05 2013] Saizan: i've just proved some lemmas, but they are probably useless: http://coq.xelpaste.org/8258 [Tue Sep 17 12:14:49 2013] had a lot of attempts, but erased them yesterday [Tue Sep 17 12:18:37 2013] http://coq.xelpaste.org/8259 -- here they are, from the undo history, but it's a mess there. and i can't say for sure which of those tries is further, cause all of them could be wrong [Tue Sep 17 12:20:12 2013] the definition of pal would also help I think, though i'm no Coq programmer myself [Tue Sep 17 12:22:17 2013] oh, right, here it is: http://coq.xelpaste.org/8260 [Tue Sep 17 12:46:26 2013] i think you might want to strengthen your induction to forall xs l, xs ++ l = rev l ++ rev xs -> pal l. so that recursive calls are easier, but no guarantees :) [Tue Sep 17 12:46:40 2013] rev is such an annoying function [Tue Sep 17 12:48:01 2013] thanks, i'll try [Tue Sep 17 14:48:35 2013] Saizan: it worked, yay! [Tue Sep 17 16:39:40 2013] I have made a tactic, and on this particular term it will always produce the same result (which can be simplified to the original term). When I do "repeat mytactic." It seems to stop after ~2 iterations. How come? [Tue Sep 17 16:41:15 2013] Does it somehow check if it is repeating on an identical term and then stop? [Tue Sep 17 16:41:35 2013] I expected an infinite loop :) [Tue Sep 17 16:54:55 2013] reynir: you may be interested in the "progress" tactic, see the reference manual (and look "repeat" too). [Tue Sep 17 16:55:33 2013] http://coq.inria.fr/refman/Reference-Manual011.html#hevea_tactic181 [Tue Sep 17 16:56:06 2013] http://coq.inria.fr/refman/Reference-Manual011.html#hevea_tactic179 [Tue Sep 17 17:04:21 2013] Zedrikov: It's not clear to me from the documentation that repeat should stop in that case [Tue Sep 17 17:04:35 2013] Thanks for the pointer to progress! [Tue Sep 17 17:05:17 2013] yeah there's a tactic that never fails but stops when 'repeat'ed [Tue Sep 17 17:05:34 2013] which is, while weird, guiltily practical [Tue Sep 17 17:09:34 2013] It isn't possible to prove [zeroes = Cons 0 zeroes] where zeroes is the infinite stream of zeroes, right? [Tue Sep 17 17:37:26 2013] reynir: Do you mean with coinductives ? [Tue Sep 17 17:38:16 2013] If so, yes, as far as I know it is not possible without additionnal axioms. [Tue Sep 17 17:39:08 2013] And in inductive cases, you cannot define 'zeroes'. [Tue Sep 17 17:41:49 2013] The idea of the reason you cannot do it is that you cannot reason by induction (since the type is not finite), and you cannot reason by coinduction (since a cofixpoint must produce a coinductive and "eq" is inductive). [Tue Sep 17 17:42:14 2013] Setting eq as coinductive won't work either. [Tue Sep 17 17:44:20 2013] Yea, thanks [Tue Sep 17 17:44:23 2013] But still you can define something like "CoInductive eq_stream (A : Type) (x y : stream A) : Prop := EqCons : head x = head y → eq_stream A (tail x) (tail y) → eq_stream A x y." [Tue Sep 17 17:44:34 2013] Yea I know [Tue Sep 17 17:44:39 2013] And in this situation you can prove your equality. [Tue Sep 17 17:44:58 2013] (well eq_stream equality in fact) [Tue Sep 17 19:44:03 2013] reynir: another argument why it's not provable, [zeroes] and [Cons 0 zeroes] are both closed terms, hence [zeroes = Cons 0 zeroes] is provable iff [refl : zeroes = Cons 0 zeroes], and since [zeroes] and [Cons 0 zeroes] are not convertable, that's not going to happen. [Tue Sep 17 20:01:41 2013] Hmm, you can actually prove that, see http://lpaste.net/93106. The weird thing however, if you normalize the proof, it's indeed a refl (which is AFAIK impossible). [Tue Sep 17 20:01:50 2013] But if you recheck the normalized proof, it will fail [Tue Sep 17 20:02:02 2013] does this have to do with the failure of subject reduction due to coinductive types? [Tue Sep 17 20:02:12 2013] or am I too sleepy to see what's actually going on [Tue Sep 17 20:48:40 2013] reading Georges Gonthier's message here: http://permalink.gmane.org/gmane.science.mathematics.logic.coq.club/3608 [Tue Sep 17 20:49:11 2013] I guess my problem is related, it's also due to cofix expansions in dependent pattern matches [Tue Sep 17 20:50:16 2013] So, this means that the reasoning I used above to show that something is not provable, does not work when dealing with coinductive types (because of the failure of subject reduction) [Wed Sep 18 08:41:27 2013] I don't think I fully understand notation scope [Wed Sep 18 09:34:42 2013] Emacs coq-mode / proofgeneral question: Is there a keybinding to toggle "Ltac Debug"? [Wed Sep 18 11:49:54 2013] hi all. more questions related with yesterday's discussion: let's say my system allows general recursion in program level but I'm always running the proofs. does that still make my system unsound? because for instance this proof: forall a. a will never terminate and thus is not a valid proof in my system. or is there value with type 'forall a. a' that [Wed Sep 18 11:49:54 2013] terminates? [Wed Sep 18 11:59:45 2013] usually the problems comes from proofs of implications [Wed Sep 18 12:01:15 2013] how? [Wed Sep 18 12:02:36 2013] because in some cases i can make a proof f of X -> Y that has a normal form but for some x : X you get that (f x) is non-terminating [Wed Sep 18 12:03:15 2013] so in a sense you can't ever trust proofs of implication, you can only verify each application of them [Wed Sep 18 12:03:52 2013] though i guess that might not be enough to make your system unsound, tbf [Wed Sep 18 12:04:22 2013] it will still be inconsistent, but it won't just do random things [Wed Sep 18 12:04:59 2013] that's pretty much the situation Haskell is in [Wed Sep 18 12:07:22 2013] I don't understand this argument. if x is not terminating that it's not a valid prof. [Wed Sep 18 12:07:26 2013] proof* [Wed Sep 18 12:07:37 2013] so it cannot be used for implications [Wed Sep 18 12:08:07 2013] x is terminating [Wed Sep 18 12:08:11 2013] but (f x) isn't [Wed Sep 18 12:08:42 2013] ahh so f x is not terminating for some x but terminating for other x [Wed Sep 18 12:09:06 2013] right, but also 'f' itself as an expression might be terminating [Wed Sep 18 12:09:52 2013] which is the only thing you can realistically check by reduction, the domain of f might be infinite [Wed Sep 18 12:10:40 2013] hmm [Wed Sep 18 12:11:48 2013] okay so what happens if I just ignore non-terminating f x and count terminating f x as valid proofs? [Wed Sep 18 12:14:40 2013] i was assuming you'd do that [Wed Sep 18 12:15:55 2013] my point was: would a f like the above be a valid proof of X -> Y? and if not how do you tell it apart from valid ones? [Wed Sep 18 12:16:47 2013] what is source of inconsistency here? is it because type of f is `forall (P : X -> Prop)` but for some x : X it doesn't give us a proof so that `forall` is somewhat ... wrong? [Wed Sep 18 12:16:52 2013] though i must say i haven't worked out the details of this stuff, so there might be room for a positive resolution [Wed Sep 18 12:17:50 2013] osa1: yeah [Wed Sep 18 12:18:42 2013] osa1: which i guess is not exactly like saying "you can derive False" but it's still worrying [Wed Sep 18 12:20:30 2013] yeah. ok so let's say I find a way to mimic dependent types in Haskell, what features of Haskell prevents it from being a proof assistant? (other than the termination stuff we just talked) [Wed Sep 18 12:25:29 2013] osa1: if you make it consistent then i guess it'd just need some tool support or language feature to make proofs easier [Wed Sep 18 12:28:32 2013] (though I'm not sure if there's a way to mimic Coq's 'forall' syntax in Haskell's function types -- I think this types are called 'pi' types or something like that) [Wed Sep 18 12:30:52 2013] you can mimic _some_ dependent types through singleton types, SHE by McBride had some preprocessing on that vein [Wed Sep 18 12:31:12 2013] i wonder if haskell has an 'f' like i described above [Wed Sep 18 12:43:02 2013] Saizan: f = \case -> { 0 -> f 0; n -> n } ? [Wed Sep 18 12:44:48 2013] ops that first arrow should not be there: \case { ... } [Wed Sep 18 12:47:35 2013] f 0 = f 0; f n = n [Wed Sep 18 12:58:25 2013] is there a reason to not to use inversion and use destruct instead? [Wed Sep 18 13:00:45 2013] speed & memory I imagine. [Wed Sep 18 13:01:41 2013] okay so can we say that inversion is strictly more powerful that destruct? e.g. if I can prove with destruct I can also prove with inversion? [Wed Sep 18 13:03:18 2013] s/that/than [Wed Sep 18 13:07:59 2013] well, as I said yesterday, my intuition would tell me "yes", but in practice I believe some problems are ok to destruct, but somehow ill-typed by inversion [Wed Sep 18 13:08:14 2013] second Ptival [Wed Sep 18 13:08:18 2013] so you'd have to do a dependent inversion [Wed Sep 18 13:09:02 2013] dependent inversion ought to be strictly more powerful than destruct [Wed Sep 18 13:09:20 2013] but maybe I'm ignoring some issues :) [Wed Sep 18 13:09:34 2013] uh. never heard "dependent inversion" before. [Wed Sep 18 13:11:09 2013] it's similar to inversion but you can specify a return annotation [Wed Sep 18 13:15:41 2013] coq doesn't have axiom K by default, right? but it is considered to have "dependent pattern matching"? [Wed Sep 18 13:18:24 2013] chris2: dependent pattern matching is the application of a type's induction principle, which needs a motive, whereas regular pattern matching uses the recursion principle, which doesn't. [Wed Sep 18 13:19:11 2013] Agda's monopoly of the term dependent pattern matching meaning the assumption of UIP is just an accident of history. [Wed Sep 18 13:19:30 2013] ok :) [Wed Sep 18 13:19:42 2013] what is UIP? [Wed Sep 18 13:20:06 2013] uniqueness of identity proofs <-> Axiom K [Wed Sep 18 13:21:07 2013] Homotopy type theory showed us that UIP is the assertion that all types are sets, whereas they allow types to be infinity-groupoids. [Wed Sep 18 13:21:16 2013] yes [Wed Sep 18 13:21:27 2013] i'm interested in using "pattern matching" in such a context [Wed Sep 18 13:21:40 2013] so, coq's match can be supported by J alone? [Wed Sep 18 13:22:08 2013] I believe so. [Wed Sep 18 13:22:29 2013] Well, J is only for Id proofs, but I know what you're getting at. [Wed Sep 18 13:22:43 2013] okay [Wed Sep 18 13:23:19 2013] but that means it doesnt work like coquands 1992 paper? [Wed Sep 18 13:23:43 2013] The HoTT formalization in Coq only had to change the internals to fix the handling of universes and not elimination. [Wed Sep 18 13:24:17 2013] chris2: I'm not as well versed in historical literature as I'd like. Elaborate? [Wed Sep 18 13:24:24 2013] http://www.cse.chalmers.se/~coquand/pattern.ps [Wed Sep 18 13:24:35 2013] this is cited by the agda people often :P [Wed Sep 18 13:24:50 2013] brb, groceries [Wed Sep 18 13:25:30 2013] mumble. I was looking for a summary. I'm working on a paper due tonight. [Wed Sep 18 13:47:20 2013] ianjneu: well, the dependent pattern matching explained there implies axiom k. and http://www.qatar.cmu.edu/~sacchini/papers/types08.pdf shows how to extend coq's pattern matching to imply it as well [Wed Sep 18 13:51:52 2013] I just approach pattern matching as a notational convenience for applying induction or recursion principles. [Wed Sep 18 13:52:04 2013] yes [Wed Sep 18 13:52:23 2013] from my non-dependent background, i thought it was mostly syntax :) [Wed Sep 18 13:52:52 2013] i'll read these papers more closely to figure out the "benefit" [Wed Sep 18 13:54:10 2013] type theorists have been mostly confused about how this all works, and most stuff leading to HoTT is just messy and gross. [Wed Sep 18 13:54:53 2013] :) [Wed Sep 18 13:55:03 2013] it certainly changed assumptions of what people want [Wed Sep 18 13:55:17 2013] and i think exploring HIT will do that even more [Wed Sep 18 13:55:26 2013] HIT? [Wed Sep 18 13:55:37 2013] higher inductive types [Wed Sep 18 13:55:37 2013] derp, nm [Wed Sep 18 13:56:41 2013] Dan Licata has felt a lot of pain trying to write HoTT proofs in Agda, since path induction is eeeeverywhere, heh. [Wed Sep 18 13:56:58 2013] yep [Wed Sep 18 13:58:09 2013] you follow him on twitter? [Wed Sep 18 13:58:39 2013] not yet [Wed Sep 18 14:01:50 2013] his fall 2013 class sounds interesting as well [Wed Sep 18 14:02:04 2013] meh, material is not public [Wed Sep 18 14:06:17 2013] did you go to OPLSS? [Wed Sep 18 14:06:21 2013] no [Wed Sep 18 14:07:16 2013] well he has lectures there and supporting material (protected by password, but I think it's oplss2013/ducks if not, stated in one of the lecture videos) [Wed Sep 18 14:07:29 2013] ok [Wed Sep 18 14:07:36 2013] thanks [Wed Sep 18 14:09:40 2013] doesn't seem to work here :\ [Wed Sep 18 14:11:28 2013] oplss/duck [Wed Sep 18 14:11:34 2013] just tried. [Wed Sep 18 14:11:36 2013] thx [Wed Sep 18 15:03:11 2013] ianjneu: can I also have the link for lectures and extra materials? [Wed Sep 18 15:05:32 2013] 1: http://www.cs.cmu.edu/~drl/teaching/oplss13/ [Wed Sep 18 15:05:48 2013] 2: http://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html [Wed Sep 18 15:24:55 2013] uh "and in reality many programming languages are given “big step” (coinductive) semantics" how is big step operational semantics and coinduction related? [Wed Sep 18 15:25:04 2013] (from this post http://www.cs.umd.edu/~micinski/posts/2012-09-04-on-understanding-coinduction.html) [Wed Sep 18 15:27:14 2013] Coinduction is needed to talk about non-terminating reduction sequences. It's really a terrible hack. Small-step semantics are much better to use for just about anything that isn't a toy. [Wed Sep 18 15:28:14 2013] ianjneu: do you know an example where coinduction is used in a big step definition? [Wed Sep 18 15:30:31 2013] Yes. The Principles of Program Analysis monograph by Nielson Nielson and Hankin define their languages with big-step semantics with an "acceptability" relation for their analyses, all defined with coinduction, but some of their proofs make a detour through small-step semantics. It's messy garbage. [Wed Sep 18 15:31:06 2013] You're better off with Felleison's reduction semantics style. [Wed Sep 18 15:32:10 2013] Felleison's reduction semantics? is that small-step SOS ? [Wed Sep 18 15:32:55 2013] It's like SOS, but you can reason contextually nicely, so control operators are easily expressed with evaluation contexts. [Wed Sep 18 15:33:33 2013] so it has a nice way to describe call/cc ? [Wed Sep 18 15:33:48 2013] E[(reset F[(shift k e)])] |-> E[e{k := (lambda (x) F[x])}] [Wed Sep 18 15:34:03 2013] (where F contains no resets) [Wed Sep 18 15:35:24 2013] call/cc is easier: E[(call/cc (lambda (k) e))] |-> e{k := E}, E[(E' v)] |-> E'[v] [Wed Sep 18 15:35:35 2013] osa1 what means the cc in call/cc ? [Wed Sep 18 15:35:42 2013] current-continuation [Wed Sep 18 15:36:05 2013] ianjneu thx [Wed Sep 18 15:36:36 2013] miss-typed, e{k := (cont E)} and E[((cont E') v)] |-> E'[v] [Wed Sep 18 15:37:14 2013] gotta wrap it to make it a value rather than say it's adding extra holes to the evaluation context. [Wed Sep 18 15:37:36 2013] Check out Semantics Engineering in PLT Redex [Wed Sep 18 15:41:01 2013] The classic call/cc is too overpowered. It needs to be delimited so that a program can't capture context it doesn't have the capability to capture. [Wed Sep 18 15:42:13 2013] shift/reset are delimited continuations, yes, but they are also composable. There are use cases where (delimited) non-composable continuations ala call/cc with prompt-tags is the right solution. [Wed Sep 18 15:43:05 2013] "Adding delimited and composable control to a production programming environment": http://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf [Wed Sep 18 15:43:23 2013] thanks for the paper suggestions [Wed Sep 18 15:45:05 2013] * spotted an eye-catcher : production programming environment [Wed Sep 18 15:45:41 2013] Anarchos: PLT Scheme, now called Racket. [Wed Sep 18 15:46:31 2013] They don't believe in doing PL work that isn't readily useful for actually doing some programming, as opposed to some more math-types that hang around here, heh. [Wed Sep 18 15:50:48 2013] any ideas on where to find online or printed version of Coq'Art book? [Wed Sep 18 15:51:44 2013] University library? [Wed Sep 18 15:53:37 2013] osa1 i had it but in french [Wed Sep 18 15:53:56 2013] It's pretty outdated. I would stick to software foundations and CPDT [Wed Sep 18 15:54:33 2013] SF is fine [Wed Sep 18 15:54:35 2013] and robbert krebbers. He hangs out here and knows about even the undocumented stuff. [Wed Sep 18 15:54:38 2013] CPDT is a bit more advanced [Wed Sep 18 17:04:41 2013] I have a goal [Some a = Some b]. How do I reduce it to [a = b]? I forget [Wed Sep 18 17:09:13 2013] f_equal [Wed Sep 18 17:10:26 2013] reynir induction. [Wed Sep 18 17:14:33 2013] Thank you ianjneu [Wed Sep 18 17:47:54 2013] I'm having trouble to understand how can anything be provable on coinductive definitions ... [Wed Sep 18 17:50:50 2013] also, do we have a name for kind of functions that allow us to write filter function on streams? like the primitive/general recursion distinction? [Wed Sep 18 18:03:06 2013] what is disturbing your understanding? [Wed Sep 18 18:05:28 2013] basically I don't understand anything about reasoning on infinite data ... how can we prove that map S zeroes = ones (where zeroes = infinite stream of zeroes etc.) [Wed Sep 18 18:07:14 2013] and also how what does equality in this proposition mean [Wed Sep 18 18:12:35 2013] A productive coinductive definition (always builds) is dual to a well-founded recursive definition (always decreases structure). [Wed Sep 18 18:13:24 2013] If there's no way to refute something in finite time, it might as well be true. [Wed Sep 18 18:14:30 2013] osa1 get a look at Büchi automaton [Wed Sep 18 18:47:35 2013] ianjneu: does same reasoning work for the other case? like "if there's no way to prove something in finite time, it might be false" ? [Wed Sep 18 18:49:19 2013] well then it is "not provable", which has little to do with truth and falsity [Wed Sep 18 18:55:07 2013] Ptival: can't we use "not provable" in the sense of "might be false" [Wed Sep 18 18:57:05 2013] also I don't understand relation with büchi automaton [Wed Sep 18 19:14:17 2013] Something which is not provable also might be true, at least, if its negation also isn't provable. [Wed Sep 18 19:22:28 2013] osa1: that result is just not provable. Instead of using Leibniz equality to talk about equality of streams, you should use use bisimilarity (which is defined coinductively) [Wed Sep 18 19:22:42 2013] then you can prove such "equalities" using a cofix [Wed Sep 18 19:23:04 2013] or the coinduction principle (which can easily be derived), but that's probably more useful for more involved stream equality proofs [Wed Sep 18 19:23:22 2013] reads the Coq'Art or CPDT chapter on coinduction :) [Wed Sep 18 19:23:25 2013] *read [Wed Sep 18 19:24:51 2013] osa1: by Goedel we know that all logics which can at least express arithmetic are incomplete, so there are statements P which are not provable, neither its negation ~P [Wed Sep 18 19:25:23 2013] and Coq is "very incomplete" (whatever that may mean formally :P) due to its intensional and constructive nature [Wed Sep 18 19:26:38 2013] In particular, in Coq many equalities are not provable due to the lack of functional extensionality, proof irrelevance, prop irrelevance, ... [Wed Sep 18 19:30:12 2013] robbert: I already read CPDT cofix chapter before asking here .. what's not explained in CPDT chapter how can coinductive proofs give use confidence on truth. [Wed Sep 18 19:31:02 2013] robbert: well we have proof relevance here http://coq.inria.fr/stdlib/Coq.Logic.ProofIrrelevance.html doesn't that help? also I remember SF book defining an exiom for functional extensionality and saying that this doesn't break Coq's logical foundations [Wed Sep 18 19:32:02 2013] osa1: well, your original question was about proving "map S zeroes = ones", that's literaly in CPDT [Wed Sep 18 19:32:27 2013] how do coinductive proofs give you confidence, well, I guess by believing that the metatheory of Coq is consistent [Wed Sep 18 19:32:30 2013] robbert: what I meant there was how can that proof give us confidence of truth because it's completely nonsense to me [Wed Sep 18 19:32:55 2013] you mean the proof, or the fact that he uses stream_eq instead of eq? [Wed Sep 18 19:33:13 2013] (let me check the proof again) [Wed Sep 18 19:33:23 2013] because the idea of using a proof assistant, is that you do not have to "trust the proof" to get confidence [Wed Sep 18 19:33:38 2013] you need to trust that the statement is indeed the thing what you want, and that the system is consistent [Wed Sep 18 19:34:49 2013] osa1: proof irrelevance there is an axiom, it's not provable in Coq [Wed Sep 18 19:34:51 2013] robbert: ok let me express myself this way: if I explain someone inductively defined data types and then proofs by induction I think that stuff make sense for most people. now I'm looking for a way to explain coinductive data types and coinduction but to explain myself [Wed Sep 18 19:36:02 2013] I'm not looking for Coq or proof assistant or constructive logic specific answers here [Wed Sep 18 19:36:41 2013] well, coinduction is basically dual to induction, so many things are the other way arround [Wed Sep 18 19:37:08 2013] since you construct infinite objects, you do not have that definitions (and thus by Curry-Howard) proofs should be terminating. Rather you want them to be productive [Wed Sep 18 19:37:23 2013] that intuitively means, they will always indeed produce something infinite [Wed Sep 18 19:37:38 2013] hence, the not guarded errors if you try to do proofs by cofix [Wed Sep 18 19:39:49 2013] osa1: if you want to understand the mathematics of coinductive types in a non Coq specific way, you may want to read something like http://www.cs.ru.nl/~bart/PAPERS/JR.pdf [Wed Sep 18 19:40:39 2013] yeah I have that paper on my to-do list. maybe I should give that greater priority [Wed Sep 18 19:41:40 2013] or, if you are interested in the programming side of things, you may want to read some tuturial on dealing with infinite data in Haskell [Wed Sep 18 19:42:49 2013] but I must agree, coinductive types in Coq are a bit obscure... [Wed Sep 18 19:43:05 2013] so, it's not very strange that you are confused about it :) [Wed Sep 18 19:50:18 2013] someone should edit this page http://en.wikipedia.org/wiki/Bisimulation [Thu Sep 19 00:15:09 2013] looking for papers to understand coinduction/codata/etc. (other than "tutorial on costuff ...." paper) [Thu Sep 19 00:17:25 2013] To get the zen of coinduction, you should try to understand the duality in the categorical sense. Coinduction "is just" the dual of induction. [Thu Sep 19 00:20:52 2013] ianjneu: do you have logs with our talk with robbert ? I can use CoInductive data types and CoFixpoints etc. but what I don't understand is that how does proving properties of codata really work. and at this point I don't want/have time to learn the "zen" of it. [Thu Sep 19 00:21:24 2013] (btw, I don't know why I'm obsessed over it .. maybe I just let it go and use CoInduction/CoFixpoint when necessary) [Thu Sep 19 00:26:25 2013] Sorry I can't be more helpful right now. I'm racing toward a deadline. It's past midnight here and my thinking cycles have to go into the paper. [Thu Sep 19 00:30:32 2013] okay, no problem. it's past midnight here too :) [Thu Sep 19 00:39:25 2013] It's great finding that one of my older papers is wrong when trying to find a bug in the code for the next paper. -_-;; [Thu Sep 19 01:05:50 2013] I probably need to learn category theory and some other maths too ... [Thu Sep 19 10:27:01 2013] can i define a notation such that i can use R* instead of clos_refl_trans _ R. clos_refl_trans is in Relation_Operators: http://coq.inria.fr/distrib/8.3pl5/stdlib/Coq.Relations.Relation_Operators.html [Thu Sep 19 11:22:27 2013] osa1: maybe http://www.fing.edu.uy/inco/eventos/SEFM2011/cursos/Davide.pdf can help to understand coinduction [Thu Sep 19 11:23:44 2013] It is from 2011 SEFM School; slides from Davide Sangiorgi's class Bisimulation and coinduction [Thu Sep 19 11:23:49 2013] This seems like a potentially overly broad question, but I'm doing some reasoning about refinement of functions, is there a "good" way to reason about refinement / program equality? [Thu Sep 19 11:24:06 2013] (E.g., other than Coq.Program.Equality with dependent equality axioms) [Thu Sep 19 11:44:52 2013] gereedy: thanks for the link, it looks interesting. [Thu Sep 19 12:32:05 2013] oh boy. there's a book named "introduction to coinduction and bisimulation". [Thu Sep 19 13:00:07 2013] osa1: yes, it has some pretty good explanations [Thu Sep 19 14:43:10 2013] if I do: "specialize (H …).", the assumption H is dropped, how do I keep it? [Thu Sep 19 14:51:46 2013] anders__: you can copy it ahead of time -- there's probably a better way to do it but `assert H as H'. exact H.` might do the job [Thu Sep 19 14:53:47 2013] ystael: thanks. I found that remember `H as H'; clear HeqH'.` also did the job. I assume it can be done in one command though. [Thu Sep 19 14:57:09 2013] anders__: You could perhaps even just do 'pose (H ...) as Hspec' [Thu Sep 19 15:00:06 2013] anders__: specialize is designed to replace the hypothesis you specify. If you want to keep it, just use a tactic that introduces a new hypothesis. [Thu Sep 19 15:00:42 2013] ok, which other tactic would have the same effect (instantiate a universal expression) [Thu Sep 19 15:01:20 2013] anders__: You could perhaps even just do 'pose (H ...) as Hspec' [Thu Sep 19 15:01:45 2013] pose proof (H ...) as . [Thu Sep 19 15:01:58 2013] assert (Hspec := H ...) as Hspec. [Thu Sep 19 15:07:31 2013] tomprince: thanks! that was exactly what i was looking for [Thu Sep 19 19:20:54 2013] Hey guys, I'm trying to interpret Chlipala's comments here: http://blog.ezyang.com/2013/09/induction-and-logical-relations/comment-page-1/#comment-6242 [Thu Sep 19 19:21:39 2013] (I know the post is written in Agda, but Chlipala primarily uses Coq so I thought maybe the insight here would be better) [Thu Sep 19 19:22:10 2013] The first thing to look at is the definition of 'what is a value', defined here http://lpaste.net/93187 ; Adam suggests that it should be done recursively; but I can't think of a way to do it that doesn't involves units and voids [Thu Sep 19 19:33:28 2013] ezyang: I couldn't follow what he suggested. [Thu Sep 19 19:34:22 2013] ok, because I couldn't follow it either [Thu Sep 19 19:36:14 2013] What does he mean by polymorphic equality? JMeq? [Thu Sep 19 19:36:50 2013] Oh, he just means Leibniz equality [Thu Sep 19 19:36:53 2013] murmble. Chlipala has always been incomprehensible to me. [Thu Sep 19 20:26:24 2013] oh I did not see that post :) [Thu Sep 19 22:33:37 2013] I'm trying to prove an induction principle for nat with multiple base cases and a "step size" of 2. [Thu Sep 19 22:34:06 2013] I don't understand why the inductive hypothesis IHn'' isn't just P n'' here: http://lpaste.net/93192 [Thu Sep 19 22:43:29 2013] Is the problem that I don't have information about the structure of the proof of P n' that comprises IHn' ? [Thu Sep 19 22:57:25 2013] never mind, figured it out - had to strengthen the conclusion [Fri Sep 20 13:47:06 2013] I'm trying to understand ... syntax, if I start the proof with "Proof with auto.", then ... replaced with ; auto. ? [Fri Sep 20 14:02:32 2013] yes? [Fri Sep 20 15:46:50 2013] Ptival: okay, thanks. [Fri Sep 20 16:00:58 2013] hi [Fri Sep 20 16:01:15 2013] i was just wondering: how can I use Print on something like <> ? [Fri Sep 20 16:01:47 2013] Print <>, or Print "<>" don't seem to work [Fri Sep 20 16:05:17 2013] Armael: maybe first Locate "<>". than call Print on the identifier [Fri Sep 20 16:05:38 2013] s/than/then [Fri Sep 20 16:06:13 2013] oh, Locate is indeed useful [Fri Sep 20 16:06:15 2013] thanks [Sat Sep 21 09:24:55 2013] I'm trying to define a new notation for a paritcular scope. I'm getting back "unknown scope delimiting key" [Sat Sep 21 11:47:02 2013] clj_newb_2345: you need to declare scopes ahead [Sat Sep 21 11:57:02 2013] Ptival: https://gist.github.com/anonymous/5661535788e4d74da844 [Sat Sep 21 11:57:04 2013] what am I missing? [Sat Sep 21 11:58:32 2013] oh [Sat Sep 21 11:58:41 2013] after declaration, you don't need the _scope [Sat Sep 21 11:58:50 2013] it's just % foo [Sat Sep 21 11:58:55 2013] I hate this stupid syntax [Sat Sep 21 11:59:31 2013] Since you said "Delimit Scope foo_scope with foo." [Sat Sep 21 12:03:15 2013] fucking dumbass syntax :-) [Sat Sep 21 12:03:33 2013] I suspect the designers of Coq were like "how can we keep low motivation people from using Coq" [Sat Sep 21 12:04:06 2013] and they were like "let return fun dependent type errors of abstractinf foo over bar; make Ltac impossibly hard to debug; and do delimiter stuff" [Sat Sep 21 12:04:23 2013] in otther words, thank you :-) [Sat Sep 21 12:14:30 2013] hehe [Sat Sep 21 13:29:14 2013] Ah, I had the same problem! Thanks, Ptival [Sat Sep 21 14:06:49 2013] what? [Sat Sep 21 14:06:57 2013] it was my line of questioning that provided the answer :-) [Sat Sep 21 15:20:07 2013] I've got a match in a goal that looks like match f x with |a => ... where x is of an inductive type i defined and f is a Fixpoint mytype -> mytype. the match consists of three branches but i already proofed a Lemma stating forall x : mytype, f x <> a. can i somehow tell Coq to drop the first branch and leave me with the match against the other two? [Sat Sep 21 17:59:52 2013] RegEchse: the best you can do is probably destruct (f x) as [foo|bar|baz] eqn:baq, and then use your result in the first subbranch [Sat Sep 21 18:28:46 2013] robbert: ok, thx. just what i thought. actually i'm destruct-ing x now, anyway. [Sat Sep 21 18:34:09 2013] pfff .... it's hard to predict whether to use inversion or induction while starting a long proof ... [Sat Sep 21 18:36:15 2013] are there any conventions for levels while defining new notations? I'm wondering how people decided levels of notation in SF book. [Sat Sep 21 18:51:56 2013] RegEchse: well, that may work too, the trick in my suggestion is the eqn:baq clause, it adds an equality to each subgoal to remember which variant of the inductive you are considering [Sat Sep 21 18:53:02 2013] osa1: induction if you need an induction hypothesis, inversion if the thing is dependent, dependent induction if both (but that tactic is a bit weird and may assume additional axioms...) [Sat Sep 21 18:54:52 2013] osa1: there is a table with the levels of the ordinary connectives in the documentation, try to put your own notations at a sensible level in between them [Sat Sep 21 18:55:15 2013] robbert: what do you mean by "dependent" ? [Sat Sep 21 18:56:04 2013] if the type contains indices in which something more complex than just a variable is used [Sat Sep 21 18:56:11 2013] for example H : vec A (S n) [Sat Sep 21 18:57:47 2013] here you typically want to avoid one case (namely nil) because of the index (S n) [Sat Sep 21 20:19:07 2013] what is 2 in "solve by inversion 2" ? [Sat Sep 21 20:46:26 2013] I wonder what was considered formal before we had theorem provers(like Coq) ... [Sat Sep 21 20:53:00 2013] inversion num [Sat Sep 21 20:53:01 2013] This does the same thing as intros until num then inversion ident where ident is the identifier for the last introduced hypothesis. [Sat Sep 21 20:53:30 2013] intros until num [Sat Sep 21 20:53:31 2013] This repeats intro until the num-th non-dependent product. [Sat Sep 21 23:09:04 2013] wow ... this is my first time using auto and it really helped http://lpaste.net/93238 [Sun Sep 22 06:37:54 2013] I have a relation R and an assumption "H : R u v". when doing "induction H", how do I get an equation in each case that tells me the value that u takes? [Sun Sep 22 07:40:23 2013] anders_: pastebin? [Sun Sep 22 07:41:34 2013] sure, I will try to come up with a minimal example [Sun Sep 22 07:56:19 2013] this should be a sort of minimal example of what i want [Sun Sep 22 07:56:25 2013] http://pastebin.com/gti27twc [Sun Sep 22 07:58:41 2013] anders_: what is the point of wanting that in the first place? [Sun Sep 22 07:59:23 2013] if you want it so badly, the easiest way is probably to write your own induction principle that gives such equalities [Sun Sep 22 08:05:23 2013] in the actual proof I am doing, I have R (x*y) (x'*y'), R x x', R y y'. doing induction on the first relation, (x*y) is substituted for z, and I need to to use (x*y) = z together with the other relations to prove some things. [Sun Sep 22 08:06:05 2013] (z being just some expression of course) [Sun Sep 22 08:06:09 2013] anders_: ok, that makes things clear :) [Sun Sep 22 08:06:33 2013] best use remember (x * y) as u eqn:Hu before doing the induction [Sun Sep 22 08:07:56 2013] yep that seems to do the trick! much thanks! [Sun Sep 22 08:49:55 2013] what is a simple way of applying a function to both sides of a hypothesis equation? currently my equation is H: x = y and i'm doing assert (H0: f x = f y). rewrite H. reflexivity. clear H. Can i do that more directly? [Sun Sep 22 08:55:05 2013] RegEchse: apply (f_equal f) in H [Sun Sep 22 08:57:59 2013] ah! i already looked up f_equal in the reference manual but didn't know how to apply it. thanks. :) [Sun Sep 22 08:58:43 2013] RegEchse: note this is unrelated to the f_equal tactic [Sun Sep 22 08:59:02 2013] it's just applying the lemma f_equal at an assumption [Sun Sep 22 09:03:45 2013] yes, i understand that. i also already Check-ed f_equal to see what it actually does / how it is defined. [Sun Sep 22 09:21:39 2013] For a relation R, I want to prove "for all u v, R u v -> R u v' -> exists w, R v w /\ R v' w" (i.e. diamond property of R). R has 4 constructors say R1,R2,R3,R4. Obviously the case "(R1 u v and R2 u v')" is the same as "(R2 u v /\ R1 u v')" etc, thus I should only have to consider 7 cases. this is the case if I do "induction H_Ruv. induction H_Ruv' " but I need to do "generalize dependent v'. induction H_Ruv. intros v' H_R [Sun Sep 22 09:21:40 2013] induction H_Ruv' " which gives me 16 cases to handle. Is it possible to not have to handle the redundant cases? [Sun Sep 22 09:23:26 2013] sorry 10 cases actually, but i did not need do the second induction in one case so 7 cases in total in my situation [Sun Sep 22 09:45:37 2013] anders_: shouldn't you do "incudction u"? [Sun Sep 22 09:47:49 2013] no I am doing inductions over the relation R [Sun Sep 22 14:10:50 2013] ;w 56 [Sun Sep 22 15:07:12 2013] I wish SF's source was on Github and was accepting pull requests from readers [Sun Sep 22 15:11:03 2013] how to simplify this H : (if eq_id_dec i i then s else tvar i) = t' ? [Sun Sep 22 15:40:10 2013] This is pretty cool https://sympa.inria.fr/sympa/arc/coq-club/2013-09/msg00059.html [Sun Sep 22 16:26:44 2013] is there a tactic to generalize multiple variables? like instead of this generalize dependent s. generalize dependent x. generalize dependent t'. some shorter version [Sun Sep 22 16:28:48 2013] osa1: Have you tried "generalized dependent s x t'." [Sun Sep 22 16:41:05 2013] tomprince: yep [Sun Sep 22 16:41:25 2013] tomprince: throws syntax error [Sun Sep 22 16:49:00 2013] this is exhausting http://lpaste.net/93267 [Sun Sep 22 17:45:05 2013] I was wondering the same a few months ago and came to the conclusion that there wasn't [Sun Sep 22 20:54:08 2013] in an implication like A -> B is there a special name given to A ? [Sun Sep 22 21:00:37 2013] I'd be inclined to call it the domain. [Sun Sep 22 21:01:57 2013] um yeah but then it sounds like we're talking about function types [Sun Sep 22 21:04:25 2013] in formal logic i think one would call A the 'antecedent'. i don't know whether people would use that term in functional programming, though. good night [Mon Sep 23 03:33:15 2013] osa1: in logic, the premise [Mon Sep 23 09:42:39 2013] robbert: hmm. I though premise/conclusion naming convention are for natural deduction style inference rules... [Mon Sep 23 10:40:05 2013] (* The "solve by inversion" tactic is explained in Stlc.v. *) <-- I don't think it's true. solve by inversion tactic is never explained anywhere in SF book .. or am I missing something? [Mon Sep 23 11:15:22 2013] http://www.cis.upenn.edu/~bcpierce/sf/References.html any ideas about last exercise? how to add garbage collection, what are some standard theorems about garbage collecting etc. [Mon Sep 23 11:32:28 2013] what is the name of @ operator? trying to look it up from documentation [Mon Sep 23 11:33:00 2013] @about @ [Mon Sep 23 11:33:53 2013] @about @ [Mon Sep 23 11:34:15 2013] error: Syntax error: illegal begin of smart_global_eoi. [Mon Sep 23 11:34:35 2013] @about "@" [Mon Sep 23 11:34:35 2013] error: Error: Unable to interpret "@" as a reference. [Mon Sep 23 11:35:00 2013] osa1: do you mean @ for explicit application as described in http://coq.inria.fr/distrib/current/refman/Reference-Manual004.html#sec118 [Mon Sep 23 11:35:37 2013] gereedy: probably. thanks. [Mon Sep 23 11:36:24 2013] basically I'm trying to understand why this tactic works ` remember (@empty ty).` while this one fails `remember (empty ty).` [Mon Sep 23 11:37:04 2013] @check @empty [Mon Sep 23 11:37:04 2013] error: Error: The reference empty was not found in the current environment. [Mon Sep 23 11:37:28 2013] osa1: Do 'Check @empty' and 'Check empty' [Mon Sep 23 11:37:33 2013] If you do Check empty. and Check @empty. you will see they have different types [Mon Sep 23 11:37:36 2013] @ disables implicit arguments. [Mon Sep 23 11:37:36 2013] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Mon Sep 23 11:38:38 2013] yeah. and I don't understand what is this term: \empty : partial_map ?3801, what is backslash in the beginning? [Mon Sep 23 11:50:23 2013] osa1: because of Notation "'\empty'" := empty. [Mon Sep 23 11:50:34 2013] in the processed document the \ is rendered as a lambda [Mon Sep 23 11:52:50 2013] thanks. [Mon Sep 23 11:53:04 2013] another question, assumption fails but apply H1 works, why is that? [Mon Sep 23 11:55:12 2013] without seeing the entire context I can't say for sure, but assumtion "looks in the local context for an hypothesis which type is equal to the goal" [Mon Sep 23 11:57:25 2013] key part being "equal to the goal", so I guess H1 has some implicit arguments and those make its type not equal [Mon Sep 23 12:00:27 2013] apply [Mon Sep 23 12:00:37 2013] apply "match the current goal against the conclusion of the type of term" [Mon Sep 23 12:01:16 2013] so it does not require strict equality but just that the conclusion unifies with the goal [Mon Sep 23 12:05:02 2013] hmm. that makes sense. [Mon Sep 23 12:07:52 2013] I'm having trouble finding my way in Coq documentation .. where is reference manual for "solve by ..." tactic? http://coq.inria.fr/distrib/current/refman/tactic-index.html I don't think solve here is the same [Mon Sep 23 12:21:08 2013] osa1: `by` is not an Ltac keyword, I think. Look for a Tactic Notation somewhere. [Mon Sep 23 15:07:27 2013] can we say that eauto is strictly more powerful than auto? (probably not -- otherwise who needs auto? I'm looking for a case where auto works but eauto doesn't) [Mon Sep 23 15:11:24 2013] osa1 no idea [Mon Sep 23 15:28:02 2013] osa1: It isn't. It will leave unresolved metas around, which auto won't do. [Mon Sep 23 21:12:58 2013] How can I do case analysis on a term but retain an equation in the context saying what case I'm in? [Mon Sep 23 21:14:35 2013] For example, if beq_nat : nat -> nat -> bool is equality, I would like to destruct (beq_nat n m), but remember in the false case an equation (beq_nat n m) = false so that I can rewrite by it later. [Mon Sep 23 21:15:50 2013] (In my case I need to use the fact twice but the second time is behind a reduction enabled by the first substitution.) [Mon Sep 23 22:43:08 2013] ystael: destruct (beq_nat n m) eqn:H [Tue Sep 24 03:31:35 2013] osa1: although it does not explicitly stated, the thing in LICENCE is the MIT licence [Tue Sep 24 03:31:43 2013] *state it [Tue Sep 24 06:42:13 2013] Is there a way to repeat a Ltac a fixed number of times? Like 5 times. [Tue Sep 24 06:58:09 2013] reynir: do 5 foo? [Tue Sep 24 07:07:33 2013] Great, thanks robbert :-) [Tue Sep 24 10:34:12 2013] Ptival: thanks for the pointer yesterday; i haven't tried it yet but from the doc it looks like exactly what i need [Tue Sep 24 11:01:33 2013] for solve by? [Tue Sep 24 11:02:29 2013] you should grep 'Tactic Notation "solve' over your codebase to find it :p [Tue Sep 24 11:02:56 2013] oh wait I'm mistaken [Tue Sep 24 11:03:04 2013] yeah the eqn thing [Tue Sep 24 11:03:35 2013] otherwise you can simulate with remember but it's more manual [Tue Sep 24 12:28:54 2013] huh this stupid talk is 11:30-12:30 on Farmer's Market day @__@ [Tue Sep 24 12:28:59 2013] woop [Tue Sep 24 12:29:12 2013] wrong channel :) [Tue Sep 24 12:38:16 2013] suppose i would like to check if some element is in a list of the element's type [Tue Sep 24 12:39:54 2013] would it be possible to do it in a way resembling this? [Tue Sep 24 12:39:56 2013] Fixpoint elem_isin (e : element) (le : list element) : bool := [Tue Sep 24 12:39:56 2013] match e, le with [Tue Sep 24 12:39:56 2013] _, nil => false [Tue Sep 24 12:39:56 2013] | var, var :: _ => true [Tue Sep 24 12:39:56 2013] | _, _ :: t => ltr_isin e t [Tue Sep 24 12:39:57 2013] end. [Tue Sep 24 12:40:22 2013] Coq complains that 'var' is bound multiple times [Tue Sep 24 12:40:48 2013] it does work when every case is specified, but i would like to just quantify over all possible cases [Tue Sep 24 13:05:09 2013] roosbeef: What do you mean by "when every case is specified"? In general you can't give an identifier multiple times in a pattern to impose an equality constraint. [Tue Sep 24 13:05:15 2013] (Also, use a pastebin like lpaste.net) [Tue Sep 24 13:08:28 2013] To do what you want you need the type element to have a decidable equality predicate, which not every type has. [Tue Sep 24 15:16:40 2013] ystael: could you give an example of a decidable equality predicate? [Tue Sep 24 15:19:43 2013] equality on integers ? [Tue Sep 24 15:22:48 2013] roosbeef: A "decidable equality predicate" is a function that, given two elements of the type, yields one thing if they are equal and another if they are not equal. [Tue Sep 24 15:23:07 2013] For instance, a simple boolean equality on natural numbers might have type nat -> nat -> bool. [Tue Sep 24 15:23:51 2013] (Usually by "decidable equality" one means something whose result type is actually a disjoint sum of proofs, like (m n : nat) -> {m = n} + {m <> n}.) [Tue Sep 24 15:26:41 2013] The point is that you don't necessarily have a decision procedure for equality on terms of any random type. That's why the pattern matcher can't enforce equality between two instances of 'var' in your pattern. [Tue Sep 24 15:33:58 2013] i understand [Tue Sep 24 15:34:21 2013] the type i have in mind would be decidably equatable though [Tue Sep 24 15:35:18 2013] so how would i then plug this equality function into the elem_isin function and use a variable of some sort? [Tue Sep 24 15:36:46 2013] Just match on le rather than e, le, and inside the x::xs case of the match, do a second match on the result of the equality test [Tue Sep 24 15:37:21 2013] (or use `if`, which is syntactic sugar for a match on a two-constructor datatype) [Tue Sep 24 15:38:55 2013] ahh [Tue Sep 24 15:38:58 2013] clever! [Tue Sep 24 15:39:05 2013] sounds pretty solid :) [Tue Sep 24 15:39:13 2013] im gonna try that [Tue Sep 24 15:39:15 2013] thanks a lot! [Tue Sep 24 15:39:27 2013] np, good luck [Tue Sep 24 19:04:54 2013] ezyang: ping [Tue Sep 24 19:06:27 2013] ezyang: where can i access the source tree for coq with mtac? [Tue Sep 24 21:06:56 2013] shergill: pong [Tue Sep 24 21:09:29 2013] should be https://github.com/beta-ziliani/coq/tree/patch-1 or https://github.com/beta-ziliani/coq/tree/mh [Tue Sep 24 21:11:31 2013] I have some branches of my own but I don't know what they're named on coq/ [Tue Sep 24 21:13:38 2013] ezyang: thanks [Tue Sep 24 21:13:54 2013] also check out my rockin' Ubuntu packages [Tue Sep 24 21:14:54 2013] i already have that installed :) [Tue Sep 24 21:15:24 2013] i was considering going through hott exercises with coq-mtac [Tue Sep 24 21:15:50 2013] and hott requires a patched version of coq too [Tue Sep 24 21:16:03 2013] oh, definitely use the mh [Tue Sep 24 21:16:09 2013] branch [Tue Sep 24 21:16:15 2013] gotcha [Tue Sep 24 21:16:27 2013] hmm, I should build Coq for HoTT with Mtac [Tue Sep 24 21:17:13 2013] if that's not too much effort for you, that'd be awesome [Tue Sep 24 21:18:37 2013] The big downside [Tue Sep 24 21:18:42 2013] is you can only have one of these packages installed at a time [Tue Sep 24 21:18:56 2013] So if you want to switch, I still recommend building from source and twiddling your rcfiles [Tue Sep 24 21:20:18 2013] hmm what do you mean by 'packages'? as in debian packages? or mtac and hott changesets are conflicting? [Tue Sep 24 21:20:52 2013] The packages conflict [Tue Sep 24 21:21:08 2013] Actually, that is not even true; they are the same package, all different versions [Tue Sep 24 21:21:54 2013] right. i was wondering if they introduced some mathematical conflict. it seems not? [Tue Sep 24 21:22:28 2013] HoTT will cause some traditional Coq stuff to stop working. Definitely so if you use their alternate standard library [Tue Sep 24 21:22:33 2013] mtac should be completely compatible [Tue Sep 24 21:22:40 2013] ok [Wed Sep 25 12:30:37 2013] Not really a Coq question, how is a partialorder that is not reflexive called? [Wed Sep 25 12:31:07 2013] In case of an equivalence relation, they call it a partial equivalence relation (PER) [Wed Sep 25 12:50:44 2013] robbert: according to wikipeia, a strict partial order [Wed Sep 25 13:56:09 2013] gereedy: a strict partial order is also irreflexive (which is not the same as "not reflexive" :)) [Wed Sep 25 13:57:04 2013] I want to know whether there is a nice name for a relation that is transitive and anti symmetric [Wed Sep 25 14:02:41 2013] robbert: What is your example? [Wed Sep 25 14:07:25 2013] tomprince: i have a relation on expressions of a programming language that is almost the partial order. The only thing lacking is that reflexivity only holds for well typed expressions. [Wed Sep 25 14:08:33 2013] What is the relation? [Wed Sep 25 14:11:12 2013] it means that the permissions contained in the expression allow more [Wed Sep 25 14:13:26 2013] but that does not matter so much, the reason for it not being reflexive, is because its definition relies on the fact that the expression is well-typed [Wed Sep 25 14:14:21 2013] it is set up in such a way that t1 <= t2 => well_typed t1 /\ well_typed t2 [Wed Sep 25 14:17:39 2013] Is there an example of the currently idiomatic way to derive decidable equality predicates for simple inductive types? [Wed Sep 25 14:17:47 2013] I don't know if I should be looking for a type class, or a module, or what [Wed Sep 25 14:17:59 2013] the reason for it not being reflexive, is the same as that the equality judgment Gamma |- x = y : A in traditional MLTT is just a PER [Wed Sep 25 14:18:13 2013] ystael: there is a tactic 'decide equality' [Wed Sep 25 14:19:07 2013] Ptival: but is there some way I should be declaring that my type implements such a predicate? [Wed Sep 25 14:20:47 2013] I guess what I'm saying is, I can write the predicate by hand (or use that tactic), I know what its type and implementation should be. But I don't know the standard library well enough yet to know whether there's a particular way I should spell it to work well in context. [Wed Sep 25 14:20:49 2013] ystael: should: not really, could: use the type class Class Decision (P : Prop) := decide : {P} + {¬P}. [Wed Sep 25 14:25:23 2013] robbert: I don't find that in the standard library? [Wed Sep 25 14:30:04 2013] robbert: I don't think it is, see Section 4.1 of http://arxiv.org/abs/1102.1323 for the idea behind it [Wed Sep 25 14:31:55 2013] ah, ok, thanks [Wed Sep 25 16:33:24 2013] automation is so awesome ... it leaves me only the interesting part in this theorem http://lpaste.net/93403 (the admitted part) [Wed Sep 25 16:33:50 2013] (also, I wish I didn't have to `remember (@empty ...)` in this proof) [Wed Sep 25 16:43:10 2013] oh wow, i [Wed Sep 25 16:43:51 2013] if I give a theorem for type preserving substitution and add it to hint database, admitted part in the proof I linked above can be solved with auto. [Wed Sep 25 16:44:37 2013] http://lpaste.net/93404 [Wed Sep 25 16:50:19 2013] though I'm not sure how to prove subst_preservation [Wed Sep 25 18:19:17 2013] is there a way to print what tactics are applied by auto/eauto? [Wed Sep 25 18:23:03 2013] info_auto [Wed Sep 25 21:09:41 2013] what is difference between try solve [ inversion H; eauto ]. and try (inversion H; eauto). ? [Wed Sep 25 23:02:33 2013] osa1: i believe 'try' by itself does not fail if its argument tactic fails partway down, but you still get whatever changes have been applied up to that point; whereas 'try solve' is a no-op if its argument does not completely solve the goal. [Wed Sep 25 23:31:12 2013] is there a particular reason that the unit value is denoted `tt` ? [Wed Sep 25 23:37:57 2013] I think it stands for tautology? [Wed Sep 25 23:39:07 2013] or something like trivially true [Wed Sep 25 23:42:39 2013] ah that kinda makes sense [Thu Sep 26 09:26:04 2013] hi [Thu Sep 26 09:26:18 2013] is there a way to shorten substrings in proof mode? [Thu Sep 26 09:26:27 2013] i would like to do this for better readability [Thu Sep 26 09:27:49 2013] for example shorten this to 'max': [Thu Sep 26 09:27:51 2013] (max (ft_depth (stratify (à :: r))) (ft_depth (stratify (ó :: r))) * max (ft_width 0 (stratify (à :: r))) (ft_width 0 (stratify (ó :: r)))) [Thu Sep 26 09:41:43 2013] Hello to all! I'm in trouble to understand a error message given at a definition using the refine tactic. I've pasted the code at http://pastebin.com/HEDwsu5T [Thu Sep 26 09:42:40 2013] I can solve the obligations generated by holes, but when I try to "Defined.", it gaves me a error message "Ill formed recursive definition" [Thu Sep 26 09:45:05 2013] Could someone give any hints on this error message? [Thu Sep 26 10:13:56 2013] It means that you applied your fixpoint function to an argument that is not structurally smaller. Try looking a "Show Proof" and seeing where the fixpoint definition show up? [Thu Sep 26 10:36:25 2013] how can I state the equivalence between an inductive in Prop and another one in Type? [Thu Sep 26 10:38:24 2013] You won't be able to prove it unless your inductive is either empty or a singleton. [Thu Sep 26 10:38:53 2013] Things in Prop are inhabited by at most one thing. [Thu Sep 26 10:41:06 2013] ianjneu: That's not provable. Whether or not things in Prop can be inhabited by multiple things requires an extra axiom. [Thu Sep 26 10:41:31 2013] OK. Thus another question: I want an inductive s.t. I can compute on it with Fixpoints and I can state a Proper instance to ease things [Thu Sep 26 10:41:37 2013] How can I do? [Thu Sep 26 10:43:34 2013] I don't know what you're asking. [Thu Sep 26 10:45:43 2013] I want an inductive MyInd : list form -> form -> ??? (with form defined somewhere) [Thu Sep 26 10:46:51 2013] I would like to have: Instance compat : Proper (@Permutation _ ==> eq ==> iff) MyInd. [Thu Sep 26 10:47:24 2013] if I want to compute I need it to be in Type. However for my permutation thing that should be in Prop [Thu Sep 26 10:47:33 2013] I don't know how to solve this dilemma [Thu Sep 26 10:48:42 2013] I don't really understand what you're asking (what's Permutation), but are you looking for higher inductive types? [Thu Sep 26 10:51:20 2013] Permutation is the one of the standard library. This states that if MyInd A B holds, then for any permutation A A', MyInd A' B holds. And later, if I have a permutation as an hypothesis, I can directly use rewrite in my Goal MyInd A B [Thu Sep 26 10:52:09 2013] I don't about higher inductive types. I'll have a look [Thu Sep 26 11:02:21 2013] Are you asking how to define an "unordered list" inductive type? The two ways that I know of are by imposing some arbitrary order on the elements of the list, so that for any given set of elements, there's only one "unordered list" with those elements; or by using higher inductive types, which are still in development (not yet in a released version of Coq). [Thu Sep 26 11:03:50 2013] i,i higher inductive list with permutation path constructors [Thu Sep 26 11:04:44 2013] (which is just a quotient type over permutations) [Thu Sep 26 11:08:00 2013] ok thanks [Thu Sep 26 11:23:01 2013] ezyang: Have you seen https://github.com/barras/coq/tree/hit? [Thu Sep 26 11:31:10 2013] nope, not yet [Thu Sep 26 11:33:56 2013] It's an implementation of higher inductive types where you can prove functional extensionality (but you can't compute with it very well, yet). [Thu Sep 26 16:03:22 2013] jgross: doesn't function extensionallity from the fact that you can define the interval using higher inductive types? [Thu Sep 26 16:27:09 2013] mortberg: Yes, that's the proof I was thinking of. I functional extensionality is the simplest result I know of fromm having HITs, and this is the first version of Coq AFAIK that can prove funext without axioms. [Thu Sep 26 16:36:02 2013] yeah, ok, that is pretty neat indeed [Thu Sep 26 17:01:53 2013] has anyone emulated coq ide in vim on os x? http://www.vim.org/scripts/script.php?script_id=4388 [Thu Sep 26 17:22:47 2013] anders__: https://github.com/trefis/coquille [Fri Sep 27 00:29:42 2013] is coq strongly normalizing? [Fri Sep 27 02:49:50 2013] maxiepoo: Yes. (Or, at least, it's believed to be. I think it's been proven somewhere, but I don't have a source.) [Fri Sep 27 03:16:23 2013] jgross: for CC you can have a look at Coq in Coq by Bruno Barras and Benjamin Werner, they implement CC in Coq and prove strong normalization. however CC is just a part of the Coq kernel so it does not mean that all of Coq is strongly normalizing... [Fri Sep 27 03:25:06 2013] reynir: thanks! [Fri Sep 27 04:47:15 2013] maxiepoo: no, it is not [Fri Sep 27 04:49:30 2013] try, fix f (x : nat) : nat := let _ := f x in 10) 12 [Fri Sep 27 04:50:07 2013] with cbv evaluation, it diverges [Fri Sep 27 04:50:09 2013] Eval compute in (fix f (x : nat) : nat := let _ := f x in 10) 12. [Fri Sep 27 04:50:16 2013] gives a nice "Stack overflow." :) [Fri Sep 27 04:51:07 2013] ah, he's not even here anymore... [Fri Sep 27 08:48:24 2013] hi [Fri Sep 27 08:48:41 2013] in proof mode, is it possible to 'fold back' functions that are unfolded? [Fri Sep 27 08:50:09 2013] or more preferably, would it be possible to just replace some substring with a keyword or something like that? After a few unfolds the propositions can become huge [Fri Sep 27 08:54:51 2013] You can try [fold ], but it doesn't always work very well. You can also try [change (
)], if you know what the goal should be. Look also at the tactic [set], and the [change foo with bar] variant of [change]. [Fri Sep 27 08:56:57 2013] hm [Fri Sep 27 08:57:24 2013] so for example suppose i have this in my goal: [Fri Sep 27 08:57:33 2013] (max (ft_depth (stratify (à :: r))) (ft_depth (stratify (ó :: r))) * max (ft_width 0 (stratify (à :: r))) (ft_width 0 (stratify (ó :: r))))) [Fri Sep 27 08:57:52 2013] and id like to replace it with 'maximal' [Fri Sep 27 08:57:59 2013] would that be possible? [Fri Sep 27 08:58:47 2013] it would make things a lot easier to read and that substring isnt even really that important for the proof itself anyway [Fri Sep 27 09:09:19 2013] You can try [set (maximal := )." [Fri Sep 27 09:10:07 2013] If the substring really isn't important, you can do [generalize (); intro.], and then it's just a variable. [Fri Sep 27 09:12:06 2013] works :) [Fri Sep 27 09:12:09 2013] thank you! [Fri Sep 27 10:24:54 2013] Is it possible to make a notation so I can use decimal notation for my own types? E.g. 42%my_type [Fri Sep 27 10:44:59 2013] reynir: Yes, but you have to write ml code. You can look at plugins/syntax/nat_syntax_plugin.* in the coq source tree. Or you can just make a coercion from nat to your type. [Fri Sep 27 10:51:13 2013] Thanks. Coercion works great! [Fri Sep 27 14:25:01 2013] why cant a proposition contain bool types? [Fri Sep 27 14:26:01 2013] what do you mean by "contain" ? [Fri Sep 27 14:26:20 2013] forall x, f_bool x -> f_prop x [Fri Sep 27 14:26:43 2013] (where f_bool has return type bool and f_prop return type Prop) [Fri Sep 27 14:27:12 2013] Coq would complain if i did that [Fri Sep 27 14:27:21 2013] What is the type f_prop x in case f_bool x is false? [Fri Sep 27 14:27:55 2013] is that a trick question? :p [Fri Sep 27 14:29:06 2013] ... I don't think so? [Fri Sep 27 14:29:23 2013] oh [Fri Sep 27 14:29:48 2013] i guess it would just be 'false' then? [Fri Sep 27 14:29:59 2013] eh wait [Fri Sep 27 14:30:02 2013] not false but False, the inductive type in sort Prop with no constructor [Fri Sep 27 14:30:10 2013] yea, im confused [Fri Sep 27 14:30:11 2013] i have no idea [Fri Sep 27 14:30:54 2013] Look at it this way. A proof of forall x, f_bool x -> f_prop x (or, a function of that type) would have to consume a boolean (either true or false) and yield a value of the corresponding type in Prop [Fri Sep 27 14:31:05 2013] But if f_bool x is false, you want the type of proofs of f_prop x to be empty [Fri Sep 27 14:31:12 2013] (otherwise you have proved false) [Fri Sep 27 14:31:26 2013] HM [Fri Sep 27 14:31:29 2013] So your function cannot yield anything at an x for which f_bool x = false [Fri Sep 27 14:31:30 2013] that makes sense [Fri Sep 27 14:31:37 2013] ok [Fri Sep 27 14:31:45 2013] Try instead: forall x, f_bool x = true -> f_prop x [Fri Sep 27 14:31:55 2013] ah :) [Fri Sep 27 14:32:01 2013] sounds good [Fri Sep 27 14:32:03 2013] lemme try [Fri Sep 27 14:33:22 2013] works :) [Fri Sep 27 14:33:45 2013] is it possible to apply an hypothesis to another hypothesis? [Fri Sep 27 14:33:49 2013] for example, [Fri Sep 27 14:33:59 2013] H : fl_isin à r = true [Fri Sep 27 14:33:59 2013] H0 : if fl_isin à r [Fri Sep 27 14:34:19 2013] would it be possible to plug H into the if condition of H0? [Fri Sep 27 14:34:31 2013] you can `rewrite H in H0` [Fri Sep 27 14:34:40 2013] ha gotcha [Fri Sep 27 14:34:41 2013] similarly `apply H in H0`, though I think rewrite is what you want here [Fri Sep 27 14:35:18 2013] apply H in H0 didnt work [Fri Sep 27 14:35:21 2013] it said "Error: Statement without assumptions." [Fri Sep 27 14:35:36 2013] yeah. apply is for conditionals. you want rewrite, that uses equations. [Fri Sep 27 14:38:11 2013] hm [Fri Sep 27 14:38:18 2013] sorry for asking so many questions :/ [Fri Sep 27 14:38:21 2013] but how do i rewrite this [Fri Sep 27 14:38:23 2013] H0 : (if fl_isin à (highest r) then true else false) = true [Fri Sep 27 14:38:24 2013] to [Fri Sep 27 14:38:35 2013] H0 : fl_isin à (highest r) = true [Fri Sep 27 14:38:47 2013] (which seems to be equivalent) [Fri Sep 27 14:39:24 2013] the way i would do that is case analysis on fl_isin à (highest r) [Fri Sep 27 14:39:41 2013] destruct (fl_isin à (highest r)) eqn: H1 [Fri Sep 27 14:39:54 2013] what does eqn: H1 do? [Fri Sep 27 14:40:07 2013] eqn: H1 tells destruct to retain an equation in the context telling you which case you're in [Fri Sep 27 14:40:29 2013] to retain it? [Fri Sep 27 14:40:30 2013] otherwise you don't actually know that the 'true' or 'false' you obtained by case analysis is connected to the originally analyzed term fl_isin à (highest r) [Fri Sep 27 14:41:00 2013] try the destruct with and without it and see the difference [Fri Sep 27 14:41:06 2013] ok let me see [Fri Sep 27 14:42:20 2013] it splits the proof in two cases [Fri Sep 27 14:42:36 2013] one where H0: true = true [Fri Sep 27 14:42:41 2013] and one where H0: false = true [Fri Sep 27 14:43:36 2013] was eqn: H1 supposed to prevent that from happening? [Fri Sep 27 14:44:26 2013] eqn: H1 adds an additional hypothesis which is the thing you actually wanted to remember [Fri Sep 27 14:44:42 2013] yes [Fri Sep 27 14:44:56 2013] and you can clear the false = true case with `contradiction` [Fri Sep 27 14:46:18 2013] ok works :) [Fri Sep 27 14:46:26 2013] is there a way to merge the subgoals? [Fri Sep 27 14:46:31 2013] as they are the same now [Fri Sep 27 14:46:41 2013] you can clear the one you don't care about by chaining [Fri Sep 27 14:46:52 2013] destruct (fl_isin à (highest r)) eqn H1; try contradiction. [Fri Sep 27 14:47:11 2013] oh wait i think it auto-merged the subgoals [Fri Sep 27 14:47:21 2013] how do i unfocus after i did Focus 2? [Fri Sep 27 14:47:34 2013] um, Focus 1. ? [Fri Sep 27 14:47:35 2013] :) [Fri Sep 27 14:47:36 2013] (to see all subgoals again) [Fri Sep 27 14:47:41 2013] oh, I don't know [Fri Sep 27 14:47:52 2013] yea but then i cant Focus 2 anymore, so i guess it merged them [Fri Sep 27 14:48:02 2013] :p [Fri Sep 27 14:49:08 2013] Sometimes I get hypothesises of the form [C1 x1 = C2 x2] where C1 and C2 are two different constructors. Is there a thing like discriminate that automatically finds such hypothesis? [Fri Sep 27 14:55:51 2013] congruence? [Fri Sep 27 14:56:49 2013] but doesn't discriminate do that already? [Fri Sep 27 15:00:14 2013] can i use Lists.List.In as an if condition? For example if (In x y) then ...? [Fri Sep 27 15:00:31 2013] you'd use In_dec [Fri Sep 27 15:01:01 2013] in_dec in fact [Fri Sep 27 15:01:16 2013] (the naming schemes in this stdlib @___@) [Fri Sep 27 15:02:27 2013] both work [Fri Sep 27 15:02:30 2013] but what does this mean [Fri Sep 27 15:02:33 2013] (forall x y:A, {x = y} + {x <> y}) [Fri Sep 27 15:02:39 2013] what does the + mean here [Fri Sep 27 15:02:56 2013] boolean and? [Fri Sep 27 15:03:07 2013] err logical i mean [Fri Sep 27 15:05:37 2013] * confused [Fri Sep 27 15:08:01 2013] are you sure in_dec is the boolean version of In? [Fri Sep 27 15:08:22 2013] it looks more like some theorem to prove a property of In [Fri Sep 27 15:15:19 2013] Ptival: Looks like you are right. I must have missed that when I read the documentation [Fri Sep 27 15:35:13 2013] roosbeef: That type is a more sophisticated version of boolean equality [Fri Sep 27 15:35:34 2013] Instead of a true value or a false value, it gives a proof that x = y is true or a proof that x <> y is true (which is a proof that x = y -> False) [Fri Sep 27 15:36:03 2013] Because `if` is just syntactic sugar for a pattern match on any two-constructor datatype, you can use this type in an `if` just as if it were a boolean [Fri Sep 27 15:36:15 2013] ... oh. gone. :( [Fri Sep 27 16:17:46 2013] :\ [Fri Sep 27 16:20:03 2013] ystael: I appreciate the explanation even though I didn't ask :) [Fri Sep 27 16:20:50 2013] :) [Sat Sep 28 08:02:55 2013] Hello. [Sat Sep 28 08:03:56 2013] I'm using coq with proof general and in Utoks mode i've noticed that => got converted into real unicode ⇒ and coq doesn't recognize it. [Sat Sep 28 08:04:48 2013] Is ther a way to tell Utoks mode not to convert tokens into real unicode? [Sat Sep 28 09:16:02 2013] tee0: Isn't that what Utoks mode is for? [Sat Sep 28 09:16:48 2013] Oh, right, the idea is that it doesn't actually modify the underlying buffer, only displays it as such [Sat Sep 28 09:46:43 2013] Cale: Yeah, but it does modify it for some reason [Sat Sep 28 09:49:29 2013] And it obvously break things. :( [Sat Sep 28 11:35:50 2013] I have a project with subdirectories. In emacs+proofgeneral I have a problem where it can't find one of the libraries. What can I do? [Sat Sep 28 15:05:34 2013] i'm stuck on classical_axioms exercise from http://www.cis.upenn.edu/~bcpierce/sf/Logic.html. should i prove that, for example, "peirce -> classic" (and four more similar implications)? if so, looks like i need some advice/hint how to do it. after unfolding and intros, i just can't see what to do next: tried to apply "peirce" with something, but had no success [Sat Sep 28 15:07:12 2013] defanor_: keep playing with it [Sat Sep 28 15:08:23 2013] i'll try, thanks [Sat Sep 28 16:18:35 2013] yay, done with "peirce -> classic" [Sun Sep 29 15:51:40 2013] almost all of the proofs in References.v fail at somewhere in my Coq installation [Sun Sep 29 15:51:55 2013] which is version 84pl2 (June 2013) [Sun Sep 29 15:52:03 2013] 8.4* [Sun Sep 29 17:13:40 2013] i'm stuck on the same exercise again (http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, classical_axioms), on the last theorem: implies_to_or -> peirce, need a hint/advice. here is my progress (not even sure if i'm on a right way): http://lpaste.net/7367171717954797568. also tried inversion on ITO, but it looks tricky [Sun Sep 29 17:16:25 2013] *induction on ITO [Sun Sep 29 17:20:35 2013] *seems [Sun Sep 29 19:32:44 2013] defanor: I don't think you are on the right way [Sun Sep 29 19:33:40 2013] you have to make a smart choice which propositions to use for implies_to_or with [Sun Sep 29 19:33:52 2013] you only need to use implies_to_or once [Sun Sep 29 19:34:11 2013] and if you make the right choice, the remaining proof is entirely trivial [Sun Sep 29 19:35:03 2013] (my proof takes 45 characters) [Sun Sep 29 19:38:05 2013] robbert: thanks [Sun Sep 29 19:40:58 2013] to give a further hint, you can (and most sensibly have to) make that choice straight away after the intros [Sun Sep 29 19:43:14 2013] defanor: and yet another hint, try proving implies_to_or -> excluded_middle before, it may give you some insight [Sun Sep 29 19:45:44 2013] robbert: thanks again, going to try it now [Sun Sep 29 19:54:13 2013] yay, finally done with it [Sun Sep 29 19:58:07 2013] defanor: well done! [Mon Sep 30 09:57:06 2013] im trying to use the function 'In' as an if-condition [Mon Sep 30 09:57:31 2013] so that the if statement would return one thing if some element is in some list, and another thing otherwise [Mon Sep 30 09:57:33 2013] eg. [Mon Sep 30 09:57:35 2013] Definition test_in (e : nat) (list : list nat) : bool := [Mon Sep 30 09:57:35 2013] if (In e list) then true else false. [Mon Sep 30 09:57:39 2013] why does this not work? [Mon Sep 30 09:58:08 2013] Coq tells me: Error: The term "In e list" has type "Prop" which is not a (co-)inductive type. [Mon Sep 30 09:58:24 2013] what does that mean and how instead should i apply In? [Mon Sep 30 09:59:36 2013] In is not a decidable property. You need In_dec with a list that has decidable equality. [Mon Sep 30 10:05:02 2013] have to reboot, brb 2 mins [Mon Sep 30 10:09:23 2013] ianjneu, how do i tell in_dec about the lists decidability? It doesnt seem to automatically infer it [Mon Sep 30 10:10:38 2013] the lists equality decidability, i mean* [Mon Sep 30 10:14:50 2013] it seems to require something like (H : forall x y : A, {x = y} + {x <> y}) [Mon Sep 30 10:15:08 2013] but that notation doesnt make sense to me [Mon Sep 30 10:17:14 2013] what type of function is that, do i need to custom write one for the list type im using? [Mon Sep 30 10:17:33 2013] what does x = y + x <> y mean? [Mon Sep 30 10:18:35 2013] hm is that like a set with all x and y that are either equal xor not equal? [Mon Sep 30 10:19:37 2013] one sec [Mon Sep 30 10:21:03 2013] {x = y} + {x <> y} is a decision procedure for elements of the type A, where you're trying to decide in_dec for some list A. [Mon Sep 30 10:23:30 2013] If you have your type in hand but no decision procedure, you likely can define it with the "decide equality" tactic. [Mon Sep 30 10:23:54 2013] wait tactics are to be used in Proof mode arent they? [Mon Sep 30 10:25:20 2013] Definition my_eq_dec : the-dec-eq-type. decide equality. Defined. [Mon Sep 30 10:28:06 2013] cool works :) [Mon Sep 30 10:28:12 2013] thanks ianjneu [Mon Sep 30 10:34:49 2013] ianjneu, it doesnt work for this type: https://privatepaste.com/8f74555e33 [Mon Sep 30 10:35:05 2013] (the bottom type, i mean) [Mon Sep 30 10:35:07 2013] why is that? [Mon Sep 30 10:35:58 2013] it depends on other types having decidable equality. You have to apply letter_eq_dec and accent_eq_dec at the appropriate times. [Mon Sep 30 10:36:23 2013] Or you can duplicate their work and use "repeat decidable equality" [Mon Sep 30 10:37:35 2013] ha that works :p [Mon Sep 30 10:37:55 2013] decide equality; try solve [apply accent_dec | apply letter_dec]. [Mon Sep 30 10:38:01 2013] also works. [Mon Sep 30 10:39:24 2013] I don't know how to prove decidable equality without an annoying amout of work for something like Inductive S : Type := A : S | B : list S -> S. [Mon Sep 30 10:52:36 2013] hm [Mon Sep 30 10:53:24 2013] what if i want to state in a theorem (to be proven) that some letter is in some list? [Mon Sep 30 10:54:39 2013] eg. https://privatepaste.com/eae3d6b2d2 [Mon Sep 30 10:55:09 2013] Coq says Error: In environment r : list fletter The term "in_dec fl_eq_dec à r" has type "{In à r} + {~ In à r}" which should be Set, Prop or Type. [Mon Sep 30 10:57:28 2013] in_dec is useful for programming / proving. You want to use In for statements of propositions. [Mon Sep 30 10:57:50 2013] oh lol [Mon Sep 30 10:58:00 2013] yea In just works there :P [Mon Sep 30 10:58:05 2013] thanks [Mon Sep 30 11:03:00 2013] is there a function to inject an element at some specific point in a list? Eg. inject z 2 (a :: b :: c :: d :: nil) would be (a :: b :: z :: c :: d :: nil) [Mon Sep 30 11:03:28 2013] (or maybe overwrite that location) [Mon Sep 30 11:09:38 2013] i wrote a function myself but trying to replace as much code as i can by code from the stdlib, because it will probably make proofs a lot simpler [Mon Sep 30 11:09:58 2013] cook dinner bbl [Mon Sep 30 11:10:01 2013] <3 [Mon Sep 30 15:16:14 2013] do you guys know anything about this: "Integrating infinite data and coinduction with dependent types is tricky. For example, in the Calculus of (Co)Inductive Construc- tions, the core theory underlying Coq (INRIA 2012), coinduction is broken, since computation does not preserve types (Gim ́enez 1996)" [Mon Sep 30 15:17:17 2013] (from Wellfounded Recursion with Copattern paper) [Mon Sep 30 15:23:53 2013] sorry for off-topic question but are SMT-prover and SMT-solver same things? [Mon Sep 30 15:35:25 2013] osa1 yes :) [Mon Sep 30 15:36:32 2013] Anarchos: was that for first question or second one? [Mon Sep 30 15:36:41 2013] for the first [Mon Sep 30 15:37:04 2013] great, can you give me an example of this for demonstration? [Mon Sep 30 15:37:33 2013] does that mean we don't have preservation theorem for Coq? and if so, doesn't that make Coq an unsound system? [Mon Sep 30 15:37:33 2013] no sory i just have a slightly idea of what he said [Mon Sep 30 15:37:44 2013] ah ok [Mon Sep 30 15:38:00 2013] it just said that they had to insert cofixpoint as primitive (as fixpoint) to deal with infinite datas [Mon Sep 30 16:05:28 2013] hi could someone help me out? I'm getting a weird type error, but only when other type errors are present in a definition [Mon Sep 30 16:05:43 2013] in a separate case of a match [Mon Sep 30 16:05:58 2013] Here's the gist: https://gist.github.com/maxsnew/6769354 [Mon Sep 30 16:09:57 2013] maxiepoo let me look [Mon Sep 30 16:10:33 2013] it [Mon Sep 30 16:10:38 2013] 's very strange [Mon Sep 30 16:12:02 2013] TinConst takes only one parameter, not two [Mon Sep 30 16:12:49 2013] wops sorry not [Mon Sep 30 16:12:53 2013] yea [Mon Sep 30 16:13:04 2013] the type of (n,s) is a couple [Mon Sep 30 16:13:16 2013] the weird thing is that it says there's a type error in the TiNConst case [Mon Sep 30 16:13:22 2013] but you declare line 62 to be vstack ts' [Mon Sep 30 16:13:47 2013] but when you fix the error in the TiBinop case, it disappears [Mon Sep 30 16:14:06 2013] in the following line TiNConst has only one parameter : [Mon Sep 30 16:14:07 2013] | TiNConst : forall s, nat -> tinstr s (Nat :: s) [Mon Sep 30 16:14:58 2013] and it returns a function taking a nat [Mon Sep 30 16:15:06 2013] did you try (s,n) instead of (n,s) ? [Mon Sep 30 16:15:29 2013] no, that's not the bug [Mon Sep 30 16:15:36 2013] that case is actually correct [Mon Sep 30 16:15:39 2013] ok [Mon Sep 30 16:15:57 2013] maybe coq types cases in match in reverse order, as in ocaml [Mon Sep 30 16:16:11 2013] if you uncomment the tbinopDenote case and comment the one that's currently there [Mon Sep 30 16:16:15 2013] so the type of TiNConst is matched against TiBinop [Mon Sep 30 16:16:19 2013] then the whole thing typechecks [Mon Sep 30 16:16:55 2013] and works [Mon Sep 30 16:17:10 2013] what means the first ' in let '(arg1, (arg2, s')) := s in ? [Mon Sep 30 16:17:41 2013] it's special let syntax [Mon Sep 30 16:17:45 2013] I got this from the book [Mon Sep 30 16:17:53 2013] the Chlipala book [Mon Sep 30 16:18:15 2013] "Certified Programming with Dependent Types" [Mon Sep 30 16:18:20 2013] Chapter 2 [Mon Sep 30 16:18:23 2013] ok [Mon Sep 30 16:18:26 2013] i know this book [Mon Sep 30 16:18:45 2013] and I added pairs to the language [Mon Sep 30 16:18:50 2013] for the syntax error i am not skilled enough to spot it in a minute [Mon Sep 30 16:19:26 2013] it's not a syntax error though, that's what's so frustrating [Mon Sep 30 16:34:03 2013] which syntax error? [Mon Sep 30 16:38:51 2013] there isn't a syntax error [Mon Sep 30 16:38:51 2013] the problem is that at that point, the mechanism that tries to figure out the match's return type annotation has been disturbed by the second branch [Mon Sep 30 16:39:19 2013] why? [Mon Sep 30 16:40:00 2013] well it should return a vstack ts' where ts' is the second index of i [Mon Sep 30 16:40:23 2013] yes [Mon Sep 30 16:41:18 2013] but the second branch does not typecheck with respect to that [Mon Sep 30 16:41:20 2013] oh and also, I want to mention that the same error happens when the tBinop case is completely missing [Mon Sep 30 16:41:43 2013] so want I really want to know [Mon Sep 30 16:41:45 2013] is [Mon Sep 30 16:42:32 2013] is there something I can do to the first case so that it catches the errors in the `TiBinop` case instead of the `TiNConst` case [Mon Sep 30 16:42:57 2013] I had similar problems before, but I could just annotate them [Mon Sep 30 16:43:14 2013] for this one, I can't seem to annotate it properly to get the error to go away [Mon Sep 30 16:44:51 2013] oh [Mon Sep 30 16:45:24 2013] http://paste.awesom.eu/Ptival/YUo [Mon Sep 30 16:46:56 2013] Hurrah! [Mon Sep 30 16:47:06 2013] now would you mind explaining it to me? [Mon Sep 30 16:47:13 2013] explain the return annotation? [Mon Sep 30 16:47:15 2013] yeah [Mon Sep 30 16:47:39 2013] I haven't seen it before, I've just started the Chlipala book [Mon Sep 30 16:47:43 2013] ok [Mon Sep 30 16:49:24 2013] well the general form of an annotated match is 'match foo as x in T _ _ i1 i2 return R foo x i1 i2 with ... end' [Mon Sep 30 16:49:45 2013] the 'x' part allows you to bind the term being discriminated [Mon Sep 30 16:50:05 2013] the 'T _ _ i1 i2' part allows you to bind its type's indices [Mon Sep 30 16:50:25 2013] and then in the return part you can use all of these bound values [Mon Sep 30 16:50:53 2013] Ptival: meaning the 'in' part ascribes a specific (partially or completely) instantiated type to foo? [Mon Sep 30 16:50:57 2013] here you want to return "vstack ts -> vstack ts'" where ts and ts' are the indices of the constructor being matched [Mon Sep 30 16:51:35 2013] ystael: it doesn't really ascribe or instantiates no :\ [Mon Sep 30 16:52:01 2013] the T in the 'in' part is the type of 'foo' [Mon Sep 30 16:52:04 2013] oh, it's just a local binder for names for the indices? [Mon Sep 30 16:52:07 2013] yes [Mon Sep 30 16:53:20 2013] ah this makes sense [Mon Sep 30 16:53:23 2013] Ptival: thanks! [Mon Sep 30 16:53:24 2013] you say that foo has type 'T _ _ i1 i2', where the underscores are for parameters (that you don't really need to name because they are uniform), and the i1 i2 gives you a name in order to refer to the index in the return part [Mon Sep 30 16:53:49 2013] this way, in each branch, i1 and i2 become the index of that particular constructor [Mon Sep 30 16:54:31 2013] I tried working through this book some time ago and I sort of bounced off the problem of understanding dependent match annotations [Mon Sep 30 16:58:20 2013] yeah it took me a few tries before groking it [Mon Sep 30 16:58:46 2013] it's easy to explain on a whiteboard [Mon Sep 30 16:59:02 2013] not so much to write it up :) [Mon Sep 30 16:59:06 2013] ezyang: ^ [Mon Sep 30 18:25:13 2013] Hi, I am super new at Coq, what tactic would eliminate the same term from both sides of an inequality/equation? [Mon Sep 30 18:27:34 2013] injection? [Mon Sep 30 18:27:48 2013] joe______: could you be more precise (an example for instance)? [Mon Sep 30 18:31:37 2013] hmm say I am trying to show that op x + op y <= op x + op z [Mon Sep 30 18:31:46 2013] where x, y, z are nat [Mon Sep 30 18:34:08 2013] oh inequality [Mon Sep 30 18:34:09 2013] I misread [Mon Sep 30 18:35:21 2013] I don't think there is a tactic. You'll probably have to use theormes. [Mon Sep 30 18:35:22 2013] I don't think there's a tactic that simplifies this [Mon Sep 30 18:35:54 2013] if you have a op y <= op z, omega should finish, but otherwise you pretty much have to direct the reasoning here [Mon Sep 30 18:40:42 2013] hm, is there a simple example of the latter case? [Mon Sep 30 18:57:18 2013] I don't really have things set up for that now [Mon Sep 30 18:57:27 2013] SearchAbout (_ <= _) might helps [Mon Sep 30 19:11:41 2013] np, thanks for your help anyway [Mon Sep 30 19:16:01 2013] you'll probably want to apply something like (a <= b -> c <= d -> a + c <= b + d) [Mon Sep 30 19:16:05 2013] or maybe it'll be a [Mon Sep 30 19:16:31 2013] Proper (le ==> le ==> le) plus [Mon Sep 30 19:16:54 2013] but searching the stdlib is a pain [Tue Oct 1 03:04:27 2013] hello. I have a question with no practical meaning. "Goal forall A (a b : A) (P Q : a = b), P = Q." -- can this be proved without axioms? (I think it can't.) Which axioms are needed to prove it? Why anyone will want to prove it? [Tue Oct 1 03:13:55 2013] Maybe http://coq.inria.fr/stdlib/Coq.Logic.ProofIrrelevance.html is relevant to your proof? [Tue Oct 1 03:16:55 2013] really, it can finish the proof easily. (dumb me, forgot about it.) but the last question still holds. [Tue Oct 1 03:17:27 2013] Oh, and http://coq.inria.fr/stdlib/Coq.Logic.EqdepFacts.html has exactly what you said (Uniqueness of Identity Proofs). [Tue Oct 1 03:18:55 2013] yes. thanks. [Tue Oct 1 03:20:07 2013] (also i promise not to ask questions when i haven't woke up properly.) [Tue Oct 1 06:01:12 2013] gdsfh: That implies that [forall A P (a : A) (x y : P a), existT P a x = existT P a y -> x = y]. [Tue Oct 1 06:01:26 2013] This statement is unprovable without UIP. [Tue Oct 1 06:19:40 2013] jgross: got it. [Tue Oct 1 10:48:06 2013] gdsfh: the statement is provable if you specify to a type [A] with decidable equality [Tue Oct 1 10:52:11 2013] robbert: good to know. It seems I understand how to do it (and doubt I'll try). But nobody had answered _why_ anyone will ever want to prove an equality of equality-proofs. Maybe you know it? [Tue Oct 1 11:33:52 2013] gdsfh: Is proving that equality of the second of dependent pairs (sigma types) not enough of a reason to want to prove UIP? Alternatively/additionally, you can go look into homotopy type theory, which talks a lot about which proofs of equality are equal and which aren't (because, secretly, equalities are path spaces). [Tue Oct 1 12:26:08 2013] jgross: HoTT was an origin of my question: I've discussed it privately with someone who told me that it's cool to prove equalities of equality proofs. Equalities on values of sigma-types -- good point. (but handmade equality-like relation can be helpful too, that one that discards second component of dependent pair.) [Tue Oct 1 12:31:35 2013] If you want to discard the second component, the appropriate (HoTT) way to do it is to take the truncation of the second component, i.e., { x : A & |B x| } where |T| means "the type T, but with all elements identified". [Tue Oct 1 12:34:34 2013] If you're in a regime where you're not assuming UIP as an axiom, then it's useful to prove it for particular types, because then you get, e.g., the permission to use axiom-K-based pattern matching (which is nicer, in some cases); the ability to use that type as the morphisms of a precategory; the ability to use that type as the objects of a strict category; the ability to apply any theorem you've proven about hSets (discrete types), etc. [Tue Oct 1 13:38:29 2013] Has someone written an expository overview of the various "extra" axioms that are frequently added to base CoC and how they relate to each other? (Things like UIP, axiom K, etc) [Tue Oct 1 13:39:22 2013] When someone mentions one of these things I vaguely know what they're referring to, but not really what the implications are. [Tue Oct 1 13:48:00 2013] ystael: I seem to remember such a thing in the Coq FAQ [Tue Oct 1 13:49:10 2013] http://coq.inria.fr/faq?som=5#htoc36 [Tue Oct 1 13:49:57 2013] Ptival: I saw that - I was wondering if there existed anywhere a more in-depth exposition [Tue Oct 1 13:50:07 2013] ok, sorry [Tue Oct 1 13:50:35 2013] no, no, I wasn't clear, don't apologize! :) [Tue Oct 1 13:52:14 2013] Have you read this paper Hofmann/Streicher 'The groupoid interpretation of type theory' which is referred to from that section of the FAQ? maybe I should start there [Tue Oct 1 13:58:03 2013] no I don't know much either [Tue Oct 1 15:21:53 2013] hm [Tue Oct 1 15:24:18 2013] im trying to prove this: https://privatepaste.com/ce8bc29e4b [Tue Oct 1 15:25:31 2013] but in the definition of 'highest' ive used in_dec, and in the proof ive used In [Tue Oct 1 15:25:50 2013] the definition would not allow use of In, and the proof would not allow use of in_dec [Tue Oct 1 15:26:19 2013] how can i then still use the assumption of the proof when im unfolding 'highest'? [Tue Oct 1 15:26:41 2013] if that makes sense [Tue Oct 1 15:26:52 2013] roosbeef: look at the result type of in_dec [Tue Oct 1 15:27:22 2013] how? [Tue Oct 1 15:27:59 2013] in_dec a l has type {In a l} + {~ In a l} [Tue Oct 1 15:28:21 2013] ah, I see, you need to go the other way [Tue Oct 1 15:29:17 2013] you could try destructing the application of in_dec and obtaining a contradiction in the context in the cases that cannot hodl [Tue Oct 1 15:29:20 2013] hold [Tue Oct 1 15:30:26 2013] it's hard to say what to do without seeing the complete script [Tue Oct 1 15:30:54 2013] :p [Tue Oct 1 15:31:13 2013] could you at least paste the proof state at the point where you are stuck? [Tue Oct 1 15:31:31 2013] you can probably destruct an in_dec, but I can't really help blindly [Tue Oct 1 15:32:03 2013] i can paste the whole thing but its kinda big [Tue Oct 1 15:32:22 2013] (although i guess you guys have probably seen much worse) [Tue Oct 1 15:33:00 2013] ill isolate the relevant parts, brb [Tue Oct 1 15:35:55 2013] or at least the definition of highest [Tue Oct 1 15:38:44 2013] https://privatepaste.com/48cc92648b [Tue Oct 1 15:39:05 2013] should work in CoqIDE [Tue Oct 1 15:39:24 2013] the thing im trying to prove unfolds to huge proportions [Tue Oct 1 15:39:52 2013] so im just playing around with simplified subproblems [Tue Oct 1 15:40:54 2013] one could give a much simpler definition of 'highest'; do you have a particular reason for the definition you've chosen? [Tue Oct 1 15:41:18 2013] eh, wait, i may have misunderstood your intent [Tue Oct 1 15:41:53 2013] suggestions are very welcome :p [Tue Oct 1 15:42:52 2013] I would do it in the standard tail-recursive way with an auxiliary accumulator [Tue Oct 1 15:43:36 2013] Fixpoint highest (accum ll: list fletter) [Tue Oct 1 15:43:51 2013] where you add an element to accum if it is not equal to or dominated by any of the existing elements of accum [Tue Oct 1 15:44:31 2013] The flattening function extract_list seems like it makes things inconvenient [Tue Oct 1 15:45:37 2013] could you give an example of a function that uses this accum parameter? [Tue Oct 1 15:46:54 2013] Fixpoint fact_iter (accum n: nat): nat := match n with | O => accum | S n' => fact_iter (n * accum) n' end. [Tue Oct 1 15:47:04 2013] Definition fact (n: nat): nat := fact_iter 1 n. [Tue Oct 1 15:47:18 2013] I just typed that into the chat, it may be totally wrong. [Tue Oct 1 15:47:36 2013] lets have a look [Tue Oct 1 15:48:29 2013] (works) [Tue Oct 1 15:49:57 2013] This is just recognizing that what you're doing is a kind of fold [Tue Oct 1 15:52:56 2013] let me try and rewrite highest to a more simplified form [Tue Oct 1 16:14:42 2013] ystael, something like this? https://privatepaste.com/5d748d7869 [Tue Oct 1 16:17:36 2013] oh wait it returns nil :p that should be result [Tue Oct 1 16:20:49 2013] seems to do what its supposed to, but is that what you meant? Do you think it could be further simplified? [Tue Oct 1 16:21:06 2013] (library is almost closing btw, gotta leave in 5 min) [Tue Oct 1 16:24:41 2013] bools don't encode correctness information. [Tue Oct 1 16:25:09 2013] ianjneu, what do you mean by that [Tue Oct 1 16:25:46 2013] You can write your bool decision procedures, but you will need to show that f(args ...) = true implies some-property(args ...) and vice versa. [Tue Oct 1 16:26:10 2013] you mean that the current notation doesnt mean what it should? [Tue Oct 1 16:26:51 2013] If you write less-than as an inductive definition that is a proposition for what "less-than" means, you can write a correctness theorem for your boolean-returning functions. [Tue Oct 1 16:27:20 2013] Otherwise, you just get "true" or "false" out of the function and get no semantic information for later proofs. [Tue Oct 1 16:27:36 2013] can i get back to you later on this? [Tue Oct 1 16:27:47 2013] I should be around for another hour or so. [Tue Oct 1 16:27:47 2013] it sounds quite important but i dont have time to look into it atm :< [Tue Oct 1 16:27:54 2013] tomorrow maybe? [Tue Oct 1 16:28:01 2013] perhaps, sure. [Tue Oct 1 16:28:07 2013] cool [Tue Oct 1 16:28:10 2013] thanks guys :) [Tue Oct 1 16:28:27 2013] gotta run security is coming ;p [Wed Oct 2 06:51:35 2013] why does Coq not return a concrete answer here? [Wed Oct 2 06:51:36 2013] https://privatepaste.com/f94aba7317 [Wed Oct 2 06:51:54 2013] (see the last two computations) [Wed Oct 2 07:02:41 2013] i think it has to do with what ianjneu said last night [Wed Oct 2 07:02:54 2013] bools don't encode correctness information. [Wed Oct 2 07:02:54 2013] ianjneu, what do you mean by that [Wed Oct 2 07:02:54 2013] You can write your bool decision procedures, but you will need to show that f(args ...) = true implies some-property(args ...) and vice versa. [Wed Oct 2 07:02:54 2013] you mean that the current notation doesnt mean what it should? [Wed Oct 2 07:02:54 2013] If you write less-than as an inductive definition that is a proposition for what "less-than" means, you can write a correctness theorem for your boolean-returning functions. [Wed Oct 2 07:02:57 2013] Otherwise, you just get "true" or "false" out of the function and get no semantic information for later proofs. [Wed Oct 2 07:03:15 2013] not entirely sure what he meant by that however [Wed Oct 2 07:33:33 2013] bbl [Wed Oct 2 11:47:00 2013] where can I see Coq proofs for theorems listed here http://www.cs.ru.nl/~freek/100/ [Wed Oct 2 14:39:50 2013] seems "Rewrite" isn't allowed as a constructor name. What does that collide with? [Wed Oct 2 14:40:33 2013] It doesn't stand alone as vernacular, maybe "Hint Rewrite"? The only other thing I see in the tactic "rewrite", and a lowercase rewrite is allowed. [Wed Oct 2 15:27:41 2013] I think Hint Rewrite yes [Wed Oct 2 16:23:07 2013] can't I pattern match like [Wed Oct 2 16:23:07 2013] | odd x :: y => x :: oddmembers(y) [Wed Oct 2 16:23:09 2013] _ [Wed Oct 2 16:23:10 2013] ? [Wed Oct 2 16:23:41 2013] what would you want that to do? [Wed Oct 2 16:23:54 2013] You could have a fallthough clause | _ => nil [Wed Oct 2 16:23:59 2013] find all odd nat's of a list [Wed Oct 2 16:24:56 2013] Oh, odd isn't a constructor? You can't write it like one then [Wed Oct 2 16:25:11 2013] hm [Wed Oct 2 16:29:58 2013] why doesn't "Eval compute in even 3" return a bool? [Wed Oct 2 16:38:17 2013] nm, found a fixpoint even instead [Wed Oct 2 18:11:53 2013] ianjneu, around perhaps? [Wed Oct 2 18:13:09 2013] roosbeef: For 17 minutes. [Wed Oct 2 18:13:23 2013] :) [Wed Oct 2 18:13:44 2013] was hoping you could elaborate a bit on what you said yesterday [Wed Oct 2 18:13:54 2013] with regards to https://privatepaste.com/f94aba7317 [Wed Oct 2 18:14:06 2013] ah, bool versus proof [Wed Oct 2 18:14:13 2013] bools don't encode correctness information. [Wed Oct 2 18:14:13 2013] ianjneu, what do you mean by that [Wed Oct 2 18:14:13 2013] You can write your bool decision procedures, but you will need to show that f(args ...) = true implies some-property(args ...) and vice versa. [Wed Oct 2 18:14:13 2013] you mean that the current notation doesnt mean what it should? [Wed Oct 2 18:14:13 2013] If you write less-than as an inductive definition that is a proposition for what "less-than" means, you can write a correctness theorem for your boolean-returning functions. [Wed Oct 2 18:14:16 2013] Otherwise, you just get "true" or "false" out of the function and get no semantic information for later proofs. [Wed Oct 2 18:14:21 2013] yea [Wed Oct 2 18:14:51 2013] why is there a difference [Wed Oct 2 18:15:54 2013] Notice the types of "decision procedures" in Coq. They look like {P}+{~P}. In programs you can just say, "left or right, I know that P or ~P holds so I go and do something." [Wed Oct 2 18:16:18 2013] yep [Wed Oct 2 18:16:20 2013] And in proofs you can use proofs of P or ~P to do reasoning. [Wed Oct 2 18:16:30 2013] right [Wed Oct 2 18:16:52 2013] true + false give you the same ability to go left or right in a program, but they don't give you the same abilities in proofs. [Wed Oct 2 18:17:27 2013] what does a proof need then? [Wed Oct 2 18:18:46 2013] A proof needs evidence. Consider an inductive datatype that is all the rules of "a < b" [Wed Oct 2 18:19:06 2013] > is just flip of that, and you can use propositional equality for the Eq case. [Wed Oct 2 18:19:15 2013] roosbeef: as to why your compute doesn't work: Eval compute in highest (à :: nil). <-- should be Eval compute in highest (à :: nil) nil. (your Fixpoint takes a list and then another list to complete its job ;)) [Wed Oct 2 18:20:04 2013] oh lol [Wed Oct 2 18:20:11 2013] Your fl_compare should be an Inductive, where oa, ua, oe, ue, and uo are constructors. [Wed Oct 2 18:20:12 2013] RegEchse, i hadnt even noticed that :P [Wed Oct 2 18:20:39 2013] ianjneu, you would have written fl_compare differently? [Wed Oct 2 18:21:40 2013] RegEchse, thanks, that solves that i guess.. although any tips on simplifying or stylizing my code to make it behave better in proof mode is more than welcome [Wed Oct 2 18:21:52 2013] fl_compare can produce "comparison x y" where comparison also carries proofs, such that Lt carries "x < y" proofs, Gt carries "y < x" proofs and Eq carries "x = y" proofs. [Wed Oct 2 18:21:53 2013] roosbeef: and i guess "(* should be FrenchLetter o acute :: FrenchLetter o grave :: nil *) [Wed Oct 2 18:22:08 2013] " that should be "u acute" ... [Wed Oct 2 18:22:28 2013] :P [Wed Oct 2 18:23:06 2013] hm [Wed Oct 2 18:23:06 2013] roosbeef: as for simplifying ... sorry, i am myself a coq noob ;) [Wed Oct 2 18:23:47 2013] both should be o (since o dominates u), but they are in the wrong order, need to fix that [Wed Oct 2 18:24:04 2013] ianjneu, i still dont understand what you mean by carrying proofs [Wed Oct 2 18:24:30 2013] ianjneu, are those isgreater islesser isequal functions still needed when "carrying proof"? [Wed Oct 2 18:25:36 2013] Inductive comparison : fletter -> fletter -> Prop := Lt : forall x y : fletter, x < y -> comparison x y | Eq : forall x y : fletter, x = y -> comparison x y | Gt : forall x y : fletter, y < x -> comparison x y. [Wed Oct 2 18:26:11 2013] where < is defined also inductively. [Wed Oct 2 18:26:18 2013] is that from std lib or did you just custom write that [Wed Oct 2 18:26:30 2013] I just wrote that. [Wed Oct 2 18:27:02 2013] but comparison is a type from std lib right [Wed Oct 2 18:27:37 2013] I'm a bit out of touch with the std lib [Wed Oct 2 18:27:44 2013] :p ok [Wed Oct 2 18:28:05 2013] but youre saying that islesser isnt needed? [Wed Oct 2 18:28:09 2013] CompareSpec might be what you want [Wed Oct 2 18:28:46 2013] do you have an url for that? [Wed Oct 2 18:28:55 2013] http://coq.inria.fr/stdlib/Coq.Init.Datatypes.html [Wed Oct 2 18:29:25 2013] I have to head out. [Wed Oct 2 18:29:50 2013] alright man thanks a lot for helping [Wed Oct 2 18:29:52 2013] meh :p [Wed Oct 2 18:30:44 2013] roosbeef: sorry for that then, i didn't actually break down your 'highest' and thought it was a typo about your expected result rather than an implementation fault ;D [Wed Oct 2 18:31:09 2013] yea it is an implementation fault, the order should be reversed [Wed Oct 2 18:31:27 2013] i guess ill just add 'rev' to the nil case [Wed Oct 2 18:33:30 2013] ah, so highest is about to collect all elements that compare equal but are greater than the others, i guess. [Wed Oct 2 18:36:07 2013] yep [Wed Oct 2 18:36:18 2013] it finds the highest ranked letter [Wed Oct 2 18:36:28 2013] or letters if more than one have the same ranking [Wed Oct 2 18:42:49 2013] ok im off to sleep [Wed Oct 2 18:43:09 2013] thanks for your help RegEchse :) [Wed Oct 2 22:10:29 2013] hi guys. I'm finished Software Foundations book -- now can anyone recommend me some other book to learn dependently typed programming (not necessarily related with theorem proving) [Wed Oct 2 23:16:10 2013] osa1: have you read CPDT? [Wed Oct 2 23:16:45 2013] wait, i think we had this conversation already :) [Thu Oct 3 06:52:46 2013] trying to prove this seemingly simple thing [Thu Oct 3 06:53:26 2013] https://privatepaste.com/2f6035731e (at the bottom) [Thu Oct 3 06:54:28 2013] how do i tell Coq that it should apply parts of the unfolded function to some of its arguments? (so as to build the proof) [Thu Oct 3 06:58:31 2013] when im unfolding the function it just substitutes the function name with (fix function ...) [Thu Oct 3 06:59:13 2013] roosbeef: btw, your highest more or less reimplements fold; you might want to take a look at fold_(left|right). Here i rewrote your highest using fold_right: https://gist.github.com/J0J0/6807976 [Thu Oct 3 07:00:55 2013] hm [Thu Oct 3 07:01:05 2013] definitely appreciated but [Thu Oct 3 07:01:12 2013] in what way does that help? [Thu Oct 3 07:01:51 2013] i didn't look at your link from above. I just thought you wanted to know for future use :) [Thu Oct 3 07:02:22 2013] well it seems good to know, i strive to use std lib more [Thu Oct 3 07:16:34 2013] RegEchse, how would you approach proving such a thing? It's obviously true, right? [Thu Oct 3 07:41:42 2013] sorry, i'm kinda busy at the moment. But yes, your lemma seems to be obviously true. [Thu Oct 3 07:42:21 2013] if i had no idea how to start i'd use a pen and paper and try to infer the crucial point about the proof [Thu Oct 3 07:43:06 2013] sometimes coq's unfolding makes the obvious difficult to see (directly in coq), at least for me [Thu Oct 3 07:44:09 2013] well the crucial point i guess would be that highest l is a subset of l [Thu Oct 3 07:44:33 2013] mm no wait [Thu Oct 3 07:45:19 2013] yea, actually there is no causal connection [Thu Oct 3 07:45:31 2013] but its a tautology [Thu Oct 3 07:48:15 2013] actually, i guess a crucial point would be that a has the highest ranking of all letters [Thu Oct 3 07:48:54 2013] but how can i convince Coq of this? :/ [Thu Oct 3 07:51:21 2013] yes, that's what i'd think, too. and to me that smells like you have to destruct the "next letter of r" at some point, because if you've got actual fletters (not just variable of that type) coq should be able to simplify the matching done in your fl_compare [Thu Oct 3 07:53:00 2013] ah right [Thu Oct 3 07:53:13 2013] so like, a case by case analysis [Thu Oct 3 07:53:19 2013] why do you need the hypothesis In à r -> [Thu Oct 3 07:53:22 2013] btw? [Thu Oct 3 07:53:28 2013] In à (highest (à :: r) nil). [Thu Oct 3 07:53:30 2013] yea its unneeded haha, i removed it already [Thu Oct 3 07:53:40 2013] ah, ok [Thu Oct 3 07:53:42 2013] :D [Thu Oct 3 07:54:29 2013] yeah, but i guess once you destructed the letter deep enough every single case should like mostly the same. [Thu Oct 3 07:58:07 2013] hm [Thu Oct 3 07:58:20 2013] r can be infinitely large though right [Thu Oct 3 07:58:40 2013] when does the case analysis end then? Should i perform some sort of induction? [Thu Oct 3 08:03:28 2013] i'd prefer 'arbitrarily large', but since In x (h::t) becomes x=h \/ In x t and you prepend the à you should be done once you know that à is the first element of your resulting list. So, i think i should work out without an induction here [Thu Oct 3 08:04:13 2013] pretty much, but [Thu Oct 3 08:04:13 2013] *it [Thu Oct 3 08:04:26 2013] highest is applied somewhere along the line [Thu Oct 3 08:04:33 2013] which makes it less obvious [Thu Oct 3 08:19:59 2013] RegEchse, im only just realizing how much i like your rewritten version of highest, its not using isequal isgreater etc :) [Thu Oct 3 08:23:14 2013] the results parameter becomes obsolete as well [Thu Oct 3 08:29:43 2013] RegEchse, could you maybe explain a few things about the rewrite you did? [Thu Oct 3 08:34:44 2013] like for example, why does c l need to be in that order? I tried to do l c and reverse the arguments but that failed to work [Thu Oct 3 08:35:02 2013] and what exactly did fold_right do? [Thu Oct 3 08:49:18 2013] (my connection is acting up, i might have missed a msg) [Thu Oct 3 08:51:43 2013] bbl [Thu Oct 3 08:51:45 2013] no you didn't. [Thu Oct 3 08:51:49 2013] oh :p [Thu Oct 3 08:52:05 2013] i was just busy ;) [Thu Oct 3 08:52:14 2013] alright np [Thu Oct 3 08:53:03 2013] 14:23:14 roosbeef | the results parameter becomes obsolete as well <- yeah, i just copied your header, that's why my definition got that superfluously [Thu Oct 3 08:54:59 2013] ok, so what you actually want to understand is fold. http://www.cis.upenn.edu/~bcpierce/sf/Poly.html <- grep that for fold, there's a short explanation [Thu Oct 3 08:55:09 2013] with some examples [Thu Oct 3 08:55:53 2013] ah so it applies that function to each element of a list [Thu Oct 3 08:56:39 2013] but its more than just that, right? Because it combines the results to a single result [Thu Oct 3 08:56:42 2013] and i just updated the gist to include a proof of your lemma with my highest''. [Thu Oct 3 08:56:53 2013] yes [Thu Oct 3 08:57:19 2013] it starts at one end of the list, applying f elem default [Thu Oct 3 08:57:46 2013] then it goes to the next element of the list and does f elem result_of_last_call_to_f [Thu Oct 3 08:58:09 2013] why do c l have to be in that order? [Thu Oct 3 08:58:21 2013] ahh :) [Thu Oct 3 08:58:23 2013] that makes sense then [Thu Oct 3 08:59:49 2013] ok im gonna scrutinize this proof [Thu Oct 3 09:00:01 2013] thank you :) [Thu Oct 3 09:00:05 2013] be back later [Thu Oct 3 09:00:05 2013] <3 [Thu Oct 3 09:22:33 2013] looking at cpdt, working through ch.2. On page 20 he starts explaining Eval, there's a line there: `Eval simpl in expDenote (Const 42).` how does this get evaluated? [Thu Oct 3 09:24:02 2013] the next line is indented and has `= 42 : nat` is this the result of an evaluation, or something that needs to be in the source? [Thu Oct 3 09:24:47 2013] actually, looking at the source for StackMachine.v, it looks like that second line is commented. [Thu Oct 3 10:21:21 2013] robbert: congrats on your POPL acceptance [Thu Oct 3 12:30:53 2013] joneshf-laptop: that is the result of the evaluation [Thu Oct 3 12:32:03 2013] Ptival, thanks, i realized I was supposed to be evaluating those lines after i asked ;) [Thu Oct 3 12:37:14 2013] yeah [Thu Oct 3 12:51:12 2013] ah, so you hang out in #coq as well, joneshf-laptop :-) [Thu Oct 3 12:54:34 2013] reynir, i actually just joined [Thu Oct 3 12:54:57 2013] oh [Thu Oct 3 20:25:46 2013] hmm, so say I have a JMeq T1 t1 T2 t2, and a T1 = T2, what can I do? [Thu Oct 3 20:26:04 2013] also, t1 and t2 have different head constructors [Thu Oct 3 20:27:00 2013] you can deduce "coerce (eq : T1 = T2) t1 = t2" [Thu Oct 3 20:28:11 2013] can I derive False? [Thu Oct 3 20:29:15 2013] not that easy, e.g. eq could be an isomorphism that swaps those constructors [Thu Oct 3 20:29:56 2013] K would give you False [Thu Oct 3 20:30:10 2013] wait, eq can be an isomorphism in plain Coq? [Thu Oct 3 20:30:30 2013] I'm not doing hott [Thu Oct 3 20:30:39 2013] Ptival: well, you can't use it, but whatever you prove must be consistent with that [Thu Oct 3 20:30:48 2013] heh [Thu Oct 3 20:31:45 2013] i think you can prove "coerce eq" is an iso, so in the end you'd have to prove there's no iso f such that f t1 = t2 [Fri Oct 4 09:16:33 2013] i have a function max_natlist to return the highest nat in a list nat [Fri Oct 4 09:16:49 2013] trying to make it more efficient by rewriting it to use fold_right [Fri Oct 4 09:17:17 2013] https://privatepaste.com/e86e84bf11 (top: my first version, bottom: rewritten version not working yet) [Fri Oct 4 09:17:43 2013] why does it not work, anyone? [Fri Oct 4 09:18:24 2013] How does it not work? [Fri Oct 4 09:18:55 2013] well it says The term "c" has type "list nat" while it is expected to have type "nat". [Fri Oct 4 09:20:04 2013] does fold_right have to have list as return type? [Fri Oct 4 09:20:15 2013] No [Fri Oct 4 09:20:44 2013] switch the order of c and l [Fri Oct 4 09:20:51 2013] tried that, doesnt work :p [Fri Oct 4 09:20:58 2013] wait no [Fri Oct 4 09:21:05 2013] The term "lnat" has type "list nat" while it is expected to have type [Fri Oct 4 09:21:05 2013] "list (list nat)". [Fri Oct 4 09:21:19 2013] the arguments to the fun is not a list [Fri Oct 4 09:21:26 2013] it's an element of the list [Fri Oct 4 09:21:35 2013] ahh right [Fri Oct 4 09:21:37 2013] :) [Fri Oct 4 09:21:41 2013] Try check the type of fold_right [Fri Oct 4 09:23:08 2013] https://privatepaste.com/d18fba07d4 [Fri Oct 4 09:23:09 2013] this works [Fri Oct 4 09:23:18 2013] thanks a lot reynir :) [Fri Oct 4 09:23:55 2013] Now you can make it shorter by just writing max instead of (fun l c => max l c) :) [Fri Oct 4 09:24:54 2013] wow cool [Fri Oct 4 09:25:37 2013] If you want to make it *even* shorter you can drop the argument to max_natlist' and just write fold_right max 0 [Fri Oct 4 09:26:16 2013] So it would be [Definition max_natlist'' := fold_right max 0.] [Fri Oct 4 09:28:08 2013] geez [Fri Oct 4 09:28:10 2013] ;p [Fri Oct 4 09:28:59 2013] I'm trying to use ListSet, but I don't want to supply A and eq_dec to every function, is there a way to fill these parameters when importing? [Fri Oct 4 13:39:33 2013] hi [Fri Oct 4 13:40:05 2013] is there anyone around familiar with C-CoRN? [Fri Oct 4 14:13:58 2013] Panzani: I may be able to help, what do you need to know? [Fri Oct 4 14:32:03 2013] robbert: OK [Fri Oct 4 14:32:09 2013] i have a partial function [Fri Oct 4 14:32:13 2013] defined on IR [Fri Oct 4 14:32:23 2013] i'm multiplying this function by x [Fri Oct 4 14:32:46 2013] and i'd like to prove that the resulting function is indeed a partial function [Fri Oct 4 14:32:50 2013] defined on the same domain [Fri Oct 4 14:33:00 2013] (which looks silly and sounds trivial, yes) [Fri Oct 4 14:33:31 2013] but I feel like I cannot do that without classical logic [Fri Oct 4 14:33:58 2013] because partial function need some proof of f(x,Hx)#f(y,Hy) => x#y [Fri Oct 4 14:34:13 2013] functions* [Fri Oct 4 14:43:21 2013] Panzani: I guess you need the fact that [*] is a strong setoid morphism [Fri Oct 4 14:43:27 2013] that's called bin_op_strext_unfolded afaik [Fri Oct 4 14:45:41 2013] oh thanks, i'm gonna give it a try [Fri Oct 4 14:46:39 2013] damn [Fri Oct 4 14:46:47 2013] i've spent a couple of hours on this [Fri Oct 4 14:46:50 2013] it worked [Fri Oct 4 14:46:51 2013] thanks :) [Fri Oct 4 14:47:10 2013] no thanks! [Fri Oct 4 15:39:03 2013] Could coq be used to prove that something cannot be deduced? [Fri Oct 4 15:40:10 2013] Like that https://gist.github.com/dmalikov/cbe21c2947462822f2ce [Fri Oct 4 15:44:35 2013] It is certainly true that Coq can prove the negation of statements. [Fri Oct 4 15:50:25 2013] Have no idea how to write in coq smth like "having MI use rule1, rule2, rule3, rule4 many times and get MU" [Fri Oct 4 15:50:38 2013] Have no idea how to formulate these rules also :[ [Fri Oct 4 15:50:41 2013] Or define A* [Fri Oct 4 19:25:29 2013] help? [Fri Oct 4 19:26:09 2013] ollehar what about ? [Fri Oct 4 19:27:34 2013] pastebin ok? it's not hard [Fri Oct 4 19:28:11 2013] http://pastebin.com/eeaX3wXv [Fri Oct 4 19:29:01 2013] what tacit to use? [Fri Oct 4 19:29:07 2013] *tactic [Fri Oct 4 19:33:43 2013] Anarchos: ^ [Fri Oct 4 19:34:39 2013] or perhaps I need a theorem, like [Fri Oct 4 19:34:39 2013] forall x, eqnat x x = yes [Fri Oct 4 19:40:39 2013] yep, that worked [Fri Oct 4 19:45:13 2013] can I backstep or undo a tactic? [Fri Oct 4 20:55:24 2013] i'm stuck and need some advice, again. it's filter_challenge exercise from http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, and here is my progress: http://lpaste.net/2668364568555683840. looks like i need to show that something is wrong in context, but not sure if i'm on a right way [Fri Oct 4 21:02:21 2013] tried to apply iom_l1 in M also, but stucking there too [Sat Oct 5 06:08:31 2013] i have a data type that has two forms which are interconvertible [Sat Oct 5 06:09:14 2013] it has a string form with accents which indicate how to convert it into tree form, and the tree form can be flattened to string form as well [Sat Oct 5 06:10:01 2013] now i have to prove something for which the tree form needs to be used, but the actual proof (on paper) uses string form [Sat Oct 5 06:10:27 2013] so in Coq, a convertion function is thrown in there [Sat Oct 5 06:10:49 2013] which huuugely clutters the proof mode window [Sat Oct 5 06:11:19 2013] since the convertion is not super efficient [Sat Oct 5 06:11:21 2013] any ideas on how to tackle this? [Sat Oct 5 19:58:39 2013] sorry for the repetition, but i'm really stuck: http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, filter challenge exercise, current progress: clean one - http://lpaste.net/2668364568555683840, messy one - http://lpaste.net/8981362586914127872. looking for a hint/advice/suggestion [Sat Oct 5 21:27:23 2013] defanor: are you sure you state the lemma correctly? :) [Sat Oct 5 21:28:20 2013] peterbb: going to check now [Sat Oct 5 21:31:58 2013] oh, looks like i forgot about "every item in [l1] satisfies [test]", and probably i should use forallb for that [Sat Oct 5 21:32:09 2013] peterbb: thanks [Sat Oct 5 21:32:42 2013] np :) [Sat Oct 5 22:04:24 2013] I'm trying to state the following in coq: given a function f from set U to set V and subsets of U called A and B, f is injective iff f(A intersects B) = f(A) intersects f(B) [Sat Oct 5 22:04:36 2013] Goal forall (U V : Set) (A B : Ensemble U) (f : U -> V),injective U V f <-> (Im U V (Intersection U A B) f = Intersection V (Im U V A f) (Im U V B f)). [Sat Oct 5 22:04:49 2013] Does that look ok? [Sat Oct 5 22:13:07 2013] i'm not sure how to 'split' = though [Sat Oct 5 22:25:39 2013] rola: What about the axiom Extensionality_Ensembles from Ensembles? [Sat Oct 5 22:27:23 2013] ah yes [Sat Oct 5 22:49:45 2013] a question about the next exercise from http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, filter_challenge_2: subsequences are mentioned here, but they are defined just for [list nat] before (in Prop.v), so should i prove filter_challenge_2 just for lists of natural numbers then? btw, why is it just about natural numbers in Prop.v? [Sat Oct 5 22:53:25 2013] it's probably not important for the exercise itself, i'm just curious about it [Sun Oct 6 10:01:08 2013] I was working through Software Foundations in emacs with proof general, and everything was going fine until I reached http://www.cis.upenn.edu/~bcpierce/sf/Poly.html#slide-5 [Sun Oct 6 10:01:15 2013] but now I'm getting "Error: Unknown command of the non proof-editing mode." [Sun Oct 6 10:03:16 2013] I'm looking through the reference manual at the moment, but if you have any pointers, I'd appreciate it [Sun Oct 6 10:07:26 2013] slide-5 isn't a tag in the page you linked to. What in particular is the problem? Did you remember to require the SF libraries? [Sun Oct 6 10:08:27 2013] funny, it took me right to it in firefox [Sun Oct 6 10:09:37 2013] ianjneu: I've been working through the .v files in the offline version [Sun Oct 6 10:09:37 2013] ijp: all the a tag names are "lab" [Sun Oct 6 10:10:07 2013] Ah. Well, are you using coq 8.4 or 8.3? The book was written for 8.3 [Sun Oct 6 10:10:25 2013] it's an id, not a name [Sun Oct 6 10:10:34 2013] Im using 8.3pl3 [Sun Oct 6 10:11:22 2013] well, iono :P [Sun Oct 6 10:14:09 2013] anyway if that link isn't working, my issue is with the directive "Arguments nil {X}." [Sun Oct 6 10:16:03 2013] I'm sorry that the question is a bit rubbish, but I've using this since yesterday and I still don't know my left from my southwest. [Sun Oct 6 10:35:40 2013] okay, I think I have the solution [Sun Oct 6 10:35:47 2013] "Before version 8.4 the command to specify the implicit arguments of a constant was Implicit Arguments followed by a bracketed list of identifiers. Starting with Coq 8.4 the Argument command must be used (see 2.7.4)." [Sun Oct 6 10:36:09 2013] So it looks like I should be using Implicit Arguments nil [[X]] instead on 8.3 [Sun Oct 6 10:41:25 2013] Can I get a hint on where to go from here? http://lpaste.net/raw/6379171004689678336 [Sun Oct 6 10:56:07 2013] rola: Firstly, you should use set equality in your proposition rather than intensional equality. [Sun Oct 6 10:58:52 2013] n/m [Sun Oct 6 10:59:25 2013] ? [Sun Oct 6 11:01:00 2013] nevermind [Sun Oct 6 11:08:41 2013] Im_def immediately applies after induction H, H; subst. [Sun Oct 6 11:14:13 2013] thanks! [Sun Oct 6 11:27:16 2013] not seeing a way to prove the other direction. [Sun Oct 6 11:30:47 2013] Your quantification doesn't match your comment [Sun Oct 6 11:41:45 2013] Your comment makes it look like you should be proving this [Sun Oct 6 11:41:46 2013] forall (UT VT : Set) (U : Ensemble UT) (V : Ensemble VT) (f : Ensemble UT -> Ensemble VT), [Sun Oct 6 11:41:49 2013] injective _ _ f <-> forall (A B : Ensemble UT), Included UT A U -> Included UT B U -> (f (Intersection _ A B)) = (Intersection _ (f A) (f B)). [Sun Oct 6 11:45:44 2013] what does the underscore do? [Sun Oct 6 11:50:06 2013] leaves it for inference [Sun Oct 6 11:59:10 2013] whoops, for some reason i thought A : Ensemble U meant A was a subset of U [Sun Oct 6 12:01:21 2013] g2g good luck [Sun Oct 6 23:44:53 2013] http://sprunge.us/PIfI Regarding the hypothesis H in the link, is there a tactic similar to decompose that would break it down? [Sun Oct 6 23:53:13 2013] rola: depends what you mean by decompose [Sun Oct 6 23:53:39 2013] you can apply H to two ensembles and two inclusion proofs to obtain an equality [Mon Oct 7 00:04:22 2013] I can? [Mon Oct 7 11:03:26 2013] hi, do you know an automatic way to generate a proof of equality of two records from the all proofs of equalities of projections ? [Mon Oct 7 11:07:42 2013] of course, I would like it to work for any record (I don't want an ad-hoc solution for each particular record). [Mon Oct 7 12:43:39 2013] mrl42: Are you asking about record types, or terms of some particular record type? [Mon Oct 7 12:43:39 2013] mrl42: If the former: You need univalence for that. Given "Record True := I {}." and "Record unit := tt {}.", you can't prove "unit = True" without univalence. If you have univalence, go look at the [issig] tactics in theories/types/Record.v of HoTT/HoTT on github, for a tactic which proves equivalence of a record with the appropriate nested sigT type. Since equivalence is transitive, if you prove two records equivalent to equal nested sigT [Mon Oct 7 12:43:39 2013] types (and you should have that proof of equality via your equality of fields), then you can get that the two record types are equivalent. Then you can use univalence to get that they're equal. [Mon Oct 7 12:43:39 2013] mrl42: If the latter: The tactic [repeat (subst || simpl in * || f_equal)] should suffice if every field of each term is a variable (i.e. not some specific expression), and you have the appropriate hypotheses of equality in your context. I usually make a separate lemma for each record type that I use, so that I don't need to do finicky [generalize]ing each time I want to apply it (also for speed). [Mon Oct 7 12:46:07 2013] So, for example: [Mon Oct 7 12:46:07 2013] Set Implicit Arguments. [Mon Oct 7 12:46:07 2013] Record prod (A B : Type) := pair { fst : A ; snd : B }. [Mon Oct 7 12:46:07 2013] Goal forall A B (x y : prod A B), [Mon Oct 7 12:46:07 2013] fst x = fst y -> snd x = snd y -> x = y. [Mon Oct 7 12:46:07 2013] Proof. [Mon Oct 7 12:46:07 2013] intros; destruct x, y; simpl in * [Mon Oct 7 12:46:07 2013] repeat (subst || simpl in * || reflexivity || f_equal). [Mon Oct 7 12:46:07 2013] Qed. [Mon Oct 7 12:46:07 2013] (I haven't tested it, but I think it'll work.) [Mon Oct 7 12:47:33 2013] it was the latter [Mon Oct 7 12:47:49 2013] I've just discover the existence of the tactic f_equal [Mon Oct 7 12:48:04 2013] but it seems very buggy when you have dependent type see for instance : [Mon Oct 7 12:48:24 2013] Variable R : Type. [Mon Oct 7 12:48:24 2013] Variable A : Type. [Mon Oct 7 12:48:24 2013] Variable B : A -> Type. [Mon Oct 7 12:48:24 2013] Variable f : forall x:A, B x -> R. [Mon Oct 7 12:48:24 2013] Lemma test : forall x y x' y', f x y = f x' y'. [Mon Oct 7 12:48:26 2013] intros. [Mon Oct 7 12:48:29 2013] f_equal. [Mon Oct 7 12:49:36 2013] What do you want it to do, there? Give you a goal that [eq_rect = y']? [Mon Oct 7 12:50:30 2013] oh, I want it to ask me to prove x = x', rewrite, then ask me for proving y = y', and rewrite [Mon Oct 7 12:50:45 2013] obviously it is not possible from the context I've given :) [Mon Oct 7 12:52:10 2013] The rewrite isn't possible in general unless [x] and [x'] are variables. [Mon Oct 7 12:54:27 2013] It's also the case that the proof you want might be impossible (without axioms) unless you know what the proof of [x = x'] looks like. [Mon Oct 7 12:58:11 2013] For example, [existT (fun x => x) bool true = existT (fun x => x) bool true] isn't provable via all proofs that [bool = bool]. (That is, if you run your tactic such that it asks you for a proof that [existT (fun x => x) bool = existT (fun x => x) bool], and then you run it again, and give [eq_refl : existT (fun x => x) = existT (fun x => x)], then you can't show that all proofs that you give it of [bool = bool] will result in [ bool across that proof> = true] (and if you have univalence, there are some proofs of [bool = bool] that send true to false when you cast across them). [Mon Oct 7 13:00:43 2013] I don't understand [Mon Oct 7 13:00:59 2013] on your example, there's nothing to do. reflexivity works. [Mon Oct 7 13:01:26 2013] my lemma "test" was a stupid example since it is not provable [Mon Oct 7 13:01:41 2013] here is a provable one : [Mon Oct 7 13:02:15 2013] Lemma test : [Mon Oct 7 13:02:15 2013] forall x y x' y', forall h : x = x', [Mon Oct 7 13:02:16 2013] eq_rect x B y x' h = y' -> f x y = f x' y'. [Mon Oct 7 13:03:09 2013] oh, no, wait :) [Mon Oct 7 13:03:19 2013] I see. [Mon Oct 7 13:04:14 2013] no, no, no, no, I don't see :). [Mon Oct 7 13:05:07 2013] I don't understand why f_equal could not always work even when you have dependent types. [Mon Oct 7 13:52:20 2013] Not quite the counterexample you're looking for: it's possible to prove [existT (fun x => x) bool true = existT (fun x => x) bool false] using univalence, but not if you run [f_equal] first. [Mon Oct 7 13:56:54 2013] Alternatively, if you have univalence, and "Inductive bool1 := true1 | false1." and "Inductive bool2 := true2 | false2.", you can prove "existT (fun x => x) bool1 true1 = existT (fun x => x) bool2 true2", but you need the right proof of [bool1 = bool2] (in particular, it needs to send true1 to true2). So if you have an opaque proof [H : bool1 = bool2], you can't actually prove [eq_rect _ _ true1 _ H = true2]. [Mon Oct 7 14:14:33 2013] thanks jason [Tue Oct 8 17:48:12 2013] Is it so that using "dependent induction" does not work inside a "match goal with ..."? See: https://gist.github.com/peterbb/6892368 [Tue Oct 8 17:49:34 2013] (Program is loaded, btw). [Tue Oct 8 18:07:40 2013] why is the extension .v as opposed to .coq or similar? [Tue Oct 8 18:08:29 2013] vernacular i think [Tue Oct 8 18:09:28 2013] hmm, I see [Tue Oct 8 18:12:19 2013] so, historical :) [Wed Oct 9 10:15:33 2013] if i have in proof mode a hypothesis of the form 'if condition then True else False', can i convert this into a hypothesis of the form 'condition'? [Wed Oct 9 10:17:51 2013] or at least use it to prove condition by assumption? [Wed Oct 9 10:39:03 2013] how can i destruct variables that are inside (fix f ...) constructs? [Wed Oct 9 10:48:51 2013] (be right back) [Wed Oct 9 11:27:12 2013] anyone? [Wed Oct 9 11:29:39 2013] roosbeef: hello [Wed Oct 9 11:33:48 2013] hey ianjneu :) [Wed Oct 9 11:33:53 2013] would you happen to know this? [Wed Oct 9 11:34:00 2013] how can i destruct variables that are inside (fix f ...) constructs? [Wed Oct 9 11:34:28 2013] for example, [Wed Oct 9 11:34:41 2013] You want to reduce under lambda? [Wed Oct 9 11:35:14 2013] (not sure what you mean by 'reduce under lambda'?) [Wed Oct 9 11:35:43 2013] for example https://privatepaste.com/2df3bdc8ed - if i do destruct fs', coq tells me Error: The reference fs' was not found in the current environment. [Wed Oct 9 11:37:08 2013] hmm [Wed Oct 9 11:38:12 2013] I don't have enough context to play with it myself, but from what I see, fs' should be in scope for pattern matching. [Wed Oct 9 11:39:10 2013] https://privatepaste.com/3a052d0a20 [Wed Oct 9 11:39:44 2013] it's yelling about line 16? [Wed Oct 9 11:40:01 2013] yea thats the one im trying to destruct [Wed Oct 9 11:40:24 2013] hm i guess there's multiple instances of fs' [Wed Oct 9 11:41:56 2013] Oh, you're trying to use the destruct fs' tactic on this term? That's different. [Wed Oct 9 11:42:14 2013] how is that? [Wed Oct 9 11:42:49 2013] You'll need to reduce so that fs' gets substituted with some value in scope that you can destruct. [Wed Oct 9 11:43:20 2013] what do you mean by 'reduce'? [Wed Oct 9 11:43:29 2013] like, simpl [Wed Oct 9 11:43:39 2013] or compute [Wed Oct 9 11:44:07 2013] ((lambda (x) x) 0) reduces to 0 [Wed Oct 9 11:44:53 2013] its not possible to destruct fs' before then? [Wed Oct 9 11:46:31 2013] no, destruct is just a match term constructor, so since fs' isn't in scope to match on (it's an inner binding in some subterm) [Wed Oct 9 11:46:37 2013] you can't. [Wed Oct 9 11:46:42 2013] I have a talk to go to. [Wed Oct 9 11:46:44 2013] bbl [Wed Oct 9 11:46:47 2013] alright man [Wed Oct 9 11:46:53 2013] thanks for helping :) [Wed Oct 9 11:48:41 2013] roosbeef: what happens if you destruct on s? [Wed Oct 9 11:54:41 2013] that works [Wed Oct 9 11:54:54 2013] it creates subgoals with different cases of s [Wed Oct 9 12:05:49 2013] but they should simplify down, right? those pattern matches should reduce then [Wed Oct 9 12:11:38 2013] i guess [Wed Oct 9 12:11:46 2013] but fs' is still there, and i would like to destruct it :p [Wed Oct 9 12:12:59 2013] what do you get after destructing s [Wed Oct 9 12:13:58 2013] the same but with different subgoals for each case of s [Wed Oct 9 12:15:10 2013] but in that first big stratify_rec call, fs' is fs, and fs is s ++ (l::nil) ++ r [Wed Oct 9 12:15:27 2013] so you should be able to rewrite by some lemmas to get the match on fs' to collapse [Wed Oct 9 12:16:41 2013] how? [Wed Oct 9 12:17:56 2013] I don't remember the names exactly but in the s = [] case you want the left identity lemma for ++, forall (A: Set) (l: list A), [] ++ l = l [Wed Oct 9 12:18:40 2013] and in the s = g::s' case you want some combination of associativity for :: and ++ that will get the string into the form g::(some stuff) [Wed Oct 9 12:18:49 2013] how does that help? [Wed Oct 9 12:18:54 2013] simpl already does that i think [Wed Oct 9 12:19:53 2013] If :: isn't the outermost call on the expression that ultimately becomes fs', simpl won't reduce the match, I think [Wed Oct 9 12:20:29 2013] how does all of this relate to destructing fs' though? [Wed Oct 9 12:20:46 2013] You can't destruct fs'. It's lambda bound. [Wed Oct 9 12:20:52 2013] ah [Wed Oct 9 12:20:56 2013] What you want to do is get the pattern match on fs' to reduce, right? [Wed Oct 9 12:21:45 2013] right [Wed Oct 9 12:23:10 2013] the way to do that is to manipulate the expression (s ++ (l::nil) ++ r) which is going to be substituted in as fs' [Wed Oct 9 12:23:40 2013] why is that necessary? [Wed Oct 9 12:24:33 2013] it has to fit the options 'nil' or 'h :: t'? [Wed Oct 9 12:24:39 2013] Exactly [Wed Oct 9 12:24:51 2013] ahaa [Wed Oct 9 12:25:00 2013] ok that makes sense :) [Wed Oct 9 12:25:27 2013] so basically i should just try and get that original expression to form a single and straight forward list [Wed Oct 9 12:25:33 2013] yeah [Wed Oct 9 12:25:48 2013] to have :: as the outermost function call, so that the pattern match on fs' sees it [Wed Oct 9 12:25:57 2013] right [Wed Oct 9 12:26:11 2013] awesome that clarifies a lot :D [Wed Oct 9 12:26:17 2013] thanks very much [Wed Oct 9 12:26:55 2013] np, good luck [Wed Oct 9 12:27:10 2013] You can configure autorewrite hints using Hint Rewrite if you are using some sets of equations very often [Wed Oct 9 12:27:33 2013] app_nil_l and app_nil_r are the ones you were talking about i think [Wed Oct 9 12:27:55 2013] I haven't had very good luck with that feature but there are people much smarter than I am who have very good results with it [Wed Oct 9 12:28:19 2013] i have never used Hint Rewrite [Wed Oct 9 12:28:30 2013] maybe ill look into it later [Wed Oct 9 12:29:06 2013] hm [Wed Oct 9 12:29:18 2013] how do i apply app_nil_r to that expression though :p [Wed Oct 9 12:29:37 2013] app_nil_r doesn't apply [Wed Oct 9 12:29:57 2013] In the s = [] case, you may need to use app_assoc first so that you have [] ++ ((l::nil) ++ r), then app_nil_l should do the job [Wed Oct 9 12:30:03 2013] my bad, app_nil_l [Wed Oct 9 12:30:19 2013] I don't remember the associativity of ++, you'd think it would be right [Wed Oct 9 12:32:06 2013] hm [Wed Oct 9 12:32:08 2013] i have (nil ++ (l :: nil) ++ nil) [Wed Oct 9 12:32:32 2013] but Coq says Error: Impossible to unify "?1385 ++ ?1386 ++ ?1387 = (?1385 ++ ?1386) ++ ?1387" with [Wed Oct 9 12:38:05 2013] eg. https://privatepaste.com/ac9ba39078 [Wed Oct 9 12:51:47 2013] can I switch around the order in which I prove the the goals from e.g. a destruct, or induction. [Wed Oct 9 14:05:41 2013] ijp: You may be looking for Focus, as in Focus 2. to temporarily switch to the second goal [Wed Oct 9 15:07:08 2013] in proof mode, is there a way to substitute? For example, match ft_compare (stratify (nil ++ (l :: nil) ++ nil)) (stratify (nil ++ x ++ nil)) with ... [Wed Oct 9 15:07:33 2013] would it be possible to substitute nil ++ list_x with just list_x? [Wed Oct 9 15:08:12 2013] or (l :: nil) ++ list_x to l :: list_x? [Wed Oct 9 15:11:20 2013] roosbeef: you want the tactic replace ... with ... [Wed Oct 9 15:11:25 2013] http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic117 [Wed Oct 9 15:12:01 2013] ystael: yes, that is basically what I was after, thanks [Wed Oct 9 15:14:10 2013] roosbeef: There is also the `at` clause to rewrite which can be used to rewrite only a specific occurrence of a lemma's matching expression, but I find it frustrating to use [Wed Oct 9 15:17:23 2013] cool that works perfectly, thanks ystael! :) [Wed Oct 9 16:40:58 2013] "Inductive Nat := O: Nat | S: Nat -> Nat". How can I make this more "verbose"? I.e. I want to write "Inductive Nat := O: Nat | S: forall (n: Nat), ... " [Wed Oct 9 16:41:01 2013] but I don't know what to put in the for ... [Wed Oct 9 16:44:07 2013] just Nat [Wed Oct 9 16:44:20 2013] awesome, thanks! [Wed Oct 9 16:44:53 2013] in fact "A -> B" abbreviates "forall x : A, B" [Wed Oct 9 16:45:04 2013] with x not in B [Thu Oct 10 05:30:44 2013] hi, naïve question here: I have something of type « forall x0 y0, (fun x y => Some_type) x0 y0 » why isn't it just « forall x0 y0, Some_type » ? isn't it equivalent? [Thu Oct 10 05:33:47 2013] apparently I can coerce without any problem, so the question remains: why doesn't it simply automatically? [Thu Oct 10 07:15:01 2013] rks`: use the "simpl", "lazy beta" tactic or something similar [Thu Oct 10 07:36:16 2013] robbert: hmm? [Thu Oct 10 07:36:25 2013] It's the type inferred for a piece of code [Thu Oct 10 07:36:31 2013] (no tactics involved) [Thu Oct 10 07:42:26 2013] rks`: in that case, why does it matter? Types are equivalent up to convertability [Thu Oct 10 07:44:05 2013] right [Thu Oct 10 07:44:09 2013] just making sure [Thu Oct 10 07:45:36 2013] (but why isn't it reduced "by default" so?) [Thu Oct 10 10:30:59 2013] i'm stuck again, and again asking for an advice. it's http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, the last exercise: i've tried to use the given lemmas and excluded_middle, but it looks almost like a mess already, and i can't find a way to show that there is a contradiction in context. here is my current progress: http://lpaste.net/6545470175590744064 [Thu Oct 10 12:28:25 2013] so after unfolding a few functions, the proof window looks like this: https://privatepaste.com/5f12f65002 [Thu Oct 10 12:30:04 2013] any tips on how to work large unfolds like that? Comments welcome as well, maybe my code is inefficiently written? [Thu Oct 10 12:32:34 2013] roosbeef: I try to avoid large goals like that; my instinct would be to pull back several steps and see if I can extract some lemmas to get reductions without unfolding explicitly [Thu Oct 10 12:32:48 2013] but I don't have enough experience doing truly difficult proofs to give any better advice than that [Thu Oct 10 12:33:00 2013] hm [Thu Oct 10 12:33:20 2013] yea maybe i should think up some sublemmas [Thu Oct 10 12:34:55 2013] the property to prove isnt that complicated [Thu Oct 10 12:35:45 2013] Sometimes `generalize` can be your friend for discovering lemmas [Thu Oct 10 12:36:16 2013] if you have a complicated subterm that appears several times and is making the goal more complex than it really needs to be [Thu Oct 10 12:36:30 2013] how does that work? [Thu Oct 10 12:37:02 2013] ah it makes it more readable right [Thu Oct 10 12:38:05 2013] If you generalize too far it can turn a true goal into a false goal! But sometimes it also makes things easier to prove [Thu Oct 10 12:38:31 2013] hm :p [Thu Oct 10 12:41:36 2013] the property im trying to prove is basically that, in some order >, x :: z > y :: z, given that x > y [Thu Oct 10 12:42:30 2013] that sounds like exactly the generality you should prove it in then [Thu Oct 10 12:42:32 2013] which is really as simple as it seems, but to establish that, both x :: z and y :: z need to pass through a convertion function, to convert their list/string form to a tree form [Thu Oct 10 12:42:38 2013] ah, ok [Thu Oct 10 12:42:55 2013] and that convertion function is hugely clogging up the proof [Thu Oct 10 12:43:34 2013] can you instead transport the order on trees to the order on lists and then prove a correctness theorem for the transport of the order? [Thu Oct 10 12:43:49 2013] or, maybe this theorem you're trying to prove is basically that correctness theorem [Thu Oct 10 12:48:13 2013] ill have to think about it [Thu Oct 10 12:48:36 2013] thanks for your suggestions [Thu Oct 10 12:48:40 2013] gotta run [Thu Oct 10 12:48:41 2013] <3 [Fri Oct 11 07:40:09 2013] Is there any easy way to pattern-match the result of "lt_eq_lt_dec x y" (lt_eq_lt_dec from Coq.Arith.Compare_dec). [Fri Oct 11 07:40:10 2013] ? [Fri Oct 11 07:41:44 2013] Never mind. I should have just RTFM. :-| [Fri Oct 11 11:55:47 2013] sorry for the repetition, but will try to ask again: [Fri Oct 11 11:55:49 2013] i'm stuck again, and again asking for an advice. it's http://www.cis.upenn.edu/~bcpierce/sf/Logic.html, the last exercise: i've tried to use the given lemmas and excluded_middle, but it looks almost like a mess already, and i can't find a way to show that there is a contradiction in context. here is my current progress: http://lpaste.net/6545470175590744064 [Fri Oct 11 11:59:43 2013] What proof are you aiming for? [Fri Oct 11 12:00:28 2013] induction on l2 seems like a bad idea [Fri Oct 11 12:02:25 2013] um, i think i didn't get the question, but i'm aiming to prove the pigeonhole_principle theorem. and thanks for the advice, will try to go by other way [Fri Oct 11 12:03:59 2013] I think you should be able to eliminate right away cases other than l1 being non-empty with a tail exactly as long as l2 [Fri Oct 11 12:06:04 2013] not sure if that usefully uses the earlier definitions, but to finish you'd prove that every element of l2 appears in the tail of l1, so you can't cons on the head [Fri Oct 11 12:07:07 2013] napping: thanks, going to try now [Fri Oct 11 12:07:36 2013] I haven't finished a proof of the pigeonhole principle myself :( [Fri Oct 11 12:08:40 2013] i'm trying not to skip any exercises, but looks like it'll take a long time to finish the book this way =\ [Fri Oct 11 12:09:30 2013] but it's fun most of the time anyway [Fri Oct 11 12:32:11 2013] ah, looks like excluded middle should only be necessary for comparing values [Fri Oct 11 12:32:33 2013] what's a good tool for printing ssreflect proofs in latex? [Fri Oct 11 12:57:37 2013] defanor: also ended up needing it for deciding whether, even when length l1 = length l2, the tail of l1 already has repeats [Fri Oct 11 12:58:01 2013] (which would be decidable given an equality predicate) [Fri Oct 11 12:59:30 2013] I got thing to go through making use of the lemmas by proving an auxiliary lemma saying that (forall x, appears_in x l2 -> appears_in x l1) if (forall x, appears_in x l1 -> appears_in x l2), ~ repeats l1, and the lengths are equal [Fri Oct 11 19:36:23 2013] How would you prove this: Goal forall (f : forall A, A -> A), f = (fun _ => fun x => x). [Fri Oct 11 19:53:59 2013] you'd have to postulate parametricity, then you can prove that forall x, f x = x [Fri Oct 11 19:54:15 2013] Is parametricity independent of CiC? [Fri Oct 11 19:54:33 2013] yep [Fri Oct 11 19:54:44 2013] oh dear. [Fri Oct 11 19:54:54 2013] it's anti-classical [Fri Oct 11 19:54:59 2013] so you wouldn't want it to follow [Fri Oct 11 19:55:22 2013] So, what's the standard parametricity axiom? [Fri Oct 11 19:55:36 2013] dinaturality gets you some of the way there, but I don't think there's a single one [Fri Oct 11 19:55:45 2013] ewww [Fri Oct 11 19:56:11 2013] well, it's a family of axioms really [Fri Oct 11 19:56:13 2013] there's this thing I wrote a while back, but Saizan pointed out that I can cheat with something like that [Fri Oct 11 19:56:14 2013] https://gist.github.com/copumpkin/2907135 [Fri Oct 11 19:57:12 2013] ezyang: this is a good starting point http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Libraries.LightweightFreeTheorems [Fri Oct 11 19:57:31 2013] Hmm, looking at the HoTT folks, it looks like they don't have a good idea what is going on here either [Fri Oct 11 19:57:52 2013] I like how this is all Agda ^^" [Fri Oct 11 19:58:39 2013] I think bob atkey had a recent paper on parametricity and noether's theorem, but I don't think much of "traditional math" uses it much [Fri Oct 11 19:59:43 2013] well, the actual paper from bernardy is less agda-ish, and the tool linked is more haskellish [Fri Oct 11 20:01:05 2013] parametricity goes all the way back to semantics for System F [Fri Oct 11 21:40:56 2013] copumkin: What paper talks about noether's theorem and parametricity? [Fri Oct 11 21:40:56 2013] ezyang: There's a computational interpretation of parametricity (and in which parametricity is itself parametric). Googling "computational interpretation of parametricity" should get you it (I'd link it, but my internet is slow right now). [Fri Oct 11 21:43:58 2013] http://publications.lib.chalmers.se/publication/153094-a-computational-interpretation-of-parametricity <- yeah, from bernardy too [Sat Oct 12 14:05:53 2013] "... a good parser for Type 0 grammars would probably make a good starting point for a theorem prover". can anyone explain me that sentence? how is theorem proving and parsing type 0 grammars related? [Sat Oct 12 14:24:11 2013] A parser for a type 0 grammar is a Turing machine? [Sat Oct 12 14:25:43 2013] Or do they really mean a parser for the grammars themselves (strings containing production rules) [Sat Oct 12 14:29:28 2013] I have no ideas [Sat Oct 12 14:31:51 2013] If we interpret it the way I did at first, I can see where they're coming from. You can encode the rules of your logic as productions, and then the problem of determining whether there's a proof of some statement becomes the same problem as parsing the statement with this grammar. [Sat Oct 12 14:33:03 2013] So they mean theorem prover in the sense of a program which searches for proofs, rather than a program which checks them. [Sat Oct 12 14:33:08 2013] (perhaps) [Sat Oct 12 16:38:51 2013] is there an IRC channel to ask questions regarding to parsing, parsers, grammars etc. [Sat Oct 12 16:40:29 2013] osa1: there is ##parsers in list [Sat Oct 12 16:40:53 2013] oh wow I had tried #parsers and nobody was there ... thanks [Sat Oct 12 16:41:04 2013] 24 ppl in ##parsers :-S [Sat Oct 12 16:41:04 2013] yw [Sun Oct 13 05:46:12 2013] i'm still stuck on the pigeonhole_principle from http://www.cis.upenn.edu/~bcpierce/sf/Logic.html. napping has suggested a useful lemma, which makes it easy to prove, but now i'm stuck on that lemma, and need one more advice. current progress: http://lpaste.net/5611770566345228288 [Sun Oct 13 06:05:28 2013] and another question: how could i disable switching to a new line after C-c C-n in proof general? [Sun Oct 13 06:05:41 2013] *to a next line [Sun Oct 13 11:05:03 2013] i'll skip that exercise for now, but need to decide which way to follow further. how long, in relation to everything before the Logic chapter in Software Foundations, will take reading/solving other chapters, which are recommended for one-semester course at http://www.cis.upenn.edu/~bcpierce/sf/deps.html? and how much time, also in relation to those previous chapters, could take all the other chapters? [Sun Oct 13 11:09:28 2013] before the Logic chapter -- and including it [Mon Oct 14 05:01:36 2013] Hi, guys. [Mon Oct 14 05:02:27 2013] hi! [Mon Oct 14 07:41:25 2013] I started software-foundations and doing first example. [Mon Oct 14 07:41:55 2013] But I want not to prove table of truths but proove that "nandb x y = negb (andb x y)". [Mon Oct 14 07:42:11 2013] And I want to do it without manual case exploration. [Mon Oct 14 07:42:27 2013] There is bool_ind, which takes predicate to prove. [Mon Oct 14 07:42:37 2013] But I don't know how to put the goal into it. [Mon Oct 14 07:42:59 2013] Is it possible or should I use any kind of "reflexion" (if I use this word correctly)? [Mon Oct 14 07:45:14 2013] So, my goal is `(x : bool) (y : bool), nandb x y = negb (andb x y)' and I want to prove it with `bool_ind <2-ary-goal> ', but don't know how to do it inCoq. [Mon Oct 14 07:52:53 2013] s/second-arg-is-false/first-arg-is-false/g [Mon Oct 14 08:26:10 2013] kirillt: using _ind for such simple cases is not justified usually. why not "destruct x; destruct y; now (simpl; reflexivity)" or something like this? [Mon Oct 14 08:50:02 2013] gdsfh, didn't know about `now' tactic, thank you. [Mon Oct 14 08:50:34 2013] gdsfh, `now (destruct x; destruct y; simpl; reflexivity)' does what I want. [Mon Oct 14 08:53:13 2013] kirillt: it should work without "now", i suppose. [Mon Oct 14 09:07:22 2013] gdsfh, really, you are right. [Mon Oct 14 09:08:11 2013] gdsfh, so actions, separated with ';' are done for every alternative? [Mon Oct 14 09:15:12 2013] gdsfh: for every goal generated by previous tactic (or for the original goal when no goal generation happened). [Mon Oct 14 09:42:52 2013] gdsfh, nice, thank you. [Mon Oct 14 10:56:05 2013] Does the stdlib have a function forall A : Type, False -> A or similar? [Mon Oct 14 11:10:10 2013] @check False_rect [Mon Oct 14 11:10:15 2013] False_rect : ∀ P : Type, False → P [Mon Oct 14 11:10:23 2013] reynir: ^^^ [Mon Oct 14 11:13:20 2013] Thank you [Mon Oct 14 17:34:21 2013] How to prove such: 'Example ble_nat_succ : forall x, ble_nat x (S x) = true.'? [Mon Oct 14 17:34:34 2013] How to perform inductive step? [Mon Oct 14 17:34:46 2013] Should I use nat_ind? [Mon Oct 14 17:48:09 2013] hmm depends on how ble_nat is defined, but probably yeah [Mon Oct 14 17:50:56 2013] Ptival, how to insert nat_ind into proof? [Mon Oct 14 17:53:25 2013] kirillt: there is a tactic called induction, if you need it for the exercise it should have been introduced earlier in the chapter [Mon Oct 14 17:54:45 2013] Ptival, I have a habit to do boring exercises in a different way, there is other task. [Mon Oct 14 17:54:51 2013] I see [Mon Oct 14 17:54:52 2013] Ptival, thank you for the tip. [Mon Oct 14 17:54:59 2013] well if you want to not use tactics [Mon Oct 14 17:55:05 2013] you can try "apply nat_ind." [Mon Oct 14 17:55:19 2013] Ptival, tactic is ok, didn't know about name of it. [Tue Oct 15 07:24:15 2013] What tactic is used for expanding function name to its definition? [Tue Oct 15 07:24:32 2013] I tried compute, but it gives strange result. [Tue Oct 15 07:24:44 2013] And I thinks it does more actions. [Tue Oct 15 07:27:28 2013] I want to convert `f (S n)' to term which defines f and then simplify pattern matching step with (S n). [Tue Oct 15 07:28:37 2013] But `compute' somehow converts `f (S n)' to ` n' (sic!). [Tue Oct 15 07:28:52 2013] It somehoe lost my `S'. [Tue Oct 15 07:30:28 2013] Oh, I found it. [Tue Oct 15 07:30:31 2013] `unfold' [Tue Oct 15 07:30:42 2013] But somehow it lost 'S', too. [Tue Oct 15 07:31:45 2013] you can try 'simpl' too [Tue Oct 15 07:37:36 2013] kirillt: S was "simplified" -- compute decided to unfold function one more time, since it knows the shape of argument (it is S n), and stopped when the shape is unknown (n, which can be O or S _). As for fine-grained reductions, you may be interested in these tactics: cbv, lazy, hnf, red (maybe i've forgot some). [Tue Oct 15 09:45:21 2013] why doesnt coq replace this with its computed value? [Tue Oct 15 09:45:23 2013] https://privatepaste.com/7f8cd6bade [Tue Oct 15 09:46:56 2013] Eval compute in fl_compare (FrenchLetter a acute) (FrenchLetter a acute).= Eq : comparison [Tue Oct 15 09:47:17 2013] my connection dropped, sorry if im reposting [Tue Oct 15 09:47:26 2013] why doesnt coq replace this with its computed value? [Tue Oct 15 09:47:26 2013] https://privatepaste.com/7f8cd6bade [Tue Oct 15 09:47:26 2013] Eval compute in fl_compare (FrenchLetter a acute) (FrenchLetter a acute).= Eq : comparison [Tue Oct 15 10:14:30 2013] nevermind, had to do compute [Tue Oct 15 14:22:06 2013] is there a standard lemma for saying that if for all x , f x = g x, then f = g [Tue Oct 15 14:23:53 2013] ijp: proof irrelevance [Tue Oct 15 14:24:14 2013] i think [Tue Oct 15 14:28:35 2013] ijp: hmm actually i'm not sure you even need that. eta-conversion is one of the things coq 8.4 gives you, so there may be a more direct way [Tue Oct 15 14:32:29 2013] It's not provable, you need the axiom in FunctionalExtensionality. [Tue Oct 15 14:35:47 2013] shergill: eta-conversion is that (fun x => f x) = f. [Tue Oct 15 14:36:07 2013] So I don't think it would be of much help here. [Tue Oct 15 14:37:15 2013] peterbb: shergill: thanks [Tue Oct 15 15:20:31 2013] What to do with cases like 'false = true' when I split by cases my assertion? [Tue Oct 15 15:20:49 2013] I mean I want to prove e.g. `x = y -> y = x'. [Tue Oct 15 15:21:16 2013] And I do `destruct x; destruct y; compute', but I have now false hypothesis, too. [Tue Oct 15 15:28:11 2013] kirillt: `contradiction` will prove your goal from an absurd hypothesis [Tue Oct 15 15:29:00 2013] ystael, oh, ye, I see now [Tue Oct 15 15:29:16 2013] ystael, but what defference with `absurd'? [Tue Oct 15 15:29:20 2013] *diff [Tue Oct 15 15:29:39 2013] And how it knows when something is False? [Tue Oct 15 15:29:40 2013] by "absurd" I mean "the tactic can figure out that it is False" [Tue Oct 15 15:31:03 2013] ystael, ah ok [Tue Oct 15 15:31:17 2013] I think some step in that tactic is smart enough to use `discriminate` (which is a tactic that directly proves False from an equation between two values with different type constructors) [Tue Oct 15 15:31:20 2013] ystael, there is also tactic called `absurd'. [Tue Oct 15 15:31:21 2013] I don't know what step that is [Tue Oct 15 15:32:16 2013] `absurd` declares that you intend to prove by reductio ad absurdum, that is, `absurd P` replaces any goal by two goals P and ~P [Tue Oct 15 15:32:26 2013] Hmm, seems that Coq cannot find `contradiction' tactic. But I see it on the web-site. [Tue Oct 15 15:32:42 2013] ysteal, understood, thanks [Tue Oct 15 15:35:32 2013] You could also prove your original goal (and not just for bool) by [intros. subst. reflexivity.] [Tue Oct 15 16:34:36 2013] So I heard you can break type preservation in Coq by mixing inductive and coinductive data somehow, but I can't find anything about it online [Tue Oct 15 16:35:08 2013] Is that true and if so could someone give me a link to an explanation? [Tue Oct 15 18:09:40 2013] maxiepoo: http://permalink.gmane.org/gmane.science.mathematics.logic.coq.club/3608 [Tue Oct 15 18:21:33 2013] robbert gnééééé [Tue Oct 15 18:21:51 2013] gonthier, did he forgot to speak in a *normal* language ? [Tue Oct 15 18:22:09 2013] last time i saw him was in 2001, he seemed to be sane at this time :) [Tue Oct 15 19:59:55 2013] I saw him this summer and he seemed sane :p [Tue Oct 15 20:00:39 2013] Who's that? [Tue Oct 15 20:04:18 2013] Gonthier? [Tue Oct 15 20:04:47 2013] Why the question mark? [Tue Oct 15 20:05:11 2013] are you asking who he is? [Tue Oct 15 20:05:27 2013] I joined the channel right after "I saw him this summer and he seemed sane :p". [Tue Oct 15 20:05:33 2013] So I think I got the answer I was looking for. [Tue Oct 15 20:05:36 2013] ok [Tue Oct 15 20:05:37 2013] yeah [Tue Oct 15 22:15:18 2013] is there a tactic like unfold, but that only unfolds a recursive function one step [Tue Oct 15 23:00:19 2013] ijp: You can try [unfold f; fold f], which sometimes works. You can also try [cbv delta [f]; cbv beta at 1; fold f] (or maybe [at 0] rather than [at 1]?), but I'm not sure. I don't think there's a reliable way to do it. [Wed Oct 16 02:09:42 2013] yeah unfold will consume as much input as it can if the head constructor for the recursive call is known I believe [Wed Oct 16 02:09:51 2013] oh he's gone anyway [Wed Oct 16 04:57:36 2013] Is there something like `undefined' in haskell? [Wed Oct 16 04:57:46 2013] I want to mock one case in pattern-matching. [Wed Oct 16 04:58:18 2013] undefined it is [Wed Oct 16 04:58:39 2013] admit [Wed Oct 16 04:59:05 2013] ah wait, in a definition? [Wed Oct 16 05:00:04 2013] in a definition, if it is only temporary, I would use an axiom undefined [Wed Oct 16 05:00:57 2013] but if you know this case is not useful, either you can build a garbage object of this type, or you would need to take some property which would imply False for this branch [Wed Oct 16 08:08:33 2013] suppose H0: P, H1: P -> Q [Wed Oct 16 08:09:04 2013] if my goal is Q, how can i use H1 for this? [Wed Oct 16 08:12:02 2013] nevermind, apply H1 first and then H0 i guess [Wed Oct 16 08:32:17 2013] hm [Wed Oct 16 08:32:33 2013] https://privatepaste.com/6aea51a5a2 [Wed Oct 16 08:32:36 2013] would this work somehow? [Wed Oct 16 08:32:57 2013] seems to me like it would be possible to apply IHx first, and then H [Wed Oct 16 08:33:03 2013] but Coq wont have it [Wed Oct 16 08:54:00 2013] in the following proof: https://privatepaste.com/3b7c3c4740 [Wed Oct 16 08:54:19 2013] why does the final step 'assumption' work? [Wed Oct 16 08:54:29 2013] the goal is not in the assumptions [Wed Oct 16 09:35:07 2013] it is impossible to define incorrect (contradictory) proof objects, right? [Wed Oct 16 09:35:34 2013] (without contradictory axioms, at least) [Wed Oct 16 09:36:14 2013] assuming there aren't any bugs in the type checker [Wed Oct 16 09:36:29 2013] yep, thanks [Wed Oct 16 10:09:58 2013] roosbeef: regarding the last example, if you do a "simple" before doing "assumption", you will see that they are equivalent. assumption does this kind of computation automatically. [Wed Oct 16 12:24:06 2013] Hello. I'm trying to implement a multithreaded algorithm with synchronization on semaphores/mutexes, but I can't convince myself that it will work correctly. Are there any relatively simple ways to formalize such things in Coq? [Wed Oct 16 12:27:20 2013] (why I need to do such sh.t -- I found out that fcntl (to synchronize file access; via OCaml's Unix.lockf) takes 60 microseconds, and it's too slow for my task, so I need some home-made readers-writer locks storage.) [Wed Oct 16 12:30:04 2013] (btw, links to rwlock implementations via semaphores/mutexes are welcome too; my google-fu seems to be broken, I can't find any decent implementation.) [Wed Oct 16 13:40:36 2013] Hi, guys. [Wed Oct 16 13:40:55 2013] I have problem with example from software foundations. [Wed Oct 16 13:41:21 2013] Assertion to prove is `forall b c, andb b c = true -> b = true'. [Wed Oct 16 13:42:37 2013] But example uses `Case' tactics which somehow cannot be interpreted on my system (error is e.g. `No interpretation for string "b = true"'). [Wed Oct 16 13:43:24 2013] I commented it out, but in example there is `rewrite <- H' which doesn't work for me (maybe because of lack of Case steps). [Wed Oct 16 13:44:11 2013] Full proof is `Proof. intros b c H. destruct b. Case "b = true". reflexivity. Case "b = false". rewrite <- H. reflexivity. Qed.'. [Wed Oct 16 13:44:35 2013] I tried to prove also via `contradict H' and got False goal, but don't know what to do next. [Wed Oct 16 13:46:45 2013] kirillt: dumb way: "destruct b; destruct c; simpl; discriminate" or like. If it doesn't work, show your hypotheses and goal. [Wed Oct 16 13:50:09 2013] kirillt: which version of coq do you have? the proof works for me without the Case tactics [Wed Oct 16 13:53:40 2013] kirillt: This is an error in Software Foundations, or something. Case tactics are found on cocorico wiki: http://coq.inria.fr/cocorico/Case%20%28tactic%29 [Wed Oct 16 13:53:51 2013] This is not the only case where SF relies on something from cocorico without saying so. [Wed Oct 16 14:00:08 2013] kirillt: are you copying from the html? [Wed Oct 16 14:00:37 2013] if you download the tarball, there are .v files and the code for Case tactics is included in a few of the files [Wed Oct 16 14:01:43 2013] Induction.v and SfLib.v [Wed Oct 16 14:01:48 2013] ijp, ye, I have seen the code archive; but didn't search for Case there. [Wed Oct 16 14:01:58 2013] ijp, so Case isn't standard? [Wed Oct 16 14:02:18 2013] ystael, I see page, but don't see what to import for et Case work [Wed Oct 16 14:02:53 2013] gdsfh, 8.3pl4 [Wed Oct 16 14:03:11 2013] (it was to gereedy) 8.3pl4 [Wed Oct 16 14:03:34 2013] kirillt: paste that piece of code into a file to import [Wed Oct 16 14:04:02 2013] How 'rewrite <- H' can solve it? It converts 'false = true' into 'false = andb false c'. [Wed Oct 16 14:04:26 2013] ystael, there is no library or something? [Wed Oct 16 14:04:27 2013] kirillt: what happens when you reduce 'andb false c' ? [Wed Oct 16 14:04:34 2013] kirillt: It's not in the standard library, no. [Wed Oct 16 14:05:21 2013] As ijp said, the implementation on that wiki page or something similar is included in the SF sources tar; or you can do what I did and just make your own mini-library. [Wed Oct 16 14:06:06 2013] ystael, ye, I understood. Just thought that there is lib with all such utility code. [Wed Oct 16 14:06:29 2013] btw, suddenly 'rewrite <- H. reflexivity.' works for me, too. [Wed Oct 16 14:06:31 2013] But how? [Wed Oct 16 14:06:51 2013] Reflexivity is when `a = a`, but we have contradiction. [Wed Oct 16 14:07:43 2013] It's OK to derive a proof from impossible hypotheses without explicitly observing that the hypotheses are impossible :) [Wed Oct 16 14:08:52 2013] kirillt: reflexivity also works when the two sides of the equation reduce to the same value [Wed Oct 16 14:09:14 2013] in this case, probably if you do the tactic `simpl.`, `andb false c` reduces to `false` [Wed Oct 16 14:09:36 2013] Ptival, ystael, ah, ok, understood [Wed Oct 16 14:10:06 2013] for instance, `1 + 1 = 2` by reflexivity [Wed Oct 16 14:11:04 2013] but not `S a + b = a + S b`, because one of the sides would not reduce [Wed Oct 16 14:11:16 2013] in which case you have to do some rewriting [Wed Oct 16 14:11:36 2013] to reason equationally rather than computationally [Wed Oct 16 14:14:58 2013] Hm, how to include SfLib.v or Induction.v into my source? [Wed Oct 16 14:15:10 2013] `Export SfLib.' doesn't work. [Wed Oct 16 14:15:35 2013] SfLib.v is compiled, both .v and .vo files are in the same directory. Error is "SfLib isn't module.". [Wed Oct 16 14:16:05 2013] Source file name <> module name? [Wed Oct 16 14:17:53 2013] Require Export SfLib? [Wed Oct 16 14:18:46 2013] Really. [Wed Oct 16 14:19:01 2013] Thanks, everything work now! [Wed Oct 16 14:24:04 2013] im a bit confused to how induction works [Wed Oct 16 14:24:18 2013] for example in this proof https://privatepaste.com/3b7c3c4740 [Wed Oct 16 14:24:24 2013] the final step is 'assumption' [Wed Oct 16 14:24:32 2013] but H does not match the goal [Wed Oct 16 14:24:41 2013] why does Coq still accept 'assumption' then [Wed Oct 16 14:26:47 2013] roosbeef: for the exact same reason that I just told kirillt about :) [Wed Oct 16 14:27:00 2013] ha whats that [Wed Oct 16 14:27:06 2013] (i was offline at that time i think) [Wed Oct 16 14:27:07 2013] if you simpl your goal, it reduces exactly to the type of your assumption [Wed Oct 16 14:27:22 2013] so their reduced form is exactly the same [Wed Oct 16 14:27:45 2013] hm [Wed Oct 16 14:28:11 2013] but why in this case does it reduce to that [Wed Oct 16 14:28:20 2013] S n is not the same as n is it? [Wed Oct 16 14:30:26 2013] look at the definition of nat_compare [Wed Oct 16 14:31:25 2013] and think about what it reduces to when called with `S (n + x)` and `S (n + y)` [Wed Oct 16 14:31:44 2013] ah, right [Wed Oct 16 14:31:51 2013] the final clause [Wed Oct 16 14:31:57 2013] :) [Wed Oct 16 14:32:13 2013] im trying to prove something that has to do with a comparison between lists [Wed Oct 16 14:32:49 2013] but the decisive elements of those lists are in the middle of the list [Wed Oct 16 14:33:12 2013] (eg. see https://privatepaste.com/0258feaf52) [Wed Oct 16 14:34:30 2013] if im comparing two lists, (a ++ x :: b) and (a ++ y ++ b), do i need to perform induction on a, b and y? (as those are all lists) [Wed Oct 16 14:35:18 2013] or just on y, as that is the decisive list (a and b dont play a determining factor because they are on both sides of the comparison) [Wed Oct 16 14:36:39 2013] my connection dropped for a minute, hopefully all came through [Wed Oct 16 14:41:22 2013] using apply on a hypothesis will unfold definitions to find an appropriate product, is there any way to get auto to do the same (even for specific definitions, Hint Unfold and Hint Transparent seem only to affect the goal) [Wed Oct 16 15:04:41 2013] in general, does 'induction' split up the goal in subgoals A and B, where you need to prove A and can prove B by induction hypothesis? [Wed Oct 16 15:05:11 2013] or do you need to prove both [Wed Oct 16 15:31:42 2013] oh, napping, there you are! [Wed Oct 16 15:31:53 2013] I got thing to go through making use of the lemmas by proving an auxiliary lemma saying that (forall x, appears_in x l2 -> appears_in x l1) if (forall x, appears_in x l1 -> appears_in x l2), ~ repeats l1, and the lengths are equal -- have you proved this lemma? [Wed Oct 16 15:32:05 2013] yeah [Wed Oct 16 15:32:11 2013] it makes whole proof easy, but i'm stuck on it [Wed Oct 16 15:32:43 2013] could you give me some advice about this lemma? [Wed Oct 16 15:33:11 2013] the trick in stating it was to start with a forall n, and then say that the lengths are both equal to n, so you can do induction on the identical lengths [Wed Oct 16 15:33:24 2013] (maybe you could do something with the "remember" tactic anyway) [Wed Oct 16 15:34:03 2013] thanks, going to try [Wed Oct 16 15:34:35 2013] inside it, lots of the little lemmas about membership and appending become useful [Thu Oct 17 07:26:13 2013] I want to use Coq.Lists.List's notation. I imported the just mentioned module. Is there anything else I have to import? [Thu Oct 17 07:26:24 2013] I want to use [1,2,3] [Thu Oct 17 08:14:37 2013] hmm anyone? [Thu Oct 17 08:27:37 2013] Is there built-in analog of ble_nat from software-foundations? [Thu Oct 17 08:27:49 2013] I.e. function `nat -> nat -> bool'. [Thu Oct 17 08:45:03 2013] there is le but this is Prop not bool. [Thu Oct 17 09:09:30 2013] can I somehow directly desctruct tuples as function arguments? [Thu Oct 17 09:10:37 2013] e.g. Fixpoint myfun (a,b) := a (without an explicit match) [Thu Oct 17 10:09:49 2013] yezariaely: If you're still looking to get list notation you need to Require Import List. Import ListNotations. Open list_scope. [Thu Oct 17 10:12:08 2013] and the notation is [1;2;3] not [1,2,3] [Thu Oct 17 10:32:24 2013] hm [Thu Oct 17 10:32:57 2013] im kinda stuck with this simple proof for a couple weeks now [Thu Oct 17 10:33:13 2013] a major sticking point i think is the inefficiency of some of my code [Thu Oct 17 10:34:11 2013] anyone care to check out a selection of functions i think are the major obstructors? [Thu Oct 17 10:36:46 2013] i think simplifying these would greatly reduce the bloat in proof mode [Thu Oct 17 10:37:45 2013] but they perform a relatively complex task and im not sure how to further simplify [Thu Oct 17 10:42:31 2013] roosbeef: what are you stuck on? [Thu Oct 17 10:43:51 2013] gereedy, one sec ill put up an example [Thu Oct 17 10:45:29 2013] gereedy: thx! [Thu Oct 17 10:47:04 2013] gereedy: however it doesn't work for me. Error: ListNotations is not a module [Thu Oct 17 10:47:56 2013] gereedy, https://privatepaste.com/60b23dc3e4 [Thu Oct 17 10:48:31 2013] gereedy, the function i would like to simplify is 'stratify' and its components (stratify_sub and stratify_rec) [Thu Oct 17 10:49:34 2013] its at the bottom [Thu Oct 17 10:49:35 2013] yezariaely: I guess you must be using coq 8.3 [Thu Oct 17 10:49:54 2013] ive added relevant code above [Thu Oct 17 10:50:01 2013] gereedy: your guess is correct [Thu Oct 17 10:50:30 2013] For which version is it? [Thu Oct 17 10:51:43 2013] 8.4 [Thu Oct 17 10:52:26 2013] In 8.3 the list notation is done as a local notation but in 8.4 it is in a Module [Thu Oct 17 10:52:46 2013] as far as I know there isn't any way to get at that local notation, other than to copy it into your code [Thu Oct 17 10:58:24 2013] gereedy: thx again. [Thu Oct 17 11:14:18 2013] roosbeef: maybe a different structure for term would help [Thu Oct 17 11:14:55 2013] like Inductive fterm := TermNil : fterm | TermConsString : fstring -> fterm -> fterm | TermConsTerm : fterm -> fterm -> fterm. [Thu Oct 17 11:19:07 2013] gereedy, interesting [Thu Oct 17 11:19:26 2013] that would be functionally equivalent to its current definition? [Thu Oct 17 11:19:30 2013] I think that is isomorphic to your fterm [Thu Oct 17 11:19:38 2013] but makes the interleaving explicit [Thu Oct 17 11:20:08 2013] I think TermConsString could actually be TermConsLetter replacing the fstring with fletter [Thu Oct 17 11:20:27 2013] why? [Thu Oct 17 11:24:03 2013] becase f (TermConsString nil ft') = ft' and f (TermConsString (fl::fs) ft') = TermConsLetter fl (f (TermConsString fs ft')) is a morphism [Thu Oct 17 11:24:57 2013] it is essentially a nested list structure [Thu Oct 17 11:26:59 2013] yea [Thu Oct 17 11:27:08 2013] sounds good :) [Thu Oct 17 11:27:13 2013] im gonna give that a shot [Thu Oct 17 11:27:26 2013] been stuck on this approach for too long now [Thu Oct 17 11:27:35 2013] thanks very much! :) [Thu Oct 17 11:27:43 2013] sure, hope it helps [Thu Oct 17 13:44:12 2013] I am just wondering: what if I try to prove function definition? [Thu Oct 17 13:44:32 2013] E.g. `Definition length' : natlist -> nat.' [Thu Oct 17 13:44:41 2013] `Proof. intro xs.' [Thu Oct 17 13:45:07 2013] What's next how to formulate definition-term in terms of tactics? [Thu Oct 17 13:45:11 2013] Is it possible? [Thu Oct 17 13:45:38 2013] According Curry-Howard correspondence there is no difference, if I understand it correctly. [Thu Oct 17 13:47:10 2013] Proof of type `nat' must be concrete instance, but how to provide it via tactics? [Thu Oct 17 13:47:14 2013] kirillt: it's possible, but it's not recommended to build computational terms with tactics. Try, for example, "Definition add (a b : nat) : nat. auto. Defined." [Thu Oct 17 13:47:42 2013] kirillt: I'll build correct length with tactics, wait some time. [Thu Oct 17 13:49:34 2013] Theres is the low level 'fix' tactic for that. [Thu Oct 17 13:49:46 2013] But guardedness is chec [Thu Oct 17 13:49:59 2013] ked at Qed time [Thu Oct 17 13:50:04 2013] kirillt: http://paste.in.ua/8872/ [Thu Oct 17 13:50:40 2013] It is often safer tou [Thu Oct 17 13:50:53 2013] use induction tactic rather than fix [Thu Oct 17 13:51:41 2013] (sorry for multiline, I recently changed my layout, and hit 'enter' at the wrong place) [Thu Oct 17 13:51:42 2013] gdsfh, thanks [Thu Oct 17 13:52:15 2013] really, induction works too: http://paste.in.ua/8873/ [Thu Oct 17 13:53:49 2013] Yes, and gdsfh called needlessly the 'fix' tactic in its first paste. [Thu Oct 17 13:54:22 2013] If you are a beginner, I do not advise the use of the 'fix' tactic. [Thu Oct 17 13:54:45 2013] Quiet funny :) [Thu Oct 17 13:54:46 2013] Zedrikov: that's because I hadn't found "length" in hypotheses, and hadn't noticed strange "IHt : nat". [Thu Oct 17 13:54:57 2013] Adding hypothesis to number :D [Thu Oct 17 13:55:36 2013] (unless you really want to have a nice proof term) [Thu Oct 17 13:56:22 2013] (Didn't look for `fix' tactic description yet). Is `fix' tactic for referring to the goal inside proof? Like recursive calls via Y-combinator in lambda calculus. [Thu Oct 17 13:57:22 2013] Yet, forget about the 'fix' tactic. With normal Coq usage, you should not need it. [Thu Oct 17 13:57:33 2013] Just wandering. [Thu Oct 17 13:57:37 2013] kirillt: do you understand why it's bad to build computational terms with tactics, while for Prop-typed values it's safe/acceptable? [Thu Oct 17 13:57:58 2013] gdsfh, because there are a lot of possible terms? [Thu Oct 17 13:58:12 2013] You need it if you disable automatic generation of induction principles, and it can be usefull for mutual induction. [Thu Oct 17 13:58:50 2013] gdsfh, as I understand we can generate only one determined term for definition only in case when our TYPE of definition has only one term. [Thu Oct 17 13:59:20 2013] Kirillt: that plus the fact that proof scripts are unreadable for human beings. [Thu Oct 17 14:00:09 2013] Zedrikov, ye [Thu Oct 17 14:02:12 2013] But there are cases where it is not much annoying. For instance, you can write a function "sub : ∀ m n, {m kirillt: possible terms -- yes. Also: 1. if you extract Coq code to OCaml (for example), all Prop values will be erased, but Type/Set values will live in the code, so they (and functions over them) rule how the program will be executed. 2. some kind of proof irrelevance: it doesn't matter (in general) how the proof looks like, so if you build a value of your type P : Prop, you have the proof. [Thu Oct 17 14:03:09 2013] Zedrikov, does it have only one inhabitant? [Thu Oct 17 14:03:09 2013] tactics and code extraction are two unrelated things in the design [Thu Oct 17 14:03:39 2013] No, but the computationnal result will be what you want. [Thu Oct 17 14:03:43 2013] Zedrikov: I know, but they are related when one uses them both. [Thu Oct 17 14:04:16 2013] Zedrikov, oh, ye, of course, I forgot, that we obviously can code one function in different ways. [Thu Oct 17 14:04:46 2013] That is: either m is lesser than n (in which case substraction is not defined) either the difference will be returned with a proof it is really the difference (but you do not ) [Thu Oct 17 14:05:00 2013] know how it is computed [Thu Oct 17 14:05:13 2013] gdsfh, interesting what will be extracted from tactic-performed definition. [Thu Oct 17 14:05:54 2013] kirillt: use "Extraction length." on my examples. [Thu Oct 17 14:06:04 2013] after definition of length of course. [Thu Oct 17 14:06:46 2013] I guess the output will be the same for both, as 'fix' is not used in the first one. [Thu Oct 17 14:07:51 2013] gdsfh, extracted code not very scarry, but definitely not readable. [Thu Oct 17 14:07:54 2013] Zedrikov: it is used. "exact (1 + length t)", where length was brought by "fix 1". [Thu Oct 17 14:08:25 2013] There is also the 'Print' command, which is probably better, if you are not interested in extraction but only in the proof/term representation [Thu Oct 17 14:09:42 2013] right, I misread it, so it is induction which is useless in your first example, it seems. [Thu Oct 17 14:10:32 2013] (sorry, I am not running Coq now, so I cannot test) [Thu Oct 17 14:10:55 2013] Zedrikov: yes, destruct seems to be enough, but I'm lazy to check it. [Thu Oct 17 14:11:46 2013] I never use induction when destruct is enough [Thu Oct 17 14:12:17 2013] As I never use the Fixpoint keyword to introduce a non recursive function [Thu Oct 17 14:13:26 2013] yes, I agree with you. No need to clutter proof terms. [Thu Oct 17 14:15:37 2013] btw, the most boring thing I've done with Coq was rewriting a part of stdlib about plus and le, so that proof terms got nice and _transparent_. [Thu Oct 17 14:18:17 2013] also I wonder how people live with "Eval .. in .." having opaque proofs from stdlib. [Fri Oct 18 10:41:45 2013] jesus christ [Fri Oct 18 10:42:01 2013] I turned my screen upside down somehow [Fri Oct 18 10:43:00 2013] xrandr -o normal [Fri Oct 18 10:44:17 2013] Windows :/ [Fri Oct 18 13:16:00 2013] Can an Ltac tactic take a set of hint databases? [Fri Oct 18 13:16:09 2013] Ltac foo hints := auto with hints. [Fri Oct 18 13:16:21 2013] works with a single hint database as argument [Sat Oct 19 05:19:14 2013] I forgot, how to handle false cases in induction? [Sat Oct 19 05:19:48 2013] like `[] = [1] -> '. [Sat Oct 19 05:26:26 2013] And what is opposite to `reflexivity'? [Sat Oct 19 05:26:45 2013] I mean tactic which I need when I have goal like `[1] <> []'. [Sat Oct 19 05:27:58 2013] injective should work [Sat Oct 19 05:28:33 2013] or was it inversion ? [Sat Oct 19 05:42:10 2013] inversion requires an parameter. [Sat Oct 19 05:42:22 2013] And there is no injective tactic. [Sat Oct 19 05:43:09 2013] kirillt i think you should find the answer in benjamin pierce book [Sat Oct 19 05:43:10 2013] you want discriminate. [Sat Oct 19 05:44:10 2013] (you can also use "discriminate H" if you avec an hypothesis "H : [] = [1]") [Sat Oct 19 05:44:31 2013] Ye, `disriminate' works. [Sat Oct 19 05:44:39 2013] Thanks. [Sat Oct 19 05:44:55 2013] tactics contradiction ? [Sat Oct 19 05:45:02 2013] Anarchos, somehow there is no introduction of `discriminate' ant the current place of the book. [Sat Oct 19 05:46:32 2013] Anarchos, `contradiction' gives an error, and I don't know about what it is, because ide's highlighting covers message. [Sat Oct 19 05:52:02 2013] What means error "No primitive equality found."? [Sat Oct 19 05:52:25 2013] It appears when I try use `discriminate' in bad cases. [Sat Oct 19 05:54:48 2013] inversion requires an parameter. -- not sure, but i think that that false hypothesis could make a nice parameter for it. after intros, at least [Sat Oct 19 06:01:00 2013] Hmm, I am trying to prove existential goal now. Base case of induction is OK, but step isn't clear. I tried to use `rewrite', but Coq talks that I must import Setoids. [Sat Oct 19 06:01:08 2013] Is there workaround without Setoids? [Sat Oct 19 06:01:24 2013] How to apply existential assertion to my goal? [Sat Oct 19 06:08:38 2013] Oh, I proved it just with `exists '. [Sat Oct 19 06:09:09 2013] No need in induction, only destruct. [Sat Oct 19 06:29:36 2013] How to prove inequality? [Sat Oct 19 06:31:46 2013] Hmm, or `discriminate' works for it, too. [Sat Oct 19 06:33:46 2013] But there is other problem with inequalities: base case of induction is juse `discriminate', but during step I can't apply inductive hypothesis, because it contains `<>' and I can't prove `<>' for bigger term from `<>' for smaller term. [Sat Oct 19 06:33:54 2013] So I think I need to use existential lemma. [Sat Oct 19 06:34:21 2013] I proved it (forall xs, forall x, exists ys, exists y, snoc x xs = cons y ys). [Sat Oct 19 06:34:51 2013] But still can't prove the goal. [Sat Oct 19 06:35:11 2013] Because I can't use discriminate on goal like `[] = x :: xs'. [Sat Oct 19 09:30:57 2013] hi [Sun Oct 20 10:53:22 2013] kirillt: use the predecessor function [Sun Oct 20 10:53:23 2013] http://pastebin.com/Dvvu3awd [Sun Oct 20 10:55:56 2013] is there a finite map data structure in Coq? I want to define substitution on a term type: [Sun Oct 20 10:55:58 2013] anderslundstedt, can it be done without `change'? [Sun Oct 20 10:56:01 2013] Inductive term {A : Set} : Set := [Sun Oct 20 10:56:01 2013] var : nat -> term [Sun Oct 20 10:56:02 2013] | const : A -> term [Sun Oct 20 10:56:03 2013] | conc : term -> term -> term. [Sun Oct 20 10:56:17 2013] anderslundstedt, (only with induction) [Sun Oct 20 11:01:39 2013] kirillt: have you tried induction n; induction m? [Sun Oct 20 11:04:42 2013] kirillt: otherwise I do not know really, you might want to check out section 6.2.3.2 "the inner workings of injection" in Coq'Art [Sun Oct 20 11:12:35 2013] anderskundstedt, I tried `induction n; induction m', can't prove last case, because hypothesis contains non-symmetrical S's (don't know how to describe shortly and clearer). [Sun Oct 20 11:12:52 2013] anderskundstedt, but thank you for the reference to the literature [Sun Oct 20 11:13:56 2013] Is there free english pdf version of Coq'Art? [Sun Oct 20 11:14:55 2013] kirillt: you will have to ask google that. If you could provide a paste bin of your attempt with induction n induction m I could take a look at tit [Sun Oct 20 11:16:08 2013] oh, book is easy to find [Sun Oct 20 11:16:17 2013] I searched previous times and somehow failed [Sun Oct 20 11:16:25 2013] now I found it [Sun Oct 20 11:21:29 2013] anderslundstedt, my attempt to prove it (here, because I have problems with posting to pastebin on current system): `intros n m eq. induction n; induction m. reflexivity. discriminate. discriminate. (* problem *)'. [Sun Oct 20 11:22:24 2013] Problem in that we have hypothesis like `S n = S S m -> ...' or `S S n = S m -> ...' and cannot apply them to equality `S n = S m'. [Sun Oct 20 11:26:21 2013] kirillt: I see. sorry I am not able to help at the moment. [Sun Oct 20 20:42:07 2013] How do I import modules that conflict. Specifically t from Vector and Fin (in the stdlib)? [Mon Oct 21 00:54:25 2013] hi all. sorry if this is off-topic but can anyone tell me some grad schools/professors in europe to work on programming language theory? I'm having hard times deciding where to apply (I only know some schools/professors in US) [Mon Oct 21 03:51:32 2013] I use coq 8.3 and I want to use the omega tactics. What import do I have to maek? [Mon Oct 21 03:52:51 2013] ah just found it. [Mon Oct 21 10:10:58 2013] is it possible to write the following without the helper function? http://pastebin.com/YX3T7xE3 [Mon Oct 21 10:27:16 2013] anderslundstedt: can you not just match on (sub_map n)? [Mon Oct 21 16:41:58 2013] How difficult is it to add another extraction back-end to Coq? [Mon Oct 21 16:43:24 2013] (on a scale of "like washing a lot of dishes" to "if you have to ask, you're incapable of understanding the answer") [Mon Oct 21 16:43:32 2013] What means "%list" at the end of expression? [Mon Oct 21 16:43:50 2013] kirillt: That's a notation scope; it says the expression should be interpreted in the notation scope named list_scope. [Mon Oct 21 16:44:42 2013] For instance, `1%nat` says that `1` should be interpreted in nat_scope and so it names the value 1 : nat (= S O). [Mon Oct 21 16:44:59 2013] ystael, you mean where "Notation := " interpretations are taken from? [Mon Oct 21 16:45:04 2013] yes, exactly. [Mon Oct 21 16:45:10 2013] ystael, ok, thank you [Mon Oct 21 18:22:05 2013] How to copy hypothesis into new variable? [Mon Oct 21 18:31:53 2013] Or how to introduce arbitrary hypothesis into context? [Mon Oct 21 18:37:18 2013] kirillt: if you have a proof, you can 'pose proof .' [Mon Oct 21 18:37:21 2013] I can imagine only the way with "assert (X : -> )". [Mon Oct 21 18:41:53 2013] Ptivampire, you mean, that I should give lemma or something into ? [Mon Oct 21 18:42:23 2013] Ptivampire, and Coq will extract necessary hypothesis from it? [Mon Oct 21 18:52:01 2013] why do I get Error: Unknown interpretation for notation "_ :: _" for http://pastebin.com/9Lq5ZE9N ? [Mon Oct 21 19:03:26 2013] Oh, there is `destruct .. eqn', that is what I looked for. [Mon Oct 21 19:09:28 2013] But Coq cannot parse it somehow. [Mon Oct 21 19:09:48 2013] (I found this tactic in software-foundations book.) [Mon Oct 21 20:30:06 2013] how do I use a comparison between nats in a function: "Definition f (n : nat) := if n = 0 then 1 else 0." gives Error: The term "n = 0" has type "Prop" which is not a (co-)inductive type. [Mon Oct 21 20:34:11 2013] anderslundstedt, try beq_nat [Mon Oct 21 20:34:56 2013] or eq_nat_dec [Mon Oct 21 20:37:23 2013] what library do I have to require? [Mon Oct 21 20:39:15 2013] Arith? [Mon Oct 21 20:39:18 2013] I'm not sure. [Mon Oct 21 20:42:01 2013] does not work: "The reference beq_nat was not found in the current environment." and similar for eq_nat_dec [Mon Oct 21 20:44:06 2013] http://coq.inria.fr/stdlib/Coq.Arith.EqNat.html#beq_nat [Mon Oct 21 20:46:13 2013] could my coq install be broken? "Require Coq.Arith.EqNat. Eval compute in beq_nat O O." gives "The reference beq_nat was not found in the current environment." [Mon Oct 21 20:46:48 2013] it's also possible that you have an old version. [Mon Oct 21 20:47:09 2013] beq_nat is also straightforward to define yourself [Mon Oct 21 20:49:53 2013] yep but I would still worry that a broken coq install would cause other problems. so just to verify: "Require Coq.Arith.EqNat. Eval compute in beq_nat O O." should work? [Mon Oct 21 20:52:04 2013] it should be "Require Import..." [Mon Oct 21 20:52:06 2013] then it should work [Mon Oct 21 20:54:30 2013] oh [Mon Oct 21 20:54:32 2013] thanks! [Tue Oct 22 07:04:42 2013] How to provide type argument to `fold'? [Tue Oct 22 07:05:23 2013] Now I get error `Cannot infer the implicit parameter of X of f' when type `fold f'. [Tue Oct 22 07:05:59 2013] I have parameter X in the context but don't know how to give it to tactic (tried `fold f with X'). [Tue Oct 22 07:54:39 2013] kirillt: "fold (@f X)"? [Tue Oct 22 08:20:55 2013] gdsfh, oh, seems to be [Tue Oct 22 08:50:39 2013] is it possible to get the following operator overloading to work? http://pastebin.com/a0cF8qd8 [Tue Oct 22 10:22:31 2013] I want to destruct n into 0, S 0, and S S n' and then use induction hypothesis for it. Can I perform such tricky induction? [Tue Oct 22 10:24:13 2013] It is useful for proof about evenb function. If I define it with `match n with | O => true | S (S n') => evenb n' | _ => false' then it is hard to prove that it is equal to inductive-defined even predicate (`Inductive even : nat -> Prop := ...'). [Tue Oct 22 10:27:05 2013] I have thought only about new fake natural inductive with three constructors, but it is awful. [Tue Oct 22 10:27:53 2013] kirillt: Try strengthening the proposition you are trying to prove so that you get a stronger inductive hypothesis from a single (one-step) induction. [Tue Oct 22 10:28:00 2013] there was a recent thread on the mailing list about such stuff too [Tue Oct 22 10:29:10 2013] ianjneu, I think it should be possible to google mailing archive with this topic, but can't imageine keywords for search. [Tue Oct 22 10:29:31 2013] ystael, hmm, will think about it [Tue Oct 22 10:31:39 2013] https://sympa.inria.fr/sympa/arc/coq-club/2013-10/msg00156.html [Tue Oct 22 10:34:12 2013] ianjneu, thank you [Tue Oct 22 10:48:31 2013] ianjneu, the thread is not about induction =/ [Tue Oct 22 10:52:01 2013] kirillt: You are best of proving the induction principle with two bases here. [Tue Oct 22 10:52:24 2013] that is forall (P : nat -> Prop), P 0 -> P 1 -> (forall x, P x -> P (S x) -> P (S (S x))) -> forall x, P x. [Tue Oct 22 10:52:38 2013] and then use that to do your proof that evenb x -> even x. [Tue Oct 22 10:54:08 2013] robert, how should I define this induction principle? [Tue Oct 22 10:54:26 2013] robert, and how to use it? Just `apply'? [Tue Oct 22 10:55:47 2013] kirilt: Lemma nat_ind_2 (P : nat -> Prop) : [Tue Oct 22 10:55:49 2013] P 0 -> P 1 -> (forall x, P x -> P (S x) -> P (S (S x))) -> forall x, P x. [Tue Oct 22 10:56:08 2013] kirilt: induction n using nat_ind_2 [Tue Oct 22 10:56:14 2013] or just apply or refine it [Tue Oct 22 10:56:22 2013] oh, very good, thanks [Tue Oct 22 11:01:20 2013] but I stuck at the same moment while proving nat_ind_2 :) [Tue Oct 22 11:01:59 2013] I am trying to do it with `induction n. apply P0. induction n. apply P1. (* ? *)'. [Tue Oct 22 11:02:18 2013] You need to prove a more general statement than just forall x, P x [Tue Oct 22 11:02:26 2013] think about that kind of more general statement you should prove [Tue Oct 22 11:05:23 2013] how can it be more general? [Tue Oct 22 11:05:54 2013] I mean more general and be useful for nat_ind_2 proving. [Tue Oct 22 11:06:29 2013] well, as you may have noticed when just saying induction x, your induction hypothesis is not strong enough [Tue Oct 22 11:07:05 2013] so, the idea is to prove [forall x, Q x] for a certain [Q : nat -> Prop] such that [Q x -> P x] and such that the induction proof works [Tue Oct 22 11:11:29 2013] robbert, are you talking now about my goal or about nat_ind_2 lemma? [Tue Oct 22 12:23:04 2013] anyone have considerable experience with ssreflect that i could bug for a few questions on general work flow? [Tue Oct 22 16:15:14 2013] for inductive types, is there any direct way to get the relation "x is equal to y or x is used in the construction of y". Example: http://pastebin.com/A8e3Pg91 [Wed Oct 23 08:09:19 2013] sup guys :) [Wed Oct 23 10:12:54 2013] is it possible to have a function print debug info? [Wed Oct 23 10:13:04 2013] (as its running through some loop for example) [Wed Oct 23 10:16:20 2013] roosbeef: it's possible to prevent reduction of some expression[s]. Take a look at https://bitbucket.org/gds/coq-breakpoints/src/tip/Bp_examples.v [Wed Oct 23 10:16:49 2013] it's not the same, but it's useful for debugging. [Wed Oct 23 10:17:25 2013] ha nice [Wed Oct 23 10:17:35 2013] so you'll know when the loop enters some case [Wed Oct 23 10:18:22 2013] exactly. [Wed Oct 23 10:18:54 2013] Error: Cannot find library Breakpoints in loadpath [Wed Oct 23 10:19:21 2013] roosbeef: it's my library. https://bitbucket.org/gds/coq-breakpoints [Wed Oct 23 10:19:30 2013] oh :P [Wed Oct 23 10:19:52 2013] lemme plug that in then [Wed Oct 23 10:20:12 2013] (my -- code; ideas are not mine.) [Wed Oct 23 10:20:59 2013] you can just copy Breakpoints.v to your source tree. No external dependencies. [Wed Oct 23 10:23:28 2013] Error: The reference BREAK was not found in the current environment. [Wed Oct 23 10:23:39 2013] roosbeef: please read README file first. [Wed Oct 23 10:23:44 2013] :p [Wed Oct 23 10:26:23 2013] also decide first, do you need one kind of breakpoints or many. in former case it's more convenient to use nameless breakpoints, in latter case use named ones. [Wed Oct 23 10:27:31 2013] gdsfh, awesome stuff! Definitely gonna help me to sharpen my source code [Wed Oct 23 10:28:17 2013] roosbeef: glad you've liked it. [Wed Oct 23 11:38:51 2013] How to apply function to both sides of hypothesis? [Wed Oct 23 11:39:11 2013] I.e `H : x = y' -> `H: length x = length y'. [Wed Oct 23 11:55:53 2013] kirillt: try: pose (H1 := length x = length x); rewrite -> H in H1 at 1 [Wed Oct 23 11:56:10 2013] eh, H1 := refl_equal (length x) [Wed Oct 23 11:56:26 2013] probably there's a better way [Wed Oct 23 12:07:51 2013] ystael, I did it with `assert', but it is not very pretty. [Wed Oct 23 12:09:07 2013] Hmm, is there rev_injective lemma? [Wed Oct 23 12:09:31 2013] (in standard library) [Wed Oct 23 12:35:17 2013] Hmm, and very strange thing: inductive hypothesis isn't generated when I do induction on tuple (like `induction (xs, rev xs)'). [Wed Oct 23 12:36:00 2013] like it is a `destruct'. [Wed Oct 23 13:17:55 2013] kirillt: That's because it is effectively a destruct -- the constructor of a tuple type isn't recursive, so the induction principle generated is just a destructuring one. [Wed Oct 23 13:19:13 2013] You can see this yourself by doing something like Inductive two_tuple (A: Set) (B: Set): Set := | mk2: A -> B -> two_tuple A B. [Wed Oct 23 13:19:38 2013] and then examining the type of the generated induction principle two_tuple_ind. [Wed Oct 23 13:33:39 2013] ystael, is it difficult to construct my own inductive principle for this purpose? [Wed Oct 23 13:34:13 2013] ystael, don't know yet what it should be... [Wed Oct 23 13:38:07 2013] kirillt: maybe "remember xs as xs_rem; induction xs as [ | x xs' ]" would suffice? (by trying to do induction over tuple i guess you want to store previous xs for later use. maybe i'm wrong.) [Wed Oct 23 13:38:53 2013] no, it's not that case. [Wed Oct 23 13:40:35 2013] kirillt: how do you think induction over "rev xs" should work? use simple induction over "xs" and use facts about "rev". [Wed Oct 23 13:50:10 2013] kirillt: apply (f_equal length) in H [Wed Oct 23 13:58:07 2013] robbert: ah, f_equal, that was the thing i couldn't remember [Wed Oct 23 13:58:29 2013] There should be something where you enter the type of the term you want and it finds it in the standard library :) [Wed Oct 23 14:01:00 2013] ystael: SearchAbout, SearchPattern ? [Wed Oct 23 14:01:59 2013] robbert: ooh, that's close! thank you! [Wed Oct 23 14:02:07 2013] I am instructed :) [Wed Oct 23 18:45:29 2013] gdsfh, or induction xs and destruct (rev xs) if I understand correctly [Wed Oct 23 18:45:48 2013] gdsfh, even don't remember my own intention behind that [Wed Oct 23 18:46:26 2013] robbert, yep, the nicest solution [Wed Oct 23 18:48:37 2013] Guys, if you use Coq for solving "industrial" problems, which problems these are? [Thu Oct 24 12:39:52 2013] mumble. [Thu Oct 24 14:59:52 2013] Is there composition function? [Thu Oct 24 14:59:59 2013] like `.' in haskell. [Thu Oct 24 15:01:42 2013] (Found `compose' in Coq.Program.Basics.) [Thu Oct 24 15:11:28 2013] t [Thu Oct 24 16:50:12 2013] this LBNF stuff looks cool. I was looking for similar tools(trying to move away from SDF), does anyone know what parsing algorith is used in LBNF generated parsers? [Thu Oct 24 16:50:54 2013] hmm, LALR, I guess [Thu Oct 24 17:16:08 2013] Could be like Danny Yoo's ragg in Racket. [Thu Oct 24 17:17:35 2013] eh, but ragg doesn't do precedence yet. LBNF probably uses earley parsing since there are no written caveats about ambiguity [Thu Oct 24 17:27:09 2013] ianjneu: it's probably LALR because it's generating Happy code for Haskell frontend [Thu Oct 24 17:27:14 2013] which means LALR [Thu Oct 24 17:39:56 2013] it suggests it is LALR in chapter 10 [Fri Oct 25 07:08:33 2013] hi! [Fri Oct 25 07:08:41 2013] can anyone help me with that error : http://paste.awesom.eu/vzF ? [Fri Oct 25 07:08:57 2013] hmmm [Fri Oct 25 07:09:40 2013] I mean, that error http://paste.awesom.eu/TZ8 [Fri Oct 25 13:22:39 2013] in context: "H : for all f : A -> B, f a = a". goal: "(for all (b : B) (f : A -> B), P (f a) b) <-> (for all b : B, P a b)", where P is some predicate. How do I finish the proof quickly? Is there a rewrite tactic to make the equivalence in the goal trivial? [Fri Oct 25 13:32:13 2013] hi, I am trying to define a new lexical type using a regexpression.. token IPIdent (digit{1,3}\.){3,3} digit{1,3} [Fri Oct 25 13:32:26 2013] http://bnfc.digitalgrammars.com/LBNF-report.pdf I don't fully get the syntax outlined here... Can anyone help? [Fri Oct 25 13:37:26 2013] perhaps #haskell is a better place to ask? [Fri Oct 25 14:04:29 2013] I asked in both places :/ [Fri Oct 25 14:28:33 2013] Well maybe a mailing list is the next place to try [Sun Oct 27 09:59:31 2013] There seems to be a bug in the definition of monoid on http://coq.inria.fr/a-short-introduction-to-coq (see the notation of op). Anyone know who one can contact for that? [Sun Oct 27 10:14:37 2013] peterbb: that's a subtle bug :) I guess the bugtracker: http://www.lix.polytechnique.fr/coq/bugs/ [Sun Oct 27 10:40:46 2013] report sent. :) [Sun Oct 27 13:53:31 2013] Is there somewhere I can find a reference on the refine error "Error: Refiner was given an argument _ of type _ instead of _"? [Sun Oct 27 13:53:42 2013] I can't find it in the error index [Sun Oct 27 13:54:24 2013] and the code I'm getting the error for seems to be type correct [Sun Oct 27 14:02:04 2013] maxiepoo: Maybe Set Printing All. will give a better error message? [Sun Oct 27 14:02:50 2013] hm, doesn't change the error message [Sun Oct 27 14:15:38 2013] hm it actually seems to be a problem with fix with 2 mutually recursive functions [Sun Oct 27 14:16:12 2013] I'm calling with one function but the error message says that I'm applying the other one [Sun Oct 27 14:24:37 2013] maxiepoo pasted “Weird Refine Mutual Fixpoint Error” at http://lpaste.net/94883 [Sun Oct 27 14:27:15 2013] oh whoops I posted the wrong thing [Sun Oct 27 14:28:45 2013] maxiepoo revised “Weird Refine Mutual Fixpoint Error”: “No title” at http://lpaste.net/94883 [Sun Oct 27 14:29:08 2013] ok that's the problematic code [Sun Oct 27 14:31:04 2013] I get the error: The term "F" of type "forall x : b, onesB x -> @sig a (fun y : a => onesA y)" [Sun Oct 27 14:31:20 2013] cannot be applied to the terms "z" : "a" "aTob z H" : "onesA z" [Sun Oct 27 14:31:57 2013] but I'm not calling F on z, I'm calling G! [Sun Oct 27 22:17:48 2013] "Imp programs that don't involve while loops always terminate. State and prove a theorem that says this." -- how could i state such thing? should it be something like 'there always exists a result of expression if there's no while in it'? [Sun Oct 27 22:19:45 2013] (it's from http://www.cis.upenn.edu/~bcpierce/sf/Imp.html) [Sun Oct 27 22:21:59 2013] defanor: that sounds right to me [Sun Oct 27 22:22:37 2013] amosr: thanks, going to try then [Mon Oct 28 00:17:50 2013] Ada has general loops [Mon Oct 28 00:17:55 2013] loop ... end loop; [Mon Oct 28 00:18:01 2013] no faked up conditions [Mon Oct 28 00:18:11 2013] no for (;;) shit or while (true) [Mon Oct 28 00:19:11 2013] The idea being that in Ada the typical infinite loop would normally end with detonation heh [Mon Oct 28 00:19:56 2013] there are while loops, but no one really uses them [Mon Oct 28 00:21:01 2013] usually just use an exit statement in the loop. [Mon Oct 28 00:21:39 2013] loop Do_Stuff; exit when Whatever_Evals_To_True; More_Stuff; end loop; [Mon Oct 28 00:23:27 2013] actually Ada for loops *can't* go on forever. they have a well defined range over which they iterate and then they're done [Mon Oct 28 00:31:37 2013] /o/ [Mon Oct 28 12:58:57 2013] The only difference between `sumbool' and `\/' is in that '\/' is Prop and `sumbool' is Set? [Mon Oct 28 13:00:39 2013] most likely. [Mon Oct 28 13:01:01 2013] Proof relevance versus proof irrelevance. [Mon Oct 28 13:01:11 2013] ? [Mon Oct 28 13:01:43 2013] What is "proof relevance"? [Mon Oct 28 13:04:39 2013] Am I right that we can use both Prop and Set inside proofs and inside definitions? [Mon Oct 28 13:06:46 2013] Oh, seems that answer is "no". [Mon Oct 28 13:07:37 2013] But why? What reason for that? [Mon Oct 28 13:08:56 2013] Proof irrelevance is useful for sanity's sake. [Mon Oct 28 13:09:42 2013] proof relevance is just another way of saying that something can be inspected, and further drive computations. [Mon Oct 28 13:10:43 2013] Proof irrelevance just means you have a proof, you don't care what it is, and you can treat all proofs as the same. That latter bit means that for soundness' sake, you may not inspect proof-irrelevant data (i.e. stuff in Prop) [Mon Oct 28 13:11:49 2013] Proof irrelevance is what homotopy type theorists call call 0-truncation. [Mon Oct 28 13:11:54 2013] -call [Mon Oct 28 13:12:43 2013] that is, proofs of identity of elements of the type (proposition) are all equivalent. [Mon Oct 28 15:39:00 2013] anyone got an example of proving something that involves a fold_left [Mon Oct 28 17:30:01 2013] cmeiklejohn: I have two reasoning things here https://github.com/Ptival/compcert-alias/blob/alias/backend/AliasAnalysis.v [Mon Oct 28 17:30:24 2013] they aren't great proofs though :) [Mon Oct 28 17:30:42 2013] not sure what you're looking for [Mon Oct 28 17:31:08 2013] but I found these two things useful for my proofs, because I would mostly reason about monotonic operations [Mon Oct 28 17:37:57 2013] your thousand line proof scares me [Mon Oct 28 17:39:04 2013] milleral: yeah that file is terrible, it was my first step into Coq :) [Mon Oct 28 17:39:22 2013] * is still making his way through software foundations [Tue Oct 29 00:55:47 2013] hm, how can I get the typechecker to do some type level arithmetic? [Tue Oct 29 00:56:04 2013] The term "NodeSame (S m) (Rec m r) y l" has type "brauntree (S (2 * S m))" [Tue Oct 29 00:56:05 2013] while it is expected to have type "brauntree (S (S (S (2 * m))))". [Tue Oct 29 11:18:31 2013] How to dispatch on result of boolean function? [Tue Oct 29 11:19:01 2013] I.e. I have expression `p a' in my goal and I want to split goal into cases when `p a' is true and false. [Tue Oct 29 11:19:23 2013] `destruct (p a)' doesn't help, because it doesn't create new hypothesis to use. [Tue Oct 29 11:19:51 2013] And `destruct (p a) as _eqn:X' doesn't work. [Tue Oct 29 11:20:29 2013] (because it needs pattern before, but I can't give pattern to boolean value) [Tue Oct 29 11:24:08 2013] what's wrong with `destruct (p a)`? [Tue Oct 29 11:24:32 2013] doesn't it split into 2 subgoals one where `p a` is replaced by true and another false? [Tue Oct 29 11:25:03 2013] maxiepoo, it doesn't replace somehow. [Tue Oct 29 11:25:22 2013] Oh. [Tue Oct 29 11:25:25 2013] Or I am blind. [Tue Oct 29 11:25:55 2013] Yeah, its ok. I just didn't see goal change. [Tue Oct 29 11:26:14 2013] oh haha [Tue Oct 29 11:27:08 2013] But for the future issues: is there universal way to create hypothesis from destruct? I use `destruct term as [] _eqn:H' now. [Tue Oct 29 11:27:51 2013] Not sure if it is useful for booleans. [Tue Oct 29 11:28:02 2013] But my way doesn't work. [Tue Oct 29 11:28:15 2013] what hypothesis do you want [Tue Oct 29 11:28:34 2013] `term = true' and `term = false' [Tue Oct 29 11:29:27 2013] Does `destruct' replaces the term with its value only in goal or in any other hypothesis too? [Tue Oct 29 11:30:09 2013] I think everywhere [Tue Oct 29 11:30:59 2013] Hmm, seems my problem didn't solved. The goal is changed, but I need info about the term again after applyin some rules. [Tue Oct 29 11:31:30 2013] I think it is possible to workaround with `assert'. [Tue Oct 29 11:31:50 2013] Ah, or not. [Tue Oct 29 11:32:15 2013] if you have a symbol {b = true} + {b = false} and destruct you get those terms [Tue Oct 29 11:32:19 2013] sumbool* [Tue Oct 29 11:33:10 2013] sumbools are typically more useful for proofs [Tue Oct 29 11:33:15 2013] than booleans [Tue Oct 29 11:33:30 2013] Is there function for converting bool into sumbool? [Tue Oct 29 11:33:38 2013] no [Tue Oct 29 11:33:42 2013] er [Tue Oct 29 11:33:56 2013] I'm not sure what you mean [Tue Oct 29 11:34:07 2013] sumbools carry more information [Tue Oct 29 11:34:59 2013] I mean I have `p x' and want to get sumbool {p x = true} + {p x = false} value in my context. [Tue Oct 29 11:37:00 2013] I don't know if there's one in the stdlib [Tue Oct 29 11:37:59 2013] but I think the best way to do it is to change your p to return sumbool proofs instead of booleans [Tue Oct 29 11:38:09 2013] unless you're actually proving some property of booleans [Tue Oct 29 11:38:14 2013] Seems that it not hard to do what I want: `assert (PA : {p a = true} + {p a = false}). destrut (p a). apply left. reflexivity. apply right. reflexivity.' [Tue Oct 29 11:39:18 2013] maxiepoo, maybe, just wanted to save purity of `filter' definition (exercise from SF). [Tue Oct 29 11:39:25 2013] maxiepoo, maybe, just wanted to save purity of `filter' definition (exercise from SF). [Tue Oct 29 11:40:02 2013] ah [Wed Oct 30 00:42:40 2013] http://www.cis.upenn.edu/~bcpierce/sf/Imp.html -- i'm stuck on s_compile_correct exercise now, can't make up that more general lemma and need some advice. here are my definitions of those functions: http://lpaste.net/6048620838301728768 [Wed Oct 30 00:52:40 2013] googled a solution, but it'll be too big hint [Wed Oct 30 00:53:13 2013] ugh, will check lemma statement =/ [Wed Oct 30 00:53:58 2013] oh, i thought about such thing even [Wed Oct 30 01:17:37 2013] no, the question is actual still. there's a huge proof where i found it, i don't think it should be that large [Wed Oct 30 01:18:16 2013] googled some hints [Wed Oct 30 08:01:09 2013] Can I split my proof into cases depending on equality of two objects? [Wed Oct 30 08:01:28 2013] E.g. if a = x then ... else ... [Wed Oct 30 08:02:00 2013] I can if I have boolean equality function, then I can use just `destruct (eq a x)'. But what if I haven't? [Wed Oct 30 08:02:40 2013] For instance, if I have to prove the goal for any type X. [Wed Oct 30 08:02:42 2013] kirillt: so you can't. (but it's better to destruct eq-dec-like functions. {a = b} + {a <> b}) [Wed Oct 30 08:04:15 2013] gdsfh, is it impossible because of constructivity? It seems to require excluded middle to do such thing that I want (not sure, just assumption). [Wed Oct 30 08:04:44 2013] I mean in classic logic we know that either a = x or a <> x, here we don't know. [Wed Oct 30 08:04:52 2013] Am I right? [Wed Oct 30 08:07:52 2013] kirillt: excluded middle should help, but it's not good to use it if you don't need it for other parts of program/proof. Better solution is: when you need to use equality on values of some type, make sure the user of your function will supply eq-dec function. You can use typeclasses to ease this process. (with typeclasses coq can find and construct instances.) [Wed Oct 30 08:08:59 2013] gdsfh, yeah, I think the same, too. I taled about excluded middle not because I wanted to use it, just insight about reasons to impossibility of the thing. [Wed Oct 30 08:14:50 2013] kirillt: "Goal 2 + 2 = 4. auto. Show Proof." gives "Proof: eq_refl 4". So the mechanics of " = " seems to be: "convert both values to normal form then match them syntactically". Proofs are just functions, they can't work with syntax of values you give them, they work with values only. [Wed Oct 30 08:14:54 2013] (it's lame enough explanation however. maybe someone will explain better.) Also imagine X = nat -> nat. What about equality on functions? [Wed Oct 30 08:29:15 2013] gdsfh, ye, I didn't think about equality on functions. [Wed Oct 30 08:29:32 2013] Thanks for explanations. [Wed Oct 30 11:14:48 2013] Anybody uses ssreflect? [Wed Oct 30 11:55:08 2013] If anybody uses ssreflect under ubuntu answer please: do you use packages libssreflect-coq or compiled and installed ssreflect from sources? [Wed Oct 30 11:55:29 2013] I installed packages but can't make simple example with "make=>" work. [Wed Oct 30 12:01:38 2013] Oh, seems it works. Just need to import files. [Wed Oct 30 12:03:03 2013] ssrcoq --version [Wed Oct 30 12:06:06 2013] Also, both `coqc' and `ssrcoq -compile' compile tutorial successfully. What difference? [Wed Oct 30 15:01:43 2013] Why I can apply `and' which is of type `Prop -> Prop -> Prop' to booleans? `A /\ B' where A and B are of type `bool' succeed. [Wed Oct 30 15:04:34 2013] Or is it a ssreflect's feature? [Wed Oct 30 15:16:19 2013] kirillt: "Goal true /\ false." <-- doesn't typecheck in plain coq (and shouldn't). [Wed Oct 30 15:20:01 2013] gdsfh, yep, seems that ssreflect uses coercion for converting bool into Prop (`x' -> `x = true'). [Wed Oct 30 19:02:59 2013] http://lpaste.net/7084625808328753152 -- i've getting 'The term "c1" has type "com" while it is expected to have type "Top.com".' with this. what's wrong there? [Wed Oct 30 19:04:15 2013] it's about 'c1' from (c1 ;; c2) / st1 || s2 / st3 [Wed Oct 30 19:04:46 2013] *i'm [Wed Oct 30 19:06:10 2013] (http://www.cis.upenn.edu/~bcpierce/sf/Imp.html, break_imp exercise) [Wed Oct 30 19:10:45 2013] oh, notation is changed here [Wed Oct 30 19:10:55 2013] ';' instead of ';;' [Wed Oct 30 19:59:34 2013] now i'm stuck on while_break_true, can't figure out how should those states look like. advices are welcome [Wed Oct 30 20:03:42 2013] trying induction on c now [Wed Oct 30 22:14:08 2013] passed that one, but now stuck on ceval_deterministic [Fri Nov 1 00:09:38 2013] [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Fri Nov 1 08:31:03 2013] What is "strong" induction? [Fri Nov 1 08:39:31 2013] Oh, I found it. [Fri Nov 1 20:36:13 2013] if i have 'A' in context, and a defined theorem stating that 'A <-> B', how could i replace it with 'B', without additional assertions? [Fri Nov 1 20:36:34 2013] oh, sorry, will rewrite the question. it's not clear [Fri Nov 1 20:37:03 2013] the theorem is 'negb_false_iff: forall b : bool, negb b = false <-> b = true' [Fri Nov 1 20:37:26 2013] and i have 'negb (beval st b) = true' in context [Fri Nov 1 20:37:51 2013] i want to get '(beval st b) = true' [Fri Nov 1 20:38:13 2013] in some simple and clean way [Fri Nov 1 20:38:41 2013] but getting 'negb (negb (beval st b)) = false' if i'm just applying that theorem [Fri Nov 1 20:47:40 2013] s/'(beval st b) = true'/'(beval st b) = false'/. solved that exercise without it (with two applications instead of one) already, but question is actual still: it would be useful to know anyway [Fri Nov 1 22:04:32 2013] Is the law of excluded middle required to prove forall a b : Prop, a /\ b <> (~ (~ a \/ ~ b)) ? [Fri Nov 1 22:05:05 2013] i.e. De Morgan's laws [Fri Nov 1 22:12:34 2013] I guess so. Proofs are on http://coq.inria.fr/V8.1/stdlib/Coq.Logic.Classical_Prop.html [Fri Nov 1 22:17:51 2013] Oops, I messed up the operator precedence. It's (a /\ b) <> (~ (~ a \/ ~ b). [Fri Nov 1 22:32:31 2013] Double oops. It's <->, not <>. <> means not-equals. [Sun Nov 3 16:07:27 2013] jgross: how many people do you have interested in the HoTT reading group? [Sun Nov 3 16:35:43 2013] Currently about 10, including me. [Sun Nov 3 16:38:27 2013] have you started already? [Sun Nov 3 16:38:35 2013] I could get interested in that... [Sun Nov 3 16:40:33 2013] Ptival: No, I'm planning to start at the beginning of January, and meet weekly in some MIT classroom. Perhaps I should post the ad to the HoTT mailing list and/or the HoTT-amateurs mailing list and/or the ##hott channel? [Sun Nov 3 16:57:13 2013] jgross: oh I see [Sun Nov 3 17:06:21 2013] btw, anyone following the harper course on hott? [Sun Nov 3 18:11:38 2013] chris2: I just starting watching the lectures, but it's a lot of rehashing the OPLSS lectures. [Sun Nov 3 18:13:03 2013] didnt watch these yet [Sun Nov 3 18:13:40 2013] I have a pretty strong background in ITT, and he doesn't do a lot of lectures on transport, suspensions, HITs or encode/decode proofs... [Sun Nov 3 18:13:54 2013] So it's an exercise in patience. [Sun Nov 3 18:15:11 2013] hm, ok [Sun Nov 3 18:16:37 2013] I'm up to chapter 8 in the HoTT book, and I've looked forward a little bit, but after HITs, the book starts going 0.95 * c [Sun Nov 3 18:16:50 2013] hehe [Sun Nov 3 18:17:25 2013] Ptival: are you in the Boston area? [Sun Nov 3 18:26:47 2013] ianjneu: no [Sun Nov 3 18:26:56 2013] I thought it was the online reading group [Sun Nov 3 18:44:03 2013] Ptival: maybe we could set up a ventrillo or something. [Mon Nov 4 11:14:37 2013] jgross: Do you have any plans for remote access (google hangout or whatever) to the HoTT reading group? I am interested but would not be able to attend in person if it is during the day on weekdays. [Mon Nov 4 12:18:19 2013] ystael: you might ask in #HoTT, there might be more group members in there than here (?) [Mon Nov 4 12:18:26 2013] er, ##HoTT [Mon Nov 4 12:25:18 2013] jgross hasn't told us when/where yet. [Mon Nov 4 12:25:45 2013] I would be fine taking my laptop and a webcam to make a hangout [Mon Nov 4 17:22:30 2013] Homotopy Type Theory book? [Mon Nov 4 17:27:16 2013] where where ? [Mon Nov 4 17:29:37 2013] I'm trying to guess what HoTT is [Mon Nov 4 17:29:53 2013] yes. i think [Mon Nov 4 17:30:04 2013] http://homotopytypetheory.org/book/ [Mon Nov 4 17:35:25 2013] milleralkind of a dragon... [Mon Nov 4 17:37:57 2013] milleral oh it comes from IAS ! [Mon Nov 4 17:38:55 2013] * hasn't heard of the IAS before [Mon Nov 4 17:40:00 2013] milleral it was the laboratory of einstein :) [Mon Nov 4 17:40:30 2013] oh cool [Mon Nov 4 18:00:56 2013] milleral just by the names listed in the book, i can assure you it is valuable [Mon Nov 4 18:01:19 2013] I'm just hoping I'll be able to understand it :) [Mon Nov 4 18:02:16 2013] i will look at it tomorrow at work :) [Mon Nov 4 20:49:00 2013] So I'm trying to Eval a term, but it won't reduce past a Fix_F [Mon Nov 4 20:49:32 2013] I've tried Eval compute, simpl, hnf, red and they all get stuck there or sooner [Mon Nov 4 20:50:31 2013] the term is a terminating computation, so I don't know why I can't just force it to eval all the way [Mon Nov 4 20:51:46 2013] are there any other evaluation strategies I could use? [Mon Nov 4 21:31:21 2013] Anyone who knows any literature about formalizing claims of fresh variables in derivations, where the freshness-claim is "global", i.e. can't really be checked locally. [Tue Nov 5 12:38:57 2013] How do I install Coq properly if I have OCaml version 4 or up? [Tue Nov 5 12:41:08 2013] apt-get install is telling me I need 3.12.1, though I had to manually install 4.02.0 from the svn repo, and I can't find a download for the CoqIDE thing, only Coq [Tue Nov 5 12:43:26 2013] Xenasis: the apt-get version of Coq seems fairly old, I'd recommend building it manually at that point :\ [Tue Nov 5 12:44:35 2013] Yeah, the reason I had to build OCaml manually was because the apt-get OCaml was 3.12.1, and my lecturer uses 4.01.1, as is required [Tue Nov 5 12:44:52 2013] The problem is that I can't find anywhere to get CoqIDE to build [Tue Nov 5 12:45:17 2013] http://coq.inria.fr/download [Tue Nov 5 12:45:19 2013] is CoqIDE required for the lecture? [Tue Nov 5 12:45:31 2013] otherwise, I find ProofGeneral to be a much nicer environment [Tue Nov 5 12:45:41 2013] Coq isn't required at all, but you can use Coq or Agda for bonus marks [Tue Nov 5 12:45:44 2013] plus they look fun [Tue Nov 5 12:46:05 2013] do you use emacs? :\ [Tue Nov 5 12:46:10 2013] I do [Tue Nov 5 12:46:25 2013] then I highly suggest installing ProofGeneral instead of trying CoqIDE [Tue Nov 5 12:46:33 2013] Alrighty [Tue Nov 5 12:51:17 2013] http://hammerprinciple.com/therighttool/statements/i-often-feel-like-i-am-not-smart-enough-to-write-t [Tue Nov 5 12:51:27 2013] I'm not sure if this should scare or excite me [Tue Nov 5 12:53:02 2013] Xenasis: both :) [Tue Nov 5 12:53:39 2013] File "kernel/univ.ml", line 229, characters 0-2: [Tue Nov 5 12:53:39 2013] Error: This comment contains an unterminated string literal [Tue Nov 5 12:53:39 2013] make[1]: *** [kernel/univ.cmo] Error 2 [Tue Nov 5 12:53:39 2013] make[1]: Leaving directory `/home/andrew/Downloads/coq-8.4pl2' [Tue Nov 5 12:53:39 2013] make: *** [world] Error 2 [Tue Nov 5 12:53:41 2013] ...huh [Tue Nov 5 12:53:56 2013] huh [Tue Nov 5 12:54:53 2013] what's on that line in your file? [Tue Nov 5 12:55:06 2013] mine has (* between u v = {w|u<=w<=v, w canonical} *) [Tue Nov 5 12:55:35 2013] One second, I'll find it [Tue Nov 5 12:58:35 2013] (* between u v = {w|u<=w<=v, w canonical} *) [Tue Nov 5 12:58:41 2013] ...huh [Tue Nov 5 13:00:06 2013] they're the same line [Tue Nov 5 13:15:21 2013] Xenasis: what does ocamlc -v return? [Wed Nov 6 09:18:57 2013] How to get LibTactics module? [Wed Nov 6 09:19:03 2013] Is there lib with it or somthing? [Wed Nov 6 09:19:52 2013] I see gallium.inria.fr link with it but don't see convinient way to get it except copy-paste. [Wed Nov 6 09:23:01 2013] Is "UseTactics" the name of it? [Thu Nov 7 17:25:08 2013] It's pretty unfortunate that inductive types can't directly implement parameters in module types [Thu Nov 7 17:25:31 2013] Need to fold or unfold the definition seems to confuse auto [Fri Nov 8 17:41:42 2013] is there a way to bind a tactic to a name without running it? [Fri Nov 8 17:42:42 2013] "Ltac foo := ." ? [Fri Nov 8 17:43:27 2013] oh I mean locally, sorry [Fri Nov 8 17:43:48 2013] it's weird because [Fri Nov 8 17:43:56 2013] "Local Ltac foo := ." ? [Fri Nov 8 17:43:57 2013] let t := fail in idtac. (* works *) [Fri Nov 8 17:44:08 2013] but let t := mytactic in idtac. (* fails *) [Fri Nov 8 17:44:41 2013] even when the toplevel of mytactic is a lazymatch [Fri Nov 8 17:44:49 2013] Is mytactic a [match]? Try "let t := (idtac; mytactic) in idtac.". [Fri Nov 8 17:45:37 2013] jgross_: indeed this works :s [Fri Nov 8 17:45:43 2013] Coq treats things like [match] specially, because they might return a constr. Like, if you do [let f := match goal with |- ?f => constr:(f) end in idtac f.], you want the goal, not a tactic. [Fri Nov 8 17:47:03 2013] sure [Fri Nov 8 17:47:29 2013] though the solution seems arbitrary [Fri Nov 8 17:49:10 2013] Any use of ; in the top level tactic you're binding will make it be treated as a tactic, rather than be eagerly evaluated. You can also turn it into a tactic function, e.g., [let t := (fun _ => ...) in t idtac.] or something. [Sat Nov 9 10:00:19 2013] copumpkin fun name you have :) [Sat Nov 9 10:00:46 2013] yeah, i like that too [Sat Nov 9 11:12:28 2013] what is the best way to handle equivalence relations and operations that respect these relations? in my case I have an equivalence relation "==" and an operation "*". i have hypotheses a*b=x and a*b*c=y, from which i want to prove x*c=y. is there a quick way to this? [Sat Nov 9 11:20:23 2013] you'll need proof that * respects == [Sat Nov 9 11:20:53 2013] something like x == y -> a == b -> x * a == y * b [Sat Nov 9 11:21:04 2013] or that it's subsitutive, which basically means everything respects it [Sat Nov 9 11:22:15 2013] need to go catch a train [Sat Nov 9 11:34:22 2013] thanks for the help. I have such a proof, is there a tactic then that gets the job done without having to apply that theorem and transitivity etc .... [Sat Nov 9 14:50:11 2013] anderslundstedt: I think if you make proper morphism instances and use type classes you get a lot out of tactics like ring [Sat Nov 9 14:50:17 2013] or just auto even? [Sat Nov 9 14:51:49 2013] Ptival: thanks. Do you have any recommended reading about type classes? [Sat Nov 9 14:53:56 2013] probably this though I haven't read it http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf [Sat Nov 9 14:56:00 2013] thank you [Sun Nov 10 11:43:42 2013] http://www.cis.upenn.edu/~bcpierce/sf/Equiv.html -- i'm stuck on havoc_swap, and not sure if solved himp_ceval right. defined E_Havoc as "forall (st : state) (X : id) (n : nat), (HAVOC X) / st || update st X n", and now i think that even same program is not 'cequal' to itself, if it contains Havoc, but i also think that it's wrong =/ need some help [Sun Nov 10 11:45:20 2013] *not 'cequiv' [Sun Nov 10 11:47:36 2013] oh, wait, same program is cequiv to itself anyway [Sun Nov 10 11:48:41 2013] and probably it should be cequiv in havoc_swap also [Sun Nov 10 17:26:44 2013] defanor_: your definition of E_Havoc looks right to me. the definition of cequiv makes it automatically reflexive, so you don't have to worry about that. and I think you're right that havoc_swap is "true", but I haven't actually done the exercise. [Sun Nov 10 18:59:47 2013] if i have a binary operation * that is proper wrt an equivalence relation ==, which tactic finishes proofs of goals like: x*y==z -> x*y*w=a -> z*w=a [Sun Nov 10 19:00:49 2013] = should be == everywhere in goal [Sun Nov 10 19:18:34 2013] well it looks like I lied :\ [Sun Nov 10 19:23:17 2013] not a big problem, and proper morphisms gives easy rewrites so still a big convenience [Sun Nov 10 19:35:31 2013] Hi, guys. [Sun Nov 10 19:36:18 2013] I am trying to install coq on my ubuntu, but SOMEHOW it depends on gnome, gtk and other stuff which I do not want to install. [Sun Nov 10 19:36:52 2013] E.g. virtual package `libcoq-ocaml-twu11', what is it? What means "twu11"? I googled, but couldnt resolve by myself. [Sun Nov 10 20:00:21 2013] CoqIDE depends on Gtk. I don't know if there's a package which is coq but not CoqIDE. If you build it from source, you can build it without Gtk. (You'll want to have ocaml and camlp5 and ocamlfind (ocaml-findlib, maybe?) installed first. Also GNU make.) [Mon Nov 11 01:04:26 2013] jrw: thanks [Mon Nov 11 16:06:03 2013] I am trying to write a small library for real-weighted binary trees in Coq. I want a prune function which removes a leaf edge (edge to a leaf node) if its weight is equal to zero. I'm using Coq.Reals.Reals for real numbers. Neither of the following constructs work: if w = 0%R then ... else ... nor if Req_dec w 0 then ... else ... (where w is of type R). How do I make this if/else work, and is the real number library suitable for this sort [Mon Nov 11 16:06:03 2013] thing? [Mon Nov 11 16:08:57 2013] what's the error for the if Req_dec w 0 case? [Mon Nov 11 16:11:46 2013] @ianjneu: Incorrect elimination of "Req_dec w0 0" in the inductive type "or": [Mon Nov 11 16:11:47 2013] the return type has sort "Type" while it should be "Prop". [Mon Nov 11 16:11:50 2013] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Mon Nov 11 16:12:33 2013] ah, you need proof-relevance. [Mon Nov 11 16:12:45 2013] hrm. what is that? [Mon Nov 11 16:13:26 2013] I'm very new to all this Coq programming. So many new concepts my head is swimming a little bit... [Mon Nov 11 16:14:08 2013] You can't eliminate a Prop to create something not in Prop. Prop is proof-irrelevant (all proofs are opaque and considered equal to one another), and because of the way Coq does things, eliminating a Prop to make a Type can cause logical inconsistencies. [Mon Nov 11 16:14:54 2013] quadelirus: To put it another way, you can't actually compute with Req_dec. [Mon Nov 11 16:15:06 2013] Req_dec is a bit of a lie, actually [Mon Nov 11 16:15:14 2013] is there any way to compute with reals in coq? [Mon Nov 11 16:15:16 2013] That's not quite true. You can normalize proofs. [Mon Nov 11 16:15:19 2013] (Real equality isn't decidable) [Mon Nov 11 16:15:35 2013] Tarski proved otherwise. [Mon Nov 11 16:15:58 2013] the reals have a decidable theory of arithmetic. [Mon Nov 11 16:17:32 2013] Surely there's some kind of LEM going on here. [Mon Nov 11 16:19:04 2013] I don't know how much work it would be to actually make Req_dec proof-relevant, since its decidability proof probably uses lots of other Prop-valued functions. [Mon Nov 11 16:20:53 2013] sorry lost internet. DOes this mean you can't represent real weighted trees in coq? [Mon Nov 11 16:21:39 2013] quadelirus: Why do you need to test equality with 0? [Mon Nov 11 16:21:47 2013] No, you should be able to, but you might have to reimplement reals to be proof-relevant. Is there a reason why you don't want to use the field of rationals? [Mon Nov 11 16:22:06 2013] need to use sin functions [Mon Nov 11 16:22:13 2013] the alg i want to prove correct [Mon Nov 11 16:22:24 2013] prunes edges w 0 length [Mon Nov 11 16:23:02 2013] and the weights are decreased periodically by trig functions [Mon Nov 11 16:23:13 2013] like w = w - sin x [Mon Nov 11 16:23:32 2013] and whenever a weight becomes zero the edge is pruned [Mon Nov 11 16:23:43 2013] oh, you want to use transcendental functions. That could be a problem. [Mon Nov 11 16:25:02 2013] you can use the zeros of sin to encode the integers and then get the same undecidability results of peano arithmetic. [Mon Nov 11 16:25:36 2013] meaning that it can't be done? [Mon Nov 11 16:25:53 2013] not with exact precision, no. [Mon Nov 11 16:25:55 2013] quadelirus: The algorithm you're describing doesn't sound computable. [Mon Nov 11 16:26:20 2013] thats too bad [Mon Nov 11 16:26:23 2013] You can check to see if a real number is within some nonzero distance of 0 [Mon Nov 11 16:26:29 2013] (computably) [Mon Nov 11 16:26:34 2013] there is a notion of "delta-completeness" for the real numbers that's NP-complete, even with transcedental functions. You have to admit a non-zero amount of error though (delta) [Mon Nov 11 16:27:27 2013] hmmm, well this is a geometric algorithm, the sines coming from angle measures, so maybe I can use one of the geometry packages to encode everything and avoid coordinate based approaches, though i think that may be a big project [Mon Nov 11 16:28:17 2013] embed the trees nodes as points and take edges to be line segments [Mon Nov 11 16:28:26 2013] in an axiomatic system like Tarski's [Mon Nov 11 16:29:03 2013] if you can just use +,-,*,/ then you should be set. [Mon Nov 11 16:29:08 2013] Well this has been really helpful, but my son is crying so I've got to run. Thank you guys. [Mon Nov 11 16:29:14 2013] cool, well I'll give that a shot [Mon Nov 11 16:29:18 2013] and probably show up here another time :) [Mon Nov 11 16:29:22 2013] indeed [Mon Nov 11 16:29:25 2013] good luck [Mon Nov 11 16:57:24 2013] Guys, I am debugging a proof now. The goal is stated as `forall X l i (e : X), insert l i e = Some nil -> False'. `insert' function is defined in obvious way. [Mon Nov 11 16:58:11 2013] Then one part of proof is `intro v. destruct i; destruct l; try destruct l; inversion h.'. [Mon Nov 11 16:59:12 2013] insert like insert sort? I expect then that X has a decidable ordering? [Mon Nov 11 16:59:30 2013] The alternative part of proof is `intro v. destruct i; destruct l. (* DOT *) destruct l; inversion h. inversion h. destruct l; inversion h.'; i.e. this unfolds semicolon into three tactics. [Mon Nov 11 16:59:50 2013] ianjneu, no, just insert element in the list at i'th position. [Mon Nov 11 17:00:02 2013] Somehow these two parts are not equivalent. [Mon Nov 11 17:00:28 2013] First leaves one goal; second leaves two (it didn't solve last of three goals). [Mon Nov 11 17:01:42 2013] Oh, I mean `destruct l; inversion h. inversion h. inversion h' after (* DOT *) in the second part. [Mon Nov 11 17:01:54 2013] (Sorry, can't use pastebin on this system.) [Mon Nov 11 17:02:53 2013] Ah, maybe the first part resolves last goal, so it leaves only one. But I can't test it. [Mon Nov 11 17:03:09 2013] Maybe admit will help to diagnose problem. [Mon Nov 11 17:04:57 2013] Ye, seems to be. [Mon Nov 11 17:05:19 2013] That feel when you write huge wall of text and resolve the problem by yourself =/ [Mon Nov 11 17:05:37 2013] it's called rubber-duck-debugging [Mon Nov 11 17:07:22 2013] LOL [Mon Nov 11 17:08:02 2013] Rubber coq ;) [Mon Nov 11 17:08:12 2013] :D [Mon Nov 11 17:10:12 2013] I'm going to have to use that. [Mon Nov 11 17:10:27 2013] the joke, not the denoted joke object [Mon Nov 11 17:10:31 2013] *sigh* [Mon Nov 11 17:21:53 2013] ianjneu, at first I didn't too [Mon Nov 11 17:35:08 2013] I don't understand [Mon Nov 11 18:48:01 2013] Hi, guys. [Mon Nov 11 18:48:08 2013] Anybody familiar with ssreflect? [Mon Nov 11 18:48:33 2013] I can't find analogue of standard `inversion' tactic. [Mon Nov 11 18:50:24 2013] nope, sorry [Mon Nov 11 19:23:17 2013] I am installing gentoo from minimal cd, ifconfig tells that my network interface is called "enp0s3". Is it ok? [Mon Nov 11 19:23:51 2013] Also I am in virtualbox, so maybe it is called so because of it; but I am not sure. [Mon Nov 11 19:24:26 2013] Should I have "eth0" usually in real machine? [Mon Nov 11 19:25:08 2013] Rc43: hmm this is #coq :) [Mon Nov 11 19:25:16 2013] Ptival, oh [Wed Nov 13 09:12:01 2013] can somebody please check following code on recent Coq version? My old 8.3pl4 gives scary error message (or maybe it's normal?). Goal forall (a : nat), True. match compute in a with | _ => idtac end. [Wed Nov 13 09:13:57 2013] also dumb question. Suppose I have "x := true : bool" in hypotheses. How can I execute tactic tactrue or tacfalse depending on what value "x" has? [Wed Nov 13 09:40:33 2013] where mopidy-scan [Wed Nov 13 09:40:42 2013] oh, well, "oups", sorry [Wed Nov 13 10:48:23 2013] gdsfh: "Error: Must evaluate to a closed term offending expression: compute in a this is a VFun with body compute in a instantiated arguments uninstantiated arguments " [Wed Nov 13 10:48:27 2013] yes, that's is scary :) [Wed Nov 13 10:48:37 2013] using 8.4pl2 here [Wed Nov 13 10:51:37 2013] robbert`: also it's formatted in a very strange way, in multiple lines, and doesn't give any insights on what is wrong here. [Wed Nov 13 10:53:31 2013] (but maybe it's just my nitpicking.) [Wed Nov 13 10:54:11 2013] yes, that's strange indeed. The problem however is that "compute in a" yields a tactic [Wed Nov 13 10:54:22 2013] not the result of cbv reducing a [Wed Nov 13 10:54:39 2013] for that you need eval cbv in a [Wed Nov 13 10:55:38 2013] match eval compute in x with false => idtac "false" | true => idtac "true" end. would solve your second problem [Wed Nov 13 10:56:09 2013] what you were trying do to, is basically match on a tactic [Wed Nov 13 10:56:17 2013] which is not possible, but still the error is insane :) [Wed Nov 13 11:00:40 2013] robbert`: i know i'm doing the wrong thing. As for second problem -- it works, thank you! (i have some free time now and i'm trying to implement "do rewrite when it reduces goal size only", mentioned in coq-club; just for fun.) [Wed Nov 13 11:01:58 2013] gdsfh: just wondering, how do you determine that the size of the goal decreases? [Wed Nov 13 11:05:12 2013] robbert`: i don't know whether my way is correct, but now i'm trying something like this: http://paste.in.ua/9025/raw/ (nats is a special case since S (S ..) is treated as application of S to (S ..); don't know is it needed to treat nats specially) [Wed Nov 13 11:06:12 2013] and i'm only trying to do it, debugging, looking at what tactic returns. Maybe it won't work in general case; just exploring. [Wed Nov 13 11:07:24 2013] also i'm not sure that this approach works well. Some clever normalization would be better, even if it expands term. [Wed Nov 13 11:08:08 2013] (so, "rewrites with decreasing goal" won't work in arithmetics, where "omega" works fine.) [Wed Nov 13 11:23:48 2013] gdsfh: I do not really see what you are trying to do there. But anyway, I doubt you can do this properly in Ltac, especially because you cannot go under binders (and rewrite will, aslong as the bound variable is not involved) [Wed Nov 13 11:24:31 2013] my attempt would be something like http://lpaste.net/95603 [Wed Nov 13 11:32:03 2013] and there is now also the whole tactic, quite ugly, and no idea whether it will work properly ;) [Wed Nov 13 11:54:05 2013] robbert`: your code is much simpler ( => better) than mine. It's a good ltac lesson for me. But i'm not sure such rewrites are useful -- i've read this idea in coq-club and tried to implement it, nothing serious/concrete. So i won't proceed further, everything is clear for me. [Wed Nov 13 12:33:06 2013] gdsfh: I also doubt such a tactic is useful. What's much more useful is to rewrite equations that have a variable on one of the sides, and that is what subst is doing. [Wed Nov 13 12:44:50 2013] robbert`: yes, subst is useful. Also some kind of normalization is needed, like "repeat rewrite Plus.plus_assoc" to rewrite "a + (b + c)" to "a + b + c". When working (not playing), "ring" with user-defined rings can be useful. [Wed Nov 13 12:44:55 2013] proofs by reflection are good, canonical structures could be useful to "normalize" some terms (or i'm wrong?). Someone should write a generic mechanism to do rewriting-with-normalization. ("auto" is not enough.) [Wed Nov 13 13:03:38 2013] gdsfh: about the associativity, maybe you are looking for something like AACTactics? [Wed Nov 13 13:07:01 2013] robbert`: not "looked for", but it's an interesting reading. [Thu Nov 14 16:06:14 2013] Is there any way to reopen a Section? [Thu Nov 14 16:07:20 2013] napping maybe :) [Thu Nov 14 16:13:29 2013] If one module includes a section that had some variables, I'd like to be able to import that module into another, make those things variables again, and prove some additional stuff without having to explicitly supply all the parameters introduced when I closed the first section [Thu Nov 14 18:15:13 2013] yeah that'd be cool [Fri Nov 15 00:55:05 2013] Hi, guys. [Fri Nov 15 00:55:12 2013] Anybody uses gentoo? [Fri Nov 15 00:55:56 2013] Just want to know is there ebuild for ssreflect or not. Maybe coq overlay? (I didn't find.) [Mon Nov 18 04:29:35 2013] Hi, guys. [Mon Nov 18 06:31:43 2013] How do you use ProofGeneral on projects with subfolders? [Mon Nov 18 06:32:25 2013] E.g. I have folder "src" and ubfolder "sub" and file src/sub/B.v depends on src/A.v. [Mon Nov 18 06:32:33 2013] How to tell ProofGeneral about loadpath? [Mon Nov 18 07:02:44 2013] hello kirillt [Mon Nov 18 07:59:38 2013] Anybody know how to enable interpreted text highlighting in proofgeneral? [Mon Nov 18 08:00:01 2013] I.e. after C-c C-n. [Mon Nov 18 19:02:14 2013] Hello Coq people! I'm trying to run a file from the Software Foundations book and running into an error I don't understand. Could anyone help me? http://stackoverflow.com/questions/20056972/coq-error-no-focused-proof-when-using-arguments-command [Mon Nov 18 19:12:22 2013] jameshfisher: fwiw, I have Coq 8.4pl2, and don't get an error message. [Mon Nov 18 19:12:50 2013] jameshfisher: Can you try running coqc on the file? [Mon Nov 18 19:13:39 2013] jameshfisher: (I ask because I don't have CoqIDE, and it would be good to eliminate it as a variable.) [Mon Nov 18 19:14:52 2013] Hi, okay, good idea [Mon Nov 18 19:15:10 2013] (Only just starting out and I've only used CoqIDE.) [Mon Nov 18 19:15:51 2013] I assume the equivalent is `coqc test.v` where test.v contains the "Inductive list .... Arguments nil {X}." stuff? [Mon Nov 18 19:15:59 2013] yeah [Mon Nov 18 19:16:18 2013] Hmm. "Error: Unknown command of the non proof-editing mode." [Mon Nov 18 19:16:27 2013] "File "./test.v", line 4, characters 0-18:" [Mon Nov 18 19:16:47 2013] So perhaps this is an 8.3 vs. 8.4 change [Mon Nov 18 19:18:39 2013] Sounds like a reasonable theory. I'll try to install 8.4 and/or check documentation changes. [Mon Nov 18 19:19:05 2013] jameshfisher: Try adding the word Implicit to the start of the line [Mon Nov 18 19:19:54 2013] Most of my code that uses this was written pre-8.4 and has "Implicit Arguments foo [x y z]." [Mon Nov 18 19:20:25 2013] Hrm, actually my own code archeology is confusing on this [Mon Nov 18 19:20:33 2013] Ooh, it accepts that, with the bracket change too [Mon Nov 18 19:21:49 2013] Ah, [] is for implicit, and {} is for maximally inserted implicit [Mon Nov 18 19:24:29 2013] Time for me to read up on what that means, then. :-) [Mon Nov 18 19:25:12 2013] I should be able to take it from here -- great help, thanks! [Tue Nov 19 00:08:48 2013] Let we have goal "forall (x y : list X), Some x = Some y -> x = y". Why proof "intros x y h; inversion h; ..." works and "destruct x; destruct y; intro h; inversion h. ..." doesn't? [Tue Nov 19 00:09:26 2013] I.e. in first proof inversion destructs hypothesis (and gives us injection) and in the second it doesn't. [Tue Nov 19 00:09:29 2013] Why so? [Tue Nov 19 03:48:10 2013] kirillt: uh, it seems to work, but the destructs produce a bunch of different cases. inversion on h is still useful. [Tue Nov 19 03:52:19 2013] kirillt: You can handle the nil = nil case with trivial, and then inversion h immediately solves the nil = (a0 :: y) case, and then you're left with (a0 :: x) = y, you can destruct y again if you really want, and apply inversion h to each of the two cases that generates, or you can just use inversion h directly. [Tue Nov 19 03:53:10 2013] (but also, why are you proving this for lists specifically? It's generally true that Some is injective, you don't have to specialise it to lists.) [Tue Nov 19 04:24:48 2013] Cale, ye, I already understood that it is bad example. I tried to extract small example of my issue. [Tue Nov 19 04:27:13 2013] Cale, it seems that in some cases destruct for complex terms (without functions but with constructors application, that why I used lists) do nothing, when it does injection-like things when it is only one constructor applied to one variable (like Some x instead of Some x :: xs). [Tue Nov 19 04:27:28 2013] But it is messy to tell it with words, I need good example [Tue Nov 19 08:08:32 2013] im somewhat confused about induction in Coq [Tue Nov 19 08:08:47 2013] this would look like your typical induction-based proof, i think: https://privatepaste.com/fce4d7ed25 [Tue Nov 19 08:09:25 2013] what are the typical steps from here? I need to do something with a0, but how does that allow me to use IHFS to complete the proof [Tue Nov 19 19:53:25 2013] why do we have a separation of Prop and Type? [Tue Nov 19 19:53:34 2013] (and where can I read up more on what this sepration gives us)? [Tue Nov 19 19:55:18 2013] Prop stuff is guaranteed to be erased during program extraction [Tue Nov 19 19:55:25 2013] Prop is also impredicative [Tue Nov 19 19:56:29 2013] I heard the Prop/Type distinction is being removed in the HoTT branch [Tue Nov 19 19:56:39 2013] .. though I don't know the inside story [Tue Nov 19 20:00:32 2013] is proof irrelevance related? [Tue Nov 19 20:03:03 2013] Coq won't let you write a function that destructs a Prop thing and produces a Type thing. [Tue Nov 19 20:03:43 2013] Prop things are erased at runtime, so are computationally irrelevant [Tue Nov 19 20:14:43 2013] is there some book chapter I can read [Tue Nov 19 20:14:54 2013] on the distinction of these two? (was disconected while asking about prop vs type) [Tue Nov 19 20:17:17 2013] logic_prog: the manual has the details, at least for the typing rules iirc [Tue Nov 19 20:17:33 2013] actually I'm implementing a dependent type checker [Tue Nov 19 20:17:36 2013] based on the tutorial of [Tue Nov 19 20:17:49 2013] http://math.andrej.com/2012/11/08/how-to-implement-dependent-type-theory-i/ [Tue Nov 19 20:18:00 2013] and I'm now confused with regardes to "how do I add props to this type theory" ? [Tue Nov 19 20:19:07 2013] adam chlipala's CPDT book has a chapter on it [Tue Nov 19 20:19:09 2013] with examples [Tue Nov 19 20:19:39 2013] some of the official Coq documentation is hard to read if you don't already know what it means [Tue Nov 19 20:20:04 2013] The Universes and Axioms chapter of CPDT [Tue Nov 19 20:30:38 2013] with apologies for missing something really simple [Tue Nov 19 20:30:43 2013] why is it important that we can not destrut Props ? [Tue Nov 19 20:31:35 2013] You can destruct Props, but you can't write a function that then produces a Type [Tue Nov 19 20:31:45 2013] suppose f (x : Prop) : Type = ... [Tue Nov 19 20:31:59 2013] After program extraction, the argument 'x' isn't available at runtime [Tue Nov 19 20:32:08 2013] so there is nothing to match on to produce the result value [Tue Nov 19 20:32:45 2013] It's ok to have g (x : Prop) : Prop = ... because neither the argument or result value need to exist at runtime [Tue Nov 19 20:33:10 2013] I have one more dumb question (I think it's related to this). [Tue Nov 19 20:33:26 2013] in Coq, I have "H: Cat = Dog", then I can do "inversion H", get False, and get done with all. [Tue Nov 19 20:33:38 2013] However, if I use "forall p q, p <-> q -> p = q" [Tue Nov 19 20:33:43 2013] then I can have "And True True = True" [Tue Nov 19 20:33:57 2013] why can't I destruct "H: And True True = True" and get False? what is different in this case? [Tue Nov 19 20:34:36 2013] what is 'And' ? [Tue Nov 19 20:36:07 2013] err, sorry, " True /\ True" [Tue Nov 19 20:37:26 2013] I don't see how 'True /\ True = True' is going to get you False [Tue Nov 19 20:38:16 2013] It doesn't, but if I had "Cat 1 2 = Dog 1 2" I would get false [Tue Nov 19 20:38:30 2013] so why is Prop treated differently in that I have "True /\ True = True" but I don't get false [Tue Nov 19 20:41:03 2013] hrm [Tue Nov 19 20:42:01 2013] is htis because False is a type [Tue Nov 19 20:42:05 2013] and after I destruct a Prop I can't return a Type? [Tue Nov 19 20:42:19 2013] (I don't know, I'm throwing mud at where I think a wall is blindfolded in the dark while drunk) [Tue Nov 19 20:43:30 2013] I don't have a clean enough understanding to give a good answer [Tue Nov 19 20:43:39 2013] it's related to how equality is defined in Coq [Tue Nov 19 20:43:47 2013] I don't think it's a Prop/Type problem [Tue Nov 19 20:49:06 2013] .. [Tue Nov 19 20:49:41 2013] given (True /\ True) you can destruct it to get a True, so (True /\ True) = True [Tue Nov 19 20:49:48 2013] but you can't destruct a Cat or a Dog to get the other one [Tue Nov 19 20:49:54 2013] ... but he's gone [Tue Nov 19 21:03:13 2013] hrm [Tue Nov 19 21:03:44 2013] I'm note sure of either '(True /\ True) = True' or 'not ((True /\ True) = True)' is provable [Tue Nov 19 21:22:33 2013] that statement, forall p q, p <-> q -> p = q, seems pretty dodgy [Wed Nov 20 03:29:29 2013] Hm, people are probably asleep but I'll ask anyway [Wed Nov 20 03:30:30 2013] so in coq when you use Fixpoint you need to use primitive(ish) recursion or the definition will be rejected [Wed Nov 20 03:31:00 2013] dually, when doing CoFixpoint you need every recursive call to be guarded with a constructor [Wed Nov 20 03:31:07 2013] a sort of primitive corecursion [Wed Nov 20 03:32:08 2013] but you can get the primitive recursion restriction by proving that some argument is decreasing according to some "well founded" relation [Wed Nov 20 03:32:26 2013] is there a dual notion for corecursion? [Wed Nov 20 03:33:00 2013] a way to encode less simple notions of productivity? [Thu Nov 21 03:56:54 2013] hm [Thu Nov 21 04:31:15 2013] ok so ive got this subgoal [Thu Nov 21 04:32:01 2013] https://privatepaste.com/1707ff50a5 [Thu Nov 21 04:32:29 2013] basically, forall x, hs_compare x nil => Gt [Thu Nov 21 04:32:37 2013] except when x is nil [Thu Nov 21 04:33:14 2013] ive got the assumption notnil x (in the above paste-example its f, my bad) [Thu Nov 21 04:33:50 2013] how do i destruct f and then tell Coq that the case in which x is nil is ruled out by "H: notnil x"? [Thu Nov 21 04:34:24 2013] so that i can use H1 to prove the subgoal [Thu Nov 21 07:05:36 2013] How difficult to implement custom extraction for Coq? [Thu Nov 21 09:39:04 2013] How do I rewrite n + 1 to S(n). Tried unfolding the plus operator but i did not work [Thu Nov 21 09:40:04 2013] more concretely I have this expression S n' + 1 = S (S n') and I am using Arith. [Thu Nov 21 10:41:54 2013] Hi [Thu Nov 21 10:43:27 2013] notdan: This channel is pretty quiet most of the time. If you have a question, just ask and whoever is around will do their best :) [Thu Nov 21 11:16:44 2013] Yeah, thanks :) [Thu Nov 21 11:17:13 2013] One question that I had was about 'repeat'. Apparently I can't use to to repeatedly solve multiple subgoals [Thu Nov 21 11:17:27 2013] is there a way to get rid of a lot of subgoals at once? [Thu Nov 21 11:21:25 2013] notdan: you have to use ; to chain the repeat after the subgoals are generated. [Thu Nov 21 11:24:43 2013] Oh, that's right, thank you [Thu Nov 21 11:24:49 2013] I haven't touched Coq in a while [Thu Nov 21 11:25:35 2013] glad you're breaking your celibacy. [Thu Nov 21 11:33:43 2013] While you are online maybe you can recommend me something/comment in a line or two: https://sympa.inria.fr/sympa/arc/coq-club/2013-11/msg00154.html (not sure if you are subscribed) [Thu Nov 21 11:34:17 2013] OK, thanks to 'repeat', ';', and 'try' my proofs are not shorter [Thu Nov 21 11:34:51 2013] Oh, and Coq.inria.fr is down :( [Thu Nov 21 11:42:38 2013] not -> now? [Thu Nov 21 11:44:44 2013] I don't know much about petri nets or the libraries for relations :/ [Thu Nov 21 11:45:12 2013] If there's a relation union, you might try unioning Relation P T and Relation T P [Thu Nov 21 11:57:55 2013] Well I am talking not about petri nets specifically, but more about, you know, different models that involve sets and functions and relations. [Thu Nov 21 11:59:08 2013] 'Relation' is part of the standard library isn't it? [Thu Nov 21 11:59:20 2013] I guess I should ditch SF's libraries [Thu Nov 21 14:16:19 2013] Where can I read about Coq's 'Set'? [Thu Nov 21 14:16:30 2013] I can seem to find a lot of information about it :( [Thu Nov 21 23:49:00 2013] is there an easy way to have an inductive type parameter be explicit for the type former, and implicit for every constructor? [Thu Nov 21 23:49:49 2013] (as in, it should always be inferrable from the context type, so I'd like it to appear in the type, but not to type it after every constructor :\) [Fri Nov 22 07:01:20 2013] Could yoou ban kirillt? Its my irc launched on other machine, I havent access to it now. It can spam about a week or something untill it won't banned. [Fri Nov 22 09:53:06 2013] Ptival: you mean as the list type is? [Fri Nov 22 09:54:29 2013] the short answer is Set Implicit Arguments [Fri Nov 22 11:56:08 2013] How can avoid explicit type parameters while using coq's stdlib? E.g., I want to write 'symmetric myRel' instead of 'symmetric nat myRel' throughout the code [Fri Nov 22 11:57:25 2013] Set Implicit Arguments doesn't work? [Fri Nov 22 12:08:35 2013] No :( [Fri Nov 22 12:09:54 2013] http://lpaste.net/7115879121405607936 [Fri Nov 22 12:09:59 2013] A minimal example [Fri Nov 22 12:11:40 2013] Dan pasted “Implicit arguments” at http://lpaste.net/7115879121405607936 [Fri Nov 22 12:27:02 2013] it appears you can't. You can however just do Definition symmetric_ := symmetric. and use that instead. [Fri Nov 22 12:31:51 2013] Alright, thanks, that worked! [Fri Nov 22 12:38:22 2013] Another quick Q, how can I use EqLtNotation : http://coq.inria.fr/coq/stdlib/Coq.Structures.Orders.html#EqLtNotation [Fri Nov 22 12:38:47 2013] It seems that I need to declare a separate module that implements it and then require it? [Fri Nov 22 12:46:29 2013] hi everyone. can anyone explain me what does "being coded in it's own logic" mean? (an example use is here http://www.cs.utexas.edu/users/moore/best-ideas/acl2/index.html ) [Fri Nov 22 12:51:46 2013] Hm, I would guess that the calculus for ACL2 has been formalized in itself? BUt that doesn't sound right [Fri Nov 22 12:52:16 2013] yeah, I don't think that's what it means [Fri Nov 22 12:53:29 2013] Maybe in case of ACL2 it means that ACL2 is itself written in (subset of) Common Lisp and you can use it to reason about Common Lisp? [Fri Nov 22 12:56:43 2013] I guess it's more like "ACL2 written in Common Lisp which is a formal system by itself, and ACL2 uses that formal system for reasoning" or something like that but I may be misusing terms completely [Fri Nov 22 13:03:26 2013] osa1_: ACL2 is implemented in a subset of Common Lisp, some of which is the subset that it can prove properties about. [Fri Nov 22 13:04:14 2013] Not all of ACL2 is written in "logic mode" as they call it, because logic functions must be total, and they have non-terminating functions. [Fri Nov 22 13:04:49 2013] which are in "program mode" [Fri Nov 22 13:05:06 2013] I've hacked on ACL2 in the past. [Fri Nov 22 13:10:11 2013] ianjneu: "some of which is the subset that it can prove properties about" some of what? properties about itself? [Fri Nov 22 13:13:49 2013] sure. They tend to be really simple helper functions for manipulating proof state though. [Fri Nov 22 13:14:31 2013] If you want to see something /like/ ACL2 that is entirely written in itself, check out Milawa [Fri Nov 22 13:15:35 2013] ACL2 talk in #coq? [Fri Nov 22 13:15:39 2013] am I dreaming? :P [Fri Nov 22 13:15:52 2013] osa1_: you might want to ask in #acl2 [Fri Nov 22 13:16:05 2013] there's a #acl2? [Fri Nov 22 13:16:12 2013] yup, as of a couple months ago (I made it) [Fri Nov 22 13:16:21 2013] one of the ACL2 authors has been kind enough to start lurking in there too [Fri Nov 22 13:16:31 2013] as well as a few former PhD students from the ACL2 research group at UT [Fri Nov 22 13:16:40 2013] Ya, I know Sol and Matt. [Fri Nov 22 13:17:17 2013] clop is jared davis and darage is david rager, if you know them [Fri Nov 22 13:17:25 2013] yup yup. [Fri Nov 22 13:17:44 2013] Went to the ACL2 seminar my last year at UT. [Fri Nov 22 13:17:58 2013] cool, I didn't know you were at UT [Fri Nov 22 13:18:05 2013] I just started here as a first year PhD student this year [Fri Nov 22 13:18:20 2013] ah so. [Fri Nov 22 13:18:58 2013] What're they up to currently? Still chip verification stuff I assume. [Fri Nov 22 13:19:14 2013] and I'm a CS undergrad who are currently applying to grad schools :-P [Fri Nov 22 13:19:28 2013] osa1_: at UT? [Fri Nov 22 13:19:50 2013] ianjneu: still doing x86 modeling, yeah [Fri Nov 22 13:20:03 2013] but I'm not sure whether calling it "chip verification" is accurate [Fri Nov 22 13:20:11 2013] kini: no, some random university outside of the US. I'm currently doing an internship at UIUC though. [Fri Nov 22 13:20:18 2013] If you want to coq for a living, Harvard, MIT and UPenn are up there. [Fri Nov 22 13:20:27 2013] the group is officially called the "Hardware Verification Group", but I was told that what we're actually doing is low-level software verification [Fri Nov 22 13:20:50 2013] yes, I already applied to UPenn, and I don't think I'm good enough for Harvard and MIT (I have very low GPA) [Fri Nov 22 13:20:54 2013] I guess when doing verification you create a model and then verify the behavior of something slightly higher level than what the model is modeling by analyzing the thing's interface to its backend, which is your model [Fri Nov 22 13:21:06 2013] osa1_: do you have research experience? [Fri Nov 22 13:21:19 2013] so this project is at the boundary, where the model is of hardware and the object being verified is software [Fri Nov 22 13:21:27 2013] ianjneu: yes, two internship at two different universities [Fri Nov 22 13:21:31 2013] internships* [Fri Nov 22 13:21:41 2013] but no papers, unfortunately [Fri Nov 22 13:21:50 2013] ah. [Fri Nov 22 13:22:04 2013] if I had known more about the field when I was applying to grad schools I would have applied to those three schools as well, haha [Fri Nov 22 13:22:17 2013] well, Maryland is getting a new professor in static analysis. They're looking for students [Fri Nov 22 13:22:20 2013] but UT is pretty nice too, though there's like one Coq user here who just graduated (afaik) [Fri Nov 22 13:22:32 2013] ianjneu: yeah I'll apply to Maryland, too :-) [Fri Nov 22 13:22:34 2013] and maybe <5 isabelle users [Fri Nov 22 13:23:44 2013] their PL group is "plum" [Fri Nov 22 13:24:50 2013] I saw something out of maryland, I forgot what it was... [Fri Nov 22 13:24:57 2013] other universities I already applied: Indiana and Portland State. I guess I'm done after applied to Maryland (which will make 4 universities) [Fri Nov 22 13:25:19 2013] oh ya, Indiana just got Sam Tobin-Hochstadt and Jeremy Siek. [Fri Nov 22 13:25:30 2013] osa1_: what unis outside of the US are you applying to? I am asking because I am a CS undergrad too [Fri Nov 22 13:25:45 2013] osa1_: I was at portland state for a year [Fri Nov 22 13:25:54 2013] there are some really cool people there, and portland is a great city [Fri Nov 22 13:25:59 2013] notdan: I'm not applying anywhere outside of the US, mostly because I have no idea where to apply and I liked uni. environment in the US [Fri Nov 22 13:26:19 2013] but I didn't take GRE this year so I won't be getting in any of the US universities [Fri Nov 22 13:26:20 2013] ianjneu: yeah, we met with them at PLFest [Fri Nov 22 13:26:22 2013] Portland is really white. Like /really/ white. [Fri Nov 22 13:26:39 2013] oh, sorry, I read your message as if you are applying to random universities outside of the US [Fri Nov 22 13:26:58 2013] bleh [Fri Nov 22 13:27:11 2013] notdan: what universities are you applying outside the US ? [Fri Nov 22 13:27:19 2013] but I was warned by a PSU student that I shouldn't go there because the average ability of students there is sort of low and the faculty don't publish that much as it's not that competitive a university, rankings-wise [Fri Nov 22 13:27:20 2013] haha [Fri Nov 22 13:27:37 2013] ianjneu: that's true [Fri Nov 22 13:27:57 2013] not any more so than austin though I don't think [Fri Nov 22 13:27:57 2013] kini: that may be a good thing for me because my GPA is very low and I basically depend on recommendation letters and previous experience [Fri Nov 22 13:28:26 2013] osa1_: the PL people there are quite good I think, faculty and grad students alike [Fri Nov 22 13:28:32 2013] osa1_: I want to apply to Free University of Bozen Bolzano, Chalmers, Humboldt U, any uni in the EMCL program [Fri Nov 22 13:28:36 2013] kini: not at all. My wife is black and was totally comfortable in Austin. [Fri Nov 22 13:28:54 2013] but I have to take TOEFL or IELTS before I can apply :S [Fri Nov 22 13:29:02 2013] Portland is was a game of "try to spot a black person" and we just gave up. [Fri Nov 22 13:29:03 2013] ianjneu: I see. Well, I haven't paid much attention to things like that, and also I haven't really explored much beyond the confines of the university yet :) [Fri Nov 22 13:29:12 2013] it was* [Fri Nov 22 13:29:29 2013] notdan: yeah, I took required tests while doing my current internship at UIUC .. [Fri Nov 22 13:29:30 2013] kini: check out Barton Springs. [Fri Nov 22 13:29:34 2013] it's pretty. [Fri Nov 22 13:30:08 2013] osa1_: hm, so you have already finished your bachelors, haven't you? or you are finishing it this year [Fri Nov 22 13:30:14 2013] *are you [Fri Nov 22 13:30:17 2013] notdan: I'm finishing on April 2014 [Fri Nov 22 13:30:26 2013] Oh [Fri Nov 22 13:30:36 2013] Well, I envy your ability to manage your time [Fri Nov 22 13:31:17 2013] huh, why? [Fri Nov 22 13:43:04 2013] osa1_: You manage to study for your degree, work as an intern in a foreign university and prepare for/take the necessary exams. That's a lot of stuff to do :) [Fri Nov 22 13:54:42 2013] notdan: well, I don't think I managed to do "study for your degree" part, my GPA is 2.7 :-P [Fri Nov 22 13:55:48 2013] your statement of purpose and letters of recommendation are much more important than you GPA [Fri Nov 22 13:55:51 2013] your* [Fri Nov 22 13:56:36 2013] yeah, that's what motivates me to apply, because all grad schools I applied say that they need at least 3.0 GPA [Fri Nov 22 14:53:29 2013] notdan: you can also use the Arguments command to change the treatment of the arguments for an already defined identifier [Fri Nov 22 14:53:40 2013] e.g. Arguments symmetric {A} _. [Fri Nov 22 16:27:21 2013] notdan: > I want to write 'symmetric myRel' instead of 'symmetric nat myRel' <- Is 'symmetric _ myRel' good enough for you? Alternatively, you can do 'Local Arguments symmetric [_] R _ _ _.' to make the first parameter implicit (use {_} for implicit and maximally inserted). I'd suggest Local rather than Global, or it'll confuse people who Import your code. [Sat Nov 23 05:19:17 2013] jgross_: thanks :) [Sun Nov 24 15:39:22 2013] Can I prove that forall A, Empty_set = sig A (fun _ => False)? [Sun Nov 24 23:45:03 2013] what does "smallest in the subtype relation" mean? [Mon Nov 25 00:53:02 2013] osa1: context? [Mon Nov 25 08:09:42 2013] I am trying to introduce the following notation: Notation "'set' i := j + c" := (WAssgnPlus i j c) (at level 200). [Mon Nov 25 08:10:16 2013] however, I can not get fun (i j: Var) c => (set i := j + c) to be accepted by coq [Mon Nov 25 08:10:34 2013] Syntax error: '+' expected after [constr:operconstr level 200] (in [constr:binder_constr]). [Mon Nov 25 08:11:04 2013] are there any references on how to debug notations? [Mon Nov 25 08:17:03 2013] ah, adding "j at level 40" fixed it [Mon Nov 25 14:32:53 2013] r [Tue Nov 26 08:17:57 2013] I'm probably misphrasing this but is there an easy way in Coq to force a value in a match based on an index? More specifically if you have some type "d x" with a constructor "C : forall x, d x", you'd like to know when you match on C that the x is the same one. [Tue Nov 26 08:18:44 2013] I know Adam Chlipala's book has several good tricks but maybe there's a more extensive list somewhere? [Tue Nov 26 12:13:37 2013] Can someone who is knowledgeblable please comment/answer my Q: https://sympa.inria.fr/sympa/arc/coq-club/2013-11/msg00164.html [Tue Nov 26 12:18:10 2013] ack, but I don't use modules since types are anti-modular. [Tue Nov 26 12:19:44 2013] I think you need to use the "with Definition" form rather than use internal definitions. [Tue Nov 26 12:26:05 2013] hm doesn't work either, but maybe I am messing something up [Tue Nov 26 12:26:18 2013] definitely going to try it using 'with' later, thanks [Tue Nov 26 12:26:35 2013] out of curiousity, why do you say that types are anti-modular? [Tue Nov 26 12:26:49 2013] And why, in that case, Coq's standard library makes such immense use of modules? [Tue Nov 26 12:31:00 2013] Coq is an experiment in the use of dependent types for large-scale programming. It's had mixed success. [Tue Nov 26 12:32:54 2013] Types are anti-modular in the sense that they leak implementation details. When you use existentials, you end up unable to prove properties about your modules. If you export lots of propositional equalities where you previously would have definitional equalities, you get into problems where many things are not well-typed. Bob Harper admits that definitional equalities lead to the same anti-modular patterns that are rampant in OO code. [Tue Nov 26 12:33:45 2013] We don't know how to do without definitional equalities yet, and without exposing the code for certain internals, you can make certain higher-order programming patterns impossible to prove terminating. [Tue Nov 26 12:35:34 2013] For some reason your R is not convertible to MyModT.t -> MyModT.t -> Prop, and that's why it's erroring. The reason for that is the Funsig instantiation does not remember that the module its given is definitionally equal to MyModT. [Tue Nov 26 12:40:32 2013] Got it. Add "with Definition t := A" after MyModT : Typ [Tue Nov 26 13:07:15 2013] ianjneu: "If you export lots of propositional equalities where you previously would have definitional equalities, you get into problems where many things are not well-typed." -- can you give a pointer to an example or background reading? [Tue Nov 26 13:16:08 2013] I still don't get Harper's argument about OO being anti-modular [Tue Nov 26 13:16:18 2013] is that stuff spelled out somewhere for newbs like me? [Tue Nov 26 13:17:07 2013] inb4 read through PFPL [Tue Nov 26 13:18:15 2013] ianjneu: hm, it works for "with Definition" but not for "with Axiom" [Tue Nov 26 15:24:40 2013] http://lpaste.net/1110043978507485184 What is going on in there? [Tue Nov 26 15:25:23 2013] Why is rt1n_trans defined to be a notation for clos_rt1n_rt they have a completely different signatures [Tue Nov 26 15:25:26 2013] -a [Tue Nov 26 16:02:37 2013] notdan: I don't know. [Tue Nov 26 17:05:09 2013] hey the website seems to be down [Tue Nov 26 17:05:23 2013] is there a mirror somewhere [Tue Nov 26 17:05:32 2013] or at least some reference material? [Tue Nov 26 17:11:35 2013] maxiepoo: they distribute the reference manual as a tar.gz, but if you didn't grab it before I suppose that won't help you now :( [Tue Nov 26 17:11:58 2013] IIRC the standard library documentation is generated from the sources, so if you built from source you can at least refer to that [Tue Nov 26 17:19:29 2013] hm I installed with yum [Tue Nov 26 17:19:33 2013] maybe it's here somewhere [Tue Nov 26 17:39:30 2013] so why Coq generates weak induction hyphothesis in first encoding of record types here http://www.cis.upenn.edu/~bcpierce/sf/Records.html ? [Tue Nov 26 17:41:32 2013] records aren't recursive. Why would there be a non-degenerate induction scheme? [Tue Nov 26 17:43:01 2013] ianjneu: what does non-degenerate mean? record constructor's first parameter is definitely an inductive type, what I don't understand is why generated induction scheme doesn't take that into account [Tue Nov 26 17:47:33 2013] Degenerate means you don't have a self-reference to the type anywhere. Booleans are a degenerate inductive type, for example. [Tue Nov 26 17:48:59 2013] I also have another question; I want to implement some formalizations from some papers in Coq as a learning exercise, which papers do you recommend me for this? I'm mostly interested in type systems, type inference etc. [Tue Nov 26 17:51:32 2013] Adam Chlipala has some papers on proving compiler correctness of simple languages in Coq, using his (now bitrotted) Lambda Tamer library. Software foundations has many examples, but I wouldn't consider their approach anything more than brute force. [Tue Nov 26 17:52:00 2013] Substitution is just a bitch to do in Coq. [Tue Nov 26 17:52:15 2013] It's much better in Twelf, but Twelf has very little automation. [Tue Nov 26 17:55:29 2013] ianjneu: what's wrong with SF's approach? [Tue Nov 26 17:55:39 2013] I learned all I know about Coq from SF :-) [Tue Nov 26 17:58:47 2013] osa1: do you own TAPL? [Tue Nov 26 17:59:13 2013] I recommend finding a chapter in there that you find interesting that is not already done in SF and doing it in SF style [Tue Nov 26 17:59:16 2013] jrw: yeah, I already read half of it [Tue Nov 26 17:59:31 2013] I also recommend adam's CPDT [Tue Nov 26 17:59:43 2013] They use a really nasty environment library based on alists and lots of representation-specific lemmas. It's not modularized by the behavior of finite maps. It's entirely unportable to better representations.e [Tue Nov 26 18:00:04 2013] ianjneu: what are some better representation? [Tue Nov 26 18:00:30 2013] some kind of balanced tree, for example. [Tue Nov 26 18:00:49 2013] or hash maps, or anything else you might expect to actually use in an interpreter [Tue Nov 26 18:00:57 2013] osa1: ianjneu point is really that the internal representation shouldn't matter [Tue Nov 26 18:01:29 2013] the problem is I've tried to abstract this out, but Coq is just limited by its need to work with definitional equalities. [Tue Nov 26 18:02:48 2013] yes, this is a more general problem in coq than just sf [Tue Nov 26 18:02:59 2013] I work and think really abstractly. Like a good software engineer, I separate concerns behind interfaces. The type theory Coq uses, while state-of-the-art, is unable to handle such abstractions. [Tue Nov 26 18:03:59 2013] interesting, so are there other theories that have equalities other than simple syntactic equalities that we have in Coq ? [Tue Nov 26 18:05:08 2013] propositional equalities are getting better understood in HoTT, but we're still not at a point where definitional equalities can be reliably removed and still have a usable library. [Tue Nov 26 18:05:43 2013] short answer: no. Getting work done in Coq is like getting work done in Pascal. Duplicate effort all over. [Tue Nov 26 18:06:44 2013] gotta go [Tue Nov 26 18:06:48 2013] ianjneu: how can this prevent us from unified interfaces? let's say I can provide equalitiy of my terms to some other terms, given some interface implemented for that other term etc. [Tue Nov 26 18:06:51 2013] uh [Tue Nov 26 18:07:02 2013] from having unified interfaces* [Tue Nov 26 18:54:03 2013] Sometimes, when I refine, Coq will existentialize one of my holes. Is there a way to make it not do that? [Tue Nov 26 19:16:43 2013] unfortunately, I don't think so :\ [Tue Nov 26 19:16:57 2013] maybe by introducing artificial constructs like a let-binding, but it's somewhat annoying? [Wed Nov 27 14:27:52 2013] how do vectors work? [Wed Nov 27 14:28:02 2013] how are they different from lists for example [Wed Nov 27 14:46:38 2013] for example how do i build a nat vector of size 3 containing 1 2 3? [Wed Nov 27 14:54:03 2013] ha Vcons [Wed Nov 27 15:01:33 2013] they work like lists but are indexed with their length [Wed Nov 27 15:09:37 2013] yep starting to make sense [Wed Nov 27 15:09:49 2013] is there a less cumbersome way of constructing them? [Wed Nov 27 15:10:27 2013] besides Vcons a (Vcons b (Vcons c Vnil))) for the vector nat 3 equivalent of a :: b :: c :: nil? [Wed Nov 27 15:10:44 2013] how is that cumbersome? [Wed Nov 27 15:10:55 2013] eh thats not entirely correct ;p but you get my point i guess [Wed Nov 27 15:11:28 2013] the list notation is more convenient for manual labor [Wed Nov 27 15:11:40 2013] you can make a notation for it too [Wed Nov 27 15:11:52 2013] ha cool [Wed Nov 27 15:11:54 2013] guess ill do that [Wed Nov 27 15:11:59 2013] how does that work? [Wed Nov 27 15:12:19 2013] alternatively, I also like to write a function "mkVec : forall {T} (l : list T) -> Vec T (length l)" [Wed Nov 27 15:12:44 2013] but [Wed Nov 27 15:13:12 2013] yea something like that :) [Wed Nov 27 15:14:18 2013] Notation "[| x ; .. ; y |]" := (VecCons x .. (VecCons y (VecNil _)) ..). [Wed Nov 27 15:15:36 2013] works but with Vcons and Vnil [Wed Nov 27 15:16:34 2013] Notation "[| x ; .. ; y |]" := (Vcons x .. (Vcons y (Vnil _)) ..). [Wed Nov 27 15:16:34 2013] Check [| 1 ; 2 ; 3 |]. [Wed Nov 27 15:17:00 2013] should that give : vector nat 3? [Wed Nov 27 15:17:22 2013] you can even reuse the list notation, using scopes to allow both to coexist [Wed Nov 27 15:19:18 2013] what is VecCons, do i need to import a library for that? [Wed Nov 27 15:20:01 2013] is there a better way to find corresponding libraries besides doing a google search for "Coq someFunction"? [Wed Nov 27 15:26:52 2013] Ptival? :p [Wed Nov 27 15:35:00 2013] nevermind ill figure something out [Wed Nov 27 15:35:11 2013] <3 [Thu Nov 28 05:25:50 2013] nat is the Set of natural numbers, right [Thu Nov 28 05:26:02 2013] whats the Set of letters [Thu Nov 28 05:26:42 2013] i want a huge set of characters to use as function symbols [Thu Nov 28 05:27:13 2013] could also just use something like (F n) i guess, but im just curious if theres a set of letters available in Coq [Thu Nov 28 15:43:10 2013] :w [Fri Nov 29 11:05:32 2013] Anybody knows is there channel for Coq devs? [Fri Nov 29 11:16:27 2013] Are you sure there's a channel? I know there's the coqdev mailing list. [Fri Nov 29 11:40:43 2013] when I was active, I was the only one here... [Fri Nov 29 17:04:19 2013] Anybody know when new release is planned? [Fri Nov 29 17:42:26 2013] Rc43: Soon, I'd hope. Maybe within the next year? There are a number of new features that have either recently been merged or are in the process of being finished up and merged, so I wouldn't be surprised if 8.5 comes out in the next year or so. [Sat Nov 30 07:22:49 2013] Hello. [Sat Nov 30 07:25:24 2013] I solved Basics chapter of "software foundations" in coq and now i'm trying to do the same in agda. Encountered a little problem http://vpaste.net/WaJdg . Not sure how can i apply neg-involutive to prove neg-involution... [Sat Nov 30 11:40:26 2013] Is it provable forall n : nat, 0 = n + n -> n = 0. ? [Sat Nov 30 11:50:33 2013] http://lpaste.net/96410 How can prove it in coq? [Sat Nov 30 12:01:46 2013] http://lpaste.net/96411 That was hard. [Sat Nov 30 12:02:02 2013] I've dumped my 0 = n + n -> n = 0 afterall. [Sat Nov 30 14:05:15 2013] How can i prove m * S n = m + m * n ? [Sat Nov 30 14:13:15 2013] People? [Sat Nov 30 14:16:44 2013] aico4: What definition of * are you using? Pattern matching on the first argument? [Sat Nov 30 14:26:46 2013] lolcathost: Yep. [Sat Nov 30 15:42:46 2013] lolcathost: Is it possible to prove without changing definition of *? [Sun Dec 1 06:12:29 2013] Hello. [Sun Dec 1 06:12:54 2013] I have "rewrite mult_0_r. rewrite mult_0_r. rewrite mult_0_r. " in my proof. Is there a way rewrite all at once? [Sun Dec 1 06:13:02 2013] to rewrite* [Sun Dec 1 06:16:40 2013] aico4: you could write ';' instead of '.' after previous tactic, so 'rewrite mult_0_r' will be applied to everything which it'll yield [Sun Dec 1 06:17:33 2013] oh, sorry, did not get the question probably [Sun Dec 1 06:18:15 2013] maybe 'repeat' is what you want [Sun Dec 1 06:18:55 2013] like 'repeat (rewrite mult_0_r)' [Sun Dec 1 06:23:26 2013] defanor: Thank you. Repeat is great. [Sun Dec 1 06:23:53 2013] yw [Sun Dec 1 09:08:16 2013] aico4, defanor: rewrite !mult_0_r (to rewrite 1 ore more times), or rewrite ?mult_0_r (to rewrite 0 or more times) is the more idiomatic way of doing that [Sun Dec 1 09:09:03 2013] robbert: Thanks for tip. [Sun Dec 1 16:06:20 2013] wow I totally ignored that :( [Sun Dec 1 16:21:30 2013] Ptival: ? [Sun Dec 1 16:45:22 2013] the ! and ? modifiers for rewrite [Mon Dec 2 10:37:28 2013] Hi, guys. [Mon Dec 2 10:37:40 2013] Are there any coq-developers? [Mon Dec 2 10:38:04 2013] I am trying to apply patch to coq, but it gives wrong behaviour. [Mon Dec 2 10:38:18 2013] I tried to run test-suite (cd test-suite && make run) [Mon Dec 2 10:38:25 2013] But I don't understand results. [Mon Dec 2 10:38:46 2013] There is folder "failures", but seems that it means "expected failures". [Mon Dec 2 10:38:55 2013] How to see errors? [Mon Dec 2 10:43:10 2013] that seems like a question for coq-club. [Mon Dec 2 10:43:30 2013] There is a dearth of documentation for this stuff :/ [Mon Dec 2 10:48:08 2013] ianjneu, mailing lists are quiet slow =/ [Mon Dec 2 10:49:21 2013] Rc43: You'll get a response today I'm quite sure. [Mon Dec 2 11:21:15 2013] Rc43: gg [Mon Dec 2 11:21:46 2013] ianjneu, received my mail? :) [Mon Dec 2 11:22:00 2013] yup. [Mon Dec 2 14:56:32 2013] Hello, is there something beyond `match' in function definition langauge(not sure what name iyt has)? [Mon Dec 2 14:56:55 2013] Something like `let' would nice to have. [Mon Dec 2 14:57:12 2013] let and fix are expression constructs [Mon Dec 2 14:57:30 2013] let (x,y) := a_pair in body. [Mon Dec 2 14:57:48 2013] fix is a nested fixpoint definition [Mon Dec 2 14:58:06 2013] ianjneu: Thanks, but where i can read about all possilbe syntax for function definition language? [Mon Dec 2 14:58:33 2013] http://coq.inria.fr/refman/Reference-Manual003.html [Mon Dec 2 14:59:13 2013] ianjneu: Ah, so it's called "Gallina", great, thank you. [Mon Dec 2 14:59:26 2013] Yup. [Mon Dec 2 15:01:07 2013] it means hen in Spanish. [Mon Dec 2 15:34:46 2013] http://vpaste.net/a3nFr How can if fix "Error: Cannot guess decreasing argument of fix." for remove_all? [Mon Dec 2 15:34:57 2013] s/if/i/ [Mon Dec 2 15:41:59 2013] Well, i could copy-past remove_one definition and change on `match' branch a bit but if it possible to reuse remove_one? [Mon Dec 2 15:46:19 2013] What you're doing is generative recursion, not structural recursion. You have to prove to coq that remove_one always decreases in size. [Mon Dec 2 15:46:40 2013] See the reference manual for well-founded recursion. [Mon Dec 2 16:02:24 2013] ianjneu: Okay, thanks. [Mon Dec 2 16:02:44 2013] Is [] subset of [whatever]? [Mon Dec 2 16:03:19 2013] More pecifically is [] subset of [1,2,3]? [Mon Dec 2 16:04:18 2013] empty is a subset of all sets. [Mon Dec 2 16:06:29 2013] ianjneu: Cool. [Mon Dec 2 16:09:46 2013] "Write down an interesting theorem about bags involving the functions [count] and [add], and prove it." it's from SF. [Mon Dec 2 16:09:53 2013] Can you suggest something interesintg? [Mon Dec 2 16:12:22 2013] (count (add a b)) = (count a)+(count b) ? [Mon Dec 2 16:17:03 2013] ianjneu: He-he, "count" counts occurances of element in natlist and add just adds elment to head of list(x :: xs). :) [Mon Dec 2 16:21:05 2013] aico4: fine, make it forall v, (count v (add a b)) = (count v a) + (count v b). [Mon Dec 2 16:23:44 2013] ianjneu: "Definition add (v:nat) (s:bag) : bag := v :: s." Bag is natlist, it can't concat two lists but just add one element ot head (cons). [Mon Dec 2 16:26:06 2013] okay, so even simpler: count v (add v a) = S (count v a). [Mon Dec 2 16:26:35 2013] ianjneu: Oh, thanks, sounds interesting. [Mon Dec 2 16:37:18 2013] ianjneu: How do you think, does it porvable using only rewrite/induction/simpl/reflexevity tactics? [Mon Dec 2 16:44:11 2013] http://vpaste.net/gnRv4 I wonder why it's not reflexive? [Mon Dec 2 16:44:22 2013] n n are obviously equal. [Mon Dec 2 16:46:08 2013] aico4: you need a lemma to reduce beq_nat n n to true. [Mon Dec 2 16:46:14 2013] I guess i have to prove that to. [Mon Dec 2 16:46:19 2013] ystael: Yeah. [Mon Dec 2 16:46:47 2013] if you've been going through SF up to this point, you should have that lemma already. [Mon Dec 2 16:49:18 2013] ystael: Indeed, just found it. [Mon Dec 2 16:50:07 2013] And having that "count v (add v a) = S (count v a)" easy as "intros. simpl. rewrite <- beq_nat_refl. reflexivity." . :) [Mon Dec 2 16:53:18 2013] Thank you guys! [Tue Dec 3 04:46:12 2013] hi guys, is there any ETA regarding a V8.4pl3 that will include the trivial fix for gnumake 4.0 bug (id 3137) or shall I apply a gentoo based patch for the time being as it started hitting our users? [Tue Dec 3 05:04:35 2013] good question [Tue Dec 3 05:17:37 2013] pchrist: coqdev@inria.fr is probably a better place to ask [Tue Dec 3 13:51:07 2013] Hello. [Tue Dec 3 13:51:19 2013] Trying to prove rev (rev l) = l. [Tue Dec 3 13:52:07 2013] Inudcing on l. When l = [] it's simple - reflexivity. [Tue Dec 3 13:52:26 2013] When it's x :: xs - i don't know. [Tue Dec 3 13:52:30 2013] Any hints? [Tue Dec 3 13:53:54 2013] aico4: it should go fairly straightforwardly from the earlier lemma rev_snoc [Tue Dec 3 13:56:18 2013] ystael: http://www.cis.upenn.edu/~bcpierce/sf/Lists.html There is no rev_snoc. I'll try to define it. What does it states? [Tue Dec 3 13:56:37 2013] snoc (rev xs) x = rev (x :: xs) ? [Tue Dec 3 13:57:42 2013] aico4: hm, I thought that was in the text, but I guess I just added that myself :) [Tue Dec 3 13:58:41 2013] try to find an equation about what you get in the inductive hypothesis [Tue Dec 3 13:59:39 2013] what you gave might work, though it's not what i used [Tue Dec 3 14:00:53 2013] ystael: I don't think "snoc (rev xs) x = rev (x :: xs) " will give me something usefull because coq just simplified rev (x :: xs) to snoc (rev xs) x. [Tue Dec 3 14:01:18 2013] ystael: What equation do you mean? What i get in the induction hypothesis? [Tue Dec 3 14:06:19 2013] ystael_: IHl : rev (rev l) = l this is my inductive hypothesis. [Tue Dec 3 14:06:26 2013] So it's basically a goal. [Tue Dec 3 14:06:45 2013] ystael_ try "destruct l" [Tue Dec 3 14:06:59 2013] ystael_ it applies the basis cases of the type [Tue Dec 3 14:08:50 2013] http://vpaste.net/D8i8s Thats what i have so far. [Tue Dec 3 14:09:28 2013] Anarchos: Is destruct the same as induction but without hypothesis? [Tue Dec 3 14:11:51 2013] After simpl i got " rev (snoc (rev l) n) = n :: l" [Tue Dec 3 14:12:35 2013] aico4 yes it is [Tue Dec 3 14:17:00 2013] Anarchos: Do you mean i need to perform induction and then destruct on l? [Tue Dec 3 14:22:58 2013] aico4 no : either induction, or destruct l. It is the same [Tue Dec 3 14:23:51 2013] Anarchos: It's not. [Tue Dec 3 14:24:06 2013] Induction gives hypothesis, destruct does not. [Tue Dec 3 14:26:54 2013] rev (app x y) = app (rev y) (rev x) [Tue Dec 3 14:27:34 2013] ianjneu yes it is true. [Tue Dec 3 14:28:03 2013] does SF's rev use snoc or app? [Tue Dec 3 14:29:18 2013] snoc l a = app l (list a) so the lemma simplifies to rev (snoc x a) = a :: (rev x) [Tue Dec 3 14:30:02 2013] (list a) meaning (a :: nil). I've been programming in Racket for a long time now. Worlds colliding. [Tue Dec 3 15:06:07 2013] ianjneu did you take into account that a::nil is written [a] in coq, as in ocaml ? [Tue Dec 3 15:23:51 2013] Anarchos: I've given up on syntax, as is evident by my Racket use. [Wed Dec 4 06:53:26 2013] Hi, guys. [Wed Dec 4 06:54:05 2013] Anybody know how to disable "import qualified Prelude" in extraction of haskell code from coq? [Wed Dec 4 06:54:09 2013] *knows [Wed Dec 4 09:40:49 2013] whats an FSet [Wed Dec 4 09:48:56 2013] finite set [Wed Dec 4 09:49:48 2013] now replaced with MSet apparenttly http://coq.inria.fr/distrib/current/stdlib/Coq.MSets.MSets.html [Wed Dec 4 09:55:28 2013] is there a function to decide equality between elements of a set? [Wed Dec 4 09:55:33 2013] (of an arbitrary set, that is) [Wed Dec 4 09:56:15 2013] i dont want to have to match a, b with some huge list of a, a => true | b, b => true | c, c => true | etc.. [Wed Dec 4 09:59:22 2013] hm I think there can be one for finite sets [Wed Dec 4 09:59:44 2013] I haven't used FSets/MSets thought. There is no such thing for Ensembles, strangely [Wed Dec 4 10:00:39 2013] there is http://coq.inria.fr/distrib/current/stdlib/Coq.MSets.MSetDecide.html [Wed Dec 4 10:04:59 2013] not using FSet or MSet actually :p i dont know how to use them, all those libraries confuse me [Wed Dec 4 10:05:23 2013] for Set though, is there an equality decider function? [Wed Dec 4 10:42:32 2013] is there a function to fill this gap? [Wed Dec 4 10:42:49 2013] Lemma beq_symb_ok : forall f g : fletter, some_function f g = true <-> f = g. [Wed Dec 4 10:43:02 2013] (the gap here being 'some_function') [Wed Dec 4 10:44:17 2013] what's this? [Wed Dec 4 10:44:21 2013] haha [Wed Dec 4 10:44:25 2013] hello ianjneu [Wed Dec 4 10:44:39 2013] im working on term rewriting [Wed Dec 4 10:44:58 2013] trying to get a simple base off the ground using CoLoR (a library on term rewriting) [Wed Dec 4 10:45:54 2013] i want to use an arbitrary set as a datatype [Wed Dec 4 10:46:07 2013] to define the signature, a decidable equality function is required [Wed Dec 4 10:47:22 2013] since i want to use an arbitrary (finite) Set, i cant define an explicit function like match f, g with a, a => true | b, b => true | c, c => true | ... | _, _ => false end. [Wed Dec 4 10:48:01 2013] It tends to be easier to use the decide equality tactic and derive the boolean function from that. [Wed Dec 4 10:48:24 2013] the decidable equality tactic being eq_dec? [Wed Dec 4 10:48:41 2013] Definition fletter_dec_eq : forall f g : fletter, {f = g}+{f <> g}. repeat decide equality. Defined. [Wed Dec 4 10:49:32 2013] Then Definition flatter_beq (f g : fletter) := if flatter_dec_eq f g then true else false. [Wed Dec 4 10:49:50 2013] fletter_beq* [Wed Dec 4 10:53:25 2013] not working [Wed Dec 4 10:53:25 2013] https://privatepaste.com/a6ae7040db [Wed Dec 4 10:54:09 2013] oh, you have an arbitrary type in an fletter. [Wed Dec 4 10:54:20 2013] yea thats probably why [Wed Dec 4 10:54:40 2013] how about you make fletter take a decidable type? [Wed Dec 4 10:54:53 2013] isnt Set a decidable type? [Wed Dec 4 10:55:03 2013] not at all. [Wed Dec 4 10:55:11 2013] why not [Wed Dec 4 10:55:13 2013] its finite [Wed Dec 4 10:55:15 2013] i thought? [Wed Dec 4 10:55:25 2013] Nope. Set = Type_0 [Wed Dec 4 10:55:42 2013] i would use FSet if i had any idea of how that worked [Wed Dec 4 10:55:44 2013] It's an arbitrary type of data, which can contain functions etc. [Wed Dec 4 10:56:21 2013] MSets are the preferred container now, I think. [Wed Dec 4 10:56:35 2013] CoLoR still uses FSet i think [Wed Dec 4 10:56:56 2013] how do i refer to an FSet? What libraries do i need to Require Import? [Wed Dec 4 10:57:16 2013] FSetInterface [Wed Dec 4 10:57:17 2013] is there some online (simple) example of FSet being applied? [Wed Dec 4 10:57:33 2013] and probably FSetDecide [Wed Dec 4 10:58:00 2013] ya, there are instantiations to different implementations, using lists and AVL trees. [Wed Dec 4 10:58:24 2013] for an alphabet-like set [Wed Dec 4 10:58:34 2013] which would be appropriate [Wed Dec 4 10:58:48 2013] just unordered lists i guess? [Wed Dec 4 10:58:57 2013] ya [Wed Dec 4 10:59:17 2013] There should be a list->set function I think. [Wed Dec 4 11:00:05 2013] ya, you can just fold add over a set with empty as a base case. [Wed Dec 4 11:00:12 2013] over a list* [Wed Dec 4 11:00:56 2013] sounds good [Wed Dec 4 11:01:09 2013] whats the 'type' of the resulting set, though? [Wed Dec 4 11:04:28 2013] i can sort of understand the mechanics behind these libraries, but its often unclear to me what elements these are actually applied to [Wed Dec 4 11:04:31 2013] Well, you will have a module FLetterSet := FSetWeakList.Make Fletter_as_decidable_type. The type of the set will be FLetterSet.t [Wed Dec 4 11:05:08 2013] hm [Wed Dec 4 11:05:10 2013] Fletter_as_decidable_type is a shim module you'll have to make with the Decidable_Type signature. [Wed Dec 4 11:05:23 2013] Er, no underscore. [Wed Dec 4 11:05:46 2013] Coq modules and functors are annoying. I'd much rather have units. [Wed Dec 4 11:05:57 2013] :p [Wed Dec 4 11:06:01 2013] yea i dont like modules either [Wed Dec 4 11:06:12 2013] although im not sure what functors or units are haha [Wed Dec 4 11:07:11 2013] functors are essentially functions from modules to modules that can (in Coq) expose certain abstract types as being definitionally equal to types its instantiating with. [Wed Dec 4 11:07:35 2013] But they're second class, so they can't take functors as values. [Wed Dec 4 11:07:58 2013] hm [Wed Dec 4 11:09:48 2013] exposing those equalities is rather important to make things work, actually. [Wed Dec 4 11:10:56 2013] hm [Wed Dec 4 11:16:16 2013] ok i should definitely look into this [Wed Dec 4 11:16:25 2013] its starting to make more sense [Wed Dec 4 11:16:35 2013] thanks ianjneu [Wed Dec 4 11:17:48 2013] n/p [Wed Dec 4 13:45:28 2013] Hello. [Wed Dec 4 13:45:41 2013] Still trying to prove rev (rev l) = l. [Wed Dec 4 13:51:12 2013] hi [Wed Dec 4 13:52:05 2013] http://vpaste.net/A2MmU Still at same spot. [Wed Dec 4 13:52:13 2013] What can i prove to help myself? [Wed Dec 4 13:52:14 2013] aico4: are you doing software foundation exercises? [Wed Dec 4 13:52:19 2013] notdan: Yep. [Wed Dec 4 13:52:36 2013] Have you proved the rev_snoc theorem? [Wed Dec 4 13:52:41 2013] rev (snoc l n) = cons n (rev l). [Wed Dec 4 13:53:38 2013] notdan: Nope, thanks for hint, i'll try to prove it now. [Wed Dec 4 14:11:50 2013] Yay, proved rev_involutive! [Wed Dec 4 14:12:01 2013] notdan: Thank you for hint. [Wed Dec 4 14:12:31 2013] notdan: How did you came up with idea that you need exact that rewrite? [Wed Dec 4 14:19:18 2013] I mean, i'm interested in your thought flow on that theorem. I'm really new to theorem proving of any sort so maybe i'm just thinking in a wrong way... [Wed Dec 4 14:30:32 2013] WOW, i proved distr_rev by my self! [Wed Dec 4 14:30:43 2013] Feels good. [Wed Dec 4 14:47:33 2013] "Write down a non-trivial theorem involving [cons] ([::]), [snoc], and [app] ([++])." [Wed Dec 4 14:47:38 2013] Can you suggest one? [Wed Dec 4 14:50:36 2013] aico4: the correctness of some sorting algorith? Stuff about permutations? [Wed Dec 4 14:55:00 2013] robbert`: Nah, it's too hard, i haven't even seen any sorting algo or permuations in coq. [Wed Dec 4 14:56:55 2013] a ++ b :: c = (snoc a b) ++ c [Wed Dec 4 14:58:51 2013] Ptival: Both arguments of ++ must be natlists and first argument of snoc must be natlist and second must be nat. [Wed Dec 4 14:59:30 2013] Ah a ++ (b :: c) = (snoc a b) ++ c [Wed Dec 4 14:59:37 2013] yes [Wed Dec 4 15:01:16 2013] a++ (cons b c) = (snoc a b) ++ c [Wed Dec 4 15:01:25 2013] Ptival: Cool, i'll try to prove it. [Wed Dec 4 15:01:56 2013] Anarchos: Same as Ptival's theorem. :) [Wed Dec 4 15:02:14 2013] aico4 yes soory [Wed Dec 4 15:07:22 2013] http://vpaste.net/Bz347 Proved. :) [Wed Dec 4 15:19:47 2013] aico4: I don't remeber! I think that theorem was given in the hint in SF [Wed Dec 4 15:19:57 2013] I just have it in my Lists.v file [Wed Dec 4 15:20:21 2013] aico4 that is one easy of SF [Wed Dec 4 15:29:01 2013] notdan: Wow, i gues they changed Lists.v since then because it's not there now, [Wed Dec 4 15:41:57 2013] aico4: ACL2 has heuristics that can prove rev-rev from scratch. Particularly it proves the rev_snoc theorem automatically. Following "the method" as they call it, you end up in certain proof states where you get stuck. You think, why am I stuck? What doesn't it see? And after some thinking you can come up with such lemmas. [Wed Dec 4 15:57:34 2013] ianjneu: Thank you for sharing. [Thu Dec 5 09:16:20 2013] trying to declare a FSetWeakList [Thu Dec 5 09:17:35 2013] https://privatepaste.com/a4ade5ce98 [Thu Dec 5 09:17:44 2013] ^ not working [Thu Dec 5 09:18:27 2013] what exactly does FSetWeakList.Make expect? [Thu Dec 5 09:18:44 2013] that Module E := X confuses me a bit http://coq.inria.fr/library/Coq.FSets.FSetWeakList.html [Thu Dec 5 09:28:26 2013] roosbeef: I don't know the answer, but if you figure the way to easily handle sets like that please do tell me :) [Thu Dec 5 09:44:26 2013] notdan, found a working example here http://robbertkrebbers.nl/research/gammainf/gammainf.v [Thu Dec 5 09:44:47 2013] modified Var_as_UDT to suit my purpose [Thu Dec 5 09:44:49 2013] seems to work [Thu Dec 5 12:14:56 2013] Hello. [Thu Dec 5 12:16:23 2013] I'm trying to prove http://vpaste.net/9Oe1a, am i on right track? [Thu Dec 5 12:16:31 2013] Just a bit stuck, hints appreciated. [Thu Dec 5 12:19:01 2013] aico4: try backing out of that last 'simpl' [Thu Dec 5 12:22:22 2013] ystael: It gives me " ble_nat (count 0 (remove_one 0 (S n :: s))) (count 0 (S n :: s)) = true" under ======= line. [Thu Dec 5 12:23:41 2013] oh [Thu Dec 5 12:23:51 2013] so, the problem is that you used `induction n` [Thu Dec 5 12:24:05 2013] this isn't actually an induction on n; the only thing you care about is whether n is zeor [Thu Dec 5 12:24:31 2013] there's a different tactic you can use there that will give you better rewrites [Thu Dec 5 12:25:54 2013] ystael: I wonder which one? All tactics i know so far are: destruct/induction, simpl, rewrite, compute, intros, replace, assert. [Thu Dec 5 12:26:35 2013] what do you use to discriminate - only to discriminate - between "n = zero" and "n = S n'" [Thu Dec 5 12:27:50 2013] ystael: Right, and it corners me after i prove "n = zero" case. [Thu Dec 5 12:28:46 2013] Try simpl before destruct n rather than after [Thu Dec 5 12:31:00 2013] http://vpaste.net/9Fot5 [Thu Dec 5 12:31:43 2013] and what is your inductive hypothesis IHs? [Thu Dec 5 12:31:51 2013] (Look up fold/unfold tactics, they may help you here) [Thu Dec 5 12:32:33 2013] http://vpaste.net/MzNOl [Thu Dec 5 12:33:12 2013] ystael: But i haven't encountered fold/unfold yet in book, does it mean that there should be the way to prove it without fold/unfold? [Thu Dec 5 12:33:26 2013] so, now you need to discriminate on n = 0 or not, try doing that with destruct rather than induction. [Thu Dec 5 12:33:54 2013] that should make the `beq_nat n 0` in those matches fall out. [Thu Dec 5 12:35:12 2013] Just because fold/unfold isn't in the book yet doesn't mean you can't use them to explore :) [Thu Dec 5 12:36:40 2013] " destruct n. simpl. rewrite ble_n_Sn. reflexivity." after last simpl, leaves me with exact same thing in my first paste(without IHn though). [Thu Dec 5 12:37:37 2013] aha [Thu Dec 5 12:38:02 2013] no, nevermind [Thu Dec 5 12:40:29 2013] I'm confused because I have a working proof for this that looks more or less exactly like yours [Thu Dec 5 12:41:23 2013] so I'm confused why yours doesn't work [Thu Dec 5 12:41:33 2013] aico4 uses member. [Thu Dec 5 12:41:48 2013] which is wasteful since you end up traversing the list anyway. [Thu Dec 5 12:42:11 2013] ianjneu: Ah, so i messed up count implementation? [Thu Dec 5 12:42:13 2013] If you write remove_one more directly, the induction hypothesis is exactly the goal. [Thu Dec 5 12:42:15 2013] oh, your definition of remove_one [Thu Dec 5 12:43:39 2013] from scratch: http://vpaste.net/UY1M3 [Thu Dec 5 12:44:20 2013] ianjneu: Thanks! [Thu Dec 5 15:21:49 2013] Hello. [Thu Dec 5 15:22:14 2013] Am I right that plugins bind dynamically to Coq? Is there way to bind them statically? [Thu Dec 5 15:27:36 2013] Rc43: I don't know. Are you having performance problems or something. [Thu Dec 5 15:27:40 2013] ?* [Thu Dec 5 15:28:34 2013] ianjneu, trying to debug that issue with failed test on patch appliance (I asked about test-suite some days ago) [Thu Dec 5 15:28:51 2013] ianjneu, seems that some modules aren't loaded in debugger due to dynamic binding [Thu Dec 5 15:29:13 2013] ianjneu, not sure how debugger works with dynamic libs [Thu Dec 5 15:29:42 2013] ah. [Thu Dec 5 15:35:34 2013] But seems that problem is not in plugins. Dynamic libs should work in debugger the same way as static; and I can't set breakpoint to other functions, too. [Thu Dec 5 18:40:06 2013] uhm, I guess a lot of people here are using Coq with Emacs+Proof General. Stupid question, but how do you indent a line twice? I only seem to be able to indent once using [Thu Dec 5 18:40:16 2013] "mash the space key" [Thu Dec 5 18:40:37 2013] ugh [Thu Dec 5 18:40:57 2013] honestly, you should just use PG's indentation [Thu Dec 5 18:41:37 2013] but it doesn't seem to work well in e.g. proof scripts [Thu Dec 5 18:41:51 2013] "Use more ltac definitions" ;) [Thu Dec 5 18:42:07 2013] I would like to indent cases for example [Thu Dec 5 18:59:45 2013] I indent manually... [Thu Dec 5 19:00:11 2013] because pg's indentation frustrates me so much, and the el script is just too messy to fix :( [Thu Dec 5 19:28:04 2013] yeah, it seems the state of the whole thing is rather messy [Fri Dec 6 00:11:24 2013] What's the preferred method for proving properties about programs that manipulate linked lists right now? [Fri Dec 6 00:11:33 2013] (something as simple as removing an element from a list) [Fri Dec 6 05:26:23 2013] Hello. [Fri Dec 6 06:40:12 2013] Hi [Fri Dec 6 20:04:19 2013] Trying to find the right way to prove a::b <> b for b some list. Surprised how I can't do this. [Fri Dec 6 20:08:41 2013] I can tell you how I'd do it in Agda, if it didn't have the magic knowledge that that's true built into it :) [Fri Dec 6 20:08:48 2013] ianjneu: Try doing it by induction on b [Fri Dec 6 20:09:25 2013] Coq knows that a::[] <> [] (by inversion or congruence or something). [Fri Dec 6 20:10:34 2013] copumpkin: the magic "occurs check" :) [Fri Dec 6 20:10:54 2013] Actually, better way: Show that length a::b = S (length b). [Fri Dec 6 20:10:59 2013] I can do the base case simply, yes. [Fri Dec 6 20:11:14 2013] ah, length. Yes, that should work. [Fri Dec 6 20:11:25 2013] Then prove that x <> S x, and use that fact that a = b -> f a = f b to finish. [Fri Dec 6 20:12:23 2013] mmhmm [Fri Dec 6 20:12:59 2013] Copumkin, Saizan: Does that work in agda without K? I feel like it contradicts HITs, e.g., if you have Zmod2 with O and S and S (S O) = O. [Fri Dec 6 20:13:48 2013] worked. [Fri Dec 6 20:16:24 2013] jgross: it doesn't without K [Fri Dec 6 20:16:37 2013] K is so nice [Fri Dec 6 20:25:12 2013] I have an s-exp ish type that I can't get the right proof of decidable equality for. It's so frustrating. [Fri Dec 6 20:47:20 2013] Saizan: But K breaks HoTT. I want K, but only for my hSets. [Fri Dec 6 20:48:19 2013] ianjneu: Is it defined inductively? Can you just use the "decide equality" tactic on the goal "forall x y : s-exp, {x = y} + {x <> y}" or something? [Fri Dec 6 21:06:12 2013] jgross: doesn't work for the "list of thing I'm trying to decide equality for" case. [Fri Dec 6 23:15:16 2013] i'm trying to learn how to prove things in Coq, and i'm trying to prove a seemingly simple lemma: "exists L : list nat, In 0 L". the econstructor tactic gets me past the exists, but i would like to just tell coq about an example L that satisfies the exists. what tactic lets me do this? (or what else do i do here?) [Fri Dec 6 23:17:07 2013] apply? [Fri Dec 6 23:22:54 2013] uucico: Try exists (cons 0 nil) for the existential. [Fri Dec 6 23:23:41 2013] and then you just have to prove In 0 (cons 0 nil), which is pretty easy. [Fri Dec 6 23:25:24 2013] ah, thanks! the "exists" tactic is what i was looking for. now i will try to figure out how to prove "In 0 (cons 0 nil)". [Fri Dec 6 23:25:39 2013] and "constructor" seems to prove it. cool. [Fri Dec 6 23:25:40 2013] (Hint, do simpl first) [Fri Dec 6 23:25:43 2013] yeah [Fri Dec 6 23:25:52 2013] Or left [Sat Dec 7 15:19:51 2013] Hello. [Sat Dec 7 15:20:48 2013] Got to the MoreCoq chapter. Just wondering, why contradictory things are proven so easily, isn't it wrong? [Sat Dec 7 15:21:10 2013] E.g http://vpaste.net/zi2pi . [Sat Dec 7 15:21:37 2013] Why is it being accpeted by coq? [Sat Dec 7 15:21:37 2013] not wrong at all [Sat Dec 7 15:21:42 2013] It's not wrong [Sat Dec 7 15:21:45 2013] if you assume impossible things, you can do impossible things [Sat Dec 7 15:21:52 2013] if you assume that 1 = 0 you can prove anything [Sat Dec 7 15:21:52 2013] eh [Sat Dec 7 15:22:04 2013] http://en.wikipedia.org/wiki/Principle_of_explosion [Sat Dec 7 15:22:39 2013] Ah, got it. Thanks. [Sat Dec 7 15:22:55 2013] I think the real question is why 1 = 0 is contradictory [Sat Dec 7 15:23:10 2013] Because of the way nats are defined [Sat Dec 7 15:23:33 2013] sgnb: Different contructors. [Sat Dec 7 15:23:56 2013] aico4: ah, I was going to explain that but you already know [Sat Dec 7 15:24:11 2013] (all constructors are injective) [Sat Dec 7 15:24:28 2013] this is different from injectivity of constructors [Sat Dec 7 15:24:52 2013] Different constructors are disjoint. [Sat Dec 7 15:24:53 2013] hm, how so? I am intrigued [Sat Dec 7 15:25:04 2013] different constructors are disjoint [Sat Dec 7 15:25:08 2013] contructors are injective [Sat Dec 7 15:25:21 2013] these are two different properties of constructors in Coq [Sat Dec 7 15:25:51 2013] wait, what does even injectivity mean in the presence of constructors like O : nat [Sat Dec 7 15:25:52 2013] ? [Sat Dec 7 15:26:01 2013] nothing [Sat Dec 7 15:26:06 2013] but S n = S p -> n = p [Sat Dec 7 15:26:29 2013] OK. I see [Sat Dec 7 15:26:30 2013] thanks [Sat Dec 7 15:26:32 2013] one interesting exercise is proving that 1 != 0 "from first principles" [Sat Dec 7 15:30:26 2013] |- = -> right? [Sat Dec 7 15:32:05 2013] Not in coq but in general one can write S n = S p |- n = p, right? [Sat Dec 7 15:35:24 2013] "|-" - entailment. [Sat Dec 7 15:35:33 2013] http://en.wikipedia.org/wiki/Logical_consequence [Sat Dec 7 15:39:02 2013] Yeah.. Kinda. I would say an equivalent of A1,A2,.. |- f in Coq would be 'Axiom A1. Axiom A2. .. . Theorem f ..' [Sat Dec 7 15:39:13 2013] => is more like an internalization of |- [Sat Dec 7 15:50:18 2013] Uh, a bit confused by inversion. http://vpaste.net/fIJWB That subgoal i inculded is a state of proof right before inversion was applied. [Sat Dec 7 15:50:30 2013] How iversion proves that goal? [Sat Dec 7 16:00:52 2013] I mean that proof is perfectly accpeted by coq but i don't see how inversion did proved that last goal... [Sat Dec 7 16:04:04 2013] aico4: your hypothesis H's type reduces to "false = true" [Sat Dec 7 16:05:46 2013] Ptival: Does it mean that induction was a wrong step? [Sat Dec 7 16:06:54 2013] aico4: no not at all [Sat Dec 7 16:10:11 2013] you could have gone with just 'destruct' though, since you won't need the induction hypothesis [Sat Dec 7 16:10:15 2013] Ptival: So proving that theorem though "false = true" was okay? Sorry for silly questions. [Sat Dec 7 16:15:45 2013] aico4: aico4 your proof goes by case analysis on the structure of n [Sat Dec 7 16:16:04 2013] when n is equal to zero, the goal is trivially true [Sat Dec 7 16:17:05 2013] Ptival: But when n is S n' then there is contradiction. [Sat Dec 7 16:18:00 2013] Maybe there is a way to tell coq that that is impossible case and with assumtion "beq_nat 0 n = true" it is impossible to have S n'. [Sat Dec 7 16:18:03 2013] ? [Sat Dec 7 16:20:19 2013] when n is not equal to zero, your hypothesis is a contradiction [Sat Dec 7 16:20:52 2013] so you can invert it to defer the goal [Sat Dec 7 16:23:56 2013] Ptival: Is there tactic for explicitly stating that hypothesis is contradiction and it's impossible case? I tried "contradiction H" but got "Error: Not a contradiction.". [Sat Dec 7 16:27:53 2013] aico4: there's many tactics that would work [Sat Dec 7 16:28:54 2013] Ptival: Which ones for example? [Sat Dec 7 16:31:12 2013] inversion for example [Sat Dec 7 16:31:40 2013] you can also try unfolding beq_nat and simplifying things in H, and only then applying a contradiction tactic [Sat Dec 7 16:32:27 2013] I think... but the inversion tactic is a perfectly fine one [Sat Dec 7 16:35:15 2013] one is named "congruence" [Sat Dec 7 16:42:42 2013] notdan: simpl in H, simplifies hypothesis to false = true. But okay. thank you guys, got it. Just confused that there is no tactic for expressive .... expression of impossible cases like "()" in agda. [Sat Dec 7 16:49:41 2013] aico4: inversion on the unfeasible argument is sort of like () in Agda... [Sat Dec 7 17:03:02 2013] Ptival: Understood, thanks! [Sun Dec 8 02:32:52 2013] Hm agda is weird [Sun Dec 8 02:32:59 2013] I'd think that () is a unit type :S [Mon Dec 9 04:01:30 2013] i'm trying to prove something by considering two cases: whether or not the length of a list is >= n. i naively tried "case_eq (gt (length l) n)", but gt produces a Prop rather than bool, and case_eq doesn't work on non-inductive things. what's the right way of doing this? [Mon Dec 9 04:22:44 2013] ah, it looks like i have to state an excluded_middle axiom, and then destruct (excluded_middle Prop).. [Mon Dec 9 04:48:52 2013] and for nat in particular, it seems like i don't need excluded_middle; i can just destruct (Coq.Arith.Bool_nat.nat_gt_le_bool ...). [Mon Dec 9 06:47:44 2013] hi [Mon Dec 9 06:48:08 2013] how can i refer to a component of an inductive definition inside the definition itself? [Mon Dec 9 06:49:17 2013] eg. https://privatepaste.com/61158e3bfc [Mon Dec 9 06:50:21 2013] x should here be the result of applying a function f to that 'S1.Sig' part [Mon Dec 9 06:59:12 2013] nm :) [Mon Dec 9 10:52:42 2013] when i do "apply some_lemma in H", H changes based on what some_lemma said. i'd like to keep the original H around. how can i duplicate a hypothesis before apply, or get apply to not modify H in-place? [Mon Dec 9 11:00:11 2013] uucico: it's possible to do via assume, but there was some better (shorter/cleaner) way, maybe it was 'remember' [Mon Dec 9 11:01:23 2013] *via 'assert', not 'assume' [Mon Dec 9 11:02:36 2013] ah, indeed, remember does what i want. thanks! [Mon Dec 9 11:03:26 2013] yw [Tue Dec 10 13:10:09 2013] I can't seem to abstract over a substitution in Ltac, e.g. Ltac foo k := apply inv with (arg := k). [Tue Dec 10 13:10:19 2013] What's the right way to do this [Tue Dec 10 13:47:38 2013] ianjneu: That works fine for me: [Tue Dec 10 13:47:38 2013] Axiom inv : forall arg : Type, arg * arg -> arg. [Tue Dec 10 13:47:38 2013] Ltac foo k := apply inv with (arg := k). [Tue Dec 10 13:47:38 2013] Goal nat. [Tue Dec 10 13:47:38 2013] foo nat. [Tue Dec 10 13:47:38 2013] What problem are you having? [Tue Dec 10 14:18:06 2013] jgross: I switched to apply (inv (arg := k) and got the right behavior, oddly. [Tue Dec 10 14:18:14 2013] (inv (arg := k)) * [Tue Dec 10 14:31:35 2013] Hello. [Tue Dec 10 14:38:26 2013] hi [Tue Dec 10 14:51:15 2013] Having hard time proving http://vpaste.net/rdWzK , could you please give me some hints? [Tue Dec 10 15:06:16 2013] prove n + S m = S (n + m) as a lemma. [Tue Dec 10 15:12:16 2013] aico4: I think the use of induction on m. here is not appropriate [Tue Dec 10 15:12:39 2013] Look at the induction hypothesis, you clearly can't get anything useful from it [Tue Dec 10 15:12:41 2013] notdan: true, induction on n suffices. You can just destruct m. [Tue Dec 10 15:13:14 2013] "appropriate" is probably not a right word here, though, but yeah [Tue Dec 10 15:18:19 2013] hm ok now that i actually tried i can't prove it myself :S [Tue Dec 10 15:19:16 2013] oh nvm think I got it [Tue Dec 10 15:20:41 2013] not intros; omega? :P [Tue Dec 10 15:25:08 2013] Ha, no. [Tue Dec 10 15:25:30 2013] I actually never tried using omega. I guess it's ~magic~, like firstorder [Tue Dec 10 15:26:35 2013] aico4: idea: turn H from 'Sn + S n = S m + S m' into 'S (S (n + n)) = S (S (m + m))' [Tue Dec 10 15:28:33 2013] kay, going to hit the sack, bye everyone [Tue Dec 10 15:29:25 2013] by [Tue Dec 10 15:29:26 2013] bye* [Tue Dec 10 15:36:06 2013] Thanks for hints! [Tue Dec 10 15:53:59 2013] ianjneu: I alread have that lemma, but not sure how to apply it. [Tue Dec 10 15:57:29 2013] induction over n with m still quantified; destruct m and you'll get three trivial cases, and finally one that you'll apply that lemma twice in a hypothesis before using it with your induction hypothesis. [Tue Dec 10 17:15:57 2013] mixing coinduction and induction doesn't seem to do what I want. Grumble. [Tue Dec 10 17:26:17 2013] I have a coinductive unrolling a of a list-like structure through a finite map. At the end of the list there is either nil or "look up from the map and keep unrolling." I'm trying to prove that if something is an unrolling, then it is an unrolling of a conservative extension of the finite map. [Wed Dec 11 00:05:51 2013] what's a good way to learn Coq for someone already familiar with tyep theory? [Wed Dec 11 00:07:00 2013] Write a category theory library in Coq? [Wed Dec 11 00:07:17 2013] Do the HoTT exercies in Coq? [Wed Dec 11 00:08:31 2013] You can try going through CPDT (Certified Programs with Dependent Types) by Chlipala, which is a good intro to using tactics, which I think are the biggest stylistic difference between Agda and Coq. [Wed Dec 11 00:10:08 2013] right, i need to learn about tactics and other language specific parts [Wed Dec 11 00:14:43 2013] (I think the other main ones are that Agda uses pattern matching definitions where Coq uses a single "match" construct, in Agda, everyone reimplements their own library, whereas in Coq everyone uses the standard library (because, e.g., if you write your own Nat type, you'd need ML code to get the numeral syntax for it), Agda is more unicode friendly, has mixfix notation (but Coq has notation scopes), Agda has explicit universe levels while Coq [Wed Dec 11 00:14:43 2013] has implicit ones, Agda uses a termination checker where Coq uses simple synatctic positivity checks, Agda uses mutual blocks where Coq uses explicit syntax for recursion (Fixpoint, fix) and mutual recursion (uh, "with" I think? or "and"; I can't remember). In Coq, sections are used more than modules, and modules are rather heavy-weight and impoverished. Coq uses "forall" to mean "pi type" rather than "infer these types". Coq is much better [Wed Dec 11 00:14:43 2013] at guessing which arguments should be implicit than Agda is. Agda is built on K, while Coq is built on J. That's all I can think of right now, though I might list more as I think of them.) [Wed Dec 11 00:15:36 2013] Oh, also, Coq has incremental compilation, always, where-as Agda often needs to recompile the whole file (if you mess up you're holes, for example). [Wed Dec 11 00:17:25 2013] *nod* [Wed Dec 11 00:19:05 2013] And you'll need to get used to working without dependently typed holes, unless you go get the trunk version of Coq, in which case you can use the [refine] tactic to give you something similar to Agda's holes. [Wed Dec 11 00:20:37 2013] oh, you mean when writing terms as opposed to using tactics? [Wed Dec 11 00:22:49 2013] Yes. [Wed Dec 11 00:23:52 2013] I hear [Program] is also a useful way of getting holes in your definitions. (Though, using tactics is also writing terms. They just tend to be very ugly terms. And [refine] is a pretty low-level tactic that lets you be explicit about things.) [Wed Dec 11 00:26:20 2013] i guess if i go through cpdt i'll get some working knowledge [Wed Dec 11 00:33:44 2013] Saizan: If you're interested, you could try porting some of your CT stuff from Agda to https://github.com/HoTT/HoTT/tree/master/theories/categories. Were you recently working on generalized polynomial functors or categories with families, or something of that sort? (Though, going through CPDT will probably give you a better guided tour in tactics and other Coq features.) [Wed Dec 11 00:43:36 2013] jgross: it seems that in most Coq files there's enough unfamiliar stuff that i'd better get a feel for the language first [Wed Dec 11 03:05:13 2013] and I don't think Coq has induction-recursion yet, though that's in the making? [Wed Dec 11 03:32:05 2013] Ptival: do you have a reference for that? [Wed Dec 11 07:45:58 2013] hi [Wed Dec 11 07:46:04 2013] anyone here working with CoLoR? [Wed Dec 11 07:55:53 2013] brb [Wed Dec 11 09:46:50 2013] im trying to define a lexicographic order between terms (which are structured as trees) [Wed Dec 11 09:46:55 2013] using CoLoR [Wed Dec 11 09:47:23 2013] however in order to do this, first it should be clear to coq how the basic elements relate to each other (the labels at the tree nodes) [Wed Dec 11 09:47:40 2013] how do i do this? Im a bit of a novice still when it comes to making sense of libraries [Wed Dec 11 09:48:04 2013] so i think i should be using these two libraries mostly but how do i tell Coq that f > g > h for example [Wed Dec 11 09:48:11 2013] http://color.inria.fr/doc/CoLoR.RPO.VLPO.html [Wed Dec 11 09:48:17 2013] http://color.inria.fr/doc/CoLoR.RPO.VPrecedence.html [Wed Dec 11 09:48:41 2013] i need to establish a VPrecedence relation somehow? (if that even makes sense) [Wed Dec 11 09:51:26 2013] I think you need to provide a precedence with leF : Sig -> Sig -> Prop. and prove it's well founded and a total order [Wed Dec 11 09:56:12 2013] companion_cube, how though :p [Wed Dec 11 09:57:23 2013] well, how are your labels represented? [Wed Dec 11 09:57:28 2013] as strings [Wed Dec 11 09:57:52 2013] but thats like a parameter in Sig [Wed Dec 11 09:57:56 2013] wait ill show you [Wed Dec 11 09:58:29 2013] the usual ordering on strings is total, and probably well-founded if you make shorter strings smaller [Wed Dec 11 09:58:33 2013] http://color.inria.fr/doc/CoLoR.Term.WithArity.ASignature.html#Signature [Wed Dec 11 09:59:15 2013] ok suppose we have strings F and G as the only strings in MySig [Wed Dec 11 09:59:25 2013] then how would i tell Coq that F > G? [Wed Dec 11 09:59:40 2013] leF G F? [Wed Dec 11 10:00:49 2013] if you already have a function Sig -> Sig -> bool, it could be used to build a predicate Sig -> Sig -> Prop? [Wed Dec 11 10:01:02 2013] hm [Wed Dec 11 10:01:03 2013] or just add an axiom, maybe, yes [Wed Dec 11 10:01:16 2013] so you would suggest to write a function Sig -> Sig -> bool [Wed Dec 11 10:01:28 2013] that specifically indicates which labels precede which labels [Wed Dec 11 10:01:29 2013] ? [Wed Dec 11 10:01:38 2013] and then present that function to leF? [Wed Dec 11 10:02:17 2013] beq_symb : symbol -> symbol -> bool <--- don't you already have this in the signature? [Wed Dec 11 10:02:30 2013] yea thats just to provide decidable equality [Wed Dec 11 10:03:14 2013] hmm right, it's not an ordering [Wed Dec 11 10:04:57 2013] then you can directly define a function (with pattern matching for instance) that return True or False to decide whether labels are smaller than other labels [Wed Dec 11 10:05:21 2013] ok that makes sense [Wed Dec 11 10:05:40 2013] suppose we have this function fstring -> fstring -> Prop [Wed Dec 11 10:06:31 2013] then you can apply the VPrecedence functor [Wed Dec 11 10:06:38 2013] how to feed this to Coq and make Coq understand that this order between labels is to be used to determine order between terms with VPrecedence / VLPO and what not [Wed Dec 11 10:06:47 2013] well you also have to prove the properties required in VPrecedenceType [Wed Dec 11 10:07:29 2013] ah [Wed Dec 11 10:07:35 2013] so the function is like the parameter leF [Wed Dec 11 10:09:30 2013] but wait the function is fstring -> fstring -> Prop, not Sig -> Sig -> Prop [Wed Dec 11 10:18:08 2013] roosbeef: you may want to read http://coq.inria.fr/cocorico/ModuleSystemTutorial about functors (to see how leF, Sig and the proofs are provided to VPrecedence) [Wed Dec 11 10:27:37 2013] nice! [Wed Dec 11 10:27:39 2013] will check that out [Wed Dec 11 10:27:53 2013] thanks for your help companion_cube, very much appreciated :) [Wed Dec 11 10:44:52 2013] g'morning [Wed Dec 11 10:50:06 2013] has anyone used Hur et. al.'s paco library for coinduction? [Wed Dec 11 11:29:21 2013] sgnb: http://coq.inria.fr/files/coq5-slides-herbelin.pdf <- page 10 says Matthieu Sozeau is working on IR (or hoping to or planning to) [Wed Dec 11 11:31:30 2013] jgross: the point just above (type-based guard) was already being talked about since before my PhD (I started in 2007)... so don't hold your breath [Thu Dec 12 15:29:48 2013] hi [Thu Dec 12 15:29:56 2013] is the reduction strategy used by coqchk documented anywhere? [Thu Dec 12 15:31:13 2013] I don't know, but I think it's strong reduction [Thu Dec 12 15:31:34 2013] it reduces every redex, even in subterms [Thu Dec 12 15:32:27 2013] thanks. any idea on whether it is cbv or lazy? [Thu Dec 12 15:33:00 2013] well, it's different [Thu Dec 12 15:33:09 2013] since it also reduces under lambda (afaik) [Thu Dec 12 15:33:17 2013] but it would be closer to call by value, I think [Thu Dec 12 15:33:36 2013] since all terms have a normal form, all terms can be reduced to their normal form without worrying [Thu Dec 12 15:34:30 2013] i understand that it will reach a fully normalized term, but the redn strategy to get there will make a difference for some of the proof terms i'm writing (i think) [Thu Dec 12 15:35:27 2013] in what way would that make a difference? [Thu Dec 12 15:36:04 2013] embarrassingly large subterms in proof terms :) [Thu Dec 12 15:36:35 2013] ah, you mean in intermediate steps [Thu Dec 12 15:36:55 2013] not sure what you mean by intermediate steps [Thu Dec 12 15:37:22 2013] well, if those subterms occur in the normal form, every reduction strategy will have to deal with them anyway [Thu Dec 12 15:37:31 2013] there has ben quite a lot of research on reduction machines for CiC [Thu Dec 12 15:38:53 2013] right, i suspect that a lazy strategy would be a good candidate for this particular application, but that seemed too much to hope for [Thu Dec 12 15:39:09 2013] thx, i'll look for the CiC reduction machine research [Thu Dec 12 15:39:34 2013] matita may have a different strategy, btw [Thu Dec 12 15:39:42 2013] i was just wondering about that! [Thu Dec 12 15:40:07 2013] and isn't there a CiC -> lua floating around also? [Thu Dec 12 15:40:22 2013] oh dear, I hope not so [Thu Dec 12 15:48:13 2013] http://www.cri.ensmp.fr/classement/doc/A-525-slides.pdf [Thu Dec 12 15:48:23 2013] section 4.1 http://raweb.inria.fr/rapportsactivite/RA2012/deducteam/deducteam.pdf [Thu Dec 12 15:49:56 2013] so a proof checker for lambda Pi using LuaJIT; not CiC -> Lua [Thu Dec 12 15:51:16 2013] I know the author :) [Thu Dec 12 15:51:41 2013] and the proof checker is moving away from lua actually, toward a matita-like reduction machine in OCaml [Thu Dec 12 15:56:00 2013] are you one of the authors? :) [Thu Dec 12 16:00:58 2013] thanks for the matita suggestion, i see the reduction strategy can be altered there. do you know if the same will apply to dedukti? [Thu Dec 12 16:02:14 2013] I'm not, but I know people who work on it [Thu Dec 12 17:49:00 2013] d t ? [Thu Dec 12 22:22:26 2013] tactics as macros doesn't quite work. I was hoping they were actually untyped, where I could mix tactic and term as output. Is there a nonobvious way to do that? [Thu Dec 12 22:25:42 2013] urgh scoping [Thu Dec 12 23:44:03 2013] ianjneu: I think you want notations, which are in fact untyped. You can also construct ill-typed terms by using (app)context, e.g., "match 1 + 1 = 2 with | appcontext G[plus] => let G' := context G[1] in idtac end". If you get trunk as of a few days ago, you can now use $()$ anywhere that Coq wants a constr, and so you can mix tactic and term. Alteratively, if you don't know about it, you can return terms from tactics by [Thu Dec 12 23:44:03 2013] using constr:(), and possibly continuation passing style. [Fri Dec 13 11:37:21 2013] Should this work: Require Import Setoid. Goal forall (P : Prop), P <-> P. reflexivity. [Fri Dec 13 11:46:22 2013] reflexivity? Hmm, is <-> a declared equivalence instance for prop? [Fri Dec 13 11:47:05 2013] there's a reflexive instance iff_Reflexive, which I can indeed finish the goal with [Fri Dec 13 11:47:20 2013] It works for me. [Fri Dec 13 11:47:38 2013] 8.4pl2 [Fri Dec 13 11:47:58 2013] hmm, that's what mine says also, but I may have built from source [Fri Dec 13 11:48:53 2013] actually, it works with that coqtop, maybe I have something else broken [Fri Dec 13 11:49:43 2013] Weird, seems Proof General somehow got its Coq in a bad state [Fri Dec 13 21:29:42 2013] anyone still awake? [Sat Dec 14 06:29:53 2013] Hello. I've been working through the Software Foundations book and find myself stymied by a question (actually a particular detail of a question). Is this a good place to ask about it? [Sat Dec 14 06:44:37 2013] iainm: yes, i think. at least i did it, got some answers [Sat Dec 14 06:50:06 2013] Oh. No matter. You know the thing where the process of framing the question in sufficient detail leads you to test some assumptions which leads you to the answer? Yes, that. [Sat Dec 14 06:52:50 2013] heh [Mon Dec 16 16:21:18 2013] Is there any way to define a notation with a free variable, for use inside generalizing binders? [Wed Dec 18 07:35:41 2013] im playing around with list to vector conversion [Wed Dec 18 07:37:19 2013] so ive got these functions: [Wed Dec 18 07:37:40 2013] https://privatepaste.com/87bad4e36a [Wed Dec 18 07:38:19 2013] basically i would like to have a function tailor_vec_of_list l n that takes the first n elements of list l and puts them in a vector [Wed Dec 18 07:39:09 2013] i think the code should work, but coq cant see that the length is correct [Wed Dec 18 07:39:12 2013] The term "vec_of_list (tailor_list A l Datatypes.nil i)" has type [Wed Dec 18 07:39:12 2013] "vector A (length (tailor_list A l Datatypes.nil i))" [Wed Dec 18 07:39:12 2013] while it is expected to have type "vector A i". [Wed Dec 18 07:51:56 2013] ok tailor_list was incomplete (didnt expend shorter lists), fixed -> https://privatepaste.com/cd6d7eb112 [Wed Dec 18 07:52:19 2013] coq gives the same message though [Wed Dec 18 07:52:50 2013] how do i convince coq that (length (tailor_list A l Datatypes.nil i)) is actually equal to i [Wed Dec 18 07:54:44 2013] by induction on l and i [Wed Dec 18 07:54:55 2013] induction where? [Wed Dec 18 07:55:01 2013] im not in proof mode when coq is telling me this [Wed Dec 18 07:55:41 2013] (see latter url) it happens when im trying to get the second function to be defined [Wed Dec 18 07:57:04 2013] well, i've never actually used coq, but once you've proven the equality separately, i imagine there's something like transport/subst to fix the types in your code [Wed Dec 18 07:57:29 2013] hm [Wed Dec 18 07:57:46 2013] yea i could prove a lemma that says the length is i [Wed Dec 18 07:58:16 2013] so youre saying coq would automatically use that lemma and not return that message? [Wed Dec 18 07:58:39 2013] no [Wed Dec 18 07:59:10 2013] how would that work then.. [Wed Dec 18 07:59:38 2013] coq wont define the function because it doesnt realise the length is equal to i, but how do i make it realise that? [Wed Dec 18 08:00:27 2013] you would use the equality explicitly, with a combinator, let me see if i can find something suitable in the stdlib [Wed Dec 18 08:02:12 2013] or maybe you should just define tailor_vec_of_list in proof mode and use apply and rewrite? [Wed Dec 18 08:03:01 2013] or use a case on the lemma [Wed Dec 18 08:03:16 2013] define it in proof mode? [Wed Dec 18 08:04:03 2013] yeah, i think it's possible? [Wed Dec 18 08:04:19 2013] i'm sorry, i'm not being very helpful but i'm quite a newbie too [Wed Dec 18 08:04:52 2013] :p [Wed Dec 18 08:21:08 2013] roosbeef: that'd be transport http://lpaste.net/97160 [Wed Dec 18 08:22:06 2013] how does that work? [Wed Dec 18 08:23:47 2013] if you have a proof (p : m = n) and (xs : vector A m) then (transport (vector A) p xs) will have type (vector a n) [Wed Dec 18 08:24:21 2013] ha nice [Wed Dec 18 08:24:57 2013] so proof the lemma, then plug that lemma into transport [Wed Dec 18 08:24:59 2013] prove* [Wed Dec 18 08:25:08 2013] yeah [Wed Dec 18 08:25:11 2013] awesome :) [Wed Dec 18 08:25:17 2013] gonna try that, thanks a lot! [Wed Dec 18 08:25:49 2013] np! [Wed Dec 18 08:27:07 2013] i imagine there are more idiomatic/automated ways, but still [Wed Dec 18 08:49:15 2013] so i have in proof mode that S i = 1 [Wed Dec 18 08:49:29 2013] is there something in the std lib that allows me to convert this into i = 0? [Wed Dec 18 08:50:59 2013] f_equal? http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic159 [Wed Dec 18 08:53:10 2013] thanks :) [Wed Dec 18 16:29:02 2013] how does one make Coq contradact redexes for cofix applications? It's really bugging me. [Wed Dec 18 16:30:19 2013] contract* [Wed Dec 18 18:24:34 2013] ah, Eduardo's email on the list answers this. Basically coinductive is friggin useless. [Wed Dec 18 19:52:05 2013] http://pastebin.com/QhmVFQXn - I'm fairly new to Coq, but trying to work through some of the textbook there; for that exercise, I have an answer that works, but I don't understand why it works [Wed Dec 18 19:53:04 2013] particularly, I don't know why I need 'rewrite <- plus_1_l' rather than ->, and the book just mentions that the former does right-to-left rather than left-to-right rewriting [Wed Dec 18 20:06:38 2013] Hodapp: the right-to-left rewrite changes the m = S n hypothesis to m = 1 + n, so you get m = 1 + n -> m * (1 + n) = m * m afterwards. [Wed Dec 18 20:07:41 2013] then if you do intro H; rewrite H; reflexivity. you'll finish since you will blast away m to have a goal (1 + n) * (1 + n) = (1 + n) * (1 + n). [Wed Dec 18 20:08:07 2013] reflexivity finalizes the proof. [Wed Dec 18 20:08:51 2013] hmm, whereas, if I use the left-to-right, then I get... m * (S n) = m * m, but wouldn't then rewriting with H give (S n) * (S n) on each side? [Wed Dec 18 20:08:54 2013] or what am I missing there? [Wed Dec 18 20:22:31 2013] Hodapp: why have you decided that you *need* to use '<-' there? [Wed Dec 18 20:22:56 2013] ya, either way works. [Wed Dec 18 23:39:06 2013] tuple notation: is there a way so I can write "intros (x,y,z)" instead of "intros ((x,y),z)"? [Thu Dec 19 05:13:50 2013] ianjneu: "coinductive is friggin useless" is both an overstatement and an understatement ;) [Thu Dec 19 05:14:05 2013] On the one hand, it is kind of useful. For example, when summing powerseries, the lazy computation given by coinductive types is pretty useful (and I guess there are tons of other examples). [Thu Dec 19 05:14:25 2013] On the other hand, it is really broken: coinductive types break subject reduction... [Thu Dec 19 08:21:29 2013] defanor, ianjneu: I didn't decide that, Coq did. I get, "Error: Tactic generated a subgoal identical to the original goal." [Thu Dec 19 08:22:20 2013] Hodapp: oh, you might want to add 'intros' [Thu Dec 19 08:22:33 2013] i mean, to intoduce H [Thu Dec 19 08:22:43 2013] before rewriting [Thu Dec 19 08:22:51 2013] I tried it that way too. [Thu Dec 19 08:23:17 2013] well, wait, I wrote down that I had... but actually that works too... [Thu Dec 19 08:23:53 2013] maybe I'll have to look through my Emacs undo buffer and see what I actually did [Thu Dec 19 08:26:48 2013] right [Thu Dec 19 08:26:53 2013] so im working this subgoal [Thu Dec 19 08:26:57 2013] https://privatepaste.com/e76d87cdac [Thu Dec 19 08:27:17 2013] when doing 'compute', the goal resolves to S i = 1, then f_equal resolves to i = 0 [Thu Dec 19 08:27:42 2013] other thing that confuses me a little - if I have, say: Theorem plus_id_exercise : forall n m o : nat, n = m -> m = o -> n + m = m + o. [Thu Dec 19 08:27:42 2013] why does IHi not want to resolve to something similar? [Thu Dec 19 08:28:33 2013] upon doing 'compute in IHi', that assumption resolves to https://privatepaste.com/034b6084f2 [Thu Dec 19 08:28:33 2013] and I do 'intros H H2.' - what is the rule for how H and H2 line up? They appear to magically line up with n=m and m=0 in this case [Thu Dec 19 08:29:34 2013] what do you mean by line up [Thu Dec 19 08:30:38 2013] What defines that H and H2 are hypotheses, and what defines that they are n = m and m = o respectively? [Thu Dec 19 08:31:03 2013] for I use the same syntax with 'intros n m o.' and there it's understood that they're universally quantified variables [Thu Dec 19 08:32:09 2013] H and H2 are simply names for the hypotheses that 'intros' introduces, n=m and m=0 are chosen because these are the first and second premises of that implication you mentioned [Thu Dec 19 08:32:30 2013] i guess with 'intros n m o', maybe coq recognizes that those are already bound and treats them differently [Thu Dec 19 08:32:47 2013] but the names could be anything and hypotheses are just chosen serially? [Thu Dec 19 08:33:17 2013] pretty much, yea. Try doing 'intros' with no name specification [Thu Dec 19 08:35:19 2013] I'm still trying to figure out Proof General a bit better [Thu Dec 19 08:35:29 2013] and how I can interactively enter commands [Thu Dec 19 08:43:01 2013] cool im using coqide [Thu Dec 19 09:17:08 2013] hm [Thu Dec 19 09:17:15 2013] trying to prove this simple theorem [Thu Dec 19 09:17:16 2013] https://privatepaste.com/fc6ff6fd4c [Thu Dec 19 09:17:43 2013] for some reason i keep running in circles [Thu Dec 19 09:18:40 2013] do i do induction on i or l? Or both? Any hints? [Thu Dec 19 09:22:09 2013] * shrugs... first day using Coq was yesterday. [Thu Dec 19 10:10:45 2013] roosbeef needs to generalize his induction hypothesis. [Thu Dec 19 10:11:09 2013] but he's already left in frustration. [Thu Dec 19 10:11:27 2013] I hope this doesn't ruin is day/evening... [Thu Dec 19 10:13:25 2013] I think you just need induction on i and destruction on l... [Thu Dec 19 10:13:58 2013] oh no, you are right [Thu Dec 19 10:14:00 2013] notdan: if you don't leave "il" general in the induction it won't go through. [Thu Dec 19 10:14:25 2013] so the first most obvious thing doesn't work. but the second most obvious thing does :) [Thu Dec 19 10:15:55 2013] 'il'? [Thu Dec 19 10:16:25 2013] I think generalizing over l is necessary, I am trying to crack this right now [Thu Dec 19 10:16:26 2013] that's what he called the argument to the function. then it's called "l" in the lemma. whatever you call it. [Thu Dec 19 10:16:33 2013] but totally forgot how does the generalization work [Thu Dec 19 10:16:51 2013] jrw: oh, sorry, got confused a little bit [Thu Dec 19 10:17:00 2013] notdan: hacky way: move i to the first thing after the forall then start the proof with "induction i" (no intros first) [Thu Dec 19 10:18:04 2013] more generally (hehe), if you've already intros'd something, you can try "generalize dependent l" [Thu Dec 19 10:18:15 2013] which will move l back into the goal as a quantified variable. [Thu Dec 19 10:20:47 2013] yep, 'generalize dependent l' , that's what I been looking for [Thu Dec 19 10:20:48 2013] thanks [Thu Dec 19 10:20:59 2013] for some reason it is no longer in SF :( [Thu Dec 19 10:21:30 2013] oh it's still in there, just in the MoreCoq chapter [Thu Dec 19 11:11:10 2013] Hi. I'm struggling to prove some basic properties for permutations of permutations (for lists of lists). [Thu Dec 19 11:11:30 2013] Can anyone help me with the beginning of the last lemma: http://tny.cz/fe6618a9 ? [Thu Dec 19 11:21:27 2013] fafounet: are you expecting this to follow directly somehow? [Thu Dec 19 11:21:35 2013] my intuition is that it will not. [Thu Dec 19 11:22:14 2013] you'll need to prove something way stronger. on the order of "if doubleperm as bs, then for all a in as and b in bs, Permuation a b" [Thu Dec 19 11:22:44 2013] with the caveat that I haven't actually tried to prove that. or thought very carefully about it. [Thu Dec 19 11:23:45 2013] I guessed I have something stronger to prove but I don't know what. [Thu Dec 19 11:24:21 2013] what you suggest should be adapted to ... there exists b in bs s.t. Permutation a b [Thu Dec 19 11:24:34 2013] i'm not sure it's enough [Thu Dec 19 11:25:22 2013] right, good point. [Thu Dec 19 12:57:29 2013] http://www.cis.upenn.edu/~bcpierce/sf/Basics.html#lab29 - In a line such as "intros n. destruct n as [| n']." what is going on here that tells us how to 'destruct' n? Does a type defined with M different constructors break down into exactly M subgoals? [Thu Dec 19 12:59:55 2013] and does the [| n'] automatically line up serially, with the empty part going to the nullary constructor, and the n' going to the S : nat -> nat? [Thu Dec 19 13:32:44 2013] "oes a type defined with M different constructors break down into exactly M subgoals? [Thu Dec 19 13:32:48 2013] " Yes [Thu Dec 19 13:33:06 2013] and yes for the second part too :) [Thu Dec 19 13:34:17 2013] i don't try to understand how to write as-clauses for inversion, but for destruct they more or less make sense [Thu Dec 19 13:35:17 2013] notdan: alrighty, thank you [Thu Dec 19 13:41:13 2013] http://www.cis.upenn.edu/~bcpierce/sf/Basics.html#lab32 - any hint on how to apply a rewrite from ∀(x : bool), f x = x? I seem to be stuck there [Thu Dec 19 13:41:46 2013] trying to destruct on b, but don't know how to rewrite 'f true' as 'true' (for instance) [Thu Dec 19 13:42:22 2013] if ∀(x : bool), f x = x is in your context as H, you can use 'rewrite (H true)' [Thu Dec 19 13:43:25 2013] But in that particular lemma you don't need to destruct on b really [Thu Dec 19 13:43:34 2013] oh, didn't realize a hypothesis could take parameters like that [Thu Dec 19 13:43:52 2013] ...is it a hypothesis? [Thu Dec 19 13:44:12 2013] if H is of a form (forall a:A. B) than (H a) gives you B [Thu Dec 19 13:44:17 2013] (assuming that a:A) [Thu Dec 19 13:44:27 2013] ooh, okay [Thu Dec 19 13:45:08 2013] that lemma, you can prove with just 'intros f H b. rewrite H. rewrite H.' though [Thu Dec 19 13:45:36 2013] I'll see if I get there on my own with enough headbanging :P [Thu Dec 19 13:48:20 2013] yeah sorry I wont spoil it for you [Thu Dec 19 13:48:31 2013] SF is such a great book [Thu Dec 19 13:48:41 2013] but apparently it got harder since the last time I read it [Thu Dec 19 13:51:23 2013] I'm glad it's a good book, because I had no idea going in [Thu Dec 19 13:51:57 2013] I was reading a paper which mentioned a page of lectures from uoregon in its references, and said lecture page referred to this text [Thu Dec 19 13:54:46 2013] OPLSS? Ya Pierce lectured there a few times [Thu Dec 19 13:55:26 2013] http://www.cs.uoregon.edu/research/summerschool/summer10/curriculum.html - there [Thu Dec 19 13:56:02 2013] 'rewrite H.' - no -> or <- there; what does it mean in the absence of those? [Thu Dec 19 13:56:12 2013] Hodapp: -> is default [Thu Dec 19 13:57:43 2013] okay [Thu Dec 19 13:59:07 2013] also, why is 'H' fine with no argument? [Thu Dec 19 14:00:30 2013] Coq will try to unify the conclusion of H with the goal to find candidates for the arguments of H [Thu Dec 19 14:00:38 2013] you don't have to specify them explicitly [Thu Dec 19 14:02:15 2013] ahh, I see that 'rewrite (H b)' works likewise [Thu Dec 19 14:02:52 2013] yeah, you can specify the argument, or try to let Coq do it [Thu Dec 19 15:28:32 2013] http://www.cis.upenn.edu/~bcpierce/sf/Basics.html#lab33 is posing an embarassing level of difficulty to me... tried destructing 'b', and then in the first subgoal it complains it can't unify 'c' with 'true'. [Thu Dec 19 15:29:57 2013] well, I suppose that's referring to the goal, I'd mistakenly thought it had derived that from the hypothesis [Thu Dec 19 16:38:05 2013] I'm to a stage in that problem where I'm at the subgoal for b=false, and H : false = orb false c, with the subgoal of false = c [Thu Dec 19 16:38:23 2013] if I add a 'rewrite H.' then it's proven, but why? I don't see how rewriting with H can solve anything there [Thu Dec 19 16:38:50 2013] or is it actually replacing 'false' with 'orb false c' which it then evaluates to 'c' thus c=c? [Thu Dec 19 21:47:34 2013] hello [Thu Dec 19 21:48:05 2013] can i ask a question? [Thu Dec 19 22:01:48 2013] hello, farewell [Thu Dec 19 22:10:29 2013] Apparently he can't? :) [Thu Dec 19 22:10:45 2013] Though I guess from another perspective, he did [Thu Dec 19 22:11:00 2013] whoa [Fri Dec 20 01:14:53 2013] which decision procedures for pean arithmetic are available? [Fri Dec 20 01:16:51 2013] (for decidable fragments of course. hesburger arithmetic does not suffice in my case) [Fri Dec 20 01:17:21 2013] *presburger [Fri Dec 20 01:17:24 2013] hesburger. is that the sa [Fri Dec 20 01:17:24 2013] ah [Fri Dec 20 01:17:45 2013] I was going to suggest looking at omega, but obviously not then [Fri Dec 20 01:37:35 2013] anderslundstedt: what's your goal look like? [Fri Dec 20 01:38:37 2013] jrw: one example is context "H : a * (d' + 1) + b' * (d + 1) = a' * (d + 1) + b * (d' + 1)" and goal "0 = (d' + 1) * (b - a - 1 + 1) + (d + 1) * (a' - b' - 1 + 1)" [Fri Dec 20 01:39:31 2013] (I have not double checked that the goal is in fact provable from the assumption, but if I have not done anything wrong in my definitions it should be) [Fri Dec 20 01:42:52 2013] now I have checked: it is provable [Fri Dec 20 01:53:14 2013] anderslundstedt: are those all nats? [Fri Dec 20 01:53:20 2013] yes [Fri Dec 20 01:54:23 2013] I'm not sure I believe that it's true, but if you say so. in any case, I was going to suggest ring, but ring says it can't prove it. [Fri Dec 20 01:56:21 2013] anderslundstedt: no, I'm right. that goal is false in that context. [Fri Dec 20 01:56:33 2013] anderslundstedt: substitute all variables for 0 and you get "0 = 0 -> 0 = 1" [Fri Dec 20 01:56:40 2013] hmmm .... ok [Fri Dec 20 01:58:41 2013] did you take into account that 0 - 0 - 1 + 1 = 1? [Fri Dec 20 01:59:08 2013] or is the associativity the other way around? [Fri Dec 20 01:59:41 2013] I didn't take anything into acount. I copied your goal. destructed all variables and looked that the first case (where they're all 0) and it was false. [Fri Dec 20 01:59:51 2013] ok. [Fri Dec 20 02:02:57 2013] anderslundstedt: I would be curious to know if "ring" solves your goal once you get it right. I haven't worked much with ring; I'm not sure exactly what its limitations are. [Fri Dec 20 02:03:37 2013] I will see if I can find another example where the goal is in fact provable and try ring. [Fri Dec 20 02:03:52 2013] I have tried ring with no success but I have not verified that the goal was provable [Fri Dec 20 02:04:15 2013] anderslundstedt: it's those pesky false theorems that get you :) if only ring could prove all goals... [Fri Dec 20 02:15:09 2013] jrw: it looks like it possible that all theorems where ring has not succeded are wrong. However I will not look more into this at the moment. (I am trying to prove basic rational arithmetic results using the fraction representation (a-b)/(d+1) with a b d : nat, i.e. rationals as setoid with underlying set nat*nat*nat, so that is where my equations come from.) [Fri Dec 20 02:16:45 2013] anderslundstedt: cool, good to know. good luck! [Fri Dec 20 04:19:39 2013] jrw: I now have a provable goal that is not solvable with ring. context "a b d : nat" and "H : a < b", goal "(a * 0 + b * (d + 1)) * 1 + 0 = d * (b - a - 1) + d + (b - a - 1) + 1 + 0 + (a * (d + 1) + 0) * 1". (This is half of the proof of multiplicative inverse for my representation of rationals.) [Fri Dec 20 04:24:17 2013] http://pastebin.com/bR0CXvSQ [Fri Dec 20 04:33:54 2013] anderslundstedt: if it depends on that inequality (presumably), then yes. ring can't handle inequalities. [Fri Dec 20 04:34:09 2013] if you have inequalities but not general multiplication, omega. if you have general multiplication but no inequalities, ring. otherwise... :( [Fri Dec 20 11:26:53 2013] I'm in a subgoal where I've destructed some term, and I've turned a hypothesis to "false = true". What exactly do I do here to signify "the hypothesis is false, this subgoal is irrelevant"? [Fri Dec 20 11:31:30 2013] Hodapp: try "contradiction" [Fri Dec 20 11:31:34 2013] Hodapp: [inversion H] will eliminate the current goal if H is a contradiction [Fri Dec 20 11:34:16 2013] Coq doesn't believe there's a contradiction, but 'inversion H' did it. Thanks. [Fri Dec 20 15:15:19 2013] http://adam.chlipala.net/cpdt/ hmm, this book any good? [Fri Dec 20 15:17:09 2013] Hodapp: it is when you've gotten the basics down. It moves at a fast pace. [Fri Dec 20 15:19:23 2013] I'm surprised at the amount of free, supposedly good-quality material on this. [Sat Dec 21 15:55:39 2013] is there a way to use instantiate with identifiers given to evar rather than the very brittle exact number assigned to that identifier? [Sat Dec 21 16:01:38 2013] ah, Chlipala's equate tactic. [Sat Dec 21 16:03:06 2013] gluh, can't change its value in different cases. [Sat Dec 21 17:30:04 2013] okay, this has bothered me for a while: is there any way to define a tactic during a proof script within the scope of the proof context? [Sat Dec 21 17:30:23 2013] I hate lamba-lifting all my tactics. [Sat Dec 21 17:52:55 2013] ianjneu: lambda-lifting? [Sat Dec 21 17:57:35 2013] jgross: turning free variables that are put in a closure into arguments that then have to be passed in at every call. [Sat Dec 21 18:29:27 2013] jgross: it also appears that "Proof with" is unhygienic. [Sun Dec 22 11:38:52 2013] What does a hyphen before a tactic do? E.g. - intros x y. [Sun Dec 22 12:54:42 2013] unsure. [Sun Dec 22 12:54:59 2013] looks like it focuses on the goal. [Sun Dec 22 13:32:05 2013] ianjneu (from last night): I generally try to structure my tactics so that they pick up variables they need from the context, by type. e.g., replacing [destruct x, y, z.] with [repeat match goal with | [ H : prod _ _ |- _ ] => destruct H end] [Sun Dec 22 13:33:22 2013] ezyang: http://coq.inria.fr/coq-84 "this version features ... a new proof engine by A. Spiwack whose most salient feature is the introduction of bullets (+, -, *) and structured scripts ({ ... })" [Sun Dec 22 13:49:57 2013] jgross: unless I can fully automate a proof in a transparent way, I prefer to introduce informative names. [Sun Dec 22 13:53:05 2013] ianjneu: My goal is to make all of my proofs as fully automated as possible. [Sun Dec 22 14:21:37 2013] jgross: I'm not that good yet. [Sun Dec 22 15:35:04 2013] if I have a hypothesis ((K 0 1) :: l), how do I bind (K 0 1) to a pattern variable in a tactic? The following fails: match goal with [H: (?a :: ?l) |- _] => inversion H end [Sun Dec 22 16:02:36 2013] ianjneu: You get better by practicing. If you always try to make proofs as automated as possible, then you'll get better over time, even if your first proof scripts are ugly. If you only automate proofs when you already know how to fully automate them, it'll take much longer to get better. [Sun Dec 22 16:03:40 2013] ianjneu: ((K 0 1) :: l) isn't a type, so you can't have a hypothesis of that type. Do you mean "match goal with [ H : (?a :: ?l) = _ |- _ ] => inversion H end"? Or maybe "match goal with [ H := ?a :: ?l |- _ ] => idtac a end"? [Sun Dec 22 16:17:39 2013] jgross: right, my attempt to give a contrived example resulted in a type error. [Sun Dec 22 21:38:24 2013] Hrm, am I the only one whose workflow - at least on the problems in SF - usually involves writing a proof that purposely fails and then inspecting the current goals/subgoals? [Sun Dec 22 22:06:59 2013] Hodapp: what do you mean by "fail"? [Sun Dec 22 22:09:40 2013] As in, one that you know is missing pieces and will produce an error. [Sun Dec 22 22:19:32 2013] Hodapp: if you're constructing a proof for the first time, especially if you're not sure the theorem is true, I'd say that's unavoidable [Sun Dec 22 22:19:38 2013] think of it as "exploratory proving" [Sun Dec 22 22:43:53 2013] seems to me to be why Coq has many of the interactive/reflective features it has [Mon Dec 23 12:08:30 2013] hm [Mon Dec 23 12:08:40 2013] so im trying to define this type [Mon Dec 23 12:08:42 2013] Definition fterm_v : Type := VTerm.term S1.VSig. [Mon Dec 23 12:08:42 2013] Definition fterm_v_wf : Type := fterm_v_wf (VTerm.term S1.VSig). [Mon Dec 23 12:08:42 2013] Error: The term "term S1.VSig" has type "Type" while it is expected to have type "fterm_v". [Mon Dec 23 12:09:08 2013] (fterm_v_wf is a function that takes fterm_v as argument) [Mon Dec 23 12:09:38 2013] how do i make coq recognize that fterm_v and "term S1.VSig" are actually one and the same Type [Mon Dec 23 12:17:59 2013] or maybe im just not defining the type properly [Mon Dec 23 12:36:12 2013] found it [Mon Dec 23 19:03:46 2013] God, I always forget the vernacular for "tell me what this notation means" [Mon Dec 23 19:23:15 2013] ezyang: I just Set Printing All. [Mon Dec 23 20:25:50 2013] ezyang: Locate "+". [Tue Dec 24 07:40:49 2013] Can I give a name to "f x" without moving it before the "," here?: http://paste.debian.net/72451/ [Tue Dec 24 07:41:32 2013] (and without also repeating the names of x, y, proof, and without explicitly renaming it from "H") [Tue Dec 24 08:12:39 2013] Igloo: does "intros Hfx" do what you mean? [Tue Dec 24 08:13:11 2013] jrw: That introduces 'x' with the name 'Hfx' [Tue Dec 24 08:13:34 2013] Igloo: okay, how about "intros x y proof Hfx"? :) [Tue Dec 24 08:13:45 2013] "intros ? ? ? Hfx." does do it, but I'd rather not have to write so many ?s [Tue Dec 24 08:13:59 2013] jrw: "without also repeating the names of x, y, proof" :-) [Tue Dec 24 08:14:50 2013] Igloo: you could state the lemma as 'forall (x : nat) (y : nat) (proof : R x y) (Hfx : f x), g y' [Tue Dec 24 08:14:59 2013] and then just intros [Tue Dec 24 08:16:15 2013] I can't remember if I can still use rewrite with the lemma if I do that? [Tue Dec 24 08:16:41 2013] I'd half-remembered that there was a way to name things in that position, but maybe my memory is palying tricks on me [Tue Dec 24 08:17:09 2013] there might be, but I don't know it :) [Tue Dec 24 08:19:50 2013] thanks for the help, anyway :-) [Tue Dec 24 08:51:16 2013] "What does UNBOUND_REL" mean? [Tue Dec 24 10:33:54 2013] ezyang: Technically, it means you found a place where Coq neglected to name something (see https://coq.inria.fr/bugs/show_bug.cgi?id=3073). In practice, I've found that it means that you tried to use a non-dependent theorem where you wanted a dependent one. [Tue Dec 24 10:40:01 2013] I just spent a really long time writing feedback for the Coq survey sent out this morning. The page timed out when I submitted, and I couldn't go back. Awesome. [Tue Dec 24 10:49:06 2013] :DDDDDDDDd [Tue Dec 24 10:55:30 2013] eh? [Wed Dec 25 06:31:50 2013] Hello. [Wed Dec 25 06:38:42 2013] Keyword `return' is necessary only for type casts? [Wed Dec 25 06:39:19 2013] In match? Sort of; usually you need it when you're doing a dependent match [Wed Dec 25 06:40:02 2013] ezyang, ye, in match; found that in implementation of polyvariadic functions. [Wed Dec 25 06:40:32 2013] like nArrow n = match n with O => nat | S n => nat -> nArrow n, etc. [Wed Dec 25 06:40:56 2013] Then in usage it is written nSum = match n return nArrow n with ... [Wed Dec 25 06:41:13 2013] Yeah, I stand by my answer [Wed Dec 25 06:41:57 2013] ezyang, why Coq can't deduce type without this? [Wed Dec 25 06:42:12 2013] Because it is undecidable [Wed Dec 25 06:42:22 2013] that being said, Coq has gotten pretty good at guessing in many cases. [Wed Dec 25 06:43:28 2013] ezyang, yeah; I checked now without "return" -- in my case it works. [Wed Dec 25 06:45:45 2013] Here is a good resource about what 'return' means: http://adam.chlipala.net/cpdt/html/MoreDep.htmlhttp://adam.chlipala.net/cpdt/html/MoreDep.html [Wed Dec 25 06:45:49 2013] oops, that's http://adam.chlipala.net/cpdt/html/MoreDep.html [Wed Dec 25 06:47:58 2013] ezyang, thanks, will check it [Wed Dec 25 07:10:43 2013] If "dependent destruction H" works, but "dependent inversion H" says "Error: Current goal does not depend on H", is there anything I can do to make "depent inversion" work? [Wed Dec 25 07:11:01 2013] (I want to add an "as ..." clause, which dependent destruction doesn't allow) [Wed Dec 25 09:43:58 2013] It seems pretty unfortunate that when you have a context, Coq gives it a name, even though the preferred mechanism by which is should be used is by the name of the method in the typeclass [Wed Dec 25 23:23:46 2013] could somebody recommend some books/articles/examples about implementing/proving network protocols in coq? i want to try it, but have no idea where to start [Wed Dec 25 23:51:44 2013] defanor-: have you read the frenetic work? [Wed Dec 25 23:53:21 2013] http://www.frenetic-lang.org/publications.php [Wed Dec 25 23:53:49 2013] jrw: nope, thanks, will check it [Wed Dec 25 23:54:48 2013] specifically the PLDI 2013 paper is the coq proofs. [Wed Dec 25 23:55:46 2013] defanor-: this might not be exactly what you mean, depending on your definitions of "network protocol" and "implementing"... [Wed Dec 25 23:56:59 2013] they verify a compiler from a software-defined networking language to open flow table rules. to do that they model open flow semantics as well as the network. [Wed Dec 25 23:57:02 2013] it's a good paper. [Thu Dec 26 00:00:26 2013] defanor-: I'd also be curious to hear more about what you're interested in doing, if it's not top secret :) [Thu Dec 26 00:00:26 2013] jrw: even if it's not exactly what i want, it seems interesting and could be helpful. thanks [Thu Dec 26 00:01:10 2013] np [Thu Dec 26 00:01:43 2013] just some protocols, on top of tcp and csd, like rpc [Thu Dec 26 00:02:54 2013] and you want to verify that, given some assumptions about tcp, the rpc satisfies certain properties? [Thu Dec 26 00:02:59 2013] i have a bunch of protocols to work with here, so it'd be nice to prove at least that any composed message could be read [Thu Dec 26 00:03:43 2013] and when i have server implementation also, then i'd like to prove that, say, it does not allow parameters which don't pass validation [Thu Dec 26 00:04:31 2013] and there are some a little more complex schemas for recovery on disconnect, it'd be nice also to prove that they work [Thu Dec 26 00:25:26 2013] defanor-: cool. keep me posted! [Thu Dec 26 05:20:37 2013] hello [Thu Dec 26 05:20:47 2013] I'm beginner in coq [Thu Dec 26 05:21:16 2013] Can you explain, how to write factorial function for Z, not using nat [Thu Dec 26 05:30:41 2013] nones: there are several ways, the easiest of which is to use nat. why don't you want to do it that way? [Thu Dec 26 05:31:55 2013] I want to better understand how to work with Z and positive [Thu Dec 26 07:43:22 2013] why this code not good? https://codeo.me/3qi [Thu Dec 26 07:44:04 2013] Not obviously terminating [Thu Dec 26 07:44:38 2013] when it will not terminated? [Thu Dec 26 07:45:18 2013] As it turns out, it will in fact terminate. But Coq needs help to figure that out. [Thu Dec 26 07:45:57 2013] how to hint coq it? [Thu Dec 26 07:47:22 2013] I am not super familiar with how Z is represented, but if you can arrange for the code to be doing structural induction on your structure of Z, you will be good. [Thu Dec 26 07:47:33 2013] Otherwise, you will need to give Coq a well-foundedness argument [Thu Dec 26 11:06:41 2013] hi [Thu Dec 26 11:06:50 2013] anyone up for a brain wrecker? [Thu Dec 26 11:07:13 2013] on this chilled out christmas day :p [Thu Dec 26 11:09:32 2013] alright so im getting this error when trying to define a function https://privatepaste.com/8e6688c332 [Thu Dec 26 11:10:10 2013] this function https://privatepaste.com/e80d3449d9 [Thu Dec 26 11:11:07 2013] so basically, coq is saying "hey wait, in that data type theres a ratio between the length of args and the length of h" [Thu Dec 26 11:11:38 2013] in the assumptions however, theres "ftv : wf_fterm_v x" (ftv is the variable matched) [Thu Dec 26 11:11:54 2013] which states precisely that the ratio between h and args is in order [Thu Dec 26 11:12:51 2013] how do i relay that information properly though? There is no interaction with the user like in proof mode when defining a function is there? [Thu Dec 26 11:15:33 2013] roosbeef: I have a gut feeling that your problem may be a few steps further back [Thu Dec 26 11:16:00 2013] It seems strange to write a pattern match expecting the value of ftv to be True [Thu Dec 26 11:16:15 2013] Here True is the type True : Prop that has a single constructor tt : True, correct? [Thu Dec 26 11:17:10 2013] yep [Thu Dec 26 11:18:10 2013] is there a better way to plug in this fact? The function needs that to be sound [Thu Dec 26 11:19:31 2013] What is the definition of the type wf_fterm_v ? [Thu Dec 26 11:21:16 2013] https://privatepaste.com/39064b0569 [Thu Dec 26 11:25:42 2013] I would probably try to define fterm_v_is_wf as an inductive type of propositions rather than a function generating a proposition [Thu Dec 26 11:26:03 2013] That way you can pattern match on its structure more easily [Thu Dec 26 11:27:36 2013] You can enforce the length constraint on the argument list by using dependently typed vectors [Thu Dec 26 11:28:08 2013] and so, some dependently typed vnil as well? [Thu Dec 26 11:32:43 2013] This is just a sketch: https://privatepaste.com/0d5604bcf4 [Thu Dec 26 11:32:49 2013] let me see [Thu Dec 26 11:33:03 2013] It may be nonsense in whole or in part [Thu Dec 26 11:34:22 2013] The thing in the comment should be a dependent pair (arg, inhabitant of fterm_v_is_wf arg) [Thu Dec 26 11:35:50 2013] so args becomes a list of dependent pairs? [Thu Dec 26 11:36:00 2013] what does Vec do? [Thu Dec 26 11:37:34 2013] not sure what you call it, it's the standard length-dependent vector type [Thu Dec 26 11:38:04 2013] (Vec n A is the type of vectors of type A and length n; I may have the arguments in the wrong order or the name wrong) [Thu Dec 26 11:38:12 2013] ok [Thu Dec 26 11:39:31 2013] hm [Thu Dec 26 11:39:58 2013] i can see how use of this other definition of fterm_v_is_wf can be more elegant [Thu Dec 26 11:40:12 2013] In a way what this does is it encodes the well-formedness constraint directly into the term type, instead of using auxiliary proofs [Thu Dec 26 11:40:24 2013] but even then, coq would complain when constructing the resulting fterm_a [Thu Dec 26 11:40:59 2013] or would it automatically detect the ratio being adhered to somehow? [Thu Dec 26 11:41:40 2013] No, that's the hard thing about constructing dependently typed functions [Thu Dec 26 11:41:55 2013] :< [Thu Dec 26 11:41:56 2013] You have to figure out how to introduce all the relevant facts into the type checker so it can match everything up [Thu Dec 26 11:42:15 2013] how does one introduce a fact though? [Thu Dec 26 11:44:19 2013] would this help? https://privatepaste.com/a7d8c707a0 [Thu Dec 26 11:44:26 2013] Generally speaking you need to have some structure on the types of the things you're putting in [Thu Dec 26 11:44:52 2013] well the structure is there but its based on the structure of where these things are coming from [Thu Dec 26 11:45:28 2013] basically im trying to construct a tree with ratio enforced from a tree with no ratio enforced BUT with the ratio in place anyway (the proof of this being available) [Thu Dec 26 11:45:39 2013] transport might be made to help, yes [Thu Dec 26 11:45:58 2013] The problem is that the type of (fterm_v_is_wf x) is Prop [Thu Dec 26 11:46:19 2013] Not the *sort* of its type, but its *type* [Thu Dec 26 11:46:47 2013] That isn't what you want [Thu Dec 26 11:47:00 2013] If you want fterm_v_is_wf x to be a proof that x is well formed, it should inhabit a type of sort Prop [Thu Dec 26 11:47:53 2013] what do you mean by 'inhabit', or 'sort of its type'? [Thu Dec 26 11:48:00 2013] im slightly confused :p [Thu Dec 26 11:48:14 2013] that's because I'm talking nonsense, ignore the last few lines [Thu Dec 26 11:48:18 2013] sorry [Thu Dec 26 11:48:49 2013] haha [Thu Dec 26 11:48:51 2013] :P [Thu Dec 26 11:50:29 2013] I am still confused by what looks like a mismatch between the definition of fterm_v_is_wf x and its use in a pattern match [Thu Dec 26 11:50:48 2013] sorry, wf_fterm_v x [Thu Dec 26 11:51:05 2013] fterm_v_is_wf consumes a term and yields a type of sort Prop [Thu Dec 26 11:51:16 2013] if the term is a Var, that type is True [Thu Dec 26 11:51:26 2013] if the term is a Fun, that type is something /\ somethingelse [Thu Dec 26 11:51:51 2013] Then in aterm_of_vterm, you start by trying to pattern match on ftv which has type wf_fterm_v x [Thu Dec 26 11:52:04 2013] But you do not even know the structure of the type of ftv [Thu Dec 26 11:52:41 2013] If x is a Var, then ftv has type True, and the pattern match should have a single case tt [Thu Dec 26 11:52:56 2013] If x is a Fun, then ftv has type a /\ b, and the pattern match should have a single case, but that case is different [Thu Dec 26 11:53:26 2013] So I don't see how you can hope to write a match like that [Thu Dec 26 11:53:53 2013] You should maybe match on x first, and destructure the proof ftv inside each case [Thu Dec 26 11:54:48 2013] the library is closing, have to get out of here, be back in about 5 mins <3 [Thu Dec 26 12:06:24 2013] hm [Thu Dec 26 12:07:15 2013] but its fed both x and ftv right [Thu Dec 26 12:07:24 2013] ftv is a property of x [Thu Dec 26 12:08:16 2013] ahh wait [Thu Dec 26 12:08:23 2013] i see your point now :p [Thu Dec 26 12:08:29 2013] let me go ahead and try that [Thu Dec 26 12:08:31 2013] :) [Thu Dec 26 12:09:07 2013] how would ftv match with False though [Thu Dec 26 12:10:03 2013] A pattern match against the type False has no cases [Thu Dec 26 12:10:20 2013] but if you have a term of type wf_fterm_v x, then you know that wf_fterm_v x is not the type False [Thu Dec 26 12:10:37 2013] because False has no inhabitants [Thu Dec 26 12:10:47 2013] Don't confuse truth of a proposition with inhabiting the type True [Thu Dec 26 12:12:38 2013] Terms of a conjunction type A /\ B have the form conj a b, where a : A and b : B [Thu Dec 26 12:13:07 2013] what does it mean for a proposition to 'inhabit' the type True? [Thu Dec 26 12:13:16 2013] sorry, 'inhabit' is just a word for 'have the type' [Thu Dec 26 12:13:22 2013] right [Thu Dec 26 12:13:30 2013] so its an expression of True [Thu Dec 26 12:13:40 2013] it's a proof term of the proposition True [Thu Dec 26 12:13:51 2013] yea [Thu Dec 26 12:14:02 2013] The proposition (type) True has _exactly_one_ proof term (inhabitant) [Thu Dec 26 12:14:06 2013] that term is tt [Thu Dec 26 12:14:22 2013] True /\ True is a true proposition, but its proof term is not tt [Thu Dec 26 12:14:24 2013] it is conj tt tt [Thu Dec 26 12:15:15 2013] but if youre pattern matching a proposition, you normally go by each possible case right? [Thu Dec 26 12:15:44 2013] With the way you have set things up, you need to know the structure of x in order to know the structure of the type wf_fterm_v x, so that you can know what the cases are [Thu Dec 26 12:16:08 2013] Like I said before - if x is a Var, wf_fterm_v x is the type True, and the pattern match has a single case, | tt => ... [Thu Dec 26 12:16:11 2013] x can be VTerm.Var or VTerm.Fun [Thu Dec 26 12:16:27 2013] If x is a Fun, then wf_fterm_v x is _not_ the type True, it is a type whose constructor is /\ [Thu Dec 26 12:16:40 2013] ah right its true by the previous case match [Thu Dec 26 12:17:05 2013] so in this case the match on ftv (of type wf_fterm_v x = something /\ somethingelse) has a single case, | conj proof-of-something proof-of-somethingelse => ... [Thu Dec 26 12:17:31 2013] Without knowing the *structure* of the type wf_fterm_v x, you cannot pattern match on proofs inhabiting that type [Thu Dec 26 12:18:11 2013] This is why I suggested making wf_fterm_v x a dependent inductive type instead of the result of a fixpoint function -- that way you get the structure transparently [Thu Dec 26 12:18:26 2013] ok im going to try that [Thu Dec 26 12:18:47 2013] but that thing about dependent pairs was weird to me to be honest [Thu Dec 26 12:18:53 2013] what did you mean by that [Thu Dec 26 12:19:39 2013] You need to have a proof term that each argument is well formed, for the recursive descent, right? [Thu Dec 26 12:21:15 2013] So for each argument arg, you need a proof term of type wf_fterm_v arg [Thu Dec 26 12:21:55 2013] so what you really have is a vector of arguments and proofs that they are well formed, which is a vector of pairs (arg, proof term of type wf_fterm_v arg) [Thu Dec 26 12:22:44 2013] This is a dependent pair because the type of the second thing depends on the first [Thu Dec 26 12:22:52 2013] what would those proofs look like then? The inductive type itself is meant to serve as proof of that, right? [Thu Dec 26 12:23:49 2013] yes, exactly [Thu Dec 26 12:24:27 2013] then why have them be pairs [Thu Dec 26 12:25:04 2013] Because you can't name "the type of proofs that is well formed" without saying what is [Thu Dec 26 12:25:30 2013] hm [Thu Dec 26 12:25:56 2013] so by 'pair' do you mean 'application' of the inductive type to some value? [Thu Dec 26 12:26:27 2013] I think you'd spell the type of the pair as sig fterm_v wf_fterm_v [Thu Dec 26 12:26:31 2013] see Coq.Init.Specif [Thu Dec 26 12:27:08 2013] not wf_fterm_v (sig fterm_v)? [Thu Dec 26 12:27:25 2013] what does sig do here [Thu Dec 26 12:27:30 2013] aaaargh ;p [Thu Dec 26 12:27:32 2013] * eats screen [Thu Dec 26 12:27:56 2013] sig is just the type constructor for dependent pairs [Thu Dec 26 12:28:03 2013] ah ok [Thu Dec 26 12:28:06 2013] was hoping that :p [Thu Dec 26 12:28:35 2013] sig A P is the constructor for a type of pairs consisting of a term (a : A) and a proof term of the proposition (P a) [Thu Dec 26 12:29:07 2013] a term of type sig A P has the form exist (a : A) (pf: P a) [Thu Dec 26 12:29:38 2013] so its specifically meant to build pairs of term a and proof of a Pa? [Thu Dec 26 12:29:45 2013] yes [Thu Dec 26 12:29:48 2013] nice [Thu Dec 26 12:29:55 2013] ok i can see how that would work [Thu Dec 26 12:30:03 2013] if P is a more general thing (yields Types rather than Props) there is sigT instead [Thu Dec 26 12:30:09 2013] but you have Props here [Thu Dec 26 12:31:35 2013] do you think coq would be able to infer from this pattern match on a more elaborate structure that the ratio required for the resulting type is adhered to? [Thu Dec 26 12:32:43 2013] I don't know enough about your problem domain to answer that with confidence [Thu Dec 26 12:32:57 2013] only one way to find out i guess :) [Thu Dec 26 12:33:31 2013] In my (relatively limited) experience getting dependently typed pattern matches to typecheck is always challenging [Thu Dec 26 12:34:03 2013] but whatever you can do to expose things directly to pattern matching rather than putting them behind opaque functions or equality proofs helps [Thu Dec 26 12:34:12 2013] cool im gonna give it a shot [Thu Dec 26 12:34:20 2013] thanks a lot! [Thu Dec 26 12:34:33 2013] you have made it a lot more clear :) [Thu Dec 26 12:34:50 2013] or at least it doesnt seem as cloudy and obscure anymore to me [Thu Dec 26 12:35:13 2013] you're welcome, good luck :) [Thu Dec 26 14:10:40 2013] anyone around? Module question. [Thu Dec 26 14:12:12 2013] Hehe... Ask! :) [Thu Dec 26 14:13:29 2013] I separated a moderately sized development into modules, and now things don't typecheck due to loss of definitional equalities. [Thu Dec 26 14:13:36 2013] Not sure how to expose them. [Thu Dec 26 14:15:22 2013] For instance, I have a type CESK that is defined as an instantiation of another type. CESK := Shell CES_point. The reduction relation is CESK -> CESK -> Prop. When I use the relation outside the module, it says the relation has type CESK -> CESK -> Prop instead of Shell CES_point -> Shell CES_point -> Prop. [Thu Dec 26 14:17:07 2013] The shell is also defined within the module that provides the reduction relation. [Thu Dec 26 14:23:40 2013] also, I have two functors that share the same instantiation of a third module. How do I expose that they are the same? Do they have to become a parameter to said functors? [Thu Dec 26 14:24:14 2013] That instantiation is dependent on the previous arguments to the functior :/ [Thu Dec 26 14:39:47 2013] Thought not. [Thu Dec 26 14:40:59 2013] The FAQ for modules is empty. Awesome. [Thu Dec 26 15:02:37 2013] * is very frustrated. [Fri Dec 27 00:15:55 2013] wow, proving commutativity of multiplication in the exercise in SF is throwing me for a loop... [Fri Dec 27 02:11:45 2013] Hodapp: where are you stuck/what have you tried? [Fri Dec 27 05:19:22 2013] Is there something like 'Section', except I can control the visibility of identifiers defined in it? [Fri Dec 27 10:23:24 2013] jrw: I was trying induction on 'm', getting then m' * n = n * m' -> S m' * n = n * S m', but keep running into cases where the S (whatever) is on the right operand and I can't turn it to anything I seem to be able to simplify [Fri Dec 27 15:28:41 2013] Hodapp: that's right. you have to prove a lemma like: m * (S n) = m + m * n. and to prove that you'll need commutativity and associativity of addition (I think). [Fri Dec 27 15:28:48 2013] and induction on m. [Fri Dec 27 15:31:01 2013] ahh, okay. [Sat Dec 28 16:35:29 2013] Why isn't this ltac matching the hypothesis (as commented on line 68)? http://paste.debian.net/72899/ [Sat Dec 28 16:47:43 2013] Ah, because I meant to have a "_ : " prefix to the pattern, I think [Sat Dec 28 16:49:50 2013] Hmm, but it then isn't accepted with the assert uncommented [Sat Dec 28 19:07:49 2013] Aha, "match type of hyp" rather than "match hyp" seems to be what I was looking for [Sun Dec 29 23:26:38 2013] newb question: Is there an equivalent to agda's "()" syntax for absurd patterns in coq? For instance, if I have an Even property for nat, how could I make a div2 function which takes an "Even n" object so I don't have to define it for odd values? [Sun Dec 29 23:44:34 2013] hjfreyer: How you'll define it depends on what Even n consists of. [Sun Dec 29 23:47:04 2013] let's say its something like Inductive Even : nat -> Prop := [Sun Dec 29 23:47:13 2013] | O_even : Even O [Sun Dec 29 23:47:42 2013] | plus_2_even : forall n, Even n -> Even (S (S n)) [Sun Dec 29 23:47:52 2013] (forgive my perhaps wrong syntax, still learning) [Sun Dec 29 23:48:53 2013] Well, you'll likely write something like: [Sun Dec 29 23:48:56 2013] In agda you just pattern match on Even n, and the case of Even 1 is obviously empty to the unifier [Sun Dec 29 23:49:06 2013] Fixpoint div2 (n : nat) (p : Even n) : nat := [Sun Dec 29 23:49:10 2013] match p with [Sun Dec 29 23:49:18 2013] | O_even => O [Sun Dec 29 23:49:34 2013] | plus_2_even k p => S (div2 k p) [Sun Dec 29 23:49:38 2013] end. [Sun Dec 29 23:50:22 2013] Cale: if Even n is in Prop can you match on it? [Sun Dec 29 23:50:35 2013] Oh, Prop... [Sun Dec 29 23:50:50 2013] Yeah, I guess that won't work then. [Sun Dec 29 23:50:57 2013] I don't tend to use Prop myself much [Sun Dec 29 23:51:01 2013] well, here's a more complex example: [Sun Dec 29 23:51:10 2013] you take two lists and a proof that they have the same length [Sun Dec 29 23:51:14 2013] But okay... [Sun Dec 29 23:51:25 2013] and you don't want to have to address the case where one is [] and the other is cons [Sun Dec 29 23:52:17 2013] Is that the kind of thing you'd do in coq, or am I just thinking wrongly? [Sun Dec 29 23:52:26 2013] I think you just leave out the cases you don't need? [Sun Dec 29 23:53:51 2013] I could be wrong [Sun Dec 29 23:55:48 2013] nope, it says non-exhaustive pattern match [Sun Dec 29 23:58:54 2013] okay, hmm [Mon Dec 30 00:00:09 2013] Well, Prop is weird, and Agda has no analogue to it. [Mon Dec 30 00:00:56 2013] But it would be good to know if we can use a Prop to define a function like this. [Mon Dec 30 00:01:05 2013] (Rather than just other Props) [Mon Dec 30 00:01:08 2013] yeah, but even if I make it a Type or whatever, that still won't address the two vectors case [Mon Dec 30 00:01:24 2013] It will, you'll just do induction on the structure of the proof [Mon Dec 30 00:01:34 2013] (or recursion) [Mon Dec 30 00:02:59 2013] hrm, I don't totally understand how the builtin "=" operator works [Mon Dec 30 00:03:09 2013] and whether one can pattern match on it [Mon Dec 30 00:03:13 2013] oh, right, there's this match ... as ... return ... syntax [Mon Dec 30 00:06:57 2013] No, that doesn't help [Mon Dec 30 00:07:30 2013] Yeah, I don't think you can eliminate a Prop in order to construct something of a type which is a Set [Mon Dec 30 00:08:03 2013] I got this error message while trying: [Mon Dec 30 00:08:09 2013] Incorrect elimination of "p" in the inductive type "Even": [Mon Dec 30 00:08:09 2013] the return type has sort "Set" while it should be "Prop". [Mon Dec 30 00:08:09 2013] Elimination of an inductive object of sort Prop [Mon Dec 30 00:08:09 2013] is not allowed on a predicate in sort Set [Mon Dec 30 00:08:09 2013] because proofs can be eliminated only to build proofs. [Mon Dec 30 00:08:42 2013] That kind of thing is why I just avoid Prop altogether. [Mon Dec 30 00:10:55 2013] I don't know the right way to do this, but the basic idea is to annotate your match correctly (???) and then put underscores on the RHS of the invalid cases, then surround the whole match with a "refine", then you get dropped into proof mode, and you prove False. [Mon Dec 30 00:12:25 2013] aha! [Mon Dec 30 00:12:32 2013] this seems like what I'm looking for [Mon Dec 30 00:14:21 2013] I just don't know what the magic annotations are in this case :( [Mon Dec 30 00:29:06 2013] oh, there's Program [Mon Dec 30 00:29:14 2013] http://coq.inria.fr/distrib/current/refman/Reference-Manual026.html#hevea_default913 [Mon Dec 30 00:54:38 2013] hjfreyer already left, but here's some ugly code that does what he wants... [Mon Dec 30 00:54:40 2013] http://lpaste.net/97722 [Mon Dec 30 01:22:33 2013] Oh, I see [Mon Dec 30 01:25:48 2013] I'm not sure that's the best way to do it. but I have seen similar things done that way by people who know more than me :) [Mon Dec 30 09:37:51 2013] I made an escrowing site for Coq proofs and bitcoins: https://proofmarket.org/ [Mon Dec 30 21:33:03 2013] so proof market is hilariously awesome [Mon Dec 30 21:33:25 2013] im tempted to learn coq now just so i can say officially that im a blackmarket logician [Mon Dec 30 21:36:53 2013] https://proofmarket.org/ in case [Mon Dec 30 21:39:41 2013] no good problems on there as far as I can see :( [Mon Dec 30 21:40:22 2013] jrw: add one! [Mon Dec 30 21:41:31 2013] the problem (ha) with that kind of site is that often the hard part of a coq development comes in just getting the right definitions and statements of theorems. [Tue Dec 31 08:15:42 2013] Hello. [Tue Dec 31 08:15:52 2013] Anybody knows what plugin "funind" for? [Tue Dec 31 08:17:02 2013] I get exception from this plugin while using "relation extraction" plugin so I am interesting what I am doing wrong. [Tue Dec 31 08:17:21 2013] As I understood "funind" is for proof generation or something. [Thu Jan 2 11:10:29 2014] anyone successfully install ssreflect in 8.4pl2? I'm getting an error about GEXTEND [Thu Jan 2 11:10:55 2014] when I change that to EXTEND, there's type error about incompatible token stream types. [Thu Jan 2 11:17:32 2014] I know someone's gotten it to work. There's a library (CoqHensel) with 8.4pl2 and ssreflect 1.4 dependencies. [Thu Jan 2 11:18:09 2014] ianjneu, what do you use Ssreflect for? [Thu Jan 2 11:19:50 2014] Smerdyakov: I'm just trying to learn it. The winter break allows me to yak shave. [Thu Jan 2 11:20:11 2014] * nods. [Thu Jan 2 11:20:25 2014] I'd like to use it in my development of this static analysis correctness proof. [Thu Jan 2 11:21:06 2014] Specifically, the propositions I have in this paper http://arxiv.org/abs/1305.3163 [Thu Jan 2 11:21:44 2014] And you think that's a more practical approach than the one CPDT advocates? [Thu Jan 2 11:24:03 2014] CPDT is impenetrable to me. [Thu Jan 2 11:24:41 2014] :-( [Thu Jan 2 11:26:21 2014] I've read and reread it at least 3 times. [Thu Jan 2 11:27:11 2014] I do use the convoy pattern a lot, but I find myself looking it up every time I decide I need it. [Thu Jan 2 11:27:24 2014] What about the Ltac advice? Impenetrable, too? [Thu Jan 2 11:30:09 2014] I've assimilated some of its advice, but it's very difficult to come up with ltac strategies that will work in more than one place. A lot of the time when I'd like to invert most every hypothesis and use just what I need, Coq says that the goal depends on something-or-other and won't do it. It's very unfriendly to let-binding. [Thu Jan 2 11:30:44 2014] Do you have an example of that sort of scenario? [Thu Jan 2 11:30:51 2014] proof automation makes me nervous... mainly because when something inevitably breaks, i've no idea why [Thu Jan 2 11:30:57 2014] it seems hard to track down the problem [Thu Jan 2 11:31:26 2014] at least the level of automation that CPDT advocates [Thu Jan 2 11:31:36 2014] "Proof. crush. Qed." [Thu Jan 2 11:31:59 2014] nothing small. I have a formalization of a reduction relation that uses let-bindings in its reduction rules. If I invert something and do subst, it says the goal depends on one of the let-bound variables and dies. [Thu Jan 2 11:32:29 2014] ianjneu, well, if it's ever practical to produce an example I could look at, I'd be interested. [Thu Jan 2 11:32:43 2014] crush is a metavariable dynamically bound in multiple places in the book. It's extremely unhelpful and disorienting. [Thu Jan 2 11:32:47 2014] rmk0, CPDT addresses how to debug in that situation. [Thu Jan 2 11:33:11 2014] ianjneu, I don't understand what you mean about a metavariable dynamically bound. [Thu Jan 2 11:34:14 2014] Either my eyes glazed over and missed its definition, or crush is, "an exercise left to the reader" and is meant to have different definitions at different parts of the book. [Thu Jan 2 11:34:24 2014] It's defined in a .v file. [Thu Jan 2 11:34:41 2014] And the details are intentionally not given in the prose, since that would be distracting early on. [Thu Jan 2 11:35:04 2014] If you want to see the particular definition for the book, read CpdtTactics.v. [Thu Jan 2 11:45:27 2014] Smerdyakov: how would you suggest someone with an ACL2 background approach CPDT? [Thu Jan 2 11:46:37 2014] ianjneu, it's designed to be read from front to back, assuming said person has also worked with Haskell or ML a fair bit. [Thu Jan 2 11:47:37 2014] But, of course, reading any book about programming is a small part of the learning process. [Thu Jan 2 11:47:52 2014] Hello. [Thu Jan 2 11:47:57 2014] Probably a first read where lots of things don't make much sense is reasonable, and then you come back to understand parts that seem useful in specific projects [Thu Jan 2 11:48:18 2014] Indeed, it's easy to read and understand each small bit of information, but combining it all within a single framework of understanding is the hard part. [Thu Jan 2 11:48:26 2014] I guess the point of the first read is to form an index of "what might hurt later and where to look to find the cure." [Thu Jan 2 11:49:28 2014] Is there a way in LTac to write conditional patterns? E.g match goal with | [ A : ?X = a, B : ?Y = b ... a <> b ... |- _] => ... ? [Thu Jan 2 11:51:27 2014] Rc43, you can make the equality in the case body and fail if it comes out the wrong way. [Thu Jan 2 11:51:44 2014] Rc43, CPDT has examples like that. [Thu Jan 2 11:51:57 2014] s/equality/equality test [Thu Jan 2 11:52:24 2014] Serdyakov, I am afraid that if I will brute-force all possibly left sides and compare them with tactics then it will very long. [Thu Jan 2 11:52:54 2014] Serdyakov, but if there is no built-in facility, then that is a way [Thu Jan 2 11:52:57 2014] Rc43: let there be an experiment! [Thu Jan 2 11:53:37 2014] Rc43, it's not obvious that the fancier language feature you're proposing could do much better. I don't think Ltac pattern-matching is implemented in a very sophisticated way. [Thu Jan 2 11:53:37 2014] Hmm, how can I test thing for equality? [Thu Jan 2 11:53:47 2014] Rc43, hold on, I'll find the example in CDPT. [Thu Jan 2 11:54:31 2014] Rc43, see [notHyp] here: http://adam.chlipala.net/cpdt/html/Match.html [Thu Jan 2 11:54:55 2014] Rc43, also, I suggest at least reading that whole chapter, if you want to do serious automation in Coq. [Thu Jan 2 11:55:01 2014] Smerdyakov, thanks! [Thu Jan 2 11:58:29 2014] Hmm, is there a way to test arbitrary values for equality? I tried `match (constructor1,constructor2) with | (x,x) => true | _ => false end.', but I can't use variable twice in patterns. [Thu Jan 2 11:59:06 2014] Yes, and the example I pointed to implicitly uses that way. [Thu Jan 2 11:59:38 2014] Match one operand with a pattern that just mentions the other. [Thu Jan 2 12:03:55 2014] Smerdyakov, does it work only in LTac or in Gallina, too? I tried "Definition check (x y : term) := match x with | y => true | _ => false end.", but y matchs with everything. [Thu Jan 2 12:04:02 2014] Only in Ltac. [Thu Jan 2 12:04:09 2014] Ok then. [Thu Jan 2 12:04:13 2014] It would be a serious metatheoretical problem if it worked in Gallina. [Thu Jan 2 12:04:47 2014] Why? [Thu Jan 2 12:04:49 2014] It feels like it would either break parametricity or make evaluation undecidable. [Thu Jan 2 12:05:58 2014] I guess another option would be to allow pattern-matching to "raise an exception" for "I can't figure this out." [Thu Jan 2 12:06:12 2014] Any of the above make the big picture of Coq significantly more complicated! [Thu Jan 2 12:07:17 2014] can you do something like match (x,y) with | (?X,?X) => true | _ => false end ? [Thu Jan 2 12:08:12 2014] That sounds like it should be equivalent. [Thu Jan 2 12:08:18 2014] More code, though! [Thu Jan 2 12:08:40 2014] Steel can't make it work. If I match context with `| [ A : ?X = ?Z, B : ?Y = ?Z |- _ ] => ...', then I cna't match ?Z because it is a metavariable. [Thu Jan 2 12:09:15 2014] Thought about extra-pattern with ..=?Z, ..=?Z but not sure. [Thu Jan 2 12:10:18 2014] You never write the question mark in the body of a match case. [Thu Jan 2 12:11:39 2014] Ah, I succeeded. [Thu Jan 2 12:12:21 2014] Second assumption was correct; just match with one pattern when things are equal and do nothing, next pattern will match when things are non-equal automatically. [Thu Jan 2 15:19:15 2014] I found a strange violation of hygiene in my current proof script. (Simplified) I have H0 : p = (something s), H1 : match (fun c) with something s => le s (extract_s p) end. When I subst p, H1 does not rename s, but instead conflates the two s variables. [Thu Jan 2 15:19:33 2014] subst p and simpl, I should say. [Thu Jan 2 15:25:13 2014] Can you prove false using it? Or can you get a proof of false which only fails at Qed time? [Thu Jan 2 15:26:31 2014] You should probably report it as a bug. [Thu Jan 2 15:37:11 2014] jgross: I can't. I had to further destruct a value in the match expression, which distinguished the two identifiers. It's just weird that they displayed as the same even with Set Printing All. [Thu Jan 2 15:38:33 2014] You should probably still report it as a bug. [Thu Jan 2 15:38:45 2014] Do you have a small example producing the behavior? [Thu Jan 2 15:57:35 2014] jgross: not as yet. [Thu Jan 2 16:03:04 2014] Okay, made one. [Thu Jan 2 16:10:34 2014] and submitted. [Thu Jan 2 17:10:08 2014] i'm trying to prove something like (exist A P x Px = exist B Q y Qy) [Thu Jan 2 17:10:42 2014] i've tried to use f_equal4, but there's a problem since P : A -> Prop [Thu Jan 2 17:10:46 2014] while Q : B -> Prop [Thu Jan 2 17:12:46 2014] i've even tried to use f_equal4_JMeq, as in [Thu Jan 2 17:12:48 2014] http://math.mit.edu/~dspivak/teaching/sp13/submissions/JasonGross/html/FEqualDep.html [Thu Jan 2 17:15:37 2014] but my goal is something like @JMeq C (exist A P x Px) C (exist B Q y Qy) [Thu Jan 2 17:16:21 2014] and f_equal4_JMeq seems to expect that C is of the form (?1 ?2 ?3 ?4 ?5) [Thu Jan 2 17:16:41 2014] (cannot unify) [Thu Jan 2 17:17:53 2014] the-manless-man: are you sure there is always a unique witness? [Thu Jan 2 17:18:58 2014] i think there is, using extensionality [Thu Jan 2 17:19:53 2014] (it's a function space) [Thu Jan 2 17:22:21 2014] are you familiar with HoTT? [Thu Jan 2 17:23:14 2014] actually the dependent issue is not between A/P and B/Q as i said before [Thu Jan 2 17:23:15 2014] rather, it's a space of monotonic functions [Thu Jan 2 17:23:15 2014] x and y are the same function by extensionality [Thu Jan 2 17:23:15 2014] Px and Qy are the proofs that x / y are monotonic [Thu Jan 2 17:23:15 2014] i've read the first couple of chapters [Thu Jan 2 17:24:39 2014] Try filling in the arguments to f_equal4_JMeq by hand. refine (@f_equal4_JMeq _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _). gets rid of the unification error. [Thu Jan 2 17:25:15 2014] coming from a cs background, the topological parts are somewhat obscure [Thu Jan 2 17:26:44 2014] i'll try that, thanks! [Thu Jan 2 17:27:34 2014] Alternatively, try "cut (A = B); [ intro H; destruct H | ]. cut (P = Q); [ intro H; destruct H | ]. cut (x = y); [ intro H; destruct H | ]. cut (Px = Qy); [ intro H; destruct H | ]." to do it by hand. [Thu Jan 2 17:30:02 2014] i see, i had tried "replace x with y" unsuccessfully [Thu Jan 2 17:30:26 2014] (Note that those are all eq, not JMeq. There's probably a way to do it with JMeq, with dependent destruction or something.) [Thu Jan 2 17:30:41 2014] Yes, you need to "replace A with B" before you can "replace x with y" [Thu Jan 2 17:31:23 2014] thanks, both alternatives seem to work [Thu Jan 2 17:33:05 2014] (Or "replace A with B in *"? Or "revert Px Qx P Q x y" and then "replace A with B".) [Fri Jan 3 00:51:13 2014] [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Sun Jan 5 18:46:46 2014] and by branches, I mean including the pattern for each case [Sun Jan 5 19:12:51 2014] "Define a function [normalize] from binary numbers to binary numbers such that for any binary number b, converting to a natural and then back to binary yields [(normalize b)]. Prove it." [Sun Jan 5 19:13:54 2014] I wonder if I was cheating by making 'normalize' a function which converts to a natural and then back to binary, so the proof is true by definition... or if that's the solution he wanted people to find. [Mon Jan 6 00:33:55 2014] Cale, im a bit puzzled as to how refine can be practically applied, the example seems overly trivial [Mon Jan 6 00:35:02 2014] (this is the example from the reference manual https://privatepaste.com/8721679504) [Mon Jan 6 00:36:30 2014] if this is my conversion function (+error) https://privatepaste.com/6462a0ffa6 [Mon Jan 6 00:37:07 2014] then how would i allow myself the opportunity to fix that error by replacing part of the definition by blanks and doing refine later? [Mon Jan 6 00:43:03 2014] roosbeef: Is https://privatepaste.com/ac9c737b14 what you're looking for? [Mon Jan 6 12:03:19 2014] i have this assumption: attempt1 := vec_of_list (map aterm_of_vterm args) : vector fterm_a (length (map aterm_of_vterm args)) [Mon Jan 6 12:03:52 2014] how do i apply the Lemma map_length from std lib? (Lemma map_length : forall l, length (map l) = length l.) [Mon Jan 6 12:04:16 2014] id like to replace "length (map aterm_of_vterm args)" by "length args" [Mon Jan 6 12:05:02 2014] `rewrite map_length` doesn't work? [Mon Jan 6 12:05:27 2014] it does, thank you [Mon Jan 6 12:05:32 2014] weird i thought i had tried that :p [Mon Jan 6 12:45:38 2014] hm [Mon Jan 6 12:46:01 2014] im trying to prove P with the assumption P /\ Q [Mon Jan 6 12:46:11 2014] how do i rewrite the assumption to P? [Mon Jan 6 12:46:51 2014] (my problem is actually https://privatepaste.com/46aaf986a5, but that is the abstracted structure) [Mon Jan 6 12:47:41 2014] roosbeef: inversion on the hypothesis P /\ Q will give you two hypotheses, one for P and one for Q [Mon Jan 6 12:48:07 2014] hm [Mon Jan 6 12:48:15 2014] P /\ Q is embedded though [Mon Jan 6 12:48:24 2014] so inversion H would not work [Mon Jan 6 12:48:48 2014] * actually reads the paste now... [Mon Jan 6 12:49:15 2014] oh, destruct t is what you want [Mon Jan 6 12:49:44 2014] cool thanks :)) [Mon Jan 6 14:04:44 2014] argh, what font do I need to install to see this symbol: http://www.cs.ru.nl/~jherold/math-classes-doc/interfaces.canonical_names.html#::x_%27%E2%9F%B6%27_x [Mon Jan 6 14:30:48 2014] hm how can I actually compile the math-classes? [Mon Jan 6 14:51:33 2014] oh nvm, got it [Mon Jan 6 14:51:45 2014] had to add -R MathClasses to the coq-prog-args [Mon Jan 6 15:15:24 2014] i have a function that converts one data type to another [Mon Jan 6 15:15:51 2014] the conversion from A to B only works given a certain assumption, which is a propery of A [Mon Jan 6 15:16:29 2014] how do i tell Coq that the function applies only to A when it has that property? [Mon Jan 6 15:17:56 2014] I'd say f : (forall a, your_property a -> a -> b) [Mon Jan 6 15:20:24 2014] Fixpoint convert_a_to_b : forall (wf_a x), (x : a) -> b. [Mon Jan 6 15:20:30 2014] like that? [Mon Jan 6 15:21:57 2014] hm.. im trying this "Fixpoint aterm_of_vterm : forall (x : fterm_v), (wf_term_v x) -> fterm_a." but Coq says Error: A fixpoint needs at least one parameter. [Mon Jan 6 15:22:16 2014] ive got the function written out almost completely, just gotta plug that assumption into it somehow :) [Mon Jan 6 15:25:16 2014] Yeah you need a parameter [Mon Jan 6 15:25:45 2014] mayb Fixpoint aterm_of_vterm (x : fterm_v) (_ : wf_term_v x) : fterm_a [Mon Jan 6 15:25:47 2014] something like that [Mon Jan 6 15:27:07 2014] Error: Cannot do a fixpoint on a non inductive type. [Mon Jan 6 15:27:49 2014] wf_term_v x is not inductive, right? [Mon Jan 6 15:27:50 2014] maybe [Mon Jan 6 15:28:04 2014] Fixpoint aterm_of_vterm (x: fterm_v) : wf_term_v x -> fterm_a [Mon Jan 6 15:29:31 2014] https://privatepaste.com/9fcaf10a4d [Mon Jan 6 15:30:21 2014] ok yea that seems to work :) [Mon Jan 6 15:30:25 2014] thank you [Mon Jan 6 15:32:06 2014] yeh because you really want to induct on fterm_v, not on the proof that x is a well formed term :) [Mon Jan 6 15:35:55 2014] robbert: sorry, are you Robbert Krebbers? If that's the case, I was wondering if the math-classes is still active [Mon Jan 6 15:51:20 2014] waaa [Mon Jan 6 15:51:21 2014] ;p [Mon Jan 6 15:51:55 2014] theres a recursive aspect to the function im writing [Mon Jan 6 15:51:56 2014] https://privatepaste.com/6328fce62d [Mon Jan 6 15:52:14 2014] soo now that assumption seems to be in place :) which is good [Mon Jan 6 15:53:39 2014] but i think that in the recursion its not obvious to Coq that the same assumption holds there [Mon Jan 6 15:53:54 2014] (although it does follow from the definition of that assumption that it does) [Mon Jan 6 16:30:40 2014] roosbeef: I'm not sure if you can do this with List.map directly. you'll need a lemma that says that if the (Fun h args) is well formed, then each element of the arument list is also well formed. then you'll need to thread that through (maybe with a custom map-like definition) [Mon Jan 6 16:33:06 2014] hm [Mon Jan 6 16:33:10 2014] yea that would make sense [Mon Jan 6 16:33:50 2014] how would i pipe that lemma in though? [Mon Jan 6 16:35:45 2014] so something like map_if_wf? [Mon Jan 6 17:31:54 2014] roosbeef: it's a little bit complicated. if you post full definitions of everything you have, I may be able to look at it later [Mon Jan 6 23:59:19 2014] in this example, why does coq allow the indirect recursive calls via map? how can I exploit this kind of thing for my own data types? http://lpaste.net/98082 [Tue Jan 7 00:24:27 2014] for example, if I replace map with a functionally equivalent my_map, the definition no longer goes through... [Tue Jan 7 04:05:52 2014] morning [Tue Jan 7 04:12:34 2014] soo [Tue Jan 7 04:12:55 2014] roosbeef: one sec [Tue Jan 7 04:13:10 2014] ok [Tue Jan 7 04:13:46 2014] roosbeef: what is CoLoR, btw? [Tue Jan 7 04:15:10 2014] its a library about term rewriting systems [Tue Jan 7 04:16:01 2014] a term being of the structure Induction term : string -> list term -> term | emptystring : term [Tue Jan 7 04:16:09 2014] (informally speaking) [Tue Jan 7 04:16:30 2014] soo basically my issue at the moment is that [Tue Jan 7 04:16:35 2014] interesting, anyway [Tue Jan 7 04:17:41 2014] if you look at what I have there, I'm not sure it's the right direction to go, but it has a couple ideas for you [Tue Jan 7 04:17:55 2014] cool :) [Tue Jan 7 04:18:00 2014] first is to change the definition of fterm_v_is_wf [Tue Jan 7 04:18:04 2014] to an inductive one [Tue Jan 7 04:18:07 2014] that starts on line 372 [Tue Jan 7 04:18:39 2014] second one is to rework the type of aterm_of_vterm to be a conversion that can fail [Tue Jan 7 04:18:47 2014] so it goes fterm_v -> option fterm_a [Tue Jan 7 04:19:09 2014] then, you prove a lemma like (fterm_v_is_wf x -> aterm_of_vterm x = Some y) [Tue Jan 7 04:19:26 2014] this is kind of a separation of concerns: the code from the proof [Tue Jan 7 04:19:30 2014] ah right, you prove a lemma that it doesnt fail given that fterm_v_is_wf [Tue Jan 7 04:19:46 2014] this is not always the right architecture, but sometimes it can make things clearer [Tue Jan 7 04:20:41 2014] so I tried both of those ideas (together, but actually, you could have tried them separately), but I got stuck at the very end [Tue Jan 7 04:20:58 2014] if you load that file up, you'll see that it gets all the way to the last line, and then chokes on the Defined. [Tue Jan 7 04:21:02 2014] which is always a huge bummer [Tue Jan 7 04:21:54 2014] thats odd :p [Tue Jan 7 04:22:01 2014] so the proof is complete but it wont wrap up [Tue Jan 7 04:22:13 2014] well, actually the proof isn't quite complete [Tue Jan 7 04:22:21 2014] it says no more subgoals [Tue Jan 7 04:22:29 2014] yeah, it's lying :) [Tue Jan 7 04:22:32 2014] because aterm_of_vterm isn't structurally restrictive [Tue Jan 7 04:22:34 2014] :p [Tue Jan 7 04:22:39 2014] er, recursive [Tue Jan 7 04:22:48 2014] damn, now I need to sleep, haha [Tue Jan 7 04:22:53 2014] haha [Tue Jan 7 04:23:13 2014] but you see where I call mapSeq? [Tue Jan 7 04:23:18 2014] yes [Tue Jan 7 04:23:28 2014] that's not a structurally recursive call to aterm_of_vterm [Tue Jan 7 04:23:33 2014] so it won't go through [Tue Jan 7 04:23:51 2014] now, coq has some magic for the builtin list.map that makes this kind of thing work [Tue Jan 7 04:24:20 2014] for example, check out: http://lpaste.net/98082 [Tue Jan 7 04:24:27 2014] wow thats some advanced stuff youre using :p [Tue Jan 7 04:24:33 2014] ok lemme see [Tue Jan 7 04:24:54 2014] if you look at f there, it's not technically structurally recursive [Tue Jan 7 04:25:09 2014] but coq has some heuristic I don't know about or something to do the right thing there [Tue Jan 7 04:25:23 2014] yea because it uses map right [Tue Jan 7 04:25:26 2014] right [Tue Jan 7 04:25:39 2014] maybe Ptival_ knows? [Tue Jan 7 04:25:47 2014] he's probably also asleep though. [Tue Jan 7 04:26:15 2014] you guys are in the US? [Tue Jan 7 04:26:21 2014] yeah, west coast [Tue Jan 7 04:26:30 2014] 1:25am atm [Tue Jan 7 04:26:31 2014] haha cool [Tue Jan 7 04:26:35 2014] gmt+1 here [Tue Jan 7 04:26:39 2014] (NL) [Tue Jan 7 04:26:46 2014] cool [Tue Jan 7 04:27:17 2014] im gonna have a closer look at your code [Tue Jan 7 04:27:39 2014] thank you so much for looking into this man, seems like you took your time [Tue Jan 7 04:27:44 2014] sounds good. [Tue Jan 7 04:27:52 2014] no problem, it's a good exercise for me [Tue Jan 7 04:27:59 2014] sorry I didn't get it all the way [Tue Jan 7 04:28:09 2014] haha you got close enough though, no more subgoals [Tue Jan 7 04:28:32 2014] also, I don't know how much you've done with dependent pattern matching, but that code might be kind of confusing [Tue Jan 7 04:28:55 2014] some of it does look somewhat exotic i would have to admit :p [Tue Jan 7 04:29:02 2014] so mapSeq isn't that bad [Tue Jan 7 04:29:42 2014] just map a function that might fail over a list, then if it succeeded on all elements, return all the results [Tue Jan 7 04:30:04 2014] then I have an admitted lemma that says if mapSeq succeeds, the resulting list has the same length as the input [Tue Jan 7 04:30:14 2014] I didn't bother to prove it, but it should be straightforward [Tue Jan 7 04:30:24 2014] (famous last words, but I'm pretty sure in this case) [Tue Jan 7 04:30:43 2014] :p [Tue Jan 7 04:30:51 2014] then there's aterm_of_vterm [Tue Jan 7 04:31:07 2014] if the lengths don't match, we fail right away (the else branch) [Tue Jan 7 04:31:24 2014] otherwise, we do the mapSeq [Tue Jan 7 04:31:32 2014] we match on the result of that [Tue Jan 7 04:31:35 2014] yea im still a bit puzzled how the mapSeq would even know that each of the elements in args is wf BECAUSE Fun h args is wf [Tue Jan 7 04:31:47 2014] oh, it won't [Tue Jan 7 04:32:09 2014] remember we're not thinking about wf yet [Tue Jan 7 04:32:23 2014] just doing the computation, and failing if we get into a not wf stage [Tue Jan 7 04:32:32 2014] then later, come back, prove a lemma about wf never failing [Tue Jan 7 04:32:34 2014] right? [Tue Jan 7 04:32:38 2014] ahh right [Tue Jan 7 04:32:47 2014] so mapSeq doesn't care about wf at all [Tue Jan 7 04:33:06 2014] but you're totally right that we'll have to prove some more lemmas about mapSeq preserving wf or something [Tue Jan 7 04:33:41 2014] okay, so back to aterm_of_vterm? [Tue Jan 7 04:33:45 2014] yes [Tue Jan 7 04:33:51 2014] so we match on the result of mapSeq [Tue Jan 7 04:34:09 2014] you should ignore everything between "as z..." up to "with" for right now [Tue Jan 7 04:34:19 2014] if the mapSeq failed, we fail too [Tue Jan 7 04:34:34 2014] (ignore the "fun _ =>" for now...) [Tue Jan 7 04:35:00 2014] otherwise, we get a list of results back, and we construct the Aterm with that, using asig_of_vsig (ignore the "fun p =>" for now... [Tue Jan 7 04:35:12 2014] does that make sense at a high level? [Tue Jan 7 04:35:18 2014] at a high level, yes [Tue Jan 7 04:35:29 2014] okay, so the details are a little nastier [Tue Jan 7 04:35:56 2014] basically, ATerm.Fun takes a vector, right? [Tue Jan 7 04:36:17 2014] so we have to prove to coq that the result "l" that we get back from mapSeq has the right length [Tue Jan 7 04:36:20 2014] yes, a string and a vector of a certain length depending on the string length [Tue Jan 7 04:36:35 2014] that turns out to be more annoyting than one might hope... [Tue Jan 7 04:36:44 2014] * can't type [Tue Jan 7 04:36:47 2014] :p [Tue Jan 7 04:37:02 2014] so have you seen the "return" annotations before? [Tue Jan 7 04:37:09 2014] yea ive seen it [Tue Jan 7 04:37:15 2014] not entirely sure what it does [Tue Jan 7 04:37:18 2014] ok [Tue Jan 7 04:37:32 2014] so if you were going to convince me that l has the right length, how would you do it? [Tue Jan 7 04:37:49 2014] l being args? [Tue Jan 7 04:38:06 2014] no, l being the result of mapSeq if it succeeds [Tue Jan 7 04:38:07 2014] ah right l being args with vterm_from_aterm applied to it [Tue Jan 7 04:38:09 2014] line 438 [Tue Jan 7 04:38:11 2014] yeah [Tue Jan 7 04:38:20 2014] i would say that map is length preserving [Tue Jan 7 04:38:25 2014] yep [Tue Jan 7 04:38:36 2014] so you need to know that l is in fact map applied to args [Tue Jan 7 04:38:53 2014] which it clearly is, because we matched on map applied to args, right? [Tue Jan 7 04:39:04 2014] but it turns out that coq can't see this equality directly [Tue Jan 7 04:39:11 2014] and that the length of args is proportional to the length of h, because Fun h args is wf [Tue Jan 7 04:39:15 2014] when you go inside the match, you lose what you were matching on. [Tue Jan 7 04:39:24 2014] haha, no wf yet! [Tue Jan 7 04:39:30 2014] :p [Tue Jan 7 04:39:56 2014] length of args is good because we checked all the way up on line 434 if the lengths matched, remember? [Tue Jan 7 04:40:05 2014] and we failed otherwise (else branch) [Tue Jan 7 04:40:33 2014] ah yes we did! [Tue Jan 7 04:40:40 2014] thats clever [Tue Jan 7 04:40:45 2014] ;) [Tue Jan 7 04:41:00 2014] but we have to convince coq of our cleverness :p [Tue Jan 7 04:41:29 2014] ok so as I was saying, when you go inside a match and get a result, coq forgets what you matched on [Tue Jan 7 04:41:40 2014] yes.. so how do we bring this under the attention of coq then? [Tue Jan 7 04:41:41 2014] there are good technical reasons for this, but it can be annoying in practice [Tue Jan 7 04:41:46 2014] good question. [Tue Jan 7 04:41:55 2014] the answer is the "as" and "return" annotations [Tue Jan 7 04:42:15 2014] "as z" means "remember the thing you're matching on and call it z" [Tue Jan 7 04:42:21 2014] ahh [Tue Jan 7 04:42:47 2014] so you can then refer to z within the match [Tue Jan 7 04:42:51 2014] yep [Tue Jan 7 04:42:54 2014] and also in the return [Tue Jan 7 04:43:01 2014] nice [Tue Jan 7 04:43:02 2014] "return ... = z -> option fterm_a" means "then give me a proof that what you matched on was actually 'mapSeq...' and I'll give you an option fterm_a" [Tue Jan 7 04:43:42 2014] now we've actually changed the type we want to return from the match [Tue Jan 7 04:43:53 2014] instead of returning just the option [Tue Jan 7 04:44:12 2014] we return a function from proofs that we're matching on "mapSeq ..." to options [Tue Jan 7 04:44:23 2014] that's why each branch starts with "fun" [Tue Jan 7 04:44:33 2014] because it takes in that proof [Tue Jan 7 04:44:42 2014] also notice that little underscore at the end of line 439 [Tue Jan 7 04:44:45 2014] that's very important [Tue Jan 7 04:44:59 2014] that's where we're going to call the function we returned from the match and pass it the proof [Tue Jan 7 04:45:10 2014] because we're inside a refine here, we can supply that proof later in proof mode. [Tue Jan 7 04:45:24 2014] did all that make sense? [Tue Jan 7 04:45:33 2014] one second :p [Tue Jan 7 04:45:37 2014] sure [Tue Jan 7 04:47:03 2014] brb. [Tue Jan 7 04:49:08 2014] ok so 'as' and 'return' are both modifiers of "match .. with" [Tue Jan 7 04:49:38 2014] yes, exactly [Tue Jan 7 04:49:41 2014] "annotations" [Tue Jan 7 04:49:46 2014] where does the p in fun p come from? [Tue Jan 7 04:49:52 2014] and where does the value of that last _ come from? [Tue Jan 7 04:49:56 2014] it's just an argument name [Tue Jan 7 04:50:12 2014] it's like where the x in "Fixpoint aterm_of_vterm (x : fterm_v) " comes from [Tue Jan 7 04:50:22 2014] ah [Tue Jan 7 04:50:29 2014] p for proof [Tue Jan 7 04:50:36 2014] so it can just be introduced there? [Tue Jan 7 04:50:37 2014] p has type apSeq aterm_of_vterm args = z [Tue Jan 7 04:50:53 2014] yeah, it's just an anonymous function [Tue Jan 7 04:51:03 2014] ok [Tue Jan 7 04:51:12 2014] I could have written "fun (p : mapSeq aterm_of_vterm args = z) => " [Tue Jan 7 04:51:19 2014] but coq is smart enough to infer it [Tue Jan 7 04:51:48 2014] actually, I probably could have left out the name entirely, but that's not really the point [Tue Jan 7 04:51:55 2014] :p [Tue Jan 7 04:52:03 2014] so what were you asking about the last _? [Tue Jan 7 04:52:07 2014] well [Tue Jan 7 04:52:25 2014] it seems that there is some sort of function application taking place [Tue Jan 7 04:52:30 2014] yes! [Tue Jan 7 04:52:33 2014] where that _ is taken as an argument [Tue Jan 7 04:52:37 2014] exactly [Tue Jan 7 04:52:40 2014] but where is that argument coming from then [Tue Jan 7 04:52:49 2014] oh, so that's where refine comes in handy [Tue Jan 7 04:53:03 2014] the whole function is inside a refine, right? [Tue Jan 7 04:53:07 2014] yes [Tue Jan 7 04:53:15 2014] ah right so you later tell Coq what the _ is [Tue Jan 7 04:53:19 2014] so we can put underscores wherever we want, and they become subgoals below [Tue Jan 7 04:53:35 2014] it turns out that that _ is very easy to fill in, "reflexivity" proves it [Tue Jan 7 04:54:02 2014] why does it even want that argument though [Tue Jan 7 04:54:23 2014] oh, because remember I said the type we're getting out of the match has changed [Tue Jan 7 04:54:41 2014] from (option fterm_a) to (mapSeq aterm_of_vterm args = z -> option fterm_a) [Tue Jan 7 04:54:44 2014] right? [Tue Jan 7 04:54:54 2014] yes [Tue Jan 7 04:55:01 2014] that's what the return annotation did, along with the "fun ... =>" in each branch [Tue Jan 7 04:55:05 2014] so now we have a function back [Tue Jan 7 04:55:07 2014] thats what return did [Tue Jan 7 04:55:10 2014] but that's not what we want yet [Tue Jan 7 04:55:11 2014] yea [Tue Jan 7 04:55:21 2014] we actually needed the (option fterm_a) [Tue Jan 7 04:55:26 2014] right? so we're not done yet [Tue Jan 7 04:55:30 2014] ahh right [Tue Jan 7 04:55:31 2014] we have to apply the function to something [Tue Jan 7 04:55:39 2014] but what we want to apply it to is a proof [Tue Jan 7 04:55:51 2014] and those are annoyhing to construct, so we just do it later [Tue Jan 7 04:55:58 2014] hence "_" [Tue Jan 7 04:56:07 2014] which looks like an emoticon [Tue Jan 7 04:56:14 2014] ok but why do we have a function there in the first place? Cant we just leave out the 'fun _ =>' part? [Tue Jan 7 04:56:17 2014] haha it does [Tue Jan 7 04:56:31 2014] yeah, that's a good question [Tue Jan 7 04:56:36 2014] the answer is no [Tue Jan 7 04:56:48 2014] I invite you to mess with it to see what the error messages are [Tue Jan 7 04:57:17 2014] but the reason boils down to the fact that coq does not (and in general, it turns out, *cannot*) remember what you matched in each branch of a match [Tue Jan 7 04:57:39 2014] and the way you remind it of what you matched on is with this weird return annotation [Tue Jan 7 04:58:07 2014] hmm right [Tue Jan 7 04:58:39 2014] haha its funny that what you did is actually not even that exotic but mostly necessary for coq to remember earlier information [Tue Jan 7 04:58:58 2014] yeah that happens a lot [Tue Jan 7 04:59:06 2014] cause at first sight i thought wow what is this guy doing haha [Tue Jan 7 04:59:19 2014] yep, that's the right first reaction :) [Tue Jan 7 04:59:49 2014] honestly, I'm no expert, so there may be a better way of doing it. but I have seen other people do it this way... [Tue Jan 7 05:00:26 2014] could you maybe expand a little on the proof steps you did? [Tue Jan 7 05:00:31 2014] what does specialize do for example [Tue Jan 7 05:00:34 2014] yeah, sure [Tue Jan 7 05:00:49 2014] okay before we get there [Tue Jan 7 05:01:16 2014] at a high level, we have one nontrivial subgoal, which boils down to convincing coq that "l" on line 438 has the right length, right? [Tue Jan 7 05:02:14 2014] l being that return thing [Tue Jan 7 05:02:15 2014] yes [Tue Jan 7 05:02:40 2014] l being the result from matchSeq if it succeeded, yeah [Tue Jan 7 05:03:09 2014] ok so this will be clearer if you actually step all the way up to that subgoal so you can see the context [Tue Jan 7 05:03:24 2014] aterm_of_vterm : fterm_v -> option fterm_a [Tue Jan 7 05:03:26 2014] x : fterm_v [Tue Jan 7 05:03:28 2014] f : S1.VSig [Tue Jan 7 05:03:30 2014] args : list (term S1.VSig) [Tue Jan 7 05:03:32 2014] _H : length args = arity (asig_of_vsig f) [Tue Jan 7 05:03:34 2014] l : list fterm_a [Tue Jan 7 05:03:36 2014] p : mapSeq aterm_of_vterm args = Some l [Tue Jan 7 05:03:38 2014] ============================ [Tue Jan 7 05:03:40 2014] vector (ATerm.term S1.ASig) (arity (asig_of_vsig f)) [Tue Jan 7 05:03:42 2014] should look like that (before the rewrite _H) [Tue Jan 7 05:03:54 2014] yep im there [Tue Jan 7 05:04:12 2014] okay so first we know that args has the same length as the arity of f [Tue Jan 7 05:04:15 2014] why do we know that? [Tue Jan 7 05:04:27 2014] i cant say wf can i :p [Tue Jan 7 05:04:30 2014] no! [Tue Jan 7 05:04:37 2014] haha, but that's why I asked :) [Tue Jan 7 05:04:54 2014] ***because we checked if the lengths were the same on line 434*** [Tue Jan 7 05:04:58 2014] :D [Tue Jan 7 05:05:04 2014] ah right [Tue Jan 7 05:05:22 2014] now eq_dec_nat has a fancy dependent type that gives you the right hypothesis in each branch of the if [Tue Jan 7 05:05:24 2014] so it would not have gone into that branch of the algorithm if the lengths were not the same [Tue Jan 7 05:05:28 2014] yep [Tue Jan 7 05:05:38 2014] _H is the result of that in the "then" branch [Tue Jan 7 05:05:42 2014] ahh [Tue Jan 7 05:05:45 2014] and it says the lengths of the same [Tue Jan 7 05:05:46 2014] i was wondering where that came from [Tue Jan 7 05:05:52 2014] god damn I really can't type [Tue Jan 7 05:05:59 2014] so _H is produced by eq_dec_nat? [Tue Jan 7 05:06:04 2014] kind of, yeah [Tue Jan 7 05:06:08 2014] kind of? [Tue Jan 7 05:06:29 2014] so the type of eq_dec_nat is weird [Tue Jan 7 05:06:46 2014] {n = m} + {n <> m} [Tue Jan 7 05:06:54 2014] you've seen stuff like that before? [Tue Jan 7 05:06:59 2014] yea [Tue Jan 7 05:07:02 2014] yeah okay [Tue Jan 7 05:07:14 2014] so in the "then" branch, we get "n = m" [Tue Jan 7 05:07:23 2014] and in the else branch we would get n <> m if we cared [Tue Jan 7 05:07:29 2014] that's where _H comes from [Tue Jan 7 05:07:33 2014] ah right [Tue Jan 7 05:07:37 2014] in this case n is length args and m is arity of f [Tue Jan 7 05:07:41 2014] so _H is just the branch of eq_dec_nat were in [Tue Jan 7 05:07:44 2014] yes [Tue Jan 7 05:08:01 2014] thats very kind of eq_dec_nat to leave that in the assumptions [Tue Jan 7 05:08:07 2014] :) yeah [Tue Jan 7 05:08:23 2014] you wouldn't have appreciated that kindness if we hadn't just spent 30 minutes talking about return annotations, haha [Tue Jan 7 05:08:31 2014] haha [Tue Jan 7 05:08:37 2014] that's why I didn't use beq_nat in the if there [Tue Jan 7 05:08:50 2014] oh beq_nat doesnt do that? [Tue Jan 7 05:08:53 2014] it would still work, but I'd have to use another lemma blah blah [Tue Jan 7 05:08:59 2014] no no, different problem [Tue Jan 7 05:09:02 2014] you still get an assumption [Tue Jan 7 05:09:14 2014] it just needs massaging before it's an equality [Tue Jan 7 05:09:23 2014] hmm [Tue Jan 7 05:09:25 2014] you get the assumption (beq_nat n m = true) [Tue Jan 7 05:09:29 2014] when you want (n = m) [Tue Jan 7 05:09:32 2014] right [Tue Jan 7 05:09:47 2014] not that hard to go between, but sometimes just easier to use eq_dec_nat [Tue Jan 7 05:09:49 2014] anyways [Tue Jan 7 05:09:57 2014] ok so yea [Tue Jan 7 05:10:00 2014] so we rewrite with that [Tue Jan 7 05:10:06 2014] we know that args has the same length as arity of f [Tue Jan 7 05:10:13 2014] yep [Tue Jan 7 05:10:22 2014] and after the rewrite we have the goal: [Tue Jan 7 05:10:28 2014] vector (ATerm.term S1.ASig) (length args) [Tue Jan 7 05:10:37 2014] yep [Tue Jan 7 05:10:46 2014] and we might think at this point "hey great, let's use (vec_of_list l) and we're done" [Tue Jan 7 05:10:51 2014] and in one sense, that is correct [Tue Jan 7 05:10:57 2014] and I invite you to try it to see what happens [Tue Jan 7 05:11:02 2014] you'll get an error [Tue Jan 7 05:11:16 2014] but conceptually it's the right idea. [Tue Jan 7 05:11:33 2014] well [Tue Jan 7 05:11:52 2014] but you probably already see what's wrong there. [Tue Jan 7 05:12:05 2014] let me try that, i would think that coq would say "but how is the length of that vector correct?" [Tue Jan 7 05:12:15 2014] yeah [Tue Jan 7 05:12:32 2014] so we need our mapSeq_length lemma [Tue Jan 7 05:13:05 2014] specialize is a tactic that, ironically, is very similar to generalize [Tue Jan 7 05:13:29 2014] if you give it a lemma, you can then partially apply some of the lemma's arguments [Tue Jan 7 05:13:40 2014] partially? [Tue Jan 7 05:13:55 2014] well if the lemma has 9 arguments, you could specify the first few but not necessarily all of them [Tue Jan 7 05:14:28 2014] and then it adds a hypothesis to your context with the lemma specialized to those arguments [Tue Jan 7 05:15:02 2014] where does specialize find "aterm_of_vterm args l p" [Tue Jan 7 05:15:23 2014] those are all arguments to mapSeq_length [Tue Jan 7 05:15:25 2014] oh those are assumptions :p nm [Tue Jan 7 05:15:29 2014] yeah [Tue Jan 7 05:15:45 2014] okay, if you step through the specialize and the intro you'll see the hypothesis, right? [Tue Jan 7 05:16:50 2014] yea the hypothesis being that mapSeq is length preserving [Tue Jan 7 05:16:56 2014] yeah [Tue Jan 7 05:17:09 2014] now at this point you should want to say "rewrite H" [Tue Jan 7 05:17:26 2014] but for reasons unknown to me, that gives a totally incoherent error message [Tue Jan 7 05:17:31 2014] haha [Tue Jan 7 05:17:43 2014] I think it's possibly related to the fact that the Defined isn't going to go through in a few lines [Tue Jan 7 05:17:54 2014] and the rewrite tactic just prints the wrong error or something [Tue Jan 7 05:17:57 2014] that's my guess [Tue Jan 7 05:18:13 2014] anyway, instead of rewrite, you can use replace, and it works for some reason [Tue Jan 7 05:18:17 2014] again, not sure why] [Tue Jan 7 05:18:28 2014] but why does it not give you another subgoal to prove [Tue Jan 7 05:18:44 2014] because I have that exact assumption in context [Tue Jan 7 05:18:45 2014] replace wants you to prove the equality from what i remember? [Tue Jan 7 05:18:49 2014] ah [Tue Jan 7 05:18:50 2014] yeah [Tue Jan 7 05:18:54 2014] but heuristics :) [Tue Jan 7 05:18:57 2014] so that does work but rewrite doesnt [Tue Jan 7 05:19:11 2014] yeah, like I said, probably for not-very-interesting error handling reasons [Tue Jan 7 05:19:30 2014] hm [Tue Jan 7 05:19:37 2014] this proof seems convincing [Tue Jan 7 05:19:43 2014] haha, good. [Tue Jan 7 05:19:45 2014] it should. [Tue Jan 7 05:19:46 2014] but apparently Coq chokes on it :< [Tue Jan 7 05:19:52 2014] nah, it likes the proof [Tue Jan 7 05:19:57 2014] "no more subgoals" [Tue Jan 7 05:20:02 2014] whats the part it doesnt like? [Tue Jan 7 05:20:04 2014] it just doesn't like the actual definition [Tue Jan 7 05:20:10 2014] of the function [Tue Jan 7 05:20:10 2014] why [Tue Jan 7 05:20:14 2014] it doesn't like the map [Tue Jan 7 05:20:21 2014] not structurally recursive blah blah blah [Tue Jan 7 05:20:24 2014] hmm [Tue Jan 7 05:20:31 2014] yea thats the idea of using map right [Tue Jan 7 05:20:38 2014] right [Tue Jan 7 05:20:53 2014] do you think i should try a more structurally recursive approach? [Tue Jan 7 05:21:00 2014] um, you could [Tue Jan 7 05:21:02 2014] like using fold_right or something? (im not even sure if that makes sense) [Tue Jan 7 05:21:21 2014] I'm not sure what the right approach in that direction would be [Tue Jan 7 05:21:28 2014] I mean, mapSeq is basically map [Tue Jan 7 05:21:44 2014] so if coq can figure map out, we should be able to convince it of mapSeq [Tue Jan 7 05:21:52 2014] I'm just not familiar with the machinery [Tue Jan 7 05:22:04 2014] so my suggested strategy would be to ask more peope in here :) [Tue Jan 7 05:22:10 2014] ha ok [Tue Jan 7 05:22:24 2014] i think its pretty funny that coq goes all the way through the proof with you [Tue Jan 7 05:22:33 2014] only to then say "mmmm nah i dont like your definition" [Tue Jan 7 05:22:36 2014] yeah that happens more often than you might think [Tue Jan 7 05:22:45 2014] it's actually a design choice that coq makes [Tue Jan 7 05:22:49 2014] tactics are unverified [Tue Jan 7 05:23:11 2014] then there's an extra "double check" step at the Qed or Defined that makes sure things are good [Tue Jan 7 05:23:26 2014] cool [Tue Jan 7 05:23:27 2014] well [Tue Jan 7 05:23:39 2014] im gonna see if i can approach it from another angle somehow [Tue Jan 7 05:23:51 2014] I assume most of these types you didn't define yourself [Tue Jan 7 05:23:55 2014] again thanks a lot, your comment was even more clarifying than i had expected! [Tue Jan 7 05:23:56 2014] like VTerm.term [Tue Jan 7 05:24:18 2014] oh, no worries [Tue Jan 7 05:24:19 2014] because like i said my first impression was "wow wtf" [Tue Jan 7 05:24:30 2014] glad to help [Tue Jan 7 05:24:42 2014] one thing you might try is to read some other functions that process VTerm.terms [Tue Jan 7 05:24:43 2014] yea those types are from the library [Tue Jan 7 05:24:49 2014] to see how they recurse and such [Tue Jan 7 05:24:56 2014] hm thats a good idea [Tue Jan 7 05:25:11 2014] maybe my approach is just wrong and there's a better one [Tue Jan 7 05:25:14 2014] that would be nice. [Tue Jan 7 05:25:26 2014] and that's better than you banging your head against this all day [Tue Jan 7 05:25:56 2014] thats ok, it builds character or so ive heard :p [Tue Jan 7 05:26:03 2014] it's true [Tue Jan 7 05:26:18 2014] anyway, I really need to sleep [Tue Jan 7 05:26:40 2014] but keep me posted, you've got me curious :) [Tue Jan 7 05:26:40 2014] alright see you later man [Tue Jan 7 05:26:45 2014] i will! [Tue Jan 7 05:26:48 2014] yep, have a good one [Tue Jan 7 08:01:42 2014] http://coq.inria.fr/library/Coq.Classes.Morphisms.html#Proper can someone please explain to me what is this all about? [Tue Jan 7 08:02:06 2014] I thought proper morphisms were something different [Tue Jan 7 08:43:56 2014] Where did the SetoidAxioms module went? Changelog doesn't mention it [Tue Jan 7 08:44:12 2014] I am looking for setoid_extensionality inparticular [Tue Jan 7 21:33:08 2014] http://www.cis.upenn.edu/~bcpierce/sf/Lists.html#lab68 - tl_length_pred right here doesn't make much sense to me; what are 'tl' and 'pred'? Are they declared implicitly and their types inferred? [Tue Jan 7 21:54:47 2014] pred = _ - 1. tl = second [Tue Jan 7 21:55:27 2014] well, not second. The tail of the list. second sometimes means that. [Tue Jan 7 21:58:04 2014] but then what does "length (tl l)" mean? [Tue Jan 7 21:58:34 2014] I was figuring that 'tl' had to be some kind of natlist -> natlist function, or something [Tue Jan 7 22:00:14 2014] if you have a list l = [1; 2] = 1 :: 2 :: nil, then tl l = [2] = 2 :: nil [Tue Jan 7 22:00:26 2014] so length l = 2 and length (tl l) = 1 [Tue Jan 7 22:01:35 2014] for that proposition to be a theorem, tl must be defined to return nil when given nil, and pred returns 0 given 0. [Tue Jan 7 22:03:24 2014] tl is defined on that page to do just that. [Tue Jan 7 22:04:00 2014] ohhhh, I was confused there for a minute. I thought you meant 'tl' was the tail of some specific list, i.e. 'tl' is a list [Tue Jan 7 22:04:03 2014] but now I see we're saying the same thing [Wed Jan 8 02:22:09 2014] i've imported Coq.Numbers.NatInt.NZLog, but getting "Error: The reference log2_up was not found in the current environment"; coq version 8.4pl2. what am i doing wrong? [Wed Jan 8 02:25:06 2014] will try to update [Wed Jan 8 02:26:59 2014] ugh, there's no 'uninstall' target in coq makefile =/ not that important though [Wed Jan 8 02:40:52 2014] same with 8.4pl3 [Wed Jan 8 03:08:59 2014] checked it, that definition is present in theories/Numbers/NatInt/NZLog.v, and it's compiled version was compiled lately. restarted proog general and coq also, and found that i had log2 from Coq.Numbers.Natural.Peano.NPeano; without that import, i don't have log2 even [Wed Jan 8 03:12:19 2014] probably i should open some scope [Wed Jan 8 03:15:50 2014] there is some NatScope, but i don't get how to open it. imported Coq.Numbers.Natural.Abstract.NAxioms, still getting "Error: Scope NatScope is not declared." [Wed Jan 8 03:32:50 2014] managed to use Z.log2_up from BinInt, but it's from ZArith [Wed Jan 8 03:33:23 2014] probably i could use Z2N, but it does not seem nice [Wed Jan 8 03:34:27 2014] Z.to_nat even [Wed Jan 8 03:36:01 2014] and Z.of_nat =/ [Wed Jan 8 03:49:18 2014] will it be harder to prove thorems with ZArith? [Wed Jan 8 06:01:15 2014] seems harder, there are negative cases [Wed Jan 8 06:01:32 2014] and it's excessive, because i don't even need them here [Wed Jan 8 06:11:57 2014] probably it'll be easier to define everything manually for nats [Wed Jan 8 06:32:34 2014] oh, there is N.log2_up [Wed Jan 8 06:32:36 2014] nice [Wed Jan 8 08:56:54 2014] how to define fixpoints with decreasing N? [Wed Jan 8 08:59:48 2014] i could convert it between N and nat all the time, but it does not seem nice at all [Wed Jan 8 09:00:12 2014] and probably will make proofs harder [Wed Jan 8 09:08:46 2014] perhaps i should read more about coq before trying to practice apart of exercises [Wed Jan 8 16:03:11 2014] wXeno: You eventually need to understand the underlying type theory. [Wed Jan 8 16:03:38 2014] You don't need to understand the _dynamics_ of how Coq works internally, in the same way as a Prolog programmer needs to manipulate the order of clause resolution and things like that. [Wed Jan 8 16:03:38 2014] that's not a big issue, since I'm just as interrested in the type theory as in the proofs [Wed Jan 8 16:04:42 2014] To the extent that similar issues arise, it's in figuring out how to build automated tactics (which is a large part of what CPDT is about) [Wed Jan 8 16:04:52 2014] Ltac is pretty vaguely specified and frustrating [Wed Jan 8 16:06:18 2014] :/ [Wed Jan 8 16:07:07 2014] this one got a pretty good walkthrough of the basics btw: http://www.cis.upenn.edu/~bcpierce/sf/index.html [Wed Jan 8 16:07:14 2014] yes, that's an excellent text [Wed Jan 8 16:07:18 2014] I wish he would make a print and/or pdf edition of it [Wed Jan 8 16:07:44 2014] if you work through even an initial segment of it you should have no problems with CPDT [Wed Jan 8 16:09:11 2014] (well, not *no* problems. there are never *no* problems in Coq.) [Wed Jan 8 16:10:15 2014] :) [Wed Jan 8 16:17:27 2014] https://github.com/math-classes/math-classes/blob/master/src/theory/hom_functor.v#L10 why won't this type check if I remove the 'Program' part? It says "The term "comp x v w X:(x ⟶ v) → x ⟶ w" has type "(x ⟶ v) → x ⟶ w" while it is expected to have type "homFrom v ⟶ homFrom w". [Wed Jan 8 16:17:28 2014] " [Wed Jan 8 16:17:40 2014] but the definition of `homFrom` is exactly that [Wed Jan 8 16:17:41 2014] idgi [Wed Jan 8 16:43:08 2014] notdan: it's not exactly that; homFrom is wrapped in the constructor setoids.object of setoids.Object; the raw arrow type is not [Wed Jan 8 18:05:29 2014] Hm, so why does the Program thing make it work? [Wed Jan 8 20:19:40 2014] notdan: I don't know if anyone else has answered your question [Wed Jan 8 20:19:57 2014] Program is a way of using tactics instead of explicit term construction to construct functions as opposed to just prove theorems [Wed Jan 8 20:20:28 2014] The "proof" tactic there is just `constructor` which does exactly that: applies the necessary constructor [Wed Jan 8 20:20:37 2014] which is precisely the difference between that arrow type and homFrom [Thu Jan 9 01:24:32 2014] is it possible to rewrite an assumption using another assumption? [Thu Jan 9 07:08:19 2014] notdan: I am Robbert Krebbers indeed. Unfortunatelly, it is not, all authors are currently working on other things, and we do not any running projects on the RU on formalization of math in Coq. If you have question about it, feel free to mail me (or Bas Spitters). [Thu Jan 9 07:47:03 2014] robbert: thanks, I'll try to play aroung with it a little bit more before mailing specific questions [Thu Jan 9 12:00:01 2014] Why does the 'Setoid' class have type 'Type -> Type'? Shouldn't it be Type -> Prop? [Thu Jan 9 12:05:54 2014] notdan: Equiv has type [Type -> Type] (that is the informative part), but Setoid has type [forall A, Equiv A -> Prop] [Thu Jan 9 12:09:49 2014] robbert: that's in math-classes, right? [Thu Jan 9 12:10:02 2014] I think that's reasonable, but I was talking about stdlib, sorry [Thu Jan 9 12:10:17 2014] sorry I didn't make that clear [Thu Jan 9 12:15:47 2014] notdan: because that Setoid class contains the relation, which you want to be able to project out [Thu Jan 9 12:15:54 2014] for that it needs to be in Type [Thu Jan 9 12:19:32 2014] So there is not possible to define a type of proper setoid morphisms using the stdlib definition? [Thu Jan 9 12:20:28 2014] I tried (exists h, Proper (equiv ==> equiv) h) [Thu Jan 9 12:20:39 2014] oh I guess I can use pairT [Thu Jan 9 12:22:49 2014] Or use a record [Thu Jan 9 12:40:04 2014] oh right, that works [Thu Jan 9 13:04:50 2014] if I have a goal that uses match e as o return (e = o -> ...) with ... end, and a hypothesis H: e = something, Coq does not let me rewrite H to reduce the goal. What is the proper incantation to do such things? [Thu Jan 9 13:06:45 2014] ouch, I am using this definition of setoid morphism http://vpaste.net/9ACSC and I need to prove that composiiton of setoid morphisms is still a setoid morphism. [Thu Jan 9 13:07:30 2014] So I managed to get to this point: http://vpaste.net/c29bi but now I have this problem of two different proofs for 'Setoid b' sm_from0 and sm_to1 [Thu Jan 9 13:07:39 2014] and they are incompatible [Thu Jan 9 13:09:35 2014] setoid hell. [Thu Jan 9 13:16:14 2014] Oh got it, need to redefine the record type: http://vpaste.net/sLBXi the (Setoid B) proof is not being duplicated that way [Thu Jan 9 13:16:18 2014] ianjneu: indeed :( [Thu Jan 9 13:16:57 2014] I set to proof Yoneda lemma a couple of days ago, fast-forward, have to sit and read about setoids [Thu Jan 9 13:22:21 2014] Category theory in Coq is very difficult. You might want to check out jgross's category theory library for pointers. He had to jump through many hoops. [Thu Jan 9 13:25:16 2014] The one in HoTT repository? [Thu Jan 9 13:25:25 2014] so much of my experience with Coq is *intense concentration for 6 hours* followed by FUUUUUUUUCK [Thu Jan 9 13:25:31 2014] notdan: I think so. [Thu Jan 9 13:25:36 2014] haha [Thu Jan 9 13:26:23 2014] oh he is using records [Thu Jan 9 13:26:31 2014] I was toying wit the typeclass approach [Thu Jan 9 13:27:57 2014] Also he doesn't deal with setoids, I think? Probably using some HoTT equality [Thu Jan 9 13:35:40 2014] Is there a way to split goal of proving the equality of records into several goals? [Thu Jan 9 13:37:44 2014] f_equal doesn't work? [Thu Jan 9 13:40:36 2014] oh I didn't think of records as functions [Thu Jan 9 13:40:37 2014] thanks [Thu Jan 9 13:41:36 2014] records aren't functions, but their constructors are. [Thu Jan 9 14:31:36 2014] Managed to prove the associativity of setoid morphisms using proof irrelevance [Thu Jan 9 14:31:51 2014] not sure if it was fair to use it [Thu Jan 9 14:52:06 2014] Someday, I'll know WTF you are saying. [Thu Jan 9 14:53:57 2014] Hodapp: elaborate? [Thu Jan 9 14:57:30 2014] ianjneu: Can you say a little bit about why your goal looks like that? (I'm not questioning you, I'm curious - I don't understand why you build the match to return e = o -> something.) [Thu Jan 9 14:57:43 2014] *would build a match [Thu Jan 9 14:59:46 2014] ianjneu: 'setoid' and 'proof irrelevance' are not yet words I even know the meaning of. It will be a ways before I work with them with fluency. [Thu Jan 9 15:02:58 2014] ystael: I wanted to case split on whether my alist lookup finds something, and maintain the equality of the result so I could use a theorem that correlates the algorithmic lookup and the relational lookup, "MapsTo" [Thu Jan 9 15:05:23 2014] Hodapp: "X-oid" in type theory means there is possibly higher path structure to the generally set-theoretic X. As for Coq's setoid's, they're a structure of a type and an equivalence relation, meant to use the typeclass system to make congruence-based reasoning more natural. They're a pain in the butt though. [Thu Jan 9 15:06:07 2014] But in that context e and o are not already definitionally equal? (since the name o is assigned to e by the match?) [Thu Jan 9 15:07:53 2014] ystael: nope. That would admit axiom K I believe. [Thu Jan 9 15:08:36 2014] ianjneu: hm. I clearly don't understand equality yet then :) [Thu Jan 9 15:13:54 2014] ah, I see what I don't understand, though I still don't understand it [Thu Jan 9 15:20:16 2014] ianjneu: when I'm in that situation, sometimes destructing on the discriminee works for me, sometimes it doesn't (error something like: goal depends on foo). but I have no idea what I'm doing. will be curious to see if you get a better answer [Thu Jan 9 15:25:46 2014] jrw: I can't destruct it or do case_eq. It needs to transport the equality across the return type, but I don't know how to make it do that. [Thu Jan 9 15:26:28 2014] I get an error along the lines of, "if you do this, you get BAAAARF which is ill-typed." [Thu Jan 9 15:26:48 2014] which is indicative of a missing transport. [Thu Jan 9 17:42:07 2014] Yay, managed to define the category of setoids and the covariant hom-functor [Thu Jan 9 17:42:55 2014] the problem was that Coq auto-picked an equivalence relation on setoid morphisms for me, and it was just Leibniz equality [Thu Jan 9 17:43:02 2014] which is wrong [Thu Jan 9 19:41:57 2014] ianjneu: and a hypothesis H: e = something <- use "destruct H" or "symmetry in H; destruct H" or "destruct (eq_sym H)" (I don't recall which side gets eliminated) [Thu Jan 9 19:44:23 2014] ianjneu: Or use "subst e". This is assuming "e" is a variable. If it's a term, you might need to first "revert H" then make it a variable by "generalize e" or "pattern e; generalize e" or a manual "change" to introduce the transport in the right place, and then you can re-intro H and destruct it. [Thu Jan 9 19:45:12 2014] (This is all assuming H is not mentioned in the goal at all. If it is, you should be able to do "pose proof H" and then destruct your new equality, but you'll be out of luck when you need to know the structure of H) [Thu Jan 9 19:52:50 2014] notdan, ianjneu: Yes, the one in the HoTT repository is the most recent version, and it uses higher inductive types rather than setoids. There's an older version of the repo at https://bitbucket.org/JasonGross/catdb, and if you go far back enough in the history, there's some work with very basic category theory based on setoids. There's not yet a proof of the yoneda lemma in HoTT/HoTT, but please feel free to clean up [Thu Jan 9 19:52:50 2014] https://github.com/JasonGross/HoTT-categories/blob/yoneda/theories/Categories/Yoneda.v (my wip on the previous version of the ct library) and port it to HoTT/HoTT and submit a pull request. Also, I plan to submit a paper to ITP 2014 on the trials and tribulations of making a performant category theory library in a proof assistant. If there's interest, I can announce (or email/irc message) when I have a better draft of it (it currently requires [Thu Jan 9 19:52:50 2014] a decent amount of reorganization). [Thu Jan 9 23:05:04 2014] http://www.cis.upenn.edu/~bcpierce/sf/Lists.html#lab73 hrmph, rev_involutive is really tripping me up for some reason [Thu Jan 9 23:05:24 2014] it *looks* like something that induction on l should solve easily, but I cannot find a way to make it work [Thu Jan 9 23:06:19 2014] gotten the subgoal to "rev (snoc (rev l') v') = v' :: l'" and just cannot find how to apply the inductive hypothesis "rev (rev l)) = l" to it [Thu Jan 9 23:06:31 2014] er, s/l/l'/ for the hypothesis [Thu Jan 9 23:19:54 2014] Hodapp: rewrite? [Thu Jan 9 23:24:12 2014] * slaps jgross__ around a bit with a large trout [Thu Jan 9 23:25:01 2014] Oops, sorry, I was seeing what a button in the kiwiirc.com irc client did. [Thu Jan 9 23:36:34 2014] Hey, if I have a goal which is "S _ = O -> something", how do I prove it? [Thu Jan 9 23:36:47 2014] the lhs is obviously false but I don't know how to tell it [Thu Jan 9 23:39:49 2014] aha, congruence [Fri Jan 10 00:46:47 2014] Hodapp: did you get it? [Fri Jan 10 05:07:54 2014] jgross: oh I would love to read such paper [Fri Jan 10 05:08:24 2014] jgross: unfortunately I don't know anything about higher inductive types, so I think such a write up would be very interesting and useful for me [Fri Jan 10 05:10:54 2014] Hodapp: you need to get that v' in front of the rev(rev(l')), I think a 'simpl' will suffice [Fri Jan 10 07:42:17 2014] notdan: 'simpl' just gets me from "rev (rev (v' :: l')) = v' :: l'" to the subgoal I stated; not sure what you mean [Fri Jan 10 07:43:40 2014] bishboria: I have tried rewriting with the inductive hypothesis and it's not clear to me that it gets me anywhere. [Fri Jan 10 07:53:18 2014] been trying to remove the outermost 'rev' somehow and just can't seem to get there; simplifying just appears to bury the v' deeper inside another application of 'rev' [Fri Jan 10 08:00:07 2014] I think you have to prove that 'rev (snoc l v) == v :: rev l' [Fri Jan 10 08:00:21 2014] and then you can use that lemma to prove your goal [Fri Jan 10 08:00:29 2014] at least that's how I did it [Fri Jan 10 08:01:47 2014] hmm, yeah, that looks like it'd work [Fri Jan 10 08:01:49 2014] for the `cons` case of l, I did: simple, then two different rewrites [Fri Jan 10 08:02:41 2014] (simple might not be necessary, I liked to use it as I ran through proofs step at a time to see how things change) [Fri Jan 10 12:11:59 2014] notdan: about HITs, I don't use them much. The selling point is that you use them when you need to (quotient types, epimorphisms in Set), and otherwise don't need to worry about them at all. Unlike setoids, where you need to worry about them everywhere. [Fri Jan 10 12:52:48 2014] I'd like to see HITs used for representing binding. See how that looks. [Fri Jan 10 13:40:50 2014] HIT for higher-order inductive types? [Fri Jan 10 14:02:26 2014] jgross: I'll take a look, this sounds promising [Fri Jan 10 14:02:27 2014] Ptival: higher inductive types. Higher as in n > 0 htypes. [Fri Jan 10 14:19:32 2014] ianjneu: oright [Fri Jan 10 15:23:34 2014] I'm trying to figure out the right definition of stuttering bisimulation refinement that doesn't need proof relevance for reduction relations. It's not going smoothly. Grah. [Fri Jan 10 15:25:30 2014] The parametric bisimulations paper is way too complicated to import. [Fri Jan 10 15:40:03 2014] proof relevance? [Fri Jan 10 15:52:30 2014] notdan: I'd rather not get into it. [Fri Jan 10 15:55:05 2014] got it. thought you made a typo [Fri Jan 10 16:44:02 2014] ianjneu: Have you considered basing your work on HoTT, where proof relevance is a good thing, rather than annoying? [Fri Jan 10 17:01:26 2014] jgross: do you mean that HoTT addresses some of the annoying parts of relevance? [Fri Jan 10 17:04:28 2014] jgross: I don't think it's really necessary. I just have to wrap more into props. I don't have any higher path structure since the reduction relation is decidable. [Fri Jan 10 17:05:33 2014] Rather, I'm trying to bake in a notion of stuttering into my relation between two trace-based semantics. [Fri Jan 10 17:06:42 2014] s --> s' ==> n,s |--> n', s' and n' < n ==> n,s |--> n',s [Fri Jan 10 17:07:29 2014] Saizan: HoTT gives a systematic way for reasoning about proof-releant equalities. What annoying parts were you thinking of? [Fri Jan 10 17:08:16 2014] ianjneu: You need prop for impedicativity, or something else? [Fri Jan 10 17:08:38 2014] The annoying parts are basically the syntactic separation of Type and Prop in Coq, so that all libraries I use have to be duplicated with Type instead of Prop. [Fri Jan 10 17:10:02 2014] I don't need relevant equalities. Rather I (thought I) need a relevant proof of s stepsto* s', so I can transform that trace in one semantics to a corresponding trace in the other semantics. [Fri Jan 10 17:10:32 2014] I'm trying a different approach nowe. [Fri Jan 10 17:10:36 2014] now* [Fri Jan 10 17:13:37 2014] jgross: well i was thinking about those, e.g. needing to prove two proofs of equality equal, knowing that it's a groupoid helps but maybe you meant more? like some powerful tactic? [Fri Jan 10 17:19:56 2014] Like, if you have two proofs of equality between sigma types, and you want to prove them equal, then you'd be stumped if they don't unify. But if you know HoTT, then you know that the type (p; H) = (p'; H') (with _;_ being the constructor for sigma types, i.e., existT in Coq) is equivalent to the type (p = p'; H = H'). So now you've simplified your proof obligation from one of type @eq ((p; H) = (p' H')) _ _ to @eq (p = p'; H = H') _ _. And [Fri Jan 10 17:19:56 2014] there's a way to prove equality of dependent pairs, namely, first prove equality of the first components, then of the second components. Maybe your first components will unify now, and then your second component proof will be doable. The idea is just that before, when you were faced with an iterated equality, you blinked and were confused, or used proof irrelevance, and now when you're faced with an iterated equality, you know how to keep [Fri Jan 10 17:19:56 2014] simplifying it until you can either prove it, or exhibit a counter-example. [Fri Jan 10 17:22:48 2014] ah, right, i guess coming at it from K i never really experienced that part of the problem [Fri Jan 10 17:23:39 2014] jgross: Is there an Agda port of your category library? Or is that a stupid question? [Fri Jan 10 17:23:47 2014] so i mostly see "ok, i proved the first projections equal, now i'll have that in the way when i prove the second projections are too" [Fri Jan 10 17:28:02 2014] There are a bunch of lemmas dealing with how you proved the first projections equal. e.g., if you used functional extensionality, there's a way of fixing that if the functions are all applied in the second projections. [Fri Jan 10 17:31:52 2014] ah, nice [Fri Jan 10 17:32:18 2014] are they discussed in the book too? [Fri Jan 10 18:19:58 2014] Almost certainly, but I haven't read that far yet. Basically, they're rules for how transport interacts with various functions with construct paths. [Sat Jan 11 00:25:58 2014] http://www.cis.upenn.edu/~bcpierce/sf/Lists.html#lab78 - huh, I guess I did the easy way. They'd already proven rev is involutive, so I did l1 = rev (rev l1) and l2 = rev (rev l2), thus making the goal rev (rev l1) = rev (rev l2) which the hypothesis readily makes true [Sat Jan 11 00:26:02 2014] not sure what the hard way was... [Sat Jan 11 04:15:33 2014] Hodapp: the hard way is by inductino probably [Sat Jan 11 08:21:08 2014] notdan: probably. I found the easy way pretty slick nonetheless. [Sat Jan 11 08:23:13 2014] though it's less impressive when I read that all involutions are bijections and therefore injective :P [Sat Jan 11 17:01:48 2014] How do I make a modules called foo.bar? [Sat Jan 11 17:02:07 2014] "Module Export foo.bar." gives an error [Sat Jan 11 18:00:43 2014] Igloo: Modulo foo. Module bar. ? [Sat Jan 11 18:03:33 2014] Hmm, I still get "Error: The file .../foo/bar.vo contains library bar and not library foo.bar" [Sat Jan 11 21:40:54 2014] Is anyone here familiar with the ConCaT contrib? I'm finding it's short names and lack of comments combination particularly impenetrable. [Sat Jan 11 23:29:04 2014] is there a way to assert something and maintain its definitional equalities after you give the proof? [Sat Jan 11 23:30:17 2014] ianjneu: Not that I know of. There a few ways around this, but generally I end up defining this outside the theorem [Sat Jan 11 23:30:30 2014] Note that 'pose proof' sometimes works well when you know what the proof term looks like [Sat Jan 11 23:31:15 2014] The point is to use tactics instead of giving the term up front. [Sat Jan 11 23:31:20 2014] oh well :/ [Sat Jan 11 23:32:01 2014] Well, if the definitional equalities are important, maybe a tactic shouldn't be used [Sat Jan 11 23:32:08 2014] Proof relevant mathematics, after all :) [Sat Jan 11 23:35:51 2014] mumble grumble. [Sat Jan 11 23:36:28 2014] I guess I should actually learn how to build these terms myself. It's just sooo much redundant typing. [Sun Jan 12 01:04:04 2014] ianjneu: You can often get away with _s. It's also good to understand how to build these terms yourself. That said, you can go build coq trunk yourself, and you can do what you want there; you get access to the proof term after building it with tactics. (There's also a nifty feature where you get to do things like "Definition foo := $(let t := constr:(1 + 1) in let t' := eval simpl in t in exact t')$.") [Sun Jan 12 08:36:05 2014] Has anyone got any idea how to make hierarchicial module names work please? http://paste.debian.net/75757/ [Sun Jan 12 10:54:37 2014] Which version of Coq natively supports eta-expansion for functions? [Sun Jan 12 10:58:55 2014] 8.4 is supposed to, but I can't find any docs for how to apply xi. [Sun Jan 12 11:00:59 2014] oh, I can prove xi by reflexivity. [Sun Jan 12 11:48:13 2014] So i'm looking to learn coq. What would be the best IDE? [Sun Jan 12 11:48:28 2014] Roscoebeezie: coqide or proof general [Sun Jan 12 11:49:17 2014] Those are kind of the only two reasonable choices you have as far as I'm aware, and they're more or less equivalent [Sun Jan 12 11:50:46 2014] hmm i'm not really to big on emacs so I guess its coqide [Sun Jan 12 11:51:40 2014] I did see that there were some vim plugins anyone have experiance with those [Sun Jan 12 11:54:20 2014] There's apparently this: http://www.vim.org/scripts/script.php?script_id=4388 [Sun Jan 12 11:54:40 2014] I don't know, I suppose you could use it. [Sun Jan 12 11:56:29 2014] The key thing you need is something to show you the hypotheses and goals, as well as other messages from coq as you step through a proof. [Sun Jan 12 11:56:59 2014] Anything which does that should be fine. coqide presents them in a split view. [Sun Jan 12 11:57:48 2014] I guess the other nice thing when you're starting out is that coqide has menus of the standard tactics and stuff [Sun Jan 12 11:58:21 2014] so if you can't quite remember the names of them, you can still look through to see if there's something which sounds about right :) [Sun Jan 12 11:59:53 2014] http://www.youtube.com/watch?v=7sk8hPWAMSw might also be helpful [Sun Jan 12 12:05:52 2014] Yeah I just tried it vs proof general and It just makes alot more sense [Sun Jan 12 12:41:26 2014] How would I go about change text color in coqide? [Sun Jan 12 12:54:23 2014] man, refine is pretty useless when it comes to putting _s in eliminator applications. It just complains about some application of a unification variable not being the same as some other application of a different unification variable. When you give the correct motive, it works. [Sun Jan 12 13:41:34 2014] feck, is there a translation of internal_typename_rew_r to path induction? [Sun Jan 12 13:41:47 2014] typename in this case is my eq type in Type. [Sun Jan 12 13:41:53 2014] "eqT" [Sun Jan 12 13:58:22 2014] okay, starting to get the hang of this. [Sun Jan 12 14:46:43 2014] awesome. Uncaught exception not found when trying to elide an inferrable argument. [Sun Jan 12 15:43:12 2014] meh, no coq 8.4pl3 in opam [Sun Jan 12 18:30:14 2014] ianjneu: You should consider reporting the uncaught exception. (https://github.com/JasonGross/coq-bug-finder can help you minimize a test case). path induction is just dependent pattern matching, so there should always be a translation. (The translation to eliminators is non-trivial when you start using recursion/fixpoints, but as long as the call isn't recursive, there's an easy translation.) You can print out the [internal_] constants to [Sun Jan 12 18:30:14 2014] see how they're defined. Using [rewrite] consists of first [pattern]ing on something, and then applying a lemma. The second step can ~always be replaced by [transport] or [transportD] or similar. [Sun Jan 12 19:49:59 2014] I'm having a bit of trouble with Ltac, trying to abstract over another tactic. If it takes an argument (even a dummy argument) everything is fine, if not it runs too early [Sun Jan 12 19:54:52 2014] I thought tactic arguments were basically call by name [Sun Jan 12 20:04:43 2014] The problematic argument was a tactic defined like Ltac foo ::= match ... end. adding ; idtac to the end of that somehow fixes things [Sun Jan 12 20:22:55 2014] napping: Ltac has this confusing behavior where there's "I'm returning something" mode and "I'm computing something" mode. The first is eagerly evaluated (think [match goal with |- ?G => constr:(G) end], while the second is lazily evaluated (or cbv rather than cbn, or something). Adding [; idtac] makes the tactic not be in "returning something" mode. [Sun Jan 12 20:39:20 2014] That seems to be how it works. From the documentation, I was expecting a match goal with tactics in the branches to be defining a tactic rather than eagerly returning something [Sun Jan 12 21:08:49 2014] jgross: submitted. It was actually really shallow. [Sun Jan 12 21:09:00 2014] https://coq.inria.fr/bugs/show_bug.cgi?id=3209 [Mon Jan 13 09:29:53 2014] i'm trying to re-program http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.7587&rep=rep1&type=pdf [Mon Jan 13 09:30:11 2014] http://sprunge.us/TUOP but i fail to see how to apply the IH here [Mon Jan 13 10:33:17 2014] chris2: your definition of delete_neutral is dubious. [Mon Jan 13 10:34:32 2014] nm, I see r1 is a constructor. [Mon Jan 13 10:39:43 2014] yes [Mon Jan 13 10:40:35 2014] i tried destructing x1/x2 now, but i can't figure out the rmult cases [Mon Jan 13 10:41:17 2014] I'm working it out too. I'll let you know. [Mon Jan 13 10:41:44 2014] i also tried destructing (rmult x1 x2) [Mon Jan 13 10:42:03 2014] the paper doesnt say much about it, but apparently they solve it with a rather simple tactic [Mon Jan 13 10:43:22 2014] and obviously i can't rewrite inner terms with IHx1, nor show delete_neutral x1 = x1 in general because T_A is not injective [Mon Jan 13 10:44:15 2014] I'm brute-forcing it myself. [Mon Jan 13 10:44:31 2014] i stopped after three levels on induction :P [Mon Jan 13 10:47:09 2014] Oh, I have just the one. [Mon Jan 13 10:50:20 2014] http://sprunge.us/KMUW [Mon Jan 13 10:50:53 2014] let me step through it [Mon Jan 13 10:51:26 2014] nice [Mon Jan 13 10:51:38 2014] unfold T_A; fold T_A; [Mon Jan 13 10:51:42 2014] what does that do? [Mon Jan 13 10:54:28 2014] it does some reductions, but not as many as simpl. [Mon Jan 13 10:54:38 2014] that was the step i was missing, i guess [Mon Jan 13 10:54:48 2014] simpl is terrible to control with many match [Mon Jan 13 10:56:37 2014] precisely. [Mon Jan 13 10:57:04 2014] i will rewrite this thing later with ssreflect anyway [Mon Jan 13 10:57:43 2014] such stuff should be fully auto-matable, tho. [Mon Jan 13 10:58:47 2014] I wish I knew the right way to automate it. [Mon Jan 13 11:09:29 2014] my best compression :( http://sprunge.us/XCdI [Mon Jan 13 11:49:30 2014] somehow i cant make auto/autorewrite do the simplest rewrites... [Mon Jan 13 11:53:18 2014] ok, adding all rewrites helps :P [Mon Jan 13 12:00:27 2014] elaborate? [Mon Jan 13 12:01:21 2014] i forgot a rule [Mon Jan 13 12:04:41 2014] ianjneu: ok, http://sprunge.us/KQTO [Mon Jan 13 12:08:49 2014] not bad. [Mon Jan 13 12:09:07 2014] unfortunately not powerful enough :P [Mon Jan 13 12:09:32 2014] delete_neutral should be a bit more complex [Mon Jan 13 12:09:36 2014] but then it doesnt work anymore [Mon Jan 13 13:24:03 2014] whats the point of JMeq with regard to dependent types, could someone explain? [Mon Jan 13 13:24:36 2014] i have sort of a vague idea about how its necessary to use that but not quite clear.. [Mon Jan 13 13:28:23 2014] my understanding is that it is a more lax way of defining equality, since it allows you to talk about equality of things whose types are not structurally equal [Mon Jan 13 13:34:38 2014] right.. [Mon Jan 13 13:34:56 2014] that makes sense [Mon Jan 13 13:35:04 2014] roosbeef: http://homotopytypetheory.org/2012/11/21/on-heterogeneous-equality/ [Mon Jan 13 13:35:05 2014] but now im looking at this lemma for example [Mon Jan 13 13:35:21 2014] and i dont see the significance of it https://privatepaste.com/7c046406a7 [Mon Jan 13 13:35:28 2014] ianjneu, ive been reading that.. [Mon Jan 13 13:36:22 2014] why would something not be structurally equal to itself? [Mon Jan 13 13:36:46 2014] i can see how JMeq helps to speak of structural equality between lists and vectors for example, but that lemma doesnt make sense to me [Mon Jan 13 13:37:04 2014] it's a way of glossing over transport [Mon Jan 13 13:37:48 2014] glossing over? [Mon Jan 13 13:38:51 2014] how does transport come into play here [Mon Jan 13 13:38:52 2014] hand-waving it away so you can say P(x) = P(y) instead of transport[z.P](some-proof-that-x=y). [Mon Jan 13 13:39:20 2014] why would it be necessary to use transport otherwise? [Mon Jan 13 13:39:26 2014] anyway, I'm heading out to MIT for the HoTT reading group. [Mon Jan 13 13:40:00 2014] alright, take care [Mon Jan 13 13:40:11 2014] thanks for your help [Mon Jan 13 13:40:13 2014] er, not P(x) = P(y) but m : P(x) and n : P(y) with JMeq m n allowing you to gloss over the transport from m to n. [Mon Jan 13 13:41:04 2014] roosbeef: let's say you have v1 : Vec (x + y), and v2 : Vec (y + x), you can express that they are equal before you show that + is commutative [Mon Jan 13 13:43:05 2014] what? How [Mon Jan 13 13:43:25 2014] x y : nat? [Mon Jan 13 13:45:30 2014] yes [Mon Jan 13 13:47:11 2014] ah because of the "forall (n n' : nat), n = n' -> " part? [Mon Jan 13 13:48:01 2014] Ptival: Let me check that I understand properly what I've been reading :) Without JMeq, you would have to use the eliminator for = on nat to derive that Vec (x + y) = Vec (y + x), and then the eliminator for = on Set to derive a function Vec (x + y) -> Vec (y + x), is that right? [Mon Jan 13 14:00:19 2014] back in 10 mins [Mon Jan 13 14:03:04 2014] ystael: without JMeq, you could not express an equality between v1 and v2, you'd have to transform either into the other's type using eliminating a proof of "x + y = y + x" [Mon Jan 13 14:56:42 2014] Ptival ah ah JMeq (the John Major equality : all members of the society are equal, but only to members of their (social) class :) ) [Mon Jan 13 15:13:23 2014] Anarchos: haha yeah, Conor explained it to me in a pub, it's all very political :) [Mon Jan 13 15:28:22 2014] Ptival it is mentioned in a footnote of the french edition of the coqart :) [Mon Jan 13 15:45:57 2014] ah [Mon Jan 13 19:45:23 2014] does anyone have experience with Coquille (CoqIDE for vim - https://github.com/the-lambda-church/coquille) or using Coq in vim? [Mon Jan 13 19:47:53 2014] I went as far as to install Coquille yes [Mon Jan 13 19:48:59 2014] any comments? good? bad? terrible? exemplary? [Mon Jan 13 19:49:38 2014] at the time it was pretty good, I'm fairly used to ProofGeneral by now so I didn't bother making the switch, but I liked it [Mon Jan 13 19:50:52 2014] good to hear [Mon Jan 13 19:52:21 2014] Is there a way I can stop the implementation leaking here: http://paste.debian.net/76068/ [Mon Jan 13 23:51:12 2014] does anyone have an opinion regarding CoqArt vs Certified Programming w/ DT vs Software Foundations for a beginner? [Tue Jan 14 00:06:47 2014] adelbertc: I think if you're truly a beginner at coq, you should start with sf and do as much of it as possible [Tue Jan 14 00:06:59 2014] adelbertc: if you finish that and want more, read CPDT [Tue Jan 14 00:07:15 2014] if you finish that and want someone else's take on how to teach coq, maybe then look at coqart [Tue Jan 14 00:18:30 2014] jrw - noted, cheers [Tue Jan 14 00:19:26 2014] adelbertc: and I at least (and probably others in this channel) am happy to answer questions when you have them :) coq can be confusing at first [Tue Jan 14 00:20:37 2014] glad to hear it :-) [Tue Jan 14 00:20:44 2014] i attempted software foundations last year [Tue Jan 14 00:20:59 2014] didn't go well. then again i wasn't very well versed in functional programming back then either (not sure if this has any effect) [Tue Jan 14 00:23:04 2014] adelbertc: well certainly being familiar with fp can help understand the kind of programs sf has you write at the beginning. but sf strives to not make fp a prereq. [Tue Jan 14 00:23:21 2014] got it [Tue Jan 14 00:23:43 2014] i ws also using coqide at the time which may have contributed to my giving up as well.. it hasn't garnered many fond reviews from the few people i've asked [Tue Jan 14 00:25:55 2014] yeah, in my experience most people use proof general. you can always put emacs in "easy" mode if you want. I forget the real name, but basically it gives you Ctrl-x/c/v as cut/copy/paste [Tue Jan 14 06:23:19 2014] is it possible to rewrite an assumption using another assumption? [Tue Jan 14 06:25:49 2014] roosbeef: rewrite H in H'? [Tue Jan 14 06:28:26 2014] that should work? [Tue Jan 14 06:29:17 2014] H : exists C : context S1.VSig, t = fill C st [Tue Jan 14 06:29:18 2014] H0 : fterm_v_is_wf t [Tue Jan 14 06:29:34 2014] i have these two assumptions, was trying to rewrite t in H0 to fill C st [Tue Jan 14 06:30:24 2014] rewrite H in H0 gives Error: The term does not end with an applied homogeneous relation. [Tue Jan 14 09:57:25 2014] so ive got this property [Tue Jan 14 09:57:34 2014] 'wf_tree' [Tue Jan 14 09:58:00 2014] from this property i know that if a tree is well formed, so are all its subtrees [Tue Jan 14 09:58:12 2014] im trying to prove this in Coq [Tue Jan 14 09:59:45 2014] https://privatepaste.com/07e53712b0 [Tue Jan 14 10:00:26 2014] subterm_eq unfolds to H : exists C : context S1.VSig, t = fill C st [Tue Jan 14 10:01:01 2014] how do i use this to sculpt the current subgoal? [Tue Jan 14 10:01:49 2014] (ie. https://privatepaste.com/0b523a5e80) [Tue Jan 14 10:27:04 2014] ystael, perhaps you would have some light to shed on this? [Tue Jan 14 10:28:24 2014] roosbeef: I missed whatever it is [Tue Jan 14 10:28:40 2014] haha pm [Tue Jan 14 10:34:46 2014] roosbeef: Well, first you need to unfold that existential [Tue Jan 14 10:38:13 2014] ystael, how? [Tue Jan 14 10:39:19 2014] sorry, I had to look it up :) [Tue Jan 14 10:39:22 2014] destruct it [Tue Jan 14 10:40:00 2014] remember that an existential is a dependent pair, the first coordinate is the context C, the second coordinate is the equation dependent on C [Tue Jan 14 10:40:12 2014] destruct H will split the pair in the context [Tue Jan 14 10:41:03 2014] ha thx :) [Tue Jan 14 10:41:34 2014] yea thats precisely what i was looking to do, split the quantification from the assertion [Tue Jan 14 11:08:47 2014] hm [Tue Jan 14 11:20:47 2014] i have the assumption H: is_wf (fill x st) [Tue Jan 14 11:21:07 2014] and the subgoal is_wf st [Tue Jan 14 11:21:40 2014] which can be derived from H, since if (fill x st) is well formed, so is st [Tue Jan 14 11:22:19 2014] (x being a context in t, such that is_wf t) [Tue Jan 14 11:30:14 2014] i need a break bbl [Tue Jan 14 14:40:57 2014] hi guys. I finished reading software foundations couple of months ago but I never used Coq for anything since then. now I was wondering if Coq is also useful for proving theorems not in programming language related fields but in fields like abstract algebra(groups etc.) or number theory. can anyone give me some pointers on that? I'm a CS major but this [Tue Jan 14 14:40:58 2014] semester I'm taking an abstract algebra course just for fun and I was thinking maybe I can use my Coq knowledge in that course somehow. [Tue Jan 14 14:42:24 2014] osa1 - i believe coq was used to prove the four color theorem in graph theory [Tue Jan 14 14:43:01 2014] adelbertc: yeah I heard something like that too(though I'm not sure if what I heard was Coq and not some other theorem prover). do you have any introductory examples on that kind of things? [Tue Jan 14 14:43:24 2014] unfortunately, no, i'd be interested myself. i'm a newbie at coq, haven't even gotten through software foundations yet [Tue Jan 14 14:44:08 2014] maybe I should send an email to mailing list [Tue Jan 14 14:57:39 2014] sent an email to coq list [Tue Jan 14 19:04:36 2014] hrmph, I keep getting Coq (well, Proof General) into a state where I seem to be hanging the process and I have no idea why, and C-c C-c is not doing anything (it says the proof process is not active) [Tue Jan 14 19:08:36 2014] http://pastebin.com/hjHib0xf - if I uncomment what is commented, this seems to cause it, oddly [Tue Jan 14 19:08:44 2014] yet 'coqc' doesn't seem to bomb out on it [Tue Jan 14 19:16:10 2014] a bunch of messages on the coq-club mailing list have been censored from Gmane, it seems [Tue Jan 14 19:16:28 2014] mostly from the second half of december I think [Tue Jan 14 19:16:31 2014] any idea why? [Tue Jan 14 19:16:43 2014] was there some XNo-Archive header or something being added to messages on coq-club at that time? [Tue Jan 14 19:16:54 2014] can someone who receives coq-club emails check? [Tue Jan 14 19:38:59 2014] kini: my email client is so shitty I can't access the whole email header. Sorry. [Tue Jan 14 19:40:46 2014] ianjneu: impressive, haha - what client is that? [Tue Jan 14 20:13:34 2014] kini: a severely old version of Zimbra, a web client my school hosts. [Tue Jan 14 20:13:45 2014] I can't even reply inline. [Tue Jan 14 20:13:55 2014] I compose such emails in emacs. [Wed Jan 15 01:07:15 2014] from the assumption H0 : fterm_v_is_wf (fill x st) [Wed Jan 15 01:07:25 2014] how do i derive that fterm_v_is_wf st? [Wed Jan 15 01:08:24 2014] (fill x st) is basically a term with st a subterm [Wed Jan 15 01:08:36 2014] if a term is well formed, all of its subterms are [Wed Jan 15 01:09:15 2014] im a bit unsure as to how to approach this [Wed Jan 15 01:11:51 2014] roosbeef: I'm not sure I understand. if fill x st actually just contains st as a subterm, then you should be able to get what you want by inversion on H0 [Wed Jan 15 01:14:00 2014] it does [Wed Jan 15 01:15:29 2014] can I see the definition of fill? [Wed Jan 15 01:16:00 2014] oh wait, when you say "subterm" do you mean "immediate subterm" or is st way deep down somewhere? [Wed Jan 15 01:18:33 2014] http://color.inria.fr/doc/CoLoR.Term.Varyadic.VContext.html#fill [Wed Jan 15 01:18:56 2014] both, it can be as deep as the term goes [Wed Jan 15 01:33:47 2014] roosbeef: the direct approach would be to formalize the notion of subterm and then prove your claim that all subterms of a wf term are wf [Wed Jan 15 01:34:19 2014] formalize it how? [Wed Jan 15 01:34:24 2014] exactly :) [Wed Jan 15 01:34:32 2014] well [Wed Jan 15 01:34:39 2014] on the other hand, I think a lemma of the form "wf (fill c t) -> wf t" might be provable by induction on c [Wed Jan 15 01:34:42 2014] fill x st is actually an unfold of subset_eq [Wed Jan 15 01:35:00 2014] oh :( [Wed Jan 15 01:35:06 2014] err, subterm_eq: http://color.inria.fr/doc/CoLoR.Term.Varyadic.VContext.html#subterm_eq [Wed Jan 15 04:38:53 2014] Are there any libraries/frameworks/whatever for proving stuff about concurrent programs that use shared mutable state and locks? [Wed Jan 15 06:40:01 2014] how do I define mutually inductive types as in http://pastebin.com/XB9FA148 ? [Wed Jan 15 06:40:26 2014] currently I get "The reference Ctx was not found in the current environment" [Wed Jan 15 13:37:31 2014] Does anyone have suggestions for standard references (for use as citations in a paper) for the folklore semantic connection between categories and typed functional programming; for higher-order type theory; and for setoids? [Wed Jan 15 13:44:11 2014] jgross: can you be more specific? Surely category theory was used to give denotational semantics to typed functional programming languages, but you seem to be getting at something else. What is "higher-order" type theory? [Wed Jan 15 13:49:36 2014] setoids originated in Bishop's 1967 book on set theory [Wed Jan 15 13:56:27 2014] ianjneu: This is for citations for the intro of a paper I'm writing for a conference. (Higher-order here I think just means "functions can take functions as input") [Wed Jan 15 13:59:49 2014] So the category theory <-> function programming connection is probably just what you mentioned. (The intro was mostly written by my advisor.) [Wed Jan 15 14:00:01 2014] Bob doesn't have any citations for his holy trinityL [Wed Jan 15 14:00:04 2014] ?* [Wed Jan 15 14:01:51 2014] jgross: I didn't hear you mention it in this week's reading group, but you said next week there's no meeting, right? [Wed Jan 15 14:02:14 2014] correct, and it was mentioned, maybe after the feed ended. [Wed Jan 15 14:02:25 2014] ah, ok, sorry [Wed Jan 15 14:35:25 2014] I will not be going to POPL. I will be cleaning my baby's POOPL [Wed Jan 15 18:07:59 2014] jgross: do you mean the original Lambek's theorem about functional programming/CCCs? [Thu Jan 16 01:11:08 2014] so im working with this library on term rewriting [Thu Jan 16 01:11:16 2014] and trying to do some stuff with well foundedness [Thu Jan 16 01:11:33 2014] theres a section about wf (http://www.lix.polytechnique.fr/coq/distrib/8.2-bugfix/stdlib/Coq.Init.Wf.html#well_founded) [Thu Jan 16 01:11:45 2014] which seems useful in this regard [Thu Jan 16 01:12:09 2014] from what i can tell it can do computations given a certain wf [Thu Jan 16 01:12:46 2014] but how do i tell Coq which wf to use, how do i describe what would be a wf term [Thu Jan 16 01:15:33 2014] oh actually those are from the std lib btw [Thu Jan 16 01:15:57 2014] but still i dont see where to plug in the definition of wf to use [Thu Jan 16 09:18:07 2014] roosbeef: http://adam.chlipala.net/cpdt/html/GeneralRec.html you'll use "Fix" [Thu Jan 16 20:16:02 2014] huh, interesting... SF has pointed out the interpretation that their polymorphic List type can be seen as a Type -> Type function [Thu Jan 16 20:16:10 2014] this is somehow the first time I've seen it that way [Thu Jan 16 20:47:24 2014] http://www.cis.upenn.edu/~bcpierce/sf/Poly.html#lab89 - I'm not totally getting what this question is asking, but is the answer zero, since I can't actually create a single element of that type? [Thu Jan 16 20:48:41 2014] unless I can make some sort of recursive definition, e.g. x Z where Z = x Z [Thu Jan 16 20:55:44 2014] hodapp: it's 0, since baz is not coinductive. [Thu Jan 16 20:59:42 2014] I can't quickly find any clean definition of 'coinductive' that seems to very obviously not describe 'baz'. [Thu Jan 16 21:01:31 2014] It's easy to think of recursive occurrences of a coinductive type's definition as "delayed" in the lazy evaluation sense. [Thu Jan 16 21:02:16 2014] Coinduction in Coq is broken, though. I suggest not using it, or at least using the Paco library. [Thu Jan 16 21:04:08 2014] I'm still not grasping what about coinduction makes the answer to that question zero. [Thu Jan 16 21:07:39 2014] Well, unless you have a guarded corecursive function that generates baz'es to lazily consume (think of a function f : ones -> baz := fun s => match s with CS s' => x (f s') end) [Thu Jan 16 21:08:03 2014] but I don't remember if that's allowed if baz isn't a coinductive type or not. [Thu Jan 16 21:08:48 2014] Also, in this case I take CoInductive ones := CS : ones -> ones. [Thu Jan 16 21:10:13 2014] likely they're trying to get at since there are no base cases in the inductive type, there is no wellfounded construction of one, and we thus say there aren't any inhabitants. [Thu Jan 16 21:11:13 2014] Coinduction, even though it's just flipping the arrows of induction, is not well supported in theorem provers. Annoying. [Thu Jan 16 21:13:14 2014] Corecursors are defined by the proof of terminality of the corecursive object in the category of F-coalgebras. [Thu Jan 16 21:14:21 2014] but in the case of arbtrary pattern matching, like Coq has for inductive types, the story is murkier, apparently. [Thu Jan 16 21:17:05 2014] I have no idea on any of this. I'm working through an early chapter in Software Foundations. [Thu Jan 16 21:25:31 2014] the categorical basis is intriguing, and I'm not a pointy-headed theorist. [Thu Jan 16 21:26:58 2014] It is all very intriguing to me, but there is only so much intrigue I can handle without knowing much in this area. [Thu Jan 16 21:29:56 2014] The HoTT book is pretty good at explaining the foundational issues. [Thu Jan 16 21:30:52 2014] I intended, after finishing Software Foundations, to move onto either HoTT or CPDT. [Thu Jan 16 21:34:19 2014] deeeefinitely HoTT. CPDT is like a memior of, "Coq is annoying to do really complicated things in. Here's how I hacked around it. BAAAAARF." [Thu Jan 16 21:51:14 2014] HoTT will teach you a lot about the foundational issues and how to think about equality types, not so much about Coq (though the HoTT exercises might be more fun than the CPDT exercises for people who like math). CPDT will teach you how to use Coq to do stuff, and not so much about the theory behind it. [Thu Jan 16 21:54:41 2014] I'm curious about both. [Fri Jan 17 03:43:57 2014] What do you mean by coinduction is broken? I was thinking of one of my developments recently and I realized that I am in need of inifinite structures [Fri Jan 17 03:44:15 2014] Coq'Art book talks about coinduction a bit, granted I didn't read that section [Fri Jan 17 03:55:57 2014] Reduction doesn't preserve the productivity condition; you can go from a valid definition to an invalid one just by simplification. Also, it's really hard to get anything done, because it's not compositional. (This is what I've heard from others; I've not really used coninduction myself.) [Fri Jan 17 04:49:48 2014] hm, I se [Fri Jan 17 04:49:51 2014] that's unfortunate [Fri Jan 17 05:09:22 2014] The more I think about it, the more I find myself impressed with the ridiculously simple constructions and proofs that path induction provides you (i.e. regarding concatenation, the inverse, all the laws and their coherences) [Fri Jan 17 05:09:48 2014] The amount of fiddly nonsense which that papers over is remarkable :) [Fri Jan 17 05:10:40 2014] and like, how somehow in there is all the information you need for an infinity groupoid, when the classical definitions of this are so often horrifying [Fri Jan 17 05:10:55 2014] and it's all so easy to unpack [Fri Jan 17 05:11:10 2014] bwaaa, it's 5 AM here, what neck of the woods are you two in? [Fri Jan 17 05:11:24 2014] It's 5am here, but I woke up at 6pm [Fri Jan 17 05:11:42 2014] I think that means you need to move to another continent or something [Fri Jan 17 05:12:02 2014] But then I'd have to move back in like 2 days or something [Fri Jan 17 05:12:11 2014] Pfffft. [Fri Jan 17 05:12:16 2014] My sleep schedule is extremely erratic :) [Fri Jan 17 05:12:37 2014] THERE ARE TOO MANY INTERESTING THINGS [Fri Jan 17 05:12:50 2014] mine's pretty normal, except for today. [Fri Jan 17 05:14:29 2014] Cale: is that something from HoTT? [Fri Jan 17 05:14:32 2014] path induction [Fri Jan 17 05:14:41 2014] notdan: yeah [Fri Jan 17 05:15:05 2014] man i should get onto that hott train ASAP it seems awesome and makes everything eathier [Fri Jan 17 05:15:12 2014] hodapp: it's 2pm for me :) [Fri Jan 17 05:15:54 2014] Whenever you want to prove something of the form Pi (x, y : A), Pi (p : x = y), C(p), you're essentially allowed to assume that y is definitionally equal to x, and that p is refl, and prove C(refl_x) [Fri Jan 17 05:16:36 2014] that's for any C: (x = y) -> Type [Fri Jan 17 05:17:48 2014] and basically what this means is that when you want to do something like define the concatenation of paths p : x = y and q : y = z, you apply path induction a couple times, and you get to assume that p and q are both refl_x [Fri Jan 17 05:18:07 2014] and then define the concatenation as refl_x [Fri Jan 17 05:18:13 2014] and path induction does the rest [Fri Jan 17 05:18:25 2014] It's like "what just happened?" [Fri Jan 17 05:19:09 2014] In traditional homotopy theory, you'd be messing around with functions from the interval [0,1] into your space [Fri Jan 17 05:19:44 2014] this is what we are used to from Agda; what I find a bit weird is that the above does not mean that every equality is refl, it's just that proving things for refl makes them hold for any other equality :) [Fri Jan 17 05:20:19 2014] yeah, a key thing to realise is that you're not allowed to do this unless you're doing it for all paths in a space at once [Fri Jan 17 05:20:33 2014] I'd like to use Agda a bit after learning a bit more of Haskell [Fri Jan 17 05:20:47 2014] side question: anyone know a way in Proof General to simply show the result of evaluating something? [Fri Jan 17 05:21:02 2014] (or, it can be shown that it works for all paths having *one* endpoint at a specific place) [Fri Jan 17 05:21:10 2014] But *both* endpoints: no. [Fri Jan 17 05:21:42 2014] nevermind, I guess C-c C-a C-c does it [Fri Jan 17 05:21:53 2014] or not... [Fri Jan 17 05:22:00 2014] I don't know Proof General so well, but I'd try Print whatever. [Fri Jan 17 05:22:16 2014] oh, or you want the cbv thing [Fri Jan 17 05:22:27 2014] cbv? [Fri Jan 17 05:22:35 2014] you can still put an "Eval compute in foo bar baz." in your script but this is discouraged afaik :) [Fri Jan 17 05:23:09 2014] Eval cbv in [Fri Jan 17 05:23:19 2014] or Compute [Fri Jan 17 05:23:22 2014] ziman: yeah, I'm looking at an 'Eval compute in...' in the textbook and wanting to get the result of that evaluation [Fri Jan 17 05:23:49 2014] ziman: Well, I think you're discouraged from leaving them in for whatever reason. [Fri Jan 17 05:24:11 2014] I'm not sure you're discouraged from using them to test things for yourself. [Fri Jan 17 05:24:18 2014] hodapp, you just put it into the script and step over it [Fri Jan 17 05:25:02 2014] (It's obviously annoying if you write a library of stuff which has all kinds of Prints and such in the proof scripts.) [Fri Jan 17 05:25:04 2014] I have no idea how to step in a script [Fri Jan 17 05:25:20 2014] hodapp: the button which makes things green? [Fri Jan 17 05:25:54 2014] (and impossible to edit) [Fri Jan 17 05:26:00 2014] I know of no such button in Proof General; I only know of C-c C-b which processes the entire buffer [Fri Jan 17 05:26:10 2014] orly... [Fri Jan 17 05:26:18 2014] I'm pretty sure the emacs toolbar has it [Fri Jan 17 05:26:48 2014] I also seem to recall it was bound to some key, but I never learn keybindings properly for my editors :P [Fri Jan 17 05:27:00 2014] I'll load up a .v and see [Fri Jan 17 05:27:03 2014] I just re-enabled the toolbar and I don't see it (also, I use this from SSH pretty often)... C-c C-n seems to do what I need though [Fri Jan 17 05:28:48 2014] try C-c C-n [Fri Jan 17 05:28:51 2014] yes [Fri Jan 17 05:29:29 2014] I think there's also C-c C-p iirc. [Fri Jan 17 05:31:26 2014] that lets me inspect the current proof/subgoals, I believe [Fri Jan 17 06:02:11 2014] ok so i have this wf property P on terms t, from P t follows that for all subterms st of t, it also holds that P st [Fri Jan 17 06:02:49 2014] what would be the conventional way of proving this given as a lemma? [Fri Jan 17 06:02:59 2014] Lemma t_wf_then_st_wf : forall (t : fterm_v) (st : fterm_v), subterm_eq st t -> fterm_v_is_wf t -> fterm_v_is_wf st. [Fri Jan 17 06:26:02 2014] I would use my proof that st was a subterm of t to recursively walk down my inductive proof that t is well formed, until I found the proof that st was well formed as a Coq-subterm of it. [Fri Jan 17 06:26:16 2014] But really it depends on how these things are defined... [Fri Jan 17 06:27:35 2014] (I like to formulate a lot of things as inductive types whenever I can, so that I can do induction on proofs) [Fri Jan 17 06:29:18 2014] roosbeef: Can you prove this for each fterm_v constructor individually, and then put the proofs together, perhaps? [Fri Jan 17 06:29:48 2014] (and where the subterm is an immediate one) [Fri Jan 17 06:30:20 2014] mm [Fri Jan 17 06:30:25 2014] dont know [Fri Jan 17 06:30:40 2014] i find this quite confusing to be honest [Fri Jan 17 06:31:28 2014] Try something simpler like: forall (t t' : fterm_v), fterm_v_is_wf (App t t') -> fterm_v_is_wf t [Fri Jan 17 06:31:40 2014] what does App do? [Fri Jan 17 06:31:53 2014] I'm assuming that App is a constructor of the inductive type fterm_v [Fri Jan 17 06:32:00 2014] I have no idea how your type is defined in the first place :) [Fri Jan 17 06:32:06 2014] :p [Fri Jan 17 06:32:32 2014] right, so [Fri Jan 17 06:32:46 2014] if the result of building t is wf, then t is wf [Fri Jan 17 06:33:10 2014] (Could I see your definitions perhaps?) [Fri Jan 17 06:33:14 2014] yeah [Fri Jan 17 06:33:30 2014] sure [Fri Jan 17 06:34:02 2014] http://color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html#term [Fri Jan 17 06:34:27 2014] http://coq.inria.fr/V8.2pl1/contribs/CoLoR.Term.Varyadic.VContext.html#subterm_eq [Fri Jan 17 06:34:49 2014] oh those arent the same versions i guess, doesnt matter hopefully [Fri Jan 17 06:35:17 2014] Er, where is fterm_v? [Fri Jan 17 06:36:14 2014] Definition fterm_v : Type := VTerm.term S1.VSig. [Fri Jan 17 06:40:47 2014] hmm [Fri Jan 17 06:42:45 2014] Okay, so, subterm_eq st t should be a dependent pair of a context C (which is an inductive type there), and a proof that t = fill C st [Fri Jan 17 06:43:50 2014] The idea of the context type is that it's like a term with a hole blown in it. If you have any term, it's either constructed with Var [Fri Jan 17 06:44:13 2014] In which case the Hole has only one place to go, in place of the variable [Fri Jan 17 06:46:22 2014] And this is a little mindbending, but the other case is it's constructed with Fun, as a mapping from (Signatures?) and lists of terms to terms [Fri Jan 17 06:46:54 2014] and you can see in the context type, there's a constructor Cont to handle this case, where we take some terms and a context, and some more terms, and produce a context [Fri Jan 17 06:47:28 2014] oh, sorry, no, it's straightforward, I got confused for a moment [Fri Jan 17 06:47:46 2014] So you have Fun applied to a Sig and a list of terms [Fri Jan 17 06:47:53 2014] yep [Fri Jan 17 06:48:02 2014] You want to put a hole in one of them, so you have some list before the hole, then a context, and some list after [Fri Jan 17 06:48:11 2014] yea [Fri Jan 17 06:48:28 2014] i can see how t = fill C st, if subterm_eq st t [Fri Jan 17 06:49:08 2014] how is fterm_v_is_wf defined? [Fri Jan 17 06:49:11 2014] but im a bit unsure as to what way to go about proving that Lemma, what steps to take [Fri Jan 17 06:49:49 2014] https://privatepaste.com/ec5670f76f [Fri Jan 17 06:50:27 2014] Why do people have so much love for Prop? :) [Fri Jan 17 06:50:29 2014] okay [Fri Jan 17 06:50:35 2014] (basically, an fterm_v is well formed if there is a certain ratio between the length of its head and the number of arguments) [Fri Jan 17 06:51:20 2014] i dunno, its the Proper way i guess :p [Fri Jan 17 06:53:16 2014] oh neat [Fri Jan 17 06:53:20 2014] Lemma subterm_ind : ∀ (P : term → Prop) [Fri Jan 17 06:53:20 2014] (IH : ∀ t, (∀ u, subterm u t → P u) → P t), [Fri Jan 17 06:53:20 2014] ∀ t, P t. [Fri Jan 17 06:53:32 2014] yea i was looking at that [Fri Jan 17 06:54:05 2014] it doesnt seem to fit into the proof of that lemma [Fri Jan 17 06:54:06 2014] Lemma subterm_eq_rect : ∀ (P : term → Type) t, [Fri Jan 17 06:54:06 2014] (∀ u, subterm_eq u t → P u) → P t. [Fri Jan 17 06:54:12 2014] Or that [Fri Jan 17 06:54:23 2014] subterm_eq_rect is going from wf subterms to wf term, right? [Fri Jan 17 06:55:00 2014] i need to prove that if t is wf, then all subterms st are fw [Fri Jan 17 06:55:03 2014] wf* [Fri Jan 17 06:55:54 2014] ah, right, yes [Fri Jan 17 06:57:35 2014] Well, we need some way to let you do induction on the structure of the term which is somehow directed by the context that you get from subterm_eq [Fri Jan 17 06:57:46 2014] Like... [Fri Jan 17 07:00:59 2014] If p is a proof that subterm_eq u t [Fri Jan 17 07:01:16 2014] why would you need a proof of that [Fri Jan 17 07:01:29 2014] that is a given right.. [Fri Jan 17 07:01:41 2014] Yeah, we're going to take that as a given [Fri Jan 17 07:02:49 2014] Well, we want the C [Fri Jan 17 07:03:05 2014] for which it's the case that exists C, t = fill C u. [Fri Jan 17 07:03:14 2014] yea exactly! [Fri Jan 17 07:03:19 2014] but how do we pin that C [Fri Jan 17 07:03:20 2014] Because that thing is going to tell us how to step down [Fri Jan 17 07:06:36 2014] so suppose we have H : exists C : context S1.VSig, t = fill C st [Fri Jan 17 07:07:09 2014] how does that crystalize into something more workable [Fri Jan 17 07:08:08 2014] Try decompose record H. [Fri Jan 17 07:09:09 2014] Does that work? :) [Fri Jan 17 07:09:09 2014] ok that gives the same as 'destruct H' [Fri Jan 17 07:09:13 2014] Yeah [Fri Jan 17 07:09:17 2014] adds x : context S1.VSig and H0 : t = fill x st [Fri Jan 17 07:09:30 2014] Now you can induction x [Fri Jan 17 07:09:42 2014] I'm not sure that's *exactly* what you want on its own [Fri Jan 17 07:09:45 2014] But it's something... [Fri Jan 17 07:10:14 2014] Try it and see if you end up in a rhubarb or not :) [Fri Jan 17 07:10:27 2014] There might be some lemma we could prove to make this work more smoothly [Fri Jan 17 07:10:40 2014] But I have a feeling that with enough induction it'll go through [Fri Jan 17 07:11:00 2014] hm [Fri Jan 17 07:11:01 2014] well [Fri Jan 17 07:11:02 2014] (I can't try it myself because I don't have your code) [Fri Jan 17 07:11:14 2014] thats actually as far as i got until now :p [Fri Jan 17 07:11:19 2014] i did just that [Fri Jan 17 07:11:23 2014] with induction on x [Fri Jan 17 07:11:25 2014] What happens? [Fri Jan 17 07:11:33 2014] i get stuck :p [Fri Jan 17 07:11:41 2014] So we have two cases [Fri Jan 17 07:11:52 2014] One is that the context is Hole [Fri Jan 17 07:11:57 2014] Did you get that one okay? [Fri Jan 17 07:12:16 2014] the t = fill Hole st should simplify to t = st [Fri Jan 17 07:12:22 2014] I'd expect [Fri Jan 17 07:12:43 2014] yea the first case was trivial [Fri Jan 17 07:14:01 2014] Okay, so in the next case, we'll have t = Cont f v1 c' v2 [Fri Jan 17 07:15:07 2014] and t = fill (Cont f v1 c' v2) st should simplify to t = Fun f (v1 ++ fill c' st :: v2) [Fri Jan 17 07:15:21 2014] * pretends to be Coq [Fri Jan 17 07:16:11 2014] this is as far as i got: https://privatepaste.com/ac24e93804 [Fri Jan 17 07:16:47 2014] simpl in H [Fri Jan 17 07:16:57 2014] what happens? [Fri Jan 17 07:17:23 2014] H : ar f = length (l ++ fill x st :: l0) /\ [Fri Jan 17 07:17:23 2014] list_prop (map fterm_v_is_wf (l ++ fill x st :: l0)) [Fri Jan 17 07:17:37 2014] yea that looks a lot like what you just said [Fri Jan 17 07:17:53 2014] although not quite but in a way it does :p [Fri Jan 17 07:18:35 2014] What's ar? [Fri Jan 17 07:18:52 2014] Oh, arity [Fri Jan 17 07:18:53 2014] hah [Fri Jan 17 07:18:54 2014] okay [Fri Jan 17 07:19:09 2014] yep [Fri Jan 17 07:19:34 2014] So, the first bit is just saying that the top level of t was okay [Fri Jan 17 07:20:17 2014] yep the first half of /\ [Fri Jan 17 07:20:17 2014] and the second bit is (informally) saying that fterm_v_is_wf for every element of l ++ fill x st :: l0 [Fri Jan 17 07:20:36 2014] yes [Fri Jan 17 07:20:42 2014] and all we need to apply our induction hypothesis [Fri Jan 17 07:20:54 2014] is fterm_v_is_wf (fill x st) [Fri Jan 17 07:21:05 2014] so that's in there, we just need to dig it out [Fri Jan 17 07:21:17 2014] sounds good [Fri Jan 17 07:21:20 2014] but how :p [Fri Jan 17 07:21:52 2014] Well, first of all, just split that thing apart with destruct [Fri Jan 17 07:22:29 2014] yep [Fri Jan 17 07:22:33 2014] then unfold list_prop? [Fri Jan 17 07:22:49 2014] Yeah, what is that even? [Fri Jan 17 07:23:16 2014] https://privatepaste.com/dbca6b40f2 [Fri Jan 17 07:27:12 2014] okay, so let's go back and do a lemma or two [Fri Jan 17 07:27:53 2014] what kind of lemmas? [Fri Jan 17 07:28:43 2014] Lemmas relating ++ and list_prop [Fri Jan 17 07:30:12 2014] Lemma list_prop_append (l l' : list Prop) : list_prop (l ++ l') -> list_prop l /\ list_prop l'. [Fri Jan 17 07:31:01 2014] hmm [Fri Jan 17 07:31:53 2014] but how do we get rid of map fterm_v_is_wf in H2 : list_prop (map fterm_v_is_wf (l ++ fill x st :: l0)) [Fri Jan 17 07:32:45 2014] the lemma for that already exists in the list library I believe [Fri Jan 17 07:32:59 2014] Lemma map_app : forall l l', map (l++l') = (map l)++(map l'). [Fri Jan 17 07:33:53 2014] apply map_app in H2. gives Error: Statement without assumptions. [Fri Jan 17 07:35:35 2014] rewrite map_app in H2? [Fri Jan 17 07:35:43 2014] (might need to supply params) [Fri Jan 17 07:36:07 2014] ah [Fri Jan 17 07:36:09 2014] yea that works, H2 : list_prop (map fterm_v_is_wf l ++ map fterm_v_is_wf (fill x st :: l0)) [Fri Jan 17 07:37:20 2014] okay, and in the meantime, I crudely proved the other lemma [Fri Jan 17 07:38:00 2014] http://lpaste.net/98642 [Fri Jan 17 07:39:19 2014] haha nice [Fri Jan 17 07:39:38 2014] Lemma list_prop_append (l l' : list Prop) : list_prop (l ++ l') -> list_prop l /\ list_prop l'. [Fri Jan 17 07:39:38 2014] firstorder ; induction l ; firstorder. [Fri Jan 17 07:39:39 2014] Qed. [Fri Jan 17 07:39:41 2014] better proof [Fri Jan 17 07:39:46 2014] lol [Fri Jan 17 07:39:46 2014] ok [Fri Jan 17 07:39:54 2014] so now we have H2 : list_prop (map fterm_v_is_wf l) /\ list_prop (map fterm_v_is_wf (fill x st :: l0)) [Fri Jan 17 07:40:05 2014] now [Fri Jan 17 07:40:21 2014] We only want the second part of that [Fri Jan 17 07:40:28 2014] You can destruct it if you want [Fri Jan 17 07:40:40 2014] (and clear the first part even) [Fri Jan 17 07:41:19 2014] and then simpl, and the bit we need should come out [Fri Jan 17 07:41:41 2014] cool [Fri Jan 17 07:41:44 2014] (the map will reduce because it's applied to a constructor) [Fri Jan 17 07:41:50 2014] yea its coming to the surface :) [Fri Jan 17 07:41:53 2014] H3 : list_prop (map fterm_v_is_wf (fill x st :: l0)) [Fri Jan 17 07:42:09 2014] simpl in H3 should make progress [Fri Jan 17 07:42:29 2014] nope that doesnt change anything [Fri Jan 17 07:42:31 2014] oh wait [Fri Jan 17 07:42:32 2014] hm [Fri Jan 17 07:42:45 2014] wow [Fri Jan 17 07:42:46 2014] H3 : fterm_v_is_wf (fill x st) /\ list_prop (map fterm_v_is_wf l0) [Fri Jan 17 07:42:51 2014] yep [Fri Jan 17 07:42:51 2014] that actually solves the whole lemma [Fri Jan 17 07:45:13 2014] hm [Fri Jan 17 07:45:19 2014] or maybe not entirely :p [Fri Jan 17 07:45:20 2014] https://privatepaste.com/136708f5c6 [Fri Jan 17 07:45:35 2014] so the first subgoal is in the assumptions [Fri Jan 17 07:45:40 2014] but how to go about the second subgoal there? [Fri Jan 17 07:46:07 2014] im guessing its in H1? [Fri Jan 17 07:52:57 2014] destruct H0 [Fri Jan 17 07:53:18 2014] er [Fri Jan 17 07:53:20 2014] nono [Fri Jan 17 07:53:40 2014] hm! [Fri Jan 17 07:53:52 2014] Step back a bit... [Fri Jan 17 07:54:04 2014] To where you did the decompose record H0 [Fri Jan 17 07:54:12 2014] that far? :p [Fri Jan 17 07:54:15 2014] which assumptions did that generate? [Fri Jan 17 07:54:30 2014] I just want to know where some of the assumptions have gone :) [Fri Jan 17 07:55:17 2014] oh, we have t = fill (Cont f l x l0) st [Fri Jan 17 07:55:23 2014] yea [Fri Jan 17 07:55:25 2014] okay [Fri Jan 17 07:55:31 2014] simpl in that [Fri Jan 17 07:55:39 2014] but how do we rewrite that to x [Fri Jan 17 07:55:41 2014] simpl in H1, specifically :) [Fri Jan 17 07:55:56 2014] did that [Fri Jan 17 07:56:00 2014] gives H1 : t = Fun f (l ++ fill x st :: l0) [Fri Jan 17 07:56:09 2014] its possible to dig it out there as well? [Fri Jan 17 07:56:17 2014] That's bad... [Fri Jan 17 07:56:24 2014] Wait... [Fri Jan 17 07:56:24 2014] thought so :p [Fri Jan 17 07:56:31 2014] (back in 5 mins) [Fri Jan 17 07:56:33 2014] Can you paste your stuff [Fri Jan 17 07:56:38 2014] from the 2/2 [Fri Jan 17 07:56:47 2014] because sometimes the assumptions change1 [Fri Jan 17 07:56:48 2014] ! [Fri Jan 17 08:05:06 2014] sure [Fri Jan 17 08:05:56 2014] https://privatepaste.com/c506643362 [Fri Jan 17 08:11:38 2014] hmm! [Fri Jan 17 08:11:42 2014] How did we get here? [Fri Jan 17 08:11:53 2014] This is clearly false [Fri Jan 17 08:12:48 2014] If we had t = fill x st here [Fri Jan 17 08:13:07 2014] then we'd have t = Fun f (l ++ t :: l0) [Fri Jan 17 08:13:51 2014] Maybe two of our assumptions are contradictory already [Fri Jan 17 08:17:11 2014] :< [Fri Jan 17 08:17:33 2014] (if they are, we're done) [Fri Jan 17 08:17:48 2014] oh really? [Fri Jan 17 08:18:13 2014] yeah, if you can prove a contradiction, you can do anything [Fri Jan 17 08:18:21 2014] well [Fri Jan 17 08:18:49 2014] yea i guess thats a classic proof [Fri Jan 17 08:19:09 2014] It's also intuitionistically valid [Fri Jan 17 08:19:45 2014] Check False_rect. :) [Fri Jan 17 08:20:26 2014] induction on False is very powerful :) [Fri Jan 17 08:21:39 2014] however [Fri Jan 17 08:21:58 2014] Can you determine which step in the proof created this particular goal? [Fri Jan 17 08:22:31 2014] let me see.. [Fri Jan 17 08:22:43 2014] yea [Fri Jan 17 08:22:45 2014] apply IHx [Fri Jan 17 08:23:15 2014] gives https://privatepaste.com/6d2b34d768 [Fri Jan 17 08:23:15 2014] okay, go back there and paste things, and let's see what we can do [Fri Jan 17 08:23:28 2014] what did it look like just before then? [Fri Jan 17 08:23:53 2014] fterm_v_is_wf st [Fri Jan 17 08:30:35 2014] oh wait [Fri Jan 17 08:30:46 2014] We cleared H2 at one point, what was that? [Fri Jan 17 08:30:56 2014] the first half of that conjunction [Fri Jan 17 08:30:59 2014] Was that one of the list_props? [Fri Jan 17 08:31:14 2014] H2 : list_prop (map fterm_v_is_wf l) [Fri Jan 17 08:31:14 2014] H3 : list_prop (map fterm_v_is_wf (fill x st :: l0)) [Fri Jan 17 08:31:19 2014] ah, okay [Fri Jan 17 08:31:23 2014] hmm [Fri Jan 17 08:32:23 2014] What'd things look like just before the induction on x? It's interesting that our induction hypothesis looks like this [Fri Jan 17 08:33:08 2014] https://privatepaste.com/82a2b8c5ce [Fri Jan 17 08:33:26 2014] and then just after? [Fri Jan 17 08:33:49 2014] What's the IHx? Is it the same one? [Fri Jan 17 08:34:34 2014] I'm just confused about why our IHx depends on that equation. [Fri Jan 17 08:35:39 2014] before: https://privatepaste.com/bb25de0b4f [Fri Jan 17 08:35:40 2014] after: https://privatepaste.com/0a3c9cff59 [Fri Jan 17 08:50:39 2014] huh [Fri Jan 17 08:50:46 2014] lemme go look at what context was again [Fri Jan 17 08:51:25 2014] um [Fri Jan 17 08:51:40 2014] Can you Check context_ind. and see what type it has? [Fri Jan 17 08:52:49 2014] context_ind [Fri Jan 17 08:52:49 2014] : forall (Sig : Signature) (P : context Sig -> Prop), [Fri Jan 17 08:52:50 2014] P Hole -> [Fri Jan 17 08:52:50 2014] (forall (f0 : Sig) (l : list (term Sig)) (c : context Sig), [Fri Jan 17 08:52:50 2014] P c -> forall l0 : list (term Sig), P (Cont f0 l c l0)) -> [Fri Jan 17 08:52:50 2014] forall c : context Sig, P c [Fri Jan 17 08:58:07 2014] I don't see any = signs in that [Fri Jan 17 08:58:09 2014] So weird [Fri Jan 17 08:58:39 2014] lol, maybe we should apply context_ind directly! [Fri Jan 17 08:59:00 2014] um where :p [Fri Jan 17 08:59:16 2014] Instead of induction x [Fri Jan 17 09:00:05 2014] oh yea [Fri Jan 17 09:00:08 2014] oh [Fri Jan 17 09:00:08 2014] then Coq says [Fri Jan 17 09:00:09 2014] Error: Unable to find an instance for the variable Sig. [Fri Jan 17 09:00:13 2014] er, right [Fri Jan 17 09:00:23 2014] but um [Fri Jan 17 09:00:24 2014] What's a Sig exactly? [Fri Jan 17 09:00:32 2014] i have a meeting at 3pm [Fri Jan 17 09:00:36 2014] Variable Sig : Signature. [Fri Jan 17 09:00:38 2014] wat [Fri Jan 17 09:00:42 2014] so i guess i should be going [Fri Jan 17 09:00:47 2014] (its 3pm now :p) [Fri Jan 17 09:00:47 2014] okay [Fri Jan 17 09:00:54 2014] Well, good luck with it :) [Fri Jan 17 09:01:03 2014] gotta say lotta thanks for your help man, sorry for my limited input [Fri Jan 17 09:01:11 2014] im back in about 2 hours i think [Fri Jan 17 09:01:11 2014] no problem :) [Fri Jan 17 09:01:13 2014] <3 [Fri Jan 17 11:16:59 2014] Cale, still here? [Fri Jan 17 11:29:12 2014] kinda, I'm playing a game with a friend [Fri Jan 17 11:29:20 2014] :p what are you playing [Fri Jan 17 11:46:05 2014] Cale, could you specify what the contradiction was that weve arrived at earlier? [Fri Jan 17 11:46:58 2014] [t = fill x st] together with [H1 : t = Fun f (l ++ fill x st :: l0)]? [Fri Jan 17 11:47:54 2014] Well, it's just that if t = Fun f (l ++ t :: l0) [Fri Jan 17 11:48:12 2014] then t would have to be an infinite data structure [Fri Jan 17 11:48:13 2014] haha [Fri Jan 17 11:48:14 2014] oh yea [Fri Jan 17 11:48:28 2014] that would be a possibility [Fri Jan 17 11:48:38 2014] but quite possibly not what were after in this instance :p [Fri Jan 17 11:48:55 2014] hm [Fri Jan 17 11:49:11 2014] im kinda sad now cause it felt like we were so close haha [Fri Jan 17 11:52:26 2014] I don't understand the introduction of that equality parameter in the induction hypothesis [Fri Jan 17 11:52:44 2014] The type of induction on contexts doesn't contain any identity types [Fri Jan 17 11:53:11 2014] so it must be coming from the choice of P [Fri Jan 17 11:53:43 2014] Do you know what Sig is? [Fri Jan 17 11:55:21 2014] yea [Fri Jan 17 11:55:40 2014] actually i would just put the whole thing on privatepaste but comments are kinda messy :p [Fri Jan 17 11:56:09 2014] Definition VSig := VSignature.mkSignature fstring_beq_ok. [Fri Jan 17 11:56:16 2014] but thats VSig.. sec [Fri Jan 17 11:56:24 2014] no, that's okay [Fri Jan 17 11:56:28 2014] Sig is a Parameter [Fri Jan 17 11:57:25 2014] color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html [Fri Jan 17 11:58:23 2014] yea its the signature by which those terms are constructed, so basically the arity of f (function/head symbol) and what f looks like (eg. its a string) [Fri Jan 17 11:58:39 2014] http://coq.inria.fr/pylons/contribs/files/CoLoR/v8.4/CoLoR.Term.Varyadic.VSignature.html [Fri Jan 17 11:58:46 2014] http://coq.inria.fr/pylons/contribs/files/CoLoR/v8.4/CoLoR.Term.Varyadic.VTerm.html [Fri Jan 17 11:58:50 2014] http://coq.inria.fr/pylons/contribs/files/CoLoR/v8.4/CoLoR.Term.Varyadic.VContext.html [Fri Jan 17 12:00:13 2014] yep [Fri Jan 17 12:00:29 2014] those are the main elements at play [Fri Jan 17 12:09:28 2014] wtf, how can Coq list a module in Print LoadPath. but not be able to find it? [Fri Jan 17 12:09:38 2014] I'm trying to install CoLoR [Fri Jan 17 12:10:21 2014] haha [Fri Jan 17 12:10:24 2014] did you compile? [Fri Jan 17 12:11:13 2014] ah, that's all it is [Fri Jan 17 12:11:33 2014] (I was expecting it'd just interpret everything :P) [Fri Jan 17 12:12:04 2014] nah [Fri Jan 17 12:12:12 2014] and it takes about 10 minutes too :p [Fri Jan 17 12:13:02 2014] lol, I'm actually getting some use out of the obscene amount of memory I have in this system [Fri Jan 17 12:13:14 2014] Up to 9 GB used :) [Fri Jan 17 12:13:18 2014] :P nice [Fri Jan 17 12:13:38 2014] (of 16) [Fri Jan 17 12:14:09 2014] i remember back when having a 1GB hard drive was a big deal [Fri Jan 17 12:14:50 2014] Oh, the game I was playing with my friend is called Heroes of Umbra. It's a freely available multiplayer action RPG / platformer game in Java. [Fri Jan 17 12:15:12 2014] cool [Fri Jan 17 12:15:35 2014] It's all right, but we're getting to parts that are pretty frustrating now :) [Fri Jan 17 12:15:39 2014] only game i ever play these days is Soul Calibur 5 at work :p [Fri Jan 17 12:16:02 2014] oh its a cooperative rpg? [Fri Jan 17 12:16:03 2014] okay, compiled [Fri Jan 17 12:16:08 2014] yeah [Fri Jan 17 12:16:09 2014] wow that was fast :p [Fri Jan 17 12:20:07 2014] Do you suppose you could paste the bits of your definitions that aren't part of this package? [Fri Jan 17 12:20:08 2014] I want to fiddle with it a bit [Fri Jan 17 12:20:08 2014] (at least, the stuff relevant to this lemma) [Fri Jan 17 12:21:53 2014] sure [Fri Jan 17 12:22:16 2014] let me go over my comments for a bit then ill put it up [Fri Jan 17 12:28:41 2014] I don't need comments :P [Fri Jan 17 12:29:00 2014] Just want the definitions so that I can step over them and try to prove this lemma :) [Fri Jan 17 12:39:15 2014] Cale, this should contain all relevant code https://privatepaste.com/82ac61409c [Fri Jan 17 12:46:27 2014] Oh weird, fstring_beq_ok has a different type here [Fri Jan 17 12:46:49 2014] er, no that's your thing [Fri Jan 17 12:46:51 2014] mkSignature does [Fri Jan 17 12:47:02 2014] ? [Fri Jan 17 12:47:09 2014] Error: The term "fstring_beq_ok" has type [Fri Jan 17 12:47:09 2014] "forall f g : fstring, fstring_beq f g = true <-> f = g" [Fri Jan 17 12:47:09 2014] while it is expected to have type [Fri Jan 17 12:47:09 2014] "forall f g : fstring, {f = g} + {f <> g}". [Fri Jan 17 12:47:37 2014] I can fix it :) [Fri Jan 17 12:47:43 2014] its still weird [Fri Jan 17 12:47:45 2014] why does that happen [Fri Jan 17 12:48:18 2014] Oh, you have eq_fstring_dec [Fri Jan 17 12:49:11 2014] Which version of Coq are you using? I'm on 8.4pl2 [Fri Jan 17 12:49:27 2014] and I downloaded the corresponding CoLoR library for that [Fri Jan 17 12:49:37 2014] yea that might be why [Fri Jan 17 12:49:56 2014] im using Coq 8.4 with CoLoR 130920 [Fri Jan 17 12:50:33 2014] (using that version of Coq because it came with Xubuntu 13.04) [Fri Jan 17 12:52:48 2014] huh, why does it think that term needs to be applied to ASig? [Fri Jan 17 12:53:29 2014] i think ATerm.term is a function taking an ASig [Fri Jan 17 12:53:37 2014] where does it say that [Fri Jan 17 12:54:14 2014] Fixpoint fterm_v_is_wf (ftv : term VSig) : Prop := [Fri Jan 17 12:54:30 2014] Error: The term "VSig" has type "Signature" while it is expected to have type [Fri Jan 17 12:54:33 2014] "ASignature.Signature". [Fri Jan 17 12:54:40 2014] oh [Fri Jan 17 12:54:45 2014] should be VTerm.term [Fri Jan 17 12:54:46 2014] then [Fri Jan 17 12:55:37 2014] actually [Fri Jan 17 12:55:40 2014] t : fterm_v [Fri Jan 17 12:55:42 2014] that would also work [Fri Jan 17 12:57:21 2014] I fixed a bunch of those ambiguities by qualifying some things with VTerm when it complained, and now I'm down to the Lemma we were working on [Fri Jan 17 12:57:22 2014] Lemma t_wf_then_st_wf : forall (t : fterm_v) (st : fterm_v), [Fri Jan 17 12:57:22 2014] fterm_v_is_wf t -> subterm_eq st t -> fterm_v_is_wf st. [Fri Jan 17 12:57:24 2014] It's complaining about the st in subterm_eq st t [Fri Jan 17 12:57:29 2014] The term "st" has type "fterm_v" while it is expected to have type [Fri Jan 17 12:57:29 2014] "term ?695". [Fri Jan 17 12:57:50 2014] Maybe just make those VTerm.terms? [Fri Jan 17 12:58:04 2014] i guess [Fri Jan 17 12:58:07 2014] dunno why its acting up [Fri Jan 17 12:58:29 2014] nope, still complains [Fri Jan 17 12:58:32 2014] did Coq/CoLoR change that much over a couple months? [Fri Jan 17 12:58:46 2014] no idea :) [Fri Jan 17 12:59:04 2014] I also had to change a Vnil to Vector.nil [Fri Jan 17 13:01:02 2014] oh [Fri Jan 17 13:01:02 2014] heh [Fri Jan 17 13:01:48 2014] So I tried commenting out anything from ASignature/ATrs [Fri Jan 17 13:01:53 2014] and now I get [Fri Jan 17 13:02:01 2014] The reference subterm_eq was not found in the current environment. [Fri Jan 17 13:02:04 2014] So that explains something [Fri Jan 17 13:02:10 2014] ah [Fri Jan 17 13:02:16 2014] so were using the wrong subterm_eq [Fri Jan 17 13:04:00 2014] okay, and now I imported CoLoR.Term.Varyadic.VContext and it's good [Fri Jan 17 13:05:21 2014] still quite strange [Fri Jan 17 13:11:33 2014] I might've gotten somewhere. No idea what the heck the induction tactic was doing. [Fri Jan 17 13:12:27 2014] errrr... [Fri Jan 17 13:12:27 2014] heh [Fri Jan 17 13:17:20 2014] "Error: Unable to find an instance for the variable Q." -- nothing called Q anywhere that I can see, great [Fri Jan 17 13:17:34 2014] unfold something? [Fri Jan 17 13:18:05 2014] ah, it's in the parameters to term_ind. [Fri Jan 17 13:39:49 2014] bbl [Fri Jan 17 14:23:29 2014] hi roosbeef [Fri Jan 17 15:00:50 2014] How do I export an Inductive with a Module Type? [Fri Jan 17 15:10:14 2014] Hi, is there a guide to writing new extraction procedures for coq? [Fri Jan 17 15:10:38 2014] I'd like to write a Racket/improved scheme extraction that uses structs instead of tagged lists [Fri Jan 17 15:45:30 2014] maxiepoo: I wouldn't bet on it. I'd totally be on board with a Racket extractor though <3 [Fri Jan 17 15:46:05 2014] ianjneu: do you know how hard it would be? Do you have to patch the compiler or is there some plugin mechanism? [Fri Jan 17 15:46:34 2014] Since you can make racket look arbitrarily close to ocaml, you would think it's not hard at all. [Fri Jan 17 15:46:50 2014] Start with looking at tho ocaml extractor. [Fri Jan 17 15:46:52 2014] the* [Fri Jan 17 15:48:31 2014] whats up Anarchos [Fri Jan 17 15:49:50 2014] roosbeef not so much [Fri Jan 17 15:50:03 2014] roosbeef still confused with set theory and hott, things like that [Fri Jan 17 15:50:16 2014] hmm [Sat Jan 18 04:46:01 2014] morning [Sat Jan 18 07:30:49 2014] hi all. I'm trying to do some algebra stuff(mainly related with relations, groups etc.) in Coq. can anyone help me how can I define something like this in Coq: "xRy in \real if |x| = |y|" , here R is a relation. I want to define this in Coq and later show some properties of this relation, like reflexivity, symmetry and transitivity. [Sat Jan 18 07:50:25 2014] do we have an absolute value function defined for reals in stdlib? [Sat Jan 18 07:59:22 2014] how can I prove x - x = 0 for reals? [Sat Jan 18 08:04:23 2014] what was the command that shows name of a notation? [Sat Jan 18 08:05:34 2014] osa1: Locate "-". [Sat Jan 18 08:05:56 2014] Also, you might find SearchAbout () useful [Sat Jan 18 08:06:06 2014] ahh right. thanks. [Sat Jan 18 08:06:18 2014] jgross: can you help me with proving 0 <= 3 where 0 and 3 are reals? [Sat Jan 18 08:06:53 2014] I've never used real numbers in Coq, but you probably either find a lemma in the stdlib, or you do it by induction. [Sat Jan 18 08:07:15 2014] R is not inductive, I think. [Sat Jan 18 08:07:25 2014] induction x failed with "not inductive product" [Sat Jan 18 08:07:30 2014] where x is R [Sat Jan 18 08:08:48 2014] If the relation isn't inductive, then you should just be able to [compute] or [simpl], and it'll tell you "yes". If it doesn't do that, it's probably because either it's opaque (and then you need lemmas) or it's inductive. [Sat Jan 18 08:11:47 2014] yeah, compute changed the goal but now I'm stuck with 0 < 3 :-) [Sat Jan 18 08:12:01 2014] working with reals turned out to be annoying that I expected [Sat Jan 18 09:26:19 2014] reals look like rather a mess [Sat Jan 18 09:45:22 2014] osa1: hello, 0 and 3 are just natural numbers and there must be a lemma saying that injection of natural numbers into reals is monotonic… [Sat Jan 18 10:54:57 2014] I'm going to rubber-duck to this channel a little bit. [Sat Jan 18 10:55:44 2014] I have a reduction relation that is parameterized by an address allocation strategy. It should be the case that if allocation always produces fresh addresses that the reduction relation is deterministic. [Sat Jan 18 10:57:28 2014] There are three important enviroments: the heap (Address -> set Value), the memo table (Context -> set Result), and the stack segment table (Context -> set Stack_segment). [Sat Jan 18 10:59:27 2014] A Context is a data-structure with enough information about a state such that regardless of the rest of the state components, the "result" of running the filled out state is "the same." Think of a memoized function called in different places. The continuation is different throughout, but you have clear points at which to say that you've reached a "result" [Sat Jan 18 10:59:55 2014] For the CESK machine, the CES components suffice for such a context. [Sat Jan 18 11:00:14 2014] Okay, so, the hard part. [Sat Jan 18 11:00:31 2014] barb: I found injections here http://coq.inria.fr/distrib/current/stdlib/Coq.Reals.RIneq.html but still can't prove 0 < 3 for reals [Sat Jan 18 11:00:41 2014] can you help me with this? [Sat Jan 18 11:01:29 2014] Intuitively, if you are executing from some context, and reach the same context again without memoizing, you will never memoize, since you just called yourself with the exact same arguments. [Sat Jan 18 11:02:13 2014] How might one state, prove, and use such a proposition to prove the overall determinism of such a reduction relation? [Sat Jan 18 11:02:35 2014] I'd expect rewrite H. rewrite Rabs_R0. compute. left. apply lt_INR. [Sat Jan 18 11:02:35 2014] to work but it doesn't [Sat Jan 18 11:04:08 2014] osa1: how are number literals 0 and 3 represented? Is 0%real = INR 0%nat? [Sat Jan 18 11:04:51 2014] ianjneu: I have no ideas how 0 and 3 are represented. [Sat Jan 18 11:05:16 2014] also don't know about second part but I was expecting it to be true [Sat Jan 18 11:05:39 2014] r_syntax_plugin looks to be the place it's all defined. [Sat Jan 18 11:05:54 2014] what's that? [Sat Jan 18 11:07:22 2014] a plugin for understanding better syntax for real number literals, I suppose. [Sat Jan 18 11:14:32 2014] so, 0%R = INR 0 by reflexivity, but reflexivity does not prove 3%R = INR 3. [Sat Jan 18 11:15:25 2014] this is annoying. I can't prove anything on reals. I'm also stuck at 1 + -7 < 0 is False [Sat Jan 18 11:19:50 2014] osa1: Set Printing All, then you can see the uses of Rplus, etc so you can use the associativity axioms to make it all work. I'll pastebin my 0 < 3 solution. You might try Robbert Krebbers' library for real numbers too. [Sat Jan 18 11:20:42 2014] http://pastebin.com/wa0Gh1d8 [Sat Jan 18 11:21:07 2014] WTF?! "Access to the application you were trying to use has been blocked in accordance with company policy. Please contact your system administrator if you believe this is in error." [Sat Jan 18 11:21:22 2014] ianjneu: apparently my access to pastebin is blocked ^^ [Sat Jan 18 11:22:12 2014] http://sprunge.us/ePQD [Sat Jan 18 11:22:21 2014] better? [Sat Jan 18 11:22:26 2014] yup, thanks. [Sat Jan 18 11:22:56 2014] neat. I didn't know assert ... as ... tactic. [Sat Jan 18 11:27:23 2014] http://lpaste.net/98732 [Sat Jan 18 11:27:24 2014] (I copied his paste there) [Sat Jan 18 14:45:18 2014] so im working with this data type, 'terms' [Sat Jan 18 14:45:26 2014] (from the library CoLoR) [Sat Jan 18 14:47:37 2014] now im trying to prove for some property P that, forall terms t: P t -> forall subterms st: P st [Sat Jan 18 14:47:50 2014] using this lemma: http://color.inria.fr/doc/CoLoR.Term.Varyadic.VContext.html#subterm_ind [Sat Jan 18 14:48:30 2014] how do i sculpt my statement such that i can apply that lemma, or is it even the lemma to use for this particular problem? [Sat Jan 18 14:49:07 2014] ive defined the problem as Lemma t_wf_then_st_wf : forall (t : fterm_v), fterm_v_is_wf t -> forall (st : fterm_v), subterm_eq st t -> fterm_v_is_wf st. [Sat Jan 18 14:50:33 2014] but after doing intros, if i apply subterm_ind, variables lose sync (not sure how to say, new variables are introduced) [Sat Jan 18 15:14:47 2014] bbl [Sat Jan 18 21:56:15 2014] is there a way to combine identical subgoals? so given a context with a bunch of subgoals, my desired command would leave a context with one subgoal for each distinct subgoal in the original context, that is, eliminating repeats. [Sat Jan 18 22:50:14 2014] jrw: Maybe in 8.5, but not in 8.4. If "tac" solves the goal, you can do something like "[ abstract tac using bar | ]; exact bar" [Sat Jan 18 22:57:01 2014] jgross: thanks, that's better than nothing :) [Sat Jan 18 22:57:40 2014] jgross: also where can read about changes in 8.5? [Sat Jan 18 23:19:22 2014] jrw: https://github.com/coq/coq/commits, https://github.com/maximedenes/coq-8.5-demo, http://coq.inria.fr/cocorico/CoqDevelopment/CRGTCoq20131126 [Sat Jan 18 23:19:42 2014] jgross: ooo, thanks! [Sun Jan 19 03:38:20 2014] morning [Sun Jan 19 03:48:36 2014] so ive got this state of proof https://privatepaste.com/590be1aafa [Sun Jan 19 03:48:57 2014] then apply this induction lemma http://color.inria.fr/doc/CoLoR.Term.Varyadic.VContext.html#subterm_sub_ind [Sun Jan 19 03:49:58 2014] bringing me to this state of proof https://privatepaste.com/aed92248d2 [Sun Jan 19 03:50:04 2014] but why does it rename the variables [Sun Jan 19 03:51:16 2014] succesfully proving the lemma would require the t in H to be the same as t0 in H0 [Sun Jan 19 03:55:16 2014] or is this sublemma merely an application of the lemma im trying to prove (saying basically that IF the lemma is true then it holds) [Sun Jan 19 15:58:40 2014] I wonder what the reason is for Coq employing a different syntax for giving a function's signature in a definition, and in a type [Sun Jan 19 16:13:37 2014] do you have an example? for me it looks like it's the same [Sun Jan 19 16:20:04 2014] hodapp: Do you mean the option of saying "Definition f x : x = Type := ...", but how you have to say (f : forall x, x = Type) elsewhere? (the reason "f x : x = Type" doesn't work in a type signature is that space means "separator in list of variables of the same type that I'm defining") [Sun Jan 19 16:33:20 2014] ia0: in Haskell, for instance, a definition contains a function signature that is almost identical to how you'd refer to that function's type elsewhere (e.g. Foo :: Float -> Float -> Float) [Sun Jan 19 16:33:52 2014] while (Float -> Float -> Float) is also a valid type, if you had a function which could accept Foo as a parameter [Sun Jan 19 16:34:32 2014] it is the same in Coq [Sun Jan 19 16:34:35 2014] but to steal an example from SF, a definition like: Fixpoint flat_map {X Y:Type} (f:X -> list Y) (l:list X) [Sun Jan 19 16:34:44 2014] has a type of: forall X Y : Type, (X -> list Y) -> list X -> list Y [Sun Jan 19 16:34:45 2014] If you write : Definition myfun : mytype := mycode. [Sun Jan 19 16:35:30 2014] Fixpoint are particular because you have to give at least one argument, but you could write [Sun Jan 19 16:35:33 2014] : [Sun Jan 19 16:36:18 2014] Definition flat_map : forall X Y : Type, (X -> list Y) -> list X -> list Y := fix flat_map X Y f l := [Sun Jan 19 16:36:40 2014] and then tell that X and Y are implicit [Sun Jan 19 16:37:29 2014] Arguments flat_map [X Y] f l. [Sun Jan 19 16:37:37 2014] or something like that, I'm not an expert [Sun Jan 19 16:37:58 2014] The difference between Haskell and Coq is the same as between Haskell and OCaml [Sun Jan 19 16:38:11 2014] in Haskell you write the whole signature at once [Sun Jan 19 16:38:17 2014] myfun :: mysign [Sun Jan 19 16:38:48 2014] in OCaml and Coq, its mixed with the definition of the function [Sun Jan 19 16:39:09 2014] myfun some_args : result_type = mycode [Sun Jan 19 18:59:45 2014] i'm trying to figure out why coq refuses to unify an existential variable (something like "?123") with another named variable that i believe should have the same type. how can i ask coq for the type signature of that existential variable -- the moral equivalent of "Check x"? [Sun Jan 19 19:12:23 2014] IME, life is easier if you prove things in a way that means existentials don't get created [Sun Jan 19 19:13:16 2014] If using coqide, the View menu (e.g. "View/Display all low-level contents") might be helpful [Sun Jan 19 19:18:08 2014] i suppose i will try to go back and see if i can avoid existentials in the first place.. although i'm now quite curious what's going on here. my goal (with "Set Printing All") is nearly trivial: "@eq Mem.mem x1 ?1504", and my only hypothesis is "x1 : Mem.mem". [Sun Jan 19 19:19:13 2014] perhaps one confusing part is that, when i try to "Show Existentials", an extra existential appears that doesn't seem to be in any of my goals.. [Sun Jan 19 19:20:23 2014] .. < Show Existentials. \\ Existential 1 = ?1559 : [x1 : Mem.mem |- @eq Mem.mem x1 ?1504] \\ Existential 2 = ?1504 : [ |- Mem.mem] [Sun Jan 19 19:20:36 2014] what is this ?1559 thing? [Sun Jan 19 19:25:49 2014] is there some analog to prefixing with @ to make all implicit arguments explicit? [Sun Jan 19 19:26:07 2014] disclaimer: I just learned about this on Friday and don't know Coq very well [Sun Jan 19 19:31:59 2014] i thought that's what @ does.. i.e., the type argument to eq is usually implicit, but @eq has an explicit type argument [Sun Jan 19 20:17:07 2014] uucico: Coq represents some goals as existentials, behind the scenes. [Sun Jan 19 20:18:41 2014] What's going on is that x1 was introduced after ?1504 (notice that ?1504 has no hypotheses in context). So you can't instantiate it with x1. Otherwise, you could do something silly, like "Goal exists x : False, forall y, y = x. eexists. intro y. reflexivity." and then you'd have a proof of false. [Sun Jan 19 20:24:49 2014] jgross: ah, that makes sense, thanks! [Sun Jan 19 22:11:54 2014] is software foundations or cpdt more suited for a complete newbie? [Sun Jan 19 22:15:24 2014] starting from nearly zero PL background, i found coq`art to be very approachable, but cpdt was difficult to absorb (and SF was somewhere in the middle). after coq`art, cpdt is much easier to read. [Sun Jan 19 22:18:10 2014] adelbertc: software foundations should be smoother [Sun Jan 19 22:21:48 2014] alright ill try SF first and if that proves to be too difficult ill fall back to coqart [Sun Jan 19 22:21:48 2014] cheers [Mon Jan 20 00:29:50 2014] how does it get determined what variables get newly introduced and what variables get bound? [Mon Jan 20 00:31:50 2014] for example i would like to use this hypothesis H0 : exists C : context VSig, C <> Hole /\ t = fill C st [Mon Jan 20 00:32:28 2014] to prove the subgoals [x <> Hole] and [t = fill x st] [Mon Jan 20 00:33:33 2014] oh wait i guess thats not correct, because that C is not necessarily equal to x :p [Mon Jan 20 00:34:27 2014] ok so nevermind haha [Mon Jan 20 00:34:47 2014] * sip coffee [Mon Jan 20 00:37:47 2014] what if theres an assumption x <> x [Mon Jan 20 00:38:03 2014] that should tick off a subgoal right? But what tactic do i use [Mon Jan 20 08:14:13 2014] anyone familiar with CoLoR? [Mon Jan 20 09:00:07 2014] is it possible to use this Lemma, subterm_sub_ind: http://color.inria.fr/doc/CoLoR.Term.Varyadic.VContext.html#subterm_sub_ind [Mon Jan 20 09:00:56 2014] to prove that, [Mon Jan 20 09:01:58 2014] if we have a property P on terms, such that if for a term t it holds that P t, it also holds that P st for any subterm st, [Mon Jan 20 09:02:41 2014] to prove that if P t, then for all st (subterms of t) it holds that P st [Mon Jan 20 09:02:43 2014] ? [Mon Jan 20 09:09:09 2014] "Sigma P : term -> Prop . forall t, P t -> forall st, subterm st t -> P st" does not have a reverse statement, that is, forall t, P <-> [...]. [Mon Jan 20 09:09:23 2014] P t * [Mon Jan 20 09:11:23 2014] such a reverse statement would be required? [Mon Jan 20 09:12:29 2014] well, can you state your desired proposition formally? [Mon Jan 20 09:12:42 2014] is my type what you're after? [Mon Jan 20 09:13:58 2014] well [Mon Jan 20 09:14:31 2014] i need to be able to infer from [P t] that if [subterm st t] then also [P st] [Mon Jan 20 09:15:13 2014] as an assumption on P [Mon Jan 20 09:15:14 2014] ? [Mon Jan 20 09:15:50 2014] its inherent to P [Mon Jan 20 09:15:59 2014] if thats what you mean by 'an assumpton _on_ P'? [Mon Jan 20 09:16:24 2014] P is a property of wellformedness [Mon Jan 20 09:16:25 2014] excuse me, "of" [Mon Jan 20 09:16:28 2014] kk [Mon Jan 20 09:16:44 2014] if t is well formed, then subterms are also by definition of wellformedness of t [Mon Jan 20 09:19:35 2014] what approach would you suggest id take? It seems like a simple enough lemma to prove but in all honesty im struggling to get at it :/ [Mon Jan 20 09:21:11 2014] so the induction principle subterm_sub_ind is saying that _if_ you can prove wellformedness purely from the wellformedness of all subterms, then all subterms are wellformed. [Mon Jan 20 09:21:29 2014] ok so thats the other direction [Mon Jan 20 09:22:34 2014] guess im confused [Mon Jan 20 09:22:59 2014] then this would be the direction im looking for? Lemma subterm_ind : forall (P : term -> Prop) (IH : forall t, (forall u, subterm u t -> P u) -> P t), forall t, P t. [Mon Jan 20 09:24:17 2014] Your condition on P does not say that you can satisfy IH. It says the opposite of the IH. [Mon Jan 20 09:24:37 2014] forall t, P t -> forall u, subterm u t -> P u [Mon Jan 20 09:24:51 2014] yep [Mon Jan 20 09:25:00 2014] haha [Mon Jan 20 09:25:08 2014] so none of these fit my puzzle [Mon Jan 20 09:25:09 2014] then [Mon Jan 20 09:25:33 2014] So, unless you can use definitional equalities of P to satisfy IH, you're hosed. Purely abstractly, this does not appear to be a theorem. [Mon Jan 20 09:25:46 2014] what?? [Mon Jan 20 09:26:00 2014] does not appear to be a theorem how [Mon Jan 20 09:26:19 2014] it does appear to be correct? [Mon Jan 20 09:28:37 2014] If you have a tree with root node R : term -> term -> term, (say we're looking at R c0 c1) and you know that c0, c1 and all their subterms are well-formed, it's not a guarantee that R c0 c1 is well-formed. You could have a deeper condition on the well-formedness of R nodes, saying that c0 must additionally be depth 4, or whatever. [Mon Jan 20 09:29:38 2014] hm [Mon Jan 20 09:29:58 2014] so the assumption is that the tree [R c0 c1] is wellformed [Mon Jan 20 09:30:31 2014] surely one can infer from this that c0 is wellformed if that is essential to a tree being wellformed (that all its subtrees are also wellformed) [Mon Jan 20 09:31:28 2014] oh, youre describing subterm_ind right [Mon Jan 20 09:31:31 2014] my bad :p [Mon Jan 20 09:31:36 2014] yes, you don't get that R c0 c1 is wellformed when trying to satisfy the IH. Your goal is wellformedness of R c0 c1 given the wellformedness of all its subterms. [Mon Jan 20 09:32:58 2014] so how would one go about proving wf c0 given wf [R c0 c1]? [Mon Jan 20 09:34:05 2014] Unless I know more about wf, that's not necessarily a theorem. [Mon Jan 20 09:35:02 2014] Consider that terms are only well-formed if they're closed. lambda x x is well-formed, but the subterm x is not. [Mon Jan 20 09:36:40 2014] https://privatepaste.com/6c4f8bd873 [Mon Jan 20 09:37:16 2014] (its at the bottom) [Mon Jan 20 09:38:14 2014] I don't know what ATerms and VTerms are. [Mon Jan 20 09:39:03 2014] http://color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html#term [Mon Jan 20 09:39:26 2014] ATerms are not relevant [Mon Jan 20 09:40:08 2014] Ah, so it's like ANF lambda calculus terms. [Mon Jan 20 09:41:03 2014] yep i suppose [Mon Jan 20 09:44:31 2014] I don't know enough about CoLoR to to help much more. It looks like induction on the term itself should suffice, since the wellformedness is so simple. [Mon Jan 20 09:45:00 2014] basic induction? [Mon Jan 20 09:47:35 2014] ya, but I'm not sure how you would construct the context to show that something is a subterm. You'd have to have deeper knowledge about your list_prop thing, that is, what position in the list are you looking at, so you can construct the hole there and fill the left and right sides with the appropriate terms. [Mon Jan 20 09:48:13 2014] brb [Mon Jan 20 09:48:31 2014] We had some rather weird problems the other day where using the induction tactic introduced strange equality requirements on the induction hypothesis [Mon Jan 20 09:48:31 2014] cool thanks for having a look :) [Mon Jan 20 09:48:39 2014] I couldn't figure out where they were coming from. [Mon Jan 20 09:48:47 2014] whats up Cale :0 [Mon Jan 20 09:48:56 2014] (that was using induction on contexts) [Mon Jan 20 09:49:02 2014] not much [Mon Jan 20 09:49:03 2014] yea thats why im unsure about using basic induction [Mon Jan 20 09:55:39 2014] why was that equality requirement so strange though [Mon Jan 20 09:56:58 2014] it merely requires [t = fill x st], right? Where x is a Context in t [Mon Jan 20 09:57:34 2014] or is that not the one you were speaking of [Mon Jan 20 09:59:00 2014] baby duty. Likely will be pretty silent for a while. [Mon Jan 20 10:00:50 2014] haha [Mon Jan 20 11:26:37 2014] Back for a while [Mon Jan 20 11:26:37 2014] . [Mon Jan 20 14:33:56 2014] I'm working through Software Foundations and I want to check one of my freeform answers. The question is in Poly, called baz_num_elts. [Mon Jan 20 14:33:59 2014] My answer: https://github.com/samwgoldman/sf/blob/67a50e9ef9ef8a60c324bfc7099c0694a75ce457/Poly.v#L182 [Mon Jan 20 14:35:06 2014] Can someone here tell me if my answer is wrong? [Mon Jan 20 14:51:15 2014] samg_: I agree with your answer, but why don't you try to prove it? [Mon Jan 20 14:51:23 2014] samg_: Theorem bazEmpty : baz -> False. [Mon Jan 20 14:54:36 2014] Cool idea! [Mon Jan 20 15:14:06 2014] Cale: I think I might need to use a tactic I haven't learned to prove baz -> False. I tried `intros H. induction H.` and then I get stuck. If I try to rewrite using IHbaz, I get "The term provided is not an applied relation" but I'm not sure what that means. [Mon Jan 20 15:14:42 2014] samg_: You can use assumption, because your goal matches one of your hypotheses [Mon Jan 20 15:14:54 2014] Or if you want to be more explicit, you can use apply IHbaz. [Mon Jan 20 15:18:16 2014] Yeah, I haven't covered those tactics yet. I will read up on them. Thanks :) [Mon Jan 20 15:59:44 2014] what tactic do i use to eliminate a subgoal when x <> x is an assumption? [Mon Jan 20 16:00:30 2014] git st [Mon Jan 20 16:00:34 2014] oops :) [Mon Jan 20 16:25:34 2014] roosbeef: "congruence" will do it. if you think that's overkill you can also do something like "exfalso. apply H. reflexivity." where H is the name of the hypothesis x <> x [Mon Jan 20 16:25:56 2014] also "contradiction H" sometimes works [Mon Jan 20 16:32:13 2014] jrw thanks! :) [Mon Jan 20 16:35:28 2014] * is really impressed by the bazillions tactics on coq.... [Mon Jan 20 16:48:41 2014] 'bazillions'? What's that tactic do? [Mon Jan 20 16:49:11 2014] hodapp: suspect whatever it does, it does a lot of it [Mon Jan 20 16:50:26 2014] hodapp i mean there are too much tactics in the standard libs [Mon Jan 20 16:50:35 2014] :) [Mon Jan 20 17:17:16 2014] Why doesn't this work? http://paste.debian.net/77493/ [Mon Jan 20 17:26:14 2014] Don't you have to open the module or something? [Mon Jan 20 17:54:22 2014] ezyang: Ah, yeah, I think I need "Module Export impl : Sig". Thanks! [Mon Jan 20 18:37:45 2014] Is there a convention for the use of simpl before tactics that do a simpl implicitly, like reflexivity? I tend to omit the simpl, but would it be more clear to include it? [Mon Jan 20 22:12:29 2014] must constructors always be disjoint, or can 'inversion' detect whether or not they are? [Tue Jan 21 04:35:52 2014] constructors are always disjoint [Tue Jan 21 04:49:45 2014] whats up guys [Tue Jan 21 04:50:01 2014] so ive got this assumption that is clearly false [Tue Jan 21 04:50:05 2014] H0 : subterm st (Var x) [Tue Jan 21 04:50:25 2014] basically saying "st is a subterm of Variable x" [Tue Jan 21 04:50:39 2014] which is impossible because variables dont have subterms (in this framework) [Tue Jan 21 04:51:00 2014] how do i alude coq to this fact [Tue Jan 21 05:00:07 2014] nevermind, coq has finally agreed with me haha [Tue Jan 21 05:18:15 2014] breakfast brb [Tue Jan 21 07:50:50 2014] ziman: alrighty, good to know. Textbook showed how it was obviously the case with booleans, naturals, and lists, but I wasn't sure if any other possibilities existed. [Tue Jan 21 07:51:15 2014] 'inversion' is a proof technique I've never seen before until now but it looks very powerful [Tue Jan 21 08:04:41 2014] http://lpaste.net/98847 <- you can prove disjointness yourself for any pair of data constructors [Tue Jan 21 08:12:41 2014] hm [Tue Jan 21 08:13:06 2014] so im unfolding this function inside assumption H3 https://privatepaste.com/7f306305cc [Tue Jan 21 08:13:56 2014] a (fix function ...) is revealed, with a case match inside [Tue Jan 21 08:14:15 2014] it has two cases, but one case is covered by another assumption, H2 [Tue Jan 21 08:15:07 2014] how do i make coq realize that c is not Hole if H2 and H3 are congruent, and collapse that function to just the second option? [Tue Jan 21 08:36:52 2014] roosbeef: Of course, because it's a fixed point, you can't *really* remove the Hole case [Tue Jan 21 08:37:23 2014] roosbeef: But maybe there's some way to get Coq to rewrite fix f -> f (fix f) [Tue Jan 21 08:37:31 2014] and then do some reduction [Tue Jan 21 08:38:54 2014] what would you say are the odds [Tue Jan 21 08:39:03 2014] :p [Tue Jan 21 08:40:19 2014] btw found a way to do that induction that seems to work using http://coq.inria.fr/V8.2pl1/contribs/CoLoR.Term.Varyadic.VTerm.html#term_ind_forall [Tue Jan 21 08:48:57 2014] ah, nice [Tue Jan 21 08:49:40 2014] yep [Tue Jan 21 08:50:00 2014] hmm, I think you'll also have a problem even if you get the fixpoint to unfold [Tue Jan 21 08:50:23 2014] hm [Tue Jan 21 08:50:45 2014] Because it's hard to infer from x <> Hole that exists ..., x = Cont f v1 c' v2 [Tue Jan 21 08:51:00 2014] why [Tue Jan 21 08:51:14 2014] Because x <> Hole doesn't tell us which f, v1, c', v2 to use [Tue Jan 21 08:51:29 2014] hm [Tue Jan 21 08:51:38 2014] https://privatepaste.com/1a23ab481d [Tue Jan 21 08:51:47 2014] if we go back a few steps [Tue Jan 21 08:51:57 2014] thats the current status [Tue Jan 21 08:52:11 2014] im pretty sure it should be fairly straight forward to wrap that up [Tue Jan 21 08:52:39 2014] H1 says that st is in v (if st is a subterm in Fun f v, it must be in the argument list v) [Tue Jan 21 08:53:28 2014] H and H0 both say (indirectly) that fterm_v_is_wf v [Tue Jan 21 08:53:39 2014] and so the subgoal must be true [Tue Jan 21 08:53:56 2014] brb meeting with a friend for coffee [Tue Jan 21 08:53:59 2014] <3 [Tue Jan 21 08:54:01 2014] ok [Tue Jan 21 19:20:20 2014] with I could understand what "Error: Statement without assumptions" meant [Tue Jan 21 19:22:03 2014] You're trying to apply some hypothesis that isn't a function. [Tue Jan 21 19:22:03 2014] s/with/wish/ [Tue Jan 21 19:23:51 2014] that isn't a function? I'm not sure what you mean [Tue Jan 21 19:24:50 2014] SF is showing it being used with hypotheses and theorems [Tue Jan 21 19:32:43 2014] you can apply some hypothesis of the form A -> B or forall x, B x, but you can't apply a theorem/hypothesis of something not immediately known to be of that form. [Tue Jan 21 19:36:43 2014] You could also apply a hypothesis whose type is equal to your goal, but that's kind of a base case. [Tue Jan 21 19:42:12 2014] an ad-hoc base case. I use exact in that case by principle. [Tue Jan 21 22:05:48 2014] jgross: nice wishlist :) [Tue Jan 21 22:40:59 2014] http://lpaste.net/98930 - I am not really sure if I overcomplicated this proof or not, given the concepts the book has used so far... would anybody be willing to take a look and see if I missed any obvious, simpler ways to prove that 2nd theorem? [Tue Jan 21 23:56:07 2014] hodapp: Whenever your goal involves an equality between two things which are constructed with distinct constructors, you can use discriminate to get rid of it. [Wed Jan 22 00:13:30 2014] induction n as [| n']; destruct m as [| m']; try (reflexivity || discriminate). -- this would knock off the 3 boring cases for you so that only the interesting one is left. [Wed Jan 22 02:43:39 2014] right [Wed Jan 22 02:43:53 2014] so ive got this assumption with a 'fix f' inside [Wed Jan 22 02:44:02 2014] see H1 in https://privatepaste.com/9db2854eda [Wed Jan 22 02:44:41 2014] ftv should match with the second case so i can unfold 'lforall fterm_v_is_wf args' [Wed Jan 22 02:45:03 2014] how does one handle such 'fix f' inside of assumptions? [Wed Jan 22 06:07:07 2014] is it possible to apply an A -> B -> C lemma using H0 : A and H1 : B? [Wed Jan 22 06:07:18 2014] (adding C as H2 for example) [Wed Jan 22 06:24:56 2014] nevermind :p [Wed Jan 22 08:22:15 2014] pose (H2 := f H0 H1) [Wed Jan 22 08:33:30 2014] ha tx :) [Wed Jan 22 08:38:29 2014] Cale: ahh, I wasn't aware of the 'discriminate' command. The textbook hadn't yet mentioned it. It had mentioned that 'inversion' will get rid of those cases which use different constructors, and I could see clearly how 0 = S (...) is different constructors, but I don't see what other places had different constructors that I could immediately eliminate. [Wed Jan 22 09:08:14 2014] meh [Wed Jan 22 09:08:27 2014] i cant figure out how to perform induction on subterms [Wed Jan 22 09:12:42 2014] got an example to post? I am not tooooo experienced but I can look [Wed Jan 22 09:12:50 2014] sure [Wed Jan 22 09:12:54 2014] do you have CoLoR installed? [Wed Jan 22 09:13:58 2014] ive got all aspects of the proof covered except for the induction [Wed Jan 22 09:33:24 2014] I don't [Wed Jan 22 16:36:32 2014] So, I'm used to the general recursive functions of ACL2 giving rise to induction schemes. I have a function I admitted with Fix, and I'm looking for the way to produce the induction scheme "induced by the structure of the recursive function." [Wed Jan 22 16:39:12 2014] * stares blankly. [Wed Jan 22 16:54:31 2014] figured it out, just have to duplicate proofs (barf). [Wed Jan 22 22:11:44 2014] http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html#lab134 trying to grok this... [Wed Jan 22 22:13:57 2014] So, if I introduce a variable into the context, in effect this is saying 'for some single...' rather than 'for every...'? [Wed Jan 22 22:14:12 2014] is this something rather specific to induction? [Wed Jan 22 23:35:10 2014] whats up guys [Wed Jan 22 23:35:30 2014] ive been kinda struggling with induction over subterms [Wed Jan 22 23:35:48 2014] i think im realizing now where the crux lies [Wed Jan 22 23:36:01 2014] im using CoLoR which is a library on term rewriting [Wed Jan 22 23:36:56 2014] ive figured out all aspects of the lemma im trying to prove except for the induction part [Wed Jan 22 23:38:12 2014] so what i think has happened is the following [Wed Jan 22 23:39:49 2014] heres the proof mode status after having done term_ind_forall https://privatepaste.com/c677508dc1 [Wed Jan 22 23:41:26 2014] you can see from this that the subgoal is true [Wed Jan 22 23:42:52 2014] H0 means that Fun f v is wellformed, which means that any subterms thereof are wf (so anything in v), and x is in v (H1), st is a subterm of x, so the subgoal is true [Wed Jan 22 23:46:07 2014] but in coq [subterm_eq st t] is defined as "t = fill x st", if theres a 'hole' in term t, and youd fill it with st, youd get term t [Wed Jan 22 23:46:38 2014] and so what i think is missing in my proof is induction over that hole, to somehow cover all possible positions of the hole in term t [Wed Jan 22 23:49:45 2014] sooo yea, thats where im stuck, i have tried to just do 'induction x' there, but somehow things dont seem to click into place. Maybe because of the structure of terms/subterms? Im probably overlooking something... anyone? [Thu Jan 23 04:19:03 2014] hi guys, as my undergraduate dissertation I want to mechanize theory of a multi-staged lambda calculus in Coq. I already finished SF book and I want to use definition in that book as a starting point. I was wondering if name binding method used in that book(functions as environments + extensional equality axiom) is good enough for my purposes or do I need to [Thu Jan 23 04:19:03 2014] use some other method? any ideas on that? [Thu Jan 23 04:36:56 2014] what's in a ModuleName.glob file? [Thu Jan 23 06:06:00 2014] can anyone help me with this http://lpaste.net/98984 [Thu Jan 23 06:14:16 2014] never mind guys. I did it with some generalize dependent blah commands. [Thu Jan 23 07:36:37 2014] wpw [Thu Jan 23 07:36:53 2014] wow, (n + 1) this pattern matching on nats worked ... [Thu Jan 23 11:30:38 2014] osa1: I think you will run into a bit of trouble if you try to extend the name binding approach in that book to more complicated systems [Thu Jan 23 11:31:21 2014] It was chosen because it allows SF to side-step the standard bit of machinery around "capture-avoiding substitution" [Thu Jan 23 11:31:25 2014] but it doesn't scale [Thu Jan 23 11:31:34 2014] for a real project, I'd use de Bruijn indices [Thu Jan 23 15:58:47 2014] hello [Thu Jan 23 15:59:20 2014] Aa3ai: welcome [Thu Jan 23 16:05:27 2014] trying to prove beq_nat n m = true -> n = m. [Thu Jan 23 16:07:31 2014] http://lpaste.net/8156929754587463680 but seemingle it gets nowhere... [Thu Jan 23 16:07:36 2014] hints are appreciated [Thu Jan 23 16:10:27 2014] Aa3ai: this is one of the things `inversion` is good for : eliminating cases with impossible hypotheses [Thu Jan 23 16:14:12 2014] ystael: yeah http://lpaste.net/8672537181153132544 but now i'm stuck here, i have a feeling that i started that proof somehow wrong. [Thu Jan 23 16:16:05 2014] sorry if i'm talking nonsense, i'm really not good at coq yet [Thu Jan 23 16:16:39 2014] You're getting somewhere [Thu Jan 23 16:16:44 2014] Aa3ai: you probably need to do something that will discriminate whether m is O or S m' [Thu Jan 23 16:17:24 2014] You did so in the n = O case, but you need to do it also for the n = S n' case [Thu Jan 23 16:18:10 2014] ystael: do you mean, apply induction in n = S n' case? [Thu Jan 23 16:19:12 2014] induction or destruct, yes. If you don't actually need to use an induction hypothesis on m, you can use destruct instead of induction [Thu Jan 23 16:20:14 2014] ystael: got it thanks [Thu Jan 23 16:20:28 2014] np, good luck [Thu Jan 23 16:21:15 2014] he-he, it seems it actually took me to base case but in "S" way. http://lpaste.net/3332770467076374528 [Thu Jan 23 16:22:54 2014] This is a case where you maybe didn't actually want to use induction on m, because it rewrote the inductive hypotheses in a way you don't want [Thu Jan 23 16:24:27 2014] http://lpaste.net/3182305779738738688 gives a bit different result but goal is the same [Thu Jan 23 16:25:52 2014] after "rewrite <- H in IHn." IHn becames "beq_nat n (S m) = beq_nat (S n) (S m) -> n = S m" [Thu Jan 23 16:26:15 2014] it's (beq_nat n (S m) = beq_nat (S n) (S m)) clearly something impossible but i can't use inversion here [Thu Jan 23 16:26:24 2014] because IHn is not inductive [Thu Jan 23 16:27:02 2014] "intros IHn" gives nothing [Thu Jan 23 16:28:31 2014] so does it mean it;s dead end? [Thu Jan 23 16:30:05 2014] Aa3ai: wow, I think you are on the same problem I was on a few days ago... [Thu Jan 23 16:31:02 2014] I solved that one but I did so in a kind of ugly way, I felt [Thu Jan 23 16:31:20 2014] Aa3ai: If the inductive hypothesis is not in the form you want, you may have intro'd too much before inducting [Thu Jan 23 16:32:02 2014] so your inductive theorem on n is too weak -- it's only for a specific m rather than all m [Thu Jan 23 16:33:52 2014] heh, proved by accident http://lpaste.net/6577369537648263168 [Thu Jan 23 16:33:59 2014] I hadn't realized you could just do 'destruct m' and 'induction m', not 'destruct m as ...' or 'induction m as...' [Thu Jan 23 16:34:24 2014] Aa3ai: you working through SF? [Thu Jan 23 16:34:31 2014] hodapp: It's better to use the as-clause because that gives you control over the names of the generated identifiers, which you need for automation [Thu Jan 23 16:34:37 2014] Sooooooo, motives. http://lpaste.net/99003 [Thu Jan 23 16:35:18 2014] hodapp: yep [Thu Jan 23 16:35:27 2014] ystael: the textbook always uses the as-clause, it looks like, so I tended to follow suit [Thu Jan 23 16:35:35 2014] Aa3ai: me too and I think we are at roughly the same point in the book [Thu Jan 23 16:35:43 2014] hodapp: heh [Thu Jan 23 16:35:56 2014] huh, what would it mean to have 'reflexivity' followed by 'exact H'? [Thu Jan 23 16:36:24 2014] my solution at that final case was: intros eq. simpl in eq. apply IHn' in eq. rewrite eq. reflexivity. [Thu Jan 23 16:36:31 2014] it might be redundant or larger than normal [Thu Jan 23 16:36:39 2014] hodapp: i'm not really sure, it's proved by accident, i just followed the coq [Thu Jan 23 16:37:05 2014] ianjneu: wat [Thu Jan 23 16:38:23 2014] apply IHn in H. rewrite H. reflexivity. rewrote it like that [Thu Jan 23 16:38:38 2014] the 'simpl in eq.' in mine is definitely not needed; 'apply' does a 'simpl' first [Thu Jan 23 16:38:50 2014] ystael: ya, exactly. I'm trying to prove that bool is finite (equivalent to fin 2), and I get to a point where I need a fancy motive that for one needs to know that the fin-ness of the discriminee is greater than 0 (which it always is) [Thu Jan 23 16:38:50 2014] which makes mine basically identical to yours [Thu Jan 23 16:39:07 2014] ystael: so how one should determine what to intro and what to not? [Thu Jan 23 16:39:17 2014] ystael: this is a trimmed down version that still overflows. [Thu Jan 23 16:39:31 2014] Aa3ai: the chapter you're on, shortly after that problem, goes into a bit of detail on this [Thu Jan 23 16:39:37 2014] ianjneu: I guess it seems a little weird that the O case of your dependent return type is a function yielding False : Prop, but the S n' case yields Prop instead of True : Prop ? [Thu Jan 23 16:39:42 2014] bit tjat [Thu Jan 23 16:39:48 2014] but that's just what my eyeballs trip over [Thu Jan 23 16:40:31 2014] oh, you're right that's off, but even fixing that, it overflows. [Thu Jan 23 16:41:37 2014] Aa3ai: Practice. The general instinct is as I said though -- if your inductive hypothesis is too weak to prove what you want, you can strengthen it by trying to inductively prove a stronger thing, which often means generalizing over more variables [Thu Jan 23 16:42:04 2014] ystael: That makes sense, thank you! [Thu Jan 23 16:44:32 2014] ianjneu: It doesn't overflow for me in stock Coq 8.4pl2 [Thu Jan 23 16:44:48 2014] do you guys belive that theorem proving using martin lof type theory will ever succeed over what we have in coq? [Thu Jan 23 16:44:54 2014] what we have in coq btw? [Thu Jan 23 16:45:06 2014] ianjneu: Eval compute in why_overflow F1 is perfectly happy to yield I: True [Thu Jan 23 16:46:44 2014] you know there are agda theorem provers based on martin lof type theory but frankly i don't find it more usable for theorem proving than coq [Thu Jan 23 16:47:04 2014] Aa3ai: Before I started working through the homotopy type theory book, I was working through SF simultaneously in Coq and Agda [Thu Jan 23 16:47:15 2014] I got up to a point just a little farther than you are now [Thu Jan 23 16:47:24 2014] ystael: with agda? [Thu Jan 23 16:47:36 2014] With both. Some things are easier in Coq, some things are easier in Agda. [Thu Jan 23 16:48:13 2014] I've heard many people say that Agda becomes unreasonably difficult for large developments because of the lack of tactics; I don't have the experience to say, myself. [Thu Jan 23 16:48:14 2014] ystael i wonder why they don't release a verifier program with the homotopy type theory book !! [Thu Jan 23 16:48:31 2014] uh, github.com/HoTT/coq ? [Thu Jan 23 16:49:23 2014] ystael it is for coq, but reading the book it looks that they have all in the annexes to write a (possibly) more powerful tool [Thu Jan 23 16:49:41 2014] i tried agda on SF but it was so much harder to do in agda so i dropped it for time being, it feels a bit more natural to prove in coq and so hard to wrap my head around the way agda suggests to prove things [Thu Jan 23 16:50:09 2014] Anarchos: as I understand it, it is not yet clear (to researchers in the field) what the computational interpretation of HoTT constructs should even be [Thu Jan 23 16:50:36 2014] i guess i'm having huge gap in my knowlege somewhere that it makes agda so hard and coq so easy [Thu Jan 23 16:50:38 2014] ystael i am aware of that point. But the annex 2 is really astonishing [Thu Jan 23 16:50:41 2014] Aa3ai: if you're curious, you can look at my exercises repo: https://github.com/ystael/sf [Thu Jan 23 16:50:51 2014] ystael: cool, thanks [Thu Jan 23 16:51:25 2014] i wonder what should i study to be able to get basic intuition on how to prove in agda... [Thu Jan 23 16:51:25 2014] Aa3ai: I won't lie, there have been several points so far where I wanted to punch the Agda pattern matching engine in its stupid face [Thu Jan 23 16:51:48 2014] There is apparently a computational interpretation now! [Thu Jan 23 16:52:12 2014] https://github.com/simhu/cubical [Thu Jan 23 16:52:29 2014] ystael: ha-ha [Thu Jan 23 16:52:51 2014] Aa3ai: Ulf Norell's agda tutorial PDF was a big help [Thu Jan 23 16:52:55 2014] Cale: UA, yes. HITs, no. [Thu Jan 23 16:53:00 2014] even though the names of all the library primitives have changed since then [Thu Jan 23 16:53:51 2014] ystael: http://www.cse.chalmers.se/~ulfn/papers/afp08/tutorial.pdf that one? [Thu Jan 23 16:53:55 2014] yep [Thu Jan 23 16:54:01 2014] ystael: great, thanks once again [Thu Jan 23 16:54:13 2014] np, also I learned a bunch from Saizan and some other people on #agda [Thu Jan 23 16:55:33 2014] ianjneu: well, yeah :) [Thu Jan 23 16:55:39 2014] ystael: I have 8.4pl2 as well. [Thu Jan 23 16:55:58 2014] ianjneu: hm, I don't know why it barfs for you and not for me then [Thu Jan 23 16:56:11 2014] Though are there actual fundamental difficulties with HITs? [Thu Jan 23 16:56:17 2014] All I did was paste your code (with the Prop => True correction) into a fresh buffer and evaluate it [Thu Jan 23 16:56:48 2014] oh, oh, wait, I lied, I have 8.4pl1 [Thu Jan 23 16:57:22 2014] pl2 is on my other machine [Thu Jan 23 16:57:47 2014] ystael: okay, so it's clearly a bug and not me being a nob. [Thu Jan 23 16:58:04 2014] seems like it, yeah [Thu Jan 23 17:01:37 2014] why can't it be both? ;) [Thu Jan 23 17:02:35 2014] hodapp: you're not distinguished enough here to suggest such a notion. [Thu Jan 23 17:02:52 2014] but ya, it's definitely both. [Thu Jan 23 17:03:17 2014] pffffft. [Thu Jan 23 17:04:24 2014] I don't know the unicode for sarcasteses. [Thu Jan 23 17:05:01 2014] sarcastises* (still a neologism) [Thu Jan 23 17:07:15 2014] Agda's on my list of things to learn, but it'll be down the road somewhere. [Thu Jan 23 17:07:20 2014] hopefully knowing some Haskell will help. [Thu Jan 23 17:10:15 2014] ehh, it's very different. [Thu Jan 23 17:12:19 2014] I thought I'd read that it had some similarities, in terms of appearance if nothing else [Thu Jan 23 17:15:58 2014] I sort of discovered that I already "knew" how to write Coq code, or at least, that I could be successful in getting the typechecker to accept things by mashing on my keyboard until the proofs were done :) [Thu Jan 23 17:16:13 2014] it has annoying pattern matching and an oppressive type checker, so ya, in some ways like Haskell. [Thu Jan 23 17:16:23 2014] Cale: that's how I defeat the C++ type checks. [Thu Jan 23 17:16:27 2014] ianjneu :) [Thu Jan 23 17:17:04 2014] It's kind of just like Haskell with fancier types and some MLish syntax here and there, and then there's the whole tactics thing. [Thu Jan 23 17:18:15 2014] Cale: motives, strict positivity, and strong normalization are the big differences. [Thu Jan 23 17:19:51 2014] Well, strong normalisation doesn't seem to require much in the way of learning. I can't say much about the other two (what are motives?). I suppose you do need to be aware about the structural conditions on recursion in various situations. [Thu Jan 23 17:21:17 2014] motives are the type families you inhabit with dependent eliminators. In Coq, they're the types given in the "return" part of the match form. [Thu Jan 23 17:21:42 2014] Oh, okay [Thu Jan 23 17:23:08 2014] ianjneu: I don't suppose "motives" in this sense is related to motivic cohomology? [Thu Jan 23 17:23:31 2014] * . o O ( is that a term ystael just completely made up? ) [Thu Jan 23 17:23:40 2014] It's not :) [Thu Jan 23 17:23:52 2014] (and I don't think so) [Thu Jan 23 17:24:05 2014] http://en.wikipedia.org/wiki/Motivic_cohomology [Thu Jan 23 17:24:07 2014] I'll pair those answers up however I like... [Thu Jan 23 17:24:34 2014] man, Grothendieck was the man. [Thu Jan 23 17:24:42 2014] Still is, as far as I know :) [Thu Jan 23 17:25:07 2014] He could be dead on a mountainside for all anyone knows. [Thu Jan 23 17:25:11 2014] yeah [Thu Jan 23 17:25:31 2014] I wonder how many more years it will take us to get to the end of "what Grothendieck was thinking" though [Thu Jan 23 17:27:06 2014] Bourbaki are a bunch of bastards, the math world has gone to hell, the good old days are long gone. [Thu Jan 23 17:27:35 2014] and fuck anyone who profits from my work [Thu Jan 23 17:27:47 2014] wat [Thu Jan 23 17:27:50 2014] wat [Thu Jan 23 17:28:37 2014] Y'all don't know your math history? [Thu Jan 23 17:28:44 2014] Get with it. [Thu Jan 23 17:28:51 2014] my degree is in electrical engineering. [Thu Jan 23 17:29:01 2014] My degree is in computer science. [Thu Jan 23 17:29:03 2014] I don't understand what you're referring to by "the good old days" [Thu Jan 23 17:29:14 2014] I might do a graduate degree in Comp Sci. I dunno. [Thu Jan 23 17:29:22 2014] or in saying that the math world has gone to hell [Thu Jan 23 17:29:39 2014] It seems as good as it's ever been to me. [Thu Jan 23 17:29:54 2014] Cale without grothendieck there should be no topos, no coq, and no hott :) [Thu Jan 23 17:29:54 2014] Cale: he was a prominent member of Bourbaki, and new blood came in and changed the group's direction in ways he vehemently disagreed with. [Thu Jan 23 17:30:19 2014] Oh, you're referring to Grothendieck specifically [Thu Jan 23 17:30:22 2014] * wanders off to the gym [Thu Jan 23 17:30:24 2014] ya [Thu Jan 23 17:30:44 2014] my works were conjectures of "what Grothendieck was thinking" [Thu Jan 23 17:30:47 2014] words* [Thu Jan 23 17:32:47 2014] It's not like the stuff he did has stopped existing or that people have stopped working on it though. [Thu Jan 23 17:33:28 2014] Oh, I see what you mean, you were speaking as if you were Grothendieck :) [Thu Jan 23 17:35:52 2014] Yeah, he sort of went nuts as I recall, trying to claw back everything he'd ever written. [Thu Jan 23 17:36:41 2014] Cale i find it very sane of him trying to forbid french government to takeover his work [Thu Jan 23 17:39:24 2014] Anarchos: Well, he apparently requested that libraries with copies of his work remove them and such [Thu Jan 23 17:39:42 2014] Which seems a little extreme [Thu Jan 23 17:39:47 2014] Cale copies of his manuscript works, not the book if i remember [Thu Jan 23 17:40:09 2014] anyway he is a genius and i find that astonishing the work he achieved [Thu Jan 23 17:53:15 2014] bah, bug persists in pl3. [Thu Jan 23 18:06:44 2014] even smaller. http://lpaste.net/99013 [Thu Jan 23 18:07:38 2014] wat the what wat [Thu Jan 23 18:20:06 2014] ianjneu: what's wrong with that? If it doesn't work, then my answer is "Coq isn't always great at inferring 'return' arguments", and if it does, my answer is "Coq has recently gotten a lot better at inferring 'return' arguments." Try "Set Printing All." and print out the term? [Thu Jan 23 18:24:47 2014] Oh, I missed the title on the lpaste. Anyway, Matthieu has answered on coq-club. [Thu Jan 23 18:35:10 2014] ianjneu: Type inference is done from left to right, so it doesn't know it's looking for [return (n = n -> nat)], and loops on trying to infer the return clause. If you replace [end)] with [end : n = n -> nat)], it compiles fine. [Thu Jan 23 23:05:58 2014] jgross: thanks [Fri Jan 24 04:53:06 2014] so im working with CoLoR (lib on term rewriting) [Fri Jan 24 04:54:07 2014] im trying to prove that, given P t, forall st (subterm of t) P st [Fri Jan 24 04:54:23 2014] its inherent to P that if P holds for t it holds for all subterms of t [Fri Jan 24 04:54:53 2014] eg. https://privatepaste.com/3f640c9953 [Fri Jan 24 04:55:26 2014] the subgoal follows from H2, H1 and H0 [Fri Jan 24 04:58:46 2014] but i cant find an induction method in the library that would tie these together [Fri Jan 24 05:01:28 2014] what do i do? Ive tried many things that didnt work but im pretty certain this should not be too difficult [Fri Jan 24 07:33:30 2014] brb [Fri Jan 24 10:20:48 2014] roosbeef: if I were you, I'd try changing your P to be something as simple as possible and then try some of the induction schemes to see how they work in the simple case. [Fri Jan 24 10:22:23 2014] ianjneu: ??!!. Does it still overflow if you eta-expand the match and extract it as a separate definition? [Fri Jan 24 10:42:39 2014] ystael: From coq-club, I just need to give a more specific return clause. [Fri Jan 24 10:55:36 2014] so id like to assert (st = (Fun f v) \/ st <> (Fun f v)). [Fri Jan 24 10:57:06 2014] how do i use term_eq_dec to prove this? (From color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html) [Fri Jan 24 11:00:48 2014] term_eq_dec (Fun f v) : forall u : term, {Fun f v = u} + {Fun f v <> u} [Fri Jan 24 11:01:27 2014] oh, or st is a specific term, so you probably want to apply that one first to have them in the order you were looking for [Fri Jan 24 11:01:41 2014] term_eq_dec st (Fun f v) : {st = Fun f v} + {st <> Fun f v} [Fri Jan 24 11:01:51 2014] ianjneu: i still don't understand how to write return annotations for dependent matches :| [Fri Jan 24 11:02:21 2014] Cale, yea its a specific term :p [Fri Jan 24 11:03:20 2014] Cale, so what exactly is that? A Lemma? An application of term_eq_dec? [Fri Jan 24 11:03:41 2014] application [Fri Jan 24 11:12:02 2014] hm [Fri Jan 24 11:12:06 2014] given this status https://privatepaste.com/036c94064c [Fri Jan 24 11:12:33 2014] how do i say "x cannot be Hole, because if it were Hole, then H0 would be false" [Fri Jan 24 11:12:55 2014] (since fill Hole z = z) [Fri Jan 24 11:14:05 2014] What happens if you do intros? [Fri Jan 24 11:15:45 2014] oh, you might have to unfold not. [Fri Jan 24 11:16:13 2014] Sometimes I don't really understand why things like that don't happen automatically :P [Fri Jan 24 11:17:19 2014] x <> Hole is the same thing as (x = Hole) -> False [Fri Jan 24 11:18:08 2014] But it's *really* the same thing as not (x = Hole) and for whatever reason, that doesn't expand to (x = Hole) -> False on its own. [Fri Jan 24 11:19:14 2014] ok that problem is solved :) [Fri Jan 24 11:19:32 2014] but what did you mean by term_eq_dec st (Fun f v) : {st = Fun f v} + {st <> Fun f v} [Fri Jan 24 11:19:45 2014] how do i apply that [Fri Jan 24 11:19:45 2014] I mean, that's a term of the type you were asking for [Fri Jan 24 11:19:53 2014] apply (term_eq_dec st (Fun f v)) [Fri Jan 24 11:20:06 2014] or perhaps [Fri Jan 24 11:20:13 2014] pose (G := term_eq_dec st (Fun f v)) [Fri Jan 24 11:20:24 2014] Depending on how you wanted to use it [Fri Jan 24 11:20:42 2014] Error: Impossible to unify "{st = Fun f v} + {st <> Fun f v}" with "st = Fun f v \/ st <> Fun f v". [Fri Jan 24 11:20:46 2014] oh, right [Fri Jan 24 11:21:00 2014] yea thats the root issue i guess :p [Fri Jan 24 11:21:02 2014] It's this silly Prop/Type thing, there are many definitions of "or" [Fri Jan 24 11:21:08 2014] Definition sumbool_to_or {A B} (p : { A } + { B }) : A \/ B. [Fri Jan 24 11:21:08 2014] induction p. [Fri Jan 24 11:21:09 2014] apply (or_introl a). [Fri Jan 24 11:21:09 2014] apply (or_intror b). [Fri Jan 24 11:21:09 2014] Defined. [Fri Jan 24 11:22:15 2014] Of course, you could also just inline that reasoning by doing induction (term_eq_dec st (Fun f v)) [Fri Jan 24 11:23:16 2014] ha perfect [Fri Jan 24 11:23:18 2014] ill do that [Fri Jan 24 11:23:30 2014] i find that to be more elegant as well [Fri Jan 24 11:23:36 2014] thanks vm :) [Fri Jan 24 11:24:31 2014] I should really try to understand what Prop is good for. [Fri Jan 24 11:25:32 2014] maybe its a very elaborate practical joke [Fri Jan 24 11:25:47 2014] j/k that would be cool though [Fri Jan 24 11:26:24 2014] I mean, sure, it means you can prove forall P Q : Prop, P \/ Q -> Q \/ P and have that itself be a Prop [Fri Jan 24 11:26:36 2014] Without going up a universe level [Fri Jan 24 11:27:02 2014] But what does that really do for you in practical terms? Why does it *matter* that it doesn't land in another universe? [Fri Jan 24 11:28:26 2014] (and is it really worth duplicating *everything* for Prop and Type and every possible combination of the two?) [Fri Jan 24 11:31:11 2014] No more subgoals. [Fri Jan 24 11:31:12 2014] I'd love to see someone more experienced come up with an example where you'd just get stuck, or be forced into a really awkward position without Prop's impredicativity. [Fri Jan 24 11:31:18 2014] * runs around hysterically [Fri Jan 24 11:31:27 2014] Congrats! [Fri Jan 24 11:31:31 2014] :D [Fri Jan 24 11:33:18 2014] thanks again for helping out Cale [Fri Jan 24 11:33:24 2014] No problem :) [Fri Jan 24 11:33:33 2014] im gonna call it a day haha [Fri Jan 24 11:33:54 2014] been hammering at this lemma for WEEKS literally hahaha [Fri Jan 24 11:34:10 2014] Paste the final result? [Fri Jan 24 11:34:15 2014] sure [Fri Jan 24 11:34:33 2014] This is the "all subterms of a WF term are themselves WF" thing? [Fri Jan 24 11:34:46 2014] yep [Fri Jan 24 11:34:51 2014] https://privatepaste.com/3c9bd0c85a [Fri Jan 24 11:37:19 2014] hm [Fri Jan 24 11:37:26 2014] wf_t_then_wf_st is redundant, that was just a simplified version to practice on [Fri Jan 24 11:40:47 2014] aaaaanyway [Fri Jan 24 11:40:50 2014] im out [Fri Jan 24 11:40:51 2014] ttyl :) [Fri Jan 24 11:43:54 2014] ystael: it's tricky. [Fri Jan 24 11:56:51 2014] ianjneu: Maybe you know why Prop is important? [Fri Jan 24 11:57:18 2014] I don't understand what makes impredicativity really nice. [Fri Jan 24 11:57:33 2014] (So much so that it's worth duplicating so much functionality) [Fri Jan 24 12:47:03 2014] Cale: I believe the person who knows best about the merits of impredicativity is Thorsten Altenkirch. I can't readily find the materials I've read before by him that spell out those merits, however. [Fri Jan 24 12:47:53 2014] Thanks for the pointer [Fri Jan 24 14:46:08 2014] gah, so many publications on, "hey, look what I proved in Coq!" with broken links to the scripts or none at all. I don't want to reprove Kleene's fixed point theorem! Graaaah [Fri Jan 24 14:47:08 2014] ianjneu: if github ever goes under we're gonna have a bad time [Fri Jan 24 15:00:40 2014] ystael: dunno about you, but I have local copies of my repos. [Fri Jan 24 15:02:56 2014] ianjneu: yeah, but it's going to make finding other people's code even more challenging [Fri Jan 24 15:13:18 2014] ystael: one of my co-authors uses a private svn server. It's terribel. [Fri Jan 24 15:13:20 2014] tirrebl [Fri Jan 24 15:13:31 2014] can't even spell correctly the rage is so much. [Fri Jan 24 15:13:59 2014] ianjneu: There was some project to use VMs to ensure that things like that wouldn't bitrot [Fri Jan 24 15:14:30 2014] Of course, if the links are just completely dead, that wouldn't help [Fri Jan 24 15:34:29 2014] Ya... [Fri Jan 24 16:31:16 2014] why doesn't Definition is_true b := b = true. Coercion is_true : bool >-> Prop. work? [Fri Jan 24 16:31:52 2014] it yells about class_rawexpr not following >->, but the docs do this exact thing. [Fri Jan 24 16:36:25 2014] Coercion is_true := (fun b => b = true). works, however. Fine. Whatever. [Fri Jan 24 16:51:23 2014] I believe you mean "Sortclass", not "Prop"? [Fri Jan 24 17:05:09 2014] jgross: If that's what I should mean, then the docs are wrong. [Fri Jan 24 17:25:22 2014] Which docs are you talking about? http://coq.inria.fr/refman/Reference-Manual021.html#sec647 doesn't allow target classes unless they're Sortclass, Funclass, or user-defined. [Fri Jan 24 17:27:14 2014] jgross: http://coq.inria.fr/library/Coq.Init.Datatypes.html [Fri Jan 24 17:29:33 2014] Yeah, that's wrong. Do you want to report it/submit a patch, or shall I? [Fri Jan 24 17:31:32 2014] I'll go submit a patch on github now, unless you want to. [Fri Jan 24 17:33:49 2014] go for it. [Fri Jan 24 17:39:07 2014] https://github.com/coq/coq/pull/8 [Fri Jan 24 20:07:54 2014] woo, 4 nested fold_lefts. Let's see how fun that one will be to prove things about ^_^;; [Fri Jan 24 20:44:30 2014] fold lefts are the evil [Fri Jan 24 20:44:40 2014] *devil [Fri Jan 24 20:51:27 2014] Saizan: they're also stack-efficient. [Fri Jan 24 23:27:19 2014] http://lpaste.net/6302811051717033984 - as soon as it hits 'rewrite snoc_simpl.' it adds a new subgoal simply called 'nat', and I don't understand what's going on here [Fri Jan 24 23:28:21 2014] I've some idea that it pertains to some quantified variable I've pulled into the context when I shouldn't have, or vice versa, or something... [Fri Jan 24 23:32:41 2014] ...nevermind. I was about to get ready for bed and realized that I did not even make use of an 'n' in the lemma [Sat Jan 25 12:31:59 2014] ianjneu: I do use it, but the proof looks clumsy nevertheless http://lpaste.net/2039702891110858752 [Sat Jan 25 12:32:18 2014] Doesn't work without all the assetions. [Sat Jan 25 12:34:18 2014] wow, solved app_length_cons 3 star exercise by my own [Sat Jan 25 12:34:21 2014] good [Sat Jan 25 12:35:39 2014] notdan: the first assert is essentially a motive for equality induction, so I'm not surprised that's there. The second, however, I would have thought etas would simpl away. I might be mistaken. [Sat Jan 25 12:39:32 2014] nah, I tried simpl before :( [Sat Jan 25 12:39:50 2014] strangely, a similar goal does not require the first assertion at all! [Sat Jan 25 12:40:20 2014] "f >=> return = f' requires it, "return >=> f = f" does not [Sat Jan 25 12:40:35 2014] man, porting this proof to arbitrary categories via setoids will be a nightmare [Sat Jan 25 12:47:28 2014] notdan: Why via setoids? Also, which proof is this? [Sat Jan 25 12:50:24 2014] jgross: because I still haven't read your draft, cos I'm a dummy :D [Sat Jan 25 12:50:27 2014] this proof: http://repos.covariant.me/browse?r=coq;a=headblob;f=/Rep.v [Sat Jan 25 12:50:42 2014] I am trying to prove that representable endofunctors are monads [Sat Jan 25 12:50:57 2014] Proved it on paper via equational reasoning [Sat Jan 25 12:53:25 2014] Which version of Coq are you using? Eta for functions is judgmental in 8.4. [Sat Jan 25 12:53:48 2014] The Coq Proof Assistant, version 8.4 (September 2012) [Sat Jan 25 12:53:48 2014] compiled on Sep 25 2012 15:01:39 with OCaml 3.12.1 [Sat Jan 25 12:54:15 2014] I am sorry, I don't know what does 'judgmental' mean in this context [Sat Jan 25 12:55:26 2014] It means you can replace "apply eta_expansion." with "reflexivity" [Sat Jan 25 12:55:58 2014] omg, proved app_length_twice 4 star exercise without anyone's help at all. i gues i'm doing progress. [Sat Jan 25 12:58:24 2014] jgross: what if I want to apply eta_expansion to some subterm? [Sat Jan 25 13:00:03 2014] change (fun a => ?f a) with f. (Or replace "f" and "?f" with the constant if you don't want to eta-reduce all of the terms.) [Sat Jan 25 13:03:17 2014] Oh, change .. with .. does work [Sat Jan 25 13:03:20 2014] thank you! [Sat Jan 25 13:07:51 2014] But your proof is not that complicated, and probably will not be any harder for arbitrary categories; most of what's annoying is that category composition is turning into function application, and that's obscuring the proofs. I wouldn't be surprised if things get easier in category-land. Also, here's a tactic that solves all of your obligations: repeat first [ intro | reflexivity | apply [Sat Jan 25 13:07:51 2014] functional_extensionality_dep | rewrite ab_iso1 | rewrite ab_iso2 | rewrite <- ab_iso1; apply f_equal | rewrite <- ab_iso2; apply f_equal ]. [Sat Jan 25 13:13:56 2014] Arghh, How do you do this [Sat Jan 25 13:13:57 2014] and so fast [Sat Jan 25 13:14:04 2014] thanks a lot jgross [Sat Jan 25 13:15:29 2014] Ah, rewrite <- ab_iso2; is like applying beta to both sides [Sat Jan 25 13:15:31 2014] that's smart! [Sat Jan 25 13:22:34 2014] hodapp: ping [Sat Jan 25 13:23:12 2014] pong [Sat Jan 25 13:23:19 2014] http://lpaste.net/9217258726434537472 sorry, having troubles with that one, looks complicated. hints appreciated. [Sat Jan 25 13:23:39 2014] I don't know that I'm that far yet in the book [Sat Jan 25 13:24:08 2014] you're a few questions ahead [Sat Jan 25 13:24:13 2014] ah, okay. :) [Sat Jan 25 13:24:19 2014] but I may get to it soon [Sat Jan 25 13:30:04 2014] notdan: I have experience with the kinds of tricks you want for automating category theory proofs without depending on asserting things in the middle, e.g., how to turn forward reasoning into backward reasoning, and similar. [Sat Jan 25 14:08:10 2014] is there a way to use "eqn:" without having to specify name by hand? [Sat Jan 25 14:08:15 2014] autogenerated are fine too [Sat Jan 25 14:09:22 2014] A3mr: does "eqn:?" do what you want? [Sat Jan 25 14:15:31 2014] jrw: destruct on compuond exressions. like destruct (f (f x)) eqn:ffx [Sat Jan 25 14:17:22 2014] http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html#lab142 [Sat Jan 25 14:55:30 2014] for example now i'm stuck here http://lpaste.net/4473325021376282624 (uses eqn a lot) [Sat Jan 25 14:59:57 2014] hint appreciated as always. :) [Sat Jan 25 15:13:07 2014] what is the difference between apply and rewrite? [Sat Jan 25 15:27:39 2014] if you have an equation (H1 = H2) you can rewrite using it, to replace occurrence of H1 with H2. Apply is a function/proof application and it works if you have a premise of the form (A -> B), and goal B [Sat Jan 25 15:32:27 2014] notdan: gotcha [Sat Jan 25 15:34:06 2014] but why for example appy doesn't work if i have theorem "beq_nat_true: forall n m : nat, beq_nat n m = true -> n = m" and goal " beq_nat m m = true"? [Sat Jan 25 15:34:24 2014] "apply beq_nat_true." => "Error: Impossible to unify "?2893 = ?2894" with "beq_nat m m = true"." [Sat Jan 25 15:40:49 2014] A3mr: you want a therem that states the dual thing: n = m -> beq_nat n m = true [Sat Jan 25 15:40:59 2014] (in this case you can probably just unfold & simpl) [Sat Jan 25 15:41:30 2014] For apply to work you need to have a premise (A->B) and a goal B. [Sat Jan 25 15:41:56 2014] Informally, you know that from A you can prove B, and you want to prove be; therefore, you decide to prove A [Sat Jan 25 15:42:06 2014] and by proving A you can get B [Sat Jan 25 15:45:31 2014] notdan: so in my case m = m was not proven? [Sat Jan 25 15:55:58 2014] * dumb [Sun Jan 26 00:09:34 2014] gah. app_length_twice is throwing me for a loop... [Sun Jan 26 00:16:52 2014] Hey guys, have you guys heard of the new proofmarket website? [Sun Jan 26 00:16:53 2014] https://proofmarket.org/problem [Sun Jan 26 00:17:07 2014] One of the open problems in particular seems interesting [Sun Jan 26 00:17:58 2014] https://proofmarket.org/problem/view/13 [Sun Jan 26 00:18:48 2014] after glancing over the paper in the problem's description, it's not at all obvious that traceL == traceR [Sun Jan 26 00:19:09 2014] the prize for a solution is a cool $45 [Sun Jan 26 05:00:14 2014] how do i make coq remember where a variable came from [Sun Jan 26 05:00:53 2014] eg. https://privatepaste.com/ebca4a98bf [Sun Jan 26 05:01:04 2014] im doing a case match on x [Sun Jan 26 05:01:35 2014] in the second case, id like to be able to refer to args_v as belonging to x somehow [Sun Jan 26 05:08:27 2014] so how do i get something in the assumptions like H1 : x = VTerm.Fun head_v args_v [Sun Jan 26 07:35:38 2014] roosbeef: the convoy pattern. (match e with pat => (fun H : e = pat => body) ... end (eq_refl e)) [Sun Jan 26 07:37:24 2014] sometime you have to give the proper return statement so that the unification engine doesn't stack overflow, as I recently found out. match e as x return (e = x -> _) pat => [...] [Sun Jan 26 07:48:13 2014] what is the fastest way to transform goal "exists x, P /\ Q" to "exists x, Q /\ P"? [Sun Jan 26 07:51:12 2014] is there a better way than "cut (exists x, Q /\ P); [firstorder | idtac]?" [Sun Jan 26 07:55:30 2014] make that a lemma and then rewrite lemma. [Sun Jan 26 07:55:32 2014] :P [Sun Jan 26 09:36:30 2014] ianjneu, gonna try that. Thanks!! :) [Sun Jan 26 12:02:36 2014] constructor. constructor. solves my goal but auto. does not, why is that? does settings search depth something bigger work? (if yes, how can I do that?) [Sun Jan 26 12:04:16 2014] osa1: Hint Constructors the types involved. [Sun Jan 26 12:05:19 2014] ianjneu: I already did that. [Sun Jan 26 12:05:29 2014] osa1: and they're not two separate goals? [Sun Jan 26 12:05:58 2014] and your hints aren't in a different section than the one you're currently in? [Sun Jan 26 12:06:12 2014] yes and yes. [Sun Jan 26 12:07:40 2014] try auto 6 I suppose. [Sun Jan 26 12:25:29 2014] guys, I defined my function "closed" which return true if a term does not contain any free variables and I'm wondering when do I need a Prop for same thing, if I ever need it. any ideas on that? [Sun Jan 26 12:27:48 2014] (forall coquser, guy coquser) -> False. [Sun Jan 26 12:28:29 2014] It's a good idea to have a spec version for inductive proof and an implementation version for program-writing. [Sun Jan 26 12:28:38 2014] spec version ~ type [Sun Jan 26 12:31:47 2014] which scope has [], [a] etc for lists? [Sun Jan 26 12:43:15 2014] Import ListNotations. [Sun Jan 26 12:45:16 2014] apparently I don't have that library. [Sun Jan 26 12:46:29 2014] Require List first. [Sun Jan 26 12:49:30 2014] I already did that [Sun Jan 26 12:50:29 2014] Perhaps List.ListNotations. [Sun Jan 26 12:52:26 2014] ianjneu: are yous sure there's such a standard module? I can't see it here http://coq.inria.fr/distrib/current/stdlib/ [Sun Jan 26 13:07:08 2014] osa1: I use it all the time. I do Require Import List. Import ListNotations. [Sun Jan 26 15:25:27 2014] http://lpaste.net/6928329435871444992 well, I proved app_length_twice from SF but I feel like I did it in a really roundabout way [Sun Jan 26 15:25:33 2014] suggestions welcome! [Sun Jan 26 15:31:36 2014] http://lpaste.net/6546249402917322752 [Sun Jan 26 15:32:36 2014] hodapp: ^ [Sun Jan 26 15:34:39 2014] hmm, I'm trying to stick with what the book's explained so far [Sun Jan 26 15:35:23 2014] [|simpl;f_equal; apply IHl]; auto. - that whole thing is foreign to me presently [Sun Jan 26 15:36:06 2014] oh, the induction introduces two goals, so [tactics for goal1 | tactics for goal 2]; tactics applied to everything after. [Sun Jan 26 15:37:04 2014] ohh, okay... hmmm [Sun Jan 26 15:38:07 2014] f_equal turns f x y z = f x' y' z' into goals about x = x' , y = y' , z = z' [Sun Jan 26 15:38:30 2014] the rule of Leibniz for the definition of a function allows this. [Sun Jan 26 15:40:54 2014] ianjneu, would this be correct application of the convoy pattern? https://privatepaste.com/25b64209d0 [Sun Jan 26 15:42:33 2014] ya, though I would think refine would need parens around the application of the match to (eq_refl x) [Sun Jan 26 15:42:52 2014] problem with it? [Sun Jan 26 15:43:12 2014] hm [Sun Jan 26 15:43:13 2014] yea :P [Sun Jan 26 15:43:16 2014] doesnt work [Sun Jan 26 15:46:19 2014] what's the error? [Sun Jan 26 15:48:33 2014] with (eq_refl x) at the end: Syntax error: '.' or '...' expected after [tactic:tactic] (in [proof_mode:subgoal_command]). [Sun Jan 26 15:48:53 2014] without: Error: The type of this term is a product while it is expected to be "fterm_a". [Sun Jan 26 15:49:07 2014] pointing at (fun H : x = VTerm.Var n => ATerm.Var n) [Sun Jan 26 15:49:10 2014] Did you put parens where I just said? [Sun Jan 26 15:49:16 2014] yep [Sun Jan 26 15:49:38 2014] https://privatepaste.com/c02d74d95e [Sun Jan 26 15:50:01 2014] you got rid of the eq_refl though, heh [Sun Jan 26 15:50:56 2014] yes [Sun Jan 26 15:51:13 2014] ah [Sun Jan 26 15:51:14 2014] my bad [Sun Jan 26 15:51:27 2014] i was putting it after end) [Sun Jan 26 15:51:36 2014] where it should be as end (eq_refl x)) [Sun Jan 26 15:51:37 2014] :) [Sun Jan 26 15:51:39 2014] thank you [Sun Jan 26 15:52:07 2014] works like a charm! [Sun Jan 26 15:53:37 2014] ;) [Sun Jan 26 15:54:39 2014] I just wrote a tiny "my unary f_equal" via eq_ind to show hodapp and hit a coq bug. Fuckin.. and people trust its proofs. [Sun Jan 26 15:55:04 2014] granted it's not a soundness bug, but... SOFTWAAAARE!! *shakefist* [Sun Jan 26 15:55:17 2014] o_O [Sun Jan 26 16:02:04 2014] ianjneu: If only you had... some way to write software that would verify its correctness. [Sun Jan 26 16:02:41 2014] hodapp: Try it: Definition my_f_equal {A B} (f : A -> B) (a a' : A) (p : a = a') : f a = f a' := eq_ind _ _ (fun a' => f a = f a') _ _ p. [Sun Jan 26 16:03:17 2014] the fix is to make the first _ after the fun into (eq_refl _) [Sun Jan 26 16:03:24 2014] but still. [Sun Jan 26 16:04:00 2014] hodapp: Self-certifying theorem provers exist. Coq-in-coq and Milawa (in particular) are such. [Sun Jan 26 16:04:15 2014] Jitawa is verified down to the assembly. [Sun Jan 26 16:04:51 2014] but chips still have logic flaws and are also subject to uncertainty from the laws of physics. [Sun Jan 26 16:05:08 2014] We can be confident of correctness, but never certain. [Sun Jan 26 16:05:59 2014] Purists who bitch and moan about everything needing to be correct has never had to write real software as part of a business. [Sun Jan 26 16:06:05 2014] have* [Sun Jan 26 16:06:24 2014] proven correct* [Sun Jan 26 16:06:52 2014] [Sun Jan 26 16:06:56 2014] (for now) [Sun Jan 26 16:37:54 2014] ianjneu, im messing around with that sigT thing you spoke of earlier [Sun Jan 26 16:38:11 2014] so how can sigT be used to construct something ofthe form {a' : fterm_v & fterm_v_is_wf a'}? [Sun Jan 26 16:38:44 2014] what type of structure is {.. & ..} anyway? [Sun Jan 26 16:41:52 2014] sigT (fun a : A => blah) is {a : A & blah} [Sun Jan 26 16:42:10 2014] intro form is existT predicate witness proof [Sun Jan 26 16:43:25 2014] existT predicate witness proof? [Sun Jan 26 16:43:43 2014] soo, to construct {a : A & blah}, [Sun Jan 26 16:44:13 2014] one does existT fterm_v_is_wf a' [Sun Jan 26 16:44:16 2014] for example [Sun Jan 26 16:44:21 2014] and then provide the proof? [Sun Jan 26 16:45:00 2014] Print sigT. to see what the intro form expects. [Sun Jan 26 16:46:03 2014] hm [Sun Jan 26 16:46:20 2014] The term "map (existT fterm_v_is_wf) args_v" has type "list (sigT ?795)" while it is expected to have type "list {a' : fterm_v & fterm_v_is_wf a'}". [Sun Jan 26 16:48:47 2014] well, your map needs to apply the function to two arguments (witness and proof) to create that resulting type. [Sun Jan 26 16:48:55 2014] what's args_v? [Sun Jan 26 16:50:22 2014] list fterm_v [Sun Jan 26 16:50:54 2014] and, fterm_v_is_wf : fterm_v -> Prop [Sun Jan 26 16:51:37 2014] so a witness is just some entity to which the predicate applies? And proof would be the proof thereof? [Sun Jan 26 16:52:20 2014] whatever function you're writing (I assume it checks for well-formedness) will have to produce some option type since you won't know starting off that the args_v are all wellformed. [Sun Jan 26 16:52:56 2014] well [Sun Jan 26 16:53:34 2014] i wrote some lemmas to derive from wf x that any subterm of x is also wf [Sun Jan 26 16:53:58 2014] let me show you [Sun Jan 26 16:54:34 2014] https://privatepaste.com/17a13eff8a [Sun Jan 26 16:55:16 2014] so H together with H1 or H2 should cover that [Sun Jan 26 16:55:20 2014] I'm actually heading out [Sun Jan 26 16:55:23 2014] gl [Sun Jan 26 16:55:33 2014] cool [Sun Jan 26 16:55:41 2014] cya :) [Sun Jan 26 17:08:04 2014] so weird [Sun Jan 26 17:08:05 2014] im getting this [Sun Jan 26 17:08:07 2014] The term "map (fun x : term VSig => existT x fterm_v_is_wf) args_v" has type [Sun Jan 26 17:08:07 2014] "list {_ : term VSig & fterm_v -> Prop}" while it is expected to have type [Sun Jan 26 17:08:07 2014] "list {a' : fterm_v & fterm_v_is_wf a'}". [Sun Jan 26 17:08:59 2014] why does it use _ and not x [Sun Jan 26 17:09:28 2014] eh, well not x but something that binds [Sun Jan 26 17:24:36 2014] hm [Sun Jan 26 17:24:42 2014] (map (fun (a' : fterm_v) => existT a' (H1 a' (H2 a' [In a' args_v]) )) args_v) [Sun Jan 26 17:24:44 2014] this should work [Sun Jan 26 17:25:09 2014] but theres one problem [Sun Jan 26 17:25:25 2014] from an outsiders perspective, [In a' args_v] is obviously true [Sun Jan 26 17:25:44 2014] any a' that map binds to is in args_v [Sun Jan 26 17:26:12 2014] but how do i get that piece of information in there? Is there a way to postpone having to provide that proof? [Sun Jan 26 17:57:07 2014] time for sleep [Sun Jan 26 20:36:07 2014] I'm working through software foundations, and I just wrote an inductive definition for palindromes with a proof that pal l -> l = rev l. The hint for this exercise says that my inductive definition needs 3 constructors, but I was able to write the theorems with only 2. [Sun Jan 26 20:36:11 2014] http://lpaste.net/99122 [Sun Jan 26 20:37:34 2014] I think I was supposed to add a constructor, forall x, pal [x], but I'm not sure why I was able to prove pal l -> l = rev l without that constructor. Can someone give me a hint? [Sun Jan 26 20:44:21 2014] Oh. I think I get it. I might be able to prove pal l -> l = rev l, but I will have a hard time proving l = rev l -> pal l, because I can't provide evidence for pal [x]. [Sun Jan 26 23:38:25 2014] morning [Mon Jan 27 00:16:12 2014] so ive got this function that wants a witness and a proof [Mon Jan 27 00:16:18 2014] and id like to map that over a list l [Mon Jan 27 00:16:30 2014] part of the proof however is that the witness is in l [Mon Jan 27 00:17:21 2014] eg. map (fun (a' : fterm_v) => existT a' (H1 a' (H2 a' [In a' args_v]) )) args_v [Mon Jan 27 00:19:36 2014] any ideas? [Mon Jan 27 07:12:47 2014] i would like to map a function over elements e from list l and refer inside that function to the fact that In e l [Mon Jan 27 07:12:50 2014] is that possible? [Mon Jan 27 07:56:39 2014] (eg. https://privatepaste.com/a42fa3e44b) [Mon Jan 27 08:01:53 2014] brb [Mon Jan 27 08:33:36 2014] You can't without modifying map. Here: http://www.privatepaste.com/984150807d [Mon Jan 27 08:35:13 2014] hm [Mon Jan 27 08:36:18 2014] Proofs are data. You need to do "dependency injection" to get the facts you want. [Mon Jan 27 08:37:22 2014] this is some advanced stuff :p [Mon Jan 27 08:38:27 2014] "dependency injection," or as functional programmers call it, "passing arguments" [Mon Jan 27 08:40:15 2014] what part of my solution is advanced? [Mon Jan 27 08:41:11 2014] dunno [Mon Jan 27 08:41:23 2014] it wouldve taken a long time for me to come up with that myself though [Mon Jan 27 08:41:38 2014] cut P; [intro blah; l | r] is a shorthand for (assert (blah : P) by r; l) [Mon Jan 27 08:41:51 2014] ah thats what cut does? [Mon Jan 27 08:41:53 2014] roughly. [Mon Jan 27 08:41:57 2014] yea i was looking at that as well [Mon Jan 27 08:42:09 2014] hey how do i refer back to In a l? [Mon Jan 27 08:42:28 2014] the function is given the proof as its second argument. [Mon Jan 27 08:43:08 2014] hm [Mon Jan 27 08:44:33 2014] so the first argument is an element of l [Mon Jan 27 08:44:40 2014] and the second is In e l [Mon Jan 27 08:45:10 2014] yup. [Mon Jan 27 08:45:28 2014] and the result is just a list of type B right [Mon Jan 27 08:46:11 2014] yup. [Mon Jan 27 08:46:53 2014] map_witness (fun a' b => existT a' (H1 a' (H2 a' b))) args_v [Mon Jan 27 08:47:02 2014] Error: The type of this term is a product while it is expected to be "list ?861". [Mon Jan 27 08:47:25 2014] give args_v first, since the function depends on it. [Mon Jan 27 08:47:51 2014] gotcha :) [Mon Jan 27 08:47:56 2014] seems to work :9 [Mon Jan 27 08:48:25 2014] lets have a look [Mon Jan 27 08:50:35 2014] magic [Mon Jan 27 08:50:41 2014] thanks a lot ianjneu! [Mon Jan 27 08:53:09 2014] yup. One day after banging your head on the keyboard for hours on end, this will start to come naturally. At least, that's the road I took. [Mon Jan 27 08:56:43 2014] haha [Mon Jan 27 08:56:51 2014] definitely heading in the right direction then :p [Mon Jan 27 10:26:50 2014] so im making this assertion in proof mode [Mon Jan 27 10:27:27 2014] assert (x := some exotic computation). [Mon Jan 27 10:28:02 2014] how do i add a 'copy' to assumptions, eg. Hx : x = some exotic comuptation [Mon Jan 27 10:36:59 2014] ? [Mon Jan 27 10:38:38 2014] well, [Mon Jan 27 10:38:55 2014] ive made this assertion [Mon Jan 27 10:39:14 2014] assert (args_a := sigmap fterm_v_is_wf aterm_of_vterm (map_witness args_v (fun a' b => existT a' (H1 a' (H2 a' b))))). [Mon Jan 27 10:39:15 2014] your assert is essentially (let x := computation in ) so you can do (guess what?) the convoy pattern to get the equality as an assumption. (let x := computation in (fun Hx : x = computation => ) (eq_refl x)) [Mon Jan 27 10:39:43 2014] I think. [Mon Jan 27 10:39:44 2014] yea i was messing around with convoy pattern a bit but couldnt get it right [Mon Jan 27 10:39:47 2014] hm [Mon Jan 27 10:39:58 2014] ok that sounds obvious [Mon Jan 27 10:46:01 2014] ianjneu, how is my assert essentially "(let x := computation in )"? [Mon Jan 27 10:48:12 2014] My bad, I was thinking pose and not assert. [Mon Jan 27 10:48:24 2014] assert is a left-left-lambda. [Mon Jan 27 10:49:07 2014] assert (H : T) by proof; continuing-proof = ((fun H : T => continuing-proof-term) proof-term-for-assert) [Mon Jan 27 10:51:00 2014] could you give a simple example of that please? [Mon Jan 27 10:52:55 2014] what is "by proof"? [Mon Jan 27 10:52:59 2014] roosbeef: I'll let you play around with it and see what comes out. I learned how to make these proof terms by printing theorems after I've proven them to see what Coq's tactics formed. [Mon Jan 27 10:53:42 2014] assert ... by tac. is a way to prove an assertion outright with some tactic, failing if you don't finish the proof. [Mon Jan 27 10:56:17 2014] this assert doesnt require a proof though [Mon Jan 27 10:58:10 2014] assert always requires proof. [Mon Jan 27 10:58:38 2014] maybe the proof is inferred automatically [Mon Jan 27 10:59:03 2014] what i did is simply "assert (args_a := computation)." [Mon Jan 27 10:59:24 2014] and this adds "args_a : result_of_computation" to the assumptions [Mon Jan 27 11:01:37 2014] ah, I was thinking : instead of := [Mon Jan 27 11:01:58 2014] :p [Mon Jan 27 11:02:20 2014] instead use pose (args_a := computation) since you'll keep the equality. [Mon Jan 27 11:03:29 2014] hm [Mon Jan 27 11:03:39 2014] can i rewrite from that? [Mon Jan 27 11:04:15 2014] Yup. [Mon Jan 27 11:04:42 2014] well, it's judgemental, so it might just be subst args_a to get rid of it. [Mon Jan 27 11:05:34 2014] yep subst works :) [Mon Jan 27 11:05:41 2014] awesome [Mon Jan 27 11:05:51 2014] thanks and sorry for being such a drag [Mon Jan 27 11:08:32 2014] no apologies necessary. I'm in #coq mostly to help. [Mon Jan 27 11:09:36 2014] mehhhh [Mon Jan 27 11:09:38 2014] No more subgoals. [Mon Jan 27 11:09:48 2014] Defined. [Mon Jan 27 11:09:52 2014] Error: Recursive definition of aterm_of_vterm is ill-formed. [Mon Jan 27 11:10:12 2014] Coq certainly makes me look at other languages differently... [Mon Jan 27 11:10:18 2014] I use Python a lot at work. [Mon Jan 27 11:10:32 2014] and C++ but not if I can avoid it. [Mon Jan 27 11:10:33 2014] you're using your fix'd function on a non-subterm probably. [Mon Jan 27 11:11:33 2014] fix'd function? [Mon Jan 27 11:11:47 2014] the convoy pattern you mean? [Mon Jan 27 11:12:10 2014] are you using refine on a use of fix? [Mon Jan 27 11:12:31 2014] no [Mon Jan 27 11:12:42 2014] I have a rather.. dumb question about type theory and its foundations. [Mon Jan 27 11:12:58 2014] LinearInterpol: go on [Mon Jan 27 11:13:16 2014] Your question is almost certainly not more dumb than I am about its subject. [Mon Jan 27 11:13:16 2014] (Bear in mind I was a pure-C programmer just a few weeks ago, so bear with my ignorance. :) [Mon Jan 27 11:14:15 2014] Outside of a language like Coq or Haskell, how would I define a function in type theory? Does it require some supplementary logic to define the "form" of a function? [Mon Jan 27 11:15:27 2014] gonna give it a rest, bbl [Mon Jan 27 11:15:27 2014] <3 [Mon Jan 27 11:15:27 2014] type theory is an informal concept. There are specific type theories. Some consistent (at least we think), like Gallina, some inconsistent (like Haskell's) [Mon Jan 27 11:16:01 2014] I don't know quite what you mean, LinearInterpol. [Mon Jan 27 11:16:05 2014] So effectively there's no one "Type Theory". [Mon Jan 27 11:16:19 2014] There are systems of it. [Mon Jan 27 11:16:22 2014] We have as axioms the computation rules such as beta. [Mon Jan 27 11:16:52 2014] Beta? [Mon Jan 27 11:17:08 2014] Beta reduction? [Mon Jan 27 11:17:11 2014] indeed. [Mon Jan 27 11:18:01 2014] http://lpaste.net/5958568516704534528 [Mon Jan 27 11:18:51 2014] A few weeks ago I was just a strict C programmer. My friend converted me to Haskell, and I've just been struggling to understand where the sort of language-dependent stuff splits from the purely mathematical stuff. [Mon Jan 27 11:18:58 2014] An example of which would be pattern matching. [Mon Jan 27 11:19:44 2014] I asked him rather naively: [Mon Jan 27 11:20:02 2014] "Is pattern/form matching a mathematical thing or a tool that languages use?" [Mon Jan 27 11:20:09 2014] "Is there something 'lower' than it?" [Mon Jan 27 11:20:35 2014] He equated it to functions over sets. [Mon Jan 27 11:23:17 2014] * crawls back into his lurking state. [Mon Jan 27 11:25:46 2014] LinearInterpol: eliminators are the "lower" things. Type eliminators are essentially proofs of initiality of the functor algebra that the inductive type forms. [Mon Jan 27 11:26:01 2014] Sorry for the delay. Diaper changes an' whatnot. [Mon Jan 27 11:26:30 2014] Type eliminators, huh? [Mon Jan 27 11:26:30 2014] See Conor McBride's "eliminating pattern matching" paper if you're interested in the details. [Mon Jan 27 11:26:43 2014] Lovely! :) [Mon Jan 27 11:27:05 2014] When you define an "Inductive" in coq, you might have noticed several different functions get "defined" [Mon Jan 27 11:27:23 2014] Type constructors, I assume? [Mon Jan 27 11:28:08 2014] those are the recursive (non-dependent) and inductive (dependent) eliminators. There are more than two because of a historical accident with "Set" and "Type" [Mon Jan 27 11:28:38 2014] What is an eliminator? [Mon Jan 27 11:28:40 2014] LinearInterpol: no, type constructors and variants are different. [Mon Jan 27 11:29:54 2014] Sorry for the questions, by the way. Just trying to grok all of this. :) [Mon Jan 27 11:30:03 2014] An eliminator for (A * B), say, would say give me a function that does something with an A and a B, an element of (A * B), and do the "computation" with it to produce an element of the motive (the result type) [Mon Jan 27 11:30:57 2014] So we're back to dealing with sets if we're working with eliminators. [Mon Jan 27 11:31:27 2014] LinearInterpol: Think of "eliminator" in the sense of "I have an expression using this new type constructor and I want to cope with it by eliminating it, i.e., interpreting it in terms of constructors I already understand." [Mon Jan 27 11:31:48 2014] Alright, I'm starting to get that.. [Mon Jan 27 11:31:49 2014] go into Coq and do Check prod_rect. [Mon Jan 27 11:32:12 2014] for the formal type of what I was getting at with A * B. [Mon Jan 27 11:33:12 2014] forall (A B : Tye) (P : A * B -> TYPE)... [Mon Jan 27 11:33:21 2014] ...woah. [Mon Jan 27 11:33:45 2014] That. That's a little more over my head than I'd like. o_o [Mon Jan 27 11:33:47 2014] LinearInterpol: type theory is richer than set theory, as recent research in homotopy type theory has illuminated. [Mon Jan 27 11:34:15 2014] It's why I'm trying to get a hold on it. Remember: I was once a C programmer. Types aren't exactly forced on me. :) [Mon Jan 27 11:34:22 2014] And I will admit that I know very very very little of Coq. [Mon Jan 27 11:35:20 2014] Homotopy type theory looks.. odd. It deals with homomorphisms between types or something? [Mon Jan 27 11:35:53 2014] brb [Mon Jan 27 11:36:50 2014] Sure. :) [Mon Jan 27 11:37:15 2014] By the way: you folks are the nicest people I've met, all other people I've pretty much annoyed want me banned from their channel. :P [Mon Jan 27 11:38:38 2014] So.. an eliminator is effectively something that characterises an operation over all things belonging to that type? [Mon Jan 27 11:39:03 2014] And yields some (A * B). [Mon Jan 27 11:40:45 2014] LinearInterpol: You might try one of the following sources for more background: Programming in Martin-Löf's Type Theory, http://www.cse.chalmers.se/research/group/logic/book/book.pdf ; Bob Harper, Practical Foundations for Programming Languages, http://www.cs.cmu.edu/~rwh/plbook/book.pdf ; Martin-Löf's original book Intutionistic Type Theory, http://intuitionistic.files.wordpress.com/2010/07/martin-lof-tt.pdf . [Mon Jan 27 11:41:01 2014] (That isn't to tell you to go away, just to provide some background reading if you want it.) [Mon Jan 27 11:41:13 2014] Totally! [Mon Jan 27 11:41:28 2014] The eliminator for product types characterizes functions _out_of_ a product type in terms of functions out of the constituents of the product. [Mon Jan 27 11:41:41 2014] It says "to give a function A * B -> C, give a function A -> B -> C." [Mon Jan 27 11:42:24 2014] I'm not exactly equipped with much terminology.. constituents of the product? [Mon Jan 27 11:42:41 2014] Sorry, not a technical term. The types you gave to the * type constructor. [Mon Jan 27 11:42:43 2014] A and B. [Mon Jan 27 11:42:46 2014] Oh. [Mon Jan 27 11:43:38 2014] So.. to produce or make an operation/function A * B. [Mon Jan 27 11:44:06 2014] Not to produce the * type constructor itself, but to produce something that consumes arguments of type A * B. [Mon Jan 27 11:44:54 2014] I'm not sure I'm getting this very well.. sorry. :( [Mon Jan 27 11:45:12 2014] I'm not really mathematically versed. [Mon Jan 27 11:45:24 2014] I've been playing with these ideas on and off for years and they still confuse me :) [Mon Jan 27 11:45:52 2014] Hehe, glad to know I'm not alone. :) [Mon Jan 27 11:45:54 2014] (I'm an amateur, there are several professionals in this channel but I'm just some software guy) [Mon Jan 27 11:46:22 2014] Same.. I've left the comfort of void* pointers and manual safety for Coq, Haskell, etc. :) [Mon Jan 27 11:47:04 2014] I've always been fascinated by the mathematics behind it. [Mon Jan 27 11:47:24 2014] Yet it's almost never approachable. [Mon Jan 27 11:48:02 2014] Have you taken a look at Software Foundations (Pierce et al) ? [Mon Jan 27 11:48:03 2014] I'm very hands-on, and it's difficult for me to sort of translate abstractions to a relatively simple concept to me. [Mon Jan 27 11:48:09 2014] Yes, actually! Only just a bit. [Mon Jan 27 11:48:16 2014] Does it cover eliminators and all of that? [Mon Jan 27 11:49:02 2014] In the chapter MoreInd where they talk about induction principles, those are another name for what we've been calling eliminators. [Mon Jan 27 11:49:26 2014] Awesome. I guess I just need to work more with Coq to understand this. :) [Mon Jan 27 11:49:34 2014] But it's nice to know that awesome people are nearby. :D [Mon Jan 27 11:49:49 2014] Afk for a bit, gotta do stuff for a class.. thanks for all the help! :) [Mon Jan 27 11:49:59 2014] I'd encourage you to continue working through Software Foundations and also look at Bob Harper's book. [Mon Jan 27 11:50:08 2014] Will do! [Mon Jan 27 11:50:13 2014] that's probably the most accessible of the sources I gave above. Good luck! [Mon Jan 27 11:50:17 2014] Thanks! :D [Mon Jan 27 11:58:16 2014] okay. Condo board of trustees shit taken care of. [Mon Jan 27 11:58:21 2014] Now for the scrollback. [Mon Jan 27 12:00:34 2014] okay, nothing I need to say. [Mon Jan 27 15:13:08 2014] when coq tells me this [Mon Jan 27 15:13:21 2014] Error: Recursive definition of aterm_of_vterm is ill-formed. [Mon Jan 27 15:13:22 2014] Recursive call to aterm_of_vterm has not enough arguments. [Mon Jan 27 15:13:45 2014] why is that [Mon Jan 27 15:14:24 2014] i did work out a full proof to the definition of aterm_of_vterm [Mon Jan 27 15:14:36 2014] and coq even told me "No more subgoals" [Mon Jan 27 15:14:50 2014] but it wont wrap up the definition when doing Defined, giving that error [Mon Jan 27 15:19:15 2014] it might be because im using refine, maybe the recursion is not structurally decreasing? [Mon Jan 27 15:19:20 2014] but i dont understand that error message [Mon Jan 27 15:19:27 2014] or maybe* [Mon Jan 27 15:21:25 2014] heres the full error msg https://privatepaste.com/69acfc11c6 [Mon Jan 27 19:37:03 2014] Hello. [Mon Jan 27 19:37:09 2014] hi Rc43 [Mon Jan 27 19:41:36 2014] I have problem with writing mutual fixpoint expression. [Mon Jan 27 19:41:40 2014] According to http://coq.inria.fr/V8.2pl1/refman/Reference-Manual003.html#fixpoints I am trying to write this: http://coq.xelpaste.org/9636 [Mon Jan 27 19:42:12 2014] But that doesn't pass due error on `g': "A fixpoint needs at least one parameter." [Mon Jan 27 19:42:53 2014] (Also manual says to write "for ", but ident_i should be function with argument.) [Mon Jan 27 19:43:04 2014] How to properly define such function? [Mon Jan 27 20:09:43 2014] Oooooh, problem was in usage of "Function" instead of "Definition". [Tue Jan 28 04:46:02 2014] hi [Tue Jan 28 04:46:36 2014] so im getting this [Tue Jan 28 04:47:13 2014] after a large proof of a function definition, after coq says "no more subgoals", when i try to wrap the thing up by doing Defined, it says [Tue Jan 28 04:47:14 2014] Error: Recursive definition of aterm_of_vterm is ill-formed. [Tue Jan 28 04:47:14 2014] Recursive call to aterm_of_vterm has not enough arguments. [Tue Jan 28 04:48:13 2014] is that a generic error for a deeper issue (thats what some google results seemed to suggest?), or is there something wrong with the definition [Tue Jan 28 04:49:03 2014] im a bit confused as to why coq accepts the proof (and thus the corresponding type checks?) but rejects the overall definition.. didnt it thoroughly type check during proof mode? [Tue Jan 28 04:54:27 2014] The ill-formed recursive call generally means that you did something that the termination checker won't pass (such as Fixpoint f x := f x.). I've never seen the "not enough arguments" message, but it probably means you used the recursive call as returning a function, rather than explicitly giving it an argument to do structural recursion on (and you can't do Fixpoint f (x : Type) : Type -> Type := fun _ => f. either). There's not an easy way [Tue Jan 28 04:54:27 2014] to check this when constructing the proof, so Coq only checks it at the end. [Tue Jan 28 04:55:09 2014] hmm [Tue Jan 28 04:55:12 2014] well, [Tue Jan 28 04:56:20 2014] im converting terms (tree type data structure, eg. f(g(a),g(b,c))) [Tue Jan 28 04:56:23 2014] ) [Tue Jan 28 04:57:20 2014] from fterm_v to fterm_a, basically the only difference being that fterm_a has a constraint such that it has a strict branching ratio [Tue Jan 28 04:57:45 2014] so when converting from the unconstrained type to the constrained type, both terms/trees look exactly the same [Tue Jan 28 04:58:27 2014] (the input is assumed to conform to that constraint) [Tue Jan 28 04:59:34 2014] so yea long story short, i think i might have been doing some of the things you were describing [Tue Jan 28 05:00:05 2014] for one there is no structurally decreasing argument :/ [Tue Jan 28 05:01:49 2014] If there's no structurally decreasing argument, then you want well-founded recursion, not structural fixpoints. (I've never used wf-recursion, so I probably can't help you much with it.) [Tue Jan 28 05:02:08 2014] how does that work? [Tue Jan 28 05:02:51 2014] (or how does that look rather) [Tue Jan 28 05:10:35 2014] http://adam.chlipala.net/cpdt/html/GeneralRec.html [Tue Jan 28 05:12:18 2014] yea was just reading that, thanks :) [Tue Jan 28 08:00:32 2014] Question: what is a dependent type? [Tue Jan 28 08:12:42 2014] LinearInterpol: A type that depends on a value. [Tue Jan 28 08:13:02 2014] LinearInterpol: One example: A function that takes a list of length 'n', and returns a list also of length 'n'. [Tue Jan 28 08:13:46 2014] So.. wait. [Tue Jan 28 08:14:08 2014] So the type of that function depends on "n"? [Tue Jan 28 08:20:18 2014] more accurately, "dependent types" depend on terms, not values. [Tue Jan 28 08:20:52 2014] terms, okay. [Tue Jan 28 08:20:58 2014] Okay. [Tue Jan 28 08:21:08 2014] So that type is effectively dependent on the list type. [Tue Jan 28 08:21:19 2014] Or terms of the list type. [Tue Jan 28 08:26:01 2014] dammit Wikipedia. https://en.wikipedia.org/wiki/Lambda_cube says "depending on terms", but https://en.wikipedia.org/wiki/Dependent_type says "depends on a value". [Tue Jan 28 08:26:13 2014] I know! I'm so confused! :( [Tue Jan 28 08:34:23 2014] terms, when the free variables are substituted for values, compute to values. [Tue Jan 28 08:35:32 2014] ah. [Tue Jan 28 08:35:41 2014] okay, that makes a tad more sense. [Tue Jan 28 08:35:59 2014] so if a function takes a parameter "n" of type "A", the type of that function is dependent on "n" [Tue Jan 28 08:36:11 2014] and that's called a dependent type. [Tue Jan 28 08:36:12 2014] right? [Tue Jan 28 08:36:41 2014] no, you just said the function takes an A, you didn't say what it produces depends on the input terms of type A. [Tue Jan 28 08:36:53 2014] oh. [Tue Jan 28 08:37:12 2014] A -> B is shorthand for forall x:A, B where x is not free in B. [Tue Jan 28 08:37:33 2014] * goes back to working through Software Foundations. [Tue Jan 28 08:57:41 2014] Ruh-roh. [Tue Jan 28 08:57:43 2014] Error: Impossible to unify "tuesday" with "monday". [Tue Jan 28 08:57:58 2014] In the first few examples. [Tue Jan 28 09:10:36 2014] Oh, sweet. I can actually step through and see the subgoals.. [Tue Jan 28 09:10:42 2014] Huh. That's why it failed. [Tue Jan 28 09:39:15 2014] ianjneu: can dependent types depend on a term with free variables? [Tue Jan 28 10:07:08 2014] hodapp: depends on what you mean by "free." Contextual type theory deals with "open" terms, but meta-closes them, heh. [Tue Jan 28 10:10:07 2014] meta-closes? [Tue Jan 28 10:11:26 2014] I guess what I'm looking for is what dependent type systems actually handle the gap in between 'types that depend on a term' and 'types that depend on a value', since a distinction was made, but you did specify that terms compute to values when free variables are substituted for values. [Tue Jan 28 10:17:50 2014] well, the terms get closed by quantifiers outside of the dependent types. [Tue Jan 28 10:18:21 2014] so zooming in on a type under a quantifier, there can be free variables. [Tue Jan 28 10:21:34 2014] that's what meta-closed means? [Tue Jan 28 10:22:53 2014] no no, contextual type theory is something used in a logical framework called Beluga, where you can manipulate quoted terms that have free variables, but you have a context of meta-variables and their typings. [Tue Jan 28 10:54:49 2014] hello [Tue Jan 28 10:55:23 2014] hodapp: have you had a chance to prove combine_split? :) [Tue Jan 28 11:07:21 2014] hah, that's where I'm stuck presently [Tue Jan 28 11:07:37 2014] I was trying to use their nearby techniques of destructing an expression but I keep losing information that I need that way [Tue Jan 28 11:08:48 2014] however I've not had much time to look at this [Tue Jan 28 11:09:26 2014] was gonna work on it Sunday, but Sunday was also my birthday, and the dinner plans ended up with a bunch of friends surprising me there and then buying many many shots of tequila for me, so not much Coq happened when I got home... [Tue Jan 28 11:25:57 2014] hodapp: to not loose info use eqn [Tue Jan 28 11:26:07 2014] like destruct (foo bar) eqn:foo_bar. [Tue Jan 28 11:26:42 2014] A3mr: I was trying to do it only using what they'd unveiled thus far in the book. [Tue Jan 28 11:28:19 2014] while destruct eqn: may be useful, one can prove this result without it. [Tue Jan 28 11:28:39 2014] and that's what I'm looking for. [Tue Jan 28 11:32:37 2014] hodapp: you will need to unpack the hypothesis `split l = (l1, l2)` somehow. [Tue Jan 28 11:32:54 2014] ystael: I was getting a sense of that as I worked, but not seeing how. [Tue Jan 28 11:33:02 2014] 'unfold' just seemed to make things worse. [Tue Jan 28 11:33:47 2014] try `inversion`; the section is about inversion after all :) [Tue Jan 28 11:34:25 2014] hmmmmmmmm [Tue Jan 28 11:37:49 2014] What does "reflexivity" really mean in Coq? [Tue Jan 28 11:37:59 2014] In contrast to simpl. ? [Tue Jan 28 11:38:28 2014] Does reflexivity just not show the simplification of whatever I want to prove? [Tue Jan 28 11:39:01 2014] LinearInterpol: It means "simpl, and then attempt to apply the constructor `eq_refl` of equality types." [Tue Jan 28 11:39:10 2014] Well, that's the mechanics. [Tue Jan 28 11:39:22 2014] Ah. So "simpl." doesn't imply any sort of equality. [Tue Jan 28 11:39:46 2014] * doesn't understand eq_refl, but he'll learn it later hopefully. [Tue Jan 28 11:39:46 2014] right. `simpl` just applies the reduction rules (beta delta eta zeta iota). [Tue Jan 28 11:40:02 2014] You can see what `simpl` would do in a particular term by typing `Eval compute in `. [Tue Jan 28 11:40:09 2014] Any "simple" explanation/reference to those rules? [Tue Jan 28 11:40:16 2014] Just so I can look at them. [Tue Jan 28 11:40:32 2014] I may know them but the terminology always screws me over. :) [Tue Jan 28 11:40:40 2014] This chapter from Adam Chlipala's book is useful: http://adam.chlipala.net/cpdt/html/Equality.html [Tue Jan 28 11:43:19 2014] Note that eta expansion (f == \x -> f x) was not part of Coq's definitional equality at the time the book was written; it was added in Coq 8.4 [Tue Jan 28 11:47:08 2014] Huh. Sweet. [Tue Jan 28 11:50:03 2014] So delta just replaces a reference to a function with the actual function? [Tue Jan 28 11:50:34 2014] then beta works by replacing terms with values.. [Tue Jan 28 11:50:54 2014] Then iota simplifies it down by determining the matches.. [Tue Jan 28 11:51:34 2014] Then zeta.. wait, how is that different than beta? [Tue Jan 28 11:52:28 2014] It's not different if you think of lets as desugaring into lambdas, but lets are primitive in Gallina [Tue Jan 28 11:52:44 2014] Oh. [Tue Jan 28 11:52:45 2014] so they need their own reduction rule [Tue Jan 28 11:52:59 2014] I see. [Tue Jan 28 11:53:07 2014] That explains it. [Tue Jan 28 12:02:21 2014] is it possible to prove S n = S m -> n = m without using inversion? how can I prove ~ (0 = 1)? [Tue Jan 28 12:06:46 2014] See the HoTT book chapter 2.12. There is a simpler problem of proving injectivity of coproduct injectors. [Tue Jan 28 12:09:30 2014] is proving ~ (0 = 1) without inversion is some constructive trick? [Tue Jan 28 12:13:34 2014] nvm [Tue Jan 28 12:13:36 2014] A3mr: match on the equality with a 0-True/1-False predicate, prove False [Tue Jan 28 12:22:09 2014] could you please give me some hints on how to proceed with that theorem http://vpaste.net/eID9J ? [Tue Jan 28 12:25:25 2014] i feel myself so dumb [Tue Jan 28 12:26:44 2014] Ptival: "match on the equality with a 0-True/1-False predicate, prove False", are you talking about how to prove "~ (0 = 1)"? [Tue Jan 28 12:27:32 2014] ianjneu: do we really need such a complicated proof? "code(x)" etc? [Tue Jan 28 12:29:59 2014] Agda's way: "suc-inversion : ∀ n m → suc n ≡ suc m → n ≡ m;suc-inversion .m m refl = refl" [Tue Jan 28 12:32:28 2014] how can I write something like the above in a Coq Definition ? [Tue Jan 28 12:37:54 2014] "Print" ftw [Tue Jan 28 12:40:03 2014] CoqNewbie: yes [Tue Jan 28 12:43:42 2014] A3mr: you need to strengthen your induction hypothesis [Tue Jan 28 12:45:42 2014] Ptival: ah, does it mean i "intros" too much? [Tue Jan 28 12:47:02 2014] Ptival: induction hypothesis of "induction l" right? [Tue Jan 28 12:47:04 2014] A3mr: yes, either that or you need to "revert" a few things before starting the induction [Tue Jan 28 12:47:46 2014] for instance, you'd want your induction hypothesis to be quantified over l1 and l2 [Tue Jan 28 12:47:55 2014] if you're going to perform induction on l [Tue Jan 28 12:49:22 2014] in the version you have posted, you see that you are stuck because the hypothesis for your induction hypothesis is false, because it is tied to the initial l1 and l2 [Tue Jan 28 12:49:51 2014] if it became IHl: forall l1 l2, split l = (l1, l2) -> combine l1 l2 = l [Tue Jan 28 12:50:12 2014] then you'd be able to use it with l1' being the tail of the initial l1 [Tue Jan 28 12:52:32 2014] Hello. [Tue Jan 28 12:52:44 2014] Coq doesn't use ocaml batteries, right? [Tue Jan 28 12:54:56 2014] Ptival: sorry, could you please expand a bit on " use it with l1' being the tail of the initial l1"? current version: http://vpaste.net/3kqRY [Tue Jan 28 12:55:21 2014] i haven't got what is l1' and what is tail of initial l1 [Tue Jan 28 12:55:33 2014] do you mean tail of initial l? [Tue Jan 28 12:58:44 2014] A3mr: my assumption is that if you were to destruct l1 into hl1 :: tl1, then x would have to be hl1, and you could prove your goal by applying the induction hypothesis to tl1 and l2 [Tue Jan 28 12:59:03 2014] (in fact you might not have needed to revert l2, but whatever) [Tue Jan 28 12:59:24 2014] (oh you did not, you just intro-ed less, good) [Tue Jan 28 12:59:44 2014] A3mr: what happens if you "simpl in H"? [Tue Jan 28 13:01:12 2014] Ptival: http://vpaste.net/SZW4S [Tue Jan 28 13:03:44 2014] oh sorry, got it [Tue Jan 28 13:04:05 2014] well you should be able to make progress by yourself now :) [Tue Jan 28 13:05:39 2014] Ptival: was that simpl in H step necessary? [Tue Jan 28 13:12:23 2014] it won't budge :( [Tue Jan 28 13:22:23 2014] In the proof by simplication for "plus" or "add" in software foundations, two questions. [Tue Jan 28 13:22:31 2014] 1. It has "Proof." on one line. [Tue Jan 28 13:22:44 2014] Why? [Tue Jan 28 13:23:03 2014] can you link to the part of the book you mean? [Tue Jan 28 13:23:06 2014] 2. "intros n." Seems to be dependent on "n". What exactly does it do? [Tue Jan 28 13:23:08 2014] Oh, sure. [Tue Jan 28 13:23:11 2014] http://www.cis.upenn.edu/~bcpierce/sf/Basics.html#slide-1 [Tue Jan 28 13:23:24 2014] Proof by Simplification. [Tue Jan 28 13:24:49 2014] When we're proving that "n" has an identity O which yields "n". [Tue Jan 28 13:25:16 2014] Ptival: that streightening of hypothesis left with exact same environment but with "forall"s in hypothesis [Tue Jan 28 13:26:27 2014] LinearInterpol: that's just how Coq denotes that a proof of the theorem follows, I believe. [Tue Jan 28 13:26:36 2014] Cool. [Tue Jan 28 13:26:49 2014] So "Proof." and "Qed." are a kind of delimiter. [Tue Jan 28 13:27:24 2014] LinearInterpol: intros, as I understand it, moves something out of a quantifier (i.e. forall n) and into the context as a sort of arbitrary value being assumed. [Tue Jan 28 13:27:24 2014] A3mr: you should break x apart into its two pieces to let H simplify even further [Tue Jan 28 13:27:35 2014] but folks here may have a less hand-wavy description of 'intros'. [Tue Jan 28 13:27:39 2014] Hehe. [Tue Jan 28 13:28:02 2014] Now.. I'm trying to prove that forall n : nat, n - n = O [Tue Jan 28 13:28:09 2014] Says it can't unify sub n n = O [Tue Jan 28 13:28:17 2014] (sub being my subtraction function) [Tue Jan 28 13:28:41 2014] induction on n [Tue Jan 28 13:28:51 2014] ? [Tue Jan 28 13:29:11 2014] n is a neutral term. You need to prove your proposition via induction. [Tue Jan 28 13:29:18 2014] LinearInterpol: The next chapter goes into induction; you may need that. [Tue Jan 28 13:29:21 2014] ianjneu: neutral term? [Tue Jan 28 13:29:39 2014] I definitely will.. [Tue Jan 28 13:29:55 2014] Proof by Rewriting? [Tue Jan 28 13:30:26 2014] rewriting is different from induction. [Tue Jan 28 13:30:26 2014] what about it? [Tue Jan 28 13:30:38 2014] that's just another section, not another chapter [Tue Jan 28 13:30:40 2014] oh. [Tue Jan 28 13:30:41 2014] sorry. [Tue Jan 28 13:31:05 2014] ianjneu: What exactly does "intros" do? [Tue Jan 28 13:31:09 2014] hodapp: neutral term is a piece of terminology from normalization-by-evaluation. [Tue Jan 28 13:31:20 2014] And.. I'm really sucky with terminology. [Tue Jan 28 13:31:24 2014] I'd say "patience, grasshopper" but I'm not sure that grasshoppers are allowed to say that to other grasshoppers. [Tue Jan 28 13:31:30 2014] haha. :) [Tue Jan 28 13:31:39 2014] I'm only a few chapters ahead of you. [Tue Jan 28 13:31:40 2014] It's terrifying that grasshoppers can talk in the first place. [Tue Jan 28 13:32:17 2014] intros without arguments will produce a proof term that is a function of as many arguments as there are things left of an -> or forall to use in the body (i.e. rest of proof) [Tue Jan 28 13:32:40 2014] Got an example? [Tue Jan 28 13:33:30 2014] Remark lint : forall (P Q : Prop) P -> Q -> P. Proof. intros; assumption. Qed. Print lint. [Tue Jan 28 13:35:15 2014] Ptival: indeed, H become " H : (x :: foo l, y :: bar l) = (l1, l2)" i wonder from where these foo and bar came :) [Tue Jan 28 13:35:16 2014] I suppose I just need to work through the rest of the book. [Tue Jan 28 13:35:34 2014] Gonna hold intros. off until later. [Tue Jan 28 13:35:45 2014] Because I, honest to god, understand little to none of that. Sorry. :\ [Tue Jan 28 13:36:02 2014] Cheers. [Tue Jan 28 13:36:25 2014] A3mr: I'm not sure which tactics you have learned yet, but now this H allows you to deduce things about l1 and l2 [Tue Jan 28 13:41:36 2014] Ptival: what things? Ptival well, my tactics knowlege is limited to http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html#lab147 [Tue Jan 28 13:57:12 2014] is there anyway to prove x = y -> f x = f y? [Tue Jan 28 13:59:47 2014] CoqNewbie: http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html#lab130 [Tue Jan 28 14:05:14 2014] CoqNewbie: f_equal is a builtin to do this for any arity function. Try proving it yourself with an application of eq_ind [Tue Jan 28 14:05:55 2014] A3mr: you should be able to get that l1 is x :: foo and l2 is y :: bar l [Tue Jan 28 15:24:16 2014] Ptival: yeah, thats clear but what is foo and bar? [Tue Jan 28 16:10:26 2014] What is the counterpart to 'inversion', but for the present goal? [Tue Jan 28 16:13:06 2014] nevermind, looks like f_equal does what I need [Tue Jan 28 16:46:28 2014] A3mr: okay, finally finished combine_split :P [Tue Jan 28 16:47:09 2014] I find it neat that I can interactively step through my own proofs and watch things unfold; it doesn't replace good commenting, but it's nice to have [Tue Jan 28 16:47:34 2014] hodapp: congrats! [Tue Jan 28 16:48:25 2014] hodapp: did you encountered "l1 is x :: foo and l2 is y :: bar l" ? [Tue Jan 28 16:50:14 2014] A3mr: I think I had something very similar [Tue Jan 28 16:51:25 2014] A3mr: http://lpaste.net/2450854973576052736 is how I solved it [Tue Jan 28 16:52:22 2014] neat, http://vpaste.net/fnWIb thats where i'm stuck :)\ [Tue Jan 28 17:00:11 2014] what's induction on X get you? [Tue Jan 28 17:00:16 2014] er, x [Tue Jan 28 17:01:02 2014] so, mine looks similar to yours in that 2nd case, but take a look at H - it is using the same constructor on each side [Tue Jan 28 17:01:24 2014] which should suggest a logical next step [Tue Jan 28 17:15:04 2014] hodapp: whithout simpl and induction on x my H looks like "split (x :: l) = (l1, l2)" [Tue Jan 28 17:17:17 2014] even without that, it has to be using the same constructor [Tue Jan 28 17:28:31 2014] question: [Tue Jan 28 17:28:37 2014] I've done some digging and thinking. [Tue Jan 28 17:28:51 2014] Underlying pattern matching, I was informed about eliminators. [Tue Jan 28 17:29:02 2014] Aren't they just equivalent to logical disjunction? [Tue Jan 28 17:37:09 2014] LinearInterpol: the answer is probably no, but I am not sure of what you mean [Tue Jan 28 17:37:19 2014] could you elaborate on what you feel is equivalent [Tue Jan 28 17:37:59 2014] Ptival: I'm an extreme newbie. [Tue Jan 28 17:38:13 2014] But "P v Q" is an eliminator because you only need to know either P or Q. [Tue Jan 28 17:38:21 2014] And whichever one you don't know, you don't need. [Tue Jan 28 17:39:15 2014] I don't know. [Tue Jan 28 17:39:51 2014] LinearInterpol: what is your definition of eliminator? [Tue Jan 28 17:40:19 2014] I don't know. I'm trying to find out things that sort of "make up" pattern matching. [Tue Jan 28 17:42:31 2014] pattern matching is indeed a syntactical nicety for using eliminators [Tue Jan 28 17:42:38 2014] P v Q is not an eliminator. It's a coproduct type. [Tue Jan 28 21:58:08 2014] Confused about a part in CPDT regarding nat's and injenction tactic, help? http://lpaste.net/1902386099393658880 [Tue Jan 28 22:17:20 2014] adelbertc: In general the `injection` tactic applies injectivity of data constructors, that is, if K is a data constructor then `injection` can take K a = K b and deduce a = b. [Tue Jan 28 22:18:11 2014] i see. So S n = Sm -> n = m means if we have S n, and if "n" follows from S m, then m [Tue Jan 28 22:18:13 2014] The `1` part is a convenience of the tactic language. If the goal has the form A -> B -> C -> ... -> X, then some tactics which normally act on a hypothesis can take a number n. [Tue Jan 28 22:18:34 2014] That means "introduce the first n hypotheses using intros, and act on the last one". [Tue Jan 28 22:18:48 2014] No, you have the syntax precedence wrong; it is (S n = S m) -> (n = m). [Tue Jan 28 22:18:48 2014] i see, so injenction 1 is acting on "S n" [Tue Jan 28 22:19:03 2014] ohhhhh ok [Tue Jan 28 22:19:10 2014] so injenction is acts on (S n = S m) [Tue Jan 28 22:19:12 2014] yes [Tue Jan 28 22:19:28 2014] and the injenction tactic basically does what you described up there [Tue Jan 28 22:19:32 2014] yes [Tue Jan 28 22:19:38 2014] followed by trivial. got it got it [Tue Jan 28 22:19:39 2014] cheers [Tue Jan 28 22:19:47 2014] np, good luck [Tue Jan 28 22:26:40 2014] ystael: how would that vary from 'inversion' in this case? [Tue Jan 28 22:27:53 2014] as SF explained inversion in much the same way - if K is a data constructor, K a1 a2 a3... = K b1 b2 b3... supplies hypotheses a1 = b1, a2 = b2, a3 = b3, and so on [Wed Jan 29 11:03:17 2014] hey guys [Wed Jan 29 11:04:11 2014] I have a theorem I'd like to inspect and possibly prove [Wed Jan 29 11:04:20 2014] it's already stated using coq syntax [Wed Jan 29 11:04:38 2014] but I'm new to coq [Wed Jan 29 11:04:44 2014] this is the theorem https://proofmarket.org/problem/view/13 [Wed Jan 29 11:04:57 2014] I have the strong suspicion that the theorem is actually false [Wed Jan 29 11:05:44 2014] and I'm wondering if I can use coq to inspect the definitions. I'd like to 'see' them well enough to first start trying to build a counter-example [Wed Jan 29 11:11:58 2014] cads: Coq isn't going to tell you a ton that isn't visible right from the source. [Wed Jan 29 11:14:32 2014] I understand only a few lines of the source [Wed Jan 29 11:14:32 2014] :) [Wed Jan 29 11:14:56 2014] I'm going to install proof general and see if I can learn how to load the code for now [Wed Jan 29 11:15:03 2014] that's a good start. [Wed Jan 29 13:44:20 2014] what exactly is () and why is its type ()? "Check ()." yields "() : ()" [Wed Jan 29 13:47:01 2014] ah, let me guess: () is tt and () is unit? [Wed Jan 29 13:52:54 2014] Eruquen: probably yes [Wed Jan 29 14:00:21 2014] what is the difference between arrow and "fat arrow? e.g. nat_ind = fun P: nat -> Prop => nat_rect P: \forall (etc etc). CPDT says "We see that this induction principle is defined in terms of a more general principle, nat_rect" ? [Wed Jan 29 14:08:47 2014] I am a beginner in Coq, working through the book Software Foundations [Wed Jan 29 14:09:16 2014] I want to use apply on a hypothesis, but when I do so the original hypothesis is gone [Wed Jan 29 14:09:26 2014] and I need to keep it around to use in the future [Wed Jan 29 14:09:32 2014] How can I do that? [Wed Jan 29 14:09:42 2014] why are so many folks working through SF right at the same time I started o_O [Wed Jan 29 14:10:00 2014] Everyone made the same New Year's resolution :) [Wed Jan 29 14:10:03 2014] dfan: where in the book are you that you're needing this? [Wed Jan 29 14:10:14 2014] Prop.v [Wed Jan 29 14:10:30 2014] I'm working on palindrome_converse [Wed Jan 29 14:10:38 2014] hmm, I am not yet to this point [Wed Jan 29 14:12:55 2014] i'm working on CPDT! [Wed Jan 29 14:16:15 2014] OK, it looks like I can use "assert (eq2 := eq)." to duplicate eq into eq2 [Wed Jan 29 14:16:25 2014] although I don't know if that's idiomatic [Wed Jan 29 14:19:50 2014] I wonder if there's some way to just duplicate a hypothesis [Wed Jan 29 14:20:02 2014] as then you could just 'apply' on the one [Wed Jan 29 14:20:12 2014] That's what that tactic did [Wed Jan 29 14:20:27 2014] but doesn't it then add a subgoal you must prove? [Wed Jan 29 14:20:39 2014] Nope, it just duplicates it [Wed Jan 29 14:20:50 2014] ahh, fair enough [Wed Jan 29 14:51:30 2014] I usually use "generalize H; intro Hdup" or something for duplicating hypotheses [Wed Jan 29 15:21:16 2014] split_combine is throwing me for a loop too now... [Wed Jan 29 15:21:50 2014] I see in some pattern-matching how the only possible result is with a specific branch of that pattern-matching which occurs only when two arguments are both empty lists, but Coq doesn't see this [Wed Jan 29 15:42:29 2014] hodapp: If your problem is "I need Coq to see that X is the only possible result", `inversion` is usually what you want. Figuring out how exactly to phrase the inversion can be hard, however. [Wed Jan 29 15:50:53 2014] is there a command to show intermediate reduction steps for Compute or Eval ... in? [Wed Jan 29 15:53:51 2014] Eruquen: You can restrict which reduction rules are applied by naming them; Eval cbv beta in ... will apply only beta-reduction. [Wed Jan 29 15:54:20 2014] hm, but it will apply them all the way through, won't it? [Wed Jan 29 15:54:52 2014] yes [Wed Jan 29 15:54:57 2014] I don't know how to get it to singlestep [Wed Jan 29 16:06:34 2014] ystael: this might also be a case of Coq being right to not see something :P [Wed Jan 29 16:22:37 2014] to duplicate a hypothesis H: pose proof H as H'. [Wed Jan 29 16:24:16 2014] adelbertc: the fat arrow is related to fun, the syntax is (fun arg => body) to build an anonymous function [Wed Jan 29 16:24:36 2014] adelbertc: the normal arrow is the arrow for types (A -> B) [Wed Jan 29 16:34:37 2014] ystael: Coq doesn't singlestep, I think. You can try "cbv beta at 1" or something, and maybe that will work to some degree? Regardless, you can do it manually with "change ()" or "change () with ()" [Wed Jan 29 16:39:22 2014] jgross_: Unrelated question - has anyone done an Agda port of your category theory library [Wed Jan 29 16:39:25 2014] ? [Wed Jan 29 16:41:59 2014] ystael: No, but https://github.com/copumpkin/categories and https://github.com/pcapriotti/agda-categories/ are decently well-developed (and the latter is HoTT based, though I hear pcapriotti has problems with its notations being too slow). [Wed Jan 29 16:42:54 2014] I recall seeing some people (maybe you?) talking about the proof engineering problems that arise when trying to formalize category theory. [Wed Jan 29 16:43:07 2014] Is there a blog post or article or something anywhere? [Wed Jan 29 16:43:21 2014] people.csail.mit.edu/jgross/category-coq-experience/category-coq-experience.pdf [Wed Jan 29 16:43:40 2014] Will soon be submitted to ITP 2014, and then I'm going to put it on arXiv. [Wed Jan 29 16:45:09 2014] awesome, thank you! [Wed Jan 29 16:45:17 2014] jgross_ http 404... [Wed Jan 29 16:45:35 2014] It's geared at Coq (some of the problems are solved in Agda, or don't come up in Agda, and Agda has some problems that Coq doesn't (such as lack of notation overloading/scoping)), but I've still yet to see a CT library in any proof assistant that does monoidal/enriched/2- categories without being super-slow, so I imagine that much of what I say also applies to other proof assistants. [Wed Jan 29 16:46:26 2014] jgross_ are you sure of the link ? [Wed Jan 29 16:46:32 2014] Anarchos: works for me [Wed Jan 29 16:47:07 2014] Anarchos: really? http://people.csail.mit.edu/jgross/category-coq-experience/category-coq-experience.pdf (http://tinyurl.com/nyqunne) works fine for me in Chrome. ystael, does it work for you? [Wed Jan 29 16:47:16 2014] jgross_ thanks it works for me now [Wed Jan 29 16:47:37 2014] jgross_ oh you work with adam ? [Wed Jan 29 16:47:52 2014] Yes [Wed Jan 29 16:48:45 2014] jgross_ get lucky ;) [Wed Jan 29 16:49:22 2014] jgross_ i will print it tomorrow and read it [Wed Jan 29 16:51:02 2014] Anarchos: get lucky ;) <- What do you mean? [Wed Jan 29 17:00:00 2014] jgross_ you are lucky to work with adam. and it is a joke with daft punk ;) [Wed Jan 29 17:00:09 2014] jgross_ by the way, what is a resk completion ? [Wed Jan 29 17:14:17 2014] Anarchos: It is a yoneda-like saturation operator that turns a precategory into an isomorphic (univalent) category. The relevent paper is one of the references (the one corresponding to that library). [Wed Jan 29 17:15:48 2014] Also, you mean Rezk, not Resk, right? [Wed Jan 29 17:16:22 2014] right [Wed Jan 29 17:26:03 2014] hey guys, what's preferred - coqide, or proof general? [Wed Jan 29 17:28:39 2014] Is there any way to work together on parallel goals? [Wed Jan 29 17:30:06 2014] I have a case where something like eapply mkfoo;try tac;instantiate;try tac;instantiate;try tac solves a goal [Wed Jan 29 17:31:56 2014] hey guys, I'm trying to compile the code available here : http://coq.inria.fr/V8.2pl1/contribs/Markov.markov.html [Wed Jan 29 17:32:00 2014] cads - proof general seems to be the most usable [Wed Jan 29 17:32:30 2014] actually, I guess I don't need the instantiate [Wed Jan 29 17:32:38 2014] I'm in coqide. I get "line 15, characters 7-8: Error: P is already used." [Wed Jan 29 17:32:52 2014] so eapply mkfoo;try tac;try tac; try tac does the job, but eapply mkfoo;repeat tac doesn't work [Wed Jan 29 17:33:04 2014] because that's going independently [Wed Jan 29 17:34:33 2014] it seems like P is already defined [Wed Jan 29 17:34:52 2014] when I delete P from the intros statement, it compiles that section. [Wed Jan 29 17:35:31 2014] there are other sections that have similar "already used" names in their intros statement. [Wed Jan 29 17:36:12 2014] cads: is it always something listed immediately to the right of the goal name as a parameter, without an explicit 'forall' ? [Wed Jan 29 17:37:01 2014] cads: Are you trying to compile with v8.2pl1? [Wed Jan 29 17:37:33 2014] there is for example http://coq.inria.fr/pylons/contribs/files/Markov/v8.4/Markov.markov.html [Wed Jan 29 17:38:12 2014] which for example starts Lemma chicli_pottier_simpson by intros EM. rather than intros P EM. [Wed Jan 29 17:42:10 2014] jgross_: I like the paper, it's nice that you looked at performances [Wed Jan 29 17:44:37 2014] or not looked, but rather talk about them [Wed Jan 29 18:26:35 2014] rks: Thanks [Wed Jan 29 18:27:00 2014] (good timing, I just finished!) [Wed Jan 29 20:58:35 2014] Hey guys, I have a goal term traceL f == traceR f, along with the premises A : Type, x : A, a : id_refl x == id_refl x, f : a == a [Wed Jan 29 20:59:26 2014] can I expand the definition of traceL and traceR? [Wed Jan 29 21:00:11 2014] It seems like I've tried all the tactics and nothing that even substitutes trace* with the definitions [Wed Jan 29 21:02:26 2014] Here are the complete definitions [Wed Jan 29 21:05:45 2014] unfold traceL,traceR. [Wed Jan 29 21:08:07 2014] cads: ^ [Wed Jan 29 21:08:40 2014] how do I unfold notation? [Wed Jan 29 21:08:54 2014] (I now have: ((!id_right_inverse a @ (f[@]id_refl (!a))) @ (!inv_sq a[@]id_refl (!a))) @ [Wed Jan 29 21:08:54 2014] id_left_inverse (!a) == traceR f ) [Wed Jan 29 21:09:57 2014] well, you can do Set Printing All. but be prepared for a deluge of stuff. [Wed Jan 29 21:10:28 2014] Or Set Printing Notations. [Wed Jan 29 21:10:57 2014] er, Unset [Wed Jan 29 21:14:24 2014] wow, unfolding too much gets rid of any legible structure [Wed Jan 29 21:19:17 2014] yup. [Wed Jan 29 21:19:26 2014] compute is even worse. [Thu Jan 30 12:45:39 2014] Under what circumstances might I get the following error? [Thu Jan 30 12:45:44 2014] Error: Impossible to unify "S n1 <= m" with "S n1 <= m". [Thu Jan 30 12:45:52 2014] I'm trying to understand how it is possible for that unification to fail [Thu Jan 30 12:55:04 2014] dfan: might just be an example of a bad/wrong error message. can you give more context? [Thu Jan 30 12:56:00 2014] I am working on the plus_lt theorem in MoreProp.v from Software Foundations [Thu Jan 30 12:56:06 2014] Actually, a simplified version of it [Thu Jan 30 12:56:18 2014] Theorem plus_lt : forall n1 n2 m, n1 + n2 < m -> n1 < m. [Thu Jan 30 12:56:48 2014] Er, I guess I could paste this somewhere, maybe there's too much context to give here [Thu Jan 30 12:58:30 2014] http://pastebin.com/S20yLvjn [Thu Jan 30 12:59:08 2014] Coq 8.4 [Thu Jan 30 13:05:06 2014] dfan: it's because of a conflict between SF's version of le and Coq's built in one. [Thu Jan 30 13:05:14 2014] because they have the same notation, the error looks really weird [Thu Jan 30 13:05:17 2014] Ah! [Thu Jan 30 13:05:21 2014] but actually they're just two different things [Thu Jan 30 13:05:50 2014] So somehow I'm not overriding the built in definition sufficiently? [Thu Jan 30 13:06:14 2014] hmm, well it sure looks like you are... [Thu Jan 30 13:07:36 2014] Maybe it's an lt issue rather an le issue? All the previous proofs worked OK and this is the first one with <= rather than < [Thu Jan 30 13:07:43 2014] Uh, reverse that [Thu Jan 30 13:07:50 2014] yeah it's your definition of lt [Thu Jan 30 13:07:54 2014] you forgot an "-" [Thu Jan 30 13:07:56 2014] :) [Thu Jan 30 13:08:13 2014] er, "=" [Thu Jan 30 13:08:17 2014] Indeed! Thank you [Thu Jan 30 13:08:43 2014] dfan: btw, the way I figured this out was to say "Set Printing All." [Thu Jan 30 13:08:50 2014] I learn much better when I type code in by hand instead of copying and pasting, but this is one occasioncal drawback [Thu Jan 30 13:09:00 2014] then it started saying things like "Peano.le" which was clearly not what you meant. [Thu Jan 30 13:09:13 2014] Great, thanks for the tip [Thu Jan 30 13:09:19 2014] dfan: I'm a big fan of typing stuff out as well [Thu Jan 30 13:10:15 2014] Unlucky for me that it didn't raise a syntax error [Thu Jan 30 13:58:25 2014] Inductiveeq(A:Type)(x : A):AæProp:=eq refl: x =x <---- CPDT says "eq" has both a parameter x that is fixed and un unamed extra argument of the same type [Thu Jan 30 13:58:32 2014] i don't see where the unnamed extra argument appears [Thu Jan 30 13:58:57 2014] Inductive eq(A:Type)(x : A):A -> Prop:=eq_refl: x =x [Thu Jan 30 13:59:56 2014] adelbertc: "A ->" in "A -> Prop" [Thu Jan 30 14:00:20 2014] the parameter x : A ends up on the left side of =, and the A -> argument winds up on the right [Thu Jan 30 14:00:54 2014] hm. so i could see it as "eq" is parameterized over some Type A, takes as an argument a value of A, and returns a function that takes an A and returns a Prop? [Thu Jan 30 14:02:23 2014] somehow yes [Thu Jan 30 14:03:58 2014] eq_refl is a constructor? the only constructor for the 'eq" inductive type? [Thu Jan 30 14:04:58 2014] hm i sorta get it [Thu Jan 30 14:06:28 2014] yes eq_refl is the constructor of the eq inductive type [Thu Jan 30 14:07:26 2014] ok so i see eq_refl is the only way to construct "eq". i see ystael is saying x is on the left side of the infix "eq" notation, but why does A -> argument wind up on the right? or is it doing prolog-like unification [Thu Jan 30 14:10:42 2014] the idea is that for a given type A and an element (a : A), (@eq A a) is a family of inductive types, indexed over a second element of type A [Thu Jan 30 14:11:49 2014] now you see that the only inhabitant of this inductive type family is eq_refl, and it only exists in the family member that has this second element be exactly a [Thu Jan 30 14:12:20 2014] so the type (@eq A a a) has one inhabitant, eq_refl [Thu Jan 30 14:12:30 2014] ohhhhhhh [Thu Jan 30 14:12:39 2014] so the type itself is indexed over the 'a" [Thu Jan 30 14:13:06 2014] is this a form of DT? [Thu Jan 30 14:15:08 2014] hmmm, I haven't thought that through, but I think it is slightly orthogonal to dependent types [Thu Jan 30 14:16:53 2014] hm. [Thu Jan 30 18:13:18 2014] is there a way to Ltac match up to beta-delta-whatever-equivalence? :( [Thu Jan 30 18:13:25 2014] rather than syntactic [Thu Jan 30 18:28:56 2014] Hello. [Thu Jan 30 18:49:14 2014] Ptival: Not easily. You can do something like [match goal with |- appcontext[?E] => unify E ; ... end] or something, or you can run [compute] first. But beta-iota-zeta-delta-eta equivalence matching would be significantly slower, if you're matching things in context. If you know the hnf of the head, you can just run hnf on the hypothesis, check if the head matches, and then try to unify the rest of the term. [Thu Jan 30 19:00:59 2014] jgross: I think I'd care mostly about delta-equivalence [Thu Jan 30 19:01:14 2014] i.e. matching against any definition alias [Thu Jan 30 19:33:27 2014] jgross: thanks for the unify idea though, I'll probably work something up with this [Thu Jan 30 19:49:47 2014] alright, back to banging my head into the desk over split_combine... [Thu Jan 30 20:18:35 2014] Can I declare module functors which derive given signature? [Thu Jan 30 20:18:37 2014] Like this http://pastebin.com/raw.php?i=2QGGgpju [Thu Jan 30 20:26:44 2014] And what difference between ":" and "<:" in "Module A <: Sig."? [Fri Jan 31 05:46:23 2014] how can i intro a variable x from the assumption H: forall x, ...? [Fri Jan 31 06:01:15 2014] confused brb [Fri Jan 31 06:34:50 2014] roosbeef: you... can't. think what H is stating: "for any x that you can provide, H holds" [Fri Jan 31 06:35:25 2014] you can instantiate it for a particular y by applying it... H y [Fri Jan 31 06:35:41 2014] you may be thinking of existentials [Fri Jan 31 13:03:07 2014] so ive got this function [Fri Jan 31 13:03:17 2014] getting the following error [Fri Jan 31 13:03:19 2014] Error: Recursive definition of aterm_of_vterm is ill-formed. [Fri Jan 31 13:03:19 2014] Recursive call to aterm_of_vterm has not enough arguments. [Fri Jan 31 13:03:26 2014] how would one go about fixing that [Fri Jan 31 13:04:20 2014] roosbeef: in the definition are you passing the function you're defining to some other higher-order function? [Fri Jan 31 13:05:31 2014] nah [Fri Jan 31 13:05:39 2014] can you paste the definition then? [Fri Jan 31 13:05:43 2014] sure [Fri Jan 31 13:06:07 2014] its more like the recursion isnt structurally decreasing [Fri Jan 31 13:06:10 2014] or something like that [Fri Jan 31 13:06:21 2014] something like that. [Fri Jan 31 13:06:24 2014] ive tried to apply some induction lemmas from the library im working with [Fri Jan 31 13:06:32 2014] (CoLoR, which is about term rewriting) [Fri Jan 31 13:06:40 2014] but im not sure how as to plug that into my definition [Fri Jan 31 13:06:46 2014] let me paste my def for you though [Fri Jan 31 13:07:26 2014] Fix is usually what you use to define a general recursive function. [Fri Jan 31 13:08:12 2014] you have to uncurry all the arguments that termination depends on and prove there's a well-founded order on that structure. [Fri Jan 31 13:08:37 2014] (since fix only describes unary functions) [Fri Jan 31 13:11:29 2014] full error: http://pastebin.com/gBcGE8pj [Fri Jan 31 13:11:34 2014] full definition: http://pastebin.com/SzkjgNC9 [Fri Jan 31 13:11:52 2014] right before Defined, coq says "No more subgoals" [Fri Jan 31 13:12:12 2014] but when proceeding to wrap things up, coq chokes [Fri Jan 31 13:12:28 2014] roosbeef: you pass aterm_of_vterm to sigmap [Fri Jan 31 13:14:21 2014] ah, thats what you meant? [Fri Jan 31 13:14:42 2014] yeah. you'll need a fancier induction principle for that to work I think. [Fri Jan 31 13:14:48 2014] hm [Fri Jan 31 13:14:49 2014] maybe. [Fri Jan 31 13:14:58 2014] I don't really know what I'm talking about. [Fri Jan 31 13:15:02 2014] :( [Fri Jan 31 13:15:26 2014] I just know that I get that error when I pass the function I'm defining to something else. [Fri Jan 31 13:19:31 2014] hm [Fri Jan 31 13:19:41 2014] i kinda need sigmap though [Fri Jan 31 13:20:00 2014] because the whole function itself is based on the assumption fterm_v_is_wf (that the input term is well formed) [Fri Jan 31 13:20:39 2014] and so, to recursive into its argument list (terms have a tree type structure, so to apply this function its first applied to the head, and then to each subterm) [Fri Jan 31 13:21:08 2014] to recurse into that list, it has to also have the assumption fterm_v_is_wf for that subterm [Fri Jan 31 13:21:16 2014] if that makes sense? So thats what sigmap is used for [Fri Jan 31 13:21:42 2014] the argument list is first converted to a list of pairs [Fri Jan 31 13:22:30 2014] and then sigmap outputs a list of (f st), while providing fterm_v_is_wf st to f each time [Fri Jan 31 13:48:53 2014] jrw, so ive got this lemma which i think is the sort of 'fancy induction principle' youre speaking of [Fri Jan 31 13:48:54 2014] http://color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html#term_rect_forall [Fri Jan 31 13:49:56 2014] kinda lost as to how to modify the current definition to implement that [Fri Jan 31 14:22:44 2014] so im messing with this induction principle [Fri Jan 31 14:22:45 2014] http://pastebin.com/j062CmhH [Fri Jan 31 14:23:24 2014] when i try to apply X, coq tells me "Error: Unable to find an instance for the variable t." [Fri Jan 31 14:23:39 2014] how can i introduce this variable? [Fri Jan 31 14:24:21 2014] roosbeef: apply (X my_t) [Fri Jan 31 14:24:52 2014] Error: The reference my_t was not found in the current environment. [Fri Jan 31 14:25:44 2014] roosbeef: where "my_t" is whatever you want to instantiate t with [Fri Jan 31 14:25:51 2014] well, yes [Fri Jan 31 14:25:57 2014] um [Fri Jan 31 14:26:30 2014] so basically, it should be ANY t such that Inb term_eq_dec t v = true [Fri Jan 31 14:27:07 2014] im not used to forall statements in the assumptions, still confused with that i guess [Fri Jan 31 14:29:00 2014] roosbeef: you can do apply ... with (t := my_t) or you can do (with some limitations), apply (X (t:= my_t)). [Fri Jan 31 14:29:42 2014] "with" syntax is annoying to abstract over with Ltac, for some crappy reason. [Fri Jan 31 14:31:02 2014] apply X with (t := my_t) - Error: The reference my_t was not found in the current environment. [Fri Jan 31 14:31:09 2014] apply (X (t:= my_t)) - Error: Wrong argument name: t. [Fri Jan 31 14:33:29 2014] again, you have to give an actual term for what you want to instantiate t with. [Fri Jan 31 14:36:29 2014] well, yes [Fri Jan 31 14:36:44 2014] but how do i assert such a term [Fri Jan 31 14:37:04 2014] as an assumption [Fri Jan 31 14:37:57 2014] full environment: http://pastebin.com/tFdJDK8r [Fri Jan 31 14:40:52 2014] roosbeef: so what t do you want to use? [Fri Jan 31 14:43:35 2014] v should be the list of arguments in x [Fri Jan 31 14:43:40 2014] t should be any element of v [Fri Jan 31 14:43:48 2014] yeah but what element? [Fri Jan 31 14:43:59 2014] any? [Fri Jan 31 14:44:12 2014] see this is where i get confused :p [Fri Jan 31 14:44:16 2014] that's not how apply works. [Fri Jan 31 14:44:58 2014] i understand but how should one proceed from here? [Fri Jan 31 14:49:18 2014] not sure because I don't understand what you're trying to prove or the context in which you're trying to prove it. [Fri Jan 31 14:49:49 2014] ...one of the only Freenode channels where a line like that isn't associated with stupid IRC debates. [Fri Jan 31 14:50:48 2014] :) [Fri Jan 31 14:51:45 2014] :p [Fri Jan 31 14:55:24 2014] so is it possible to break up v into a head and tail? [Fri Jan 31 14:55:56 2014] so i can use the head to apply X on? [Fri Jan 31 14:56:05 2014] roosbeef: what if it's nil? [Fri Jan 31 14:56:22 2014] hm [Fri Jan 31 14:57:02 2014] well that would not affect the truth of X [Fri Jan 31 14:57:34 2014] but i see your point [Fri Jan 31 14:58:01 2014] its not possible to break up v into cases where v is nil and where v is not nil though? And then feed these into X? [Fri Jan 31 14:58:37 2014] roosbeef: what about destruct? [Fri Jan 31 14:59:34 2014] ah yea [Fri Jan 31 14:59:42 2014] thats starting to look like it [Fri Jan 31 14:59:46 2014] haha i actually did that [Fri Jan 31 15:00:23 2014] but been durring at this for so long that i didnt even see that it was actually producing a desirable effect [Fri Jan 31 15:05:39 2014] thanks a lot guys [Fri Jan 31 15:06:05 2014] gonna have a fresher look at it tomorrow :p [Sat Feb 1 04:52:18 2014] hi [Sat Feb 1 04:52:24 2014] so im using this induction principle on terms [Sat Feb 1 04:52:59 2014] terms have a tree type structure, where a term looks like [string (list term)] [Sat Feb 1 04:53:48 2014] the weird thing with this induction principle http://color.inria.fr/doc/CoLoR.Term.Varyadic.VTerm.html#term_rect_forall [Sat Feb 1 04:54:13 2014] im applying it, and it gives three subgoals, the last of which is asking for a term [Sat Feb 1 04:54:54 2014] but all three of them should be working on that (input) term, not just the last one. The input term is unlinked from the first and second subgoal [Sat Feb 1 04:56:14 2014] these subgoals dont affect each others environments, right? [Sat Feb 1 09:34:58 2014] I have strange issue with building coq from sources. [Sat Feb 1 09:35:18 2014] I do `cd coq; ./configure -local; make`. Anybody know what could I forget to do before `make`? [Sat Feb 1 09:36:06 2014] Strange is that I just can build coq from other directory, but can't from other (with cloned code). Also, I pulled code from git. [Sat Feb 1 09:44:06 2014] Error is that there is no library Rbase; but I see theories/Reals/Rbase.v [Sat Feb 1 10:12:05 2014] Why does coq appear to have forgotten what :: means here? http://paste.debian.net/79641/ [Sat Feb 1 10:39:58 2014] Hmm, a %list fixes it [Sat Feb 1 14:45:37 2014] Bah, looks like even "Program" won't let me provide a class instance after making a definition [Sat Feb 1 14:54:35 2014] Igloo: Are you looking for the 'Existing Instance' command? [Sat Feb 1 14:55:28 2014] Hmm, I don't /think/ so [Sat Feb 1 14:56:39 2014] http://paste.debian.net/79689/ is my problem [Sat Feb 1 14:57:39 2014] I can prove "ConsOK p cxt" from "{notIn : notInContextedPatch p c}", but I can't see a way to convince coq to give me the opportunity [Sat Feb 1 14:58:00 2014] Or at least, not a pleasant way [Sat Feb 1 15:00:15 2014] Program Definition ... := match c as c' return (ConsOK p (match c' with MkContextedPatch _ _ ctx _ _ => ctx end) -> ContextedPatched pu) with ... => fun (H : ConsOK p ctx) => ... end _. [Sat Feb 1 15:04:17 2014] Hmm, I'll read up on the return/with stuff. Thanks [Sat Feb 1 20:24:51 2014] .....Hhhuh. [Sat Feb 1 20:25:07 2014] So pattern matching is just using the elimination rules for a type to extract a value? [Sat Feb 1 20:50:21 2014] I'm trying to prove something seemingly simple: forall (A B C:Type) (f:A->B*C), (fun a => let (x, y) := (f a) in (x, y)) = f. I can prove two related propositions, but can't seem to figure out how to combine them to prove the first goal here. Namely, it's easy to prove forall (A B:Type) (f:A->B), (fun a => let z := f a in z) = f. And also forall (A B:Type) (v:A*B), (let (x, y) := v in (x, y)) = v. But I can't rewrite the first "let" [Sat Feb 1 20:50:48 2014] Any thoughts as to what's going on here? [Sat Feb 1 20:57:21 2014] LinearInterpol: Pattern matching and recursion is more general than that, but the idea is to have a checker that only lets you write what you could write using elimination rules, or other things derived from them. [Sat Feb 1 20:57:39 2014] Sometimes there are bugs with that, though. [Sat Feb 1 21:09:38 2014] uucico: You need functional extensionality to prove that. The "let (x, y) := ..." is syntactic sugar for pattern matching, and there's no rule (yet! see https://coq.inria.fr/bugs/show_bug.cgi?id=3119) for reducing "let (x, y) := v in (x, y)" to "v" judgmentally, while there is a judgmental rule for "let x := v in x" -> "v". [Sat Feb 1 21:18:00 2014] ah, interesting! i recall briefly seeing "functional extensionality" somewhere in coq'art.. so even though i have a lemma that says (let (x, y) := v in (x, y)) = (v), coq can't use it inside the "fun a => ..."? does this mean coq generally doesn't allow rewrite'ing of expressions inside a fun body? [Sat Feb 1 21:23:00 2014] That's correct. Functional extensionality is "(forall x, f x = g x) -> f = g". [Sat Feb 1 21:28:05 2014] thanks! [Sat Feb 1 21:58:19 2014] the lack of functional extensionality makes it pretty awkward to reason about something like state monads, which are all functions. what's the usual solution to this, if any? avoid monads? use a different equality definition for which functional extensionality holds in Coq? introduce functional extensionality as an axiom? [Sat Feb 1 22:16:57 2014] You could work up to the equivalence relation defined by functional extensionality. [Sat Feb 1 22:17:16 2014] Just use (forall x. f x = g x) as your equivalence type. [Sat Feb 1 22:17:48 2014] It is less convenient than equality for some things, but maybe it won't matter. [Sat Feb 1 22:18:36 2014] Introduce functional extensionality as an axiom. Or use setoids. Or you can wait until Coq 8.6 (or 9.0? 9.1? 10?) which will hopefully have computational functional extensionality. (You can prove functional extensionality in https://github.com/barras/coq/tree/hit by http://homotopytypetheory.org/2011/04/04/an-interval-type-implies-function-extensionality/ using "Inductive Interval := zero | one with paths := seg : zero = one." Or you can [Sat Feb 1 22:18:36 2014] introduce functional extensionality as the axiom that f_equal_dep is an equivalence, which gives you enough rope to compute with functional extensionality (though rather tediously). [Sat Feb 1 22:20:21 2014] makes sense; thanks again. [Sun Feb 2 07:23:06 2014] Using vim plugins CoqIDE (http://goo.gl/z7uYZD) or Coquille (http://goo.gl/bvFemZ), Coq responds "Incorrect query" when trying to send a command to Coqtop. My Coq is 8.4pl3. anyone with a solution? [Sun Feb 2 07:34:02 2014] They've been changing the interaction protocol recently (though I thought they left it backwards compatible in 8.4). Try 8.4pl2? [Sun Feb 2 07:35:53 2014] Ok, I will try that. [Sun Feb 2 07:46:41 2014] If there an equivalent to "match e with C x y" which keeps a hypothesis "e = C x y"? [Sun Feb 2 07:48:10 2014] "match e as e' return e = e' -> ... with C x y => ... end eq_refl" [Sun Feb 2 07:48:51 2014] Why are there 2 ...s? [Sun Feb 2 07:49:19 2014] Alternatively, "Goal . destruct e. Show Proof." and you can see what kind of proof term Coq creates to do it. [Sun Feb 2 07:50:06 2014] The first ... is the return type (if you didn't need a "return" clause before, you can leave it as an underscore), the second is the return clause/term. [Sun Feb 2 07:51:17 2014] Erm, I guess in this case, you'd want "case_eq e" not "destruct e". [Sun Feb 2 07:55:21 2014] Hmm, I'm getting this: http://paste.debian.net/79770/ I guess this is the Program stuff getting in the way? [Sun Feb 2 08:09:01 2014] No, you need to replace "c" with "fun H => c" and "addToContext ..." with "fun H => addToContext ...". [Sun Feb 2 08:09:51 2014] Ah, ta [Sun Feb 2 08:10:35 2014] Hmm, that seems to create more obligations that I can't prove [Sun Feb 2 08:10:59 2014] e.g. http://paste.debian.net/79772/ [Sun Feb 2 08:12:42 2014] (where ps and ps' are the things that the "return" says are equal) [Sun Feb 2 08:13:13 2014] I think Program might be messing you up. Use "Fixpoint . refine match ...." instead (you'll have to stick in underscores for all of the arguments to the recursive call, explicitly). [Sun Feb 2 08:14:26 2014] "Fixpoint ." gives me "Error: Cannot do a fixpoint on a non inductive type." [Sun Feb 2 08:26:31 2014] Which I assume is because ContextedPatch is in Type, but AFAICS I can't put it in Set instead [Sun Feb 2 08:35:09 2014] Fixpoint {struct . [Sun Feb 2 08:35:46 2014] It's just telling you that without a "match" it can't figure out ahead of time what you're going to be matching on (inducting on) [Sun Feb 2 08:43:19 2014] Aha, thanks! [Sun Feb 2 08:48:04 2014] OK, I think I might have everything working now. Thanks for all your help! [Sun Feb 2 11:03:58 2014] inside of definition part of Inductive ty := ... I want to use "tyenv" instead of (id -> option ty), is there a way to do that? [Sun Feb 2 11:29:18 2014] osa1: I think you can "with Notation ..." with your definition [Sun Feb 2 11:31:12 2014] but is this a notation? I'm actually defining this as a Definition but I just want to use that definition inside definition of ty too .. [Sun Feb 2 11:31:28 2014] hmm wait. yeah "with notation" makes sense [Sun Feb 2 11:31:52 2014] I also need to use reserved notation, right? [Sun Feb 2 11:32:52 2014] I think so yes [Sun Feb 2 11:33:35 2014] I'll try in a minute. [Sun Feb 2 11:36:37 2014] I'm using functions as type environments in my language definition, is there a problem with having extensional equality as an axiom? [Sun Feb 2 11:38:32 2014] oh wait, we already have extensional equality in stdlib! [Sun Feb 2 11:55:30 2014] I don't understand how does induction work. it forgets too many things. if I use "remember" than most cases can't be proved by "auto" ... [Sun Feb 2 11:55:39 2014] s/than/then [Sun Feb 2 11:59:03 2014] hmm. I solved that cases by using inversion ...;subst. [Sun Feb 2 11:59:06 2014] nice. [Sun Feb 2 12:10:56 2014] yeah induction forgets about indices that are not just variables :( [Sun Feb 2 12:10:58 2014] inversion does not [Sun Feb 2 12:55:11 2014] is there a way to apply a function to both sides of an equation? [Sun Feb 2 12:56:00 2014] like, I have term1 = term2 as goal and I want to have fun term1 = fun term2. [Sun Feb 2 13:03:06 2014] whatever. I proved it by changing my definitions a bit. [Sun Feb 2 13:04:10 2014] osa1: I think you can "apply f_equal with (f := fun) in H"? [Sun Feb 2 13:04:16 2014] unless I got it backwards [Sun Feb 2 13:22:10 2014] Ptival: thanks, I'll try. I don't need it anymore, though, because I changed some of my definitions instead and proved my theorem that way. [Sun Feb 2 14:39:46 2014] osa1: various reasons for not assuming funtional extensionality: 1.) if you do not use it, you have proven a stronger theorem 2.) if programs rely on it, they won't compute 3.) more axioms, bigger chance on them being unsound (see the prop ext issue of a while ago), however the "chance of you actually using it as a paradox" is of cource rather small. [Sun Feb 2 14:41:09 2014] robbert: thanks. in point 2 do you mean if I ever run my program? [Sun Feb 2 14:46:48 2014] osa1: well, whenever a pattern match on the functional extensionality axiom appears in your program, it cannot be contracted. [Sun Feb 2 14:47:21 2014] but if you only use it at careful places, it may very well be dead code, and your program may run fine [Sun Feb 2 14:49:13 2014] robbert: what do you mean by "it cannot be contracted"? does that effect type checking? [Sun Feb 2 14:49:59 2014] osa1: it just means that match functional_extensionality FOO with refl => BAR end cannot be reduced [Sun Feb 2 14:50:20 2014] no, in principle it does not affect type checking [Sun Feb 2 14:50:32 2014] then it works for me :-) [Sun Feb 2 14:50:50 2014] I'm just formalizing a language, I don't think I'll ever need to run something. [Sun Feb 2 18:15:54 2014] is it guaranteed that any gallina function will eventually halt? [Sun Feb 2 18:17:48 2014] googled it, looks like it is [Mon Feb 3 00:21:04 2014] [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup [Tue Feb 11 15:12:33 2014] Hello [Tue Feb 11 15:22:46 2014] Suppose I declared "Module Type Interface. Definition D : Type. admit. Defined. Parameter P : Type. End Interface." and want to use D in my module "Module Implementation <: Interface. Definition P := D. End IMplementation.". [Tue Feb 11 15:22:48 2014] How to do it? [Tue Feb 11 15:23:56 2014] Or should I separate common things in other module-argument and make Implementation to be functor? [Tue Feb 11 15:34:54 2014] But seems I can't (in my partial case, I need mutual recursion between defined data and parameters in Interface). [Tue Feb 11 15:55:43 2014] I found that I can do that with "Declare Module Export X : Interface.". [Tue Feb 11 15:56:09 2014] But I found also that I must dublicate all data defined in Interface. [Tue Feb 11 15:56:12 2014] How to avoid this? [Wed Feb 12 11:44:13 2014] Hello. [Wed Feb 12 11:45:09 2014] Is there library function for constructing such proposition: "forall X (l : list X), all P l" with given (P : X -> Prop)? [Wed Feb 12 11:45:31 2014] Or at least "forall x, member x l". [Wed Feb 12 12:03:22 2014] mem_ind or something [Wed Feb 12 12:08:24 2014] ianjneu, didn't find that; but found "Forall". [Wed Feb 12 12:08:38 2014] "Inductive Forall {A} (P:A->Prop) : list A -> Prop := ..." [Wed Feb 12 12:12:37 2014] oh that's what you meant. [Wed Feb 12 12:12:44 2014] Ya, Forall is good. [Wed Feb 12 15:35:28 2014] hi guys. I have this hypothesis: "H : set_add eq_id_dec h2 (set_union eq_id_dec [] t2) = []" and I want to eliminate this case since this is not true. How can I do that? inversion doesn't provide anything useful. [Wed Feb 12 15:35:54 2014] theorem I'm trying to prove is this: set_union eq_id_dec set1 set2 = nil <-> set1 = nil /\ set2 = nil. [Wed Feb 12 15:35:59 2014] forall set1 set2 [Wed Feb 12 15:38:06 2014] aha! I have H: false [Wed Feb 12 15:38:09 2014] now how can I use this? [Wed Feb 12 15:38:40 2014] inversion H. [Wed Feb 12 15:38:41 2014] nice. [Wed Feb 12 16:36:43 2014] wtf?!?! I can't apply minus_n_O because last character is not actually O or 0 ?? [Wed Feb 12 16:37:04 2014] duh. I think I need to use proper font. [Wed Feb 12 16:37:35 2014] hah [Wed Feb 12 16:38:50 2014] I hate functions. can anyone help me solving this: http://lpaste.net/99837 ? [Wed Feb 12 16:53:10 2014] osa1: what does simpl in H3 do? [Thu Feb 13 12:12:40 2014] Hello. [Thu Feb 13 12:12:51 2014] Is there analogue of "exissts" for Type instead Prop? [Thu Feb 13 12:13:19 2014] I want to construct sort of heterogeneous list. [Thu Feb 13 12:13:50 2014] (Without declaring extra type.) [Thu Feb 13 12:20:48 2014] Rc43: see sigT in Coq.Init.Specif [Thu Feb 13 12:24:24 2014] in this case, if P is a type family indexed by A, you probably want list (sigT A P). [Thu Feb 13 12:29:36 2014] ystael, seems to be what I want; but I can't use it with A = Type :/ [Thu Feb 13 12:30:09 2014] I have Definition Tag1 : Type and Definition Tag2 : Type. And I mark elements of list with this tags. [Thu Feb 13 12:30:54 2014] Seems that this is impossible. [Thu Feb 13 12:31:16 2014] are Tag1 and Tag2 types each of which has several values, or do you have only two tag values? [Thu Feb 13 12:31:59 2014] Pretty sure you don't want A = Type, as that would mean your type family is indexed by Type (i.e., for *every* type you have a defined fiber type) [Thu Feb 13 12:33:45 2014] Ye, I already fixed my tags to "Inductive Tag := Tag1 | Tag2". [Thu Feb 13 12:33:59 2014] But now I found that sigT works with Type, but not Set. [Thu Feb 13 12:34:43 2014] Oh, or everything is ok, not sure yet. [Thu Feb 13 12:35:35 2014] Rc43: Set is included in Type, it behaves as if Set were Type at universe level 0 [Thu Feb 13 12:35:52 2014] Also if your tag type no longer varies between values, you don't need sigma types at all [Thu Feb 13 12:37:20 2014] ystael, it varies between Tag1 and Tag2; list contains elements Element Tag1 or Element Tag2. [Thu Feb 13 12:37:39 2014] ah, I see [Thu Feb 13 12:37:52 2014] so yeah, it should be sigT Tag Element, right? [Thu Feb 13 12:38:02 2014] I am trying to define HList := list (sigT Tag (fun t => Element t)), but coq says that it expects only ? -> Type. [Thu Feb 13 12:38:10 2014] Aaaa [Thu Feb 13 12:38:15 2014] Just Element :) [Thu Feb 13 12:39:08 2014] well, that shouldn't make a difference I think? [Thu Feb 13 12:39:08 2014] But Coq still complains, it says that it expects only function. [Thu Feb 13 12:39:15 2014] paste the full error somewhere? [Thu Feb 13 12:40:34 2014] Error: the term "Tag" has type "Set" while it is expected to have type "?50 -> Type". [Thu Feb 13 12:40:54 2014] If I write "sigT Element" it is ok, but that is not what I want. [Thu Feb 13 12:40:57 2014] no, I mean the entire set of definitions [Thu Feb 13 12:41:27 2014] lpaste.net [Thu Feb 13 12:43:47 2014] http://pastebin.com/raw.php?i=Xmr8mVg6 [Thu Feb 13 12:46:24 2014] Oh [Thu Feb 13 12:46:57 2014] It looks like the A argument of sigT is implicit; that's not super obvious from the library source [Thu Feb 13 12:47:13 2014] it just has Set Implicit Arguments at the top which I guess makes it maximally implicit [Thu Feb 13 12:47:20 2014] so sigT Element is all you need to write [Thu Feb 13 12:47:22 2014] Ye, I thought implicit arguments must be in { }. [Thu Feb 13 12:47:26 2014] to write it out in full, @sigT Tag Element [Thu Feb 13 12:47:45 2014] Hmm, if sigT is what I want, then how to construct element? [Thu Feb 13 12:47:52 2014] *sigT Element [Thu Feb 13 12:48:40 2014] Oh [Thu Feb 13 12:48:49 2014] existT Element Left left [Thu Feb 13 12:48:55 2014] so long [Thu Feb 13 12:51:24 2014] Seems I need some aliases. [Thu Feb 13 13:07:45 2014] http://pastebin.com/raw.php?i=dF2sPpLe [Thu Feb 13 13:07:55 2014] Why there is Error about non-exhaustive pattern matching? [Thu Feb 13 13:09:40 2014] (We can't provide this possible branches with any element, because L requires Left element e.g.) [Thu Feb 13 15:10:41 2014] Anybody knows if there is lib similar to haskell's lenses? [Thu Feb 13 15:11:33 2014] I described some structure with Coq, but it requires a lot of code to take a field from the bottom of structure. [Thu Feb 13 15:31:26 2014] I don't. [Sat Feb 15 08:18:41 2014] I don't suppose there are any coq bugzilla folk around? When I try to add a comment to #2689 I get an error "You must select a target milestone for bug 2689 if you are going to accept it. Part of accepting a bug is giving an estimate of when it will be fixed.", but I can't set a milestone [Sat Feb 15 08:22:47 2014] :/ no idea. Probably jgross knows. [Sat Feb 15 08:27:34 2014] Hah, the "Help" link takes me to https://coq.inria.fr/bugs/docs/en/html/query.html#list [Sat Feb 15 08:34:05 2014] hi, is there a way to force coq to forget the default library? [Sat Feb 15 08:52:32 2014] kamatara: -nois [Sat Feb 15 08:53:05 2014] robbert, o it does not work, because i ould still write Require Import ... and the thing will be found and load [Sat Feb 15 08:53:16 2014] that's what I want to prevent [Sat Feb 15 08:53:32 2014] I 'm looking for a 100% virgin environment [Sat Feb 15 08:58:47 2014] kamatara: rm theories in the coq root? [Sat Feb 15 09:00:04 2014] robbert, ..., it's really the only solution? coqc is the only compiler which does not provide that kind of switch? [Sat Feb 15 09:00:56 2014] I have no idea, but I don't think a more extreme switch than -nois exists [Sat Feb 15 09:02:33 2014] that's sad [Sat Feb 15 09:02:45 2014] but thank for the help [Sat Feb 15 09:25:42 2014] kamatara: by the way, there has been quite some discussion about disabling the recursive Require Import, see https://sympa.inria.fr/sympa/arc/coq-club/2013-12/msg00099.html [Sat Feb 15 09:25:52 2014] maybe that would be of help (eventually) [Sat Feb 15 10:02:19 2014] http://www.cis.upenn.edu/~bcpierce/sf/Prop.html#lab180 - does anyone know a simple solution to the final (Optional, harder) one there? [Sat Feb 15 10:03:02 2014] I'm trying to work through it, but keep getting nowhere; induction on either piece of evidence seems to lead me nowhere [Sat Feb 15 10:13:32 2014] hodapp, do you know how to do the proofs with you pen and your paper ? [Sat Feb 15 12:12:17 2014] let's say I have this as goal: "length tl = n - 1" can I apply S to both sides of equation and have S (length tl) = S (n - 1) as goal? [Sat Feb 15 12:24:23 2014] That only works if n <> 0 [Sat Feb 15 12:26:47 2014] why? [Sat Feb 15 12:27:02 2014] yeah right [Sat Feb 15 12:27:14 2014] let's assume I have H: n <> 0 [Sat Feb 15 12:27:26 2014] and I want to apply S to both sides of the equation. [Sat Feb 15 12:32:48 2014] there must be an axiom stating that any arrow is a morphism for = somewhere. [Sat Feb 15 12:32:51 2014] ianjneu: uhm, S is injective, so that just works [Sat Feb 15 12:32:57 2014] @check eq_add_S [Sat Feb 15 12:32:58 2014] oups; [Sat Feb 15 12:33:04 2014] eq_add_S : ∀ n m : nat, S n = S m → n = m [Sat Feb 15 12:33:30 2014] going from S (n - 1) to n requires n <> 0 [Sat Feb 15 12:34:08 2014] check @f_equiv [Sat Feb 15 12:34:28 2014] kamatara, is that what you mean? [Sat Feb 15 12:34:43 2014] @check f_equiv [Sat Feb 15 12:34:44 2014] error: Error: The reference f_equiv was not found in the current environment. [Sat Feb 15 12:34:49 2014] @check f_equal [Sat Feb 15 12:34:49 2014] f_equal : ∀ (A B : Type) (f : A → B) (x y : A), x = y → f x = f y [Sat Feb 15 12:34:53 2014] robbert, forget what I said (it's just that I was thinking about n = 0 and not n <> 0) [Sat Feb 15 12:35:34 2014] is there a way to find axiom by their type (like with hoogle)? [Sat Feb 15 12:36:08 2014] SearchPattern [Sat Feb 15 12:36:27 2014] SearchPattern (S ?x = S ?y -> ?x = ?y). [Sat Feb 15 12:36:35 2014] for example [Sat Feb 15 12:38:14 2014] nice, thx [Sat Feb 15 12:38:31 2014] And by the way, this result about injectivity of S is a theorem (Coq is strong enough to prove it), not an axiom :) [Sat Feb 15 12:42:08 2014] robbert, impossible, that's the definition of injectivity [Sat Feb 15 12:43:00 2014] (coq is not more powerful than maths) [Sat Feb 15 12:48:02 2014] kamatara: no, that is the rule of Leibniz. [Sat Feb 15 12:48:38 2014] ianjneu, ho please look at your axioms, and you'll see that somewhere you have an axiom equivalent to that, that's why you think it's a theorem and not an axiom [Sat Feb 15 12:49:13 2014] kamatara: Coq can prove the Peano axioms [Sat Feb 15 12:49:14 2014] It's a theorem by induction on (x = y) [Sat Feb 15 12:49:19 2014] robbert, no it can't [Sat Feb 15 12:49:28 2014] when you use inductive, coq define the axioms for you [Sat Feb 15 12:49:52 2014] No, it does not [Sat Feb 15 12:50:04 2014] those induction principles are defined in terms of fix/match [Sat Feb 15 12:50:07 2014] which are primitives in Coq [Sat Feb 15 12:50:13 2014] @check nat_ind [Sat Feb 15 12:50:14 2014] nat_ind : ∀ P : nat → Prop, P 0 → (∀ n : nat, P n → P (S n)) → (∀ n : nat, P n) [Sat Feb 15 12:50:20 2014] Do print nat_ind [Sat Feb 15 12:50:22 2014] isn't it the gfucking axiom of recurrence ? [Sat Feb 15 12:50:56 2014] @check nat_rect [Sat Feb 15 12:50:57 2014] nat_rect : ∀ P : nat → Type, P 0 → (∀ n : nat, P n → P (S n)) → (∀ n : nat, P n) [Sat Feb 15 12:51:03 2014] @print nat_rect [Sat Feb 15 12:51:19 2014] :| [Sat Feb 15 12:51:31 2014] Ok it's not axiom, because it's inductive wich come with the axioms builtin [Sat Feb 15 12:51:33 2014] roosterbot: okay fine, don't print the term. [Sat Feb 15 12:51:41 2014] nat_rect = [Sat Feb 15 12:51:41 2014] λ (P : nat → Type) (f : P 0) (f0 : ∀ n : nat, P n → P (S n)), [Sat Feb 15 12:51:41 2014] fix F (n : nat) : P n := [Sat Feb 15 12:51:41 2014] match n as n0 return (P n0) with [Sat Feb 15 12:51:41 2014] | 0 => f [Sat Feb 15 12:51:42 2014] | S n0 => f0 n0 (F n0) [Sat Feb 15 12:51:42 2014] end [Sat Feb 15 12:51:43 2014] : ∀ P : nat → Type, P 0 → (∀ n : nat, P n → P (S n)) → (∀ n : nat, P n) [Sat Feb 15 12:51:43 2014] kamatara: also false. [Sat Feb 15 12:51:55 2014] inductive is a hiddent way to introduce axioms [Sat Feb 15 12:52:20 2014] kamatara: only if you consider function definitions axioms. [Sat Feb 15 12:52:48 2014] that is, the axiom that function symbol f is equal to its body. [Sat Feb 15 12:52:58 2014] inductive is magic [Sat Feb 15 12:53:02 2014] no it's not. [Sat Feb 15 12:53:08 2014] which provides a way to have recurrence hidden [Sat Feb 15 12:53:42 2014] recurrence is a fucking axiom, it's proved, so if it's a theorem in coq, it's because there is an equivalent axiom sopmewhere, otherwise we are facing a contradictino [Sat Feb 15 12:53:44 2014] QED. [Sat Feb 15 12:54:05 2014] The structure of the grammar of Inductive allows Coq to automatically produce an induction theorem. [Sat Feb 15 12:54:10 2014] those axioms are hidden in inductive [Sat Feb 15 12:54:14 2014] sorry, but if you start calling things a "fucking axiom", I do not really consider a discussion with you seriously [Sat Feb 15 12:54:28 2014] robbert, i proved what i said [Sat Feb 15 12:54:37 2014] induction is an axiom, even in coq [Sat Feb 15 12:54:50 2014] it's just coq come with a built in induction axiom [Sat Feb 15 12:54:50 2014] induction is a tactic. [Sat Feb 15 12:55:19 2014] read on the history of type theory/Coq, back in the days Coq was based on the Calculus of Constructions, where one could define data types like the natural numbers using second order encoding [Sat Feb 15 12:55:19 2014] Mmm, calling induction an axiom is misrepresenting it a little. [Sat Feb 15 12:55:38 2014] ezyang, a scheme of axioms if you want [Sat Feb 15 12:55:40 2014] then, indeed, you could not prove injectivity of S, induction, and so on [Sat Feb 15 12:55:49 2014] robbert, I could use it [Sat Feb 15 12:56:07 2014] As thus, they added inductive data types to the system, which made it possible to prove those properties in the system [Sat Feb 15 12:56:08 2014] you can prove that S O = O => false [Sat Feb 15 12:56:14 2014] without relying on axioms [Sat Feb 15 12:56:40 2014] robbert, inductive type are a camouflaged way to introduce axioms [Sat Feb 15 12:57:11 2014] No, they are not, they are part of the system. Axioms are things you introduce using the Parameter command [Sat Feb 15 12:57:53 2014] If you have Gamma |- M : A, Gamma are the axioms, you can prove Gamma |- 1 /= 0 with Gamma = empty [Sat Feb 15 12:58:05 2014] Axioms tend not to have computation rules [Sat Feb 15 12:58:08 2014] axiom are thing I can't prove using modus ponens, absurd, and the few laws about forall [Sat Feb 15 12:58:13 2014] you won't redefine mathematics [Sat Feb 15 12:58:32 2014] I'm done feeding the troll. [Sat Feb 15 12:58:40 2014] ezyang: indeed! [Sat Feb 15 12:59:23 2014] for mathematicians you'll be joke when you will try to affirm that induction is not an "axiom" [Sat Feb 15 12:59:42 2014] call me troll if you want, but thet truth is mathematicians agree with me, not you [Sat Feb 15 13:00:34 2014] it depends on what form induction takes. It can be reconstructed from more basic notions. [Sat Feb 15 13:00:37 2014] I mean, what you're saying is all true in set theory, but type theory works differently. [Sat Feb 15 13:01:54 2014] ezyang, what a joke [Sat Feb 15 13:01:59 2014] go explain that to mathematicians [Sat Feb 15 13:02:07 2014] you're just a kiddo for me [Sat Feb 15 13:02:08 2014] nothing wrong with redefining mathematics, mathematicians have beend doing if for millenia [Sat Feb 15 13:02:23 2014] if->it [Sat Feb 15 13:02:26 2014] ijp, yes but each time they agree on the fact that induction is an "axiom" [Sat Feb 15 13:02:55 2014] You're in a channel of mathematicians. [Sat Feb 15 13:03:33 2014] ianjneu, OK, Isn't induction an "axiom" in mathematics ? [Sat Feb 15 13:03:42 2014] we'll see :) [Sat Feb 15 13:04:11 2014] It is an axiom in classical first order logic [Sat Feb 15 13:04:22 2014] o.O [Sat Feb 15 13:04:33 2014] copumpkin: long time no see [Sat Feb 15 13:04:46 2014] hi :) [Sat Feb 15 13:04:46 2014] here to troll :P [Sat Feb 15 13:05:07 2014] not often you see trolls in these sorts of channels [Sat Feb 15 13:05:15 2014] last I remember was a coq troll in #agda [Sat Feb 15 13:05:47 2014] so a guy come, say what mathematicians say since a long time, and for you that guy is a troll [Sat Feb 15 13:05:51 2014] you're funny guys [Sat Feb 15 13:05:51 2014] copumpkin: presumably they don't appear because trolling is not constructive [Sat Feb 15 13:05:55 2014] copumpkin: I think HoTT has attracted more amateurs to explore the area. This often leads to trolling. [Sat Feb 15 13:06:01 2014] fair enough [Sat Feb 15 13:06:08 2014] ianjneu: ha ha :) [Sat Feb 15 13:06:33 2014] today I know why mathematician fdon't use such a tool [Sat Feb 15 13:06:39 2014] What's the story? "The September that never ended"? [Sat Feb 15 13:06:44 2014] the community is not serious and mature for math [Sat Feb 15 13:06:48 2014] yes yes [Sat Feb 15 13:06:49 2014] move along [Sat Feb 15 13:07:06 2014] I quit before the ban [Sat Feb 15 13:07:12 2014] you won't get banned [Sat Feb 15 13:07:16 2014] it just won't be productive [Sat Feb 15 13:07:19 2014] ciao guys, learn math and we will argue more seriously nn the future [Sat Feb 15 13:07:34 2014] What a douche ;) [Sat Feb 15 13:07:46 2014] Proof assistants are just really hard to use. The status quo in the mathematics community does not pressure people to spend the time to certify their proofs with these tools. [Sat Feb 15 13:09:11 2014] Well, the thing here is that "actual mathematicians" (whomever I may address using that), don't really care about logic/foundations. But when using a proof assistant, it becomes quite a big deal. [Sat Feb 15 13:09:48 2014] robbert: I'm sure they care, just not when it comes to getting papers out. [Sat Feb 15 13:10:26 2014] I'm tired of overgeneralized speculation and no-true-scotsman arguments though. [Sat Feb 15 13:10:31 2014] I'm going back to my proof. [Sat Feb 15 13:11:26 2014] Well, my point was more they do not really care about whether to be classical/constructive, having choice, intensional/extensional equality, setoids, ... [Sat Feb 15 13:12:51 2014] for an appropriate, "they," sure [Sat Feb 15 13:13:48 2014] Hence the quotes arround "actual mathematicians" in my previous message :) [Sat Feb 15 13:42:56 2014] is there a nice simple example of a coq proof that uses integers? I'm really new to this :( [Sat Feb 15 13:44:53 2014] Olive`: omega is really great at knocking out simple obligations. [Sat Feb 15 13:45:48 2014] is that part of the standard library? [Sat Feb 15 13:46:15 2014] ZArith. [Sat Feb 15 13:47:46 2014] thank you! I'll look there [Sat Feb 15 14:07:24 2014] Igloo, ianjneu: I've never seen that error message before. If you tell me what you want to comment (e.g., by gist or something), I can try to comment for you? Alternatively, maybe there was a change since you loaded the page, and Pierre Letouzey assigned the bug to himself, but your comment page didn't know about it, and so bugzilla assumed that you were unassigning the bug to him when you commented? If you reload the page and try to comment, [Sat Feb 15 14:07:24 2014] does it work now? [Sat Feb 15 14:30:26 2014] ianjneu: I ended up using the definition of Z from Coq.Numbers.BinNums [Sat Feb 15 15:07:18 2014] hodapp: did you get that subsequence one? [Sat Feb 15 15:24:54 2014] apparently #coq is not drama-exempt? [Sat Feb 15 15:24:56 2014] * scrolls up [Sat Feb 15 15:26:59 2014] hodapp why ? [Sat Feb 15 15:33:04 2014] BECAUSE I BELIEVE IN FAIRY-TALES SOMETIMES, YOU DON'T NEED TO REMIND ME [Sat Feb 15 15:33:07 2014] * runs away [Sat Feb 15 15:34:07 2014] jrw: I have not yet, but I've not had a lot of time since I posted to look at it. [Sat Feb 15 15:37:21 2014] hodapp: the hint they give is very accurate, if also very vague. in response to your original "does anyone have a clean way...", if you pick your induction correctly, it's pretty clean. [Sat Feb 15 15:38:35 2014] what kinds of cool things are you all working on? [Sat Feb 15 15:38:39 2014] jrw: I'd suspected all of those things upon starting the problem, but seem stuck anyhow... [Sat Feb 15 15:38:54 2014] Olive`: We're all learning more math so that we are qualified to talk to katamara. [Sat Feb 15 15:39:02 2014] lol [Sat Feb 15 15:39:05 2014] hehehe [Sat Feb 15 15:39:06 2014] hodapp: what have you tried inducting on? [Sat Feb 15 15:39:26 2014] jrw: mostly the two pieces of evidence. [Sat Feb 15 15:39:38 2014] jrw: I don't entirely see how inducting on either list can get me anywhere. [Sat Feb 15 15:39:38 2014] hodapp: try something else :) [Sat Feb 15 15:40:09 2014] there are two "pieces of evidence" and three lists, no? I suggest you try all of them. [Sat Feb 15 15:40:24 2014] what is a piece of evidence? A proposition? [Sat Feb 15 15:40:34 2014] I wasn't sure what term to apply. [Sat Feb 15 15:40:50 2014] you used the phrase first, I assumed you had a definition in mind :p [Sat Feb 15 15:40:51 2014] Olive`: I'm just going through the Software Foundations book. I idle here because when the rest of the channel talks it reminds me of how much I don't know. [Sat Feb 15 15:41:00 2014] I just meant one of the two "subsequence" hypotheses [Sat Feb 15 15:41:00 2014] aw [Sat Feb 15 15:41:07 2014] trust me I probably know less than you [Sat Feb 15 15:41:33 2014] jrw: well, it's things like 'subseq l1 l2', things which Coq allows as hypotheses [Sat Feb 15 15:41:44 2014] yep [Sat Feb 15 15:42:34 2014] Olive`: my degree is in EE, and I do some embedded programming... one thing that piques my interest a little is if I'd be able to leverage Coq's code generation for a fairly simple embedded kernel. [Sat Feb 15 15:43:06 2014] but once I get through this book, I was going to go either to HoTT or CPDT, and folks have dominantly recommended the latter :P [Sat Feb 15 15:43:18 2014] hodapp that's cool! I just started learning about electronics recently [Sat Feb 15 15:44:41 2014] Olive`: what brings you here? [Sat Feb 15 15:45:10 2014] I got interested in type theory and proving things about programs [Sat Feb 15 15:52:31 2014] that's sort of how I landed here. I was dabbling a bit with functional programming, particularly Haskell, and the channel mentioned some things like Agda [Sat Feb 15 15:52:41 2014] and somehow this led me to SF [Sat Feb 15 16:18:48 2014] ezyang: was that for me: "I mean, what you're saying is all true in set theory, but type theory works differently." ? [Sat Feb 15 16:19:04 2014] (sorry for very late response) [Sat Feb 15 16:50:12 2014] osa1: I believe he was talking to the troll about induction always being an axiom. [Sat Feb 15 16:57:06 2014] ah, okay. [Sat Feb 15 18:00:56 2014] I don't suppose anyone has an example of how to make an OrderedType in which eq is Leibniz equality handy? [Sat Feb 15 19:08:20 2014] "Error: refine: proof term contains metas in a product." what does this mean? [Sun Feb 16 07:14:09 2014] hi [Sun Feb 16 07:14:15 2014] should this be trivial? [Sun Feb 16 07:14:17 2014] Lemma layer_compare_wf' : forall h1, forall h2, subfterm_order h1 h2 -> Acc subfterm_order h1. [Sun Feb 16 09:06:14 2014] any tips on proving "rev (rev list) = list"? [Sun Feb 16 09:08:56 2014] nm, found on google [Sun Feb 16 10:19:44 2014] this looked like a very basic question to me https://sympa.inria.fr/sympa/arc/coq-club/2014-02/msg00150.html but apparently it's not .. does anyone here have any ideas? [Sun Feb 16 10:44:57 2014] it is simple. Injectivity of constructors. [Sun Feb 16 10:46:59 2014] injectivity if you need to go S x = S y -> x = y, if you need to go x = y -> S x = S y it's just congruence and can be proved for any function [Sun Feb 16 10:47:08 2014] osa1: http://lpaste.net/264255443503677440 [Sun Feb 16 10:48:01 2014] Saizan: congruence isn't even needed. It's induction on the equality: the functoriality of functions over equalities. [Sun Feb 16 10:48:11 2014] aka the rule of Leibniz. [Sun Feb 16 10:49:04 2014] yeah, that's how you prove congruence :) [Sun Feb 16 10:49:32 2014] but maybe there's something in Coq called congruence that i'm accidentally referring to in this conversation [Sun Feb 16 10:52:11 2014] Saizan: the congruence tactic works with the setoid and equivalence typeclasses to do "equality-like" things (basically, you make instances of the proper typeclass to prove that a function respects some equivalence relation that isn't necessarily built-in) [Sun Feb 16 10:52:57 2014] If you've heard of the congruence closure algorithm, it's like that, but general to equivalence relations. [Sun Feb 16 10:55:32 2014] ianjneu: i see, thanks [Sun Feb 16 11:24:02 2014] thanks guys! [Sun Feb 16 11:24:08 2014] ianjneu: that worked. [Sun Feb 16 11:24:21 2014] I'm seeing "trivial" and "injection" tactics for first time ... [Sun Feb 16 11:24:41 2014] also cut [Sun Feb 16 11:26:53 2014] osa1: cut is simpler "assert" [Sun Feb 16 11:27:13 2014] trivial is a weaker form of intuition. [Sun Feb 16 11:27:26 2014] and auto. [Sun Feb 16 11:28:21 2014] speaking of new tactics, maybe someone can give me some tactics on simplifying our proofs: https://github.com/osa1/StagedLambda/blob/master/Lc.v :-) (we're two first time Coq users) [Sun Feb 16 11:31:03 2014] osa1: check out Adam Chlipala's cheat sheet [Sun Feb 16 11:31:20 2014] http://adam.chlipala.net/itp/tactic-reference.html [Sun Feb 16 11:31:33 2014] thank you. [Sun Feb 16 17:43:55 2014] can I save the "state" of a coqtop session? [Sun Feb 16 18:28:07 2014] ollehar: http://sourceforge.net/projects/dmtcp [Sun Feb 16 18:28:54 2014] There might be a better answer, but I work with Proofgeneral, where my state is a file. [Mon Feb 17 06:29:05 2014] Hello. [Mon Feb 17 12:51:12 2014] just out of curiosity, how much of a trivial matter do well foundedness proofs tend to be? [Mon Feb 17 12:52:21 2014] (im having some difficulties) [Mon Feb 17 12:52:22 2014] :p [Mon Feb 17 13:02:32 2014] * stares blankly [Mon Feb 17 13:03:25 2014] roosbeef: considering that you can sometimes prove the (relative) consistency of logical systems through well-foundednes they can get pretty hard :) [Mon Feb 17 13:08:48 2014] meh [Mon Feb 17 13:16:22 2014] roosbeef: IMHO they can be tricky. it's easy to get lost. [Mon Feb 17 13:17:16 2014] roosbeef: http://adam.chlipala.net/cpdt/html/GeneralRec.html maybe have a look at adam's proof that less than on nats is well founded [Mon Feb 17 13:17:35 2014] or, rather, that "length order" on lists is [Mon Feb 17 13:19:37 2014] jrw, that was my starting point actually :p [Mon Feb 17 13:20:09 2014] roosbeef: might be a good exercise to delete his proofs and try them yourself [Mon Feb 17 13:20:23 2014] also to meditate one why he has that helper lemma [Mon Feb 17 13:20:24 2014] yep my thoughts exactly :p [Mon Feb 17 13:20:27 2014] s/one/on [Mon Feb 17 13:20:46 2014] tried adapting the helper lemma to my setting but no luck [Mon Feb 17 13:21:40 2014] nevermind ill give it a rest and have a closer look later [Mon Feb 17 13:22:49 2014] <3 [Mon Feb 17 13:58:00 2014] Hi! I have a question about proof irrelevance. I know that it cannot be proven in Coq, and I know it can be safely added to Coq as an axiom. But: can its negation be disproven in Coq? Does "proof relevance" lead to any contradictions? [Mon Feb 17 18:57:57 2014] http://www.cis.upenn.edu/~bcpierce/sf/MoreProp.html in the 'le' relation, if I am doing induction over a piece of evidence with 'le', e.g. E: n <= m, I expect that when I use 'as' with induction that each part corresponds to a specific constructor [Mon Feb 17 18:58:43 2014] so I would expect that, for the 2nd constructor, I'd need to supply names for n, m, and some hypothesis? [Mon Feb 17 18:58:49 2014] which does not seem to be the case [Mon Feb 17 18:59:04 2014] so, I'm wondering what's wrong about how I see it [Mon Feb 17 19:07:31 2014] hodapp: do you have an example, it seems to work the way I expect here... [Mon Feb 17 19:08:50 2014] I do induction LE as [ n' | n' m' LE' ]. [Mon Feb 17 19:16:07 2014] http://lpaste.net/100081 [Mon Feb 17 19:16:45 2014] step through and note things at Case "le_S" [Mon Feb 17 19:32:22 2014] is this using le from the file you pointed at or le from the standard library? [Mon Feb 17 19:32:58 2014] they differ in that the LHS is a parameter in one and an index in the other [Mon Feb 17 19:34:03 2014] hodapp: could you "Locate le." ? [Mon Feb 17 20:26:53 2014] this is 'le' from the URL I gave [Mon Feb 17 20:29:33 2014] Hm, I get this. Wrong version of Coq_ [Mon Feb 17 20:29:33 2014] Coq < Arguments nil {X}. [Mon Feb 17 20:29:33 2014] Error: Unknown command of the non proof-editing mode. [Mon Feb 17 20:29:34 2014] ? [Mon Feb 17 20:30:15 2014] are you using coq 8.3? [Mon Feb 17 20:30:47 2014] ijp: yes [Mon Feb 17 20:30:58 2014] the syntax changed between 8.3 and 8.4 [Mon Feb 17 20:31:04 2014] ah! [Mon Feb 17 20:31:05 2014] try Implicit Arguments nil [[X]]. [Mon Feb 17 20:31:22 2014] they should update the book, then :P [Mon Feb 17 20:31:30 2014] the book is right for 8.4 [Mon Feb 17 20:31:50 2014] right, I'm using the old version. duh. [Mon Feb 17 20:32:00 2014] thanks. [Mon Feb 17 21:19:48 2014] jkff: The univalence axiom is consistent with Coq, and implies the negation of proof irrelevance. [Mon Feb 17 21:49:23 2014] (At least insofar as the consistency of anything of that sort can be ensured...) [Mon Feb 17 21:52:31 2014] Cale: There's a model. I trust consistency of univalence, consistency of proof irrelevance, consistency of Coq core all approximately equally (slightly more trust in Coq core, though). [Mon Feb 17 21:53:32 2014] jgross_: Right, but it'd be a model in ZF or something which hopefully can't prove its own consistency. :) [Mon Feb 17 21:54:56 2014] Cale: Of course. [Mon Feb 17 21:56:24 2014] At some point I'll really have to find a route to dig into the model theory of HoTT. There's a lot of cool-sounding things in that direction. [Tue Feb 18 06:31:03 2014] Hello. [Tue Feb 18 06:31:27 2014] Is there syntax for records which gives possibility to create new copy with changed field? [Tue Feb 18 10:22:56 2014] Is there a quick way to derive a "strong induction" principle for an inductive datatype? That is, I want to be able to do induction via a well-founded subterm relation instead of just immediate subterms. [Tue Feb 18 10:23:57 2014] I think I know how to do it manually, but it seems like something that can easily be automated. [Tue Feb 18 10:29:32 2014] It's not clear what the order relation should be for an arbitrary inductive datatype for such a scheme to be automatically generated. [Tue Feb 18 10:32:11 2014] Right, but isn't there a way to use something like "Scheme" to hint at what that should be? [Tue Feb 18 10:33:12 2014] Oh, wait, I think I get what you're saying. [Tue Feb 18 10:33:55 2014] Hmm, I guess I have to define a subterm relation manually, and prove an induction principle. [Tue Feb 18 10:34:31 2014] The induction principle is Acc_ind once you prove your subterm relation wellfounded. [Tue Feb 18 10:35:17 2014] Ah, that's convenient! Thank you. [Tue Feb 18 12:12:58 2014] dolle: I tend to define a measure [foo_size : foo -> nat] for such inductive types [foo], and then do well-founded induction on the size [Tue Feb 18 13:33:50 2014] robbert: Yeah, that is probably the easiest to do. I ended up defining a "deep" subterm relation, proved that it was well-founded and then used the well_founded_ind principle. Next time, I think I'll just use term sizes :) [Tue Feb 18 15:50:56 2014] Is there any formal definition of what HoTT is about? For a text written by a bunch of mathematicians, it's surprisingly non formal. [Tue Feb 18 15:51:38 2014] If you look at the HoTT book, the first time the word "path" is being used, it's not even followed by a fully formal definition of the concept. [Tue Feb 18 15:52:27 2014] jdoles do you know algebraic topology ? [Tue Feb 18 15:52:56 2014] Anarchos: I wonder whether anyone does ;) [Tue Feb 18 15:53:04 2014] Anarchos: more seriously, I know "some". [Tue Feb 18 15:54:10 2014] jdoles then you must know what a path is .... [Tue Feb 18 15:55:04 2014] Is the code in http://permalink.gmane.org/gmane.science.mathematics.logic.coq.club/7252 meant to work? [Tue Feb 18 15:55:28 2014] It seems to be missing proofs for eq_equiv and lt_strorder? [Tue Feb 18 15:55:38 2014] Anarchos: they say in the text that some concepts are supposed to be interpreted in a homotopy type theory specific manner. [Tue Feb 18 15:55:59 2014] Anarchos: so, the idea is that I flip a coin to decide which ones those are? [Tue Feb 18 15:57:06 2014] Anarchos: to make things more complex, the definition of a continuous map talks about sets again. [Tue Feb 18 15:57:19 2014] Anarchos: and I though the whole point of HoTT was to get rid of sets. [Tue Feb 18 15:57:37 2014] thought* [Tue Feb 18 15:57:51 2014] jdoles: there is a ##hott channel if you're interested (I don't say this to chide you for asking here) [Tue Feb 18 15:59:02 2014] I also don't particularly care about all the constructions people have build on a few axioms. [Tue Feb 18 15:59:12 2014] which definition of continuous map are you referring to? [Tue Feb 18 15:59:26 2014] I would much rather just have seen an algorithmic and logical description of what was "invented". [Tue Feb 18 15:59:58 2014] For example CIC is easy to understand (it fits on half a page). [Tue Feb 18 16:00:25 2014] Now, why does HoTT need 100+ pages (order of magnitude)? [Tue Feb 18 16:01:28 2014] (Similarly, I don't care that people have build Feit-Thompson on top of Coq when I am learning about the calculus behind Coq. ) [Tue Feb 18 16:01:40 2014] ystael: https://en.wikipedia.org/wiki/Continuous_%28topology%29#Continuous_functions_between_topological_spaces [Tue Feb 18 16:02:03 2014] oh, the classical topological one, i thought you were referring to something in the HoTT book [Tue Feb 18 16:02:32 2014] ystael: ok, so even the word "continuous map" is now overloaded? [Tue Feb 18 16:02:38 2014] or phrase* [Tue Feb 18 16:03:03 2014] i'm not the best person to be answering this, I'm only part way through the book myself [Tue Feb 18 16:03:13 2014] you'd get better answers from ##hott probably [Tue Feb 18 16:03:41 2014] but as I understand it the word "continuous" isn't actually given a definition in the base type theory [Tue Feb 18 16:04:12 2014] there's a formal analogy between the theories, that's all [Tue Feb 18 16:04:19 2014] "path" just means "element of an identity type" [Tue Feb 18 16:04:47 2014] because in the analogy, elements of identity types behave like paths in homotopy theory [Tue Feb 18 16:10:50 2014] jdoles: There's an entire book because once you give a foundation of mathematics (ITT + UA + HIT), you should support its usefulness by providing constructions of standard mathematical ideas in it. [Tue Feb 18 16:12:13 2014] Moreover, HoTT is under active research, trying to pin down completely formally the kinds of arguments exposited in the book. There is no complete formal semantics for it like Martin-Loef intensional type theory. [Tue Feb 18 16:13:48 2014] UA is modeled by cubical sets via Coquand's cubical evaluator (as far as we know), but we still don't know the boundaries of what constitutes a valid HIT or not. [Wed Feb 19 11:15:56 2014] Hello. [Wed Feb 19 11:19:42 2014] Admitted. [Wed Feb 19 11:52:37 2014] hodapp: eh? [Wed Feb 19 11:52:59 2014] hodapp: is that your new #coq greeting? [Wed Feb 19 11:53:58 2014] Only if the greeting I'm replying to looks like a Coq command. [Wed Feb 19 11:54:30 2014] Understood. [Wed Feb 19 11:55:17 2014] hmm, I'm finding 'emacsclient' rather helpful with Proof General [Wed Feb 19 11:55:47 2014] because my desktop at home can have full GUI emacs there, but I can also SSH in from other environments and get to the same buffer wherever I left off. [Wed Feb 19 11:57:31 2014] hodapp: interesting. I can use my phone's ssh client to do some proofs on the go :P [Wed Feb 19 11:57:43 2014] I... could do that. In theory. [Wed Feb 19 11:58:26 2014] I have a physical keyboard on my phone. It's nice. [Wed Feb 19 11:58:50 2014] I do too, but Emacs isn't the easiest thing to use on it. [Wed Feb 19 11:59:45 2014] my phone's an MB612 [Wed Feb 19 12:00:20 2014] dunno it. [Wed Feb 19 12:00:24 2014] Droid 4 here. [Wed Feb 19 12:01:06 2014] slider keyboards looked too failure-prone and annoying to me [Wed Feb 19 12:01:16 2014] but I'm running out of phones that have fixed QWERTY keyboards [Wed Feb 19 12:02:23 2014] unless I get a Blackberry....... [Wed Feb 19 12:04:07 2014] tiny screen [Wed Feb 19 12:59:11 2014] yeah [Wed Feb 19 12:59:59 2014] hi hodapp [Wed Feb 19 13:00:03 2014] hiya [Thu Feb 20 10:41:46 2014] why apply sometimes prints "unable to unify because ....." but sometimes just prints "unable to unify." ? [Thu Feb 20 11:02:17 2014] osa1: I imagine it's a difference between impossibility of unificiation and not being able to find a substitution due to the uncomputability of higher-order unification. [Fri Feb 21 02:38:06 2014] [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup [Fri Feb 21 07:25:46 2014] Hello. [Fri Feb 21 07:27:04 2014] hi [Fri Feb 21 07:43:54 2014] How to create module M with parameter P and fucnction f : P -> X such way that I import M once and then choose P every time I use f? [Fri Feb 21 07:44:16 2014] If I defined Parameter P then I must choose P when I import module M. [Fri Feb 21 07:44:35 2014] So I need to import M multiple times for multiple paramters. [Fri Feb 21 08:08:07 2014] Rc43: What's wrong with sections? [Fri Feb 21 08:15:28 2014] ianjneu, hmm, hever used them; will look [Fri Feb 21 08:23:04 2014] Rc43: Section BigScope. Variables (A B C : Type) (a0 : A). (* functions with A B C and a0 fixed ... *) End BigScope. (* uses of functions in bigscope that can give different A B C a0 *) [Fri Feb 21 08:25:48 2014] ianjneu, ye, seems to be exactly what I want. [Fri Feb 21 08:31:16 2014] ianjneu, is it possible to make this parameters implicit when section is closed? [Fri Feb 21 09:11:18 2014] hi [Fri Feb 21 09:25:55 2014] im trying to proof the well-foundedness of some function [Fri Feb 21 09:26:36 2014] (following http://adam.chlipala.net/cpdt/html/GeneralRec.html) [Fri Feb 21 09:28:46 2014] first im trying to prove the sublemma analogous to http://adam.chlipala.net/cpdt/html/GeneralRec.html#lengthOrder_wf%27 [Fri Feb 21 09:29:05 2014] but how do i prove that? The definition of Acc confuses me [Fri Feb 21 13:29:32 2014] I have a function m : A -> nat. How do I define a recursive function with arguments x having decreasing m x? [Fri Feb 21 13:38:16 2014] Function f x y z {measure m x} : t := ... ? [Fri Feb 21 13:44:08 2014] Ptival: Error: Found a product. Can not treat such a term [Fri Feb 21 13:45:44 2014] where is the error located? [Fri Feb 21 13:47:23 2014] "failure in proveterminate" [Fri Feb 21 13:53:13 2014] Function f x : Prop := match x with ... f0 a b => f a -> f b ... [Fri Feb 21 13:53:58 2014] that is the problematic part. without it (and another product) it goes through [Fri Feb 21 16:52:34 2014] Was wondering, how would you prove two monad transformers commute in Coq? [Fri Feb 21 16:53:30 2014] ezyang: is the question about stating the fact or going about proving such an existing statement? [Fri Feb 21 16:56:20 2014] Stating the fact. [Fri Feb 21 16:56:56 2014] To be concrete, let's consider ReaderT a and ReaderT b [Fri Feb 21 16:57:17 2014] (yep I think concrete will help) [Fri Feb 21 17:01:35 2014] The first difficulty seems to be selecting the category to operate in. Let's suppose that we use Coq itself as the CC [Fri Feb 21 17:01:38 2014] *CCC [Fri Feb 21 17:06:50 2014] Maybe I will natter around with the ExtLib monad implementation [Fri Feb 21 17:16:21 2014] Why my module can be import ed twice? [Fri Feb 21 17:16:51 2014] I have now in scope every definition with two instances: "Module.Def" and just "Def". [Fri Feb 21 17:16:58 2014] That makes some troubles. [Sat Feb 22 02:27:31 2014] Hm, I'm playing with Conor's suggested alternative formulation of free monad http://comments.gmane.org/gmane.science.mathematics.logic.coq.club/3232 [Sat Feb 22 02:27:46 2014] But I can't figure out how to turn a functor into a container form [Sat Feb 22 03:05:46 2014] Oh, Conor is using a very silly trick [Sat Feb 22 07:44:53 2014] how do i define a string type where every letter always alphabetically precedes the next letter? [Sat Feb 22 09:20:13 2014] whats up ianjneu [Sat Feb 22 11:07:45 2014] hm [Sat Feb 22 11:08:12 2014] seems like freenode is unstable atm [Sat Feb 22 11:09:00 2014] hope im not reposting [Sat Feb 22 11:10:56 2014] so ive got this order R between letters of some alphabet E [Sat Feb 22 11:10:57 2014] how do i define a type eq_string such that every letter has the same order as all other letters in that string? [Sat Feb 22 11:11:28 2014] i was thinking something like https://privatepaste.com/975869e6a4 [Sat Feb 22 11:12:03 2014] but im stuck at the last part. Seems like coq doesnt want to evaluate fl_eq [Sun Feb 23 06:51:40 2014] trying to get this dependent type to work [Sun Feb 23 06:51:47 2014] https://privatepaste.com/0b2093ac30 [Sun Feb 23 06:52:21 2014] coq tells me Error: The term "eqCons à è eq_proof :: nil" has type "list (fletter_eq à)" while it is expected to have type "hstring". [Sun Feb 23 06:53:22 2014] Definition hstring : Type := forall fl, list (fletter_eq fl). [Sun Feb 23 06:54:05 2014] how does a forall/dependency in typing work? (or rather, why does it not work here :p) [Sun Feb 23 07:44:45 2014] where is everybody? :p [Sun Feb 23 07:56:09 2014] bbl [Sun Feb 23 11:52:14 2014] roosbeef: I think you want fun fl => instead of forall fl, [Sun Feb 23 11:53:31 2014] weird irc client wouldn't scroll all the way down. [Sun Feb 23 12:30:55 2014] hi [Sun Feb 23 13:26:21 2014] hello [Sun Feb 23 13:37:08 2014] whats up Olive` [Sun Feb 23 21:29:01 2014] how do I apply a tactic to multiple goals at once? [Sun Feb 23 21:36:10 2014] anderslu1dstedt: are you familiar with the ; operator? [Sun Feb 23 21:48:27 2014] ianjneu_: yes, I know how to apply it to subgoals. How do I apply it to multiple goals generated by e.g. the Function command? [Sun Feb 23 22:47:15 2014] impossible [Mon Feb 24 09:04:02 2014] Hello. [Mon Feb 24 09:04:15 2014] How to handle diamond module dependencies? [Mon Feb 24 09:04:42 2014] I.e. A and B have common depenndency C and D imports A and B. I have problems with that. [Mon Feb 24 10:01:28 2014] Rc43: Have you consulted CPDT chapter 16? [Mon Feb 24 10:15:01 2014] ianjneu_, didn't know it contains info about modules; thanks for the reference [Mon Feb 24 10:15:53 2014] hmm, maybe the numbers changed, but CPDT has a chapter on modules. [Mon Feb 24 10:17:03 2014] It's 16.3. [Mon Feb 24 12:13:24 2014] As a math student, how can I use coq to improve my education or mathematical intuition? [Mon Feb 24 12:16:42 2014] adsisco: mathematical intuition comes from lots of practice. Perhaps work through the exercises of Software Foundations or the HoTT book. [Mon Feb 24 12:19:03 2014] adsisco: what form of mathematics are you looking to strengthen? [Mon Feb 24 13:40:14 2014] Hmm, didn't find information in CPDT 16.3 =/ [Mon Feb 24 14:00:18 2014] whats up guys [Mon Feb 24 14:00:37 2014] im kinda puzzled by dependent typing in coq [Mon Feb 24 14:00:41 2014] anyone care to help? [Mon Feb 24 14:02:00 2014] https://privatepaste.com/624888c20e [Mon Feb 24 14:02:28 2014] the type im trying to create is something along the lines of "a string of letters that have equal order in fl_compare" [Mon Feb 24 14:16:38 2014] equal order? [Mon Feb 24 14:17:10 2014] well, [Mon Feb 24 14:17:30 2014] so that forall x y in the string, eq_fl x y is True [Mon Feb 24 14:17:47 2014] (cf. link) [Mon Feb 24 14:20:08 2014] two lists of the same length where component-wise fl_eq holds? [Mon Feb 24 14:20:14 2014] I'm not following what you're getting at. [Mon Feb 24 14:20:32 2014] :p my bad [Mon Feb 24 14:20:55 2014] so suppose we have the order a, b > c, d > e, f [Mon Feb 24 14:21:13 2014] where a and b are equal in >, as are c and d, and e and f [Mon Feb 24 14:21:49 2014] how do i build a type so that it consists of all strings made of a and b, or c and d or e and f? [Mon Feb 24 14:22:37 2014] actually it doesnt even have to be that, i just want to wrap my head around dependent typing cause i cant get it to work ;p (as can be seen in the example at the bottom) [Mon Feb 24 14:43:44 2014] roosbeef: use an equivalence closure of your ordering. [Mon Feb 24 14:44:28 2014] how does that work? [Mon Feb 24 14:44:59 2014] (in coq, i mean, how is that implemented) [Mon Feb 24 14:47:55 2014] roosbeef: Relation_Operators defines transitive closure. Reflexive closure has two constructors: one that says x is related to x, and one that says if R x y then Reflexive_closure R x y. [Mon Feb 24 14:48:27 2014] Symmetric closure is similar, only instead of x related to x, you have if R x y then Symmetric_closure R y x. [Mon Feb 24 14:48:40 2014] put all three together and you have an equivalence closure. [Mon Feb 24 14:50:13 2014] so how does one employ an equivalence closure to define a type? [Mon Feb 24 14:51:18 2014] It's a proposition. [Mon Feb 24 14:51:27 2014] ah [Mon Feb 24 14:52:07 2014] also, equivalence closure of your > won't give you a, b <> c but a = b. [Mon Feb 24 14:52:25 2014] thats fine i guess [Mon Feb 24 14:52:30 2014] hm [Mon Feb 24 14:52:51 2014] but how is that different from the above failed attempt? (see link) [Mon Feb 24 14:52:53 2014] how do you want your equivalence classes to look? [Mon Feb 24 14:52:59 2014] that is using a Prop too? [Mon Feb 24 14:54:37 2014] hstring is "a list of fletters that have a proof that they're equal to fl, for a universally quantified fl." Your quantification seems to be in the wrong place. [Mon Feb 24 14:54:55 2014] Perhaps you want exists. [Mon Feb 24 14:56:12 2014] in fletter_eq you mean? [Mon Feb 24 14:56:22 2014] hstring [Mon Feb 24 14:57:43 2014] Definition hstring : Type := exists fl, list (fletter_eq fl). [Mon Feb 24 14:57:43 2014] Error: In environment fl : fletter [Mon Feb 24 14:57:43 2014] The term "list (fletter_eq fl)" has type "Set" while it is expected to have type "Prop". [Mon Feb 24 14:59:04 2014] sigT fletter_eq [Mon Feb 24 14:59:22 2014] er, sigT (fun fl => list (fletter_eq fl)) [Mon Feb 24 15:00:03 2014] The syntactic Prop/Type distinction is getting on my nerves. [Mon Feb 24 15:01:18 2014] Definition hstring : Type := exists fl, sigT (fun fl => list (fletter_eq fl)). [Mon Feb 24 15:01:18 2014] Error: In environment fl : ?12 The term "{fl : fletter & list (fletter_eq fl)}" has type "Set" while it is expected to have type "Prop". [Mon Feb 24 15:01:38 2014] no, kill the exists. [Mon Feb 24 15:01:42 2014] oh haha [Mon Feb 24 15:01:45 2014] :p [Mon Feb 24 15:03:13 2014] ok that seems to work [Mon Feb 24 15:03:21 2014] but how to construct a string of this type? [Mon Feb 24 15:03:40 2014] and why is sigT required? [Mon Feb 24 15:04:00 2014] sigT is an existential type in Type and not Prop. [Mon Feb 24 15:04:37 2014] existT (fun fl => list (fletter_eq fl)) some_fletter some_list_of_fletter_eq_some_fletter [Mon Feb 24 15:05:00 2014] hm [Mon Feb 24 15:05:03 2014] lets see [Mon Feb 24 15:07:49 2014] ok then i dont understand how fletter_eq works haha [Mon Feb 24 15:08:08 2014] heres what im trying [Mon Feb 24 15:08:11 2014] Definition test1 : hstring := existT (fun fl => list (fletter_eq fl)) à ((eqCons à) :: (eqCons è) :: nil). [Mon Feb 24 15:08:35 2014] Error: The term "eqCons è :: nil" has type "list (forall fl' : fletter, fl_eq è fl' -> fletter_eq è)" [Mon Feb 24 15:08:35 2014] while it is expected to have type "list (forall fl' : fletter, fl_eq à fl' -> fletter_eq à)". [Mon Feb 24 15:10:39 2014] how about existT _ à ((eqCons à à) :: (eqCons à è) :: nil) [Mon Feb 24 15:12:09 2014] Error: The term "eqCons à à :: eqCons à è :: nil" has type "list (fl_eq à à -> fletter_eq à)" while it is expected to have type "list (fletter_eq à)". [Mon Feb 24 15:12:15 2014] does that mean coq wants proof? [Mon Feb 24 15:12:47 2014] yup. [Mon Feb 24 15:12:50 2014] hm [Mon Feb 24 15:12:59 2014] is there a way to make coq automatically derive this proof? [Mon Feb 24 15:13:10 2014] its quite trivial when you look at the definitions [Mon Feb 24 15:13:12 2014] Canonical structures. [Mon Feb 24 15:13:20 2014] how does that work? [Mon Feb 24 15:13:30 2014] mumble mumble [Mon Feb 24 15:13:44 2014] haha [Mon Feb 24 15:14:08 2014] does it help to write tactics? I havent been using those so far [Mon Feb 24 15:14:25 2014] (well custom ones i mean) [Mon Feb 24 15:16:05 2014] it won't help. You have to hook into the unification algorithm to fill in those proofs. [Mon Feb 24 15:16:13 2014] that's what canonical structures give you [Mon Feb 24 15:17:13 2014] would you have a good resource for getting started with canonical structures perhaps? [Mon Feb 24 15:18:25 2014] http://www.mpi-sws.org/~beta/lessadhoc/ [Mon Feb 24 15:20:34 2014] looks good :) [Mon Feb 24 15:20:38 2014] gonna study that [Mon Feb 24 15:20:42 2014] thanks a lot! [Mon Feb 24 20:18:24 2014] how do I simplify Fixpoints created by Program Fixpoint? http://pastebin.com/J10FeHV1 [Mon Feb 24 20:40:46 2014] anderslundstedt: what obligations did you have left to prove? [Mon Feb 24 20:42:54 2014] well, if I do the import Coq.Program.Program then none, all are solved automatically [Mon Feb 24 20:45:14 2014] here is a modified pastebin with no obligations remaining or admitted: http://pastebin.com/TCRCztNU (just the first line changed) [Mon Feb 24 20:45:22 2014] unfold f; rewrite Fix_eq; fold f; simpl. [Mon Feb 24 20:47:40 2014] full proof: intros n. unfold f; rewrite Fix_eq; [simpl; reflexivity|intro x; induction x; auto]. [Mon Feb 24 20:54:43 2014] thank you. The actual fixpoint I have is of course more complicated. The combination "unfold f; rewrite Fix_eq; fold f; simpl." does not work there. There is no combination that works with all Program Fixpoints? [Mon Feb 24 20:58:42 2014] I suggest you look at the theorems you get from uses of Fix. [Mon Feb 24 21:00:07 2014] where can I find them? [Mon Feb 24 21:03:18 2014] SearchAbout Fix. [Mon Feb 24 21:04:20 2014] thanks [Tue Feb 25 02:36:41 2014] how do I get the necessary equalities when using refine on a pattern match? http://pastebin.com/n8G12TY8 [Tue Feb 25 04:06:18 2014] anderslundstedt: something like this? http://pastebin.com/meTJhpd6 [Tue Feb 25 04:13:09 2014] I kind of wish there were a more sugary syntax available for providing additional inferrable parameters to the branches of a case in that fashion. [Tue Feb 25 04:13:31 2014] of a match, I should say :) [Tue Feb 25 04:54:58 2014] jrw: yes, thanks! [Tue Feb 25 15:18:04 2014] Is there a powerpoint to evangelise coq within enterprises ? [Tue Feb 25 15:25:04 2014] Anarchos: There was a talk at POPL about how to sell program verification to industry: http://www.cl.cam.ac.uk/~pes20/pip2014-slides/PIP2014-Leroy.pdf [Tue Feb 25 15:28:34 2014] jgross thanks [Tue Feb 25 15:28:44 2014] jgross do you know if this channel is looged ? [Tue Feb 25 15:29:05 2014] I have my own logs of it, but I don't know of any public logs. Why? [Tue Feb 25 15:46:49 2014] jgross to be able to find this link again at work tomorrow [Tue Feb 25 15:47:19 2014] Anarchos: paste in in ##hott :P [Tue Feb 25 15:48:21 2014] ianjneu lol [Tue Feb 25 15:48:44 2014] ianjneu so is T. Coquand near to show that univalent axiom as a computation model ? [Tue Feb 25 15:57:06 2014] I'm not close to the project. Dunno. [Tue Feb 25 16:01:35 2014] ianjneu oh ok [Tue Feb 25 16:01:54 2014] could you remind me what are you close to ? [Tue Feb 25 16:04:35 2014] Anarchos: http://www.ccs.neu.edu/home/ianj/ [Tue Feb 25 16:06:07 2014] ok :) [Tue Feb 25 17:01:34 2014] Anarchos: google popl 2014 pip, then look for "Xavier Leroy, How much is a mechanized proof worth, certification-wise?" [Tue Feb 25 19:05:18 2014] Hi folks. I'm with some trouble in defining a decidable equality function on a dependent type. The problematic code is in the following gist: https://gist.github.com/rodrigogribeiro/9220646 [Tue Feb 25 19:06:04 2014] If someone could take a look, the trouble is in definition eq_ty_dec [Tue Feb 25 19:11:45 2014] rribeiro: looks like you want propositional extensionality, not JMeq. [Tue Feb 25 19:14:37 2014] ianjneu: Propositional extensionality? But the types in eq_ty_dec involve different indices... Because of that, I thought that JMeq was necessary [Tue Feb 25 19:15:36 2014] JMeq is a kludge best not used. [Tue Feb 25 19:15:52 2014] and I meant proof irrelevance. I'm still playing with your code. [Tue Feb 25 19:16:01 2014] ianjneu: Using proof irrelevance, I can prove some cases, but I can't do inversion on some contradictions [Tue Feb 25 19:16:50 2014] ianjneu: But, there's no way of doing this without any axioms like proof irrelevance? [Tue Feb 25 19:18:33 2014] rribeiro: you need to show that two variables of type In x y are equal. That needs proof irrelevance or more information than you're giving. [Tue Feb 25 19:28:21 2014] Hello. [Tue Feb 25 19:30:17 2014] Rc43: hey [Tue Feb 25 19:32:32 2014] rribeiro: I'm hitting an anomaly trying to induct on points of JMeq. [Tue Feb 25 19:33:30 2014] what kind of anomaly? [Tue Feb 25 19:33:43 2014] ianjneu: what kind of anomaly? *** [Tue Feb 25 19:34:39 2014] an anomalous one [Tue Feb 25 19:36:53 2014] OAnomaly: Uncaught exception Option.IsNone. Please report. [Tue Feb 25 19:37:15 2014] oh! A bug... [Tue Feb 25 19:37:57 2014] ya [Tue Feb 25 19:38:16 2014] I keep hitting those. I am Ian, breaker of languages. [Tue Feb 25 19:38:33 2014] ianjneu: :) [Tue Feb 25 19:39:27 2014] JMeq_ind seems to be weaker than what it should be.. [Tue Feb 25 19:48:18 2014] Internal rewrites seem to break well-typedness too. Wtf. [Tue Feb 25 19:48:50 2014] oh okay. Trying to do Defined gives a universe inconsistency. [Tue Feb 25 19:58:43 2014] ]ianjneu: Wtf this thing... It seems to be a simple definition... :( [Tue Feb 25 19:59:08 2014] rribeiro: equality is mysterious. [Tue Feb 25 20:02:56 2014] ianjneu: Strange thing... In agda, I believe that this function is easy to implement... :( [Tue Feb 25 20:03:23 2014] ianjneu: I thought that it would be equaly easy in Coq. [Tue Feb 25 20:06:47 2014] Agda treats equality irreverently. [Wed Feb 26 00:25:52 2014] rribeiero: Agda's pattern matching assumes Axiom K. That is what makes it easy. But if you're willing to replace [In] with a decidable version, then it's doable in Coq, without any axioms and using eq rather than JMeq: https://gist.github.com/rodrigogribeiro/9220646#comment-1180189 [Wed Feb 26 03:05:28 2014] hi, CoqIde refuses to start properly on my macbook pro running mavericks... is that a known problem? [Wed Feb 26 03:05:45 2014] 8.4p12 [Wed Feb 26 08:06:59 2014] wow, I amaze myself with the things I can come up with in Coq [Wed Feb 26 08:07:25 2014] ...and how far they are from an actual simple solution to the problem. [Wed Feb 26 10:49:51 2014] Where can I find the expected form of and induction principle for induction ... using ? [Wed Feb 26 11:01:38 2014] napping: do you have any sort of example of what you're talking about? [Wed Feb 26 11:02:35 2014] Lets say you have a vec : Set -> nat -> Set [Wed Feb 26 11:04:10 2014] and define something like vec_nz_ind : forall (Q : forall A n, vec A n) (H : forall A (a : A) n (v : vec A n), a -> Q v -> Q (vcons a v)), forall A n (v : vec A (S n)), Q v [Wed Feb 26 11:05:21 2014] that doesn't seem to work with destruct ... using [Wed Feb 26 11:05:35 2014] like if you have H : vec string 3 in scope, destruct H using vec_nz_ind [Wed Feb 26 11:05:50 2014] Haven't actually tested that yet, it's simplified from my full code [Wed Feb 26 11:28:42 2014] Here's a simpler example that actually fails http://lpaste.net/100415 [Wed Feb 26 22:44:52 2014] is this a channel strictly for coq development, or are coq usage questions acceptable here? [Wed Feb 26 22:57:21 2014] eridu: usage questions definitely welcome! [Wed Feb 26 23:14:24 2014] how can I split out an implication that's in a hypothesis? [Wed Feb 26 23:15:03 2014] eridu: can you give an example? [Wed Feb 26 23:15:46 2014] if I have a hypothesis of the form P -> Q, is there a way I can split that so I have a hypothesis P? [Wed Feb 26 23:17:37 2014] eridu: I'm not sure I follow, but that doesn't sound like something you should expect to be able to do [Wed Feb 26 23:17:49 2014] if I know "P implies Q" that doesn't mean I know "P" (or "Q" for that matter) [Wed Feb 26 23:17:50 2014] that's understandable, I don't understand this very well [Wed Feb 26 23:18:20 2014] now, if your *goal* is "P -> Q" [Wed Feb 26 23:18:37 2014] then the tactic "intros" will introduce P into your hypotheses [Wed Feb 26 23:18:43 2014] and then your goal will become Q [Wed Feb 26 23:32:51 2014] so, let's say I have an assumption P x -> Q [Wed Feb 26 23:33:06 2014] and another assumption about the shape of x that means I know P x to be true/provable [Wed Feb 26 23:33:23 2014] how can I apply the latter assumption to prove Q in the former assumption? [Wed Feb 26 23:38:11 2014] also, is the "Case" (uppercase) command/tactic used in the Software Foundations book an extension? I can't seem to use it in my coq [Wed Feb 26 23:40:02 2014] eridu: regarding Case, if I recall, you have to import their library that defines it. [Wed Feb 26 23:40:32 2014] recent versions of coq have a sort of similar mechanism via bullets: you can use "-", "+", and "*" to delineate cases in your proof [Wed Feb 26 23:41:42 2014] regarding the other question, one thing you can do is "assert (P x)." then proceed to prove P x. that will give you a new hypothesis "P x", then you can apply the old hypothesis to the new one to get Q [Wed Feb 26 23:49:02 2014] ah, okay [Wed Feb 26 23:52:50 2014] how do parentheticals interact with the "in 1" sort of syntax? If I have a constructor application in parens, inside a larger statement, is that one increment of the 'in x' number, or more? [Wed Feb 26 23:58:07 2014] do you mean "at 1"? [Wed Feb 26 23:58:28 2014] in that case, I don't think parenteses matter, but I don't use that feature very much [Thu Feb 27 00:04:06 2014] yes, that [Thu Feb 27 00:08:21 2014] okay, I think this should be one of my last questions; thanks so much for your help [Thu Feb 27 00:09:22 2014] how do you construct a value of a sigma type? like {x | P x} [Thu Feb 27 00:09:39 2014] actually typing "{x | P x}" gives me something in set, but I want that particular type [Thu Feb 27 00:12:03 2014] eridu: the answer in this case is the constructor "exist" [Thu Feb 27 00:12:37 2014] you can find this by saying: Locate "{ _ | _ }". [Thu Feb 27 00:12:44 2014] which tells you that the real type name is sig [Thu Feb 27 00:12:48 2014] you can then say: Print sig. [Thu Feb 27 00:12:58 2014] to see its constructors (in this case there's only one) [Thu Feb 27 00:13:22 2014] ah. I was confusing exist and existT. [Thu Feb 27 02:32:48 2014] hi, CoqIdE won't start on mavericks - or rather, it just doesn't open the window - anything anyone knows about? [Thu Feb 27 03:58:49 2014] I have two hypotheses: a < b and b > a. How can I derive a contradiction? [Thu Feb 27 03:59:30 2014] it seems like most of the normal contradiction tactics don't easily work on inequalities... [Thu Feb 27 04:44:54 2014] eridu: Do you mean a < b and b < a? If so, omega will solve the goal. [Thu Feb 27 04:45:13 2014] yeah, I had exactly that, but omega was saying it couldn't solve the system. [Thu Feb 27 04:45:47 2014] could have been another issue though [Thu Feb 27 05:39:27 2014] Hi. [Thu Feb 27 05:54:32 2014] What function should be used for getting remainder of division? [Thu Feb 27 05:54:38 2014] (a `mod` b) [Thu Feb 27 06:06:39 2014] Oh, its Zmod. [Thu Feb 27 06:07:09 2014] But Z <> nat. [Thu Feb 27 06:08:19 2014] http://coq.inria.fr/distrib/current/stdlib/Coq.Arith.Euclid.html [Thu Feb 27 06:08:25 2014] There's that, which might be of use [Thu Feb 27 06:14:20 2014] Oh, I already used Z.of_nat and Z.to_nat :) [Thu Feb 27 06:39:46 2014] Is ther analogue of "undefined" from haskell? [Thu Feb 27 06:40:02 2014] I can use "admit" in proofs, but what about functions? [Thu Feb 27 06:46:21 2014] I found in google, that there are "holes" in ProofGeneral for Coq. [Thu Feb 27 06:46:30 2014] But I can't find how to use it. [Thu Feb 27 06:49:06 2014] Ah, just import Program and put _ in desired place. [Thu Feb 27 06:54:08 2014] But I can't use unfinished definitions (with holes) =/ [Thu Feb 27 13:21:58 2014] has coq kernel been extracted from coq itself ? [Thu Feb 27 13:29:02 2014] the closest I'm aware of is: http://coq.inria.fr/V8.2pl1/contribs/CoqInCoq.html [Thu Feb 27 13:35:06 2014] hodapp i read the report of bruno barras on the subject, and obviously he used Godel theorem to state it is not fully feasible [Thu Feb 27 14:02:19 2014] There is a research goal of the HoTT community to see if type theory with n + 1 universes justifies the consistency of type theory with n universes. [Thu Feb 27 14:02:37 2014] I think it's along the lines of the paper, "Type theory should eat itself." [Thu Feb 27 14:39:26 2014] ianjneu well it sounds like ZFC+Cardinal Inaccessible proves ZF [Thu Feb 27 15:26:04 2014] I am looking for some help working with a function that has a non-obvious induction metric [Thu Feb 27 15:28:24 2014] the only way I've gotten coq to accept a definition that looks right is with Program Fixpoint, but I don't know how to actually work with that definition because it adds a bunch of complicated stuff I don't understand [Thu Feb 27 15:54:37 2014] jtpercon: You have to use the Fix theorems like Fix_eq to rewrite functions to their body. [Thu Feb 27 15:54:53 2014] simpl does not do this for you. [Thu Feb 27 15:55:42 2014] ok I will take a look at Fix_eq [Thu Feb 27 15:59:44 2014] ianjneu: I don't understand what this does [Thu Feb 27 16:02:04 2014] jtpercon it unrolls recursive calls [Thu Feb 27 16:06:05 2014] ok so after I unfold two things I get to a goal that is an application of Fix_sub to a bunch of stuff, which seems to be the right shape to apply Fix_eq, but it doesn't actually match if I try to do that [Thu Feb 27 16:07:24 2014] rewrite, don't apply [Thu Feb 27 16:08:01 2014] but the conclusion isn't an equality [Thu Feb 27 16:08:11 2014] or wait, I am reading this wrong [Thu Feb 27 16:08:40 2014] I misread a => as a -> and also ignored some parens, oops [Thu Feb 27 16:11:27 2014] ok it did a rewrite, but this was not actually helpful because now I have a huge match expression instead of something I can read [Thu Feb 27 16:19:31 2014] did you try «simpl» after that ? [Thu Feb 27 16:20:28 2014] actually I think I might be getting it? hang on [Thu Feb 27 16:25:26 2014] well ok, I got things to match up for one subgoal that looks like what I expect to be proving but it generated another subgoal with a bunch of stuff I don't understand [Thu Feb 27 16:34:47 2014] I am not sure what information to give now other than explaining everything I'm doing [Thu Feb 27 16:55:42 2014] jtpercon: the extra subgoal is almost always provable by auto or intro x; induction x; auto. [Thu Feb 27 16:59:48 2014] ok so you know what the extra subgoal is then? [Thu Feb 27 17:02:32 2014] (it does give me a thing called x but doing induction on it did not solve the goal) [Thu Feb 27 17:11:57 2014] I forget. [Thu Feb 27 17:14:03 2014] I may have to give up on this for today [Thu Feb 27 17:14:15 2014] ah, it's the subgoal that you preserve the function equality given the equality of recursive calls. [Thu Feb 27 17:15:04 2014] oh is that what it is, ok [Thu Feb 27 17:15:39 2014] that sort of makes sense from the parts of this proof state I have been able to make sense of [Thu Feb 27 17:31:30 2014] yeah I give up for now, thanks anyway ianjneu [Thu Feb 27 17:33:12 2014] * gets it to work immediately after saying I gave up [Thu Feb 27 20:44:49 2014] how do I return a finite set of nats from a function? [Thu Feb 27 21:35:59 2014] Module FinNatSet := MSetList.Make Nat_as_OT. [Thu Feb 27 21:36:06 2014] is that correct? [Thu Feb 27 22:58:41 2014] could be [Thu Feb 27 22:58:49 2014] FinNatSet.t [Fri Feb 28 05:48:25 2014] Hello to all! I have a question about well founded relations. I want to define a wf relation between elements of two "diferent" types --- different in the sense that the types have different indices. I've looked at stdlibrary and books (coq-art and chlipala's) and didn't find anything. Anyone have any suggestion on how to define such relation? Thanks in advance [Fri Feb 28 07:11:33 2014] rribeiro: package the different index into a sigma type. [Sat Mar 1 11:53:14 2014] can I use coq to prove that a state machine cannot reach an invalid state? [Sat Mar 1 11:56:18 2014] with suitable definitions, sure [Sat Mar 1 12:00:55 2014] ziman: cool, any tips how? or a link? [Sat Mar 1 12:02:47 2014] I found some info about it in OCaml on stackoverflow, will check that [Mon Mar 3 09:18:27 2014] bonjour [Mon Mar 3 09:22:59 2014] hi fser [Mon Mar 3 09:24:07 2014] sorry I didn't notice this channel was english spoken :) [Mon Mar 3 09:24:19 2014] fser no problem [Mon Mar 3 09:24:38 2014] I may have beginner questions about coq, maybe this is not the appropriate chan .. [Mon Mar 3 09:41:10 2014] I have term like: 'match l with | cons x l' => ... | nil => ... end'. [Mon Mar 3 09:41:34 2014] How to generate equalities "l = cons x l'" and "l = nil" inside branches? [Mon Mar 3 09:52:27 2014] destruct l [Mon Mar 3 09:57:20 2014] Anarchos, how to do it with term? [Mon Mar 3 09:57:47 2014] I want to define function, not prove its propertty. [Mon Mar 3 10:01:31 2014] Maybe it is easier to define the function with tactics though =/ [Mon Mar 3 10:02:32 2014] Rc43 no idea [Mon Mar 3 10:02:45 2014] rc did you look into the coqart ? [Mon Mar 3 10:07:20 2014] Anarchos, not yet [Mon Mar 3 10:18:00 2014] How to use "inversion" if I want to keep equality? [Mon Mar 3 10:18:13 2014] I mean, "keep equality hypothesis in the context". [Mon Mar 3 10:27:45 2014] I can't make "eqn:" from ref manual work. [Mon Mar 3 10:30:12 2014] Hmm, "destruct something as [x y] eqn:N" works. [Mon Mar 3 13:10:09 2014] new to coq here, are there tactics to automatically prove easy theorems like: http://pastie.org/8842272 (for instance, if i fix A to be a finite set, are there tactics which just enumerate all possible relations and check if the property holds?) [Mon Mar 3 16:24:31 2014] guys, any ideas why simpl does not work in this case: http://lpaste.net/100661 [Mon Mar 3 17:41:36 2014] osa1: maybe it doesn't want to simple unless it knows the structure of the structurally-recursive argument? [Tue Mar 4 16:00:09 2014] is there a way to bind multiple values with a single let? [Tue Mar 4 16:02:10 2014] defanor_ if you can define a tuple , yes. And i remind it should be feasible within coqq [Tue Mar 4 16:05:51 2014] thanks [Tue Mar 4 22:22:46 2014] In working through a proof, I found that at a particular point, "destruct e." gives me an error, "Error: Case analysis on sort Type is not allowed for inductive definition Logic.ex." [Tue Mar 4 22:23:03 2014] However, if I first do "exfalso.", then the error does not appear and I'm successfully able to destruct the term e. [Tue Mar 4 22:23:35 2014] specifically, I have "e : exists v : val, set_In (l, v) nil" (i.e. it's a contradiction) [Tue Mar 4 22:23:59 2014] it destructs to "x : val" and "H : set_In (l, x) nil", the latter of which I can use the contradiction tactic on to satisfy the goal [Tue Mar 4 22:24:05 2014] but why do I need to use exfalso before destructing e? [Tue Mar 4 22:24:28 2014] isn't the goal irrelevant when destructing a hypothesis? [Tue Mar 4 22:34:12 2014] kini: I think it has to do with the exists v : val, set_In (l, v) nil being a Prop, while your goal is perhaps a Type? [Tue Mar 4 22:35:13 2014] kini: Once you do exfalso, the goal becomes False, which is a Prop, so you can eliminate other Props to get it. [Tue Mar 4 22:37:27 2014] Yes, my goal is a Type, good guess! [Tue Mar 4 22:37:57 2014] I'm not sure I understand why that would prohibit me from destructing a Prop, though... [Tue Mar 4 22:41:06 2014] I'm not sure I do either, I just know that Coq doesn't like it. :) There's probably something bad that you can do using Prop's impredicativity if you're allowed to destruct Props to get Types, but I don't really know. [Tue Mar 4 22:41:33 2014] Personally, I tend to prefer to avoid Prop [Tue Mar 4 22:45:20 2014] But there are some set theoretical things you need that impredicativity for, like defining power sets without going up a universe level. [Tue Mar 4 23:23:07 2014] Cale, kini: It's not so much the impredicativity (I think) that bites as it is prop erasure. When you extract code, all the Prop arguments get erased. If your construction depends on it, then your extracted code goes boom. In HoTT there's a more structured distinction: (weak) hProps can only be destructed if you prove that your construction doesn't depend on the value (i.e., you send all inhabitants of the hProp to propositionally equal [Tue Mar 4 23:23:07 2014] things). strict hProps require you to send all inhabitants to judgmentally equal things. [Tue Mar 4 23:39:07 2014] hmm, I guess I don't really know what I'm doing [Tue Mar 4 23:39:35 2014] I remember that at POPL someone said that anyone who has used Coq for long enough knows that the only way to get any work done is to make your code have simple types and then prove external theorems about your code using more complicated types [Tue Mar 4 23:39:50 2014] rather than trying to carry proofs of theorems along with your computational values [Tue Mar 4 23:39:58 2014] I guess I'm finding that out firsthand :P [Tue Mar 4 23:41:16 2014] but I think I see your point, jgross -- destructing a Prop will basically create a match expression on the Prop in the proof object, right? so if that Prop is gone, you have a problem, even if it is impossible to get into that branch during execution (as you are trying to go on to prove) [Tue Mar 4 23:41:40 2014] because your code is just missing pieces, even though it's in a dead code region, so to speak [Tue Mar 4 23:41:55 2014] Yeah, that's a good point [Tue Mar 4 23:43:36 2014] ok, here is a very dumb question. I have a hypothesis "(x, y) = (z, w)". How do I get two hypotheses "x = z" and "y = w"? Trying to destruct the hypothesis just makes it go away. [Wed Mar 5 00:01:29 2014] kini: Ah, apparently it's called f_equal. [Wed Mar 5 00:02:00 2014] f_equal fst p should get you x = z [Wed Mar 5 00:02:10 2014] where p is your (x, y) = (z, w) [Wed Mar 5 00:02:22 2014] (In HoTT, this is called ap) [Wed Mar 5 00:03:36 2014] You might need to supply the implicit parameter to fst [Wed Mar 5 00:04:00 2014] well, this is a hypothesis, not a goal... [Wed Mar 5 00:04:22 2014] The function is also called f_equal [Wed Mar 5 00:04:42 2014] (There's also a tactic called f_equal) [Wed Mar 5 00:06:24 2014] There is also an [inversion] tactic that might do what you want. But [pose proof (f_equal (@fst _ _) p)] is less black-box-magic. [Wed Mar 5 00:06:26 2014] My version of Coq has trouble unifying the type of fst with the type of the argument to f_equal though unless I explicitly specify the type of the second part using (B := B) [Wed Mar 5 00:06:45 2014] oh, of course, inversion worked, haha [Wed Mar 5 00:07:03 2014] thanks, Cale and jgross [Wed Mar 5 00:07:10 2014] Oh, that at-sign magic again :) [Wed Mar 5 00:07:12 2014] man, it's been too long since I cracked open software foundations... [Wed Mar 5 00:07:50 2014] Kini: exfalso is how you tell Coq that you're in a dead code region. Coq can't figure out whether or not you're in a dead code region automatically, so you need to tell it. [Wed Mar 5 00:08:35 2014] Cale: What's magic about @s? @? are kind-of magic in pattern matching (but not magic enough), but @ just says "make all the parameters explicit". [Wed Mar 5 00:08:43 2014] well, you could also just keep going and eventually say "contradiction H", but I guess that's just being overly conservative in what you're telling Coq is a dead code region [Wed Mar 5 00:08:55 2014] so I guess the lesson is to use exfalso as soon as possible [Wed Mar 5 00:09:24 2014] jgross: Well, it's strange to me that Coq would refuse to infer the implicit parameters, and then you go and make them explicit and fill them with blanks and everything is okay [Wed Mar 5 00:10:08 2014] I would kind of expect fst to mean the very same thing as @fst _ _ [Wed Mar 5 00:10:15 2014] given that fst has two implicit parameters [Wed Mar 5 00:10:58 2014] Cale: This is the difference between implict, and implicit and maximally inserted. [fst] is the same as [@fst] if you pass it no parameters, but if you pass it a parameter [x], then it's [@fst _ _ x]. If you want [fst] to mean [@fst _ _], then you need to do [Arguments fst {A B} _.] (To make it implicit but not maximally inserted, you do [Arguments fst [A B] _.]) [Wed Mar 5 00:13:24 2014] I wonder if it would be worth making it try adding blanks until it runs out of implicit parameters in the case of a type mismatch. [Wed Mar 5 00:13:51 2014] (In general) [Wed Mar 5 00:16:45 2014] Cale, I think that would be confusing. But maybe not. Feel free to submit a feature request for a kind of "minimally inserted implicit arguments". [Wed Mar 5 00:16:56 2014] Anyway, I'm off to bed. Goodnight! [Wed Mar 5 00:17:12 2014] Yeah, I haven't thought it through too well :) [Wed Mar 5 00:17:41 2014] But it seems like it would be the right thing in many cases, given that the parameters are already supposed to be implicit [Wed Mar 5 00:18:01 2014] (obviously auto-inserting _'s for non-implicit parameters would be confusing!) [Wed Mar 5 14:45:42 2014] what is reflexivity? google search does not seem to help? I am trying to learn coq from here: https://www.kevinjsullivan.com/lets-start-at-the-very-beginning and could not understand what reflexivity is. [Wed Mar 5 14:45:46 2014] any thoughts, please? [Wed Mar 5 14:46:00 2014] Or, is there a better place to learn coq from? [Wed Mar 5 14:48:08 2014] joe9: in general, reflexivity is a property of a relation, that says that an element is related to itself [Wed Mar 5 14:48:22 2014] the reflexivity tactic solves goals of the form 'a = a' [Wed Mar 5 14:48:25 2014] the common example is the fact that a thing is always equal to itself [Wed Mar 5 14:49:47 2014] Ptival: ezyang thanks. [Wed Mar 5 14:57:37 2014] I do not have a math background. just wanted to check if there are any good coq tutorials or if this is my best bet: https://www.kevinjsullivan.com/lets-start-at-the-very-beginning [Wed Mar 5 14:58:35 2014] joe9: http://www.cis.upenn.edu/~bcpierce/sf/ [Wed Mar 5 15:03:22 2014] ditto SF. It is a very gentle introduction. [Wed Mar 5 15:20:52 2014] rmk0: ezyang thanks. [Wed Mar 5 15:49:44 2014] for a beginner, is it recommended to use coqide or emacs/proof general. I have both working. Just want to check if there is a "better for beginner" one. [Wed Mar 5 15:57:47 2014] joe9: if you are already an emacs user, definitely proof general. if not, a little harder to say, but when i tried to use coqide it was not a great editor experience. [Wed Mar 5 15:58:07 2014] i hate mice though [Wed Mar 5 16:02:01 2014] ystael: yes, I use emacs. thanks, will stick with proof general. [Wed Mar 5 16:05:01 2014] When I make a mistake with emacs/proof general, the region becomes red (read-only). Is there any way to revert back to editing mode? [Wed Mar 5 16:05:43 2014] or, delete that region. [Wed Mar 5 16:06:15 2014] C-c C-u to back up? does that work? [Wed Mar 5 16:08:07 2014] ystael: yes, that helped. thanks. [Wed Mar 5 17:21:43 2014] error: http://codepad.org/N5Nu2ICl code, http://codepad.org/R4vVbrPQ . The error is with the second true argument of this line : Example test_orb3 (orb false true) = true. [Wed Mar 5 17:21:50 2014] Any thoughts on what I am missing, please? [Wed Mar 5 17:22:15 2014] oh, got it. sorry for the bother. [Wed Mar 5 22:20:15 2014] :sp [Wed Mar 5 22:20:19 2014] sorry for that. [Wed Mar 5 22:55:21 2014] Any suggestions on the basics of mathematical theorem proving. Just so that I can learn what QED, hypothesis, etc. mean. [Wed Mar 5 22:56:19 2014] I know high school maths, not college level maths. Just want to check if there is any book to read that can help with the terminology of mathematics theorem proving. [Wed Mar 5 23:11:50 2014] would you recommend any of these: http://www.amazon.com/exec/obidos/ASIN/0471510041/ref=nosim/weisstein-20 http://www.amazon.com/exec/obidos/ASIN/047196199X/ref=nosim/weisstein-20 [Wed Mar 5 23:13:59 2014] http://www.amazon.com/How-Prove-It-Structured-Approach/dp/0521675995/ref=pd_sim_sbs_b_1?ie=UTF8&refRID=1EHRTK3XA5BFWKJE7QHV or this. [Wed Mar 5 23:20:36 2014] these look like affiliate links :( [Wed Mar 5 23:21:13 2014] oh maybe you copied the link from somewhere... [Wed Mar 5 23:21:39 2014] Ptival: yes, from amazon. [Thu Mar 6 15:54:44 2014] Is there some functionality to show how a tactic changes the goals? I can see the end result after applying the tactic. Just want to check if there is a way to show the goal before and after. [Thu Mar 6 16:04:35 2014] I am using proofgeneral but I can use coqide, if that can show these changes. [Thu Mar 6 16:18:03 2014] got it, the coq window has that info. [Thu Mar 6 16:18:25 2014] hmmm not really :\ [Thu Mar 6 16:18:31 2014] info tactic. maybe? [Thu Mar 6 17:01:31 2014] Ptival: could not find "info tactic" with M-x. Is that what you meant? [Thu Mar 6 17:14:22 2014] no I meant the tactic modifier "info" [Thu Mar 6 17:14:28 2014] but it won't do what you want anyway [Thu Mar 6 17:14:57 2014] joe9: I believe the only way to do what you want is to go back and forth applying the tactic [Thu Mar 6 20:06:56 2014] Ptival: ok, thanks. [Thu Mar 6 20:20:03 2014] looking at the excluded middle definition from Logic.v of SF (forall P:Prop, P \/ ~P)... but not understanding how to actually *use* this definition [Thu Mar 6 20:21:22 2014] it looks like I should be able to apply it to some proposition and use inversion to get two subgoals, one for P and one for ~P [Thu Mar 6 20:21:27 2014] but I don't know how to achieve that [Thu Mar 6 20:36:09 2014] also... http://lpaste.net/100812 - I thought anything resembling P1 \/ P2 was a disjunctive pattern with two branches? What is going on here? [Thu Mar 6 20:37:59 2014] is this correct: http://codepad.org/8TS434ut ? this is an Exercise problem from sf. [Thu Mar 6 20:38:18 2014] joe9: another fellow working through SF?! [Thu Mar 6 20:38:37 2014] seems to be the best book I could find. [Thu Mar 6 20:38:42 2014] Hodapp: ^^ [Thu Mar 6 20:38:56 2014] I'm told it's a good book, I'm just surprised by how many people come through here working with it [Thu Mar 6 20:39:19 2014] I'm working through SF too but I'm further along so I don't suppose you'd be able to help [Thu Mar 6 20:39:28 2014] Hodapp: have you checked out these? http://www.cs.uoregon.edu/research/summerschool/summer12/curriculum.html http://www.seas.upenn.edu/~cis500/current/index.html [Thu Mar 6 20:39:39 2014] I checked them out, but, was not sure how useful they are. [Thu Mar 6 20:40:44 2014] your exercise solution looks good to me [Thu Mar 6 20:41:34 2014] that first link is how I found SF [Thu Mar 6 20:45:37 2014] oh, I think my issue with that paste is not the inversion but how I was trying to do it [Thu Mar 6 21:13:22 2014] http://www.cis.upenn.edu/~bcpierce/sf/Logic.html#lab221 this one is seriously throwing me for a loop. I can't use 'rewrite' with their equality definition and I really can't find anything else I can do either [Thu Mar 6 21:17:50 2014] waitaminute... if I do 'inversion' on x = y, then I get another hypothesis of x = y, yet this latter one I can use 'rewrite' on. That does not make much sense... is it using another definition there? [Thu Mar 6 21:31:50 2014] this exercise http://codepad.org/wNcVGJm6 suddenly jumped to a lemma. [Thu Mar 6 21:32:15 2014] without teaching how to prove a lemma, etc. [Thu Mar 6 21:32:43 2014] Lemmas are just other theorems [Thu Mar 6 21:33:37 2014] ezyang: I do not want the solution for this exercise. Can you please guide me on how to go about solving it. [Thu Mar 6 21:33:52 2014] should I first prove (andb b c = orb b c)? [Thu Mar 6 21:33:57 2014] that is the hypothesis. [Thu Mar 6 21:34:07 2014] I can just use intros and it goes to the assumption. [Thu Mar 6 21:34:21 2014] this is how I am going about it. http://codepad.org/YMARVtJx [Thu Mar 6 21:35:03 2014] but, it does not seem to be correct as I get stuck with http://codepad.org/0miAhQcS second subgoal is unprovable. [Thu Mar 6 21:35:38 2014] joe9_: Hint: is the hypothesis impossible? [Thu Mar 6 21:37:22 2014] ezyang: yes, I think the hypothesis is impossible as the second goal seems a valid value, but, it is not equal. [Thu Mar 6 21:37:43 2014] andb true false = orb true false -> true = false -- is impossible. [Thu Mar 6 21:38:03 2014] From falsity you can conclude anything [Thu Mar 6 21:38:51 2014] ezyang: I do not understand. [Thu Mar 6 21:39:52 2014] I can prove '1 = 0 -> 2 = 4' [Thu Mar 6 21:40:24 2014] Do you know how to use the 'contradiction' tactic yet? [Thu Mar 6 21:40:55 2014] ezyang: no. It does not seem to have been covered yet. [Thu Mar 6 21:41:38 2014] Hmmk [Thu Mar 6 21:41:52 2014] http://www.cis.upenn.edu/~bcpierce/sf/Basics.html is the lesson [Thu Mar 6 21:41:58 2014] and there is nothing in there with contradiction. [Thu Mar 6 21:42:31 2014] Basically, your proof approach requires use of contradiction [Thu Mar 6 21:43:14 2014] ezyang: ok, thanks. I will try the exercise after the next chapter then. [Thu Mar 6 22:09:47 2014] code: http://codepad.org/75x0S8uC error: Toplevel input, characters 20-30: Error: No interpretation for string "b = true". [Thu Mar 6 22:10:03 2014] In here http://www.cis.upenn.edu/~bcpierce/sf/Induction.html, it seems to work fine. [Thu Mar 6 22:14:06 2014] http://stackoverflow.com/questions/19212951/coq-error-when-trying-to-use-case-example-from-software-foundations-book got it here. [Fri Mar 7 02:56:52 2014] Hello everyone. [Fri Mar 7 02:57:22 2014] I am learning Coq for CPDT and tried the code http://lpaste.net/100826 [Fri Mar 7 02:57:28 2014] but getting error. [Fri Mar 7 02:57:52 2014] It's the same code given on page 49 [Fri Mar 7 02:58:40 2014] Looks like a bug in the code; you need to pass T to Cons and app [Fri Mar 7 02:58:46 2014] As they are not implicit arguments [Fri Mar 7 02:59:47 2014] ezyang: Thank you. [Fri Mar 7 03:03:17 2014] ezyang: By setting the Set Implicit Arguments, it pass the type arguments under the hood ? [Fri Mar 7 03:05:37 2014] yes, that's right. [Fri Mar 7 07:40:16 2014] anyone worked with canonical structures? [Fri Mar 7 09:20:48 2014] http://www.cis.upenn.edu/~bcpierce/sf/Logic.html#lab222 - they say of 'sumbool', "The only difference is that values of [sumbool] are declared to be in [Set] rather than in [Prop]; this is a technical distinction that allows us to compute with them." [Fri Mar 7 09:20:58 2014] what do they mean there? [Fri Mar 7 09:44:30 2014] ianjneu, around perhaps? [Fri Mar 7 10:24:14 2014] Hodapp: sumbool returns in Set, so they will not be erased at runtime, which allows you to inspect them to build values in Set [Fri Mar 7 10:25:36 2014] Ptival: Props are erased at runtime? [Fri Mar 7 11:37:35 2014] Hodapp: at extraction should I say [Fri Mar 7 11:38:37 2014] But if extraction is never performed here (if you're referring to what I think you are), it seems unlikely that that's what the author is talking about [Fri Mar 7 11:38:43 2014] when he says 'allows us to compute with them' [Fri Mar 7 11:40:24 2014] Hodapp: in order to allow this feature of not extracting Prop things, the system enforces a policy that you never compute over Prop things in the process of building Set things [Fri Mar 7 11:41:06 2014] Ptival: but in the context of Coq, what does 'compute over' mean? [Fri Mar 7 11:41:24 2014] for instance, pattern matching [Fri Mar 7 11:41:43 2014] ahh, so, one can never pattern match on a proposition? [Fri Mar 7 11:41:56 2014] or, a Prop specifically [Fri Mar 7 11:41:57 2014] you can, but only in order to build other propositions [Fri Mar 7 11:42:24 2014] hmmmmm [Fri Mar 7 11:42:44 2014] you cannot pattern match on propositions to build computationally-relevant terms, because the propositions are meant to disappear and the term could not compute without the proposition [Fri Mar 7 11:43:33 2014] what are 'computationally-relevant terms'? [Fri Mar 7 11:43:44 2014] and when you say 'meant to disappear' is this manifest anywhere besides extraction? [Fri Mar 7 11:43:59 2014] in Coq, the things in Set [Fri Mar 7 11:44:43 2014] and no, I think they disappear at extraction, but that still has consequences for you even if you don't plan to extract your code [Fri Mar 7 11:44:56 2014] this is the first I've seen Set thus far in the SF book [Fri Mar 7 11:45:03 2014] ok [Fri Mar 7 11:45:12 2014] so I'm trying to make sense of what they're doing [Fri Mar 7 11:45:35 2014] sure [Fri Mar 7 11:45:38 2014] but it appears that for a Prop in general you cannot 'introspect' on it in any way... is that right? [Fri Mar 7 11:45:51 2014] where pattern matching is a sort of introspection I guess [Fri Mar 7 11:46:00 2014] well you can inspect them in the context of other proofs [Fri Mar 7 11:46:38 2014] but you should not try to inspect them in the context of "computations", because you agreed with the system that you would not do that when you declared something in Prop [Fri Mar 7 11:46:47 2014] but is extraction here pretty specifically what it does when you're turning the code to Haskell, Scheme, or ML? [Fri Mar 7 11:47:19 2014] yes [Fri Mar 7 11:48:06 2014] the idea is that proofs are only here to make sure everything is fine, but you don't really want to run them everytime you run your code because they are usually computationally-intensive [Fri Mar 7 11:48:50 2014] so by enforcing this phase distinction between things meant to be computed and things meant to be checked once for all, the system can then produce code that contains only the things that matter [Fri Mar 7 11:49:53 2014] you'll see later that Prop has a few other features I guess, but for now you can think of it as a contract between you and Coq to mean "I'll only inspect Prop things to build other Prop things, never to build Set things" [Fri Mar 7 11:50:38 2014] ahh, okay [Fri Mar 7 12:04:51 2014] isnt the point of canonical structures automatic type inference? [Fri Mar 7 12:05:41 2014] (this is unrelated to the above, but im currently scratching my head about something to do with canonical structures) [Sat Mar 8 00:41:34 2014] joe9_: yes, but first: what don't you like about it? [Sat Mar 8 00:45:45 2014] jrw, seems too long. [Sat Mar 8 00:46:05 2014] joe9_: right, I'd say the repetitiveness of it is what's annoying. [Sat Mar 8 00:46:06 2014] and, I am sure there is a better way than brute-force'ing all the values. [Sat Mar 8 00:46:44 2014] joe9_: so one way would be to use other properties you might already have of orb and andb [Sat Mar 8 00:46:53 2014] jrw, btw, I cannot figure this out: http://codepad.org/GEJmbqvT [Sat Mar 8 00:46:58 2014] any hints, please? [Sat Mar 8 00:47:01 2014] in this case though, I'd recommend sticking with the brute force approach [Sat Mar 8 00:47:09 2014] jrw, ok, thanks. [Sat Mar 8 00:47:14 2014] iirc, SF hasn't introduced the semicolon operator yet [Sat Mar 8 00:47:22 2014] yes, it has not. [Sat Mar 8 00:47:23 2014] but this is a great example of why its useful [Sat Mar 8 00:47:52 2014] your whole proof can be reduced to "destruct b, c; simpl; reflexivity" [Sat Mar 8 00:48:07 2014] and even the simpl isn't necessary [Sat Mar 8 00:48:07 2014] oh, ok. thanks. [Sat Mar 8 00:48:23 2014] ok, then I will not bother with that. [Sat Mar 8 00:48:48 2014] Can you please give some hints about mult_plus_distr_r? [Sat Mar 8 00:48:52 2014] joe9_: for your other question, how did you decide to induct on p? [Sat Mar 8 00:49:14 2014] seemed easier than inducting on n or m. [Sat Mar 8 00:50:00 2014] joe9_: why? [Sat Mar 8 00:50:26 2014] jrw, you are correct. inducting on n is getting somewhere. let me try that. [Sat Mar 8 00:50:35 2014] joe9_: yep, that's going to be the right choice [Sat Mar 8 00:50:46 2014] generally speaking you want to induct on the variable that occurs as the structurally recursive argument to the functions your reasoning about [Sat Mar 8 00:51:12 2014] in this case, both + and * are defined by matching over their first argument, so n is a good choice [Sat Mar 8 00:52:28 2014] jrw, ok, thanks. [Sat Mar 8 00:52:38 2014] joe9_: that's not to say you couldn't get the induction to go through over p, just that it would be harder. you'll need lots of lemmas describing the behavior of + and * when their second argument is of the form "S x" [Sat Mar 8 00:52:53 2014] might be an interesting exercise to do the proof that way [Sat Mar 8 00:54:29 2014] http://codepad.org/bqIak4Sk stuck here. I will take a break and continue this tomorrow. I cannot seem to think. [Sat Mar 8 00:56:33 2014] jrw, sorry for the bother today. [Sat Mar 8 00:56:53 2014] joe9_: np, that's what irc is for :) [Sat Mar 8 00:58:15 2014] joe9_: don't do the second induction on m. rewrite by IHn immediately and look at the resulting goal. it should remind you of something... [Sat Mar 8 01:57:16 2014] why does coercions have the following effect on the printing of notations? http://pastebin.com/7wsVhEfj [Sat Mar 8 08:06:51 2014] so ive got this data type, 'fletter' and an order on fletter called 'fl_compare' [Sat Mar 8 08:08:05 2014] im trying to construct the following data type: list fletter such that for all elements x,y of this list, fl_compare x y = Eq [Sat Mar 8 08:09:18 2014] heres my attempt so far: https://privatepaste.com/9e950c60ce [Sat Mar 8 08:10:23 2014] been trying to use canonical structure, but to be honest i dont see its added value for my purposes. But perhaps im not applying it properly.. [Sat Mar 8 08:22:38 2014] any ideas? [Sat Mar 8 10:02:22 2014] brb [Sat Mar 8 11:31:11 2014] is there a way to take a currently existing data type, such as list, and impose additional constraints upon it? [Sat Mar 8 11:32:20 2014] a sigma, but then you need to unwrap it [Sat Mar 8 11:32:46 2014] with existT, right? [Sat Mar 8 11:57:33 2014] brb [Sat Mar 8 11:57:43 2014] library closing [Sat Mar 8 12:10:20 2014] jrw, that helped. thanks. [Sat Mar 8 13:11:52 2014] interesting. this Logic.v section that explains that their use of 'Definition' rather than 'Proof', and 'Set' rather than 'Prop', in order to have the proposition (in some sense) contain evidence, reminds me somewhat of http://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ where he talks about why not to use booleans [Sat Mar 8 13:20:59 2014] so I suppose the original Prop is, what, encoded in the existence of a well-founded 'sumbool' term? [Sat Mar 8 13:44:27 2014] Hodapp: Prop is very much like Set/Type, but it's designed to interact with those in such a way that terms of type Prop don't have to exist in compiled code (they can be erased). So when your goal is some type which is a Set, you're not allowed to eliminate something whose type is a Prop. [Sat Mar 8 13:47:53 2014] However, terms whose type is a Prop are allowed to appear in other data types, notably: Inductive sig (A:Set) (P:A -> Prop) : Set := exist (x:A) (_:P x). [Sat Mar 8 13:49:23 2014] At runtime, the proofs here can be erased, but they serve as a witness at compile time that the x : A actually satisfies the property that it was supposed to. [Sat Mar 8 13:50:44 2014] Hodapp: Personally, I find that restriction very frustrating to work under though. It's often a very natural thing to construct a result by doing induction over the structure of the proof of some property. [Sat Mar 8 13:51:11 2014] (But it makes sense if you're interested in conserving memory at runtime) [Sat Mar 8 13:52:33 2014] Just to be clear, you *are* allowed to eliminate things whose type is a Prop when your goal is to produce something else whose type is a Prop. [Sat Mar 8 13:53:12 2014] So, the Props *do* carry evidence, they just don't let you access that when you're making something in a Set or Type. [Sat Mar 8 13:54:01 2014] (It's evidence which won't be present at runtime in compiled code) [Sat Mar 8 13:54:32 2014] 'compiled code' meaning what here? [Sat Mar 8 13:54:48 2014] Ptival was explaining it yesterday and I think he was saying something similar [Sat Mar 8 13:55:23 2014] Hodapp: For example, if you extract OCaml or Haskell code [Sat Mar 8 13:55:34 2014] ah, so it's referring specifically to extraction? [Sat Mar 8 13:56:17 2014] Perhaps also coqc, but I don't know the details there [Sat Mar 8 13:56:35 2014] (In fact, I don't *really* know the details in any case :D) [Sat Mar 8 13:57:09 2014] But yeah, the intention is that when you compile Coq code to something else, it should be at least possible to erase all the Props. [Sat Mar 8 13:59:13 2014] I've yet to get to anything of the 'extraction' part of Coq [Sat Mar 8 15:18:34 2014] copumpkin, do you have any examples of how to use "a sigma" to put constraints on a list to build a new data type? (eg. a list of elements that relate to one another in some particular way) [Sat Mar 8 15:19:57 2014] using a sigma is the only way to do that? I thought i had something working (basically the list contains only elements that are equivalent by some order) but i had to prove the equivalence for each member of the list, even though the equivalence is trivial [Sat Mar 8 15:46:28 2014] How do I define this without using recursion? http://codepad.org/e2PihFaY from http://codepad.org/Djg5FG3o of http://www.cis.upenn.edu/~bcpierce/sf/Lists.html [Sat Mar 8 15:54:31 2014] the same for this http://codepad.org/fvq4x1pw . [Sat Mar 8 15:54:39 2014] the map has not been covered yet. [Sat Mar 8 15:55:22 2014] joe9_: you misunderstand the meaning of 'add' [Sat Mar 8 15:55:41 2014] it doesn't mean to add something to each element of the bag, but to add (put in) something to the bag [Sat Mar 8 15:56:31 2014] you should not expect to be able to define `member` without using recursion somewhere, however [Sat Mar 8 15:56:51 2014] that doesn't mean the recursion is explicit in the definition of `member` though [Sat Mar 8 15:57:15 2014] the question you should ask yourself is, do you already have functions defined which carry out the recursive operation, and which you can delegate to? [Sat Mar 8 16:00:00 2014] ystael: oh, ok. [Sat Mar 8 16:06:12 2014] ystael: thanks, I figured it out. [Sat Mar 8 16:06:21 2014] your explanation helped. [Sat Mar 8 16:06:32 2014] np, good luck [Sat Mar 8 19:09:31 2014] Hello, I'm new to Coq and getting stuck. I created a bool type and am using "Example" to check that some truth tables work on the type, but "Proof. reflexivity. Qed." isn't cutting it. Coq thinks there's a subgoal remaining. What am I don't wrong? I'm working from this book: http://www.cis.upenn.edu/~bcpierce/sf/Basics.html#slide-4 [Sat Mar 8 19:10:21 2014] begriffs: what is the theorem you're trying to prove? [Sat Mar 8 19:10:53 2014] Example test_orb: (orb true false) = true. [Sat Mar 8 19:11:16 2014] The first example in the page I linked. [Sat Mar 8 19:12:20 2014] Here's a gist with my code and coq's output https://gist.github.com/begriffs/9441011 [Sat Mar 8 19:12:21 2014] hmm this one should work by reflexivity :\ [Sat Mar 8 19:13:14 2014] begriffs: I think your display might not have updated correctly [Sat Mar 8 19:13:23 2014] can you go back/forth the Qed.? [Sat Mar 8 19:13:50 2014] Hm, I'm using vim with a plugin to run things through coqtop. Maybe I should try with the coqide to double check [Sat Mar 8 19:14:23 2014] Oh, it works in coqide. Hmm, frustrating. [Sat Mar 8 19:15:19 2014] are you using Coquille? [Sat Mar 8 19:16:00 2014] I'm on a mac and using https://github.com/eagletmt/coqtop-vim [Sat Mar 8 19:16:25 2014] The thing that worked however was "Coq Proof Assistant 8.4" [Sat Mar 8 19:18:33 2014] https://github.com/the-lambda-church/coquille this could be an alternative [Sat Mar 8 19:27:17 2014] Ptival: thank you, I'll give that a try. This irc channel is surprisingly active! [Sat Mar 8 19:35:09 2014] Yep, Coquille works. Just need to find a way to change the nasty highlight color. :) [Sat Mar 8 19:39:10 2014] http://codepad.org/UFGE6YMz can anyone please help with this? I seem to be stuck. It is from here: http://www.cis.upenn.edu/~bcpierce/sf/Lists.html Exercise: 3 stars (list_exercises) [Sat Mar 8 19:41:36 2014] joe9: it'd be nice if you posted the goal on which you're stuck in comments [Sat Mar 8 19:45:30 2014] Ptival: sure, http://codepad.org/qWeBjThc [Sat Mar 8 19:46:06 2014] Ptival: if I add a simple, I get this: http://codepad.org/jHoligbo [Sat Mar 8 19:51:25 2014] joe9: I'd prove a side lemma about rev of snoc [Sat Mar 8 19:52:12 2014] Ptival: makes sense. thanks. [Sat Mar 8 21:21:40 2014] Do I have to include a module or something to get access to the "admit" tactic? I'm getting "Error: The reference admit was not found in the current environment." [Sat Mar 8 23:37:48 2014] hmm no it's standard [Sat Mar 8 23:37:59 2014] are you sure you're in a proof setting? :) [Sat Mar 8 23:38:28 2014] begriffs: ^ [Sat Mar 8 23:52:14 2014] Ptival: got it. thanks. http://codepad.org/R44bdHKf [Sat Mar 8 23:55:45 2014] joe9: looks good [Sun Mar 9 12:51:30 2014] Has anyone got any suggestions for how I can make progress on this please? http://paste.debian.net/86578/ [Sun Mar 9 14:11:30 2014] Any help on how to do this, please? problem: http://codepad.org/RRSTW8nJ from http://www.cis.upenn.edu/~bcpierce/sf/Lists.html. My partial try: http://codepad.org/zourb5Rq , goal: http://codepad.org/yTcYLLx4 [Sun Mar 9 15:17:34 2014] From what I am learning from coq, this is my opinion. Please correct me if I am wrong. "It is hard for unit tests to cover all possible scenarios, whereas when we write a proof, we cover for all possible scenarios." -- Is this correct/ [Sun Mar 9 15:17:37 2014] s,/,?, [Sun Mar 9 15:25:31 2014] joe9: I wouldn't say it's just hard for unit tests to cover all possible scenarios, I'd say it's impossible. [Sun Mar 9 15:26:01 2014] joe9: Or, as Dijkstra put it, "Testing shows the presence, not the absence of bugs." [Sun Mar 9 15:45:01 2014] you can also go for partial correctness -- not proving everything totally correct but just preserving the most important invariants [Sun Mar 9 15:45:46 2014] this already helps a lot and is easy to get in expressively typed languages [Sun Mar 9 15:49:39 2014] hodapp: don't forget the knuth quote "beware of bugs in the above code, I have only proven it correct, not tested it" [Sun Mar 9 15:51:06 2014] so "proven program does not cover for all possible scenarios"? [Sun Mar 9 16:12:03 2014] joe9: what you prove is what you get. Sometimes one can overlook an important property of code, forget to prove it, and code may disregard this property. [Sun Mar 9 16:12:09 2014] as [a silly] example, one can prove that [List.append x y] returns list that contains all elements of [x] and [y]. [Sun Mar 9 16:12:12 2014] but also it's possible to prove that [List.append x y] returns list, where [x]'s elements are going in an order they are in [x] list, and then [y]'s elements in order. [Sun Mar 9 16:16:15 2014] proofs are a bit like tests: there was a case when i found a logic error in my code, then i added proof that proves absence of this error. so this proof guarantees i have no this error (even if i modify function's code later), and makes my development more trustworthy. [Sun Mar 9 16:16:22 2014] yeah I've had times where I proved a property, only to realize that it did not mean exactly what I thought it did [Sun Mar 9 16:20:41 2014] Ptival: this is a common argument against proving in general. [Sun Mar 9 16:20:51 2014] Ptival: a flawed argument, obviously. [Sun Mar 9 16:21:23 2014] Hello. [Sun Mar 9 16:22:22 2014] I am have main project folder "src" and subfolder "sub". Can I import src/Upper.v in src/sub/Lower.v? [Sun Mar 9 16:24:23 2014] jdoles: personally i'm not against either proving or testing, but do you really think you are always be able to catch all important properties of your code? What about human factor? [Sun Mar 9 16:24:52 2014] jdoles: yeah it is obviously flawed in that if you don't understand what you're talking about you're in trouble in any setting [Sun Mar 9 16:26:00 2014] Rc43: this has to do with you coq-loadpath [Sun Mar 9 16:26:34 2014] Ptival, oh, thanks [Sun Mar 9 16:32:34 2014] gdsfh: practically speaking it's valuable to know what to prove and what not for a specific service. [Sun Mar 9 16:33:31 2014] gdsfh: but theoretically getting 100% is certainly possible. [Sun Mar 9 16:33:42 2014] jdoles: for tests too, obv. [Sun Mar 9 16:34:01 2014] gdsfh: sure, but you are much less certain then of its correctness. [Sun Mar 9 16:34:19 2014] gdsfh: and I think the main advantage for proofs is that you don't need to trust someone else anymore. [Sun Mar 9 16:34:41 2014] gdsfh: if someone has just written a bunch of tests there is no guarantee it's completely solid. [Sun Mar 9 16:35:24 2014] i know this. Also when someone has written a bunch of proofs. But why it's an argument against proving? It's also against testing. [Sun Mar 9 16:35:26 2014] gdsfh: I think it's a *huge* productivity improvement that one no longer needs to see a computing system as a system but as an idealized mathematical machine. [Sun Mar 9 16:36:13 2014] gdsfh: you mean the thing I talked about before? [Sun Mar 9 16:36:27 2014] yes, about common argument. [Sun Mar 9 16:36:47 2014] gdsfh: the argument goes like this: humans might make a mistake in the specification and thus they prove the wrong thing and hence there is still a bug in the final product. [Sun Mar 9 16:36:49 2014] about other things you wrote -- i agree completely. [Sun Mar 9 16:37:04 2014] gdsfh: like I said: it's a flawed argument. [Sun Mar 9 16:37:31 2014] gdsfh: however some people without university backgrounds (or bad university backgrounds) are also walking around on this planet. [Sun Mar 9 16:37:44 2014] gdsfh: and they are just fueled by ignorance. [Sun Mar 9 16:41:15 2014] ah, i understood your point. symmetric flawed arguments could be used by both sides of "proofs vs tests" holywar. [Sun Mar 9 16:43:16 2014] lol, i had only 11 years of school education. (now i'm 31.) and i use proofs everywhere i can, because i know their power. [Sun Mar 9 16:47:37 2014] well, it's a real concern, but it does not constitute an argument against proving [Sun Mar 9 17:34:07 2014] OK, I made a boiled-down standalone version of my problem. Could anyone help me with proving http://paste.debian.net/86657/ please? [Sun Mar 9 17:36:56 2014] That's weird, seems to me it should just work [Sun Mar 9 17:41:07 2014] Well, that would be nice... :-) [Sun Mar 9 18:10:09 2014] Igloo: maybe you meant to mark "ps" as the structural argument using "{struct ps}"? [Sun Mar 9 18:13:18 2014] jrw: Aha, ta [Sun Mar 9 18:50:44 2014] gdsfh: about using proofs everywhere. which programming language do you use? Do you do so even for general programs? [Sun Mar 9 18:50:54 2014] such as maybe a webscraper, etc. [Sun Mar 9 19:15:56 2014] joe9: "everywhere _i can_". Most of my code have no proofs/tests at all. I have proofs for some Coq code (extracted to OCaml), OCaml code (manually, by direct translation from Coq to OCaml), some C code (with not so direct translation). Usually I prove critical code, it's small, and properties are known beforehand. [Sun Mar 9 19:16:20 2014] but proving is acceptable for general programs for end-users too, for example, http://goto.ucsd.edu/quark/ (i didn't participate in this project, just for clarity) [Sun Mar 9 19:22:20 2014] the difference to testing may lie in the fact that for tests, you need their whole code to assess their correctness/completeness; for proofs, you only need to read their statements (types) [Sun Mar 9 19:22:29 2014] (*also lie) [Mon Mar 10 01:36:12 2014] While learning coq I've been creating some simple arithmetic functions. They operate on my custom "nat" type. How can I get coq to convert arabic numerals into my type? Right now it says 'Error: The term "5" has type "Datatypes.nat" while it is expected to have type "nat".' [Mon Mar 10 08:52:43 2014] Hi folks... I'm with a little trouble in defining a function using dependent pattern matching. I've already defined it in Agda without any trouble, but in Coq I got stuck. Some could help me with this? The code is on the following gist: https://gist.github.com/rodrigogribeiro/9464436. The trouble is function eqVarDec, that I do not know how to express the required dependency between arguments and return type. [Mon Mar 10 10:08:16 2014] relevant article gdsfh http://www.reddit.com/r/netsec/comments/1lyxxr/quark_a_web_browser_with_a_formally_verified/ [Mon Mar 10 11:24:44 2014] Hello. [Mon Mar 10 11:25:02 2014] Rc43: hey [Mon Mar 10 11:25:03 2014] Is there way to provide proof of termination for my fixpoints? [Mon Mar 10 11:25:25 2014] Which fixpoints would those be? [Mon Mar 10 11:26:00 2014] Currently I have fixpoint args n {struct n} : option result, where n is only for termination checker. And I have proof that forall args exists n such that fixpoint = some result. [Mon Mar 10 11:27:27 2014] I can write wrapper that takes this functions and the theorem, computes n from theorem and gives to function. But this makes unnecessary computations. [Mon Mar 10 11:29:53 2014] Try Program Fixpoint instead. [Mon Mar 10 12:33:15 2014] hi [Mon Mar 10 12:33:29 2014] so i have this proven: Lemma some_lemma : forall y, forall x, fl_lt x y -> Acc fl_lt x. [Mon Mar 10 12:34:14 2014] now im trying to use this to prove this: Lemma some_other_lemma : forall x, Acc fl_lt x [Mon Mar 10 12:35:25 2014] but somehow i cant seem to get rid of some loose ends on that [Mon Mar 10 12:35:32 2014] wait ill paste some [Mon Mar 10 12:38:29 2014] those lemmas: https://privatepaste.com/770f807238 [Mon Mar 10 12:39:21 2014] current proof state: https://privatepaste.com/0ce62ece70 [Mon Mar 10 12:41:18 2014] what would be the proper approach here? [Mon Mar 10 12:56:56 2014] induct on x [Mon Mar 10 12:57:22 2014] and use your lemma in the IH case(s) [Mon Mar 10 12:57:59 2014] hm [Mon Mar 10 12:58:31 2014] there is no IH case though [Mon Mar 10 12:58:59 2014] when i do that [Mon Mar 10 12:59:24 2014] x is a trivial inductive type? Acc should also then be trivial. [Mon Mar 10 13:00:01 2014] what defines a trivial inductive type? [Mon Mar 10 13:00:17 2014] no self references. [Mon Mar 10 13:00:38 2014] yea its trivial [Mon Mar 10 13:00:53 2014] what do you mean by 'Acc should be trivial'? [Mon Mar 10 13:01:43 2014] You should only have to use constructors and no induction principles, which really makes your lemma unnecessary. [Mon Mar 10 13:02:17 2014] ? [Mon Mar 10 13:02:29 2014] could you elaborate on that please [Mon Mar 10 13:02:50 2014] how can i use constructors to prove that forall x, Acc fl_lt x [Mon Mar 10 13:03:05 2014] paste your full definitions and I'll show you. [Mon Mar 10 13:03:10 2014] sure [Mon Mar 10 13:05:40 2014] https://privatepaste.com/4bfc3f87e2 [Mon Mar 10 13:16:16 2014] ok got it. [Mon Mar 10 13:16:23 2014] red; intros []; intros [] []; do 3 (let H := fresh in constructor; intros [[] []] H; compute in H; try solve [destruct H]). [Mon Mar 10 13:17:23 2014] what does intros [] mean [Mon Mar 10 13:17:42 2014] let x := fresh in intro x; destruct x. [Mon Mar 10 13:18:54 2014] wow thats pretty cool :) [Mon Mar 10 13:19:32 2014] alright im going to have to take a closer look at this [Mon Mar 10 13:19:35 2014] thanks very much! :) [Mon Mar 10 13:29:26 2014] why do 3? [Mon Mar 10 13:31:05 2014] nevermind [Mon Mar 10 13:35:11 2014] fletter, letter, acute. [Mon Mar 10 14:20:05 2014] need help with this? I think simpl is doing something wrong here. partial proof: http://codepad.org/FlsEy69Q , goal: http://codepad.org/9bCiwpTO . But, when I do simpl now, it gives me this as the goal: http://codepad.org/Ymg7jp7W <- this is not correct. [Mon Mar 10 14:20:15 2014] Any thoughts on what I could be missing, please? [Mon Mar 10 14:56:18 2014] joe9: Your definition of rev must be wrong. [Mon Mar 10 14:57:51 2014] rev [] = [] ; rev (s :: t) = snoc (rev t) s [Mon Mar 10 14:58:08 2014] however you must have made the last snoc simply snoc t s. [Mon Mar 10 15:10:09 2014] ianjneu: thanks. you are correct. that was my mistake. Thanks again. [Mon Mar 10 15:25:25 2014] proof: http://codepad.org/CYy78A47 , goal: http://codepad.org/sxOMGrOY . adding reflexivity. to the proof gives this error: http://codepad.org/3NKKdk2q [Mon Mar 10 15:25:34 2014] Any thoughts on what I am missing, please? [Mon Mar 10 15:27:11 2014] destruct p; simpl. [Mon Mar 10 15:29:12 2014] ianjneu: thanks, that helped. [Mon Mar 10 16:35:29 2014] do ssreflect users never use inversion? i find no occurence for it in the sources. how would i prove an inductive definition to be decidable then? [Mon Mar 10 18:28:25 2014] Hi. Does anyone know how long will the website be down? (or at least is it down since a long time) ? [Mon Mar 10 18:44:51 2014] Hi. Does anyone know how long will the website be down? (or at least is it down since a long time) ? [Mon Mar 10 18:48:04 2014] proof: http://codepad.org/g2A52Z5p , goal: http://codepad.org/ccEkaSxa . Any thoughts on how to solve this, please? [Mon Mar 10 18:50:30 2014] joe9: I'd prove that "map f (xs ++ ys) = map f xs ++ map f ys" and the rest should be relatively straightforward. [Mon Mar 10 18:52:32 2014] Hi folks... I'm with a little trouble with dependent pattern matching. The problematic code is in the following gist:https://gist.github.com/rodrigogribeiro/9464436 . If someone could helme with some pointer on how I could define the function eqVarDec (in the gist), I would appreciate. [Mon Mar 10 18:54:57 2014] rribeiro: is the convoy pattern relevant here? [Mon Mar 10 18:55:53 2014] jrw: Convoy? What is this? [Mon Mar 10 18:57:19 2014] jrow, thanks. [Mon Mar 10 18:57:41 2014] rribeiro: http://adam.chlipala.net/cpdt/html/MoreDep.html [Mon Mar 10 18:57:43 2014] search for convoy [Mon Mar 10 18:58:52 2014] jrw: I've googled and found the same link as you provide... I'm reading it now! Thanks for the tip! [Mon Mar 10 18:59:21 2014] jrw: I've googled and found the same link as you provide... I'm reading it now! Thanks for the tip! [Tue Mar 11 04:36:07 2014] Hello. [Tue Mar 11 04:36:38 2014] What is the syntax for strings? [Tue Mar 11 04:36:49 2014] Like "123" in other langs. [Tue Mar 11 05:10:55 2014] Rc43: http://pastebin.com/KnCDjvZn [Tue Mar 11 05:11:29 2014] String : ascii -> string -> string [Tue Mar 11 05:13:45 2014] anderslundstedt, ye, I didn't open scope. [Tue Mar 11 06:23:46 2014] Is there unchecked exceptions in Coq? I want to use them for my mocks. [Tue Mar 11 06:24:14 2014] Now I use "Axiom error : forall {X}, X.", but not sure that this appropriate perfectly. [Tue Mar 11 09:31:45 2014] Also, is it possible to "trace" Coq code? [Tue Mar 11 10:01:54 2014] 'trace' in what sense? [Tue Mar 11 10:12:06 2014] Hodapp, printing strings during evaluation. [Tue Mar 11 10:12:52 2014] Hodapp, E.q. "match x with | S x' => f x' | O => 1 end". [Tue Mar 11 10:34:55 2014] can someone please help me with this proof? http://codepad.org/7RR2QlSs I am stuck here: http://codepad.org/geysJ4sT [Tue Mar 11 10:36:35 2014] sorry, got it: http://codepad.org/jHucBOgu [Tue Mar 11 12:12:01 2014] joe9: so you didn't need map_app? sorry I sent you down the wrong path... [Tue Mar 11 12:14:45 2014] oh I see, you proved map_snoc [Tue Mar 11 12:14:59 2014] which is a special case [Tue Mar 11 12:15:01 2014] nice. [Tue Mar 11 12:18:06 2014] Rc43: tracing -- maybe this approach will work for you: https://bitbucket.org/gds/coq-breakpoints/src ? But it's not exactly what you want. [Tue Mar 11 12:29:54 2014] jrw, thanks. [Tue Mar 11 15:07:49 2014] just wanted to check, is induction a bullet-proof way of proving theorems. Just because something works with 0 (in case of nat's), does not mean it will work for all numbers. [Tue Mar 11 15:08:06 2014] I am a non-math guy, please excuse if the above statement is stupid. [Tue Mar 11 15:09:06 2014] joe9: induction on natural numbers is true (reliable) in all sane logics [Tue Mar 11 15:09:49 2014] remember that the inductive step has a hypothesis: forall n, P n -> P (S n) [Tue Mar 11 15:13:28 2014] the induction schema principle that if P holds for 0 and if P holds for (n + 1) whenever P holds for n, then P holds for all n. the key is the "if P holds for (n + 1) whenever..." part. if the preceding were true, but P didn't hold for all n, then there would be a least n for which it failed, say m. but then P holds for m - 1, and so for m as well. is this what you mean? [Tue Mar 11 15:14:12 2014] *induction schema for a proposition P; sorry about the typo [Tue Mar 11 15:21:17 2014] pordan30: yes, that is along the lines of what I was trying to get to. [Tue Mar 11 15:21:23 2014] ystael: pordan30 thanks. [Tue Mar 11 15:26:28 2014] joe9: you can also think of it like a game: suppose (a) P 0 and (b) P n -> P (n + 1) for all n. then you see if you can find a number for which P fails. if you give me 0, I invoke (a). If you give me 1, I invoke (a) and (b) once. In general, if you give me m, I invoke (a) and then (b) m times. [Tue Mar 11 15:34:56 2014] pordan30: induction only holds if both a and b hold. if P n -> P (n+1) does not hold, then induction does not hold. correct? [Tue Mar 11 15:39:38 2014] joe9: that's right. if P n -> P (n + 1) doesn't hold, then there would be a particular m for which P fails. [Tue Mar 11 15:39:50 2014] (or at least one such m) [Tue Mar 11 15:40:04 2014] joe9: better to say, the induction *principle* is true, but if P n -> P (n + 1) is not true, then you cannot use induction to prove forall n, P n [Tue Mar 11 15:40:12 2014] (this doesn't mean that forall n, P n is false!) [Tue Mar 11 15:41:59 2014] pordan30: ystael, ok, thanks. [Tue Mar 11 15:43:39 2014] really? suppose you have a proof M that forall n, P n holds. then P n -> P (n + 1) holds since M proves P (n + 1). what am i missing? [Tue Mar 11 21:44:44 2014] I am trying to figure out how to do this without using apply? http://codepad.org/2uxzknEk , my attempt: http://codepad.org/tUeX580V goal: http://codepad.org/GD3G4QDZ [Tue Mar 11 21:44:50 2014] can anyone please help? [Tue Mar 11 21:46:50 2014] Not sure, but try 'rewrite (eq2 ?? ??)', filling in the blanks appropriately [Tue Mar 11 21:47:08 2014] maybe you need three arguments [Tue Mar 11 22:17:21 2014] ezyang: ok, thanks. [Tue Mar 11 22:19:17 2014] ezyang: thanks, that helped. [Wed Mar 12 03:56:32 2014] Hello. [Wed Mar 12 03:57:59 2014] How to print strings in convinient way? [Wed Mar 12 04:00:21 2014] I have strange representation of string in list, but I can't reproduce it yet. [Wed Mar 12 04:00:54 2014] My strings are represented (by Eval) in constructor-way. [Wed Mar 12 04:01:37 2014] I.e. String.String "A" (String.String. "B" (.... String.EmptyString))))) [Wed Mar 12 04:03:58 2014] Aah =/ IT's just because I didn't import String in one file. [Wed Mar 12 05:08:32 2014] Is there option of "coqc", which increaases stack size? [Wed Mar 12 07:46:16 2014] how do i define a data type that is a list such that each element is equivalent according to some comparison function f? [Wed Mar 12 08:43:22 2014] is there a tactic that tries all applicable constructors if they provide a trivial solution? how could i write that? [Wed Mar 12 11:33:27 2014] How do I prove this, please? [Wed Mar 12 11:33:44 2014] I know that with rev_involutive, l = rev (rev l). [Wed Mar 12 11:34:12 2014] with intros, I have: http://codepad.org/1kAMyTYv [Wed Mar 12 11:42:07 2014] joe9: you've proved rev_snoc? [Wed Mar 12 12:09:42 2014] ianjneu: thanks. I did. let me check it. [Wed Mar 12 12:10:54 2014] ianjneu: I am not sure how rev_snoc can help. rev_snoc: forall (X : Type) (v : X) (s : list X), rev (snoc s v) = v :: rev s [Wed Mar 12 12:11:21 2014] I need to substitute the l above with rev l'. [Wed Mar 12 12:12:11 2014] joe9: did you try induction on l to prove rev_involutive? [Wed Mar 12 12:12:30 2014] sorry, got it. all i needed was a rewrite -> H. [Wed Mar 12 12:12:42 2014] sorry that I missed that. [Wed Mar 12 12:12:46 2014] np [Wed Mar 12 12:13:11 2014] http://codepad.org/ZG8K7MGi [Wed Mar 12 12:50:47 2014] in sf, the inversion tactic is confusing. www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html did anyone feel the same and is there something that helped with the confusion? [Wed Mar 12 12:54:38 2014] what about it is confusing? [Wed Mar 12 12:55:02 2014] it seems to prove things that are wrong. [Wed Mar 12 12:55:11 2014] from the examples. [Wed Mar 12 12:55:55 2014] not quite [Wed Mar 12 12:56:49 2014] It can help you use inherent properties of constructors to show your assumptions are contradictory, making the conclusion vacuously true. [Wed Mar 12 12:57:35 2014] It also allows you to decompose a value into its components (like destruct) but maintain equality information, in case you need it. [Wed Mar 12 13:15:47 2014] If there are no remaining goals or existentials, is Guarded. enough to ensure Qed. will succeed? [Wed Mar 12 13:29:03 2014] napping: no, you can still have universe inconsistencies [Wed Mar 12 13:32:26 2014] I'm trying to write up a few ways of proving something so it can also be stepped through in proof general [Wed Mar 12 13:32:48 2014] I guess I'll just make separate Goals. [Wed Mar 12 13:33:15 2014] Undo and Reset mess up navigation, and Abort doesn't tell you by itself that the Qed would actually go through [Wed Mar 12 14:46:42 2014] How can I write this proof using apply instead of rewrite? http://codepad.org/bji5iRe2 [Wed Mar 12 14:51:26 2014] joe9: if you subst first can you just apply rev_invol? [Wed Mar 12 15:17:29 2014] joe9: you're using redundant syntax. You can just write rewrite H,rev_involutive. [Wed Mar 12 15:25:16 2014] SF doesn't give a lot of these shortened syntax forms [Wed Mar 12 15:39:43 2014] -> is always unnecessary [Wed Mar 12 15:45:56 2014] ianjneu: whaa? always? [Wed Mar 12 15:51:35 2014] jrw, ianjneu Hodapp, thanks. [Wed Mar 12 15:52:23 2014] can you please help me prove this: my attempt: http://codepad.org/qCqkLknz , goal: http://codepad.org/QxprlXxw [Wed Mar 12 16:00:26 2014] jrw, for the previous question regarding using apply instead of rewrite, this is what I get. proof: http://codepad.org/6ZrypZyU , goal: http://codepad.org/jznEUJlJ , error: http://codepad.org/nD6laGOm [Wed Mar 12 16:23:07 2014] jrw, forget the above question, I got it. Proof. intros. rewrite -> H. symmetry. apply rev_involutive. Qed. [Wed Mar 12 17:26:16 2014] hi [Wed Mar 12 17:26:41 2014] ive been kinda struggling with this for a couple days [Wed Mar 12 17:26:58 2014] it shouldnt be too difficult i dont think [Wed Mar 12 17:28:47 2014] how does one define a data type that is a list, where each element of that list relates to the next element by some function f (for example forall x, forall y In l, f x y = Eq) [Wed Mar 12 17:28:50 2014] ? [Wed Mar 12 17:38:51 2014] hmmm I guess there could be different ways [Wed Mar 12 17:39:03 2014] im all ears :) [Wed Mar 12 17:42:24 2014] in a language with induction-recursion, one could probably make it very intrinsic by having a cons constructor that does something like Cons : (x : T) -> (l : flist T) -> ((y : T) -> In y l -> f x y) -> flist T [Wed Mar 12 17:43:13 2014] is coq such a language? [Wed Mar 12 17:43:23 2014] not yet, AFAIK [Wed Mar 12 17:43:51 2014] too bad, that would be quite elegant [Wed Mar 12 17:44:36 2014] on the opposite side of the spectrum, a super extrinsic way would be the type {l : list T | forall a b c, l = a ++ b :: c -> (forall x, In x c -> f x b) } [Wed Mar 12 17:45:06 2014] that works in coq? [Wed Mar 12 17:45:12 2014] oh wait, you only want to relate to the next [Wed Mar 12 17:45:18 2014] sorry I was relating to everyone in the tail [Wed Mar 12 17:45:20 2014] well, forall is ok too [Wed Mar 12 17:45:29 2014] i thought the next would be simpler [Wed Mar 12 17:45:39 2014] its a transitive relation, so doesnt matter [Wed Mar 12 17:45:54 2014] {l : list T | forall a b c d, l = a ++ b :: c :: d -> f b c } [Wed Mar 12 17:45:57 2014] something like this [Wed Mar 12 17:46:08 2014] but you get the idea [Wed Mar 12 17:46:35 2014] hm [Wed Mar 12 17:46:52 2014] thats a data type? [Wed Mar 12 17:47:17 2014] what are the {} for [Wed Mar 12 17:47:42 2014] depending on your jargon, you might call them subset types [Wed Mar 12 17:48:10 2014] ah so basically you declare a subset of your original list by this function [Wed Mar 12 17:48:14 2014] (akin to what people could call Sigma types, dependent sums, or dependent pairs) [Wed Mar 12 17:48:21 2014] yeah [Wed Mar 12 17:48:30 2014] do you maybe have a working example of this? [Wed Mar 12 17:48:34 2014] it basically consist of a list l, paired with a proof that it has the property you care about [Wed Mar 12 17:49:03 2014] i have tried to mess around with sigT and existT but no luck [Wed Mar 12 17:49:03 2014] this is what people call the "extrinsic" approach, because the list itself does not have any property baked in [Wed Mar 12 17:49:12 2014] ahh right [Wed Mar 12 17:49:16 2014] you just carry proofs around with it [Wed Mar 12 17:49:17 2014] so its like a workaround [Wed Mar 12 17:49:21 2014] hm :/ [Wed Mar 12 17:49:28 2014] whereas the intrinsic approach tries to make the list be correct by construction [Wed Mar 12 17:49:40 2014] and i guess what youre saying is that coq only supports these extrinsic workaround type approaches [Wed Mar 12 17:49:50 2014] oh no, Coq supports both approaches [Wed Mar 12 17:50:01 2014] really? I thought you said the former wasnt supported yet [Wed Mar 12 17:50:30 2014] no, I said induction-recursion was not supported yet, and has the ability to make the extrinsic approach much nicer [Wed Mar 12 17:50:44 2014] nicer how? [Wed Mar 12 17:50:59 2014] can it work without sigT and existT? [Wed Mar 12 17:51:01 2014] I'm pretty sure there's always a way to get around it but it implies messing a little bit with universes [Wed Mar 12 17:51:34 2014] with universes? [Wed Mar 12 17:51:56 2014] and then working with intrinsic datatypes in Coq can be a bit tedious, whereas other languages like Agda/Idris have facilities that make it a bit easier for you [Wed Mar 12 17:52:02 2014] yeah [Wed Mar 12 17:52:25 2014] that way you dont have to use sigT and existT? [Wed Mar 12 17:52:28 2014] the problem is that if you want to encode the property that the "rest" of the list relates to the head [Wed Mar 12 17:52:37 2014] you need to force it in your Cons constructor [Wed Mar 12 17:52:51 2014] one problem i had with sigT and existT, was that i had to provide a proof of every single outcome of the subset declaring function [Wed Mar 12 17:52:56 2014] and to do this you need to be able to "observe" the tail in the constructor [Wed Mar 12 17:53:17 2014] but you're trying to observe the type you're currently defining, and that can be tricky [Wed Mar 12 17:53:37 2014] hmmm [Wed Mar 12 17:53:54 2014] what do you call the "subset declaring function"? [Wed Mar 12 17:53:59 2014] basically [Wed Mar 12 17:54:26 2014] the list consists of elements that are compared by some function f, and forall x, forall y, f x y = Eq should be the case [Wed Mar 12 17:54:40 2014] but coq wants a proof of that statement [Wed Mar 12 17:54:52 2014] yes it will want a proof [Wed Mar 12 17:54:57 2014] well [Wed Mar 12 17:55:11 2014] but the proof is just "compute; trivial." [Wed Mar 12 17:55:54 2014] the datatype {x : T | P x} only contains elements of the form (existT x pf) such that x has type T and pf has type P x for that x [Wed Mar 12 17:56:21 2014] so to build elements you need to build the proofs [Wed Mar 12 17:56:34 2014] {} is pseudocode or does that work in coq? [Wed Mar 12 17:56:55 2014] it's a notation that should be in scope by default I think [Wed Mar 12 17:57:13 2014] it stands for something like (sigT (fun x => P x)) [Wed Mar 12 17:57:48 2014] but what if you want to make a data type spanning over nat for example [Wed Mar 12 17:57:54 2014] defined in Coq.Init.Specif http://coq.inria.fr/stdlib/Coq.Init.Specif.html [Wed Mar 12 17:58:11 2014] how can you generate such proofs automatically? [Wed Mar 12 17:58:12 2014] { n : nat | odd n } [Wed Mar 12 17:58:19 2014] ah! [Wed Mar 12 17:58:30 2014] then you need some help from Coq :) [Wed Mar 12 17:58:32 2014] especially since the proof is just "compute; trivial; qed." [Wed Mar 12 17:58:39 2014] for all instances [Wed Mar 12 17:58:42 2014] I can show you one way: [Wed Mar 12 18:01:36 2014] http://paste.awesom.eu/EbEO here are ways to do so [Wed Mar 12 18:02:47 2014] another way is using the Program extension of Coq that helps with separating implementation from proofs for such kinds of lightweight dependent types [Wed Mar 12 18:03:12 2014] but doesnt that still require interaction between user and coq? [Wed Mar 12 18:03:29 2014] sure [Wed Mar 12 18:03:33 2014] what i meant was, is it possible for coq to automatically infer the proof without even going into proof mode [Wed Mar 12 18:03:40 2014] ah! [Wed Mar 12 18:03:50 2014] not always, but sometimes yes [Wed Mar 12 18:04:00 2014] in the case of such trivial proofs? [Wed Mar 12 18:04:12 2014] let me think of how you could achieve this quickly :\ [Wed Mar 12 18:04:30 2014] getting Coq to work out proofs automatically without entering proof mode is not trivial [Wed Mar 12 18:04:32 2014] because otherwise how does one create a data type where there are dozens and dozens of combinations [Wed Mar 12 18:04:51 2014] or should one write those all out manually? [Wed Mar 12 18:04:58 2014] one way I can think of is using Canonical Instances in the way described in the "proof automation less ad hoc" paper, however it's a lot of work to set up [Wed Mar 12 18:05:12 2014] haha yea i was messing around with canonical types too :p [Wed Mar 12 18:05:22 2014] and i did get it to work [Wed Mar 12 18:05:40 2014] but i couldnt get from compairing two values to comparing values in a list [Wed Mar 12 18:06:18 2014] yeah it's tricky [Wed Mar 12 18:06:26 2014] because of the unification mechanism [Wed Mar 12 18:06:36 2014] also I feel like it might be brittle if Coq changes :( [Wed Mar 12 18:06:45 2014] haha thats ok [Wed Mar 12 18:07:15 2014] the technique is really nice but some built-in support for these things would be much better than their crazy hacks to make it work :) [Wed Mar 12 18:07:27 2014] hm [Wed Mar 12 18:07:50 2014] what approach would you take in my situation? [Wed Mar 12 18:08:00 2014] anyway, no I can't really think of a lightweight way to get Coq to fill your proofs for you without at least typing one tactic [Wed Mar 12 18:08:20 2014] I mean, that's what Program should do for you [Wed Mar 12 18:08:20 2014] and then just perform that tactic manually a dozen times? [Wed Mar 12 18:08:41 2014] maybe i can reuse the same proof? [Wed Mar 12 18:08:56 2014] well you can do refine( program with many proof obligations as _ ); powerful_tactic_that_solves_all_obligations. [Wed Mar 12 18:09:21 2014] you should take a look at Program [Wed Mar 12 18:09:29 2014] so the proof becomes part of the definition right [Wed Mar 12 18:09:37 2014] but maybe some other people will have better ideas for you [Wed Mar 12 18:09:48 2014] I have a slow brain right now :) [Wed Mar 12 18:10:14 2014] haha thats ok these are exactly the answers i was looking for [Wed Mar 12 18:10:35 2014] even considering that its not so simple as i was hoping is an answer in and of itself [Wed Mar 12 18:10:57 2014] its weird though because this doesnt seem like a very sophisticated data type [Wed Mar 12 18:11:22 2014] yeah it is not complicated in fact [Wed Mar 12 18:13:32 2014] alright so [Wed Mar 12 18:14:09 2014] what i had working was this: https://privatepaste.com/711bbd6c17 [Wed Mar 12 18:14:18 2014] but i dont like how ugly that is [Wed Mar 12 18:14:46 2014] that is what you were talking about though right? [Wed Mar 12 18:15:36 2014] its weird though, im using the same proof twice for different equalities [Wed Mar 12 18:15:59 2014] (only saw that just now) [Wed Mar 12 18:29:06 2014] alright [Wed Mar 12 18:29:11 2014] im gonna call it a day [Wed Mar 12 18:29:19 2014] thanks for hearing me out Ptival :) [Wed Mar 12 18:29:31 2014] ill try and mess around with what i had some more, perhaps its not that bad after all [Wed Mar 12 18:32:25 2014] roosbeef: where's the proof used twice? [Wed Mar 12 18:32:56 2014] um [Wed Mar 12 18:32:58 2014] its 'pr' [Wed Mar 12 18:33:31 2014] if you look below its used both for eqCons a e as for eqCons a a [Wed Mar 12 18:33:38 2014] which i dont fully understand [Wed Mar 12 18:34:37 2014] oh that's not weird :) [Wed Mar 12 18:35:38 2014] a nice thing about your property is that it is computable [Wed Mar 12 18:37:46 2014] yea [Wed Mar 12 18:38:07 2014] but the proof only computes some other proposition right [Wed Mar 12 18:38:46 2014] so your type fl_eq à à is really just computed to be the True type [Wed Mar 12 18:38:57 2014] anf your proof pf is just I, the inhabitant of True [Wed Mar 12 18:39:12 2014] ok that makes sense then [Wed Mar 12 18:39:26 2014] I guess what is weird is that [Wed Mar 12 18:39:41 2014] fl_compare à è seems to return Eq? [Wed Mar 12 18:39:46 2014] yea [Wed Mar 12 18:39:52 2014] because they are equivalent [Wed Mar 12 18:39:58 2014] ok [Wed Mar 12 18:40:05 2014] well then all is well [Wed Mar 12 18:40:10 2014] yep [Wed Mar 12 18:40:47 2014] one last question how do i infer any properties from this data type? [Wed Mar 12 18:41:14 2014] for example if i know the first letter is a then i know the next letter is equivalent, how do i infer this? [Wed Mar 12 18:41:37 2014] my formulation on this question is a bit fuzzy i guess [Wed Mar 12 18:41:44 2014] yeah I'm not sure what you mean [Wed Mar 12 18:42:06 2014] but what im trying to get at is that the data type is 'wrapped' by sigT and 'unwrapped' by existT, right? [Wed Mar 12 18:42:18 2014] no [Wed Mar 12 18:42:39 2014] oh whats the role of those two functions then [Wed Mar 12 18:42:44 2014] sigT is a type constructor [Wed Mar 12 18:42:52 2014] existT is a data constructor for the type sigT [Wed Mar 12 18:43:26 2014] right so you use sigT in the data type definition [Wed Mar 12 18:43:36 2014] and existT in the declaration of some instance of that data type [Wed Mar 12 18:46:16 2014] yes [Wed Mar 12 18:46:43 2014] alright ill just mess around with it a bit tomorrow, im puzzled as to im going to extract that equivalence information [Wed Mar 12 18:46:57 2014] (in proof mode, when its relevant) [Wed Mar 12 18:47:22 2014] thanks a lot for you help! [Wed Mar 12 18:47:53 2014] things have become much clearer to me :) [Wed Mar 12 18:53:16 2014] cool [Wed Mar 12 23:16:04 2014] current goal is S1_pmul (a @ b) 1 = S1_pmul a 1 @ S1_pmul b 1 [Wed Mar 12 23:16:10 2014] Error: Found no subterm matching "S1_pmul a 1" in the current goal. [Wed Mar 12 23:16:13 2014] AUGH [Wed Mar 12 23:16:20 2014] Any idea what it could be? [Wed Mar 12 23:16:39 2014] Try turning on printing of implicit parameters and try again [Wed Mar 12 23:16:42 2014] 'Set Printing all' [Wed Mar 12 23:17:21 2014] aha! [Wed Mar 12 23:17:32 2014] That seems to help :) [Thu Mar 13 06:09:44 2014] Hello. [Thu Mar 13 06:10:07 2014] I found such manual http://ulm.uni.udm.ru/~budin/coq-docs-html/node.3.8.0.html with section "Realizing axioms". [Thu Mar 13 06:10:21 2014] It says about command "Link" for axioms realization. [Thu Mar 13 06:10:27 2014] But it seems to be outdated. [Thu Mar 13 06:10:36 2014] Is there similar facility in modern Coq? [Thu Mar 13 07:44:52 2014] Rc43: "Link" -- strange, why it's noted in chapter about extraction, it's just a way to tell "let A will be nat" (as in example). The most resembling thing in modern Coq are functors. So, you create functor (function between modules, uses special syntax), then apply functor, providing given A, and get module where A = nat. [Thu Mar 13 07:45:54 2014] gdsfh, ye, I use functors for such thing, but looked for workaround (currently I work with legacy code and lazy to refactor it). [Thu Mar 13 07:45:58 2014] Rc43: not everybody love functors; sometimes explicitly parameters (look at Section command) or typeclasses could be used, but not always. [Thu Mar 13 07:46:08 2014] gdsfh, so, Link is related only to extraction? [Thu Mar 13 07:46:48 2014] Rc43: I hadn't used such old Coq versions to tell exactly. And I wonder why Link is placed in extraction chapter of old docs. [Thu Mar 13 07:47:32 2014] btw, ah, clear now [Thu Mar 13 07:47:39 2014] but if you do extraction and know that A in extracted code must be nat always, you can use modern extraction mechanism to state it. [Thu Mar 13 07:48:06 2014] No, I currently don't need extraction. Just was wondering if it is extraction-only feature or not. [Thu Mar 13 08:05:06 2014] gdsfh: BTW, implementing everything via modules+functors makes some problems (maybe I do it wrong). Not critical, but requires some garbage like exporting modules-parameters outside, etc. [Thu Mar 13 08:12:19 2014] Rc43: really, sometimes verbose things must be written when working with modules. But it's not a big problem usually. However there are records, typeclasses, you can try them out, maybe some things will look better. [Thu Mar 13 08:12:27 2014] But I really don't remember were such problems caused by wrong usage or not. [Thu Mar 13 08:12:50 2014] gdsfh, ye, typeclasses are fine. [Thu Mar 13 08:13:19 2014] gdsfh, records -- I usually use them not for functions, but for structures only. [Thu Mar 13 08:13:48 2014] BTW, are typeclasses = records + algorithms for inference of implicit arguments? [Thu Mar 13 08:15:55 2014] Rc43: records can hold not only values, but functions, types and proofs too. They are powerful. Typeclasses -- really, records + searching of instances, in rough words. [Thu Mar 13 08:17:07 2014] Seems I again encounter situation, when I need to re-export imported modules. [Thu Mar 13 08:17:09 2014] In two words: A (E) -> B (E) -> C (E). [Thu Mar 13 08:17:30 2014] E -- parameter for A, B, C, which are functors, which use themselves in linear order. [Thu Mar 13 08:17:54 2014] Like "Module B (E : ...). Import A (E). Export A (E).". [Thu Mar 13 08:18:21 2014] Not big problem though. [Thu Mar 13 08:22:40 2014] Also, is there way to declare "Variable X : ..." such way, that after "End Section." it will become implicit argument (not explicit)? [Thu Mar 13 08:26:39 2014] Rc43: about modules: Import A(E) really works? I have complain "Syntax error: '.' expected after". If you have no intersections between A and B, you can use "Include A(E)" in functor B, it: 1. includes all A(E) elements in B, 2. exports them. With intersections, "Module Export AE := A(E). Import AE." may help. [Thu Mar 13 08:28:35 2014] gdsfh, ah, no :) I shortened it. Must be "Module X := A E. Import X.". [Thu Mar 13 08:29:03 2014] so "Module Export X := A(E). Import X." [Thu Mar 13 08:29:45 2014] Yes, this is what I do, but looks not very good. [Thu Mar 13 08:30:26 2014] Maybe problem not in module, because they do what it is expected; problem is in bad separation of code. [Thu Mar 13 08:32:37 2014] I think, it is because, we can't put all things that depend on one set of modules into one scope; we usually separate them. But if we don't want to create whole pile of intermediate modules for proper injection we must to "linearise" them. Hence we often need to to these Import+Export things. [Thu Mar 13 08:33:14 2014] I suspect that type classes appropriate better. [Thu Mar 13 08:38:55 2014] Rc43: I don't know. Putting every small bit of code in separate module/functor is not a good decision. However it's better to be seen "in situ". Many definitions can be left outside of functors usually. As for typeclasses, they have its own weaknesses. [Thu Mar 13 08:40:57 2014] if modules represent a kind of layers, then linearizing them looks very natural. [Thu Mar 13 08:41:27 2014] (layers -- in terms of software engineering.) [Thu Mar 13 08:46:11 2014] gdsfh, yep, agree about layers. [Thu Mar 13 08:46:39 2014] gdsfh, so perhaps problem is in too large stack of layers instead of separating some of them into ortogonal components. [Thu Mar 13 08:47:33 2014] Rc43: really, it looks like a common problem with development. [Thu Mar 13 12:04:57 2014] this proof seems convoluted: http://codepad.org/S5mpUznk . It is from http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html . Just want to check if it is doing so as it cannot use "not-yet-taught" tactic. [Thu Mar 13 12:05:48 2014] or, is such a proof the common occurrence. [Thu Mar 13 14:31:53 2014] Can anyone please help with this exercise: http://codepad.org/jOZDMyKo from http://www.cis.upenn.edu/~bcpierce/sf/MoreCoq.html . My attempt: http://codepad.org/JYhtGuKi goal: http://codepad.org/S0N06Idq [Thu Mar 13 14:48:57 2014] joe9: this is a good example of when you need a stronger induction hypothesis. try only "intros n. induction n." and then intros the rest of the stuff. see if you can make that work. [Thu Mar 13 15:21:22 2014] jrw, thanks. will try that. [Thu Mar 13 15:57:44 2014] jrw, I am stuck here: http://codepad.org/r9jz3Tft goal: http://codepad.org/vnrDqjcR [Thu Mar 13 16:23:07 2014] joe9: still stuck? (btw, separating your proof state into several pastes doesn't help us) [Thu Mar 13 17:08:15 2014] ianjneu: yes, still stuck. [Thu Mar 13 17:13:56 2014] what have you tried and what are you currently thinking? [Thu Mar 13 17:43:23 2014] goals: http://codepad.org/tPgwTWvi proof attempt: http://codepad.org/Bc4JjyWl . How do I do this: apply IHn' in eq with (n':=(S n')). [Thu Mar 13 17:43:41 2014] I think if I can do that, the proof will be complete. [Thu Mar 13 17:48:29 2014] joe9: you will need to use plus_n_S or whatever the hint was to rewrite your hypothesis eq [Thu Mar 13 17:48:52 2014] you'll probably also want to destruct m and use plus_n_S again [Thu Mar 13 17:49:11 2014] then you can use inversion to get something that satisfies the hypothesis of IHn [Thu Mar 13 20:30:31 2014] jrw, ok, thanks. [Thu Mar 13 20:57:13 2014] jrw, proof: http://codepad.org/42YI7jHI error: http://codepad.org/8HzolwM1 goal: http://codepad.org/ys4z2AQu . I cannot figure out how plus_n_Sm fits in here. [Fri Mar 14 01:24:20 2014] joe9: do "rewrite plus_n_Sm in eq." instead of "apply..." [Fri Mar 14 01:25:01 2014] joe9: also, if you combine your pastes into one big one instead of separating everything out, it makes things easier. [Fri Mar 14 04:42:08 2014] Is it possible to define an inductive type and a fixpoint which both depend on each other? [Fri Mar 14 09:07:38 2014] I find forward reasoning more readable than backward reasoning. Anyone uses forward reasoning all the time? [Fri Mar 14 10:52:32 2014] BmoreDan_: that is called induction-recursion, and it is not allowed in Coq. In some simple cases you can fake it though (using a sigma over a type of pseudo terms) [Fri Mar 14 12:15:19 2014] I am having a hard time understanding these proofs/theorems. Can anyone please throw some insight? http://codepad.org/JRD2uqFu [Fri Mar 14 12:15:59 2014] The theorems do not make sense to me. They cannot be true. How did we end up proving them? [Fri Mar 14 12:36:53 2014] joe9: what's wrong with them? assuming False, anything follows. [Fri Mar 14 12:52:45 2014] jrw, regarding the rewrite plus_n_Sm in eq, I get this error: http://codepad.org/MgXgzBv9 [Fri Mar 14 12:53:09 2014] jrw, so, even "false" assumptions can be used? [Fri Mar 14 12:53:21 2014] joe9: "rewrite <- plus_n_Sm in eq." ? [Fri Mar 14 12:54:24 2014] joe9: yes, this is common in logic. see http://en.wikipedia.org/wiki/Principle_of_explosion [Fri Mar 14 12:56:44 2014] jrw, thanks. the rewrite [Fri Mar 14 12:56:48 2014] <- helped. [Fri Mar 14 12:57:55 2014] joe9: re: forward reasoning, many people agree with you. I suggest trying to learn to like backward reasoning first, because that is what coq is good at by default. there are ways to do better forward reasoning after you understand more. [Fri Mar 14 13:00:41 2014] jrw, can you please help with this. http://codepad.org/WVctlOln I am stuck here. [Fri Mar 14 13:01:27 2014] joe9: you'll need to do the rewrite twice: once for each side of the equality in eq. then inversion (twice, possibly) will get you what you want. [Fri Mar 14 13:08:54 2014] jrw, this worked http://codepad.org/9uRTLeNf . btw, how did you know that? or, how did you figure that out? did you struggle with it initially? If so, what helped figure it out. [Fri Mar 14 13:43:32 2014] joe9: practice :) [Fri Mar 14 13:43:50 2014] jrw, how long have you been doing this? [Fri Mar 14 13:44:10 2014] joe9: I worked through SF about 3 years ago. [Fri Mar 14 13:46:43 2014] Mitch Wand taught me the curry-howard isomorphism. I also banged my head on ACL2 for a year prior to that. [Fri Mar 14 14:36:08 2014] ACL2 looks interesting [Fri Mar 14 14:36:23 2014] read through a tutorial on it, but have yet to mess with it [Fri Mar 14 15:06:25 2014] Hodapp: it's really fast, but hard to drive. Like a racecar. [Fri Mar 14 15:12:10 2014] hmmmm. [Fri Mar 14 15:15:42 2014] particularly, you have to think carefully about what your rewriting strategy will be. Imagine every Coq proof was autorewrite with everything-proved; destruct everything; congruence; induction wizzlepop (congruence does weird things, and induction guesses which scheme is probably the best to use). [Fri Mar 14 15:16:59 2014] the trusted extension to ACL2, the ACL2 sedan, has better termination checking using state-of-the-art tech. It also does amazing work to generate counter-examples when it can. [Fri Mar 14 15:17:59 2014] (sedans are easier to drive than racecars) [Fri Mar 14 15:44:58 2014] robbert: Thanks. Is there some fundamental reason it's not allowed in Coq? [Fri Mar 14 15:56:10 2014] BmoreDa__: no one's implemented it. [Fri Mar 14 15:56:39 2014] I think Matthieu Sozeau is implementing it for some later version, however. [Fri Mar 14 15:59:45 2014] ianjneu: Ok, thanks. [Fri Mar 14 16:12:59 2014] inversion seems to be magical to me now. I do not seem to understand all that it does. Is that common when starting out? [Fri Mar 14 16:15:56 2014] it is traditional for not understanding to precede understanding [Fri Mar 14 16:20:29 2014] ijp: haha. inversion seems to be a very powerful tactic. [Fri Mar 14 16:20:41 2014] there seems to be a lot of functionality in it. [Sat Mar 15 11:01:28 2014] hi guys, can anyone help me with this definition: http://lpaste.net/101239 I'm getting Error: The reference tm was not found in the current environment. [Sat Mar 15 11:01:37 2014] in with value : tm -> Prop := ... [Sat Mar 15 11:03:07 2014] youre still defining tm at that point, right [Sat Mar 15 11:03:39 2014] yup [Sat Mar 15 11:03:46 2014] maybe thats why [Sat Mar 15 11:03:51 2014] im a novice at coq though :p [Sat Mar 15 11:03:54 2014] but isn't that point of "and" syntax? I'm trying to define mutually recursive definitions [Sat Mar 15 11:04:36 2014] http://lpaste.net/101241 . . . can anyone give some pointers here? I'm at http://www.cis.upenn.edu/~bcpierce/sf/Logic.html#lab226 [Sat Mar 15 11:05:23 2014] I have E : all X (fun t : X => test t = true) (v' :: l') and Heq : test v' = true, which looks to me like it should be sufficient to show the goal, all X (fun t : X => test t = true) l', but perhaps my definition of 'all' is somehow prohibiting this [Sat Mar 15 11:33:14 2014] but, I suppose I cannot rely on my assumption that the constructors 'empty' and 'rest' are disjoint, which I was mis-remembering from something else [Sat Mar 15 11:34:20 2014] that is - I'm acting like 'all X P (a::l)' can only come from '(P a)' and 'all X P l' being given, and I expect Coq to see this, but then it hardly seems like a certainty [Sat Mar 15 19:27:49 2014] Hodapp: I think if you do "inversion E" you should get what you want. [Sun Mar 16 00:28:54 2014] jrw: alright. I'll try to work through that, thanks. [Sun Mar 16 00:30:22 2014] I need to remember that 'inversion' means more than 'HEY LOOK, A CONTRADICTION!' [Sun Mar 16 00:31:47 2014] as predicted - this readily made it very easy to solve. I'll have to figure out why soon. [Sun Mar 16 02:30:44 2014] Hodapp: if you invert on a hypothesis that is an inductive. it will consider all constructors for that inductive that unify with the form your hypothesis has. for each such constructor, inversion gives you a new subgoal with the hypotheses of that constructor added to your context [Sun Mar 16 02:31:40 2014] in this case, the only constructor of "all" that unifies with "all X P (a::l)" is the second constructor, since the first one would have to unify nil with cons. one of that constructor's hypotheses is "all X P l" which is what you wanted [Sun Mar 16 09:43:32 2014] can I do model checking in coq? [Sun Mar 16 10:30:17 2014] jrw: yup... I remember reading basically that in this chapter, but, it had slipped my mind. [Sun Mar 16 12:35:56 2014] Hello. [Sun Mar 16 12:36:44 2014] How such notation is called? "Definition wrapper := { something | predicate something }" [Sun Mar 16 12:41:30 2014] (There is "something : X")I have such definition and have term of type X [Sun Mar 16 12:41:46 2014] and want to get term of type Wrapper. [Sun Mar 16 12:47:21 2014] Rc43: disable printing of notations (depends on your "ide") and use "Print wrapper.". [Sun Mar 16 13:10:28 2014] gdsfh, that helped. BTW, should work for any "ide". [Sun Mar 16 13:10:44 2014] (Unset Printing Notations. Print Wrapper.) [Sun Mar 16 13:11:33 2014] Rc43: "Error: Use CoqIDE display menu instead". And really, menu provides such function. [Sun Mar 16 13:11:48 2014] gdsfh, wow [Sun Mar 16 13:12:44 2014] Rc43: CoqIDE tries to keep some global modes in sync between gui and engine. [Sun Mar 16 13:14:50 2014] Yep, but semantics is little different (Coq's settings can be different in two different places of one file), in some scenarios it can be undesirable. [Sun Mar 16 13:18:25 2014] source is a thing to be processed by coqc finally, and used for extraction or linking, so printing is just a developer's setting, never needed in final result. [Sun Mar 16 13:18:39 2014] when you have something like: Inductive appears_in {X:Type} (a:X) : list X -> Prop := ... [Sun Mar 16 13:20:07 2014] I guess 'X' and 'a' are parameters of appears_in... what is the fundamental difference here between those and the 'list X'? [Sun Mar 16 13:20:46 2014] just that 'X' and 'a' must be present to parametrize appears_in? [Sun Mar 16 14:52:05 2014] http://lpaste.net/101289 - trying to do this for the first part of http://www.cis.upenn.edu/~bcpierce/sf/Logic.html#lab228 (defining what it means for a list to be a merge of others) [Sun Mar 16 14:53:01 2014] and keep getting errors like, "Last occurrence of list_is_merge must have l2 as 3rd argument in list_is_merge X [] [] []." [Sun Mar 16 14:53:20 2014] I'm trying to figure out what this error means or why the last occurrence must have this, and not getting much [Sun Mar 16 14:53:42 2014] Hodapp: move l1 and l2 from the left of the : to the righte. [Sun Mar 16 14:54:02 2014] ianjneu: in the... type declaration? (not sure what to call it) [Sun Mar 16 14:54:10 2014] Currently list_is_merge is indexed by these values rather than parameterized by them. [Sun Mar 16 14:54:23 2014] ahh, that's kind of what I was asking earlier [Sun Mar 16 14:54:36 2014] I just came back [Sun Mar 16 14:54:38 2014] 'indexed by' vs. 'parametrized by', there's a distinction I'm not really familiar with [Sun Mar 16 14:54:59 2014] yeah, I'm not blaming you for not answering my question immediately, just saying this was already something I didn't get well :P [Sun Mar 16 14:56:20 2014] Well, indicies allow you to fix something that will be shared amongst all variants of the type. Parameters allow free choice at each variant. [Sun Mar 16 14:57:21 2014] does SF explain this? this chapter uses the phrase "indexed by" but I'm not sure they explain it [Sun Mar 16 14:57:52 2014] Say you're looking at a form of "list" that is parameterized by a type rather than indexed by one. It's like a comparison of a homogeneous list and a heterogeneous one. [Sun Mar 16 14:58:54 2014] I didn't read SF from start to finish since I was fairly proficient at the time it came out. [Sun Mar 16 14:59:12 2014] yeah, I'm just aiming to know where to get a good idea what the difference is [Sun Mar 16 14:59:21 2014] since all I know now is that there's a syntactic difference [Sun Mar 16 14:59:45 2014] http://cs.stackexchange.com/questions/20100/what-are-the-difference-between-and-consequences-of-using-type-parameters-and-ty [Sun Mar 16 14:59:59 2014] different induction principles. [Sun Mar 16 15:00:25 2014] thanks [Sun Mar 16 15:02:25 2014] I found myself using two versions of refl_trans closure of a reduction relation, where the starting point is an index versus a parameter. I show the two are logically equivalent, and in some lemmas I need the induction principle from the indexed version and in others I need the one from the parameterized version. [Sun Mar 16 15:02:46 2014] It's a whole to-dop. [Sun Mar 16 15:02:49 2014] to-do* [Sun Mar 16 15:05:43 2014] hmmmmmmm. [Sun Mar 16 15:05:50 2014] * goes to make some Irish Coffee [Sun Mar 16 15:29:36 2014] mind went blank. Is there something that simplifies a goal of a :: l1 = a :: l2? [Sun Mar 16 15:29:56 2014] I know I can simplify a hypothesis of this sort with 'inversion', but I don't know about a goal [Sun Mar 16 15:31:12 2014] meh, guess it doesn't really matter - if I had what I needed I could just rewrite [Sun Mar 16 15:34:23 2014] Hodapp: f_equal [Sun Mar 16 16:22:38 2014] jgross: thanks. [Mon Mar 17 09:56:28 2014] hi here http://coq.inria.fr/distrib/current/refman/Reference-Manual012.html 10.1.1 dependent induction H generalizing G D do not work [Mon Mar 17 09:57:15 2014] but dependent induction H do work alone [Mon Mar 17 09:59:53 2014] everyone is zzzz or what :D [Mon Mar 17 10:00:21 2014] it's St. Patrick's Day. We're all hitting up the whiskey. [Mon Mar 17 10:00:38 2014] lol :P [Mon Mar 17 10:50:10 2014] I'm trying to define this: "Definition var := (id * var_kind)." but it fails with "id sould be nat" beucause I think it's interpreting * as multiplication, how can I fix this? [Mon Mar 17 10:50:15 2014] I'm trying to define a tuple type [Mon Mar 17 12:10:26 2014] Hello. [Mon Mar 17 12:12:21 2014] Am I right that Coq's type checking is decidable? [Mon Mar 17 12:32:18 2014] I have strange error: [Mon Mar 17 12:32:29 2014] I defined term with pattern matching like "Definition t := match x with ... " where (x : sigT some_pred) and (t : sigT other_pred). [Mon Mar 17 12:32:39 2014] But I got error "term .. has type (other_pred ..) while it is expected to have type ?116". [Mon Mar 17 12:32:50 2014] Ok, I rewrote definition with explicit declaration of type of result "Definition t : sigT other_pred := ..." and tried to type-check definition. But it doesn't terminate. [Mon Mar 17 12:38:07 2014] Also, the same term inside larger definition works fine. [Mon Mar 17 13:50:33 2014] Rc43: if you have no typeclasses (or similar features, maybe), and typechecking doesn't terminate, it's a bug (imho). Try the latest release. If bug persists, file it to bugtracker. If you aren't sure it's a bug or not, write to coq-club. [Mon Mar 17 14:29:47 2014] gdsfh, ye, going to do it but still not sure (maybe I am just shooting in my foot). [Mon Mar 17 14:29:57 2014] I used some "Axiom error : forall {M} {X}, X." definitions for mocking some holes; maybe it is a problem. [Mon Mar 17 14:30:27 2014] Now rewriting with monad ^_^ [Mon Mar 17 15:36:14 2014] what's the usual mathematical notation to denote sets of dependent pairs? [Mon Mar 17 15:37:13 2014] {x \in domain : prop-about-x} but in Coq it's {x : domain & prop-about-x} [Mon Mar 17 15:37:52 2014] but in math those aren't really pairs, but just a restricted subset of domain. [Mon Mar 17 15:38:24 2014] so probably {(x,y) : prop-relating-y-with-x} [Mon Mar 17 15:38:27 2014] exactly so I get that e.g. a family would also denote such a space, so for instance (A_i)_{i \in I} [Mon Mar 17 15:38:57 2014] I can pick an i, and then an element of A_i [Mon Mar 17 15:39:30 2014] so in effect such a family defines what could be thought of as a space of dependent pairs [Mon Mar 17 15:39:45 2014] but I don't think it is standard to write (i,a) [Mon Mar 17 15:39:51 2014] ya I can see that as a classic mathematics notation for a Sigma type. [Mon Mar 17 15:40:12 2014] but not for an inhabitant of it. [Mon Mar 17 15:40:16 2014] exactly [Mon Mar 17 15:40:46 2014] I wouldn't fret too much about notation. Classic mathematics is vague and ambiguous. [Mon Mar 17 15:40:49 2014] I was wondering if there was such a thing [Mon Mar 17 15:40:56 2014] true [Mon Mar 17 15:41:02 2014] I just don't like reinventing the wheel [Mon Mar 17 15:41:58 2014] Better to do and ask forgiveness than to ask and be shut down. [Mon Mar 17 15:43:05 2014] :) [Mon Mar 17 15:43:30 2014] Is it possible to make Coq output aliases instead of normal form? E.g. "Inductive Either .... left | right ... . Definition fail := left. Eval compute in ... . (* output: left ... ; desired: fail ... *)". [Mon Mar 17 15:44:31 2014] Rc43: Notation [Mon Mar 17 15:44:55 2014] use notation for fail instead of Definition. [Mon Mar 17 15:45:53 2014] ianjneu, ah, so simple; thanks [Mon Mar 17 15:51:00 2014] > A notation must include at least one symbol [Mon Mar 17 15:51:01 2014] =/ [Mon Mar 17 15:51:23 2014] Let it be "!fail" and "!ok" then. [Mon Mar 17 15:57:43 2014] Strange enough; rewrote error handling properly (with Either monad) but looks that computation doesn't terminate. [Mon Mar 17 16:05:48 2014] Rc43: Notation fail := left. doesn't work? [Mon Mar 17 16:06:07 2014] ianjneu no, its ok. [Mon Mar 17 16:06:14 2014] If you use quotes, anything in single quotes becomes a keyword for the lexer. [Mon Mar 17 16:06:29 2014] ianjneu, problem in my setting, but pretty strange. [Mon Mar 17 16:06:39 2014] ianjneu, cycled computation [Mon Mar 17 16:06:49 2014] 'cycled'? [Mon Mar 17 17:51:09 2014] is there a way to use in the presence of an explit type like 'I_10 numeric literals for Ordinal in ssreflect? [Mon Mar 17 20:32:39 2014] http://www.cis.upenn.edu/~bcpierce/sf/Logic.html#lab228 is taking me a ton of effort and confusion [Mon Mar 17 20:32:51 2014] yet.. I have no one to blame but myself... because I wrote the specification :| [Mon Mar 17 20:58:00 2014] Hodapp: what do your definitions look like? [Mon Mar 17 21:15:43 2014] jrw: http://lpaste.net/101368 [Mon Mar 17 21:17:01 2014] jrw: I've been trying inversion on 'list_is_merge l1 l2 l' and I'm not sure if it gets me anywhere or not. I was trying induction first and that seemed to help, but then I kept bumping into cases that seemed contradictory but not in ways I knew how to show [Mon Mar 17 21:17:30 2014] but I've been looking over my definitions and filter_challenge to see if the reason I'm having trouble with that proof is because the theorem is idiotic and wrong [Mon Mar 17 21:23:51 2014] Hodapp: I think that proof will go through. I don't think you need to destruct on (test a) because you'll know the answer by one of your hypotheses. [Mon Mar 17 21:24:16 2014] Hodapp: all that being said, I actually recommend inducting on your in order merge hypothesis [Mon Mar 17 21:24:22 2014] I found that proof to be easier [Mon Mar 17 21:24:39 2014] I think they're basically isomorphic though [Mon Mar 17 21:25:21 2014] isomorphic proofs! [Mon Mar 17 21:31:22 2014] jrw: fair enough. and I think I was heading into the same thing by a different direction, because it was in a certain branch that the annoying-sorta-contradiction emerged [Mon Mar 17 21:37:13 2014] Hodapp: feel free to post a partial proof if you get stuck [Mon Mar 17 21:38:21 2014] looks like I already did once :P [Mon Mar 17 21:52:39 2014] I guess it's important that I do this exercise, since I managed to forget that induction on a hypothesis is a thing you could do. [Mon Mar 17 21:54:21 2014] * . o O ( leave it up to me to forget that something defined inductively can have induction over it... ) [Mon Mar 17 22:08:14 2014] jrw: thank you much. the proof was a cinch after that. [Mon Mar 17 22:17:51 2014] Hodapp: cool. nice work! [Tue Mar 18 03:58:18 2014] wtf?!?! I can't compile this code http://lpaste.net/101378 it's failing with "Error: substx_rec already exists."... how can this be? any idea? [Tue Mar 18 03:58:40 2014] if I print it it says "Error: substx_rec not a defined object." [Tue Mar 18 03:58:45 2014] wtf???? [Tue Mar 18 04:44:51 2014] i think it's because substx_rec is going to be the name of the generated recursion principle for substx [Tue Mar 18 04:46:24 2014] Saizan: yeah that's right :) I also asked this to mailing list and got same asnwer. [Tue Mar 18 04:46:27 2014] answer* [Tue Mar 18 13:46:05 2014] Is there built-in function for taking n-list from stream? [Tue Mar 18 13:57:16 2014] I don't think streams have much in terms of batteries included. [Tue Mar 18 15:58:21 2014] heho anyone here [Tue Mar 18 17:01:10 2014] hi user1_ [Wed Mar 19 07:24:38 2014] Hello. [Wed Mar 19 07:51:18 2014] I have type synonym "T a := x -> a". [Wed Mar 19 07:51:20 2014] I want to write fixpoint on it (i.e. Fixpoint f : T something). [Wed Mar 19 07:51:53 2014] But I need to specify that arguement of type X is {struct x}. [Wed Mar 19 07:52:01 2014] Is there workaround for that? [Wed Mar 19 08:27:57 2014] If I just unwrap T definition then something wrong with my monads happens (suppose that it becomes harder to find right instance). [Wed Mar 19 08:47:23 2014] Can I make Coq to unify "forall x {struct x}, a" with "T a" where T is "X -> A"? [Wed Mar 19 08:52:09 2014] Rc43: as a general note: for simple monads typeclasses are ok, but for monad transformers you'll probably get lost with them. I've tried. Coq typeclasses are more powerful than haskell's ones, instance searching is more complex. The best thing I could do to use monads in my code is https://bitbucket.org/gds/coq-practical-monads [Wed Mar 19 08:53:02 2014] gdsfh, wow, didn't searched for monads implementation, thanks [Wed Mar 19 08:53:22 2014] btw, there are _many_ implementations. [Wed Mar 19 08:53:47 2014] gdsfh, I currently don't use monad transformers, but just hasrdcoded complex monad instance for (F -> R -> Either Error A) [Wed Mar 19 08:54:17 2014] (where F -> Q and R -> Q and Either Error Q are monads) [Wed Mar 19 08:56:26 2014] Rc43: got it. Your approach is simple (that's good), but proofs must be hard. Using monad transformers, one can be sure that monad laws are obeyed. (but probably you don't need proofs here.) [Wed Mar 19 08:57:43 2014] gdsfh, will not need, its code for generating some testing stuff (here R stands for Random := Stream nat and F stands for Fuel := nat; fuel is used for limiting recursion). [Wed Mar 19 08:58:24 2014] but problem that with hiding F into compplex monad I lost ability to type {struct f} on argument of type F [Wed Mar 19 08:59:08 2014] (BTW, F -> Q isn't actually monad, but F -> Either Error Q looks to be). [Wed Mar 19 08:59:20 2014] (in my case) [Wed Mar 19 09:01:49 2014] suppose you are using module as an argument to monad transformer's functor. By default, module values are transparent. Nothing should prevent you from looking at f's structure, even when you are working with monad that uses F. But I have not much brainpower now, so may be mistaken. [Wed Mar 19 09:06:51 2014] gdsfh, hmm, I didn't understand something. [Wed Mar 19 09:06:56 2014] I have "Definition Dirty A := Fuel -> Rand -> Either Error A." and I want to type function "Fixpoint generate ... : Dirty Result." which is decreasing on Fuel which is inside of Dirty. [Wed Mar 19 09:07:20 2014] I have "Instance dirty_monad : Monad Dirty := ..." also. [Wed Mar 19 09:08:43 2014] If I type "Fixpoint generate ... : forall (f : Fuel), {struct f}, Rand -> Either Error A" Coq doesn't complain about fix, but complains something like "expected ?123, got Something". [Wed Mar 19 09:09:59 2014] I suppose that it is because Coq can't unify LHS with RHS during type classes instances search. [Wed Mar 19 09:11:31 2014] I give up on questions about instance searching. Maybe you'd better post complete example here or to coq-club, so somebody could help? [Wed Mar 19 09:13:01 2014] gdsfh, just posted into coq-club; but complete example is pretty long; will try to reduce it (also it can give some information to me, too). [Wed Mar 19 10:07:31 2014] Is {struct x} just notation or hardcoded into Coq? Can I write something like {x : proof_that_something_is_structural_recrusive}? [Wed Mar 19 10:40:41 2014] Rc43: for what it is worth, {struct foo} is no type or so, it is just syntax that belongs to the Fixpoint command and fix term, where it can only be used on the left hand side of the : [Wed Mar 19 10:42:09 2014] structural arguments should always appear on the LHS of the :, you cannot curry them like you are trying to [Wed Mar 19 10:42:34 2014] robbert, and we can't pass fixpoint name into its body without any arguments? [Wed Mar 19 10:43:47 2014] you can, for example in nested recursive functions [Wed Mar 19 10:44:40 2014] In your 03:41 PM message at Coqclub, the {struct f} already makes no sense, it should refer to an argument of the fixpoint [Wed Mar 19 10:44:52 2014] and please! post self-contained code [Wed Mar 19 10:45:16 2014] there is no way of knowing what is going on with code where many definitions are missing [Wed Mar 19 10:47:52 2014] robbert, its about 100 lines =/ [Wed Mar 19 10:48:34 2014] rrobbert, {struct f} is typo, should be {struct fuel}. [Wed Mar 19 10:48:51 2014] I doubt we need all of it [Wed Mar 19 10:49:12 2014] just keep unfolding and removing definitions util you end up with a self contained example [Wed Mar 19 10:50:02 2014] robbert, I did it, it is about 100 lines, because we need to define functor, monad and applicative instances for either and some other types. [Wed Mar 19 10:50:22 2014] http://pastebin.com/raw.php?i=Skm2hLdN [Wed Mar 19 10:51:24 2014] Ye, I can construct example without monads though, but initial point was in type synonyms and why I can't just type them unfolded. [Wed Mar 19 10:53:10 2014] The kind of syntax in [Wed Mar 19 10:53:13 2014] Program Fixpoint f : forall (f : Fuel) {struct f}, WithFuel nat := [Wed Mar 19 10:53:19 2014] is probably wrong [Wed Mar 19 10:53:41 2014] Like I said, the decreasing argument and the struct declaration should be on the LHS of the : [Wed Mar 19 10:53:43 2014] robbert, yes, it's old version before emails. [Wed Mar 19 10:54:01 2014] Here, the { } is seen as an implicit argument or so, I guess [Wed Mar 19 10:54:03 2014] robbert, just wanted to show you size [Wed Mar 19 10:55:29 2014] How do you think is it possible to do in any way? To use monadic operations on fixpoints, I mean. [Wed Mar 19 10:57:10 2014] Can I provide manual proof of termination? [Wed Mar 19 10:59:14 2014] It could work for sure, but I would recommend you to first play without the whole type class and notation machinery, just so you can see what is actually going on [Wed Mar 19 11:00:23 2014] What you are doing now, is making it highly confusing. Start simple, and when that is working, extend [Wed Mar 19 11:04:55 2014] I can't make run already this "Fixpoint f (fuel : Fuel) {struct fuel} : Either Error nat := let g := (pure 1) >>= (fun x => pure (S x)) >>= (fun _ => f) in g fuel." [Wed Mar 19 11:05:24 2014] But maybe I am missing something obvous. [Wed Mar 19 11:05:29 2014] Will try to reduce some more. [Wed Mar 19 11:05:56 2014] Unfold pure, unfold bind, unfold the let, and study that term [Wed Mar 19 11:06:10 2014] there is enough left to simplify [Wed Mar 19 11:13:17 2014] Am I right that wiithout wrapper Coq will not find instance of type class? [Wed Mar 19 11:13:48 2014] So I need to use (FromX A) instead of (X -> A)? [Thu Mar 20 08:17:58 2014] is it possible to only 'compute' part of a goal or hypothesis? [Thu Mar 20 09:32:10 2014] roosbeef: You can rewrite by refl with a given type [Thu Mar 20 09:32:32 2014] Not sure if that's exactly what you mean [Thu Mar 20 09:33:20 2014] suppose we have H : f3 (f1 x) (f2 y) [Thu Mar 20 09:33:26 2014] how can i compute only (f1 x) [Thu Mar 20 09:33:42 2014] and get H : f3 [result] (f2 y) [Thu Mar 20 21:48:42 2014] Logic.v of SF has done a great job stumping me. I guess it makes for good practice. [Fri Mar 21 04:28:47 2014] Hodapp: What are you having trouble with? [Fri Mar 21 04:30:57 2014] Are you doing the 5 star exercise? :) [Fri Mar 21 07:45:25 2014] Cale: yup :P [Fri Mar 21 07:45:53 2014] but I'm on, "Finally, state and prove one or more interesting theorems relating [disjoint], [no_repeats] and [++] (list append)." [Fri Mar 21 07:46:22 2014] trying to show: no_repeats (l1 ++ l2) <-> disjoint l1 l2. [Fri Mar 21 12:45:53 2014] how do i "lift" a relation from symbols to strings of symbols? [Fri Mar 21 12:49:32 2014] for example. if we have the relation let_le on letters, how do we define str_le to encompass the following: [Fri Mar 21 12:50:27 2014] strings of symbols = list of symbols? [Fri Mar 21 12:50:32 2014] yes, [Fri Mar 21 12:50:39 2014] also, unary relation or binary? [Fri Mar 21 12:50:46 2014] if unary, use Forall [Fri Mar 21 12:50:49 2014] take two strings, x and y, and let the first letter of these be x1 and y1 respectively; if let_le x1 y1 then str_le x y; otherwise, take the second letters x2 and y2; if let_le x2 y2 then str_le x y, and so on and so forth [Fri Mar 21 12:51:13 2014] (binary) [Fri Mar 21 12:51:27 2014] you want a lexicographic ordering on lists? [Fri Mar 21 12:51:31 2014] exactly :) [Fri Mar 21 12:52:23 2014] One minute. [Fri Mar 21 12:52:26 2014] ive defined the ordering on letters inductively [Fri Mar 21 12:53:16 2014] like this: https://privatepaste.com/7c9ac3d1ca [Fri Mar 21 12:54:04 2014] but not sure how to approach defining a lifted order [Fri Mar 21 12:56:35 2014] btw you can get rid of "forall" and move accent to the left of the colon [Fri Mar 21 12:57:10 2014] fl_Le_oa accent : fl_Le (FrenchLetter o accent) [...] [Fri Mar 21 13:01:23 2014] does that in practice amount to exactly the same? [Fri Mar 21 13:01:32 2014] seems to me like this requires less parameters [Fri Mar 21 13:01:58 2014] it's the same, just less typing "forall" [Fri Mar 21 13:03:15 2014] hm [Fri Mar 21 13:06:10 2014] so lexorder or dictionary order? If you're looking at strings, should [a;p;p;l;e] be less than [b;e] ? Or do you also need to have a tail of length less than or equal to the rhs list's tail? [Fri Mar 21 13:06:28 2014] n.b. if dictionary order, it won't be wellfounded [Fri Mar 21 13:06:30 2014] yea apple should be less than be [Fri Mar 21 13:06:51 2014] it wont? [Fri Mar 21 13:06:55 2014] nope. [Fri Mar 21 13:07:12 2014] i guess i need lexorder then ;p [Fri Mar 21 13:07:18 2014] cause it should be well founded [Fri Mar 21 13:07:34 2014] why is that not well founded btw [Fri Mar 21 13:08:32 2014] infinite decending chain of a^{n}b [Fri Mar 21 13:09:03 2014] why would that be infinitely decending [Fri Mar 21 13:10:36 2014] unless n equals infinity? [Fri Mar 21 13:10:37 2014] there is no "smallest" string. Is ab? No, aab is smaller. Is aab? No, aaab is smaller. [Fri Mar 21 13:10:57 2014] ahh [Fri Mar 21 13:11:06 2014] ok that makes sense [Fri Mar 21 13:11:38 2014] i think emptystring is always the smallest, does that help? [Fri Mar 21 13:15:27 2014] nil < (a::l) [Fri Mar 21 13:16:18 2014] ie. yes? :p [Fri Mar 21 13:17:47 2014] ya. Working on wellfoundedness claim. [Fri Mar 21 13:18:38 2014] wow thanks [Fri Mar 21 13:31:11 2014] If you want something like lexicographic order which is a well ordering, you can just compare the length first, and then break ties with lexicographic order. [Fri Mar 21 13:31:35 2014] (which is sometimes referred to as graded lexicographic order, or grlex) [Fri Mar 21 13:31:53 2014] how does that work [Fri Mar 21 13:32:56 2014] nm googled it [Fri Mar 21 13:33:33 2014] (You'll probably find lots of resources about computing Gröbner bases, because that's where it mostly shows up :) [Fri Mar 21 13:34:00 2014] haha yea [Fri Mar 21 13:34:03 2014] was looking at https://en.wikipedia.org/wiki/Monomial_order#Graded_lexicographic_order [Fri Mar 21 13:34:15 2014] which makes mention of that [Fri Mar 21 13:35:18 2014] the rules are just nil < (a::l) | a < a' & |l| <= |l'| => (a::l) < (a'::l') | l < l' => (a::l) < (a::l') [Fri Mar 21 13:35:26 2014] of course < must also be wellfounded. [Fri Mar 21 13:36:21 2014] ok that looks correct [Fri Mar 21 13:39:31 2014] why "& |l| <= |l'|"? [Fri Mar 21 13:41:14 2014] to rule out dictionary ordering. [Fri Mar 21 13:41:28 2014] ah but it should be dictionary ordering right? [Fri Mar 21 13:42:17 2014] i thought nil ensured well foundedness for dictionary ordering? [Fri Mar 21 13:42:45 2014] err, forall x, le nil x [Fri Mar 21 13:43:27 2014] the tails don't matter at all for dictionary ordering.e [Fri Mar 21 13:43:44 2014] if the heads are different, I mean. [Fri Mar 21 13:44:27 2014] what would any of these orderings look like in coq though? [Fri Mar 21 13:44:49 2014] should i be using Inductive to define that? [Fri Mar 21 13:44:55 2014] or Fixpoint? [Fri Mar 21 13:45:19 2014] Inductive is how I'm doing it. Still trying to prove accessibility. [Fri Mar 21 13:54:08 2014] meeting in 5 minutes :/ [Fri Mar 21 13:54:14 2014] back in 40 mins [Fri Mar 21 14:26:11 2014] I did a dinky little thing in coq https://gist.github.com/kini/9683018 [Fri Mar 21 14:26:11 2014] eapply is magic :P [Fri Mar 21 14:26:46 2014] anyone have comments on style? (if there can even be style concerns about something this small) [Fri Mar 21 14:40:49 2014] hi [Fri Mar 21 14:41:35 2014] hey, I had to walk home and now I'm on baby duty. [Fri Mar 21 14:41:56 2014] haha ok [Fri Mar 21 14:42:08 2014] baby duty? [Fri Mar 21 14:43:19 2014] My partner and I split our work days to take care of the little one. She's 3 months. [Fri Mar 21 14:44:07 2014] :) [Fri Mar 21 14:45:24 2014] that is to say, I haven't proven wf [Fri Mar 21 14:46:08 2014] no worries [Fri Mar 21 14:46:36 2014] i would love to give it a shot [Fri Mar 21 14:47:46 2014] could you give me a hint as to what your definition of the ordering looks like? [Fri Mar 21 14:48:26 2014] http://lpaste.net/4554856999736573952 [Fri Mar 21 14:53:07 2014] why do you need ZArith? For length? [Fri Mar 21 14:53:57 2014] ya [Fri Mar 21 14:54:12 2014] omega takes out some silly cases that I cut out of the paste. [Fri Mar 21 14:54:35 2014] omega? [Fri Mar 21 14:55:28 2014] it's a powerful tactic for arithmetic goals. [Fri Mar 21 14:55:52 2014] ah like sledgehammer [Fri Mar 21 14:56:24 2014] pvs? [Fri Mar 21 14:56:46 2014] sorry my connection dropped, i may have missed some messages [Fri Mar 21 14:57:26 2014] sledgehammer is a PVS thing, right? [Fri Mar 21 15:00:42 2014] i think so, yea [Fri Mar 21 15:03:46 2014] ok going to disect your definition for a while [Fri Mar 21 15:03:54 2014] much thanks! [Fri Mar 21 15:22:08 2014] ianjneu, why do you open the module with [Fri Mar 21 15:22:09 2014] Module ListLex (Ord: EqLtLe) : EqLtLe with Definition t := list Ord.t. [Fri Mar 21 15:22:12 2014] and then say [Fri Mar 21 15:22:20 2014] Definition t := list Ord.t. [Fri Mar 21 15:26:27 2014] Because Coq modules are painfully verbose. [Fri Mar 21 15:28:01 2014] are those both defining the same t? [Fri Mar 21 15:28:45 2014] yes. The "with" is to make it transparent to users of the module. [Fri Mar 21 15:29:41 2014] ahh [Fri Mar 21 15:30:10 2014] why would that need to be transparent? [Fri Mar 21 15:30:24 2014] ianjneu: so that imposes a constraint on the t exported by the signature EqLtLe of ListLex Ord? [Fri Mar 21 15:42:28 2014] It makes it clear that the ordered type defined by the module is connected to the type put into it. [Fri Mar 21 15:49:38 2014] hm [Fri Mar 21 15:50:49 2014] im working with signatures [Fri Mar 21 15:52:19 2014] this question might make no sense [Fri Mar 21 15:52:35 2014] but suppose we have Definition fs_Sig : Signature := mkSignature fstring_beq_ok. [Fri Mar 21 15:53:33 2014] how do i then define a function like ListLexLt : fs_Sig -> fs_Sig -> Prop? [Fri Mar 21 15:53:54 2014] my bad i should have included that fact [Fri Mar 21 16:01:56 2014] brb [Fri Mar 21 19:34:56 2014] kini: Here's a slightly different way to formulate the same thing: http://lpaste.net/101576 [Fri Mar 21 19:35:41 2014] Makes it perhaps a little clearer that it's SKK :) [Fri Mar 21 19:35:44 2014] right, treat axioms as premiseless inference rules basically :) [Fri Mar 21 19:36:40 2014] yes, bob atkey pointed that out to me on twitter (about SKI), haha [Fri Mar 21 19:37:35 2014] You can also do away with f_not, and replace contrapositive by ((F ~> G) ~> F) ~> F :) [Fri Mar 21 19:37:53 2014] (also known as call/cc) [Fri Mar 21 19:38:02 2014] (also known as Peirce's law) [Sat Mar 22 09:11:45 2014] hello [Sat Mar 22 09:12:26 2014] is there some builtin functionality to automatically prove that l1 = [] and l2 = [] having ([], []) = (l1, l2)? [Sat Mar 22 09:17:03 2014] induction ? [Sat Mar 22 09:17:07 2014] or destruct ? [Sat Mar 22 09:18:19 2014] ainieco: Require Import List. Goal forall (l1 l2 : list nat), (nil, nil) = (l1, l2) -> nil = l1. intros l1 l2 H. injection H. intros. [Sat Mar 22 09:18:22 2014] hello. (how) can I load/check a .v-file in the default emacs-coq-mode? C-c C-l does not work. [Sat Mar 22 09:19:10 2014] gdsfh aah i forgot «injection H» [Sat Mar 22 09:19:12 2014] ainieco: or "congruence", when the goal is a simple one. [Sat Mar 22 09:19:19 2014] I don't want to use this "coqide". [Sat Mar 22 09:19:52 2014] gdsfh: thanks, injection exactly what i needed [Sat Mar 22 09:32:53 2014] trying to prove split l = (l1, l2) -> combine l1 l2 = l but stuck with - http://lpaste.net/4415477618694946816 . could you please give me some hints on that? [Sat Mar 22 09:34:16 2014] is this possible with the default coq-mode? [Sat Mar 22 10:12:53 2014] HEHOO guys urgent question [Sat Mar 22 10:13:37 2014] whats goin on with the [focus on] of chap11 math proof language ????? [Sat Mar 22 10:14:22 2014] what? [Sat Mar 22 10:15:06 2014] sec 11.3.7 [Sat Mar 22 10:16:11 2014] of what? [Sat Mar 22 10:16:49 2014] http://coq.inria.fr/distrib/current/refman/Reference-Manual013.html [Sat Mar 22 10:24:35 2014] KNOCK KNOC? [Sat Mar 22 10:30:07 2014] Why is there a source code of an ocaml runtime in the source code of coq ? [Sat Mar 22 10:32:41 2014] [focus on] is supposed to be part of the tactics of the math proof language.. [Sat Mar 22 10:33:04 2014] it is even written in the syntax presentation [Sat Mar 22 10:33:16 2014] and given in example.. so why the error? [Sat Mar 22 10:37:16 2014] anyone? [Sat Mar 22 10:44:57 2014] anyone? [Sat Mar 22 10:48:17 2014] ainieco: give full example that depends on stdlib only; i'm not a big fan of SF. [Sat Mar 22 10:48:26 2014] schoppenhauer: are you using proofgeneral? [Sat Mar 22 10:48:46 2014] gdsfh: not sure. i think not. [Sat Mar 22 10:49:40 2014] schoppenhauer: so, maybe you should install it? it has some documentation, afair. [Sat Mar 22 10:50:12 2014] yes. [Sat Mar 22 10:50:18 2014] but ... [Sat Mar 22 10:50:52 2014] hm ... [Sat Mar 22 10:51:10 2014] I am not quite sure I understand what proofgeneral actually is. [Sat Mar 22 10:52:06 2014] it's an emacs mode, good for interactive proving within emacs. [Sat Mar 22 10:52:42 2014] maybe not a "mode" by itself, but it should provide its mode. [Sat Mar 22 10:53:10 2014] thx [Sat Mar 22 10:58:20 2014] gdsfh: http://lpaste.net/6370845343730368512 [Sat Mar 22 11:09:49 2014] ainieco: received, checked, thinking. [Sat Mar 22 11:10:16 2014] gdsfh: thank you [Sat Mar 22 11:37:43 2014] ainieco: http://paste.in.ua/9467/ -- not a beautiful proof, but straightforward (for my style of thinking). It's possible to do better. [Sat Mar 22 11:49:01 2014] gdsfh: Thanks! [Sun Mar 23 13:10:45 2014] What is the right citation to use when discussing "The Coq proof assistant" in a paper? [Sun Mar 23 13:14:51 2014] what does [] mean? [Sun Mar 23 13:16:06 2014] roosbeef: depends on context. In expression context with ListNotations imported, it means nil. If an intros pattern, it means destruct and use default naming rules for the unnamed components (which are all of them) [Sun Mar 23 13:17:37 2014] yea its added in a hypothesis after intros [Sun Mar 23 13:24:10 2014] ianjneu, im working on that ListLex module [Sun Mar 23 13:24:33 2014] could you explain this tactic please? Ltac acc_bad := constructor; intros ? bad; inversion bad. [Sun Mar 23 13:25:12 2014] ? is an intro pattern that says to use the default naming strategy (but don't destruct) [Sun Mar 23 13:25:32 2014] normally intro destructs? [Sun Mar 23 13:25:55 2014] no, but I was just relating back to my explanation of intros []. [Sun Mar 23 13:26:02 2014] ah [Sun Mar 23 13:27:40 2014] so basically, this tactic breaks apart the data type according to its constructors and sees if it can dismiss any of these by contradiction? [Sun Mar 23 13:27:42 2014] So acc_bad is for typical Acc proofs, since your base case is almost always an argument of vacuity, which acc_bad will do. [Sun Mar 23 13:29:29 2014] right [Sun Mar 23 13:34:20 2014] so when looking at this proof state https://privatepaste.com/30fe4d2f00 [Sun Mar 23 13:34:59 2014] subgoal 1 is the base case, right? [Sun Mar 23 13:39:48 2014] ya, l must be [], so if you invert H0, you'll be able to use acc_bad, but you might also have to argue the extra cases of the inversion are vacuous. [Sun Mar 23 13:42:43 2014] im confused [Sun Mar 23 13:42:44 2014] :p [Sun Mar 23 13:43:43 2014] doing inversion H0. acc_bad. results in https://privatepaste.com/4b1215030d [Sun Mar 23 13:44:22 2014] do subst after inversion. [Sun Mar 23 13:46:03 2014] hm [Sun Mar 23 13:46:14 2014] btw im attempting to prove le not lt [Sun Mar 23 14:00:21 2014] you're trying to prove forall l, Acc ListLexLe l? [Sun Mar 23 14:00:40 2014] since that won't work. You can have an infinite chain of equal lists. [Sun Mar 23 14:01:41 2014] However, if you use Le to bound l from above (ListLexLe l l') to prove Acc ListLexLt l, that might work by induction on l'. [Sun Mar 23 14:03:58 2014] Lemma wf_acc : well_founded fl_Le -> forall l' l, ListLexLe l l' -> Acc ListLexLe l. [Sun Mar 23 14:04:29 2014] ya that's a nontheorem. [Sun Mar 23 14:04:37 2014] why? [Sun Mar 23 14:05:24 2014] Because you can have (ListLexLe l l) ad infinitum. You will never bottom out. [Sun Mar 23 14:05:50 2014] hm [Sun Mar 23 14:06:13 2014] ok that makes sense [Sun Mar 23 14:06:19 2014] Exercise, assume well_founded ListLexLe and prove False. [Sun Mar 23 14:08:21 2014] whats the syntax for that? [Sun Mar 23 14:08:42 2014] Lemma ex : well_founded ListLexLe. [Sun Mar 23 14:08:42 2014] ? [Sun Mar 23 14:09:27 2014] Lemma ex : well_founded ListLexLe -> False. [Sun Mar 23 14:09:30 2014] Lemma ex : ~ well_founded ListLexLe. [Sun Mar 23 14:09:32 2014] ya [Sun Mar 23 14:11:20 2014] hm [Sun Mar 23 14:11:49 2014] https://privatepaste.com/5b7f20236e [Sun Mar 23 14:29:38 2014] ianjneu: FWIW, I always cite the manual. [Sun Mar 23 14:30:16 2014] gotta go home [Sun Mar 23 14:30:30 2014] thanks for your help and patience ianjneu :) [Sun Mar 23 22:01:38 2014] * considers the possibility that Coq invents even more and more outlandish theorems the deeper and deeper you get into a proof, just to mess with your head. [Sun Mar 23 22:07:45 2014] why [Sun Mar 23 22:08:01 2014] and did you solve my [focus on] problem [Sun Mar 23 22:13:59 2014] I don't know what problem you refer to. [Mon Mar 24 11:45:09 2014] hi [Mon Mar 24 11:46:17 2014] i'm young with coq, and have problem with definition of tail recursive function for compute length of a list [Mon Mar 24 11:46:35 2014] Fixpoint lengthbis (acc: nat) (l: list nat) :nat := match l with   | nil => acc | cons x xs => lengthbis (acc + 1) xs end. [Mon Mar 24 11:46:55 2014] i have this error: The components of this disjunctive pattern must bind the same variables. for the first match [Mon Mar 24 11:47:04 2014] i don't understand the problem [Mon Mar 24 15:03:11 2014] wwilly_: you have a stray underscore before the first pipe [Mon Mar 24 18:06:06 2014] how to prove that the foundation axiom is independent of the bourbaki axioms ? [Mon Mar 24 23:40:38 2014] what foundation axiom and what bourbaki axioms? [Tue Mar 25 06:43:55 2014] how do i make coq abstract over details? [Tue Mar 25 06:44:16 2014] for example i have this goal: fl_Lt (FrenchLetter a grave) (FrenchLetter a acute) [Tue Mar 25 06:44:29 2014] and i have this assumption H : fl_Lt (FrenchLetter a acute) (FrenchLetter a grave) [Tue Mar 25 06:44:42 2014] 'grave' and 'acute' are irrelevant for this proof [Tue Mar 25 06:45:17 2014] yet coq sees this assumption as unfitting to solve the goal (even though it is) [Tue Mar 25 07:05:09 2014] nevermind wrote a lemma :p [Tue Mar 25 07:05:20 2014] (to rewrite one into the other) [Tue Mar 25 07:07:34 2014] brb [Tue Mar 25 08:29:39 2014] im working on this well foundedness proof that should be quite trivial [Tue Mar 25 08:30:10 2014] but using the wrong tactics i think [Tue Mar 25 08:30:18 2014] anyone care to give a slight push in the right direction? [Tue Mar 25 08:44:05 2014] nm think i got it :) [Tue Mar 25 12:46:47 2014] hello. http://lpaste.net/3760098886731956224 ← "Error: The reference lt_zero_one was not found in the current environment." ← what am I doing wrong? [Tue Mar 25 12:54:36 2014] schoppenhauer: You need to finish that theorem with Qed. [Tue Mar 25 12:55:09 2014] There's something kind of ironic about someone named Schoppenhauer forgetting the "Qed." at the end. [Tue Mar 25 12:55:12 2014] * flees [Tue Mar 25 12:55:30 2014] hm. i tried "qed." [Tue Mar 25 12:55:40 2014] didnt expect it to be capital [Tue Mar 25 12:56:04 2014] kthx! [Tue Mar 25 13:22:18 2014] is it possible to have "anonymous theorems"? [Tue Mar 25 13:23:46 2014] schoppenhauer: Are you looking for the [abstract] tactic, or the [Goal] vernacular command? [Tue Mar 25 13:35:49 2014] jgross_: probably #1, but ... I just want to be able to have a proof term inside a "normal" term (like I would in Agda). [Tue Mar 25 13:38:30 2014] hm. ok, more important question: is there in the stdlib some definition for "guarded" subtraction, that is, subtraction n - m that requires one to provide n <= m? [Tue Mar 25 13:39:47 2014] schoppenhauer: maybe you're looking for cut [Tue Mar 25 13:40:07 2014] for your first question [Tue Mar 25 13:41:05 2014] What would you want guarded subtraction to look like, other than just be an alias for subtraction with a dummy argument? [Tue Mar 25 13:41:55 2014] ianjneu: subtraction on natural numbers n - m is only possible if n <= m [Tue Mar 25 13:42:37 2014] not when pred 0 = 0, which is what it's defined to be. [Tue Mar 25 13:42:57 2014] wut? [Tue Mar 25 13:43:00 2014] ah. [Tue Mar 25 13:43:10 2014] well, that is not what I want. [Tue Mar 25 13:43:34 2014] it is a lot harder to prove properties about this. [Tue Mar 25 13:44:06 2014] nah, you just have to use the right library theorems, or the omega tactic. [Tue Mar 25 15:21:57 2014] there's a special name for types of the form { foo | bar }, right? what is that name again? [Tue Mar 25 15:22:23 2014] kini: do you mean {x : A & P x} ? [Tue Mar 25 15:22:46 2014] they're sigma types, but in that notation they're sometimes called, "subset types" [Tue Mar 25 15:23:18 2014] hmm, what's the difference between & and | there? [Tue Mar 25 15:24:18 2014] I don't know about the { foo | bar } notation, except informally in mathematics, which denotes to what I discussed. [Tue Mar 25 15:25:09 2014] kini: | is used for the sig type family, where the condition P x is required to live in Prop; & for sigT, where P x lives in Type. [Tue Mar 25 15:25:10 2014] well, coq accepts both and prints them out differently... [Tue Mar 25 15:25:17 2014] see Coq.Init.Specif [Tue Mar 25 15:25:24 2014] ystael: ah [Tue Mar 25 15:25:35 2014] Check ({z : nat & z = 0}, {z : nat | z = 0}). [Tue Mar 25 15:25:35 2014] ({z : nat & z = 0}, {z : nat | z = 0}) : Set * Set [Tue Mar 25 15:25:48 2014] ystael: aha, thanks [Tue Mar 25 15:27:30 2014] I still don't really understand the difference between Type, Set, and Prop. I guess I should read Coq'Art... [Tue Mar 25 15:29:32 2014] I'm pretty sure Set should be deprecated, since it really stands for Type_0, but it can't be interpreted with typical ambiguity. [Tue Mar 25 15:30:41 2014] Type has a predicative tower for "large" types, and Prop doesn't allow any destruction of Props except to create Props. It makes sure values never depend on proofs so that they can be dropped during extraction. [Tue Mar 25 15:30:57 2014] They're also impredicative [Tue Mar 25 19:14:41 2014] is there a substantal difference between Lemma and Theorem? [Tue Mar 25 19:14:57 2014] schoppenhauer: no [Tue Mar 25 19:16:10 2014] thx. [Tue Mar 25 19:16:55 2014] schoppenhauer: don't forget about Remark :P [Tue Mar 25 19:21:44 2014] Can anyone with access to a better subscription to Elsevier get me a copy of "A note on linear time simulation of deterministic two-way pushdown automata" by Neil Jones? [Tue Mar 25 19:22:11 2014] Fucking paywalls are a detriment to science. [Tue Mar 25 19:22:28 2014] http://ojs.statsbiblioteket.dk/index.php/daimipb/article/viewFile/6492/5611 ? [Tue Mar 25 19:22:59 2014] ezyang: many thanks. [Tue Mar 25 19:32:35 2014] hello. [Tue Mar 25 19:32:43 2014] hm. [Tue Mar 25 19:32:53 2014] http://lpaste.net/5523438529473937408 can please somebody help me, I am totally stuck. [Tue Mar 25 19:34:26 2014] schoppenhauer: what have you tried? [Tue Mar 25 19:35:51 2014] jrw: actually, this is pretty much the problem I extracted from something bigger. [Tue Mar 25 19:36:03 2014] jrw: I try to do induction on all variables. [Tue Mar 25 19:36:21 2014] and come to a subgoal "False" from "H : lex (true :: nil) nil" [Tue Mar 25 19:36:59 2014] this H can obviously not occur [Tue Mar 25 19:37:08 2014] by inversion. [Tue Mar 25 19:37:12 2014] for example. [Tue Mar 25 19:37:18 2014] right. so if you do inversion what happens? [Tue Mar 25 19:39:15 2014] it works -.- [Tue Mar 25 19:39:20 2014] sorry [Tue Mar 25 19:39:34 2014] its late and I took a lot of pills against my headache :/ [Tue Mar 25 19:39:41 2014] jrw: thank you! [Tue Mar 25 19:40:07 2014] np [Tue Mar 25 20:05:29 2014] hi! Does anyone know of a parser generator that generates Coq parsing code? [Tue Mar 25 20:06:16 2014] The furthest i got was with one called Menhir, but it is undocumented and the code it generates seems to depend on modules it does not generate. [Tue Mar 25 22:56:08 2014] anyone here? [Tue Mar 25 23:22:04 2014] nope. [Wed Mar 26 16:02:18 2014] how do i prove transitivity of a relation without having to go by every single combination of elements? [Wed Mar 26 16:02:22 2014] https://privatepaste.com/3a4d30aa26 [Wed Mar 26 16:02:30 2014] induction? [Wed Mar 26 16:02:46 2014] * ducks [Wed Mar 26 16:03:22 2014] my bad, https://privatepaste.com/b698f7c8a7 [Wed Mar 26 16:03:38 2014] looks the same :) [Wed Mar 26 16:38:07 2014] anyone? [Wed Mar 26 16:40:54 2014] carter: its a trivial inductive type [Wed Mar 26 16:40:59 2014] :) [Wed Mar 26 16:41:09 2014] i'm rusty wrt coq [Wed Mar 26 16:47:53 2014] got it! :)) [Wed Mar 26 16:48:03 2014] now i can go home [Wed Mar 26 16:48:07 2014] <3 [Fri Mar 28 08:07:33 2014] Hodapp: how goes? [Fri Mar 28 08:07:46 2014] mostly nowhere! [Fri Mar 28 08:08:23 2014] not too familiar at dealing with the existentials [Fri Mar 28 08:10:00 2014] invert existential hypotheses to get hold of a witness, and use exists w to give a witness w. [Fri Mar 28 08:10:05 2014] pretty much handles it. [Fri Mar 28 08:15:22 2014] I proved it by induction on l with no lemmas. [Fri Mar 28 08:16:38 2014] If you get stuck http://lpaste.net/3266009989348589568 [Fri Mar 28 08:22:42 2014] hmm, I was just pondering inverting the existential, but hadn't tried it yet [Fri Mar 28 09:45:51 2014] Hodapp: how's it coming? [Fri Mar 28 10:21:13 2014] ianjneu: I'm at work now, thus no progress :P [Fri Mar 28 10:25:28 2014] ah [Fri Mar 28 10:25:32 2014] where's work? [Fri Mar 28 10:36:25 2014] im trying to prove wellfoundedness of an order between strings [Fri Mar 28 10:36:32 2014] this is done by means of induction, right? [Fri Mar 28 10:43:12 2014] still on that, huh? [Fri Mar 28 10:43:50 2014] b [Fri Mar 28 10:44:15 2014] haha yep [Fri Mar 28 10:45:00 2014] i did prove wellfoundedness of the same order between letters (of which the string is composed) [Fri Mar 28 10:46:03 2014] :/ [Fri Mar 28 10:46:31 2014] have you proven lt strict? [Fri Mar 28 10:46:58 2014] what do you mean by strict? [Fri Mar 28 10:48:07 2014] ianjneu: design engineer at a startup, or something like that [Fri Mar 28 10:49:43 2014] roosbeef: irreflexive and transitive. As in the type constructor StrictOrder. I found that irreflexivity at least will probably be needed. [Fri Mar 28 10:49:54 2014] ah [Fri Mar 28 10:49:56 2014] yes i did [Fri Mar 28 10:50:10 2014] wait actually i proved reflexive and transitive [Fri Mar 28 10:50:33 2014] i want to use an order from CoLoR called VLPO [Fri Mar 28 10:50:34 2014] lt should not be reflexive. [Fri Mar 28 10:50:36 2014] le will be. [Fri Mar 28 10:50:41 2014] yea ive used le [Fri Mar 28 10:50:48 2014] it requires a preorder [Fri Mar 28 10:50:49 2014] again le is not wellfounded. [Fri Mar 28 10:51:21 2014] heres an example of the order: http://gallium.inria.fr/~fpottier/ssphs/MyLPO.html [Fri Mar 28 10:51:40 2014] le doesnt have to be proven wellfounded [Fri Mar 28 10:51:43 2014] only lt [Fri Mar 28 10:54:29 2014] so i did get to a working lt_lpo [Fri Mar 28 10:54:37 2014] but it was with letters not strings [Fri Mar 28 16:30:30 2014] Hey guys. I have trouble with cons defined in Coq.Init.Datatypes. "Compute cons." gives "fun (A : Type) (x : A) (x0 : list A) => x :: x0", but "Compute (cons nat)" yields "fun x : list Set => nat :: x", where I was expecting something like "fun (x : nat) (x0 : list nat) => x :: x0". Can someone explain this behaviour? [Fri Mar 28 16:34:22 2014] cbkg11: A is an implicit argument to cons. Does `Compute (@cons nat)` give you what you expect? [Fri Mar 28 16:35:59 2014] Yes, it does indeed. Do you have some reference to the documentation of @ or an identifier I can search for? [Fri Mar 28 16:36:47 2014] cbkg11: @ maximally de-implicitifies an application: http://coq.inria.fr/refman/Reference-Manual004.html#hevea_default136 [Fri Mar 28 16:37:10 2014] You could instead say `Compute (cons (A := nat))` [Fri Mar 28 16:37:34 2014] I see, good to know. Thank you! [Fri Mar 28 16:37:39 2014] np, good luck [Fri Mar 28 16:59:09 2014] I really wish that Coq had syntax which made it apparent in all cases when parameters were implicit [Fri Mar 28 16:59:16 2014] You can't really tell from the types sometimes [Fri Mar 28 18:08:19 2014] Cale put an @ in front of the name of the term you want the full type (with implicit parameters made explicit) [Fri Mar 28 18:09:01 2014] Anarchos: Well, that's fine, but it's not what I want :) [Fri Mar 28 18:09:22 2014] Anarchos: I want a type signature which somehow represents syntactically which of the parameters are implicit. [Fri Mar 28 18:10:38 2014] Similarly, in cbkg11's example, the fun term which was printed was unable to indicate which parameters there were implicit. [Fri Mar 28 18:11:32 2014] It would be nice if fun {A : Type} (x : A) (x0 : list A) => x :: x0 were valid syntax, so that this would be clear [Fri Mar 28 18:12:03 2014] Oh, apparently it even is [Fri Mar 28 18:12:43 2014] But Coq chose not to use that syntax to represent the fact that the parameter was implicit. [Fri Mar 28 18:13:11 2014] In other cases, especially in type signatures, it's harder to express that certain parameters are implicit. [Sat Mar 29 18:20:27 2014] Qeq return Prop. Can it return bool? [Sat Mar 29 18:36:42 2014] nm [Sun Mar 30 08:52:34 2014] Hi guys, can someone explain how I can use Reverse_Induction from Coq.Lists.List to do induction on a reversed list? [Sun Mar 30 09:29:35 2014] w 27 [Sun Mar 30 09:29:41 2014] oops, sorry [Sun Mar 30 09:41:54 2014] looking at http://www.cis.upenn.edu/~bcpierce/sf/ProofObjects.html#lab237 and writing the proof object directly [Sun Mar 30 09:42:08 2014] and I can't exactly figure out why this is not valid: Definition b_times2': forall n, beautiful n -> beautiful (2*n) := forall n, forall H, b_sum n n H H. [Sun Mar 30 09:44:13 2014] because coq doesn't know that (H + H) there is the same as (2 * H) [Sun Mar 30 09:45:25 2014] as far as it is concerned, 2 * x is 2 + (2 + 0) [Sun Mar 30 09:46:19 2014] I was looking at that and for writing it as a 'proof object' I've no idea how to express that as it's only just here the text has shown proofs of this form... [Sun Mar 30 09:46:53 2014] but I made a lemma, beautiful (n+n) -> beautiful(2*n), and attempted to wrap it in that, but to the same error [Sun Mar 30 09:47:47 2014] when giving evidence for the right branch, supply the proof that H is H + 0 [Sun Mar 30 09:48:09 2014] which is simply another b_sum [Sun Mar 30 09:51:22 2014] I'm still getting it complaining that the whole object has type "beautiful (2*n)" which should be Set, Prop, or Type [Sun Mar 30 09:51:57 2014] and I get that whether the right branch of the outer b_sum has proof that H is H+0 or not [Sun Mar 30 09:53:39 2014] Hodapp: oh right, you should also change the second n to reflect the new evidence [Sun Mar 30 09:53:53 2014] or just use _ [Sun Mar 30 09:57:14 2014] I'm to: Definition b_times2': forall n, beautiful n -> beautiful (2*n) := forall n, forall H, b_sum n _ H (b_sum n 0 H b_0). [Sun Mar 30 09:57:40 2014] which still complains that it has type 'beautiful (n + (n + 0))' which should be Set, Prop or Type [Sun Mar 30 09:58:19 2014] trying to grok what that error even means... [Sun Mar 30 09:58:36 2014] or what solution the text was going for here [Sun Mar 30 09:59:19 2014] oh right, it's because you are using forall [Sun Mar 30 10:00:10 2014] not sure how else I'm meant to do it [Sun Mar 30 10:02:48 2014] Hodapp: we generalise propositions with forall, we generalise code with .... [Sun Mar 30 10:03:50 2014] the textbook appears to generalize code with forall. [Sun Mar 30 10:04:09 2014] look up to the definition of b_plus3' [Sun Mar 30 10:04:23 2014] same section as the exercise you are doing [Sun Mar 30 10:05:49 2014] oh... so the expectation was writing a function. [Sun Mar 30 10:07:14 2014] yes. if propositions correspond to types, then implications correspond to function types [Sun Mar 30 10:07:39 2014] so you supply a function as evidence [Sun Mar 30 10:11:26 2014] hmmm... was confused because [Check b_plus3'] and [Check b_plus3''] both gave the same thing so I wasn't aware there was a fundamental difference [Sun Mar 30 19:54:20 2014] "The term "beautiful n" has type "Prop" while it is expected to have type "beautiful n"." [Sun Mar 30 19:54:25 2014] errrrm... well, okay then... [Sun Mar 30 20:26:49 2014] http://www.cis.upenn.edu/~bcpierce/sf/ProofObjects.html#lab241 I could see easily how to do this if it were beautiful n -> gorgeous n, or gorgeous n -> beautiful n, but the <-> is throwing me for a loop. [Sun Mar 30 20:28:50 2014] it looks like I need to use 'iff' somehow to give evidence, and I'm confused as to how [Sun Mar 30 20:28:58 2014] eh? [Sun Mar 30 20:29:11 2014] split and do each case separately [Sun Mar 30 20:29:37 2014] they want a proof object, not tactics [Sun Mar 30 20:29:42 2014] can I use split there? [Sun Mar 30 20:30:34 2014] conj proof_obj1 proof_obj2 [Sun Mar 30 20:32:11 2014] that's one thing I'm trying, but still getting errors I don't really comprehend. [Sun Mar 30 20:32:31 2014] presently trying "fun (n : nat) => conj (beautiful__gorgeous n) (gorgeous__beautiful n)" [Sun Mar 30 20:34:41 2014] if I need (P -> Q) /\ (Q -> P) to give evidence for iff, it looks to me like 'beautiful__gorgeous n' should supply the (P -> Q) but clearly I'm not getting something here [Sun Mar 30 20:36:24 2014] dunno what to tell you without more info. [Sun Mar 30 20:38:10 2014] http://lpaste.net/6742821582084767744 . . . it's just the question I linked to. [Sun Mar 30 20:39:15 2014] ack, forgot two theorems it refers to. http://lpaste.net/102034 [Sun Mar 30 20:41:19 2014] and the error is what? [Sun Mar 30 20:42:06 2014] The term "beautiful__gorgeous n" has type "beautiful n -> gorgeous n" while it is expected to have type "Prop". [Sun Mar 30 20:43:24 2014] I suppose you don't have Set Implicit Arguments. Try conj _ _ object1 object2. [Sun Mar 30 20:44:25 2014] ahh, that did it [Sun Mar 30 20:46:54 2014] if I kept trying to do it with 'iff' would that have led anywhere? [Sun Mar 30 20:47:57 2014] "do it with iff" means what? [Sun Mar 30 20:51:35 2014] they use: Definition iff (P Q : Prop) := (P -> Q) /\ (Q -> P). [Sun Mar 30 20:52:05 2014] so I guess, using that to provide evidence for the <-> [Sun Mar 30 20:52:17 2014] which I guess is what conj is doing anyhow [Sun Mar 30 20:57:20 2014] is there way to name the introduced variables when using "dependent induction"? e.g. as one uses "induction as [...]"? http://pastebin.com/TtB6uUmf [Sun Mar 30 21:07:13 2014] anderslundstedt: nope. It also uses JMeq if you're unaware of any introduced axiom dependencies [Mon Mar 31 10:31:59 2014] hello. does coq have a "literal mode", like agda/haskell, etc.? [Mon Mar 31 12:32:57 2014] schoppenhauer: what is 'literal mode'? [Mon Mar 31 13:20:53 2014] literate mode, actualy [Mon Mar 31 14:06:27 2014] hello [Mon Mar 31 14:07:07 2014] i have a newbie problem: [Mon Mar 31 14:07:10 2014] Error: Impossible to unify [Mon Mar 31 14:07:10 2014] "(derivable f1 x /\ derivable f2 x) /\ [Mon Mar 31 14:07:10 2014] (exists x : R, interp f2 x < 0) /\ (exists x : R, interp f2 x > 0)" with [Mon Mar 31 14:07:10 2014] "interp f2 x <> 0". [Mon Mar 31 14:10:56 2014] i write (and (exists x:R, Rlt (interp ed x) 0) (exists x:R, Rgt (interp ed x) 0)) for meaning that (interp x) must be different of zero [Mon Mar 31 14:11:20 2014] did i do mistake ? [Mon Mar 31 14:12:45 2014] willy_: if you paste your code somewhere I can look at it. [Mon Mar 31 14:20:03 2014] jrw, mp, is personal project [Mon Mar 31 14:21:15 2014] willy_: so first of all your "fonction" type is uninhabited [Mon Mar 31 14:52:12 2014] Yes, literate mode. [Mon Mar 31 15:05:15 2014] what do I have to import to get integer division? ("/") [Mon Mar 31 15:05:27 2014] There is http://coq.inria.fr/distrib/V8.4/stdlib/Coq.Numbers.Natural.Abstract.NDiv.html, but it is not sufficient. [Mon Mar 31 15:52:34 2014] noone? [Mon Mar 31 15:52:55 2014] I don't do integer division in Coq, heh. [Mon Mar 31 15:53:26 2014] Coq doesn't have anything about Euclidean domains? [Mon Mar 31 15:54:03 2014] it *has* packages which use division ... I just cannot import them ... [Mon Mar 31 15:56:39 2014] Require Import NPeano. [Mon Mar 31 15:57:58 2014] I tried it. It works. [Mon Mar 31 16:00:41 2014] seems so, thanks. [Mon Mar 31 16:15:57 2014] Hello. [Mon Mar 31 16:16:20 2014] Can I easily treat Set or Type values as Prop without lots of modification? [Mon Mar 31 16:16:46 2014] Currently I can do it, but I need to replace "P x" with "exists _ : P x" and fix some proofs. [Mon Mar 31 16:16:51 2014] Not very convinient. [Mon Mar 31 16:17:23 2014] Ah, even "exists _ : P x, True". [Mon Mar 31 16:20:31 2014] You can make "P x" into "Propify (P x)": Make an inductive type Inductive Propify : A -> Prop := propify : forall (A : Type), A -> Propify A. [Mon Mar 31 16:21:31 2014] Ye, but tactics don't know about Propify, so I still need to fix proofs. [Mon Mar 31 16:32:50 2014] is there n=n/1 proved anywhere? [Mon Mar 31 16:33:29 2014] Wrapping intro inductive is inconvinient, because in proofs I need to inversion hypothesis with such wrapper, I can't just write "exact (H H1 H2 (H3 H4))", only "remember (H3 H4) as H5; inversion H5 as H5'; ...". [Mon Mar 31 16:43:30 2014] Rc43: you can make a coercion rule. [Mon Mar 31 16:44:16 2014] schoppenhauer: SearchAbout div. You'll find Nat.div_1_r. [Mon Mar 31 16:45:57 2014] ianjneu: thx! [Mon Mar 31 17:09:23 2014] ianjneu, ah, ok; never used coercions, will look at it. [Mon Mar 31 17:32:29 2014] Why proof irrelevance gives restriction with matching on Prop values? [Mon Mar 31 17:33:04 2014] Ah, forget; I already understood :) [Mon Mar 31 17:43:02 2014] because the proof has to be irrelevant? :) [Mon Mar 31 17:43:48 2014] And now unward to proof parametricity [Mon Mar 31 17:49:36 2014] Ptival, no, I meant other: why I am restricted if I don't care about determinancy of my Set result. But answer is that we have "functional" programming, where every function must return the same answer every time on same parameters. [Mon Mar 31 17:54:05 2014] hmmm I'm unsure this makes sense [Mon Mar 31 21:09:20 2014] mind = blown. [Mon Mar 31 21:09:30 2014] 'induction' is just a wrapper around 'apply t_ind'. [Mon Mar 31 21:44:16 2014] Hodapp: did you also know that you can define t_ind yourself? that was mind blowing for me. [Mon Mar 31 21:53:18 2014] NOOOOO SHUTUP [Mon Mar 31 22:11:52 2014] :D [Tue Apr 1 07:45:18 2014] [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Tue Apr 1 08:27:20 2014] hello. I wnat to make a case-distinction between c=a for natural a and c. this should be decidable. but how do I do this case distinction? [Tue Apr 1 11:18:16 2014] schoppenhauer: Arith contains a lt_dec [Tue Apr 1 12:50:52 2014] Ptival: thx. [Tue Apr 1 20:15:02 2014] how to remove a definition, to re-state it? [Tue Apr 1 21:28:25 2014] Hello (cross post from agda), are coq terms total, and is there an open specification/report for coq such as R5RS? [Tue Apr 1 22:41:12 2014] SrPx: The functions are total, assuming you don't admit a proof of wellfoundedness (in the case of, say, a Program Fixpoint). [Tue Apr 1 22:41:42 2014] Terms aren't total. That doesn't make sense. [Tue Apr 1 22:42:08 2014] As for a spec, I doubt there is one. [Tue Apr 1 23:38:48 2014] Hello. [Tue Apr 1 23:39:38 2014] Is there tactic for multiple rewrite? [Tue Apr 1 23:49:05 2014] Rc43: de n rewrite? [Tue Apr 1 23:50:20 2014] or rewrite H,H',<- H'',H''' (etc) [Wed Apr 2 00:04:31 2014] ianjneu, second answer appropriates, thanks [Wed Apr 2 00:04:55 2014] ianjneu, as for the first -- what is syntax? coq website seemd to be down currently =/ [Wed Apr 2 00:08:49 2014] Also, if I have hypothesis "[match something with | first => Some x | second => None end] = [Some y]", how to convert it to "x = y"? [Wed Apr 2 00:08:51 2014] Plain inversion can't do it. [Wed Apr 2 00:09:00 2014] Need I implement my own tactic? [Wed Apr 2 00:09:37 2014] I can destruct on "something", but in my case it is pretty big and can be different. [Wed Apr 2 00:12:21 2014] ianjneu, seems you have meant "do"; I found that in tactics list, didn't know about it. [Wed Apr 2 02:23:22 2014] Rc43: "Ltac eq_some := match goal with H : match ?a with first => _ | second => _ end = Some ?b |- _ => destruct a end." Fresh coq versions might accept "Ltac eq_some := match goal with H : match ?a with _ end = Some ?b |- _ => destruct a end.". [Wed Apr 2 02:26:14 2014] Hey, sinc coq.inria.fr seems to be down (at least from my computer) does anyone know an alternative reference for structures or would be willing to explain them to me briefly? [Wed Apr 2 02:46:06 2014] gdfsh, can I construct something similar for arbitrary inductive? [Wed Apr 2 02:46:23 2014] gdfsh, or I need sort of reflection for that? [Wed Apr 2 03:10:49 2014] Also, would be useful tactic or lemma for record types: [match x with {| field1 := y; field2 := z |} => f y z end] -> [f (field1 x) (field2 x)]. [Wed Apr 2 03:17:48 2014] Though such lemma seems to be easily provable... [Wed Apr 2 05:30:25 2014] Is it ok if my proof cannot be checked at Qed stage in 5 minutes? [Wed Apr 2 05:30:31 2014] It isn't very large. [Wed Apr 2 05:33:28 2014] Can it be because of hypothesis, which I introduced with "assert () by admit."? [Wed Apr 2 05:44:48 2014] Rc43: "inversion" and "omega" generate large proof terms usually. Also think about "abstract" tactic, it may appear useful here. [Wed Apr 2 08:22:13 2014] hello. I have the following definition: http://lpaste.net/7906967588582719488 - it complains that "inv" has type "m < 2 ^ n" while it is expected to have type "m < 2 ^ S n'". But in this case, n = S n'. [Wed Apr 2 08:42:11 2014] schoppenhauer: there is a problem in your code; I've tried to fix it but there is a true logical issue [Wed Apr 2 08:42:26 2014] (same place) [Wed Apr 2 08:43:43 2014] sgnb: what logical issue? [Wed Apr 2 08:44:17 2014] I get "The term "from_msb_helper1 m n' inv0" has type "m - 2 ^ n' * (m / 2 ^ n') < 2 ^ n'" while it is expected to have type "n' < 2 ^ (m - 2 ^ n' * (m / 2 ^ n'))". [Wed Apr 2 08:45:10 2014] schoppenhauer: replacing "inv" by "_" in your original code (+ fixing parentheses) show the issue [Wed Apr 2 08:46:45 2014] sgnb: ah ... exchanging the arguments n' and (m-(pow 2 n')*(m/(pow 2 n'))) in the recursive call results in no error with your code. [Wed Apr 2 08:47:20 2014] ok, I didn't think a lot on that... [Wed Apr 2 08:48:22 2014] schoppenhauer: you might be interested by Program, though... http://coq.inria.fr/distrib/current/refman/Reference-Manual026.html [Wed Apr 2 08:49:17 2014] thx. [Wed Apr 2 08:50:34 2014] sgnb: hm ... what does "end inv" actually do? [Wed Apr 2 08:51:25 2014] schoppenhauer: "end" finishes the "match", which defines a function which is applied to "inv" [Wed Apr 2 08:52:45 2014] (inv has different types "inside" and "outside" the match) [Wed Apr 2 08:53:39 2014] Program would hide this kind of details [Wed Apr 2 08:54:16 2014] ok thx. [Wed Apr 2 10:35:29 2014] how do i use list2multiset from http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetTheory.html [Wed Apr 2 10:36:25 2014] coq says its not found in current environment even though i did import CoLoR.Util.Multiset.MultisetTheory [Wed Apr 2 10:58:30 2014] brb [Wed Apr 2 16:15:09 2014] why cant i use the function list2multiset from this library when i import it: http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetTheory.html [Wed Apr 2 16:19:13 2014] is there something im overlooking? [Wed Apr 2 18:06:52 2014] [Multiset] is a functor; you need to give it a [MultisetCore] argument to turn it into a module, and then import that module. [Wed Apr 2 18:07:38 2014] roosbeef: ^ [Thu Apr 3 00:05:32 2014] ezyang_: do you plan to update coq with mtac to coq 8.4pl3? [Thu Apr 3 02:03:37 2014] shergill: Yeah, I can do that, I just have to do it ^_^ [Thu Apr 3 02:36:03 2014] shergill: Well, I don't know if Beta has tested it with coq 8.4pl3 [Thu Apr 3 03:11:17 2014] do i need to do something special to use the function list2multiset from http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetTheory.html ? [Thu Apr 3 03:11:50 2014] coq keeps telling me it cannot find the function in the current environment even though i did import that lib [Thu Apr 3 06:04:17 2014] roosbeef: reposting a question multiple times a day, without any other posts in between, is not done... Please don't do that. [Thu Apr 3 06:04:28 2014] Anyway, to answer your question, that function is in a module. [Thu Apr 3 06:26:01 2014] my bad.. i am aware of netiquette, thought a few hours in between would be ok. I wont do that again sorry [Thu Apr 3 06:27:26 2014] so do i need to create an instance of the module to call the function? [Thu Apr 3 06:32:49 2014] nevermind ill check this tutorial http://coq.inria.fr/cocorico/ModuleSystemTutorial [Thu Apr 3 06:33:00 2014] thanks :) [Thu Apr 3 08:28:11 2014] in agda, it is possible to just write ? somehwere when you want to provide a correctly-typed term later. (how) can this be done in coq? admit and Admitted only work inside proofs. [Thu Apr 3 08:29:16 2014] schoppenhauer: use "refine" tactic instead of directly written term, mark holes with "_". [Thu Apr 3 08:31:59 2014] gdsfh: but it is a function and not a theorem. [Thu Apr 3 08:33:38 2014] schoppenhauer: no big differences. Definition succ (n : nat) : nat. refine (S n). Defined. [Thu Apr 3 08:35:52 2014] gdsfh: so I just write "Admitted" after "refine (...)"? [Thu Apr 3 08:37:04 2014] "refine (...); admit." would work. [Thu Apr 3 08:38:48 2014] thx. [Thu Apr 3 08:38:51 2014] works. [Thu Apr 3 08:45:07 2014] is there a ssreflect idiom for move=> H; apply H.? [Thu Apr 3 08:46:11 2014] ah, exact if its done then [Thu Apr 3 09:56:36 2014] how do i use modules [Thu Apr 3 09:57:08 2014] i feel like a total idiot for not understanding this because ive been trying tutorials and what not [Thu Apr 3 10:06:49 2014] brb [Thu Apr 3 11:33:54 2014] ezyang_: gotcha. what would the 'test' entail? building it and seeing? or ensuring that updates in pl3 (not sure what they are specifically) interact nicely with mtac manually? [Fri Apr 4 01:07:37 2014] chris2: try with only writing "apply" [Fri Apr 4 01:10:40 2014] it should work as "move=> H; apply: H" just pop and push H on the "stack" and then use apply [Fri Apr 4 10:25:26 2014] what does this mean? [Fri Apr 4 10:25:32 2014] The term "fs" has type "list fletter" while it is expected to have type "list Eq.A". [Fri Apr 4 10:25:43 2014] whats Eq.A? [Fri Apr 4 10:28:19 2014] Maybe try something like Print Eq.A [Fri Apr 4 10:29:25 2014] *** [ Eq.A : Type ] [Fri Apr 4 10:29:54 2014] okay, so that doesn't tell us much :) [Fri Apr 4 10:30:14 2014] Do you know where the Eq module might be defined? [Fri Apr 4 10:30:36 2014] oh, right CoLoR [Fri Apr 4 10:30:38 2014] haha no im looking for it [Fri Apr 4 10:31:15 2014] http://coq.inria.fr/V8.2pl1/contribs/CoLoR.Util.Relation.RelExtras.html [Fri Apr 4 10:31:49 2014] (check the version number there, I got that link from google) [Fri Apr 4 10:32:52 2014] how do i get my type to match Eq.A? [Fri Apr 4 10:32:57 2014] So it looks like Eq.A is a parameter, I'm not sure why it's not being unified with something else here [Fri Apr 4 10:33:41 2014] When it comes to details like this, I really don't know how I should expect Coq to behave [Fri Apr 4 10:34:24 2014] :/ [Fri Apr 4 10:34:45 2014] that not very reassuring coming from you :p [Fri Apr 4 10:35:43 2014] I haven't actually read anything about how Coq works or how to write programs in it. I just get by on intuition and knowing similar languages. [Fri Apr 4 10:36:02 2014] (Well, that's a bit of a lie, I've looked things up in the documentation a bunch) [Fri Apr 4 10:38:56 2014] so do i need to declare my type to be a parameter in Eq somehow? [Fri Apr 4 10:40:23 2014] Eqset* [Fri Apr 4 17:16:13 2014] how can I use list syntax for vectors? [Fri Apr 4 17:16:56 2014] I opened vector_scope but Check [] still says list [Fri Apr 4 17:18:13 2014] hmm. nil is also list. how can I use vector constructors? [Fri Apr 4 18:42:49 2014] Cale, roosbeef: http://coq.inria.fr/pylons/contribs/files/CoLoR/v8.4/CoLoR.Util.Relation.RelExtras.html [Fri Apr 4 18:45:06 2014] roosbeef, Cale: I think it means you need to make a module that implements the Module Type Eq, and use list fletter as the A, and apply the functor to that module, and call the method that gives you. [Fri Apr 4 19:06:24 2014] jgross: Yeah, I just haven't investigated the Coq module system very fully at all. [Sat Apr 5 03:12:12 2014] can anyone help me using vector? I imported it but still can't use, nil and [] is still list constructors, not vector. what should I do? [Sat Apr 5 03:12:18 2014] (I also opened vector_scope) [Sat Apr 5 04:46:42 2014] what's wrong with this last print statement? http://lpaste.net/102289 it fails with Syntax error: 'XML' or 'Firstorder' 'Solver' expected after 'Print' (in [vernac:command]). [Sat Apr 5 05:37:57 2014] osa1: Print expects an identifier, not a proper term. That means, you can Print take, but not take applied to something. [Sat Apr 5 08:26:32 2014] how can i implement a module with <: and give it a name name at the same time? [Sat Apr 5 08:26:59 2014] (im trying to figure out how to work with modules) [Sat Apr 5 08:27:35 2014] for my purposes, i would like to do the following: [Sat Apr 5 08:27:38 2014] Module M (MC : MultisetCore). Export MC. [Sat Apr 5 08:27:47 2014] without masking [Sat Apr 5 08:29:08 2014] because it seems that with masking, coq will complain that [Sat Apr 5 08:29:32 2014] The term "fs" has type "list fletter" while it is expected to have type "list Eq.A". [Sat Apr 5 10:00:30 2014] brb [Sat Apr 5 12:24:54 2014] i have a function f : (a : nat) -> (a < C) -> list bool, and a_lt : a < C, b_lt : b < C. I know a = b. (how) can I prove f a a_lt = f b b_lt? [Sat Apr 5 12:31:52 2014] schoppenhauer: rewrite hypothesis that states "a = b" in 1. hypothesis b_lt, 2. goal "f a .. = f b ..", 3. replace b_lt with a_lt (they are equal since step#1). [Sat Apr 5 12:33:49 2014] gdsfh: I dont quite understand. [Sat Apr 5 12:34:50 2014] schoppenhauer: your knowledge about "a = b" is a hypothesis, an axiom, parameter or like? [Sat Apr 5 12:35:23 2014] gdsfh: a = b is a hypothesis. [Sat Apr 5 12:35:55 2014] schoppenhauer: so wait a bit, I'll construct an example. [Sat Apr 5 12:47:03 2014] schoppenhauer: https://gist.github.com/gdsfh/6f70c5f852f289a00ded , i was wrong, one more thing is needed. Either proof irrelevance axiom, or proof of equality of lt proofs (it's possible, but it's hard; however maybe stdlib has such proof now). [Sat Apr 5 12:56:18 2014] gdsfh: yes, proof irrelevance. [Sat Apr 5 13:00:14 2014] schoppenhauer: so you know what to do here to prove it? [Sat Apr 5 13:01:14 2014] yes. [Sat Apr 5 14:25:58 2014] can anyone help me with this https://sympa.inria.fr/sympa/arc/coq-club/2014-04/msg00015.html ? [Sat Apr 5 15:23:45 2014] http://www.cis.upenn.edu/~bcpierce/sf/MoreInd.html#lab266 . . . hmm... I'm struggling a little to understand what's going on with the induction principles that Coq generates for inductively-defined propositions [Sat Apr 5 15:29:35 2014] it looks like it generates an induction principle that is... indexed over? parametrized by?... all propositions that are of the same form as that proposition [Sat Apr 5 15:29:39 2014] and I'm trying to see why [Sat Apr 5 16:54:29 2014] Hodapp: I'm not sure what you mean. the induction principles there let you prove an arbitrary statement (called P) about all natural numbers. [Sat Apr 5 16:57:32 2014] induction principles where? [Sat Apr 5 17:00:16 2014] are you referring to them in general or something specific on that page? [Sat Apr 5 17:02:07 2014] Hodapp: the ones you linked to [Sat Apr 5 17:02:17 2014] like gorgeous_ind [Sat Apr 5 17:17:44 2014] what library (if any) would be recommended when dealing with (self-defined) ordering relations, maxima/suprema, sums, etc.? [Sun Apr 6 06:40:54 2014] im having difficulties coming to grasp with the workings of modules [Sun Apr 6 06:41:09 2014] anyone bored and feel like helping out a struggling novice? :p [Sun Apr 6 06:43:51 2014] grips* [Sun Apr 6 07:04:58 2014] brb [Sun Apr 6 07:24:54 2014] roosbeef: I think that the only document available is the reference manual [Sun Apr 6 07:25:08 2014] which is quite hard to follow if you are learning modules from scratch [Sun Apr 6 07:25:17 2014] I am interested in learning modules in Coq myself btw :D [Sun Apr 6 07:25:28 2014] I used them a bit, but it was a trial-error thing [Sun Apr 6 07:30:42 2014] haha well [Sun Apr 6 07:31:33 2014] do you understand what type of unit they are? Is it like a template for reuse of code? Or is it an object? I have no idea how to 'use' a module, if the term 'use' even makes sense in that context [Sun Apr 6 07:31:58 2014] it's similar to modules in ML [Sun Apr 6 07:32:11 2014] or to namespaces in Java/C# [Sun Apr 6 07:32:17 2014] (albeit more "powerful") [Sun Apr 6 07:32:30 2014] i havent worked with those [Sun Apr 6 07:33:40 2014] whats the use of namespaces in Java? [Sun Apr 6 07:33:46 2014] do you come from a programming background or math background? [Sun Apr 6 07:33:55 2014] well it's like [Sun Apr 6 07:34:06 2014] both, but more toward programming i guess (AI) [Sun Apr 6 07:34:25 2014] it's a unit of separation, in some sense. It also lets you avoid name clashes [Sun Apr 6 07:34:58 2014] So if you have a variable x in a module A, you can use it as normal inside A, but outside A you have to refer to it as A.x or whatnot [Sun Apr 6 07:35:17 2014] how is that useful in coq? In my attempts to work with modules ive had more issues with not being able to locate the origin of some reference than with name clashes haha :p [Sun Apr 6 07:35:19 2014] But in Coq modules can be abstracted over types [Sun Apr 6 07:35:40 2014] roosbeef: that is *exactly* the issue I had! [Sun Apr 6 07:36:00 2014] I still don't understand the differences between "Require Import"/"Require Export"/"Import"/etc [Sun Apr 6 07:36:14 2014] yea what does Export do within a module [Sun Apr 6 07:37:20 2014] but anyway, in Coq you can parametrize module over some type which helps with code reuse: http://coq.inria.fr/cocorico/ModuleSystemTutorial [Sun Apr 6 07:37:38 2014] In that tutorial the module "Sig" works like an interface [Sun Apr 6 07:37:50 2014] and module Min accepts all the modules that adhere to that interface [Sun Apr 6 07:38:10 2014] roosbeef: apparently Export imports a module and exports it... or something like that [Sun Apr 6 07:38:21 2014] exports it where? [Sun Apr 6 07:38:46 2014] Well if I understand it correctly, it exports it like it exports other things [Sun Apr 6 07:38:57 2014] (it being another module) [Sun Apr 6 07:39:01 2014] how are things exported in general then [Sun Apr 6 07:39:10 2014] it makes sense to me to import external code [Sun Apr 6 07:39:18 2014] Those technicalities, I am not sure about :S Sorry I wish I knew more about it myself [Sun Apr 6 07:39:34 2014] but the tutorial I linked provides a nice outline [Sun Apr 6 07:39:56 2014] roosbeef: yes, but you can only import something if it is available for export [Sun Apr 6 07:39:58 2014] i have looked at that one before :/ [Sun Apr 6 07:40:07 2014] was actually going over it again this morning [Sun Apr 6 07:40:41 2014] ive also read the chapter about modules in Coq'Art [Sun Apr 6 07:41:09 2014] I wanted to read Elie Soubiran thesis on modules, but havent got to do it yet [Sun Apr 6 07:41:34 2014] he/she wrote a thesis on modules in coq? [Sun Apr 6 07:41:44 2014] there is also this: http://adam.chlipala.net/cpdt/html/Large.html [Sun Apr 6 07:42:00 2014] yep http://tel.archives-ouvertes.fr/docs/00/67/92/01/PDF/these.pdf [Sun Apr 6 07:42:09 2014] and it's in English [Sun Apr 6 07:43:56 2014] wow thanks! [Sun Apr 6 07:44:30 2014] there should be at least one or two clarifying parts in there :) [Sun Apr 6 07:44:44 2014] yw :) please share your experience if you get to read it [Sun Apr 6 07:45:42 2014] will do but dont expect major epiphanies :p [Sun Apr 6 09:26:27 2014] notdan: been reading, still confused :p [Sun Apr 6 09:34:57 2014] the reason i would like to understand modules is because a data type i want to use (http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetCore.html) is written using modules [Sun Apr 6 09:35:08 2014] i cant seem to get to the root of the definition of a multiset though [Sun Apr 6 09:35:16 2014] what is a multiset? Where are the operations on multisets? [Sun Apr 6 09:35:33 2014] how can i instantiate a multiset and how can i manipulate it [Sun Apr 6 09:36:13 2014] seems like theres only skeletons of code that could potentially be used to implement that, and references to other such skeletons [Sun Apr 6 09:40:22 2014] although im pretty sure the authors of CoLoR would not include such non-operational code in their library [Sun Apr 6 09:41:46 2014] no idea [Sun Apr 6 09:47:21 2014] brb [Sun Apr 6 10:42:46 2014] is there a difference betwen Defined. and Qed. ? [Sun Apr 6 10:43:33 2014] osa1 number of letters used ? [Sun Apr 6 10:43:46 2014] Defined is more for a definition, qed for the end of a proog [Sun Apr 6 10:43:49 2014] proof. [Sun Apr 6 10:44:09 2014] Qed means : «Quod erat demonstration» = what was to be proved. [Sun Apr 6 10:54:47 2014] Qed might make the definition opaque? iirc [Sun Apr 6 10:57:46 2014] Saizan we should look the manual for it :) [Sun Apr 6 12:45:28 2014] is: fun (a0 : A0) (a1 : A1) (a2 : A2) ... (aN : aN) => ... [Sun Apr 6 12:45:54 2014] just syntactic sugar for: fun (a0 : A0) => fun (a1 : A1) => fun (a2 : A2) => ... => fun (aN : AN) => ... ? [Sun Apr 6 13:16:06 2014] I'm reading CPDT dependently typed programming section, and I don't understand lines 6 and 7 in this code http://lpaste.net/102331 why Unknown takes one argument, and Found takes 3? isn't that supposed to be 0 and 2 arguments? [Sun Apr 6 13:24:16 2014] osa1: first argument is "P : A -> Prop" (declared in Inductive maybe ...) for both constructors. [Sun Apr 6 13:26:07 2014] gdsfh: that makes sense. thanks. [Sun Apr 6 13:26:41 2014] gdsfh: but sometimes that argument is not really passed, it's confusing. [Sun Apr 6 13:27:34 2014] for example, [Sun Apr 6 13:27:36 2014] Inductive sumor (A : Type) (B : Prop) : Type := inleft : A -> A + {B} | inright : B -> A + {B} here when using inright we're passing only two parameters [Sun Apr 6 13:28:36 2014] hmm [Sun Apr 6 13:28:58 2014] For inleft: Argument A is implicit [Sun Apr 6 13:28:58 2014] For inright: Argument B is implicit [Sun Apr 6 13:29:07 2014] Print sumor. [Sun Apr 6 13:29:28 2014] gdsfh: how do I understand what's implicit? [Sun Apr 6 13:29:43 2014] osa1: "Print sumor." [Sun Apr 6 13:30:04 2014] gdsfh: I already pasted output of Print sumor. [Sun Apr 6 13:30:35 2014] as far as I know implicit argumetns are specified using {} but in this definition they're not wrapped with {} [Sun Apr 6 13:30:55 2014] my output is http://paste.in.ua/9500/ [Sun Apr 6 13:31:58 2014] ahh, right. I ignored rest of the output. so does Coq make some arguments implicit automatically or do I need to do something to make some arguments implicit? [Sun Apr 6 13:32:23 2014] you need to do something explicit to make them implicit. [Sun Apr 6 13:34:05 2014] osa1: http://coq.inria.fr/refman/Reference-Manual004.html#hevea_default115 [Sun Apr 6 13:46:16 2014] can anyone help me proving this http://lpaste.net/102332 ? [Sun Apr 6 13:49:11 2014] osa1: exists n'. reflexivity. [Sun Apr 6 13:51:06 2014] gdsfh: thanks, I didn't know exists work on sig. is it possible to implement that case in pattern matching part of the code? [Sun Apr 6 13:54:16 2014] osa1: yes, and it's better to do it (don't construct computation values with tactics): S n' => inleft _ (exist _ n' _) [Sun Apr 6 13:55:07 2014] why not construct computation values with tactics? [Sun Apr 6 13:55:24 2014] I'm just learning but to me it seems like sometimes constructing values in proof mode is easier. [Sun Apr 6 14:05:42 2014] osa1: Definition add (a b : nat) : nat. auto. Show Proof. [Sun Apr 6 14:08:19 2014] osa1: "exist" tactic is "safe", like destruct, case, decide equality. Like any other tactic where there's no place for error, like using one value instead of another. [Sun Apr 6 14:08:32 2014] very interesting program if you ask me :P [Sun Apr 6 14:29:28 2014] while trying to complete some paths using refine tactic and underscores, why equalities are not added as hyphothesis? for example, if I have match n with | 0 => something _ _ ... I don't have n = 0 as hyphothesis, why? [Sun Apr 6 14:41:01 2014] osa1: don't know/remember exactly, but use "convoy pattern" (described in CPDT) if you need them. Also maybe "Program" instead of "Definition" could help, but never tried it in practice (so i can't help here). [Mon Apr 7 04:10:03 2014] whoa!! "Anomaly: unknown meta ?2107. Please report." [Mon Apr 7 15:51:22 2014] * pokes jdoles [Mon Apr 7 15:52:06 2014] * was pleasantly surprised to discover this [Tue Apr 8 05:12:08 2014] i am completely confused about how i can use the data types and operations defined in this lib http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetCore.html [Tue Apr 8 05:13:05 2014] anyone care to nudge me into the right direction? [Tue Apr 8 09:15:13 2014] hello. is it possible to have an inversion on a record, and get an equality for it at the same time? like for induction, you would pass eqn:? [Tue Apr 8 09:15:23 2014] (which does not work on inversions) [Tue Apr 8 09:16:21 2014] ah I can just use induction [Tue Apr 8 09:16:23 2014] thx [Tue Apr 8 09:32:35 2014] Hello. [Tue Apr 8 09:33:08 2014] I am looking at fresh Coquand's pdf http://www.cse.chalmers.se/~coquand/cirm.pdf [Tue Apr 8 09:33:35 2014] And can't understand what is "description operator" on page 13 and how it acts. [Tue Apr 8 09:33:39 2014] Any ideas? [Tue Apr 8 10:10:05 2014] Rc43: you might get insights from http://plato.stanford.edu/entries/type-theory-church/ [Tue Apr 8 10:11:30 2014] ianjneu, ah, thanks [Tue Apr 8 10:11:46 2014] ianjneu, btw, is Church's TT is the most early version of TTs? [Tue Apr 8 10:12:30 2014] russell's probably [Tue Apr 8 10:13:12 2014] Ah, ye, I see in the article about TT of Russel in 1908. [Tue Apr 8 10:16:40 2014] Btw, how did versions of lambda calculus and TTs interact in history? I mean LC and TT are seems to be all-sufficient and it is not clear when they have been met. [Tue Apr 8 10:18:50 2014] pretty early on in the development of the lambda calculus [Tue Apr 8 10:23:54 2014] Russel's type theory is decidable. I don't remember which standard logic it's equivalent to off the top of my head. [Tue Apr 8 10:24:14 2014] STLC also has decidable type inhabitance. [Tue Apr 8 10:25:46 2014] "History of Lambda Calculus and Combinatory Logic" by Cardone and Hindley devotes about 20 pages to a section on types [Tue Apr 8 15:21:13 2014] When I have a goal that contains a "match (nat_compare a b) with ...", and I do an induction on that, why don't I get the 'current' case of that match as a hypothesis in the created goals? [Tue Apr 8 15:22:10 2014] What did you do induction on? On (nat_compare a b)? [Tue Apr 8 15:22:14 2014] yes [Tue Apr 8 15:22:26 2014] Maybe try simpl? [Tue Apr 8 15:23:40 2014] doesn't do anything, but the actual situation isn't really that simple. The match comes from a fixpoint that I've just unfolded [Tue Apr 8 15:24:21 2014] when I do "induction (nat_compare a b)" then I get three cases, but I expect one of the hypotheses to be 'nat_compare a b = Gt' for example [Tue Apr 8 15:24:26 2014] or something along those lines... [Tue Apr 8 15:26:19 2014] Does inversion do any better? [Tue Apr 8 15:28:07 2014] doesn't inversion just work on hypotheses? [Tue Apr 8 15:29:17 2014] Uh, you might be right. I'm trying to recall, there was some tactic which gave you an equational hypothesis when it did case analysis. case_eq? [Tue Apr 8 15:30:01 2014] (Yeah, it looks like inversion only works on identifiers in context, not arbitrary terms) [Tue Apr 8 15:30:30 2014] hm, case_eq looks promising [Tue Apr 8 15:31:19 2014] it does exactly what I wanted to do... now just to finish this proof ;) [Tue Apr 8 15:31:29 2014] nice! [Tue Apr 8 15:32:04 2014] thanks a lot! [Tue Apr 8 15:32:13 2014] if I have a proof for "forall ... exists ...", how do I get a function from it? [Tue Apr 8 15:32:22 2014] (eg program extraction) [Tue Apr 8 15:35:41 2014] schoppenhauer: I don't know anything about program extraction, but within Coq, you can simply treat a term of that type as a function and apply it to an argument of the type quantified over by the forall. [Tue Apr 8 15:45:36 2014] Hello again. [Tue Apr 8 15:45:52 2014] What do curve brackets mean in result of function? [Tue Apr 8 15:46:30 2014] E.g. "Theorem test (x : X) : {y : }". [Tue Apr 8 15:46:44 2014] Is it has something with existential types? [Tue Apr 8 15:56:44 2014] Cale: Qed :), thanks again! [Tue Apr 8 15:57:54 2014] arnovanlumig: cheers! [Tue Apr 8 15:58:28 2014] Rc43: In that case, it's a notation for an existential type. [Tue Apr 8 15:59:10 2014] Cale, thanks; but is there other case? [Tue Apr 8 15:59:25 2014] Cale, (other but in result not arguments) [Tue Apr 8 15:59:27 2014] Rc43: Curly braces are also used for implicit parameters [Tue Apr 8 15:59:45 2014] Cale, ah, ok [Tue Apr 8 16:00:22 2014] {x:A | P x} means sig A P [Tue Apr 8 16:00:34 2014] Cale: the problem is ... I have a "decidable ...", and I cannot match on it [Tue Apr 8 16:01:06 2014] and {x:A & P x} means sigT A P [Tue Apr 8 16:01:29 2014] since decidable is a Prop and not a set (why ever ...) [Tue Apr 8 16:02:12 2014] schoppenhauer: The reason for this is that Props are meant to be erasable at runtime, so you can only eliminate them into other Props [Tue Apr 8 16:02:54 2014] Cale: you mean "not meant", I guess. [Tue Apr 8 16:03:42 2014] Cale: and I know the reason for irrelevance, but the question is whether I have to rewrite the whole thing or can use some magical Coq-Extraction-Mechanism instead. [Tue Apr 8 16:03:57 2014] When we need functional extensionality? [Tue Apr 8 16:05:20 2014] schoppenhauer: I think I meant meant :) [Tue Apr 8 16:05:46 2014] schoppenhauer: When you do program extraction, things whose type is a Prop vanish. [Tue Apr 8 16:06:56 2014] Cale: Can I extract a Set from something that produces a Prop?< [Tue Apr 8 16:07:07 2014] Cale: so I do not have to write stuff twice? [Tue Apr 8 16:07:55 2014] I have proved the decidability of a relation. [Tue Apr 8 16:08:39 2014] The problem is that I now need it at runtime. [Tue Apr 8 16:08:52 2014] To be honest, I avoid Prop so much that my answer here will probably not be idiomatic [Tue Apr 8 16:08:55 2014] But there is sig [Tue Apr 8 16:10:13 2014] sig : forall A : Type, (A -> Prop) -> Type [Tue Apr 8 16:10:37 2014] Cale: this is just a dependent pair type [Tue Apr 8 16:10:44 2014] isn't it? [Tue Apr 8 16:11:13 2014] Well, but it is turning a Prop into a Type in some sense :) [Tue Apr 8 16:12:05 2014] ah, I see. [Tue Apr 8 16:14:36 2014] Cale: I am not quite sure how to use this for something that returns decidability. [Tue Apr 8 16:15:00 2014] Yeah, I'm not sure either. Let me play with it a bit. [Tue Apr 8 16:16:56 2014] Is univalence axiom is the same as proposition extensionality? [Tue Apr 8 16:17:26 2014] no [Tue Apr 8 16:17:42 2014] Well, wait, what do you mean by "proposition extensionality"? [Tue Apr 8 16:19:31 2014] This one: "Axiom prop_ext : forall (P Q : Prop), (P <-> Q) -> P = Q [Tue Apr 8 16:19:35 2014] " [Tue Apr 8 16:19:45 2014] But I already see that it is only in one direction. [Tue Apr 8 16:20:04 2014] It is from here: http://coq.inria.fr/cocorico/CoqAndAxioms [Tue Apr 8 16:21:10 2014] Well, it's similar in shape to that, except that you have to replace <-> with some appropriate notion of equivalence of types. [Tue Apr 8 16:22:08 2014] If Prop was was the HoTT book called Prop, then this might actually be a reasonable analogy, as (homotopy) propositions are equivalent if coinhabited. [Tue Apr 8 16:22:17 2014] was what* [Tue Apr 8 16:22:21 2014] Also, it is not obvious for me how we produce excluded middle from indefinite description and proof irrelevance. [Tue Apr 8 16:23:36 2014] Well, I don't understand indefinite description as well: "Axiom constructive_indefinite_description : forall (A : Type) (P : A->Prop), (exists x, P x) -> { x : A | P x }." [Tue Apr 8 16:23:58 2014] schoppenhauer: hmm. Well, I don't know. What I usually end up doing is just avoiding Prop and constructing things of sort Type in the first place. [Tue Apr 8 16:23:59 2014] Aren't "exists x, P x" and "{ x : A | P x }" the same? [Tue Apr 8 16:24:31 2014] Rc43: Is that in the HoTT library? [Tue Apr 8 16:25:03 2014] I'm pretty sure the HoTT library unifies all the various weird existentials in Coq. [Tue Apr 8 16:25:10 2014] Cale, not sure; I've found that on http://coq.inria.fr/stdlib/Coq.Logic.ClassicalEpsilon.html [Tue Apr 8 16:25:20 2014] Oh, well, then no [Tue Apr 8 16:27:01 2014] https://github.com/HoTT/HoTT/wiki -- the HoTT Coq documentation is here [Tue Apr 8 16:27:19 2014] and there's a special version of Coq which goes with it too [Tue Apr 8 16:27:46 2014] exists x, P x is a Prop, i guess? [Tue Apr 8 16:28:07 2014] Saizan, yep, isn't {.. | ..} a Prop, too? [Tue Apr 8 16:28:30 2014] Oh, it certainly isn't. { x : A | P x } is a Set [Tue Apr 8 16:28:42 2014] Ah, so that makes sense. [Tue Apr 8 16:29:08 2014] I just was confused P : Prop with {...} : Prop. [Tue Apr 8 16:29:18 2014] *-was [Tue Apr 8 16:30:08 2014] What's the point of HoTT library/patch? [Tue Apr 8 16:30:17 2014] It changes practically everything. [Tue Apr 8 16:30:28 2014] It replaces the base libraries [Tue Apr 8 16:30:44 2014] What I can do with it? [Tue Apr 8 16:31:05 2014] (Counting only what I can't do without it.) [Tue Apr 8 16:31:29 2014] You can do homotopy type theory with it :) [Tue Apr 8 16:31:46 2014] Cale: how can I use the proof assistent then? [Tue Apr 8 16:31:49 2014] Ow :) [Tue Apr 8 16:32:06 2014] I suppose one big thing is that it avoids lots of things which are inconsistent with homotopy type theory [Tue Apr 8 16:32:23 2014] Cale, isn't HoTT declared as a tool and not as a goal? [Tue Apr 8 16:33:05 2014] Rc43: Well, I don't know what the distinction between those is right now. It's a research program. [Tue Apr 8 16:33:11 2014] Or is it useful only for new foundation? [Tue Apr 8 16:33:59 2014] If you're interested in taking part in that line of research, then you'll want to use the HoTT-specific versions of things, more likely than not. [Tue Apr 8 16:35:21 2014] There are reasons why HoTT might turn out to be a really good formalism for mathematics in general, but there are also things which at present can make it awkward for things which would otherwise be easy. [Tue Apr 8 16:35:28 2014] Cale, ok, I just thought that it is already have pretty examples of appliance in maths. [Tue Apr 8 16:35:36 2014] Yes, it does. [Tue Apr 8 16:35:57 2014] Where can I look at it? [Tue Apr 8 16:36:14 2014] Well, there's a whole book :) [Tue Apr 8 16:36:23 2014] http://homotopytypetheory.org/book/ [Tue Apr 8 16:36:27 2014] Isn't it about HoTT itself but not about examples? [Tue Apr 8 16:36:39 2014] Yep, I have seen it and even started. [Tue Apr 8 16:36:47 2014] But I still don't understand. [Tue Apr 8 16:36:50 2014] It develops a large fraction of what's been done so far [Tue Apr 8 16:36:51 2014] later chapters are about applications [Tue Apr 8 16:37:02 2014] Ah, ok. [Tue Apr 8 16:37:04 2014] Including applications [Tue Apr 8 16:37:07 2014] This is all very new [Tue Apr 8 16:40:10 2014] http://www.cse.chalmers.se/~coquand/cirm.pdf <- i like slide 65 here [Tue Apr 8 16:41:15 2014] haha [Tue Apr 8 16:41:27 2014] "The proof is incredible" [Tue Apr 8 16:46:14 2014] Doesn't "indefinite_description" break computability? [Tue Apr 8 16:46:50 2014] i'd expect so [Tue Apr 8 16:47:07 2014] if you want to erase Prop's at least [Tue Apr 8 16:47:27 2014] Ok, but how it with prop extensionality implies excluded middle? [Tue Apr 8 16:48:10 2014] Can't imagine how we can use i.d. if e.m. is about props and not sets. [Tue Apr 8 17:01:15 2014] Oh, btw, I recalled that I had a question about SSReflect. [Tue Apr 8 17:01:46 2014] So it has its name because it reflects prop to decidable prop, right? [Tue Apr 8 17:01:54 2014] Doesn't it require excluded middle? [Tue Apr 8 21:07:49 2014] I would like to use a fixpoint (recursive function) inside something similar to "refine". is this possible? [Tue Apr 8 21:08:11 2014] (fun ... => ...) apparently does not allow recursion. [Tue Apr 8 21:08:29 2014] I could of course use the _rec-function from the decreasing argument [Tue Apr 8 21:08:34 2014] but that would not be as nice. [Tue Apr 8 21:34:54 2014] ok, i found it ... there is a "fix" keyword [Wed Apr 9 07:19:46 2014] Module LexicographicOrder (A_ord B_ord : Ord). [Wed Apr 9 07:19:49 2014] whats Ord? [Wed Apr 9 07:35:42 2014] brb [Wed Apr 9 08:36:08 2014] http://www.cis.upenn.edu/~bcpierce/sf/MoreInd.html#lab275 - in nat_ind2, what does that "forall n : nat, P n := ..." syntax even mean? [Wed Apr 9 08:36:30 2014] I was trying to walk myself through that definition, and that's where I am stuck [Wed Apr 9 08:48:48 2014] is there an automatic way of rewriting a proof-irrelevant term such that one gets an adequate relevant term? [Wed Apr 9 09:56:12 2014] whats Sid? [Wed Apr 9 09:57:21 2014] nevermind ^^ [Wed Apr 9 10:24:59 2014] is it possible to do destruct {n | {m | ...}} inside a term? [Wed Apr 9 10:25:49 2014] schoppenhauer: match e with sig n (sig m _) => _ end [Wed Apr 9 10:27:50 2014] where e is a term of type {n | {m | ...}} [Wed Apr 9 10:57:32 2014] thx. [Wed Apr 9 15:53:58 2014] I just read http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic129 , but is it possible to just evaluate "one step", only the outer definition? [Wed Apr 9 16:03:16 2014] schoppenhauer: unfold function_name [Wed Apr 9 16:04:13 2014] ianjneu: thx. [Wed Apr 9 16:06:32 2014] schoppenhauer: if you're looking for something more robust, as in, contract "the first" redex using beta, delta, iota or zeta, then I don't have as good of an answer. [Wed Apr 9 16:07:32 2014] its sufficient for me, thx [Wed Apr 9 16:07:34 2014] . [Wed Apr 9 20:56:08 2014] huh... implementing a parser, and proving that certain optimizations do not change the value of anything [Wed Apr 9 20:56:18 2014] interesting use case that I'd likely not have thought of... [Thu Apr 10 08:37:20 2014] hello. if I want rational numbers, and prove several inequalities, is Coq.Numbers.Rational.BigQ.BigQ the right thing? [Thu Apr 10 08:37:52 2014] or is QArith better? [Thu Apr 10 08:38:20 2014] I will not use the rational numbers in a "relevant" fashion, they only occur in Props. [Thu Apr 10 08:39:09 2014] so efficiency is probably not an issue, ease of proving is. [Thu Apr 10 09:17:03 2014] gah ... QArith does not work with Nats... [Thu Apr 10 09:30:51 2014] is there a function that injects nat -> positive? [Thu Apr 10 09:31:17 2014] well, except when nat = 0, obviously. [Thu Apr 10 09:41:17 2014] is there a library that works with nat rather that BinNums? [Thu Apr 10 11:59:20 2014] is there a function that injects nat -> positive? *push* [Thu Apr 10 13:05:48 2014] schoppenhauer: what's positive? rational number? [Thu Apr 10 13:23:34 2014] ollehar: the denominators of rationals must be of type "BinNums.positive" [Thu Apr 10 13:24:32 2014] and this is a problem, because I want to have the rational 1/(2 ^ n) for n:nat [Thu Apr 10 13:26:17 2014] why are the ratinal numbers not defined using nat? [Thu Apr 10 14:05:32 2014] schoppenhauer: nat can be zero? [Thu Apr 10 14:05:41 2014] so you have to prove it's not, I suppose [Thu Apr 10 14:06:20 2014] but I'm a coq n00b, so don't take my word for anything ;) [Thu Apr 10 14:11:38 2014] ok. [Thu Apr 10 14:45:12 2014] schoppenhauer: do you have a proof that n > 0 everywhere you use 1/(2 ^ n)? [Thu Apr 10 14:53:05 2014] rmk0: why is it necessarry that n>0? 2^n>0, even if n=0 [Thu Apr 10 14:53:46 2014] hah, sorry, yes, completely misread [Thu Apr 10 16:13:53 2014] ok. first, I have problems with the packaging/scoping system. is there a good introduction to it? [Thu Apr 10 16:22:02 2014] What kind of packaging? [Thu Apr 10 16:22:20 2014] There's a module and section system [Thu Apr 10 16:22:30 2014] notations have interpretation scopes [Thu Apr 10 16:34:46 2014] this [Thu Apr 10 16:35:08 2014] I currently have the problem of having to use many additions and multiplications. [Thu Apr 10 16:35:32 2014] so far, I just wrote qualified names. [Thu Apr 10 16:36:05 2014] but somehow, I cannot get "Pos.mul" imported. [Thu Apr 10 16:37:45 2014] Where are you trying to import it from? [Thu Apr 10 16:37:54 2014] You can look in the library module index to see where it's from [Thu Apr 10 16:38:08 2014] but I'm pretty sure it's reexported from somehwere more convenient than PArith [Thu Apr 10 16:40:54 2014] napping: I only find mul [definition, in Coq.Numbers.Cyclic.ZModulo.ZModulo] [Thu Apr 10 16:41:37 2014] http://coq.inria.fr/distrib/current/stdlib/Coq.PArith.BinPos.html [Thu Apr 10 16:41:54 2014] yes, and this does not work. [Thu Apr 10 16:42:16 2014] Which one do you want? [Thu Apr 10 16:42:32 2014] the one in BinPos [Thu Apr 10 16:42:34 2014] Require Coq.PArith.BinPos. [Thu Apr 10 16:42:46 2014] but I cannot use BinPos.mul or BinPos.Pos.Mul [Thu Apr 10 16:42:50 2014] or anything similar [Thu Apr 10 16:42:53 2014] You didn't import short names [Thu Apr 10 16:43:04 2014] I do not want [Thu Apr 10 16:43:27 2014] I want qualified names. [Thu Apr 10 16:43:28 2014] try Check Coq.PArith.BinPos.Pos.mul. [Thu Apr 10 16:43:33 2014] you got a qualified name [Thu Apr 10 16:44:11 2014] ok, this works. [Thu Apr 10 16:44:13 2014] thx. [Thu Apr 10 16:44:32 2014] If you do something like Require Import Coq.PArith.BinPos, you'll have Pos.mul in scope [Thu Apr 10 16:44:55 2014] but I'll also have collisions when using notations like + and * [Thu Apr 10 16:45:15 2014] for that you should look up how to use notation scopes [Thu Apr 10 16:46:25 2014] oh, I guess you don't need to fully qualify that [Thu Apr 10 16:47:06 2014] BinPos.Pos.mul works after your require [Thu Apr 10 16:47:30 2014] Pos is a module defined in the file so you can't require it as a module [Thu Apr 10 16:47:36 2014] dafaq ... I thought I tried this already. [Thu Apr 10 16:47:39 2014] thx. [Thu Apr 10 16:49:09 2014] as I asked ... a good introduction to it would be nice. the documentation is very "shorthand" [Thu Apr 10 16:49:59 2014] I just look at the reference manual for that [Thu Apr 10 16:50:33 2014] and read very carefully [Thu Apr 10 19:12:26 2014] exists k : nat, 0 = 2 * k [Thu Apr 10 19:12:34 2014] how do I solve this ^ [Thu Apr 10 19:12:46 2014] as a goal, I want to pick a k [Thu Apr 10 19:13:23 2014] but "intro k" gives "Error: No product even after head-reduction." [Thu Apr 10 19:30:48 2014] ah, "exists 0" [Fri Apr 11 01:49:19 2014] Hello. [Fri Apr 11 01:50:14 2014] Am I right that in Coq definitional equality for (a b : Set) can hold but propositional -- not? [Fri Apr 11 01:50:42 2014] I mean, we can do reductions on elements of Set, so there is notion of def-l equality for them. [Fri Apr 11 01:51:02 2014] But if I do "Check eq_refl nat nat" then I get error about Set. [Fri Apr 11 01:51:19 2014] So propositional equality can't be applied to elements of Set, right? [Fri Apr 11 02:06:51 2014] Rc43: no. eq_refl only takes one argument [Fri Apr 11 02:07:02 2014] "Check eq_refl nat." should work fine [Fri Apr 11 02:08:52 2014] Oh =/ [Fri Apr 11 02:09:32 2014] jrw, yea, that works; I forgot to check type annotation [Fri Apr 11 02:09:37 2014] jrw, thanks [Fri Apr 11 02:09:54 2014] np. [Fri Apr 11 04:38:20 2014] how can i check where some function was defined? (From what library) [Fri Apr 11 04:38:44 2014] for example id like to know where the notation _ =A= _ is defined [Fri Apr 11 04:38:47 2014] but when i do [Fri Apr 11 04:38:48 2014] Check _ =A= _. [Fri Apr 11 04:39:02 2014] it only says ?37 =A= ?38 : Prop [Fri Apr 11 04:39:13 2014] which is not very informative :p [Fri Apr 11 04:40:14 2014] roosbeef: does "Locate ..." help? [Fri Apr 11 04:41:35 2014] Locate (_ =A= _). Syntax error: [locatable] expected after 'Locate' (in [vernac:command]). [Fri Apr 11 04:43:21 2014] roosbeef: how about: [Fri Apr 11 04:43:26 2014] Locate "=A=". [Fri Apr 11 04:43:52 2014] same [Fri Apr 11 04:44:01 2014] ah wait i forgot to include " [Fri Apr 11 04:44:04 2014] works now, thanks :) [Fri Apr 11 04:44:32 2014] hm [Fri Apr 11 04:44:49 2014] actually that only shows "X =A= Y" := eqA X Y [Fri Apr 11 04:45:34 2014] roosbeef: right, so now you should try "Check eqA" [Fri Apr 11 04:45:38 2014] or googling eqA [Fri Apr 11 04:45:50 2014] but at least now you have something google-able [Fri Apr 11 04:46:50 2014] * headbutt desk [Fri Apr 11 04:47:16 2014] haha thanks :p not fully awake yet i guess [Fri Apr 11 04:47:27 2014] did Locate eqA, that worked [Fri Apr 11 07:15:06 2014] hi [Fri Apr 11 07:15:15 2014] so im working with this lib http://color.inria.fr/doc/CoLoR.Util.Pair.LexOrder.html [Fri Apr 11 07:15:30 2014] where does lp_L or lp_R get its value? [Fri Apr 11 07:15:49 2014] or how [Fri Apr 11 07:28:58 2014] jrw: uhm, eq_refl really takes two arguments: eq_refl : ∀ (A : Type) (x : A), x = x [Fri Apr 11 07:40:56 2014] nm, got it :) [Fri Apr 11 12:12:39 2014] Hello. [Fri Apr 11 12:12:57 2014] Which semantics is used while unification? I guess lazy, but not sure. [Fri Apr 11 12:13:03 2014] Also, is it possible to specify? [Fri Apr 11 12:22:40 2014] I think it's full normalization. [Fri Apr 11 13:52:58 2014] this code is taken from CPDT http://lpaste.net/102573 how is this definition of app valid? Coq gives an error but as far as I can see it's full of errors... (or maybe I'm missing something) [Fri Apr 11 13:53:23 2014] first, recursive call to app is applied to 2 arguments but `app` actually gets 4 arguments. [Fri Apr 11 13:53:31 2014] osa1: set implicit arguments? [Fri Apr 11 13:53:54 2014] jrw: no, it gives same error (maybe it was already set) [Fri Apr 11 13:54:03 2014] jrw: does that definition look correct to you? [Fri Apr 11 13:54:47 2014] osa1: yes. I just typed it in and it worked. you have to say "Set Implicit Arguments." before the first line [Fri Apr 11 13:55:37 2014] ooh wait. how can this work [Fri Apr 11 13:56:06 2014] application of Cons and app takes less number or arguments than their definitions... [Fri Apr 11 13:58:00 2014] osa1: yes. because those arguments are implicit. you should read about implicit arguments. [Fri Apr 11 17:13:14 2014] what does it really _mean_ to make induction over an hypothesis? [Fri Apr 11 17:15:15 2014] What does it mean to destruct over one? [Fri Apr 11 17:19:02 2014] Hodapp: context? [Fri Apr 11 17:51:27 2014] Hodapp: you mean it's the same thing? [Fri Apr 11 18:56:12 2014] i have this seemingly simple problem.. somewhere in my proof, i have a hypothesis H: Int.eq i Int.zero = true. i also have a theorem Int.eq_spec: forall x y : int, if Int.eq x y then x = y else x <> y. how do i get "i = Int.zero" out of this? [Fri Apr 11 19:03:25 2014] assume (x = y). apply H. probably? [Fri Apr 11 19:03:35 2014] äh [Fri Apr 11 19:03:44 2014] assume (Int.zero = true) [Fri Apr 11 19:03:47 2014] wah [Fri Apr 11 19:04:03 2014] assume (i = Int.zero) [Fri Apr 11 19:04:16 2014] then apply Int.eq_spec [Fri Apr 11 19:08:14 2014] i tried that, but even if i'm very explicit -- doing apply (Int.eq_spec i Int.zero) -- Coq tells me it cannot unify (if Int.eq i Int.zero then i = Int.zero else i <> Int.zero) with (i = Int.zero).. [Fri Apr 11 19:08:58 2014] i have some ugly workaround with rewrite rules -- first rewriting the (i = Int.zero) goal into (if Int.eq i Int.zero then i=Int.zero else i<>Int.zero), and then proving it using Int.eq_spec. but i don't understand why Coq is happy to convert (i=Int.zero) into the (if..) but not unify them the other way around. [Fri Apr 11 19:09:16 2014] s/convert/rewrite/ [Fri Apr 11 19:15:10 2014] ok, good question, I am too much of a newb to have an answer. [Fri Apr 11 19:26:05 2014] uucico: pastebin of proof status? [Fri Apr 11 19:26:26 2014] one second, let me reconstruct my situation at that point.. [Fri Apr 11 19:29:09 2014] proof status: http://pastebin.com/jVXHciAH output from "apply (Int.eq_spec i Int.zero)" at that point: http://pastebin.com/Php264NY [Fri Apr 11 19:29:19 2014] pardon the gigantic unwieldy proof :) [Fri Apr 11 19:32:26 2014] You do know that "i = Int.zero" is a proposition? [Fri Apr 11 19:33:17 2014] sure, as is any (eq a b), right? [Fri Apr 11 19:33:38 2014] Have you tried eq_bool? [Fri Apr 11 19:34:06 2014] what is eq_bool? [Fri Apr 11 19:34:51 2014] a function that returns true or false. but a proposition is either True or False (not the same thing as true or false). I think. [Fri Apr 11 19:35:04 2014] Hm. [Fri Apr 11 19:36:02 2014] i'm not sure why it should be necessary (and, pragmatically, the compcert library that i'm using lacks an Int.eq_bool that i can see). [Fri Apr 11 19:36:38 2014] specifically, it doesn't seem necessary because, from what i understand, the type of (if _ then i=Int.zero else i<>Int.zero) should be Prop, same as i=Int.zero and i<>Int.zero. [Fri Apr 11 19:37:02 2014] hm, ok [Fri Apr 11 19:40:05 2014] but in "if x", shouldn't x be a proof, or a function that returns a proof? [Fri Apr 11 19:41:33 2014] eq_dec should be such a function. [Fri Apr 11 19:41:41 2014] not necessarily, i think -- it just needs to be some inductive product with two constructors, where the first one gets treated as true, and the second gets treated as false [Fri Apr 11 19:42:18 2014] my "x" is already of type bool, which should be decidable (has two constructors); it's not a raw proposition [Fri Apr 11 19:42:35 2014] (in particular, my x is "Int.eq i Int.zero", and i have a hypothesis "Int.eq i Int.zero = true") [Fri Apr 11 19:45:17 2014] OK, don't know, I'm a beginner too ^^ [Fri Apr 11 19:45:19 2014] sorry [Fri Apr 11 19:45:26 2014] no worries -- thanks for looking :) [Fri Apr 11 19:45:34 2014] Mostly, I post stuff on stackoverflow [Fri Apr 11 19:45:44 2014] usually get an answer within some hours [Fri Apr 11 19:58:32 2014] oh I think I answered your last two posts [Fri Apr 11 20:01:31 2014] uucico: can you describe your problem? [Fri Apr 11 20:01:59 2014] let me try to produce it in a simpler setting; one second [Fri Apr 11 20:02:03 2014] ok [Fri Apr 11 20:05:50 2014] here's the coqtop transcript that confuses me: http://pastebin.com/siRpYiyN [Fri Apr 11 20:05:59 2014] in particular, why does my replace command work when the unification fails? [Fri Apr 11 20:49:21 2014] uucico: well the unification fails because the two types don't unify [Fri Apr 11 20:50:13 2014] the fact that you have a proof that "Int.eq i Int.zero = true" does not mean that "Int.eq i Int.zero" is convertible with "true" [Fri Apr 11 20:50:20 2014] so [Fri Apr 11 20:50:28 2014] if Int.eq i Int.zero then i = Int.zero else i <> Int.zero [Fri Apr 11 20:50:47 2014] is inert [Fri Apr 11 20:53:16 2014] and not judgementally equal to true [Sat Apr 12 06:22:23 2014] can anyone help me fixing and completing this function http://lpaste.net/102596 ? [Sat Apr 12 08:31:05 2014] osa1_: it's not a full source. [Sat Apr 12 08:31:13 2014] "Error: The reference Vector.t was not found in the current environment." [Sat Apr 12 08:32:44 2014] osa1_: ah, I've read coq-club, somebody will help, forget it. [Sat Apr 12 08:34:30 2014] gdsfh: Require Import Coq.Vectors.Vector. [Sat Apr 12 08:36:22 2014] osa1_: "Error: Cannot find library Coq.Vectors.Vector in loadpath". 8.3pl4 is too old, i think. [Sat Apr 12 08:36:54 2014] gdsfh: I don't know. I have 8.4pl2 [Sat Apr 12 08:37:07 2014] it's in stdlib [Sat Apr 12 08:38:24 2014] there were significant changes in 8.4 stdlib. So sorry, can't help -- not enough free time to install fresh coq. But don't worry, coq-club will help you, almost sure. [Sat Apr 12 13:37:20 2014] where is my misunderstanding here? I have a line like, "destruct b; simpl; repeat (rewrite optimize_0_plus_sound); reflexivity." and I do not even see optimize_0_plus_sound being applied a single time [Sat Apr 12 13:37:49 2014] I've tried with and without 'try' around the 'repeat, or inside it [Sat Apr 12 13:42:13 2014] http://lpaste.net/102617 is what I'm working with. For optimize_0plus_b_sound I have the solution for each individual case and I am trying to rewrite using tacticals [Sat Apr 12 13:44:09 2014] nevermind. It had an extraneous underscore [Sat Apr 12 13:44:17 2014] so 'try' was happily failing and moving along. [Sat Apr 12 18:10:00 2014] Hello. [Sat Apr 12 18:15:40 2014] Hi. [Sat Apr 12 20:34:52 2014] In HoTT book it is said that there is proof-relevant mathematics in the book. [Sat Apr 12 20:35:04 2014] How it is combines with proof-irrelevance of Coq? [Sat Apr 12 20:35:22 2014] Or HoTT modification of Coq declines proof irrelevance? [Sat Apr 12 20:35:42 2014] Proof irrelevance is an axiom and it does not hold for HoTT [Sat Apr 12 20:36:25 2014] Isn't it built in Coq? [Sat Apr 12 20:36:40 2014] For erasure e.g. [Sat Apr 12 20:38:49 2014] Rc43: Erasure/extraction is not part of the program logic. It's pretty ad-hoc. [Sat Apr 12 20:40:09 2014] Proof-relevance is a fancy word for treating data like data, no matter what philosophical meaning people attribute to that data's type. [Sat Apr 12 20:44:36 2014] ianjneu, but why HoTT makes accent on proof-relevance? [Sat Apr 12 20:44:49 2014] If you put equality in Prop, and then have univalence for that equality, your extracted program will segfault (rather than simply blocking on an axiom). Hence in HoTT, equality goes in Type. [Sat Apr 12 20:45:00 2014] (maybe it is explained, I didn't read ch.1 and intro) [Sat Apr 12 20:46:00 2014] jgross, ah, I didn't know that in HoTT version eq is in Type; so it is combined nicely. [Sat Apr 12 20:46:19 2014] BTW, there is no logs for that channel? [Sat Apr 12 20:47:13 2014] "that" meaning ##hott? Because jgross has a public log. [Sun Apr 13 02:44:43 2014] Actually, at night I was meaning "this" (#coq) channel. [Sun Apr 13 02:46:51 2014] Going through the HoTT book I imageined two more questions: [Sun Apr 13 02:46:53 2014] 1. Has Coq-HoTT modified type-checking? How he is adapted to univalence axiom? I just don't see difference if it is just an axiom, because we need to use it manually to rewrite terms and then it is just easier to use isomorphism. [Sun Apr 13 02:47:10 2014] 2. What is judgmental equality? Is it the same as extensional equality? [Sun Apr 13 02:51:45 2014] Rc43: Even when it's an axiom, you still can use it to create equalities of types [Sun Apr 13 02:52:03 2014] Rc43: The big reason why Coq modifications were needed was universe polymorphism [Sun Apr 13 02:55:17 2014] Rc43: Judgmental equality is a sort of equality where you can just make substitutions anywhere like you're used to from classical mathematics, but the system only has very restricted ways to give you judgmental equalities. Because it's not a type, but a judgment, you can't form universal statements about judgmental equality. Basically it ends up amounting to a sort of equality which expresses what can be computed directly [Sun Apr 13 02:55:17 2014] from the definitions. [Sun Apr 13 02:55:41 2014] You might like to have a look at, I think it was Appendix 2 [Sun Apr 13 02:56:04 2014] where there are formal rules laid about, and you can see where judgmental equalities get formed there [Sun Apr 13 03:03:36 2014] Cale, oh, maybe. I just searched "judgment" in part of the book before the place I read and didn't find; so I thought there is no its definitional (would be pretty strange). [Sun Apr 13 03:08:46 2014] Am I right? There are at least 3 equalities: [Sun Apr 13 03:08:47 2014] 1. Eq_A(x : A, x : A) is a propositional equality (i.e. wrapper of definitional equality (i.e. depends on reduction rules)). [Sun Apr 13 03:09:21 2014] 2. Equivalence of propositions (i.e. when we have isomorphism (i.e. function to and reverse)). [Sun Apr 13 03:09:34 2014] 3. Judgmental equality (I haven't understand yet what it is). [Sun Apr 13 03:10:38 2014] Or 2 points of this list are the same? [Sun Apr 13 03:14:43 2014] Also I guess that 2 is also called extensional equality and 1 is called intensional equality. [Sun Apr 13 04:44:43 2014] Rc43: definitional and judgemental are synonym, propositional is distinct [Sun Apr 13 04:45:35 2014] Rc43: univalence is the axiom saying that Equivalence of types and propositional equality are the same thing [Sun Apr 13 04:47:24 2014] (prop. equality between those types) [Sun Apr 13 07:05:21 2014] I'm having trouble indexing vectors. is there a way to convert a nat to Fin.t ? [Sun Apr 13 07:05:33 2014] I have a proof that nat n > 0 [Sun Apr 13 07:22:51 2014] Saizan, thanks [Sun Apr 13 07:23:14 2014] Saizan, what about intensional/extensional equalities? [Sun Apr 13 07:24:01 2014] I suppose, that intensional = propositional and extensional = equivalence. [Sun Apr 13 07:28:35 2014] not really [Sun Apr 13 07:30:00 2014] intensional and extensional are quite mudded, in particular you get some extensional properties for prop.equality once you have the univalence axiom, but still it's not the same as "Extensional Type Theory" which is the one with the equality reflection rule [Sun Apr 13 07:31:04 2014] anyhow equivalence is supposed to be the definition of prop. equality in HoTT, so the two should have the same properties [Sun Apr 13 07:31:04 2014] Saizan, ah, ok. So intensional/extensional is more term for properties than for specific notion and they can be mapped differently to other notions in different TTs. [Sun Apr 13 07:32:06 2014] sometimes you get people saying "extensional equality" to mean a prop. equality with the reflection rule [Sun Apr 13 07:32:49 2014] but a prop. equality with the reflection rule can't be interpreted as paths, so you get people calling it strict equality [Sun Apr 13 07:33:16 2014] (if you have equality reflection then def. and prop. equality collapse into the same thing) [Sun Apr 13 07:33:18 2014] As I remember I heard it about [ pointwise equality of functions -> equality of functions]. [Sun Apr 13 07:33:47 2014] that's a principle more properly called "functional extensionality" [Sun Apr 13 07:33:50 2014] And about some other things. Maybe about (A <=> B) -> (A = B). [Sun Apr 13 07:33:56 2014] and there are various ways to get it for prop. equality [Sun Apr 13 07:33:58 2014] Saizan, exactly [Sun Apr 13 07:35:22 2014] right, the confusion is that for a long time the main system that had functional extensionality was extensional type theory, i.e. with equality reflection [Sun Apr 13 07:35:35 2014] so the two things were strongly associated together [Sun Apr 13 07:36:09 2014] but OTT and now HoTT show there are other ways [Sun Apr 13 07:38:15 2014] so now we have that the equality of extensional type theory (ETT) is less philosofically extensional than the prop.equality of HoTT [Sun Apr 13 07:52:10 2014] Saizan, what is OTT? [Sun Apr 13 07:55:48 2014] Rc43: observational type theory, what Epigram 2 would use if it existed :) [Sun Apr 13 07:56:42 2014] Rc43: there equality for the type A is defined according to the shape of A, so you do get functional extensionality [Sun Apr 13 07:57:23 2014] Rc43: though equality of types is more precise than equivalence there, and you get uniqueness of identity proofs [Sun Apr 13 07:57:43 2014] Rc43: though i think an actual implementation of HoTT will be a lot like a generalization of OTT [Sun Apr 13 08:01:14 2014] can anyone help me? do I have to write a function to convert nats to Fin.t ? [Sun Apr 13 11:54:35 2014] its weird [Sun Apr 13 11:54:44 2014] i have this subgoal: MSet.member a (a :: nil) [Sun Apr 13 11:55:07 2014] (MSet is a multiset module) [Sun Apr 13 11:55:36 2014] what it boils down to is (if eq_letter_dec a a then 1 else 0) > 0 [Sun Apr 13 11:56:07 2014] is there any way to make coq automatically infer eq_letter_dec a a? [Sun Apr 13 18:10:42 2014] Hi, guys. [Sun Apr 13 18:12:13 2014] Could anybody check it for correctness/clearness? [Sun Apr 13 18:12:14 2014] https://docs.google.com/drawings/d/1IhJ2Utmb9OpiBSCcjSpZFFIqfSaqDsqWtzZ9_A8D59Y [Sun Apr 13 18:12:33 2014] Also, I has a question: what should be on place of ?1 and ?2 ? [Sun Apr 13 18:13:28 2014] When we do topology we use index space instead of them (X for indexing path and I for indexing homotopy's "instances"). [Sun Apr 13 18:13:53 2014] But in HoTT it isn't clear what to substitute, because our paths are just morphisms. [Sun Apr 13 18:24:15 2014] Rc43: it's not public [Sun Apr 13 18:25:39 2014] Saizan, fixed [Sun Apr 13 18:31:53 2014] Maybe the name is misleading (it's not about lemma, just it is about place from the book right after the lemma). [Sun Apr 13 18:40:31 2014] Are ?1 and ?2 just one-point sets? [Sun Apr 13 18:52:46 2014] I am confused. [Sun Apr 13 19:07:24 2014] Ow, there is in book different description of how P is fibration =/ There we must lift path, but not homotopy as I did on picture. [Sun Apr 13 19:07:31 2014] Why first description is right? [Sun Apr 13 19:07:57 2014] Isn't fibration defined for 2-paths? [Sun Apr 13 19:15:38 2014] Oh, it seems that there can be different lifting properties: homotopy / path at least. On wiki def of fibration is about homotopy lifting only. [Sun Apr 13 19:18:46 2014] You could probably do it the exact same way using the interval type, or express the homotopies involved a little differently [Sun Apr 13 19:22:00 2014] What are morphisms in HoTT? Isn't it true that our morphisms are paths only i.e. Eq_A(x,y)? [Sun Apr 13 19:22:54 2014] Or we can talk about type also in external" [Sun Apr 13 19:23:09 2014] category where morphisms are functional types? [Sun Apr 13 19:23:43 2014] (This "external" category would be built on top of our groupoid.) [Sun Apr 13 19:24:40 2014] Well, what category do you want to talk about? There are functions between types in HoTT [Mon Apr 14 02:36:42 2014] Cale, I want to talk about that category in which type family P : A -> U is a fibration. [Mon Apr 14 02:39:02 2014] Cale, and there is interesting for me question: is P fibration only according to path lifting property, or according to homotopy lifting property, too? [Mon Apr 14 02:41:20 2014] http://www.andrew.cmu.edu/user/awodey/preprints/TTH.pdf might answer your question :) [Mon Apr 14 02:42:17 2014] The idea, I think, is that those things are represented by fibrations in various models of the theory [Mon Apr 14 02:42:40 2014] and yeah, you should get the homotopy lifting property [Mon Apr 14 02:44:00 2014] There also ought to be a homotopy lifting property which you can prove within HoTT [Mon Apr 14 02:44:25 2014] The main tricky part about proving it will be stating it conveniently. [Mon Apr 14 02:58:33 2014] Cale, thanks for paper [Mon Apr 14 03:21:57 2014] Strange, text search in the paper looks to be broken [Mon Apr 14 03:23:23 2014] E.g. ctrl+f("bration") finds "fibration" on p.9; but ctrl+f("ibration") doesn't. Seems that author accidentally inserted 'i' from other language =/ [Mon Apr 14 03:23:51 2014] Or just broken index. [Mon Apr 14 03:24:01 2014] Maybe it's the 'fi' ligature? [Mon Apr 14 03:24:36 2014] Oh, maybe. [Mon Apr 14 03:25:00 2014] If it's from LaTeX, you need to explicitly include, e.g., "\input{glyphtounicode} \pdfgentounicode=1" to get "fi" to be correctly searchable in all pdf readers. [Mon Apr 14 03:25:03 2014] I am not familiar with such things, I am from Russia; we don't use ligatures. [Mon Apr 14 03:25:39 2014] jgross, ah, that's not my paper :) [Mon Apr 14 03:26:12 2014] Well, the author would need to include that for it to be searchable in all pdf readers. [Mon Apr 14 03:26:13 2014] jgross, ligatures are automatically inserted instead of known pairs or only manually? [Mon Apr 14 03:26:24 2014] Automatically [Mon Apr 14 03:28:02 2014] But I think the fault is in index. Because I try "path-" and get "ath-l". It looks to be shifted since one place. [Mon Apr 14 03:28:38 2014] Also "path-l" fails, but "path-li" works properly (without shift). [Mon Apr 14 03:28:41 2014] Strange. [Mon Apr 14 16:23:16 2014] Hello. [Mon Apr 14 16:23:57 2014] Rc43: hola [Mon Apr 14 20:54:56 2014] hello. /2 [Mon Apr 14 20:55:27 2014] is there any other library for finite types than the one from ssreflectP [Mon Apr 14 20:55:30 2014] ? [Mon Apr 14 20:55:45 2014] because currently I do not use ssreflect [Tue Apr 15 08:47:49 2014] in proof mode, when i have unfolded a function and it results in a subnested fix function [Tue Apr 15 08:48:03 2014] how can i split that into the different possible outcomes of that match ... with? [Tue Apr 15 08:48:30 2014] for example https://privatepaste.com/3ce130fd7f [Tue Apr 15 08:49:06 2014] how can i split that into two cases, one replacing the whole nested fix with 'empty', and the other with '{{h0}} + fstring2multiset t' [Tue Apr 15 10:50:15 2014] what's the current status of coq para-itp? [Tue Apr 15 12:47:02 2014] No "Redo" in coq? [Tue Apr 15 15:28:51 2014] Hello. [Tue Apr 15 15:30:04 2014] o/ [Tue Apr 15 17:02:48 2014] if im trying to prove this goal: well_founded (fun f g : Sig => fstring_le f g /\ ~ (fstring_le f g /\ fstring_le g f)) [Tue Apr 15 17:03:01 2014] how can i split that into multiple goals somehow? [Tue Apr 15 17:03:28 2014] suppose i have proof of fstring_le being well_founded for example [Tue Apr 15 17:04:08 2014] how do i fit that proof to this goal? [Tue Apr 15 17:05:10 2014] that doesn't seem like a theorem, if the relation's name denotes what I think it does. Consider instantiating f and g with the same thing. [Tue Apr 15 17:05:53 2014] thats what the second conjunct covers [Tue Apr 15 17:07:33 2014] the module im working with for some reason wants a less than equal relation and then limit that relation to only the less than part (with this "f x y /\ ~ (f x y /\ f y x)" construction) [Tue Apr 15 17:12:28 2014] (eg. http://color.inria.fr/doc/CoLoR.RPO.VPrecedence.html -> ltF_wf) [Tue Apr 15 17:13:53 2014] ah [Tue Apr 15 17:15:15 2014] (wellfounded R) is often proved with a lemma "forall x y, y <= x -> Acc R y" [Tue Apr 15 17:15:39 2014] induct on x. [Tue Apr 15 17:15:49 2014] The cases come from the induction. [Tue Apr 15 17:16:03 2014] hm [Tue Apr 15 17:19:31 2014] ltF is basically an order on pairs [Tue Apr 15 17:19:48 2014] (a lexicographic order on pairs) [Tue Apr 15 17:20:12 2014] for both the left and the right component of those pairs i have a proof that they are wellfounded [Tue Apr 15 17:20:26 2014] (multisets and natural numbers) [Tue Apr 15 17:21:46 2014] and this lemma tells me that if thats the case, then ltF is also wellfounded: http://color.inria.fr/doc/CoLoR.Util.Pair.LexOrder.html#lp_lexprod_wf [Tue Apr 15 17:22:02 2014] do i really need to unfold into Acc and all that? [Tue Apr 15 17:22:46 2014] wf_lexprod in Wellfounded/Lexicographic_Product.v is a place to look. [Tue Apr 15 17:26:21 2014] i dont understand [Tue Apr 15 17:26:29 2014] what is there to look for? [Tue Apr 15 17:27:34 2014] soryy I'm a bit distracted. [Tue Apr 15 17:27:41 2014] :p [Tue Apr 15 18:39:43 2014] In Intensional TT how can we get "non-trivial" proof of propositional equality? [Tue Apr 15 18:39:44 2014] When we have not-coinciding definitional and propositional equalities? [Tue Apr 15 18:44:41 2014] Rc43: meta-theoretically, they're all refl. [Tue Apr 15 18:44:58 2014] but this is probably a better question for ##hott [Tue Apr 15 18:45:39 2014] ianjneu, there is no channel for type theories or something? [Tue Apr 15 18:45:56 2014] ianjneu, I mean for more general topic [Tue Apr 15 18:46:31 2014] Rc43: hott in particular specializes in questions of equality. [Tue Apr 15 18:47:01 2014] I'm not sure of any general "type theory" channel. Just the upenn types mailing list and ncatlab. [Tue Apr 15 18:47:33 2014] so, we know that all proofs are refl, but sometimes can't prove it inside our theory? [Tue Apr 15 18:47:52 2014] yes. [Tue Apr 15 18:48:05 2014] Due to canonicity of ITT [Tue Apr 15 18:48:57 2014] Shouldn't canonicity be something about that every proof is refl? [Tue Apr 15 18:49:06 2014] Where to read about that property? [Wed Apr 16 08:20:57 2014] my goal is well_founded (fun x y : fs_Sig => LexMSTR.LexProd_Lt (fstring2pair x) (fstring2pair y)) [Wed Apr 16 08:21:20 2014] i have already proven Lemma lexprod_wf : well_founded LexMSTR.LexProd_Lt. [Wed Apr 16 08:22:01 2014] how do i use lexprod_wf to prove the above goal? [Wed Apr 16 08:35:31 2014] back in 30 mins [Wed Apr 16 09:33:38 2014] ok 60 :p [Wed Apr 16 09:43:22 2014] how can i search for all lemmas with well_founded in their definition? [Wed Apr 16 09:45:26 2014] nm found it :)) http://coq.inria.fr/coq/stdlib/Coq.Wellfounded.Inverse_Image.html [Wed Apr 16 15:40:59 2014] so if you write a proof using generic tactics and then extract code, do you get crappy code and are you better off proving in smaller steps? is there a sense of how to optimize the code by choosing tactics carefully? [Wed Apr 16 16:21:34 2014] solrize: you mean if you write a computationally-relevant term using tactics? [Wed Apr 16 16:26:09 2014] solrize: use only {exact, refine, destruct, case[_eq], clear, decide equality, apply, abstract} tactics and everything will be ok, if you'll get Defined at last. (induction too, maybe. e too, maybe.) [Wed Apr 16 16:26:57 2014] ptival, yeah, i wondered if that was reasonable. gdsfh1, thanks [Wed Apr 16 16:28:44 2014] solrize: btw, not very reasonable, imho. It's better to write computational terms with refine and prove other stuff (which is in Prop) with tactics or whatever. [Wed Apr 16 16:29:18 2014] thanks [Wed Apr 16 16:29:21 2014] basically, only use tactics for which you understand exactly what the proof-subterm being built is and whether it is the right thing to do :) [Wed Apr 16 16:29:47 2014] but even then, I agree with gdsfh1 [Wed Apr 16 16:30:23 2014] cool [Wed Apr 16 16:30:45 2014] since there's not really code generators in Coq, you can use tactics to build the term, then copy-paste it and tweak :) [Wed Apr 16 18:31:49 2014] hello. when using refine, one parameter needs to decrease. is there a direct method of giving another measure of induction? [Wed Apr 16 18:32:28 2014] the thing that currently decreases is a rather sophisticated calculation. [Wed Apr 16 18:36:00 2014] schoppenhauer: have you seen measure? [Wed Apr 16 18:36:08 2014] or wellfounded? [Wed Apr 16 18:37:13 2014] not yet, no. [Wed Apr 16 18:39:30 2014] Ptival thx [Wed Apr 16 18:39:47 2014] loox like what i need. [Thu Apr 17 04:13:55 2014] is it possible to 'assume' a lemma? So instead of writing a proof and finishing off with Qed, just finished off with Assumed? And use that lemma as a placeholder in subsequent proofs? And then return to it later to fill in the proof [Thu Apr 17 04:14:18 2014] Admitted. [Thu Apr 17 04:16:52 2014] perfect, thanks :)) [Thu Apr 17 04:49:33 2014] how can i pull a hypothesis back to the goal? [Thu Apr 17 04:49:57 2014] for example H: P with goal Q, how can i turn that into the goal P -> Q [Thu Apr 17 04:51:45 2014] generalize [Thu Apr 17 04:52:07 2014] ha thanks :) [Thu Apr 17 05:25:18 2014] hm [Thu Apr 17 05:26:53 2014] Lemma fstring_le_trans: forall s1 s2 s3, fstring_le s1 s2 -> fstring_le s2 s3 -> fstring_le s1 s3. [Thu Apr 17 05:27:10 2014] fstring_le is simply defined as https://privatepaste.com/9675452629 [Thu Apr 17 05:27:34 2014] i have proven Lemma LexProd_LT_trans : transitive LexMSTR.LexProd_Lt. [Thu Apr 17 05:27:50 2014] how do i use LexProd_LT_trans to prove fstring_le_trans? [Thu Apr 17 05:30:04 2014] my problem is that i need fstring_le when either of s1 s2 s3 are equal (apply fstring_eq), and LexProd_LT otherwise. When destructing things, it tends to bring this out of sync.. [Thu Apr 17 05:35:18 2014] nevermind think i got it [Thu Apr 17 05:35:35 2014] when doing inversion on the assumptions rather than destructing things, that works better [Thu Apr 17 05:38:06 2014] nope ;p actually it brings up the same issue [Thu Apr 17 06:37:09 2014] back in a bit [Thu Apr 17 07:50:52 2014] how is this possible? [Thu Apr 17 07:50:58 2014] Error: Impossible to unify "strict_order (MultisetGt ?2982)" with "strict_order (MultisetGT (transp l_Lt))". [Thu Apr 17 14:23:33 2014] roosterbot: [Thu Apr 17 14:23:35 2014] oops [Thu Apr 17 14:23:41 2014] no roosbeef [Fri Apr 18 04:19:28 2014] is it possible to get more specifications on a message like this? Error: Impossible to unify "strict_order (MultisetGt ?2982)" with "strict_order (MultisetGT (transp l_Lt))". [Fri Apr 18 04:37:44 2014] i dont get it [Fri Apr 18 05:08:03 2014] how do i add lemmas to the hint database, or check that they are in there? [Fri Apr 18 05:28:46 2014] How do I load a file in coqtop? [Fri Apr 18 05:45:28 2014] Is there any kind of help command in coqtop? [Fri Apr 18 05:48:00 2014] I figured out how to load stuff, but if I make a small change in my file and want to reload it I get name collisions and have to quit coqtop and reload. Is there a better way to do this? [Fri Apr 18 05:59:04 2014] Guuf: I am not sure what you are doing, but if it's normal proof editing you should use Proof General or CoqIDE [Fri Apr 18 06:00:39 2014] I am working through the second chapter in “Certified Programming with Dependent Types”, so right now I am basically just doing regular programming. [Fri Apr 18 06:01:12 2014] CoqIde does not work on my OS and Proof General uses emacs. [Fri Apr 18 06:02:18 2014] :( You don't like emacs? [Fri Apr 18 06:02:35 2014] It basically is not possible to do proofs without proper IDE support [Fri Apr 18 06:02:55 2014] Which OS? [Fri Apr 18 06:03:26 2014] OS X. [Fri Apr 18 06:04:03 2014] I guess it was broken with the Mavericks update to OS X> [Fri Apr 18 06:04:36 2014] I guess it’s this bug: http://www.lix.polytechnique.fr/coq/bugs/show_bug.cgi?id=3155 [Fri Apr 18 06:06:00 2014] ezyang: Yeah, I thought so, we’ll see when I run into a wall. :) [Fri Apr 18 06:07:07 2014] It sounds like you've already run into it [Fri Apr 18 06:07:20 2014] :P [Fri Apr 18 06:07:57 2014] Nah, this is just a hurdle. [Fri Apr 18 07:23:25 2014] Maybe I’ll just make my own IDE, with blackjack, and hookers. [Fri Apr 18 07:50:57 2014] Guuf: there's a vim plugin which works great [Fri Apr 18 07:51:06 2014] I'm using it for months [Fri Apr 18 07:52:04 2014] Cool! [Fri Apr 18 07:52:08 2014] Thanks osa1. [Fri Apr 18 07:52:29 2014] Guuf: I'm using customized version of http://www.vim.org/scripts/script.php?script_id=4388 but there's also https://github.com/the-lambda-church/coquille [Fri Apr 18 07:53:46 2014] Guuf: you can see my vim setup here https://github.com/osa1/rcbackup you may want to copy coq related files/settings [Fri Apr 18 08:15:01 2014] osa1, thanks a bunch! [Sat Apr 19 05:52:04 2014] suppose we have this goal: strict_order (MultisetGT (transp l_Lt)) [Sat Apr 19 05:52:21 2014] and we have this proven Lemma, mord_sorder : strict_order MultisetGt. (see http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetOrder.html) [Sat Apr 19 05:52:54 2014] why does coq then give this error when trying to apply that lemma, and what does coq mean by that? Error: Impossible to unify "strict_order (MultisetGt ?2982)" with "strict_order (MultisetGT (transp l_Lt))". [Sat Apr 19 05:53:23 2014] it should be able to unify those? How can i find out whats going wrong [Sat Apr 19 07:56:33 2014] back in a bit [Sat Apr 19 09:33:34 2014] doh [Sat Apr 19 09:33:41 2014] GT is not Gt [Sat Apr 19 09:34:15 2014] how did i manage to overlook that for hours on end haha [Sat Apr 19 11:26:17 2014] what are the news about coq and its extracted programs ? [Sat Apr 19 12:40:03 2014] im trying to prove for some function f on strings that "forall x y : string_type, {f x y} + {~ f x y}" [Sat Apr 19 12:40:36 2014] it should be straight forward i think [Sat Apr 19 12:41:16 2014] but i keep getting stuck on the induction part [Sat Apr 19 12:41:21 2014] any tips? [Sat Apr 19 13:04:53 2014] roosbeef did you look at *_eq_dec theorems ? [Sat Apr 19 13:11:04 2014] well [Sat Apr 19 13:11:11 2014] ive been browsing them a lot yea [Sat Apr 19 13:11:28 2014] but arent those about equalities? [Sat Apr 19 13:13:58 2014] im trying to prove rel_dec f, not eq_dec f [Sat Apr 19 13:14:11 2014] um [Sat Apr 19 13:14:49 2014] i guess eq_dec f doesnt make sense but just to emphasize :p [Sat Apr 19 15:38:05 2014] ok i give up for today [Sun Apr 20 05:26:02 2014] to prove that a relation R is decidable, ie. rel_dec R (see http://color.inria.fr/doc/CoLoR.Util.Relation.RelMidex.html#rel_dec) [Sun Apr 20 05:26:28 2014] is it neccesary to use this lemma? http://color.inria.fr/doc/CoLoR.Util.Relation.RelDec.html#clos_trans_restriction_dec_R_dec [Sun Apr 20 08:05:41 2014] given a relation R on letters https://privatepaste.com/048ea75e06 [Sun Apr 20 08:06:51 2014] how can i write a function that takes a list of letters and returns a list of only those letters x for which l_Lt x y is not in l_Lt (given any y of the input list) [Sun Apr 20 08:09:38 2014] meh [Sun Apr 20 08:09:41 2014] i have to go [Sun Apr 20 08:09:48 2014] but im back in a bit [Sun Apr 20 08:21:11 2014] hi :p [Sun Apr 20 09:17:44 2014] Hello there roosbeef! [Sun Apr 20 09:31:19 2014] whats up Guuf [Sun Apr 20 09:31:26 2014] Not much. [Sun Apr 20 09:31:29 2014] The sun, I guess. [Sun Apr 20 09:31:35 2014] haha [Sun Apr 20 09:31:36 2014] You? [Sun Apr 20 09:31:36 2014] it is indeed [Sun Apr 20 09:32:05 2014] just listening to some music [Sun Apr 20 09:32:28 2014] i was taking a break from trying to figure out coq [Sun Apr 20 09:34:21 2014] Hmm, yes, indeed. I myself am trying to figure out Coq. What approach are you using? [Sun Apr 20 09:34:31 2014] brute force [Sun Apr 20 09:34:42 2014] Haha. :) [Sun Apr 20 09:34:54 2014] how far along are you? [Sun Apr 20 09:34:56 2014] Any special resources, books? [Sun Apr 20 09:34:59 2014] Not very. [Sun Apr 20 09:35:06 2014] well, ive read Coq'Art mostly [Sun Apr 20 09:35:16 2014] Is it good? [Sun Apr 20 09:35:48 2014] I have been reading “Certified Programming with Dependent Types” but couldn’t get an example to work. [Sun Apr 20 09:36:11 2014] i guess, although i only started to really understand coq after simply messing with it for a while [Sun Apr 20 09:36:29 2014] I see. [Sun Apr 20 09:36:43 2014] im probably not giving it enough credit though [Sun Apr 20 09:37:03 2014] because when i was reading that it seemed like it was the only resource on coq that would start you from scratch [Sun Apr 20 09:39:14 2014] itll probably seem like a brand new book when i read it now [Sun Apr 20 09:40:50 2014] besides that book, this channel has been of tremendous value to me [Sun Apr 20 09:41:58 2014] Okay, sounds good. [Sun Apr 20 09:42:25 2014] Well, I have been messing around a bit with Coq now, so maybe I should pick up Coq’Art. [Sun Apr 20 09:43:17 2014] it will get you past the point of trying to get an example to work thats for sure :p [Sun Apr 20 09:49:44 2014] :) [Sun Apr 20 09:54:39 2014] Coq d'Art doesn't teach you a method of proof, AFAIK. [Sun Apr 20 09:54:51 2014] It just shows you a bunch of random things you can do with Coq. [Sun Apr 20 09:55:46 2014] CPDT on the other hand shows a proof framework such that you can work in a structured manner. [Sun Apr 20 10:03:51 2014] hm [Sun Apr 20 10:04:03 2014] think ill just read CPDT [Sun Apr 20 10:04:17 2014] seems like a decent book [Sun Apr 20 12:21:59 2014] The goo.gl link in the topic appears to be about some publicly visible work of art, not a theorem. [Sun Apr 20 14:03:16 2014] hello. I do not quite get what {bla} does. for example, one has {a <= b}+{b <= a}. [Sun Apr 20 14:03:40 2014] can somebody explain please? [Sun Apr 20 14:06:07 2014] schoppenhauer: It's syntax for that it's decidable which of those outcomes it is. [Sun Apr 20 14:06:25 2014] scubed: i mean the {...} especially. [Sun Apr 20 14:06:49 2014] That's just syntax. It doesn't particular have meaning on its own. [Sun Apr 20 14:06:56 2014] particularly [Sun Apr 20 14:07:43 2014] scubed: but I cannot follow a+b from {a}+{b} [Sun Apr 20 14:08:32 2014] schoppenhauer: Try Locate "{" and you'll see that it comes out to sumbool and sumor. [Sun Apr 20 14:09:10 2014] So, + is not plus, but sumbool. [Sun Apr 20 14:09:24 2014] (You can also do Locate "+".) [Sun Apr 20 14:09:39 2014] So, it's not related to "a+b". [Sun Apr 20 14:09:50 2014] That would have a and b be nat, but here, they're propositions. [Sun Apr 20 14:10:14 2014] Does that help? Or which part is confusing? [Sun Apr 20 14:10:47 2014] hm. [Sun Apr 20 14:11:48 2014] scubed: why can't I use inl to generate a+b? [Sun Apr 20 14:12:26 2014] Could you give a concrete example? [Sun Apr 20 14:14:37 2014] scubed: http://lpaste.net/103003 [Sun Apr 20 14:15:02 2014] Impossible to unify "(?8286 + ?8287)%type" with "a <= b + b <= a". [Sun Apr 20 14:15:28 2014] it is a set, probably. [Sun Apr 20 14:15:34 2014] and not a type. [Sun Apr 20 14:16:15 2014] schoppenhauer: Check forall a b, (a <= b + b) /\ ( b+b <= a). [Sun Apr 20 14:16:34 2014] If you put that in, you'll see it displays as a <= b + b <= a, which is what you have in your goal. [Sun Apr 20 14:16:48 2014] m( [Sun Apr 20 14:16:50 2014] ok thx [Sun Apr 20 14:16:52 2014] So, you're doing plus (b : nat) (b :nat) [Sun Apr 20 14:17:07 2014] instead of sumbool (A : a <= b) (B: b <= a). [Sun Apr 20 14:17:37 2014] You need {} so it parses as sumbool instead of plus. [Sun Apr 20 14:20:08 2014] scubed: but (a <= b) + (b <= a) is not the same as {a <= b} + {b <= a}. [Sun Apr 20 14:21:05 2014] That's sum instead of sumbool. The Locate command shows you which syntax there is for different symbols. [Sun Apr 20 14:21:29 2014] is there a standard lemma showing that the one follows from the other? [Sun Apr 20 14:22:05 2014] I mean I can prove it now. [Sun Apr 20 14:22:10 2014] sumbool is Prop, sum is Type. [Sun Apr 20 14:22:20 2014] hm. [Sun Apr 20 14:22:46 2014] So, sum is more general. [Sun Apr 20 14:23:23 2014] e.g. like how there's nat_rect vs. nat_ind. [Sun Apr 20 14:24:38 2014] schoppenhauer: Print sum. Print sumbool. [Sun Apr 20 14:26:48 2014] schoppenhauer: You can do e.g. destruct (le_ge_dec a b) as [|] _eqn. [Sun Apr 20 14:27:09 2014] That proves your Lemma. [Sun Apr 20 14:34:59 2014] thx. [Sun Apr 20 15:51:30 2014] Ahoy. [Sun Apr 20 21:17:57 2014] so let's see, we've got values like 3, that are members of types, and the types are members of higher types (2-types) and so on through the finite indexes. the union is omega. question: is it meaningful to abstract over all of them and so on, so you get transfinite ordinal type levels? [Mon Apr 21 05:41:00 2014] hi [Mon Apr 21 05:41:53 2014] given a type and a partial order R on this type, is it possible to extract from a list of this type only those elements that are in R? [Mon Apr 21 05:42:00 2014] eg. https://privatepaste.com/ea625c88fd [Mon Apr 21 05:43:45 2014] how can i, given any list of letters, create a list of only the elements e such that forall x, not_eq x e -> l_Lt x e [Mon Apr 21 08:01:09 2014] brb [Mon Apr 21 15:14:58 2014] hello. I (still) do not get how I can get equalities from match ... with. If I have match a with | b => _, then in _, I want to have a predicate a=b [Mon Apr 21 15:15:02 2014] is that possible? [Mon Apr 21 15:18:02 2014] like I would do with eqn:... in inductions. [Mon Apr 21 15:34:52 2014] schoppenhauer: there is a design pattern to do this described in Adam Chlipala's book, CPDT. It's called the convoy pattern. [Mon Apr 21 15:35:47 2014] Essentially you eta-expand inside each match case to get equality hypotheses, and you apply the match to eq_refl of the discriminant (the thing you match on) [Mon Apr 21 15:36:34 2014] (match x as y in (x = y -> _) with blah => fun H : x = blah => rhs end (eq_refl x)) [Mon Apr 21 16:11:32 2014] ianjneu: thx. i try it, but didnt notice that my battery vanished. [Tue Apr 22 09:12:24 2014] hi. I have a problem: I know that a=b. and I want to prove that (forall x, x nat) = (forall x, x nat). [Tue Apr 22 09:12:58 2014] well actually, I have a function f : forall x, x nat, and I need forall x, x nat, but I can prove a=b. [Tue Apr 22 09:13:26 2014] but rewrite does not go into type parameters. [Tue Apr 22 09:16:43 2014] oh nice, setoid_rewrite gives a coredump :3 [Tue Apr 22 09:17:06 2014] a segv. [Tue Apr 22 09:17:18 2014] I assume this is a bug. right? [Tue Apr 22 09:19:04 2014] schoppenhauer: maybe you want "(forall x, x nat) -> (forall x, x nat)" instead of equality? [Tue Apr 22 09:19:16 2014] gdsfh: unfortunately, no. [Tue Apr 22 09:19:55 2014] hm. ok, independently of my actual problem, I can reproduce a segfault using setoid_rewrite. [Tue Apr 22 09:20:17 2014] is this a know issue or should I file a bug report? [Tue Apr 22 09:20:27 2014] schoppenhauer: Goal forall (a b : nat) (E : a=b), (forall x, x nat) = (forall x, x nat). intros a b E. rewrite <- E. reflexivity. Qed. [Tue Apr 22 09:20:41 2014] gdsfh: thx. [Tue Apr 22 09:21:00 2014] schoppenhauer: if you are using not so old coq version (>=8.4), it's better to file a bug. [Tue Apr 22 09:21:36 2014] Welcome to Coq 8.4pl3 (April 2014) [Tue Apr 22 09:21:40 2014] that should be sufficient :3 [Tue Apr 22 09:21:56 2014] schoppenhauer: btw, "<-" in rewrite is not necessary here. [Tue Apr 22 09:22:29 2014] gdsfh: I have read that without <- its not compatible with ssreflect. and even though I do not use ssreflect, I think it makes t he code more clear. [Tue Apr 22 09:28:20 2014] schoppenhauer: don't know about ssreflect. But as you wish; "rewrite E" == "rewrite -> E". In this example the direction of rewrite can be any. [Tue Apr 22 10:41:08 2014] Error: Impossible to unify "?9445" with "?9445". [Tue Apr 22 10:41:55 2014] :3 [Tue Apr 22 10:43:51 2014] Yup, that's an unhelpful error message. [Tue Apr 22 10:44:49 2014] I think you can tell Coq to print more details. [Tue Apr 22 10:45:20 2014] doesn't matter in this case. [Tue Apr 22 10:45:45 2014] Set Printing All! [Tue Apr 22 10:45:49 2014] I just thought it was funny. [Tue Apr 22 10:46:02 2014] tswett: thank you. [Tue Apr 22 10:50:38 2014] ok, my problem is more general: is there a possibility to replace x : T a with x : T b if a = b, where T is some type-functor? [Tue Apr 22 10:52:15 2014] or equivalently: a rewrite tactic that goes into every type parameter? [Tue Apr 22 11:06:58 2014] I don't remember if the type system is too stubborn to allow you to do that. [Tue Apr 22 11:10:36 2014] If I'm not mistaken (and my Coq is very rusty), the type checker will only give one type to a term; if x : T a, then (barring coercion) it's not the case that x : T b. [Tue Apr 22 11:10:56 2014] But I think given a = b, you ought to be able to take a term of type T a and create a different term of type T b out of it. [Tue Apr 22 11:13:44 2014] gah, I cannot even do pattern matching on dependent types ... [Tue Apr 22 11:14:01 2014] s/types/products [Tue Apr 22 11:14:19 2014] I am probably doing something wrong *reads chapter 17 agan* [Tue Apr 22 11:30:12 2014] tswett: if I define a coercion, is it possible then? [Tue Apr 22 11:31:00 2014] schoppenhauer: do you need x : T b, or just : T b ? [Tue Apr 22 11:31:18 2014] ystael: x : T b [Tue Apr 22 11:33:50 2014] I actually have a function f : forall (x : nat) (g : forall y : nat -> (y < x) -> nat). [Tue Apr 22 11:33:57 2014] and I am doing induction over x, essentially. [Tue Apr 22 11:34:26 2014] to prove that f 0 g = ..., and f (S n) g = ... [Tue Apr 22 11:34:55 2014] now when x = 0, g is not of type (forall (y : nat) -> (y < 0) -> nat). [Tue Apr 22 11:35:07 2014] (I know that y < 0 is not possible) [Tue Apr 22 11:35:19 2014] (but that is not the problem here) [Tue Apr 22 11:35:59 2014] (the function just must be the trivial function from \bot to \bot) [Tue Apr 22 11:38:57 2014] schoppenhauer: The type you have given for g is a type family, dependent on x. I feel like your match clauses should have the shape f 0 (g 0) = ..., f (S n) (g (S n)) = ... [Tue Apr 22 11:41:39 2014] i.e., g : P x where P x = forall (y : nat) -> (y < x) -> nat [Tue Apr 22 12:03:15 2014] ystael: you mean g gets an additional implicit argument? [Tue Apr 22 12:03:55 2014] Whether it is implicit or not is a syntactic issue, but yes, I think it needs to have an additional argument. [Tue Apr 22 12:50:51 2014] schoppenhauer: I think coercion is just a convenience allowing functions to be implied automatically, without having to be written; you can't do anything with coercion that you couldn't do without it. [Tue Apr 22 13:09:33 2014] ok, thanks. I am trying to do the whole thing in another way now. [Tue Apr 22 13:43:25 2014] Does the mainline version of Coq have universe polymorphism yet? [Tue Apr 22 15:15:44 2014] http://lpaste.net/103089 ok, this pretty much summarizes my problem I guess. [Tue Apr 22 15:16:28 2014] the refinement fails, because The 2nd term has type "forall x : nat, x < i0 -> nat" which should be coercible to "forall x : nat, x < i -> nat". [Tue Apr 22 15:20:53 2014] tswett: only for inductives, not for definitions. Matthieu Sozeau is working on full universe polymorphism. [Tue Apr 22 15:21:19 2014] he may have a version on github [Tue Apr 22 15:23:46 2014] does anyone have a clue whats wrong? [Tue Apr 22 15:37:47 2014] why doesn't it automatically substitute the correct term? [Tue Apr 22 15:48:17 2014] hm. I'll post it on SO. [Thu Apr 24 23:48:46 2014] Does coq support any form of definitional equality for coinductive types at the type level? [Thu Apr 24 23:50:15 2014] For example, how do I prove that (repeat 1 = Yield 1 (repeat 1)), for reasonable definitions of repeat and Yield and streams? [Thu Apr 24 23:59:46 2014] p92: doesn't cpdt discuss this [Thu Apr 24 23:59:48 2014] ? [Fri Apr 25 00:01:49 2014] p92: yeah, reread cpdt 5.2 [Fri Apr 25 00:06:28 2014] p92: short answer: your equality probably isn't provable. [Fri Apr 25 00:24:22 2014] jrw, CPDT suggests "no", wonder if anything has changed. [Fri Apr 25 00:27:32 2014] p92: what do you mean? [Fri Apr 25 00:28:51 2014] jrw, I get confused by Coq versions and which one CPDT discusses [Fri Apr 25 00:30:12 2014] p92: I seriously doubt that this has changed in any recent version of coq [Fri Apr 25 00:31:10 2014] jrw, fair enough [Fri Apr 25 09:02:47 2014] Hi! How would one go about proving a lemma where the left side of a consequence does not hold? [Fri Apr 25 09:02:57 2014] E.g. Lemma A: 2 = 3 -> P. [Fri Apr 25 09:04:49 2014] well, false proves anything, so exfalso [Fri Apr 25 09:09:42 2014] mrtn_: just do inversion on your hypothesis 2=3 [Fri Apr 25 09:11:45 2014] Ah yes, thanks! [Fri Apr 25 09:20:13 2014] Error: Cannot infer an internal placeholder of type "Type". [Fri Apr 25 09:20:14 2014] =/ [Fri Apr 25 09:23:38 2014] Solved with manual annotation of type. [Fri Apr 25 09:31:14 2014] Another question: How are lemma's with greater-than relations handled? [Fri Apr 25 09:31:34 2014] E.g. Lemma B: forall n, S n > O. [Fri Apr 25 09:40:14 2014] mrtn_, what do you want to do with it exactly? [Fri Apr 25 09:40:27 2014] mrtn_, I use "inversion" on them usually [Fri Apr 25 09:40:36 2014] mrtn_, but not sure that it is the best way [Fri Apr 25 09:44:46 2014] I try to proof that each iteration of my algorithm results in a smaller datastucture. I defined a length function and now I need to proof a subgoal similar to lemma B above. [Fri Apr 25 09:45:43 2014] How would I use inversion on lemma B, if I apply it directly it only duplicates my subgoal? [Fri Apr 25 11:11:17 2014] hello. is there a "<=" defined for Fin.t anywhwere? [Fri Apr 25 11:11:28 2014] otherwise I would have to use to_nat. [Fri Apr 25 11:21:54 2014] mrtn_, oh I thought you want to imply something from x > y. So now you need to construct element of x > y; lt is just inductive type lt. E.g. for Lemma B you need to destruct n, you will get n = 0 and goal : S O > O, this is proved by lt_base (I don't remember exact name); other branch is n = S n', here you need to use induction hypothesis and the second contructor of inductive lt. [Fri Apr 25 12:01:22 2014] gah, when I try to prove it, I get strange type errors. [Fri Apr 25 12:11:58 2014] is there any decidable equality for Fin.t ? [Fri Apr 25 12:25:05 2014] schoppenhauer: depends on what you want to show. You can use to_nat and decide equality there, or you can inject the smaller indexed type into the larger index and use a decidable equality in that type, but you're hosed if you want to arbitrarily compare elements of type Fin.t with different indices (unless you admit the sloppy JMeq axiom) [Fri Apr 25 12:50:30 2014] ianjneu: If (a b : Fin.t m), then it should be decidable whether a=b, shouldn't it? [Fri Apr 25 12:52:04 2014] ianjneu: that is, a and b both have the index m. [Fri Apr 25 12:56:00 2014] ianjneu: why are strong axioms required to proof equalities of *finite* objects? [Fri Apr 25 12:59:54 2014] ianjneu: equality of numbers is also decidable. and I really need forall m (a b : Fin m), a = b \/ ~ a = b [Fri Apr 25 13:07:57 2014] schoppenhauer: it's a little more difficult since the indices change through induction. You need a stronger argument. [Fri Apr 25 13:08:38 2014] ianjneu: so equality on Fin m is not decidable? [Fri Apr 25 13:10:49 2014] schoppenhauer: It is, it's just harder to prove. [Fri Apr 25 13:11:11 2014] ianjneu: is there a proof in the standard lib? [Fri Apr 25 13:11:18 2014] I could not find one [Fri Apr 25 13:12:40 2014] not that I know of. [Fri Apr 25 13:12:52 2014] perhaps in Agda's standard lib. [Fri Apr 25 13:13:40 2014] yeah, but I use coq ... [Fri Apr 25 13:14:54 2014] yes, but you can port proofs. [Fri Apr 25 15:09:12 2014] Hello all. [Fri Apr 25 15:09:45 2014] I just finished the first chapter of software foundation and trying to compile it using coqc Basic.v [Fri Apr 25 15:09:49 2014] but getting [Fri Apr 25 15:10:01 2014] Error: There are pending proofs [Fri Apr 25 15:10:19 2014] I think I proved all the theorem ihttp://lpaste.net/103203 [Fri Apr 25 15:10:40 2014] Could some one please tell me what is wrong with code. [Fri Apr 25 15:15:42 2014] identity_fn_applied_twice [Fri Apr 25 15:17:20 2014] keep_learning: ^ [Fri Apr 25 15:20:02 2014] ianjneu: I did not get you. You mean Notation "x ^ y" := ( exp x y ) ( at level 30, right associativity) : nat_scope. Eval simpl in 2^2^3 ? [Fri Apr 25 15:31:20 2014] Any one ? [Fri Apr 25 15:33:09 2014] keep_learning: Hi! [Fri Apr 25 15:33:28 2014] rribeiro: Hi! [Fri Apr 25 15:34:34 2014] keep_learning: When you ask "Any one?", its because do you have a question? [Fri Apr 25 15:34:50 2014] rribeiro: Yes. [Fri Apr 25 15:35:14 2014] I just finished the first chapter of software foundation [Fri Apr 25 15:35:16 2014] keep_learning: What is your question, maybe I could help you [Fri Apr 25 15:35:22 2014] keep_learning Any one ? ----> 1 [Fri Apr 25 15:35:28 2014] rribeiro: http://lpaste.net/103203 [Fri Apr 25 15:35:35 2014] and moving to second chapter [Fri Apr 25 15:35:42 2014] * gave an intuitionistic answer with a constructive proof :) [Fri Apr 25 15:35:48 2014] so it asked me to compiler the Basic.v [Fri Apr 25 15:35:59 2014] and but I am getting compiler error. [Fri Apr 25 15:36:08 2014] Error: There are pending proofs [Fri Apr 25 15:36:27 2014] but I think I proved every single theorem. [Fri Apr 25 15:36:38 2014] except one which I removed from file. [Fri Apr 25 15:37:58 2014] Yes. It give me the same error [Fri Apr 25 15:38:10 2014] I'm looking your code to see what is happening [Fri Apr 25 15:38:23 2014] Qed missing at identity_fn_applied_twice? [Fri Apr 25 15:39:19 2014] keep_learning: Just as jrw says: missing Qed at identity_fn_applied_twice [Fri Apr 25 15:39:33 2014] rribeiro: jrw Thank you! [Fri Apr 25 15:42:08 2014] rribeiro: so how come it accepted proof without Qed. Should not that be error ? [Fri Apr 25 15:42:53 2014] keep_learning: Yeah... It also have happened to me when I'm making software foundations... I don't know why this is happening [Fri Apr 25 15:43:19 2014] I believe that this is related to the fact that you can define a theorem inside another one. [Fri Apr 25 15:43:36 2014] so, before you Qed something, you can start another proof. [Sat Apr 26 05:26:48 2014] schoppenhauer: see https://github.com/robbertkrebbers/ch2o/blob/master/vector.v#L41 for decidable equality of fin [Sat Apr 26 06:47:09 2014] Hello. [Sat Apr 26 06:48:16 2014] I am reading CPDT #7, and see the definition of well-founded relation R as such, that every element is accessible with R. [Sat Apr 26 06:48:38 2014] And there is implication that such relation doesn't has infinitely decreasing chains. [Sat Apr 26 06:49:30 2014] Am I right that "<" on [0;1] would be well-founded in this definition if we could define real numbers? [Sat Apr 26 06:50:02 2014] (I mean that for "<" on [0;1] there are infinitely decreasing chains, but it satisfies the definition.) [Sat Apr 26 07:14:38 2014] how does it satisfy the definition? [Sat Apr 26 07:16:37 2014] suppose you are given a formalisation of reals; how do you give a proof that _<_ is WF? [Sat Apr 26 07:17:57 2014] ziman, hmm [Sat Apr 26 07:21:39 2014] ziman, seems I understood. We can't build acc_intro, because there are always elements less than given; in wf relations terminal point is when we haven't such elements, so function \y yRx -> _|_ is trivial. [Sat Apr 26 07:22:48 2014] I was confused with name of the relation "accessibility"; I interpreted it wrong. [Sat Apr 26 07:23:45 2014] right [Sat Apr 26 07:24:18 2014] it took a while for me to wrap my head around the notion [Sat Apr 26 12:14:59 2014] So what was the reason to shift from record based type classes to module based type classes? (I find the second much harder to use, though honestly I don't understand what I don't understand.) [Sat Apr 26 12:56:21 2014] nolrai66: I can't say for certain, but I do know there are performance benefits to using first order modules rather than records. [Sat Apr 26 12:57:21 2014] Okay. Its just I can not figure out how to use MSets. [Sat Apr 26 12:59:01 2014] Maybe I can get away with lists or vectors... [Sat Apr 26 13:38:22 2014] nolrai66: modules have been there long before type classes in Coq [Sat Apr 26 13:38:59 2014] hmm, maybe I should start checking whether people I respond to are actually still here... ;) [Sat Apr 26 13:39:24 2014] does anyone know whether you can make that more visible in weechat? [Sat Apr 26 13:40:10 2014] robbert: if you write names tab-complete, I think most chat clients only use the list of who's currently in the room. [Sat Apr 26 13:46:08 2014] ianjneu: awesome, that works :) [Sat Apr 26 13:53:58 2014] robbert: and now you have the problem where you reply to other people with the same prefix :) [Sat Apr 26 13:55:07 2014] anyway, speaking of modules, what's the curre [Sat Apr 26 13:55:39 2014] anyway, speaking of modules, what's a recommended overview of the state of the art in ML-style module systems? [Sat Apr 26 14:08:21 2014] ML-style module systems or just Coq's? [Sat Apr 26 14:08:49 2014] Dreyer & Rossburg have a good paper on mixin-based ML modules. [Sat Apr 26 14:09:54 2014] http://www.mpi-sws.org/~rossberg/papers/Rossberg,%20Dreyer%20-%20Mixin%27%20Up%20the%20ML%20Module%20System.pdf [Sat Apr 26 21:11:19 2014] hey all, is there a resource someone can point me to to read about how to structure a Coq project? [Sat Apr 26 21:11:49 2014] it doesnt seem to work too well when i dont put all the source in the same directory [Sat Apr 26 23:59:10 2014] ddere: I think CPDT has a chapter about structuring Coq projects. [Sun Apr 27 02:22:55 2014] jgross: cool thank you :) [Sun Apr 27 08:14:40 2014] when proving a decidability theorem, such as {f x} + {~ f x} [Sun Apr 27 08:15:04 2014] where f is inductively defined [Sun Apr 27 08:15:53 2014] is there a way to replace f with one of its clauses? [Sun Apr 27 08:16:33 2014] (without breaking up the {} + {~} decidability pattern) [Sun Apr 27 08:20:51 2014] roosbeef: "{induction,destruct,case,case_eq} (f x)." [Sun Apr 27 08:25:11 2014] eh [Sun Apr 27 08:25:25 2014] not sure if im applying it correctly [Sun Apr 27 08:26:06 2014] show your "proof window" maybe? [Sun Apr 27 08:27:01 2014] ok [Sun Apr 27 08:27:14 2014] well heres my goal: {MultisetGt l_Lt m n} + {~ MultisetGt l_Lt m n} [Sun Apr 27 08:27:17 2014] and im trying {constructor} (MultisetGt l_Lt m n). [Sun Apr 27 08:27:33 2014] Coq says Syntax error: '.' or '...' expected after [tactic:tactic] (in [proof_mode:subgoal_command]). [Sun Apr 27 08:29:51 2014] probably you need "destruct (MultisetGt l_Lt m n).". "{}" was a meta-stuff: choose one of these options. [Sun Apr 27 08:32:44 2014] ah [Sun Apr 27 08:34:09 2014] destruct (MultisetGt l_Lt m n). Error: Not an inductive product. [Sun Apr 27 08:34:09 2014] constructor (MultisetGt l_Lt m n). Error: The reference MultisetGt was not found in the current environment. [Sun Apr 27 08:35:37 2014] i actually just want to unfold MultisetGt i guess, its not directly inductively defined actually... Definition MultisetGt := clos_trans MultisetRedGt. [Sun Apr 27 08:36:33 2014] ok [Sun Apr 27 08:36:44 2014] this is weird [Sun Apr 27 08:36:55 2014] i did "unfold MultisetGt." and that just worked [Sun Apr 27 08:36:58 2014] apparently i hadnt tried that [Sun Apr 27 08:37:05 2014] yay me [Sun Apr 27 08:37:07 2014] :'( [Sun Apr 27 08:39:49 2014] also i was wrong about destruct, understood it. [Sun Apr 27 08:44:20 2014] hm [Sun Apr 27 08:44:29 2014] maybe you can help me with the following then [Sun Apr 27 08:44:54 2014] which happens to be my original question [Sun Apr 27 08:45:16 2014] with a goal like this: {clos_trans (MultisetRedGt l_Lt) m n} + {~ clos_trans (MultisetRedGt l_Lt) m n} [Sun Apr 27 08:45:35 2014] where clos_trans, MultisetRedGt and l_Lt are all inductive definitions [Sun Apr 27 08:46:05 2014] how can i rewrite any of those to their deeper definitions without breaking up the {...} + {~...} pattern? [Sun Apr 27 08:47:38 2014] something you can do, yes. But what kind of rewrite? What do you want to achieve? [Sun Apr 27 08:54:08 2014] good point [Sun Apr 27 08:54:58 2014] um [Sun Apr 27 08:55:13 2014] well im trying to prove that the decidability holds [Sun Apr 27 09:05:57 2014] roosbeef: so, if you want to rewrite inside {...}, you can do it with usual "rewrite" that takes term of type "... -> a = b", it should be possible. [Sun Apr 27 09:13:02 2014] roosbeef: but maybe there are lemmas about { clos_trans ?x } + { ~ clos_trans ?x }? you can try to SearchAbout them. [Sun Apr 27 09:21:30 2014] gdsfh1: nope, nothing in SearchAbout [Sun Apr 27 09:23:38 2014] is there a conventional approach to proving theorems like this? [Sun Apr 27 09:24:17 2014] for example breaking it up into deeper levels of decidability? Its probably easier to prove that l_Lt is decidable and that clos_trans is decidable for example [Sun Apr 27 09:42:29 2014] roosbeef: it could work. For example, if you prove lemma : forall x (xdec : {x} + {~x}), {clos_trans x} + {~clos_trans x}, then you can "apply" this lemma to your goal and next you will have to prove premises of this lemma (xdec). (of course "clos_trans x" is malformed; it takes 3 arguments as i see in your code, but i gave an idea only.) [Sun Apr 27 09:53:33 2014] ok yea that seems to work :) [Sun Apr 27 09:58:32 2014] gonna see how i can work with that [Sun Apr 27 09:58:34 2014] thanks gdsfh1 [Sun Apr 27 09:58:35 2014] brb [Sun Apr 27 11:49:21 2014] Error: Unable to unify. [Sun Apr 27 11:49:24 2014] how do i get more details on that? [Sun Apr 27 12:07:52 2014] roosbeef: unification is directionless and infamously hard to debug. The best I can say is that you are not giving enough explicit arguments somewhere. [Sun Apr 27 12:08:15 2014] also, PL research software is notoriously bad at including debugging features :P [Sun Apr 27 12:11:05 2014] i am giving explicit arguments [Sun Apr 27 12:11:14 2014] so i guess theres something wrong with them [Sun Apr 27 12:11:40 2014] would be nice if Coq just said what its expecting and what im giving [Sun Apr 27 12:15:16 2014] what do you mean by 'somewhere'? [Sun Apr 27 12:16:41 2014] just that. I don't know [Sun Apr 27 12:19:55 2014] * mutters something about coq should provide a constructive proof of an error [Sun Apr 27 12:38:33 2014] meh [Sun Apr 27 12:38:35 2014] https://privatepaste.com/150fcf5874 [Sun Apr 27 12:38:53 2014] im trying to do "apply t_step with A0 R x y in H" [Sun Apr 27 12:39:16 2014] shouldnt that fit? [Sun Apr 27 14:31:37 2014] roosbeef: subtraces? [Sun Apr 27 14:32:57 2014] try apply (@t_trans _ _ _ x y) in H [Sun Apr 27 14:33:14 2014] derp, nm I see you mean step. [Sun Apr 27 14:36:17 2014] ianjneu, subtraces? [Sun Apr 27 14:38:29 2014] the current proof engine (8.4) doesn't do well with dependent goals. You'll need to get a proof of R x y up-front to give to t_step, is my suspicion. [Sun Apr 27 14:42:28 2014] hm [Sun Apr 27 14:42:51 2014] but thats the subgoal im trying to prove :p [Sun Apr 27 14:43:27 2014] use cut [Sun Apr 27 14:44:13 2014] how? [Sun Apr 27 14:44:43 2014] cut (R x y); [intro Rxy; apply t_step|]. [Sun Apr 27 14:46:08 2014] cut creates a duplicate subgoal [Sun Apr 27 14:46:18 2014] suppose this works, how do i solve the new subgoal? [Sun Apr 27 14:48:36 2014] nm [Sun Apr 27 14:48:48 2014] its not a duplicate ;p [Sun Apr 27 22:15:46 2014] hi, anyone here? [Sun Apr 27 22:19:35 2014] hi molikto [Sun Apr 27 22:20:29 2014] i am reading the "theories" folder of HoTT. what does this means? why the last one is a Type? [Sun Apr 27 22:20:30 2014] Definition relation (A : Type) := A -> A -> Type. [Sun Apr 27 22:22:25 2014] for example, in haskell we have class Eq a where(==)::a →a →Bool [Sun Apr 27 22:23:46 2014] hmm, well relation takes two values of type A, and is a type that may or may not be inhabited [Sun Apr 27 22:24:41 2014] say you had a fixed-size vector, it’d be something like “Inductive vector (A : Type) : nat -> Type” [Sun Apr 27 22:25:31 2014] then “vector unit 2” is a type [Sun Apr 27 22:26:35 2014] ok. i see this. thanks. but i still do not understand why use this but not a bool or something. i think i should read more and see how's it actually used [Sun Apr 27 22:27:50 2014] types are usually better than bools, because you use it to provide proof that the two are related somehow, rather than just a boolean that asserts they are related [Sun Apr 27 22:28:28 2014] you can often then induct over the proof object because it has some structure [Sun Apr 27 22:28:43 2014] I’m not sure if what I’m saying is at all helpful; I haven’t read the HoTT stuff [Sun Apr 27 22:29:19 2014] thanks, i think i understand now. [Sun Apr 27 22:33:53 2014] hey - did you guys see that we had a Coq Fight in Sydney last week? [Sun Apr 27 22:33:54 2014] http://liamoc.net/posts/2014-04-26-coqfight.html [Sun Apr 27 22:34:12 2014] it was a lot of fun. we had projectors set up and raced to prove lemmas [Sun Apr 27 22:44:04 2014] and amosr won [Sun Apr 27 22:48:54 2014] :-) [Sun Apr 27 22:49:22 2014] that’s true, but I didn’t really want to gloat, I just thought others might be interested ;-) [Sun Apr 27 22:49:41 2014] amosr: I know, you're modest, but i got your back [Mon Apr 28 06:57:53 2014] im trying to prove the decidability of a relation [Mon Apr 28 06:58:15 2014] (without much use of pre-existing decidability lemmas from the libraries) [Mon Apr 28 06:58:41 2014] no matter how i break it up into subproblems, i dont seem to be succeeding [Mon Apr 28 06:59:10 2014] anyone got any tips to help me go the right direction? [Mon Apr 28 07:47:57 2014] Hello. [Mon Apr 28 07:48:29 2014] Am I right, that there is no easy way to place a proof from Prop into Set? [Mon Apr 28 08:14:26 2014] the point of Prop is to make that impossible so that anything in Prop can be erased [Mon Apr 28 08:26:45 2014] Actually, I don't understand this decision. [Mon Apr 28 08:26:46 2014] I have read that main reasons are erasability-and-extraction and some mathematical related to excluded middle (http://cstheory.stackexchange.com/questions/21836/why-does-coq-have-prop). [Mon Apr 28 08:27:13 2014] But if we are talking about extraction then it seems that there are better ways to provide erasability. [Mon Apr 28 08:27:38 2014] E.g. mark some things in development as "non-valuable" and travers their dependencies. [Mon Apr 28 08:27:58 2014] Or create polymorphic universe type with mark to erase it or not. [Mon Apr 28 08:28:18 2014] Because now we have to have duplicates of the same things in Prop and Set sometimes. [Mon Apr 28 08:29:05 2014] I have one proof in Prop and now I realized that I need to use it in computation, but it is difficult to move it into Set =/ [Mon Apr 28 08:34:36 2014] Maybe latter way ("polymorphic universe type with mark to erase it or not") is equivalent to polymorphism like "forall U, forall A : U, forall x y z : A, ". [Mon Apr 28 08:55:36 2014] I agree. ;) [Mon Apr 28 08:56:27 2014] that's why I developed erasure for Idris in a different way :) [Mon Apr 28 09:39:48 2014] Rc43: do you have a small but meaningful example where Set/Prop duplication is necessary? Interesting to look at it. (by no means I doubt that duplication can happen in a practically useful manner.) Also maybe coq-club members will suggest some way to avoid this duplication. [Mon Apr 28 09:39:57 2014] Rc43: but do you really mean Set? Why not Type? [Mon Apr 28 09:44:14 2014] there is a guy that achieves remarkably good erasure with Prop without much duplication [Mon Apr 28 09:45:01 2014] https://github.com/jonleivent/mindless-coding [Mon Apr 28 09:45:26 2014] it requires quite a lot of automation but it seems to be doable [Mon Apr 28 09:47:09 2014] also, the extracted ML code bears no trace of proofs at all, which is very nice [Mon Apr 28 09:48:02 2014] ziman: good stuff, but he overcomplicates things, imho. ML code is nice, really. [Mon Apr 28 09:48:53 2014] gdsfh1, could you make it simpler? [Mon Apr 28 09:49:43 2014] gdsfh1, 1st question: [Mon Apr 28 09:49:51 2014] Currently I have proof of termination for some function made by my collegue; it uses some metrics (i.e. functions X -> nat) and lemmas about decreasing of them. [Mon Apr 28 09:49:52 2014] basically, what he does is creating an Erased monad and then implementing some scaffolding for lifting things to it without having to duplicate definitions [Mon Apr 28 09:49:56 2014] Then I have main theorem about termination: "exists n : nat, ". [Mon Apr 28 09:50:01 2014] I wanted to refactor it to made proof be in Set, but encountered that can't destruct "/\" and "\/" to make Set. [Mon Apr 28 09:50:17 2014] This isn't a problem, just replaced with "*" and "+". [Mon Apr 28 09:50:23 2014] But then I found the same issue with "<" -- I don't see counterparts in Set for it and I also realized that there can be too much changes. [Mon Apr 28 09:50:25 2014] Theoretically, I can modify structure of proof to give number (which is "exists n : nat, ..."), but I am not sure that it is easy in my case. [Mon Apr 28 09:50:55 2014] So, it isn't something fundamental, just matter of pragmatics. [Mon Apr 28 09:51:38 2014] ziman: "make" -- no, have no time*brain now and in near future. just some thoughts: keep rbtree with invariants packed in value with computational part and invariants, write code with refine, prove invariants. [Mon Apr 28 09:52:02 2014] yes, ideally, the function would just take the proof to convince the termination checker that everything is okay, and then not use it at runtime to get rid of the proof as well [Mon Apr 28 09:52:28 2014] gdsfh1, that's what he does [Mon Apr 28 09:52:30 2014] gdsfh1, about 2nd question (Set/Type): I really don't know; what difference? [Mon Apr 28 10:01:05 2014] Rc43: 2. Set is a restricted kind of Type. Set is almost not needed in current versions of Coq, Type is enough. But sometimes people use Set with intention. I wondered whether is it your case. [Mon Apr 28 10:02:04 2014] Rc43: 1. why do you need a termination proof to be in Set? [Mon Apr 28 10:04:42 2014] gdsfh1, 1. I want to bind it with the function to get "good" wrapper (f : nat -> X -> option Y; termination : forall x : X, {n : nat | exists y, f n x = Some y}, g : X -> Y). [Mon Apr 28 10:05:16 2014] gdsfh1, 1. I need this "g" for more convinient definitions and proofs without considering unnecessary branch with None, etc. [Mon Apr 28 10:06:09 2014] gdsfh1, 2. I didn't know, what's the restriction? Maybe I have the same problem with Type, too, not sure. [Mon Apr 28 10:19:15 2014] Rc43: if you can reformulate "termination" to "forall x : X, {n : nat & {y : Y | f n x = Some y } }.", then it's possible to build "g". But maybe it's worth to rewrite proof and build Acc/wf for your recursion? [Mon Apr 28 10:26:52 2014] gdsfh1, yes, it is what I tried to do. Definetely it's worth to rewrite proof / build Acc/wf, but I need to understand code and some time :) [Mon Apr 28 10:27:18 2014] gdsfh1, as I said nothing fundamental, just weekday problems [Mon Apr 28 10:28:20 2014] gdsfh1, but what about Set-vs-Type? I thought that Set is just alias for Set0 and Type is aliase(es) for Set1 and higher. [Mon Apr 28 10:28:32 2014] Rc43: as I understand, the problems are caused by the fact that one can't destruct Prop and get value in Set/Type to use in computations. (here -- use in "g" as a return value.) [Mon Apr 28 10:29:13 2014] gdsfh1, yep, exactly [Mon Apr 28 10:32:46 2014] Rc43: I'm not an expert in theory, just a "software engineer", so don't believe me here :) But I think you are right about SetN. [Mon Apr 28 10:37:36 2014] Rc43: the set-vs-type thing is so that you don't "accidentally" go up a universe level when using Set. Type has typical ambiguity resolved in the background. [Mon Apr 28 10:38:05 2014] Set used to also be impredicative, but that was shown inconsistent. [Mon Apr 28 10:39:26 2014] ianjneu, what's bad in going up a universe level? Inference/type checking/unification problems? [Mon Apr 28 10:41:40 2014] Well, <=8.4 isn't universe-polymorphic, so you kind of screw yourself when trying to write reusable libraries that muck with universe constraints. [Mon Apr 28 10:42:43 2014] The HoTT people can probably tell better horror stories about typical ambiguity than I can. [Mon Apr 28 10:48:14 2014] Btw, is there < counterpart in Set? [Mon Apr 28 10:48:39 2014] as in, lt in the natural numbers? [Mon Apr 28 10:49:03 2014] Probably not. Coq libraries are not written in a relevance-polymorphic way. [Mon Apr 28 10:49:59 2014] If I learned anything using Coq, it's that abstraction is limited to copy and paste in most cases. [Mon Apr 28 10:50:27 2014] when you have a type system, that is. Oh man do I love Racket and its macros... [Mon Apr 28 10:51:29 2014] :D [Mon Apr 28 10:52:05 2014] Well, I hope that I needn't copy-paste something more than lt... [Mon Apr 28 10:52:54 2014] Rc43: theorems & proofs related to lt, no doubt. [Mon Apr 28 10:53:17 2014] But if you're doing this to prove termination, you're just doing it wrong. [Mon Apr 28 10:55:07 2014] ianjneu, maybe the proof uses only transitivity or something elementary (I hope :) [Mon Apr 28 10:55:19 2014] ianjneu, I agree, that it is done wrong [Mon Apr 28 10:55:29 2014] ianjneu, it's a crutch =/ [Mon Apr 28 10:56:28 2014] It's not so much a crutch as it is a virus. Proof relevance will spread everywhere in your development. [Mon Apr 28 10:57:38 2014] ianjneu, actually, I think that it will not; this function is a top of all development and I need only to prove one lemma about it for the interface between "that" part and "my" part. [Mon Apr 28 10:58:05 2014] Btw, in some sense any crutch is a virus. [Mon Apr 28 11:19:51 2014] Strange, ssreflect's "move =>" looks to behave differently for Prop and Set. [Mon Apr 28 11:41:57 2014] Also, can I print proof of local hypothesis? [Mon Apr 28 11:42:15 2014] I found it with omega and want to learn it. But proof session for it is already closed. [Mon Apr 28 12:22:11 2014] Rc43: no [Mon Apr 28 12:24:01 2014] you can print the entire proof term afterwards and find the binding that is the hypothesis you were looking for [Mon Apr 28 12:24:24 2014] Theorem foo : T. Proof. blah. Qed. Print foo. [Mon Apr 28 20:07:34 2014] hello. is it possible to prove that forall (n' : Fin 1), n' = Fin.F1? [Mon Apr 28 20:07:42 2014] because ... this obviously holds. [Mon Apr 28 20:23:19 2014] schoppenhauer: if you Require Import Program you can use the dependent destruction tactic to do that [Mon Apr 28 20:23:31 2014] requires JMeq, though [Mon Apr 28 20:23:59 2014] usually if you look at the resulting match annotations you can figure out how to do it yourself without JMeq [Mon Apr 28 20:24:14 2014] yeah it shouldn't be too hard [Mon Apr 28 20:24:31 2014] I just realized 8.4 has some better dependent match annotation inference when using refine! [Mon Apr 28 20:32:40 2014] like this: http://paste.awesom.eu/lxkj [Mon Apr 28 20:32:49 2014] (pretty bad proof, don't use it please :p) [Mon Apr 28 20:34:31 2014] got it [Mon Apr 28 20:34:55 2014] Ptival: ok, mine is different [Mon Apr 28 20:35:38 2014] Ptival: http://pastebin.com/vAVYH8AX [Mon Apr 28 20:36:11 2014] yeah dependent destruction hides away all the gory stuff :) [Tue Apr 29 03:23:45 2014] schoppenhauer, Ptival: and it secretly makes your lemma depend on an axiom... [Tue Apr 29 03:24:14 2014] Print Assumptions fin_1_is_1. [Tue Apr 29 03:24:18 2014] Axioms: [Tue Apr 29 03:24:20 2014] JMeq_eq : ∀ (A : Type) (x y : A), x ~= y → x = y [Tue Apr 29 03:25:48 2014] I tend to use a hand made inversion tactic for such types, like http://pastebin.com/KAg9f062 [Tue Apr 29 03:25:58 2014] at least, now you get axiom free proofs [Tue Apr 29 03:30:44 2014] robbert: the one I posted earlier should be axiom free [Tue Apr 29 03:30:50 2014] though I'd trust JMeq on that one [Tue Apr 29 03:31:02 2014] isn't it provable safe on decidable types or something like that? [Tue Apr 29 03:35:42 2014] JMeq A a A b is the same as (existT (fun T => T) A a) = (existT (fun T => T) A b). JMeq A a A b -> a = b is only provable when A is an hProp (when you already have forall a b : A, a = b). Otherwise it implies that the universe is an hSet, i.e., that all proofs of A = A are refl. [Tue Apr 29 03:44:02 2014] Does anyone get the political joke about John Major? I'm not from the UK. [Tue Apr 29 03:46:45 2014] Also, I think you should get JMeq A a A b -> ||a = b|| whenever a and b lie in equivalent connected components of A. [Tue Apr 29 03:52:51 2014] Cale: I can prove JMeq bool true bool false using univalence and the path ua negb. Does this break your claim? [Tue Apr 29 03:53:06 2014] nope, it's an example of it :) [Tue Apr 29 03:53:33 2014] I don't follow. We don't have || true = false ||, right? [Tue Apr 29 03:53:35 2014] true and false are in the two connected components of Bool, each of which is equivalent to the unit type [Tue Apr 29 03:53:48 2014] er [Tue Apr 29 03:53:52 2014] oops, yeah [Tue Apr 29 03:54:06 2014] hmm, what do I want to say here :) [Tue Apr 29 03:55:48 2014] You get JMeq A a B b -> A = B, but that's not particularly interesting, I think. If A has decidable equality, you provably don't get anything more than that, because the "swap a and b" isomorphism equates all a's and b's. If A does not have decidable equality, then the case is murkier. [Tue Apr 29 03:55:57 2014] Maybe I just wanted to say ||JMeq A a B b|| whenever a and b lie in equivalent connected components of A [Tue Apr 29 03:56:09 2014] That seems more plausible [Tue Apr 29 03:56:16 2014] er [Tue Apr 29 03:56:25 2014] that B should be A [Tue Apr 29 03:57:28 2014] So, you transport along the equivalence which swaps the two components, and get mere existence of a path between them [Tue Apr 29 03:58:26 2014] I'm not sure that's provable without decidable equality. Like, say you have that { x : A & || x = a || } and { x : A & || x = b || } are equivalent types, and you want || JMeq A a A b ||. I don't see where you're going to pull a mere isomorphism of A from, since you don't really know enough to swap the connected components unless || x = a || and || x = b || are decidable. [Tue Apr 29 04:15:38 2014] hmmm [Tue Apr 29 07:57:12 2014] robbert, Ptival, jgross: Hm. Ok, I guess I'll just try to avoid it and write stuff where I need it only inside small opaque lemmata, so I can replace them later. currently, it somehow boosted my productivity. [Tue Apr 29 07:57:18 2014] is that a good strategy? [Tue Apr 29 07:59:09 2014] (as far as I understand, that is what I was suggested to do anyway, sort of... looking at the proofs dependent induction gives me.) [Tue Apr 29 07:59:14 2014] (but I can do that later as well) [Tue Apr 29 10:21:33 2014] Cale: I remember asking Conor to explain it to me. IIRC, John Major was arguing for a classless society, but didn't really come through, so that's meant as "any two things can hope to be equal, but in practice only two of the same things can be truly equal" [Tue Apr 29 10:22:58 2014] jgross: thanks [Tue Apr 29 14:53:03 2014] Hello. [Tue Apr 29 14:54:47 2014] I am wondering, why eliminating of Prop is forbidden not for all elements of Prop? [Tue Apr 29 14:55:38 2014] E.g. proving "Lemma q (p : 1 = 1) : { n : nat | n > 6 }" I can do "destruct p". [Tue Apr 29 14:56:00 2014] Or for "(p : 1 = 1 /\ 2 = 2)" I can do "destruct p", too. [Tue Apr 29 14:56:22 2014] But for "(p : 1 <= 2)" I can't. [Tue Apr 29 14:56:55 2014] ("Case analysis on sort Set is not allowed for inductive definition le.") [Tue Apr 29 14:57:21 2014] So, is it really true that I can't build anything in Set/Type from Prop? [Tue Apr 29 14:57:59 2014] Or I can to do it only before Qed and then proof will be declined anyway? [Tue Apr 29 15:01:44 2014] Rc43: not sure what you mean, it's the universe of what you're trying to build that influences whether Prop elimination is allowed or not [Tue Apr 29 15:02:04 2014] let me try [Tue Apr 29 15:02:41 2014] Rc43: the difference is the number of constructors. If only 1, then the Prop can be destructed without case analysis. [Tue Apr 29 15:03:08 2014] oh :) [Tue Apr 29 15:03:16 2014] jonikelee, ah, so simple [Tue Apr 29 15:04:35 2014] jonikelee, does it imply that inductive types with only one constructor don't carry any information in some sense? [Tue Apr 29 15:05:01 2014] jonikelee, we needn't destruct, because all information is already known, etc. [Tue Apr 29 15:05:05 2014] It implies they don't carry information in the form of which constructor was used - but their args might carry some. [Tue Apr 29 15:06:00 2014] jonikelee, yes, I forgot about arguments. Is it ok then to allow to destruct Prop? [Tue Apr 29 15:06:20 2014] jonikelee, I mean destruct one-constructor inductives in Prop. [Tue Apr 29 15:07:20 2014] Yes - any single constructor inductive in Prop is always destructable, since no choice (no info) was involved in its construction. [Tue Apr 29 15:08:33 2014] jonikelee: not true in all models. Singleton elimination changes the theory. It's inconsistent with univalence. [Tue Apr 29 15:09:26 2014] Oh - sorry - in the standard Coq model then. I guess one should never say "always". [Tue Apr 29 15:10:09 2014] ianjneu, why is it inconsistent with univalence? [Tue Apr 29 15:11:16 2014] It makes every proof of equality refl, which ua refutes with something like the circle. [Tue Apr 29 15:14:42 2014] ianjneu, it is inconsistent in UA + HIT only or in any UA? [Tue Apr 29 15:17:05 2014] bool = bool has two distinct proofs of equality [Tue Apr 29 15:18:58 2014] Ah, I got it. I thought it is because HIT can add "constructors" of Eq, but it is just because in HoTT we use information while construct Eq object (even without HITs). [Tue Apr 29 20:29:24 2014] Ptival: ah, haha [Tue Apr 29 22:31:29 2014] schoppenhauer: did you ever get the decidable equality of Fin.t figured out? [Tue Apr 29 22:44:42 2014] Why is it that sometimes I should supply forall-arguments explicitly and other times I shouldn't? [Tue Apr 29 22:45:20 2014] I.e sometimes it's a type error to leave them out and sometimes it's a type error to provide them explicitly [Tue Apr 29 22:45:41 2014] The example I'm looking it is page 60 of http://adam.chlipala.net/cpdt/cpdt.pdf [Tue Apr 29 22:46:37 2014] And_case is applied without passing in f1 and f2 explicitly, while Forall_case is applied specifying f explicitly [Tue Apr 29 22:47:33 2014] see Set Implicit Arguments. [Tue Apr 29 22:50:19 2014] ah, the args are implicit, and if i want to specify them explicitly I need to do so by name [Tue Apr 29 22:50:32 2014] Thanks ianjneu [Tue Apr 29 22:51:09 2014] or use the @ syntax to get the explicit version [Tue Apr 29 22:52:00 2014] And "Print Implicit" shows which args are implicit. Okay, I'm good now. [Tue Apr 29 22:52:33 2014] @ works too. Thanks. [Tue Apr 29 22:52:36 2014] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Tue Apr 29 23:06:48 2014] @Check Acc_ind. [Tue Apr 29 23:06:48 2014] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Tue Apr 29 23:07:04 2014] huh. [Tue Apr 29 23:20:39 2014] schoppenhauer: I played around with it. Here's my solution. http://lpaste.net/103378 [Tue Apr 29 23:34:19 2014] @help [Tue Apr 29 23:34:19 2014] Get help on what? (try 'help ', or 'commands' for a command list) [Tue Apr 29 23:34:28 2014] @help commands [Tue Apr 29 23:34:29 2014] Usage: commands - List available commands [Tue Apr 29 23:34:36 2014] @commands [Tue Apr 29 23:34:36 2014] buildbot commands: about, check, commands, compute, def, default, hello, help, mute, print, source, unmute, version [Tue Apr 29 23:35:06 2014] @check Acc_ind [Tue Apr 29 23:35:18 2014] @check Acc_ind. [Tue Apr 29 23:36:02 2014] Acc_ind : ∀ (A : Type) (R : A → A → Prop) (P : A → Prop), [Tue Apr 29 23:36:02 2014] (∀ x : A, (∀ y : A, R y x → Acc R y) → (∀ y : A, R y x → P y) → P x) [Tue Apr 29 23:36:02 2014] → (∀ x : A, Acc R x → P x) [Tue Apr 29 23:36:03 2014] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Wed Apr 30 07:28:49 2014] Hello. [Wed Apr 30 07:29:26 2014] I found that somehow I can't build Prop with destructing of exists. [Wed Apr 30 07:30:39 2014] I get error "case analysis on sort Type is not allowed for inductive definition ex". [Wed Apr 30 07:31:55 2014] Aaah, I understood my mistake. I tried to prove "Prop" (I was meaning element of Prop). [Wed Apr 30 07:33:09 2014] Or didn't understand =/ [Wed Apr 30 07:33:45 2014] I am trying "Definition order (x y : X) : Prop." and then to do refines for constructing formula. [Wed Apr 30 07:38:23 2014] What's wrong with this? "Definition order (x y : X) := match some_function x with ex_intro y' ... => y = y' end." [Wed Apr 30 07:41:21 2014] Seems that the reason is elimination of Prop for construction of Type. But is it the same "dangerous" as construction of Set? [Thu May 1 10:34:08 2014] how do i force coq to normalize decidable equality statements automatically? [Thu May 1 10:35:24 2014] for example "if match fletter_eq_dec (FrenchLetter a grave) (FrenchLetter a grave) with" [Thu May 1 10:37:07 2014] is your eq_dec Defined or Qed'd? [Thu May 1 10:37:37 2014] Qed [Thu May 1 10:37:43 2014] should i use Defined? [Thu May 1 10:37:47 2014] yes. [Thu May 1 10:37:51 2014] ha [Thu May 1 10:37:54 2014] lets see [Thu May 1 10:37:55 2014] Qed removes computational content. [Thu May 1 10:38:31 2014] works :) [Thu May 1 10:38:33 2014] hm [Thu May 1 10:38:38 2014] so when to use Qed? [Thu May 1 10:38:50 2014] never! [Thu May 1 10:38:58 2014] haha [Thu May 1 10:39:32 2014] Use Qed when you don't need the result, just the type. [Thu May 1 10:39:47 2014] e.g. correctness theorems. [Thu May 1 10:39:58 2014] ok that makes sense [Thu May 1 10:40:10 2014] when you simply want to know IF some statement holds [Thu May 1 10:40:52 2014] except for some pseudo-efficiency-results, is it really useful to remove computational content? [Thu May 1 10:40:56 2014] is there any advantage to using Qed over Defined in those cases? [Thu May 1 10:41:05 2014] ha i was going to aim at the same [Thu May 1 10:41:22 2014] I mean, ok, when actually extracting programs ... that is, in the late developement-phase ... it might be. [Thu May 1 10:41:32 2014] or if proof-irrelevance is needed. [Thu May 1 10:41:56 2014] decidable equalities need computational content if you use them in functions that are extracted. [Thu May 1 10:42:04 2014] However, [Thu May 1 10:42:25 2014] it's better to write a -> bool function and prove a correspondence instead [Thu May 1 10:42:40 2014] hm. agda-developers would not agree, I guess ^^ [Thu May 1 10:42:49 2014] "forgettfull boolean" and stuff. [Thu May 1 10:42:59 2014] so I guess it is a matter of culture. [Thu May 1 10:43:03 2014] Agda people don't write programs that do anything. [Thu May 1 10:43:38 2014] so ya, elitists can go ahead and say, "no no no" but I'll get shit done at the end of the day. [Thu May 1 10:43:52 2014] well, I wonder ... isn't it a solved problem to track the parts of a lambda-term that are actually needed? [Thu May 1 10:44:29 2014] which makes the efficiency-part of proof irrelevance ... sort of useless? [Thu May 1 10:44:36 2014] useless variable elimination does not go deep into data structures. [Thu May 1 10:45:09 2014] which is the optimization I think you're alluding to. [Thu May 1 10:45:30 2014] hm. probably. [Thu May 1 10:45:38 2014] well, lazy evaluation, then? [Thu May 1 10:46:07 2014] I remember that I proved for the formalism of minlog that it is possible to automatically decorate proofs. [Thu May 1 10:46:26 2014] laziness is seldom what you want. [Thu May 1 10:46:49 2014] @laziness: well, if it makes work easier, it is a prize I am willing to pay. [Thu May 1 10:46:52 2014] error: Syntax error: end of input expected after [constr:lconstr] (in [constr:lconstr_eoi]). [Thu May 1 10:46:52 2014] scratch that, need. I have no idea what backward-ass desires people have these days. [Thu May 1 10:47:32 2014] * shrugs, walks off [Thu May 1 10:47:44 2014] anyway, I am not sure whether the same decorating algorithm works for dependent types as well. [Thu May 1 10:47:52 2014] Hodapp: heh, not touching that one? [Thu May 1 10:48:14 2014] in minlog, you do not squash types, but you decorate quantifiers and implications with "c" and "nc" (computable and non-computable) [Thu May 1 10:48:33 2014] and an optimal such decoration can be found automatically. [Thu May 1 10:49:31 2014] ianjneu: never written in Agda before. [Thu May 1 10:50:04 2014] Hodapp: have you written minlog? [Thu May 1 10:51:29 2014] http://hugelol.com/lol/270917? [Thu May 1 10:51:31 2014] GAH [Thu May 1 10:51:35 2014] wrong channel, sorry. [Thu May 1 10:52:35 2014] hugelol :p [Thu May 1 10:52:36 2014] j/k [Thu May 1 10:52:43 2014] nice. [Thu May 1 10:52:44 2014] interesting discussion [Thu May 1 10:53:36 2014] regardless: thanks very much guys for solving my problem by changing a single word haha [Thu May 1 11:12:36 2014] Nope. [Fri May 2 12:24:44 2014] hello. can somebody please explain to me, what <+ means (heavily used in http://coq.inria.fr/distrib/V8.4/stdlib/Coq.Structures.Orders.html#) [Fri May 2 12:25:16 2014] I need Mergesort (actually, I need any kind of sorting predicate to begin with), and would like to keep it near the stdlib. [Fri May 2 12:25:59 2014] but I have a special ordering relation. I can prove transitivity, decidability, antisymmetry, etc. - but I have no idea how to pack that together such that I can use the predefined stuff for it. [Fri May 2 12:38:13 2014] <+ is sugar for including all module types or modules mentioned. [Fri May 2 12:44:13 2014] so you can <+ all the module types that include those properties. OrderedType is decidable and has a strict ordering. Transitivity and antisymmetry come from IsStrOrder, which uses the StrictOrder class in Classes/RelationClasses. [Fri May 2 12:45:48 2014] forgive me, antisymmetry is not strictness. That's irreflexivity. [Fri May 2 12:46:31 2014] ianjneu: so ... all I have to do is ... make a module, let it <: LeBool, and implement le_..., etc., inside it? [Fri May 2 12:46:51 2014] ya, modules are terribly verbose. [Fri May 2 12:47:19 2014] hm? [Fri May 2 12:48:09 2014] "ya"? [Fri May 2 12:49:10 2014] ianjneu: what do you mean? [Fri May 2 12:50:26 2014] nevermind me. [Fri May 2 12:50:29 2014] I just bitch. [Fri May 2 12:51:44 2014] ok. [Fri May 2 14:44:44 2014] Is type "Inductive Q : Set := | q : Q -> Q." equal to empty type? [Fri May 2 14:57:36 2014] Rc43 i am not sure if it is a valid definition. [Fri May 2 15:01:00 2014] It's a valid definition, and yeah, it's empty. [Fri May 2 15:01:55 2014] (Try proving that, it's not hard: Theorem emptyQ : not Q. ) [Fri May 2 15:05:43 2014] Cale, ah, yep; obvious. And there is other side of isomorphism because we have morphism from False to anything. [Sat May 3 01:36:38 2014] Are there really trivial examples that demonstrate the workflow? [Sat May 3 01:44:06 2014] I mean, really trivial. I have never done any automated/assisted theorem proving but I'd like to get into it. [Sat May 3 01:44:32 2014] dmbaturin: Are you looking for a book? [Sat May 3 01:44:39 2014] dmbaturin: or a video? or? [Sat May 3 01:45:58 2014] dmbaturin: This book starts out pretty basic: http://www.cis.upenn.edu/~bcpierce/sf/ [Sat May 3 01:46:00 2014] lispy: Preferrably a commented code sample that gives the answer for a trivial axiom set and proposition (like x+3 always >=3 or whatever). [Sat May 3 01:46:15 2014] dmbaturin: and I think this is a recorded lecture for that same book: https://www.youtube.com/watch?v=KKrD4JcfW90 [Sat May 3 01:46:39 2014] dmbaturin: do you have proof-general setup in emacs? [Sat May 3 01:47:38 2014] Uhm, no, I generally prefer vim over emacs. I installed the coq IDE. [Sat May 3 01:48:00 2014] Should I setup it in emacs instead? [Sat May 3 01:48:54 2014] I like vim too, but the coq integration doesn't appear to work reliably [Sat May 3 01:49:20 2014] I asked a friend about Coq IDE and he said it's best to skip it and go straight to proof-general [Sat May 3 01:49:36 2014] He felt that it's flaky [Sat May 3 01:49:45 2014] (I don't have any experience) [Sat May 3 01:50:50 2014] Ah, ok. I'm not really an emacs hater type. [Sat May 3 01:50:53 2014] dmbaturin: getting back to your earlier question. Are you familiar with natural deductions or representing proofs as a tree of derivations? [Sat May 3 01:51:33 2014] lispy: A little. I think I have a lot to catch up here. [Sat May 3 01:53:04 2014] dmbaturin: The proof assistant interaction (using tactics) is really that same concept. [Sat May 3 01:53:50 2014] dmbaturin: Coq presents you with a list of things it currently knows and a current goal. And the format is very similar to that of a natural deduction. [Sat May 3 01:54:51 2014] It's your job to help it make progress by using a tactic on some of the known things to transform (or solve) the goal. [Sat May 3 01:54:58 2014] Very abstract and probably not helpful :) [Sat May 3 01:56:01 2014] I'll read the "Software foundations" book then, seems it has some examples. [Sat May 3 01:56:42 2014] Download the .v files and step through them in proof-general with C-c C-n [Sat May 3 02:09:58 2014] lispy: What kind of tasks do you use coq for? [Sat May 3 02:14:05 2014] dmbaturin: Learning Coq :) [Sat May 3 02:14:33 2014] at the moment I'm just learning it to learn it. [Sat May 3 02:27:33 2014] lispy: Ah, same here. I'm using SPARK for Ada programs verification, but I want to get into more fundamental proofs too. [Sat May 3 06:30:58 2014] ok so [Sat May 3 06:31:28 2014] im working with an order on the data type 'term' [Sat May 3 06:31:39 2014] Error: The term "empty_vterm" has type "VTerm.term fs_Sig" while it is expected to have type "term". [Sat May 3 06:32:02 2014] this is what Coq tells me when i try to call it - Eval compute in MyLPO.lt_lpo empty_vterm empty_vterm. [Sat May 3 06:32:21 2014] i think that coq doesnt realize these are actually the same type.. [Sat May 3 06:32:39 2014] how can i find out where the gap lies and how can i bridge that gap, anyone? [Sat May 3 06:53:23 2014] brb [Sat May 3 23:40:29 2014] [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup [Sun May 4 10:06:39 2014] hi. I'm trying to work with boolean vectors. Apparently I can't declare a fixpoint on them, because "Bcons" would not be a constructor. [Sun May 4 10:07:05 2014] I tried to use the "cons" constructor of vector, but apparently I can't reach it. [Sun May 4 10:07:29 2014] I can't require "Vector" either, it appears to be hidden in Bvector [Sun May 4 10:11:03 2014] there's not even a file called like that, even though i just installed a debian package [Sun May 4 10:22:17 2014] i upgraded the package, and now it works [Mon May 5 11:04:31 2014] Is there somewhere I can find a definition of positive / negative position in inductive definitions? Unfortunately, all of the Google results I've managed to find relate to coordinate systems, etc. [Mon May 5 11:05:31 2014] ryanakca: a precise definition is in 4.5.3 of http://coq.inria.fr/doc/Reference-Manual006.html [Mon May 5 11:05:45 2014] ystael: Thanks [Mon May 5 11:05:53 2014] "strictly positive occurrence" may be a better Google phrase [Mon May 5 12:12:40 2014] is there something similar to eqn:? for elim? [Mon May 5 12:12:47 2014] that is, getting the equality? [Mon May 5 14:01:56 2014] hi! [Mon May 5 14:02:21 2014] I'm trying to use the "Drop" command (from coqtop) [Mon May 5 14:02:53 2014] but I don't know how to "reattach"/"return to" coq once I am done with on the caml side [Mon May 5 14:03:03 2014] the ressources I found seem outdated [Mon May 5 14:03:11 2014] ( http://coq.inria.fr/cocorico/CoqCustomizationHowTo and http://flint.cs.yale.edu/cs428/coq/doc/Reference-Manual014.html ) [Mon May 5 14:03:57 2014] ( http://coq.inria.fr/refman/Reference-Manual016.html#sec567 says the same as that last link, but that doesn't seem to work for me) [Mon May 5 14:05:51 2014] ok it seems to now be called "Coqloop.loop" [Mon May 5 14:05:57 2014] (found this in dev/base_include) [Mon May 5 14:06:00 2014] sorry for the noise [Mon May 5 14:08:26 2014] hello. [Mon May 5 14:08:32 2014] is it possible to prove Lemma existT_inj : forall f (n : nat) (a m : f n), existT f n a = existT f n m -> a = m. [Mon May 5 14:08:47 2014] because that should hold... [Mon May 5 14:43:58 2014] ok, I probably can get it with dependent equality. [Mon May 5 14:57:09 2014] you need to use the fact that nat has decidable equality [Mon May 5 17:29:04 2014] Ahoy. Is there some convention as to when an identifier should begin with a capital letter? [Mon May 5 17:33:27 2014] tswett: the convension usually is that types are uppercase. [Mon May 5 17:33:37 2014] well, start with a capital letter I mean. [Mon May 5 17:34:02 2014] but that isn' strictly true. [Mon May 5 17:34:04 2014] That convention seems to be violated pretty frequently in the standard library, though. [Mon May 5 17:34:07 2014] With things like nat and relation. [Mon May 5 17:34:10 2014] tswett: indeed. [Mon May 5 17:34:26 2014] I could see a person arguing that nat is a "pretty small" type or something. [Mon May 5 17:35:06 2014] I often see ML-ish types with lowercase, but "more dependent" types with capital letters. [Mon May 5 17:35:52 2014] Now, if I'm in a proof and the goal is a record type, is there a tactic I can use to perform one proof for each field in the record? [Mon May 5 17:36:46 2014] constructor should work. [Mon May 5 17:37:23 2014] There we go. Thanks. [Mon May 5 17:38:50 2014] This proof ends up being pretty easy, then. [Mon May 5 17:38:54 2014] "constructor. auto. auto. auto." [Mon May 5 17:50:34 2014] constructor; auto. [Mon May 5 17:51:08 2014] or if you have Hint Constructors your_record_type. then just auto will work.e [Mon May 5 19:12:46 2014] gah ... again ... I need to prove Lemma toN_S : forall {n} (t : fin n), toN (FinFS t) = S (toN t). [Mon May 5 19:12:55 2014] but I can't ... [Mon May 5 19:13:08 2014] I always run into problems with the typechecker. [Mon May 5 19:23:29 2014] do you have a working file? [Mon May 5 19:23:43 2014] schoppenhauer: ^ [Mon May 5 22:37:02 2014] hm. I solved the problem differently. [Mon May 5 22:37:12 2014] now ... I am trying to understand the mergesort-package. [Mon May 5 22:37:38 2014] when I use "sort f L", it returns Sorted f L : Prop, instead of ... a list. [Mon May 5 22:38:04 2014] as it should, as far as I understand http://coq.inria.fr/library/Coq.Sorting.Mergesort.html [Mon May 5 22:39:54 2014] dunno. [Mon May 5 22:40:21 2014] hm? [Mon May 5 22:40:28 2014] well, you told me this already. [Mon May 5 22:40:46 2014] there is an example ... but it is ... strange. [Mon May 5 22:45:48 2014] this whole part of the library seems ... over-engineered. [Mon May 5 22:54:30 2014] It's hard to strike the right balance between generality/reusability and intuitiveness/usability. [Mon May 5 23:04:16 2014] for list sorting, it shouldn't be too hard, though. [Mon May 5 23:05:33 2014] I never really understood anything beyond what java-people would call "interfaces" ... have dependent records with some guaranteed functions and name shadowing if you really want. [Mon May 5 23:06:34 2014] When you don't have fully dependent types, I see a reason for template- and generic-mechanisms. but aren't "parametrized modules" just types? [Mon May 5 23:09:26 2014] functors and modules are second class for static compilation reasons. [Mon May 5 23:11:37 2014] ok. so it is not bad style to just ... not use them. when one already decided to use eqdep/JMeq and make everything computational... [Mon May 5 23:12:23 2014] A lot of Coq developers have abandoned modules in favor of type classes. [Tue May 6 00:25:54 2014] a lot of Coq developers have abandoned modules in favor of dependent records [Tue May 6 02:48:46 2014] Ptival, that’s interesting. Would you say more about that? [Tue May 6 11:41:13 2014] steshaw: https://plus.google.com/103230589736939055811/posts/hd4PTtZvEuN [Tue May 6 16:25:36 2014] Ptival: thanks. IIRC Lennart Augustsson used dependent records in Cayenne but there was some kind of downside that I can't recall (and probably never understood) [Tue May 6 17:31:27 2014] well I'd be interested in knowing :) [Tue May 6 18:23:08 2014] Can anyone help me understand induction on propositions? [Tue May 6 18:23:11 2014] http://lpaste.net/103701 [Tue May 6 18:26:56 2014] performing an induction on something without all variable parameters rarely works. You may need to generalize. [Tue May 6 18:27:25 2014] But all my variables are mentioned in the hypothesis. There's nothing to generalize. [Tue May 6 18:27:51 2014] (n::l1) is not a single variable. [Tue May 6 18:27:54 2014] I'll take a closer look. [Tue May 6 18:28:00 2014] thanks. [Tue May 6 18:31:23 2014] your notion of subsequence is that l is a subsequence of l' iff l' is of shape _++l++_ ? [Tue May 6 18:32:38 2014] no, interspersed characters should be okay, too. [1;3;5] is a subsequence of [1;2;3;4;5]. [Tue May 6 18:32:45 2014] at least that was the intent. [Tue May 6 18:33:14 2014] okay. [Tue May 6 18:51:57 2014] http://lpaste.net/103705 [Tue May 6 18:53:38 2014] Thanks! [Tue May 6 19:07:00 2014] ianjneu: It's kind of weird that you do induction on l1/l2, not the evidence [Tue May 6 19:11:57 2014] ezyang: the (n::l1) makes the induction fail, since it's "forgotten" with a fresh list variable. [Tue May 6 19:12:26 2014] yeah [Tue May 6 19:12:41 2014] so I did what didn't fail. [Tue May 6 19:12:42 2014] but it turns out that sticking it in an external equality isn't right either; you get the wrong IH [Tue May 6 19:12:51 2014] here is a more golfed proof: induction l2; inversion 1; auto. [Tue May 6 19:14:06 2014] nice. Needs Hint Constructors subsequence @avenge [Tue May 6 23:40:01 2014] Is there a tactic that will make use of a match statement in the goal and break the proof into cases depending on which match branch is taken? [Tue May 6 23:40:53 2014] I can do a match to find a match and destruct its argument but that breaks things down too much in my use case [Tue May 6 23:44:55 2014] I'll try to make a minimal version of my problem... [Tue May 6 23:46:16 2014] mj____: I use something like this quite a bit. http://lpaste.net/103714 [Tue May 6 23:47:00 2014] I have something similar [Tue May 6 23:47:09 2014] what does eqn:? acheive? [Tue May 6 23:47:13 2014] I don't have that [Tue May 6 23:47:26 2014] mj____: it introduces an equality that remembers which branch was taken [Tue May 6 23:47:37 2014] oh, that is very useful indeed [Tue May 6 23:47:38 2014] for example if you're matching a list. in one case you get "xs = []" [Tue May 6 23:47:45 2014] and in the other, something about cons [Wed May 7 00:22:42 2014] Another q: Why does apply fail like this? Impossible to unify "?3257 * 0 = 0" with "binopDenote b (expDenote e1_1) (expDenote e1_2) * {| this := 0; canon := canon|} = {| this := 0; canon := canon|}? [Wed May 7 00:23:58 2014] I'm using the Qcanon module. canon is a proof that 0 is a reduced (that is, canonical) rational [Wed May 7 00:24:53 2014] And {| this := _; canon := _ |} is the internal representation of canonical rationals, which is leaking out into this proof [Wed May 7 00:29:50 2014] It can't unify is 0 with {| this := 0; canon := canon |} it seems [Wed May 7 00:32:37 2014] At a higher level, I guess what I want to do is destruct rational numbers more usefully than by their internal representation [Wed May 7 00:41:59 2014] okay, I was able to eventually prove it by proving that that internal repr equals 0 [Wed May 7 00:42:05 2014] but pretty ugly [Wed May 7 00:47:22 2014] mj____: maybe your library has some nicer elimination rules for rationals [Wed May 7 00:47:33 2014] I am not familiar with Qcanon unfortunately [Wed May 7 00:54:14 2014] Thanks, that seems like it could be the right direction [Wed May 7 05:47:45 2014] Here's a puzzle for denizens of this channel (posed by neelk): prove commutativity of addition with a single induction and no lemmas [Wed May 7 11:10:31 2014] Anomaly: unknown meta ?9583. Please report. [Wed May 7 11:10:33 2014] ;_; [Wed May 7 11:11:17 2014] what should I do ... [Wed May 7 11:52:25 2014] noone here? [Wed May 7 13:26:08 2014] schoppenhauer: that happens... do something else :( [Wed May 7 13:26:32 2014] ezyang: oooh sweet :3 [Wed May 7 13:44:11 2014] Ptival: what? [Wed May 7 13:45:47 2014] Ptival: I tried to find a workaround, but ... is there any useful way of finding what actually goes wrong? [Wed May 7 13:46:05 2014] (and ... "that happens" ... for something that is used for program verification ...) [Wed May 7 13:47:33 2014] Ptival: It doesn't even happen after I proved something. It is after I started a theorem. [Wed May 7 13:48:34 2014] what does this even mean? [Wed May 7 13:57:39 2014] schoppenhauer: Coq has many bugs, so you can try to file a bug report or search the horrendous bug tracker for this issue [Wed May 7 13:57:49 2014] otherwise I'm not sure how they debug that [Wed May 7 13:59:58 2014] ok ... I'll try to update to ... trunk. [Wed May 7 14:00:07 2014] because there are a lot of bugs with this error message. [Wed May 7 14:06:25 2014] oh [Wed May 7 14:06:44 2014] do you have a small example? :\ [Wed May 7 14:16:17 2014] Ptival: I'll first try it on the git version (maybe it has been resolved already), and then I will try to get a smaller example. [Wed May 7 14:25:41 2014] ok [Wed May 7 14:54:01 2014] how can I turn on the more detailled output in coq again? [Wed May 7 15:00:15 2014] I now get a different error message, that f cannot be unified with ?..., but I have no idea what ?... should be [Wed May 7 15:01:25 2014] Unable to unify "f" with "?1202" (cannot unify "?1202" and [Wed May 7 15:01:28 2014] "f"). [Wed May 7 15:06:03 2014] ok, I tried "Set Printing All", but ... nothing helps. [Wed May 7 15:18:17 2014] ok, after messing around with it, it ... sorta works. [Wed May 7 17:09:32 2014] ezyang: is a a nat induction? :) [Wed May 7 17:15:55 2014] Ahoy. [Wed May 7 17:16:04 2014] Ptival: "a a nat"? [Wed May 7 17:16:47 2014] Hey, little question. Is it feasible to write readable tactic-based proofs in Coq? It seems like the behavior of each tactic is so context-dependent that it's not really possible to read a tactic-based proof without working through it in the prover. [Wed May 7 17:18:35 2014] Also, at the moment I have a goal of Reflexive (onLists e). I'd like to expand Reflexive, but not onLists. Is there a tactic that does that? [Wed May 7 17:19:04 2014] ezyang: sorry, I meant to write "is it a nat induction?" [Wed May 7 17:19:49 2014] Ptival: I do not know. [Wed May 7 17:19:55 2014] I guess hnf does that. [Wed May 7 17:20:14 2014] ezyang: oh you haven't solved it yet? :) [Wed May 7 17:20:28 2014] tswett: [unfold Reflexive] ? [Wed May 7 17:20:33 2014] No, I was hoping someone would tweet me the answer [Wed May 7 17:23:33 2014] ystael: that's what I was looking for. Thanks. [Wed May 7 17:28:34 2014] ezyang: do you think making an inductive family and going from (x, y) to an element of that family is fair game? :\ [Wed May 7 17:31:36 2014] I think that might be ok [Wed May 7 17:34:18 2014] Hm. So I have a relation on lists, "onLists e", which is defined inductively. I want to prove that if onLists e x y, then onLists e y x. [Wed May 7 17:34:32 2014] onLists is False if x and y have different lengths. [Wed May 7 17:34:47 2014] What I want to do is do induction on both x and y in tandem. [Wed May 7 17:35:57 2014] So that, for part of the inductive step, I get to use "onLists e (x' :: xs) (y' :: ys) -> onLists e (y' :: ys) (x' :: xs)" as an assumption. [Wed May 7 17:47:48 2014] I don't really know how to go about doing that, other than perhaps zipping x and y together. [Wed May 7 18:05:16 2014] ezyang: I feel like there might be a way to somehow shift the S's from one side of plus to the other using some new datatype and unification, but I don't know how to [Wed May 7 18:06:49 2014] Right, I can define a third list, z, that's the zipping-together of x and y, and then do induction on z. [Wed May 7 18:07:35 2014] Ptival: The problem with doing another inductive type is that you need to convert from the first evidence to your new evidence, and that constitutes an induction [Wed May 7 18:07:39 2014] Thing is, x and y are still around, and so it does induction on z independent of x and y. [Wed May 7 18:08:05 2014] ezyang: yeah [Wed May 7 18:08:37 2014] it almost feels like there is a way to prove that this riddle is not solvable :D [Wed May 7 18:08:48 2014] but I assume it is :( [Wed May 7 18:12:03 2014] help, how do i do weird induction [Wed May 7 18:15:43 2014] tswett: are you working on the riddle? [Wed May 7 18:23:57 2014] Ptival: no, I'm working on my own thing. [Wed May 7 18:26:48 2014] Given an equivalence relation e, I'm saying that two lists are equivalent according to "onLists e" if and only if the lists are the same length and corresponding elements are equivalent. [Wed May 7 18:26:56 2014] Now I'm trying to prove that this new relation is also an equivalence relation. [Wed May 7 18:27:24 2014] Reflexivity wasn't too hard to prove, but symmetricity is different. [Wed May 7 18:34:54 2014] tswett: I proved symmetry without too much trouble. what exact definition of onLists are you using? [Wed May 7 18:37:27 2014] jrw: lemme paste some stuff. [Wed May 7 18:40:35 2014] http://lpaste.net/103778 - my definition, and my attempt at proving symmetry. [Wed May 7 18:44:14 2014] jrw: as you can see, using "induction x" doesn't work; I end up being asked to prove the wrong thing. [Wed May 7 18:45:03 2014] tswett: why do you think that's the wrong thing? [Wed May 7 18:46:10 2014] jrw: well, we have lists x and y. I'm being asked to prove that if "onLists e" is symmetric for x and y, then it's symmetric for (a0 :: x) and y. [Wed May 7 18:46:24 2014] But if x and y have the same length, then (a0 :: x) and y do not have the same length. [Wed May 7 18:46:35 2014] tswett: oh, don't intros first [Wed May 7 18:46:42 2014] you need to induct on x leaving y general [Wed May 7 18:46:49 2014] Ahh. [Wed May 7 18:46:59 2014] That sounds about right. Let me try that. [Wed May 7 18:50:23 2014] Yeah, this seems to be working. Thanks. [Wed May 7 18:50:28 2014] np [Wed May 7 18:57:51 2014] All right. Let's see if I can finally prove this entire theorem now. [Wed May 7 19:02:43 2014] Now something I'd like to do is to unfold onLists by one step only. [Wed May 7 19:04:26 2014] Apparently simpl does that. [Wed May 7 19:19:38 2014] dependent [Wed May 7 19:19:56 2014] ^ sorry, disregard [Wed May 7 19:36:25 2014] I notice that if I look at the type of Equivalence_Reflexive, it seems to give me some arbitrary equivalence relation as the relation that it's for. [Wed May 7 19:36:53 2014] Like its implicit parameter is something that looks in the surrounding scope and grabs whatever looks right. [Wed May 7 19:57:44 2014] * ponders whether or not he wants to include a readable proof that the always-true relation is an equivalence relation. [Wed May 7 19:57:47 2014] The proof is really boring. [Wed May 7 19:58:42 2014] maybe one of the auto tactics is sufficient? [Wed May 7 19:58:54 2014] Proof. auto. Qed. is very readable :) [Wed May 7 19:59:05 2014] or tauto, intuition, whatever [Wed May 7 20:00:20 2014] auto is just barely insufficient. [Wed May 7 20:00:33 2014] The required proof is "constructor. auto. auto. auto." [Wed May 7 20:00:50 2014] tried tauto? [Wed May 7 20:01:46 2014] Well, I'm trying to prove something of the form "Equivalence r". The "tauto" tactic can't break through Equivalence. [Wed May 7 20:02:34 2014] intuition maybe then. gotta try 'em all! [Wed May 7 20:02:40 2014] it's the Coq way [Wed May 7 20:02:51 2014] When in doubt, use a bunch of automatic tactics. [Wed May 7 20:03:00 2014] yes! [Wed May 7 20:03:34 2014] Lemme look at the hint commands. [Wed May 7 20:03:40 2014] Maybe instead of providing a proof, I can just declare a hint. [Wed May 7 20:03:48 2014] btw that can also be your life philosophy [Wed May 7 20:04:18 2014] Need a job? Type "I need a job" into Google and hope for the best. [Wed May 7 20:04:30 2014] worked for me! [Wed May 7 20:06:19 2014] i believe there's something like Hint Constructors bla. [Wed May 7 20:07:48 2014] Yeah, "Local Hint Constructors Equivalence : core" made the proof go away. [Wed May 7 20:11:46 2014] Huh, reflexivity solved something that auto couldn't. [Wed May 7 20:21:15 2014] this is why you have to try them all: it is unpredictable which ones will bring you success [Wed May 7 20:21:30 2014] Maybe there should be a tactic that automatically tries all automatic tactics. [Wed May 7 20:21:33 2014] "autoauto" [Wed May 7 20:22:01 2014] let's call it HAL [Wed May 7 20:22:55 2014] "trivial" is also a nice one [Wed May 7 20:23:02 2014] and congruence [Wed May 7 20:23:34 2014] the best thing about tactics that automatically pick tactics for you is that there's so many of these tactics to pick from! [Wed May 7 20:37:50 2014] I'm starting to feel like it's best to use "Theorem" for complicated proofs and "Definition" for simple ones. [Wed May 7 20:38:16 2014] A very short proof that uses "exact" a couple of times seems like an ugly proof. [Wed May 7 21:23:06 2014] Woo, I've defined a couple of monoids. [Wed May 7 22:21:58 2014] What happened to the 'dependent induction' tactic? [Thu May 8 00:28:16 2014] Eh, isn't there some tactic that, if the goal is a record type, creates a subgoal for each of the fields? [Thu May 8 00:30:45 2014] "eapply" with the constructor does it, I guess. [Thu May 8 10:42:09 2014] how can i define a "partial order" type which is a couple "set,relation" such that the relation is reflexive transitive antisymmetric? [Thu May 8 10:48:53 2014] eizo check out the Classes/RelationClasses.v library. There's a partial order typeclass. [Thu May 8 10:53:46 2014] Class PartialOrder {A} eqA `{equ : Equivalence A eqA} R `{preo : PreOrder A R} [Thu May 8 10:54:07 2014] how do i use it? [Thu May 8 10:55:12 2014] Program Instance your_partialorder_name : PartialOrder your_eqv_rel your_preorder. [Thu May 8 10:56:29 2014] http://pastie.org/9155982 [Thu May 8 10:57:15 2014] in the end i want a type Hist which the set of labeled posets (over some arbitrary set, or say over N for simplicity, i don't know which is simpler) [Thu May 8 10:57:26 2014] posets labeled by "I" [Thu May 8 10:58:44 2014] I don't understand this paste. [Thu May 8 10:58:52 2014] ianjneu: that would be for defining a particular partial order [Thu May 8 11:00:04 2014] ianjneu: line 8 i want to say that I is the cartesian product of sets M and D, line 10, i want to define the type "Poset", and line 12 i want to say Hist has elements composed of a partial order, alongside a labeling function [Thu May 8 11:07:08 2014] Hello. [Thu May 8 11:07:30 2014] Hello. [Thu May 8 11:11:53 2014] morning [Thu May 8 11:15:30 2014] does this make sense? http://pastie.org/9156050 [Thu May 8 11:15:56 2014] how do i extend this to restrict the "relation Element" to be a partial order? [Thu May 8 11:32:24 2014] i have a definition Definition blah : type_of_blah. why can't i use blah in an another definition? i'm getting "blah was not found in the current environment"; [Thu May 8 11:33:40 2014] eizo: you never defined it. [Thu May 8 11:33:50 2014] ianjneu: i admitted it [Thu May 8 11:33:57 2014] When? [Thu May 8 11:34:18 2014] your pastes don't have "Admitted." [Thu May 8 11:34:31 2014] ianjneu: http://pastie.org/9156142 [Thu May 8 11:34:36 2014] blah is "false_hists" [Thu May 8 11:35:16 2014] hm i guess i should replace admit by Admitted [Thu May 8 11:41:50 2014] thanks [Thu May 8 12:22:12 2014] how can i apply a forall or implication hypothesis to another hypothesis? [Thu May 8 12:22:18 2014] Hello, what theory lies behind http://qandwhat.apps.runkite.com/i-failed-a-twitter-interview/ task? I want to build proven solution to this problem in coq [Thu May 8 12:33:58 2014] if i have H: A -> B and X: A in my hypothesis, in order to get B, should i assert(B); apply H? [Thu May 8 12:36:14 2014] and when i have H : Exists t -> ... how can i get such a t as a hypothesis? [Thu May 8 13:31:34 2014] Now I'd like to prove that two values of record types are equal by proving that their fields are equal. [Thu May 8 13:31:39 2014] Is there a nice way to do that? [Thu May 8 13:38:49 2014] tswett: there's a tactic f_equal that might do what you want [Thu May 8 13:47:37 2014] given hypothesis g(x) = t and x = f(y) how to solve the goal g(f(y)) = t [Thu May 8 13:48:11 2014] subst x [Thu May 8 14:04:36 2014] thanks [Thu May 8 14:13:19 2014] how to change a whole expression in the goal by another expression which is equal by hypothesis? [Thu May 8 14:19:59 2014] I think that's "replace (first expression) with (second expression)". [Thu May 8 14:20:14 2014] That's one way to do it, at least. [Thu May 8 14:38:34 2014] thanks [Thu May 8 19:33:25 2014] Is there a way to clear out the default hint database? [Thu May 8 19:34:35 2014] there's -nois, closest i can think of [Thu May 8 19:35:02 2014] ugh, I don't really want to do that [Thu May 8 19:38:56 2014] ugh, even if I use a different hint database, it looks like core is still used [Thu May 8 19:42:28 2014] i wonder how much hassle it would be to use -nois in a big Coq project [Thu May 8 19:42:41 2014] probably not much [Thu May 8 19:49:59 2014] I mean, there's nocore, right? [Thu May 8 19:50:18 2014] If you can specify an alternative database to use, can't you also specify that core should not be used? [Thu May 8 19:55:59 2014] Hm, is there a way to specify -nois from the source file? [Thu May 8 19:57:05 2014] oh this is so terrible http://comments.gmane.org/gmane.science.mathematics.logic.coq.club/2800 [Fri May 9 10:22:35 2014] given a set A : Set, how do i define the subsets of A? [Fri May 9 10:41:39 2014] eizo_: depends on what kind of subsets you want [Fri May 9 10:41:45 2014] A->Prop is a good start [Fri May 9 10:42:00 2014] hm yes [Fri May 9 12:39:53 2014] Parameter A B: Set. Definition I := A * B. why does this fail, but Definition I := prod A B works? [Fri May 9 12:44:48 2014] Definition I := (A * B)%type. [Fri May 9 12:45:57 2014] rks`: thanks, but why? [Fri May 9 12:47:51 2014] * == prod in the type scope, in the term/expression/what's-the-name scope it is a notation for mult : nat -> nat -> nat I'm guessing [Fri May 9 12:48:27 2014] ok i see [Fri May 9 14:13:55 2014] Hello. [Fri May 9 14:14:02 2014] morning [Fri May 9 14:14:38 2014] Am I right that it is impossibly to prove "((forall x, D x) -> False) -> (exists x, (D x -> False))"? [Fri May 9 14:14:48 2014] Is it possible to do with excluded_middle? [Fri May 9 14:14:59 2014] yes and yes [Fri May 9 14:18:16 2014] Eelis, I am just trying to prove drinker's paradox, but I thought that it uses ex_middle only once in the proof. [Fri May 9 14:18:44 2014] oh, maybe i'm wrong [Fri May 9 14:19:01 2014] Eelis, intuitevely I think that you are right [Fri May 9 14:19:09 2014] what is the type of x? [Fri May 9 14:19:18 2014] Eelis, any {X} [Fri May 9 14:19:59 2014] {X} {D : X -> Prop} (f : (forall x, D x) -> False) : exists x, (D x -> False) [Fri May 9 14:21:43 2014] yeah that's provable with excluded middle [Fri May 9 14:22:56 2014] http://codepad.org/rZb4Cs7x [Fri May 9 14:26:48 2014] why can't i use tabs to indent proofs? should i use emacs instead of coqide? [Fri May 9 14:27:48 2014] eizo, I guess that most of guys here use emacs for Coq. [Fri May 9 14:27:58 2014] Eelis, you are fast; I am still trying. [Fri May 9 14:29:42 2014] eizo: I find proof general much more functional than CoqIDE, but I use Emacs for everything else [Fri May 9 14:30:02 2014] If you're not already an emacs user and CoqIDE is working for you, there may not be a reason to switch [Fri May 9 14:30:44 2014] Eelis, oh, or I just tried to prove wrong expression (maybe I confused brackets). [Fri May 9 14:31:19 2014] * uses coqide [Fri May 9 14:34:31 2014] hm i like this emacs autoindent [Fri May 9 14:36:59 2014] how does it indent proofs? [Fri May 9 14:38:22 2014] just by two spaces, but you can type tab wherever on the line and it will indent it correctly; also si you're in a proof with 4 indents, it will keep 4 spaces for the next line [Fri May 9 14:38:42 2014] any editor would do that, but they don't have coq integrated [Fri May 9 14:38:46 2014] oh, thought you meant a coq-specific autoindent, not just "copy the previous line's indentation" [Fri May 9 14:39:23 2014] Where I can find overview of ConCaT? It's category theory contribution for Coq. [Fri May 9 14:39:56 2014] never heard of it [Fri May 9 14:40:09 2014] I heard that it uses multiple copies of the same file for some reason and want to make sure/understand why. [Fri May 9 14:40:23 2014] there are lots of category theory Coq developments [Fri May 9 14:40:24 2014] Eelis, I guess that it is that one: http://coq.inria.fr/pylons/contribs/view/ConCaT/v8.4 [Fri May 9 14:41:00 2014] i think that one may be very old. it probably doesn't use Coq's modern features [Fri May 9 14:42:35 2014] Rc43: one reason you sometimes used to have to copy stuff in Coq was because it didn't support universe polymorphism very well. i think nowadays the support is much better [Fri May 9 14:44:05 2014] Eelis, may be this is the reaason; I heard about that workaround with files in ConCat exact in discussion of HoTT and how does it make proofs simpler. [Fri May 9 14:45:23 2014] i didn't understand the grammar in that last part [Fri May 9 14:53:52 2014] Eelis, there was discussion between me and one guy. I was interested in HoTT applications and that guy said me that one of applications is category theory. And he said about that workaround with files in ConCaT. [Fri May 9 14:56:09 2014] well, HoTT is what's spurring the improvements in universe polymorphism support, for example [Fri May 9 14:56:14 2014] so yeah, that's related [Fri May 9 14:57:39 2014] Eelis, yep [Fri May 9 14:58:17 2014] But as I understand here we needn't all power of HoTT, agda has universe polymorphism as I know [Fri May 9 14:58:54 2014] "some form of universe polymorphism, would be nice" http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.UniversePolymorphism doesn't sound like it, unless it's new [Fri May 9 14:59:11 2014] Hmmm [Fri May 9 14:59:28 2014] Maybe I don't know what is universe polymorphism. [Fri May 9 14:59:49 2014] I thought that it is something like "forall l, X : Set l". [Fri May 9 15:00:16 2014] no [Fri May 9 15:00:16 2014] It seems that this page is just old. [Fri May 9 15:00:32 2014] > Page last modified on December 27, 2009 [Fri May 9 15:00:47 2014] ah indeed http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.UniversePolymorphism [Fri May 9 15:01:04 2014] next question: do they mean the same by universe polymorphism as the coq people? ^_^ [Fri May 9 15:01:28 2014] Yeah :) [Fri May 9 15:01:52 2014] Also, "Universe levels are no longer defined as a data type" -- seems that I tried agda right before this change. [Fri May 9 15:02:02 2014] in any case, i certainly wasn't saying you needed HoTT for universe polymorphism. if anything, i'd guess the opposite is more likely true [Fri May 9 15:02:18 2014] And maybe now it is made without "forall l, Set l". [Fri May 9 15:43:32 2014] is the book Software Foundation ok for learning more about coq? [Fri May 9 15:53:17 2014] eizo yes. [Fri May 9 15:56:27 2014] ok i'll have a look [Fri May 9 16:13:39 2014] how can i use a hypothesis like "1 = 0" to prove false? [Fri May 9 16:21:23 2014] discriminate [Fri May 9 16:21:46 2014] eizo: ^ [Fri May 9 16:25:47 2014] cool thanks [Fri May 9 16:48:01 2014] heh, i just read about the new "primitive projections". i guess Coq got /another/ kind of implicit argument, hurray! [Fri May 9 16:48:08 2014] how many do we have now, 4? [Fri May 9 16:48:24 2014] what's a primitive projection? [Fri May 9 16:48:33 2014] i don't know more than what's in CHANGES [Fri May 9 16:50:43 2014] it's also not clear to me whether it's just sugar or truly primitive [Fri May 9 16:51:59 2014] they put it under "Logic", after all [Fri May 9 17:10:07 2014] Eelis: It's truely primitive (as in, in the kernel). The primary purpose is to speed up handling of things like sigma types, because arguments to primitve projections don't show up in the term. (They also provide judgmental eta for records.) Also, Coq 8.5 will have universe polymorphism (but probably not any explicit universe level type). [Fri May 9 17:15:27 2014] jgross i guess it is for hott ? [Fri May 9 17:16:15 2014] It was developed for HoTT. It's useful even without HoTT. [Fri May 9 17:20:54 2014] jgross i hope to see what hott will provide in 2014 ! [Fri May 9 17:24:01 2014] Anarchos: http://math.andrej.com/2014/05/06/brazilian-type-checking/ [Fri May 9 17:24:51 2014] Unless you mean "I hope that HoTT will provide me things in 2014, and I won't have to wait for 2015", in which case, me too. [Fri May 9 17:25:04 2014] jgross will look :) [Fri May 9 17:25:23 2014] jgross i just wait for the computational interperation of the ua axiom :) [Fri May 9 17:31:18 2014] Anarchos: There's a cubical sets evaluator that's computational. [Fri May 9 17:34:15 2014] Maxime Dénès recently managed to prove False again (this time in trunk): https://coq.inria.fr/bugs/show_bug.cgi?id=3300#c3 [Fri May 9 17:44:02 2014] jgross i thougt vladimir was still looking for a computational interpretation of ua ? [Fri May 9 17:56:00 2014] Anarchos: There are some subtleties. E.g., the J computation rule is propositional and not judgmental in cubical sets, so you can't actually compare it with Coq/MLTT, strictly speaking. And it's not known how to compute directly, nor if terms compute to the same thing in all models. [Fri May 9 17:59:35 2014] jgross: but could a development that uses primitive projections be rewritten to not use them? [Fri May 9 18:00:54 2014] anyway, feels hacky to me [Fri May 9 18:02:33 2014] then again pretty much everything to do with records in Coq seems hacky [Fri May 9 18:12:20 2014] Eelis: Not if it uses judgmental eta for records with primitive projections. [Fri May 9 18:12:39 2014] ah, i see [Fri May 9 18:18:49 2014] also, cool link, thanks [Fri May 9 18:19:08 2014] (first one) [Sat May 10 12:01:58 2014] If I'm proving something like this, is there a way to break up the proof into cases based on what smartPlus returns (and what that tells about the arguments) rather than by destructuring e1 and e2? forall e1 e2, expDenote (smartPlus e1 e2) = expDenote (Binop Plus e1 e2). [Sat May 10 12:02:27 2014] smartPlus's body is a match statement on e1 and e2 [Sat May 10 12:02:37 2014] s/statement/expression [Sat May 10 12:03:47 2014] While I can break down the proof based on how e1 and e2 is inductively defined, it would be much more natural to break it down based on which match branch is taken within smartPlus [Sat May 10 12:16:50 2014] magnus____: apply induction to smartPlus e1 e2? [Sat May 10 12:17:13 2014] Or just destruct it or whatever [Sat May 10 12:50:03 2014] That gives me the right goal, but it doesn't infer any info about e1 and e2 based on what smartPlus returned [Sat May 10 12:50:19 2014] which should come from which match branch was taken in smartPlus [Sat May 10 12:51:54 2014] oh, right, you might want something like... what was it called... [Sat May 10 12:52:33 2014] let's say I have a goal like forall a. a = b -> c, and I can use intros followed by rewrite to solve the goal. Is there a way to apply the rewrite "under the forall" so that I don't have to use intros? [Sat May 10 12:52:51 2014] case_eq [Sat May 10 12:53:39 2014] magnus____: ^^ [Sat May 10 12:53:42 2014] Very interesting :) [Sat May 10 12:55:43 2014] lispy: I'm not sure that'll always make sense, because the things you're rewriting might involve the variables bound by intros, no? [Sat May 10 12:55:57 2014] lispy: Is it sufficient just to revert the variables after? [Sat May 10 12:56:42 2014] lispy: maybe this: intro as A; rewrite A [Sat May 10 12:57:31 2014] that at least avoids having to know the name after introducing the hypothesis [Sat May 10 12:57:45 2014] I should have said, I don't need to do this. I just started playing with avoiding intros and seeing which tactics could still be used. [Sat May 10 12:58:07 2014] I know that intros roughly corresponds to creating a lambda [Sat May 10 14:15:08 2014] Hello. [Sat May 10 14:16:14 2014] Suppose, I have hypothesis, which looks like "yh' := f yh : list nat". How to rewrite other expression with it? [Sat May 10 14:16:39 2014] I can't use "rewrite", because its type "list nat", buut not equality. [Sat May 10 14:16:52 2014] I can use "assert", I guess. But that is not very convinient. [Sat May 10 14:18:50 2014] Rc43: what does this hypothesis say? [Sat May 10 14:19:51 2014] eizo, that I have variable yh' which is by definition equal to image of "f" on "yh". [Sat May 10 14:19:52 2014] But I need usual propositional equality instead of eq-y by definition. [Sat May 10 14:20:35 2014] why does it have type "list nat"? [Sat May 10 14:20:37 2014] "assert (yh'Eq : yh' = f yh) by auto" solves the problem; but it isn't very good solution, I think. [Sat May 10 14:20:59 2014] eizo, because it is variable of that type; function f is of type "ist nat -> list nat". [Sat May 10 14:45:05 2014] Rc43: try zeta reduction. [Sat May 10 14:48:00 2014] ianjneu, which tactic? Just "zeta" doesn't work. [Sat May 10 14:51:28 2014] Oh, "cbv zeta". [Sat May 10 14:52:13 2014] "cbv zeta in T" doesn't work, can I point my yh' hypothesis to it? [Sat May 10 14:55:16 2014] well I know subst yh' works, but you won't keep the yh' binding in the context. [Sat May 10 14:58:29 2014] ianjneu, seems that I need "backward" subst. [Sat May 10 14:58:59 2014] ianjneu, not "a + b + c -> a + + c", but backward [Sat May 10 15:17:02 2014] Rc43: use the change tactic. [Sat May 10 15:26:08 2014] ianjneu, it does what I want; thanks [Sat May 10 15:26:39 2014] Though requires little bit verbous writing (change with yh' in T1.). [Sat May 10 15:32:17 2014] Is there fast equivalent to "remember as T; clear HeqT."? [Sat May 10 15:34:02 2014] If not can I construct it with Ltac? I don't know how to bind T agrument from "as T", because it doesnseems [Sat May 10 15:34:12 2014] *doesn't seem to be argument of tactic [Sat May 10 15:35:37 2014] Ah, passing T as parameter isn't a problem; but I can't do "clear HeqT" inside Ltac expression (it doesn't see the hypothesis). [Sat May 10 15:37:12 2014] Oh, just "Ltac rem exp name := remember exp as name eqn:T; clear T." [Sat May 10 15:37:36 2014] But I guess that T can be binded with hypothesis from outside =/ [Sat May 10 17:11:42 2014] Am I right that (a + b) - c = a + (b - c)? [Sat May 10 17:11:48 2014] I can't prove =/ [Sat May 10 17:15:15 2014] Oh, thats wrong. [Sat May 10 18:12:12 2014] Rc43: why? [Sat May 10 18:12:50 2014] eizo, for natural numbers (I forgot to add that) [Sat May 10 18:12:55 2014] eizo, because if c > b then (b - c) = 0 [Sat May 10 18:13:08 2014] oh ok [Sat May 10 18:13:42 2014] i want to define a polymorphic record R { Blah } := ..., and then write a function taking some r : R { Blah } and b : Blah; what is the syntax for writing such a function? [Sat May 10 18:14:11 2014] eizo, what do you mean by "polymorphic"? [Sat May 10 18:14:20 2014] eizo, as I understand your task it is type class [Sat May 10 18:14:33 2014] there is manual about that [Sat May 10 18:15:31 2014] Rc43: http://pastie.org/9163545 [Sat May 10 18:18:30 2014] what do you call an endomorphic catamorphism? [Sat May 10 18:19:00 2014] ie expFold (f : exp -> exp) : exp -> exp where f is applied on backing out of the recursion [Sat May 10 18:22:11 2014] eizo, "relation" is something standard? [Sat May 10 18:22:22 2014] eizo, could you give me lines for import? [Sat May 10 18:23:07 2014] eizo, btw your syntax at definition looks wrong [Sat May 10 18:23:31 2014] eizo, if you want to provide implicit parameter you should write not "something {arg}", but "@something arg". [Sat May 10 18:23:45 2014] eizo, @ makes all implicit arguments to be explicit [Sat May 10 18:24:22 2014] eizo, maybe that was your problem [Sat May 10 18:24:32 2014] Rc43: Require Import Relations and I is some Set [Sat May 10 18:25:22 2014] Rc43: Record @Hist Element? that doesn't parse [Sat May 10 18:25:41 2014] eizo, no-no-no :) [Sat May 10 18:25:50 2014] eizo, not in Record; in Definition. [Sat May 10 18:26:32 2014] Rc43: i finally wrote it like that: http://pastie.org/9163562 that way i can access the Domain of the Hist within the field [Sat May 10 18:26:33 2014] When you declare that "x" is implicit argument, you write "{x}"; when you want to provide implicit argument for something you should convert function with @ [Sat May 10 18:27:20 2014] So, you should write "Definition f {Element} (h : @Hist Element) ..." in your first paste. [Sat May 10 18:28:33 2014] Rc43: that means a Hist whose implicit type parameter is Element? [Sat May 10 18:28:53 2014] eizo, yep [Sat May 10 18:29:41 2014] eizo, but be careful with @, because it converts all implicit arguments into expllicit; not only first [Sat May 10 18:32:48 2014] works perfect thanks [Sat May 10 18:36:33 2014] Rc43: now almost everytime i write a function with some Hist, i have to put Element explicitely it's a bit annoying [Sat May 10 18:39:28 2014] eizo, yep, it's not very convinient if you are trying to make all possible arguments implicit. Make arguments explicit if you have to point them manually frequently. [Sat May 10 18:40:06 2014] Try to make implicit only that what can be inferred by Coq in most of cases. [Sat May 10 18:40:56 2014] making the parameter explicit for the record would mean putting it inside the record? [Sat May 10 18:41:46 2014] eizo, not necessary, I will try now, but I guess that you can just remove { and }, maybe you need annotate type manuall too [Sat May 10 18:43:08 2014] eizo, ye, you need to place type annotation; e.g. Record R (T : Set) := mk_R { ... }. [Sat May 10 18:46:32 2014] make sense thanks [Sat May 10 19:05:13 2014] How to rewrite only first place? [Sat May 10 19:07:03 2014] "rewrite at 1" doesn't work. [Sun May 11 00:03:16 2014] Is there a version of match that produces evidence of equality of the input and matched terms? [Sun May 11 01:04:21 2014] Ah, http://coq.inria.fr/refman/Reference-Manual026.html describes a rewrite that does the trick [Sun May 11 08:57:01 2014] Hello. [Sun May 11 08:57:21 2014] I can't understand how to propogate information about equalities. [Sun May 11 08:58:02 2014] match xs with xh :: xt => (fun (p : eq xs (xh :: xt)) => ...) eq_refl end [Sun May 11 08:58:05 2014] How to do it? [Sun May 11 09:01:02 2014] I would consult CPDT, but it meets me with huge red-black tree example. [Sun May 11 09:01:09 2014] Is there small example? [Sun May 11 09:30:08 2014] Ah, old mail from Gabriel Scherer gives small example. [Mon May 12 08:22:39 2014] Hello. [Mon May 12 08:22:49 2014] Can I apply tactic to every hypothesis in context? [Mon May 12 08:23:53 2014] I tried Ltac with "repeat" and "match" but can't do it because my tactic can fail, so I need to wrap it with "try"; therefore my repeat can't exit the loop. [Mon May 12 08:28:26 2014] Rc43: check 'fail 1' [Mon May 12 08:29:48 2014] ezyang, hmm, tricky [Mon May 12 08:29:58 2014] ezyang, I need some time to understand it; but looks fine [Mon May 12 08:30:45 2014] http://adam.chlipala.net/cpdt/html/Match.html also has a discussion of this and other ltac tricks [Mon May 12 08:34:59 2014] ezyang, ah yeah; I glanced at it but didn't read the whole [Mon May 12 08:35:12 2014] ezyang, now I know that I need to search "fail 1" on it; thanks [Mon May 12 10:36:20 2014] what should I add to my program to enable list and string syntax? [Mon May 12 10:37:46 2014] I opened list and string scopes but list syntax still doesn't work [Mon May 12 11:01:14 2014] osa1: You need to Require Import Coq.Lists.List. Import Coq.Lists.List.ListNotations. [Mon May 12 11:07:50 2014] ystael: I was already trying that but I'm getting this Cannot find library Coq.Lists.List.ListNotations in loadpath [Mon May 12 11:09:25 2014] do I need to update my Coq? I have 8.4pl2 [Mon May 12 11:09:53 2014] ListNotations is a submodule of Coq.Lists.List [Mon May 12 11:10:00 2014] note, it is "Import" not "Require Import" for the second one [Mon May 12 11:10:19 2014] okay now it works, thanks [Mon May 12 11:10:34 2014] how are they different? Require Import and Import? [Mon May 12 11:11:46 2014] "Require" is "load a module from filesystem"; "Import" is "open a loaded module"; "Require Import" is "do both" [Mon May 12 19:20:09 2014] There is no well_founded relation for product in the library? [Mon May 12 19:21:01 2014] I mean, given A B and < on A and < on B, which are w.f. < on A*B is w.f. too. [Mon May 12 19:24:45 2014] Oh, seems that it is lexprod =/ [Mon May 12 19:56:06 2014] How to make module local? [Mon May 12 19:56:12 2014] I.e. without exporting it outside. [Mon May 12 20:00:10 2014] Manual says that I have to use "Require Export Module", if I want to make it visible by default. By somehow it is already visible for me. [Mon May 12 20:04:01 2014] Or maybe it is possible to make section local? [Tue May 13 14:01:42 2014] how can i make this typecheck? Definition comp (T: Type) (A B: Set) (p: A = B) (f: T -> A) (g: T -> B) := forall t, f t = g t. [Tue May 13 14:01:45 2014] (using p) [Tue May 13 14:56:36 2014] soso: maybe you're looking for eq_rect, aka transport [Tue May 13 15:10:18 2014] forall (A : Type) (x : A) (P : A -> Type), P x -> forall y : A, x = y -> P y [Tue May 13 15:13:10 2014] trying to make sense of that [Tue May 13 15:41:36 2014] jrw: i wasn't able to apply it to my example [Tue May 13 15:43:02 2014] if i want to make that typecheck: Definition comp (T: Type) (X Y: Set) (p: X = Y) (f: T -> X) (g: T -> Y) := forall t, f t = g t. [Tue May 13 15:43:53 2014] i guess i have to use eq_rect (signature above) with A = Set, x = X [Tue May 13 15:44:47 2014] but whenever i start writing eq_rect Set X i get a type error [Tue May 13 17:50:54 2014] soso: still stuck? [Tue May 13 17:52:10 2014] Eelis: finally i got it by making a proof and printing it; it makes sense now, thanks [Tue May 13 17:52:34 2014] the proof was just "rewrite <- p. assumption", and it generated a proof term with "eq_rec" [Tue May 13 17:53:23 2014] right, and the reason typing "eq_rect Set X" didn't work was because some of eq_rect's arguments are implicit [Tue May 13 17:54:24 2014] Eelis: yes looks like the first forall (A : Type) [Tue May 13 17:54:35 2014] is there a way in general to know which are implicits? [Tue May 13 17:55:14 2014] About thing. mentions which of thing's parameters are implicit [Tue May 13 17:58:46 2014] nice thanks [Wed May 14 02:16:34 2014] I don't understand the 'destruct' tactic. As I understand it now, it's like 'inversion' except that it loses information sometimes. [Wed May 14 02:17:22 2014] Here's an example where inversion works but destruct generates a result that's too weak to complete the proof. http://lpaste.net/104119 [Wed May 14 02:17:32 2014] What does destruct do? [Wed May 14 02:24:13 2014] destruct is a simplified version of induction [Wed May 14 02:24:31 2014] The full answer is, "It's complicated", but it comes down to the fact that in order to do induction, you need to calculate a "motive" for it [Wed May 14 02:25:07 2014] This might help http://web.mit.edu/~ezyang/Public/motive/motive.html [Wed May 14 02:33:53 2014] hmm... [Wed May 14 02:50:09 2014] I see that there's a free type in the early examples representing the conclusion from eliminating a first-order nonrecursive constructor. More generally, the conclusion type can depend on the argument values of the type constructor being eliminated. [Wed May 14 02:51:39 2014] Does destruct assume the conclusion's type is invariant? [Wed May 14 02:53:24 2014] I'm not sure what you mean. [Wed May 14 02:53:40 2014] But I think the answer is, "It all has to do with how the unification algorithm works" [Wed May 14 02:55:20 2014] Hmm, okay [Wed May 14 02:56:42 2014] I don't really get it, but I can work around it. [Wed May 14 02:58:37 2014] When you get a chance, try doing some inductive proofs by hand [Wed May 14 02:58:50 2014] that is, without the 'induction' tactic, but by manually calling the relevant *_ind function [Wed May 14 02:59:46 2014] Do you have any proofs in mind? [Wed May 14 03:00:06 2014] * is currently writing merge sort in Coq because it seemed like a good thing to practice [Wed May 14 03:00:17 2014] Well, I'm writing lemmas about sorted lists now. [Wed May 14 03:00:41 2014] It doesn't matter. Maybe start with some facts about natural numbers [Wed May 14 03:22:07 2014] heatsink: it's basically as you put it yeah, destruct does case analysis after generalizing all the type indices [Wed May 14 03:22:21 2014] while inversion does its best to save all the indices as equations [Wed May 14 12:52:03 2014] "Error: Applied theorem has not enough premisses. [Wed May 14 12:52:05 2014] " [Wed May 14 12:52:07 2014] what does this even mean? [Wed May 14 12:53:45 2014] it makes no sense. [Wed May 14 12:53:59 2014] how can a theorem not have enough premisses? [Wed May 14 12:57:14 2014] schoppenhauer: you're probably trying to apply a theorem with p premisses to a goal with q premisses where p < q? [Wed May 14 12:57:37 2014] but it's weird that it doesn't default to some behavior [Wed May 14 13:04:54 2014] well. I gave up for today. [Wed May 14 13:13:33 2014] hm. [Wed May 14 13:13:37 2014] ok, I only gave up shortly. [Wed May 14 13:13:50 2014] Ptival: what is a "premis" in this case? [Wed May 14 13:14:09 2014] I only have closed proofs of stuff. [Wed May 14 13:17:48 2014] a premise a something left of -> [Wed May 14 13:26:35 2014] http://lpaste.net/104143 [Wed May 14 13:26:46 2014] ianjneu, Ptival: http://lpaste.net/104143 ← minimal error. [Wed May 14 13:28:47 2014] I don't really see the problem. [Wed May 14 13:31:35 2014] why am I always making mistakes when pasting code ... [Wed May 14 13:34:31 2014] http://lpaste.net/104143 ← more like it [Wed May 14 13:37:46 2014] ok ... + binds stronger that -> [Wed May 14 13:37:48 2014] one error. [Wed May 14 13:37:55 2014] schoppenhauer: the thing you try to apply has type (_ + _) [Wed May 14 13:38:14 2014] and the goal has type ((_ + _) -> _) [Wed May 14 13:45:07 2014] ok. [Wed May 14 13:45:16 2014] still ... not a helpful error message. [Wed May 14 13:45:25 2014] but thx. got it now. [Wed May 14 18:00:18 2014] Anyone used coq for reasoning about formal grammars consistency and ambiguity? [Wed May 14 19:53:55 2014] Don't you love it when you can do proofs like this: [Wed May 14 19:53:57 2014] comp_Arrows_is_assoc := fun _ _ _ _ _ _ _ => eq_refl [Wed May 14 19:57:14 2014] tswett: What exactly that statement means? I'm still learning the very basics. [Wed May 14 19:58:05 2014] Well, it defines comp_Arrows_is_assoc as a function that takes seven arguments, ignores them, and returns eq_refl. [Wed May 14 19:59:54 2014] Meanwhile, eq_refl has the type a = a for all a. [Wed May 14 20:03:42 2014] So the function is supposed to check if all arguments are the same or..? [Wed May 14 20:04:07 2014] Well, are you familiar with the purpose of Coq? [Wed May 14 20:04:46 2014] Coq is an automated proof verifier; you give it proofs written in computer language and it verifies that they're correct. fun _ _ _ _ _ _ _ => eq_refl is a proof. [Wed May 14 20:05:11 2014] Well, you should probably give the type signature, or else it's not clear which proof that is [Wed May 14 20:05:14 2014] It's a proof that two things are equal. Just by looking at it, you can't see what, exactly, it's proving to be equal. [Wed May 14 20:05:17 2014] Familiar with the purpose, but still struggling with the syntax. [Wed May 14 20:06:04 2014] In this case, it happens to be a proof that compose f (compose g h) = compose (compose f g) h. [Wed May 14 20:11:30 2014] Little question: given "Inductive Bloop : Prop := {a : Bloop; b : Bloop}.", can we prove that a <> b? [Wed May 14 20:14:37 2014] I guess that's the wrong definition. Shrug. [Wed May 14 20:53:22 2014] tswett: Given function extensionality, I can prove a = b [Wed May 14 20:54:03 2014] (by first proving not Bloop) [Wed May 14 20:55:27 2014] tswett: http://lpaste.net/104156 [Thu May 15 10:19:02 2014] how can one proof that eq ~= eq_refl x forall eq : x = y? (this should hold, since UIP holds) [Thu May 15 10:22:41 2014] It's an inductive type. You can match an eq term against eq_refl. [Thu May 15 10:23:49 2014] It's not clear to me what part of that isn't true by definition. [Thu May 15 10:27:16 2014] heatsink: so ... how do I derive it? [Thu May 15 10:30:22 2014] schoppenhauer: Apply UIP? [Thu May 15 10:30:35 2014] Cale: where is UIP? [Thu May 15 10:30:40 2014] schoppenhauer: It's not a theorem [Thu May 15 10:30:46 2014] Cale: but? [Thu May 15 10:30:49 2014] So you must have assumed it somewhere [Thu May 15 10:31:00 2014] If you're saying that it holds [Thu May 15 10:31:20 2014] it holds for JMeq I thought. [Thu May 15 10:31:33 2014] JMeq shouldn't imply UIP [Thu May 15 10:32:20 2014] Oh, perhaps JMeq_eq will... let me think about that [Thu May 15 10:34:02 2014] Well, no, I don't believe you'll get a version of UIP for JMeq, and so JMeq_eq shouldn't help [Thu May 15 10:34:13 2014] You could certainly assume one [Thu May 15 10:35:16 2014] what I actually want to prove: [Thu May 15 10:35:26 2014] forall {A} {n m} (eq : n = m) (v : vec A n), (vec_id eq v) ~= v [Thu May 15 10:35:30 2014] where [Thu May 15 10:35:43 2014] vec_id {A} {a b} (eq : a = b) : vec A a -> vec A b. [Thu May 15 10:35:56 2014] this should hold. [Thu May 15 10:36:05 2014] What is ~= ? [Thu May 15 10:36:12 2014] JMeq [Thu May 15 10:36:16 2014] okay [Thu May 15 10:36:17 2014] it will not hold for = [Thu May 15 10:36:26 2014] because that is not well-typed [Thu May 15 10:37:18 2014] do you agree that this should hold? [Thu May 15 10:43:01 2014] hmm [Thu May 15 10:45:09 2014] dang, I have had no time for Coq lately due to editing lots of wedding photos [Thu May 15 10:55:09 2014] schoppenhauer: Okay, I managed to do it [Thu May 15 10:55:27 2014] Cale: how? [Thu May 15 10:55:30 2014] Actually, you're probably not using HoTT, let me just translate this :) [Thu May 15 10:56:01 2014] Oh, hmm [Thu May 15 10:56:15 2014] It won't let me do induction over the equality in the same place... [Thu May 15 10:56:25 2014] :3 [Thu May 15 10:56:30 2014] coq is a productivity sink. [Thu May 15 10:57:05 2014] at least you're not editing wedding photos. [Thu May 15 10:57:07 2014] http://lpaste.net/104173 [Thu May 15 10:57:17 2014] This works in my HoTT-Coq [Thu May 15 10:57:26 2014] and doesn't really use HoTT all that much [Thu May 15 10:57:40 2014] But when I try it in plain Coq, it won't let me do induction over the path eq [Thu May 15 10:57:51 2014] In the latter proof [Thu May 15 10:57:59 2014] indeed, indeed. [Thu May 15 10:58:03 2014] that's coq. [Thu May 15 10:58:10 2014] That *might* be that my plain Coq is older [Thu May 15 10:58:34 2014] The HoTT Coq that I'm using is a development release [Thu May 15 10:58:37 2014] the only reason why I need vec_id in the first place is that a=b does not imply vec A a = vec A b, obviously. [Thu May 15 10:58:46 2014] Well, it does imply that [Thu May 15 10:58:53 2014] well, it does, but it is not easy to work with it. [Thu May 15 10:59:20 2014] Definition vec_id {A} {a b} (eq : a = b) : vec A a = vec A b. [Thu May 15 10:59:20 2014] induction eq. [Thu May 15 10:59:20 2014] reflexivity. [Thu May 15 10:59:20 2014] Defined. [Thu May 15 10:59:26 2014] there is no simple way to get c : vec A b from c : Vec A a [Thu May 15 10:59:41 2014] yes, but I cannot rewrite with this. [Thu May 15 10:59:55 2014] You can transport... [Thu May 15 11:00:02 2014] ? [Thu May 15 11:00:44 2014] what does that mean? [Thu May 15 11:01:15 2014] transport : forall (P : A -> Type) (x y : A), x = y -> P x -> P y. [Thu May 15 11:01:17 2014] (sorry, I am a bit ... nerved ... by the many concepts people evolved for something as simple as equality ... especially since the stuff I *actually* want to prove is hard enough) [Thu May 15 11:01:22 2014] ah ok [Thu May 15 11:01:27 2014] that is "subst" for me. [Thu May 15 11:01:32 2014] yes, I can do that. [Thu May 15 11:01:50 2014] Right, yeah, I couldn't remember the standard name for some reason :) [Thu May 15 11:02:43 2014] actually, vec_id is some sort of substitution [Thu May 15 11:02:58 2014] btw, HoTT gives you a much better intuition for when things will be possible with equalities -- if you think about them as paths which might not be refl, then it becomes clearer what the obstructions are to doing certain things. [Thu May 15 11:03:12 2014] Yes, it is [Thu May 15 11:03:56 2014] Definition vec_id {A} {a b} (eq : a = b) : vec A a -> vec A b := transport _ eq. [Thu May 15 11:04:11 2014] (or subst ;) [Thu May 15 11:05:05 2014] But instead of making that substitution, you could instead do it with whatever you were trying to prove about c [Thu May 15 11:05:18 2014] (I think) [Thu May 15 11:05:35 2014] Or if you don't care, you could always just assume UIP and it all becomes trivial. [Thu May 15 11:21:54 2014] Cale: what I meant to define was an inductive type Bloop with two values, a and b. [Thu May 15 11:25:39 2014] tswett: Oh, well, in that case, yes, you can prove they're distinct. [Thu May 15 11:25:53 2014] http://lpaste.net/104175 [Thu May 15 11:29:36 2014] tswett: The type you defined earlier was a record consisting of a pair of values of type Bloop. Because the recursion wasn't well-founded, it was easy to show that no such record could ever be constructed. [Thu May 15 11:31:09 2014] Cale: can I still prove they're distinct if Bloop : Prop? [Thu May 15 11:32:08 2014] ah, hmm [Thu May 15 11:33:20 2014] Apparently not the same way, at least. [Thu May 15 11:34:12 2014] * looks at how discriminate behaves. [Thu May 15 11:34:57 2014] Looks like it essentially says, let f a = True and f b = False; if a = b, then by eq_ind, f a = f b, so True = False. [Thu May 15 11:36:52 2014] When I try to do the same with Bloop : Prop, I get this: [Thu May 15 11:37:43 2014] Error: Incorrect elimination of "e" in the inductive type "Bloop": the return type has sort "Type" while it should be "Prop". Elimination of an inductive object of sort Prop is not allowed on a predicate in sort Type because proofs can be eliminated only to build proofs. [Thu May 15 11:38:45 2014] Specifically, that's what happens when I do "Goal a = b. set (f := fun e => match e with | a => True | b => False end)." [Thu May 15 11:40:58 2014] yeah [Thu May 15 11:41:25 2014] True : Prop and Prop : Type [Thu May 15 11:42:01 2014] I didn't know about that rule. [Thu May 15 11:42:20 2014] I tend to just avoid Prop as much as possible. [Thu May 15 11:44:04 2014] There are two main reasons you'd want to use Prop: 1) either you need impredicativity because you're doing set theoretical things, and it lets you deal with things like the powerset, or 2) you're doing program extraction and you want to make use of the fact that Props are erased [Thu May 15 11:44:41 2014] * looks at his code. [Thu May 15 11:45:07 2014] Well, I'm using equality, which is a Prop. [Thu May 15 11:45:23 2014] Ah, there's no reason for equality to be a Prop. [Thu May 15 11:45:58 2014] (and it isn't one in HoTT for instance) [Thu May 15 11:46:32 2014] I suppose there's a bit of a trick [Thu May 15 11:46:34 2014] eq is a Prop in my copy of HoTT Coq. [Thu May 15 11:47:00 2014] Uh, that's weird [Thu May 15 11:47:07 2014] It's not in mine. [Thu May 15 11:47:24 2014] You type "Check eq." and it gives you a Type? [Thu May 15 11:47:34 2014] Maybe I have a weird version. [Thu May 15 11:47:52 2014] Er, it tells me that eq isn't a thing [Thu May 15 11:48:05 2014] Check paths tells me that paths : forall (_ : ?1) (_ : ?1), Type [Thu May 15 11:48:28 2014] I don't have paths. [Thu May 15 11:48:46 2014] Yeah, I guess we're talking about different things. [Thu May 15 11:48:51 2014] hm [Thu May 15 11:49:10 2014] What I know about my copy of HoTT Coq is that it's just like regular Coq except you can say "Set Universe Polymorphism." [Thu May 15 11:49:12 2014] Any usage of Prop in HoTT should be considered a bug [Thu May 15 11:49:32 2014] Are you using the HoTT library with it? [Thu May 15 11:49:41 2014] I don't think so. [Thu May 15 11:51:08 2014] Let me do an update to make absolutely sure that I have the latest version. The code is here: https://github.com/HoTT/HoTT [Thu May 15 11:51:41 2014] You can see that coq-HoTT is a submodule which is meant to be used together with the theories from here [Fri May 16 10:07:37 2014] if i want to prove something on a list of the form l = x :: (l' ++ [y]), how can i apply the induction hypothesis on l'? [Fri May 16 10:18:32 2014] i need to use P(l') in order to prove P(l) [Fri May 16 11:09:34 2014] i made a recursive function which given an int S (S k) calls itself on k, but coq cannot guess the decrasing argument, how can i help it? [Sat May 17 15:31:02 2014] why is it a copy of the ocaml interpreter in coq (in kernel/byterun/coq_interp.c) ? [Sun May 18 09:27:26 2014] why does coq have its own ocaml runtime interpreter ? [Sun May 18 09:57:03 2014] Anarchos: Maybe someting to do with the native compiler or vm_compute? (It sometimes compiles Coq functions to OCaml and runs them, for speed.) [Sun May 18 10:09:19 2014] jgross why not using the installed runtime ?? [Sun May 18 10:33:41 2014] Hi. I am just starting to learn Coq with the company of "Software fundations" book, and I wonder if it is possible to make Coq rewrite specific parts of the equaltions or I have to play with make simple nested proofs to make coq guess which variables I want to subsitute? [Sun May 18 10:34:48 2014] (just proved the distributivity of multiplication with addition and it was kind of cumbersome) [Sun May 18 10:38:43 2014] nvm. Just came to the moment where they tell me that there actually is an easier way of doing it. [Sun May 18 10:54:33 2014] Anarchos: That would increase the size of the trusted code base? [Sun May 18 10:56:24 2014] jgross i am not skilled enough to answer that sorry :) [Sun May 18 11:19:02 2014] Why do i get this one when compiling coq ? COQC -noinit theories/Init/Notations.v Fatal error: exception File "camlinternalFormat.ml", line 980, characters 6-12: Assertion failed [Sun May 18 18:09:55 2014] schoppenhauer: no! We have [existT (fun x => x) bool true = existT (fun x => x) bool false] with univalence [Sun May 18 18:10:26 2014] nevermind, my chatlog was a couple of days back :) [Sun May 18 18:32:06 2014] taking a look at Coq'Art, it seems a lot of terms that were typed Set in 8.2 are now Type... why is that? [Sun May 18 18:35:24 2014] tautologico: Set is only to restrict the user to not go up a universe level. Most people don't care anymore and want to reuse their code in places that do need universes. [Sun May 18 18:35:46 2014] also Set used to be impredicative, but now that that's gone, it's pretty nerfed. [Sun May 18 18:38:57 2014] ianjneu: I see, thanks [Sun May 18 18:43:34 2014] Is there a way to normalize and print a term? [Sun May 18 18:44:00 2014] I want to look at the result of a function application, but Print just shows the application [Sun May 18 18:50:56 2014] Eval compute in ? [Sun May 18 18:53:41 2014] that works! thanks [Sun May 18 21:15:55 2014] I'm trying to show that any terms of type { x : list A | length x = 0 } are equal, but I can't figure out how to show equality for 'exist' terms. [Sun May 18 21:16:24 2014] The 'destruct' tactic doesn't work for case analysis. http://lpaste.net/104297 [Sun May 18 21:18:19 2014] I don't know how to show equality using induction, because the predicate of 'exist' depends on the existentially bound value. [Sun May 18 21:19:56 2014] I'd appreciate some advice, or reading on how to prove equality in these cases. [Sun May 18 22:41:42 2014] heatsink: easiest way to prove something like that is with proof irrelevance. but know that that comes with philosophical implications. [Sun May 18 22:42:56 2014] heatsink: you probably are happy enough proving `proj1 lst1 = proj1 lst2`? [Sun May 18 22:48:20 2014] heatsink: something like this: http://lpaste.net/104298 [Sun May 18 22:51:37 2014] hmm... [Sun May 18 22:57:57 2014] those inductions can be replaced by destructs. not sure what I was thinking. [Sun May 18 23:03:48 2014] Overall, I'm writing mergesort as an exercise to learn Coq. I can see that proving equality of proj1 should be logically sufficient, but I don't know how that will affect the rest of the code. [Sun May 18 23:06:00 2014] I was planning for the code to carry along evidence that the output of subproblems is a sorted permutation of the input. [Sun May 18 23:08:27 2014] you can still do that, I think. [Sun May 18 23:08:35 2014] if you post your code I can take a look [Sun May 18 23:09:57 2014] I think that switching to equality on projections will be encapsulated in the proposition that says "permutation p transforms lst1 into lst2," so it won't affect the rest of the code. [Sun May 18 23:10:20 2014] I can do that. [Sun May 18 23:16:25 2014] I was also trying to write the equality proof using sig_ind and eq_ind [Sun May 18 23:18:44 2014] But I couldn't find a solution that way. It seemed like I needed a proof of (length xs = 0) for arbitrary xs, which clearly isn't right. [Sun May 18 23:20:34 2014] There must be some extra trick to dependent equality, beyond using induction, eq_refl, and f_equal. [Sun May 18 23:34:52 2014] Reading a so post about proof irrelevance. http://cstheory.stackexchange.com/q/5158 [Sun May 18 23:46:05 2014] Right I think I have a handle on the problem now. Thanks for suggesting to use the projection, jrw. [Sun May 18 23:46:18 2014] np [Mon May 19 15:37:24 2014] hello. [Mon May 19 15:37:48 2014] I often have the pattern that I need to prove f(a)=f(b), by just proving a=b [Mon May 19 15:38:07 2014] this is possible, but is there a strategy such that I can just convert the goal f(a)=f(b) into the goal a=b? [Mon May 19 15:38:20 2014] (this is the trivial direction. the other requires injectivity.) [Mon May 19 15:50:36 2014] f_equal or something [Mon May 19 16:36:12 2014] thx [Mon May 19 18:40:01 2014] I'm using proof general and am getting Error: Compiled library AssocList.vo makes inconsistent assumptions over [Mon May 19 18:40:04 2014] library Coq.Init.Logic [Mon May 19 18:40:10 2014] with a library I'm using [Mon May 19 18:40:26 2014] I compiled everything with my version of Coq, is it possible my proofgeneral is using a different version? [Mon May 19 18:41:04 2014] (This was from the metatheory library, but I don't really think that's got anything to do with it, metalib compiles fine if I just run the Makefile) [Mon May 19 22:59:46 2014] Hi, I'm a budding programmer and someone recommended that I learn coq. I'm wondering, how will it help me be a better programmer? [Mon May 19 23:02:43 2014] I suspect because it will affect how you think. It will challenge your assumptions about programming and the structure of programs. Consequently your problem solving approaches will change [Mon May 19 23:03:33 2014] But it also depends on your skill level, experience, and interests wrt programming... [Tue May 20 00:06:18 2014] Hi, I'm a budding programmer and someone recommended that I learn coq. I'm wondering, how will it help me be a better programmer? [Tue May 20 00:08:27 2014] logicalguy: didn't like my other answers? :( [Tue May 20 00:09:11 2014] mankyKitty, I'm sorry, I missed your answers because my network died :( [Tue May 20 00:09:27 2014] logicalguy: 1:02 PM I suspect because it will affect how you think. It will challenge your assumptions about programming and the structure of programs. Consequently your problem solving approaches will change [Tue May 20 00:09:28 2014] 1:03 PM But it also depends on your skill level, experience, and interests wrt programming... [Tue May 20 00:09:35 2014] :) [Tue May 20 00:10:31 2014] Well, I do have a degree in computer science, but its been over 5 years since I did any programming. I need to start with baby steps again [Tue May 20 00:11:08 2014] logicalguy: No you don't. Dive in, deep end, with concrete shoes. [Tue May 20 00:13:07 2014] logicalguy: http://www.cis.upenn.edu/~bcpierce/sf/ Have at it !! :) [Tue May 20 00:13:26 2014] mankyKitty, ha ha, yes, but what I mean is since I'm pretty much starting again from scratch, I want to build a proper foundation [Tue May 20 00:13:48 2014] mankyKitty, thank you, I'm looking it up now [Tue May 20 00:14:03 2014] Coq and or Haskell will provide you with that foundation. [Tue May 20 00:14:06 2014] np [Tue May 20 00:14:39 2014] I'm only learning Coq now, but I'm a firm believer in learning languages that challenge how you think instead of "how do I do a for loop in this language?" [Tue May 20 00:14:46 2014] oh, between Coq and haskell, is it either-or, or are they complementary [Tue May 20 00:15:06 2014] I would regard them as complementary [Tue May 20 00:15:46 2014] okay, [Tue May 20 00:16:18 2014] I'm learning Java right now, so maybe getting into Haskell right now would only confuse me, I think [Tue May 20 00:16:31 2014] drop java, it will ruin you [Tue May 20 00:16:35 2014] gogo Haskell :P [Tue May 20 00:16:50 2014] ha ha [Tue May 20 00:16:58 2014] unfortunately, I also need to find a job [Tue May 20 00:17:51 2014] which are hard to come by for Haskell programmers, where I live [Tue May 20 00:18:00 2014] fair enough [Tue May 20 00:19:20 2014] I'm watching this right now: http://vimeo.com/6615365 [Tue May 20 00:19:48 2014] noice [Tue May 20 00:21:42 2014] hope all this decides to stay on in this thick head of mine :D [Tue May 20 00:22:32 2014] don't worry you're not the only one with that concern >< [Tue May 20 00:23:02 2014] really [Tue May 20 00:23:40 2014] okay, I will wait for tomorrow to tell me how much I've retained [Tue May 20 00:23:52 2014] hehe [Tue May 20 00:23:54 2014] best of luck ! [Tue May 20 00:26:07 2014] how long approx was it for you before you noticed a change in the way you think, [Tue May 20 00:27:56 2014] hard to say, i've been kicking around FP for a while, and recently started on Haskell.. but lately just noticed I look at problems differently and break them up into different components... not something I could really put my finger on. [Tue May 20 00:28:57 2014] how and what you code will change what benefits you get... just keep learning what fascinates you and you'll do a double take in the near future about how you're approaching things. ;) [Tue May 20 00:30:11 2014] mankyKitty, yes, I want to learn what I'm interested in, but i want a proper approach to it, not just googling on a topic randomly everyday, you know :) [Tue May 20 00:30:33 2014] logicalguy: my advice then is to follow the references [Tue May 20 00:30:44 2014] for example work through software foundations [Tue May 20 00:31:10 2014] but also you'll discover through looking for information that people drop the names of people/papers [Tue May 20 00:31:13 2014] read them [Tue May 20 00:31:23 2014] then if they reference something interesting go read that [Tue May 20 00:31:36 2014] don't read papers piecemeal [Tue May 20 00:31:57 2014] go through the whole paper, not a few at a time (my current problem) [Tue May 20 00:32:39 2014] ah okay [Tue May 20 00:32:57 2014] logicalguy: here is a (daunting) awesome reading list for haskell http://www.stephendiehl.com/posts/essential_haskell.html [Tue May 20 00:33:02 2014] just as an example [Tue May 20 00:33:54 2014] here's goodbye to my life :( [Tue May 20 00:34:06 2014] also don't be afraid to try to help people, even if you're not 100% sure about things... like I can't form a single Coq statement yet, but I'm more than happy to natter with you about this stuff [Tue May 20 00:34:07 2014] hahaha [Tue May 20 00:34:13 2014] that's why i said one at a time [Tue May 20 00:34:22 2014] plenty of time for life and type theory :P [Tue May 20 00:34:46 2014] it's not life AND, it's life OR [Tue May 20 00:35:06 2014] pfft [Tue May 20 00:35:45 2014] sorry, looking at that list made me a bit melancholic [Tue May 20 00:36:16 2014] Your own list will grow organically from your learning [Tue May 20 00:36:33 2014] things like that are meant as a reference or bounce point [Tue May 20 00:36:55 2014] No one looks at a bibliography and just adds that to their reading list [Tue May 20 00:37:02 2014] yes, I understand, I was just kidding :) [Tue May 20 00:37:24 2014] but isn't that what this stephen dude wants people to do [Tue May 20 00:37:54 2014] in a perfect world, wouldn't you? :D [Tue May 20 00:38:17 2014] no [Tue May 20 00:38:32 2014] I'd want everyone to go on a two-week trek in the himalayas [Tue May 20 00:39:03 2014] yeah but it's a perfect world so you can do both. :p [Tue May 20 00:40:00 2014] yes, probably, ha ha, one could be cut off from all distractions and have 3G internet at the same time [Tue May 20 00:40:57 2014] heh [Tue May 20 00:42:53 2014] do you have a programming job or do you do it as a hobby [Tue May 20 00:43:15 2014] yeah I'm a workaday coder... PHP though :( [Tue May 20 00:43:18 2014] hobby too [Tue May 20 00:43:34 2014] are you also a gamer [Tue May 20 00:43:48 2014] used to be, lost interest [Tue May 20 00:44:49 2014] oh [Tue May 20 00:49:29 2014] sensible [Tue May 20 00:52:29 2014] meh, it's neither here nor there [Tue May 20 00:53:35 2014] have you finished the whole SF book? [Tue May 20 00:54:37 2014] nope, only just getting started myself [Tue May 20 00:54:47 2014] I'm just keen as biscuits :D [Tue May 20 00:55:29 2014] yes, you're already an evangelist [Tue May 20 00:55:51 2014] nah, if I was i'd still be yelling at you about java :p [Tue May 20 00:56:25 2014] bible bashing with a Java bible, goodness! [Tue May 20 01:03:28 2014] logicalguy: good luck with your efforts though and stick with it.. don't be afraid to kick around a few "I wonder if ..." side projects too.. always fun :D I'll probably be around randomly as I work through the book [Tue May 20 01:07:41 2014] thanks a lot for your comments and suggestions, mankyKitty, I'm sure I'll be around to bother you with more questions every now and then :) [Tue May 20 01:07:53 2014] logicalguy: happy to help ^_^ [Tue May 20 01:10:04 2014] have a good night :) [Tue May 20 14:11:29 2014] whats the status of CoqIde for macosx for coq8.4pl4? is there a new version? [Tue May 20 15:47:10 2014] hi [Tue May 20 15:48:24 2014] what's the canonical way to deal with non exhaustive pattern matching ? When the case can't happen [Tue May 20 15:57:48 2014] Enjolras: turn the return type of the pattern matching into a match [Tue May 20 15:58:13 2014] where you return an empty type in cases that are unfeasible [Tue May 20 15:58:14 2014] ? [Tue May 20 15:58:34 2014] Whaou. You blew my mind. [Tue May 20 15:58:59 2014] That's totally awesome to be able to do that. Thanks [Tue May 20 15:59:51 2014] I'm stil stuck in an ML world sometimes :) [Tue May 20 16:00:58 2014] Ahoy. [Tue May 20 16:03:05 2014] So I'm defining a sort of variant lambda calculus thingy. In order to typecheck the term "apply a b", I want to typecheck the terms "a" and "b", and verify that the type of "a" is a function whose domain is the type of "b". [Tue May 20 16:03:16 2014] Types are defined inductively. [Tue May 20 16:04:04 2014] Is there a way to use the "match" construct, or some other construct, to check whether or not two values of inductive types are equal? [Tue May 20 16:04:38 2014] Other than just doing case analysis with one case per constructor. [Tue May 20 16:11:44 2014] is there a way to permutate universal quantifiers? [Tue May 20 16:12:13 2014] schoppenhauer: like, during a proof? [Tue May 20 16:12:19 2014] tswett: yes. [Tue May 20 16:12:30 2014] tswett: when I need to do induction on the second variable, not on the first. [Tue May 20 16:12:43 2014] tswett: and want the quantor for the first variable in the induction hypothesis. [Tue May 20 16:12:50 2014] * nods. [Tue May 20 16:12:57 2014] how? [Tue May 20 16:13:54 2014] Well, if you're trying to prove A -> B -> C, could you just say "cut (B -> A -> C). tauto."? [Tue May 20 16:14:12 2014] schoppenhauer: just introduce the two, and revert the one you need not introduced [Tue May 20 16:14:45 2014] Ptival: thx! that was what I was searching for! [Tue May 20 16:15:09 2014] revert will put a hypothesis back, generalize dependent will put a hypothesis back along with all the stuff that depended on it [Tue May 20 16:15:56 2014] tswett: you should write a function for your type of terms, whose type would be forall (a b : term), {a = b} + {a <> b} [Tue May 20 16:16:25 2014] tswett: then you can just use this function to decide equality of two values [Tue May 20 16:18:01 2014] tswett: this function will probably have pattern matching involved, though you might be lucky using the 'decide equality.' tactic to do most of the work [Tue May 20 16:18:09 2014] Ptival: *nod* Thanks. [Tue May 20 16:22:46 2014] Sweet. I managed to use magic to make it look like I have a term T : T. [Tue May 20 16:26:14 2014] First I defined a type Term, with T : Term. Then I defined a type "Val a", which is the type of Terms with "type" a. I then defined a function checkU which takes a term and returns the "type" of that term, and finally I defined checkT which takes a term and returns the "Val" version of that term. [Tue May 20 16:26:51 2014] Then I just do "Coercion Val : Term >-> Sortclass" and "Coercion checkT : Term >-> Val", and voila, "Check T : T." says that T : T. [Tue May 20 16:27:30 2014] hehe [Tue May 20 16:28:33 2014] I tried to do that a while back, but I couldn't think of the correct trick. [Tue May 20 16:34:33 2014] What I'd really like to do is just type something like "Axiom T : T. Axiom Si : Fun (Si T) T. Axiom Fun : Fun (Times (Si T) (Si T)) T. Axiom Times : Fun (Times T T) T." [Tue May 20 16:35:41 2014] Unfortunately, you can't define an axiom whose type involves a term that hasn't already been defined. [Tue May 20 16:37:03 2014] I'd like it if there were some really easy way to work around that. [Tue May 20 16:41:17 2014] An alternative that would also be nice: "Inductive Val := | T : Val T." [Tue May 20 16:41:32 2014] Of course, the type of Val is Val T -> Type. [Tue May 20 19:52:11 2014] is it possible to eliminate equality` [Tue May 20 19:52:13 2014] ? [Tue May 20 19:52:27 2014] (do induction after it?) [Tue May 20 19:52:32 2014] because it somehow wont work for me. [Tue May 20 19:53:08 2014] I need to match some equality with eq_refl. [Tue May 20 20:08:36 2014] ok got it using refinement. [Tue May 20 22:06:04 2014] whats the status of CoqIde for macosx for coq8.4pl4? is there a new version? [Tue May 20 23:18:41 2014] hi everyone [Tue May 20 23:19:53 2014] I'm working through Software Foundations and I've a question about one of the exercises in the Basics.v file.. [Tue May 20 23:20:17 2014] I've solved it, but it feels a little messy.. anyone have any pointers perhaps -> https://gist.github.com/mankyKitty/27693c0961361e76509b [Tue May 20 23:25:34 2014] mankyKitty: I think something like Proof. intros f H b. rewrite -> H. rewrite -> H. reflexivity. Qed. [Tue May 20 23:26:01 2014] intros f H b. rewrite -> H. apply H. Qed. [Tue May 20 23:26:03 2014] yeh [Tue May 20 23:26:12 2014] I’d use the [repeat] tactical and some semicolons: “intros f x b. destruct b; repeat (rewrite -> x); reflexivity.” [Tue May 20 23:26:13 2014] ie you don't need to destruct, since you're not using the knowledge you gain from the destruction [Tue May 20 23:26:31 2014] Oh, yeah, that makes it even shorter. [Tue May 20 23:26:41 2014] ddere: alkabetz: this is from Basics.v in SF - apply and repeat aren't in scope yet :) [Tue May 20 23:26:51 2014] ah ok [Tue May 20 23:27:03 2014] Oh, right, oops. [Tue May 20 23:27:04 2014] assumption would work just as well i think [Tue May 20 23:27:12 2014] thats got to be in scope right? [Tue May 20 23:27:21 2014] assumption in place of apply H. [Tue May 20 23:27:27 2014] dalaing: Yeah i was trying to retrieve my H, but I couldn't and didn't understand what I'd gotten myself into [Tue May 20 23:27:30 2014] I mean in scope of what has been covered in SF at this point [Tue May 20 23:27:38 2014] thanks for the suggestions everyone [Tue May 20 23:27:40 2014] :D [Tue May 20 23:27:42 2014] mankyKitty: So yes, it seems a little messy, but only because not enough stuff is in scope to make it really elegant ): [Tue May 20 23:27:55 2014] always good to know there are better things coming [Tue May 20 23:28:01 2014] daliang: the forall (x : bool) part makes me think they wanted him to do the destruct as an exercise though [Tue May 20 23:28:20 2014] daliang: otherwise you could just do forall (x : A) right? [Tue May 20 23:28:30 2014] no polymorphism at that point [Tue May 20 23:28:40 2014] ah ok [Tue May 20 23:29:06 2014] coq seems to let me down on the polymorphism front in general i guess [Tue May 20 23:29:23 2014] im probably just missing something [Tue May 20 23:29:25 2014] I'm only part way through SF, so I remember the progression pretty well [Tue May 20 23:29:37 2014] looking forward to revisiting it after CPDT with crush in hand... [Tue May 20 23:29:43 2014] :) [Tue May 20 23:30:34 2014] mankyKitty: in any case, you had intros f x b. [Tue May 20 23:30:45 2014] At least I was curious about the right things... the unused b' had me concerned and I was lost when trying to introduce my hypothesis (??) [Tue May 20 23:30:46 2014] the H [Tue May 20 23:31:02 2014] ddere: yeah that part was why I went...well..still right, but ugly [Tue May 20 23:31:04 2014] mankyKitty: x : forall x : bool, f x = x was a bit confusing ;) [Tue May 20 23:31:16 2014] yup [Tue May 20 23:32:13 2014] so much fun to just chip away at this... looking forward to CPDT too ! [Tue May 20 23:32:20 2014] daliang: do you know if theres something i am missing here: https://github.com/domdere/haskell-coq/blob/master/src/classes/Monad.v#L128 [Tue May 20 23:32:52 2014] dliang: like if theres a way i can get away without having bind1 and bind2 as separate arguments, and instead just have a single bind [Tue May 20 23:33:02 2014] a single (polymorphic) bind [Tue May 20 23:33:08 2014] I'm still pretty new to this :) [Tue May 20 23:35:06 2014] so not at the moment [Tue May 20 23:35:27 2014] can you implicit type arguments to the bind itself? [Tue May 20 23:35:55 2014] daliang: i havent managed to [Tue May 20 23:36:25 2014] daliang: when i *call* those functions i can use the same function that has been defined polymorphically [Tue May 20 23:36:40 2014] daliang: but i jsut have to pass it in twice and get it to resolve them down into 2 seperate functions [Tue May 20 23:38:07 2014] could you replace the A/B/Cs in bind with underscores? or will it try to unify them across the usages? [Tue May 20 23:38:21 2014] it's a bit beyond my level I'm afraid [Tue May 20 23:39:05 2014] although I'm about to start working 4 days a week to get more FP study in, so hopefully I'll get to that level sooner rather than later :) [Tue May 20 23:39:20 2014] daliang: wow ok [Tue May 20 23:39:30 2014] dalaing: nice O_O [Tue May 20 23:39:46 2014] daliang: thats not a bad suggestion, i'll give it a try when i get home [Tue May 20 23:51:00 2014] ddere: I might be too used to Haskell's inferencing - started wondering whether you need the binds in the definition at all [Tue May 20 23:59:42 2014] daliang: hmm? [Wed May 21 00:00:30 2014] the function is a helper function to use while defining your instances, so technically the arg is not a Monad yet [Wed May 21 00:01:18 2014] daliang: its a function i intend to use when defining the Applicative instance which is a requirement for the Monad instance in my defns [Wed May 21 00:37:42 2014] hey where can i find a reference on strictness/non-strictness and the Eval command in Coq? [Wed May 21 00:39:17 2014] ddere: what do you mean? [Wed May 21 00:40:10 2014] well i understand that in a total language like Coq, in terms of the result returned by a function strictness/non-strictness is irrelevent [Wed May 21 00:40:17 2014] (am i wrong there?) [Wed May 21 00:41:08 2014] but i read somewhere that you can still tell Eval to evaluate a function strictly or non-strictly? [Wed May 21 00:44:08 2014] ddere: you're right that if you want to normalize a term, it doesn't matter what reduction strategy you follow. you might want to read about the difference between the "cbv" and "lazy" tactics in coq [Wed May 21 00:44:27 2014] jrw: ok cool thanks :) [Wed May 21 00:45:17 2014] one difference, for example, is their behavior under binders, iirc. [Wed May 21 00:53:14 2014] and whats the difference between "Eval simpl" and "Eval compute"? [Wed May 21 00:53:45 2014] ddere: compute normalizes terms. simpl does less reduction. [Wed May 21 00:53:51 2014] the exact rules are a little complicated [Wed May 21 00:53:55 2014] ah ok [Wed May 21 00:54:14 2014] but, for example, simpl will not unfold a fixpoint unless its structural argument is "known" [Wed May 21 00:56:43 2014] ah ok [Wed May 21 00:59:48 2014] jrw: I don't think cbv (equivalently(?), compute) and lazy differ under binders. Perhaps you're thinking of hnf vs. lazy/compute? [Wed May 21 01:00:46 2014] ah, I must be wrong about that. I'm sure you're right. [Wed May 21 01:14:15 2014] tests say: [Wed May 21 01:14:15 2014] Eval hnf in (fun x : Set => 1 + 1). (* = fun _ : Set => 1 + 1 *) [Wed May 21 01:14:15 2014] Eval cbv in (fun x : Set => 1 + 1). (* = fun _ : Set => 2 *) [Wed May 21 01:14:15 2014] Eval lazy in (fun x : Set => 1 + 1). (* = fun _ : Set => 2 *) [Wed May 21 01:14:15 2014] Eval compute in (fun x : Set => 1 + 1). (* = fun _ : Set => 2 *) [Wed May 21 01:14:15 2014] Eval simpl in (fun x : Set => 1 + 1). (* = fun _ : Set => 2 *) [Wed May 21 03:33:01 2014] Dumb question: At some point in my proof, an inversion introduces some package-qualified names (e.g., "Imp.X"). Is there some convenient way to reference these without typing "." (which causes proof general to send the partial statement to coq)? Thanks. [Wed May 21 03:34:16 2014] Warning: query commands should not be inserted in scripts ---------------- I get this warning in coqide, what is the right way to enter query commands? [Wed May 21 04:58:27 2014] does decidability in coq "forall t, (P t \/ ~ P t)" correspond exactly to the existence of a turing machine which can tell whether P t or not P t for all t? [Wed May 21 07:07:55 2014] how can i stop ProofGeneral from advancing automatically the proof when i make a "."? [Wed May 21 07:45:42 2014] eizo: C-c . [Wed May 21 07:46:35 2014] eizo: and it does not "exactly" correspond. if you can prove it, there is such a turing machine. if you cannot prove it, things are more complicated. [Wed May 21 07:48:07 2014] but thinking in terms of turing machines is probably not the best in this case anyway. [Wed May 21 08:36:14 2014] schoppenhauer: I think it's the other way: if there's a TM that decides it, you should be able to prove it. But for instance, when t is infinite (e.g. a stream of nats) then you might be able to prove "forall t, (P t \/ ~ P t)" (e.g. P t := stream is all 0s), but couldn't decide such a property with a TM. [Wed May 21 09:08:52 2014] thanks [Wed May 21 09:08:55 2014] so they're incomparable? [Wed May 21 09:21:04 2014] td202: how do you prove that in coq? [Wed May 21 09:21:23 2014] i thought proofs corresponded to terminating programs [Wed May 21 09:38:01 2014] http://pastie.org/9196028 [Wed May 21 10:45:18 2014] * is probably mistaken [Thu May 22 06:16:01 2014] Hi. I'm trying to access the equiv "field" of a Setoid which is required by a Module Type. But I can't firgure out how to do that.Module Type Eqset. Parameter A : Type. Parameter Instance SetoidA : Setoid A. Definition eqA := SetoidA.equiv. End Eqset. [Thu May 22 06:24:37 2014] Nevermind. It's just equiv without SetoidA in front of it. [Thu May 22 11:20:20 2014] why do i get "Could not find an instance for "RelationClasses.subrelation"" when trying to use "rewrite andb_true_eq" [Thu May 22 11:22:58 2014] or andb_prop [Thu May 22 16:37:51 2014] I don't know how to go about doing a counting proof in coq. Can I have a hint or example? [Thu May 22 16:38:08 2014] For example, for any byte b, for any set S of 256 bytes, b is in S. [Thu May 22 16:58:46 2014] heatsink: can you say a bit more about what you're trying to do? how are you modeling byes? sets? [Thu May 22 17:05:34 2014] jrw, I'm encoding size-N permutations as a list of list indices less than N, with all list elements distinct from each other. [Thu May 22 17:06:02 2014] I want to show that each list index appears exactly once [Thu May 22 17:06:27 2014] i.e., permuting a list doesn't discard or duplicate elements [Thu May 22 17:07:19 2014] heatsink: okay, can you post your definitions? it's definitely possible to show this. [Thu May 22 17:07:27 2014] Alright, just a moment [Thu May 22 17:14:08 2014] I think this is the only part that's relevant. http://lpaste.net/104485 [Thu May 22 17:14:27 2014] There's the permutation data type and the goal to be proven. [Thu May 22 17:14:37 2014] heatsink: what's ForallOrdPairs? [Thu May 22 17:14:53 2014] oh I see [Thu May 22 17:14:54 2014] It's from the List module [Thu May 22 17:14:56 2014] stdlib [Thu May 22 17:15:45 2014] ForallOrdPairs R lst means that R x y holds for each (x, y) in the list where x precedes y [Thu May 22 17:16:05 2014] each x and each y, rather [Thu May 22 17:17:16 2014] heatsink: is there any reason you chose not to use the definition of permutation in Sorting.Permutation? [Thu May 22 17:19:16 2014] No. I'm not familiar with Coq and the library. [Thu May 22 17:19:54 2014] ok, well one option would be to use that [Thu May 22 17:19:58 2014] there are more lemmas about permutations [Thu May 22 17:20:06 2014] but not the exact one you want. [Thu May 22 17:21:37 2014] Hmm [Thu May 22 17:24:42 2014] There's a lemma that if l is a permutation of l', every element of l is in l'. [Thu May 22 17:24:55 2014] yeah, that's pretty close to what you were saying [Thu May 22 17:25:34 2014] Permutations here are a relation on lists, rather than a transformation that can be applied to lists. But I think that will work for now. [Thu May 22 17:27:23 2014] I am still interested in learning about counting proofs, though [Thu May 22 17:28:06 2014] Since it seems "obvious" but I have no idea how to formalize it [Thu May 22 17:31:10 2014] My intuition says that I could use 'cardinal' from the Finite_sets module, and induction on the natural number data type, to count the size of { i | i < n } [Thu May 22 17:33:09 2014] That would also give me a way of constructing the set, with type Ensemble { i | i < n } [Thu May 22 17:35:01 2014] That won't give me the whole proof, but I think I need to put that off for another time [Thu May 22 17:35:30 2014] while I try using Sorting.Permutation [Fri May 23 03:09:40 2014] how can i set hybrid mode by default for coq? [Fri May 23 03:09:46 2014] in emacs [Fri May 23 07:44:57 2014] let (S,<=) be an arbitrary partially ordered type, and Max be the set of elements which are maximal in S. can i prove in coq that for every s in S, there exists a maximal element m such that s <= m? [Fri May 23 07:45:13 2014] i feel i need to use the excluded_middle, in order to expose the maximal element [Fri May 23 07:47:43 2014] nvm this is just wrong [Fri May 23 08:19:26 2014] how can i force a definition to always be unfolded in proofs? [Fri May 23 10:13:46 2014] You should post a minimal example, but I’ve got something kind of like what you want using [Hint Unfold] and the [autounfold] tactic. See http://lpaste.net/104516. [Fri May 23 11:45:06 2014] hello. I have found strange behavior in coq. [Fri May 23 11:45:10 2014] but I cannot isolate it. [Fri May 23 11:45:27 2014] and I don't want to put my whole code online [Fri May 23 11:45:42 2014] is anyone willing to look at it? might be a bug. [Fri May 23 11:46:16 2014] (I use the git-version. and it sometimes does not recognize subterms that are there. but also, I have a case in which it does not demand an equality proof.) [Fri May 23 11:46:26 2014] (even though I do a replacement before) [Fri May 23 11:59:47 2014] nevermind. [Fri May 23 12:00:09 2014] what I need to do works now ... everything else ... oh well. [Fri May 23 13:14:08 2014] alkabetz: thank you [Fri May 23 19:10:58 2014] Ahoy. [Fri May 23 19:12:00 2014] How does the proof that the Calculus of Constructions is strongly normalizing go? Does it pretty much go by defining a model in ZFC? [Fri May 23 19:17:42 2014] Related question. The CoC is weaker than ZFC; is there a simple axiom you can add that makes it as strong as ZFC? [Fri May 23 19:50:33 2014] Maybe a transfinite induction axiom would do the trick. Given a well-ordered set, and a function that takes a family of Ts indexed by a truncation of the well-ordered set and returns a T, there's a family of Ts indexed by the entire well-ordered set such that each T is produced by the function applied to all the Ts before it. [Fri May 23 19:53:05 2014] Then, if you wanted to, you could define the von Neumann universe by using the set of all ordinal numbers as your well-ordered set. [Fri May 23 19:53:19 2014] (Obviously, multiple universes will end up getting invoked here.) [Fri May 23 20:58:56 2014] I'm trying to create the following definition: [Fri May 23 20:59:02 2014] http://pastebin.com/mxRbcuZZ [Fri May 23 20:59:08 2014] But Coq complains that [Fri May 23 20:59:17 2014] term "v" has type "if b then nat else unit" [Fri May 23 20:59:23 2014] while it is expected to have type "if b then nat else unit". [Fri May 23 20:59:28 2014] How can I fix my definition? [Sat May 24 00:43:49 2014] konne: you have a rather subtle bug with a terrible error message [Sat May 24 00:44:07 2014] as always, the first step is to say "Set Printing All." to get coq to stop contradicting itself while printing things to you [Sat May 24 00:44:20 2014] once you do that, you'll see that it's having trouble with Type vs Set [Sat May 24 00:44:47 2014] in this case, the problem is that the if expression is automagically returning a Set where a Type is expected [Sat May 24 00:45:26 2014] the following code works: http://pastebin.com/eW3qsF7u [Sat May 24 14:25:44 2014] hi [Sat May 24 14:26:10 2014] I'd like to unfold an inductive definition, but only unfold one step and don't perform simpl [Sat May 24 14:26:19 2014] I don't find how to do that [Sat May 24 14:31:52 2014] nvm, I might not be possible at all, i should read about delta reduction. I found another way [Sat May 24 17:45:50 2014] Enjolras: yeah cbv delta might help [Mon May 26 05:51:48 2014] Hi. I'd like to know if it's possible to get a proof that the argument of a match is equal to the matched pattern. Thank you in advance. [Mon May 26 06:35:23 2014] Nevermind. I got what I wanted with a Program Definition. [Mon May 26 06:36:40 2014] xaviem02: there's a more verbose way called the "convoy pattern", but if you're happy to use Program... [Mon May 26 06:36:44 2014] xaviem02: http://adam.chlipala.net/cpdt/html/MoreDep.html [Mon May 26 06:39:00 2014] xaviem02: essentially, you use extra annotations on the match expression and effectively pass equality proofs to each case of the match [Mon May 26 06:39:36 2014] can obviously use this to mark "unreachable" cases by refuting the equality proofs in the cases that are supposed to be unreachable [Mon May 26 06:39:47 2014] i think Program does these refinements by itself [Mon May 26 07:02:13 2014] rmk0: Thank you :) [Mon May 26 15:56:34 2014] does anyone have a good understanding of why a Coinductive definition of eq is not satisfactory for proving equalities of coinductive datatypes? [Mon May 26 15:57:49 2014] it seems to relate to how judgemental equality does not unfold cofix unless they are being consumed [Mon May 26 17:35:06 2014] Ptival: what do you mean by "a Coinductive definition of eq"? [Mon May 26 17:35:43 2014] cofixes are unfolded lazily when applied to a match [Mon May 26 17:36:40 2014] robbert: I mean, take the greatest fixed point of Coq's eq definition [Mon May 26 17:37:15 2014] For non-recursive data types, being inductive or coinductive does not matter [Mon May 26 17:38:08 2014] Coinductive ceq {A} (x : A) : A -> Prop := crefl : eq x x. is equivalent to the ordinary eq (easy exercise to prove) [Mon May 26 17:41:07 2014] robbert: to prove in Coq or to meta-prove? [Mon May 26 17:41:38 2014] To prove in Coq [Mon May 26 17:41:58 2014] interesting :) [Mon May 26 17:43:47 2014] The proof is a one-liner :) [Mon May 26 17:47:06 2014] http://paste.awesom.eu/2Zz5 like this? [Mon May 26 17:48:03 2014] Yes, or just [now split; destruct 1.] :). [Mon May 26 17:48:41 2014] ok [Mon May 26 17:49:10 2014] that's a bit surprising to me [Mon May 26 17:49:34 2014] But anyway, now that you have this, the argument that bisimarity does not implies Coq's equality eq, is the same for bisimilarity w.r.t your coinductive eq type [Mon May 26 17:49:55 2014] yes [Mon May 26 17:50:06 2014] Well, basically, taking the greatest or least fixpoint over a constant functor is the same [Mon May 26 17:50:17 2014] yeah [Mon May 26 17:50:18 2014] So, if a data type is not recursive, coinductive and inductive are the same [Mon May 26 17:51:22 2014] I'm trying to understand how propositional equality captures more than judgemental :\ [Mon May 26 17:52:10 2014] By the way, there are some people that define records like [CoInductive foo := Foo { bar : nat }.] [Mon May 26 17:52:40 2014] that way you do not mess up your namespace with garbage induction principles :) [Mon May 26 17:53:42 2014] robbert: ? CoInductive does not seem to generate principles [Mon May 26 17:53:51 2014] oh I see [Mon May 26 17:53:57 2014] you mean when they actually want an inductive [Mon May 26 17:54:27 2014] No, I mean, it does not matter :) And since the induction principles for records are useless, you may as well avoid generating them [Mon May 26 17:55:03 2014] But for coinductive types, both propositional equality and judgmental equality are generally too weak [Mon May 26 17:55:27 2014] You cannot prove [map suc zeroes = ones] for example [Mon May 26 17:55:36 2014] oh I meant, even in the inductive case now [Mon May 26 17:56:24 2014] Uhm, you are wondering about the difference between propositional and judgmental equality for inductive types? [Mon May 26 17:56:30 2014] I guess propositional lets you prove that things that aren't syntactically equivalent would reduce to syntacticall-equivalent things in all cases? [Mon May 26 17:56:34 2014] yes [Mon May 26 17:57:00 2014] or rather, how the inductive definition eq captures more equalities than the judgemental I guess? [Mon May 26 17:57:23 2014] Judgmental equality is just algorithmic equality (beta/eta/iota/delta) [Mon May 26 17:57:32 2014] when it seems to simply say that things judgementally equal are propositionally equal :) [Mon May 26 17:58:13 2014] Hence, you do not have that [plus x 1] is judgmentally equal to [plus 1 x] [Mon May 26 17:58:31 2014] Both terms have unequal normal forms [Mon May 26 17:59:19 2014] And indeed, judgmental equality (which is a meta property, by the way) implies propositional equality [Mon May 26 18:00:08 2014] That is by the conversion rule, which states that if [M : A], [A : some sort], and [A] judgmentally equal to [B], then [M : B] [Mon May 26 18:13:46 2014] robbert: my current interrogation is of the form "how is it that the fixed-point of the eq definition contains eq (plus x 1) (plus 1 x)" [Mon May 26 18:16:28 2014] i.e. how is the set of things judgementally equal not a fixed point? [Mon May 26 18:31:10 2014] oh maybe it doesn't, but you can start using the other rules of the proof system to make judgementally equal things appear? [Tue May 27 04:05:21 2014] Ptival: what do you mean by "the fixed-point of the eq definition" [Tue May 27 04:06:06 2014] Anyway, the reason is indeed that you can use other rules of the system (in particular induction) to prove equalities [Tue May 27 05:14:41 2014] is it possible to rewrite an assumption? [Tue May 27 05:19:49 2014] schoppenhauer: do you mean perform a rewrite in an assumption's type? [Tue May 27 05:38:44 2014] Ptival: yes. [Tue May 27 15:44:42 2014] schoppenhauer: isn't it just 'rewrite H1 in H2.'? [Tue May 27 15:55:56 2014] Ptival: thy. [Tue May 27 15:55:58 2014] *thx [Wed May 28 09:41:36 2014] how do i copy a hypothesis? [Wed May 28 09:41:57 2014] for example duplicate H to H and H_copy [Wed May 28 09:44:07 2014] nevermind ill just use cut [Wed May 28 13:03:15 2014] roo [Wed May 28 13:03:18 2014] erf [Wed May 28 13:09:32 2014] bonk [Wed May 28 13:21:31 2014] The sound of glass breaking. [Thu May 29 05:34:58 2014] if i have x <-> y [Thu May 29 05:35:04 2014] is it possible to prove that x = y [Thu May 29 05:35:05 2014] ? [Thu May 29 05:35:25 2014] for general x/y, no [Thu May 29 05:35:30 2014] ok but in some cases? [Thu May 29 05:35:38 2014] sure [Thu May 29 05:35:55 2014] i have this equivalence between relations [Thu May 29 05:36:02 2014] MultisetGt (transp l_Lt) <-> MultisetGT (transp l_Lt) [Thu May 29 05:36:14 2014] and would like to use this to prove this subgoal MultisetGt (transp l_Lt) = MultisetGT (transp l_Lt) [Thu May 29 05:36:31 2014] you don't need the equivalence, your subgoal is true by reflexivity.... [Thu May 29 05:36:54 2014] note one is large T one is small t [Thu May 29 05:37:03 2014] oh oopsies [Thu May 29 05:37:12 2014] yea :p [Thu May 29 05:37:21 2014] You probably need univalence [Thu May 29 05:37:29 2014] whats that? [Thu May 29 05:37:51 2014] it says if A is isomorphic to B, then A = B [Thu May 29 05:37:52 2014] roosbeef: what's the type of these objects? [Thu May 29 05:38:18 2014] you need extra conditions to hold on <-> [Thu May 29 05:38:22 2014] MultisetGt (transp l_Lt) : Multiset -> Multiset -> Prop [Thu May 29 05:38:47 2014] ezyang, how do i figure if they are isomorphic? [Thu May 29 05:38:58 2014] what if you had functional extensionality ? [Thu May 29 05:39:10 2014] whats that? [Thu May 29 05:40:37 2014] roosbeef: http://pastie.org/9234139 (taken from Equiv chapter of the software foundations book) [Thu May 29 05:41:11 2014] i'm new to coq, so i'm not sure if that's what you need [Thu May 29 05:42:30 2014] hm.. in all honesty i dont see how that would help [Thu May 29 05:44:16 2014] ok there are some Morphisms in the library that provides the relations [Thu May 29 05:44:29 2014] ezyang: would that help? [Thu May 29 05:44:34 2014] roosbeef: if i understood correctly, you know: forall m1 m2, MultisetGt (transp l_Lt) m1 m2 = MultisetGT (transp l_Lt) m1 m2 [Thu May 29 05:45:25 2014] Yes, funexst is exactly what the doctor ordered, except you still might have trouble proving equalities in Prop [Thu May 29 05:45:25 2014] that is not correct [Thu May 29 05:45:29 2014] oh wait, maybe rather: forall m1 m2, MultisetGt (transp l_Lt) m1 m2 <-> MultisetGT (transp l_Lt) m1 m2 [Thu May 29 05:45:36 2014] eizo: yep [Thu May 29 05:45:50 2014] ezyang, why? [Thu May 29 05:46:12 2014] roosbeef: you need to deduce from that that they're equal, and they apply funexst [Thu May 29 05:46:23 2014] whats funexst? [Thu May 29 05:46:29 2014] functional extensionality [Thu May 29 05:46:49 2014] how do i do that [Thu May 29 05:48:49 2014] how are Morphisms employed? [Thu May 29 05:48:57 2014] i don't know, maybe there is an axiom that you can add to coq which says: forall p1 p2 : Prop, (p1 <-> p2) -> p1 = p2, but that seems a bit strong [Thu May 29 05:49:17 2014] why do you need to prove that MultisetGt (transp l_Lt) = MultisetGT (transp l_Lt)? and what do you mean by equality here? [Thu May 29 05:49:21 2014] funext is an axiom [Thu May 29 05:49:26 2014] because i want to rewrite one to the other [Thu May 29 05:49:30 2014] it states (forall x, f x = f' x) -> f = f' [Thu May 29 05:50:46 2014] roosbeef: why do you need to rewrite? is it not enough to use the prop equivalence for all m1 m2? [Thu May 29 05:50:54 2014] well, [Thu May 29 05:51:04 2014] i have a lemma for one but not for the other [Thu May 29 05:51:12 2014] and i want to apply that lemma to the other [Thu May 29 05:51:17 2014] so i need a bridge from one to the other [Thu May 29 05:51:28 2014] roosbeef: can you post the lemma? [Thu May 29 05:51:32 2014] sure [Thu May 29 05:52:33 2014] Lemma mord_sorder : strict_order MultisetGt. [Thu May 29 05:53:02 2014] and i need transitive MultisetGT, i guess [Thu May 29 05:54:13 2014] could you post more context, on a pastebin if possible [Thu May 29 05:54:34 2014] i could but do you really need more? [Thu May 29 05:55:10 2014] http://color.inria.fr/doc/CoLoR.Util.Multiset.MultisetOrder.html [Thu May 29 05:55:14 2014] its from this lib [Thu May 29 05:57:24 2014] suppose id give funext a try, do i need to Require Import something? [Thu May 29 05:58:16 2014] roosbeef: you can write down the axiom as in the pastebin [Thu May 29 05:58:52 2014] eh [Thu May 29 05:59:03 2014] but thats unproven [Thu May 29 05:59:23 2014] i cant be adding axioms like that [Thu May 29 05:59:49 2014] roosbeef: basically, you want to prove that if two relations are "equivalent" and one is transitive, the other one is transitive too [Thu May 29 05:59:59 2014] yep [Thu May 29 06:00:05 2014] which is true [Thu May 29 06:00:12 2014] given the definition of transitivity: forall x y z:A, R x y -> R y z -> R x z, this doesn't seem hard [Thu May 29 06:00:35 2014] it doesnt? [Thu May 29 06:07:25 2014] roosbeef: http://pastie.org/9234326 [Thu May 29 06:11:00 2014] hm [Thu May 29 06:11:14 2014] did i miss anything? My wifi dropped i guess [Thu May 29 06:24:23 2014] roosbeef: http://pastie.org/9234326 [Thu May 29 06:25:08 2014] interesting :) [Thu May 29 06:25:17 2014] let me have a look at that, thanks! [Thu May 29 06:33:35 2014] roosbeef: if you know R2 x y and R2 y z, you deduce by equivalence that R1 x y and R1 y z, then by transitivity of R1 you deduce R1 x z, and by equivalence you conclude that R2 x z (thus that R2 is transitive) the proof in coq is backwards compare to what i wrote [Thu May 29 06:36:57 2014] compared [Thu May 29 06:43:27 2014] hm [Thu May 29 06:44:04 2014] yea that makes sense [Thu May 29 06:44:30 2014] but why cant it be done directly :p [Thu May 29 06:46:23 2014] roosbeef: you can write down a lemma which says if R1 and R2 are equivalent, and one is a strict order, then the other one too [Thu May 29 06:46:46 2014] similar to what you did, right? [Thu May 29 06:47:38 2014] you don't have to do it again, you just apply this lemma [Thu May 29 06:47:43 2014] (and another one for irreflexivity) [Thu May 29 06:48:22 2014] yea writing the irreflexivity one as we speak :) [Thu May 29 06:51:46 2014] equiv_irreflexivity is defined [Thu May 29 06:51:47 2014] :) [Thu May 29 06:52:52 2014] :) now you should be able to combine the two to define equiv_strict_order [Thu May 29 06:53:49 2014] yep it seems like :) [Thu May 29 06:53:53 2014] thanks very much! [Thu May 29 06:57:23 2014] yw [Thu May 29 07:22:54 2014] it worked! :D [Thu May 29 07:23:08 2014] * does a chair spin [Thu May 29 07:26:44 2014] =) [Thu May 29 09:23:14 2014] hehehe surprise surprise :D [Fri May 30 03:04:19 2014] hello [Fri May 30 07:04:35 2014] ok so i have [Fri May 30 07:04:35 2014] Module FL. Definition A := fletter. End FL. [Fri May 30 07:04:54 2014] how do i make it so that coq can see outside of FL that FL.A. is fletter? [Fri May 30 07:05:28 2014] i know how to do this when the Module has a type, you open the module with Module FL : Type with Definition A := fletter. [Fri May 30 07:05:38 2014] but how do i do the same thing when a module has no "type"? [Fri May 30 07:14:06 2014] roosbeef: try just “unfold FL.A”? [Fri May 30 07:14:27 2014] with Module FL. Definition A := 1. End FL. [Fri May 30 07:14:52 2014] I can do [Fri May 30 07:14:53 2014] Lemma A_lt_2 : FL.A < 2. unfold FL.A. [Fri May 30 07:16:21 2014] let me see [Fri May 30 07:16:59 2014] lol [Fri May 30 07:17:02 2014] yea that works :P [Fri May 30 07:17:08 2014] :-) [Sat May 31 05:08:08 2014] is there a lemma to rewrite "'exists2' x : t , p & q" to "'exists x : t , p /\ q"? [Sat May 31 07:20:53 2014] i have to prove this subgoal: https://privatepaste.com/8ce9779065 [Sat May 31 07:21:41 2014] because of the ~ ( forall a0, ... ) structure i find it difficult to get to the root of it [Sat May 31 07:21:54 2014] any tips on how to approach this? [Sat May 31 17:09:44 2014] @roosbeef, the lemma you asked for can be proven in the following way [Sat May 31 17:09:59 2014] https://www.irccloud.com/pastebin/8MMyrKm0 [Sun Jun 1 22:39:08 2014] Is there any automated way to enumerate the elements of an inductive type? I want to check my answer for type baz in the Poly.v file of Software Foundations. [Sun Jun 1 23:12:02 2014] coq 8.3 is failing on the Arguments directive in Software Foundation's Poly.v (as described here: http://stackoverflow.com/questions/23303713/coq-arguments-directive) and 8.4 is failing on Basics.v with the error message "There are pending proofs." Any suggestions for how to move forward? [Sun Jun 1 23:13:31 2014] Oh, and Basics.v runs without errors under 8.4 under Proof General. [Sun Jun 1 23:17:05 2014] Basics.v also runs without errors in CoqIde v8.4, but executing the Software Foundations make file under CoqIde via Compile -> Makefile fails with the same error, "There are pending proofs." [Sun Jun 1 23:22:44 2014] Never mind, it was a modification I'd made when playing around with Basics.v. [Sun Jun 1 23:23:41 2014] @coventry, it is generally undecidable to check whether a value is an element of an inductive type. [Sun Jun 1 23:25:22 2014] e.g. you can define an inductive type whose elements are all the Turing Machines that terminate [Sun Jun 1 23:25:54 2014] If you tell us your answer for baz, we can tell you whether it's right or not [Sun Jun 1 23:27:25 2014] I actually don't know how you could proof in coq that there are exactly x elements in baz [Sun Jun 1 23:28:39 2014] konne: Can you give me an example of a definition for an inductive type which doesn't implicitly define an enumeration of its elements? [Sun Jun 1 23:28:55 2014] I suspect it might be impossible [Sun Jun 1 23:32:15 2014] I guess the halting Turing machines definition must be an example, actually. Can you point me at that definition? [Sun Jun 1 23:34:48 2014] Oh, maybe not, but if the definition is enumerable, there can't be a decidable way of estimating when all turing machine expressions of a given length have been enumerated. [Sun Jun 1 23:36:37 2014] " I suspect it might be impossible" was in reference to the provability of elements in baz, not your response [Sun Jun 1 23:38:16 2014] Thanks for clarifying. [Sun Jun 1 23:39:21 2014] for an example, you can take a look at small step semantics of programming languages. e.g. http://www.cis.upenn.edu/~bcpierce/sf/Smallstep.html [Sun Jun 1 23:40:30 2014] Thanks. Probably a bit beyond me right now, but I will keep it in mind when I get to that section. [Mon Jun 2 03:17:55 2014] is there any difference between Z_of_nat and Z_of_nat’ ? [Mon Jun 2 04:19:57 2014] is it possible to unfold only a particular occurence of a function inside a subgoal? [Mon Jun 2 04:22:01 2014] nevermind found it, "at n" [Mon Jun 2 04:22:03 2014] :) [Mon Jun 2 05:42:23 2014] how do i apply the same tactic to multiple subgoals? [Mon Jun 2 05:43:37 2014] you can do semicolon after the thing that produces multiple goals [Mon Jun 2 05:43:46 2014] like “destruct X; apply Y” [Mon Jun 2 05:44:00 2014] but for existing subgoals? [Mon Jun 2 05:44:21 2014] I don’t know whether there’s a way to do that [Mon Jun 2 05:44:23 2014] hmm [Mon Jun 2 05:44:39 2014] such as "all:tactic" [Mon Jun 2 05:44:51 2014] i found this on google: http://www.lix.polytechnique.fr/coq/bugs/show_bug.cgi?id=1805 [Mon Jun 2 05:45:03 2014] guess its still a requested feature? [Mon Jun 2 05:47:36 2014] is there any way to defer the current subgoal? [Mon Jun 2 05:47:45 2014] like, put it at the end? [Mon Jun 2 05:48:04 2014] well [Mon Jun 2 05:48:08 2014] i have three subgoals [Mon Jun 2 05:48:14 2014] and they are all the same [Mon Jun 2 05:48:14 2014] :p [Mon Jun 2 05:48:40 2014] ah i see what youre hinting at [Mon Jun 2 05:48:59 2014] yeah [Mon Jun 2 05:49:02 2014] defer the first subgoal when those three appear, and then apply the tactic after ; [Mon Jun 2 05:49:29 2014] but I’m not sure [Mon Jun 2 05:50:53 2014] I’m not sure. if they’re all the same, why doesn’t ; work? [Mon Jun 2 05:52:44 2014] because theyre not the only new subgoals [Mon Jun 2 05:53:21 2014] ah, ok. “try apply X“ can be useful [Mon Jun 2 05:53:33 2014] or “try (solve (X Y Z))” I think [Mon Jun 2 05:53:40 2014] yea was thinking of that but its a bit ugly imo [Mon Jun 2 05:58:13 2014] yeah, true [Mon Jun 2 06:22:36 2014] lunch timeee [Mon Jun 2 06:22:38 2014] see ya :p [Mon Jun 2 07:55:27 2014] say i have a list in my hypotheses [Mon Jun 2 07:55:40 2014] is it possible to introduce an arbitrary element of this list? [Mon Jun 2 07:55:54 2014] for example pose x : A [Mon Jun 2 07:56:11 2014] which would add x : A and Hx : In x l [Mon Jun 2 07:56:12 2014] ? [Mon Jun 2 07:56:21 2014] (suppose we take some element x from l) [Mon Jun 2 08:01:34 2014] hmm, maybe a lemma “forall xs, xs <> [] -> exists x, In x xs”? [Mon Jun 2 08:03:36 2014] sounds good :) [Mon Jun 2 08:03:40 2014] lemme try that, thanks! [Mon Jun 2 08:03:49 2014] pretty obvious lol [Mon Jun 2 08:04:20 2014] i guess im still confused with direction of reasoning in hypotheses (opposite from the direction of reasoning in subgoals) [Mon Jun 2 08:04:49 2014] most of the time it’s only obvious in retrospect ;-) [Mon Jun 2 08:06:59 2014] haha [Mon Jun 2 08:07:32 2014] yea the solution space can be large :p [Wed Jun 4 07:25:48 2014] {x0 =mul= y0} + {x0 <>mul y0} [Wed Jun 4 07:25:52 2014] is there a lemma for this? [Wed Jun 4 10:18:28 2014] i have subgoal False [Wed Jun 4 10:19:31 2014] roosbeef: show one of your assumptions is false. [Wed Jun 4 10:19:34 2014] can i use this hypothesis to prove that? forall l, In l nil -> exists2 l', In nil & lt l l' [Wed Jun 4 10:19:35 2014] ? [Wed Jun 4 10:19:51 2014] no, it assumes false. [Wed Jun 4 10:20:03 2014] hm [Wed Jun 4 10:20:23 2014] so the assumption is not false? [Wed Jun 4 10:21:03 2014] forall l, In l nil -> exists2 l', In l' nil & lt l l' [Wed Jun 4 10:21:08 2014] fixed* [Wed Jun 4 10:26:20 2014] nope. You can prove that easily with intros ? bad; inversion bad. [Wed Jun 4 10:32:09 2014] hm :< [Wed Jun 4 14:24:56 2014] do we need weak bisimilarity to prove equivalence of λ-terms in STLC, or is bisimilarity enough? [Wed Jun 4 20:00:38 2014] Anomaly: Backtrack.backto 13252: a state with no vcs_backup. Please report. [Wed Jun 4 20:00:40 2014] what to do? [Fri Jun 6 01:01:47 2014] hmm, is there an ltac way to recursively look inside the current goal for anything matching “V_eq_dec _ _” and destruct on it? [Fri Jun 6 01:06:34 2014] amosr: Ltac foo := [Fri Jun 6 01:06:36 2014] match goal with [Fri Jun 6 01:06:38 2014] | [ |- context [ V_eq_dec ?X ?Y ] ] => destruct (V_eq_dec X Y) [Fri Jun 6 01:06:40 2014] end. [Fri Jun 6 01:06:42 2014] [Fri Jun 6 01:06:47 2014] see if that does what you want [Fri Jun 6 01:16:06 2014] jrw: cool, thanks! [Fri Jun 6 01:16:53 2014] amosr: note that that only works if what you want to destruct is in the conclusion of the goal, not any hypothesis [Fri Jun 6 01:17:09 2014] if you want hypotheses too, that's also possible by adding another branch to that ltac match [Fri Jun 6 04:07:48 2014] is there coq syntax for treating an operator as a function? [Fri Jun 6 04:08:10 2014] I'm in a position where I want to use + as nat -> nat -> nat [Fri Jun 6 04:22:21 2014] dalaing: it actually works the other way; + is just a Notation for the plus function [Fri Jun 6 04:23:04 2014] Is there a way to search for the function, given a notation? [Fri Jun 6 04:23:24 2014] I found the functions I was looking for in the Peano module, just wondering for the future [Fri Jun 6 04:23:50 2014] (I should be less lazy and read about all of the various search functions again, been a little while) [Fri Jun 6 04:24:06 2014] currently lurching through SF, for greater context :) [Fri Jun 6 04:27:22 2014] dalaing: Locate, I think [Fri Jun 6 04:27:29 2014] dalaing: Locate "+" will give you notation definitions that use the "+" symbol [Fri Jun 6 04:27:38 2014] ah, quotes :) [Fri Jun 6 04:27:40 2014] thank you both [Fri Jun 6 04:27:51 2014] dalaing: it'll give you a few more of them than you want, but one of them is "plus" :) [Fri Jun 6 05:47:01 2014] suppose i have an inductively defined relation R [Fri Jun 6 05:47:04 2014] which looks something like [Fri Jun 6 05:48:23 2014] Definition R : A -> B -> Prop := R1 x y : R x y | R2 x y : R x y. [Fri Jun 6 05:48:47 2014] suppose we also have transitive R1 and transitive R2 [Fri Jun 6 05:48:54 2014] is it possible to prove from this that transitive R? [Fri Jun 6 06:58:19 2014] ok its possible, had to adjust my definition of R2 a little :p [Fri Jun 6 13:54:50 2014] I’m trying to write a nonempty list type, and I’m having some notation difficulties (http://lpaste.net/105179). Any recommendations? [Fri Jun 6 14:06:23 2014] I don't know camlp4's bastardization of MBE. It probably doesn't know how to identify b as a single terminator for an ellipsised nonterminal. [Fri Jun 6 14:08:17 2014] I also tried [Notation "[ a ; .. ; b ; c ]" := (cons a .. (cons b (singleton c)) .. ).], which Coq allows but it doesn’t parse correctly. [Fri Jun 6 14:09:50 2014] did you try putting it on both high and low priorities for precedence? Maybe that has something to do with it. [Fri Jun 6 14:11:14 2014] I get the same error at level 0 and level 200. [Fri Jun 6 14:15:17 2014] :/ [Fri Jun 6 16:02:32 2014] How can I get a list of currently-open notation scopes? [Sat Jun 7 14:27:13 2014] I have some notation defined for record updates. if I deeply nest this notation coqtop takes quite a while to process. see http://lpaste.net/105241 . does anyone have any ideas about why this is happenning? [Sat Jun 7 14:27:54 2014] as an interesting side note, scaling up n from 7 to 10 causes coqtop to start swapping on a machine with 8gb ram... :D [Sat Jun 7 15:21:53 2014] jrw: Without thinking too hard about it, my first guess is that the types of intermediate terms are very large. [Sat Jun 7 15:22:25 2014] Cale: the *types* of the terms are large? all the intermediate terms should have type foo... [Sat Jun 7 15:24:10 2014] jrw: hmm, it does appear that way [Sat Jun 7 15:24:54 2014] Either foo or nat or some function type like foo -> nat anyway [Sat Jun 7 15:30:26 2014] jrw: It takes a similarly long time when nested the other way (inverting the order of the 'with') [Sat Jun 7 15:31:23 2014] oh, turn off notation display and try printing func [Sat Jun 7 15:31:43 2014] That will explain everything :D [Sat Jun 7 15:32:47 2014] haha, wow. such duplication. many term. [Sat Jun 7 15:33:12 2014] jrw: Of course, it's somewhat to be expected, as 'a' occurs many times on the right hand side of your notation. [Sat Jun 7 15:33:51 2014] cool. I can probably force sharing using a let or something [Sat Jun 7 15:34:15 2014] It would likely be better to define functions for setting each of the fields, and then define the notations to be applications of those functions [Sat Jun 7 15:36:59 2014] that's probably true. thanks for your help, Cale. [Sat Jun 7 15:37:52 2014] No problem [Sat Jun 7 18:08:32 2014] how can i define transform_set in the following? http://pastie.org/9269276 [Sat Jun 7 18:12:03 2014] eizo: can you say more about what you want it to mean? [Sat Jun 7 18:13:21 2014] jrw: yes, you're given some a's, and by applying the hypothesis, you know for every a, there is b with Pred a b, so you can contruct that way a bunch of b's (i want these ones) [Sat Jun 7 18:15:06 2014] i should start by defining a function A -> B, which given an a, construct the corresponding B [Sat Jun 7 18:15:19 2014] that sounds like a good start [Sat Jun 7 18:17:11 2014] jrw: http://pastie.org/9269298 why can't i destruct (transform a) here? [Sat Jun 7 18:19:43 2014] eizo: good question. [Sat Jun 7 18:21:00 2014] I guess you're trying to use a Prop (the exists...) to define something that is computationally relevant [Sat Jun 7 18:21:12 2014] why not change transform to be of type A -> B? [Sat Jun 7 18:21:32 2014] and then include an extra hypothesis that says forall a, Pred a (transform a) [Sat Jun 7 18:21:54 2014] jrw: in my real file 'transform' is a theorem [Sat Jun 7 18:21:57 2014] hm [Sat Jun 7 18:22:37 2014] eizo: implement the proof of the theorem as a program of type A -> B [Sat Jun 7 18:23:35 2014] i'll try the first idea thanks [Sat Jun 7 20:38:54 2014] Hey, I was wondering if there's a simple way to describe how the induction functions are generated from inductive definitions. [Sun Jun 8 01:08:13 2014] how can I get coq-SearchAbout in Proof General to search terms from other files that I've required (and perhaps transitively required)? [Sun Jun 8 01:27:12 2014] for example, Foo Require's Bar, but when I am working in Foo, C-c C-a C-a only matches against theorems in Foo, and not from Bar [Sun Jun 8 09:30:19 2014] is xor available in coq? [Sun Jun 8 09:43:34 2014] Is it alright to ask Proof General questions in here? I want to prevent it from ever making new Emacs frames. [Sun Jun 8 10:18:46 2014] Athas: best to just ask... [Sun Jun 8 10:18:55 2014] (i don't use proof general) [Sun Jun 8 10:19:59 2014] I use it very superficially. [Sun Jun 8 12:22:00 2014] Does the standard library predefine simple algebraic laws for natural numbers (like commutativity, the distributive law, etc)? [Sun Jun 8 12:22:24 2014] I'm using the 'nat' type. [Sun Jun 8 12:25:29 2014] Athas: http://coq.inria.fr/V8.1/stdlib/Coq.Arith.Plus.html [Sun Jun 8 12:25:55 2014] http://coq.inria.fr/V8.1/stdlib/Coq.Arith.Mult.html [Sun Jun 8 12:27:48 2014] Nice, thanks. [Sun Jun 8 18:49:26 2014] What is a good book on denotational semantics? (That uses lambda or typed lambda) [Sun Jun 8 19:01:13 2014] denotational semantics is dead. [Sun Jun 8 19:01:22 2014] I read that as "demotivational semantics". [Sun Jun 8 19:02:39 2014] I mean that in terms of its usefulness. Denotational semantics stagnated until Abramsky came up with game semantics, which have been superceded by the more intuitive construction of Kripke logical relations and operational semantics. [Sun Jun 8 19:03:26 2014] Perhaps Appel's new book on program logics is a place to look. [Sun Jun 8 19:03:42 2014] I haven't read it myself, but I know the general gist of the work. [Sun Jun 8 19:05:40 2014] ianjneu: reading papers on FP, gives the insight that denotational semantics are still widely used. [Sun Jun 8 19:07:14 2014] dreams: outside Haskell? [Sun Jun 8 19:07:35 2014] ianjneu: nope. [Sun Jun 8 19:07:50 2014] ianjneu: I am talking about papers from the 90s. [Sun Jun 8 19:08:06 2014] I'm talking about the last 5-10 years. [Sun Jun 8 19:08:13 2014] sorry I meant *were* widely used. not still. [Sun Jun 8 19:09:27 2014] ianjneu: well, the 90s papers for Haskell are golden for me, and so I am trying to break into denotational semantics (coming from operational semantics background). If there is a good read, please guide. [Sun Jun 8 19:09:36 2014] Ya, a problem with PL papers is that they often present toys that use weak proof techniques, then promise the world that it must be able to scale to more features like effects. That ends up not happening. [Sun Jun 8 19:10:14 2014] Gunter is what people in my lab point to. [Sun Jun 8 19:10:34 2014] ISBN 0-262-07143-6 [Sun Jun 8 19:10:45 2014] Wiskel is another. [Sun Jun 8 19:10:52 2014] ianjneu: Thanks a lot. [Sun Jun 8 19:10:54 2014] ISBN 0-262-73103-7 [Sun Jun 8 19:11:16 2014] See also Sampson Abramsky's dissertation. [Sun Jun 8 19:11:52 2014] Winskel has lecture notes online: http://www.cl.cam.ac.uk/~gw104/dens.pdf [Sun Jun 8 19:12:55 2014] ianjneu: Great, I will check them out. Any thoughts on the "The Scott-Strachey Approach to Programming Language Theory" book? [Sun Jun 8 19:13:58 2014] I haven't read that book. I think Strachey started doing work in environmental bisimulations, but I might be mistaken. [Sun Jun 8 19:14:16 2014] Scott on semantics is old-hat. Love the guy, but he's done. [Sun Jun 8 19:15:57 2014] Ah. I heard its out-dated. Though I never didn't know that denotational semantics are dead. I am surprised. [Sun Jun 8 19:17:26 2014] ianjneu: Which kind of formal semantics are widely used now? [Sun Jun 8 19:17:44 2014] Haskellers that haven't even used denotational semantics to prove something will likely refute their demise, but for people trying to actually prove things, denotational semantics are too cumbersome and underpowered to help. [Sun Jun 8 19:18:56 2014] Derek Dreyer, Lars Birkedal (Scott's successor), Amal Ahmed et. al. have done the most impressive work on logical relations for proving program equivalences. [Sun Jun 8 19:19:33 2014] The underlying semantics are I believe small-step reduction semantics a la Felleisen. [Sun Jun 8 19:19:50 2014] long live syntactic! [Sun Jun 8 19:19:51 2014] so natural semantics? [Sun Jun 8 19:20:19 2014] Ah wait you mean sos. [Sun Jun 8 19:20:50 2014] dreams: natural semantics is a mistaken term that denotes big step semantics. Big step is problematic and has been largely abandoned for small-step. [Sun Jun 8 19:20:54 2014] No, not sos. [Sun Jun 8 19:21:22 2014] Evaluation contexts reify the control structure that is implicit in sos derivations. [Sun Jun 8 19:21:30 2014] additionally in big-step. [Sun Jun 8 19:22:44 2014] I see. [Sun Jun 8 19:23:09 2014] "pretty-big step" is a new technique that is essentially a compiled form of small-step semantics. Many small steps that are bounded by the depth of a term are glommed into one, to make reasoning a bit less symbol-churning. [Sun Jun 8 23:13:19 2014] ianjneu : "parallel" steps or what ? [Sun Jun 8 23:14:21 2014] hm, i suppose not. i suppose they would be successive steps on some path .. [Mon Jun 9 00:01:15 2014] in Emacs, does anyone know how to search for theorems in any required file, and not just the current one? [Mon Jun 9 00:45:28 2014] johnw: in my experience SearchAbout does something like that. but I usually "Require Import" instead of just "Require"... [Mon Jun 9 00:45:44 2014] I'm specifically working with Software Foundations [Mon Jun 9 00:45:53 2014] I go to Prop.v and evaluate to a certain point [Mon Jun 9 00:46:01 2014] then I search for a term when I know was in List.v [Mon Jun 9 00:46:07 2014] but I have no way of finding it without grep at the console [Mon Jun 9 05:42:19 2014] hy [Mon Jun 9 05:43:04 2014] suppose we have an Inductive R [Mon Jun 9 05:43:23 2014] which says something like case : forall y, some_property y [Mon Jun 9 05:43:50 2014] :p [Mon Jun 9 05:44:10 2014] wait let me be a bit more clear on that description [Mon Jun 9 05:48:44 2014] ok [Mon Jun 9 05:48:53 2014] ive got this https://privatepaste.com/35b64e2c8c [Mon Jun 9 05:49:07 2014] basically, the thing to prove is what the inductively defined assumption states [Mon Jun 9 05:49:08 2014] but [Mon Jun 9 05:49:15 2014] when i do inversion on that assumption [Mon Jun 9 05:49:27 2014] the universal quantifiers become disconnected [Mon Jun 9 05:49:36 2014] how can i make it so that they match? [Mon Jun 9 07:03:14 2014] got it :) [Mon Jun 9 07:04:04 2014] brackets in the inductive definitions were too narrow [Mon Jun 9 13:03:56 2014] bit of a (probably easy) theoretical question [Mon Jun 9 13:04:44 2014] I understand how indexed sums generalise binary products to the dependent case [Mon Jun 9 13:05:16 2014] likewise I for indexed products and dependent functions [Mon Jun 9 13:06:10 2014] now I was reading that implication is a particular case of quantification where variables aren't used [Mon Jun 9 13:07:36 2014] but that I'm having more trouble making sense of [Mon Jun 9 13:09:12 2014] is there some set theoretical interpretation that helps clarify the meaning [Mon Jun 9 13:09:32 2014] with implication denoting functions between sets [Mon Jun 9 13:09:41 2014] or will this lead me nowhere? [Mon Jun 9 13:11:04 2014] i.e. I understand that from a logical perspective forall _ : I . B is true as long as there is a witness for I, any witness [Mon Jun 9 13:11:26 2014] and therefore if we prove I, then B is a consequence [Mon Jun 9 15:25:06 2014] Is there any infix notation for "andb x y" ? [Mon Jun 9 15:26:31 2014] inf-groupoid: && [Mon Jun 9 15:26:53 2014] probably will want to say "Open Scope bool." somewhere before you want to use it [Mon Jun 9 15:30:40 2014] Ah! [Mon Jun 9 15:30:43 2014] Thanks! [Mon Jun 9 19:13:53 2014] Is there any tactic that attempts to apply each the available hypothesis exactly once, in all possible orders? [Mon Jun 9 19:45:51 2014] I have a goal of the form "A -> B". "A" has no constructors. How do I say "from A follows anything"? [Mon Jun 9 19:46:26 2014] pyon: one way would be "intros H_a. inversion H_a." [Mon Jun 9 19:47:04 2014] Ah, thanks! [Mon Jun 9 20:09:19 2014] How do I apply a hypothesis to another hypothesis to get a new hypothesis? [Mon Jun 9 20:11:05 2014] pyon: "apply H1 in H2" ? [Mon Jun 9 20:11:22 2014] Ah! [Mon Jun 9 23:03:31 2014] http://i.imgur.com/9nlGPaW.png -- In this Coq session, given "H : level (S n) (Succ t)", I would like to derive "level n t", by pattern-matching on H. How do I do this? [Mon Jun 9 23:26:25 2014] pyon: "inversion H." ? [Mon Jun 9 23:26:39 2014] in general if you post your stuff in plain text people will have an easier time looking at it/playing with it [Mon Jun 9 23:28:06 2014] Ah! Thanks! [Tue Jun 10 01:16:04 2014] So is CoqIDE not smart enough to know that if I say "Definition mytypealias := othertype." that "mytypealias" is an inductive type is "othertype" is? [Tue Jun 10 01:16:23 2014] *jf "othertype" is [Tue Jun 10 01:16:31 2014] Wow, *if [Tue Jun 10 02:34:18 2014] cjenkin1: I'm not sure what you mean by that... you may have to unfold the definition. [Tue Jun 10 07:54:22 2014] how do i pick the left element of a pair? [Tue Jun 10 07:54:32 2014] eg. pair : nat * nat [Tue Jun 10 07:54:35 2014] how would i get the first number? [Tue Jun 10 08:01:20 2014] got it [Tue Jun 10 08:01:22 2014] fst and snd, thanks :) [Tue Jun 10 08:12:48 2014] hello. I need to proof something about a list of lists. The induction would go along the "maximum length of a list in this list". [Tue Jun 10 08:13:04 2014] However, I don't quite understand how to use induction measures. [Tue Jun 10 08:13:17 2014] I can prove that in every step the maximum length gets smaller. [Tue Jun 10 08:13:32 2014] but how can I use this to make coq accept it? [Tue Jun 10 08:14:07 2014] except for using a refinement on a fixpoint on n, and a dependent argument (n = maxlen l) [Tue Jun 10 08:14:18 2014] which is possible, but not ... beautiful. [Tue Jun 10 08:14:55 2014] schoppenhauer: I'll need more specificity to help. [Tue Jun 10 08:16:39 2014] also, give up on beautiful in Coq. [Tue Jun 10 08:22:28 2014] ianjneu: well, I can do a recursion. [Tue Jun 10 08:22:41 2014] ianjneu: and the recursive calls use lists of lists as well. [Tue Jun 10 08:23:27 2014] ianjneu: the only thing I know is that the maximum length will be strictly smaller in every step. [Tue Jun 10 08:35:41 2014] ok, I'll do it the ugly way [Tue Jun 10 08:51:23 2014] so I was reading "certified prog. with dep. types" and got to the section on inductive type and their restricitions [Tue Jun 10 08:51:58 2014] where it explains the positivity requirement in constructor's arguments [Tue Jun 10 08:52:17 2014] to understand why that is so, they give this example [Tue Jun 10 08:52:20 2014] http://lpaste.net/105390 [Tue Jun 10 09:11:47 2014] hello, i'm new to coq and just encountered a problem while following a tutorial to implement the 'nat' Set. [Tue Jun 10 09:12:21 2014] in the tutorial the 'fixpoint plus' was defined as: [Tue Jun 10 09:13:04 2014] Fixpoint plus(a b: nat): nat := [Tue Jun 10 09:13:04 2014] match a with [Tue Jun 10 09:13:04 2014] | O => b [Tue Jun 10 09:13:04 2014] | (S a') => S (plus a' b) [Tue Jun 10 09:13:04 2014] end. [Tue Jun 10 09:14:41 2014] The theorem to prove 'forall n. (plus 0 n)' is by "induction n as [|n'], auto. simpl, rewrite inHn'. auto." [Tue Jun 10 09:15:02 2014] While i tried to define plus in another way: (S a') => (plus a' (S b)) [Tue Jun 10 09:15:34 2014] And i was stuck in the proof of the theorem. [Tue Jun 10 09:16:02 2014] is there any hints? or suggestions? [Tue Jun 10 09:18:12 2014] is there a lemma to infer from a relation's well-foundedness that it must be irreflexive? [Tue Jun 10 09:18:45 2014] shouya, where did you get stuck? [Tue Jun 10 09:19:06 2014] i just don't know how to go on after induction and auto. [Tue Jun 10 09:19:16 2014] 1 subgoals [Tue Jun 10 09:19:16 2014] n' : nat [Tue Jun 10 09:19:16 2014] IHn' : plus n' O = n' [Tue Jun 10 09:19:16 2014] ______________________________________(1/1) [Tue Jun 10 09:19:16 2014] plus (S n') O = S n' [Tue Jun 10 09:19:18 2014] i got this. [Tue Jun 10 09:19:29 2014] f_equal. [Tue Jun 10 09:19:36 2014] assumption. [Tue Jun 10 09:20:05 2014] Print f_equal. [Tue Jun 10 09:20:11 2014] if you want to know why that works [Tue Jun 10 09:20:24 2014] roosbeef: i yet haven't learned that... [Tue Jun 10 09:20:39 2014] haha well thats what i would do :p [Tue Jun 10 09:20:45 2014] i'm completely new :p [Tue Jun 10 09:20:48 2014] welcome :) [Tue Jun 10 09:21:05 2014] roosbeef: okay perhaps i'd continue following the guide :) [Tue Jun 10 09:21:34 2014] haha yea i guess they probably want you to do something else [Tue Jun 10 09:21:52 2014] to be honest my skills with induction are a bit poor [Tue Jun 10 09:21:53 2014] yep but i am too a noob.. [Tue Jun 10 09:22:20 2014] i just touch this thing and start to feel a little bit amazed. [Tue Jun 10 09:22:23 2014] ive been at it for a while now but still a novice, doing my thesis on term rewriting systems [Tue Jun 10 09:22:34 2014] haha its pretty cool right? [Tue Jun 10 09:22:42 2014] roosbeef: really cool. [Tue Jun 10 09:23:21 2014] i started to imagine one day i can proof all the abstract algebra i learned with coq after i got started with it :p [Tue Jun 10 09:24:14 2014] actually i am following this guide: http://kevinjsullivan.org/Courses/Reasoning/L04_Ad_Infinitum.html [Tue Jun 10 09:24:54 2014] however it's not easy to find a novice-friendly tutorial to coq. [Tue Jun 10 09:25:07 2014] shouya : what you could do is prove "forall n m, plus n (S m) = S (plus n m)" beforehand, and then use this to conclude. [Tue Jun 10 09:25:53 2014] Cypi: wow i was just wondering something like that !! [Tue Jun 10 09:26:25 2014] Cypi: cool! thanks. i'd have a try. [Tue Jun 10 09:48:42 2014] shouya: what are you trying to prove? [Tue Jun 10 09:48:58 2014] forall n m, plus n (S m) = S (plus n m) [Tue Jun 10 09:49:00 2014] currently. [Tue Jun 10 09:49:39 2014] for which definition of "plus"? S a' => plus a' (S b)? [Tue Jun 10 09:50:12 2014] yup. this one. [Tue Jun 10 09:50:32 2014] |O => b [Tue Jun 10 09:50:32 2014] |(S a') => (plus a' (S b)) [Tue Jun 10 09:52:44 2014] shouya: i just tried it it's a direct application of the induction hypothesis [Tue Jun 10 09:53:28 2014] what do you mean by 'direct'? [Tue Jun 10 09:54:03 2014] apply IH [Tue Jun 10 09:54:25 2014] hum.. wait. [Tue Jun 10 09:55:11 2014] to be more detailed? [Tue Jun 10 09:55:26 2014] ianjneu: or simple show the code? [Tue Jun 10 09:56:03 2014] for two relations R1 R2, both of which are defined inductively, im trying to prove the following: well_founded R1 -> well_founded R2 [Tue Jun 10 09:56:17 2014] how can i 'unfold' R1 and R2? R2 is actually a special case of R1 [Tue Jun 10 09:56:51 2014] shouya: http://pastebin.com/aJjZPhEP [Tue Jun 10 09:57:48 2014] shouya: induction n; intros; [|simpl;rewrite IHn];reflexivity. [Tue Jun 10 09:58:17 2014] i'm trying to understand it :p [Tue Jun 10 09:58:52 2014] try to understand each step when executing the proof i pasted [Tue Jun 10 09:58:53 2014] roosbeef: By "unfold" I'm guessing your relations aren't definitions but rather things that don't have a reduction rule to expose their bodies? [Tue Jun 10 09:59:07 2014] whats a reduction rule? [Tue Jun 10 09:59:21 2014] roosbeef: delta beta iota zeta [Tue Jun 10 09:59:30 2014] roosbeef: have you tried inversion? [Tue Jun 10 10:00:19 2014] i have tried inversion [Tue Jun 10 10:00:35 2014] but then coq tries to apply that to well_founded i think [Tue Jun 10 10:00:48 2014] wait let me put it on a pastebin, easier to explain [Tue Jun 10 10:02:10 2014] https://privatepaste.com/b0f96b135d [Tue Jun 10 10:02:19 2014] ianjneu: eizo: ooh it's so obvious... [Tue Jun 10 10:02:35 2014] (note: ive implemented Multiset using list fletter) [Tue Jun 10 10:03:01 2014] roosbeef: It's easier when what you paste actually works. [Tue Jun 10 10:03:02 2014] ianjneu: eizo: thanks. btw a stupid question: how to use previously proved theorem in another proof? [Tue Jun 10 10:03:39 2014] ianjneu, that would require you to install CoLoR.. [Tue Jun 10 10:03:40 2014] shouya: refer to it by name the same way you refer to hypotheses. [Tue Jun 10 10:03:48 2014] roosbeef: Blech, okay. [Tue Jun 10 10:04:05 2014] ianjneu: alright, thanks :) [Tue Jun 10 10:04:49 2014] roosbeef: I'm not sure how to help. Too much unknown context. [Tue Jun 10 10:05:00 2014] hm.. [Tue Jun 10 10:05:04 2014] well [Tue Jun 10 10:05:11 2014] if i can somehow expose the bodies of R1 and R2 [Tue Jun 10 10:05:23 2014] that would allow me to point out to coq that they are in fact the same [Tue Jun 10 10:05:55 2014] (as you can see, when Z = nil they are equivalent) [Tue Jun 10 10:06:26 2014] (fl_is_in_fs and in are also equivalent) [Tue Jun 10 10:07:09 2014] hm i need to add transp somewhere but hopefully it got the point accross.. [Tue Jun 10 10:08:03 2014] MSOrd.gtA is MultisetGT (transp fl_Lt), and >A is (transp fl_Lt) [Tue Jun 10 10:08:20 2014] ianjneu, haha sorry i only realize now that there is indeed a lot of context missing :p [Tue Jun 10 10:08:40 2014] should i fix the paste so it has all information? [Tue Jun 10 10:09:00 2014] I still wouldn't be able to step through it without CoLoR [Tue Jun 10 10:09:12 2014] there isnt much to step through though.. [Tue Jun 10 10:09:19 2014] coq wont unfold anything [Tue Jun 10 10:10:06 2014] Error: The type of H is not inductive. [Tue Jun 10 10:11:11 2014] installing CoLoR [Tue Jun 10 10:11:16 2014] haha :P [Tue Jun 10 10:14:54 2014] Is there any type of numbers that can be actually used in practice for computing results, rather than merely prove stuff by induction on the natural numbers? [Tue Jun 10 10:15:35 2014] (i.e., not Peano naturals) [Tue Jun 10 10:23:21 2014] pyon: see Coq.ZArith in the standard library [Tue Jun 10 10:35:33 2014] ystael: Ah! :-) [Tue Jun 10 10:39:44 2014] Are there any facilities for "tweaking a definition" within a section/module/whatever? [Tue Jun 10 10:40:18 2014] I am solving exercises from TaPL, and some of them are of the form "Would theorem Foo still hold if we added/removed one rule to/from Bar?" [Tue Jun 10 11:16:51 2014] pyon: No, in general you cannot redefine existing types or theorems; you must restate the definition with the changes you want and give it a new name. [Tue Jun 10 11:17:21 2014] Ah, well, I guess I have to live with that. [Tue Jun 10 11:50:15 2014] whats a typical approach in proving well_foundedness [Tue Jun 10 11:50:21 2014] somehow i always get stuck at this [Tue Jun 10 11:56:49 2014] both > and < are well_founded right? (on natural numbers) [Tue Jun 10 11:58:15 2014] no¸ only `<' [Tue Jun 10 11:58:56 2014] hm [Tue Jun 10 11:59:42 2014] ah yea, that makes sense i guess :p [Tue Jun 10 13:37:20 2014] I am stuck in the middle of this proof. Could anyone point me in the right direction? -- https://gist.github.com/eduardoleon/ee5dd1ead90e5896de19 (By the way, I did understand the proof from the book, I just... have no idea how to enter it in Coq.) [Tue Jun 10 14:02:09 2014] pyon: commented. [Tue Jun 10 14:08:26 2014] pyon: you need to generalize your induction hypothesis by not introducing t2 until after you say "induction". then you should be able to push the proof through, just a few more cases left after what you had. [Tue Jun 10 14:11:26 2014] jrw: Ah! [Tue Jun 10 14:11:43 2014] ianjneu: Checking out. [Tue Jun 10 14:13:11 2014] jrw: ianjneu: Thanks, you two :-) [Tue Jun 10 14:15:21 2014] np [Tue Jun 10 14:27:07 2014] jrw: So, in general, if a function (theorem) has multiple arguments (premises), the order of the premises matters, even if there is no dependency between them, right? [Tue Jun 10 14:29:22 2014] pyon: yes and it's even worse than that. it matters how soon you intro them (before vs after saying "induction") [Tue Jun 10 14:51:41 2014] It would be nice if function arguments were arranged in a partial order, with only dependent arguments coming after their dependencies. [Tue Jun 10 14:53:16 2014] pyon: how would you call them? (consider a function that takes two natural numbers) [Tue Jun 10 14:54:51 2014] dunno, perhaps something like OCaml's labelled arguments? [Tue Jun 10 14:56:44 2014] Not a bad idea. Positional constructions are a big fucking mess for refactoring. [Tue Jun 10 16:36:48 2014] If my goal is "f x = f y", where f is an injective function (more specifically, a constructor), what tactic do I use to get "x = y" as the new goal? [Tue Jun 10 16:38:03 2014] apply the proof of injectivity. [Tue Jun 10 16:38:17 2014] pyon: ^ [Tue Jun 10 16:38:39 2014] or f_equal [Tue Jun 10 16:39:02 2014] f_equal is actually the right tactic here. [Tue Jun 10 16:39:13 2014] doesn't one usually prove a = b -> f a = f b? [Tue Jun 10 16:39:36 2014] Ah. [Tue Jun 10 16:39:47 2014] johnw: that is functoriality of identity, which always holds. [Tue Jun 10 16:39:51 2014] ah, o [Tue Jun 10 16:40:16 2014] It's also known as "the rule of Leibniz" for what defines a function. [Tue Jun 10 16:40:40 2014] Gottlieb was the man. [Tue Jun 10 16:40:43 2014] congruence? [Tue Jun 10 16:40:53 2014] I use "cong" in Agda for that situation [Tue Jun 10 16:41:15 2014] TIL f_equal. YIL injection. :-P [Tue Jun 10 16:41:17 2014] congruence is more general to equivalence relations. [Tue Jun 10 16:42:08 2014] pyon: f_equal is a built-in tactic for applying johnw's proposition to any arity of function. [Tue Jun 10 16:42:51 2014] well, not built-in, but needs to use raw Ocaml and the plugin framework to generalize to any arity. [Tue Jun 10 16:44:27 2014] Ah! [Tue Jun 10 16:46:58 2014] pyon: is your name supposed to be the Japanese onomatopoeia for hop? [Tue Jun 10 16:48:45 2014] yea [Tue Jun 10 16:50:19 2014] Mmm, while proofs can be stepped over, it is hard to tell what they mean without stepping over them. [Tue Jun 10 16:53:40 2014] tactics are an inside-out way to write proofs, whereas Agda's "hole based" way is outside in. Inside out has a hidden shell around each goal, effectively. Neither give both ways to view proof. I share your frustration. [Tue Jun 10 16:57:42 2014] If my current goal matches (the type of) an existing lemma, what tactic do I use? [Tue Jun 10 16:57:55 2014] Is the lemma in your context already? [Tue Jun 10 16:58:08 2014] Or is it somewhere else in your code? [Tue Jun 10 16:58:10 2014] It is not amongst the hypotheses, if that is what you mean. [Tue Jun 10 16:58:32 2014] It is immediately above the theorem I am trying to prove. [Tue Jun 10 16:58:37 2014] Okay. So you want 'exact lemma_name', I think. [Tue Jun 10 16:59:04 2014] (If it were amongst your hypotheses, you’d use 'assumption'.) [Tue Jun 10 16:59:38 2014] Ah! [Tue Jun 10 16:59:40 2014] Thanks! [Tue Jun 10 16:59:58 2014] You’re welcome! [Tue Jun 10 17:00:19 2014] As an aside, if you find yourself typing 'exact my_lemma' a lot, you should consider adding it as a hint. [Tue Jun 10 17:02:55 2014] Ah! [Tue Jun 10 17:07:20 2014] pyon: more precisely, Hint Immediate my_lemma. [Tue Jun 10 17:10:58 2014] What if I find myself using the same tactic a lot? :-O [Tue Jun 10 17:11:06 2014] Or, rather, the same sequence of tactics. [Tue Jun 10 17:11:19 2014] pyon gyang [Tue Jun 10 17:11:46 2014] hehe [Tue Jun 10 17:11:49 2014] pyon: You can define your own tactics: e.g., [Ltac my_tac := tac1; tac2; tac3.] [Tue Jun 10 17:13:48 2014] Does this work even if the intermediate tactics use hypotheses introduced by the preceding ones? [Tue Jun 10 17:13:57 2014] Yes. [Tue Jun 10 17:13:58 2014] I am going to post an example. [Tue Jun 10 17:14:05 2014] Ltac is effectively a macro language. [Tue Jun 10 17:14:34 2014] Ah! [Tue Jun 10 17:30:05 2014] In this script, how would I make a Ltac macro for lines 18 and 19? -- https://gist.github.com/eduardoleon/f4be9c6ad4993c09f265 [Tue Jun 10 17:32:59 2014] Just syntactically, you could do [Ltac foo new old := rewrite <- new in old; inversion old.] [Tue Jun 10 17:33:07 2014] Ah! [Tue Jun 10 17:33:32 2014] The inversion tactic is nice... but there really ought to be some way to make it not pollute the hypotheses with lots of equal things. [Tue Jun 10 17:36:15 2014] inversion foo; subst. usually does the job [Tue Jun 10 17:36:17 2014] I mean, sometimes you need those equal things. [Tue Jun 10 17:36:46 2014] But ==Cypi [Tue Jun 10 17:37:25 2014] Ah! [Tue Jun 10 17:39:18 2014] pyon: You should scan through http://coq.inria.fr/refman/Reference-Manual011.html when you have a chance, just so you know what kinds of wacky stuff you can do in Ltac. [Tue Jun 10 17:40:16 2014] Ah! [Tue Jun 10 18:04:46 2014] In general, single-tactic proofs (a single tactic may be a "compound" one: "foo; bar; baz; ...") are "nicer" than multi-tactic proofs, right? [Tue Jun 10 18:06:21 2014] There are varying schools of thought on this. :) [Tue Jun 10 18:07:36 2014] :-O [Tue Jun 10 18:44:59 2014] Is there any way to step through proofs built using "foo ; bar" and "solve [ foo | bar ]" ? [Tue Jun 10 23:51:01 2014] hmm. if I define “Ltac blah := …” inside a proof, it’s visible after the proof. is there a way to make only local ltacs? [Tue Jun 10 23:53:31 2014] You can put them inside a module. They won’t be local to the proof, but they will be local to the module. [Tue Jun 10 23:54:45 2014] (Or, at least, they’ll only be in the module’s namespace.) [Wed Jun 11 01:35:19 2014] what does it mean generally when my goal turns into n = S n? What principle have I violated? [Wed Jun 11 01:36:42 2014] johnw: It means that some of your hypotheses better be provably insatisfiable. :-P [Wed Jun 11 01:36:54 2014] yeah indeed [Wed Jun 11 01:37:07 2014] johnw: Nothing wrong with provably insatisfiable goals per se. [Wed Jun 11 01:37:40 2014] yeah like it can mean that case in uninhabitable [Wed Jun 11 01:38:17 2014] for example: https://gist.github.com/0dc5726a7b2bfb7105ea [Wed Jun 11 01:38:29 2014] every approach I try, I end up with S (S n) = n, roughly speaking [Wed Jun 11 01:38:53 2014] that link doesnt work for me [Wed Jun 11 01:38:55 2014] "Whoops. We seem to have missed the gist of that gist you were looking for." [Wed Jun 11 01:39:03 2014] https://gist.github.com/0dc5726a7b2bfb7105ae [Wed Jun 11 01:39:10 2014] spell checker reversed the last two letters [Wed Jun 11 01:39:37 2014] oh [Wed Jun 11 01:40:23 2014] ah [Wed Jun 11 01:40:25 2014] yeah [Wed Jun 11 01:40:37 2014] youmight want to prove the result for two lists xs and ys first [Wed Jun 11 01:40:40 2014] I've been at that one for long enough that I'm ready for help :) [Wed Jun 11 01:40:51 2014] cos length is defined recursively on the firt arg i think [Wed Jun 11 01:41:06 2014] you would find it easier if you only performed induction on the first arg [Wed Jun 11 01:41:14 2014] aren't I already applying induction on l? [Wed Jun 11 01:42:36 2014] yeh but l is both the first and second arg to ++ [Wed Jun 11 01:43:10 2014] how do I perform induction on only the first arg? [Wed Jun 11 01:43:27 2014] If he's doing SF, the goal of the exercise is to not use this lemma that says "length (l1 ++ l2) = (length l1) + (length l2)" [Wed Jun 11 01:43:43 2014] ah i see [Wed Jun 11 01:43:50 2014] right [Wed Jun 11 01:43:52 2014] with that it would be trivial [Wed Jun 11 01:44:03 2014] I keep reaching for it and slapping my hand away [Wed Jun 11 01:48:48 2014] What I did at this point was to prove first the reciprocal of app_length_cons, but I'm not sure if it is the intended way... [Wed Jun 11 01:49:16 2014] (since it still comes back to an induction where you have both l1 and l2) [Wed Jun 11 02:39:04 2014] ok, what I was missing was the inverse of app_length_cons [Wed Jun 11 02:39:24 2014] if I have some Theorem a -> b, is there an automated way to transform it into b -> a, if the proof can remain the same? [Wed Jun 11 02:39:41 2014] because to change app_length_cons to app_length_cons_r, all I did was invert the proposition; I didn't have to change the proof at all. [Wed Jun 11 03:15:56 2014] ah i dont think so [Wed Jun 11 03:17:10 2014] cos generally the converse of an implication is not always true [Wed Jun 11 03:17:29 2014] if you have a Theorem a <-> b then you get both directions [Wed Jun 11 03:18:21 2014] in your case its possible that whoever defined app_length_cons as a weaker result than they could have [Wed Jun 11 03:20:28 2014] "johnw: ok, what I was missing was the inverse of app_length_cons" <- isnt that what Cypi said? [Wed Jun 11 03:26:58 2014] what would you call a tactic that looks for contradictory hypotheses like “n <> n” ? [Wed Jun 11 03:27:39 2014] I think I’ll just call it bye_not_eq [Wed Jun 11 03:29:49 2014] ddere: yes :) [Wed Jun 11 04:25:08 2014] amosr: absurd? [Wed Jun 11 05:59:57 2014] hi, a stupid question, again :p [Wed Jun 11 06:00:17 2014] what tactic should i use to prove 'true = false -> true = false'. [Wed Jun 11 06:02:51 2014] simply i can't prove 'true = false' is false. [Wed Jun 11 06:03:20 2014] because 'true = false' is a Prop, while 'false' is a bool value. [Wed Jun 11 06:05:06 2014] how about ... "trivial" [Wed Jun 11 06:05:58 2014] or "intro quak. apply quak." [Wed Jun 11 06:06:17 2014] 'trivial' works but i want to know if i can prove it with 'simpl', 'destruct', and 'rewrite'. [Wed Jun 11 06:06:42 2014] "inversion" probably. [Wed Jun 11 06:06:43 2014] since i am following a guide till which i just learned these three tactics. [Wed Jun 11 06:06:50 2014] "intro Q. inversion Q." [Wed Jun 11 06:06:57 2014] hmm. [Wed Jun 11 06:07:16 2014] "intros Q. rewrite <- Q. reflexivity." [Wed Jun 11 06:07:38 2014] should also work. [Wed Jun 11 06:08:04 2014] hmm... [Wed Jun 11 06:08:13 2014] i'd have a try? [Wed Jun 11 06:08:37 2014] never thought 'true = false' can be used to rewrite goals... :p [Wed Jun 11 06:09:20 2014] works for me. [Wed Jun 11 06:09:22 2014] yup it works. [Wed Jun 11 06:09:47 2014] thanks, i think that's what the guide wants me to use :) [Wed Jun 11 06:09:54 2014] \o/ [Wed Jun 11 06:43:25 2014] shouya : whenever you have A = B, it really means that each time there is A somewhere, you can replace it by B (and conversely). [Wed Jun 11 06:43:36 2014] The fact that A = B is false is irrelevant :p [Wed Jun 11 06:43:41 2014] okay~ [Wed Jun 11 06:44:05 2014] so it doesn't mean i can derive a 'false' from 'A = B'? [Wed Jun 11 06:45:22 2014] Well, if you know A = B and A <> B, then yes, you can most certainly prove False. [Wed Jun 11 06:48:40 2014] ... since A <> B is shorthand for A = B -> False ... [Wed Jun 11 06:49:12 2014] okay. [Wed Jun 11 06:49:25 2014] at least I hope that there is no exception. [Wed Jun 11 06:49:34 2014] it's a little bit weird but still fine :p [Wed Jun 11 06:49:46 2014] weird? [Wed Jun 11 06:50:08 2014] to regard 'A = B' just as a property. [Wed Jun 11 06:50:51 2014] as simply equality and it doesn't derive a value. [Wed Jun 11 06:50:52 2014] huh? [Wed Jun 11 06:51:28 2014] You mean, the fact that "A = B" isn't a boolean? Like "beq_nat n m"? [Wed Jun 11 06:51:46 2014] yup. that's exactly what i mean. [Wed Jun 11 06:51:59 2014] because it is intensional. [Wed Jun 11 06:52:39 2014] yup. [Wed Jun 11 06:52:50 2014] hm. if it was a boolean ... how would you use it for rewriting? [Wed Jun 11 06:53:00 2014] hm. i knew but i still have to get used to that. [Wed Jun 11 06:53:14 2014] so i can derive 'false -> *' is false. [Wed Jun 11 06:53:26 2014] that's basically what i thought. [Wed Jun 11 06:53:28 2014] what's *? [Wed Jun 11 06:53:37 2014] any of true or false. [Wed Jun 11 06:53:48 2014] ah ok. [Wed Jun 11 06:54:00 2014] actually, False -> * is true. [Wed Jun 11 06:54:08 2014] sorry. little mistake. [Wed Jun 11 06:54:13 2014] i mean that. [Wed Jun 11 06:54:53 2014] Yes, be careful with capitalization also: "false -> true" doesn't make sense (these are booleans), whereas "False -> True" does. [Wed Jun 11 06:55:48 2014] can't distinguish with them.. can't i have 'a : bool -> b : bool'? [Wed Jun 11 06:56:02 2014] but only 'a : Prop -> b : Prop'? [Wed Jun 11 06:56:36 2014] okay, it's confirmed/ [Wed Jun 11 06:56:42 2014] ->, by default, is meant between Prop, not between booleans. [Wed Jun 11 06:56:59 2014] okay :) [Wed Jun 11 06:57:41 2014] the intuition that every property can be assigned with a boolean comes from classical logic ... [Wed Jun 11 06:57:58 2014] Also, unformally, you have "not not B -> B" for booleans (if you were to defined implication on booleans), whereas you don't have "~ ~ P -> P" in general [Wed Jun 11 06:57:59 2014] and many mathematicians do not understand why that might not be the ultimate truth. [Wed Jun 11 06:58:05 2014] this ^ [Wed Jun 11 06:59:14 2014] Cypi: why is the difference? [Wed Jun 11 06:59:57 2014] Exactly for what schoppenhauer said. [Wed Jun 11 07:00:14 2014] In classical logic, you have the fact that a property is either true or false. [Wed Jun 11 07:00:31 2014] Not in constructive logic, which is Coq's logic. [Wed Jun 11 07:00:40 2014] hm, and? [Wed Jun 11 07:01:03 2014] Actually, if you're following Software Foundations, it is explained (better than I could do it) in Logic.v [Wed Jun 11 07:01:04 2014] how about properties? [Wed Jun 11 07:01:46 2014] okay, i skipped the first chapter... :p [Wed Jun 11 07:02:24 2014] no. no. it's in the latter chapters. [Wed Jun 11 07:02:47 2014] It's the next one for you I believe [Wed Jun 11 07:02:51 2014] don't worry :p [Wed Jun 11 07:03:22 2014] thanks, i'll read it :) [Wed Jun 11 07:03:46 2014] the reason why we do not want ~ ~ P -> P in general is that we cannot give realizers of this axiom, in general. [Wed Jun 11 07:04:26 2014] what do you mean 'realizer'? [Wed Jun 11 07:04:35 2014] the canonical example of why constructivism is worthwile is the simple classical proof that "there are irrational a and b, such that a^b is rational". [Wed Jun 11 07:04:40 2014] and why we cannot do that? [Wed Jun 11 07:05:01 2014] you say: assome sqrt(2)^sqrt(2) is rational. then we are done. [Wed Jun 11 07:05:21 2014] schoppenhauer: good example. [Wed Jun 11 07:05:23 2014] assume not. then (sqrt(2)^sqrt(2))^sqrt(2)=sqrt(2)^2=2 is and we are also done. [Wed Jun 11 07:05:33 2014] i thought i caught that... [Wed Jun 11 07:05:51 2014] so we can prove that "there exist a b", but we cannot give examples for a and b. [Wed Jun 11 07:06:05 2014] hm. [Wed Jun 11 07:06:45 2014] while in constructive logic, as long as you have computational realizers of your axioms, you will always get a computational realizer of your proof. [Wed Jun 11 07:07:41 2014] so if you prove forall x exists y, then you get a function from the x-s to the y-s (not in coq, because "exists" is a prop, you would need to use {x | ...}, but that has other reasons) [Wed Jun 11 07:08:35 2014] wow. true. [Wed Jun 11 07:09:45 2014] i noted down what you said there :p [Wed Jun 11 07:10:17 2014] amazing... just expanded my outlook. i never thought so deeply. [Wed Jun 11 07:12:12 2014] alright thanks. i got to carry on. i'll be back when i have further questions :) [Wed Jun 11 07:12:34 2014] ++ [Wed Jun 11 12:22:56 2014] I have been stuck with this problem since yesterday. Yesterday I managed to prove that the evaluation strategy of a small language with booleans and if-then-else is deterministic. Now I extended this language with natural numbers, and want to prove that the evaluation strategy of this language is still deterministic. https://gist.github.com/eduardoleon/593666acc0ca56c1a85d [Wed Jun 11 12:22:56 2014] [Wed Jun 11 12:27:56 2014] Oops. Just fixed the paste -- https://gist.github.com/eduardoleon/593666acc0ca56c1a85d [Wed Jun 11 12:27:59 2014] But I am still stuck. [Wed Jun 11 14:18:34 2014] Is there a more elegant way to do what lines 40-44 do here? https://gist.github.com/eduardoleon/593666acc0ca56c1a85d [Wed Jun 11 14:29:36 2014] pyon: a good rule of thumb is that if you have to do inline induction, you should factor it out as a lemma [Wed Jun 11 14:47:38 2014] pyon: did you get an answer? I relocated. [Wed Jun 11 15:03:23 2014] jrw: Ah! [Wed Jun 11 15:03:30 2014] ianjneu: I got a tip. [Wed Jun 11 15:03:39 2014] pyon: I also commented on your gist [Wed Jun 11 15:03:46 2014] Oh, let me see. [Wed Jun 11 15:15:53 2014] How do you write such long sequences of semicolon-separated tactics? [Wed Jun 11 15:16:04 2014] Do you first write them separately and then try to merge them? :-O [Wed Jun 11 15:18:24 2014] pyon: that's my technique. [Wed Jun 11 15:19:08 2014] :-O [Wed Jun 11 15:20:10 2014] it's like when you decide to write a function for something rather than write it all over again. [Wed Jun 11 15:23:58 2014] excuse me for asking a so stupid.. i'm totally confused on how to prove: S n = 1 -> n = 0. [Wed Jun 11 15:24:32 2014] f_equal, perhaps. [Wed Jun 11 15:24:51 2014] what is f_equal? [Wed Jun 11 15:24:59 2014] i'm new to coq. sorry. [Wed Jun 11 15:25:20 2014] Ignore me, that does not work. [Wed Jun 11 15:25:39 2014] shouya: You want [injection] on the hypothesis that [S n = 1]. [Wed Jun 11 15:26:13 2014] i currently only learned intro, induction, destruct, reflexivity, simpl, assert, and rewrite, [Wed Jun 11 15:26:15 2014] Yeah, injection H (that is what the hypotheses was called here) did the trick. :-) [Wed Jun 11 15:26:43 2014] can i solve it solely with these tactics i learned? [Wed Jun 11 15:27:03 2014] Hmm, let me try. [Wed Jun 11 15:30:26 2014] actually i am starting from proving: forall n k k' : nat, n + k = n + k' -> k = k'. [Wed Jun 11 15:31:02 2014] yet i'm stuck here. it looks simple but i have really no idea how to carry on :( [Wed Jun 11 15:33:52 2014] Given a goal "x = y", is there a tactic "apply the same injective function to both sides"? [Wed Jun 11 15:33:58 2014] I can’t do it with only those tactics. I’m able to do it with [injection] or with [symmetry] and a theorem from the standard library. [Wed Jun 11 15:34:26 2014] nope? :( [Wed Jun 11 15:34:33 2014] maybe i'm on the wrong way? [Wed Jun 11 15:34:49 2014] shouy: It might be possible, but I’m not sure how. Are you sure it’s possible using only those tactics? [Wed Jun 11 15:35:00 2014] i don't know. [Wed Jun 11 15:35:02 2014] (e.g., is this a /Software Foundations/ exercise?) [Wed Jun 11 15:35:06 2014] yes. [Wed Jun 11 15:35:13 2014] Which one is it? [Wed Jun 11 15:35:35 2014] proving mult_comm. ( http://www.cis.upenn.edu/~bcpierce/sf/current/Induction.html ) [Wed Jun 11 15:36:35 2014] is there any pastebin-like service that support coq code highlighting? i shall show my work. [Wed Jun 11 15:36:45 2014] shouya: That exercise looks like a different theorem than the one you’ve been trying to prove. [Wed Jun 11 15:36:56 2014] shouya: http://lpaste.net/ [Wed Jun 11 15:41:15 2014] pyon: I don’t think there’s a tactic for ‘apply this injective function to the equality in the goal’, because that would require you to pass the tactic a proof that the function is actually injective [Wed Jun 11 15:41:34 2014] Usually, a function’s injectivity is stated as an auxiliary lemma and then [apply]d [Wed Jun 11 15:41:43 2014] alkabetz: http://lpaste.net/105474 here is it. [Wed Jun 11 15:43:23 2014] pyon: Have a look at http://lpaste.net/105476 [Wed Jun 11 15:46:10 2014] pyon: Have they introduced [assumption] yet? [Wed Jun 11 15:46:16 2014] Er, not pyon. [Wed Jun 11 15:46:24 2014] shouya: Have they introduced [assumption] yet? [Wed Jun 11 15:46:40 2014] alkabetz: nay :( [Wed Jun 11 15:47:47 2014] Okay. ([assumption] says ‘this goal is identical to an assumption I have and therefore true’, but you can get there the same way using [rewrite] and [reflexivity]) [Wed Jun 11 15:48:27 2014] yup. i've met this situation. and i used rewrite and reflexivity :p [Wed Jun 11 15:49:05 2014] I would guess there are a lot of people doing SF this week, in preparation for OPLSS [Wed Jun 11 15:49:43 2014] johnw: no i'm just learning for fun :p i'm just graudated from high school lol [Wed Jun 11 15:49:49 2014] ah, very cool! [Wed Jun 11 15:49:56 2014] great time to do it [Wed Jun 11 15:50:11 2014] johnw: i'm really enjoyin [Wed Jun 11 15:50:12 2014] I wish i had known about stuff like this back in high school [Wed Jun 11 15:50:18 2014] yeah, it's seriously addictive [Wed Jun 11 15:50:50 2014] true. and very immersive. [Wed Jun 11 15:57:22 2014] are you using proof general and prooftree? [Wed Jun 11 15:58:35 2014] shouya: Okay, I found a simpler way for you to be proving this. You do not need to do induction on [m]. [Wed Jun 11 15:58:36 2014] johnw: what are those? [Wed Jun 11 15:58:49 2014] alkabetz: how? [Wed Jun 11 15:58:55 2014] proof general is an interactive theorem prover for Emacs that makes working on proofs much easier [Wed Jun 11 15:59:10 2014] prooftree shows you a graphical representation of your proof as you work on it, so that you don't get lost in sub-goals [Wed Jun 11 15:59:13 2014] shouya: How much of a hint do you want me to give you? [Wed Jun 11 15:59:32 2014] on the branch to 'induction m'. [Wed Jun 11 15:59:40 2014] what should i do next rather than ab induction? [Wed Jun 11 15:59:46 2014] s/ab/an/ [Wed Jun 11 15:59:56 2014] shouya: http://dl.dropbox.com/u/137615/Screen%20Shot%202014-06-11%20at%202.59.15%20PM.png [Wed Jun 11 15:59:59 2014] that's my current desktop [Wed Jun 11 16:01:17 2014] johnw: prooftree looks awesome XD [Wed Jun 11 16:01:24 2014] it's super handy [Wed Jun 11 16:01:35 2014] in Emacs while working on any proof, I type C-c C-d to pop up a prooftree window for that proof [Wed Jun 11 16:01:37 2014] shouya: Go back to [Case "n = S n".]. You don’t need to [simpl]; look again at the theorems above yours in SF and see if anything looks promising. [Wed Jun 11 16:01:40 2014] also, it updates in real time with my typing [Wed Jun 11 16:01:52 2014] johnw: cool, i'd have a look later. currently still using coqide. [Wed Jun 11 16:02:14 2014] alkabetz: thanks, i'd have a try first :) [Wed Jun 11 16:02:44 2014] I’m going to be AFK for a while, would you like me to put my solution on lpaste so you can have a look at it if you get really stuck? [Wed Jun 11 16:05:27 2014] alkabetz: okay :) [Wed Jun 11 16:05:37 2014] alkabetz: thank you very much :) [Wed Jun 11 16:07:27 2014] alkabetz: got it! assert (H: 0 + S n = S n). ! [Wed Jun 11 16:09:54 2014] Wait, is this in your proof for [plus_uniq_r]? [Wed Jun 11 16:11:24 2014] alkabetz: nay. nay. i misread it. [Wed Jun 11 16:11:32 2014] alkabetz: ignore me. [Wed Jun 11 16:17:09 2014] shouya: Well, if you get really stuck, a complete proof script is now at http://lpaste.net/105479. Good luck! [Wed Jun 11 16:17:49 2014] alkabetz: thank you :) have a good night (from my timezone) [Wed Jun 11 16:18:39 2014] Haha, I’m on -0700, so good afternoon :) [Wed Jun 11 16:19:22 2014] i'm on +0800, so it's 4.19 in the morning :p [Wed Jun 11 20:32:19 2014] sa va pas se solidifier tout de suite ; [Wed Jun 11 20:32:24 2014] sa va pas se solidifier tout de suite . [Wed Jun 11 20:32:41 2014] RESPIRE [Wed Jun 11 20:32:49 2014] et détache toi tout seul [Wed Jun 11 20:33:04 2014] tres doucement dans cette boue [Wed Jun 11 20:33:22 2014] le pire à croire la perte de temps [Wed Jun 11 20:33:59 2014] marche jusque la tu y arrivera encore mieu à l'entrainement . [Wed Jun 11 20:35:19 2014] le tronc de bois ici [Wed Jun 11 20:35:35 2014] délicattement dans la boue [Wed Jun 11 20:36:00 2014] u de leau à voir à coté [Wed Jun 11 20:36:06 2014] de leau à voir à coté [Wed Jun 11 20:36:19 2014] ont suveile les pioisson [Wed Jun 11 20:36:22 2014] ont suveile les poisson [Wed Jun 11 20:36:29 2014] ont surveille les poisson [Wed Jun 11 20:36:35 2014] ont surveilles les poisson [Wed Jun 11 20:36:40 2014] ont surveilles les poissons [Wed Jun 11 20:36:44 2014] o.O [Wed Jun 11 20:36:52 2014] dans l'eau [Wed Jun 11 20:36:58 2014] se laver de la boue [Wed Jun 11 20:37:07 2014] Anyone can be op here? [Wed Jun 11 20:37:08 2014] pas les crocodiles [Wed Jun 11 20:38:04 2014] soyez tous attentif à tout le monde . [Wed Jun 11 20:39:31 2014] alerte dans l'eau [Wed Jun 11 20:40:00 2014] crier une seule fois alerte dans l'eau tanp pis si personne à entendu . [Wed Jun 11 20:41:02 2014] de la bouffe la bas [Wed Jun 11 20:41:18 2014] parcontre les machoire serrer avec les nerf [Wed Jun 11 20:41:29 2014] lui faire comprendre de lacher . [Wed Jun 11 20:41:55 2014] ont plaisante c'est un piege [Wed Jun 11 20:42:03 2014] un crocodile au repa [Wed Jun 11 20:42:06 2014] un crocodile au repas [Wed Jun 11 20:42:30 2014] le faire cuire sentire de loin les jaguar [Wed Jun 11 20:42:33 2014] le faire cuire sentire de loin les jaguars [Wed Jun 11 20:43:21 2014] et tous . [Wed Jun 11 20:44:06 2014] bonne appétit crocodile [Wed Jun 11 20:44:18 2014] tu a entendu [Wed Jun 11 20:44:43 2014] la riviere est plein d'eau . [Wed Jun 11 20:45:02 2014] la tete se mange [Wed Jun 11 20:45:07 2014] ont laisse rien [Wed Jun 11 20:45:29 2014] quel bonne appétie cette aliguatore [Wed Jun 11 20:45:30 2014] Nope, neither channel op is on right now. :P [Wed Jun 11 20:46:19 2014] ont pourrait le secher la viande avec du sel . [Wed Jun 11 20:46:37 2014] les proteine . [Wed Jun 11 20:46:41 2014] les proteines . [Wed Jun 11 20:47:01 2014] etant doner que l'estomcs décompose tout [Wed Jun 11 20:47:09 2014] les genes nous revienne pas [Wed Jun 11 20:47:18 2014] un peut de science à savoir . [Wed Jun 11 20:48:11 2014] etant doner que l'estomac décompose tout [Wed Jun 11 20:48:13 2014] les genes nous revienne pas [Wed Jun 11 20:48:17 2014] les genes nous reviennes pas [Wed Jun 11 20:48:28 2014] un peu de science à savoir . [Wed Jun 11 20:49:17 2014] le crocodile vous mange par surprise [Wed Jun 11 20:49:45 2014] dieu à bien fait à eux cloulé son bec avec un peu de force . [Wed Jun 11 20:50:10 2014] le trainé ici maintenant [Wed Jun 11 20:50:12 2014] tous [Wed Jun 11 20:50:27 2014] dieu à bien fait à eux cloué son bec avec un peu de force . [Wed Jun 11 20:50:52 2014] petit soyons à coté c'est un talent [Wed Jun 11 20:51:16 2014] le zbre est complement décapité [Wed Jun 11 20:51:38 2014] petit comme une sourrie elle conserve sa forme . [Wed Jun 11 20:51:43 2014] I just used ignore... everything tis deathly quiet now.. :P [Wed Jun 11 20:52:44 2014] il est mort [Wed Jun 11 20:52:49 2014] pas l'autre [Wed Jun 11 20:53:25 2014] son dentier au fond de la bouche est de la peau [Wed Jun 11 20:53:34 2014] osé sert queleque fois [Wed Jun 11 20:54:14 2014] des ose ossi acséder à la boite cranier avec son couteau éguisé dans l'au . [Wed Jun 11 20:54:17 2014] des ose ossi acséder à la boite cranier avec son couteau éguisé dans l'eau . [Wed Jun 11 20:54:28 2014] des ose ossi acséder à la boite cranien avec son couteau éguisé dans l'eau . [Wed Jun 11 20:55:02 2014] et léquipe qui doit savoir usé de son intelligence au mieu aidé [Wed Jun 11 20:55:22 2014] remonté assez vite [Wed Jun 11 20:55:48 2014] une bouché d'air à coté de tous [Wed Jun 11 20:55:52 2014] les canibale [Wed Jun 11 20:55:55 2014] les canibale s [Wed Jun 11 20:55:57 2014] les canibales [Wed Jun 11 20:56:00 2014] pas nous . [Wed Jun 11 20:56:15 2014] tiré le deuxieme [Wed Jun 11 20:56:21 2014] qui tient l'autre [Wed Jun 11 20:56:30 2014] plus de peur que de mal . [Wed Jun 11 20:56:51 2014] reprenons notre nourriture une autre fois [Wed Jun 11 20:57:40 2014] pas mal osé [Wed Jun 11 20:57:49 2014] les court sont théorique [Wed Jun 11 20:57:56 2014] pas pour rien . [Wed Jun 11 20:58:04 2014] les cours sont théorique [Wed Jun 11 20:58:09 2014] les cours sont théoriques [Wed Jun 11 20:58:11 2014] pas pour rien . [Wed Jun 11 20:58:46 2014] osé le faire plustot que se sauvez comme un animale [Wed Jun 11 20:59:16 2014] pas mal il vous a pas mordu [Wed Jun 11 20:59:22 2014] et s'était rapide [Wed Jun 11 20:59:35 2014] les crocodile ont manger l'autre [Wed Jun 11 20:59:40 2014] les crocodiles ont manger l'autre [Wed Jun 11 20:59:50 2014] il y en avait plein [Wed Jun 11 21:00:00 2014] il faudrai savoir ou s''est [Wed Jun 11 21:00:04 2014] il faudrai savoir ou s'est [Wed Jun 11 21:01:15 2014] une chance parmis plusieurs de lui coulé le bec [Wed Jun 11 21:01:24 2014] c'est de la théorie ça aussi . [Wed Jun 11 21:01:34 2014] une chance parmis plusieurs de lui cloué le bec [Wed Jun 11 21:02:27 2014] saut perrieux en erriere dans leau . [Wed Jun 11 21:02:35 2014] saut perrieux en arriere dans leau . [Wed Jun 11 21:03:18 2014] il mort lea ce stupide animale à ce moment lui bouclé sa face . [Wed Jun 11 21:03:33 2014] dans l'au il sait nagé . [Wed Jun 11 21:03:43 2014] il respire pas . [Wed Jun 11 21:04:03 2014] j suit à coté pas de panique . tu respire pas . [Wed Jun 11 21:04:30 2014] son cerveau est sa boite cranien . un couteau de guerre . [Wed Jun 11 21:04:37 2014] tourné [Wed Jun 11 21:05:06 2014] sauvons nous de la , . [Wed Jun 11 21:05:11 2014] pour l'instant [Wed Jun 11 21:05:25 2014] le language des signes . [Wed Jun 11 21:05:56 2014] loin la bas [Wed Jun 11 21:06:01 2014] tiré les . [Wed Jun 11 21:06:22 2014] OKAI [Wed Jun 11 21:06:26 2014] DEBOUT [Wed Jun 11 21:06:34 2014] PLUS DE PALME CELLE CI AU SOL [Wed Jun 11 21:10:11 2014] le crocodiles est toujours à craindre [Wed Jun 11 21:10:34 2014] la thhéorie sera jamais suffisant . [Wed Jun 11 21:10:40 2014] la théorie sera jamais suffisant . [Wed Jun 11 21:10:50 2014] la théorie sera jamais suffisant . [Wed Jun 11 21:11:03 2014] avoir peur non [Wed Jun 11 21:11:20 2014] mais savoir quil sait nager et courrir au sol . [Wed Jun 11 21:11:58 2014] etre calme à toujour été mieu . [Wed Jun 11 21:12:05 2014] etre calme à toujours été mieu . [Wed Jun 11 21:12:28 2014] au dessus de la surface la haut [Wed Jun 11 21:12:48 2014] trainer son arme dont les millitaire save pas le lacher [Wed Jun 11 21:13:15 2014] un crocodile à manger . [Wed Jun 11 21:13:20 2014] cuit . [Wed Jun 11 21:13:28 2014] Just wondering... What are you going on about? [Wed Jun 11 21:13:37 2014] dautre moceau à d'autres voir si il sont canibale . [Wed Jun 11 21:13:40 2014] dautre moceau à d'autres voir si il sont canibale .s [Wed Jun 11 21:13:43 2014] dautre moceau à d'autres voir si il sont canibales [Wed Jun 11 21:14:00 2014] s'ils* sont, perhaps? [Wed Jun 11 21:14:17 2014] dautre morceau à d'autres voir si il sont canibales [Wed Jun 11 21:14:32 2014] un crocodile de peche [Wed Jun 11 21:14:37 2014] se nourrir ; [Wed Jun 11 21:14:41 2014] se nourrir. [Wed Jun 11 21:14:58 2014] CUIT AU FEU ; [Wed Jun 11 21:15:15 2014] cuit au feu . [Wed Jun 11 21:18:04 2014] des proteines . [Wed Jun 11 21:18:29 2014] les virus existes que comme des parrasites sauf que ça [Wed Jun 11 21:18:55 2014] possedent une proteine un espace génétique propore . [Wed Jun 11 21:19:00 2014] possedent une proteine un espace génétique propre . [Wed Jun 11 21:19:27 2014] je serait moin bete croire que la théorie est potentiellement existante . de a [Wed Jun 11 21:19:34 2014] je serait moin bete croire que la théorie est potentiellement existante de ça [Wed Jun 11 21:20:15 2014] quatre patte de crocodile en un seul ou mécui . [Wed Jun 11 21:20:22 2014] quatre patte de crocodile en un seul ou méchoui . [Wed Jun 11 21:21:00 2014] combien de personne cinq ? [Wed Jun 11 21:21:09 2014] DEUX CROCODILE POUR LA SOIR2 [Wed Jun 11 21:21:20 2014] DEUX CROCODILE POUR LA SOIRéé$ [Wed Jun 11 21:22:30 2014] ont nous a libré du sel . [Wed Jun 11 21:22:35 2014] ont nous a livré du sel . [Wed Jun 11 21:23:26 2014] un gros morceau de pulet [Wed Jun 11 21:23:31 2014] pas de vache [Wed Jun 11 21:23:39 2014] un gros morceau de poulet [Wed Jun 11 21:23:42 2014] pas de vache. [Wed Jun 11 21:24:04 2014] ont est heureux maintenant [Wed Jun 11 21:24:15 2014] pas triste sauf à faire mine . [Wed Jun 11 21:31:02 2014] manger doucement [Wed Jun 11 21:31:18 2014] comme ceux qui dame peu ou beaucoup avoir le meme poids [Wed Jun 11 21:32:33 2014] je déteste pas la franmaçonnerie à dire comme tous pense des satanique . [Wed Jun 11 21:32:36 2014] je déteste pas la franmaçonnerie à dire comme tous pense des sataniques . [Wed Jun 11 21:32:54 2014] ce que jaimerai pas aussi; . [Wed Jun 11 21:32:58 2014] ce que jaimerai pas aussi . [Wed Jun 11 21:35:31 2014] heuresement [Wed Jun 11 21:35:37 2014] parcontre à la cantine [Wed Jun 11 21:35:44 2014] lesz frittes saller [Wed Jun 11 21:35:48 2014] ont aimes [Wed Jun 11 21:36:05 2014] le steque ont en discute pas vraiment . [Wed Jun 11 21:36:25 2014] les cerises . [Wed Jun 11 21:36:38 2014] manger votre steak [Wed Jun 11 21:36:44 2014] apres les cerises . [Wed Jun 11 21:42:09 2014] le pot de cerise . [Wed Jun 11 21:42:19 2014] le grand pot de cerise ; [Wed Jun 11 21:42:25 2014] le grand pot de cerise . [Wed Jun 11 21:42:56 2014] BASTON DE CERIS ; [Wed Jun 11 21:43:01 2014] BASTON DE CERISe maintenant$ ; [Wed Jun 11 21:43:07 2014] BASTON DE CERISe maintenant$ ; [Wed Jun 11 21:43:34 2014] baston de cerise maintenant . [Wed Jun 11 21:44:50 2014] noyau de cerise . [Wed Jun 11 21:45:47 2014] baston de nayau de cerise . [Wed Jun 11 21:46:04 2014] souflé [Wed Jun 11 21:46:11 2014] loi la bas . [Wed Jun 11 21:46:15 2014] loin la bas . [Wed Jun 11 21:48:39 2014] tipar [Wed Jun 11 21:49:01 2014] noyau de cerise loin la bas [Wed Jun 11 21:49:12 2014] un soufflé [Wed Jun 11 21:52:52 2014] attack . [Wed Jun 11 21:53:12 2014] pleins de cerises .? [Wed Jun 11 21:53:14 2014] pleins de cerises . [Wed Jun 11 21:53:16 2014] pleins de cerises . [Wed Jun 11 21:53:20 2014] pleins de cerises . [Wed Jun 11 21:54:00 2014] un soullet de noyau [Wed Jun 11 21:54:12 2014] et des cerisqes à balençer seulement la bas [Wed Jun 11 21:54:31 2014] et des cerises à balançer seulement la bas [Wed Jun 11 21:58:11 2014] je suit pas le premier à en parler . [Wed Jun 11 21:59:11 2014] des noyeu de cerise meme des cerises entiers . [Wed Jun 11 21:59:55 2014] et le pot de fleur . [Wed Jun 11 22:00:49 2014] et la table . [Wed Jun 11 22:00:56 2014] les chaises . [Wed Jun 11 22:04:18 2014] manger des protein avant les fruits . [Wed Jun 11 22:04:42 2014] LES PROTEIN FRUITUI2 SONT AUSSI DES PROTeine [Wed Jun 11 22:05:04 2014] LES PROTEIN FRUITé SONT AUSSI DES PROTeines [Wed Jun 11 22:05:16 2014] nan ? [Wed Jun 11 22:05:41 2014] cerise [Wed Jun 11 22:06:08 2014] noyaux de cerise à totallement damé . [Wed Jun 11 22:06:22 2014] à l'autre boud de la salle . [Wed Jun 11 22:07:37 2014] fois deux [Wed Jun 11 22:07:40 2014] et trois [Wed Jun 11 22:07:48 2014] et quatre ; [Wed Jun 11 22:07:56 2014] et cind et six [Wed Jun 11 22:08:01 2014] huit neuf dix [Wed Jun 11 22:08:09 2014] et cent . [Wed Jun 11 22:10:56 2014] bataille de noyau de cerise ensuite de cerise simplement et de pot de fleur [Wed Jun 11 22:11:03 2014] la table et les chaises . [Wed Jun 11 22:13:39 2014] quelque camp se sont formé. [Wed Jun 11 22:17:24 2014] soyer labas [Wed Jun 11 22:17:54 2014] mais peureux que je suit pa s vraiment à faire espres si plus jeune du cayak en faite non [Wed Jun 11 22:18:18 2014] mais peureux que je suit pa s vraiment à faire espres si plus jeune du cayak $ [Wed Jun 11 22:18:20 2014] mais peureux que je suit pa s vraiment à faire espres si plus jeune du cayak [Wed Jun 11 22:18:46 2014] en faite non j'était pas peureux [Wed Jun 11 22:19:11 2014] il est compliquer peut etre meme aaujoudrhui de respecter dieu et sa création . [Wed Jun 11 22:19:22 2014] il est compliquer peut etre meme aujoudrhui de respecter dieu et sa création . [Wed Jun 11 22:19:44 2014] cela dit comme un noob [Wed Jun 11 22:19:50 2014] mais pas loin .? [Wed Jun 11 22:19:53 2014] mais pas loin . [Wed Jun 11 22:20:00 2014] cela dit comme un noob mais pas loin . [Wed Jun 11 22:21:11 2014] je déteste pas tellement dieu parler de la création comme darwin dirait des poisson pareil . [Wed Jun 11 22:21:32 2014] ce que par avance son charabia lui appartient . [Wed Jun 11 22:22:45 2014] ce que darwin dirait est totallement nullement en contradiction avec la création de dieu . [Wed Jun 11 22:25:07 2014] je pense pas dire juif la personne qui en est [Wed Jun 11 22:25:22 2014] moise est un film [Wed Jun 11 22:25:53 2014] leetre jeai vu les fourbe et dautres paysages bien mieu éduquer [Wed Jun 11 22:26:33 2014] tres simples de discuer de paysage terrestre . [Wed Jun 11 22:27:14 2014] je suit pas le pote de hitler lui meme brun dire que les blond aux yaux bleu sont meilleur meme ence moment . [Wed Jun 11 22:27:32 2014] je suit pas le pote de hitler lui meme brun dire que les blond aux yux bleu sont meilleur meme ence moment . [Wed Jun 11 22:27:39 2014] je suit pas le pote de hitler lui meme brun dire que les blond aux yeux bleu sont meilleur meme ence moment . [Wed Jun 11 22:28:00 2014] je suit pas le pote de hitler lui meme brun dire que les blond aux yeux bleu sont meilleurs . [Wed Jun 11 22:29:37 2014] ramers: can you stop please? [Wed Jun 11 22:29:51 2014] je parle de ce que je veut [Wed Jun 11 22:29:53 2014] ensuite [Wed Jun 11 22:30:03 2014] parler en français si vous voulez . [Wed Jun 11 22:30:16 2014] j'en ai pas envie [Wed Jun 11 22:30:21 2014] lol. [Wed Jun 11 22:31:37 2014] what made you want to write all that stuff? [Wed Jun 11 22:31:44 2014] what you made [Wed Jun 11 22:31:52 2014] enddin zut [Wed Jun 11 22:32:19 2014] je parles français au thcat je comprends beaucoup de gens qui aime pas le foot encore aujourdhui . [Wed Jun 11 22:33:24 2014] thank you [Wed Jun 11 22:33:28 2014] je parles français au tchat je comprends beaucoup de gens qui aime pas le foot encore aujourdhui . [Wed Jun 11 22:34:22 2014] ja'aime le volley ball et aussi le badblitnone [Wed Jun 11 22:35:37 2014] ja'aime le volley ball et aussi le badblitone [Wed Jun 11 22:36:19 2014] je déteste le bablitone en vrai. [Wed Jun 11 22:37:52 2014] je déteste le bablintone en vrai. [Wed Jun 11 22:38:06 2014] je déteste le bablitone en vrai. [Wed Jun 11 22:38:16 2014] le foot est pire [Wed Jun 11 22:38:34 2014] savoir en période de baccallauréat le tenis . [Wed Jun 11 22:39:05 2014] savoir tote l'anée eduquer sa pose pas de probleme; [Wed Jun 11 22:39:09 2014] savoir tote l'anée eduquer sa pose pas de probleme; [Wed Jun 11 22:39:12 2014] savoir tote l'anée eduquer sa pose pas de probleme. [Wed Jun 11 22:39:23 2014] savoir toUte l'anée eduquer sa pose pas de probleme. [Wed Jun 11 22:39:35 2014] savoir toute l'anée eduquer sa pose pas de probleme. [Wed Jun 11 22:39:48 2014] savoir toute l'année eduquer sa pose pas de probleme. [Wed Jun 11 22:41:39 2014] savoir toute l'année eduquer sa pose pas de probleme. [Wed Jun 11 22:42:16 2014] je félicite à présent les gens mon bete qui passe le baccalauréat bientot. [Wed Jun 11 22:42:36 2014] je félicite à présent les gens moin bete qui passe le baccalauréat bientot. [Wed Jun 11 22:44:19 2014] jaitait un tueur en math et en tout . [Wed Jun 11 22:44:43 2014] de la dire ça à tous . [Wed Jun 11 22:45:53 2014] je sait pas plus aujourdhui comment sappelle les equations complexes; S4EN SOUVENIR comme les profs [Wed Jun 11 22:46:57 2014] PARLER DES POULPES EN CORR2LLATION DANS SE MONDE ; [Wed Jun 11 22:47:00 2014] PARLER DES POULPES EN CORR2LLATION DANS CE MONDE ; [Wed Jun 11 22:47:40 2014] je suit satifait en parler de vous . [Wed Jun 11 22:47:51 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:13 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:14 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:15 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:16 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:17 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:18 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:22 2014] 41 [Wed Jun 11 22:48:23 2014] 41 [Wed Jun 11 22:48:23 2014] 41 [Wed Jun 11 22:48:23 2014] 41 [Wed Jun 11 22:48:23 2014] 41 [Wed Jun 11 22:48:23 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:29 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:48:30 2014] je suit satisfait en parler de vous . [Wed Jun 11 22:49:15 2014] jai eut des bon prof [Wed Jun 11 22:49:24 2014] je peut rien reprocher à moi . [Wed Jun 11 22:49:37 2014] je peut rien reprocher à moi . [Wed Jun 11 22:49:44 2014] jai eut des bon profs [Wed Jun 11 22:49:46 2014] je peut rien reprocher à moi . [Wed Jun 11 22:53:26 2014] meme en otique [Wed Jun 11 22:53:33 2014] meme en optique [Wed Jun 11 22:54:07 2014] je peut absolument rien me reprocher . [Wed Jun 11 22:54:40 2014] c'est la faute d'un tier . [Wed Jun 11 22:54:59 2014] parceque ça aurrait interresser la myonne game . [Wed Jun 11 22:55:10 2014] parceque ça aurrait interresser la moyenne game . [Wed Jun 11 22:55:50 2014] nul est soit pas les profs . [Wed Jun 11 22:56:07 2014] nul est soit pas les profs . [Wed Jun 11 22:58:30 2014] savoit apprendre des math pourrit appréçié faites pas semblant . [Wed Jun 11 22:58:41 2014] savoir apprendre des math pourrit appréçié faites pas semblant . [Wed Jun 11 22:58:47 2014] ou de la biologie . [Wed Jun 11 22:58:57 2014] aussi bien [Wed Jun 11 22:59:22 2014] hi roconnor [Wed Jun 11 22:59:27 2014] fancy seeing you here! [Wed Jun 11 22:59:36 2014] maybe spread some of that power for future needs :) [Wed Jun 11 23:01:45 2014] apprenez enffin [Wed Jun 11 23:01:53 2014] Yeah, ramers has been sitting here spamming for 300-some-odd lines [Wed Jun 11 23:02:04 2014] les profs qui ont été payé par l'éducations nationale les miens . [Wed Jun 11 23:02:15 2014] par rappord au autres [Wed Jun 11 23:02:22 2014] ls intellot alleur [Wed Jun 11 23:02:28 2014] ls intellot ailleur [Wed Jun 11 23:02:43 2014] les intellot alleur [Wed Jun 11 23:02:48 2014] les intellot ailleur [Wed Jun 11 23:08:13 2014] roconnor set flags +o on cale. [Wed Jun 11 23:08:30 2014] roconnor set flags +o on copumpkin. [Wed Jun 11 23:27:29 2014] roconnor set flags +ARfirstv on copumpkin. [Wed Jun 11 23:27:45 2014] roconnor set flags +ARfirstv on cale. [Thu Jun 12 08:57:00 2014] Is there way to partially give the shape of an existential? More precisely, if I'm using "eapply foo." and it introduces some existential ?666, quand I tell Coq that it should be something more precise like "Cons ?666"? [Thu Jun 12 08:57:10 2014] s/quand/can/ [Thu Jun 12 09:54:31 2014] why does inversion not prove that S (S n) <> n? [Thu Jun 12 12:01:30 2014] need some induction too, i'd imagine [Thu Jun 12 14:11:43 2014] schoppenhauer: I've wondered that too, but I have a feeling it would take an induction proof to determine that [Thu Jun 12 14:12:44 2014] yes, with induction it worked. [Thu Jun 12 14:12:58 2014] i mean, it can't know that until you've proven it down to the base case [Thu Jun 12 21:35:07 2014] can I prove things directly about recursive data types in negative position in Coq, since I can't do that in Agda without some hoop-jumping? [Thu Jun 12 21:38:08 2014] ah, it says "Non strictly positive occurence" also [Thu Jun 12 21:40:08 2014] what I'm wondering is where I can prove theorems about Free monads in Coq [Thu Jun 12 21:42:24 2014] I think ddere might have been looking at free monads in coq at some stage [Thu Jun 12 22:07:36 2014] can anyone help me understand why Coq thinks 'k' is a type in my call to the Y constructor here: https://gist.github.com/795c9c7777df1ad15b70 [Thu Jun 12 22:07:43 2014] let me add more code to that [Thu Jun 12 22:07:52 2014] updated [Thu Jun 12 22:10:10 2014] johnw: Y (fun k …) is the (f : Type -> Type) parameter of Yoneda, I think [Thu Jun 12 22:10:25 2014] doh! thank you [Thu Jun 12 22:10:31 2014] I forget that that parameter wasn't implicit yet [Thu Jun 12 22:10:51 2014] I'm still not used to type variables being fulfilled by what seem like values passed to functions [Thu Jun 12 22:10:59 2014] hmm, though “Y f (fun k …)” doesn’t work either [Thu Jun 12 22:11:11 2014] Y f X ? [Thu Jun 12 22:12:44 2014] Y f X X (fun k => fmap f X X k a). works, though it's not correct :) [Thu Jun 12 22:13:22 2014] heheh [Thu Jun 12 22:17:08 2014] amosr: got it! fixed the gist [Thu Jun 12 22:19:36 2014] nice! [Thu Jun 12 22:20:50 2014] I don’t really understand what this is [Thu Jun 12 22:20:57 2014] trying to prove yoneda's lemma [Thu Jun 12 22:21:22 2014] ah ok, I don’t know that [Thu Jun 12 22:21:30 2014] *googles* [Thu Jun 12 22:21:56 2014] for the case of lists, it says that [a] ~ \f -> fmap f [a] [Thu Jun 12 22:22:08 2014] everything you can do with a list, you can do with a suspended application of fmap on a list [Thu Jun 12 22:22:44 2014] the impliciations are very deep, but phrasing it this way makes it easier to prove :) [Thu Jun 12 22:24:22 2014] I think I’m misunderstanding. you couldn’t filter a list with a fmap? [Thu Jun 12 22:27:37 2014] filter' :: (a -> Bool) -> ((a -> a) -> [a]) -> ((a -> a) -> [a]) [Thu Jun 12 22:27:38 2014] filter' f xs k = Prelude.filter f (xs k) [Thu Jun 12 22:29:00 2014] so we could define: newtype YList a = YList (forall r. (a -> r) -> [r]) [Thu Jun 12 22:29:11 2014] and for all intents and purposes, anything you can do with [a], you can do with YList a [Thu Jun 12 22:29:23 2014] which means we can write functions [a] -> YList a, and YList a -> [a] [Thu Jun 12 22:29:42 2014] (sorry, I speak more Haskell than Coq) [Thu Jun 12 22:30:20 2014] yeah, me too [Thu Jun 12 22:31:14 2014] huhh okay [Thu Jun 12 22:31:28 2014] the advantage of doing so [Thu Jun 12 22:31:53 2014] is that repeated applications of fmap turn into simple composition, and the real fmap is only invoked once you lower the YList a back to [a] [Thu Jun 12 22:32:08 2014] so in cases where you have to pass a list around to various functions, each doing its own fmapping [Thu Jun 12 22:32:22 2014] this lets you optimize for the 2nd functor law without changing any of that code [Thu Jun 12 22:32:24 2014] it's a pretty nifty trick [Thu Jun 12 22:32:26 2014] oh! [Thu Jun 12 22:32:53 2014] like a “delayed array representation for free” [Thu Jun 12 22:32:55 2014] wow [Thu Jun 12 22:32:57 2014] exactly [Thu Jun 12 22:33:23 2014] and it gets better too [Thu Jun 12 22:33:34 2014] lists are isomorphic to suspended fmaps, per Yoneda [Thu Jun 12 22:33:39 2014] they are also isomorphic to suspended folds [Thu Jun 12 22:34:03 2014] newtype FList a = FList (forall r. r -> (r -> a -> r) -> r) [Thu Jun 12 22:34:23 2014] now, let's say we want to generate our list on demand, using side-effects, so we turn this into a suspended monadic fold: [Thu Jun 12 22:34:35 2014] newtype FListM m a = FListM (forall r. r -> (r -> a -> m r) -> m r) [Thu Jun 12 22:34:45 2014] well, believe it or not, we have enough for an entire streaming library, using only that type :) [Thu Jun 12 22:35:00 2014] see http://hackage.haskell.org/package/simple-conduit :) [Thu Jun 12 22:35:55 2014] that’s fascinating [Thu Jun 12 22:36:05 2014] yeah, it's still blowing my mind over here [Thu Jun 12 22:37:09 2014] so, I was wanting to prove some of these properties in Coq, which is what brought me here [Thu Jun 12 22:38:37 2014] I don't think the way I've written is_iso is correct, though [Thu Jun 12 22:38:45 2014] maybe that should be a Definition [Thu Jun 12 22:39:33 2014] yeah, I think it should be a definition [Thu Jun 12 22:48:46 2014] johnw: yeah free monads dont really work in coq [Thu Jun 12 22:48:54 2014] amosr: yay, https://gist.github.com/59aa0b5b16e85911928d [Thu Jun 12 22:48:58 2014] yoneda proven for lists :) [Thu Jun 12 22:49:42 2014] ddere: do you have any developments started? [Thu Jun 12 22:50:19 2014] no i backed out of them [Thu Jun 12 22:50:33 2014] i dont think they are possible in coq [Thu Jun 12 22:50:40 2014] well [Thu Jun 12 22:50:52 2014] not as an inductive type at least [Thu Jun 12 22:51:09 2014] johnw: cool! do you think you’d be able to prove that just from the fmap laws, for any functor? [Thu Jun 12 22:51:11 2014] ddere: see: https://github.com/jwiegley/notes/blob/master/agda-free-monad-trick.md [Thu Jun 12 22:51:24 2014] coq can't validate the positivity restriction [Thu Jun 12 22:51:27 2014] amosr: I would be able to prove it for any functor whose functor laws have been proven [Thu Jun 12 22:51:36 2014] so this is likely a job for type classes [Thu Jun 12 22:51:44 2014] ah i see [Thu Jun 12 22:51:47 2014] then, if you can make an instance of the functor type class, then by definition yoneda applies to you [Thu Jun 12 22:51:56 2014] yeah [Thu Jun 12 22:52:08 2014] ddere: I didn't write that note, btw [Thu Jun 12 22:52:16 2014] it was copied from elsewhere on the web [Thu Jun 12 22:52:20 2014] or if you don’t want to screw around with typeclasses, you could just assume them as hypotheses/variables [Thu Jun 12 22:52:28 2014] johnw: well yeh the positivity restriction is exactly the problem i ran into but i couldnt work around it [Thu Jun 12 22:53:00 2014] ddere: oh well [Thu Jun 12 22:53:14 2014] Variable f : Type -> Type. Variable fmap : … f a -> f b. Hypothesis fmap_id x : fmap id x = x [Thu Jun 12 22:53:20 2014] the strict positivity requirement makes it hard to prove some things I'd really like to make proofs for :( [Thu Jun 12 22:53:23 2014] johnw: so what use cases does simple-conduit not handle (wrt conduit)? [Thu Jun 12 22:53:27 2014] amosr: right [Thu Jun 12 22:53:28 2014] johnw: well the first few lines of that note imply that thats what he is working around, is that right? [Thu Jun 12 22:53:34 2014] shergill: there are essentially two [Thu Jun 12 22:53:37 2014] which is probably just equivalent to a typeclass really [Thu Jun 12 22:53:46 2014] shergill: leftovers, and fine-grained exception handling [Thu Jun 12 22:54:02 2014] shergill: thus far, I've been able to implement every other conduit function in terms of simple-conduit, with no loss of functionality [Thu Jun 12 22:54:10 2014] i forget, but does pipes handle leftovers? [Thu Jun 12 22:54:12 2014] oh, and ZipSinks require side-effects to implement [Thu Jun 12 22:54:15 2014] no, pipes does not either [Thu Jun 12 22:54:18 2014] johnw: really? i think things would be pretty broken without it [Thu Jun 12 22:54:22 2014] makes sense [Thu Jun 12 22:54:32 2014] ddere: pretty broken without what? [Thu Jun 12 22:54:40 2014] the positivity restriction [Thu Jun 12 22:54:45 2014] oh, yeah [Thu Jun 12 22:54:57 2014] but I was hoping to prove some properties of simple-conduit in Coq [Thu Jun 12 22:55:02 2014] but I'm not going to be able to [Thu Jun 12 22:55:03 2014] oh i see [Thu Jun 12 22:55:15 2014] or at least, not without more effort than it's worth [Thu Jun 12 22:55:20 2014] right yeh [Thu Jun 12 22:55:28 2014] i know that feeling [Thu Jun 12 22:55:45 2014] I'll just use good old fast Eq reasoning to show that they form a category, uphold the monad laws, etc. [Thu Jun 12 22:56:42 2014] i'm actually starting to think that simple-conduit may be as expressive as uni-directional pipes, which means that I can use his FreeT trick to achieve the same kinds of things that Gabriel does [Thu Jun 12 22:57:40 2014] I’m staying at a friend’s place. he doesn’t drink coffee… better go buy some. seeya! [Thu Jun 12 22:57:58 2014] ah, not quite [Thu Jun 12 22:58:07 2014] pipes' Proxy type is an MFunctor, which my Source cannot be [Thu Jun 12 22:58:22 2014] so he has greater expressivity [Thu Jun 12 23:01:28 2014] oh, n/m! [Thu Jun 12 23:01:32 2014] just implemented MFunctor :) [Thu Jun 12 23:01:42 2014] it's wonderful what a night of rest can do [Fri Jun 13 02:49:32 2014] if I have a function that wants an argument like {X : Type}, how do I specify X? Using {arg} doesn't work in Coq as it would in Agda [Fri Jun 13 02:49:53 2014] @ [Fri Jun 13 02:50:05 2014] if you func is "foo" [Fri Jun 13 02:50:17 2014] @foo is the same func with the implicit args made explicit [Fri Jun 13 02:50:25 2014] i think, from memeory [Fri Jun 13 03:01:11 2014] johnw: did that work? [Fri Jun 13 03:05:29 2014] ah, didn't try that [Fri Jun 13 03:05:33 2014] but thank you [Fri Jun 13 03:06:07 2014] johnw: hehe thanks me when it works, i'm a bit unsure [Fri Jun 13 03:06:16 2014] I have a Functor type class now [Fri Jun 13 03:06:25 2014] how do I say that a Theorem wants (F : Functor)? [Fri Jun 13 03:07:29 2014] https://github.com/domdere/haskell-coq/blob/master/src/classes/Applicative.v#L36 [Fri Jun 13 03:07:32 2014] something like that [Fri Jun 13 03:07:37 2014] i do it with Applictive there though [Fri Jun 13 03:07:52 2014] ah, nice [Fri Jun 13 03:07:57 2014] that's exactly what I needed, thanks! [Fri Jun 13 03:08:01 2014] np [Fri Jun 13 03:08:10 2014] and @ worked too [Fri Jun 13 03:08:21 2014] if you want to use it as a constraint later like (Functor f) => Applicative f [Fri Jun 13 03:08:26 2014] that example is there too ;) [Fri Jun 13 03:08:44 2014] like i mean as a constraint for another typeclass [Fri Jun 13 03:14:40 2014] saw that [Fri Jun 13 03:16:36 2014] ddere: I have this now: https://gist.github.com/a406d661167b1a19b918 [Fri Jun 13 03:16:51 2014] can you tell me why, in lift_yoneda, it complains that 'k' has type 'Type'? [Fri Jun 13 03:16:56 2014] shouldn't it have type X -> Y? [Fri Jun 13 03:19:55 2014] hmm [Fri Jun 13 03:20:03 2014] yeah i cant see the problem there either sorry :( [Fri Jun 13 03:20:15 2014] you're doing something that i hadnt figured out how to do with : (forall {Y}, (X -> Y) -> F Y) [Fri Jun 13 03:20:27 2014] as in real polymorphism in Y [Fri Jun 13 03:20:48 2014] so, thats the second line and its already unexplored territory for me [Fri Jun 13 03:20:56 2014] :) [Fri Jun 13 03:21:01 2014] I'm just translating the Haskell really [Fri Jun 13 03:21:16 2014] :) [Fri Jun 13 03:24:07 2014] coq.inria.fr is down ;( [Fri Jun 13 03:24:31 2014] :/ [Fri Jun 13 03:28:03 2014] ddere: got it! [Fri Jun 13 03:28:10 2014] nice! [Fri Jun 13 03:28:15 2014] Embed takes two parameters, since they aren't implicit in the definition of Yoneda [Fri Jun 13 03:28:24 2014] ahh [Fri Jun 13 03:28:25 2014] I love it when everything turns that pleasing shade of blue :) [Fri Jun 13 03:28:30 2014] :) [Fri Jun 13 03:28:35 2014] (well, Embed takes three) [Fri Jun 13 03:28:41 2014] Embed F X (fun _ f => fmap f a) [Fri Jun 13 03:28:43 2014] is what I needed exactly [Fri Jun 13 03:28:49 2014] dunno why the _ is necessary [Fri Jun 13 03:28:54 2014] since the {Y} is implicit [Fri Jun 13 03:29:19 2014] I updated https://gist.github.com/jwiegley/a406d661167b1a19b918 [Fri Jun 13 03:29:27 2014] now yoneda is proven for any functor :) [Fri Jun 13 03:29:49 2014] ah right i see now [Fri Jun 13 03:30:06 2014] my is_iso needs to prove both directions also [Fri Jun 13 03:30:13 2014] yeh that bites me too even when i use something simple like a list sometimes [Fri Jun 13 03:30:43 2014] anyway im heading off cya! [Fri Jun 13 03:32:00 2014] night! thanks for your help [Fri Jun 13 03:37:35 2014] np :) [Fri Jun 13 04:47:47 2014] how should I express a theorem that involves two propositions? [Fri Jun 13 04:48:04 2014] for example, to prove an isomorphism, I want to prove that to (from x) = x && from (to x) == x [Fri Jun 13 04:48:23 2014] but I'd like to proceed by proving each individually [Fri Jun 13 04:48:46 2014] perhaps I should make a data type called Isomorphism? [Fri Jun 13 04:48:55 2014] i'm not sure at which "level" to do this [Fri Jun 13 06:02:18 2014] so im working with multisets [Fri Jun 13 06:02:47 2014] equality between multisets M N is denoted meq M N, or M =mul= N [Fri Jun 13 06:02:56 2014] i need decidability of this equality [Fri Jun 13 06:03:18 2014] but the only lemmas seeming to relate to that i could find were these: [Fri Jun 13 06:03:20 2014] Lemma empty_dec : forall M, {M =mul= empty}+{M <>mul empty}. [Fri Jun 13 06:03:31 2014] Lemma empty_decomp_dec : forall M, {Ma: (Multiset * A) | M =mul= fst Ma + {{snd Ma}}} + {M =mul= empty}. [Fri Jun 13 06:03:46 2014] is this some sort of standard deal for list-like data type equalities? [Fri Jun 13 06:04:35 2014] can i employ these two lemmas to prove Lemma meq_dec : forall M N, {M =mul= N} + {M <>mul N} [Fri Jun 13 06:04:37 2014] ? [Fri Jun 13 06:07:34 2014] hm [Fri Jun 13 06:07:40 2014] theres also Lemma member_dec : forall a M, {a in M}+{~a in M}. [Fri Jun 13 06:49:55 2014] back in a bit [Fri Jun 13 10:17:53 2014] could someone link me and/or explain the strict positivity condition. what is meant by positive and negative in this context, and how is it sufficient for soundness? [Fri Jun 13 10:24:04 2014] shergill: it's a sufficient condition to make fixpoints on inductive types always terminate. In other words, it's sufficient to make the type well-founded. [Fri Jun 13 10:25:09 2014] Unfortunately we don't have support for a semantic notion of inductive datatype that allows users to prove their generators indeed are still well-founded even if not strictly positive. [Fri Jun 13 10:25:43 2014] there's some discussion here [Fri Jun 13 10:25:45 2014] http://adam.chlipala.net/cpdt/html/InductiveTypes.html [Fri Jun 13 10:27:12 2014] ianjneu: right, i gather that. but what threw me off was the example of the Inductive term here http://adam.chlipala.net/cpdt/html/InductiveTypes.html [Fri Jun 13 10:27:44 2014] i don't understand why only 'Abs' constructor runs afoul and not 'App' [Fri Jun 13 10:32:00 2014] That tripped me up too when I tried to understand strict positivity. I didn't end up getting a satisfying answer, just "because" [Fri Jun 13 10:33:07 2014] you can think of a -> b -> c as (prod a b) -> c, and in inductive type definitions, c is always the inductive type, so you might as well consider a and b to be in positive position. [Fri Jun 13 10:33:54 2014] but that probably is just confusing and unenlightening. That's where I am with my understanding. [Fri Jun 13 10:59:55 2014] http://coq.inria.fr/refman/Reference-Manual006.html seems to offer some detail, but i need time to digest it [Fri Jun 13 12:19:18 2014] hello. how cann I pass a parameter to an imported module, imported by module import. [Fri Jun 13 12:26:12 2014] I mean, I can assume parameters ... as documented in http://www.lix.polytechnique.fr/coq/distrib/current/refman/Reference-Manual004.html. [Fri Jun 13 12:26:24 2014] but how can I set them when importing? [Fri Jun 13 12:42:25 2014] schoppenhauer: Parameters, Variables, Hypotheses etc are all synonyms for extra arguments that will be passed to functions that use them. You have two options [Fri Jun 13 12:42:51 2014] 1. redefine everything with the parameters explicitly given. [Fri Jun 13 12:43:39 2014] 2. give all your parameters unique 'tags' and then use the canonical structure mechanism to automatically resolve to the parameter you want. [Fri Jun 13 12:44:11 2014] Inductive Tag : Type := my_unique_tag : type_to_tag -> Tag. [Fri Jun 13 12:44:39 2014] Coq is notoriously bad at ergonomics. [Fri Jun 13 12:47:33 2014] ianjneu: redefinition is no option, I want to use http://coq.inria.fr/stdlib/Coq.Sorting.Mergesort.html#Sort.sort [Fri Jun 13 12:47:44 2014] ianjneu: the problem is that the type has a parameter. [Fri Jun 13 12:48:17 2014] I don't get this "tag" thing ... [Fri Jun 13 12:49:24 2014] and what's the canonical structure mechanism? [Fri Jun 13 12:50:30 2014] ok, I do not really understand the documentation about canonical structures. [Fri Jun 13 12:51:52 2014] can I declare modules "locally" somehow? [Fri Jun 13 12:52:10 2014] Modules may not be within Sections. [Fri Jun 13 12:52:56 2014] so there is no way to directly set the parameters, and if I have a list of parametrized types whjich I want to sort, I can ... gfm ...? [Fri Jun 13 12:52:57 2014] I also don't know how a local module would help you. If you're not using modules for scoping tactic databases and notations, you should really just be using records. [Fri Jun 13 12:53:12 2014] i do not want to use modules. [Fri Jun 13 12:53:16 2014] but mergesort uses them [Fri Jun 13 12:53:28 2014] lame. [Fri Jun 13 12:53:35 2014] see http://coq.inria.fr/stdlib/Coq.Sorting.Mergesort.html [Fri Jun 13 12:53:48 2014] I'm trying to follow the example at the bottom of the page [Fri Jun 13 12:53:51 2014] but they sort Nat. [Fri Jun 13 12:54:04 2014] I have an order over fin n * nat, where n is a parameter. [Fri Jun 13 12:54:16 2014] and this parameter is set _inside_ a proof. [Fri Jun 13 12:54:33 2014] modules are not first class. You can't do that. [Fri Jun 13 12:55:05 2014] so ... I cannot use this library? [Fri Jun 13 12:55:18 2014] You'll have to rewrite it to use records. [Fri Jun 13 12:55:42 2014] is there another library for list sorting? [Fri Jun 13 12:55:51 2014] Or find a version rewritten already, since most people have realized modules in Coq are terrible. [Fri Jun 13 12:56:10 2014] I guess writing it myself is easier ... [Fri Jun 13 12:57:35 2014] put it on github afterwards so others may benefit. [Fri Jun 13 12:59:10 2014] schoppenhauer: ordered types have a typeclass implementation in Lescuyer's Containers contribution [Fri Jun 13 12:59:13 2014] http://coq.inria.fr/pylons/pylons/contribs/view/Containers/v8.4 [Fri Jun 13 13:18:37 2014] hm. do not really see how this would help [Fri Jun 13 16:14:06 2014] can someone help me with this: https://gist.github.com/4f11f2a128183fe33f68 [Fri Jun 13 16:14:14 2014] I'm down to this goal: Embed F X (fmap x f) id = Embed F X f x [Fri Jun 13 16:14:32 2014] which should be trivially true, except that its truth depends on the implementation of how Embed is lowered by lower_yoneda [Fri Jun 13 16:15:32 2014] and I'm not sure how to say that these values will both be consumed by lower_yoneda, and that it's in that sense that they are equal [Fri Jun 13 16:22:23 2014] quotient types would be the solution [Fri Jun 13 16:22:47 2014] what are those? [Fri Jun 13 16:25:30 2014] searching [Fri Jun 13 16:31:28 2014] hmm [Fri Jun 13 16:35:48 2014] basically they allow you to specify a custom equivalence relation to use place of their equality [Fri Jun 13 16:36:12 2014] do you have a simpler example of their use than what I'm finding online? [Fri Jun 13 16:36:37 2014] but anyhow Coq doesn't have the [Fri Jun 13 16:36:41 2014] *them [Fri Jun 13 16:36:44 2014] ah [Fri Jun 13 16:40:05 2014] so is this proof not doable in Coq then? or will it just require a lot more wizardry than I posses at the moment? [Fri Jun 13 16:42:25 2014] you either have to postulate quotient types or change your definition of functor to use a given equivalence relation rather than equality [Fri Jun 13 16:43:22 2014] ah [Fri Jun 13 17:07:12 2014] hmm.. [Fri Jun 13 17:07:19 2014] can I just make something this basic a Hypothesis? [Fri Jun 13 17:07:40 2014] something tells me that's just bad form though [Fri Jun 13 17:07:53 2014] creating a functor equivalence is a bit too non-obvious yet [Fri Jun 13 17:24:53 2014] i guess it's not too bad, since it's a consequence of parametricity [Fri Jun 13 17:30:42 2014] OK. I'll stick with it for now, then. I'm not trying to develop a general treatment for CT, but just endofunctors in Coq (ala Haskell), so that I can prove things about the behavior of Haskell types. [Fri Jun 13 17:30:58 2014] total Haskell types, that is [Sat Jun 14 02:04:38 2014] what does `(...) mean? [Sat Jun 14 03:53:55 2014] if I have something like (let (fmap, _, _) := Identity_Functor X in fmap), and I know what Identity_Functor is, how can I "unfold" that? [Sat Jun 14 04:13:06 2014] ah, Defined [Sat Jun 14 05:16:01 2014] in this code: https://gist.github.com/f9a2bbdd246ebd4e00e6, in the fun_identity proof for EitherT_Functor, I need to be able to unfold the fmap definition from Either_Functor. How do I bring that instance "into scope" so to speak? [Sat Jun 14 11:16:26 2014] hm ... so now I have written a module "Quicksort" ... and it is in the same directory as my main project file. And Print LoadPath also contains the directory of my project file. Still, I cannot Require Import it. [Sat Jun 14 11:19:01 2014] ah. [Sat Jun 14 11:19:06 2014] I have to run Coqc on it. [Sat Jun 14 11:19:10 2014] didnt know that, sorry. [Sat Jun 14 14:39:50 2014] is it possible to pass the names of the hypotheses to "destruct" and "inversion"? [Sat Jun 14 14:52:11 2014] schoppenhauer: yes, destruct H as [a b c|d e] if there are two constructors of H, the first with (at least) 3 arguments, the second with (at least) 2 arguments. [Sat Jun 14 14:52:18 2014] same with inversion [Sat Jun 14 15:08:41 2014] when I'm defining an instance whose type is also an instance of the same typeclass, how do I make that other instance's definitions transparent? [Sat Jun 14 15:08:48 2014] i mean, whose type has within it a type which is an instance of the same typeclass [Sat Jun 14 15:10:38 2014] ahh, Transparent [Sat Jun 14 15:14:45 2014] if my function accepts a constraint (m_dict : Monad M), how do I make that m_dict transparent? [Sat Jun 14 15:45:46 2014] I guess that makes no sense, until I would know which monad it was; thanks [Sat Jun 14 15:50:26 2014] given that I have this m_dict, can I push one of its laws as a hypothesis into the current context (I'm assuming it's already taken as "given", I just don't see it)? I found my way to proceed, but I have to modify the law to match the exact form of my goal. [Sat Jun 14 16:04:57 2014] aha: pose proof (@monad_law_5 M m_dict X) as H. [Sat Jun 14 16:05:01 2014] thank goodness for stackoverflow [Sun Jun 15 13:17:08 2014] johnw: there's an oplss channel, if you're interested [Sun Jun 15 16:23:59 2014] If I say [Hint Rewrite my_thm], what tactics will leverage that theorem? [Sun Jun 15 19:10:19 2014] Can I extract Coq nats to Haskell Integers or some other numeric type? [Sun Jun 15 19:21:21 2014] alkabetz: yup, I think… [Sun Jun 15 19:21:25 2014] Extract Inductive nat => "Prelude.Int" [ "0" "(Prelude.+ 1)" ] "(\fO fS n -> if n Prelude.== 0 then fO () else fS (n Prelude.- 1))". [Sun Jun 15 19:23:00 2014] I imagine you’d want to extract addition, subtraction and all that to something like ((a - b) `max` 0) [Sun Jun 15 19:27:30 2014] I guess something like… Extract Constant minus => “(\a b -> Prelude.max 0 (Prelude.- a b))”. [Sun Jun 15 19:27:44 2014] Heh, that last argument to Extract Inductive is totally undocumented. Thanks! [Sun Jun 15 19:28:10 2014] though it might be nicer to define your own newtype Nat = Nat Integer with its own Num instance [Sun Jun 15 19:28:45 2014] * nods [Sun Jun 15 19:28:46 2014] actually what I’ve been wondering about extraction – do you know if there’s a way to add “import qualified Blah” to the top of the extracted module? [Sun Jun 15 19:29:16 2014] it seems like such an obvious thing, but I just haven’t seen it mentioned in the docs [Sun Jun 15 19:37:28 2014] it would be nice if this was integrated with cabal [Sun Jun 15 19:40:10 2014] amosr: you been doing a lot of coq extraction to haskell? [Sun Jun 15 19:40:27 2014] amosr: i wouldnt mind learning all your tricks [Sun Jun 15 19:40:50 2014] ddere: not a whole lot. I’ve just been playing around to see how plausible it was [Sun Jun 15 19:43:00 2014] that seems like a mad science sort of fun, will have to try haskell / coq fun times when I'm a bit more skilled ^.^ [Sun Jun 15 19:44:45 2014] yeah, I’m hoping to be able to extract something useful that we can use in ddc [Sun Jun 15 19:53:20 2014] ah cool [Sun Jun 15 20:24:46 2014] amosr: I think what i worry about when it comes to extracting haskell from coq is all the `error "absurd case"' like statements that might crop up all over the place when it removes all the proofs [Sun Jun 15 20:26:13 2014] ddere: hmm, I haven’t seen any of those, but I have seen this double underscore __ for when Prop values are computed [Sun Jun 15 20:26:47 2014] amosr: oh ok cool maybe its not as bad as i feared then [Sun Jun 15 20:27:33 2014] they have those error cases in some CPDT examples where they extract some examples to Ocaml, i.e it gereates partialfunctions [Sun Jun 15 20:27:35 2014] my stuff probably doesn’t have many absurd cases though [Sun Jun 15 20:28:11 2014] so have you been just sort of working through various types, and typeclasses etc? proving that they work in Coq and then using them for building up the rest? [Sun Jun 15 20:28:28 2014] or is it for actual programs? like vital pieces that Must Work(TM) [Sun Jun 15 20:30:20 2014] so, what I eventually want to do is prove that this fusion/clustering algorithm gives a clustering that works/gives the same result [Sun Jun 15 20:31:05 2014] the clustering algorithm takes a list of combinators or graph, and generates these integer linear programming constraints [Sun Jun 15 20:32:00 2014] so I’ve axiomatised the integer linear program solver in coq, but ideally I’d be able to extract a function that takes a list of combinators, and gives back a list of constraints [Sun Jun 15 20:32:31 2014] or better yet, if it returned the list of (list of combinators fused together) [Sun Jun 15 20:32:42 2014] wow [Sun Jun 15 20:32:43 2014] damn [Sun Jun 15 20:33:17 2014] I’ve just started trying with a much simpler clustering algorithm though [Sun Jun 15 20:33:18 2014] so basically you're prototyping and designing and proving in Coq before you implement in Haskell? That's awesome... (if I've understood correctly) [Sun Jun 15 20:33:59 2014] actually I have already implemented a rough prototype in haskell, but it’s not integrated into DDC [Sun Jun 15 20:34:23 2014] DDC? (sorry ><) [Sun Jun 15 20:34:43 2014] ah, the disciplined disciple compiler (benl23’s language) [Sun Jun 15 20:35:09 2014] strict, haskelly, but finer-grained effect types instead of using monads for side-effects [Sun Jun 15 20:35:43 2014] oooo another language!! *adds to list* [Sun Jun 15 20:36:52 2014] oh man that looks awesome [Sun Jun 15 20:36:55 2014] brutal, but fun [Sun Jun 15 20:37:04 2014] …and we have this ghc plugin that converts things to ddc core and back, so we can implement our fusion optimisations in ddc and use them from ghc [Sun Jun 15 20:37:15 2014] O.O [Sun Jun 15 20:37:26 2014] cripes that's the pointy end of things [Sun Jun 15 20:38:42 2014] yeah I'm definitely getting in on this, thanks amosr !! :D [Sun Jun 15 20:39:12 2014] it’s pretty crazy, but it will end up being less work than implementing twice (I hope) [Sun Jun 15 21:24:45 2014] extraction to haskell xmonad experience report “I use a shell-script that removes the first fifteen lines of the extracted Haskell code and splices in a custom, hand-written Haskell header” [Sun Jun 15 21:39:20 2014] o.O [Sun Jun 15 22:48:51 2014] hi, is there a way of making a definition using terms with holes that are turned into proof obligations? [Sun Jun 15 22:49:18 2014] i'm thinking specifically on the exist constructor for sig types [Sun Jun 15 22:49:43 2014] i haven't found anything similar [Sun Jun 15 22:54:39 2014] kind of like the metavariables in idris? [Sun Jun 15 22:55:07 2014] sorry, i'm not sure, i haven't used idris [Sun Jun 15 22:55:19 2014] i guess it might be similar to that [Sun Jun 15 22:56:10 2014] yeah i dont know sorry :( [Sun Jun 15 22:56:22 2014] it would be nice if there was, cos i think its a great feature [Mon Jun 16 08:12:28 2014] is there some script or something that automatically adds name-annotations to induction/inversion, etc.? [Mon Jun 16 08:12:49 2014] and if not ... assuming one wants to write one ... what would be the best way to do it? [Mon Jun 16 09:39:50 2014] schoppenhauer: I remember robbert trying to produce better, more persistent names a couple years ago. If he's around perhaps he'll tell you what he learned. [Mon Jun 16 09:40:36 2014] ianjneu: the problem is, I use a git-version of coq ... and I can remember it has a different naming scheme than the stable version. [Mon Jun 16 09:41:10 2014] ok, robbert seems to be idling *highlights* [Mon Jun 16 09:41:26 2014] my ansatz would be to ... run coqtop and parse its output. [Mon Jun 16 09:41:43 2014] and then just add the names it gives automatically to the file. [Mon Jun 16 09:45:29 2014] ianjneu: https://github.com/dasuxullebt/quicksort.v btw. [Mon Jun 16 09:47:05 2014] This seems like a really good feature for proof general to have. [Mon Jun 16 09:47:44 2014] your proofs could really handle to be better automated. [Mon Jun 16 09:49:11 2014] hm? [Mon Jun 16 09:49:49 2014] what do you mean? [Mon Jun 16 09:51:08 2014] by better automated? [Mon Jun 16 09:51:10 2014] your proofs are crazy imperative and menial. You can cut out a lot of repetition by encoding your proof strategy into a tactic. [Mon Jun 16 09:51:20 2014] hm. [Mon Jun 16 09:51:27 2014] I never worked with tactics so far. [Mon Jun 16 09:52:00 2014] everything you're using in your proof is a tactic. [Mon Jun 16 09:52:19 2014] yes, but I never wrote my own tactics. [Mon Jun 16 09:53:09 2014] now's a good a time as any. [Mon Jun 16 09:53:39 2014] Also, Coq rejects your statement of the first lemma. {post | ...} isn't a proposition. [Mon Jun 16 09:54:50 2014] I use a git version. [Mon Jun 16 09:54:55 2014] which does not reject it. [Mon Jun 16 09:55:06 2014] never tested it in stable. [Mon Jun 16 09:56:40 2014] ianjneu: might this be a bug in the git-version? [Mon Jun 16 09:57:01 2014] I don't know. [Mon Jun 16 09:57:37 2014] anyway, it compiles in the version I use. [Mon Jun 16 10:00:17 2014] a lot of the time goals are solved just by inverting the right hypothesis. If you write a tactic that just inverts everything, you can get rid of a lot of work. [Mon Jun 16 10:00:32 2014] Ltac invert_all := repeat match goal with [H : _ |- _] => inversion H end. [Mon Jun 16 10:00:51 2014] your first lemma's base case is then simple: [Mon Jun 16 10:01:39 2014] do 5 intro; induction 0; [exists nil,nil; repeat split; intros; try solve [invert_all]|]. [Mon Jun 16 10:02:28 2014] that would be shorter, but nobody would understand it. [Mon Jun 16 10:02:58 2014] but I need to look at the tactic stuff. [Mon Jun 16 10:03:33 2014] perhaps intros; induction list; [exists nil,nil; firstorder|]. [Mon Jun 16 10:09:55 2014] anyway ... the much bigger problem is to make it ... compatible with future versions of coq. [Mon Jun 16 10:10:16 2014] not only this but also the rest of my code [Mon Jun 16 10:11:03 2014] the best way to do that is not depend on names and instead use tactics to search for what you mean. [Mon Jun 16 10:11:55 2014] ok [Mon Jun 16 10:15:03 2014] may I quote you in my paper? ^^ [Mon Jun 16 10:15:17 2014] I think this is a nice quote. [Mon Jun 16 10:16:26 2014] I just forked your gist with a much smaller proof of the first lemma. [Mon Jun 16 10:16:50 2014] I only introduce names that I actually need. [Mon Jun 16 10:18:18 2014] ++ [Mon Jun 16 10:18:57 2014] ? [Mon Jun 16 10:19:09 2014] i consider this positive. [Mon Jun 16 10:20:46 2014] I should have made the third ? in the intros "total", but it's safe to assume all future versions of Coq will introduce named hypotheses as the actual names, unless those names are already taken. [Mon Jun 16 10:21:08 2014] ianjneu: do you have a link? [Mon Jun 16 10:21:40 2014] to your fork? [Mon Jun 16 10:22:46 2014] I just made a pull request. [Mon Jun 16 10:22:54 2014] You should be able to see it. [Mon Jun 16 10:25:02 2014] thx [Mon Jun 16 11:27:08 2014] schoppenhauer/ianjneu: the tricks I use for names are 1.) For inversion, I often use the "small inversions" technique by Monin. That way, it is easier to control the generated names than using the ordinary inversion tactic [Mon Jun 16 11:28:11 2014] 2.) I tend to use automation in order to avoid having to refer to automatically named hypotheses 3.) If often apply induction principles by hand so that you can intro all the names on a per case basis [Mon Jun 16 11:41:12 2014] hm. ok. [Mon Jun 16 11:41:21 2014] robbert: I do not understand 3. [Mon Jun 16 11:42:34 2014] robbert: but in general, you are saying the same thing as ianjneu: use automation? [Mon Jun 16 12:01:00 2014] schoppenhauer: yes, indeed, especially for CS proofs, more automation is generally nicer [Mon Jun 16 12:01:11 2014] for math proofs, not so [Mon Jun 16 12:01:55 2014] hm. how can I name the induction hypothesis of an induction? [Mon Jun 16 12:01:55 2014] About 3.) instead of saying induction foo as [x y z|x y q], say refine (foo _ _ _) (or use the elim tactic if you want to use the standard induction scheme) [Mon Jun 16 12:02:05 2014] that way, the names do not all appear at the top [Mon Jun 16 12:02:10 2014] but at the right place in the proof [Mon Jun 16 12:04:02 2014] hm. [Mon Jun 16 12:04:07 2014] so refinement of a fixpoint. [Mon Jun 16 12:04:09 2014] I did that often [Mon Jun 16 12:04:15 2014] when the induction was complicated [Mon Jun 16 12:05:45 2014] Oops, that should be refine (foo_ind _ _ _) [Mon Jun 16 12:05:50 2014] So, refinement of the induction scheme [Mon Jun 16 12:34:49 2014] hm. how can I import a module "Unqualified", that is, without having to type its name before every function it contains. [Mon Jun 16 12:34:58 2014] Require Import module_name. [Mon Jun 16 12:35:13 2014] Or, if you’ve already [Require]d it, just [Import module_name.]. [Mon Jun 16 12:35:15 2014] alkabetz: doesn't work [Mon Jun 16 12:35:19 2014] doesn't work. [Mon Jun 16 12:35:29 2014] do I have to do something inside the module? [Mon Jun 16 12:35:36 2014] like exporting symbols or something? [Mon Jun 16 12:35:47 2014] No, all symbols are exported by default. [Mon Jun 16 12:35:53 2014] Can you paste an example? [Mon Jun 16 12:36:31 2014] no. [Mon Jun 16 12:36:36 2014] the code is too long [Mon Jun 16 12:36:40 2014] that is why I want to split it. [Mon Jun 16 12:37:15 2014] I am just using "Module my_module. ...code... End my_module." then coqc-ing it, and then in the main file Require Import my_module. [Mon Jun 16 12:37:27 2014] it works, and accessing all symbols using my_module.symbol also works. [Mon Jun 16 12:37:30 2014] Oh, you don’t want to put a [Module] declaration at the top level. [Mon Jun 16 12:37:40 2014] I dont? [Mon Jun 16 12:37:43 2014] As in OCaml, every file is automatically a new module. [Mon Jun 16 12:37:52 2014] You don’t need an explicit module declaration like you do in Haskell. [Mon Jun 16 12:38:49 2014] ok [Mon Jun 16 12:38:52 2014] that was the problem [Mon Jun 16 12:38:54 2014] thx [Mon Jun 16 12:39:00 2014] You’re welcome. [Mon Jun 16 13:29:09 2014] given that I know the definition of fmap, id and "fmap id" for some types X and F X, can I prove fmap id = id? fmap id x = id x isn't a problem, but I can get it to unify the two lambdas which fmap id and id unfold to [Mon Jun 16 13:30:08 2014] s/can/cannot [Mon Jun 16 13:30:10 2014] johnw: for that you need function extensionality [Mon Jun 16 13:30:21 2014] johnw: which afaik isn't readily available in coq [Mon Jun 16 13:30:30 2014] (i had a similar issue not too long ago, still a coq newbie myself) [Mon Jun 16 13:30:42 2014] for example, one thing I'm tripping up on is proving that fmap (fmap id) x = id x [Mon Jun 16 13:31:28 2014] where I know "which" fmap to use in the outermost fmap, but I only know that I have some Functor for the inner one [Mon Jun 16 13:31:41 2014] so I need a general way to say "if it's really a Functor, then fmap id can be collapsed down to id" [Mon Jun 16 13:32:52 2014] in particular I'm trying to prove the first functor law for EitherT e m a, which is effectively Functor (Monad (Functor A)), where I know the inner and outer functor definitions, but I don't know which Monad the user will choose [Mon Jun 16 13:33:44 2014] i thought coq 8.4 could do eta equivalence? [Mon Jun 16 13:33:55 2014] at least for dependent product types [Mon Jun 16 13:34:01 2014] how do I use it? [Mon Jun 16 13:34:23 2014] my code is here: https://github.com/jwiegley/simple-conduit/blob/master/coq/Either.v [Mon Jun 16 13:34:36 2014] i'm stuck on line 124 [Mon Jun 16 13:34:47 2014] I'm trying to debug a vim plugin for Coq. There's some strangeness in the xml responses that I'm getting [Mon Jun 16 13:34:54 2014] is there documentation on the ideslave stuff? [Mon Jun 16 13:35:25 2014] johnw: no clue, not having tried it myself =/ try your hand at googling? [Mon Jun 16 13:35:33 2014] yes, intensive googling so far :) [Mon Jun 16 13:35:43 2014] now I'm down to reading manuals and papers to see if I can glean some insight [Mon Jun 16 13:35:50 2014] Technically, I'm working with the HoTT coq, butt he ideslave module hasn't been changed in the fork [Mon Jun 16 14:36:47 2014] tbelarie: no, no documentation [Mon Jun 16 14:40:27 2014] Would you like documentation that I write up as I try and get this working? [Mon Jun 16 14:41:03 2014] It'd be rough, and possibly incorrect, as I will be only looking at the parts that I need [Mon Jun 16 14:41:42 2014] I don't need it personally but it'd be good [Mon Jun 16 14:41:46 2014] https://github.com/coq/coq/blob/trunk/lib/serialize.ml this is what I look at [Mon Jun 16 14:42:31 2014] ezyang: did you attempt to write up about it at some point? [Mon Jun 16 14:57:18 2014] Oh, cool I do see [Mon Jun 16 14:57:18 2014] http://blog.ezyang.com/2012/05/what-happens-when-you-mix-three-research-programming-languages-together/ [Mon Jun 16 14:57:37 2014] From ezyang, I'm checking out his patches and looking about [Mon Jun 16 14:57:45 2014] That's at least a lead, thanks [Mon Jun 16 15:24:06 2014] tbelaire: I'm a bit rusty, but yes, that code should be helpful [Mon Jun 16 15:50:32 2014] What I'm seeing right now though, is I'm sending the command Check 4. [Mon Jun 16 15:50:35 2014] it replies [Mon Jun 16 15:50:39 2014] I send Check 4. [Mon Jun 16 15:50:51 2014] it replies with [Mon Jun 16 15:50:58 2014] I send Check 4. [Mon Jun 16 15:51:05 2014] vim locks up [Mon Jun 16 15:52:00 2014] Most confusingly, when I change pr_debug_answer [Mon Jun 16 15:52:07 2014] to also include the xml string [Mon Jun 16 15:52:23 2014] (from Serialize.of_answer) [Mon Jun 16 15:52:33 2014] it's different from what I get on the vim side [Mon Jun 16 15:54:43 2014] is Xml_utils.print_xml different Xml_utils.to_string followed by a print? [Mon Jun 16 17:33:57 2014] ah ah : coq$ make install -> argument is too big [Tue Jun 17 08:18:51 2014] when using firstorder and recursion, firstorder sometimes calls the recursive function without decreasing the argument. can I prevent firstorder from using certain assumptions? [Tue Jun 17 10:24:43 2014] whats the tactic that does nothing? [Tue Jun 17 10:25:50 2014] idtac [Tue Jun 17 10:29:47 2014] thanks :) [Tue Jun 17 11:41:54 2014] Is there an [OrderedType] module for [nat]? Or do I need to switch to [BinNat]? [Tue Jun 17 22:19:18 2014] if I see something like "(let (fmap, _, _) := Either_Functor X in fmap) X0 Y f (Left E X0 e)", how do I substitute for the definition of fmap, when Either_Functor is my base instance? [Tue Jun 17 22:27:43 2014] can do it with an unfold [Tue Jun 17 22:28:22 2014] johnw: https://github.com/domdere/haskell-coq/blob/master/src/types/Maybe.v#L126 [Tue Jun 17 22:30:19 2014] what do I unfold exactly? [Tue Jun 17 22:30:24 2014] unfolding fmap is what gets me to what I pasted [Tue Jun 17 22:31:02 2014] for example, I have is_functor := Either_Functor X [Tue Jun 17 22:31:11 2014] but when I "unfold is_functor", nothing happens [Tue Jun 17 22:36:26 2014] in that example i am unfolding maybe_functor which is defined here: https://github.com/domdere/haskell-coq/blob/master/src/types/Maybe.v#L29 [Tue Jun 17 22:37:13 2014] so you have to find the specific instance that applies [Tue Jun 17 22:55:43 2014] how do I specify types, as in unfold (Either_Functor X).? [Tue Jun 17 22:56:15 2014] also, locally I have 'is_functor := Either_Functor X' [Tue Jun 17 22:56:18 2014] as I mentioned before [Tue Jun 17 23:02:52 2014] ddere: https://gist.github.com/ba5e829644b14d53f4c3 [Tue Jun 17 23:03:54 2014] oh, duh [Tue Jun 17 23:03:58 2014] I used Qed instead of Defined [Tue Jun 17 23:04:12 2014] yep, that was it [Tue Jun 17 23:04:13 2014] thanks ddeere [Tue Jun 17 23:04:37 2014] np :) [Tue Jun 17 23:17:59 2014] what tactic would I use to go from (fun x0 : X0 => f (g x0)) back to (f . g)? [Tue Jun 17 23:30:04 2014] woohoo, did it! [Tue Jun 17 23:31:10 2014] johnw: grats ! [Tue Jun 17 23:31:21 2014] thanks, that took many many hours [Tue Jun 17 23:36:52 2014] Would that just be "replace (fun x0 : X0 => f (g x0)) with (f . g)" or something? [Tue Jun 17 23:37:01 2014] Given that that's the definition of f . g? [Tue Jun 17 23:38:16 2014] i ended up just rewriting using a lemma from the typeclass, fun_composition [Tue Jun 17 23:38:47 2014] proving app_identity is proving very tricky too [Tue Jun 17 23:39:12 2014] i have a dependent type matching question [Tue Jun 17 23:39:53 2014] standard example: dependently typed fixed length vectors [Tue Jun 17 23:40:03 2014] I want to write a zip function [Tue Jun 17 23:40:39 2014] zip {A} {B} {n} (v1:vector A n) (v2:vector B n): vector (A*B) n := ... [Tue Jun 17 23:41:14 2014] i match on the first list, then the second list, [Tue Jun 17 23:41:55 2014] but the lengths of the two sub-vectors are given distinct length so the type checking fails in the recursive call. [Tue Jun 17 23:44:09 2014] hmm, here's my code, maybe that's clearer: http://pastebin.com/9T1ZtfaS [Tue Jun 17 23:44:37 2014] the typechecker fails with v1' and v2' having different types n0 and n1. [Tue Jun 17 23:44:43 2014] anyone know how to tell coq that n0 = n1? [Wed Jun 18 00:34:16 2014] maybe have your vnil and vcons constructors take the nat? [Wed Jun 18 00:34:41 2014] ah, n/m [Wed Jun 18 00:34:48 2014] I'm confused here: Inductive vector (A:Type): nat -> Type [Wed Jun 18 00:34:56 2014] why is that nat -> Type? [Wed Jun 18 00:38:19 2014] i'm a bit confused about why A*B is used [Wed Jun 18 00:39:03 2014] oh nvm [Wed Jun 18 00:40:05 2014] and also why => tt? [Wed Jun 18 08:50:00 2014] hi [Wed Jun 18 08:50:46 2014] ive got this definition and hypothesis: https://privatepaste.com/9172784a17 [Wed Jun 18 08:51:19 2014] when i do 'destruct H3', coq discards the value of fs1 and fs2 [Wed Jun 18 08:51:29 2014] eg. H3 : fs_lt fs2 fs1 [Wed Jun 18 08:51:57 2014] how can i destruct H3 so that it becomes H3 : fs_lt (vt_head (VTerm.Fun f0 l0)) (vt_head (VTerm.Fun f l)) [Wed Jun 18 08:51:58 2014] ? [Wed Jun 18 08:53:41 2014] oh nevermind, just use inversion i guess :p [Wed Jun 18 12:25:58 2014] Let's say I have a type A and a predicate P : A -> Prop. How can I say : "Define t : A such that (P t)", followed by a proof that builds t? [Wed Jun 18 12:33:07 2014] I can do something like http://lpaste.net/105807, but I’m curious if there’s a better way. [Wed Jun 18 12:43:08 2014] Somebody else just told me that, it seems to be the right way to do it. [Wed Jun 18 12:44:24 2014] However... I'd like to be able to really print the term, how can I do that? :/ [Wed Jun 18 12:45:00 2014] (proj1_sig t) is the term I want to print, but Coq doesn't seem to go farther than "let (a, _) := p in a" when I ask to print it. [Wed Jun 18 12:51:25 2014] p is not transparent [Wed Jun 18 12:51:31 2014] what is p in this context? [Wed Jun 18 12:51:39 2014] Sorry, 'p' is 't' [Wed Jun 18 12:51:43 2014] (different notations) [Wed Jun 18 12:51:50 2014] what is its type? [Wed Jun 18 12:52:28 2014] http://lpaste.net/105807 >> its type would be { x : A | P x} in the general case [Wed Jun 18 12:52:42 2014] I could be more precise for my use-case, but I don't know if it would be relevant? [Wed Jun 18 12:53:16 2014] so, proj1_sig throws away the second argument, so it's definition is just that 'let' you pasted [Wed Jun 18 12:53:40 2014] (more specifically, the second value from the product) [Wed Jun 18 12:53:47 2014] You can do [Eval compute in proj1_sig t]. [Wed Jun 18 12:53:55 2014] it's the same as fst or π₁ [Wed Jun 18 12:53:56 2014] That's what I tried [Wed Jun 18 12:54:04 2014] it still doesn't try to replace p by its value [Wed Jun 18 12:54:23 2014] Oh, really? I get <<= 8 : nat>> when I do that. [Wed Jun 18 12:54:43 2014] Hmm, I tried with my code. Wait, I can paste it, it's short. [Wed Jun 18 12:55:32 2014] http://lpaste.net/105808 [Wed Jun 18 12:55:42 2014] The goal was just to find automatically some combinator [Wed Jun 18 12:55:56 2014] So only the last lines are important [Wed Jun 18 12:56:07 2014] change line 36 from Qed to Defined [Wed Jun 18 12:56:10 2014] Oh [Wed Jun 18 12:56:27 2014] I see, thanks a lot! [Wed Jun 18 12:56:41 2014] [Qed] produces an opaque term, while [Defined] produces a transparent one. [Wed Jun 18 12:56:44 2014] Glad we could help! [Wed Jun 18 12:57:10 2014] it feels so bizarre to be answering these questions instead of asking them :) [Wed Jun 18 12:57:24 2014] I guess at least that's one sign of progress [Wed Jun 18 12:57:29 2014] Hooray for learning! [Wed Jun 18 12:57:34 2014] :D [Wed Jun 18 12:58:41 2014] I'm in a Coq class right now, being overwhelmed by tactics [Wed Jun 18 12:59:52 2014] johnw: always go for the flank. [Wed Jun 18 13:00:07 2014] I propose we add strategies to Coq [Wed Jun 18 13:00:25 2014] good strategies beat tactics all the time [Wed Jun 18 13:01:46 2014] strategies are tactic databases, no? [Wed Jun 18 13:03:36 2014] hmm... I would say that in chess at least, a tactic takes advantage of a weakness, while a strategy is a scheme to create opportunities for exploiting weakness [Wed Jun 18 13:04:07 2014] so an autorewrite database. [Wed Jun 18 13:04:19 2014] or the boyer-moore tactic :P [Wed Jun 18 13:04:21 2014] I just discovered autorewrite yesterday. I was so excited. [Wed Jun 18 13:04:51 2014] maybe you should get some sunlight and human contact once in a while [Wed Jun 18 13:05:06 2014] Ha! [Wed Jun 18 15:40:38 2014] hi folks, [Wed Jun 18 15:41:06 2014] i stuck on an exercise provided by software foundations. [Wed Jun 18 15:42:35 2014] it's about using double induction to prove theorem. [Wed Jun 18 15:42:48 2014] i just stuck in the final step. [Wed Jun 18 15:42:52 2014] check it here: http://lpaste.net/105814 [Wed Jun 18 15:42:57 2014] thank you :) [Wed Jun 18 15:47:44 2014] shouya: the proof is simply induction m; induction n; auto. [Wed Jun 18 15:48:00 2014] but... what does 'auto' do. [Wed Jun 18 15:48:10 2014] i haven't learned that yet. [Wed Jun 18 15:49:32 2014] ianjneu: hm... since i am still studying, i tend to do it manually before i knew how it works :p [Wed Jun 18 15:49:46 2014] it will try applying hypotheses recursively. It also does stuff with hints, but you're not there yet. [Wed Jun 18 15:50:20 2014] Here's another way that is more transparent: induction m; induction n; repeat match goal with [H : _ |- _] => apply H end; assumption. [Wed Jun 18 15:50:54 2014] actually, ; assumption is unneeded because applying a non-product hypothesis is the same as saying exact of that hypothesis. [Wed Jun 18 15:51:33 2014] ianjneu: hmm.. but so far i haven't learned those tactics yet... [Wed Jun 18 15:51:38 2014] repeat is unnecessary, even. You can just use do 2, since that's the depth of search you need. [Wed Jun 18 15:52:24 2014] sorry but i haven't learned 'match' neither :p [Wed Jun 18 15:52:42 2014] i thought there may be other ways.. [Wed Jun 18 15:52:50 2014] shouya : the problem with your proof is that you're doing an induction on 'm' when 'n' is already instantiated [Wed Jun 18 15:52:54 2014] as an exercise on tutorial. [Wed Jun 18 15:52:58 2014] so the hypothesis that you get is not general enough [Wed Jun 18 15:53:12 2014] Cypi: hmm.. [Wed Jun 18 15:53:34 2014] So, two choices : don't instantiate m et n before doing the induction ; or use "genralize dependent n.", which will put pack a "forall n," at the beginning of the goal and make it general enough. [Wed Jun 18 15:53:46 2014] generalize dependent n. sorry [Wed Jun 18 15:53:49 2014] Cypi: the last 'induction m' is nothing necesary. [Wed Jun 18 15:53:49 2014] shouya: indeed, don't use intros; but instead do 6 intro; induction m; intro n; induction n; if you want to be more explicit. [Wed Jun 18 15:54:02 2014] I meant, at the beginning [Wed Jun 18 15:54:24 2014] Cypi: perhaps? [Wed Jun 18 15:54:44 2014] Cypi: i'd try it, bbl. [Wed Jun 18 15:55:29 2014] "intros. induction m." : here, you have already lost, you won't be able to prove the second goal. [Wed Jun 18 15:57:45 2014] Cypi: yep it works. http://lpaste.net/105814 [Wed Jun 18 15:58:12 2014] how do i understand 'generalize dependent' and when should i use it? [Wed Jun 18 15:58:31 2014] i mean, i know what it means. but i don't get the intuition... [Wed Jun 18 15:59:01 2014] when you need an induction to include quantification over that thing. [Wed Jun 18 15:59:27 2014] http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic57 to know what happens exactly (the reference manual is very useful imo) [Wed Jun 18 15:59:49 2014] Cypi: i'm just following that guide lol [Wed Jun 18 16:00:23 2014] Cypi: i don't see much intuition about when to use it... [Wed Jun 18 16:01:19 2014] Well, what ianjneu said. That is, when you need to make a goal more general. [Wed Jun 18 16:02:15 2014] In your example, without generalizing a little bit the goal, the induction hypothesis that you get only concernes one particular n, which is not enough to prove what you want. By generalizing n, you have an induction hypothesis that concerns every n. [Wed Jun 18 16:02:41 2014] Cypi: ianjneu: hmm... [Wed Jun 18 16:03:12 2014] Cypi: ianjneu: very clear explanation.. i thought, i believe i got the point. thanks :) [Wed Jun 18 16:03:48 2014] i'd try to read more examples and do more exercises about that :) [Wed Jun 18 16:06:31 2014] So, the difference between 'generalize' and 'generalize dependent' is that the latter one remove the 'particular x' from the assumptions. am i understanding correctly? [Wed Jun 18 16:09:23 2014] It also generalizes the hypotheses that depend on x [Wed Jun 18 16:09:31 2014] So, if you "generalize dependent n." [Wed Jun 18 16:09:45 2014] and in your context, you have "H : Q n" where Q : nat -> Prop is some predicate [Wed Jun 18 16:10:16 2014] It will remove n and H from your context, and put "forall n, Q n -> " at the beginning of the goal [Wed Jun 18 16:16:26 2014] Cypi: ryu gai desu! [Wed Jun 18 16:17:47 2014] What? [Wed Jun 18 16:18:10 2014] ryo kai desu == 'i understood' in japanese :) [Wed Jun 18 16:18:30 2014] ok :D [Wed Jun 18 16:19:09 2014] In a typing rule, when do I need inference in my hypothesis? It seems like checking should be sufficient in all cases … [Wed Jun 18 16:22:08 2014] Oh, I think I need inference whenever the term won’t have a type associated with it in Γ by the time I try to typecheck it. [Wed Jun 18 16:58:36 2014] alkabetz: it depends a lot on what you're trying to type [Wed Jun 18 16:59:19 2014] Oh, wait, lolz, wrong channel [Wed Jun 18 16:59:30 2014] No wonder nobody responded quickly :) [Wed Jun 18 16:59:37 2014] Anyway, I got the help I needed offline. [Wed Jun 18 16:59:46 2014] oplss? :) [Wed Jun 18 16:59:54 2014] Yep :) [Wed Jun 18 19:38:46 2014] Does anyone know how to rewrite (fun xv : Either E X => match xv with | Left e => f (Left E X e) | Right x' => f (Right E X x') end) as f? [Wed Jun 18 19:39:03 2014] as a separate Theorem I can prove it trivially, but I can't seem to rewrite it in my goal [Wed Jun 18 19:39:26 2014] in fact, when I try to apply my Theorem, it says it can't find any subterm matching the lambda [Wed Jun 18 22:44:52 2014] how do you uninstall coq 8.4pl2 from a mac? [Wed Jun 18 22:46:54 2014] wagle: drag it to the trash bin? [Wed Jun 18 22:47:23 2014] its smeared all over /usr/local [Wed Jun 18 22:47:25 2014] wagle: btw are you on mavericks? I was unable to get coqide working on it last time I tried [Wed Jun 18 22:47:42 2014] ahh [Wed Jun 18 22:47:48 2014] on mavericks, havent gotten that far yet [Wed Jun 18 22:48:54 2014] trying to install coq8.4pl4 via homebrew, doesnt work due to the old coq being there [Wed Jun 18 22:49:16 2014] brew remove coq ? [Wed Jun 18 22:49:33 2014] also a 'brew cleanup' might help if things have become a bit messy [Wed Jun 18 22:49:38 2014] the old one isnt brew [Wed Jun 18 22:49:42 2014] if you're not managing the old one with brew or anything, you might have to manually remove things [Wed Jun 18 22:49:47 2014] yar [Wed Jun 18 22:50:24 2014] prolly have to rebuild /usr/local [Wed Jun 18 22:50:28 2014] run a `find /usr/ -iname "coq*"` and get to tedious work I guess :/ [Wed Jun 18 22:50:55 2014] not everything has "coq" in its name [Wed Jun 18 22:52:31 2014] bummer [Wed Jun 18 22:57:08 2014] lsbom /private/var/db/receipts/fr.inria.coq.bom [Wed Jun 18 22:57:51 2014] this assumes it installed everything normally, and not by scripts [Wed Jun 18 22:58:02 2014] homebrew was happy [Wed Jun 18 22:58:15 2014] meh [Wed Jun 18 23:14:22 2014] awww he quit [Wed Jun 18 23:15:17 2014] coqide-8.4pl4-ssreflect-1.5.dmg worked, but CoqIdE_8.4pl4.app.tar.bz2 froze on launch [Fri Jun 20 01:36:12 2014] Why won’t [Hint Extern] cause [plus] to get unfolded in http://lpaste.net/105855 ? [Fri Jun 20 01:36:59 2014] Oh, wait, does auto not pay attention to [Hint Extern]? [Fri Jun 20 01:47:24 2014] alkabetz: auto uses Hint Extern, but only when it helps to solve goal. Here the goal is not solved with your hint and with other automation stuff. [Fri Jun 20 01:48:26 2014] alkabetz: so, what do you see if you manually "unfold plus. auto."? [Fri Jun 20 01:49:18 2014] Then it works, as does 'autounfold'. [Fri Jun 20 01:50:23 2014] after "unfold plus. auto." the goal is not _solved_. (in my Coq version at least.) So Coq decided that your hint is not useful to solve goal, so it is not applied with auto. [Fri Jun 20 01:51:11 2014] Ah, I see. Hang on … [Fri Jun 20 01:52:23 2014] Okay. I have to go to sleep, but I’ll revisit this later. Thanks for your help. [Fri Jun 20 13:11:14 2014] I’m having some difficulty with closed notations. Why does http://lpaste.net/105880 error out? [Fri Jun 20 13:20:52 2014] Any Coq wizards have any idea why http://lpaste.net/105880 fails? [Fri Jun 20 13:21:04 2014] Oh, whoops, wrong channel. Sorry for the double post. [Fri Jun 20 13:29:12 2014] Oh, never mind anyway, I got it to work with [x at level 0] [Fri Jun 20 15:16:59 2014] excuse me, a little question. [Fri Jun 20 15:17:28 2014] i have this in the hypothesis: H: (l1', l2') = (l1, l2) -> combine l1 l2 = l [Fri Jun 20 15:17:45 2014] and my goal is: combine l1' l2' = l [Fri Jun 20 15:17:56 2014] so what can i do to prove it? [Fri Jun 20 15:19:18 2014] my basic idea is some like: 'intro in H. [Fri Jun 20 15:19:20 2014] ' [Fri Jun 20 15:23:26 2014] okay, solved. i used 'rewrite. [Fri Jun 20 18:48:03 2014] say I have some 'u : F A', where I know that eta (an embedding function) exists for F. How can I posit exists (x : A), u = eta x in my proof, so that I can work in the domain of A and then later switch back to F A? [Fri Jun 20 18:52:24 2014] hmm.. this isn't generally true, ok [Sat Jun 21 22:31:17 2014] Is someone here? I would like to know where to ask my Gallina question. http://coq.inria.fr produces 502 proxy error [Sat Jun 21 22:31:28 2014] I’m here. [Sat Jun 21 22:31:52 2014] Looks like the Coq site is down again :/ [Sat Jun 21 22:32:00 2014] This seems to happen every couple weeks. [Sat Jun 21 22:32:50 2014] I have18 lines of Gallina code with a blank I'm not sure how to fill. [Sat Jun 21 22:33:19 2014] You should put it on lpaste.net [Sat Jun 21 22:33:25 2014] Well, 19 lines really, it needs "Require Import BinPos." [Sat Jun 21 22:33:25 2014] ok [Sat Jun 21 22:41:47 2014] http://lpaste.net/106022 [Sat Jun 21 22:42:57 2014] Hope that's either easy or interesting. Possibly it's only barking up the wrong tree though [Sat Jun 21 22:43:01 2014] * looks [Sat Jun 21 22:50:45 2014] I found the github README so I'll make a request to coq-club-request@inria.fr [Sat Jun 21 22:58:02 2014] If I lose connection or leave the channel, I would welcome comments about http://lpaste.net/106022 at my email address mentioned there [Mon Jun 23 06:57:59 2014] hello. is it possible to replace a function f with a function g, if forall x, fx = gx, somehow? [Mon Jun 23 06:58:23 2014] the equality is not intensional. [Mon Jun 23 09:04:43 2014] schoppenhauer: that is called functional extensionality. Currently it has to be taken as an axiom. [Mon Jun 23 09:05:26 2014] afaik the axiom is not consistent with some hott-stuff or so. [Mon Jun 23 09:06:03 2014] anyway, I am trying to solve the problem differently now. [Mon Jun 23 09:10:10 2014] if = is proprositional equality then what you are asking for is actually implied by univalence, so quite consistent with hott [Mon Jun 23 09:10:24 2014] otherwise it depends [Mon Jun 23 09:11:26 2014] btw, does Coq have some way to let me use a value of a record type where i actually mean some specific projection of it? [Mon Jun 23 09:11:47 2014] e.g. so that i don't have to use the second projection for some sigma types explicitly [Mon Jun 23 14:17:31 2014] Could someone explain the fundamental differences between haskell's and coq's type systems to me? I've learned a little about dependent type systems, and I know a fair amount of haskell. Could anyone help me understand what else coq provides? I understand it models the calculus of inductive constructions (i think), but I haven't studied type theory for long at all. What practical applications does that bring? [Mon Jun 23 14:22:43 2014] athan: Have you looked at the Software Foundations course? [Mon Jun 23 14:23:33 2014] johnw: No! Thank you!! [Mon Jun 23 14:24:00 2014] I think that will help, and then you can come back and ask again, because that's a fairly deep question :) [Tue Jun 24 12:41:04 2014] What’s the difference between [match goal with _ |- _ => …] and [match goal with [_ |- _] => …]? When do I need brackets around the context rule? [Wed Jun 25 15:46:27 2014] Hi! I have a structure with Set and Prop fields. Is there any direct/idiomatic way of reducing equality of record instances to the equality of each of its Set fields? (i.e. assuming proof irrelevance) [Wed Jun 25 18:29:49 2014] has anyone ever used "Show Tree."? [Wed Jun 25 18:30:01 2014] it doesn't seem to do anything under proofgeneral or coqide :\ [Thu Jun 26 04:02:19 2014] I don’t really understand when coq will, or will not let you induct over something [Thu Jun 26 04:03:05 2014] like, if I want to induct over “Vs” but Vs is mentioned inside this definition of Min, I need to unfold Min before performing induction [Thu Jun 26 04:03:35 2014] but Vs is also mentioned in this thing Clustering_Full, and I don’t have to unfold clustering_full. it can be very confusing [Thu Jun 26 04:04:10 2014] sorry– when I say I need to unfold Min, I mean coq gives me an error if I don’t [Thu Jun 26 09:49:39 2014] hello. I have proved {x | ...}. How can I compute and print x? [Thu Jun 26 09:49:47 2014] "Print x" does just give me the term. [Thu Jun 26 10:59:45 2014] schoppenhauer : if [px : {x | ...}], you can use [Eval compute in (proj1_sig px).]. [Thu Jun 26 11:00:00 2014] The definition of [px] has to be transparent however [Thu Jun 26 11:00:50 2014] hm. [Thu Jun 26 11:01:03 2014] you mean everything must be "Defined." rather than "Qed.", Cypi ? [Thu Jun 26 11:01:29 2014] I think so. I'm not that sure because I asked this very question here a few days ago :p [Thu Jun 26 11:05:09 2014] I'll just try. [Thu Jun 26 15:58:32 2014] hm ... my current implementation takes a *lot* of RAM and time ... probably because I tried to avoid using Prop and opaque definitions. Is it to be expected that the extracted program will be faster? Is there a way of doing dead-code-detection? [Thu Jun 26 16:01:54 2014] Are intersection types connected to type classes? [Thu Jun 26 16:46:59 2014] schoppenhauer: Coq does not do dead-code detection during extraction (beyond not extracting proof terms). Whatever language you’re extracting to may do dead-code detection, though. [Thu Jun 26 16:53:28 2014] alkabetz: does ocaml do that? [Thu Jun 26 16:57:28 2014] A cursory glance at the compiler source suggests it does, but I’m definitely not familiar with the OCaml compiler internals [Thu Jun 26 16:58:45 2014] Error: The 2nd argument of exist still occurs after extraction. [Thu Jun 26 16:59:05 2014] wut? [Thu Jun 26 17:00:27 2014] Please check the Extraction Implicit declarations. [Thu Jun 26 17:00:30 2014] what does that mean [Thu Jun 26 17:00:51 2014] Can you paste a minimal failing example? [Thu Jun 26 17:01:26 2014] no. [Thu Jun 26 17:01:36 2014] :( [Thu Jun 26 17:01:37 2014] it is a very complicated recursion. [Thu Jun 26 17:01:42 2014] and I have no clue ... [Thu Jun 26 17:01:43 2014] Ah. [Thu Jun 26 17:01:45 2014] where to start. [Thu Jun 26 17:02:08 2014] What do your [Extraction] commands look like? [Thu Jun 26 17:02:24 2014] Extraction Language Haskell. [Thu Jun 26 17:02:25 2014] Recursive Extraction fc1. [Thu Jun 26 17:02:43 2014] same for [Thu Jun 26 17:02:45 2014] Extraction "fc1.hs" fc1. [Thu Jun 26 17:02:48 2014] Okay. [Thu Jun 26 17:04:10 2014] Okay, so the second argument of [exist] is the proposition in the Σ type [Thu Jun 26 17:04:32 2014] Where are you passing [Prop]s around in your code? [Thu Jun 26 17:05:55 2014] hm. nowhere? [Thu Jun 26 17:06:06 2014] isn't there some way to find out the problematic part? [Thu Jun 26 17:06:22 2014] I mean, if that’s the only information the extractor gives you … [Thu Jun 26 17:06:35 2014] How can I check that? [Thu Jun 26 17:07:21 2014] What does Proof General / Coqide say when you run the [Recursive Extraction] command? [Thu Jun 26 17:08:34 2014] Toplevel input, characters 15-40: [Thu Jun 26 17:08:37 2014] Error: The 2nd argument of exist still occurs after extraction. [Thu Jun 26 17:08:39 2014] Please check the Extraction Implicit declarations. [Thu Jun 26 17:09:03 2014] Hmm, want to try coqc instead? It might give you a better error. [Thu Jun 26 17:09:40 2014] ok [Thu Jun 26 17:10:28 2014] nope. [Thu Jun 26 17:10:30 2014] same error. [Thu Jun 26 17:10:32 2014] It sounds like you have a [Prop] getting passed around somewhere as an implicit argument, and Coq gets sad when it tries to extract because it expects all [Prop]s to be erasable … but yours isn’t? [Thu Jun 26 17:10:38 2014] Ew. [Thu Jun 26 17:11:34 2014] Have you looked at http://coq.inria.fr/distrib/current/refman/Reference-Manual025.html#sec710 at all? [Thu Jun 26 17:11:43 2014] I suspect this is how you fix it once you figure out where the problem is [Thu Jun 26 17:11:48 2014] Not that that’s terribly useful :/ [Thu Jun 26 17:12:28 2014] can't I just tell coq to ... just extract everything? [Thu Jun 26 17:12:42 2014] You mean, including the [Prop]s? [Thu Jun 26 17:13:44 2014] yes [Thu Jun 26 17:14:00 2014] if I have a language with dead code detection, props are merely good for proof irrelevance [Thu Jun 26 17:14:26 2014] I don’t think you can do that, unfortunately. [Thu Jun 26 17:14:57 2014] At this point, I’d probably start binary-searching your codebase to try to isolate the function that causes extraction problems. :( [Thu Jun 26 17:29:38 2014] that is a *bit* too much work. [Thu Jun 26 17:29:45 2014] for ... 7000 loc [Thu Jun 26 17:30:16 2014] Aw, it’s only 13 bisections :) [Thu Jun 26 17:30:35 2014] You should consider asking on coq-club [Thu Jun 26 17:31:11 2014] is there any situation in which I can not just replace {... | ...} with {... & ...} ? [Thu Jun 26 17:38:03 2014] I just wonder ... why doesn't the typesystem guarantee that this cannot happen? [Thu Jun 26 17:39:05 2014] I'm asking for a list ... everything else is inside the term. [Thu Jun 26 21:01:55 2014] if I have a hypothesis “x = SomeConstructor” and a goal “x <> OtherConstructor”, is there an easy tactic to solve that? [Thu Jun 26 21:02:22 2014] I mean, I can just do “intros not. rewrite not in blah. inversion blah” but it seems like there should be a simpler way [Thu Jun 26 21:06:58 2014] [congruence.] will solve this I believe [Thu Jun 26 21:07:17 2014] ahh. thank you [Thu Jun 26 21:07:43 2014] (I don't know if it's an overkill or not, sorry) [Thu Jun 26 22:49:26 2014] weird thing happened earlier: [Thu Jun 26 22:49:39 2014] induction Vs (* error: hypothesis t depends on Vs! *) [Thu Jun 26 22:49:48 2014] clear t (* no hypothesis ’t’! *) [Fri Jun 27 03:08:45 2014] if I have a hypothesis of the form, IHn' : exists e : N, e N zero succ = C_n n' [Fri Jun 27 03:08:56 2014] how can I choose 'e' to match my goal? [Fri Jun 27 03:14:35 2014] johnw: if it’s a hypothesis, I don’t think you can “choose” which e it is. you don’t know which e it is, only that there is an e [Fri Jun 27 03:14:51 2014] I see, that makes sense [Fri Jun 27 03:15:32 2014] but you can destruct it to introduce the e, whatever it may be [Fri Jun 27 03:15:54 2014] destruct the hypothesis? [Fri Jun 27 03:16:06 2014] oh, weird [Fri Jun 27 03:16:50 2014] well, now I have universe inconsistencies [Fri Jun 27 03:16:54 2014] so I think I may give up here [Fri Jun 27 03:17:09 2014] hmm. that sounds scary [Fri Jun 27 03:17:11 2014] :o [Fri Jun 27 03:34:09 2014] it's too bad too, I was able to complete all the goals [Fri Jun 27 03:34:14 2014] I wonder if there's an easy fix [Fri Jun 27 03:34:39 2014] If you describe a little bit more your problem, maybe someone will be able to help x) [Fri Jun 27 03:34:56 2014] sorry to be obscure [Fri Jun 27 03:35:02 2014] here is the proof attempt: https://gist.github.com/6ae2ecbe63ae3c4501f5 [Fri Jun 27 03:44:55 2014] Hmm, I'm kind of new to this universe inconsistencies stuff, but I'm not sure that you can prove your goal [Fri Jun 27 03:45:35 2014] it seems odd to me that e is parameterized over N, when Ct_ clearly isn't [Fri Jun 27 03:45:54 2014] I have a feeling it isn't complaining more, simply because the shapes appear similar when you aren't trying to fully resolve them [Fri Jun 27 03:45:56 2014] You can get a more informative error if you display universes levels, either through the "View" menu in CoqIDE if you're using it, or with the command "Set Printing Universes." [Fri Jun 27 03:46:16 2014] (cannot enforce Top.6579 <= Top.6581) [Fri Jun 27 03:47:34 2014] Yes, and in your case, Top.6579 is the type of the parameter given to N, and Top.6581 is the type of N itself [Fri Jun 27 03:48:19 2014] Hmm [Fri Jun 27 03:48:24 2014] Or I am saying nonsense [Fri Jun 27 03:48:24 2014] wait [Fri Jun 27 03:48:38 2014] http://adam.chlipala.net/cpdt/html/Universes.html [Fri Jun 27 03:48:48 2014] Maybe the best thing to do is to learn properly about universes :) [Fri Jun 27 03:51:39 2014] Alright, so, scratch what I said before : Top.6579 is the type of N itself, and Top.6581 is the type of the A that is given to N. So when you write [@e N zero succ], you're trying to convert a Top.6579 too a Top.6581 (hence the inequality that Coq wants to enforce) [Fri Jun 27 03:52:16 2014] is there any fix, or am I trying to prove the impossible? [Fri Jun 27 03:52:20 2014] but when you defined N, Coq also added [Top.6581 < Top.6579] to a set of inequalities that have to be respected by the universes managed by Coq [Fri Jun 27 03:55:20 2014] Sorry, I don't know :/ [Fri Jun 27 03:58:57 2014] Well, I don't think you can even state that goal actually [Fri Jun 27 03:59:21 2014] You basically cannot apply an object to itself, if I'm not mistaken [Fri Jun 27 04:00:13 2014] ok, time to sleep then [Fri Jun 27 04:00:15 2014] thank you, Cypi [Fri Jun 27 05:24:21 2014] hm ... isn't coq supposed to ... like ... extract correct programs from accepted proofs? [Fri Jun 27 05:25:00 2014] or am I mistaken? [Fri Jun 27 05:25:18 2014] can an accepted proof yield a wrong program? [Fri Jun 27 05:25:29 2014] and if so ... why? [Fri Jun 27 05:27:50 2014] __ = Prelude.error "Logical or arity value used" [Fri Jun 27 05:27:54 2014] just ... _why_? [Fri Jun 27 05:35:06 2014] schoppenhauer: is not typical to derive a program from a proof. is more typical to write a program, prove properties of the program, then extract executable ocaml/haskell from the program you've written (with the proofs and most of the types erased) [Fri Jun 27 05:41:24 2014] rmk0: but why can a *correct, accepted* proof yield a wrong program? [Fri Jun 27 05:42:45 2014] schoppenhauer: is a hard question to answer... if you're deriving programs from proofs that were constructed from tactics, you've got no guarantee that the program will run in a reasonable amount of time. there could also be bugs in the extraction code (because nobody's verified that extraction is correct), although i think those are rare [Fri Jun 27 05:42:51 2014] is there something specific you're seeing? [Fri Jun 27 05:43:03 2014] rmk0: yes, the above error. [Fri Jun 27 05:43:38 2014] that __ = Prelude.error ... function actually gets called? [Fri Jun 27 05:43:42 2014] yes [Fri Jun 27 05:44:15 2014] i've not extracted to haskell before... is your code public? [Fri Jun 27 05:44:32 2014] not yet. [Fri Jun 27 05:44:46 2014] well, it also extracts the same type twice. [Fri Jun 27 05:44:56 2014] sounds bad [Fri Jun 27 05:45:06 2014] I just don't understand *why* [Fri Jun 27 05:45:56 2014] hard to tell without looking... usually proven unreachable cases would be marked with "undefined" and so on (assert false in ocaml), but if that code is actually being reached, then there's an issue somewhere [Fri Jun 27 05:46:12 2014] probably worth telling the mailing list about it [Fri Jun 27 05:47:33 2014] there appear to be a *lot* of issues with coq when you really work with it. [Fri Jun 27 05:47:48 2014] urhur [Fri Jun 27 05:48:15 2014] i get the impression that the ocaml extraction is a lot more mature than the haskell extraction [Fri Jun 27 05:48:38 2014] i should mention that extraction assumes that you're respecting the preconditions of functions you define when you call them from ocaml/haskell [Fri Jun 27 05:48:42 2014] like, er [Fri Jun 27 05:49:09 2014] let's assume you define a function f that divides its first argument by the second [Fri Jun 27 05:49:20 2014] so in coq, you define it as requiring a proof that the second argument is > 0 [Fri Jun 27 05:49:49 2014] extraction will obviously erase the proof argument, and the extracted code will assume that you never call it "from outside" with the second argument as 0 [Fri Jun 27 05:50:01 2014] so you need to be careful what you expose to external code [Fri Jun 27 05:50:24 2014] rmk0: I directly extract a term of type "List (List Bool)" [Fri Jun 27 05:50:29 2014] rmk0: it has no arguments [Fri Jun 27 05:50:39 2014] hm, right [Fri Jun 27 05:50:52 2014] but I [Fri Jun 27 05:50:58 2014] will t ry the ocaml-extraction [Fri Jun 27 05:51:07 2014] I just don [Fri Jun 27 05:51:14 2014] t know ocaml well enough. [Fri Jun 27 05:57:20 2014] worth it just to see if the same issue is there too [Fri Jun 27 10:43:25 2014] Am I right that "omega can't solve this system" <=> "goal is false" if there is no quantifiers in goal and it consists only from <= and +? [Fri Jun 27 10:44:12 2014] The only two hypotheses consist of <= and + too. [Fri Jun 27 10:56:56 2014] Ah, I did a mistake, now it's ok. [Fri Jun 27 14:17:04 2014] If I have [forall a, a -> b] and [b -> c] as hypotheses, how can I combine them to produce [forall a, a -> c]? [Fri Jun 27 14:18:27 2014] alkabetz: assuming they're named H0 and H1, pose (fun x : a => H1 (H0 x)) [Fri Jun 27 14:19:00 2014] well, x : whatever type a is. [Fri Jun 27 14:19:14 2014] Type, I suppose. [Fri Jun 27 14:19:18 2014] or Prop [Fri Jun 27 14:23:27 2014] Coq doesn’t like that. I get ‘The term "H0 x" has type "x -> b" while it is expected to have type "b".’ [Fri Jun 27 14:24:06 2014] I can do [assert (forall x : Prop, x -> a -> c) by eauto], but that feels a bit ugly [Fri Jun 27 14:24:41 2014] Er, [assert (forall a : Prop, a -> c) by eauto] [Fri Jun 27 14:24:47 2014] (I totally copied the wrong thing there. Sorry.) [Fri Jun 27 14:28:51 2014] I can also do [pose (fun (a : Prop) (pf : a) => H1 (H0 a pf))], it looks like, which seems similarly ugly [Sat Jun 28 05:43:36 2014] if destruct introduces new variables, is there a way to name them? [Sat Jun 28 10:50:46 2014] roosbeef: Yes – see variant 2 under http://coq.inria.fr/refman/Reference-Manual010.html#sec371 [Sat Jun 28 10:53:45 2014] whats a num [Sat Jun 28 10:54:55 2014] It’s literally a number – e.g., [destruct 0] [Sat Jun 28 11:04:24 2014] how does that relate to destructing a hypothesis? [Sat Jun 28 11:55:11 2014] alkabetz, still dont understand but thanks anyway, i had solved it already by modifying the variables on paper :P [Sat Jun 28 12:55:16 2014] Hello [Sat Jun 28 12:55:50 2014] I'm looking for a computer program for writing mathematical proofs [Sat Jun 28 12:56:15 2014] at the moment I'm studying simple theorems from set theory [Sat Jun 28 12:56:41 2014] example: http://i.imgur.com/6SAsw1Z.jpg (kuratowski ordered pairs) [Sat Jun 28 12:56:58 2014] I'm wondering if coq can be good for me [Sat Jun 28 12:57:08 2014] Whoa, that’s beautiful [Sat Jun 28 12:57:16 2014] I’ve never actually seen somebody do a formal proof on paper [Sat Jun 28 12:58:12 2014] i use natural deduction [Sat Jun 28 12:58:19 2014] first order logic [Sat Jun 28 12:58:28 2014] nothing exotic [Sat Jun 28 12:58:30 2014] So, all the computer theorem provers use higher-order logic. [Sat Jun 28 12:58:35 2014] I don’t know if this matters to you. [Sat Jun 28 12:58:55 2014] But if you’re already used to the detail and commitment required to do formal proofs on paper, learning a theorem prover would probably be a lot of fun. [Sat Jun 28 12:59:36 2014] my goal is to learn math and then physics [Sat Jun 28 12:59:44 2014] * nods [Sat Jun 28 12:59:54 2014] Formal proofs are some pretty deep math :) [Sat Jun 28 13:00:48 2014] i dropped out of university because i couldn't stand the way they addressed theory [Sat Jun 28 13:00:58 2014] i had a hard time at learning the rules [Sat Jun 28 13:01:19 2014] but then i discovered they are rather simple [Sat Jun 28 13:02:07 2014] someone could have described them to me in an afternoon. i spent years instead, on my own. [Sat Jun 28 13:02:17 2014] So, I recomend trying out all of Coq, Agda, and Isabelle. For math, I’ve been happiest with Isabelle, but I use Coq mostly nowadays. (I’m a computer scientist.) [Sat Jun 28 13:04:15 2014] isn't there some example somewhere of a proved theorem like mine? [Sat Jun 28 13:04:43 2014] https://en.wikipedia.org/wiki/Isabelle_(proof_assistant) has an example in Isabelle [Sat Jun 28 13:07:18 2014] isabelle manual is a whopping 223 pages! [Sat Jun 28 13:08:25 2014] Yeah, Isabelle is /very/ well-documented [Sat Jun 28 13:08:47 2014] Coq is also pretty well-documented, but Agda documentation is unfortunately fairly sparse [Sat Jun 28 13:15:53 2014] coq tutorial seems shorter and more spot on [Sat Jun 28 13:16:09 2014] I’d recommend /Software Foundations/ for Coq (it’s free online) [Sat Jun 28 13:16:27 2014] It is more geared at CS folk, though [Sat Jun 28 13:17:32 2014] * is installing coq [Sat Jun 28 15:33:58 2014] In CPDT, Adam says that ‘Some very recent versions of Coq include mechanisms for removing hints from databases’. Anybody know more about this? [Sat Jun 28 15:34:29 2014] Alternatively, can I run [auto] without the core hint database loaded? [Sat Jun 28 15:38:19 2014] Ah, it looks like [Remove Hints] is slated for Coq 8.5 :/ [Sat Jun 28 17:01:24 2014] Oh hey! $coq_expert says I should use [auto with nocore], which works! [Mon Jun 30 03:32:20 2014] is there something like Forall, except for _ -> Set instead of _ -> Prop? [Mon Jun 30 03:33:46 2014] ....forall? [Mon Jun 30 03:34:27 2014] yeah forall should still work with Set [Mon Jun 30 03:35:04 2014] hmm. I guess I really want something like a heterogeneous list [Mon Jun 30 03:35:37 2014] sure, you can totally do that in Coq [Mon Jun 30 03:35:40 2014] so I have a thing, (S -> Set) and a list S, then I want Forall’Set (list S) [Mon Jun 30 03:36:06 2014] http://adam.chlipala.net/cpdt/html/DataStruct.html [Mon Jun 30 03:36:41 2014] cool, thanks [Mon Jun 30 03:36:59 2014] I thought there might just be something in the library. Forall seems exactly the same, right, except that it’s restricted to Prop [Tue Jul 1 02:58:52 2014] hello folks. i got a question. [Tue Jul 1 02:59:13 2014] it's about how 'apply' tactic works. [Tue Jul 1 03:00:39 2014] http://lpaste.net/106695 [Tue Jul 1 03:00:49 2014] i am confused on the usage of apply here. [Tue Jul 1 03:01:21 2014] which seems splitted the goal into two subgoal but i don't know why this is. [Tue Jul 1 03:02:20 2014] sorry, code updated. the definition of 'classic' and 'excluded_middle' now included. [Tue Jul 1 04:29:21 2014] shouya : when Coq applies [P -> False] to H, it will deduce [False] from the conclusion [P] in H. This is what you obtain in the first goal, where you have to prove your main goal and H is replaced simply bi [False]. [Tue Jul 1 04:29:47 2014] But to be able to deduce [False] from [P] in H, you first have to prove [(P -> False) -> False] [Tue Jul 1 04:29:51 2014] this is the second goal [Tue Jul 1 04:30:50 2014] Cypi_: i see. it's all clear now. [Tue Jul 1 04:30:57 2014] Cypi_: thank you :) [Tue Jul 1 04:31:08 2014] So if you have [H1 : A -> B -> C -> D] and [H2 : D -> E], when you do [apply H2 in H1.], Coq generates the subgoals for A, B and C, and replace H1 by E for your main goal. [Tue Jul 1 04:32:41 2014] Cypi_: yup. [Tue Jul 1 11:17:19 2014] Hello. [Tue Jul 1 11:17:45 2014] Can I parameterize Ltac expressions with "usual" like nats or records? [Tue Jul 1 11:18:07 2014] I would like to implement some semigroup-polymorphic tactics, but seems that I can't =/ [Tue Jul 1 11:25:14 2014] Well, Ltac seems to be possible to take semigroup as argument, but somehow I can't rewrite with it's associativity law. [Tue Jul 1 11:36:16 2014] Rc43: what is your definition for semigroups? [Tue Jul 1 11:37:01 2014] magma + assoc [Tue Jul 1 11:37:14 2014] i mean coq definition [Tue Jul 1 11:37:26 2014] typeclass? records? informal set of required theorems? [Tue Jul 1 11:37:58 2014] anyway Ltac arguments work in a rather primitive way [Tue Jul 1 11:40:30 2014] you can get "regular" coq arguments (works best with Tactic Notation) but can't really do anything with them except inlining them into expressions [Tue Jul 1 11:44:17 2014] so whatever way you define your semigroups, you need functions that, given a semigroup, gives you the neutral element/law/associativity lemma [Tue Jul 1 11:44:34 2014] the easiest way to do that is probably to use typeclasses and let Coq figure out the correct instantiation for you [Tue Jul 1 11:46:08 2014] elarnon, yep, it is type class [Tue Jul 1 11:46:36 2014] elarnon, just rewrite says something that it expects "Semigroup.op x (Smeigroup.op y z)" instead of x + y + z [Tue Jul 1 11:46:44 2014] And I don't know how to fix it. [Tue Jul 1 11:46:45 2014] then you shouldn't need to know the actual type of your typeclass in your ltac [Tue Jul 1 11:46:54 2014] can you show the definition of your typeclass? [Tue Jul 1 11:47:02 2014] elarnon, sure, one moment [Tue Jul 1 11:47:19 2014] I will minimize example of ltac I try. [Tue Jul 1 11:54:33 2014] elarnon, aah, seems I did mistake at the very beginning, it rewrites ok =/ [Tue Jul 1 11:55:37 2014] I even found the way imitate loops with "regular" nat, match on S _ | O, but don't use n' from (S n'); use (pred n) instead. [Tue Jul 1 12:48:29 2014] Is there common name for something with neutral element? [Tue Jul 1 12:48:42 2014] Like "Monoid = + Semigroup". [Tue Jul 1 12:51:58 2014] wikipedia says unital [Tue Jul 1 12:52:39 2014] https://en.wikipedia.org/wiki/Magma_(algebra)#Classification_by_properties [Tue Jul 1 13:00:04 2014] elarnon, oh, thanks [Tue Jul 1 14:01:12 2014] Aaah, tactics fully-polymorphic on type-classes don't work well =/ [Tue Jul 1 14:01:38 2014] E.g. when different semigroups should be tried. [Tue Jul 1 14:02:13 2014] Like "rewrite assoc" on "x + 0 + 1 * x + x * 1 = x + x + x". [Tue Jul 1 14:03:31 2014] Because Coq searchs semigroup instance using information about founded implicit arguments, not simultaneously =/ [Tue Jul 1 14:05:01 2014] *monoid instance [Tue Jul 1 14:21:03 2014] is there any library to work with indexed sums? [Tue Jul 1 16:54:10 2014] Can anyone tell me whether https://github.com/jwiegley/simple-conduit/blob/master/coq/Category.v#L209 looks like a properly stated theorem about the UMP for products, and if my subsequent proof for tuples in Coq looks reasonable? [Tue Jul 1 16:54:55 2014] elarnon: hello! [Tue Jul 1 17:04:29 2014] johnw: hi! how was your trip home? [Tue Jul 1 17:05:50 2014] your definition of product seems weird to me [Tue Jul 1 17:06:05 2014] it was uneventful; how about yoU? [Tue Jul 1 17:06:15 2014] I thought it might be weird, I just didn't know in what way... [Tue Jul 1 17:06:43 2014] as far as i understand (is afaiu a valid abbreviation?) the Coq arrow shouldn't appear there [Tue Jul 1 17:07:14 2014] where exactly? [Tue Jul 1 17:07:45 2014] elarnon, I always use "AIUI", shortening "as I understand it". [Tue Jul 1 17:07:50 2014] I have -> as the Coq arrow, and → as the categorical arrow [Tue Jul 1 17:08:05 2014] the trip was too long for my taste, and my right foot didn't like it much, but it was otherwise ok [Tue Jul 1 17:08:17 2014] but I don't see how to do objC → objC → objC, because I don't have currying, since currying needs products :) [Tue Jul 1 17:08:29 2014] but you are defining the product [Tue Jul 1 17:08:43 2014] and homC is defined with Coq arrows on line 40 [Tue Jul 1 17:08:49 2014] let me think about what i would have written [Tue Jul 1 17:08:52 2014] but can I define the product in terms of a product? [Tue Jul 1 17:08:56 2014] k [Tue Jul 1 17:09:42 2014] the Coq arrow on the definition of Category are required b/c you are creating your model [Tue Jul 1 17:09:51 2014] but then Coq arrows should have been abstracted [Tue Jul 1 17:10:29 2014] I'm not sure what ob → ob → ob would even mean though [Tue Jul 1 17:10:32 2014] so I guess P and X are just unneeded [Tue Jul 1 17:10:41 2014] oh [Tue Jul 1 17:10:52 2014] hmm [Tue Jul 1 17:11:08 2014] then p1 becomes what? [Tue Jul 1 17:11:17 2014] Class Product `{C : Category objC} {A B : objC} (P : objC) (p1 : P \to A) (p2 : P \to B) := ... [Tue Jul 1 17:11:29 2014] I see [Tue Jul 1 17:11:39 2014] trying to imply that these things have "types" is wrong [Tue Jul 1 17:13:11 2014] hmm [Tue Jul 1 17:13:24 2014] so now what does my instance become [Tue Jul 1 17:13:26 2014] well "P : objC -> objC -> objC" doesn't make any sense in a categorical way as you said [Tue Jul 1 17:13:28 2014] Global Instance Tuple_Product : @Product Coq Tuple (@fst A B) snd. is not right anymore [Tue Jul 1 17:14:54 2014] well Global Instance Tuple_Product : @Product Coq A B (A * B) fst snd should be [Tue Jul 1 17:15:14 2014] ah, I've been wondering about this [Tue Jul 1 17:15:18 2014] how do I get a general '*' operator? [Tue Jul 1 17:15:26 2014] every time I use it, it wants ℕ [Tue Jul 1 17:15:32 2014] what do you mean by general? [Tue Jul 1 17:15:39 2014] something not specialized to nats [Tue Jul 1 17:16:08 2014] you get into the quirks of Coq's notation system [Tue Jul 1 17:16:35 2014] what is a notation for in this case? [Tue Jul 1 17:16:35 2014] are you familiar with the way notation scopes work? [Tue Jul 1 17:16:38 2014] yes [Tue Jul 1 17:16:58 2014] I have a category_scope [Tue Jul 1 17:17:09 2014] "*" is just a notation for mult (or whatever it is called) in scope nat_scope [Tue Jul 1 17:18:01 2014] so various options are open to you [Tue Jul 1 17:18:15 2014] you can close nat_scope and redefine a notation for * [Tue Jul 1 17:18:32 2014] what is your use of * here referring to? [Tue Jul 1 17:18:42 2014] you can use scope delimiters for your notation (as in (A * B)%type that you have to type in the body of a definition if you need it) [Tue Jul 1 17:19:24 2014] well whatever you want the notation to be ; maybe to a 'mult' member of some Num typeclass? [Tue Jul 1 17:19:53 2014] I mean, in this case [Tue Jul 1 17:20:01 2014] I'm defining general products of (Type * Type) [Tue Jul 1 17:20:05 2014] what does "*" mean in that case? [Tue Jul 1 17:20:19 2014] I.e., what would the Notation rewrite into? [Tue Jul 1 17:20:25 2014] is Type the Coq Type? [Tue Jul 1 17:20:29 2014] in this case, yes [Tue Jul 1 17:20:39 2014] Tuple is the product of the Coq category [Tue Jul 1 17:20:55 2014] i'm not sure ; you can just Unset Printing Notations. and see by yourself [Tue Jul 1 17:21:00 2014] I'm trying to prove that "Coq" has categorical products [Tue Jul 1 17:21:26 2014] hmm [Tue Jul 1 17:21:30 2014] oh, you mean my use of "*"in the definition? [Tue Jul 1 17:21:30 2014] i feel like I'm missing something here [Tue Jul 1 17:21:32 2014] yes [Tue Jul 1 17:21:41 2014] you can just use your "Tuple" class if you want [Tue Jul 1 17:21:47 2014] but Coq has built-in tuple types [Tue Jul 1 17:22:11 2014] I thought it might, but I couldn't find them [Tue Jul 1 17:22:25 2014] well * is a notation for them [Tue Jul 1 17:22:37 2014] I see, so somehow these nat tuples are getting in my way [Tue Jul 1 17:22:41 2014] (and they are probably defined through an Inductive similar to yours, but with a different name) [Tue Jul 1 17:22:50 2014] yes [Tue Jul 1 17:23:00 2014] yay, it worked [Tue Jul 1 17:23:08 2014] Global Instance Tuple_Product : Product (Tuple A B) fst snd. [Tue Jul 1 17:23:09 2014] so coq has a special scope named "type_scope" which it uses by default anywhere it is expecting a type [Tue Jul 1 17:23:25 2014] and it do not open that scope elsewhere [Tue Jul 1 17:23:38 2014] hence the (A * B)%type [Tue Jul 1 17:24:50 2014] is there a HOWTO anywhere about using the builtin tuples instead of these nat-specific tuples? [Tue Jul 1 17:24:54 2014] so Coq's "built-in" product is called prod and has exactly the same definition as your tuple modulo alpha-renaming [Tue Jul 1 17:25:06 2014] it is not nat-specific tuples [Tue Jul 1 17:25:15 2014] ah, "prod", that's what I was looking for [Tue Jul 1 17:25:27 2014] when you write (A * B) Coq rewrites this to "mult A B", i.e. the natural numbers multiplication [Tue Jul 1 17:25:31 2014] ah [Tue Jul 1 17:25:34 2014] i see [Tue Jul 1 17:25:41 2014] so that notation is getting in the way of the type_scope notation? [Tue Jul 1 17:26:05 2014] yes [Tue Jul 1 17:26:17 2014] how do I unset a notation? [Tue Jul 1 17:27:11 2014] you can't afaik ; but you can close the nat_scope [Tue Jul 1 17:27:32 2014] Close Scope nat_scope. [Tue Jul 1 17:27:34 2014] well, or just re-open type_scope to make it shadow the other [Tue Jul 1 17:27:40 2014] with Open Scope type_scope. [Tue Jul 1 17:27:49 2014] (coq first searches the last opened scope) [Tue Jul 1 17:28:14 2014] excellent [Tue Jul 1 17:31:59 2014] huh, even though prod is nearly identical, using (prod A B) doesn't work, but (Tuple A B) does [Tue Jul 1 18:48:18 2014] how is "not equal" symbol in CPDT book printed in Coq syntax? [Tue Jul 1 18:52:36 2014] Can you point to a specific source file? [Tue Jul 1 18:52:51 2014] (Or, equivalently, a specific chapter?) [Tue Jul 1 18:53:40 2014] alkabetz: page 111 [Tue Jul 1 18:53:48 2014] or chapter 6.2 [Tue Jul 1 18:54:10 2014] I don't have any source files [Tue Jul 1 18:54:47 2014] Ah, it’s written <>: http://adam.chlipala.net/cpdt/repo/file/1dd9d8664853/src/Subset.v#l410 [Tue Jul 1 18:55:52 2014] alkabetz: thanks! [Tue Jul 1 19:42:24 2014] You’re welcome! [Tue Jul 1 20:46:06 2014] How can I declare local Ltac procedure inside other Ltac procedure? [Tue Jul 1 20:48:58 2014] Ah, I found it. [Tue Jul 1 20:49:10 2014] Ltac something := ... with other := ... . [Tue Jul 1 20:51:09 2014] Rc43 : in this case, 'other' is not local, it's just defined at the same time. (It allows for mutually recursive functions) [Tue Jul 1 20:51:26 2014] If you want 'other' to be local, you can use : Ltac something := let other := ... in ... [Tue Jul 1 20:51:42 2014] (mutually recursive tactics* I meant) [Tue Jul 1 20:52:15 2014] Cypi, ah, ye; I wanted your way. [Tue Jul 1 22:03:19 2014] would anyone like to help with a proof before I tear my head off of my spine? [Tue Jul 1 22:03:50 2014] I'm trying to prove that composing two applicative functors always yields an applicative functor [Tue Jul 1 22:04:08 2014] I could take a peek [Tue Jul 1 22:04:09 2014] before I was trying to prove this in a more involved context, but now I think I've simplified it down to the core lemma [Tue Jul 1 22:04:15 2014] ok, let me commit what I have. [Tue Jul 1 22:04:50 2014] the repository is https://github.com/jwiegley/simple-conduit [Tue Jul 1 22:04:53 2014] subdirectory "coq" [Tue Jul 1 22:04:56 2014] the file is Functor.v [Tue Jul 1 22:04:59 2014] search for "admit" [Tue Jul 1 22:22:33 2014] I'm looking for a paper proof of this, that applicative functors are closed under composition, but while I find many papers which state it as a fact, none give a proof [Tue Jul 1 22:35:48 2014] johnw: nope. no clue! [Tue Jul 1 22:36:30 2014] ok, thanks amosr [Tue Jul 1 22:36:40 2014] I hate to admit how many things I've tried :) [Wed Jul 2 05:13:39 2014] suppose im trying to prove decidability of a complex statement such as: [Wed Jul 2 05:13:40 2014] exists2 e0 : fletter, countIn eq eq_fletter_dec e0 ll > 0 & fl_Lt l e0 \/ fl_Lt e0 l [Wed Jul 2 05:14:04 2014] how can i chop this up into smaller segments to prove decidability of? [Wed Jul 2 06:48:07 2014] what is `[x]` syntax used in this code from CPDT: `Notation "[|| x ||]" := (inleft _ [x]).` ? [Wed Jul 2 06:48:33 2014] I can't define that notation because I'm getting this error: "Syntax error: ',' or ')' expected after [constr:operconstr level 200] (in [constr:operconstr])." [Wed Jul 2 07:31:08 2014] johnw: i don't have a proof for you, but it seems that you are not proving what you think you are proving (and neither are you in Compose_Functor) - the objects you are considering seem to be F (F X) rather than F (G X) [Wed Jul 2 11:32:05 2014] roosbeef: I use typeclasses to automatically derive such deciders [Wed Jul 2 11:32:25 2014] and he's offline... [Wed Jul 2 12:04:11 2014] is there a way to search for a definition in libs to see what to import? [Wed Jul 2 12:20:17 2014] If you already have it imported, you can use [Locate the_definition.]. [Wed Jul 2 12:20:26 2014] Otherwise, I always just use grep … [Thu Jul 3 05:16:21 2014] ive got this proof state: https://privatepaste.com/98f8bf9183 [Thu Jul 3 05:16:31 2014] how do i get rid of a0? [Thu Jul 3 05:17:00 2014] the exists quantifier is kinda confusing me i guess, are there any libraries for that i should look at? [Thu Jul 3 06:47:55 2014] elarnon: ping [Thu Jul 3 07:02:07 2014] Hello. [Thu Jul 3 07:27:26 2014] what should I do to use leb definition in this module http://coq.inria.fr/distrib/current/stdlib/Coq.NArith.BinNatDef.html ? I'm importing Coq.NArith.BinNatDef but Check leb fails with `Error: The reference leb was not found in the current environment.` [Thu Jul 3 07:30:38 2014] osa1 : N.leb [Thu Jul 3 07:31:06 2014] Cypi: Error: The reference N.leb was not found in the current environment. [Thu Jul 3 07:31:20 2014] oh wait, if worked after I added "Import" [Thu Jul 3 07:31:27 2014] so what's difference between Require and Require Import? [Thu Jul 3 07:33:11 2014] With only "Require", you have to fully qualify leb : [Check Coq.Narith.BinNatDef.N.leb.] (actually, only [Check BinNatDef.N.leb.] works) [Thu Jul 3 07:34:01 2014] With Import, the contents of the module is also imported, so that you can access directly its components [Thu Jul 3 07:35:08 2014] Check http://coq.inria.fr/refman/Reference-Manual008.html#hevea_command147 and http://coq.inria.fr/refman/Reference-Manual004.html#Import [Thu Jul 3 07:54:47 2014] ops, apparently I need a leb that works on nats [Thu Jul 3 07:55:14 2014] why I'm wasting 90% of my time searching for basic functions in the stdlib? [Thu Jul 3 09:25:22 2014] Is there a way to define Inductive mutually with a term? [Thu Jul 3 09:25:48 2014] What do you mean? [Thu Jul 3 09:26:24 2014] Like "Inductive some_type : Type := ... some_struct ... with some_struct := ... some_type ... ." [Thu Jul 3 09:28:35 2014] Well, what you said work, doesn't it? [Thu Jul 3 09:28:38 2014] Where some_struct is term, not inductive. [Thu Jul 3 09:28:52 2014] Ah. [Thu Jul 3 09:29:13 2014] Cypi, but I am not sure that what I want terminates =/ [Thu Jul 3 09:29:51 2014] I want type class instance which has field-type which uses this type class instance itself. [Thu Jul 3 10:51:56 2014] Is it possible to define recursive type class instances? [Thu Jul 3 10:52:03 2014] (Sounds pretty scary.) [Thu Jul 3 10:56:49 2014] Oh, seems that I can just use Fixpoint + Build_. [Thu Jul 3 17:04:36 2014] <{AS}> Hi, is it possible to extend the scope of a let-binding in coq? [Thu Jul 3 17:05:07 2014] <{AS}> such that all let-bindings occur at the outer most scope (when the bound variables are not free in the outer scope) [Thu Jul 3 17:05:39 2014] <{AS}> e.g. if I have R (a) (let b := c in d) and I want let b := c in R (a) (d) [Thu Jul 3 17:53:12 2014] when Coq is showing me a goal, is there a way for it to print the @x forms of all identifiers, so that I can see all implicit arguments? [Thu Jul 3 17:55:49 2014] johnw: Set Printing All. [Thu Jul 3 17:56:23 2014] sweet, thanks [Thu Jul 3 17:57:17 2014] can I do it for a specific identifier? [Thu Jul 3 17:58:23 2014] not that I know of [Thu Jul 3 23:02:50 2014] I have a hypothesis in my context, and an occurance of its left-hand side in my goal, which I've verified with Set Printing All. However, it still says "no subterm matching" [Thu Jul 3 23:03:07 2014] https://gist.github.com/aed819ae66f7be914b5a [Thu Jul 3 23:03:18 2014] I'm trying to do "rewrite H6" [Thu Jul 3 23:03:34 2014] sweet dickens [Thu Jul 3 23:03:47 2014] well, the goal is just mu ∘ fmap mu = mu ∘ fmap mu ∘ fmap eta otherwise :) [Thu Jul 3 23:04:05 2014] i'm following someone else's paper proof step by step, and I'm stuck on not being able to do this rewrite [Thu Jul 3 23:04:23 2014] yeah I'm barely two chapters into SF so I'm not going to be much help to you. :( [Thu Jul 3 23:04:30 2014] oh, weird [Thu Jul 3 23:04:33 2014] if I use replace, it works [Thu Jul 3 23:04:42 2014] spooky? [Thu Jul 3 23:04:58 2014] yeah, I've actually run into this a lot, where replace won't work but assert will, and now vice-versa [Thu Jul 3 23:05:07 2014] I don't quite understand the subtle differences between them yet [Thu Jul 3 23:35:17 2014] if I have an instance which defines basically fmap := fmap . fmap, and I'm in a situation where I believe that instance is in scope, how can I "unfold" that fmap into fmap . fmap? [Fri Jul 4 00:31:24 2014] johnw: holy moly, when it says it cant match the subterms, what patterns does it give you in the error msg? [Fri Jul 4 00:37:35 2014] it states the exact subterm I'm trying to match :) [Fri Jul 4 01:01:57 2014] oh :( [Fri Jul 4 05:19:27 2014] is there a way to have separate notations based on the types used for a polymorphic function? [Fri Jul 4 05:19:47 2014] i'm looking at 7 instances of fmap, but they're not all the same fmap, which makes it very hard to determine what the goal actually is [Fri Jul 4 05:25:49 2014] for example, if it's really (@fmap M _ ...), I'd like it to print fmap[M] [Fri Jul 4 05:28:23 2014] ah, got it: Notation "fmap[ M ]" := (@fmap M _ _ _ _) (at level 68). [Fri Jul 4 05:31:04 2014] and: Notation "fmap[ M N ]" := (@fmap (fun X => M (N X)) _ _ _ _) (at level 66). [Fri Jul 4 05:31:07 2014] now it's perfect [Fri Jul 4 08:29:43 2014] Hello. [Fri Jul 4 08:29:59 2014] Is it possible to defined Fixpoint with tactics? [Fri Jul 4 08:30:06 2014] Without Fix combinator or something. [Fri Jul 4 08:30:17 2014] I am getting error on "Defined." stage. [Fri Jul 4 08:33:15 2014] It is possible: http://lpaste.net/106918 [Fri Jul 4 08:34:05 2014] Cypi, ok, thanks; therefore I will search bugs in my definition. [Fri Jul 4 08:38:24 2014] Hum, my definition is actually false, but don't mind it, it still shows that you can use tactics with Fixpoint :-° [Fri Jul 4 08:39:12 2014] Cypi, I have localised my problem, it is because of incorrect recursive call (though I don't know yet why). [Fri Jul 4 08:43:35 2014] Rc43: just "clear" everything you don't need to make a recursive call, it usually helps. [Fri Jul 4 08:49:02 2014] gdsfh, actually it is pretty small definition, I have only one rec. call (well, second is commented now). [Fri Jul 4 08:49:28 2014] And message is weird "has not enough arguments" while there is only one argument to rec. function. [Fri Jul 4 08:49:43 2014] (and it is given) [Fri Jul 4 08:53:53 2014] Hmm, I commented the single rec. call (replaced with admit) and error didn't dissapear. [Fri Jul 4 08:57:22 2014] Could "induction" be the reason of that? [Fri Jul 4 08:59:17 2014] Indeed, "Show Proof." shows that there is redundant call. [Fri Jul 4 08:59:38 2014] (Not redundant, but surprizing for me.) [Fri Jul 4 09:00:11 2014] Why does it use recursion instead of induction principle? [Fri Jul 4 09:01:37 2014] Ah, I am stupid, it's "_admitted". [Fri Jul 4 09:02:02 2014] Rc43: because. :] Maybe you should supply induction principle if you want it to be used? [Fri Jul 4 09:04:03 2014] gdsfh, no-no, it was my distraction, no rec calls at all, nat_rect is used as it should be. [Fri Jul 4 09:04:30 2014] gdsfh, so there is no rec calls at all, but message says that "not enough arguments". [Fri Jul 4 09:06:26 2014] Rc43: I faced similar problem years ago, but can't remember what caused it. If you have small standalone example, I could try to help. [Fri Jul 4 09:06:57 2014] gdsfh, I will try to reduce it [Fri Jul 4 09:12:59 2014] Rc43: maybe after reducing it will work, so show minimal example that doesn't work; but please, without external dependencies. [Fri Jul 4 09:14:15 2014] btw, does anybody know about coq+opam progress? Some guys wanted to use them together (in coq-club iirc). [Fri Jul 4 09:17:24 2014] gdsfh, you mean intention to install coq via opam? [Fri Jul 4 09:18:16 2014] Rc43: coq + some widely used libraries/extensions, like mtac, ssreflect, CoLoR. [Fri Jul 4 09:18:48 2014] + custom repositories (I use it in OCaml development, very handy). [Fri Jul 4 09:24:08 2014] gdsfh, yep, that would be great thing. [Fri Jul 4 09:25:48 2014] gdsfh, seems that this message is occured on every Fixpoint with admit. [Fri Jul 4 09:26:07 2014] gdsfh, at least on "Fixpoint test (n : nat) : nat. admit. Defined." [Fri Jul 4 09:26:53 2014] Don't understand yet what can be wrong in "fix test (n : nat) : nat => test_admitted test n". [Fri Jul 4 09:27:35 2014] Aaaah, I understood. [Fri Jul 4 09:27:52 2014] Haha, it just sees plain "test" without args and complains about it. [Fri Jul 4 09:29:59 2014] really, "test" needs arguments. btw, you can move arguments that change on recursive calls to right, it simplifies writing of fixpoint. [Fri Jul 4 09:31:14 2014] gdfsh, why does it? [Fri Jul 4 09:36:18 2014] Rc43: why fixpoints needs arguments? It's about termination, as I remember. [Fri Jul 4 09:41:10 2014] If you just allow test_admitted to take test as an argument this way, I guess you wouldn't know what test_admitted will do with foo [Fri Jul 4 09:41:44 2014] It could just call foo again on some nat, and you would end up with an infinite loop [Fri Jul 4 09:43:04 2014] gdsfh, no :) Why does arguments on right instead of left help to write fixpoints? [Fri Jul 4 09:43:40 2014] Cypi, why did Coq generate such Coq? [Fri Jul 4 09:43:51 2014] Cypi, couldn't it just place test_admitted without arguments? [Fri Jul 4 09:44:41 2014] I don't know if it's just a weakness of the "admitted" tactic, which shouldn't occur anyway in finalized proofs. [Fri Jul 4 09:45:20 2014] admit* [Fri Jul 4 09:45:26 2014] You can just write "Axiom test_admitted : nat. exact test_admitted." or something similar if you want, it must be close to what admit would do, I guess [Fri Jul 4 09:47:39 2014] Cypi, yep, sure. Just was surprizing and spent some time. [Fri Jul 4 09:48:10 2014] Rc43: because you don't need to pass these arguments on each recursive call. Take a look at http://pastebin.com/nywncwFE , "f" is constant on each call. [Fri Jul 4 09:48:12 2014] Btw, in this particular case it is possible just ot use "Admitted." [Fri Jul 4 09:48:38 2014] Yes, since Admitted will abort the proof altogether and replace your definition with an Axiom [Fri Jul 4 09:48:49 2014] it won't just fill one gap with an axiom [Fri Jul 4 09:50:15 2014] Cypi, ah, I didn't know. [Fri Jul 4 09:50:47 2014] Cypi, I thought that it is just syntax sugar for "admit. Qed." [Fri Jul 4 09:51:12 2014] Nope, especially since it works for any number of remaining subgoals :p [Fri Jul 4 09:58:41 2014] Hmm, so I figure out now that I need "Fixpoint f", which depends on "Definition g.", which depends on "f" again. [Fri Jul 4 09:58:43 2014] But I want to defined "f" with tactics; is there syntax for such mutual definition? [Fri Jul 4 10:01:14 2014] how do I import stream type used here http://adam.chlipala.net/cpdt/repo/file/1dd9d8664853/src/GeneralRec.v#l110? [Fri Jul 4 10:01:27 2014] Rc43: "Fixpoint foo (n : nat) : nat with bar (n : nat) : nat.", and then you end up with two subgoals. [Fri Jul 4 10:03:16 2014] Cypi, "Fixpoints should be on the same mutual inductive declaration." [Fri Jul 4 10:03:23 2014] Cypi, (in my case). [Fri Jul 4 10:03:58 2014] Both f and g are "terms". [Fri Jul 4 10:04:13 2014] Hum, I don't know what it means, sorry :o . (I'm learning as I am answering you actually, don't take my words as good advice, just as something that worked for me) [Fri Jul 4 10:05:19 2014] Oh, I just put non-recursive arguments into rgight in "f" and everything is ok. [Fri Jul 4 10:06:10 2014] I mean I replaced "Fixpoint f (n : nat) (xs ys : list ...) : ..." with "Fixpoint f (n : nat) : list ...". [Fri Jul 4 10:07:35 2014] Ah, still can't unfold "g" inside proof of "f". [Fri Jul 4 10:08:08 2014] Maybe I need to decrease its argument =/ [Fri Jul 4 10:08:38 2014] I think so. Apparently Coq heuristics for fixpoints isn't clever enough to figure it out in such cases :/ [Fri Jul 4 10:09:12 2014] Ah wait, you want to unfold [Fri Jul 4 10:09:23 2014] hum [Fri Jul 4 10:09:25 2014] Hmm, even with "smaller" argument Coq can't "coerce it to evaluable reference". [Fri Jul 4 10:10:11 2014] Well yes, you are defining both f and g at the same time with a Fixpoint, so until the definition is complete, f and g aren't bound to anything, they only have a type. [Fri Jul 4 10:10:33 2014] Hmm, how could you do that... [Fri Jul 4 10:11:05 2014] Cypi, maybe it is because what you just said. [Fri Jul 4 10:11:14 2014] *because of [Fri Jul 4 10:19:12 2014] Ow, and I can't use "h" in type of "g" while defining "Fixpoint f : ... with g : ... with h : ... ." [Fri Jul 4 10:19:13 2014] =/ [Fri Jul 4 10:20:41 2014] Reasonably though (since no value binded to name "h" so far). [Fri Jul 4 11:41:18 2014] Has anybody an idea about how to define record (instance of type class), which is recursive through its field? [Fri Jul 4 11:42:52 2014] E.g. Fixpoint record (S n) : ... := { x := ... ; y := .... @x record n ... }. [Fri Jul 4 11:44:02 2014] My problem is in that "@x" can't be replaced with its body (because definition isn't complete), so I just can't use "record" inside definition of "y". [Fri Jul 4 14:28:10 2014] in CPDT chapter 7.1 this is said "... yet we know this[merge sort] is a well-founded recursive definition" how do we know about that? [Fri Jul 4 14:43:48 2014] I'm also wondering how well-founded recursion is encoded. is there something magic going on under the hood to make termination checker accept such definitions(e.g. by somehow making Fix special), or is it somehow encoded with exsiting basic rules? can we implement that as an external library? [Fri Jul 4 14:52:24 2014] also, are there any other ways to tell termination checker that a function actually teminates? I mean other than structural recursive and well-founded ones? [Fri Jul 4 15:07:51 2014] how can I search in standard library? [Fri Jul 4 15:11:08 2014] osa1: I’m a fan of grep for that … [Fri Jul 4 16:20:53 2014] hi (bonjour) [Fri Jul 4 19:00:18 2014] `match E as Y in (T x1 ... xn) return U with | C z1 .. zm => B end` in this code are Y and x1 ... xn bound in B ? [Fri Jul 4 19:51:26 2014] can anyone help me with this proof http://lpaste.net/106947 ? This code is from CPDT and I want to prove it without using magical CPDT tactics. [Fri Jul 4 20:10:41 2014] osa1: you'll need to write the match in the proof term by hand because coq's destruct isn't smart enough to handle this kind of dependent match [Sun Jul 6 17:02:41 2014] when is "dependent destruction" tactic added to standard tactics library? [Sun Jul 6 17:03:57 2014] I don't think there are any plans to do so [Sun Jul 6 17:05:15 2014] am I looking to wrong page http://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_tactic80 [Sun Jul 6 17:08:24 2014] Erm, maybe I don't know what you're askig [Sun Jul 6 17:09:38 2014] ezyang: I'm trying to use "dependent destruction" tactic explained in that link but I'm getting `Syntax error: 'generalize_eqs_vars' or 'generalize_eqs' or 'rewrite' or 'simple' 'inversion' expected after 'dependent' (in [tactic:simple_tactic]).` so I'm wondering if I'm doing some stupid mistake or I need to update Co [Sun Jul 6 17:09:39 2014] Coq* [Sun Jul 6 17:16:46 2014] I'm using 8.4pl2 and latest version appears to be 8.4pl4 [Sun Jul 6 17:17:07 2014] so any comments before I update Coq? [Sun Jul 6 17:32:41 2014] oh, that error. You need to import some module [Sun Jul 6 18:46:53 2014] How do I hide symbols from an earlier imported module? [Sun Jul 6 18:51:51 2014] johnw: I don't believe that's possible.. but I'm pretty sure the ordering of the imports matters, so if you have bindings that shadow earlier imports, if you import those AFTER the originals then you should be okay.. err.. I think.. [Sun Jul 6 18:52:17 2014] i'm running into conflicts between notations [Sun Jul 6 18:53:01 2014] I've only been present for conversations between people that have had a similar problem.. the import order matters is the only thing I remember out of it.. I've not encountered it myself, sorry mate. :( [Sun Jul 6 18:53:35 2014] ok, I worked around it [Sun Jul 6 18:53:37 2014] thx [Sun Jul 6 18:53:45 2014] \o/ [Sun Jul 6 19:24:28 2014] what does it mean when you use {} to specify a type class instance? [Sun Jul 6 19:24:35 2014] like: Category { Fobj : C->D & Functor C D Fobj } (...) [Sun Jul 6 19:29:35 2014] implicit args for the instance? [Sun Jul 6 19:29:43 2014] i'm not entirely sure myself, thats just a guess [Sun Jul 6 19:41:51 2014] woohoo, just encountered a case where I had to use sigma types; never quite understood it before, now it clicked [Mon Jul 7 04:06:56 2014] why is it that when I have a typeclass in my context, like H0 : Monad (EitherT E M), that I can't simplify any of the methods from that typeclass, even though there is an instance for it in scope? [Mon Jul 7 04:08:39 2014] what does it say when you try [Mon Jul 7 04:08:47 2014] it just doesn't simplify [Mon Jul 7 04:08:49 2014] my goal says: [Mon Jul 7 04:08:55 2014] (EitherT_ E M A ∘ eta/M ∘ eta/Either E) x = (eta/EitherT E M) x [Mon Jul 7 04:09:05 2014] that should just be refl, since the left is exactly the implementation of EitherT_eta [Mon Jul 7 04:09:19 2014] beta eta/EitherT E M is not "resolving" down to the method I used to implement it: [Mon Jul 7 04:09:29 2014] eta := fun _ => EitherT_eta [Mon Jul 7 04:09:35 2014] I've noticed this in other places before [Mon Jul 7 04:09:50 2014] here's a simple example: https://gist.github.com/977fe1d45b66a824c947 [Mon Jul 7 04:09:57 2014] rather, see the whole file: [Mon Jul 7 04:10:00 2014] https://gist.github.com/dd5bc6ee27d9db3e462a [Mon Jul 7 04:10:13 2014] if I add a constraint `{Functor (fun X => F (G X))} [Mon Jul 7 04:10:20 2014] suddenly I can't unfold compose_fmap anymore [Mon Jul 7 04:10:35 2014] it seems I can only see the instance methods when the type class constraint isn't present [Mon Jul 7 04:16:08 2014] (i dont think i would be of much help here, being a relative novice at this) [Mon Jul 7 04:23:08 2014] ah well, I'm missing something simple [Mon Jul 7 04:23:12 2014] elarnon would know :) [Mon Jul 7 04:24:01 2014] hm? [Mon Jul 7 04:24:07 2014] hi elarnon! [Mon Jul 7 04:24:13 2014] Just having some issues with type classes [Mon Jul 7 04:24:38 2014] hi johnw [Mon Jul 7 04:24:49 2014] I finished proving all those things I was trying to prove [Mon Jul 7 04:25:06 2014] nice! [Mon Jul 7 04:25:15 2014] yes, it feels good [Mon Jul 7 04:25:26 2014] now I'm trying to prove that my MonadTrans instance is lawful [Mon Jul 7 04:25:33 2014] but I'm stuck on a simplification issue [Mon Jul 7 04:25:42 2014] 03:10 https://gist.github.com/dd5bc6ee27d9db3e462a [Mon Jul 7 04:25:43 2014] 03:10 if I add a constraint `{Functor (fun X => F (G X))} [Mon Jul 7 04:25:43 2014] 03:10 suddenly I can't unfold compose_fmap anymore [Mon Jul 7 04:25:50 2014] that is a good example of the problem [Mon Jul 7 04:26:06 2014] why does having a constraint make the instance opaque? [Mon Jul 7 04:26:09 2014] i'll take a quick look to see if i can help [Mon Jul 7 04:27:37 2014] that would be great, thanks [Mon Jul 7 04:28:05 2014] what is the error you get? [Mon Jul 7 04:28:09 2014] no erro [Mon Jul 7 04:28:10 2014] r [Mon Jul 7 04:28:19 2014] (or alternatively, where can i see the Functor.v file?) [Mon Jul 7 04:28:19 2014] just that unfold does nothing [Mon Jul 7 04:28:32 2014] https://github.com/jwiegley/category-theory/blob/master/Endo/Functor.v [Mon Jul 7 04:28:35 2014] oh hm [Mon Jul 7 04:31:44 2014] wrong file: https://github.com/jwiegley/category-theory/blob/master/Endo/FCompose.v [Mon Jul 7 04:31:46 2014] that's what I meant [Mon Jul 7 04:31:52 2014] oh, I see, n/m [Mon Jul 7 04:33:11 2014] well your goal is no longer the same [Mon Jul 7 04:33:39 2014] it uses is_functor now, rather than Functor_Compose, right? [Mon Jul 7 04:33:45 2014] the `{Functor (fun X => F (G X))} shadows the Functor_Compose instance [Mon Jul 7 04:33:52 2014] right [Mon Jul 7 04:33:58 2014] how do I unshadow? [Mon Jul 7 04:34:08 2014] I mean, the instance satisfies that constraint [Mon Jul 7 04:34:26 2014] hmm.. because I'm parametrizing on the instance? [Mon Jul 7 04:34:32 2014] yes [Mon Jul 7 04:34:37 2014] I'm allowing the user to select any instance of that type [Mon Jul 7 04:34:38 2014] ah, I see [Mon Jul 7 04:34:39 2014] hmm [Mon Jul 7 04:34:42 2014] so you don't know what is the definition of this fmap anymore [Mon Jul 7 04:34:48 2014] that actually makes sense :) [Mon Jul 7 04:34:52 2014] it may be something completely unrelated to fmap_compose as far as Coq knows [Mon Jul 7 04:35:03 2014] right [Mon Jul 7 04:35:23 2014] it's like having a forall on the instance type [Mon Jul 7 04:35:51 2014] yes, you are saying this is true for any instance [Mon Jul 7 04:36:27 2014] you are actually trying to prove this for any function with same type as compose_fmap [Mon Jul 7 04:37:05 2014] that is awesome, thanks elarnon [Mon Jul 7 04:37:13 2014] you answered me perfectly :) [Mon Jul 7 04:37:49 2014] you're welcome :-) [Mon Jul 7 04:37:51 2014] and with that, my problem is fixed [Mon Jul 7 04:38:13 2014] i just had to make my typeclass dictionary be a parameter of the MonadTrans type class, rather than a parameter of each law [Mon Jul 7 04:40:48 2014] do you really need to use Global Instance btw? [Mon Jul 7 04:41:14 2014] it is only different from Instance when using the Section mechanism (which you do not seem to be), iirc [Mon Jul 7 04:41:38 2014] ah, ok [Mon Jul 7 04:41:44 2014] I just copied that from elsewhere when I started [Mon Jul 7 07:57:35 2014] if i have a function with nested functions (fix ... ) args [Mon Jul 7 07:57:49 2014] how can i do case analysis on the arguments? [Mon Jul 7 08:35:22 2014] http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic137 [Mon Jul 7 08:35:29 2014] how does this work? [Mon Jul 7 08:35:33 2014] unfold tactic at 2, 3. [Mon Jul 7 08:35:40 2014] that doesnt work.. [Mon Jul 7 08:36:56 2014] what "doesn't work" mean? [Mon Jul 7 08:37:02 2014] +does [Mon Jul 7 08:39:08 2014] well, coq unfold fl_insert at 2, 3. [Mon Jul 7 08:39:14 2014] oh, the manual seems to be outdated [Mon Jul 7 08:39:16 2014] gives [Mon Jul 7 08:39:16 2014] Syntax error: [unfold_occ] expected after ',' (in [red_tactic]). [Mon Jul 7 08:39:28 2014] you want [unfold fl_insert at 2 3] [Mon Jul 7 08:39:36 2014] ?? [Mon Jul 7 08:39:38 2014] why the brackets [Mon Jul 7 08:39:38 2014] or [unfold fl_insert at 2, fl_insert at 3] [Mon Jul 7 08:39:41 2014] oh [Mon Jul 7 08:39:51 2014] ok :p [Mon Jul 7 08:39:57 2014] makes no sense but lets try [Mon Jul 7 08:40:03 2014] no the bracket means "coq code inside" [Mon Jul 7 08:40:14 2014] ok works :) [Mon Jul 7 08:40:16 2014] thank you [Mon Jul 7 08:40:30 2014] that's the convention in coq/ocaml comments and i tend to use it a bit too much ;-) [Mon Jul 7 08:40:51 2014] in coqdoc/ocamldoc comments* [Mon Jul 7 08:40:57 2014] you dont say :p [Mon Jul 7 08:42:23 2014] Ltac syntax is a bit weird ; when you think comma should be a separator but it doesn't work try space (and conversely) [Mon Jul 7 13:33:00 2014] hello, [Mon Jul 7 13:33:14 2014] i got stuck while trying to understand some inductions. [Mon Jul 7 13:33:35 2014] shouya: okay [Mon Jul 7 13:33:50 2014] ianjneu: one minute, i'll paste the code :) [Mon Jul 7 13:35:41 2014] http://lpaste.net/107061 [Mon Jul 7 13:35:47 2014] here, a very simple case. [Mon Jul 7 13:36:13 2014] to prove the transivity of less_or_equal. [Mon Jul 7 13:36:45 2014] you're introducing too many variables. You want your induction to include quantification over c. [Mon Jul 7 13:37:36 2014] over c [Mon Jul 7 13:37:41 2014] what is that? [Mon Jul 7 13:37:44 2014] In this case you don't need induction anyway, since you're using "le_S", which basically did all the work. [Mon Jul 7 13:38:13 2014] nono.. it's from software foundations guide. [Mon Jul 7 13:39:13 2014] Oh, sorry. [assumption] uses the induction hypothesis, nevermind :) [Mon Jul 7 13:39:55 2014] the guide uses induction to prove this. that's a case in the guide: http://www.cis.upenn.edu/~bcpierce/sf/current/Rel.html#lab232 [Mon Jul 7 13:40:00 2014] intros; generalize dependent c; induction H. [Mon Jul 7 13:41:21 2014] ianjneu: thank you... but i am still confused. [Mon Jul 7 13:41:41 2014] my question is about the induction over 'le' [Mon Jul 7 13:42:03 2014] let me state my confusion clearly. [Mon Jul 7 13:42:23 2014] first of all, the type of le is nat -> nat -> Prop, right? [Mon Jul 7 13:42:36 2014] Yes [Mon Jul 7 13:42:42 2014] so 'le a b' should have type of Prop isn't it? [Mon Jul 7 13:42:44 2014] le is an inductive definition that carries more information about the ordering relationship of two natural numbers. [Mon Jul 7 13:42:56 2014] Yes it does [Mon Jul 7 13:43:00 2014] that's why it's valid to be put as a hypo. [Mon Jul 7 13:43:02 2014] and... [Mon Jul 7 13:43:02 2014] You can eliminate Prop into Prop. [Mon Jul 7 13:43:20 2014] why can i perform an induction on a Prop. [Mon Jul 7 13:43:32 2014] relation's return type is Prop. [Mon Jul 7 13:43:34 2014] Prop isn't any inductive type basically. [Mon Jul 7 13:43:41 2014] Because in this case, [le] is an inductive definition [Mon Jul 7 13:44:02 2014] Cypi: okay, that's how i interpret it. fine. [Mon Jul 7 13:44:16 2014] and second, i don't know if i'm understanding correctly. [Mon Jul 7 13:44:50 2014] induction basically means to seperate an inductive definition into each cases, just like what 'destruct' does. [Mon Jul 7 13:45:18 2014] so as the definition of le, showing here: http://lpaste.net/107061 [Mon Jul 7 13:45:42 2014] shouya: yes, but on top of what destruct does, it also gives you a proof for the recursive occurences of the same type [Mon Jul 7 13:45:57 2014] Ptival: yup that's no problem. [Mon Jul 7 13:46:20 2014] but i found no where the cases goes in splited subgoals after induction. [Mon Jul 7 13:47:32 2014] shouya: what is your misunderstanding [Mon Jul 7 13:47:45 2014] so after induction you now have two subgoals, one for each of the constructors of `le` [Mon Jul 7 13:48:36 2014] Ptival: yup i think in this way. [Mon Jul 7 13:48:47 2014] in the first case, `b` and `c` have been unified (because le_n is indexed at the same value as its parameter) [Mon Jul 7 13:49:31 2014] okay. good so far :) [Mon Jul 7 13:50:11 2014] so it should yield a hypo: b = c right? [Mon Jul 7 13:50:25 2014] okay... i get it. [Mon Jul 7 13:50:32 2014] how about the second case? [Mon Jul 7 13:50:39 2014] well, it does, but then it just substs it, so you never see that hypothesis [Mon Jul 7 13:50:52 2014] I mean, it doesn't, but morally you could think it does [Mon Jul 7 13:51:13 2014] Ptival: i see it :) [Mon Jul 7 13:51:46 2014] btw, updated paste: the goals before and after the induction are shown. http://lpaste.net/107061 [Mon Jul 7 13:51:52 2014] in fact, if you do 'remember c.' before the induction, you will see it [Mon Jul 7 13:52:18 2014] Ptival: i think i can comprehend this case, no problem :) [Mon Jul 7 13:52:35 2014] not the second one? [Mon Jul 7 13:53:27 2014] so in the second one, we consider the case where the original `b <= c` we did induction has been built using the constructor `le_S` [Mon Jul 7 13:54:08 2014] so it must be the case that `b <= c` unifies with `n <= S m`, therefore `b` unifies with `n` and `c` unifies with `S m` [Mon Jul 7 13:54:22 2014] hmm... [Mon Jul 7 13:54:48 2014] gotcha! [Mon Jul 7 13:55:09 2014] so you get in your context the parameters given to le_S: m, `n <= m` (which after unification becomes `b <= m`) [Mon Jul 7 13:55:22 2014] Ptival: thank you i think i got the idea of how it works :P [Mon Jul 7 13:55:40 2014] and your goal is still `a <= c`, but `c` has been unified with `S m`, so the goal is `a <= S m` [Mon Jul 7 13:55:48 2014] yes, yes.. [Mon Jul 7 13:56:07 2014] it just a little bit convoluted :) [Mon Jul 7 13:56:17 2014] thanks everyone :) [Mon Jul 7 13:56:50 2014] yeah it takes time to wrap your head around it [Mon Jul 7 13:57:13 2014] :P [Mon Jul 7 13:57:29 2014] especially because all the unification happens so you don't see some more intermediate states [Mon Jul 7 13:59:07 2014] Ptival: is there an option that i can switch it on and see all the detailed reductions? [Mon Jul 7 14:01:34 2014] shouya: I annotated with a proof [Mon Jul 7 14:03:09 2014] ianjneu: thanks at first, i'm trying this out step by step :) [Mon Jul 7 14:08:00 2014] ianjneu: why is there an extra 'subst' in line 45? [Mon Jul 7 14:08:58 2014] shouya: inversion introduces equalities. I used subst to distribute them. [Mon Jul 7 14:09:20 2014] this step seems unnecessary isn't it? [Mon Jul 7 14:09:44 2014] it might be. [Mon Jul 7 14:13:26 2014] ianjneu: what does 'constructor' tactic do? [Mon Jul 7 14:13:49 2014] it transforms the goal 'n <= S n' directly to 'n <= n'. [Mon Jul 7 14:14:06 2014] is it same as 'apply le_Sn' ? [Mon Jul 7 14:16:23 2014] okay, i've checked the ref doc :) [Mon Jul 7 14:20:01 2014] ianjneu: thank you for such an elaborated annotation. it's very clear. i think my confusion has been solved. thank you again :p [Mon Jul 7 14:51:42 2014] shouya: not really, because there are no reductions per se [Mon Jul 7 21:01:59 2014] there is nothing quite so satisfying as spending hours, giving up on a proof as hopeless, then after a night's sleep finding the solution within 30 minutes :) [Mon Jul 7 21:02:20 2014] turns out I used f_equal a few too many times, and robbed myself of the information I needed to solve the problem [Tue Jul 8 17:20:18 2014] is forall {A B : Set}, (A -> inhabited B) -> inhabited (A -> B) provable? [Tue Jul 8 17:21:40 2014] what if A is empty? [Tue Jul 8 17:21:46 2014] oh [Tue Jul 8 17:21:47 2014] nvm [Tue Jul 8 17:21:49 2014] wait [Tue Jul 8 17:21:56 2014] I confused myself :) [Tue Jul 8 17:23:44 2014] does "inhabited" include a witness? [Tue Jul 8 17:24:13 2014] assume it must... [Tue Jul 8 17:24:17 2014] It's from the library, Inductive inhabited (A : Type) : Prop := inhabits : A -> inhabited A [Tue Jul 8 17:30:30 2014] is obviously possible to construct an "inhabited B", but i don't know how to extract the witness given that the whole thing's in Prop [Tue Jul 8 17:31:16 2014] http://waste.io7m.com/2014/07/08/state.txt [Tue Jul 8 17:31:23 2014] is the sticking point, as i'm sure you've already discovered [Tue Jul 8 17:31:47 2014] yes. This might be relevant: http://homotopytypetheory.org/2012/01/22/univalence-versus-extraction/ [Tue Jul 8 17:34:40 2014] defining the full induction scheme looks like it might help [Tue Jul 8 17:44:06 2014] looks like it won't work [Tue Jul 8 17:45:20 2014] anyone know how to get any use out of ~Acc? [Tue Jul 8 17:46:11 2014] I came by this "inhabited" stuff trying to work with some kind of CoInductive diverges {A} (step : A -> A -> Prop) (a : A) := dstep : forall b, step a b -> diverges step b -> diverges step a [Tue Jul 8 17:46:25 2014] like getting an explicit path as a (nat -> A) function under an "exists" [Tue Jul 8 17:48:27 2014] even getting from ~Acc R a to exists b, R b a /\ ~Acc R b seems to take a decent helping of excluded middle. [Tue Jul 8 17:50:03 2014] ~Acc R a -> ~~exists b, R b a without axioms [Tue Jul 8 17:51:12 2014] well, I guess I don't have too much reason to put my diverging paths into Prop [Tue Jul 8 17:59:41 2014] seems like there's a bit of a gap between having termination, and exhibiting a diverging path [Tue Jul 8 19:20:10 2014] how can I unfold <= ? [Tue Jul 8 19:20:57 2014] maybe Locate “<=“. unfold le_nat (or whatever it says) ? [Tue Jul 8 19:21:42 2014] actually I can’t remember whether <= is defined in terms of <, or vice versa [Tue Jul 8 19:22:52 2014] so <= is actually notation for le and sometimes I want to replace notations with definitions in hypothesis/goal screen. [Tue Jul 8 19:23:35 2014] you can Unset Printing Notations. in proof general and there is a menu somewhere in coqide [Tue Jul 8 19:23:36 2014] so it's not unfolding, but I need something more general to replace notations with definitions. [Tue Jul 8 19:24:04 2014] I'm not using proof general or CoqIDE [Tue Jul 8 19:24:18 2014] Unset Printing Notations failed with: Error: Use CoqIDE display menu instead [Tue Jul 8 19:24:52 2014] so basically there's not a command like this but CoqIDE somehow manages to do it [Tue Jul 8 19:24:58 2014] or am I missing something? [Tue Jul 8 19:25:23 2014] there is a command that does this, but CoqIDE disables it [Tue Jul 8 19:25:33 2014] hm [Tue Jul 8 19:25:35 2014] what are you using to interact with Coq if not CoqIDE? [Tue Jul 8 19:25:42 2014] a vim plugin [Tue Jul 8 19:25:58 2014] coquille? [Tue Jul 8 19:26:26 2014] most of the time notations are very, very annoying to me. especially annoying when working through CPDT book because it's full of notations that convert Coq syntax into something annoying. [Tue Jul 8 19:26:29 2014] elarnon: no [Tue Jul 8 19:26:43 2014] elarnon: I don't think it has a name, I found it in vim.org and modified a little bit to make it working [Tue Jul 8 19:26:53 2014] it was something like "vim coq plugin" [Tue Jul 8 19:27:09 2014] I didn't like coquille for several reasons I don't remember now [Tue Jul 8 19:27:57 2014] well whatever, i don't know how this coq plugin interacts with coq but coq believes it is using CoqIDE somehow [Tue Jul 8 19:28:34 2014] do you know the command that is used by your plugin to start coq? [Tue Jul 8 19:29:57 2014] no [Tue Jul 8 19:30:11 2014] you should be able to get it by running "ps aux | grep coq" in a terminal on a linux (and probably mac too) machine [Tue Jul 8 19:30:19 2014] while your vim plugin is running [Tue Jul 8 19:30:31 2014] coqtop.opt -ideslave [Tue Jul 8 19:30:51 2014] interesting. there's also `grep --color=auto coq` [Tue Jul 8 19:31:50 2014] that one is the command that you used for searching, which indeed contain "coq" in the name also [Tue Jul 8 19:32:28 2014] so apparently your vim plugin is telling coq that it is running under CoqIDE (which is not the case) [Tue Jul 8 19:33:05 2014] so either the plugin provide a way to toggle this and you need to find it, or you're screwed [Tue Jul 8 19:33:51 2014] osa1: out of curiousity, why do you need to replace notations with definitions? they're transparent to coq, so you should be able to just proceed using notations. [Tue Jul 8 19:34:06 2014] jrw: he wants to see the real goal [Tue Jul 8 19:34:30 2014] right. also I want to be able to SearchAbout without running Locate every single time. [Tue Jul 8 19:34:34 2014] in order to know what are the actual definitions used [Tue Jul 8 19:34:37 2014] also, CPDT notations are horrible anyway [Tue Jul 8 19:35:05 2014] SearchPattern may help [Tue Jul 8 19:35:21 2014] but i thought SearchAbout worked with notation patterns [Tue Jul 8 19:35:59 2014] Are you looking for [Unset Printing Notations.]? [Tue Jul 8 19:36:10 2014] SearchAbout works with notation patterns [Tue Jul 8 19:36:28 2014] jgross: he is using a vim plugin that starts coq in coqide mode, so coq refuses this [Tue Jul 8 19:36:32 2014] jgross: I'm looking for making it working [Tue Jul 8 19:36:59 2014] elarnon: in any case I'd love to get ride of notations [Tue Jul 8 19:37:17 2014] osa1: you can do things like [SearchAbout (_ <= _).] [Tue Jul 8 19:37:32 2014] thanks for the tip, I didn't know that [Tue Jul 8 19:42:56 2014] osa1: if your plugin is http://www.vim.org/scripts/script.php?script_id=4388 , you should be able to do N to disable notation printing and n to enable it again [Tue Jul 8 19:46:46 2014] well on that i will go to bed, hope you find a solution that works for you osa1 [Tue Jul 8 19:46:54 2014] elarnon: yeah that plugin but I don't think that binding is working. it's still showing h' <= h as goal. [Tue Jul 8 19:46:58 2014] elarnon: yeah thanks [Tue Jul 8 19:49:34 2014] maybe I should read another book instead [Tue Jul 8 20:27:49 2014] is there a way to fold an unintentionally unfolded definition? [Tue Jul 8 20:27:57 2014] other than assertion equality and rewriting [Tue Jul 8 20:27:59 2014] asserting* [Wed Jul 9 06:00:12 2014] this is the definition of multiset equality: [Wed Jul 9 06:00:29 2014] forall a0 : fletter, multiplicity (list_contents eq eq_fletter_dec (ú :: ó :: nil)) a0 = multiplicity (list_contents eq eq_fletter_dec (ú :: ó :: ó :: nil)) a0 [Wed Jul 9 06:00:41 2014] actually, not a definition but an instance [Wed Jul 9 06:01:04 2014] anyway, does anyone see how this definition works? [Wed Jul 9 06:01:14 2014] i can conceptually grasp it perfectly [Wed Jul 9 06:01:20 2014] but i dont see how coq makes sense of this [Wed Jul 9 06:01:31 2014] when i unfold multiplicity and list_contents, heres what it says: [Wed Jul 9 06:02:20 2014] https://privatepaste.com/cb69f65c17 [Wed Jul 9 06:02:36 2014] which makes no sense to me, how does coq infer from this any number? [Wed Jul 9 06:02:47 2014] its comparing numbers right, with <= [Wed Jul 9 06:02:49 2014] ? [Wed Jul 9 06:09:03 2014] ahh thats what Bag does, nevermind :) [Wed Jul 9 08:33:15 2014] I'm trying to solve exercises listed here http://www.cs.princeton.edu/~appel/VFA/ but I'm stuck with first exercise http://lpaste.net/3569227525030674432 (see insert_sorted_preserve lemma) can anyone help me on how to approach this? [Thu Jul 10 11:03:47 2014] I'm that part of the day again, in which I'm wasting 30 minutes looking for a function in stdlib which takes less amount of time to implement from scratch. this time I'm looking for peano nat division. [Thu Jul 10 11:04:05 2014] I'm in that part* [Thu Jul 10 11:10:34 2014] osa1_: have you tried searchabout combined with your editor's "find" functionality? [Thu Jul 10 11:12:02 2014] NPeano.div is what you want I imagine. [Thu Jul 10 11:15:02 2014] ianjneu: yes. thanks. [Thu Jul 10 11:15:35 2014] Here's what I did: coqtop RET Require Import ZArith. RET SearchAbout nat. RET C-R div C-R (some number of times to search. Oh, NPeano.divide?) Print NPeano.divide. RET (hmm, nope that's a prop) C-R div C-R (searching more. Ah, NPeano.div) Print NPeano.div. (That looks right) Eval compute in (NPeano.div 60 6). (that's the right answer. Good.) [Thu Jul 10 11:15:40 2014] so it turns out that I can use types in SearchAbout like SearchAbout (nat - >nat -> nat) which is very useful. [Thu Jul 10 11:16:23 2014] This is in emacs's shell, btw [Thu Jul 10 11:16:36 2014] C-R is search reverse. [Thu Jul 10 11:17:02 2014] ianjneu: the problem with SearchAbout is that I have to include required modules for it to be useful. [Thu Jul 10 11:17:19 2014] ianjneu: but I have no idea what module to import which is part of the main problem. [Thu Jul 10 11:17:27 2014] osa1_: You can be reasonably sure that your arithmetic needs are in ZArith. [Thu Jul 10 11:17:29 2014] because if I knew the module I could look in documentation [Thu Jul 10 11:18:37 2014] But I agree with you in general, outside of numbers, coq's lib is hard to navigate. I really love Racket's documentation search. [Thu Jul 10 11:39:28 2014] is there an alternative keyword for Proof? does Proof keyword has any significance other than being useful for delimiting tactic-based definitions? [Thu Jul 10 11:53:25 2014] Proof has an optional form: Proof with tac. This allows you to denote an application of tac with just ".." [Thu Jul 10 11:54:20 2014] Er, "..." [Thu Jul 10 11:55:16 2014] Goal True. Proof with (exact I). idtac... Qed. [Thu Jul 10 11:55:29 2014] contrived, but meh. [Thu Jul 10 11:55:44 2014] i hate this feature [Thu Jul 10 11:55:58 2014] It's really stupid, I agree. [Thu Jul 10 11:56:09 2014] using a Ltac definition i a couple of keywords longer and much more clearer [Thu Jul 10 11:56:16 2014] keystrokes* [Thu Jul 10 11:56:42 2014] It counts as a "." so you can't use it in any of ti for t;[t0 | ... | tn] [Thu Jul 10 11:59:39 2014] ... should be treated as ;tac, only tac may not textually reference the current proof environment, because that's unhygienic. [Thu Jul 10 12:00:07 2014] I'm pretty sure it's an old wart, not a new feature. [Thu Jul 10 12:02:38 2014] i would love to see it deprecated [Thu Jul 10 17:36:33 2014] can anyone give me some pointers on how to prove this http://lpaste.net/138510831280193536 ? [Thu Jul 10 17:53:48 2014] osa1: you'll need an induction hypothesis that generalizes over i because the two recursive calls use different values for i [Thu Jul 10 17:54:00 2014] other than that it should go through just by using some permutation facts [Thu Jul 10 17:54:54 2014] jrw: hmm I didn't try generalizing i before induction. I'll try that, thanks for the pointer. [Fri Jul 11 06:57:28 2014] i have an insert sort function, fl_insert [Fri Jul 11 06:57:28 2014] id like to say that fl_insert f L equals either f :: L' or L' (where L' is a subset of L) [Fri Jul 11 06:57:49 2014] how do i formulate this? [Fri Jul 11 06:58:37 2014] i find it difficult to involve L' [Fri Jul 11 06:59:03 2014] (as it is not defined/instantiated at the point of beginning that case analysis) [Fri Jul 11 07:13:41 2014] nevermind, this should work i guess: forall f L, msubeq (fl_insert f L) L \/ msubeq (fl_insert f L) f :: L. [Fri Jul 11 08:05:37 2014] Uggh, damn you, `fresh' [Fri Jul 11 08:08:08 2014] http://lpaste.net/2182626071143251968 how can something like this generate name clashes? [Fri Jul 11 08:08:17 2014] I use nothing but "fresh" and H/H0 [Fri Jul 11 08:08:56 2014] http://lpaste.net/2182626071143251968 i've postedt the error too [Fri Jul 11 08:15:20 2014] Ugh, I replaced all "with" with "in" [Fri Jul 11 08:15:22 2014] and it's working [Fri Jul 11 08:15:27 2014] weird :SS [Fri Jul 11 08:16:40 2014] Anyway, finally finished proving deduction lemma for propositional calculus. 261 lines [Fri Jul 11 10:52:02 2014] I tried to encode some algebraic structures/properties in Coq https://gist.github.com/osa1/fb600a76dd7123d8b37a am I doing this right? [Fri Jul 11 10:53:00 2014] osa1: Usually I've seen people using 1) Records 2) Typeclasses for defining algebraic gadgets [Fri Jul 11 10:54:04 2014] hm, I don't know neither of those. [Fri Jul 11 10:54:12 2014] notdan: other than that it looks OK? [Fri Jul 11 10:54:38 2014] I mean I know records and typeclasses from Haskell but I never used them in Coq [Fri Jul 11 10:56:03 2014] osa1: they're not much different, and they are much nicer to use for non-inductive collections like algebraic structures. [Fri Jul 11 10:56:31 2014] http://arxiv.org/pdf/1102.1323v1.pdf <- a paper about implementing mathematics in Coq with typeclasses [Fri Jul 11 10:56:36 2014] Record monad := mk_monad {tau : ... ; mu : ...}. [Fri Jul 11 10:57:07 2014] thanks for the paper [Fri Jul 11 10:57:34 2014] I think there are some downsides to using inductive.. [Fri Jul 11 10:58:07 2014] like what? [Fri Jul 11 10:58:15 2014] well I guess with typeclasses you can have automatic instnaces, and you dont have to carry proofs around [Fri Jul 11 11:00:33 2014] also the upside of using typeclasses is that you can use setoids and setoid rewriting, which is just a special type of equality [Fri Jul 11 11:00:43 2014] yeah, things are a bit more explicit when typeclasses are not used. on the other hand this way I can have multiple different implementations of same proof. [Fri Jul 11 11:00:44 2014] e.g. you might want to have quotient groups and stuff [Fri Jul 11 11:01:14 2014] setoid = Type + equality function with some laws? [Fri Jul 11 11:01:18 2014] I think you can have multiple instances for a typeclass as well, I don't remember precisel [Fri Jul 11 11:01:40 2014] osa1: yeah, basically a type with an equivalence relation [Fri Jul 11 11:01:54 2014] and setoid morphism is a function from one type to another that preserves the equality relations [Fri Jul 11 11:02:24 2014] setoids are unfortunately cumbersome. [Fri Jul 11 11:02:42 2014] yep [Fri Jul 11 11:04:51 2014] is there a convention to when to use capitalized variable names and when to use lowercase? [Fri Jul 11 11:08:24 2014] osa1: like in Haskell. Types and Type Constructors versus constructors and functions. [Fri Jul 11 11:09:23 2014] osa1: Or When You Need To Get Your Point Across [Fri Jul 11 11:09:39 2014] proof by EMPHATIC DECLARATION [Fri Jul 11 11:09:55 2014] just be consistent. [Fri Jul 11 11:10:07 2014] lol [Fri Jul 11 11:10:18 2014] rmk0: I USE ALL CAPS SO YOU TOTALLY MISS THIS NEXT Admitted. [Fri Jul 11 11:10:28 2014] \o/ [Fri Jul 11 11:10:46 2014] actually I don't. [Fri Jul 11 11:10:46 2014] http://staffhome.ecm.uwa.edu.au/~00043886/humour/invalid.proofs.html [Fri Jul 11 11:11:26 2014] my favourite is Proof by Exercise. [Fri Jul 11 11:11:33 2014] I'm a kabab case person from all my years in Racket. Too bad most other languages think I'm trying to subtract proof from my when I write my-proof. [Fri Jul 11 12:33:55 2014] anyone here in Viena atm by any chance? [Fri Jul 11 12:33:59 2014] *from here [Fri Jul 11 12:37:40 2014] notdan: you might find fabianm in #prl sometimes. He's from Austria, but I'm not sure if Vienna. [Fri Jul 11 12:38:35 2014] Oh, don't know anybody from the nuprl community. I was thiking more of people participating in the VSL [Fri Jul 11 12:38:36 2014] that's Fabian Muehlboehck at Cornell. [Fri Jul 11 12:39:00 2014] previously a masters in my lab. [Fri Jul 11 12:39:25 2014] prl isn't nuprl, but northeastern university's Programming Research Lab. [Fri Jul 11 12:39:49 2014] Ah [Fri Jul 11 12:40:22 2014] I think Billy Bowman and Phillip Mates are there. [Fri Jul 11 12:40:39 2014] pmatey and bluephoenix47 in #prl. [Fri Jul 11 12:41:35 2014] They're at some logic summer school... [Fri Jul 11 12:41:45 2014] maybe it's a different one in Paris. [Fri Jul 11 13:22:22 2014] Hello. [Fri Jul 11 13:23:00 2014] Can I prove in Coq that "forall f : X -> X, fun x => f x = f" ? [Fri Jul 11 13:24:27 2014] no [Fri Jul 11 13:24:55 2014] that's functional extensionality and it has to be imported as an axiom if you need it [Fri Jul 11 13:25:30 2014] see http://coq.inria.fr/library/Coq.Logic.FunctionalExtensionality.html [Fri Jul 11 13:26:00 2014] elarnon, ok, I thought the same, but somehow fell in doubts. [Fri Jul 11 13:26:20 2014] oh wait [Fri Jul 11 13:26:51 2014] it's not functional extensionality directly but i thought it was equivalent [Fri Jul 11 13:27:01 2014] i'm not so sure anymore [Fri Jul 11 13:27:33 2014] elarnon, I just thought that we can rewrite somehow f into "fun x => f x" (dunno) [Fri Jul 11 13:28:00 2014] no that's false iirc [Fri Jul 11 13:28:06 2014] well not false [Fri Jul 11 13:28:15 2014] no it should be equivalent to functext [Fri Jul 11 13:28:22 2014] elarnon, oh, I understood that actually I needn't it! [Fri Jul 11 13:28:31 2014] elarnon, yep it seems to be equivalent to FE. [Fri Jul 11 13:28:32 2014] Yeah, that’s η-reduction, which is equivalent to extensionality [Fri Jul 11 13:28:40 2014] elarnon, but I can prove equality of arguments. [Fri Jul 11 13:31:29 2014] it is trivially implied by extensionality but i'm having doubts about the converse [Fri Jul 11 13:33:43 2014] coq doc only says it follows from functext [Fri Jul 11 13:33:53 2014] alkabetz: eta is not equivalent to funext. [Fri Jul 11 13:35:21 2014] and it seems you never get an x to apply eta expansion when trying to prove functext [Fri Jul 11 13:35:47 2014] Rc43: in Coq8.4 that goal is provable by auot. [Fri Jul 11 13:35:49 2014] auto* [Fri Jul 11 13:36:27 2014] Goal forall (X : Type) (f : X -> X), (fun x : X => f x) = f. auto. Qed. [Fri Jul 11 13:37:36 2014] oooh right they added eta to Coq, forgot about that one [Fri Jul 11 13:38:47 2014] I'm heading home for lunch. [Fri Jul 11 13:56:35 2014] Hmm, can't understand is it true that "well_founded R -> well_founded (symmetric R)", where "symmetric R (xl,xr) (yl,yr) := R (xr,xl) (yl,yr)". [Fri Jul 11 18:46:22 2014] does anyone know some data structures with group properties? we have monoids but I can't come up with a data structure with inverse elements. does that even make sense? [Fri Jul 11 18:48:06 2014] diffs? :) [Fri Jul 11 18:51:02 2014] very interesting. I think you're right. [Fri Jul 11 18:52:32 2014] but we can't always merge two diffs [Fri Jul 11 18:53:02 2014] so it doesn't have a semigroup operation. [Fri Jul 11 18:57:01 2014] we can't define Diff -> Diff -> Diff, we can only define Diff -> Diff -> option Diff or some other partial function. [Fri Jul 11 18:57:05 2014] any other ideas? :) [Fri Jul 11 18:59:33 2014] so if I work with setoids can I use rewrite when I have my equivalence relation between two values? [Sat Jul 12 00:55:55 2014] Hi everybody! A soft question: if one wants to encode mainstream math in Coq (classical, without an emphasis on program extraction), is there a "recommended" existential quantifier? (ex / sig / sigT) [Sat Jul 12 00:59:16 2014] I mean the one that implies less headaches :) [Sat Jul 12 01:41:59 2014] the-manless-man: I don't have enough experience with it to say for sure, but I usually just avoid Prop. [Sat Jul 12 01:42:15 2014] the-manless-man: There are reasons why you might want the impredicativity that Prop offers [Sat Jul 12 01:42:34 2014] (even if you don't care about Prop erasure) [Sat Jul 12 01:43:19 2014] But for the most part, well, at least I find it more convenient to be able to take apart proofs in order to define functions and such. [Sat Jul 12 02:16:30 2014] Thanks Cale [Sat Jul 12 02:17:28 2014] Are you thinking on a specific reason one might want to work in Prop, other than erasure? [Sat Jul 12 02:19:14 2014] Oh, ok, you were pointing to impredicativity [Sat Jul 12 10:37:41 2014] osa1_: you can use rewrite if you also have a typeclass instance of Proper for the function in question wrt your relation. [Sat Jul 12 17:29:18 2014] I'm trying to implement a very simple dependently typed function, basically I want to reverse a list from given index, provided that index < length list and I also want to return a proof that returned list has same length as argument list. I'm trying this: http://lpaste.net/1470943702363930624 can anyone give me some pointers? [Sat Jul 12 17:31:51 2014] I was disconnected if anyone wrote anything to me [Sat Jul 12 17:34:41 2014] I updated the link [Sat Jul 12 17:36:08 2014] doh "Anomaly: Uncaught exception Vernac.End_of_input. Please report." [Sat Jul 12 17:40:02 2014] why I can't do inversion on p : 0 > 0 ? [Sat Jul 12 17:41:47 2014] can anyone offer advice on this theorem from SF: [Sat Jul 12 17:41:48 2014] Theorem rev_pal : forall X l, l = rev l -> pal X l. [Sat Jul 12 17:42:01 2014] it would seem to do this that I need to perform induction on l from "both directions at once" [Sat Jul 12 17:42:10 2014] and yet, that's not something which the text has introduced [Sat Jul 12 17:42:23 2014] every set of solutions on the web has Admitted for this proof :) [Sat Jul 12 17:43:36 2014] which section of SF is it in? [Sat Jul 12 17:45:01 2014] hmm, no, I Admitted. that one too [Sat Jul 12 17:45:40 2014] :) [Sat Jul 12 17:45:49 2014] i've spent enough time on it now that I'm ready for hints [Sat Jul 12 17:45:51 2014] It's a pretty tough one [Sat Jul 12 17:45:58 2014] ezyang_: oh! [Sat Jul 12 17:46:02 2014] ezyang_: I had a separate question for you [Sat Jul 12 17:46:05 2014] I think my advisor spent a day working on it [Sat Jul 12 17:46:10 2014] * has not solve dit [Sat Jul 12 17:46:28 2014] in LogicT, why is the type (a -> m r -> m r) -> m r -> m r, instead of just (a -> r -> m r) -> r -> m r? [Sat Jul 12 17:46:59 2014] Well, the former type seems more flexible. Maybe it could be supported cost free? [Sat Jul 12 17:47:14 2014] can you give into more detail there? [Sat Jul 12 17:47:25 2014] this concerns a design point in one of my own libraries [Sat Jul 12 17:47:39 2014] given Monad m => (a -> m r -> m r) -> m r -> m r, I can give you the latter [Sat Jul 12 17:49:30 2014] johnw: I got reasonably far by proving it true for even, and for odd, and then proving that the length is always odd or even [Sat Jul 12 17:49:59 2014] but the whole thing was a mess, and I'm not going to let you see it :) [Sat Jul 12 17:50:46 2014] ezyang_: https://gist.github.com/c6e7a22a8875a480d21d [Sat Jul 12 17:51:08 2014] aren't the two forms isomorphic? [Sat Jul 12 17:51:20 2014] ijp: :( [Sat Jul 12 17:51:42 2014] It's true [Sat Jul 12 17:51:56 2014] the best ideas I've seen on the Web so far involve crafting a custom induction principle for lists, where you case analyze on both ends at once; and yet, SF have never talked about this [Sat Jul 12 17:52:09 2014] ezyang_: so.... [Sat Jul 12 17:52:26 2014] ezyang_: why does LogicT not choose the simpler form? [Sat Jul 12 17:52:26 2014] johnw: You're guess is as good as mine :) Take a look at the impl, maybe [Sat Jul 12 17:52:30 2014] ok [Sat Jul 12 17:52:36 2014] i've been pouring over that, and Oleg's paper [Sat Jul 12 17:52:46 2014] re custom induction principle, you know an induction principle is just another lemma, right? [Sat Jul 12 17:52:53 2014] can anyone help me? why I can't use inversion on p : S (length t) > 0 ? [Sat Jul 12 17:52:53 2014] Tekmo thought that with the additional 'm', you couldn't have a lawful MonadTrans instance for LogicB [Sat Jul 12 17:52:58 2014] but I proved in Coq that that's not the case [Sat Jul 12 17:52:58 2014] ops sry [Sat Jul 12 17:53:01 2014] wrong expression [Sat Jul 12 17:53:08 2014] p : 0 > 0 [Sat Jul 12 17:53:10 2014] ezyang_: true [Sat Jul 12 17:53:20 2014] ezyang_: very true..... [Sat Jul 12 17:53:50 2014] even still, that seems beyond what the reader is expected to know that point in SF, which makes me feel like I'm missing something more obvious [Sat Jul 12 17:54:08 2014] johnw: they're covered in one of the optional parts, no? [Sat Jul 12 17:54:15 2014] I forget which one [Sat Jul 12 17:55:15 2014] well, https://github.com/vladoovtcharov/Software-Foundations-Solutions/blob/master/Prop.v does have a simpler answer [Sat Jul 12 17:55:18 2014] he uses: [Sat Jul 12 17:55:22 2014] Inductive pal' {X: Type} : list X -> Prop := [Sat Jul 12 17:55:23 2014] | palc' : forall l, l = rev l -> pal' l. [Sat Jul 12 17:55:39 2014] even though SF itself says you wouldn't want to do that [Sat Jul 12 17:55:57 2014] MoreInd.html I think [Sat Jul 12 17:56:18 2014] although that's 3 chapters further into the book from Prop.v! [Sat Jul 12 17:59:25 2014] ezyang_: did he ever finish it? [Sat Jul 12 18:04:25 2014] maybe I should do inversion but how can I eliminate the goal from if I have `p : S idx' < 0` ? [Sat Jul 12 18:04:34 2014] shouldn't* [Sat Jul 12 18:08:50 2014] interesting, omega solved it. [Sat Jul 12 18:12:08 2014] "< osa1> why I can't do inversion on p : 0 > 0 ?" >> it actually works for me :o [Sat Jul 12 18:15:21 2014] I'm very confused. I can't do anything with refine but I can't implement recursion as I want without using refine... so I'm stuck [Sat Jul 12 18:16:08 2014] there are always lots of information lost while filling missing parts when refine is used. [Sat Jul 12 18:16:46 2014] Cypi: "Error: Inversion would require case analysis on sort Type which is not allowed for inductive definition le." [Sat Jul 12 18:17:02 2014] I'd love to see some refine examples. [Sat Jul 12 18:17:49 2014] Certified Programming with Dependent Types uses a lot refine, in some chapters [Sat Jul 12 18:18:20 2014] I'm trying to avoid that book if possible :P [Sat Jul 12 18:18:27 2014] Oh? Ok [Sat Jul 12 18:19:34 2014] About your error, ok, I have the same if I'm trying to prove "0 < 0 -> nat" for example. (Because my goal is not in Prop, I guess) [Sat Jul 12 18:20:20 2014] But doing "exfalso" first works just fine. [Sat Jul 12 18:24:19 2014] interesting. what's wrong with doing inversion when goal is not prop? [Sat Jul 12 18:40:45 2014] johnw: how would you prove your theorem by hand? [Sat Jul 12 18:42:19 2014] osa1: Coq prevents you from doing case analysis (inversion, induction, destruct, etc.) on Prop when your goal is not in Prop for code extraction reasons [Sat Jul 12 18:42:50 2014] things in Prop are erased when you extract code, so your real values (things in Set and Type) must never look at it [Sat Jul 12 18:43:37 2014] otherwise your code couldn't be executed [Sat Jul 12 18:45:23 2014] using the [exfalso] tactic allows you to say "I am looking at these things in Prop to prove this goal in Set/Type, but my goal is actually a contradiction so when running code I will never get there and it is safe" [Sat Jul 12 18:45:58 2014] elarnon: that makes sense. thanks. [Sat Jul 12 18:47:26 2014] johnw: (my hint would be that you probably wouldn't do an induction on the list but rather on some simple derived property) [Sat Jul 12 19:06:21 2014] elarnon: thanks! [Sun Jul 13 05:00:08 2014] ltac can be pretty fun [Sun Jul 13 05:00:17 2014] most of my set theory proofs now reduce to: [Sun Jul 13 05:00:22 2014] Theorem inter_assoc : forall A B C, A ∩ (B ∩ C) = (A ∩ B) ∩ C. [Sun Jul 13 05:00:23 2014] Proof. intros. extension; obvious. Qed. [Sun Jul 13 05:00:44 2014] that's how most of the simple ones look now, whereas before they were many lines each [Sun Jul 13 09:40:49 2014] question http://lpaste.net/107424 [Sun Jul 13 09:45:38 2014] You need well-founded recursion. See http://adam.chlipala.net/cpdt/html/GeneralRec.html. [Sun Jul 13 09:49:24 2014] oh no [Sun Jul 13 09:56:05 2014] Coq’s termination checker is extremely simple. It expects to find you recursing on a /syntactic/ subterm of one of your arguments. You’re not, so you need to prove to Coq that your recursion is well-founded. [Sun Jul 13 10:07:37 2014] I know. I just find type of Fix hard to understand. I think the idea of well-founded relation is very simple(not in Coq context, but in general) but somehow I can't use that to define recursive functions. [Sun Jul 13 10:15:12 2014] I'm wondering if there are languages with more powerful termination checkers as default. [Sun Jul 13 10:19:58 2014] do I need to use noBadChains as described in CPDT? [Sun Jul 13 19:33:40 2014] I solved my problem with map_rest function by using a "timeout" parameter. [Mon Jul 14 05:20:36 2014] ezyang_: ping [Mon Jul 14 05:21:51 2014] pong [Mon Jul 14 05:22:05 2014] ok, so using Coq I attempted to prove the isomorphism between those two forms of LogicT [Mon Jul 14 05:22:21 2014] which led to the discovery that I need an additional law for it to hold: [Mon Jul 14 05:22:23 2014] forall A B (f : M A -> M B), mu ∘ fmap f = f ∘ mu [Mon Jul 14 05:22:50 2014] which I think means that the two type are adjoint with respect to this law, not isomorphic [Mon Jul 14 05:23:19 2014] here's my work: https://gist.github.com/543bdc9ac4d39ad608db [Mon Jul 14 05:23:26 2014] sorry, https://gist.github.com/543bdc9ac4d39ad608bd [Mon Jul 14 05:23:27 2014] That looks like a parametricity property [Mon Jul 14 05:23:51 2014] hmm [Mon Jul 14 05:24:07 2014] Jones & Duponcheel give this law in their formulation of agreeable monadic compositions [Mon Jul 14 05:24:17 2014] or rather, they say that when you assume it, certain properties can hold [Mon Jul 14 05:24:32 2014] Oh, OK, nevermind then [Mon Jul 14 05:24:59 2014] so I think it can be said that for any monads M and N which form a monad composite, then LogicT and LogicT' (using r -> m r) are isomorphic [Mon Jul 14 05:25:23 2014] no, wait, the N is missing in some cases [Mon Jul 14 05:25:34 2014] I wonder what this law is all about then [Mon Jul 14 05:32:21 2014] we have the law: join . fmap (fmap f) = fmap f . join [Mon Jul 14 05:32:28 2014] but apparently we can't specialize that down to just f [Mon Jul 14 10:40:25 2014] yay, I am at ITP [Mon Jul 14 10:41:43 2014] cool! [Mon Jul 14 10:42:59 2014] Currently Dimitry Traitel is talking about co-datatypes in Isabelle; don't understand much tbqh [Mon Jul 14 10:51:10 2014] hello. is there some "deque" defined in coq? [Mon Jul 14 10:51:25 2014] (deque = fifo) [Mon Jul 14 10:53:24 2014] not that I know of. [Mon Jul 14 10:54:57 2014] schoppenhauer: you could use Okasaki's pure functional deque, but then you'd have to do all the correctness proofs etc. [Mon Jul 14 10:56:15 2014] It uses lazy streams, so it could get awkward. [Mon Jul 14 10:56:59 2014] here's an implementation in Typed Racket you could start from https://github.com/takikawa/tr-pfds/blob/v6.0/pfds/deque/real-time.rkt [Mon Jul 14 10:58:16 2014] ianjneu_: well, the naive implementation using two lists is amortized constant, so I would probably use that one [Mon Jul 14 10:59:44 2014] sure. [Mon Jul 14 11:01:38 2014] but maybe there is already something with actual lemmata and such [Mon Jul 14 11:05:40 2014] I don't see anything obvious is user contribs [Mon Jul 14 11:06:01 2014] ok [Mon Jul 14 11:08:57 2014] ACL2 has a verified super-fast deque implementation, but that doesn't help too much. It uses single-threaded objects to do "purely functional mutation" [Mon Jul 14 11:09:15 2014] Not sure if Coq has a fast runST :P [Mon Jul 14 11:30:43 2014] jason gross is about to speak, and like 20 more people entered the room [Mon Jul 14 12:46:53 2014] In CPDT (the book by Chlipala), there is an exercise about dependent types where you define a type of lists [plist : nat -> Set] such that any [plist n] contains at least [n] elements that satisfy some predicate [P]. You then have to define [plistOut : forall n, plist n -> list A] (A is the set in which the elements of the lists are), which is easy. But then you have to define [plistIn], which [Mon Jul 14 12:46:58 2014] would be "list A -> plist n". Except that I don't know exactly which return type there should be. The return type should express the fact that [n] has been chosen to be the best possible [n]. [Mon Jul 14 12:47:12 2014] If I'm not very clear: http://lpaste.net/107476 . I wonder what type I should put instead of "(* ??? *)" [Mon Jul 14 12:49:00 2014] well, can't you take n to be (length l)? [Mon Jul 14 12:49:28 2014] or (length (filter P l)) rather [Mon Jul 14 12:50:41 2014] Ah. I didn't think of that, I guess so [Mon Jul 14 12:51:14 2014] also, are you sure that your plistOut definition is correct? [Mon Jul 14 12:51:25 2014] it doesn't work for me [Mon Jul 14 12:51:54 2014] What do you mean "it doesn't work"? I didn't test it (the next step is to prove the correctness of both functions ^^' ) [Mon Jul 14 12:52:31 2014] It didn't compile for me; I had to replace the call to (plistOut t) with (plistOut n0 t) [Mon Jul 14 12:52:43 2014] Oh, right [Mon Jul 14 12:52:46 2014] Chlipala uses "Set Implicit Arguments. [Mon Jul 14 12:52:49 2014] " everywhere [Mon Jul 14 12:52:58 2014] (which I don't like very much :/ ) [Mon Jul 14 12:53:21 2014] ah, fair enough [Mon Jul 14 12:53:42 2014] I didn't think 'n' was implicit in that definition. Probably should finally look up the exact specification [Mon Jul 14 12:54:32 2014] The second argument to [plistOut] is a [plist n], so you can deduce [n] from the type of the second argument, which makes it implicit [Mon Jul 14 12:55:02 2014] thx [Mon Jul 14 12:55:20 2014] It does weird things sometimes, for example [x] is implicit in the constructor [PCons] :/ [Mon Jul 14 12:57:03 2014] What chapter is plist from? [Mon Jul 14 12:58:02 2014] It's in this pdf: http://adam.chlipala.net/cpdt/ex/exercises.pdf section "0.5 From MoreDep". [Mon Jul 14 12:59:33 2014] oh, cool [Mon Jul 14 12:59:40 2014] I didn't know there were exercises [Mon Jul 14 13:01:25 2014] http://lpaste.net/107477 [Mon Jul 14 13:01:42 2014] Cypi: not a proof term, but there you go. [Mon Jul 14 13:10:49 2014] Ah, I was trying to write directly a proof term (apparently this is what was intended for this exercise) :p [Mon Jul 14 13:11:32 2014] Defining things with tactics was kind of unthinkable for me some time ago, but now I find it to be easier, indeed [Mon Jul 14 13:12:13 2014] ya, good luck writing that proof term. [Mon Jul 14 13:23:49 2014] If I have a decision procedure P_dec : forall x : A, {P x} + {~ P x}, and a statement H: if P_dec x then true else false = true, how can I get p:P x? [Mon Jul 14 13:25:23 2014] It seems strange that I can write if P_dec x ... anyway :| it's not a bool [Mon Jul 14 13:25:58 2014] Oh, if works on all booleans [Mon Jul 14 13:27:18 2014] notdan: if has a weird-ass semantics that depends on the order you write your inductive's type constructors. [Mon Jul 14 13:32:51 2014] btw, I think you don't need a complicated match there: http://lpaste.net/107477 [Mon Jul 14 13:33:17 2014] granted, I did define Pbool through P_dec, the other way around [Mon Jul 14 13:33:21 2014] (relatively to what you did) [Mon Jul 14 13:53:46 2014] notdan : you can write [if e then _ else _] whenever [e] is in an inductive type with exactly two constructors. [Mon Jul 14 13:54:10 2014] It doesn't have to be booleans or anything related to booleans (it works with lists for example) [Mon Jul 14 14:01:00 2014] oh [Mon Jul 14 17:20:09 2014] So, about [plist] again, I wrote the proof term myself (helped by Coq still), but there is one single point I do not get [Mon Jul 14 17:20:12 2014] http://lpaste.net/107491 [Mon Jul 14 17:20:26 2014] The definition of plistIn is fine, but the definition of plistIn' is not [Mon Jul 14 17:20:49 2014] The only difference is the replacement of [if s then true else false] by [s]. How come this is important? [Mon Jul 14 17:49:29 2014] I also added a lemma that I don't seem to be able to prove :/ [Mon Jul 14 17:49:37 2014] (Yes, I'm having trouble with dependent types :p ) [Mon Jul 14 18:00:57 2014] where are you getting filter from? [Mon Jul 14 18:01:37 2014] Standard library [Mon Jul 14 18:01:44 2014] what Require line? [Mon Jul 14 18:01:48 2014] I cannot load your file as it was patsed [Mon Jul 14 18:01:54 2014] Maybe you need "Require Import Arith List." [Mon Jul 14 18:01:59 2014] (probably only List) [Mon Jul 14 18:02:03 2014] Sorry, it's a messy file :x [Mon Jul 14 18:02:06 2014] ah, that was it [Mon Jul 14 18:02:18 2014] I added it [Mon Jul 14 18:05:56 2014] well, it would seem you need to case analyze 's' at two levels deep to get to the type you need [Mon Jul 14 18:06:09 2014] which is what 'if' is doing [Mon Jul 14 18:07:00 2014] Hmm. The type of [s] is [{P x} + {~ P x}] [Mon Jul 14 18:07:32 2014] So for me, what [if s then true else false] does is just replacing a sumbool by the correspondig boolean (which should contain even less information :o ) [Mon Jul 14 18:07:43 2014] i think that proving the lemma you'll need some other things [Mon Jul 14 18:07:54 2014] like a way to move the 'x' inside x :: plistOut (plistIn t) [Mon Jul 14 18:08:28 2014] if I had x :: plistOut (plistIn t) = plistOut (plistIn (x :: t)), the proof is trivial [Mon Jul 14 18:09:32 2014] Well, yes, that's exactly the second case of the induction :p [Mon Jul 14 18:09:39 2014] (At least I think) [Mon Jul 14 18:09:56 2014] What surprised me is the error I got [Mon Jul 14 18:10:05 2014] how do I rewrite only the second occurence? [Mon Jul 14 18:10:09 2014] rewrite <- IHt at 2 never works for me [Mon Jul 14 18:10:09 2014] "Error: Abstracting over the term "s" leads to a term [...] which is ill-type" [Mon Jul 14 18:10:21 2014] That's the way, but I tried it here and it didn't work [Mon Jul 14 18:11:42 2014] https://gist.github.com/6eeb25e529131b791e9c [Mon Jul 14 18:12:18 2014] that's really just a trivial rewrite of the goal [Mon Jul 14 18:12:47 2014] Yes, I agree. But this subgoal is as difficult as the original proof [Mon Jul 14 18:12:51 2014] exactly [Mon Jul 14 18:13:54 2014] I feel like there's not enough information here to proceed [Mon Jul 14 18:14:11 2014] I really have no laws governing what NCons and PCons mean [Mon Jul 14 18:14:29 2014] the definition of plistIn is pretty complex [Mon Jul 14 18:14:53 2014] try to break it down into the simplest expression of the property that you can [Mon Jul 14 18:15:07 2014] Well, intuitively, here, you just have to make a case-analysis on [P_dec x], and it's really easy [Mon Jul 14 18:15:17 2014] But Coq won't let me for some reason that I have a hard time to understand :p [Mon Jul 14 18:15:32 2014] oh, it lets me [Mon Jul 14 18:15:35 2014] in the place of the admit [Mon Jul 14 18:15:44 2014] it gives me: p : P x [Mon Jul 14 18:15:49 2014] and then asks me to prove the same goal [Mon Jul 14 18:16:08 2014] Well, try with [case_eq (P_dec x.] instead, you'll get more information [Mon Jul 14 18:16:13 2014] but even then, it doesn't work [Mon Jul 14 18:16:24 2014] ah [Mon Jul 14 18:16:29 2014] that adds H : P_dec x = left p [Mon Jul 14 18:16:34 2014] the next logical step would be to [simpl.], and then rewrite to replace [P_dec x] with [{P x}] [Mon Jul 14 18:16:42 2014] Or with [left p] I mean [Mon Jul 14 18:16:47 2014] by using this hypothesis H [Mon Jul 14 18:17:16 2014] but then you get, again, this cryptic error [Mon Jul 14 18:17:28 2014] "Error: Abstracting over the term "P_dec x" leads to a term [...] which is ill-typed" [Mon Jul 14 18:17:30 2014] yeah [Mon Jul 14 18:17:35 2014] i've never used 'as' before, so I can't really help [Mon Jul 14 18:17:53 2014] The difficulties of dependently-typed terms :( [Mon Jul 14 18:18:51 2014] subst says: Error: Cannot find any non-recursive equality over t. [Mon Jul 14 18:19:02 2014] perhaps that's more illuminating [Mon Jul 14 18:19:28 2014] It's not the same error. In this case, it's just that the only inquality over t is recursive, so [subst] won't use it [Mon Jul 14 18:19:36 2014] equality* [Mon Jul 14 18:20:34 2014] ah [Mon Jul 14 18:23:28 2014] Oh well, I have to go for now, dropping the link again in case someone can help in some way :D http://lpaste.net/107491 [Mon Jul 14 18:23:36 2014] Thanks in any case johnw [Mon Jul 14 18:24:55 2014] sure, let me know what you find [Tue Jul 15 11:27:33 2014] johnw: just in case you're interested, someone helped me for the problem I had yesterday [Tue Jul 15 11:27:38 2014] http://lpaste.net/107491 for a completed proof [Tue Jul 15 11:27:54 2014] (And yes, this is kind of ugly, but apparenty this is usual when dealing with dependently-typed matches...) [Tue Jul 15 11:28:41 2014] ya, I wouldn't have come up with that. [Tue Jul 15 15:22:45 2014] huh [Wed Jul 16 19:06:32 2014] can I declare a `{...} constraint as a Variable in a section? [Wed Jul 16 19:58:13 2014] ah, "Context" [Wed Jul 16 20:07:39 2014] can I name my obligations, so that they aren't named Tuple_Assoc_obligation_2? [Wed Jul 16 20:07:48 2014] i'd rather that be called Tuple_Assoc_iso_from [Thu Jul 17 10:19:01 2014] hello [Thu Jul 17 10:19:33 2014] is it possible to display "forall" and such keywords as unicode characters in coqide? [Thu Jul 17 10:19:50 2014] like \forall [Thu Jul 17 10:20:06 2014] ∀ [Thu Jul 17 10:22:57 2014] too bad coq general haven't benn updated for almost year and can't even be compiled with latest emacs [Thu Jul 17 10:23:05 2014] proof general* [Thu Jul 17 10:36:30 2014] Ainieco: Coq Proof General works fine for me on Emasc 24.3.1, and M-x proof-unicode-tokens-toggle works fine for me as well. [Thu Jul 17 10:51:34 2014] alkabetz: same emacs version, unicode tokens break arrows e.g when i'm writing "->" it converts it to "→" literally, as one character which coq doesn't understand [Thu Jul 17 10:52:24 2014] "->" written before toggling unicode tokens remain to be two char token which coq perfectly understands but newly written "->" after toggling unicode are broken [Thu Jul 17 10:52:38 2014] Oh, huh, look at that. [Thu Jul 17 10:53:18 2014] Hang on, let me look at this for a second … [Thu Jul 17 11:05:06 2014] Well, I’m not sure why it does this, but disabling the Unicode tokens input mode (C-\) fixes the issue. [Thu Jul 17 11:05:44 2014] (That is, I’m not sure why the Unicode tokens mode enables the input method. It’s pretty obvious why disabling the input method fixes the glitch.) [Thu Jul 17 11:06:12 2014] we "fixed the glitch" [Thu Jul 17 11:15:45 2014] alkabetz: thanks! [Thu Jul 17 11:18:39 2014] You’re welcome. Enjoy your Unicode ☺ [Thu Jul 17 18:26:02 2014] I'm trying to use the {order} annotation for Program Fixpoint. As an exercise, I'm trying to reproduce standard syntactic-subterm restriction that Coq imposes on Fixpoint functions. Is there any standard trick to construct a well-founded relation along the lines of Coq's syntactic-subterm restriction? Something similar to structural induction? [Thu Jul 17 20:45:40 2014] in my Ltac script, if I want to match against anything in the goal of the form "match ?X with ... end", how do I specify the "..."? [Thu Jul 17 21:00:57 2014] also, can I get the ?X to only match a specific form? [Thu Jul 17 21:01:04 2014] right now it's matching anything there [Thu Jul 17 21:03:48 2014] perhaps do a later match on X and fail if it's not what you wanted? [Thu Jul 17 21:04:23 2014] e.g., match type of X with ..., or match X with ... [Thu Jul 17 21:09:55 2014] ah, I se [Thu Jul 17 21:10:03 2014] how do I say match X is bare-naked identifier? [Thu Jul 17 21:10:11 2014] because that's all I care about [Thu Jul 17 21:10:24 2014] i just want to match on ?X when ?X has the form 'x' or 'u' or 'a' [Thu Jul 17 21:10:32 2014] letter unknown [Thu Jul 17 21:10:43 2014] right now I have this nastiness: https://gist.github.com/00b1e88713a9996706d4 [Thu Jul 17 21:10:52 2014] which works, but is basically just working around the problem statement above [Thu Jul 17 21:12:02 2014] also, can I get Program Instance to try one of my tactics on each obligation for me? [Thu Jul 17 21:13:26 2014] ooh, Obligation Tactic [Thu Jul 17 21:14:46 2014] perhaps you could use context patterns to avoid describing all of the ways that match could appear in your goal? [Thu Jul 17 21:15:22 2014] something like.. match goal with | [ |- context[match ?X with _] ] => ... end. [Thu Jul 17 21:15:48 2014] but that doesn't help the "match ?X only if it's an identifier" [Thu Jul 17 21:16:06 2014] when I do a full context[match ?X with _], it matches sub-matches, for example [Thu Jul 17 21:16:21 2014] of the form match match match x with ... end with ... end with ... end [Thu Jul 17 21:16:26 2014] i only want to match the innermost match [Thu Jul 17 21:17:04 2014] in the "..." of the tactic i suggested, perhaps you could match X and fail if it's another match? [Thu Jul 17 21:17:27 2014] ah, I see [Thu Jul 17 21:17:28 2014] that I could do [Thu Jul 17 21:17:51 2014] how do I match on any number of sub-patterns? [Thu Jul 17 21:17:56 2014] your context[match ?X with _] doesn't parse [Thu Jul 17 21:33:03 2014] instead of "fail", can I have it move on to trying the next match expression? [Thu Jul 17 21:33:25 2014] I have this: https://gist.github.com/978da72c04ee2cd92a2f [Thu Jul 17 21:33:32 2014] if I could say "skip" instead of "fail", for example, it would work [Thu Jul 17 21:33:46 2014] once I determine that the "match" doesn't match what I'm looking for, I want to move on to try the next one [Thu Jul 17 21:36:01 2014] ah, I need to make this recursive [Thu Jul 17 21:45:21 2014] uucico: this did it: https://gist.github.com/cd6817136ecae21db740 [Thu Jul 17 21:45:24 2014] thanks for your help [Fri Jul 18 04:17:21 2014] johnw: another approach for your problem would be "match goal with [ x: _ |- context[match ?y with _ => _] ] => unify x y; ... end" [Fri Jul 18 04:17:52 2014] hmmm [Fri Jul 18 04:17:57 2014] can you explain further? [Fri Jul 18 04:18:57 2014] the "x: _" will match any "hypothesis" (in this case, we are actually interested in the variables present in the context) [Fri Jul 18 04:19:49 2014] so this will try all variables in your context, try to unify them with what is matched, fail when it is not what is matched, and the remaining will only apply when x=y (so y is a pure variable) [Fri Jul 18 04:21:38 2014] ahh [Fri Jul 18 04:21:41 2014] that makes total sense! [Fri Jul 18 04:21:44 2014] thanks elarnon [Fri Jul 18 04:21:48 2014] I like it [Fri Jul 18 04:22:41 2014] note that if you are matching on an existential variable and there is a variable of that type in your context, this will blindly perform the unification though [Fri Jul 18 04:25:34 2014] good to know [Fri Jul 18 04:26:21 2014] I missed the beginning of the discussion, but I thought there was an is_var tactic to know if a term is a variable [Fri Jul 18 04:26:45 2014] match goal with [ |- context[ match ?y with _ => _ ] ] => is_var y; ... end [Fri Jul 18 04:27:00 2014] oh, you are right [Fri Jul 18 04:27:13 2014] ah, this is exactly what I wanted [Fri Jul 18 04:27:23 2014] somehow never seen that one, nice [Fri Jul 18 04:27:52 2014] yep, that does the trick [Fri Jul 18 04:27:52 2014] knowing that is_evar existed, I could have guessed [Fri Jul 18 04:30:12 2014] never understood how tu use is_evar, though [Fri Jul 18 04:30:42 2014] it always fail for me [Fri Jul 18 15:40:09 2014] Hi, I know almost nothing about coq. Are there some easy exaples of formalization of finite algebra in coq, preferable the universal algebraic flavor? Are there other proof assistants more suitable for finite algebra? [Fri Jul 18 19:26:37 2014] How do I get congruence or a similar tactic to work with setoid equality? Require Import Coq.Classes.SetoidClass. [Fri Jul 18 19:26:40 2014] [Fri Jul 18 19:26:42 2014] Parameter A : Set. [Fri Jul 18 19:26:45 2014] Axiom A_setoid : Setoid A. [Fri Jul 18 19:26:47 2014] [Fri Jul 18 19:26:50 2014] Theorem t : forall a b c : A, a = b -> c = a -> b = c. [Fri Jul 18 19:26:52 2014] Proof. [Fri Jul 18 19:26:55 2014] congruence. [Fri Jul 18 19:26:57 2014] Qed. [Fri Jul 18 19:27:00 2014] [Fri Jul 18 19:27:02 2014] Theorem t' : forall a b c : A, a == b -> c == a -> b == c. [Fri Jul 18 19:27:05 2014] Proof. [Fri Jul 18 19:27:07 2014] try congruence. (* no success *) [Fri Jul 18 19:27:10 2014] intros a b c H H'. rewrite <- H, H'. reflexivity. [Fri Jul 18 19:27:12 2014] srry, did not mean to paste [Fri Jul 18 19:27:15 2014] http://pastebin.com/UNYvFMqr [Fri Jul 18 19:37:09 2014] have you try "reduce"? [Fri Jul 18 19:40:46 2014] johnw: No success. [Fri Jul 18 19:40:59 2014] one sec [Fri Jul 18 19:41:36 2014] that file checks here [Fri Jul 18 19:41:42 2014] oh, I see [Fri Jul 18 19:45:53 2014] it proves here also with: intros. transitivity a; symmetry; assumption. [Fri Jul 18 19:48:35 2014] Yes that works. But I am looking for something as convenient as the subst or congruence tactics is for equality. [Sat Jul 19 05:56:40 2014] Hello. [Sat Jul 19 05:58:07 2014] Is there canonical way to handle hypotheses like "match x with | <1> => true | <2> => false end = true"? [Sat Jul 19 05:59:13 2014] I can do it with proving lemma for bool by destructing x and filtering bad subgoals but when I will have other type (say, nat) I will have to rewrite this routine. [Sat Jul 19 05:59:21 2014] Is there something standard/idiomatic? [Sat Jul 19 05:59:59 2014] I guess that I can write own tactic for that polymorphic on type, but not sure that it is enough robust. [Sun Jul 20 14:11:05 2014] hello [Sun Jul 20 14:11:46 2014] if i need to do "rewrite -> foo" three times, there was some operator to apply tactic until it fails of something, iirc it looked like "!". [Sun Jul 20 14:12:31 2014] could you please remind me that? [Sun Jul 20 14:18:04 2014] [repeat (rewrite -> foo)] should do what you want. [Sun Jul 20 14:18:53 2014] alkabetz: indeed, thank you! [Sun Jul 20 14:40:26 2014] how can I get an instance of `H : forall l : list A, Permutation l (f l) /\ length l = length (f l)` for a specific l ? [Sun Jul 20 14:40:56 2014] I have l : list A but apply doesn't work [Sun Jul 20 14:41:10 2014] osa1: H l [Sun Jul 20 14:43:37 2014] Cale: that doesn't work. "Error: The reference H was not found in the current environment." even though I have H as hypothesis [Sun Jul 20 14:45:00 2014] Are you trying to use it as a tactic? [Sun Jul 20 14:45:05 2014] It's just an expression [Sun Jul 20 14:45:17 2014] You should be able to pose (G := H l) [Sun Jul 20 14:46:06 2014] But whatever you were going to do with G, you could also do with H l directly [Sun Jul 20 14:47:00 2014] e.g. you should be able to split (H l) [Sun Jul 20 14:47:50 2014] If that's the sort of thing you're trying and it's still complaining about H not being found, well, I don't know what's going on. [Sun Jul 20 14:49:56 2014] yeah split (H l) worked. thanks. [Sun Jul 20 14:50:14 2014] it'd still be nice to have H1: . [Sun Jul 20 14:50:24 2014] specialized version* [Sun Jul 20 14:50:41 2014] or instantiated version. I don't know what term to use :P [Sun Jul 20 14:51:32 2014] [pose proof (H l)] maybe? [Sun Jul 20 14:56:50 2014] Yeah, you can use pose to define a variable equal to that [Sun Jul 20 15:03:09 2014] can anyone give me some tips to fill this admitted case http://lpaste.net/107796 ? [Sun Jul 20 15:12:49 2014] Perhaps start with apply (Permutation_trans H0). [Sun Jul 20 15:14:01 2014] oh, right, your induction hypothesis says stuff about t [Sun Jul 20 15:14:31 2014] Ahoy. [Sun Jul 20 15:14:45 2014] I'm reading Gödel, Escher, Bach, and it includes Euclid's theorem about prime numbers. [Sun Jul 20 15:15:20 2014] Which one was that? [Sun Jul 20 15:15:31 2014] There are infinitely many. [Sun Jul 20 15:15:37 2014] okay [Sun Jul 20 15:15:54 2014] Or, to paraphrase it in a manner Euclid may have liked better: For every (finite) set of prime numbers, there is a prime number not in that set. [Sun Jul 20 15:16:04 2014] (If I remember correctly, Euclid wasn't a fan of infinite sets.) [Sun Jul 20 15:16:37 2014] GEB says that the proof, if you break it down into the smallest possible pieces, is actually very complicated. [Sun Jul 20 15:16:45 2014] Set theory didn't really exist in Euclid's time :) [Sun Jul 20 15:16:53 2014] And this made me want to write the proof in Coq without using tactics. [Sun Jul 20 15:17:10 2014] (I find tactic-based proofs completely unreadable. I'm guessing everyone finds tactic-based proofs completely unreadable.) [Sun Jul 20 15:17:28 2014] The usual proof uses LEM [Sun Jul 20 15:17:53 2014] So you'll want to throw that axiom in. [Sun Jul 20 15:18:02 2014] Does it? [Sun Jul 20 15:18:05 2014] yes [Sun Jul 20 15:18:18 2014] I don't remember that bit. I'll add it in once I run into it. [Sun Jul 20 15:18:48 2014] Well, okay, the way you stated it the second time, I don't think you need LEM for. [Sun Jul 20 15:19:29 2014] I certainly don't feel like proving the existence of a bijection between the primes and a subset of the primes. [Sun Jul 20 15:19:29 2014] Hm, actually, perhaps I'm wrong :) [Sun Jul 20 15:19:36 2014] Anyway. [Sun Jul 20 15:19:58 2014] tactic-based proofs are readable iff you can step through them interactively [Sun Jul 20 15:20:14 2014] and see the goal and hypotheses [Sun Jul 20 15:20:19 2014] Right. [Sun Jul 20 15:20:45 2014] I'm trying to find a function that tells me whether or not one nat is greater than another. [Sun Jul 20 15:21:02 2014] And, for the future, I'm wondering if there's a way I can search within Coq for such things. [Sun Jul 20 15:21:12 2014] Like if I can get a list of all names in a module or something. [Sun Jul 20 15:31:16 2014] tswett: managed to find it: http://coq.inria.fr/distrib/current/stdlib/Coq.Arith.Compare_dec.html [Sun Jul 20 15:31:33 2014] Thanks. [Sun Jul 20 15:31:38 2014] tswett: generally, I tend to use the index for the web documentation [Sun Jul 20 15:32:04 2014] In this case, I figured there might be something starting with dec or decidable or something [Sun Jul 20 15:32:12 2014] All right. At the moment, I want to prove ~(S x <= 0). [Sun Jul 20 15:32:32 2014] I felt like proving the decidability manually. [Sun Jul 20 15:33:10 2014] I hit "intro", and now I have S x <= 0 and I want to prove False. [Sun Jul 20 15:33:50 2014] I feel like now I want to do induction on H : S x <= 0, so I can show that le_n doesn't work and le_S doesn't help either. [Sun Jul 20 15:33:58 2014] inversion H. [Sun Jul 20 15:35:13 2014] Yup, that did it. Lemme look up what inversion is. [Sun Jul 20 15:37:19 2014] Feels similar to destruct. [Sun Jul 20 15:40:33 2014] Yeah, it sort of takes the thing apart and figures out what would be required in order to have a term of that type, and when that's impossible, it'll discover this and solve whatever goal you might have. [Sun Jul 20 15:42:07 2014] (impossible because none of the data constructors could generate that particular application of the type constructor) [Sun Jul 20 15:43:07 2014] So it's like destruct, but it also generates hypotheses? [Sun Jul 20 15:44:16 2014] yeah [Sun Jul 20 15:45:21 2014] And how do I change "forall x y" in the goal to "forall y x"? [Sun Jul 20 15:46:09 2014] Rather, change "forall x y" to "forall x" with y as a hypothesis. [Sun Jul 20 15:46:37 2014] I could either swap the antecedents, or do "intros" and then turn x back from a hypothesis into an antedecent. [Sun Jul 20 15:46:58 2014] I think that's "revert x"? [Sun Jul 20 15:47:10 2014] Looks like it. Thanks. [Sun Jul 20 15:52:10 2014] If someone asked me to develop a procedure to test whether or not one natural number is greater than another, I think I would have a much, much easier time describing it in English... [Sun Jul 20 15:55:37 2014] Maybe it would be useful to actually imagine that I'm explaining the procedure, in English, to a very stubborn mathematician. [Sun Jul 20 15:55:52 2014] Then I just have to type in a translation of my explanation. [Sun Jul 20 16:05:43 2014] can anyone help me with this http://lpaste.net/107796 [Sun Jul 20 16:12:42 2014] Now I have "IHy : forall x, blah blah x blah", and I'd like to instantiate it as "blah blah z blah", replacing the original hypothesis. [Sun Jul 20 16:12:55 2014] (I don't have to, but I'd like to.) [Sun Jul 20 16:13:14 2014] IHy z [Sun Jul 20 16:13:24 2014] oh [Sun Jul 20 16:13:38 2014] I could do "set (IHy z)", but that leaves IHy there and I can't clear it. [Sun Jul 20 16:13:43 2014] I don't know about replacing the original hypothesis, but you could generate a new one [Sun Jul 20 16:14:09 2014] Because Coq remembers that the new hypothesis is equal to IHy z, and so it refuses to forget about IHy z. [Sun Jul 20 16:14:31 2014] Yeah, IHy needs to continue existing [Sun Jul 20 16:14:47 2014] You could maybe destruct (IHy z) or something [Sun Jul 20 16:15:43 2014] I guess that works, since I was going to destruct it right away anyway. [Sun Jul 20 16:22:02 2014] "Okay, tswett, I know that x <= y. But how does it follow that S x <= S y?" My, what an interesting question, Mr. Stubborn Mathematician. [Sun Jul 20 16:33:29 2014] All right, the proof turns out to be really simple. [Sun Jul 20 16:33:52 2014] I was trying to figure out whether to use induction on x or on y. After a while, I realized I actually have to do induction on the proof that x <= y. [Sun Jul 20 16:39:44 2014] "All right, tswett, but how about the converse? We are given that S x <= S y, but I don't see why it must be true that x <= y." Why, isn't it the same thing, Mr. Mathematician? Do induction on the given proof. [Sun Jul 20 16:39:56 2014] "No, that doesn't work." No? Why not? [Sun Jul 20 16:54:14 2014] Whelp, I figured out how to get past it. Perform inversion once first, then you can do induction. [Sun Jul 20 17:04:34 2014] I'm trying to figure out exactly how it is that the induction tactic works. [Sun Jul 20 17:16:33 2014] http://lpaste.net/107804 – so I'm trying to figure out how the hypotheses in the last subgoal were generated. [Sun Jul 20 17:17:13 2014] What we had before was H1 : S x <= y |- x <= y. If we perform induction on H1, one of the inductive cases is the constructor le_S : forall m : nat, n <= m -> n <= S m. [Sun Jul 20 17:19:23 2014] What I see happen is that new hypotheses m : nat, H1 : Sx <= m, and IHle : x <= m are created, and in the goal, y is replaced with S m. [Sun Jul 20 17:20:19 2014] I'm trying to figure out why those hypotheses are created. [Sun Jul 20 17:20:24 2014] (Sx should be S x, of course.) [Sun Jul 20 17:22:06 2014] I see there's one hypothesis created for each parameter of le_S, with n replaced with S x. So we get m : nat and H1 : S x <= m. [Sun Jul 20 17:22:46 2014] But there's also an extra hypothesis, IHle : x <= m. That's the inductive hypothesis, of course. Where did it come from, and why's it that? [Sun Jul 20 19:35:20 2014] Dang. Sometimes tactics produce really huge proof terms. [Sun Jul 20 19:36:09 2014] I said, "Goal forall x y : nat, S x <= S y -> x <= y. intros. inversion H. admit. admit. Defined. Print Unnamed_thm1." [Sun Jul 20 19:36:14 2014] It's a pretty good screenful. [Sun Jul 20 20:24:26 2014] Even really simple proofs can be pretty unreadable when written as proof terms. [Sun Jul 20 20:25:17 2014] le_ind (S x) (le x) (le_S x x (le_n x)) (fun m _ => le_S x m) [Sun Jul 20 20:48:07 2014] I guess that is pretty readable when you add lots of comments to it. [Sun Jul 20 23:35:04 2014] Yeah, I guess this is pretty complicated after all. [Sun Jul 20 23:38:09 2014] tswett: have you read the section in Software Foundations about induction? [Sun Jul 20 23:38:19 2014] I don't think so. [Sun Jul 20 23:44:16 2014] you'd find that highly illuminating here [Mon Jul 21 00:11:23 2014] Whelp. This is the best code I've ever written: [Mon Jul 21 00:11:33 2014] Axiom mod_conv : forall (s : nat -> Real) (m : Real), baz m -> baz (minus one m) -> (forall i, gt (times m (minus (s (S i)) (s i))) (minus (s (S (S i))) (s (S i)))) -> exists (l : Real), forall (n : nat), exists (j : nat), forall (p : nat), p > j -> gt (times (nat_to_Real n) (minus l (s p))) /\ gt (times (nat_to_Real n) (minus (s p) l)). [Mon Jul 21 00:13:06 2014] Actually, gt takes multiple arguments. [Mon Jul 21 00:15:38 2014] Stick "one" after both of those "gt"s. [Mon Jul 21 00:40:43 2014] does that really need to be an axiom? [Mon Jul 21 17:54:46 2014] can anyone help me proving this simple theorem? http://lpaste.net/107853 I can't make any progress for two days now [Mon Jul 21 18:19:02 2014] osa1 : I have a solution, do you want it or just a hint? [Mon Jul 21 18:19:17 2014] Cypi: hint :) [Mon Jul 21 18:19:42 2014] Ok. By doing it this way you are stuck I believe, because you are reasoning about permutations, so having an induction hypothesis like that is not enough [Mon Jul 21 18:20:08 2014] Try proving this instead : [forall A (f : list A -> list A), (forall (l : list A), Permutation l (f l)) -> forall (n : nat) (l : list A), length l = n -> Permutation l (map_rest l f)] [Mon Jul 21 18:20:19 2014] and then you use it to prove your main theorem [Mon Jul 21 18:23:16 2014] Cypi: as far as I can see only difference is that extra n but why is this necessary? [Mon Jul 21 18:23:29 2014] You can also start your proof with [intros. remember (length l) as n. generalize dependent l.] to do the same, actually [Mon Jul 21 18:23:45 2014] the idea is that you will do the induction on the length of l, not on l itself [Mon Jul 21 18:24:05 2014] That way, you will get an induction hypothesis about the tail of l, but also all the permutations of the tail of l [Mon Jul 21 18:24:27 2014] (or any list of size [length l - 1], which is what you need) [Mon Jul 21 18:30:36 2014] Cypi: I'm having this IHn' : length l = n' -> Permutation l (map_rest l f) but I can't use it because this is second case of induction, where length l = S n'. [Mon Jul 21 18:31:10 2014] [IHn' : forall l : list A, n' = length l -> Permutation l (map_rest l f)] I have this, which is better [Mon Jul 21 18:31:21 2014] l should not be in the context when you do the induction, only n [Mon Jul 21 18:31:55 2014] okay let me try that [Mon Jul 21 18:33:08 2014] okay. now I need to destruct l, right? [Mon Jul 21 18:34:20 2014] That's probably a good idea, yes [Mon Jul 21 18:47:31 2014] how can I get `Permutation (a :: l) (f (a :: l))` from H : forall l : list A, Permutation l (f l) ? [Mon Jul 21 18:48:13 2014] Just [apply H] will do the job. So even [auto] will do it [Mon Jul 21 18:48:33 2014] Oh, sorry, you want it as an hypothesis? [pose proof (H l)] [Mon Jul 21 18:49:00 2014] Or [pose proof (H (a :: l))] rather :p [Mon Jul 21 18:49:09 2014] that worked, thanks [Mon Jul 21 18:50:31 2014] I'm trying to eliminate first case of `match f l with ...` [Mon Jul 21 18:50:49 2014] I have this as hypothesis H0 : Permutation (a :: l) [] [Mon Jul 21 18:51:13 2014] ah, Permutation_nil should help [Mon Jul 21 18:51:19 2014] to derive a :: l = [] [Mon Jul 21 18:51:25 2014] For instance, yes [Mon Jul 21 19:01:34 2014] interesting. I'm stuck again but this time at `length ret = n'`. all I know about n' is that it's a nat [Mon Jul 21 19:01:42 2014] maybe I need to use remember at some point [Mon Jul 21 19:03:05 2014] hmm yeah H2 : length l = n' is lost at some point because I used it in apply [Mon Jul 21 19:04:11 2014] and it worked!! \o/ [Mon Jul 21 19:04:13 2014] Cypi: thanks! [Mon Jul 21 19:04:36 2014] now I'm going to remove `length l = n` part and use remember instead [Mon Jul 21 19:07:34 2014] Cypi: http://lpaste.net/107854 how did you solve it? [Mon Jul 21 19:32:23 2014] so with the help of this theorem I proved that a weird sort function returns a permutation. now harder part, proving that result is sorted. [Tue Jul 22 05:34:36 2014] osa1 : http://lpaste.net/107866 [Tue Jul 22 05:34:54 2014] but that's not particularly a nice proof, I didn't try to make it better :p [Tue Jul 22 05:41:54 2014] Cypi: what's destruct ... eqn: ... ? [Tue Jul 22 05:42:28 2014] It keeps in context an equation about what you destructed [Tue Jul 22 05:42:44 2014] whoa! [Tue Jul 22 05:42:59 2014] So here it adds [Hfal: f (a :: l) = []] and [Hfal: f (a :: l) = a' :: l'] [Tue Jul 22 05:43:02 2014] I was doing something like that `remember (f (a :: l)) as ret` before every single destruct [Tue Jul 22 05:43:11 2014] Well, now you can do that :) [Tue Jul 22 05:43:16 2014] awesome! \o/ [Tue Jul 22 05:43:17 2014] (the syntax is a bit weird, but eh) [Tue Jul 22 06:44:58 2014] it's still not exactly same as remember ... as e. destruct e. [Tue Jul 22 06:51:16 2014] generated equality is symmetric to what we get when remember is used. [Tue Jul 22 09:02:59 2014] Hello. [Tue Jul 22 09:03:41 2014] I have project divided into subfolders. How can I make modules be accessible by "dot" notation? [Tue Jul 22 09:04:03 2014] I have read manual, but either I hadn't understood or it doesn't talk about it. [Tue Jul 22 09:04:26 2014] I want to be able to access A/B/C.v with "Require Import A.B.C.". [Tue Jul 22 09:06:43 2014] I also tried to examine how it is done in coq "theories", but I only see "Require Export Datatypes." in Init/Prelude.v; though it is possible to write "Require Import Coq.Init.Datatypes." [Tue Jul 22 09:12:13 2014] And I tried -R option of coq, but id doesn't seem to help. [Tue Jul 22 10:51:03 2014] http://bogomolov-lab.ru/SHKOLA2014/talks/voevodsky.html Voevodsky is going to talk about Homotopy Type Theory and Coq at the Russian algebraic geometry school [Tue Jul 22 10:52:21 2014] notdan, will he actually use HoTT or only plain Coq? The page talks only about Coq, no mention about HoTT. [Tue Jul 22 11:09:18 2014] well he talks about "univalent foundations" and i think he will show examples from homotopy theory proved with hott [Tue Jul 22 16:52:17 2014] anyone around? [Tue Jul 22 16:54:07 2014] dfdfff: I am [Tue Jul 22 16:56:14 2014] ianjneu: Good. I'm reading Aluffi's "Algebra 0" and would like to do proofs in Coq. Is it a realistic goal for a beginner in both? [Tue Jul 22 16:57:38 2014] ianjneu: For instance, I'd like to prove that a certain relation is an equivalence relation. Or, say, that Sets is indeed a category. [Tue Jul 22 16:58:03 2014] What packages should I try? [Tue Jul 22 16:58:53 2014] Category theory is generally difficult to do in dependent type theories, but jgross has done some good work using univalence in the HoTT github repo. [Tue Jul 22 16:59:54 2014] ianjneu: Oh, I've thought it should be easy. Could you elaborate a bit? [Tue Jul 22 17:00:08 2014] I don't know Aluffi's Algebra 0. I would recommend a text that is written with mechanized proof in mind, like "software foundations" [Tue Jul 22 17:01:42 2014] dfdfff: The notion of equality in category theory is largely brushed under the rug as a "foundational question," but in a proof theory, the foundation hits you square in the face. Homotopy type theory has a promising notion of equality that is suitable for reasoning about equalities/equivalences in categories. [Tue Jul 22 17:03:05 2014] On top of equality issues are representation questions. Bundling morphisms and objects and all the rest actually takes careful thought and engineering. Many previous attempts have come up against performance limitations of the underlying proof assistants. [Tue Jul 22 17:04:27 2014] I don't have a single source to point you to on this, as it's just been buzzing around my head following different conversations in person, the Agda and Coq mailing lists, etc. jgross again is probably a good resource for questions about CT in DTT. [Tue Jul 22 17:04:34 2014] I'm surprized that there are performance problems. [Tue Jul 22 17:05:01 2014] Thanks for the pointers, anyway. [Tue Jul 22 17:20:56 2014] ianjneu: are you familiar with Pierce's Category Theory book? Does it contain any proofs/defn's? [Tue Jul 22 17:33:47 2014] I haven't read it, no. [Tue Jul 22 17:34:24 2014] I also don't expect much formalism when I see category theory proofs. [Tue Jul 22 17:40:03 2014] any ideas what does OTT stand for? I guess ITT is intuitionistic type theory but OTT??? [Tue Jul 22 17:42:49 2014] observational type theory [Tue Jul 22 17:43:11 2014] thanks. [Tue Jul 22 17:43:18 2014] It's... something best overlooked. [Tue Jul 22 17:44:19 2014] Conor McBride is a bit of a type theory hacker, so what he comes up with isn't particularly clean, concise or elegant. [Tue Jul 22 17:51:29 2014] I don't know any alternative type theories(I don't even know Coq's underlying type theory completely) but I like Coq's syntactic approach of deciding termination and equality, mostly because it's very easy to understand and I'm a beginner :) [Tue Jul 22 17:53:23 2014] I'm wondering how is well-founded recursion encoded in Coq. is there a magic(an axiom or something like that) that somehow makes Coq termination checker to accept such definitions or is it somehow encoded in a way that it looks to Coq like a structural recursion on subterms? [Tue Jul 22 17:53:59 2014] osa1: it's unfortunately not that easy to understand because it had bugs in it until recently. [Tue Jul 22 17:54:19 2014] wellfoundedness is proven using Acc. [Tue Jul 22 17:54:38 2014] ianjneu, dfdfff: Most of what I've done is precategory theory; I haven't actually been making use of univalence much, but have been making sure that what I do is compatible with it. In Agda, copumpkin has a category theory library with many contributions from Saizan and xplat, and all three of them tend to hang around #agda. (By the way, proving that Sets is a (pre)category is pretty easy, though you need functional extensionality to get that [Tue Jul 22 17:54:38 2014] the morphisms form a set rather than a groupoid. Here's my construction: https://github.com/HoTT/HoTT/blob/master/theories/categories/SetCategory/Core.v) [Tue Jul 22 17:55:47 2014] ianjneu: do you mean in termination checker or equality? what was the bug? [Tue Jul 22 17:56:07 2014] Also, I'm happy to answer questions, though I only check IRC a few times a day (at most; ocassionally I only check it once every few days). If you mention 'jgross', though, it'll be highlighted in my client, and I'll notice it. [Tue Jul 22 17:56:16 2014] cafe closing. Relocating. [Tue Jul 22 17:59:16 2014] osa1: The guardedness checker (termination checker) is/was incompatible with propositional extensionality. (The coinductive productivity checker had a bug that let you prove false in a vaguly similar manner that doesn't actually require propositional extensionality.) The bugs are now (mostly?) fixed. There are more details on the coq-club archives. (You can search for mail from Maxime Denes to find it relatively quickly.) [Tue Jul 22 18:24:20 2014] what is propositional extensionality? is this that function equality thing? [Tue Jul 22 18:24:55 2014] (p <-> q) -> p = q [Tue Jul 22 18:25:17 2014] Is that the same thing as proof irrelevance? [Tue Jul 22 18:25:38 2014] Hum, nevermind. [Tue Jul 22 18:32:25 2014] is that defined by default or is it an extra axiom like the one that says functions may be equal even thought they're syntactically not? [Tue Jul 22 18:32:29 2014] (what was the name of it?) [Tue Jul 22 18:32:39 2014] functional extensionality [Tue Jul 22 18:32:43 2014] and that's an extra axiom [Tue Jul 22 18:33:33 2014] functional extensionality is an axiom in Coq, but it does follow from the computational extensional equality from univalence. [Tue Jul 22 18:56:55 2014] so what's univalence? I always thought HoTT when I heard univalence I don't have many ideas about HoTT too :) I was just reading this "Function extensionality as a principle of equality cannot be derived in ITT, but must be added as an additional postulate (or derived from a stronger postulate, such as univalence or the existence of a one-dimensional interval type)." in one of Robert Harper's blog posts [Tue Jul 22 19:11:36 2014] "The “Fix” combinator is written as primitive-recursive in the structure of a termination proof, and extraction to OCaml erases proofs systematically." so when I use well-founded recursion, decreasing argument is actually the termination proof? cool. [Tue Jul 22 19:18:04 2014] osa1: that is correct. [Wed Jul 23 12:45:58 2014] ijp: Another Racket/Coq member. Interesting. [Wed Jul 23 12:51:25 2014] I'm not stalking you, honest! [Wed Jul 23 12:52:00 2014] Nah, anyone straddling Racket and Coq at the same time is too busy for stalking. [Thu Jul 24 00:13:02 2014] http://rosettacode.org/wiki/Proof#Agda [Thu Jul 24 00:13:21 2014] i've heard that coq is usually more verbose than agda, but this doesn't seem to be the case here [Thu Jul 24 00:13:38 2014] what do you get with agda that you don't get with coq? [Thu Jul 24 00:13:47 2014] what do you get with coq that you don't get with agda? [Thu Jul 24 05:01:00 2014] how good/complete would you say Coq's extraction to OCaml is in 8.4? [Thu Jul 24 07:08:50 2014] johnw: Modulo a couple issues related to functor extraction, it’s very complete. [Thu Jul 24 07:09:06 2014] The Coq development team makes the OCaml extractor a higher priority than the Haskell or Scheme extractors. [Thu Jul 24 07:09:56 2014] We’re using it for research work in my group, and it produces multiple thousand lines of OCaml without issue (save for the aforementioned functor issues). [Thu Jul 24 07:42:55 2014] alkabetz what for do you produce code ? [Thu Jul 24 07:48:27 2014] We have a compiler written in Coq; its bottom IR gets extracted to OCaml, which pretty-prints it. [Thu Jul 24 07:48:35 2014] It’s really a performance hack. [Thu Jul 24 07:53:36 2014] alkabetz a compiler for which language ? [Thu Jul 24 07:54:22 2014] Bedrock: http://plv.csail.mit.edu/bedrock/ [Thu Jul 24 07:56:46 2014] alkabetz oh you work with adam ? [Thu Jul 24 07:58:22 2014] Yes. [Thu Jul 24 07:58:49 2014] alkabetz oh i envision you will write a verified operating system in coq some day ? [Thu Jul 24 07:59:21 2014] I don’t know about me personally, but I think that’s a dream :) [Thu Jul 24 07:59:31 2014] The technology is still quite a way away from taking on a project of that magnitude. [Thu Jul 24 08:35:26 2014] alkabetz is it the opinion of your team ? [Thu Jul 24 08:52:07 2014] I like my group. Everybody is very competent. I can get a lot of good help when Coq misbehaves. :) [Thu Jul 24 09:03:13 2014] alkabetz sure, as adam wrote a book about coq :) [Thu Jul 24 09:39:07 2014] adam? of CPDT? [Thu Jul 24 09:46:21 2014] Hodapp yes [Thu Jul 24 09:47:00 2014] I need to read that book [Thu Jul 24 10:10:54 2014] Hodapp i began but it becomes difficult early... [Thu Jul 24 10:11:45 2014] Agreed, I'm currently trying to read it [Thu Jul 24 13:29:46 2014] hehe, Adam is much nicer in person than he appears on the Coq mailing list :) [Thu Jul 24 13:32:06 2014] Ptival: he's gotten better. [Thu Jul 24 13:32:49 2014] Once he all but said to me that my research is stupid. [Thu Jul 24 13:36:51 2014] ianjneu what rude :/ [Thu Jul 24 13:40:06 2014] Well, I pivoted research topics after that anyway, since Matthias Felleisen told me, "it's a noble goal, but I've been thinking about how to do that for 20 years and still don't know where to start." [Thu Jul 24 13:40:48 2014] Not many people appreciate hygienic macros. [Thu Jul 24 14:51:31 2014] I'm now about halfway through CPDT [Thu Jul 24 14:51:42 2014] some parts of certainly denser than others, so skip them if they give you troubles [Thu Jul 24 14:51:45 2014] better parts lie ahead :) [Thu Jul 24 14:52:10 2014] I'm glad he wrote it, but so far I haven't seen anything else even remotely like it out in the world [Thu Jul 24 14:52:22 2014] which is a shame, because Coq can do some very cool things [Thu Jul 24 14:55:12 2014] certified programming I thought was not particularly unique - is it the dependent typing that makes it unique? [Thu Jul 24 14:55:22 2014] it's the emphasis on proof automation [Thu Jul 24 14:55:42 2014] I thought automated proof assistants were already used plenty for certified programming though [Thu Jul 24 14:55:44 2014] he basically makes the claim that nearly every proof you do should end up using only one or two tactics for the body of the proof [Thu Jul 24 14:55:53 2014] huh [Thu Jul 24 14:58:32 2014] I'm liking cpdt as well, though some parts I only skim to keep for future reference... part III about proof automation and Ltac is interesting (Coq'Art didn't cover Ltac if I remember correctly) [Thu Jul 24 14:58:59 2014] yeah, I've skimmed several sections now, since they really get into the nitty gritty of how to automate very particular scenarios [Thu Jul 24 14:59:08 2014] it's good enough to know they're there for future reference [Thu Jul 24 14:59:37 2014] but it's cool just how much area he covers [Thu Jul 24 14:59:49 2014] at OPLSS I asked elarnon if there was a way to use domain theory to encode free monads in Coq [Thu Jul 24 15:00:07 2014] and lo and behold, CPDT has a chapter on using domain theory to encode potentially non-terminating monads in Coq :) [Thu Jul 24 15:00:14 2014] yes [Thu Jul 24 15:00:42 2014] this is the chapter about general recursion, and it's quite useful [Thu Jul 24 15:00:53 2014] Hodapp: dependent typing is not really unique either [Thu Jul 24 15:01:39 2014] it's curious that there's nothing about type classes, but I think the book was mostly written a few years ago [Thu Jul 24 15:07:51 2014] I had an idea for the Admitted directive [Thu Jul 24 15:08:34 2014] What if Admitted, instead of just assuming the theorem, in the background generated a QuickCheck test for that theorem and ran it through 100 iterations during type-checking, so that you could at least get sanity checking for pending proofs [Thu Jul 24 15:11:55 2014] this could be problematic for some richer types in Coq [Thu Jul 24 15:12:30 2014] quickcheck my theorem that assumes the generalized reimann hypothesis [Thu Jul 24 15:12:44 2014] riemann* [Thu Jul 24 15:22:56 2014] well, let's say it'll do it if and where it can [Thu Jul 24 15:23:08 2014] a "better than nothing" approach, that can also just be turned off [Thu Jul 24 15:23:18 2014] maybe Tested instead of Admitted [Thu Jul 24 15:23:28 2014] ianjneu what was your first research topics ? [Thu Jul 24 15:23:29 2014] johnw: Well, this exists in the ACL2 sedan :) [Thu Jul 24 15:23:40 2014] ianjneu: nice to know! [Thu Jul 24 15:24:02 2014] at work i'm currently reviewing the theorems proving universe, so that kind of info is exactly what I'm looking for [Thu Jul 24 15:24:42 2014] Anarchos: 1st was automated theorem proving in ACL2 with Pete Manolios. He pivoted to system assembly via SMT, so I went to work with Mitch Wand on proving correctness of hygienic macros. [Thu Jul 24 15:25:02 2014] what is ACL2 ? [Thu Jul 24 15:25:30 2014] a computational logic for applicative common lisp. [Thu Jul 24 15:26:27 2014] It's a current "Boyer-Moore" style theorem prover, actively developed by Moore and more substantially by Matt Kaufmann. [Thu Jul 24 15:26:37 2014] we're using ACL2 in fact, but not my immediate gruop [Thu Jul 24 15:26:38 2014] The other "current" is PVS. [Thu Jul 24 15:27:07 2014] alkabetz: say hi to adam from me, I was one of his first hcoop users :) [Thu Jul 24 15:27:11 2014] ok [Thu Jul 24 15:27:39 2014] johnw: He’s at a PI meeting right now, but I’ll be sure to mention you when he gets back next week [Thu Jul 24 15:28:22 2014] when I first knew him, he was undergrad, that was a long time ago now, 12 years? [Thu Jul 24 15:32:17 2014] is this a file format that GNU Make recognizes or is this for some Coq-specific build tool http://mattam.org/repos/coq/prelude/Make ? [Thu Jul 24 15:36:01 2014] that looks like a file you'd import into a makefile [Thu Jul 24 15:36:08 2014] how, I don't know [Thu Jul 24 15:36:11 2014] awful. I guess that project uses some now invalid Coq syntax [Thu Jul 24 15:36:14 2014] are you using coq_makefile to generate your Makefile? [Thu Jul 24 15:36:33 2014] no [Thu Jul 24 15:36:55 2014] I never used that. but that project won't work anyway [Thu Jul 24 15:39:02 2014] looks like that project is last updated in 2007. [Thu Jul 24 15:39:11 2014] which project? [Thu Jul 24 15:41:52 2014] [22:31] is this a file format that GNU Make recognizes or is this for some Coq-specific build tool http://mattam.org/repos/coq/prelude/Make ? <--- that one [Thu Jul 24 15:42:00 2014] ah, I see [Thu Jul 24 15:46:46 2014] I have F : Type -> Type and I'm having this error message: `The term "ret ?506 x" has type "F ?506" while it is expected to have type "Type".` any ideas why? [Thu Jul 24 15:48:42 2014] Probably a problem with universes (which means I won't be able to help you much ^^ ) [Thu Jul 24 15:49:13 2014] Try [Set Printing Universes.] just to confirm. [Thu Jul 24 15:49:33 2014] Error: Use CoqIDE display menu instead [Thu Jul 24 15:49:35 2014] .......... [Thu Jul 24 15:49:51 2014] this thing is driving me crazy [Thu Jul 24 15:50:02 2014] In "View", check "Display universes levels" [Thu Jul 24 15:50:08 2014] universe* [Thu Jul 24 15:50:11 2014] I'm not using CoqIDe [Thu Jul 24 15:50:22 2014] Oh. [Thu Jul 24 15:50:24 2014] :o [Thu Jul 24 15:51:16 2014] it's just that my coq editor uses coq with -ideslave parameter which makes coq assume that it's running inside CoqIDE. [Thu Jul 24 15:51:35 2014] oh wait, I have CoqIDE installed [Thu Jul 24 15:52:02 2014] I have this error when compiling coq : http://pastebin.com/5JzevKFq [Thu Jul 24 15:53:46 2014] Cypi: is this a universe related error http://lpaste.net/108057 ? [Thu Jul 24 15:55:10 2014] Seems like it, I guess. F returns a [Type (* Top.774 *)] while a [Type (* Top.791 *)] is expected, and most probably, somehow, Top.774 < Top.791 is enforced [Thu Jul 24 15:55:29 2014] oh wait [Thu Jul 24 15:55:48 2014] [The term "ret x" has type "x -> F x"] >> I'm not sure actually, don't believe me ^^' [Thu Jul 24 15:56:52 2014] Cypi: I pasted wrong error message [Thu Jul 24 15:56:55 2014] let me paste correct one [Thu Jul 24 15:57:25 2014] Cypi: http://lpaste.net/108057 [Thu Jul 24 15:57:50 2014] Ok, so what I was saying did make sense, I believe [Thu Jul 24 15:58:02 2014] (not that it would help you however ^^ ) [Thu Jul 24 16:40:40 2014] cool. I can use _ to fill that part in tactic mode [Thu Jul 24 16:40:46 2014] while defining instances [Thu Jul 24 16:44:34 2014] I wish I could do that without losing almost all the relevant information. [Thu Jul 24 16:44:43 2014] while defining functions/fixpoints [Thu Jul 24 16:51:05 2014] what to do to use (x, y) syntax for pair construction/pattern matching? [Fri Jul 25 03:47:59 2014] is "scattered sublist" in the coq libs? [Fri Jul 25 03:49:24 2014] nm guess ill adapt from this http://coq.inria.fr/pylons/contribs/files/HigmanS/v8.4/HigmanS.list_embeding.html#Embeds [Fri Jul 25 09:30:35 2014] http://plv.csail.mit.edu/ur/ that's kind of interesting... [Fri Jul 25 09:30:41 2014] now if only we could do it client-side o_O [Fri Jul 25 09:32:15 2014] Hodapp: sandbox the sandbox in a sandbox. [Fri Jul 25 09:32:25 2014] and yet still XSS. [Fri Jul 25 09:33:34 2014] Hodapp: also relevant to your interests http://blog.ezyang.com/2012/07/managing-the-server-client-split-in-ur-web/ [Fri Jul 25 09:50:54 2014] hello [Fri Jul 25 09:51:14 2014] "coqc" says "Error: There are pending proofs", what does it means? [Fri Jul 25 09:51:49 2014] Ainieco: you have unproven goals, or you haven't written Qed. or Defined. after your proofs. [Fri Jul 25 09:51:55 2014] i have quite large file and it looksl ike everyth theorem have its "Qed". [Fri Jul 25 09:53:01 2014] unfortunately I don't know of a settable warning for a newly started "Theorem" or "Lemma" during a proof. [Fri Jul 25 09:53:19 2014] Binary search your file by commenting out parts to find where the unclosed theorem is. :/ [Fri Jul 25 09:53:47 2014] uh, okay [Fri Jul 25 09:55:15 2014] what is difference between [| ] and [] in "destruct x as"? [Fri Jul 25 09:56:09 2014] | separates constructors. [Fri Jul 25 09:57:09 2014] if x is of type T, with constructors C1 ... Cn, you would expect a pattern on x to have [names ..._1| ...|names ..._n] [Fri Jul 25 09:58:01 2014] where names correspond to arguments of the respective constructors, with trailing names optional. [Fri Jul 25 09:58:17 2014] In what circumstances would I be expecting this? [Fri Jul 25 09:59:59 2014] When I’m reading somebody else’s code? When Coq is autogenerating names for me? [Fri Jul 25 10:00:00 2014] expecting what? That the syntax makes intuitive sense? [Fri Jul 25 10:00:15 2014] Oh, wait, derp [Fri Jul 25 10:00:19 2014] That was not a question. [Fri Jul 25 10:00:28 2014] I was very confused. :P [Fri Jul 25 10:00:30 2014] Sorry. [Fri Jul 25 10:00:40 2014] ianjneu: got it, thanks [Fri Jul 25 10:00:53 2014] No apologies necessary. Coq has some weird design decisions that cause confusing. [Fri Jul 25 10:00:56 2014] confusion* [Fri Jul 25 14:11:25 2014] hi all. [Fri Jul 25 14:13:11 2014] I want to define some languages in Coq -- which means implementing operational semantics, type system etc. as inductive definitions. almost all of the languages contain some kind of binders and thus substitution, alpha renaming etc. and it's too painful to implement those again and again. I'm wondering if we have some libraries to somehow make implementing those easier. [Fri Jul 25 14:27:08 2014] osa1: there's probably a few [Fri Jul 25 14:27:17 2014] right now I can think of dblib by Pottier [Fri Jul 25 14:28:14 2014] might also want to consider PHOAS unless you need to do program transformations [Fri Jul 25 14:42:55 2014] hello [Fri Jul 25 14:43:58 2014] is there a let statement(expression) in coq? [Fri Jul 25 14:44:32 2014] i want to use it within Fixpoint [Fri Jul 25 14:47:11 2014] Ainieco: I think so, it's probably "let pattern := expr in expr"? [Fri Jul 25 15:01:46 2014] is there a standard library module for applying all the lambda calculus conversions? I mean, I know beta-reduction would just be "simpl", but what about eta conversion? [Fri Jul 25 15:04:42 2014] Ptival: it worked, thanks! [Fri Jul 25 15:07:39 2014] johnw: There’s the cbv tactic for β/δ/ι/ζ reduction. I don’t know about η. [Fri Jul 25 15:07:52 2014] ok, thanks! [Fri Jul 25 15:08:10 2014] I've seen the tactic mentioned in Adam's book [Fri Jul 25 15:28:28 2014] how to search proofs by substring? [Fri Jul 25 15:30:03 2014] i just want to find all proofs which name includes "beq_nat" [Fri Jul 25 15:30:16 2014] of proves something about beq_nat function [Fri Jul 25 15:31:34 2014] well, you can use SearchAbout and SearchRewrite [Fri Jul 25 15:33:28 2014] johnw: SearchAbout is what i wanted, thank you [Fri Jul 25 15:37:57 2014] johnw: what SearchRewrite does? [Fri Jul 25 15:38:52 2014] SearchRewrite (S _ + n = S (_ + n) [Fri Jul 25 15:38:58 2014] you can search for patterns [Fri Jul 25 15:41:14 2014] What's your sha256sum of http://coq.inria.fr/distrib/V8.4pl4/files/coq-8.4pl4.tar.gz? [Fri Jul 25 15:41:25 2014] johnw: oh, that's really cool! [Fri Jul 25 17:30:06 2014] i'm proving various goals that involve arithmetic (+, -, *, =, <>) over sig types. ordinarily, omega would be able to solve these without any problem, but some constraints are hidden away inside the sig type. is there a "omega for sig types" of some sort out there, to help automate proving such things? [Fri Jul 25 18:05:38 2014] Ptival: what is PHOAS? [Fri Jul 25 18:28:39 2014] osa1: parametric higher-order abstract syntax [Fri Jul 25 18:28:57 2014] osa1: there's a primer on it in CPDT [Sat Jul 26 07:22:26 2014] I can't make this code copied from CPDT working http://lpaste.net/108181 any ideas what's changed? [Sat Jul 26 07:28:57 2014] What error do you get? [Sat Jul 26 07:29:13 2014] Also, make sure to have [Set Implicit Arguments.] if you want to make code from CPDT work [Sat Jul 26 07:37:04 2014] ops, right. it works now, thanks [Sat Jul 26 15:08:33 2014] I often got «/bin/sh: ./install.sh: Argument too big», is it known ? [Sat Jul 26 16:57:15 2014] it fails in install-library [Sat Jul 26 18:37:06 2014] slowly, I think I made sense of why the notation for a function's signature is the same as the notation for logical implication. [Sat Jul 26 18:37:09 2014] I think. [Sat Jul 26 18:53:07 2014] Hodapp curry howard correspondence. [Sat Jul 26 18:53:41 2014] I know the sound-bite reason, but that doesn't give an immediate intuitive notion for the nature of the notation. [Sat Jul 26 19:16:47 2014] why are a lot of proofs shown with ; rather than . separating the tactics, in cases where they are equivalent in meaning? (i.e. only one subgoal) [Sat Jul 26 22:43:00 2014] huh, Imp.v mentions "Fixpoint loop_false (n : nat) : False := loop_false n." being illegal by virtue of being non-terminating recursion [Sat Jul 26 22:43:19 2014] but says, hypothetically, if it were permitted, then 'loop_false 0' would be a proof of False, which would cause all sorts of problems [Sat Jul 26 22:43:45 2014] can't quite grasp what they mean there... how would it be a proof of False? [Sat Jul 26 22:46:44 2014] Hodapp: Just look at its type! [Sat Jul 26 22:47:01 2014] Hodapp: loop_false applied to any n : nat has type False [Sat Jul 26 22:50:36 2014] but even being permitted, what does that actually matter, when it cannot terminate? [Sat Jul 26 22:54:01 2014] You don't actually evaluate proofs to decide if they're valid. [Sat Jul 26 22:54:29 2014] Evaluation corresponds to some sort of normalisation or simplification of proofs. [Sat Jul 26 22:55:41 2014] Introducing axioms such as LEM will also cause proofs to become stuck terms. [Sat Jul 26 22:55:50 2014] LEM? [Sat Jul 26 22:55:57 2014] Law of excluded middle [Sat Jul 26 22:56:01 2014] oh. [Sat Jul 26 22:56:13 2014] and what is a 'stuck term'? [Sat Jul 26 22:56:57 2014] An expression which isn't a value, but to which no evaluation rule applies. [Sat Jul 26 22:58:42 2014] Er, sorry, or perhaps one which never reaches a value under evaluation. [Sat Jul 26 22:59:14 2014] So infinite loops count as well, even though evaluation rules keep applying, they don't help reduce the expression to a value. [Sat Jul 26 23:01:49 2014] If you think about classical logic, it really has nothing corresponding to evaluation [Sat Jul 26 23:02:09 2014] It just has something which more or less corresponds to typechecking. [Sat Jul 26 23:06:24 2014] I think that makes sense, thanks [Sat Jul 26 23:06:37 2014] I was off of this textbook for 3 months so I'm having to re-learn some things. [Sun Jul 27 09:09:10 2014] when I have a section and inside it `Variable A : Set`, is that added to definitions in the section as an implicit argument? [Sun Jul 27 10:16:09 2014] I'm trying to implement "get" on ilists using tactics and I wrote this http://lpaste.net/108218 extracted code is different but I believe they could be proven equal(e.g. for same arguments they return same results) [Sun Jul 27 10:17:43 2014] implementing recursion on sub-structures of multiple arguments is too painful to implement in both tactics and code. [Sun Jul 27 10:21:26 2014] also, I don't understand how this line http://lpaste.net/108218#line29 works. (line 29) it's missing get's first argument [Sun Jul 27 10:36:58 2014] osa1: note the Set Implicit Arguments. [Sun Jul 27 10:47:07 2014] hmm, SF notes the Coq "computation mechanism" a few times but I still have a hazy idea what it actually is [Sun Jul 27 10:48:23 2014] Hodapp: beta, iota, delta, zeta reduction? [Sun Jul 27 12:01:06 2014] So, if my interpretation is right, when SF gives their example of evaluating some expressions and imperative commands... [Sun Jul 27 12:01:47 2014] this can be done as a relation, which requires a proof that the given expression actually does evaluate to a result [Sun Jul 27 12:02:52 2014] or it can be done as a function, which utilizes Coq's "computation mechanism", and is itself a constructive way to create that same proof [Sun Jul 27 12:03:25 2014] but, then it cannot handle constructs such as their general 'while' loop, because it cannot guarantee termination [Sun Jul 27 12:07:24 2014] that's the way I made sense of stuff, so hopefully that's reasonably correct. [Mon Jul 28 05:15:10 2014] still "argument too big" when installing coq library :( [Mon Jul 28 06:21:44 2014] I'm implementing code in CPDT without using implicit arguments. I hope this removes some levels of magic. [Mon Jul 28 06:23:55 2014] osa1 i cross fingers for you :) [Mon Jul 28 06:23:57 2014] also, I'm avoiding name shadowing since it makes things only more complex and hard to understand. (like y in match ... in return (x y) where y is also a parameter to the enclosing function) [Mon Jul 28 06:24:02 2014] heh [Mon Jul 28 06:34:37 2014] I'm still using {} sometimes [Mon Jul 28 06:56:18 2014] what is Obj.magic Tt and why is it used in places of absurd cases? [Mon Jul 28 06:56:53 2014] (in extracted OCaml code) [Mon Jul 28 07:02:23 2014] is there a value like "undefined" of Haskell to just fill in some parts to see the progress? [Mon Jul 28 07:04:28 2014] in definition of Fin in CPDT, isn't this constructor have wrong type: | First : forall n, fin (S n) ? I think it should be First : fin 1 [Mon Jul 28 07:07:55 2014] Obj.magic has type [forall A B, A -> B] [Mon Jul 28 07:08:13 2014] so it serves in places where the OCaml type system isn't expressive enough [Mon Jul 28 07:11:16 2014] Cypi: any ideas about fin? [Mon Jul 28 07:11:21 2014] About [fin n], as he says, it's meant to be isomorphic to {m : Nat | m < n}. So, first of all, [fin 0] has no elements, hence the [S n] in the constructor [First]. [Mon Jul 28 07:12:04 2014] Then, if you just put [fin 1], it doesn't work: the only inhabitant of [fin 2] would be [Next (First 1)] for example, and so on (you would have exactly one inhabitant of [fin n] for any n > 0). [Mon Jul 28 07:12:04 2014] yeah but I think it should be First : S 0 which still makes it isomorphic to that [Mon Jul 28 07:12:19 2014] ah [Mon Jul 28 07:12:50 2014] I get it now, thanks [Mon Jul 28 07:13:16 2014] I still think my definition would make some stuff easier [Mon Jul 28 07:13:53 2014] Your definition doesn't make [fin n] isomorphic to {m : Nat | m < n} [Mon Jul 28 07:14:14 2014] right but why we need that isomorphism? [Mon Jul 28 07:14:29 2014] Because the idea is to use an element of [fin n] as an index for an [ilist n] [Mon Jul 28 07:14:55 2014] and the only indexes that make sense for an [ilist n] are those in {m : Nat | m < n} [Mon Jul 28 07:15:05 2014] which is why we want a type to represent this set of indexes [Mon Jul 28 07:15:21 2014] oh right [Mon Jul 28 07:15:31 2014] Try to write [get] with your definition if you're not convinced [Mon Jul 28 07:15:44 2014] right, my definition would be useless. [Mon Jul 28 07:15:53 2014] You will either get in trouble trying to write it, or write a definition that will only allow access to the last element [Mon Jul 28 07:16:10 2014] (depending on the type you want to give it) [Mon Jul 28 11:18:26 2014] hi [Mon Jul 28 11:19:11 2014] Anybody get "argument too big" when installing coq library ? [Mon Jul 28 12:29:10 2014] I don't understand how does Coq type check and it's really annoying. I have a constructor `Cons : forall n, A -> ilist n -> ilist (S n)` in a section with `Variable A : Set.` and I can apply that constructor 2, 3, 4 or even 5 arguments. I tried hard to fix it(I removed all implicit argument declaration) but now the closest I could get was `The 1st term has type "Type" which should be coercible to "Set".` which is super frustrating. [Mon Jul 28 12:33:27 2014] osa1 is it due to implicit arguments ? [Mon Jul 28 12:33:57 2014] I assume not because I removed implicit arguments commands. unless it's somehow active by default. [Mon Jul 28 12:38:52 2014] what is your ilist definition ? [Mon Jul 28 12:40:05 2014] Anarchos: http://lpaste.net/108294 whole code, just evaluate/compile it and you should see [Mon Jul 28 12:41:59 2014] ha! I found same error demonstrated in here http://adam.chlipala.net/cpdt/html/Universes.html [Mon Jul 28 12:42:04 2014] osa1 i can't evaluate it (broken install here) [Mon Jul 28 12:42:41 2014] Anarchos: error is given while evaluating last definition (imap) [Mon Jul 28 12:43:51 2014] osa1 did you try  Set Printing All. ? [Mon Jul 28 12:44:06 2014] no [Mon Jul 28 12:44:23 2014] I can't use that "Error: Use CoqIDE display menu instead" [Mon Jul 28 12:44:30 2014] ... [Mon Jul 28 12:45:09 2014] That just means there’s an option for it in CoqIDE. [Mon Jul 28 12:45:14 2014] it should. [Mon Jul 28 12:45:26 2014] alkabetz: really? well guess what, I'm not using CoqIDE [Mon Jul 28 12:45:39 2014] I'm using a vim plugin which runs coq using -ideslave [Mon Jul 28 12:45:56 2014] coq is so smart it assumes I'm using CoqIDE if I use -ideslave since it has to be the only coq ide [Mon Jul 28 12:46:22 2014] Ugh. :( [Mon Jul 28 12:48:01 2014] I'll try replacing Sets with Types [Mon Jul 28 13:09:11 2014] hi. may i ask a question related to formal verification in general (as opposed to coq in particular)? if not, please direct me to a place where this is appropriate. [Mon Jul 28 13:11:43 2014] don't ask to ask [Mon Jul 28 13:12:21 2014] normally i don't, but when it's not on-topic, there's always someone who gets on your case :) [Mon Jul 28 13:12:31 2014] you may get answers here, or someone may redirect you to a more appropriate place, but that is easier to do knowing the question [Mon Jul 28 13:14:27 2014] ok, so the question is this: i'm new to both functional programming and to formal verification. however, as far as i understand, the point of formal verification is to come up with a mathematical formulation that is self-evidently taken as correct and then prove some imperative code is equivalent to it. functional code, on the other hand, seems to be that mathematical formulation so why not write functional code instead and skip all t [Mon Jul 28 13:15:34 2014] (your message seem to have hit the length limit and stopped at "instead and skip all t") [Mon Jul 28 13:16:00 2014] ...all the intermediary steps? [Mon Jul 28 13:16:04 2014] sorry about that. [Mon Jul 28 13:17:45 2014] don't worry about it [Mon Jul 28 13:18:21 2014] there seem to be a couple of misunderstanding somewhere [Mon Jul 28 13:18:51 2014] i'm not surprised :) [Mon Jul 28 13:21:41 2014] could you elaborate on what those might be? [Mon Jul 28 13:21:57 2014] i'm willing to do the research but i'd like to know where to start [Mon Jul 28 13:21:57 2014] sorry i had to take a call, i'm back [Mon Jul 28 13:22:07 2014] it's alright, no need to apologize [Mon Jul 28 13:23:36 2014] so basically formal verification means building a mathematical model of your code (that may be imperative, functional, or hardware circuits…) and proving properties about this model [Mon Jul 28 13:24:37 2014] the only thing you sake as self-evidently correct is that the model you are building has the same semantics (meaning) as the program/algorithm you are considering [Mon Jul 28 13:25:39 2014] sure but that's kind of an ambiguous statement. when you write any piece of code, the assumption that you make is that it does what you want it to :) [Mon Jul 28 13:25:51 2014] but i know what you mean [Mon Jul 28 13:26:00 2014] functional programming on the other hand does not really concern itself about mathematics (although there are links) [Mon Jul 28 13:26:52 2014] so the thing is, you may be writing really complex code that does complex stuff efficiently [Mon Jul 28 13:27:34 2014] (in reply to your remark) [Mon Jul 28 13:28:06 2014] and the inner working of this program may be really complex [Mon Jul 28 13:29:18 2014] but you want to prove that is satisfy a simple specification — and for that what you need is a system that can a) express your specification and b) reason about your code [Mon Jul 28 13:29:55 2014] you may very well just take a formal system that understands the language your code is written in and directly reason about it [Mon Jul 28 13:30:37 2014] and the only thing that can't be checked is that the semantics of the language understood by your formal system actually corresponds to what your compiler is doing or whatever [Mon Jul 28 13:31:04 2014] but I digress [Mon Jul 28 13:31:23 2014] back to functional programming [Mon Jul 28 13:31:42 2014] the notion is a bit fuzzy [Mon Jul 28 13:33:11 2014] the main idea is that it means your functions are first-class objects of your language — you can take them as arguments and pass them around [Mon Jul 28 13:34:51 2014] indeed [Mon Jul 28 13:34:53 2014] it is often associated to others ideas, amongst them the idea of immutability - once you have a value, you can't change it, and this has the benefit that once you have a value, there is not another piece of code that is going to change it [Mon Jul 28 13:35:04 2014] so people actually prove functional code too, i take it [Mon Jul 28 13:35:27 2014] which is why it is "math-like", because it shares characteristics with mathematical objects [Mon Jul 28 13:35:37 2014] yes, i thought immutability was a key feature of functional programming [Mon Jul 28 13:36:31 2014] it is usually easier to prove things about functional code because of this immutability [Mon Jul 28 13:37:13 2014] because it means that you don't have to analyze the set of objets that can be modified each time you do an operation — if you proved something about a value, that property is never going to change [Mon Jul 28 13:37:17 2014] right, because it is a guarantee that your therems don't break [Mon Jul 28 13:37:30 2014] yes [Mon Jul 28 13:38:06 2014] so for instance coq is both a formal verification system and a functional programming language (although you should probably not expect good performances out of it, that is not really the point) [Mon Jul 28 13:39:10 2014] which allows you to express and prove mathematical properties about code written in its language [Mon Jul 28 13:39:57 2014] but it is also complete enough that you can define the semantics of other languages in it, and prove properties about programs written in other languages [Mon Jul 28 13:40:58 2014] i should definitely try it out :) [Mon Jul 28 13:41:47 2014] a SMT solver on the other hand is an automated formal verification system that is (usually) not a functional language that allows you to express models and properties about them, and have powerful algorithms try to prove them for you [Mon Jul 28 13:42:32 2014] an languages like OCaml, Haskell, or scheme are functional programming languages but aren't expressive enough to express and prove complex properties about their programs [Mon Jul 28 13:43:35 2014] i presume smt's aren't particularly useful for big problems (because of the whole p vs np problem) [Mon Jul 28 13:44:21 2014] if you want to read more about coq i would suggest the Software Foundations book (http://www.cis.upenn.edu/~bcpierce/sf/ ) [Mon Jul 28 13:45:12 2014] so it is not really that smts are not useful for big problems [Mon Jul 28 13:45:15 2014] is it accessible with someone who has no background in formal verification? [Mon Jul 28 13:45:19 2014] it's more that they are not useful for complex problems [Mon Jul 28 13:45:53 2014] it should, yes [Mon Jul 28 13:46:12 2014] * downloads [Mon Jul 28 13:46:15 2014] but you should at least read the introduction anyway [Mon Jul 28 13:46:54 2014] it expands a bit on what i said [Mon Jul 28 13:48:05 2014] he seems to have given a series of lectures on software foundtions in coq, too [Mon Jul 28 13:48:08 2014] so the thing about SMTs is, they are usually extremely efficient as long as the problem you throw at them does not involve induction or too much quantifiers [Mon Jul 28 13:48:13 2014] i'll use that to accompany this material [Mon Jul 28 13:48:30 2014] and when they fail you are on your own [Mon Jul 28 13:49:30 2014] i understand what the computational limitations are. i do know some computer science :) [Mon Jul 28 13:49:35 2014] there is work to adapt SMTs into proof assistants (see for instance http://www.lix.polytechnique.fr/~keller/Recherche/smtcoq.html ) and be able to send them your formulae once you simplified them enough that they can handle it [Mon Jul 28 13:50:13 2014] ooh [Mon Jul 28 13:50:15 2014] nice [Mon Jul 28 13:52:34 2014] what a coincidence that i was studying sat solvers the past few weeks [Mon Jul 28 13:53:18 2014] i hadn't heard the term "smt" before but i understand what they are [Mon Jul 28 13:54:14 2014] smt stands for satisfiability modulo theory ; it's basically more powerful sat solvers that "know" about arithmetic or other mathematical theories [Mon Jul 28 13:54:36 2014] (because at some points booleans are just boring) [Mon Jul 28 13:55:46 2014] yeah, i read on wikipedia what the gist is [Mon Jul 28 13:56:02 2014] cool stuff. i'll look over that book cause all this stuff seems exciting [Mon Jul 28 13:56:24 2014] do you have something precise you are trying to do? [Mon Jul 28 13:56:51 2014] no, just wanting to educate myself [Mon Jul 28 13:57:33 2014] :-) [Tue Jul 29 07:31:49 2014] is isabelle also a dependently typed PL with some helper tools(like tactics) for proving? [Tue Jul 29 07:54:06 2014] IIRC it’s not dependently typed, but it does have a tactic system. [Tue Jul 29 08:08:31 2014] so no curry-howard or similar correspondence of isabelle programs and props/proofs? or does it have a different type system? [Tue Jul 29 08:37:06 2014] does the lack of dependent typing limit how much Curry-Howard applies? [Tue Jul 29 09:01:30 2014] iirc, there is no real curry-howard correspondance in isabelle (maybe in the kernel ; but to the end-user proofs and terms / propositions and types are different beasts) [Tue Jul 29 09:26:21 2014] Hodapp: probably not but I think you still need a type system [Tue Jul 29 09:27:01 2014] so I'm reading the paper and apparently they specified a subset of C in isabelle. I'm wondering if they had a compiler from that definition too. [Tue Jul 29 09:27:11 2014] had a compile for that definition too* [Tue Jul 29 12:22:48 2014] elarnon: what does a language itself do to support Curry-Howard Correspondence? [Tue Jul 29 12:24:03 2014] the only language of this sort that I've worked with is Coq, really [Tue Jul 29 12:28:20 2014] Hodapp: Curry-Howard is a syntactic thing. It's probably not what want. Say you have a linear arithmetic solver in your typechecker to relieve you from mundane arithmetical manipulation. You would then need a syntactic form, like "using linarith, e" [Tue Jul 29 12:31:31 2014] ianjneu: I guess my take after reading a little is that it looked more like a way of interpreting things than a syntactic thing, but I'm not very familiar (as you've probably guessed from my derpy questions here). [Tue Jul 29 13:08:57 2014] Hodapp: my formulation was a bit confusing, sorry — what I meant was that iirc in Isabelle there are distinct mechanisms for programs/types and formulae/proofs, so that (unlike e.g. Coq) it doesn't really apply the ideas in the correspondance [Tue Jul 29 13:10:47 2014] of course you can always apply the correspondance to a logic system and get a typing system and conversely, the correspondance is just the insight that these are the same anyway, merely looked at through different glasses [Tue Jul 29 14:24:38 2014] elarnon: well, that's why I asked - what does a language itself do to support it? [Tue Jul 29 14:25:24 2014] elarnon: or are you saying that what it provides is not particularly useful when viewed that way, compared to (for instance) Coq? [Tue Jul 29 14:25:24 2014] there is no difference between proofs/programs and propositions/types in coq [Tue Jul 29 14:26:23 2014] i mean they really are the same thing, everything you can do with types inside coq you can do with a proposition [Tue Jul 29 14:26:33 2014] that is, afaik, not the case in Isabelle [Tue Jul 29 14:26:45 2014] ahhh, okay [Tue Jul 29 14:28:38 2014] (well you probably can but that's two different mechanism — afai the exact tactic wouldn't make much sense in Isabelle for instance) [Tue Jul 29 14:30:11 2014] so any sort of translation between the two would have to be done manually? [Tue Jul 29 14:30:37 2014] again, that's as far as user interaction is concerned ­ Isabelle is a LCF system so the kernel is probably using propositions as types [Tue Jul 29 14:31:36 2014] hmmmm [Tue Jul 29 14:33:13 2014] from what I understand Isabelle's programs are sort of written in some DSL embedded in Isabelle [Tue Jul 29 14:42:17 2014] hi elarnon! bon jour [Tue Jul 29 14:56:20 2014] hi johnw ! [Tue Jul 29 14:56:25 2014] how are you doing? [Tue Jul 29 14:56:31 2014] I'm good, you? [Tue Jul 29 14:56:39 2014] (crap, i'm getting confused with spaces before punctuation again) [Tue Jul 29 14:57:11 2014] I'm having a little bit of trouble writing my internship report, but I'm good otherwise [Tue Jul 29 14:57:17 2014] will you be at ICFP? [Tue Jul 29 14:58:02 2014] I don't think I'll be at any conference in the next year [Tue Jul 29 14:59:17 2014] it will depend how things go, but if things are going well I should be doing industry internships the whole year [Tue Jul 29 15:02:53 2014] aw, we'll miss you then [Tue Jul 29 15:03:06 2014] I may visit france during the two weeks after ICFP though [Tue Jul 29 15:03:36 2014] my father bought a property I think in Bordeaux? We may drive down to visit it [Tue Jul 29 15:26:04 2014] what's LCF? [Tue Jul 29 15:27:19 2014] how do i prove transitivity of a definition like this? Do i need to use induction? And if so, how? [Tue Jul 29 15:27:20 2014] https://privatepaste.com/310fa9ad06 [Tue Jul 29 15:29:53 2014] I believe you'd use induction on L1 [Tue Jul 29 15:30:07 2014] and you may need to generalize your dependents L2 and L3 [Tue Jul 29 15:31:25 2014] hm [Tue Jul 29 15:31:38 2014] what do you mean by that :p [Tue Jul 29 15:32:21 2014] alright so after doing induction L1, ive got https://privatepaste.com/c92c15ebb8 [Tue Jul 29 18:29:43 2014] Does anyone here work with Coq & Vim ? Just trying ot use the coquille plugin and it's a bit interesting [Tue Jul 29 18:37:30 2014] mankyKitty: I'm using vim [Tue Jul 29 18:38:00 2014] mankyKitty: I had some problems with coquille. there's a Coq plugin in vim.org, I use a modified version of it and it works great. [Tue Jul 29 18:38:15 2014] osa1: awesome cheers [Tue Jul 29 18:38:23 2014] what did you have to modify? [Tue Jul 29 18:38:37 2014] mankyKitty: it's coming with hard-coded colors so you have to modify that parts for your color scheme [Tue Jul 29 18:38:49 2014] mankyKitty: see my vim setup at github.com/osa1/rcbackup [Tue Jul 29 18:38:55 2014] ahhh okay. [Tue Jul 29 18:39:21 2014] that's not a huge drama then :) [Tue Jul 29 18:39:31 2014] right [Tue Jul 29 18:40:04 2014] thanks for that. :) [Tue Jul 29 18:40:09 2014] mankyKitty: there's also another problem but that's all [Tue Jul 29 18:40:40 2014] mankyKitty: you can't enable some Coq settings because Coq thinks you're using CoqIDE and says "use CoqIDE menu to do that". [Tue Jul 29 18:40:46 2014] other than that it works great. [Tue Jul 29 18:40:50 2014] haha [Tue Jul 29 18:40:52 2014] nifty [Tue Jul 29 18:41:07 2014] I'm not really doing anything creepy so it should be fine [Wed Jul 30 03:06:45 2014] how do i prove transitivity on a relation on lists? (eg. sublist) [Wed Jul 30 03:07:15 2014] forall K L M, sublist K L -> sublist L M -> sublist K M [Wed Jul 30 03:07:44 2014] where to apply induction? What variable to introduce first? Im trying different things but somehow keep running into walls [Wed Jul 30 04:26:57 2014] should it be difficult to prove transitivity? [Wed Jul 30 04:27:05 2014] i dont get why im stuck on this for hours lol [Wed Jul 30 04:36:53 2014] How is sublist defined? [Wed Jul 30 04:37:59 2014] I guess you could start by proving forall K L, sublist K L <-> exists K1 K2, K1 ++ K ++ K2 = L, from which you result would follow directly [Wed Jul 30 04:39:24 2014] as such: https://privatepaste.com/eb9a5845f6 [Wed Jul 30 04:42:01 2014] Ohh, I see. Not the kind of sublist I thought :) [Wed Jul 30 04:43:10 2014] This is kind of ordered multi-set inclusion [Wed Jul 30 04:45:42 2014] It doesn't work by induction on derivations? [Wed Jul 30 04:49:44 2014] whats that? [Wed Jul 30 04:51:18 2014] Induction on the structure of the proof of `sublist K L', instead of one of K or L [Wed Jul 30 04:51:46 2014] that sounds interesting [Wed Jul 30 04:51:49 2014] how do i do that [Wed Jul 30 04:53:02 2014] Wait, actually, I don't think that applies here. But otherwise you could do something like `intros K L M SP. induction SP.' [Wed Jul 30 04:53:37 2014] wow thats weird [Wed Jul 30 04:53:45 2014] it doesnt apply here? [Wed Jul 30 04:54:23 2014] ohh wait [Wed Jul 30 04:54:34 2014] think its starting to dawn on me [Wed Jul 30 04:54:36 2014] No, I don't think it's going to help you, since the second argument is decreasing anyway [Wed Jul 30 04:54:41 2014] hm but youre saying thats not useful? [Wed Jul 30 04:55:01 2014] I think, however, that you might get somewhere by generalizing the first two lists and doing induction over M. [Wed Jul 30 04:55:41 2014] hm could you clarify that perhaps? [Wed Jul 30 04:55:53 2014] so lets say we have [Wed Jul 30 04:55:59 2014] Lemma sublist_trans : forall K M L, sublist K L -> sublist L M -> sublist K M. [Wed Jul 30 04:56:29 2014] So: intros K L M. generalize K L. clear K L. induction M. [Wed Jul 30 04:57:31 2014] https://privatepaste.com/737fe58def [Wed Jul 30 04:57:41 2014] ok, ive been at that point [Wed Jul 30 04:57:45 2014] but how to proceed from there? [Wed Jul 30 05:00:11 2014] The first goal can be solved by using inversion on H, from which you learn that K=nil. Then you can proceed by induction on L, (or, prove in a different lemma that forall L, sublist nil L). [Wed Jul 30 05:01:22 2014] ok thats a good idea, ill prove that in an auxiliary lemma [Wed Jul 30 05:01:56 2014] https://privatepaste.com/29715fdcf5 [Wed Jul 30 05:02:21 2014] no wait [Wed Jul 30 05:02:32 2014] https://privatepaste.com/52e44ee2f4 [Wed Jul 30 05:02:57 2014] hm [Wed Jul 30 05:03:06 2014] so first induction on M, then on L, and then on K right? [Wed Jul 30 05:04:32 2014] Okay, I just went through the proof in coq, and it actually suffices to do only a single induction over M. [Wed Jul 30 05:05:16 2014] thats it? [Wed Jul 30 05:05:31 2014] but how do you do the rest then? [Wed Jul 30 05:05:49 2014] So, let's go though it, the goals that you pasted look right. [Wed Jul 30 05:06:58 2014] Oh, wait, it seems like you ended up doing induction on the middle list instead of the last. Can you paste your lemma and the proof script up until now? [Wed Jul 30 05:08:42 2014] sure [Wed Jul 30 05:08:47 2014] https://privatepaste.com/eb728d803f [Wed Jul 30 05:09:20 2014] ah, yes. In your first line, you actually rename your variables. [Wed Jul 30 05:09:56 2014] When you write "intros K L M", it does not change the order that the variables are introduced, you just assign them new names. So, this renames M to L, and L to M :) [Wed Jul 30 05:10:04 2014] oh haha [Wed Jul 30 05:10:08 2014] i didnt mean to [Wed Jul 30 05:11:10 2014] It probably makes most sense to reorder the variables in the statement of the lemma, so they come in alphabetical order ;) [Wed Jul 30 05:12:11 2014] Anyways, after that, you only need `intros K L M. generalize K L. clear K L. induction M.', and after that, everything should go through by using inversion and applying the induction hypothesis and the sublist_cons rules. [Wed Jul 30 05:12:53 2014] I can send you my proof script if you want to :) [Wed Jul 30 05:15:11 2014] yes please [Wed Jul 30 05:15:18 2014] Here you go: http://privatepaste.com/5deffa9eb2 [Wed Jul 30 05:15:37 2014] right now my head is still spinning from a thousand and one brute force attempts :p [Wed Jul 30 05:15:37 2014] It's a little messy, but you should be able to step through it and get the idea [Wed Jul 30 05:16:03 2014] awesome :) gonna have a closer look at that [Wed Jul 30 05:16:06 2014] Haha, yes, I know the feeling :). [Wed Jul 30 05:16:55 2014] thanks a million :) brb [Wed Jul 30 05:17:10 2014] You're welcome :) [Wed Jul 30 09:57:52 2014] how hard is it to write and prove a custom induction lemma? [Wed Jul 30 10:06:03 2014] maybe this induction lemma already exists? [Wed Jul 30 10:06:24 2014] https://privatepaste.com/9e6d7ca0f3 [Wed Jul 30 10:09:36 2014] its based on well-founded induction i guess [Wed Jul 30 10:15:57 2014] nm got it :) pretty simple [Wed Jul 30 13:50:48 2014] "A compiling option of Coq allows to type-check theories in this extended system." what does this extended system provide? (from http://coq.inria.fr/refman/Reference-Manual006.html) [Wed Jul 30 13:56:40 2014] I'm having trouble finding info about sections in the documentation [Wed Jul 30 13:57:48 2014] it provides impredicativity of Set [Wed Jul 30 13:58:38 2014] is Coq predicative absent that? [Wed Jul 30 13:58:58 2014] Modulo bugs in Coq, yes. [Wed Jul 30 14:00:48 2014] Okay. I was reading about Calculus of Constructions, and constructive type theory, last night and confusing myself a bit. [Wed Jul 30 14:05:28 2014] Ptival: does that mean I can have `Inductive ty : Set -> Set` ? [Wed Jul 30 14:06:44 2014] Ptival: does that lead to inconsistencies? if not, why not enable it by default? [Wed Jul 30 14:07:30 2014] Impredicativity does lead to inconsistencies. [Wed Jul 30 14:07:46 2014] alkabetz like russel's paradox ? [Wed Jul 30 14:07:51 2014] Exactly. [Wed Jul 30 14:12:04 2014] Although now that I look more into this, I see this in CPDT: ‘… [Prop] is impredicative…. The impredicativity of [Prop] interacts crucially with the elimination restriction to avoid those pitfalls.’ [Wed Jul 30 14:12:51 2014] alkabetz: which page? [Wed Jul 30 14:13:40 2014] Not sure; my copy’s not in front of me. It’s in http://adam.chlipala.net/cpdt/html/Universes.html. [Wed Jul 30 14:13:40 2014] chapter 12 I guess [Wed Jul 30 14:50:42 2014]
Hi. Anyone read "Certified programming and dependent types" and "Software fundations" ? [Wed Jul 30 14:51:00 2014] I’ve read some of each. [Wed Jul 30 14:51:20 2014] I'm reading the latter. [Wed Jul 30 14:54:48 2014]
alkabetz: great. Could you compare them? I am a SC & maths student and I am wondering which would be better for me to read? The main reason why I want to know Coq is to prove programs but from the introduction to Cpdt I have a feeling that it is less precise (a library is used for proof automation from the begininng instead of manual proofs) [Wed Jul 30 14:57:09 2014] Full disclosure: The author of CPDT is my advisor. :) [Wed Jul 30 14:57:44 2014] But that said, I agree with the widespread advice that you should start with Software Foundations, and then switch to CPDT when you get bored. [Wed Jul 30 14:58:36 2014]
alkabetz: ok, thanks [Wed Jul 30 14:58:49 2014] If you want to deal with large proof developments, you need the style of automation integrated throughout CPDT. But for just starting out, I think learning to do proofs manually is valuable. [Wed Jul 30 14:59:01 2014] (Heck, learning to write proof terms is valuable until you get sick of it.) [Wed Jul 30 15:03:54 2014] alkabetz i tried to learn write proof, but i go fast to use "intro, induction auto elim" only :/ [Wed Jul 30 15:04:21 2014] Impredicativity does lead to inconsistencies. [Wed Jul 30 15:04:39 2014] I don't think that is true, what do you mean by "Impredicativity"? [Wed Jul 30 15:05:13 2014] System F is usually considered impredicative, for example [Wed Jul 30 15:05:23 2014] vanila: Yes, and it's inconsistent with classical axioms [Wed Jul 30 15:05:38 2014] well, System F is not strong enough to be that interesting, I guess [Wed Jul 30 15:05:45 2014] Coq used to be impredicative by default [Wed Jul 30 15:09:46 2014] if you have impredicativity for large types then you are even inconsistent with and sigma types [Wed Jul 30 15:19:17 2014] Coq has -impredicative-set, I doubt they would provide that if it was contradictory [Wed Jul 30 15:37:21 2014] vanila: -impredicative-set lets you break the consistency of Coq, which is why it’s a flag you have to turn on as opposed to the default. [Wed Jul 30 15:41:03 2014] How is that done? [Wed Jul 30 15:41:44 2014] I think you need extra axioms like excluded middle, for it to cause contradiction [Wed Jul 30 15:44:21 2014] IIRC you would lose only with impredicativity, but I’ve never actually constructed a proof of False from an impredicative Coq. Somebody else can probably give a more complete/satisfying answer. :/ [Wed Jul 30 15:44:40 2014] vanila: http://okmij.org/ftp/Haskell/impredicativity-bites.html [Wed Jul 30 15:44:52 2014] ianjneu, I don't think that's relevant? [Wed Jul 30 16:00:16 2014] "Set has been made predicative from version 8.0 of Coq. The main reason is to interact smoothly with a classical mathematical world where both excluded-middle and the axiom of description are valid" [Wed Jul 30 16:03:07 2014] Hmm, I thought it had something to do with injective constructors too. Guess that's wrong. [Wed Jul 30 16:04:30 2014] ianjneu: it [Wed Jul 30 16:04:34 2014] also does [Wed Jul 30 16:04:36 2014] cf. [Wed Jul 30 16:05:20 2014] http://coq.inria.fr/faq?som=5#htoc48 [Wed Jul 30 16:05:44 2014] Ptival: is Girard's proof that Impredicative MLTT in his dissertation related? [Wed Jul 30 16:05:53 2014] ah "The question remains open whether injectivity is consistent on some large inductive types not expressive enough to encode known paradoxes (such as type I above)." [Wed Jul 30 16:05:55 2014] idk [Wed Jul 30 16:06:03 2014] so it's an open problem [Wed Jul 30 16:06:05 2014] impredicative MLTT is inconsistent* [Wed Jul 30 17:17:29 2014] "Matthieu Sozeau has started the discussion on Haskell Cafe on January 27, 2010, describing the divergence in the type checker encountered while encoding a recently found Coq paradox in Haskell" where can I learn more about this paradox? was that an implementation related bug or a problem in theory? (maybe in cic or whatever) [Wed Jul 30 20:25:10 2014] How do I get the emacs mode to put me into hybrid 3 window mode? [Wed Jul 30 20:25:20 2014] I mean, it works when I select that from the menu [Wed Jul 30 20:25:39 2014] but when I close and reopen im back in 'smart' [Wed Jul 30 20:38:53 2014] vanila: there is an option in the emacs menu I believe to switch to 3 buffer mode [Wed Jul 30 20:39:02 2014] I think [Wed Jul 30 20:39:08 2014] I selected that, then saved my preferences - but when I reopen im back to smart mode [Wed Jul 30 20:40:49 2014] oohh right, yeah that's a different collection of settings.. something about remembering buffer configs and restoring on open.. I've not used them though so I'm not much help. Sorry :) [Wed Jul 30 20:49:51 2014] is there a way to make a section variable implicit outside of the section? [Wed Jul 30 20:55:11 2014] uh... Error: Impossible to unify "?20" with "?20". [Wed Jul 30 22:28:21 2014] i've run into a situation where "inversion" appears to construct an existT out of nowhere (http://lpaste.net/108469). any ideas as to what's going on -- what terms or concepts should i read about / google for? [Wed Jul 30 23:53:49 2014] why (if eq_nat_dec x x then true else false) does not reduce/simplify to true? [Wed Jul 30 23:56:50 2014] tautologico: what is eq_nat_dec? [Wed Jul 30 23:57:12 2014] tautologico: and how did you define your booleans? [Wed Jul 30 23:58:07 2014] standard booleans [Wed Jul 30 23:58:16 2014] it doesn't matter, actually [Wed Jul 30 23:58:36 2014] (if eq_nat_dec x x then A else B) should be A [Thu Jul 31 00:00:06 2014] I'm doing something wrong, maybe I should be using ListSet or eq_nat_dec there [Thu Jul 31 00:12:47 2014] tautologico: if x isn't concrete, then that won't reduce by computation, you need to use the fact that eq_nat_dec is reflexive [Thu Jul 31 00:14:01 2014] I tried to look for a reflexive property for it but couldn't find it [Thu Jul 31 00:23:57 2014] I can get it to work using destruct, but it's not pretty [Thu Jul 31 00:35:37 2014] I think ListSet may not be a good option for (computational) sets [Thu Jul 31 04:10:57 2014] Would anyone be able to help me with a recursive function im trying to define? [Thu Jul 31 04:11:38 2014] http://pastebin.com/hQYyY078 I just added the Askipif case, and the compiler seems to go into an infinite loop [Thu Jul 31 04:16:48 2014] oh actually i have to fix something else first, then i'll try this again [Thu Jul 31 05:29:46 2014] How do I register a new equality relation? [Thu Jul 31 10:27:25 2014] I'm trying to prove a simpler compiler correct but the type dependency keeps causing problems (like blocking rewrite) [Thu Jul 31 10:27:43 2014] what should I read to learn to fix this? I've already been reading coq'art and cpdt [Thu Jul 31 10:28:55 2014] vanila: docs for ssreflect [Thu Jul 31 10:29:13 2014] great, thanks [Thu Jul 31 10:37:27 2014] ooc, what're the limitations with regards to what is provable in coq? [Thu Jul 31 10:39:45 2014] shergill: that's a really open-ended question. What exactly are you looking for in an answer? [Thu Jul 31 10:42:03 2014] ianjneu what is ssreflect ? [Thu Jul 31 10:42:54 2014] ianjneu: well i'm aware that certain constraints that coq imposes (such as strict positivity) are more constraining than what is strictly required. i am curious what impact that has on the space of things which can be proven (or perhaps the space of techniques which you have at your disposal to construct a proof with) [Thu Jul 31 10:45:13 2014] Anarchos: a tactic language developed by Gonthier et al. It does more conversions for rewriting, so you don't get stuck simpl'ing and unfolding, etc. [Thu Jul 31 10:45:25 2014] Of course there's a lot more to it than that. [Thu Jul 31 10:47:39 2014] shergill: The problem of higher-order termination does not have a satisfying solution for modular termination proofs, so you end up having to have concrete representations of your datatypes available if you want to use higher-order functions recursively. I think that's a major roadblock that no one has solved. [Thu Jul 31 10:48:19 2014] By [Thu Jul 31 10:50:44 2014] My go-to example is trying to use an abstract finite function type family to define a closure datatype, i.e. Closure := closure : LambdaTerm -> FiniteFunction Name Closure -> Closure. [Thu Jul 31 10:52:00 2014] HoTT researchers are looking for more "semantic" criteria for defining inductive datatypes, but I don't know what the status of that search is. [Thu Jul 31 11:00:19 2014] I skimmed through the ssreflect manual and I don't really see how this could help me [Thu Jul 31 11:24:35 2014] vanila: what do you mean by blocking rewrite then? [Thu Jul 31 11:30:00 2014] it cant generalize the goals to apply eq_rect because of dependent indices [Thu Jul 31 11:32:27 2014] do you have a small example? [Thu Jul 31 11:33:17 2014] it's not very small - I could post a summary along with the whole code [Thu Jul 31 11:33:33 2014] you likely have to transport your equalities through the indices. Heterogeneous equality is a hack that HoTT addresses. [Thu Jul 31 11:34:17 2014] this sounds a lot harder than I think i can manage :( [Thu Jul 31 11:35:05 2014] my file is 334 lines [Thu Jul 31 11:35:10 2014] paste it. [Thu Jul 31 11:35:16 2014] I'll take a stab at it [Thu Jul 31 11:36:44 2014] ok thanks! [Thu Jul 31 11:36:48 2014] http://pastebin.com/wRfR8tuh [Thu Jul 31 11:36:48 2014] s [Thu Jul 31 11:36:49 2014] so [Thu Jul 31 11:37:26 2014] I define E with tagless interpreter, then line 40 to 120 is some weird hacking that I was desperately trying - can ignore this [Thu Jul 31 11:37:49 2014] then I defined stack based "assembly instructions" A with an interpreter [Thu Jul 31 11:38:10 2014] then the compiler that I want to prove preserves meaning [Thu Jul 31 11:38:45 2014] and then etype_eq_list expresses that true booleans get compiled to any number other than zero, false booleans are 0 [Thu Jul 31 11:40:51 2014] then in the proof at line 308 I can't progress because I have "etype_of e2" that I can't rewrite - because of the type dependency problem [Thu Jul 31 11:41:33 2014] I guess that I basically need to find a completely different way to do this: I tried using a tagged interpreter and the maybe monad - but then I can't even get this far in the proof because all the monad binds block applying induction hyps [Thu Jul 31 11:41:57 2014] but any kind of nudge in an interesting direction would be helpful [Thu Jul 31 11:57:15 2014] vanila what kind of compiler ? [Thu Jul 31 11:57:22 2014] vanila did you look at compcert sources ? [Thu Jul 31 11:57:34 2014] just simple arithmetic and boolean expressions with if [Thu Jul 31 11:57:58 2014] im googling about for papers/slides that might help [Thu Jul 31 12:06:41 2014] baby is hindering... [Thu Jul 31 12:07:54 2014] the high level is that you need to generalize by the type and use match's return to match on the type and give unit in the impossible cases. [Thu Jul 31 12:08:19 2014] ah [Thu Jul 31 12:08:46 2014] neat, I think that might work [Thu Jul 31 12:09:34 2014] Agda's sugar for this pattern is the absurd form. lambda() [Thu Jul 31 12:50:24 2014] vanila: how goes? [Thu Jul 31 12:50:36 2014] good, thanks for the idea! [Thu Jul 31 13:20:08 2014] hi, bloody-stupid question to ask here. [Thu Jul 31 13:20:51 2014] I've defined two mutual inductives in Type (inductively-defined data-types) and also defined a mutually-inductive predicate (inductive Prop) over them. [Thu Jul 31 13:21:07 2014] Now I want to prove properties of the inductive Prop, such as its reflexive property. [Thu Jul 31 13:21:20 2014] the mutual induction schemes I've read about how to create seem to help for later theorems, but not for this. [Thu Jul 31 13:21:25 2014] what can I do here? [Thu Jul 31 13:45:42 2014] esennesh: are you stating reflexivity properties for both types and trying to prove them at the same time? [Thu Jul 31 13:46:34 2014] You'll want to have a scheme that takes a "tag" for which type you're talking about, and state your theorem wrt a given tag. [Thu Jul 31 13:55:38 2014] ok, though I actually figured out how to just write down the predicate I wanted as a function returning bool and prove the appropriate properties over it. [Thu Jul 31 13:55:41 2014] Thanks! [Thu Jul 31 14:25:54 2014] hello [Thu Jul 31 14:28:51 2014] http://lpaste.net/6060138596264837120 during simplification Coq gave me weird result - what sense does "(rev n)" make since n is a nat, it doesn't typecheck in my head [Thu Jul 31 14:29:56 2014] Ainieco: look at the context, n is a natlist. [Thu Jul 31 14:30:09 2014] l1' is a nat [Thu Jul 31 14:30:15 2014] strangely named, I agree [Thu Jul 31 14:30:26 2014] ugh, i flipped it accidentally [Thu Jul 31 14:30:28 2014] sorry [Thu Jul 31 14:30:49 2014] no worries :) [Thu Jul 31 14:43:18 2014] is there a good general reference forsyntax? [Thu Jul 31 14:43:55 2014] working through some stuff in the HoTT book and it's confusing trying to figure out where to put foralls and stuff [Thu Jul 31 14:44:47 2014] Elision: you mean other than the Coq reference manual? [Thu Jul 31 14:44:48 2014] Elision: http://coq.inria.fr/distrib/current/refman/ [Thu Jul 31 14:46:10 2014] aha [Thu Jul 31 14:46:22 2014] I'd only ever found tutorials that skip over stuff I really want to know [Thu Jul 31 14:46:23 2014] thanks [Thu Jul 31 14:46:39 2014] Elision: what kind of stuff do you really want to know? [Thu Jul 31 14:48:11 2014] Elision there is coq code in the HoTT book ?? [Thu Jul 31 14:48:13 2014] stuff about types :p [Thu Jul 31 14:48:34 2014] Anarchos: no, I'm trying to implement some of the stuff in the first chapter in coq right now [Thu Jul 31 14:48:53 2014] see if I can verifiably prove my solutions to the exercises :p [Thu Jul 31 14:50:01 2014] they do mention it at times, and I know there's a library/plugin/whatever to coq for working specifically on it, though [Thu Jul 31 14:50:57 2014] Elision: see also https://github.com/HoTT/HoTT/tree/master/coq/theories [Thu Jul 31 14:51:28 2014] yeah that's what I was talking about [Thu Jul 31 14:51:44 2014] gonna be adding to that in the fall, hopefully, in a research course [Thu Jul 31 14:51:52 2014] nice! [Thu Jul 31 14:52:20 2014] but I want to start from scratch right now to make sure I really understand the fundamentals [Thu Jul 31 14:54:18 2014] if you can understand the fundamentals of HoTT, I say more power to you :) [Thu Jul 31 14:54:53 2014] :p [Thu Jul 31 14:57:08 2014] Elision: Until recently you needed the fork of Coq at https://github.com/HoTT/coq to use the HoTT library. I _think_ that those changes are now on Coq master so if you build current master the HoTT library will work with that too? I'm not sure. [Thu Jul 31 14:57:57 2014] What's coming in 8.5? [Thu Jul 31 14:58:00 2014] I read something like that... I'm sure my advisor knows how to get it all set up if I have any trouble, since he suggested the project [Thu Jul 31 14:58:14 2014] I started with 8.4, and already use several features that I didn't realize never existed previously [Thu Jul 31 15:02:50 2014] does anyone really use anything other than coqide and the emacs bindings? [Thu Jul 31 15:04:56 2014] ystael: like which changes? [Thu Jul 31 15:06:55 2014] Elision: I use vim plugin [Thu Jul 31 15:08:11 2014] Ainieco: I don't know exactly what the issues were -- I believe the biggest one had something to do with universe polymorphism? [Thu Jul 31 15:08:29 2014] I mostly used Agda rather than Coq for HoTT hacking so I don't know the details [Thu Jul 31 15:09:41 2014] osa1: ooh! it works well, then? [Thu Jul 31 15:09:57 2014] Elision: it works very well except for one problem. [Thu Jul 31 15:10:31 2014] how different is the experience doing it in Agda? [Thu Jul 31 15:10:32 2014] Elision: you can't use some commands that coqide allows you to use [Thu Jul 31 15:10:40 2014] oh :| [Thu Jul 31 15:10:58 2014] this is, uh, coquille? or something? [Thu Jul 31 15:11:01 2014] there are mostly commands that are useful for debugging. when I really need them I just fire coqide and try there [Thu Jul 31 15:11:25 2014] not coquille, the one listed in vim.org. you need to modify it because colors are hard-coded and won't match with your color scheme [Thu Jul 31 15:11:36 2014] ah [Thu Jul 31 15:11:38 2014] I had some problems with coquille but I don't remembe what was the problems were [Thu Jul 31 15:12:08 2014] I feel like I tried it a while ago and couldn't get it to do anything [Thu Jul 31 15:12:34 2014] interesting. I'm using it for months now. you can see my vim setup at github.com/osa1/rcbackup if you need help [Thu Jul 31 15:13:21 2014] johnw: I think the differences between working in Coq and in Agda are similar between HoTT and other things: Agda has a more flexible syntax (if you like to go nuts with Unicode math symbols, which I do) and is simpler and more regular. BUT you have to construct your terms semi-manually, whereas Coq has tactics. [Thu Jul 31 15:13:50 2014] If what you are doing is working through the HoTT book, constructing proof terms semi-manually is actually OK, becaues it helps understand what's going on. [Thu Jul 31 15:14:36 2014] (I say "semi-manually" because the Emacs mode provides some automation tools analogous to the behavior of simple Coq tactics, so you're pretty much required to use the Emacs mode.) [Thu Jul 31 15:14:41 2014] osa1: that is, I couldn't get coquille to do anything [Thu Jul 31 15:15:54 2014] johnw: Adam Chlipala says the value of tactic-based proof automation basically dominates the value of all other design choices once you get into bigger developments, so Agda is ultimately not useful. I don't have enough experience to have an opinion yet. [Thu Jul 31 15:16:19 2014] i've been trying out Adam's techniques [Thu Jul 31 15:16:20 2014] Elision: did you get an error about some Python libs? as far as I can remember I had a problem related with some Python modules but it was easy to fix. [Thu Jul 31 15:16:24 2014] it's certainly powerful stuff [Thu Jul 31 15:16:33 2014] osa1: no idea, this was in like march [Thu Jul 31 15:16:53 2014] I'll give the vim.org one a shot tonight [Thu Jul 31 15:19:34 2014] I can say that after writing some Agda code with heavy use of Unicode math symbols, I really, really miss them when going back to Coq (or any other programming language) [Thu Jul 31 15:21:15 2014] ystael: does Coq notations help for that? [Thu Jul 31 15:21:17 2014] I can see that in something like coq [Thu Jul 31 15:21:33 2014] but I'd rather not have unicode in source I have to maintain [Thu Jul 31 15:22:36 2014] Elision: My background is math, not computer science, so I am predisposed to consider the symbology worth the price [Thu Jul 31 15:23:06 2014] osa1: Yes, but it's just not as easy as Agda makes it [Thu Jul 31 15:23:20 2014] I haven't spent the time trying to get a unicode input method wired into Proof General for Coq [Thu Jul 31 15:23:40 2014] ystael: I come from both, but I consider programming from a mainly pragmatic viewpoint [Thu Jul 31 15:24:00 2014] in general, not in this specific instance [Thu Jul 31 15:33:17 2014] M-x proof-unicode-tokens-enable [Thu Jul 31 15:33:28 2014] I actually use Agda's input method in Coq files [Thu Jul 31 15:33:42 2014] C-x RET C-\, then pick Agda [Thu Jul 31 16:02:41 2014] johnw: it's that easy?! o_O [Thu Jul 31 16:02:58 2014] yeh [Thu Jul 31 18:45:11 2014] is there a tactac for unfold not. intros. inversion H.? [Thu Jul 31 19:00:58 2014] johnw : in some cases, [discriminate] [Thu Jul 31 21:35:10 2014] eegad. Is pup_to_2_ceval in Imp.v an exercise - or a penance for using imperative languages all my life? [Thu Jul 31 21:59:09 2014] http://www.cis.upenn.edu/~bcpierce/sf/current/Imp.html#lab426 - do they mean "partial function" here, as opposed to a relation that is not a function? Not as opposed to a total function? [Thu Jul 31 22:10:31 2014] Hodapp: yes. He basically says "This is good, we don't have a total function anyway. However, is it still at least a function?" [Thu Jul 31 22:10:39 2014] s/anyway/anymore/ [Thu Jul 31 22:47:55 2014] the confusion was that they phrased it as, "Is the second definition of evaluation actually a partial function? That is, is it possible that, beginning from the same state [st], we could evaluate some command [c] in different ways to reach two different output states [st'] and [st'']?" [Thu Jul 31 22:48:24 2014] asking if it is a partial function, is not the same as asking that "That is..." question [Thu Jul 31 22:48:59 2014] as the latter is asking if it's *not* a partial function [Thu Jul 31 22:49:56 2014] Ah, I see. I didn't see it as confusing, but English is not my native tongue, so maybe I wasn't mislead by the "That is..." :p [Thu Jul 31 22:51:26 2014] when you're talking about Coq "function" means "total function" [Thu Jul 31 22:52:14 2014] In this sentence, Pierce wasn't talking about Coq functions, he was really speaking of some relation he defined inductively. [Thu Jul 31 22:52:20 2014] so he's saying "partial function" to avoid implying that it's total [Thu Jul 31 23:01:14 2014] My confusion is that starting a sentence with, "That is," should follow with a restatement of something earlier - not a restatement of its opposite. [Thu Jul 31 23:01:43 2014] Well, for me, asking "P ?" and "Not P ?" is the same thing :p [Thu Jul 31 23:02:06 2014] But it also raises a question: Is the second definition of evaluation actually a partial function? That is, is it possible that, beginning from the same state st, we could evaluate some command c in different ways to reach two different output states st' and st''? [Thu Jul 31 23:02:17 2014] "that is" is continuing on from the question [Thu Jul 31 23:02:34 2014] he's elaborating [Thu Jul 31 23:10:47 2014] "But it also raises a question: Is it a triangle? That is, does it have four sides?" [Thu Jul 31 23:11:32 2014] Now suppose you're not entirely certain what 'triangle' is meant to contrast with. [Thu Jul 31 23:12:07 2014] I mean, I could argue more - but this is silly [Thu Jul 31 23:12:32 2014] whether or not something has four sides doesn't say if it's a triangle or not [Thu Jul 31 23:12:49 2014] whether or not something 'can be evaluating two different ways' does determine if it's a function or not [Thu Jul 31 23:14:38 2014] If it has four sides, it is not a triangle. If it can be evaluated two different ways, it is not a function. [Thu Jul 31 23:18:29 2014] "four sides" implies "not a triangle", but is not equivalent to "not a triangle". "it can be evaluated two different ways" is equivalent to "not a function" [Thu Jul 31 23:18:35 2014] At least I see it this way [Thu Jul 31 23:18:48 2014] yeah that's what I was trying to say [Thu Jul 31 23:19:43 2014] don't get me wrong - if you were proof-reading/editing this book it would be right to bring this up [Thu Jul 31 23:19:58 2014] but if you're trying to learn Coq or something, just read on [Thu Jul 31 23:26:31 2014] That is, I should examine the wording further? [Thu Jul 31 23:27:11 2014] lol [Thu Jul 31 23:27:24 2014] ;) [Fri Aug 1 00:32:57 2014] do any of you have any opinions on what the best way to represent a two-dimensional grid (like a game board for chess or shogi or something) in coq might be? [Fri Aug 1 00:34:42 2014] right now I have board (w h : nat) := {x | x < w} -> {y | y < h} -> tile where tile is whatever gets put on the board [Fri Aug 1 00:36:28 2014] I've also seen people use lists of lists but that makes certain operations (like anything dealing with columns instead of rows) a bit complicated [Fri Aug 1 00:58:19 2014] yukko: it really depends on what you're trying to do with it, but I would tend to stay away from a function taking sigmas for this. either use a function that takes nats and returns a bogus tile when the coordinates are out of bounds, or use a list of lists [Fri Aug 1 01:01:42 2014] but then wouldn't a board be infinitely large and difficult to write proofs about? [Fri Aug 1 01:02:17 2014] yukko: like I said, it depends. it would be infinitely large but you'd only ever use the in bounds cells [Fri Aug 1 01:02:36 2014] depending on what you're proving, this can actually make things easier or harder [Fri Aug 1 01:02:44 2014] another option would be a vector of vectors [Fri Aug 1 01:02:50 2014] which can be indexed by fins [Fri Aug 1 01:05:27 2014] oh that's true! [Fri Aug 1 04:20:16 2014] hello [Fri Aug 1 04:20:50 2014] having troubles to come up with "an interesting theorem about bags involving the functions [count] and [sum]" [Fri Aug 1 04:21:10 2014] what interesting could be proven about these functions and bags? [Fri Aug 1 04:22:13 2014] what are those? [Fri Aug 1 04:22:59 2014] bags are like mulitsets right? [Fri Aug 1 04:23:01 2014] vanila: bag - list of nats, sum - sum of nats in list, count - count of elements in bag [Fri Aug 1 04:23:04 2014] multi* [Fri Aug 1 04:23:18 2014] roosbeef: yup [Fri Aug 1 04:23:28 2014] count unique elements of the list? [Fri Aug 1 04:23:48 2014] can I see the formal definitions? [Fri Aug 1 04:24:20 2014] count 1 s = 1 -> S (sum s) looks kind of boring. [Fri Aug 1 04:24:57 2014] vanila: http://www.cis.upenn.edu/~bcpierce/sf/current/Lists.html that's what i'm doing [Fri Aug 1 04:26:12 2014] vanila: one sec ,i'll extract it for you [Fri Aug 1 04:26:17 2014] that's ok I see it! [Fri Aug 1 04:27:10 2014] oh, sum does not sums nats... it's just an ++ for list. [Fri Aug 1 04:27:18 2014] sorry got confused by name [Fri Aug 1 04:27:24 2014] oh [Fri Aug 1 04:27:33 2014] count a s + count a s' = count a (sum s s') [Fri Aug 1 04:28:35 2014] vanila: that's interesting! thank you! [Fri Aug 1 04:45:17 2014] how can i define such theorem? http://vpaste.net/v4icy [Fri Aug 1 04:46:31 2014] Theorem match_bool_nat_distr : forall (bool : Boolean) (a b c : nat), ???. [Fri Aug 1 04:46:46 2014] what should be in place of "???" ? [Fri Aug 1 04:48:14 2014] or does my pseudo theorem on vpaste is valid enough for coq? [Fri Aug 1 04:50:02 2014] heh, actually it is. :) [Fri Aug 1 04:51:38 2014] vanila: yay! proved yout theorem. :) [Fri Aug 1 04:51:48 2014] * feels smart [Fri Aug 1 04:56:04 2014] well done :) [Fri Aug 1 05:04:22 2014] does it "f x = f y -> x = y" called "congruence"? [Fri Aug 1 05:04:39 2014] injectivity [Fri Aug 1 05:08:42 2014] vanila: hm, in agda they have cong with type "{A B : Set} {f : A -> B} {x y : A} -> x = y -> f x -> f y" [Fri Aug 1 05:09:05 2014] so "f x = f y -> x = y" injectivity and "x = y -> f x -> f y" is congruence? [Fri Aug 1 05:09:18 2014] yes [Fri Aug 1 05:09:36 2014] vanila: got it, thanks! [Fri Aug 1 05:13:05 2014] oh, "x = y -> f x -> f y" should be "x = y -> f x = f y", but i guess you've got what i meant anyway. :) [Fri Aug 1 05:18:52 2014] having hard time proving "Theorem injectivity : forall (A B : Type) (f : A -> B) (x y : A), f x = f y -> x = y.". [Fri Aug 1 05:19:13 2014] just don't know how to start... [Fri Aug 1 05:19:36 2014] "intros A B f x y H." and then i'm stuck. [Fri Aug 1 05:20:39 2014] Ainieco, let f be the constant function from bool to 0 [Fri Aug 1 05:20:54 2014] f true = f false but true <> false [Fri Aug 1 05:23:20 2014] vanila: it's over my head for now i guess, haven't been introduced to "<>" in SF yet and don't know how to "let f be the constant function from bool to 0" in coq either. :) [Fri Aug 1 05:23:33 2014] <> means not equal [Fri Aug 1 05:23:51 2014] Definition f : bool -> nat := fun _ => 0. [Fri Aug 1 05:24:21 2014] just encountered "Theorem rev_inj : forall (l1 l2 : natlist), rev l1 = rev l2 -> l1 = l2." exercise in SF and tried to generalize solution via proving injectivity :) [Fri Aug 1 05:24:43 2014] vanila: but how can i use this definition within proof? [Fri Aug 1 05:25:00 2014] This is a counter-example to your theorem [Fri Aug 1 05:25:27 2014] vanila: ah, so my theorem is invalid, right? [Fri Aug 1 05:25:33 2014] that's right [Fri Aug 1 05:25:40 2014] not everytihng is injective, rev is special [Fri Aug 1 05:25:54 2014] okay, lesson learned. [Fri Aug 1 05:32:52 2014] found an easy way to prove rev_inj via fact that rev is involutive. [Fri Aug 1 05:48:00 2014] i wonder what's workflow for writing software in arbitrary language and proving properties about that software using coq. one thing bugs me, if coq doesn't support target lagnuage code generation then it possible to make typo/manual translation/etc mistakes. [Fri Aug 1 05:48:26 2014] that complete mystery to how did they proved their things http://sel4.systems/FAQ/proof.pml [Fri Aug 1 05:48:43 2014] they even excluded compiler and linker from trusted parties! [Fri Aug 1 05:49:02 2014] that's complete mystery to me* [Fri Aug 1 05:49:58 2014] sel4 uses isabelle [Fri Aug 1 05:50:19 2014] I could not build it :( [Fri Aug 1 05:50:41 2014] isn't there also a more in-depth paper on seL4? [Fri Aug 1 05:51:03 2014] vanila: isabell is proof asistant too, isn't it? So it's possible to do the same thing with coq, right? [Fri Aug 1 05:51:16 2014] Well I don't know about isabelle [Fri Aug 1 05:51:19 2014] so I can't say [Fri Aug 1 05:51:33 2014] I think so [Fri Aug 1 05:52:15 2014] vanila: but how would you exclude compiler and linker from trusted parties if you were proving things about you C code? [Fri Aug 1 05:52:25 2014] are 'target language code generation' and 'program extraction' vastly different? [Fri Aug 1 05:52:42 2014] as SF has http://www.cis.upenn.edu/~bcpierce/sf/current/Extraction.html [Fri Aug 1 05:53:17 2014] I think that the way sel4 claims to do this is by showing the assembly has the same meaning as the C code [Fri Aug 1 05:53:23 2014] and there is Bedrock as well, http://plv.csail.mit.edu/bedrock/ [Fri Aug 1 05:54:02 2014] "There is a further proof that the binary code which executes on the hardware is a correct translation of the C code. This means that the compiler does not have to be trusted, and extends the functional correctness property to the binary. " [Fri Aug 1 05:56:23 2014] vanila: well, how that proof can be possible? did they proved that *some* of compilers transalte their C code correctly because i can't think of a way to abstract away compiler [Fri Aug 1 05:57:33 2014] vanila: sorry for being annoying on that topic, just excited about that magic. [Fri Aug 1 05:58:43 2014] I think their development includes a C compile [Fri Aug 1 05:58:54 2014] it's not annoying :) [Fri Aug 1 05:58:56 2014] Ainieco: By ignoring the compiler entirely, and showing that the model of the source code that they've proved correct is implemented by the machine code, without worrying about where the machine code came from. (Although they use knowledge about the compiler to guide that proof) [Fri Aug 1 05:59:04 2014] oh I see [Fri Aug 1 05:59:15 2014] I was really excited about sel4 but I couldn't get it working, because of problems with running/building isabelle [Fri Aug 1 05:59:24 2014] so I haven't investigated it much [Fri Aug 1 06:00:41 2014] I didn't have much trouble rerunning the proofs, but it does use quite a lot of memory (it swapped a bit on my 8GB machine) [Fri Aug 1 06:01:20 2014] Although that probably doesn't include the machine code bit. [Fri Aug 1 06:01:21 2014] woah [Fri Aug 1 06:01:24 2014] that's gigantic [Fri Aug 1 06:01:50 2014] It's not the worst Isabelle development I've seen for that. [Fri Aug 1 06:03:14 2014] bacam: hm, so they're proved correctess of machine code ignoring compilers but end user still need to use compiler to build se4L, right? [Fri Aug 1 06:04:21 2014] If the end user really cares about correctness they ought to use the binary that was checked, or rerun the check themselves. [Fri Aug 1 06:04:51 2014] bacam: yeah, that all makes sense now [Fri Aug 1 06:05:04 2014] bacam: thanks for an explanation! [Fri Aug 1 06:05:20 2014] Ainieco, not related to seL4, but there is a C compiler developed in Coq called compcert - with correctness proofs [Fri Aug 1 06:05:41 2014] vanila: that's cool! [Fri Aug 1 06:08:10 2014] BTW, Andrew Appel's group have been working on verification using the language semantics for CompCert, which gives you strong guarantees about the machine code too via the compiler correctness theorem. [Fri Aug 1 06:09:42 2014] It's certainly interesting to work with developments like this after working for several years in software development where it was just assumed to be the case that formally correct software was an impossibility. [Fri Aug 1 06:09:45 2014] looks like compcert's site is down http://compcert.inria.fr/ [Fri Aug 1 06:10:18 2014] meanwhile http://sel4.systems/ is up [Fri Aug 1 06:10:26 2014] "© 2014 NICTA. Terms of use · Contact us · privacy Served by Apache on Linux on seL4. " [Fri Aug 1 06:11:11 2014] >on Linux on seL4 [Fri Aug 1 06:11:12 2014] wow [Fri Aug 1 06:13:20 2014] waaaait, Linux ON seL4? [Fri Aug 1 06:13:54 2014] oh, http://os.inf.tu-dresden.de/L4/LinuxOnL4/ maybe [Fri Aug 1 06:18:31 2014] http://l4android.org/ I suppose that's neat too [Fri Aug 1 13:17:03 2014] Hi. I am doing SF exercises and encountered a problem, in the second chapter the book tells me to compile the module "Basic.v", and so I did. Never the less in the second chapter coq complains that it does not know "evenb". Anyone encountered similar problems ? [Fri Aug 1 13:30:06 2014] pumpkin360: are you working in the provided Induction.v file? [Fri Aug 1 13:32:06 2014] pumpkin360: also, the file is "Basics.v" not "Basic.v", maybe that's it? [Fri Aug 1 13:51:34 2014] jrw: you solved my problem, thanks. [Fri Aug 1 13:51:47 2014] np [Fri Aug 1 21:48:43 2014] Hi. I am reading software fundations and have a task to filter even elements from the list, but if statments were not covered yet, is it possible to filter even elements from the list using only pattern matching? [Fri Aug 1 21:49:11 2014] Possible and reasonably complex. [Fri Aug 1 21:50:21 2014] In which file is this? [Fri Aug 1 21:50:48 2014] Cypi: Lists.v [Fri Aug 1 21:51:05 2014] Cypi: line ~290 [Fri Aug 1 21:53:10 2014] Yes, I see it. I was just checking if indeed if statements were not covered yet, and it seems to be the case. I'm surprised :o [Fri Aug 1 21:53:19 2014] (I used "if" for this exercise) [Fri Aug 1 21:53:50 2014] Cypi: so will I do then. Thanks. [Fri Aug 1 22:16:28 2014] pumpkin360: I did not use 'if' statements in my own solution, it appears. [Fri Aug 1 22:16:33 2014] just pattern matching. [Fri Aug 1 22:20:12 2014] Hmm, I wonder how you did it exactly then [Fri Aug 1 22:46:32 2014] Hodapp: Can I see it? [Sun Aug 3 07:40:09 2014] hello. are there any collections and dictionaries in coq? [Sun Aug 3 09:00:20 2014] There are dictionaries; they’re called ‘finite maps’ (e.g., the [FMaps] module). What other collections do you need? [Sun Aug 3 09:17:20 2014] alkabetz: I need maps which can be efficiently changed elementwise. [Sun Aug 3 09:40:32 2014] Cypi: I know how he ommited using if statements - we can match on anything, on the predicate return value in particular so, match a | true => true | false => false end. := if a then true else false [Sun Aug 3 09:50:27 2014] Ah, alright [Sun Aug 3 09:50:37 2014] Thanks [Sun Aug 3 09:53:37 2014] btw. I find Coq syntax extremely cumbersome, I guess that it is connected with the fact that it is a DSL less convenient for general purpose programming? Or maybe because it is old? [Sun Aug 3 09:55:23 2014] (comparing to Haskell because that is probably the most similar language) [Sun Aug 3 09:57:22 2014] I don't know, I don't find it that cumbersome :o [Sun Aug 3 10:00:17 2014] maybe it is a matter of little experience. I am just starting to learn but do not even think I will understand the rules of type inference anytime soon. [Sun Aug 3 10:00:35 2014] and the syntax of giving types to things. [Sun Aug 3 10:02:07 2014] pumpkin360: I got your response a bit late. Do you still want to see mine? [Sun Aug 3 10:15:20 2014] Hodapp: no, I figured it out how to do it. [Sun Aug 3 10:15:31 2014] Hodapp: but thanks. [Sun Aug 3 11:12:51 2014] pumpkin360 if you had a math background, you would not find typing difficult to understand at all [Sun Aug 3 11:13:42 2014] hey I did math and folk could not proe x + y = y + x, don't assume match background helps anything :P [Sun Aug 3 11:13:51 2014] math background* [Sun Aug 3 11:17:21 2014] Anarchos : I'm not sure a math background would help with typing dependent matches, that kind of things :-° [Sun Aug 3 11:20:36 2014] Cypi maybe i find things too easy there :) [Sun Aug 3 11:20:47 2014] in my country math is just memorize a bunch of bullshit, theorem names etc. [Sun Aug 3 11:21:15 2014] vanila: you in the US? [Sun Aug 3 11:21:24 2014] UK [Sun Aug 3 11:21:50 2014] it's a sad situation :( [Sun Aug 3 11:21:55 2014] so, similar education it appears. [Sun Aug 3 11:22:20 2014] vanila: that's what it looks like in many countries I guess. I am learning SC and not maths - that helps :) [Sun Aug 3 11:22:57 2014] Lockhart's lament. Mathematicians have been trying to say there's so much more to math than what is taught in schools, and people write them off like industry writes off Haskellers. [Sun Aug 3 11:23:05 2014] "ya ya, know-it-alls." [Sun Aug 3 11:24:33 2014] does it really write off Haskellers? I think that Haskell is getting more and more attention in industrial applications (it is not suited in many cases though) [Sun Aug 3 11:27:15 2014] specialised subgroup bemoans lack of wider acceptance by society, news at 11 [Sun Aug 3 11:27:42 2014] What is SC? [Sun Aug 3 11:27:58 2014] vanila: sorry, was supposed to be CS [Sun Aug 3 11:28:05 2014] ah, CS was horrible for me :( [Sun Aug 3 11:28:10 2014] we were forced to make pets in second life [Sun Aug 3 11:28:19 2014] so I dropped CS and went to pure math, which has its own problems [Sun Aug 3 11:28:35 2014] like, we got marked on how nice our pets were.. and did a pet show [Sun Aug 3 11:28:52 2014] o_o [Sun Aug 3 11:29:38 2014] so I think institutionalised education needs a revamp, or maybe it's just not about educating people [Sun Aug 3 11:29:42 2014] vanila: since the next learn I will also be learning pure maths. Btw. we don't have such things on our University... [Sun Aug 3 11:30:24 2014] ijp: aren't you a Schemer? [Sun Aug 3 11:31:11 2014] I'm many things [Sun Aug 3 11:32:15 2014] vanila in my maths lessons, we did exhaustive demonstrations on about nearly 900 pages of hand written papers... [Sun Aug 3 11:33:10 2014] ok! hard work benefits well :) [Sun Aug 3 11:35:12 2014] Oh, if we made a such big offtopic, I guess you may be fimilar with statistics/machine learning, what languages would you advice for it? Is R worth learning in particular? [Sun Aug 3 11:35:56 2014] well I think R is very nice, but I dont know about machine learning.. [Sun Aug 3 11:36:27 2014] and yeay maybe we should start to talk about Coq some day :p I may start to work through pierce SF book today [Sun Aug 3 11:37:44 2014] vanila: brace yourself, it gets boring very fast. I am in my 3 attempt to read it and hopeful won't give up too fast this time. [Sun Aug 3 11:38:02 2014] haha [Sun Aug 3 11:38:06 2014] I can skip the first couple chatpers [Sun Aug 3 11:38:11 2014] because I studied some other books already [Sun Aug 3 11:38:21 2014] vanila id did most of SF at work while being bored with silly bank java code :) [Sun Aug 3 11:38:25 2014] I'm just interested in how they formalize IMP, and prove things about it [Sun Aug 3 11:38:30 2014] Anarchos, hehe don't get caught ! [Sun Aug 3 11:40:57 2014] vanila: that may be a good idea. I have started from the beginning because Coq was new to me and was expecting to learn proving formatlly and the main thing I learnt in the first chapters is the syntax of another language which seems a bit archaic. [Sun Aug 3 11:41:36 2014] vanila: and ugly - comparing to Haskell for example, but perhaps I will get used to it soon. [Sun Aug 3 11:42:18 2014] lol [Sun Aug 3 11:42:21 2014] it's based on ocaml [Sun Aug 3 11:42:25 2014] the syntax [Sun Aug 3 11:42:42 2014] I kind of agree, but I don't mind it much [Sun Aug 3 11:42:48 2014] heard about it [Sun Aug 3 11:42:59 2014] the important thing is what's behind the syntax - which is very good [Sun Aug 3 11:44:04 2014] vanila IMP ? [Sun Aug 3 11:44:53 2014] one of the later chapers [Sun Aug 3 11:44:54 2014] vanila: perhap you know - where in SF will the mechanism of checking proofs be described, I would really like to be able to know what can I do. Chapter "Logic" or "More Coq" ? [Sun Aug 3 11:44:59 2014] for imperative programming langauge [Sun Aug 3 11:45:39 2014] pumpkin360, I don't know if it goes into the theory much - but it's quite simple. Checking proofs is just type checking lambda calculus terms [Sun Aug 3 11:45:44 2014] pumpkin360 what do you mean by "the mechanism of checking proofs" ? [Sun Aug 3 11:45:54 2014] all the tactics in Coq do is create lambda terms, for the core proof checker to look at [Sun Aug 3 11:45:57 2014] vanila you answered faster than me [Sun Aug 3 11:46:53 2014] and the "core proof checker" is some simple algorithm operating on lambda calculus ? [Sun Aug 3 11:48:28 2014] yes [Sun Aug 3 11:49:04 2014] There are just some complications to ensure termination I believe. [Sun Aug 3 11:49:10 2014] The fundamental idea is that any complicated things can be expressed in terms of a simple core - so that you have less assumptions to worry about to see what is a valid proof [Sun Aug 3 11:49:30 2014] Do you know the simple typed lambda calculus? [Sun Aug 3 11:50:13 2014] and tactics will be described in MoreCoq. [Sun Aug 3 11:50:16 2014] a little bit [Sun Aug 3 11:50:41 2014] it can serve as a proof language for constructive propositional logic [Sun Aug 3 11:50:46 2014] like P -> P is proved by \p -> p [Sun Aug 3 11:51:15 2014] vanila: ok. I will read about it a bit then, and about Coq tactics. [Sun Aug 3 11:51:37 2014] and Coq is just a more powerful lambda calculus plus data types.. plus pattern matching [Sun Aug 3 11:51:45 2014] at least the core is [Sun Aug 3 11:53:47 2014] pumpkin360 do you know the curry howard correspondance ? [Sun Aug 3 13:02:55 2014] Anarchos: Only hear about it, that it states that proves are equal to programs [Sun Aug 3 13:04:50 2014] it's like how I said \p -> p proves P -> P [Sun Aug 3 13:05:04 2014] that proof is a "program" in lambda calculus [Sun Aug 3 13:05:31 2014] pumpkin360 ok. If you can get a glance at it, it is really interesting [Sun Aug 3 13:54:41 2014] is there a way to say "in this file, this implicit argument is always equal to T"? [Sun Aug 3 13:57:05 2014] You can use sections [Sun Aug 3 13:57:11 2014] and define it as a parameter [Sun Aug 3 13:57:30 2014] http://coq.inria.fr/library/Coq.Init.Wf.html for example [Sun Aug 3 13:57:42 2014] Variable A : Type, Variable R [Sun Aug 3 13:58:04 2014] yes, my situation is [Sun Aug 3 13:58:34 2014] I'm using ListSet, and it defines a section with an hypothesis Aeq_dec to say that the type A of elements has decidable equality [Sun Aug 3 13:58:56 2014] I'm using it for sets of nats, but I have to pass eq_nat_dec all the time as a parameter [Sun Aug 3 13:59:12 2014] I'd like to fix Aeq_dec as equal to eq_nat_dec [Sun Aug 3 14:00:40 2014] oh you're on the other side, I see - sorry I don't know how to solve that [Sun Aug 3 14:00:51 2014] hello [Sun Aug 3 14:01:05 2014] thanks anyway :) I think this may be solved using modules or type classes [Sun Aug 3 14:01:13 2014] but it's just for convenience [Sun Aug 3 14:02:03 2014] why does "map f t" has " list (list Y)" type http://lpaste.net/4199287390424006656 ? [Sun Aug 3 14:02:47 2014] Ainieco, you use map instead of flat_map [Sun Aug 3 14:02:55 2014] ohhh [Sun Aug 3 14:03:07 2014] yes [Sun Aug 3 14:03:12 2014] thanks for pointing it out :) [Sun Aug 3 14:03:16 2014] t : list X, f : X -> list Y [Sun Aug 3 14:04:02 2014] never use modules unless you're exporting hint databases and notations. [Sun Aug 3 14:04:51 2014] * needs more coffee [Sun Aug 3 14:04:56 2014] so type classes then [Sun Aug 3 14:06:19 2014] * just downed a 4-shot americano. [Sun Aug 3 14:06:59 2014] a 4-shot americano is about the same as 1 espresso, in terms of caffeine? :) [Sun Aug 3 14:08:50 2014] 4 shots of espresso, with water added = 4-shot americano [Sun Aug 3 14:09:25 2014] I see [Sun Aug 3 14:09:40 2014] I only associate "americano" with "weak coffee" [Sun Aug 3 14:11:14 2014] definitely not the case. [Sun Aug 3 14:11:57 2014] well, depends on how much water you add, TBH [Sun Aug 3 14:12:03 2014] yes [Sun Aug 3 14:12:28 2014] it's the water... and basically every coffee I had in the US was weak [Sun Aug 3 14:13:04 2014] I prefer to drink espresso or ristretto [Sun Aug 3 14:14:45 2014] is there a good way to say that a list of sets is disjunct, with good theorems about this? [Sun Aug 3 14:15:42 2014] i.e. given a list of sets I want a Prop that says they're disjunct, and an easy way to establish that a member of one of them is not a member of the others [Sun Aug 3 14:17:01 2014] hm. is there some way of having fast arrays in coq? like monads or uniqueness types would do? [Sun Aug 3 14:18:01 2014] do you want them to extract to arrays? [Sun Aug 3 14:18:32 2014] yes [Sun Aug 3 14:18:53 2014] i want a blob. and do stuff on that blob. [Sun Aug 3 14:19:52 2014] i can (and probably will) use a tree if that is necessary [Sun Aug 3 14:20:02 2014] it just would be nice [Sun Aug 3 14:20:30 2014] I don't know if there's something like that already [Sun Aug 3 14:42:49 2014] huh, kind of unexpcted to see these kind of things about proof assistants, but well this is japan apparantly http://p.twpl.jp/show/orig/qGEap [Sun Aug 3 14:46:10 2014] http://p.twpl.jp/show/orig/FslzM [Sun Aug 3 14:46:55 2014] they even have stickers... http://f.st-hatena.com/images/fotolife/a/akuraru/20130622/20130622214252.jpg [Sun Aug 3 14:47:17 2014] haha [Sun Aug 3 14:47:36 2014] cute proof general :) [Sun Aug 3 14:47:48 2014] it's from #ProofCafe [Sun Aug 3 14:47:54 2014] japanese formal methods club [Sun Aug 3 14:48:19 2014] https://twitter.com/search?q=%23ProofCafe [Sun Aug 3 14:51:29 2014] http://f.hatena.ne.jp/akuraru/20130622214454 [Sun Aug 3 15:54:38 2014] what is the difference between "rewrite" and "apply" tactics, it looks like "apply" can do quite a lot of different things at same time' [Sun Aug 3 15:56:05 2014] so far i'm thinking about "apply" as about "simpl + rewrite" or "rewrite + reflexivity" [Sun Aug 3 15:56:19 2014] but i don't have clear understanding what it actually does [Sun Aug 3 15:56:49 2014] Ainieco: apply deals with Goals (or targets) of form G and uses a hypothesis of form H ... -> G. Rewrite allows you to change subterms in a target, using equality or more generally equivalence relations that are respected. [Sun Aug 3 15:57:45 2014] You can't "apply" a hypothesis of form H <-> H', but you can rewrite it. [Sun Aug 3 16:00:56 2014] Actually you can apply a hypothesis of form H <-> H'. [Sun Aug 3 16:01:59 2014] and unless I'm mistaken, you cannot rewrite it without [Require Import Setoid.] or something like that. [Sun Aug 3 16:06:30 2014] hm, so when i have goal G and hypothesis of form A = B then if rewriting G using H solves G then "apply" acts as "rewrite + reflexivity". but if H has form of H ... -> H then what happens? [Sun Aug 3 16:06:51 2014] H ... -> G* [Sun Aug 3 16:12:36 2014] let me rephrase [Sun Aug 3 16:13:50 2014] http://lpaste.net/7982070606491287552 what happened after "apply H1."? does it substituted current goal with premise of H1, correct? [Sun Aug 3 16:18:46 2014] if so then what happens when there is no premises, e.g., when theorem being applied is just proven equality? [Sun Aug 3 16:18:48 2014] there is no rewrite + reflexivity happening here. In order to make H1's conclusion match the goal, it determined n = 3. It now needs to know that evenb 3 = true, because it doesn't backchain to fulfil obligations. [Sun Aug 3 16:19:55 2014] Ainieco: for now think of rewrite as having to do with equality. if you have a hypothesis H : a = b, and a appears in the goal, then "rewrite H" will replace that occurence of a with b. [Sun Aug 3 16:20:03 2014] Just like if you have a goal of bool and have a hypothesis H: nat -> bool, if you apply H, you have to apply it to _something_ of type nat. [Sun Aug 3 16:20:53 2014] apply is more about implication. simplest example is if you have a hypothesis H : P and your goal is exactly P then you can "apply H" to finish [Sun Aug 3 16:21:37 2014] more generally, if you have H : P -> Q and your goal is Q, then "apply H" will change your goal to P, because if you can prove P, then H proves P implies Q and so Q follows [Sun Aug 3 16:21:50 2014] so apply and rewrite are really quite different and unrelated [Sun Aug 3 16:22:18 2014] however, in your example, it can be confusing, because you're reasoning about equality, so it seems like maybe rewrite is involved. [Sun Aug 3 16:22:27 2014] but it's not [Sun Aug 3 16:23:01 2014] when you do "apply H1", coq unifies the conclusion of H1 (that is, "oddb (S n) = true") with your goal [Sun Aug 3 16:23:18 2014] oh, i think i got it, thank you guys! [Sun Aug 3 16:23:20 2014] this unification tells coq that n must be 3 [Sun Aug 3 16:24:55 2014] jrw: and then i need to prove that premise of conclusion holds, to do that i did "apply H2" which is exactly what my goal is. [Sun Aug 3 16:29:41 2014] Ainieco: exactly [Sun Aug 3 16:30:19 2014] so "apply H1" changed the goal to the assumption of H1, suitably modified since we know n must be 3. [Sun Aug 3 16:30:42 2014] then "apply H2" is the simplest case I mentioned above, when a hypothesis exactly matches a goal. [Sun Aug 3 19:08:05 2014] if I have f ≈ f' in my context, and f = f' in my goal, how can I relate these two? [Sun Aug 3 19:16:13 2014] [assumption], or [exact H] where [H : f = f'], or [rewrite H; reflexivity], or simply [auto]. [Sun Aug 3 19:16:56 2014] or I didn't understand your question [Sun Aug 3 19:16:59 2014] it's ≈ from Setoid, not = [Sun Aug 3 19:17:14 2014] Oh, sorry. Then I don't know :) [Sun Aug 3 19:17:41 2014] normally I would be able to rewrite H, but not here; I may be missing something [Sun Aug 3 19:19:41 2014] ahh [Sun Aug 3 19:19:44 2014] apply eqv_equivalence in H. [Sun Aug 3 19:19:53 2014] that turns f ≈ f' into f = f' in the context [Sun Aug 3 19:20:07 2014] uh, no, sorry, msiread it [Sun Aug 3 19:20:11 2014] it just flipped f and f' [Sun Aug 3 22:02:43 2014] Isn’t there a setoid_rewrite tactic? [Sun Aug 3 22:04:57 2014] alkabetz: Require Import Setoid. [Mon Aug 4 06:50:39 2014] hello. I am trying to do recursion on a structure, matching a structure with patterns like C0 => _ | C1 0 => _ | C1 (S m) => _. [Mon Aug 4 06:51:12 2014] the prblem is, when I call the recursion inside the body of the last part with C1 m, the recursion checker fails. [Mon Aug 4 06:51:30 2014] *termination [Mon Aug 4 09:12:31 2014] "so it is not very surprising that a ({x : A | P x} : Prop) can be cast into a ({x : A | P x} : Type)." how is this not surprising? I thought Prop and Type are two separate universes with no conversions between them. [Mon Aug 4 09:13:30 2014] That is very surprising [Mon Aug 4 09:13:40 2014] "cast"? where is this from [Mon Aug 4 09:14:18 2014] coq-club [Mon Aug 4 09:14:28 2014] see "what exactly are the Prop analysis rules?" thread [Mon Aug 4 09:16:44 2014] Isn't Prop a subtype of Type? [Mon Aug 4 09:17:41 2014] [Variable P : Prop. Definition x : Type := P.] does work [Mon Aug 4 09:18:04 2014] I thought Prop had stricter elimination rules than Type, so I don't get it [Mon Aug 4 09:18:14 2014] I guess im just wrong, that would nake sense [Mon Aug 4 09:22:14 2014] interesting. [Mon Aug 4 09:22:27 2014] I didn't know Prop is subtype of Type [Mon Aug 4 09:27:18 2014] what's a singleton? [Mon Aug 4 09:55:39 2014] osa1: A singleton is a few things due to conflated concepts. One is the notion of singleton elimination in Prop: if an inductive has only one constructor, you can eliminate into Type, because it's essentially a 0-information tag. It can also mean a type that intensionally has one element, like unit. Another meaning is now called a sub-singleton: a type in which all inhabitants have a pairwise equality. [Mon Aug 4 09:56:25 2014] singleton elimination in Coq is inconsistent with univalence. [Mon Aug 4 10:08:20 2014] ianjneu: "if an inductive has only one constructor, you can eliminate into Type" what does that mean? do you have an example? [Mon Aug 4 10:14:03 2014] how is [True\/True] not isomorphic to bool ? [Mon Aug 4 10:19:36 2014] so analyzing(destructing) [exists e, P] is actually safe but prevented in Coq for some reason? [Mon Aug 4 10:32:07 2014] The idea is that Prop should have a notion of "proof irrelevance" [Mon Aug 4 10:32:26 2014] where any two proofs of the same proposition should be interchangable [Mon Aug 4 10:32:53 2014] That's why when you fininsh a proof with Qed rather than Defined, it doesn't reduce it in computations [Mon Aug 4 10:33:16 2014] it's all about trying to make proofs more opaque, so that as long as the theorem is proved you'll be ok (doesn't matter which proof) [Mon Aug 4 10:33:50 2014] so you shouldn't be able to write a nonconstant function True\/True -> bool [Mon Aug 4 10:37:23 2014] vanila: so the problem is that [True\/True] has type Prop? what if I cast it to Type? (like mentioned above) [Mon Aug 4 10:37:41 2014] well yeah, that's why I was so confused earlier - please try this and tell me what happens [Mon Aug 4 10:38:23 2014] I have no ideas about how to "cast" :) [Mon Aug 4 10:38:47 2014] oh Check (True \/ True : Type). [Mon Aug 4 10:38:54 2014] I guess annotating is enough. [Mon Aug 4 10:41:23 2014] Error: Case analysis on sort Set is not allowed for inductive definition or. [Mon Aug 4 10:44:29 2014] osa1: http://lpaste.net/108746 [Mon Aug 4 10:44:46 2014] so it's not type of what I'm doing pattern matching on but rather the type of the result. [Mon Aug 4 10:45:14 2014] osa1: yes, that's what I mean by "eliminate into" [Mon Aug 4 12:37:19 2014] do we have a Prop in stdlib saying that `e is member of list l` with constructors member e (e :: l) | member e t -> member e (h :: t) ? [Mon Aug 4 12:39:49 2014] osa1: I only know In, which is a fixpoint, but there is Exists, which is a decorated version of your "member". [Mon Aug 4 12:41:11 2014] member: forall A : Type, A -> list A -> Prop. member A x l <-> Exists A (fun y => x = y) l. [Mon Aug 4 17:33:46 2014] any ideas how to prove this http://lpaste.net/108781 ? [Mon Aug 4 17:49:36 2014] osa1: prove a lemma that says membership is preserved by permutation [Mon Aug 4 17:50:17 2014] osa1, induction on the permutation using lemmas like http://lpaste.net/108782 [Mon Aug 4 17:51:06 2014] jrw: well that's already the main goal [Mon Aug 4 17:51:20 2014] oh wait sorry it's not [Mon Aug 4 17:53:18 2014] so any of you proved something like this before to prove some sorting algorithm correct? [Mon Aug 4 17:54:01 2014] osa1: here's one way. http://lpaste.net/108783 [Mon Aug 4 17:54:13 2014] yes it's common to reason about Permutations for sorting algorithms. [Mon Aug 4 17:54:36 2014] that's a really nice proof [Mon Aug 4 17:54:39 2014] much better than my way [Mon Aug 4 17:55:46 2014] jrw: eauto doesn't do induction, right? [Mon Aug 4 17:55:55 2014] I'm wondering how did that work [Mon Aug 4 17:56:10 2014] osa1: you don't need induction for the last proof :) [Mon Aug 4 17:56:13 2014] only to prove the lemma [Mon Aug 4 17:56:21 2014] then your thing follows immediately using that lemma [Mon Aug 4 17:58:28 2014] oh I get it now. really nice proof. so actually the tricky part is to see that proving membership is preserved with permutation is required. [Mon Aug 4 17:59:34 2014] osa1: right. I first tried to do it directly by induction, but in the transitivity case the IH is not strong enough. so you know you'll need to generalize something. [Mon Aug 4 18:05:02 2014] jrw: why I can't use the lemma with auto and I have to use eauto instaed? [Mon Aug 4 18:06:06 2014] I'm also wondering how did you figure that `match goal` part. did you first write the whole proof manually? [Mon Aug 4 18:06:17 2014] e.g. using inversions and autos. [Mon Aug 4 18:06:33 2014] osa1: yes I always start manually [Mon Aug 4 18:06:35 2014] then clean up [Mon Aug 4 18:08:40 2014] osa1: you have to use eauto because it needs to guess the value of l' [Mon Aug 4 18:08:47 2014] er, I mean l [Mon Aug 4 18:08:57 2014] because l doesn't appear in the conclusion of member_perm [Mon Aug 4 18:09:56 2014] I thought it's only used for guessing existential vars [Mon Aug 4 18:11:23 2014] osa1: eauto applies member_perm to the goal and introduces an existential variable in place of l. this existential is resolved by finding the hypothesis "Permutation l l'" [Tue Aug 5 01:26:05 2014] can anyone help with a universe inconsistency problem? https://github.com/jwiegley/category-theory/blob/master/Functors.v#L131 [Tue Aug 5 01:26:24 2014] that doesn't get accepted because: Error: Universe inconsistency (cannot enforce Category.33 <= Top.32334). [Tue Aug 5 01:27:14 2014] is it because I'm trying to create arrows between objects which are arrows? [Tue Aug 5 01:28:32 2014] I'm trying to rely on the fact that polymorphic functions in Coq are effectively sets of functions [Tue Aug 5 01:28:52 2014] (or rather, any function type is effectively a set of functions) [Tue Aug 5 02:39:34 2014] *push* hello. I am trying to do recursion on a structure, matching a structure with patterns like C0 => _ | C1 0 => _ | C1 (S m) => _. [Tue Aug 5 02:39:52 2014] the prblem is, when I call the recursion inside the body of the last part with C1 m, the termination checker fails. [Tue Aug 5 03:09:07 2014] schoppenhauer: yes because that is not a direct subterm. one way to proceed is to use the general recursion facilities of coq. another way is to define a custom induction principle for your type which allows recursive calls to applications of C1 to smaller nats. [Tue Aug 5 03:18:36 2014] johnw: The issue seems to be your [Instance Nat]; moving your definition to just before that instance makes it work, whereas right after that instance, you get the universe inconsistency. This seems to be because, according to Coq's universe rules, natrual transformations on functors out of a locally small category do not form a Set (the type [forall {X : objC}, F X ~> G X] has universe level max(level of objC, level of _ ~{ D }~> _)). If you [Tue Aug 5 03:18:36 2014] add the ": objC" annotation to [forall {X}, F X ~> G X] (so that you don't go through the monomorphic type of [obj] and you make it so that [Natural] takes a [Set] for [objC], it all goes through. I think you can get away with taking a [Type] for [objC], if you break things up into enough sections so that [Nat] and [Natural] get different universes for [objC]. In any case, if you're interested, it compiles fine with the older version of my [Tue Aug 5 03:18:36 2014] library (https://bitbucket.org/JasonGross/catdb/src) which works with 8.4 (the newer version is (https://github.com/HoTT/HoTT/tree/master/theories/categories/): https://gist.github.com/JasonGross/a7ada2d97eb0b0e8be27 is on top of catdb. [Tue Aug 5 03:20:54 2014] johnw: One useful trick for tracking down universe inconsistencies in 8.4 (things are much, much better in trunk) is to make the type of morphisms be [Set] (working under the "category theorists only ever need small and locally small categories, ~never large ones" principle), and seeing what breaks. This makes things break much earlier, and is an easier way to find a conceptualization than staring at the too-verbose output of [Print Universes]. [Tue Aug 5 03:20:54 2014] (Again, things are better in trunk, where printing a definition also prints the universe constraints it adds.) [Tue Aug 5 04:48:11 2014] Hi. I'd like to install coq on a pendrive. Is this possible? [Tue Aug 5 08:58:03 2014] jrw: what general recursion facilities do you mean? [Tue Aug 5 09:56:11 2014] jrw: I can only find "experimental" features for functional induction [Tue Aug 5 10:14:40 2014] hm. ok, i will just define my own measure function and work with bla = measure blubb, and induction over bla [Tue Aug 5 10:14:44 2014] (did this before) [Tue Aug 5 10:16:33 2014] (it's just ... harder) [Tue Aug 5 12:45:21 2014] schoppenhauer: I was thinking of using Function or Program. I can whip up an example if you're interested [Tue Aug 5 12:45:58 2014] jrw: the documentation sais these are experimental. [Tue Aug 5 12:46:10 2014] so I probably better stick with my explicit equality. [Tue Aug 5 12:46:42 2014] (my expierience sais that ... if something is experimental in coq, one shouldn't use it ...) [Tue Aug 5 12:46:48 2014] schoppenhauer: coq is a research tool, many things are experimental. depending on what project you're working on, you shouldn't feel too worried about using them. [Tue Aug 5 12:49:00 2014] jrw: actually I have to finish stuff in the near future, so better more to write but less to debug. thank you anyway! [Tue Aug 5 14:05:18 2014] hello [Tue Aug 5 14:07:29 2014] geez, it's so hard http://lpaste.net/6734884027255226368 [Tue Aug 5 14:08:09 2014] using app_length it's piece of cake but exercise forbids usage of app_length [Tue Aug 5 14:09:36 2014] did my current context messed up? or is there any way forward without using app_length? [Tue Aug 5 14:32:19 2014] Ainieco: you're allowed to use cons_app_length, right? [Tue Aug 5 14:33:17 2014] Ainieco: I recommend doing induction on n without introducng l. [Tue Aug 5 14:53:24 2014] can anyone help me with this http://lpaste.net/108854 ? I'm looking for tips [Tue Aug 5 15:08:07 2014] osa1: you'll need to prove a lemma about find_min_idx_aux [Tue Aug 5 15:08:08 2014] jrw: thanks for hint, i'll try [Tue Aug 5 15:11:42 2014] jrw: any more tips? I think that one is kind of obvious :) [Tue Aug 5 15:12:15 2014] osa1: you need something about the fact that min_idx is always less than the length of l plus cur_idx [Tue Aug 5 15:13:27 2014] min_idx l < length l + cur_idx ? but this is not correct. [Tue Aug 5 15:15:26 2014] osa1: okay, well there's some invariant about cur_idx you need to capture [Tue Aug 5 15:15:45 2014] hm [Tue Aug 5 15:19:12 2014] osa1: http://lpaste.net/108860 [Tue Aug 5 15:19:14 2014] okay. I think there are two invariants about cur_idx. 1) it's always holds index of minimum element of the list up to the point we're currently analyzing. 2) it's always smaller than length of analyzed part of the list. [Tue Aug 5 15:19:29 2014] I shouldn't see that [Tue Aug 5 15:19:31 2014] :) [Tue Aug 5 15:21:29 2014] osa1: oh sorry, I wasn't sure if you wanted to see a way to do it or just hints. [Tue Aug 5 15:21:43 2014] well don't worry I read it and it's amazing. [Tue Aug 5 15:21:48 2014] I think I understand the lemma. [Tue Aug 5 15:22:52 2014] so the invariant is that the return value of find_min_idx_aux will always be less than the length of the input list plus ci [Tue Aug 5 15:23:11 2014] under the assumption that you pass in a reasonable value for mi (that is, a value that is less than ci) [Tue Aug 5 15:51:59 2014] jrw: by the way, exercise description says "Prove this by induction on [l]" :) [Tue Aug 5 16:03:40 2014] why we don't have a nth with type `l -> n -> n < length l -> a ? [Tue Aug 5 16:18:04 2014] do we have lb in stdlib? like leb but I want < relation not <=. [Tue Aug 5 16:34:01 2014] osa1: there's NPeano.ltb [Tue Aug 5 16:34:12 2014] http://lpaste.net/108870 any ideas why I'm having this huge term? [Tue Aug 5 18:58:36 2014] if I have to prove that two records are propositionally equal, how do I split the fields into separate goals? [Tue Aug 5 19:01:55 2014] johnw: does f_equal do what you want? [Tue Aug 5 19:02:05 2014] no, it has no effect [Tue Aug 5 19:02:23 2014] I end up: [Tue Aug 5 19:02:28 2014] {| transport := transport1; naturality := naturality1 |} = {| transport := transport0; naturality := naturality0 |} [Tue Aug 5 19:02:28 2014] [Tue Aug 5 19:02:45 2014] and I need to prove separately that transport1 = transport0, and naturality1 = naturality0 [Tue Aug 5 19:03:17 2014] assert (transport1 = transport0) as A. [Tue Aug 5 19:03:19 2014] prove it [Tue Aug 5 19:03:23 2014] then assert the other as B [Tue Aug 5 19:03:33 2014] then congruence should complet the goal [Tue Aug 5 19:03:46 2014] it says "transport0 not found in the current environment" [Tue Aug 5 19:03:57 2014] oh, wait [Tue Aug 5 19:07:34 2014] no, that didn't work [Tue Aug 5 19:08:03 2014] I do end up with a context of transport1 = transport0, but those are both just types: ∀ X : C, A X ~{ D }~> B X [Tue Aug 5 19:08:07 2014] I think I'm missing some other condition [Tue Aug 5 19:11:39 2014] is there any other way to do induction on record fields? [Tue Aug 5 19:17:39 2014] apply f_equal2 was much more successful [Tue Aug 5 21:00:48 2014] I'm using f [Tue Aug 5 21:00:51 2014] _equal2 to attempt to simplify two records [Tue Aug 5 21:00:54 2014] and I'm ending up with: https://gist.github.com/0ee41eeed2bb70bd1141 [Tue Aug 5 21:00:58 2014] now, I have a right_identity law; is there any way to "reach inside" when applying f_equal like this to get it to use that law? [Tue Aug 5 21:01:06 2014] just rewriting does not find the term [Tue Aug 5 21:05:55 2014] I thought Coq had eta conversion [Tue Aug 5 21:06:18 2014] what if you do intro H X Y f0. apply (H X Y f0). [Tue Aug 5 21:06:29 2014] I mean, I assume you tried this and it doesn't work - I'm justcurious what happens? [Tue Aug 5 21:06:47 2014] here's my context: https://gist.github.com/ca56ec2d900bdf68f11f [Tue Aug 5 21:06:56 2014] you'll see that I can't use intro here (or don't know how) [Tue Aug 5 21:07:08 2014] if I could "descend" into the second field somehow, and prove that as a separate goal, then I could [Tue Aug 5 21:07:22 2014] oh, way [Tue Aug 5 21:07:23 2014] wait [Tue Aug 5 21:07:29 2014] maybe I can use forward reasoning here [Tue Aug 5 21:08:47 2014] if I have something in my context of type ∀ X, ... [Tue Aug 5 21:08:51 2014] I can't help you unless I can try things with this, even then I probably can't help [Tue Aug 5 21:08:53 2014] how do I bring the X out as an existential? [Tue Aug 5 21:09:06 2014] github.com/jwiegley/category-theory, if you are interested [Tue Aug 5 21:10:10 2014] thanks, what file is this? [Tue Aug 5 21:10:14 2014] Functors.v [Tue Aug 5 21:10:33 2014] trying to prove right_identity for the Nat category [Tue Aug 5 21:11:09 2014] ok i need to figure out how to add loadpaths, then I'll look at this [Tue Aug 5 21:11:22 2014] thanks! [Tue Aug 5 21:14:26 2014] it says Error: Cannot find library Category in loadpath [Tue Aug 5 21:14:40 2014] so I tried adding that in .emacs but it doesn't work [Tue Aug 5 21:14:47 2014] maybe i have to build it [Tue Aug 5 21:14:52 2014] since Functors.v and Category.v are in the same directory [Tue Aug 5 21:14:57 2014] you shouldn't need to add any load path [Tue Aug 5 21:15:01 2014] I never did [Tue Aug 5 21:15:22 2014] ah it works after you 'make' [Tue Aug 5 21:15:29 2014] ah, ok [Tue Aug 5 21:15:48 2014] here's the further I've gotten: https://gist.github.com/08a02fcf890ade991e77 [Tue Aug 5 21:15:55 2014] which is *so* close [Tue Aug 5 21:16:05 2014] and I have the law, I just don't know how to "get it in there" [Tue Aug 5 21:16:39 2014] youre proving that natural transforms form a category [Tue Aug 5 21:16:43 2014] yes [Tue Aug 5 21:16:51 2014] well, that functors, with natural transforms as the morphisms [Tue Aug 5 21:17:06 2014] I forgot why this is true [Tue Aug 5 21:17:16 2014] when I was working in setoids I proved it easily [Tue Aug 5 21:17:24 2014] now I'm trying to do it with just propositional equality [Tue Aug 5 21:17:30 2014] I get it, you just paste the diagrams together [Tue Aug 5 21:19:46 2014] if I have ∀ X, X = ∀ X, Y, can I change that to ∀ X, X = Y? [Tue Aug 5 21:23:27 2014] I think that this is impossible [Tue Aug 5 21:23:41 2014] hmm [Tue Aug 5 21:23:51 2014] http://lpaste.net/108880 [Tue Aug 5 21:23:58 2014] I tried to make a lemma that would split the proof into parts [Tue Aug 5 21:24:07 2014] yeah, I just tried to assert that very thing [Tue Aug 5 21:24:10 2014] but naturality0 = naturality1 doesn't typecheck [Tue Aug 5 21:24:20 2014] oh, no, what I did was different [Tue Aug 5 21:24:23 2014] what was the error? [Tue Aug 5 21:24:43 2014] well basically they have different types, so you can't claim they're equal [Tue Aug 5 21:24:51 2014] one of them has transport0 in the type, the other transport1 [Tue Aug 5 21:25:19 2014] we do have a proof that these are equal, and could rewrite that into the type to say something like naturality0 = eq_ind _ _ _ _ naturality1 [Tue Aug 5 21:25:28 2014] but Coq can't deal with that sort of thing properly [Tue Aug 5 21:28:09 2014] what about something along the lines of: [Tue Aug 5 21:28:11 2014] assert (∀ f, nat_compose f nat_identity = [Tue Aug 5 21:28:12 2014] {| transport := (@transport C D A B f) ∘ id |}). [Tue Aug 5 21:28:19 2014] (left incomplete for now) [Tue Aug 5 21:30:15 2014] oh "id" is not the identify function [Tue Aug 5 21:30:24 2014] it's the identity morphism from a category [Tue Aug 5 21:30:30 2014] yeah, I just changed it [Tue Aug 5 21:31:38 2014] hmmmm [Tue Aug 5 21:36:56 2014] http://lpaste.net/108881 [Tue Aug 5 21:36:59 2014] Coq can't rewrite this [Tue Aug 5 21:37:09 2014] I'm not sure how to even prove (λ X : C, transport0 X ∘ id) = transport0 [Tue Aug 5 21:37:15 2014] yeah [Tue Aug 5 21:37:17 2014] but this same issue with the indices is a problem [Tue Aug 5 21:37:18 2014] i wonder where I've gone wrong here [Tue Aug 5 21:37:24 2014] I don't think it's you that's gone wrong [Tue Aug 5 21:37:33 2014] this is just a limitation of Coq [Tue Aug 5 21:37:49 2014] when you try to do proofs about things with dependent types it gets really stuck [Tue Aug 5 21:40:53 2014] if my natural transformations behaved like arrows on functors, rather than as dependent records, I think this would be trivial [Tue Aug 5 21:40:59 2014] that's what happened with setoids [Tue Aug 5 21:41:17 2014] i just had f ≈ f' → transport f ≈ transport f' [Tue Aug 5 21:41:23 2014] and then all the proofs were trivial [Tue Aug 5 21:41:37 2014] transport is the action of the Natural [Tue Aug 5 22:12:09 2014] bah, loop_never_stops of Imp.v is throwing me for a loop (no, not a pun) [Wed Aug 6 02:50:17 2014] johnw, vanila: To prove (λ X : C, transport0 X ∘ id) = transport0, you need the functional_extensionality axiom from FunctionalExtensionality. If you want to see where I did this, it's at https://github.com/HoTT/HoTT/blob/master/theories/categories/NaturalTransformation/Composition/Laws.v, and the classification of the equality type of natural transformations is at [Wed Aug 6 02:50:17 2014] https://github.com/HoTT/HoTT/blob/master/theories/categories/NaturalTransformation/Paths.v [Wed Aug 6 04:27:30 2014] im trying to prove that, given an order R on a set S, for any finite subset s of S, there is always an element in s such that ~ exists s', R s s' [Wed Aug 6 04:27:40 2014] this should not be too difficult right? [Wed Aug 6 04:28:14 2014] given a transitive, irreflexive order* [Wed Aug 6 04:52:25 2014] roosbeef, do you mean "for any finite subset T of S, there is always and element s in T such that ~ exists s', s' \in T /\ R s s'"? First of all, the empty subset is a counter-example. And if you're not assuming classical axioms, then you can't prove that non-empty -> has a distinguished element. If by "finite", you mean "I have a list of the elements", then you can start going somewhere. Is your order total (do you have forall x y, R x y \/ [Wed Aug 6 04:52:25 2014] R y x, or maybe R x y + R y x if you want your element constructively (using sig, rather than exist))? If so, you can just enumerate all of the elements to find the largest one, and then use the proof that it's the largest to contradict [exists s', s' \in T /\ R s s']. [Wed Aug 6 04:59:38 2014] my bad, assuming s <> nil [Wed Aug 6 05:00:14 2014] the order is partial [Wed Aug 6 05:05:02 2014] If the order isn't decidable, you can't do anything. For example, say S = nat, and R x y = (if P = NP then x < y else x > y). You're not going to be able to come up with your element unless you can also prove P = NP or P <> NP. [Wed Aug 6 05:05:43 2014] its decidable [Wed Aug 6 05:08:32 2014] Assuming it's constructively decidable, you can define pairwise-max-according-to-R, which picks, say, the first one if the elements are incomparable, and prove the properties you want about it. [Wed Aug 6 05:10:53 2014] hm [Wed Aug 6 05:10:59 2014] thats interesting [Wed Aug 6 05:11:02 2014] why pick the first? [Wed Aug 6 05:12:41 2014] Lemma always_max_elem : forall L, L <> nil -> exists e, In e L /\ not_below e L. [Wed Aug 6 05:12:59 2014] not_below : https://privatepaste.com/22a32e6e8f [Wed Aug 6 05:20:30 2014] it seems very obvious to me that this must be true [Wed Aug 6 05:21:07 2014] but somehow cant seem to prove it [Wed Aug 6 05:21:56 2014] maybe i need to define a sublemma? [Wed Aug 6 05:53:10 2014] back in a bit [Wed Aug 6 06:05:38 2014] You should be able to prove it by induction. The sublemma will be something like "for any x and any list L, together with an [e] such that [In e L /\ not_below e L], either [not_below e (x::L)] or [not_below x L]". [Wed Aug 6 06:07:07 2014] back [Wed Aug 6 06:19:19 2014] Did you see: You should be able to prove it by induction. The sublemma will be something like "for any x and any list L, together with an [e] such that [In e L /\ not_below e L], either [not_below e (x::L)] or [not_below x L]". ? [Wed Aug 6 06:23:03 2014] nope i missed that [Wed Aug 6 06:23:04 2014] hm [Wed Aug 6 06:24:14 2014] lemme see if that sublemma helps [Wed Aug 6 06:26:04 2014] is that true though? [Wed Aug 6 06:27:10 2014] why would x not_below L? [Wed Aug 6 06:59:07 2014] (back in a bit) [Wed Aug 6 07:54:01 2014] hi [Wed Aug 6 07:55:15 2014] hi [Wed Aug 6 07:56:25 2014] hello [Wed Aug 6 07:58:28 2014] haha whats up guys :p [Wed Aug 6 07:59:18 2014] well, working on http://www.cis.upenn.edu/~bcpierce/sf/current/Imp.html#lab429 [Wed Aug 6 07:59:21 2014] and being a bit stuck [Wed Aug 6 07:59:57 2014] I did "induction contra" and "inversion Heqloopdef" and then I have no idea where to go [Wed Aug 6 08:08:17 2014] I'm going to work on this too [Wed Aug 6 08:08:25 2014] I wish I had started this a couple days ago, then maybe we could discuss it [Wed Aug 6 08:08:28 2014] I'll definitely start on it today [Wed Aug 6 08:09:30 2014] maybe i can just look at it now [Wed Aug 6 08:14:44 2014] can i prove properties of non-empty lists by means of induction? [Wed Aug 6 08:17:50 2014] hodapp, I proved it [Wed Aug 6 08:18:19 2014] use induction contra; try discriminate. to start off and clear away all the nonsense cases [Wed Aug 6 08:18:37 2014] now you can use inversion Heqloopdef; subst. to make use of your structual hypotheses [Wed Aug 6 08:18:41 2014] in both remaining cases [Wed Aug 6 08:19:01 2014] both are easy, can post the script if you want to step through it [Wed Aug 6 08:19:31 2014] http://lpaste.net/108902 [Wed Aug 6 08:25:08 2014] ah, I've never heard of 'discriminate' before. [Wed Aug 6 08:26:57 2014] or perhaps I forgot. who knows... [Thu Aug 7 05:23:51 2014] what would be a good way to go about proving the following lemma [Thu Aug 7 05:23:53 2014] https://privatepaste.com/a869582a45 [Thu Aug 7 06:15:12 2014] brb [Thu Aug 7 06:55:14 2014] i think it's related to Zorn's lemma? Although i was hoping there would be a simpler way of proving it for finite sets [Thu Aug 7 07:26:49 2014] hello. is there any implementation of the pi calculus für coq? [Thu Aug 7 07:58:56 2014] ok there apparently is. thx. [Thu Aug 7 08:01:27 2014] LINK! [Thu Aug 7 08:01:57 2014] http://coq.inria.fr/V8.2pl1/contribs/PiCalc.html [Thu Aug 7 08:02:56 2014] hello. I want to prove an algorithm, but don't know how to represent my subject area. Algorithm works on direct acyclic graphs with mutable vertices. Of course, there are walking down the graph, mutating vertices' data, some global mutable state too (no threads, at least..). Which keywords can you suggest me? [Thu Aug 7 08:03:58 2014] what are "mutable vertices"? [Thu Aug 7 08:04:54 2014] vertices with mutable data associated with them. Some record with mutable fields, in my case. [Thu Aug 7 08:06:09 2014] such graph can be represented in OCaml as "type node = { children : node list ; mutable fld : int }", for example. [Thu Aug 7 08:09:52 2014] hm. mutable state is a problem I also often have to face. mostly I can somehow hack myself around it. [Thu Aug 7 08:11:01 2014] i *guess* there are som mstate monads out there. otherwise ... well, I would also be interested. something that would be nice would be uniqueness types or something like that, but it probably doesnt exist in coq. [Thu Aug 7 08:11:14 2014] what your hacks look like typically? [Thu Aug 7 08:12:21 2014] monads are not very useful -- I can manually pass state if needed, but proofs won't be much easier or harder because of such passing. [Thu Aug 7 08:12:31 2014] there are a lot of purely functional structures that one can use. balanced trees, stuff from okasaki et al. they mostly behave only linearly worse. [Thu Aug 7 08:15:21 2014] I can't avoid mutability in my OCaml version of this algorithm, and mutability adds problems in "manual" reasoning, that's why I want to use Coq here. If I could implement it in an immutable way, there were not problems, I think. [Thu Aug 7 08:15:34 2014] * there were no problems [Thu Aug 7 08:21:34 2014] for mutable recursion you usually have a loop invariant, don't you? [Thu Aug 7 08:23:55 2014] I should have it, probably. It's easier to state what was before entering function and what is after exiting. [Thu Aug 7 08:25:13 2014] maybe it would be easier to suggest something if you provided more info. [Thu Aug 7 08:26:46 2014] really. In a few minutes.. [Thu Aug 7 08:28:20 2014] I once implemented warshall in agda. the invariant there is that between any two nodes, aevery n-tuple of nodes accessing it are longer than the direct path (which was introduced), and this n increased. so, since there were only finitely many nodes, n was bounded. [Thu Aug 7 08:40:51 2014] roosbeef: https://privatepaste.com/ada8937059 (probably not the shortest way) [Thu Aug 7 08:41:38 2014] schoppenhauer: https://gist.github.com/gdsfh/b5fc400f3e931e0194ad -- it's a simple example of "what code I want to prove". (of course, this concrete example can be rewritten to avoid machine-checked proofs, but it's just an example, real code is harder.) [Thu Aug 7 08:41:39 2014] Here I want to prove that "after calling 'setmax somenode' all nodes below 'somenode' have 'fld = max(n.fld)' where n are direct and indirect children". [Thu Aug 7 08:42:15 2014] ( + fld of leaf nodes is intact.) [Thu Aug 7 08:48:17 2014] sgnb, thanks! let me have a look at that :) [Thu Aug 7 10:26:55 2014] sgnb, is your definition of nbn equivalent to not_below_nat? [Thu Aug 7 10:34:04 2014] roosbeef: it depends on what you mean by "equivalent"... it is for Coq's "<->" [Thu Aug 7 10:34:43 2014] L4 proves one way, the other way can be proven as well [Thu Aug 7 10:38:19 2014] gdsfh: mh ... you should be able to prove that the fold-max of a list is larger-or-equal to all elements of that list. [Thu Aug 7 10:39:21 2014] gdsfh: but why do you use state here? you could let setmax create a new graph. [Thu Aug 7 10:43:50 2014] sgnb, haha nice. I should probably review some of my code and try to simplify it :p [Thu Aug 7 10:45:39 2014] schoppenhauer: it was just a toy example that shows "which things I can't encode in Coq in an easy way". In the real case I need to prove things about "which vertices would be affected and how exactly" -- logic consists of misc arithmetics checks, modifying vertex data, recursions. I can't create new graph, it's not convenient for programmer who uses my code, and too costly. [Thu Aug 7 10:47:49 2014] also there are "diamonds" in DAG, so creating a new graph must care of preserving their physical sharing. [Thu Aug 7 10:59:48 2014] hm. [Thu Aug 7 11:00:31 2014] I'm not sure whether then it wouldn't be better to view the graph as a set of nodes and a set of edges, gdsfh [Thu Aug 7 11:04:42 2014] schoppenhauer: right, I've tried to do something like this, plus state passing. But: 1. it's hard to work with, 2. I need something to prove things like "eval (a := 1; a := 2) => a == 2", including not only linear sequence of "instructions", but recursive calls too, and I don't know how to represent such code in Coq. [Thu Aug 7 11:05:57 2014] and http://perso.ens-lyon.fr/jeanmarie.madiot/files/reportru.pdf doesn't help too much, or I'm too dumb to apply this approach to my task. [Thu Aug 7 11:06:18 2014] ok, I guess I can't help you, sorry. [Thu Aug 7 11:06:39 2014] no problem. [Thu Aug 7 13:49:51 2014] it looks like Coq head changes the way files are compiled a fair bit [Thu Aug 7 13:49:57 2014] by head I mean Git HEAD [Thu Aug 7 13:50:22 2014] it now doesn't find files in my current directory without -I., and it says: Error: Cannot find library Functors in loadpath, for things that I just Require [Thu Aug 7 13:57:01 2014] ah, I see the change to -I in CHANGES [Thu Aug 7 14:06:49 2014] if I say -I . -as Hask, then should I expect to be able to refer to a library Foo.v in . as Hask.Foo? [Thu Aug 7 15:31:23 2014] ok, got it all resolved [Thu Aug 7 16:18:23 2014] johnw, hey did you complete the proof about natural transforms? [Thu Aug 7 17:03:42 2014] vanila: yes [Thu Aug 7 17:03:48 2014] wow awesome! [Thu Aug 7 17:03:51 2014] I am really surprised [Thu Aug 7 17:03:57 2014] well done [Thu Aug 7 17:04:00 2014] if I have an object of type ∃ x, y, can I pluck out the x? [Thu Aug 7 17:04:14 2014] I thin that you can as long as it's into a Prop context [Thu Aug 7 17:04:19 2014] vanila: Why are you surprised? [Thu Aug 7 17:04:24 2014] vanila: well, it was Adam who solved the natural transforms proof [Thu Aug 7 17:04:24 2014] if you want to use it in a Set context you'll need { x | y } [Thu Aug 7 17:04:31 2014] ok adam can do anything [Thu Aug 7 17:04:35 2014] I was really close, but I hadn't assumed proof irrelevance [Thu Aug 7 17:04:38 2014] even if it's impossible [Thu Aug 7 17:04:43 2014] oh [Thu Aug 7 17:04:46 2014] you had to use the K axio [Thu Aug 7 17:04:46 2014] m [Thu Aug 7 17:04:53 2014] that's what I was talking about when I said "this is a limitation of Coq" [Thu Aug 7 17:05:06 2014] yeah [Thu Aug 7 17:05:43 2014] good luck with the rest of the category stuff you're doing :) [Thu Aug 7 17:05:57 2014] johnw: You might be interested in the recent thread on the coq-club mailing list about how to pull things out of props ("prop smuggling") [Thu Aug 7 17:06:14 2014] oh, nice [Thu Aug 7 17:06:21 2014] johnw: Is there any particular reason you decided to do a category theory library? [Thu Aug 7 17:06:34 2014] yes [Thu Aug 7 17:06:45 2014] edwardk is building a really cool library for Haskell called "hask" [Thu Aug 7 17:06:56 2014] based on the notion of monoidal bifunctors over enriched closed categories [Thu Aug 7 17:07:05 2014] and I want to formalize what he's doing to verify that the theory is sound [Thu Aug 7 17:07:21 2014] he's on Google hangouts with me now, and we're working on a lemma for the unique of products [Thu Aug 7 17:07:41 2014] * waves hello [Thu Aug 7 17:07:43 2014] Any particular reason you decided to start from scratch, rather than base it on one of the existing libraries? [Thu Aug 7 17:07:52 2014] *waves back* [Thu Aug 7 17:07:57 2014] yeah, we're working on a really small subset of what the existing libraries try to deal with [Thu Aug 7 17:08:06 2014] and I wanted to end up with something that you could read side-by-side with the Haskell [Thu Aug 7 17:08:22 2014] i do all the category theory in hask in a slightly odd way, all the category theory is curried -- since i only work with locally small categories and this leads to a very nice way to talk about the yoneda lemma, etc. [Thu Aug 7 17:08:31 2014] What are monoidal bifunctors over enriched closed categories [Thu Aug 7 17:08:48 2014] well, its not quite that =) [Thu Aug 7 17:09:08 2014] ooh, do correct me! [Thu Aug 7 17:09:31 2014] i do a lot of stuff encoding things as monoids over monoidal categories. e.g. haskell's applicative is a monoid for day convolution, monads are monoids for compose, etc. [Thu Aug 7 17:10:26 2014] Wow, that sounds really neat :) [Thu Aug 7 17:10:36 2014] Also, I suspect you're going to run into a lot of trouble with speed when you try to formalize enriched categories (at least, if you go through monoidal categories). Things are better in trunk than in 8.4, but when I did monoidal and enriched categories in https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/MonoidalCategory.v?at=default, my definition of monoidal categories (not even doing anything with them) [Thu Aug 7 17:10:36 2014] took around 35 seconds to compile. [Thu Aug 7 17:11:38 2014] the first version of hask deliberately conflated the notion of a kind in haskell with a category, this made for a very nice way to talk about functors over any argument, etc. without burden, but parametricity is a poor proxy for naturality. it is too strong and too weak at the same time [Thu Aug 7 17:11:52 2014] jgross: I switched to trunk about an hour ago :) [Thu Aug 7 17:11:57 2014] so in that pseudo-category theory we get limits that are too strong to express products, the yoneda lemma, etc. [Thu Aug 7 17:12:05 2014] but which are very nice to talk about haskell stuff [Thu Aug 7 17:12:21 2014] then i went back and did a more correct form of category theory to compare and contrast for folks [Thu Aug 7 17:12:34 2014] to show _why_ limits have the structure they do, why parametricity isn't naturality [Thu Aug 7 17:12:45 2014] and to drive home the need for the different distinctions [Thu Aug 7 17:12:52 2014] that is the form john is writing up in coq now [Thu Aug 7 17:12:59 2014] day convolution? [Thu Aug 7 17:13:04 2014] What a cool projec [Thu Aug 7 17:13:05 2014] t [Thu Aug 7 17:13:18 2014] vanila: https://github.com/jwiegley/category-theory [Thu Aug 7 17:13:20 2014] instead of bifunctors what we do is functors to a functor category, so we are doing 'curried' category theory [Thu Aug 7 17:13:25 2014] yeah I have it bookmarked :) [Thu Aug 7 17:13:28 2014] and https://github.com/ekmett/hask [Thu Aug 7 17:13:30 2014] which is an application of the yoneda lemma [Thu Aug 7 17:13:41 2014] which is sound in the case where our categories are all locally small [Thu Aug 7 17:14:06 2014] then the yoneda embedding _is_ the notion of an opposite category for us, since it just curries backwards [Thu Aug 7 17:14:11 2014] and we're already curried [Thu Aug 7 17:14:33 2014] so ∃ x : A, y doesn't have the type { x : A & y }? projT1 isn't working on the former [Thu Aug 7 17:14:46 2014] exists is in Prop isn't it? [Thu Aug 7 17:14:59 2014] and we have no projects for Prop, do we [Thu Aug 7 17:14:59 2014] http://coq.inria.fr/library/Coq.Init.Logic.html [Thu Aug 7 17:15:03 2014] projections [Thu Aug 7 17:15:03 2014] Inductive ex (A:Type) (P:A -> Prop) : Prop := [Thu Aug 7 17:15:03 2014] ex_intro : forall x:A, P x -> ex (A:=A) P. [Thu Aug 7 17:15:11 2014] you can project as long as you only use it in proofs [Thu Aug 7 17:15:17 2014] ah [Thu Aug 7 17:15:22 2014] I need to project to state the lemma [Thu Aug 7 17:15:22 2014] so you might need to change to subset from Specif, instead of exists [Thu Aug 7 17:15:53 2014] The yoneda embedding is currying/opposite categories? (Yoneda is the one bit of category theory that I really don't understand, despite having formalized it. (The rest of category theory that I have no clue about, it's because I haven't formalized it yet.)) [Thu Aug 7 17:16:02 2014] but then the 'old' notion of parametricity instead of naturality can possibly be salvaged by doing _more_ non-standard category theory, by tyiong the notion of variance to the objects, then Nat ceases to be what you're used to, loses its terminal and initial object and becomes to adjoined copies of Nat varying by variance, etc. [Thu Aug 7 17:16:25 2014] If we write down a category C in terms of a bifunctor C^op -> [ C, Set ] [Thu Aug 7 17:16:32 2014] note we've curried the bifunctor here [Thu Aug 7 17:16:41 2014] its not going from (C^op * C) -> Set [Thu Aug 7 17:16:43 2014] You might understand Yoneda better if you do it on paper [Thu Aug 7 17:16:47 2014] but rather its a functor to the functor category [Thu Aug 7 17:17:01 2014] then the definition of a category is already going through one form of the yoneda embedding! [Thu Aug 7 17:17:06 2014] in the other direction [Thu Aug 7 17:17:27 2014] I see [Thu Aug 7 17:17:28 2014] Yoneda :: C -> [C^op, Set] -- takes an object in the category c to Hom(_, c) [Thu Aug 7 17:17:32 2014] the presheaves on C [Thu Aug 7 17:17:39 2014] the arrows that end at c [Thu Aug 7 17:18:00 2014] in the encoding above, if C^op^op = C then you get Yoneda = ^op [Thu Aug 7 17:18:17 2014] it becomes our opposite category [Thu Aug 7 17:18:35 2014] then the yoneda lemma lets you go back and forth between Nat (p a) f and f a [Thu Aug 7 17:18:46 2014] for some category p [Thu Aug 7 17:18:49 2014] sheaves are the thing I don't understand/scared of [Thu Aug 7 17:18:54 2014] sheaves are boring [Thu Aug 7 17:19:03 2014] well [Thu Aug 7 17:19:05 2014] presheaves are [Thu Aug 7 17:19:08 2014] sheaves are terrifying [Thu Aug 7 17:19:14 2014] presheaves are 'functors to set' [Thu Aug 7 17:19:29 2014] any functor f :: C^op -> Set -- is a presheave [Thu Aug 7 17:19:33 2014] er presheaf [Thu Aug 7 17:19:42 2014] ay functor C -> Set is a copresheaf [Thu Aug 7 17:20:03 2014] oh that's simple then :) [Thu Aug 7 17:20:16 2014] representable presheaves are the ones that look like Hom(_,c) for some c [Thu Aug 7 17:20:19 2014] <__cody__> often called a "covariant presheaf" [Thu Aug 7 17:20:31 2014] edwardk: in the encoding above, if C^op^op = C then you get Yoneda = ^op <- Isn't C^op^op always C? And ^op is a functor Cat -> Cat. Yoneda is a functor C -> [C^op, Set]. How can Yoneda = ^op? [Thu Aug 7 17:21:01 2014] jgross: yes C^op^op = C [Thu Aug 7 17:21:14 2014] i was using that as a lemma you give yourself to show that Yoneda above is describing the opposite category [Thu Aug 7 17:21:41 2014] Yoneda C is now a category that when you apply it to one object gives you a presheaf [Thu Aug 7 17:21:52 2014] becuase in this world our categories are functors [Thu Aug 7 17:21:59 2014] C^op -> [C, Set] [Thu Aug 7 17:22:20 2014] Then Yoneda_C :: C -> [C^op, Set] [Thu Aug 7 17:22:44 2014] is a functor that you can partially apply to one argument to get an object in [C^op, Set] which is a functor from C^op -> Set [Thu Aug 7 17:23:17 2014] <__cody__> It's kind of like defining a category to be "that for which op satisfies the Yoneda lemma" [Thu Aug 7 17:23:18 2014] our categories are functors with a few extra conditions on them basically [Thu Aug 7 17:23:27 2014] __cody__: yeah [Thu Aug 7 17:23:35 2014] __cody__: categories are where the yoneda lemma holds [Thu Aug 7 17:23:38 2014] =) [Thu Aug 7 17:23:41 2014] <__cody__> hehe [Thu Aug 7 17:23:56 2014] which is a perfectly cromulent way to do category theory [Thu Aug 7 17:24:12 2014] that's tricky [Thu Aug 7 17:24:14 2014] but it also means we're not farting around with products all the time [Thu Aug 7 17:24:18 2014] so everything stays curried [Thu Aug 7 17:24:24 2014] which makes it very nice to work with [Thu Aug 7 17:24:35 2014] you can now define Functor Either, Functor (Either a) -- etc. [Thu Aug 7 17:24:39 2014] and the former makes use of the latter [Thu Aug 7 17:25:14 2014] then the number of times you use transport determines which argument you are focalizing on [Thu Aug 7 17:25:23 2014] How does this definition of categories relate to the standard one? [Thu Aug 7 17:25:42 2014] and bimap, etc. for bifunctors is defined in terms of using the functors you map to as well as the outer form [Thu Aug 7 17:26:24 2014] well, this form of category is what you get if you go back and forth by currying the usual definition of Hom as a bifunctor through the internal hom of Cat, which you can do for locally small categories. [Thu Aug 7 17:26:53 2014] you need to know that the set of arrows between any two objects is formally "small enough" and this encoding works [Thu Aug 7 17:27:13 2014] since we're working in internal category / constructive hell? we're pretty much always going to be small enough [Thu Aug 7 17:27:55 2014] in haskell i do most of my work in terms of bicategories, i build the tower of naturality up, then i work with explicit 1-morphisms for Compose or for profunctor composition [Thu Aug 7 17:28:31 2014] and then all my monoids are w.r.t. these weak monoidal structures, so everything becomes weak with explicit associators [Thu Aug 7 17:28:34 2014] and unitors [Thu Aug 7 17:28:35 2014] you mean normal programming? [Thu Aug 7 17:28:49 2014] yes =) [Thu Aug 7 17:29:09 2014] that sounds really interesting, do you have some example of that around? [Thu Aug 7 17:29:24 2014] so the main difference is that we build profunctors 'backwards' from the usual category theory definition [Thu Aug 7 17:29:36 2014] sure [Thu Aug 7 17:29:41 2014] let me dig up monads in hask [Thu Aug 7 17:30:17 2014] https://github.com/ekmett/hask/blob/master/src/Hask/Tensor/Compose.hs#L134 [Thu Aug 7 17:30:45 2014] Compose itself isn't 'on the nose' [Thu Aug 7 17:31:12 2014] here's Day convolution which is less magic right now: https://github.com/ekmett/hask/blob/master/src/Hask/Tensor/Day.hs#L16 [Thu Aug 7 17:31:40 2014] the monoids of Day convolution are applicatives (lax closed functors with strength) [Thu Aug 7 17:32:11 2014] in contravariant form you get some stuff that is going into my contravariant package, which are contravariant applicatives, etc. [Thu Aug 7 17:35:30 2014] anyways, i find it to be a nice encoding of category theory in haskell because then you can just use kinds as an approximation of category sans info on variance, morphisms, etc. and refine it with a category [Thu Aug 7 17:39:04 2014] yeah - it's really interesting turning things upside down like that [Thu Aug 7 17:39:11 2014] how do you come up with this stuff :) [Thu Aug 7 17:39:37 2014] i spend a lot of time building things up sideways to work around haskell ;) [Thu Aug 7 17:40:13 2014] i gave a talk on hask when i had it wired up deliberately wrong a couple of weeks ago [Thu Aug 7 17:40:41 2014] https://www.youtube.com/watch?v=Klwkt9oJwg0&feature=youtu.be [Thu Aug 7 18:35:05 2014] if my goal is { a : { b : B, c }, d }, how do I provide a value of the sigma type using exists? [Thu Aug 7 18:35:27 2014] conversely, how do I break it apear so that I can use exists on the argument, making it into a goal? [Thu Aug 7 18:35:31 2014] you could assert { b : B, c } as H [Thu Aug 7 18:35:32 2014] prove that [Thu Aug 7 18:35:35 2014] then exists H [Thu Aug 7 18:35:36 2014] ah [Thu Aug 7 18:35:36 2014] and prove d [Thu Aug 7 18:35:39 2014] thank you [Thu Aug 7 18:36:05 2014] perfect [Thu Aug 7 18:41:27 2014] vanila: in https://github.com/jwiegley/category-theory/blob/master/Products.v#L75 [Thu Aug 7 18:41:38 2014] I have a proof where I've asserted the same object to two sigmas [Thu Aug 7 18:41:51 2014] and yet, Coq does not preserve their identity, forcing me to have to elaborate [Thu Aug 7 18:42:00 2014] is there any way unify the two choices of 'h' that I have there? [Thu Aug 7 18:42:10 2014] you'll see what I mean if you step through the proof [Thu Aug 7 18:42:11 2014] let me try running it [Thu Aug 7 18:43:56 2014] "coqc" -Q . Hask CpdtTactics [Thu Aug 7 18:43:56 2014] coqc: -Q: no such file or directory [Thu Aug 7 18:43:56 2014] Makefile.coq:251: recipe for target 'CpdtTactics.vo' failed [Thu Aug 7 18:43:59 2014] this wasnt happening last time [Thu Aug 7 18:44:02 2014] sorry [Thu Aug 7 18:44:05 2014] I'm using the HEAD version of Coq [Thu Aug 7 18:44:26 2014] I needed universe polymorphism [Thu Aug 7 19:22:54 2014] if I have (λ x : Z, f (g1 x)) = (λ x : Z, f (g2 x)) in my context, how can I invent an x to apply to both sides? In the goal I'd use extensionality [Thu Aug 7 19:24:00 2014] I think that is an axiom: (forall x, f x = g x) -> f = g [Thu Aug 7 19:24:04 2014] which is not part of coqs theory [Thu Aug 7 19:24:13 2014] so you would just apply that axiom [Thu Aug 7 19:24:24 2014] that's called functional_extensionality_dep I believe [Thu Aug 7 19:24:30 2014] using axioms could cause problems (blocking reduction) though [Thu Aug 7 19:24:33 2014] no, just functional_extensionality [Thu Aug 7 19:24:34 2014] http://coq.inria.fr/library/Coq.Logic.FunctionalExtensionality.html [Thu Aug 7 19:25:05 2014] but applying it to the context does not work [Thu Aug 7 19:25:09 2014] it says "Unable to unify" [Thu Aug 7 19:25:12 2014] hm [Thu Aug 7 19:25:16 2014] maybe instantiate it [Thu Aug 7 19:25:19 2014] like [Thu Aug 7 19:25:45 2014] apply (functional_extensionality (λ x : Z, f (g1 x)) (λ x : Z, f (g2 x))). [Thu Aug 7 19:26:38 2014] Unable to unify "(λ x : Z, f (g1 x)) = (λ x : Z, f (g2 x))" with "g1 e = g2 e". [Thu Aug 7 19:27:01 2014] i tihnk those f applications are causing me trouble [Thu Aug 7 19:27:07 2014] what about just looking at [Thu Aug 7 19:27:11 2014] pose (functional_extensionality (λ x : Z, f (g1 x)) (λ x : Z, f (g2 x))). [Thu Aug 7 19:27:16 2014] thanks [Thu Aug 7 19:27:20 2014] and seeing if it looks the same as what you have in the goal [Thu Aug 7 19:27:41 2014] it looks identity to what I have in the context [Thu Aug 7 19:28:21 2014] ah [Thu Aug 7 19:28:26 2014] (∀ x : Z, f (g1 x) = f (g2 x)) → (λ x : Z, f (g1 x)) = (λ x : Z, f (g2 x)) [Thu Aug 7 19:28:30 2014] that is indeed something I want [Thu Aug 7 19:39:30 2014] given a hypothesis of the form ∀ x y : X, f x = f y → x = y [Thu Aug 7 19:39:40 2014] can I have Coq invent two variables of type X? [Thu Aug 7 19:39:50 2014] I want something like especialize H. [Thu Aug 7 20:17:35 2014] johnw: Try [eapply f_equal in H]. (This would be functional extensionality in the goal, but it's f_equal in a hypothesis, because you're going the other way.) For your other question, are you looking for [evar (x : X)]? [Thu Aug 7 20:20:31 2014] yeah we found that one, if you pull you should see it [Thu Aug 7 20:20:55 2014] evar we didn't find [Thu Aug 7 20:45:28 2014] ok, it's pushed [Thu Aug 7 20:45:58 2014] extensionality e; apply H; apply (equal_f H0). was the magic sauce we needed [Thu Aug 7 23:39:07 2014] hello. Now I need a hack (if it exists). Can something in Coq be used as "unique identifiers"? Say, I have "Definition id1 := . Definition id2 := ." and then I can use in proofs facts like "idN = idN" and "idN <> idM where N<>M". [Thu Aug 7 23:50:00 2014] is there a way to ask Proof General to not be so eager about clearing the response buffer? [Thu Aug 7 23:50:16 2014] as soon as I start typing it clears it, and yet 99% of the time I want to do further editing based on what I had seen there [Fri Aug 8 01:21:51 2014] if i have (∃ x0 : X, f x0 = f e) = True in my goal, and an e : X in my context, what tactic can I use? [Fri Aug 8 01:23:35 2014] it's like I want to check if both sides of the equality are the same, but separately [Fri Aug 8 01:23:53 2014] I can easily prove that the left side is True, but I can't rewrite to show True = True [Fri Aug 8 01:33:00 2014] still playing with surjectivity? [Fri Aug 8 01:33:09 2014] I feel like I'm almost there [Fri Aug 8 01:33:29 2014] the goal is obviously true, I just don't know what to tell coq to turn the left side into True [Fri Aug 8 01:33:34 2014] good luck, going to go sleep. medication/being sick sucks. [Fri Aug 8 01:33:42 2014] sleep well, edwardk! thanks for today [Fri Aug 8 01:33:47 2014] np [Fri Aug 8 01:33:53 2014] we'll get there! [Fri Aug 8 01:34:02 2014] indeed [Fri Aug 8 01:34:08 2014] we made huge progress today [Fri Aug 8 02:14:53 2014] given that 'e : X' is in my context, why isn't it obvious that (∃ x0 : X, f x0 = f e) = (f e = f e)? [Fri Aug 8 02:18:40 2014] said more generally: [Fri Aug 8 02:18:42 2014] Lemma existence_exists {A} (a : A) (P : A → Prop) : (∃ y : A, P y) = P a. [Fri Aug 8 03:32:34 2014] those types might be logically equivalent, but surely not equal [Fri Aug 8 03:32:58 2014] unless A is an hProp too [Fri Aug 8 03:33:20 2014] (and we're using univalence) [Fri Aug 8 03:35:53 2014] uh, i guess another case is when P x = x = z, which is your case :) [Fri Aug 8 03:37:14 2014] how could P x = x [Fri Aug 8 03:37:36 2014] P x = (x = z) [Fri Aug 8 03:37:43 2014] ohh [Fri Aug 8 03:37:44 2014] haha [Fri Aug 8 03:38:05 2014] sorry im at a caffeine defficiency :p [Fri Aug 8 04:44:13 2014] gdsfh: define an inductive type with constant constructors [Fri Aug 8 04:45:03 2014] (as in: "Inductive foo := id1 | id2") [Fri Aug 8 05:00:11 2014] sgnb: really, thanks. /me feels too dumb. [Fri Aug 8 06:29:03 2014] how do i prove incomparability is transitive in a partial strict order? [Fri Aug 8 06:38:57 2014] it's not in general: consider a, b, c s.t. a < b, a is incomparable to c, c is incomparable to b, but a is comparable to b [Fri Aug 8 06:42:17 2014] is partial strict order and weak strict order the same? [Fri Aug 8 06:42:19 2014] https://en.wikipedia.org/wiki/Weak_ordering [Fri Aug 8 06:42:31 2014] here it says incomparability is transitive in such an order [Fri Aug 8 06:44:01 2014] or am i misreading that? [Fri Aug 8 06:57:09 2014] no, a weak strict order is precisely a partial strict order which additionaly satisfies transitivity for incomparability. You cannot derive it, you have to assume it. [Fri Aug 8 06:57:53 2014] oh haha [Fri Aug 8 07:13:46 2014] johnw: is there a way to ask Proof General to not be so eager about clearing the response buffer? <- Submit a feature request on the bug tracker? [Fri Aug 8 07:16:04 2014] johnw: The axiom you're looking for is called propositional extensionality. It says (forall P Q : Prop, (P <-> Q) -> P = Q). [Fri Aug 8 07:16:44 2014] are there any examples of well-founded recursion in coq online except http://adam.chlipala.net/cpdt/html/GeneralRec.html ? [Fri Aug 8 08:03:44 2014] roosbeef: I have an implementation of quick-select on a vector at https://github.com/JasonGross/ClosestPoints/blob/master/VectorQuickSelect.v, see [vector_quick_select] at the bottom, but it's not particularly pretty or well-documented. [Fri Aug 8 08:08:41 2014] jgross, thank you [Fri Aug 8 08:09:49 2014] jgross, how much more difficult would you say is it to use wf recursion compared to standard recursion [Fri Aug 8 08:16:25 2014] brb [Fri Aug 8 11:27:56 2014] jgross: ahhhh, thank you [Fri Aug 8 14:54:14 2014] johnw: ping [Fri Aug 8 17:03:29 2014] edwardk: pog [Fri Aug 8 17:15:59 2014] edwardk: you pinged? [Fri Aug 8 17:16:10 2014] yeah was going to check in on the state of things [Fri Aug 8 17:16:18 2014] I completed the proofs we were working on [Fri Aug 8 17:16:21 2014] but distracted by the chatter on #nothaskell [Fri Aug 8 17:16:22 2014] and all the admitted ones [Fri Aug 8 17:16:27 2014] :) [Fri Aug 8 17:16:30 2014] it was good chatter [Fri Aug 8 17:16:32 2014] did you figure out surjective? [Fri Aug 8 17:16:41 2014] I did, but again I needed an axiom, but I don't like it at all [Fri Aug 8 17:16:47 2014] so I asked the mailing list for help [Fri Aug 8 17:16:56 2014] this axiom is unacceptable pretty much [Fri Aug 8 17:17:07 2014] yeah [Fri Aug 8 17:17:08 2014] see if you can think of a better way to progres... [Fri Aug 8 17:17:25 2014] https://github.com/jwiegley/category-theory/blob/master/Products.v#L261 [Fri Aug 8 17:17:36 2014] so, for the g1 and g2 I picked functions returning propositions [Fri Aug 8 17:17:51 2014] since I think it would be easy enough to yield two things that were both True [Fri Aug 8 17:17:54 2014] s/think/thought [Fri Aug 8 17:18:29 2014] however, without propositional extensionality I run into the same problem I did with functional extensionality: how to identify two propositions as equal [Fri Aug 8 17:18:46 2014] so I think the real answer is a better choice of functions [Fri Aug 8 17:20:39 2014] ok, heading home [Fri Aug 8 17:20:42 2014] k [Fri Aug 8 17:21:06 2014] i'll be on later this evening, if you want to hack some more [Fri Aug 8 17:43:20 2014] johnw: I'm confused why you need propositional extensionality [Fri Aug 8 17:43:35 2014] did you see the proof on coq-club? [Fri Aug 8 17:43:42 2014] um [Fri Aug 8 17:43:44 2014] no [Fri Aug 8 17:44:08 2014] https://github.com/jwiegley/category-theory/blob/master/Products.v#L235 [Fri Aug 8 17:44:11 2014] that's the context [Fri Aug 8 17:44:20 2014] I would like to do away with that lemma [Fri Aug 8 17:44:30 2014] is this the cody that I met at Hac Boston? [Fri Aug 8 17:44:33 2014] yes [Fri Aug 8 17:44:38 2014] hello!! [Fri Aug 8 17:44:40 2014] hi [Fri Aug 8 17:44:41 2014] it was great meeting you [Fri Aug 8 17:44:45 2014] same here! [Fri Aug 8 17:44:50 2014] I like the way you pronounce 'Coq' :) [Fri Aug 8 17:45:01 2014] it's hard to find a balance [Fri Aug 8 17:45:20 2014] the lemma looks a bit strange [Fri Aug 8 17:45:32 2014] i didn't run your file though [Fri Aug 8 17:45:40 2014] it needs the HEAD version of Coq to compile [Fri Aug 8 17:46:16 2014] how come? [Fri Aug 8 17:46:25 2014] i'm using universe polymorphism now [Fri Aug 8 17:46:34 2014] in order to have the category of categories [Fri Aug 8 17:47:17 2014] ah ok [Fri Aug 8 17:47:27 2014] I should really try to sell you on Lean [Fri Aug 8 17:47:31 2014] :) [Fri Aug 8 17:47:41 2014] i'm open to learning most anything in this space at the moment [Fri Aug 8 17:47:42 2014] but that debate is for another time [Fri Aug 8 17:47:59 2014] i don't see why you need this property [Fri Aug 8 17:48:24 2014] down on line 268 [Fri Aug 8 17:48:50 2014] I end up with a goal of: (∃ x0 : X, f x0 = f e) = (f e = f e [Fri Aug 8 17:48:53 2014] ) [Fri Aug 8 17:49:14 2014] giving 'e' to the left-hand side yields the equality I need [Fri Aug 8 17:49:28 2014] http://pastebin.com/hHh1yJtK [Fri Aug 8 17:50:14 2014] that goal is weird [Fri Aug 8 17:50:32 2014] one sec, let me chew on this [Fri Aug 8 17:50:37 2014] it's strange to end up with an equality between propositions as a goal [Fri Aug 8 17:51:30 2014] I don't have surj_f in my context [Fri Aug 8 17:51:32 2014] here is what I have: [Fri Aug 8 17:51:38 2014] https://gist.github.com/8cdcd6aae521f0b42aa5 [Fri Aug 8 17:52:04 2014] oh [Fri Aug 8 17:52:09 2014] i'm proving the other direction: given a surjective function, it is epi [Fri Aug 8 17:52:09 2014] that's not provable [Fri Aug 8 17:52:12 2014] oh? [Fri Aug 8 17:52:21 2014] it's false in some sense [Fri Aug 8 17:52:27 2014] surjective is really strong [Fri Aug 8 17:52:31 2014] more than epi [Fri Aug 8 17:52:32 2014] it's provable with propositional extensionality.... :) [Fri Aug 8 17:52:46 2014] it's true in SET [Fri Aug 8 17:52:50 2014] yes [Fri Aug 8 17:52:54 2014] I'm only proving it for Set [Fri Aug 8 17:52:57 2014] it's false in TOP [Fri Aug 8 17:53:10 2014] right, I've read about that in Awodey [Fri Aug 8 17:53:10 2014] in Coq, Sets behaves like TOP sometimes [Fri Aug 8 17:53:14 2014] oh? [Fri Aug 8 17:53:34 2014] intuitionistic logic is a bit closer to topolgy [Fri Aug 8 17:53:52 2014] but let me mull over it for a second [Fri Aug 8 17:54:00 2014] maybe i'm being stupid [Fri Aug 8 17:54:08 2014] cody__, isn't that the whole basis of topos theory? [Fri Aug 8 17:54:32 2014] one thing for sure: epi + mono -/-> iso [Fri Aug 8 17:54:39 2014] yea [Fri Aug 8 17:55:12 2014] basically, being a continuous bijection doesn't make you an isomorphism in TOP [Fri Aug 8 17:55:22 2014] which is the source of all weirdness [Fri Aug 8 18:00:18 2014] http://math.stackexchange.com/questions/81123/examples-of-categories-where-epimorphism-does-not-have-a-right-inverse-not-surj [Fri Aug 8 18:00:27 2014] this explains it better than I can [Fri Aug 8 18:04:26 2014] basically you need some form of the excluded middle [Fri Aug 8 20:27:29 2014] johnw: You can do it without that axiom if you only care about sets where you can decide whether or not an element is in the image of a function: https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/SetCategoryFacts.v?at=default#cl-120. You can do it with univalence and higher inductive types (which give you a nicer form of propositional extensionality): [Fri Aug 8 20:27:29 2014] https://github.com/HoTT/HoTT/blob/402eacdd7d19132d2040bd8d1ddd6ca9253f78d6/theories/hit/epi.v#L60, although things will go wrong quickly without an impredicative hProp. You can also do it via pushouts and cones (also via higher inductive types and univalence): https://github.com/HoTT/HoTT/blob/master/theories/hit/epi.v#L163. You're not going to be able to avoid using axioms, except (maybe) by using setoids, or by restricting your attention to a [Fri Aug 8 20:27:29 2014] decidable subset. [Fri Aug 8 20:43:14 2014] ok [Fri Aug 8 20:43:17 2014] i started out with setoids, but abandoned them to due to their added complexity and slowness [Fri Aug 8 23:43:00 2014] johnw: How attached are you to not using axioms? If you're willing to use axioms whose computational interpretation is still being figured out, use higher inductive types, which give you all the benefit of setoids without any of the slowdown (by pushing the complexity into the metatheory). [Sat Aug 9 00:00:46 2014] jgross: I'm certainly attracted to the idea of higher inductive types [Sat Aug 9 00:00:49 2014] if I keep hitting snags, I'll head that route [Sat Aug 9 07:03:23 2014] Hello all. [Sat Aug 9 07:03:39 2014] I am reading the second chapter of software foundation. [Sat Aug 9 07:04:06 2014] Could some one please give me the little hint about solving the theorem [Sat Aug 9 07:04:12 2014] m * n = n * m [Sat Aug 9 07:04:32 2014] One way I can thing of is destruct m [Sat Aug 9 07:04:39 2014] and follow both cases [Sat Aug 9 07:06:07 2014] first case is reflexivity [Sat Aug 9 07:06:23 2014] but I am stuck with S m' * n = n * S m' [Sat Aug 9 07:46:17 2014] Induction.v, mult_comm? [Sat Aug 9 07:49:07 2014] Theorem mult_comm : ∀m n : nat, m × n = n × m. [Sat Aug 9 10:11:58 2014] is it possible to give an explicit data type into which a coq datatype has to be extracted? [Sat Aug 9 10:12:47 2014] for example, I want to prove stuff about bytes. therefore, I want a vec 8 to extract to a Byte in Haskell, not a vector. [Sat Aug 9 10:12:50 2014] vec 8 bool [Sat Aug 9 10:13:07 2014] or vec bool 8, whatever ... [Sat Aug 9 10:14:01 2014] probably by giving explicit realizers for functions and constructors or so. [Sat Aug 9 10:35:58 2014] The problem I see is that bytes are fast to inc/dec, but also fast bitwise ops. and this cannot be directly mapped to coq. [Sat Aug 9 10:58:29 2014] hm. nobody here? [Sat Aug 9 12:48:49 2014] do we have a nth function in stdlib that takes a proof n < length l and removes default argument? [Sat Aug 9 13:55:59 2014] osa1: no, but there is nth_error. [Sat Aug 9 13:56:11 2014] and iirc there are lemmata about nth_error that say this. [Sat Aug 9 13:56:14 2014] so it is easy to build. [Sat Aug 9 14:21:53 2014] so ... anyone knows how to represent bytes? [Sat Aug 9 15:03:01 2014] ok. it would be helpful to have a possibility to extract nat to the native ints of haskell. [Sat Aug 9 15:04:33 2014] I found http://flint.cs.yale.edu/cs428/coq/doc/Reference-Manual021.html can I do Extract Inductive nat "int" ["0" "(1 +)"] ? [Sat Aug 9 15:04:36 2014] or something similar? [Sat Aug 9 15:04:44 2014] and give explicit realizers of *, /, etc.? [Sat Aug 9 15:05:29 2014] for the latter thing, I don't know how to do this. there is Extract Constant. [Sat Aug 9 15:06:24 2014] Would Extract Constant mult "'x" "'y" "'x * 'y" [Sat Aug 9 15:06:43 2014] work? [Sat Aug 9 15:06:58 2014] even though the multiplication is given as a function? [Sat Aug 9 15:13:35 2014] yay. I'm working on my first non-trivial correctness proof and I have two lemmas left (unless I need more lemmas to prove them) I had to define 13 lemmas in total [Sat Aug 9 15:17:48 2014] ah ok, according to http://www.seas.upenn.edu/~cis500/current/sf/Extraction.html [Sat Aug 9 15:19:01 2014] it worx [Sat Aug 9 15:19:21 2014] have to try it. [Sat Aug 9 17:24:59 2014] can anyone help me prove this http://lpaste.net/109134? [Sat Aug 9 17:56:16 2014] in general, to prove something about a function defined in terms of auxiliary functions, you need to prove an auxiliary lemma [Sat Aug 9 17:56:38 2014] in this case, you need to find some invariant for find_min_idx_aux [Sat Aug 9 18:08:49 2014] by the way, it would probably help a lot if member had an extra argument which gave the position [Sat Aug 9 18:09:15 2014] osa1 [Sat Aug 9 18:09:48 2014] this is really hard to prove, it's not clear what kind of induction you should use [Sat Aug 9 18:10:13 2014] trying to prove things about find_min_idx_aux by induction on l doesn't seem to work [Sat Aug 9 18:13:37 2014] vanila: yeah. I tried induction on everything in that context. [Sat Aug 9 18:13:46 2014] I also tried induction on length l [Sat Aug 9 18:14:00 2014] I tried functional induction scheme but it doesn't seem to work either [Sat Aug 9 18:14:17 2014] i would rewrite the function so its easier to prove things about [Sat Aug 9 18:15:01 2014] its kind of bugging me though, this shouldn't be hard to prove things about... [Sat Aug 9 18:15:05 2014] I can change the aux one but other one should stay same [Sat Aug 9 18:15:17 2014] yeah, as cody said aux is the only one that matters [Sat Aug 9 18:15:38 2014] okay, so how can I make proving easier? [Sat Aug 9 18:22:28 2014] osa1: find the invariant you want to prove about aux [Sat Aug 9 18:22:32 2014] make it a lema [Sat Aug 9 18:22:34 2014] lemma [Sat Aug 9 19:16:12 2014] osa1, have you had any luck yet? [Sat Aug 9 20:36:23 2014] I'm having trouble with recursion when defining a fixpoint [Sat Aug 9 20:37:51 2014] I have a function f, in some cases a call f x is resolved to f (g y) where y is part of x and g does not increase the size of y, but coq does not recognize that this argument is decreasing.. is there any way to do that or do I have to try another approach? [Sat Aug 9 20:40:16 2014] coq just looks for structurally decreasing recursive calls [Sat Aug 9 20:41:01 2014] for something like this you might need to use mutual recursion with g, or if that's not the case use a well founded measure (proving that g y is smaller than x) or Equations which automates that stuff [Sat Aug 9 20:41:35 2014] what's Equations? [Sat Aug 9 20:44:48 2014] it's from the stdlib? [Sat Aug 9 21:01:30 2014] I guess I'll have to try to use well-foundedness [Sun Aug 10 01:01:04 2014] trap_exit: welcemoe [Sun Aug 10 01:01:16 2014] johnw: did you also write git from the bottom up? [Sun Aug 10 01:01:20 2014] I did [Sun Aug 10 01:01:27 2014] let's talk git in #coq! [Sun Aug 10 01:01:28 2014] i'm kidding [Sun Aug 10 01:01:32 2014] haha [Sun Aug 10 01:01:37 2014] back to Coq, so dyou do you performance debug ltac ? [Sun Aug 10 01:01:41 2014] I do [Sun Aug 10 01:01:42 2014] I had problems with it in proof general [Sun Aug 10 01:01:48 2014] where it shows me how the ltac script does its work [Sun Aug 10 01:01:49 2014] when crush is really slow, I first think about my hint databases [Sun Aug 10 01:01:52 2014] but i found it useless [Sun Aug 10 01:01:56 2014] and whether I should be using Hint Immediate instead of Hint Resolve [Sun Aug 10 01:02:11 2014] plus, some rewrite rules should be in specific databases, and not fire generally [Sun Aug 10 01:02:23 2014] what key is that in PG? [Sun Aug 10 01:02:54 2014] I do not recall; I stopped using proof-general/ltac a while back [Sun Aug 10 01:03:23 2014] ah. I spent 12 hours on Friday in PG [Sun Aug 10 01:03:31 2014] it's so hard to stop working on proofs [Sun Aug 10 01:03:47 2014] the 'video game' effect ? [Sun Aug 10 01:03:50 2014] yep [Sun Aug 10 01:03:51 2014] try working on this one: [Sun Aug 10 01:04:14 2014] forall a, b, c, n: a >= 2, b >= 2, c >= 2, n >= 3: a^n + b^n != c^n [Sun Aug 10 01:04:15 2014] whoever thought of color the background blue when you hit period was genius [Sun Aug 10 01:04:24 2014] hahaha [Sun Aug 10 01:04:44 2014] i recognize the lemma, but have forgotten the name [Sun Aug 10 01:04:53 2014] Fermat's Last Theorem [Sun Aug 10 01:04:55 2014] auto. [Sun Aug 10 01:05:03 2014] really_crush [Sun Aug 10 01:05:13 2014] skynet_crush [Sun Aug 10 01:05:25 2014] why is the color blue important? [Sun Aug 10 01:05:39 2014] it's just what he chose [Sun Aug 10 01:05:46 2014] the green Idris uses is way too bold [Sun Aug 10 01:06:47 2014] coq is fast becoming my #1 choice for active procrastination [Sun Aug 10 01:07:01 2014] I think it already has the spot [Sun Aug 10 01:08:09 2014] can I have two modules that refer to each other, or is it like OCaml where there are no recursive modules? [Sun Aug 10 01:08:15 2014] what I hate most about Coq [Sun Aug 10 01:08:26 2014] is how it's changed my relationship with math [Sun Aug 10 01:08:36 2014] these days, I read math proofs, and I'm like "this is not formal enough" [Sun Aug 10 01:08:38 2014] "Coq would not accept this" [Sun Aug 10 01:08:41 2014] "crush would get stuck" [Sun Aug 10 01:09:20 2014] tautologico: I can't see how recursion would work [Sun Aug 10 01:09:26 2014] since order of declaration is significant [Sun Aug 10 01:09:37 2014] trap_exit: lol [Sun Aug 10 01:09:47 2014] trap_exit: mostly I think "this is not a constructive proof" [Sun Aug 10 01:11:05 2014] johnw: what are you using Coq for? intellectual interest, or actual development use? [Sun Aug 10 01:11:15 2014] I mentioned it in #haskell [Sun Aug 10 01:11:26 2014] I'm using it both for personal development in maths studies [Sun Aug 10 01:11:31 2014] and to formalize edwardk's hask library [Sun Aug 10 05:29:18 2014] vanila: no luck. I can see several invariants about the aux function but none of them look useful to me. main problem is that induction hypothesis looks useless no matter what I do induction on in main function. (e.g. there's no way to move from inductive hypothesis to current goal) [Sun Aug 10 05:30:01 2014] I guess I shouldn't be using induction on main function and focus on aux function instead. [Sun Aug 10 05:54:04 2014] nice [Sun Aug 10 05:54:21 2014] for some reason irc is blocked here but webchat works :) [Sun Aug 10 05:59:27 2014] brb [Sun Aug 10 06:09:16 2014] hi, I'm trying to prove what ought be a downright trivial theorem. [Sun Aug 10 06:09:30 2014] forall s, IdMapFacts.diff s (IdMap.empty type) = s [Sun Aug 10 06:09:55 2014] Unfortunately, trying to actually prove it seems to blow up into some complicated thing involving functional extensionality and then gets stuck. [Sun Aug 10 06:10:08 2014] Which trivial lemma from the standard library am I missing here? [Sun Aug 10 06:16:26 2014] Where IdMapFacts and IdMap are just FMapWeakList and FMapFacts instances. [Sun Aug 10 06:24:34 2014] is there a way to say that once I've proven C^op^op = C for any category C, that Coq could apply this during type unification in order to know that C^op^op stands for C? [Sun Aug 10 06:27:03 2014] i wonder if Identity Coercion could do this, but it's telling me that Category must be a transparent constant (it's a typeclass) [Sun Aug 10 06:51:35 2014] is there a part in the standard library that calculates the binary representation of a nat (and proves stuff about it)? [Sun Aug 10 06:51:54 2014] I could write it myself, but if it was there ... [Sun Aug 10 06:52:20 2014] do you mean Coq.NArith.BinNat? [Sun Aug 10 06:54:25 2014] johnw: looks promising. [Sun Aug 10 06:54:39 2014] johnw: do you know how the function is called that transforms nat to BinNat? [Sun Aug 10 06:55:24 2014] SearchAbout for double -> nat [Sun Aug 10 06:57:55 2014] hm. there is to_nat. [Sun Aug 10 06:57:57 2014] and of_nat [Sun Aug 10 08:24:01 2014] how do i use let ... := ... in ... [Sun Aug 10 08:24:06 2014] when this is loaded [Sun Aug 10 08:24:08 2014] Notation Scope "x 'in' M" := member x M : msets_scope (default interpretation) [Sun Aug 10 08:24:25 2014] you might want to give it a lower priority in parsing, I would think. [Sun Aug 10 08:24:53 2014] is there another way? [Sun Aug 10 08:25:00 2014] its from a library [Sun Aug 10 08:25:15 2014] i have this definition https://privatepaste.com/d57796632e [Sun Aug 10 08:25:32 2014] but Coq tells me Syntax error: 'in' expected after [constr:operconstr level 200] (in [constr:binder_constr]). [Sun Aug 10 08:25:46 2014] im guessing it has something to do with msets_scope [Sun Aug 10 08:25:57 2014] because Coq does accept the definition before Multisets are loaded [Sun Aug 10 08:27:38 2014] isnt there a way to disambiguate the statement? [Sun Aug 10 08:28:11 2014] or maybe i can close the scope temporarily? Ive tried Close Scope msets_scope. but to no avail [Sun Aug 10 08:39:29 2014] Notation "x 'in' M" := (member x M) (at level 10) : msets_scope. [Sun Aug 10 08:40:13 2014] its defined at level 10, thats very low right? I dont get it [Sun Aug 10 08:41:24 2014] Unset Notation [Sun Aug 10 08:42:26 2014] oh that's only for priting, that wont help [Sun Aug 10 08:43:23 2014] oh you tried Close Scope sets_scope. [Sun Aug 10 08:43:40 2014] vanila: doesnt work, same thing [Sun Aug 10 08:43:41 2014] Locate "in" [Sun Aug 10 08:43:47 2014] is it part of other scopes [Sun Aug 10 08:45:20 2014] nope, just msets_scope [Sun Aug 10 08:45:45 2014] CoqIDE doesnt give any feedback when i do Close Scope msets_scope. but i did do it [Sun Aug 10 08:53:09 2014] sorry my wifi connection dropped [Sun Aug 10 08:53:14 2014] did i miss anything? [Sun Aug 10 09:14:14 2014] Near-victory! I've at least proved: IdMap.Equal s (subst_diff empty_subst s). [Sun Aug 10 09:14:38 2014] Now if I can prove this implies Leibniz equality when the key type is a UsualDecidableType... [Sun Aug 10 09:34:07 2014] haha i cant even do Eval compute in 2 + 2. anymore [Sun Aug 10 09:37:55 2014] And I proceeded to find absolutely no way to strengthen that theorem given my knowledge that it's Leibniz equality on everything. [Sun Aug 10 09:38:03 2014] So I just gave up and declared success with a weaker theorem. [Sun Aug 10 10:24:23 2014] if i dont respond to any suggestions, its probably because my laptop lost the wifi signal.. [Sun Aug 10 16:06:05 2014] vanila: I still can't prove my lemma [Sun Aug 10 16:06:09 2014] vanila: any tips? :-) [Sun Aug 10 16:19:02 2014] http://lpaste.net/109177 [Sun Aug 10 16:19:05 2014] here's a round-about approach [Sun Aug 10 16:19:29 2014] it's difficult to prove things about a function that returns list indexes (i can say why if you want) [Sun Aug 10 16:20:06 2014] so idea: Write the min function normally, prove it correct and then write a version that returns indices and relate the two - carry correctness across that relation [Sun Aug 10 16:20:54 2014] why it's difficult to prove about functions that return list indexes? [Sun Aug 10 16:24:07 2014] it's hard because the specification of the function requires correctness of recursive calls - but the recursive calls depend on being part way through a list.. If you try to give a specification that accounts for being part way through a list you might be able to complete the proof but it's difficult to come up with [Sun Aug 10 17:05:31 2014] hm ... I guess I asked this before, but ... are there state monads or something like that in coq? [Sun Aug 10 17:05:46 2014] or anything else to enforce stateful operation? [Sun Aug 10 17:06:09 2014] state monads would be good, they can be extracted to haskell directly [Sun Aug 10 17:13:59 2014] schoppenhauer: just state monad, for example. https://bitbucket.org/gds/coq-practical-monads/src . But don't think you'll like it. [Sun Aug 10 17:26:52 2014] it looks like SF doesn't work with the latest coq (from git) [Sun Aug 10 17:37:23 2014] osa1, vanila: I think i've got it [Sun Aug 10 17:37:58 2014] the trick is to define a min_list predicate of type list A -> A -> nat -> Prop [Sun Aug 10 17:38:37 2014] cool! Good luck, i'd like to see if you complete it [Sun Aug 10 17:38:45 2014] I managed to get SF to build, but I had to change some pattern matches [Sun Aug 10 17:39:54 2014] I've managed to prove the appropriate invariant [Sun Aug 10 17:40:00 2014] all i have to do is tie up the knots [Sun Aug 10 17:41:41 2014] cody__: can you share? [Sun Aug 10 17:41:56 2014] yea give me a minute to prove the main theorem [Sun Aug 10 18:01:25 2014] cody__: any news? [Sun Aug 10 18:03:03 2014] gdsfh: hm. the main reason I ask this is since the best possibility to solve a certain problem I have is by using an array. I can make sure that the changes to this array are sequential. But it is still necessary to have an array. [Sun Aug 10 18:03:35 2014] gdsfh: and since I want to run the code afterwards, I want it to be extractable. [Sun Aug 10 18:06:19 2014] gdsfh: in fact, if I just used a function with many arguments, the usual tco of haskell et al whould apply. [Sun Aug 10 18:12:30 2014] gdsfh: but I'd guess that I can give explicit extraction commands for bind et al. so this looks promising, thx! [Sun Aug 10 18:12:58 2014] um [Sun Aug 10 18:13:12 2014] osa1: it's a bit more tedious than expected [Sun Aug 10 18:13:20 2014] as can be expected :) [Sun Aug 10 18:13:35 2014] just give me another minute [Sun Aug 10 18:14:01 2014] sure :-) [Sun Aug 10 18:18:12 2014] gdsfh: hm. what is the MonadRecord.v good for? [Sun Aug 10 19:10:24 2014] osa1: ok finally done [Sun Aug 10 19:11:31 2014] http://pastebin.com/ea1C9gsC [Sun Aug 10 19:11:35 2014] reaaaly ugly though [Sun Aug 10 19:11:40 2014] there's got to be a better way [Sun Aug 10 19:12:54 2014] I made some small changes to the code btw [Sun Aug 10 19:13:07 2014] it returns a Some instead of defaulting to 0 [Sun Aug 10 19:36:18 2014] cody__: do you know much about parametric relations? [Sun Aug 10 19:37:01 2014] cody__: the Hoare logic chapter in SF is basically proving things about a state monad, although I'm not sure if they introduce monads [Sun Aug 10 19:39:17 2014] I want to define Isomorphism as an equivalence relation, so that setoid_rewrite will let me use isomorphisms in my context as if they were equalities [Sun Aug 10 19:39:46 2014] I wrote the Parametric Relation, but when I try to use it I get: [Sun Aug 10 19:39:51 2014] https://gist.github.com/39c05b708a558abdace8 [Sun Aug 10 19:39:58 2014] so it feels like I'm missing an instance of something [Sun Aug 10 19:41:06 2014] ah, Proper it would esem [Sun Aug 10 19:58:10 2014] is there a common name for the function "split" where split f g (a,b) = (f a , g b) ? [Sun Aug 10 20:10:01 2014] johnw: did you work it out? [Sun Aug 10 20:10:15 2014] almost there [Sun Aug 10 20:10:24 2014] i'm defining a Proper instance for eq_iso right now [Sun Aug 10 20:10:56 2014] I have a small example of parametric morphisms but i'm not sure it will help [Sun Aug 10 20:11:19 2014] http://www.andrew.cmu.edu/user/croux/coq/monoid_nbe.html [Sun Aug 10 20:11:54 2014] what's the difference between Add Relation and Add Parametric Relation? [Sun Aug 10 20:12:48 2014] I think Add Parametric Relation is more verbose but more expressive [Sun Aug 10 20:14:10 2014] http://coq.inria.fr/V8.2pl1/refman/Reference-Manual030.html#toc157 [Sun Aug 10 20:14:53 2014] you're going to need parametric relation though probably [Sun Aug 10 21:08:05 2014] cody__: still no go yet: https://github.com/jwiegley/category-theory/blob/master/Category.v#L350 [Sun Aug 10 21:09:50 2014] johnw: what is proper? [Sun Aug 10 21:10:00 2014] to be honest, I don't really know [Sun Aug 10 21:26:09 2014] by the way, what you're doing isn't trivial [Sun Aug 10 21:26:21 2014] it's basically the first level of univalence [Sun Aug 10 21:26:38 2014] right [Sun Aug 10 21:26:47 2014] and if I can make it inductive, I get infinity-groupoids? [Sun Aug 10 23:04:55 2014] pretty much [Sun Aug 10 23:05:03 2014] logging out [Mon Aug 11 00:12:00 2014] is there some syntactic extension for "exists (some, pair)"? [Mon Aug 11 00:12:37 2014] you mean { some | pair }? [Mon Aug 11 00:12:58 2014] or do you mean inhabited (some * pair)? [Mon Aug 11 00:13:10 2014] the latter [Mon Aug 11 00:13:21 2014] there is "inhabited" [Mon Aug 11 00:14:02 2014] johnw: can you point me to some documentation? [Mon Aug 11 00:14:12 2014] http://coq.inria.fr/library/Coq.Init.Logic.html [Mon Aug 11 00:14:17 2014] search for "Being inhabited" [Mon Aug 11 00:14:38 2014] it's a fairly weak notion, I think, in that unlike the sigma it doesn't give you the witness [Mon Aug 11 00:16:05 2014] I'll keep a note of it, thanks [Mon Aug 11 02:54:07 2014] schoppenhauer: (sorry for late answer, I was sleeping) MonadRecord -- for working with monads and their laws that are first-class values; modules are not first-class values in Coq. Don't remember though, where and how it was used. As for your arrays, I don't know what would be the best solution.. [Mon Aug 11 06:08:18 2014] I have a function that returns Some for (h :: t) and None for [] and I have a hypothesis saying that f (n :: n0 :: t) = None. is there an easy way to eliminate this case? [Mon Aug 11 06:11:54 2014] osa1 : doesn't inversion takes care of this? :o [Mon Aug 11 06:22:04 2014] Cypi: I guess it could but in case of (h :: t) there are further pattern matchings and function calls going so it's still a lot more work than just simple destruct l + inversion. I need to keep destructing to prove all the nested pattern matchings. [Mon Aug 11 06:23:14 2014] If just [simpl] isn't enough to simplify [f (n :: n0 :: t)] to [Some _], then maybe should prove this in a separate lemma? [Mon Aug 11 06:23:21 2014] +you [Mon Aug 11 06:24:15 2014] yeah I did just that while waiting for answers :-) I was expecting a smart tactic that further destructs and uses inversion automatically to prove that result is in the form of Some _. [Mon Aug 11 06:25:04 2014] I don't believe a lot of tactics will attempt to destruct things by themselves. [Mon Aug 11 08:01:11 2014] wow. assert _ by _ and replace _ by _ are really useful. [Mon Aug 11 08:01:45 2014] I was doing that manually: assert (_ = _) as eq; omega or auto; rewrite <- eq in _; clear eq. [Mon Aug 11 15:21:27 2014] instead of clear H, is there a way to just say "keep H in the context, but don't show it?" [Mon Aug 11 15:23:22 2014] Doubtful [Mon Aug 11 16:05:39 2014] johnw: I wished [Mon Aug 11 16:12:00 2014] osa1: and sometimes replace can achieve things that assert+rewrite can't; I ran into that just now [Mon Aug 11 18:10:47 2014] so I'm still working on my find_min_correct lemma [Mon Aug 11 18:12:08 2014] I currently have two solutions but neither of them written by me and I don't understand how they work. so I'm trying to derive it. [Mon Aug 11 18:12:45 2014] I think I understand what's wrong with working on indexes. I tried a different version(find_min which returns minimum element instead of index of minimum element) and proving it correct was almost trivial. [Mon Aug 11 18:13:35 2014] but I can't prove `nth (find_min_idx l) l 0 = find_min l` so I'm still stuck. [Mon Aug 11 18:18:55 2014] osa1: how can I help? [Mon Aug 11 18:23:33 2014] jrw: this is the lemma I'm trying to prove http://lpaste.net/109212 [Mon Aug 11 18:23:49 2014] jrw: and I'm clueless [Mon Aug 11 18:24:34 2014] jrw: basically, induction doesn't work and I need a different approach but I don't know what [Mon Aug 11 18:26:55 2014] osa1: okay, one sec while I look at it. [Mon Aug 11 18:30:22 2014] osa1: again, you'll need some fact about the aux function that will be proved by induction [Mon Aug 11 18:31:00 2014] whenever you have this situation where one function is defined using a helper, and that helper is the actually recursive part, and you want to prove something about the function, you'll pretty much always need a lemma about the helper [Mon Aug 11 18:31:32 2014] and it's not always completely obvious what the helper lemma should be [Mon Aug 11 18:32:29 2014] jrw: yeah and that's the problem. I know I need to prove something about the aux one but after an unfold is that what I'm doing already? [Mon Aug 11 18:33:11 2014] osa1: no, because by just unfolding you haven't generalized the extra arguments [Mon Aug 11 18:33:20 2014] I prefer to state the aux lemma separately [Mon Aug 11 18:33:25 2014] it is clearer and easier, I find. [Mon Aug 11 18:33:32 2014] hm [Mon Aug 11 18:51:42 2014] osa1: how's it going? [Mon Aug 11 18:57:18 2014] jrw: not great. trying to figure out what invariant would help me. [Mon Aug 11 18:59:07 2014] osa1: okay, so you have your end goal of proving this fact about find_min_idx. if you're stuck on the helper lemma, try copy-pasting the fact you want to prove and doing the unfold manually. try to prove that by induction. you'll get stuck somewhere along the line probably. how exactly you get stuck will help you figure out what stronger invariant you need. [Mon Aug 11 19:08:16 2014] jrw: okay. I'll need to find what helper lemma to use first. [Mon Aug 11 19:08:41 2014] osa1: I'm suggesting a way to get started on figuring that out. [Mon Aug 11 19:09:07 2014] copy paste the end goal lemma and do the unfold manually and proceed by induction [Tue Aug 12 00:47:24 2014] if I have an equal between two records of N fields, so {| ... |} = {| ... |}, how can I break it apart so that I now have to prove N goals? [Tue Aug 12 00:47:46 2014] trying to apply f_equal3 wants all the fields to match [Tue Aug 12 01:42:59 2014] osa1_: ping [Tue Aug 12 03:10:01 2014] osa1_: I made you a pset :) http://lpaste.net/109225 [Tue Aug 12 03:10:03 2014] hello. I'm stuck, help please. I have relation (inductive type) with transitivity case, and I can't prove something about it: http://pastebin.com/HrLWUWDC (it's not a real case, I've simplified it to nats). [Tue Aug 12 03:16:13 2014] gdsfh: you need to use induction [Tue Aug 12 03:16:29 2014] you also need to generalize the 0 to a variable before inducting [Tue Aug 12 03:16:36 2014] jrw: induction on which term? [Tue Aug 12 03:16:47 2014] gdsfh: on the my_le hypothesis [Tue Aug 12 03:21:15 2014] jrw: how to generalize 0? [Tue Aug 12 03:21:39 2014] gdsfh: you can either use the "remember" tactic, or restate the goal. I prefer to restate things. [Tue Aug 12 03:23:12 2014] gdsfh: http://lpaste.net/109227 [Tue Aug 12 03:27:49 2014] jrw: thank you! What was your intuition here? (how you found out what is the correct way to prove it?) [Tue Aug 12 03:38:11 2014] gdsfh: good question. the short answer is that any time you have a transitivity rule like that, you'll need to prove everything by inudction on the derivation. [Tue Aug 12 03:38:34 2014] because the recursive cases in transitivity don't decrease the nat [Tue Aug 12 03:38:45 2014] so induction on any of the parameters/indices won't work [Tue Aug 12 03:39:36 2014] can I "downgrade" a pi-type to a function type? [Tue Aug 12 03:45:44 2014] johnw: what do you mean ? [Tue Aug 12 03:46:12 2014] jrw: good answer :) thanks! [Tue Aug 12 03:46:47 2014] np [Tue Aug 12 03:50:30 2014] coq doesn't make any difference between a pi type w/o dependencies and a function type afaik (see e.g. [Check eq_refl : (forall x:nat, nat) = (nat -> nat)]) [Tue Aug 12 04:44:26 2014] johnw: prove f_equalN to prove an equality between two records of N fields. See https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/FEqualDep.v?at=default for versions that let you handle dependent records (f_equalN_JMeq), by assuming K (rather, the equivalent, JMeq_eq). If some of your fields are hProps, (are proof irrelevant), you can classify the path space of your record; see [Tue Aug 12 04:44:26 2014] https://github.com/HoTT/HoTT/blob/master/theories/categories/Functor/Paths.v#L100 [Tue Aug 12 04:45:26 2014] johnw: In trunk, -> is just a notation for forall: https://github.com/coq/coq/blob/trunk/theories/Init/Logic.v#L13 [Tue Aug 12 05:33:08 2014] jrw: wow that's really helpful. thanks. I was sleeping and just saw that. [Tue Aug 12 07:00:43 2014] newtype ListT m a = ListT (m (Maybe (a, ListT m a))) [Tue Aug 12 07:00:48 2014] How would I define this in Coq? [Tue Aug 12 07:00:54 2014] Inductive ListT (m : Type -> Type) (a : Type) : Type := [Tue Aug 12 07:00:54 2014] | listT : m (option (a * ListT m a)) -> ListT m a. [Tue Aug 12 07:00:56 2014] was my first attempt [Tue Aug 12 07:00:59 2014] but it says [Tue Aug 12 07:01:02 2014] Error: Non strictly positive occurrence of "ListT" in [Tue Aug 12 07:01:02 2014] "m (option (a * ListT m a)) -> ListT m a". [Tue Aug 12 07:06:47 2014] https://github.com/nikita-volkov/list-t/blob/master/library/ListT.hs would like to prove this correct [Tue Aug 12 08:06:06 2014] Hello! [Tue Aug 12 08:06:20 2014] hiya [Tue Aug 12 08:06:45 2014] Is it possible to define mutually recursive lemmas? [Tue Aug 12 08:06:46 2014] I.e. to define them via tactics. [Tue Aug 12 08:07:15 2014] Like "Lemma f (n : nat) : .... . exact (...). Defined with Lemma g (n : nat) : ... ." [Tue Aug 12 08:07:49 2014] yes [Tue Aug 12 08:08:28 2014] "with" is the keyword for that [Tue Aug 12 08:09:35 2014] vanila, yep, but how to insert tactics? I know that it is possible in fresh Coq versions, but I am on 8.4pl3. [Tue Aug 12 08:09:48 2014] i think that you specify both lemmas, then do the proofs [Tue Aug 12 08:11:56 2014] vanila, I can't manage to do it =/ [Tue Aug 12 08:18:00 2014] I can use "Program" extension though. [Tue Aug 12 08:19:39 2014] I'm sure you can do this without program [Tue Aug 12 10:32:21 2014] Syntax error: 'in' expected after [constr:operconstr level 200] (in [constr:binder_constr]). [Tue Aug 12 10:33:13 2014] Notation "x 'in' M" := (member x M) (at level 10) : msets_scope. [Tue Aug 12 10:33:46 2014] (in https://privatepaste.com/2c39647ca3) [Tue Aug 12 10:34:12 2014] how can i make Coq disregard the Notation and instead use let ... := ... in ... [Tue Aug 12 10:34:13 2014] ? [Tue Aug 12 10:36:23 2014] [Local Close Scope msets_scope]? [Tue Aug 12 10:37:36 2014] didnt help [Tue Aug 12 10:37:47 2014] Can you paste the full file? [Tue Aug 12 10:37:55 2014] edit the library that makes this bad notation [Tue Aug 12 10:37:55 2014] well.. [Tue Aug 12 10:38:05 2014] i could but you would have to have CoLoR installed [Tue Aug 12 10:38:17 2014] vanila, i cant modify the library [Tue Aug 12 10:38:29 2014] use a older version of coq [Tue Aug 12 10:38:31 2014] I don’t think that’s the right approach. The notation is defined in [msets_scope], so the right approach is to hide that scope. [Tue Aug 12 10:38:42 2014] roosbeef: I just want to see the whole code, not run it [Tue Aug 12 10:39:36 2014] Like, I’d like to see what you’re importing [Tue Aug 12 10:39:56 2014] Alternatively, what’s the output of [Print Visibility] right before your [Fixpoint]? [Tue Aug 12 10:40:06 2014] http://coq.inria.fr/pylons/contribs/files/CoLoR/v8.4/CoLoR.Util.Multiset.MultisetTheory.html [Tue Aug 12 10:40:42 2014] https://privatepaste.com/aac27c0d4c [Tue Aug 12 10:41:43 2014] hm [Tue Aug 12 10:41:46 2014] Huh, weird [Tue Aug 12 10:41:53 2014] somehow its removed by that command you suggested [Tue Aug 12 10:42:04 2014] [Local Close Scope msets_scope]? [Tue Aug 12 10:42:07 2014] Yeah. [Tue Aug 12 10:42:15 2014] Are you familiar with notation scopes in Coq? [Tue Aug 12 10:42:17 2014] but Coq gives the same complaint [Tue Aug 12 10:42:23 2014] Oh, wait, what? [Tue Aug 12 10:42:26 2014] Uhh [Tue Aug 12 10:42:43 2014] Are you using Proof General? This might be a good time to restart Proof General. :) [Tue Aug 12 10:42:56 2014] Or C-r your buffer and reload it [Tue Aug 12 10:42:57 2014] nah CoqIDE [Tue Aug 12 10:43:01 2014] Huh, weird [Tue Aug 12 10:43:15 2014] And you pu the [Close Scope] above the [Fixpoint]? [Tue Aug 12 10:43:18 2014] *put [Tue Aug 12 10:43:37 2014] yes [Tue Aug 12 10:43:56 2014] the scope comes from a module [Tue Aug 12 10:44:07 2014] does that matter? [Tue Aug 12 10:44:15 2014] It shouldn’t … [Tue Aug 12 10:44:38 2014] it works before this line and not after: Module Export FL_MSetTheory := MultisetTheory.Multiset FL_MSetCore. [Tue Aug 12 10:45:32 2014] You should be able to put that [Local Close Scope] after the [Module Export] command to make that scope disappear. [Tue Aug 12 10:46:02 2014] are there alternative ways to close it? [Tue Aug 12 10:46:46 2014] Not that I’m aware of. [Tue Aug 12 10:46:56 2014] Oh, wait, is this crossing a section boundary or something like that? [Tue Aug 12 10:47:04 2014] ah yea i guess it is [Tue Aug 12 10:47:12 2014] yes [Tue Aug 12 10:47:26 2014] I forget if notations get reset when you exit a section … [Tue Aug 12 10:47:36 2014] well [Tue Aug 12 10:47:38 2014] the module is loaded [Tue Aug 12 10:47:44 2014] and then a new section is opened [Tue Aug 12 10:48:05 2014] Oh, okay [Tue Aug 12 10:48:09 2014] That shouldn’t be an issue, then [Tue Aug 12 10:48:14 2014] Scopes only get reset when you exit a section [Tue Aug 12 10:49:23 2014] so how can the notation not be in Print Visibility [Tue Aug 12 10:49:34 2014] but still be found when doing Locate "in". [Tue Aug 12 10:49:54 2014] That means the notation exists but is not visible. [Tue Aug 12 10:50:00 2014] That sounds like expected behaviour. [Tue Aug 12 10:50:20 2014] why is there a difference between existing and being visible [Tue Aug 12 10:50:31 2014] Being visible means it’s in a currently-open notation scope [Tue Aug 12 10:50:45 2014] Existing means that it’s been defined and can be used, e.g., in a scope-delimited block [Tue Aug 12 10:50:46 2014] isnt there some prefix i can use [Tue Aug 12 10:50:49 2014] Suffix, yeah [Tue Aug 12 10:50:52 2014] so that Coq interprets in to mean something else? [Tue Aug 12 10:51:20 2014] Sure, you can define a notation to make [in] mean whatever you want [Tue Aug 12 10:51:27 2014] And then put that in a scope-delimited block [Tue Aug 12 10:51:58 2014] a scope-delimited block? [Tue Aug 12 10:52:27 2014] Something like (3 + 5)%nat [Tue Aug 12 10:52:44 2014] yea exactly [Tue Aug 12 10:52:51 2014] so in%normal [Tue Aug 12 10:52:54 2014] or something like that? [Tue Aug 12 10:53:15 2014] I don’t know if there’s a key for ‘don’t use any custom scopes’ [Tue Aug 12 10:54:54 2014] Oh, wait, hang on, I can reproduce [Tue Aug 12 10:54:58 2014] This is really weird [Tue Aug 12 10:57:22 2014] it is right [Tue Aug 12 10:57:26 2014] :\ [Tue Aug 12 11:00:03 2014] Okay, I talked with a postdoc in my office, and he figured it out [Tue Aug 12 11:00:19 2014] When a notation exists, even if it is not in scope, it defines a parser rule for it [Tue Aug 12 11:00:45 2014] So just by virtue of the fact that the [in] notation exists in CoLoR, Coq tries to parse [in] as part of the notation [Tue Aug 12 11:00:49 2014] Does that make sense? [Tue Aug 12 11:01:21 2014] The kind-of-unsatisfactory solution we came up with for this is to not [Import] the module, but just [Require] it [Tue Aug 12 11:01:39 2014] And then if you need to re-export or something, [Export] it at the end of the module, after you no longer need to use [let] [Tue Aug 12 11:01:39 2014] let me try that [Tue Aug 12 11:01:51 2014] But we both agree this is a really awful design decision on the CoLoR devs’ part [Tue Aug 12 11:01:56 2014] Maybe things are better in trunk? [Tue Aug 12 11:02:07 2014] yea it would be nice if they had used inn or something :p [Tue Aug 12 11:02:22 2014] But in the meantime, somebody probably ought to file a bug against CoLoR [Tue Aug 12 11:02:42 2014] so use [Import CoLoR.Util.Multiset.MultisetTheory.]? [Tue Aug 12 11:02:50 2014] Use [Require], not [Import] [Tue Aug 12 11:02:54 2014] ah [Tue Aug 12 11:03:25 2014] that doesnt work [Tue Aug 12 11:03:34 2014] In what way? [Tue Aug 12 11:03:45 2014] Like, it still breaks the parser? [Tue Aug 12 11:03:49 2014] no wait it does [Tue Aug 12 11:03:50 2014] my bad [Tue Aug 12 11:03:53 2014] Okay. :) [Tue Aug 12 11:04:27 2014] ok so i only Required it [Tue Aug 12 11:04:54 2014] what do you mean by And then if you need to re-export or something, [Export] it at the end of the module, after you no longer need to use [let] [Tue Aug 12 11:09:05 2014] So, say you’re wrapping a module M. [Tue Aug 12 11:09:28 2014] wrapping a module? [Tue Aug 12 11:09:29 2014] Normally, the way you do this is by saying [Require Export M] at the top of your file [Tue Aug 12 11:09:32 2014] Oh, uh [Tue Aug 12 11:09:41 2014] Here, hang on, let me write up a quick example. [Tue Aug 12 11:09:49 2014] ok [Tue Aug 12 11:15:08 2014] … and now I discover I don’t actually understand the Coq module system as well as I thought I did. [Tue Aug 12 11:15:52 2014] :p [Tue Aug 12 11:15:55 2014] I think I understand things now, but I’m sufficiently shaky that I don’t want to lie to you. [Tue Aug 12 11:16:05 2014] Plus, I think this is probably enough of an edge case that you’re not going to need to worry about it. [Tue Aug 12 11:16:39 2014] whats an edge case? [Tue Aug 12 11:16:55 2014] A weird use case that doesn’t appear in real code very often. [Tue Aug 12 11:17:05 2014] We both should probably (re)read http://coq.inria.fr/refman/Reference-Manual004.html#section%3AModules at some point, but for the time being, I think you should just forge ahead. [Tue Aug 12 11:18:07 2014] Anyway, I’ve got to head out for a bit, but I’m glad we figured out the [Notation] thing. Good luck! [Tue Aug 12 11:18:08 2014] yea i guess i could do without let ... := ... in ... [Tue Aug 12 11:18:24 2014] alkabetz, thanks a lot! Ill think of something :) [Tue Aug 12 11:18:44 2014] Oh, wait [Tue Aug 12 11:18:49 2014] I think I didn’t make myself quite clear. [Tue Aug 12 11:19:05 2014] I’m very confident that [Require], rather than [Import], will fix the issue with the notation. [Tue Aug 12 11:19:27 2014] I’m not sure about exactly when you should be using [Export], but like I said, I don’t think it’s going to be an issue in your code right now. [Tue Aug 12 11:19:55 2014] ok then i dont understand [Tue Aug 12 11:20:07 2014] but dont worry about it :p [Tue Aug 12 11:20:15 2014] No, no, let’s fix this. :) [Tue Aug 12 11:20:26 2014] i need to open that module right [Tue Aug 12 11:20:29 2014] to start using it [Tue Aug 12 11:20:33 2014] open/Export [Tue Aug 12 11:20:36 2014] No. [Tue Aug 12 11:20:41 2014] You need only [Require] it. [Tue Aug 12 11:20:51 2014] no because it uses other modules [Tue Aug 12 11:21:13 2014] Okay, hold on. [Tue Aug 12 11:21:16 2014] We need to slow down a bit. [Tue Aug 12 11:21:18 2014] https://privatepaste.com/e64603157b [Tue Aug 12 11:21:26 2014] You want to use CoLoR.Util.Multiset.MultisetTheory, correct? [Tue Aug 12 11:21:33 2014] Ah, looking [Tue Aug 12 11:21:33 2014] you see, it uses FL_MSetCore [Tue Aug 12 11:21:50 2014] basically, im using that module with a custom data type [Tue Aug 12 11:21:59 2014] if i only Require it, the module wont recognize that [Tue Aug 12 11:22:42 2014] Which module are you using with a custom data type? [Tue Aug 12 11:23:25 2014] all of them? [Tue Aug 12 11:23:33 2014] Okay. [Tue Aug 12 11:23:54 2014] So what error do you get that indicates to you that you need to [Import] CoLoR.Util.Multiset.MultisetTheory? [Tue Aug 12 11:24:02 2014] i dont get such an error [Tue Aug 12 11:24:07 2014] but i dont understand what you mean by Export it later [Tue Aug 12 11:24:11 2014] Oh. [Tue Aug 12 11:24:13 2014] i need to Export it at that point [Tue Aug 12 11:24:20 2014] for my code to work [Tue Aug 12 11:25:23 2014] Do you need to [Export] CoLoR.Util.Multiset.MultisetTheory? [Tue Aug 12 11:26:15 2014] hm [Tue Aug 12 11:26:17 2014] not sure to be honest [Tue Aug 12 11:26:26 2014] im not gonna lie, im a bit of a novice at Coq :p [Tue Aug 12 11:26:33 2014] ‘Aren’t we all’ :) [Tue Aug 12 11:26:34 2014] even though ive been working on this project for over a year [Tue Aug 12 11:26:39 2014] Well, I guess jgross isn’t :) [Tue Aug 12 11:26:54 2014] for me, if it works it works :P i gave up wanting to understand every single bit [Tue Aug 12 11:27:02 2014] Heh, yeah, I know that feeling [Tue Aug 12 11:27:05 2014] let me try to drop [Export] [Tue Aug 12 11:27:42 2014] ok that seems to work [Tue Aug 12 11:27:54 2014] So, AIUI, [Export Foo] means ‘Import Foo, and then also make it so that when people import this module, they also get all the names in Foo as well’ [Tue Aug 12 11:27:54 2014] but now the scope is never even initialized [Tue Aug 12 11:30:44 2014] meh sorry but i have to go [Tue Aug 12 11:30:58 2014] gotta be at work in 30 mins [Tue Aug 12 11:31:12 2014] Okay, yep :) Sounds like we made some progress, though. Best of luck! [Tue Aug 12 11:31:30 2014] we did [Tue Aug 12 11:31:33 2014] again thanks a lot for being so helpful, much appreciated :) [Tue Aug 12 11:31:46 2014] You’re welcome. Glad I could help. :) [Tue Aug 12 11:43:11 2014] Ahoy. [Tue Aug 12 11:43:44 2014] Given an infix operator or a piece of notation, how can I tell what term it refers to? [Tue Aug 12 11:47:39 2014] Here we go. Locate. [Tue Aug 12 11:53:36 2014] I'm occasionally amazed how certain rules of logic turn out to be "induction" principles for certain connectives. [Tue Aug 12 11:54:08 2014] Ex falso quodlibet is induction on falsehood proofs. Substitution is induction on equality proofs. [Tue Aug 12 12:16:23 2014] vanila: in coq for listT done right you might look at something more like the LogicT approach: After you strip away all of Oleg's newtype noise you are left with ListT m a = forall r. (a -> m r -> m r) -> m r -> m r which is a special case of the Codensity monad [Tue Aug 12 12:17:12 2014] clever edwardk! Thanks for that idea [Tue Aug 12 12:17:23 2014] just replacing it with the church encoding [Tue Aug 12 12:17:48 2014] i have to do that a lot in haskell for speed / technical reasons, so its a habit =) [Tue Aug 12 12:18:21 2014] also you may want to look at oleg's recent Reflection without Remorse paper which gives a much heavier way to translate LogicT [Tue Aug 12 12:18:33 2014] that approach may or may not work in Coq. [Tue Aug 12 12:19:10 2014] great, ill give this a go :) [Tue Aug 12 12:25:25 2014] vanila: what behavior do you want from your ListT? [Tue Aug 12 12:25:44 2014] vanila: if you just want monadic production of values, then forall r. (a -> r -> m r) -> r -> m r will work fine [Tue Aug 12 12:26:02 2014] vanila: if you want something like Oleg's msplit combinator, you'll need the form that edwardk gave [Tue Aug 12 12:26:05 2014] I just want to prove it's monad, and I thought Coq would help me https://github.com/nikita-volkov/list-t/blob/master/library/ListT.hs [Tue Aug 12 12:26:20 2014] for example, see https://github.com/jwiegley/category-theory/blob/master/Endo/Conduit.v [Tue Aug 12 12:26:36 2014] "Source" is a final-encoded ListT, and I have proofs that it is a monad there [Tue Aug 12 12:26:39 2014] This was just released and there's no proofs or references! So I was wondering what this correctness claim was based on [Tue Aug 12 12:26:51 2014] it is an old old idea [Tue Aug 12 12:27:04 2014] and its kind of annoying to see it repackaged when the old idea is already packaged elsewhere [Tue Aug 12 12:27:11 2014] yeah, theer are many ListT's out in the world now [Tue Aug 12 12:27:12 2014] What does final-encoded mean? [Tue Aug 12 12:27:18 2014] http://www.haskell.org/haskellwiki/ListT_done_right is the classic writeup [Tue Aug 12 12:27:20 2014] Thanks for this, this is great! [Tue Aug 12 12:27:29 2014] turning m [a] into the Boehm-Berarducci encoding [Tue Aug 12 12:27:48 2014] oh interesting, that's a new term to me [Tue Aug 12 12:28:08 2014] nikita's form just turns the Nil+Cons constructors into a Maybe, which is algebraically isomorphic [Tue Aug 12 12:28:21 2014] so really there is nothing new there [Tue Aug 12 12:28:37 2014] vanila: http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html [Tue Aug 12 12:28:55 2014] great lots of crazy fun stuff to read today, thanks :) [Tue Aug 12 12:29:01 2014] it's funny you ask this, since I've been working on exactly this in Coq for the last two months :) [Tue Aug 12 12:29:16 2014] proving not just monad, but all the other type classes as well [Tue Aug 12 12:30:22 2014] nikita's ListT is really an anemic form of http://hackage.haskell.org/package/simple-conduit [Tue Aug 12 12:31:24 2014] ([bug] http://hackage.haskell.org/package/simple-conduit-0.5.1/docs/Conduit-Simple.html your hyperlinks have been mangled here) [Tue Aug 12 12:31:35 2014] ouch, thanks [Tue Aug 12 12:41:35 2014] vanila: also, if you did want the LogicT approach: https://github.com/jwiegley/category-theory/blob/master/Endo/LogicT.v [Tue Aug 12 12:42:06 2014] proving that either of those is a monad should follow pretty much the same form as proving it for the more complex Source type [Tue Aug 12 12:42:40 2014] jgross: I don't quite follow, although what you linked to is probably exactly what I'm looking for; I'm lacking a bit of context to understand how it relates [Tue Aug 12 13:44:55 2014] if my goal is a record, for example I have to prove Foo a b, I normally do it using apply Build_Foo with (field1 := ...) ... [Tue Aug 12 13:45:11 2014] is there a way to simply say "make production of all those fields goals, and then have it build up the record after I've proven them all? [Tue Aug 12 13:47:52 2014] Does apply Build_Foo. alone work? or maybe eapply [Tue Aug 12 13:48:08 2014] well, then I have these existentials in my goal, but I don't know what to do with them [Tue Aug 12 13:49:26 2014] It should be that when you prove one of the goals, that fills in the existentials in the others [Tue Aug 12 13:49:39 2014] for exampel, my goal is now ?1316 (?1317 e) = e [Tue Aug 12 13:49:47 2014] hm [Tue Aug 12 13:49:48 2014] wheer those things are the "from" and "to" which I'm needing to define [Tue Aug 12 13:49:57 2014] except now I don't know how to "provide a definition" for ?1316 [Tue Aug 12 13:50:01 2014] maybe give Build_Foo all the information you can, like type indices and things [Tue Aug 12 13:50:11 2014] but leave out all the fields [Tue Aug 12 13:52:34 2014] no, that changes nothing [Tue Aug 12 13:57:36 2014] osa1: how's it going? [Tue Aug 12 14:00:20 2014] jrw: I'll start working on it in 2-3 hours. I'm currently working on my day job :p [Tue Aug 12 14:00:33 2014] haha, okay [Tue Aug 12 14:12:40 2014] johnw: In trunk, you're looking for [refine (Build_Foo _ _ ...)]. Currently, [refine] is ~the only tactic that introduces dependent subgoals. (I think there might be an rapply defined somewhere in the stdlib that just does [refine H || refine (H _) || refine (H _ _) || ...] up to some number.) [Tue Aug 12 14:12:54 2014] let me try [Tue Aug 12 14:14:44 2014] huh, that worked! [Tue Aug 12 14:15:15 2014] i was doing assert (foo := ...) for a bunch of things [Tue Aug 12 14:15:30 2014] and then apply Build_Foo with (foo := foo), etc. [Tue Aug 12 14:16:07 2014] johnw: The key idea in Functor/Paths.v is that to prove an equality of functors, you need to prove that they're equal on objects and equal on morphisms. So I prove this fact (for arbirary functors), which is mostly straightforward (most of the noise is dealing with functional extensionality and proof irrelevance), and then I can just apply this theorem whenever I want to use it. If you only ever try to prove equality of a few record types, [Tue Aug 12 14:16:07 2014] it's much easier to prove such a lemma for each record type separately, than to try to use general tactics/lemmas that are meant to prove equality of any records. [Tue Aug 12 14:16:58 2014] johnw: Yes, assert is the old-school way to do things, where by old-school, I mean older than current development. [Tue Aug 12 14:17:08 2014] ok; I'm using HEAD so this is great, thanks [Tue Aug 12 14:17:21 2014] however, I'm finding that refine needs all the type arguments for Build_Foo function [Tue Aug 12 14:17:26 2014] example: refine (Build_Isomorphism Sets (Const a ⟾ F) (Cone a F) _ _ _ _). [Tue Aug 12 14:18:03 2014] can i pick different names for what the refiner is building? [Tue Aug 12 14:18:31 2014] ah, rename X into transport. did it [Tue Aug 12 14:21:27 2014] johnw: If you do it a lot with a given record, you can do [hnf; lazymatch goal with |- @Isomorphism ?a ?b ?c => refine (@Build_Isomorphism a b c _ _ _ _) end]. (Or stuff that into a [Build_Isomorphism] tactic or something.) [Tue Aug 12 14:25:04 2014] johnw: Do you have an example where you need to give arguments? The following works for me: [Tue Aug 12 14:25:04 2014] Record iso A B := { f : A -> B; [Tue Aug 12 14:25:04 2014] g : B -> A; [Tue Aug 12 14:25:04 2014] sect : forall x, f (g x) = x; [Tue Aug 12 14:25:04 2014] retr : forall x, g (f x) = x }. [Tue Aug 12 14:25:04 2014] Goal iso Set Set. [Tue Aug 12 14:25:04 2014] refine (Build_iso _ _ _ _ _ _). [Tue Aug 12 14:28:36 2014] yeah, noe sec [Tue Aug 12 14:29:12 2014] https://github.com/jwiegley/category-theory/blob/master/Functor.v#L702 [Tue Aug 12 14:29:27 2014] if you make all the arguments there to Build_Isomorphism underbars, you'll get errors [Tue Aug 12 14:29:31 2014] sometimes even an infinite lopo [Tue Aug 12 14:30:56 2014] jgross: thanks so much for this refine trick, it will add years back to my life [Tue Aug 12 14:44:36 2014] johnw: Do you want to run that through https://github.com/JasonGross/coq-bug-finder (python /path/to/coq-bug-finder.py ./Functor.v bug_refine.v --topname Hask) (you can add -vv if you want to see more about what it's doing), after you save Functor.v so that it gives you the error? (You may have to run "make" first... I haven't worked out all the bugs in the auto-building code.) It'll inline all the dependencies and (eventually) give you a [Tue Aug 12 14:44:36 2014] small example reproducing the error in bug_refine.v. I suspect that it's an unfortunate interaction with typeclasses, but it might be a bug, or worth reporting on the bug tracker. [Tue Aug 12 14:45:50 2014] ooh [Tue Aug 12 14:46:40 2014] do you mean find-bug.py? [Tue Aug 12 14:47:28 2014] jgross: even the working version gives me an error [Tue Aug 12 14:48:12 2014] Yes, I mean find-bug.py [Tue Aug 12 14:48:26 2014] oh [Tue Aug 12 14:48:30 2014] now using all underscores works [Tue Aug 12 14:48:38 2014] is there a way to say "use as many underscores as you need?" [Tue Aug 12 14:48:44 2014] johnw: What do you mean "even the working version gives me an error"? [Tue Aug 12 14:48:56 2014] meaning, the Functor.v that compiles still gives an error [Tue Aug 12 14:49:39 2014] i wonder if there's sometheing like #line for Coq, so find-bug.py can relate bugs to their source in Functor.v [Tue Aug 12 14:50:50 2014] You mean, it doesn't give you the error when you compile Functor.v, but you do get the error after it inlines all the dependencies? [Tue Aug 12 14:50:56 2014] yep [Tue Aug 12 14:51:01 2014] let me make sure about that [Tue Aug 12 14:51:50 2014] yes, coqc passes [Tue Aug 12 14:52:00 2014] bug_refine does not [Tue Aug 12 14:52:25 2014] Ugh. I'll take a look in a moment. (The first thing it does is inlines the imports, Coq's the file, and asks you if the error matches the one you thought you'd get. There are only a few cases that I know of where it fails, essentailly all of them are when you depend on the fact that you haven't [Require]d something.) [Tue Aug 12 14:52:59 2014] Also, https://github.com/coq/coq/blob/f5bbb5ce34bb1ee2165086b0fdb3ee5f3d96a44e/theories/Program/Tactics.v#L173 <- "as many underscores as I need". [Tue Aug 12 14:53:01 2014] that could well be [Tue Aug 12 14:53:06 2014] hahaha [Tue Aug 12 14:53:09 2014] awesome [Tue Aug 12 14:53:26 2014] I have a feeling that just injesting your brain would help me [Tue Aug 12 14:54:01 2014] Nah, ingesting it would probably destroy it. [Tue Aug 12 14:54:16 2014] I'm going to learn Coq tricks, zombie-style [Tue Aug 12 14:54:46 2014] so another questoin [Tue Aug 12 14:54:55 2014] i have two records, say with 3 fields each [Tue Aug 12 14:55:06 2014] if I try apply f_equal3, it wants the three to be refl [Tue Aug 12 14:55:12 2014] The main cases of this (inlining not working) are: you use a notation that changes the parser in a way that breaks other files (e.g., you make a notation for "a : b" in one file, and then use it as has-type-of in another file where you haven't Require'd the first one.) Typeclass instances used to be another case of side-effects of Require, but I thought they fixed that one. [Tue Aug 12 14:55:14 2014] how do I get it to just turn them into goals that I then prove? [Tue Aug 12 14:55:48 2014] I want apply f_equal_but_if_they_don't_unify_then_make_it_a_goal [Tue Aug 12 14:56:13 2014] 1. Are they dependent? 2. Have you tried [rapply f_equal3] or [refine (f_equal3 _ _ _...)]? [Tue Aug 12 14:56:25 2014] ohh [Tue Aug 12 14:56:26 2014] i haven't [Tue Aug 12 14:56:33 2014] uh oh [Tue Aug 12 14:56:37 2014] rapply Build_Cone causes an infinite loop [Tue Aug 12 14:57:22 2014] if you clone github.com/jwiegley/category-theory, you should be able to build it htere [Tue Aug 12 14:57:35 2014] just "make" [Tue Aug 12 14:57:48 2014] then go into Functor.v, line 702, and change it to use rapply [Tue Aug 12 14:57:59 2014] actually, I've been seeing infinite loops in this file a *lot* [Tue Aug 12 14:58:51 2014] huh [Tue Aug 12 14:59:10 2014] even with what I have now, if I don't crush before refine (Build_Cone ...) I get an infinite loop [Tue Aug 12 14:59:30 2014] You should add a .dir-locals.el to set coq-prog-args to ("-emacs" "-R" "." "Hask") (see https://github.com/HoTT/HoTT/blob/master/theories/.dir-locals.el) [Tue Aug 12 14:59:37 2014] ah, thanks [Tue Aug 12 15:01:39 2014] Why do you use -Q in Makefile but -R in _CoqProject? [Tue Aug 12 15:01:45 2014] done [Tue Aug 12 15:01:50 2014] i don't know, copy&paste fail [Tue Aug 12 15:02:06 2014] won't the _CoqProject settings set coq-prog-args correctly? [Tue Aug 12 15:02:26 2014] is -R better, or -Q? [Tue Aug 12 15:05:25 2014] It's not setting it for me, but maybe I've mis-configured my emacs. -R means "I'm not going to fully qualify all of my imports" and -Q means "I am going to ...", right? [Tue Aug 12 15:05:41 2014] you've got me, that's a brand new flag I thought [Tue Aug 12 15:06:33 2014] coqc --help says [Tue Aug 12 15:06:33 2014] -R dir -as coqdir recursively map physical dir to logical coqdir [Tue Aug 12 15:06:33 2014] -R dir coqdir (idem) [Tue Aug 12 15:06:33 2014] -Q dir coqdir map physical dir to logical coqdir [Tue Aug 12 15:06:50 2014] ah [Tue Aug 12 15:07:53 2014] You should make coq-prog-args a local variable, as in the HoTT example I pointed you at, or else emacs will get very confused when you decide you want to mess around in another project that doesn't set coq-prog-args. [Tue Aug 12 15:08:07 2014] i put it into .dir-locals.el [Tue Aug 12 15:09:35 2014] jgross: have you written up somewhere how you use higher inductive types to avoid the need for propositional equality? [Tue Aug 12 15:10:18 2014] Also, you should pass -no-native-compiler to coqc unless you use native_compute. It shaves about a minute off the compilation time of Functor.v (You can use coqc -time -Q . Hask Functor to see that it spends that minute ... after the last Qed in the file.) [Tue Aug 12 15:10:30 2014] sweet [Tue Aug 12 15:11:15 2014] MUCH faster [Tue Aug 12 15:11:24 2014] hmm [Tue Aug 12 15:12:56 2014] johnw: http://homotopytypetheory.org/2011/04/23/running-circles-around-in-your-proof-assistant/ for HITs in agda/Coq in general. The particular proof of epi <-> surj is in the HoTT book (http://homotopytypetheory.org/), I think? See also https://github.com/HoTT/coq/issues/120#issuecomment-46379740. To avoid prop ext in general, you'll want Univalence. [Tue Aug 12 15:13:16 2014] great, thanks [Tue Aug 12 15:13:48 2014] johnw: You should report the issue with -no-native-compiler to the bug tracker (coq.inria.fr/bugs/enter_bug.cgi). Preferably with a .zip file attached of the relevant files up to Functor.v. [Tue Aug 12 15:14:47 2014] what issue was that? [Tue Aug 12 15:25:08 2014] The fact that it makes things slower. [Tue Aug 12 15:26:26 2014] oh [Tue Aug 12 15:28:44 2014] johnw: Here's why the inlined version is failing: in obligation 4 of YonedaLemma, you're relying on generated names. When you define a record in the current file, and then destruct something of that type, the fields get 0s appended to them. When you define the record in a different file, the names don't have 0s. So when you say "id A", you mean "the id that came from [destruct C]", but once it's inlined, that's [id0]. So you should either [Tue Aug 12 15:28:44 2014] use [destruct C as [...]], or you should pick up the names some other way. [Tue Aug 12 15:29:13 2014] ah [Tue Aug 12 15:29:20 2014] thanks for looking into that [Tue Aug 12 15:29:38 2014] In any case, you can open up the file that it gives you the error in, and manually modify it, and then tell it to try again. (If you say "n(o, this isn't the error I was looking for)", it tells you to do so. [Tue Aug 12 15:29:47 2014] btw, in Emacs now I'm getting: [Tue Aug 12 15:29:48 2014] Warning: [Tue Aug 12 15:29:49 2014] Dynlink error, cannot find file /Users/johnw/Projects/category-theory/.coq-native/NHask_Axioms.cmxs in search path [Tue Aug 12 15:29:55 2014] (It won't actually accept the longer version) [Tue Aug 12 15:30:20 2014] Yes, throw -no-native-compiler in coq-prog-args in the .dir-locals.el? [Tue Aug 12 15:31:23 2014] that gives me errors: [Tue Aug 12 15:31:24 2014] *** Warning: in file /var/folders/8h/tky3qz1d63l05l5jp_nzwzjr0000gn/T/ProofGeneral-coq80370JZR.v, library Hask.Category.v is required and has not been found in loadpath! [Tue Aug 12 15:31:40 2014] i have in .dir-locals.el: [Tue Aug 12 15:31:40 2014] ((coq-mode . ((coq-prog-args "-emacs" "-no-native-compiler" "-Q" "." "Hask")))) [Tue Aug 12 15:31:55 2014] although really it should be already picking up flags from _CoqProject [Tue Aug 12 15:32:26 2014] however, putting -no-native-compiler in _CoqProject breaks Makefile.coq [Tue Aug 12 15:32:33 2014] I end up with: [Tue Aug 12 15:32:34 2014] /bin/sh: line 0: cd: ./-no-native-compiler: No such file or directory [Tue Aug 12 15:33:44 2014] no, that wasn't the problem [Tue Aug 12 15:34:04 2014] Try rm -rf .coq-native? [Tue Aug 12 15:34:12 2014] make clean does that, so it wasn't there [Tue Aug 12 15:34:27 2014] Try closing your file and reopening it, to get emacs to look at .dir-locals.el again? [Tue Aug 12 15:34:28 2014] i'm running into something more basic [Tue Aug 12 15:34:30 2014] let me restart emacs [Tue Aug 12 15:38:10 2014] johnw: I'm about to report the -no-native-compiler issue. [Tue Aug 12 15:38:16 2014] thanks [Tue Aug 12 15:38:40 2014] so, -R works for me, -Q does not [Tue Aug 12 15:41:33 2014] https://coq.inria.fr/bugs/show_bug.cgi?id=3511 [Tue Aug 12 15:41:39 2014] Where does -Q not work? [Tue Aug 12 15:41:42 2014] thank you [Tue Aug 12 15:41:47 2014] -Q doesn't work anywhere that I use it [Tue Aug 12 15:41:50 2014] I get those errors I pasted above [Tue Aug 12 15:43:54 2014] If you run coqc -Q . Hask -no-native-compiler .v, do you get it? What about coqtop -Q . Hask -no-native-compiler -compile ? What about coqtop -Q . Hask -no-native-compiler < .v? [Tue Aug 12 15:45:28 2014] coqtop -Q . Hask -no-native-compiler -compile Functor works [Tue Aug 12 15:45:42 2014] coqtop -Q . Hask -no-native-compiler Functor.vDon't know what to do with Functor.v [Tue Aug 12 15:45:42 2014] See --help for the list of supported option [Tue Aug 12 15:45:56 2014] coqc works [Tue Aug 12 15:46:48 2014] coqtop -Q . Hask -no-native-compiler < Functor.v ? [Tue Aug 12 15:47:27 2014] https://github.com/jwiegley/category-theory/blob/master/Utils.v#L26 <- haha. You could just [Require Export Coq.Program.Tactics] instead; I pointed you at the source for the Coq trunk stdlib. [Tue Aug 12 15:47:47 2014] that worked too [Tue Aug 12 15:47:59 2014] ah, ok [Tue Aug 12 15:49:49 2014] It sounds like somehow your emacs isn't getting the -no-native-compiler flag. What command line does the *Messages* buffer say you're running coqtop with? [Tue Aug 12 15:51:17 2014] Starting: /Users/johnw/.nix-profile/bin/coqtop -emacs -no-native-compiler -R . Hask -R /Users/johnw/src/category-theory -as Hask [Tue Aug 12 15:51:34 2014] see, _CoqProject's arguments are getting inserted [Tue Aug 12 15:51:40 2014] so I don't need .dir_locals, except for -no-native-compiler [Tue Aug 12 15:52:52 2014] ok, I need to switch to some work tasks now [Tue Aug 12 15:52:55 2014] thanks for your help jgross [Tue Aug 12 15:53:15 2014] Ah, I guess I just need to go install PG 4.3. [Tue Aug 12 15:53:31 2014] yeah, 4.3_prewhatever [Tue Aug 12 15:54:06 2014] also, have you used prooftree? [Tue Aug 12 15:54:10 2014] i find it to be quite helpful [Tue Aug 12 15:54:12 2014] Good luck with your work tasks. I'm going to head home and have dinner and sleep. And let me (or the bug tracker) know if you find another case where refine (Build_foo _ _ _ _ _...) doesn't work. [Tue Aug 12 15:54:17 2014] doesn't seem to work with Program Instance though [Tue Aug 12 15:54:30 2014] ok, I will keep an eye out, since I'll be using refine a LOT in the coming days [Tue Aug 12 15:56:44 2014] Prooftree looks neat for ssreflect-style proofs. I try to automate everything (Adam's my advisor, so I learned his style, and I also think it makes sense), so I think it wouldn't be super-helpful for me unless it knows how to unroll a [repeat match goal with ... end] automatically. [Tue Aug 12 15:57:13 2014] very true [Tue Aug 12 15:57:19 2014] i'm working my way toward Adam-style [Tue Aug 12 15:57:34 2014] I went to visit him last week, and we spoke about you :) [Tue Aug 12 15:59:57 2014] Really? Will you be joining us at MIT? (I'm curious, if you don't mind sharing, what about me did you talk about?) [Tue Aug 12 16:00:39 2014] no, but I'm working at BAE now, which is in your back yard [Tue Aug 12 16:00:49 2014] I just know Adam from a long ways back, before either of us had found Coq :) [Tue Aug 12 16:01:20 2014] Boston Academy of English? [Tue Aug 12 16:01:26 2014] it has no expansion [Tue Aug 12 16:01:31 2014] gov't contractor [Tue Aug 12 16:01:36 2014] I work on research contracts [Tue Aug 12 16:01:42 2014] what was adam doing before coq? [Tue Aug 12 16:01:51 2014] he was running hcoop! [Tue Aug 12 16:01:56 2014] ohh yeah [Tue Aug 12 16:02:03 2014] I think I was user 11 [Tue Aug 12 16:02:12 2014] jgross: for that matter i live right over in medford [Tue Aug 12 16:02:32 2014] jgross: you and edwardk and I should definitely get some chow together the next time I'm out there [Tue Aug 12 16:02:38 2014] jgross: are you coming to ICFP by any chance? [Tue Aug 12 16:03:18 2014] johnw: hahahaha i just connected the hcoop thing with adam. i'd forgotten that [Tue Aug 12 16:04:02 2014] yeah, that was forever ago. 13 years! [Tue Aug 12 16:04:18 2014] i think that was the year before I join freenode [Tue Aug 12 16:04:49 2014] No, I'm not going to be at ICFP. I'll have just gotten back to MIT from my internship in the UK then. I hope to attend POPL, though. [Tue Aug 12 16:05:15 2014] in India? [Tue Aug 12 16:05:27 2014] Yes ^.^ [Tue Aug 12 16:05:28 2014] jgross: fair nuff. well some time when you're back in the MIT area, ping me and we can grab lunch or something [Tue Aug 12 16:05:39 2014] i doubt I can get work to swing that one; Sweden was a hard enough sell [Tue Aug 12 16:06:56 2014] clearly i should go visit one of the QA teams we have out there at just the right time [Tue Aug 12 16:09:11 2014] Sure, lunch or something sounds great! I'll ping you two when I'm back in Boston. (It might take until October, though, depending on how busy your schedules are. I'll be pretty busy in September; I have a cousin's wedding on the 14th and I'll be in Germany for the Heidelberg Laureate Forum the 19th through the 28th.) [Tue Aug 12 16:11:33 2014] I'm all over the place but late September should be pretty open. [Tue Aug 12 16:11:56 2014] so maybe after ICFP/CUFP [Tue Aug 12 16:11:58 2014] * shrugs. [Tue Aug 12 16:12:01 2014] We'll figure it out [Tue Aug 12 16:31:27 2014] johnw: damn you for getting me to install coq again. =P i was happy and productive in haskell [Tue Aug 12 16:31:40 2014] hahaha [Tue Aug 12 16:31:49 2014] and don't forget proof general 4.3pre! [Tue Aug 12 16:31:59 2014] * watches his days vanish into the hell of the zork-like 'guess the tactic' adventure game [Tue Aug 12 16:32:07 2014] building coq head now [Tue Aug 12 16:32:16 2014] > Take lamp. [Tue Aug 12 16:32:20 2014] I don't know what a lamp is. [Tue Aug 12 16:32:23 2014] > Take the lamp. [Tue Aug 12 16:32:24 2014] Taken. [Tue Aug 12 16:33:17 2014] heh, i have an hour interview thing with jason scott of the get lamp documentary fame coming up, i should mention coq as the spiritual successor to text adventure games to him ;) [Tue Aug 12 16:34:36 2014] o_O [Tue Aug 12 16:34:38 2014] what [Tue Aug 12 16:36:07 2014] hodapp: come on, you've sat there in proof general looking at the current state of the world, your goal, the inventory of stuff you have in the environment and played the "guess the verb" game that defined 80s-90s text adventures. [Tue Aug 12 16:37:29 2014] open the mailbox. get the pamphlet. read the pamplet. vs unfold Monic in *. intros. apply eg. apply ef. -- not much different ;) [Tue Aug 12 16:39:13 2014] vi .emacs # hrmm, i think i'm doing this wrong. [Tue Aug 12 16:41:24 2014] lol [Tue Aug 12 16:42:17 2014] nice, just got Isabella working with proof general [Tue Aug 12 16:42:54 2014] now i just have to remember my way around emacs sans vim bindings =P [Tue Aug 12 16:44:33 2014] install evil [Tue Aug 12 16:45:19 2014] may, but i may just go native again. its been long enough [Tue Aug 12 16:45:40 2014] you know its serious i even gave in and remapped my capslock to ctrl to avoid crippling myself =P [Tue Aug 12 16:46:59 2014] going native is better in the long run [Tue Aug 12 16:47:10 2014] remapping capslock to ctrl is just common sense [Tue Aug 12 17:28:11 2014] oh, did you see that jgross gets dualization of his proofs pretty much for free in his development? [Tue Aug 12 17:28:26 2014] at least, that's what the experience report said [Tue Aug 12 17:37:27 2014] yeah [Tue Aug 12 17:37:30 2014] i walked through that part [Tue Aug 12 17:38:12 2014] noticeably the extra 'redundant' proofs that identity . identity = identity and of the reversed associativity law to make constructing the dual easier [Tue Aug 12 17:38:46 2014] yeah, he's really tempting me to lean in the HoTT direction [Tue Aug 12 17:39:01 2014] only I fear that might lose connection with the Haskell implementation [Tue Aug 12 17:40:02 2014] the haskell implementation is warped by the need to be implemented in haskell [Tue Aug 12 17:40:12 2014] aye, there's the rub [Tue Aug 12 18:55:10 2014] Hey everyone. [Tue Aug 12 18:55:20 2014] http://lpaste.net/109265 – Coq can be confusing sometimes. [Tue Aug 12 18:58:57 2014] I should learn how induction actually works in Coq. [Tue Aug 12 19:00:39 2014] I think that Coq can't do this [Tue Aug 12 19:01:09 2014] I'm pretty sure that Coq can't do that. [Tue Aug 12 19:01:55 2014] Which seems counterintuitive to me. I have two proofs, p and q, that x = x. Are they the same? Well, let's look at all the things p could possibly be. p must be eq_refl x. [Tue Aug 12 19:02:14 2014] this requires an extra axiom than the normal dependent type lambda calculus, to prove [Tue Aug 12 19:02:47 2014] The "look at all the things p could possibly be" step is where things don't work, I think. [Tue Aug 12 19:04:15 2014] tswett: http://homotopytypetheory.org/2011/04/10/just-kidding-understanding-identity-elimination-in-homotopy-type-theory/ [Tue Aug 12 19:11:18 2014] Hmm. [Tue Aug 12 19:17:14 2014] Yeah, my big issue is that I don't see how the type of an induction function is determined. Like, here's how I understand "ordinary" induction: given a predicate over elements of the inductive type, if every constructor preserves truth of that predicate, then the predicate is true everywhere. [Tue Aug 12 19:18:28 2014] So then I try to understand eq_ind like that. Given a predicate over proofs that x = x, if the predicate holds for eq_refl x, then it holds for all proofs that x = x. [Tue Aug 12 19:18:36 2014] But it turns out that eq_ind is actually something completely different. [Tue Aug 12 19:20:25 2014] Ah, but that's not quite how eq is defined. [Tue Aug 12 19:20:36 2014] The "elements of the inductive type" are actually functions A -> Prop. [Tue Aug 12 19:20:49 2014] Okay, let me retry that understanding. [Tue Aug 12 19:21:55 2014] When you define an inductive data type the eliminators are automatically created [Tue Aug 12 19:22:03 2014] Have a look at [Tue Aug 12 19:22:04 2014] Print bool. [Tue Aug 12 19:22:04 2014] then [Tue Aug 12 19:22:06 2014] Print bool_rec. [Tue Aug 12 19:22:11 2014] I know that much. [Tue Aug 12 19:22:23 2014] But I'm wondering how the types of the eliminators are determined. [Tue Aug 12 19:23:21 2014] it creates a hypothesis for each constructor of the type and concludes with the predicate for all values of that type [Tue Aug 12 19:23:54 2014] So now I'd expect eq_ind to look like this: Given a predicate P over equality predicates (x =), if the predicate P holds for eq_refl x, then the predicate P holds for all equality predicates (x =). [Tue Aug 12 19:25:26 2014] Which is starting to resemble the actual type of eq_ind, but still isn't correct. [Tue Aug 12 19:28:43 2014] The type of P in an eliminator seems to be random. [Tue Aug 12 19:29:42 2014] In eq_ind, P : A -> Prop; it's a predicate over one of the arguments to eq. In and_ind, P is just a proposition. In bool_ind, P is a predicate on bool. [Tue Aug 12 19:31:48 2014] that's because it has type indices [Tue Aug 12 19:32:15 2014] if you look at bool then option and so on, you can understand the pattern gradually [Tue Aug 12 19:32:23 2014] If you say so. [Tue Aug 12 19:32:27 2014] wow [Tue Aug 12 19:32:30 2014] good bye [Tue Aug 12 19:35:13 2014] Sorry, did I come across as rude there? I'm just saying that this concept has been difficult for me to understand, so I expect it to be a struggle going on. [Tue Aug 12 19:35:25 2014] I didn't mean to dismiss your advice. [Tue Aug 12 19:37:22 2014] makes me wonder why I try to help people when they act like such assholes, hopefully nicer people show up soon [Tue Aug 12 19:37:46 2014] Sorry, I honestly don't understand what I did wrong. [Tue Aug 12 19:38:41 2014] tswett: there's a really nice paper by Peter Dybjer that explains how recursors for type families are defined [Tue Aug 12 19:38:46 2014] http://www.cse.chalmers.se/~peterd/papers/Inductive_Families.pdf [Tue Aug 12 19:40:11 2014] if you are just looking for technical definitions [Tue Aug 12 19:40:38 2014] the semantics are a bit more complex [Tue Aug 12 19:58:46 2014] vanila: okay, I've looked at bool and option, and yeah, I can see how the constructor hypotheses work. Thanks. [Tue Aug 12 19:59:00 2014] When you say "it has type indices", what's the thing that has type indices? [Tue Aug 12 20:23:01 2014] Okay, I think I finally understand exactly how the type for eq_ind is constructed. [Tue Aug 12 20:26:21 2014] First, the parameters (A : Type) and (x : A). These are just the parameters to eq. Next, (P : A -> Prop)--P always has the same kind as the inductive type itself (as long as the inductive type is of class Prop, not Type). [Tue Aug 12 20:26:55 2014] Then the inductive hypotheses are always the types of the constructors, where the inductive type is replaced with P. In this case, eq x is replaced with P, yielding P x. [Tue Aug 12 20:27:43 2014] Finally, the assertion that as long as the inductive type is actually populated, P is populated, too. [Tue Aug 12 20:32:17 2014] tswett: That's about the long and short of it, except that P can depend on the element of the inductive itself [Tue Aug 12 20:35:35 2014] cody__: right. If I understand correctly, that happens when the inductive is a Set or Type. When the inductive is a Prop, P doesn't depend on the proof. [Tue Aug 12 20:36:05 2014] when I is a Prop [Tue Aug 12 20:36:18 2014] I being the inductive [Tue Aug 12 20:36:47 2014] Indeed, if I understand correctly, Coq never lets you prove that a predicate holds for all proofs of a proposition (unless you can prove that there are no proofs of that proposition). [Tue Aug 12 20:38:01 2014] well you can, you just shouldn't be able to distinguish propositions [Tue Aug 12 20:38:33 2014] which means you shouldn't be able to case on I:Prop into Type [Tue Aug 12 20:38:47 2014] oops [Tue Aug 12 20:38:49 2014] gtg [Tue Aug 12 21:03:52 2014] Guess I'm wrong about the latter part. You can indeed prove that every proof of True is I. [Wed Aug 13 01:13:02 2014] hello. I'm trying to make function threading (composition) that gathers proofs returned by functions: http://pastebin.com/4MffD1JM , but it seems I'm trying to do something impossible. Right? [Wed Aug 13 01:17:47 2014] cur_prop has the wrong type [Wed Aug 13 01:17:54 2014] it's not the type of a proposition, but a proof term [Wed Aug 13 01:19:53 2014] I've tried to write other things in { n : nat | }, but no one worked. There's something I don't understand, obv. [Wed Aug 13 01:20:16 2014] write out the result type of step first [Wed Aug 13 01:20:24 2014] that shoudl help clarify things [Wed Aug 13 01:22:02 2014] "(nat * Prop)". For example, Check (1, True) returns this type, and I could be happy with it. [Wed Aug 13 01:22:39 2014] have you tried (f : nat -> { n : nat & P })? [Wed Aug 13 01:23:45 2014] yes, error is the same. [Wed Aug 13 01:25:43 2014] maybe (f : nat -> { n : nat & Prop })? The thing is, you're treating { n : nat | P } and (nat * Prop) as if they were effectively the same thing [Wed Aug 13 01:25:55 2014] so they need to be the same thing [Wed Aug 13 01:25:58 2014] if that's right [Wed Aug 13 01:31:11 2014] gdsfh: can you say more about what you're trying to do? [Wed Aug 13 01:32:29 2014] johnw: really, "step" typechecks. But then "Definition f1 n : { n' : nat & n' = S n }." doesn't work in "Example s : unit. refine (step f1 (0, True)).": "The term "f1" has type "forall n : nat, {n' : nat & n' = S n}" while it is expected to have type "nat -> {_ : nat & Prop}".". I need to return Prop from f1 somehow, but I don't know how to make Prop of "n' = S n". [Wed Aug 13 01:35:18 2014] jrw: I have functions that {take,return} proofs and values. I want to use them in code without providing proofs in the code (using notations, for example), and gather all proofs that these functions return, to use them in proof mode for reasoning about code and for providing input proofs for these functions. [Wed Aug 13 01:35:53 2014] gdsfh: are you talking about a Hoare logic? [Wed Aug 13 01:36:27 2014] Hoare logic is very close to what I want to do. [Wed Aug 13 01:36:44 2014] so, yes. [Wed Aug 13 01:37:16 2014] software foundations has a couple of chapters on doing that in Coq, if you haven't seen that already [Wed Aug 13 01:37:43 2014] also of possible interest: http://ynot.cs.harvard.edu/ [Wed Aug 13 01:38:15 2014] I'll read SF on this topic. Ynot -- seen. [Wed Aug 13 01:38:56 2014] so hoare logic may not be exactly what you're going for. classically speaking hoare logic is applied to imperative style languages. [Wed Aug 13 01:39:10 2014] but any ideas are welcome. [Wed Aug 13 01:39:13 2014] obviously the idea is very general [Wed Aug 13 01:39:31 2014] whenever I hear "step" I hear imperative... [Wed Aug 13 01:40:10 2014] really, it's about imperative stuff representation. [Wed Aug 13 01:41:14 2014] gdsfh: http://pastebin.com/BdDREznA [Wed Aug 13 01:41:20 2014] I think this is what you were getting at [Wed Aug 13 01:41:44 2014] you have some f that returns a proof of p and some value that's a nat and a proof of q [Wed Aug 13 01:42:01 2014] you want to run f on the nat and get a proof of P, and return the result together with a proof of p /\ q [Wed Aug 13 01:42:15 2014] the trick is that you need to return a proof object that proves p /\ q [Wed Aug 13 01:42:26 2014] you can't just return the value "p /\ q" [Wed Aug 13 01:42:29 2014] which has type Prop [Wed Aug 13 01:42:30 2014] based on the non-dependent sigma, couldn't it be (f : nat -> (nat * P))? [Wed Aug 13 01:42:47 2014] yeah, those are exactly the same [Wed Aug 13 01:46:55 2014] jrw: doesn't work: The term "f1" has type "forall n : nat, {n' : nat | n' = S n}" while it is expected to have type "nat -> {_ : nat | ?40}". [Wed Aug 13 01:59:15 2014] johnw: awake? [Wed Aug 13 01:59:29 2014] that's funny [Wed Aug 13 01:59:34 2014] i was just checking to see if you were around [Wed Aug 13 01:59:40 2014] I'm bored of register allocators, let's have some fun [Wed Aug 13 01:59:48 2014] heh [Wed Aug 13 01:59:50 2014] ok, one sec [Wed Aug 13 02:02:02 2014] gdsfh: can you put your example code on a pastebin? it didn't come through right for me. [Wed Aug 13 02:05:20 2014] jrw: http://pastebin.com/AU9eE8nh [Wed Aug 13 02:06:24 2014] thanks [Wed Aug 13 02:19:44 2014] gdsfh: http://pastebin.com/4cUXTy4B [Wed Aug 13 02:31:29 2014] jrw: thank you, it works! Also it works when I do "{inp outp} {P : inp -> outp -> Prop}" in step arguments and below. Nice! [Wed Aug 13 02:32:09 2014] np [Wed Aug 13 03:18:02 2014] can I have mutually recursive records? [Wed Aug 13 03:36:18 2014] johnw: afaik no; last answer I received about this was "use mutually recursive inductive types to emulate records". [Wed Aug 13 03:36:36 2014] when using mutually recursive inductive types how much uglier does it get? [Wed Aug 13 03:38:11 2014] 1. explicit projections need to be written, 2. no record.(field) notation, only "proj record". [Wed Aug 13 03:38:31 2014] 2.) was what i was afraid of [Wed Aug 13 03:39:10 2014] i suppose you could define the raw 'un-tied' record, make inductive data types that used the raw records as their only members and tie through that? [Wed Aug 13 03:39:11 2014] however maybe it's possible to invent nicely looking notation like "r f" := (f r). [Wed Aug 13 06:32:44 2014] so im using refine to skip over some things and fill in the blanks later [Wed Aug 13 06:33:01 2014] how do i make it so that Coq remembers where the fillers came from? [Wed Aug 13 06:33:38 2014] for example, [Wed Aug 13 06:34:44 2014] https://privatepaste.com/d098c77d10 [Wed Aug 13 06:35:16 2014] at the end, im left with this proof state: https://privatepaste.com/4dea4a37dc [Wed Aug 13 06:35:49 2014] basically, if Coq would have remembered that x was originally in lss, this would be (almost) trivial [Wed Aug 13 07:01:27 2014] http://gizmodo.com/a-computer-has-finally-proven-the-answer-to-a-400-year-1620027845 [Wed Aug 13 07:01:39 2014] * stabs the author of that article, and most of the commenters [Wed Aug 13 07:01:55 2014] * sees "gizmodo", ignores [Wed Aug 13 07:02:29 2014] a wise choice. [Wed Aug 13 07:02:33 2014] I missed that when I clicked. [Wed Aug 13 07:02:49 2014] tl;dr https://en.wikipedia.org/wiki/Kepler_conjecture#A_formal_proof [Wed Aug 13 07:48:03 2014] Hello all! I'm currently trying to get an overview over the different kinds of Martin Loef Type Theories. Concerning the system described in "Intuitionistic Type Theory", I'm wondering if one can replace the new kind of judgement "A Type" by an ordinary typing judgement "A : Type" with an atomic type 'Type'. As far as I understand, unless one is willing to add a whole hierarchy of types as in Coq, this means that 'Type' itself will not [Wed Aug 13 07:48:03 2014] have any type, since 'Type : Type' is inconsistent -- but does this cause problems? Can't one have expressions that arise as types of other expressions, while they are themselves not of any type? [Wed Aug 13 07:49:03 2014] With 'Type' introduced as an atomic type, one could e.g. model first order predicate logic by having 'A : Type' as an axiom for any sort A, and 'reln : A1 -> ... -> An -> Type' as an axiom for any n-ary predicate between sorts Ai, and 'fn: A1 -> ... -> An -> B' as an axiom for any n-ary function symbol in the theory. While it's not very different from having "A type" as a new kind of judgement, and introducing axioms 'x1 : A1, ..., xn: [Wed Aug 13 07:49:03 2014] An |- reln x1 ... xn type' and so on for sorts, relations and functions, I'd find the above variant more natural. But maybe I'm missing some complications that arise...? [Wed Aug 13 08:17:37 2014] johnw, edwardk: Yes, I get almost all dualization for free (except for this pesky bit of limits not being opposite colimits when they're defined as Kan extensions, because (C^op -> D^op)^op isn't judgmentally (C -> D). You don't have to use HoTT to do this, though. However, the correct solution is clearly to get ghc to implement HoTT, to mirror the Coq stuff. (Using HoTT also doesn't need to pull you away from Haskell. You just need to think [Wed Aug 13 08:17:37 2014] more carefully about which types are actually sets and which types are univalent and which types are hProps.) [Wed Aug 13 09:08:24 2014] johnw: Do you want to add your email address to https://coq.inria.fr/bugs/show_bug.cgi?id=3511, so you get updates and can respond with things about your code? Pierre-Marie Pédrot said "I think that you're stressing the native compiler too much. It doesn't really like to be fed with huge proof terms, and this is not its purpose altogether... I'll assign this bug to Maxime anyway." [Wed Aug 13 10:03:27 2014] jgross: we definitely know we're leaning on the compiler too hard just trying to brute force stuff through as we go [Wed Aug 13 10:05:02 2014] jgross: part of what i started last night was going through and seeing if we can swap out the foundations to make something prettier, because what is there is just an effort in programming by force of will, not elegance =) [Wed Aug 13 10:15:09 2014] edwardk: Where are you running into trouble with brute force? (I think most places where I throw brute force tactics at things are either when I'm shoving isomorphisms around (mostly pseudofunctors and grothendieck) and when transporting across equalities is painful because Coq's pattern matcher isn't good enough. I guess my yoneda proofs are a bit ugly, but not very long. I also might have forgotten some cases.) [Wed Aug 13 10:17:02 2014] so far we're getting by actually, this is sort of stab 1 while we get the kinks worked out of how to work. the main thing i want to do is go do work with double categories / framed bicategories / proarrow equipments where things are much more interesting, but we need to get past the base vocabulary first [Wed Aug 13 10:17:41 2014] my usual approach is to just spew code out, learn the language as we go, and ruthlessly refactor over and over [Wed Aug 13 10:18:06 2014] we'll probably adopt your symmetry hacks [Wed Aug 13 10:21:29 2014] the current work we're doing is just setting up limits and colimits in terms of adjoints to the diagonal functor, then monoidal categories, so we can do day convolution, set up monoidal functors and monads as monoids, and then do profunctor composition, show prearrows as monoids of profunctor composition, build a notion of a generalized tambara module that I use for lens so we can get free freyd categories and can freely adjoin [Wed Aug 13 10:21:29 2014] 'profunctor strength' to any profunctor, model monads and comonads on the category of profunctors, since the Tambara construction is a comonad, and the left adjoint to the construction is a monad whose monad algebras are the strong profunctors [Wed Aug 13 10:21:39 2014] once we have that we can start talking about the lens plumbing [Wed Aug 13 10:21:50 2014] thats the stuff i want to talk about mostly [Wed Aug 13 10:22:24 2014] and i'm happy to swap out plumbing a couple dozen times to get a better sense of taste til we get there. [Wed Aug 13 10:22:27 2014] I'll be interested to see if you can get 2-category stuff working with reasonable speed. I had problems when I tried in 8.4, though now that trunk is faster, I might try again. [Wed Aug 13 10:23:10 2014] especially since i'm more interested in virtual double categories than 2-categories [Wed Aug 13 10:24:52 2014] I have (co)limits as adjoints to the diagonal functor (there's a nifty way of setting this up where you define adjoints using universal morphisms, and you get the usual definition of limits just by unfolding that definition), and I had monoidal categories at one point, but that's where things started getting really slow. [Wed Aug 13 10:24:56 2014] i figure the two areas i really know category theory cold are in all the generalized notions of currying/uncurrying/powers/copowers that arise and the asymptotic benefits of certain representations, and in the area of framed bicategories since lens is basically built upon quantifying over the choice of all possible profunctors and working with interesting functors between certain full-subcategories of prof [Wed Aug 13 10:26:55 2014] here we got stuck a little bit on limits the other day because i forgot a side-condition and poor john beat his head against a wall trying to prove the unprovable for a couple hours, but i think we know the right way forward now [Wed Aug 13 10:27:03 2014] or rather 'a way forward' [Wed Aug 13 10:27:08 2014] i hesitate to say the right way [Wed Aug 13 10:27:51 2014] but ultimately to dodge axiom of choice issues we're going to get shoehorned into taking the univalence approach you did or going to anafunctors and ananatural transformations soon [Wed Aug 13 10:28:54 2014] Yeah, I did something like that when I was first formalizing limits. I said something like "there exists a unique morphism m : s -> d, and also P holds of m" rather than "there exists a unique morphism m : s -> d for which P holds". I developed an allergy to having too many side conditions and moved to the "intial/terminal objects of comma categories" definition. [Wed Aug 13 10:29:18 2014] not a bad choice [Wed Aug 13 10:29:30 2014] Univalence! (Although, I don't actually make use of it that much, yet.) [Wed Aug 13 10:30:17 2014] i'm probably going to steer john towards defining dinatural transformations and swapping out the guts of our natural transformations, build comma categories, do grothendieck through commas, etc. [Wed Aug 13 10:31:08 2014] ultimately the main thing where univalence gives me heebie-jeebies is i don't really have a firm grasp of where my programs will get stuck because of it. [Wed Aug 13 10:31:32 2014] It's really slick, because you get the fact that (co)limits assemble into a functor which is adjoint to the diagonal functor for free, out of the appropriate characterization of adjoint functors in general. (I'm kind-of bummed that the adjoint functor theorem talks about limits and colimits in particular; I want to see if there's some nice way of looking at it so that you only talk about adjoints without explicitly mentioning the diagonal [Wed Aug 13 10:31:32 2014] functor, or something.) [Wed Aug 13 10:32:45 2014] Why do you need dinatural transformations to do comma categories? And how do comma categories give you grothendieck? [Wed Aug 13 10:33:17 2014] * reads "dinosaur transformations" [Wed Aug 13 10:33:19 2014] you don't need it for comma categories, but you want them so you can talk about ends/coends, then use the end to build nat [Wed Aug 13 10:33:19 2014] * rubs eyes [Wed Aug 13 10:33:31 2014] and the comma category is a nice place to do all that [Wed Aug 13 10:33:40 2014] if you don't want to just directly compose the functors [Wed Aug 13 10:35:01 2014] Univalence will never make your programs get stuck forever; you can always compute by hand, or wait until the technology develops to compute automatically. You might need a "compute by tactics" or "univalence scrubber tactic" or something. (And it'll get your programs temporarily stuck in roughly the same places that using funext will get them stuck, I think, except when you're talking about types rather than functions) [Wed Aug 13 10:35:37 2014] that's fair [Wed Aug 13 10:35:48 2014] Oh, because grothendieck is a (co)end over something? I remember thinking (co)ends were ugly because the diagram you were taking the (co)limit over was too complicated. [Wed Aug 13 10:35:53 2014] univalence is actually very much my preferred way of thinking about this stuff [Wed Aug 13 10:36:35 2014] part of this is me going off and trying all the dumb ways to put things together so i can know in my bones why they are dumb and if not make a little progress ;) [Wed Aug 13 10:38:10 2014] for fiddling with univalence then, what is needed that isn't in head? do you still need to go off and apply the voevodsky hacks to dodge the use of prop etc? [Wed Aug 13 10:38:38 2014] i'm happy to go back down that path in a branch or side project [Wed Aug 13 10:40:20 2014] Depends how much you care about consistency. If you want to keep [eq] out of Prop, you need to replace the standard library and use one compiled with -indices-matter (forces [eq] to be in Type). HoTT/HoTT does this. If you don't care about smuggling large types into prop and having unsound extraction when you use univalence, you don't need to do anything. Regardless, you don't need to patch HEAD Coq or anything like that. [Wed Aug 13 10:41:01 2014] ok, so -indices-matter is the real trick [Wed Aug 13 10:41:29 2014] is this a workaround for jmeq? [Wed Aug 13 10:41:30 2014] i may sit down and brute force my way through a simple core then just for familiarity's sake [Wed Aug 13 10:41:42 2014] Yes. It says "if my inductive type has large indices, then it can't live in Prop", roughly. [Wed Aug 13 10:42:17 2014] jmeq being the old john major equality thing? [Wed Aug 13 10:42:39 2014] yeah [Wed Aug 13 10:42:41 2014] i can never remember the dumb political joke he was making [Wed Aug 13 10:42:53 2014] everyone is equal, some more than others [Wed Aug 13 10:42:58 2014] vanila: What do you mean? JMeq is equality of pointed types. That is [JMeq A a B b] is equivalent to [(A; a) = (B; b) :> { T : Type & T }] [Wed Aug 13 10:42:59 2014] ah yes [Wed Aug 13 10:43:29 2014] i gotta run sorry [Wed Aug 13 10:43:32 2014] saked at a bad time [Wed Aug 13 10:44:37 2014] edwardk: While you're at it, you should [Set Primitive Projections], so you get judgmental eta for records (and faster nested sigma types). [Wed Aug 13 10:44:52 2014] that is the thing that lets you do field projections? [Wed Aug 13 10:45:15 2014] What do you mean? [Wed Aug 13 10:46:28 2014] turning that on now [Wed Aug 13 10:46:58 2014] Set Printing Projections i guess [Wed Aug 13 10:47:20 2014] http://coq.inria.fr/V8.2pl1/refman/Reference-Manual004.html the bit about dot projection [Wed Aug 13 10:47:46 2014] No, I mean Primitive projections, not Printing projections. It's a new feature of trunk. [Wed Aug 13 10:48:09 2014] yeah noticed the different words after i asked [Wed Aug 13 10:48:23 2014] turning that on now everywhere [Wed Aug 13 10:49:41 2014] Once I get Matthieu to fix the remaining bugs, I'll move to that in the HoTT library, and I'll only need one kind of opposite natural transformation, rather than the 8 or 16 I have now. [Wed Aug 13 10:54:54 2014] that is a very strong argument for turning it on. what goes wrong? [Wed Aug 13 10:56:13 2014] https://coq.inria.fr/bugs/show_bug.cgi?id=3507, https://coq.inria.fr/bugs/show_bug.cgi?id=3503, https://coq.inria.fr/bugs/show_bug.cgi?id=3481, https://coq.inria.fr/bugs/show_bug.cgi?id=3484, https://coq.inria.fr/bugs/show_bug.cgi?id=3505, https://coq.inria.fr/bugs/show_bug.cgi?id=3504, https://coq.inria.fr/bugs/show_bug.cgi?id=3478, https://coq.inria.fr/bugs/show_bug.cgi?id=3506 [Wed Aug 13 10:58:03 2014] There are some minor bugs with evars vs. metas, things (such as subject reduction) break if you ever mix [match] and the primitive projections, and [?f ?x] no longer matches an application of a primitive projection. And if you mix the eta-expanded forms with the non-eta-expanded forms, [rewrite] fails. That's most of it. [Wed Aug 13 10:58:45 2014] Nothing that can't be worked around, but stuff I want to see fixed in Coq rather than committing a bunch of changes to work around it. [Wed Aug 13 10:59:17 2014] fair [Wed Aug 13 11:00:43 2014] e.g., until recently, things like [apply ] failed if was a primitive projection; now it silently eta-expands instead, which is what I think it should do. (After that, the diff to make HoTT/HoTT work with primitive projections went from ~700 loc changed to ~200 loc changed) [Wed Aug 13 13:48:31 2014] morning [Wed Aug 13 21:46:20 2014] jgross: around? [Wed Aug 13 21:48:25 2014] Trying to understand Local Obligation Tactic. If I turn it on, I have a Program Instance block that has 'solved obligations' but i still have to open them one at a time and say they are defined [Wed Aug 13 21:48:46 2014] tried: Local Obligation Tactic := path_induction. [Wed Aug 13 21:49:08 2014] and i have a ton of obligations that all look like Obligation 2. path_induction. Defined. that i'd think that would clear out [Wed Aug 13 21:49:27 2014] https://github.com/jwiegley/category-theory/blob/master/Toy.v#L117 [Wed Aug 13 21:50:16 2014] ideas? [Wed Aug 13 21:51:37 2014] I also am not clear on how to use Solve Obligations with ... [Wed Aug 13 21:51:49 2014] they all need the same tactic [Wed Aug 13 22:02:57 2014] it just weirds me out that i get Obligation 1. Defined. -- for some of them after o turn on the Local Obligation Tactic -- but others don't work [Wed Aug 13 22:04:21 2014] me too [Thu Aug 14 02:28:51 2014] edwardk: Replace [induction] with [destruct] in [path_induction] and it should work fine. Also, add yourself to https://coq.inria.fr/bugs/show_bug.cgi?id=3517. :-P [Thu Aug 14 03:52:09 2014] good morning [Thu Aug 14 04:03:04 2014] Also, johnw, edwardk: You should list all of your files in _CoqProject, and not pass *.v to coq_makefile (also, possibly don't pass '.', but I'm not sure about that one). This way, you won't get the page of spew about duplicated targets. [Thu Aug 14 04:03:17 2014] torfscholle: good morning [Thu Aug 14 04:03:30 2014] ah, ok [Thu Aug 14 04:03:34 2014] i do list the files in _CoqProject [Thu Aug 14 04:04:16 2014] ah, much nicer [Thu Aug 14 04:05:28 2014] Also, use $(MAKE), rather than make, to invoke make on, e.g., Makefile.coq. I think this will make `make -j4` (or however many threads you want) work for the parallel build) [Thu Aug 14 04:19:39 2014] thanks! [Thu Aug 14 04:23:57 2014] Would you mind if I asked some basic thing about systems with dependent types, although not yet Coq? [Thu Aug 14 04:24:07 2014] go for it [Thu Aug 14 04:26:25 2014] I'm trying to understand the precise relation between ML type theory, the logical framework lLF as in Pierce's ATPL, and the PTS lP over {*,o}, {* : o}, {(*,*), (*,o)}. [Thu Aug 14 04:27:27 2014] It seems that in MLTT, one can only form product and sum types of dependent types, but the dependent types themselves do not exist in the system -- they can only be realized through new axiomatic judgements as 'x y : A |- I x y Type' [Thu Aug 14 04:29:14 2014] In lLF, one can introduce them through adding kind assumptions 'I :: A -> A -> *' to the context, but still, one can't define new dependent types through lambda abstractions. In lP finally, one does have abstraction on the type level, and this seems most natural to me. Despite these differences, I'm wondering that all these systems allow for a faithful embedding of first order predicate logic? [Thu Aug 14 04:34:58 2014] ... or am I mixing things up? [Thu Aug 14 04:36:21 2014] I don't know enough to say [Thu Aug 14 04:51:08 2014] johnw: okay, thanks for reading! It's not terribly important anyway, I'm just trying to get a better overview over the many different type systems. [Thu Aug 14 04:52:37 2014] johnw: what are you working on? [Thu Aug 14 04:52:48 2014] MoreLogic.v from Software Foundations right now [Thu Aug 14 04:53:25 2014] they added a morelogic? [Thu Aug 14 04:53:36 2014] yeah, 3.0 changed a lot [Thu Aug 14 05:00:30 2014] johnw: ah, interesting. is this the definition of existential quantification that's automatically loaded and used in coq when one writes "exists ..."? [Thu Aug 14 07:57:47 2014] anybody have an example of well-founded recursion? I find the Adam Chlipala example highly confusing [Thu Aug 14 08:15:20 2014] (ie. of a function using Fix) [Thu Aug 14 09:25:28 2014] roosbeef: hi. as far as I understand it, realizing a recursion as being well-founded is a generalization of the method of proving termination of recursive definitions by means of assigning non-negative integer values to the values over which you induct, in such a way that they decrease on each induction step. this is most obvious if the values themselves are numerical, as in the definition of the factorial, but it also works in the [Thu Aug 14 09:25:28 2014] mergesort example, where each time mergesort calls itself, it does so with a list of smaller size as argument. however, the point of the technique is not that you are working with non-negative integers, but only that you know there is no infinite strictly decreasing chain of such, and this is precisely what you keep when working with a general well-founded relation [Thu Aug 14 09:33:09 2014] I don't know a *useful* example of a well-founded relation R on a type A which is not "layered" in the sense that there is some function f : A -> N_{>= 0} such that R x y <=> f x <= f y, but they exist: for example, consider ordered chains of elements of length 1,2,3,..., and tie them all together at their top element (or take any rooted tree with longer and longer paths from the root to the leaves). then this is a well-founded relation [Thu Aug 14 09:33:10 2014] over which you could possible induct, but it is not realizable through a numerical function f as above. [Thu Aug 14 09:56:59 2014] hm [Thu Aug 14 09:57:07 2014] unfortunately i have to run now [Thu Aug 14 09:57:11 2014] work in 3 minutes :p [Thu Aug 14 09:57:20 2014] ill look into it later [Thu Aug 14 09:57:22 2014] thanks a lot! :) [Thu Aug 14 11:54:14 2014] hello [Thu Aug 14 11:56:28 2014] i'm a little bit stuck, could someone kindly help me with http://lpaste.net/1719548139012096000 ? [Thu Aug 14 11:57:07 2014] i just don't know how to approach it, struggling for couple of days already and feeling terminally dumb [Thu Aug 14 11:58:05 2014] What do you import for this? [Thu Aug 14 11:58:12 2014] snoc is missing [Thu Aug 14 12:00:30 2014] http://lpaste.net/1719548139012096000 is it okay now? [Thu Aug 14 12:00:34 2014] it's from SF [Thu Aug 14 12:03:48 2014] should not require any import at all http://lpaste.net/1719548139012096000 [Thu Aug 14 12:04:18 2014] sorry about previous ones [Thu Aug 14 12:05:31 2014] this is kind of tricky, did oyu try proving a lemma about split'? [Thu Aug 14 12:05:40 2014] rather than trying to prove the theorem directly by induction on l or so [Thu Aug 14 12:06:34 2014] nope, what kind of lemma one can prove about split' to assist combine_split proof? [Thu Aug 14 12:07:15 2014] im having a look [Thu Aug 14 12:07:49 2014] did i defined split function in a i shouldn't have at this point in book? [Thu Aug 14 12:08:15 2014] i wonder how else one can define split... using map problably but map is defined well after split in book [Thu Aug 14 12:09:50 2014] split' l (a1, a2) = (l1, l2) -> combine l1 l2 = app(combine a1 a2) l. [Thu Aug 14 12:09:51 2014] maybe this? [Thu Aug 14 12:10:21 2014] I don't know how this related to the book, this is so hard that I imagine you've strayed off the book - but still should be provable and a good learning exercise [Thu Aug 14 12:11:54 2014] haha, kind of relief to hear "this is so hard" from someone else, after struggling with it so much time :) [Thu Aug 14 12:13:19 2014] vanila: let me try to prove it tonight, not sure how it going to help with main proog yet tho [Thu Aug 14 12:14:20 2014] I don't know if this lemma will be easier to prove [Thu Aug 14 12:14:25 2014] let me show you how I came up with it [Thu Aug 14 12:14:57 2014] i guess i just defined split really not the way Pierce imagined one would define it [Thu Aug 14 12:15:12 2014] There are two difficult things about this [Thu Aug 14 12:15:39 2014] First is that you are doing stuff with snoc, reversing lists [Thu Aug 14 12:16:27 2014] second is that the recusion scheme would be nicer if both lists were the same length, but this isn't assured [Thu Aug 14 12:18:06 2014] http://bpaste.net/show/YIfYSTV315agRoTn6Zz6/ [Thu Aug 14 12:20:42 2014] I don't think combine_snoc_lemma is true so this can't work without extra assumptions [Thu Aug 14 12:20:57 2014] vanila: i could get rid of snoc thing if i define split like this "Fixpoint split {X Y : Type} (l : list (X*Y)) : (list X) * (list Y) := (map fst l, map snd l). [Thu Aug 14 12:21:00 2014] " [Thu Aug 14 12:21:09 2014] that could definitely help [Thu Aug 14 12:21:34 2014] that wil make proving this much easier [Thu Aug 14 12:22:31 2014] oh, okay, let me try, i guess i can't use map here because it will be defined later on so i'll define split' and split'' which just specialized map on fst and snd functions [Thu Aug 14 12:23:15 2014] i hvae to go, good luck [Thu Aug 14 12:23:41 2014] thanks! [Thu Aug 14 13:01:16 2014] When I see [Thu Aug 14 13:01:17 2014] { PreOrder_Reflexive :> Reflexive R | 2 ; -- what is the | 2 ? [Thu Aug 14 13:13:33 2014] edwardk: It's a priority. See http://coq.inria.fr/refman/Reference-Manual022.html#hevea_command314 [Thu Aug 14 13:13:52 2014] thanks [Thu Aug 14 13:14:07 2014] (The :> means "Existing Instance" for Classes, and "Coercion" for Records.) [Thu Aug 14 13:14:18 2014] yeah [Thu Aug 14 13:14:23 2014] i grok the :> part [Thu Aug 14 13:14:31 2014] next question, since i have you =) [Thu Aug 14 13:14:50 2014] Local Obligation Tactic -- how do i get it to actually do work? [Thu Aug 14 13:15:00 2014] i can get it to _almost_ finish my obligations [Thu Aug 14 13:15:25 2014] but they get left hanging where i still need to open some of them up with Obligation 1. Defined. -- to finish them off =/ [Thu Aug 14 13:15:59 2014] i have a crap ton of things that can all be defined by path_induction [Thu Aug 14 13:16:20 2014] and it'd be nice to just kill all the boilerplate Next Obligation. path_induction. Defined. lines in my project [Thu Aug 14 13:16:29 2014] Update Coq. Matthieu fixed https://coq.inria.fr/bugs/show_bug.cgi?id=3517. [Thu Aug 14 13:16:31 2014] i tried Solve All Obligations with path_induction. [Thu Aug 14 13:16:33 2014] k [Thu Aug 14 13:16:46 2014] perfect [Thu Aug 14 13:17:20 2014] (If you ever have to do [Next Obligation. Defined.], it's probably a bug, and likely worth tracking down and reporting.) [Thu Aug 14 13:18:05 2014] i didn't get very far with your Set Primitive Projections suggestion. [Thu Aug 14 13:18:18 2014] that one blew up on me halfway through my second or third record/class [Thu Aug 14 13:18:39 2014] and i'm glad to hear it wasn't just me on that one =) [Thu Aug 14 13:19:04 2014] i was wracking my brains trying to figure out why Solve All Obligations / Obligation Tactic wasn't working [Thu Aug 14 13:19:33 2014] Blew up on you how? Like, rewrite started failing? Or Ltac pattern matching started failing? Or like, Coq crashed or melted your computer? (Or something else?) [Thu Aug 14 13:21:12 2014] let me turn it on again real quick [Thu Aug 14 13:21:29 2014] Set Primitive Projections [Thu Aug 14 13:21:31 2014] er [Thu Aug 14 13:21:40 2014] Error: Cannot recognize a projection [Thu Aug 14 13:21:56 2014] Yeah, I generally take the "minimize first, report second, applogize if it's not actually a bug later" approach. (I had to do that last one for https://coq.inria.fr/bugs/show_bug.cgi?id=3498. But more often then not, I either notice how it works in the process of minimizing the code, or it's actually a bug.) I guess this might only work well because I have a pretty decent idea of how most of Coq works. [Thu Aug 14 13:21:56 2014] is what i get when i go to use one of the Class definitions that works fine without it [Thu Aug 14 13:22:08 2014] Er, what's the class definition? [Thu Aug 14 13:22:23 2014] When you declare the class, or use it? [Thu Aug 14 13:22:28 2014] when i declare it [Thu Aug 14 13:22:33 2014] i don't even get close to using it [Thu Aug 14 13:22:59 2014] its a precategory class that looks a lot like yours, for setting up an (infinity,1)-category, sans the IsHSet constraint on morphisms [Thu Aug 14 13:24:02 2014] Toplevel input, characters 0-160: [Thu Aug 14 13:24:03 2014] Anomaly: Backtrack.backto 40: a state with no vcs_backup. Please report. [Thu Aug 14 13:24:05 2014] this is getting annoying [Thu Aug 14 13:24:19 2014] am I the only one seeing this a lot in HEAD? [Thu Aug 14 13:24:34 2014] one sec. let me update the file [Thu Aug 14 13:25:02 2014] edwardk: Unrelated question: why do you make it a class? I can't imagine that typeclass inference is actually helping you in most cases. [Thu Aug 14 13:25:02 2014] Acutal question: which fields can you remove without making the error go away? [Thu Aug 14 13:25:55 2014] the class is cargo cult, the reason is i don't know how to get my definitions later to just set up missing fields automatically as obligations when i don't use it because i suck at coq [Thu Aug 14 13:26:11 2014] good question. one sec. pushing now so you can see the thing that breaks [Thu Aug 14 13:26:51 2014] https://github.com/jwiegley/category-theory/blob/master/Toy.v#L51 is the definition that doesn't like the Set Primitive Projections [Thu Aug 14 13:26:54 2014] vanila: Is this HEAD as of today/yesterday, or HEAD as of a few weeks ago? Enrico (or maybe Pierre or Arnaud) fixed most of those; the only one I know about is when you have a [Definition] or [Goal] in the middle of another proof and your statement doesn't parse or type-check. Are you seeing this one, or another one? [Thu Aug 14 13:27:11 2014] ah i better update and then see if its still happening [Thu Aug 14 13:27:38 2014] (* ; uhom := Type : Type *) is the culprit [Thu Aug 14 13:29:03 2014] Really? Set Primitive Projections. Class foo := { bar := Type }. works for me. It must be that together with other ones? [Thu Aug 14 13:29:35 2014] Class Precategory := { ob :> Type; uhom := Type : Type}. [Thu Aug 14 13:29:37 2014] that fails for me [Thu Aug 14 13:29:52 2014] Also, why do you have uhom in there at all? (Where do you need it?) [Thu Aug 14 13:30:21 2014] Possible way to make it not a class: use an underscore wherever you want [Program] to give it to you as an obligation. [Thu Aug 14 13:30:42 2014] we may well not need it to be in there at all [Thu Aug 14 13:30:46 2014] edwardk: You want to report this bug, or shall I? [Thu Aug 14 13:30:50 2014] it was something johnw threw in i kept [Thu Aug 14 13:30:53 2014] go for it [Thu Aug 14 13:31:04 2014] Ainieco, any luck? I had a look at it and I think this way works also [Thu Aug 14 13:31:06 2014] i suck at bug reporting [Thu Aug 14 13:31:19 2014] i tend to find them, find workarounds and keep my head down while working on the problem i have at the moment ;) [Thu Aug 14 13:31:26 2014] vanila: http://lpaste.net/1719548139012096000 stuck here currently [Thu Aug 14 13:32:15 2014] That's what practice is for? You already have a minimal example (Set Primitive Projections. Record foo := { bar : Type ; baz := Set }.), all you need to do is say that that gives you the error message you get. [Thu Aug 14 13:32:25 2014] heh [Thu Aug 14 13:32:47 2014] http://bpaste.net/show/H37nUljUPW4PhoBFsjMq/ [Thu Aug 14 13:32:52 2014] with your original defs this works ok [Thu Aug 14 13:33:03 2014] like, I assume it would be routine to complete this [Thu Aug 14 13:33:06 2014] ok, with uhom gone now I can use Set Primitive Projections [Thu Aug 14 13:33:47 2014] since I instlaled HEAD I have to do so much messing about to get other peoples code to load, its really frustrating [Thu Aug 14 13:33:52 2014] implicit args all changed [Thu Aug 14 13:34:04 2014] Also, that's part of what I made my bug-minimizer for; I set that on my error-generating code, and let it run while I keep working, and come back to it a few hours later. (That's why I have it inline all the dependencies first, so I don't have to worry about messing up the error when working on code.) [Thu Aug 14 13:34:22 2014] vanila: Are you looking for [Set Asymmetric Patterns]? [Thu Aug 14 13:34:34 2014] So, edwardk, are you going to go report the bug? [Thu Aug 14 13:34:36 2014] so basically 'quickcheck shrink' for coq [Thu Aug 14 13:34:39 2014] I don't know, I just want other peoples code to work when I open it up [Thu Aug 14 13:34:41 2014] ok ok i'll do it [Thu Aug 14 13:34:45 2014] let me go find the bugtracker [Thu Aug 14 13:34:47 2014] I guess it'll sort itself when everyones at the same version [Thu Aug 14 13:35:35 2014] Ainieco, define split as Definition not Fixpoint [Thu Aug 14 13:35:56 2014] vanila: there are a bunch of compatibility flags. Set Asymmetric Patterns is the big one, because they changed implicits in pattern matching, and this changes them back. Alternatively, you could keep 2 versions of Coq installed (or thirteen, which is how many I have). [Thu Aug 14 13:35:59 2014] now you can complete the proof using inversion H; subst; rewrite IHxs; reflexivity [Thu Aug 14 13:36:15 2014] oh, destruct x in there [Thu Aug 14 13:36:48 2014] jgross, oh I see! [Thu Aug 14 13:38:19 2014] done =P [Thu Aug 14 13:38:39 2014] where is Asymmetric Patterns defined i can't find what it means in the docs [Thu Aug 14 13:39:33 2014] and not being part of the culture i can't tell if its good bad or indifferent ;) [Thu Aug 14 13:39:41 2014] vanila: already at destruct x part :) [Thu Aug 14 13:41:00 2014] edwardk: https://github.com/coq/coq/blob/trunk/CHANGES#L66 Don't set it, unless you're porting a large body of code from 8.4. It's a compatibility flag, and may go away some day. [Thu Aug 14 13:41:08 2014] k [Thu Aug 14 13:41:13 2014] thats what i wanted to know =) [Thu Aug 14 13:43:59 2014] Ainieco, but just comparing the size of your proof with mine, the map definition you came up with is way way easier to work with - a lot of time coming up with nice definitions makes the proofs much easier/possible [Thu Aug 14 13:44:17 2014] vanila: i have troubles understanding how does "rewrite IHxs" transfroms "(x, y) :: combine (split' xs) (split'' xs) = (x, y) :: xs" into "(x, y) :: xs = (x, y) :: xs"? [Thu Aug 14 13:44:27 2014] vanila: agreed [Thu Aug 14 13:44:34 2014] well that's just a hypothesis that needs to discharged, for the rewrite to work [Thu Aug 14 13:44:43 2014] the actual rewrite is the other goal [Thu Aug 14 13:45:06 2014] whats happening here is that Coq is using unification to guess the variables needed to do the rewrite [Thu Aug 14 13:48:31 2014] ah, okay, it unifies "combine (split' xs) (split'' xs)" with "combine l1 l2" and rewrites it with xs, and then leaves us next goal of proving assumption of split xs = (l1, l2), correct? [Thu Aug 14 13:48:54 2014] yeah exactly [Thu Aug 14 13:50:02 2014] edwardk: are you Edward Kmett? [Thu Aug 14 13:50:07 2014] yep [Thu Aug 14 13:51:13 2014] sorry, i was just curious, never mind me [Thu Aug 14 13:52:43 2014] heh, no worries [Thu Aug 14 13:54:50 2014] weird [Thu Aug 14 13:55:19 2014] i have a situation where if i use Solve All Obligations with path_induction. -- i still wind up with obligations that need Next Obligation. path_induction. Defined. [Thu Aug 14 13:55:24 2014] even with upgraded trunk [Thu Aug 14 13:56:21 2014] and worse, if i use Local Obligation Tactic := path_induction -- instead of Solve All Obligations with path_induction then i get a different result [Thu Aug 14 13:56:42 2014] where instead it puts me in a different state where i can't finish with path_induction on one of the sub-problems. [Thu Aug 14 13:57:03 2014] i can't tell if this is a coq problem or a problem with my thought process of how this works [Thu Aug 14 13:57:09 2014] since i'm new here i assume the latter [Thu Aug 14 13:58:27 2014] maybe its my path_induction tactic [Thu Aug 14 13:59:41 2014] interesting how two well known haskellers(edwardk and johnw) popping up on #coq around the same time, are you guys doing something interesting haskell related together in coq? [Thu Aug 14 14:00:10 2014] but its strange to me that Local Obligation Tactic := path_induction and the Obligation n. path_induction. Defined. don't yield the same answers. [Thu Aug 14 14:00:15 2014] more or less [Thu Aug 14 14:00:37 2014] he started work at BAE recently and they are now paying him to do more formal methods stuff. [Thu Aug 14 14:00:49 2014] and i wrote a library for doing some crazier category theory in haskell [Thu Aug 14 14:00:59 2014] and he decided he was going to formalize it in coq to understand it [Thu Aug 14 14:01:03 2014] so i've been helping him out [Thu Aug 14 14:01:13 2014] but we got to the point where setoids sucked the life out of the project [Thu Aug 14 14:01:30 2014] and he adopted a few of jgross et al's tricks to fix it up [Thu Aug 14 14:01:51 2014] but now i'm sitting here playing with switching over to a more HoTT like model to get cleaner, faster proofs [Thu Aug 14 14:02:16 2014] and just decided to take a bit of time and use it to firm up my understanding of (infinity,1)-categories, etc. [Thu Aug 14 14:02:49 2014] so for the moment i'm just scribbling pseudo-hott code all over jwiegley's nice repo that is a copy of my haskell category theory machinery in coq ;) [Thu Aug 14 14:02:57 2014] or something like that [Thu Aug 14 14:03:42 2014] wow, that's really great, thanks for sharing! [Thu Aug 14 14:09:24 2014] jgross: anyways the one thing i seem to get out of Class is that if i make it not a class, then my sugar for (~>) breaks inside Pregroupoid [Thu Aug 14 14:09:35 2014] which makes me sad [Thu Aug 14 14:09:40 2014] could be a clean way to recover it [Thu Aug 14 14:09:46 2014] but i'm not that well versed in the tools [Thu Aug 14 14:41:22 2014] roosbeef: https://gist.github.com/3fc6d545a7907bff8610 [Thu Aug 14 14:41:38 2014] roosbeef: for a simple example of using well-founded recursion [Thu Aug 14 14:47:25 2014] Given A : Set, is it possible to switch back and forth between maps p: B -> A with B : Set and A-dependent sets, i.e. fib: A -> Set? [Thu Aug 14 14:51:10 2014] intuitively, fib should be sent to the disjoint union of its values, while p should be sent to a |-> p^(-1)(a), but I can't realize either of these ideas in coq. can someone help? [Thu Aug 14 14:55:04 2014] Hello, did something called le_ind use to be defined in zarith? I'm having trouble proof checking a script that Frama-C came with? [Thu Aug 14 14:55:28 2014] The part that is failing >> apply Z.le_ind with (n := m) ; auto with zarith. [Thu Aug 14 15:04:05 2014] Hmmm. Would it be crazy to write my math course notes with coq-doc? [Thu Aug 14 15:04:42 2014] Probably in a group theory / number theory course. I think it would be interesting to try, but it might become unwieldy very fast? [Thu Aug 14 15:05:47 2014] that would e a really bad idea [Thu Aug 14 15:07:05 2014] for example a normal math course will introduce associativity then freely write a * b * c without brackets, in your entire development in Coq you'll have to manually re-arrange brackets [Thu Aug 14 15:07:18 2014] but you can achieve that with notations [Thu Aug 14 15:07:23 2014] chirpsalot: I don't see what would be wrong with that, you have the side benefit of knowing that the examples in your notes are correct [Thu Aug 14 15:07:37 2014] i'm not talking about the notation [Thu Aug 14 15:08:05 2014] he can also hide the manual rearrangement, if necessary [Thu Aug 14 15:08:24 2014] johnw: yeah, I am just wondering if I will ever come to the point where I get something that I can't prove in Coq. I think it would be great for working through assignments. [Thu Aug 14 15:08:29 2014] I use literate Haskell to write blog articles for just that reason: to know that what I'm posting works exactly in the form that I'm posting [Thu Aug 14 15:08:42 2014] chirpsalot: you could always mark it Admitted and then hide that statement [Thu Aug 14 15:08:54 2014] johnw: yeah, I was thinking that. And then work it out on paper :). [Thu Aug 14 15:10:22 2014] vanila: I mostly mean writing up the theorems. I used to write up my notes live with LaTeX, but I am thinking of just jotting down the theorems on paper and stuffing them in coq later. It would be cool to write the coq notes live, but I suspect that will be more troublesome :). [Thu Aug 14 15:13:00 2014] Thanks for the tips, though. I think I am going to try it. The most effort would probably be going from Coq proofs -> written proofs to hand in, but that's not too bad. Haven't used Coq for any real number stuff yet... [Thu Aug 14 15:18:05 2014] just worried that you will get bogged down with syntax rubbish pulling your attention away from the number theory concepts [Thu Aug 14 15:18:49 2014] just pretend the syntax rubbish is like a sacrifice you must make to the gods of computing [Thu Aug 14 15:37:49 2014] Does anyone know if, given A : Set, the correpondence between maps A -> Set and pairs (B : Set, f: B -> A) has been formalized in Coq? [Thu Aug 14 15:46:31 2014] i wonder why Pierce starts using Prop in the middle of chapter without even explainging what is it [Thu Aug 14 15:48:31 2014] http://www.cis.upenn.edu/~bcpierce/sf/current/MoreCoq.html#lab176 here, there are no mentions of Prop before that place whatsoever [Thu Aug 14 15:51:26 2014] vanila: this was one of my concerns -- large part of why I asked. I guess it's worth trying to formalize the course in Coq, though? [Thu Aug 14 15:53:27 2014] chirpsalot, well i dont mean to discourage you it will be fun if you try [Thu Aug 14 15:53:46 2014] torfscholle, I don't exactly understand what you mean [Thu Aug 14 15:54:03 2014] for the second type [Thu Aug 14 15:55:50 2014] vanila: does it statest that split is inverse of combine? "forall X Y (l : list (X * Y)) l1 l2, combine l1 l2 = l -> split l = (l1, l2)." just a little confused how simple it is because in SF Pierce even gave some hints which suggests that define such property should be hard... [Thu Aug 14 15:56:39 2014] vanila: oh no worries :). I'm just a bit new to Coq (month or so of use), and wanted opinions from those more familiar. I don't know what hidden madness awaits me ;). [Thu Aug 14 15:57:10 2014] Ainieco, That isn't true but you should be able to prove it assuming length l2 = length l2 [Thu Aug 14 15:57:13 2014] length l1 = length l2 [Thu Aug 14 15:57:28 2014] Ainieco: you may want to mention that on coq-club, and you're right it isn't [Thu Aug 14 15:58:10 2014] chirpsalot: lots and lots of hidden madness :) [Thu Aug 14 15:58:24 2014] only, it doesn't look like madness to you from the other side... [Thu Aug 14 15:59:46 2014] johnw: are you talking about fact that Prop wasn't mentioned previously in the book or the fact that it "split_combine" is not hard? [Thu Aug 14 15:59:54 2014] former [Thu Aug 14 16:00:21 2014] it's hard to say what's really hard and what's not [Thu Aug 14 16:00:36 2014] i've had 2 star exercises take me a whole evening, and 4-star ones take no time at all [Thu Aug 14 16:00:44 2014] so partly it depends on the person and how you see things [Thu Aug 14 16:01:33 2014] vanila: hm, sorry but what do you mean by "That isn't true but you should be able to prove it"? sounds like false = true to me :) [Thu Aug 14 16:03:03 2014] probably i'm missing what "that" is [Thu Aug 14 16:03:05 2014] Ainieco : is http://lpaste.net/raw/1719548139012096000 where you're at? [Thu Aug 14 16:03:15 2014] Ainieco, assuming length l2 = length l2 [Thu Aug 14 16:03:18 2014] Ainieco, assuming length l1 = length l2 [Thu Aug 14 16:03:21 2014] i.e. [Thu Aug 14 16:03:28 2014] forall X Y (l : list (X * Y)) l1 l2, length l1 = length l2 -> combine l1 l2 = l -> split l = (l1, l2) [Thu Aug 14 16:03:44 2014] this is the issue (2) that I mentioned before [Thu Aug 14 16:04:34 2014] vanila: ah, i see now, and Pierce's hint now totally makes sense, thank you once again! [Thu Aug 14 16:04:44 2014] no prob :) [Thu Aug 14 16:05:51 2014] Cypi: http://www.cis.upenn.edu/~bcpierce/sf/current/MoreCoq.html#lab187 I'm here now [Thu Aug 14 16:06:31 2014] Ok :) [Thu Aug 14 16:07:03 2014] the other day I proved false = true. Then i woke up. [Thu Aug 14 16:07:39 2014] Cypi: why do you asking? [Thu Aug 14 16:47:37 2014] vanila: if A : Set, intuitively a dependent type f: A -> Set over A can be thought of as a set B equipped with a map p: B -> A, with f a being the "fiber" of p over a. do you agree? I'm wondering how to formalize this correspondence in coq [Thu Aug 14 16:48:18 2014] I have never really understood notions like fiber [Thu Aug 14 16:49:51 2014] I don't understand how this pair exists B : Set, B -> A is related to f but i think that's just because I don't know about this stuff - does anyone else know? [Thu Aug 14 16:50:43 2014] how do I use an assertion in an Ltac script? [Thu Aug 14 16:50:48 2014] assert (X = false) as Hfalse; [ assumption; rewrite Hfalse; clear Hfalse ] is not working [Thu Aug 14 16:51:02 2014] it's not "entering the goal" for the assertion to perform the subtactics [Thu Aug 14 16:51:27 2014] oh, "by solve" [Thu Aug 14 16:51:39 2014] that did it, thanks [Thu Aug 14 16:59:19 2014] vanila: to me, 'fiber' is the categorical name for 'preimage'. here we're talking about sets, so "fiber of f:B->A over a:A" literally means "those b : B where f b = a". however, I already don't know how to formalize this in coq, since 'exists b : B, eq (f b) a' is a proposition rather than a set. [Thu Aug 14 16:59:42 2014] you could use { b : B | a = f b } [Thu Aug 14 16:59:47 2014] this is just exists in Set rather than Prop [Thu Aug 14 16:59:58 2014] an "Adam-style" solution to filter_challenge: https://gist.github.com/063935676a06e1dcddc4 [Thu Aug 14 17:00:59 2014] vanila: ah, great! didn't know about exists for Sets.. what is it an abbreviation for? 'Check ex' only gives existence quantification for propositions [Thu Aug 14 17:01:18 2014] It's in the Specif part of the stb lib [Thu Aug 14 17:01:25 2014] edwardk (catching up on IRC): [Infix "~>" := (@hom _) : category_scope.] will fix your notation problem. Alternatively, [Arguments hom {_} _ _.]. The issue is that typeclasses are automatically declared as implicit and maximally inserted (what you get with curlies), while records are not. Note that using records rather than classes means that you can remove the [@]s from most of your subsequent notations. [Thu Aug 14 17:02:32 2014] jgross: nice [Thu Aug 14 17:02:39 2014] How do you construct a function B -> A given A -> Set though? [Thu Aug 14 17:02:41 2014] jgross: thank you for all of your help with this! [Thu Aug 14 17:03:09 2014] johnw, thanks!! [Thu Aug 14 17:03:10 2014] or do you choose B:=A in this case? [Thu Aug 14 17:03:27 2014] roosbeef: oh hey, I wondered if you'd see that :) [Thu Aug 14 17:03:31 2014] haha i did [Thu Aug 14 17:03:36 2014] but only right before bedtime :p [Thu Aug 14 17:03:42 2014] going to have a closer look tomorrow :) [Thu Aug 14 17:03:56 2014] do ask more questions here if you're still stuck [Thu Aug 14 17:03:58 2014] sleep wlel [Thu Aug 14 17:04:01 2014] this looks a LOT simpler than the example Adam Chlipala gave :p [Thu Aug 14 17:04:11 2014] ok ill keep that in mind, thank you :) [Thu Aug 14 17:04:18 2014] edwardk: Local Obligation Tactic := path_induction should not leave you any cases where [Obligation n. path_induction. Defined.] is what you need to solve something. Uh, unless [Local Obligation Tactic := repeat path_induction.] is what you need to solve things. Anyway, if changing [induction] to [destruct] in [path_induction] fixes it, it's probably another universe issue that you should report on the bug tracker. I've never used [Solve All [Thu Aug 14 17:04:18 2014] Obligations with], but do you have a concrete (preferably smallish, preferably stand-alone) example? [Thu Aug 14 17:04:51 2014] vanila: fun a : A => {b : B | p b = a} is of type A -> Set [Thu Aug 14 17:05:00 2014] i don't have anything small [Thu Aug 14 17:05:08 2014] i'll try destruct there [Thu Aug 14 17:05:57 2014] vanila: ah sorry, that's the other direction [Thu Aug 14 17:06:35 2014] i wind up with Paths_Pregroupoid still getting stuck even after going to destruct [Thu Aug 14 17:07:04 2014] same issue as before [Thu Aug 14 17:07:13 2014] edwardk: If you can get a variant that gives you an error message (that is different from the one you'd get if you removed the [Local Obligation Tactic] line entirely), then you can use find-bug.py in https://github.com/JasonGross/coq-bug-finder to auto-minimize the file. [Thu Aug 14 17:07:24 2014] torfscholle, I wish I couldfollow sorry :( [Thu Aug 14 17:07:35 2014] I don't understand what the isomorphism is supposed to be between [Thu Aug 14 17:08:19 2014] vanila: no it's fine, I'm just thinking about your question on how to get a map B -> A from a map A -> Set [Thu Aug 14 17:09:05 2014] torfscholle: Are you looking for https://github.com/HoTT/HoTT/issues/323 ? (The names for exists for sets are sigT and sig (the latter has the second component being a Prop, while the former are both types) [Thu Aug 14 17:09:35 2014] vanila: if f : A -> Set, then the corresponding B should be the union of all the sets f a for a : A. so we can define it as an inductive type "unionOfImages" with constructor 'forall a : A, f a -> unionOfImages' [Thu Aug 14 17:09:52 2014] alright let me try that [Thu Aug 14 17:11:28 2014] jgross: https://github.com/ekmett/homotopy/blob/master/Core.v#L159 is where it dies if i turn on Local Obligation Tactic [Thu Aug 14 17:11:31 2014] jgross: thanks, I'll look at it! [Thu Aug 14 17:11:47 2014] vanila, torfscholle: I think the equivalence you want is (forall x, Q x) <~> { f : A -> { x : _ & Q x } & Sect f pr1 } where [Sect fs r := forall x : A, r (s x) = x] (which is what's proven in that issue) [Thu Aug 14 17:12:00 2014] it can't figure out how to reverse the arrow there if its on, but it'll run just fine by hand [Thu Aug 14 17:12:27 2014] could it be something like auto using different hints or something? [Thu Aug 14 17:12:41 2014] jgross, vanila: unfortunately, I have to go now - see you later or tomorrow! [Thu Aug 14 17:13:09 2014] bye [Thu Aug 14 17:14:00 2014] https://github.com/vladimirias/UniMath/blob/master/UniMath/PAdics/padics.v lol [Thu Aug 14 17:18:30 2014] edwardk: I think that's because the default obligation tactic (which is [program_simpl], according to [Show Obligation Tactic], which I found at http://coq.inria.fr/refman/Reference-Manual026.html) does some unfolding that makes path_induction succeed. When you give it a different obligation tactic, it obliterates the default tactic, and so path_induction will no longer succeed. The way to make it so that path induction can solve your [Thu Aug 14 17:18:30 2014] obligation again is to run [hnf in *]. (The reason that morphisms in a pregroupoid are invertible is that they're actually paths.) [Thu Aug 14 17:19:03 2014] ah [Thu Aug 14 17:19:38 2014] so i should bolt that on the front of path_induction if i want to do this this way [Thu Aug 14 17:19:52 2014] path_destruction? =) [Thu Aug 14 17:20:31 2014] johnw, edwardk: You're doing interesting stuff. I'm interested in seeing where it goes, so I'm interested in helping out a bit. [Thu Aug 14 17:20:34 2014] path_elimination? [Thu Aug 14 17:20:48 2014] jgross: i appreciate it [Thu Aug 14 17:21:04 2014] i figured what i'd do is go through and throw the other approaches in a blender, try to put my spin on it and see what comes out [Thu Aug 14 17:21:10 2014] =) [Thu Aug 14 17:23:52 2014] right now i'm exploring weakening your definition of Precategory a bit, and seeing if its more natural to define everything 'up to coherent homotopy', and if bringing in the category theory vocabulary earlier makes some of the homotopy vocabulary redundant [Thu Aug 14 17:24:56 2014] No, don't bolt [hnf in *] to the head of [path_induction]; it'll cause you pain later, when it decides that your application of composed functors can be unfolded to some ugly mess. Look at destruct_head_hnf (https://github.com/JasonGross/coq-tactics/blob/master/Common.v#L203); [destruct_head_hnf T] is like [decompose [T] H] for every hypothesis [H], except that it runs [hnf] on the hypotheses it can eventually decompose [Thu Aug 14 17:24:56 2014] (http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic46 is about decompose). Basically, you want to run [hnf in H; ; destruct H] for each hypothesis. [Thu Aug 14 17:25:02 2014] then i want to see if i can instead do monoidal categories instead as bicategories over one object, and model a bunch of other stuff through enriched and internal categories [Thu Aug 14 17:25:54 2014] ugh. you're going to force me to learn tactics =) [Thu Aug 14 17:26:52 2014] What do you mean by "up to coherent homotopy"? Like, rather than assume the morphisms are an hset, make them cohere with the groupoid structure on objects? (If you manage that, I think you get to write a paper on how you defined semisimplicial types?) [Thu Aug 14 17:27:17 2014] Yes! Tactics are really useful! [Thu Aug 14 17:27:31 2014] jgross: my usual way to learn something is to remove something and run with it until i smack face first into the wall that everyone else tells me is there. [Thu Aug 14 17:27:33 2014] edwardk: tactics are fun :) [Thu Aug 14 17:27:50 2014] either i get through to the other side by dint of a hard head or i learn something about how hard the wall is and exactly where it is placed. [Thu Aug 14 17:29:34 2014] i'm okay with this failing process taking a long time, because i have a lot of ground to cover ;) [Thu Aug 14 17:29:58 2014] basically being on coq day 2. having forgotten everything i knew when i tried it 6 years ago or so [Thu Aug 14 17:32:06 2014] I'm having some trouble passing tactic arguments to tactics [Thu Aug 14 17:32:28 2014] they often try to run at the call site [Thu Aug 14 17:32:34 2014] so right now i have two such weakenings in play. the first is relaxing = in the precategory definition to ~, and the second is moving the hSet constraint down to later [Thu Aug 14 17:33:03 2014] but i haven't gotten to where those will bite me yet. still laying out machinery to get funext from univalence, etc. [Thu Aug 14 17:34:57 2014] the next major step is to go define bicategories up to coherent homotopy ( (infinity, 2)-bicategories ? ), use bicategories of one object to define monoidal categories and ideally then use that to talk about enriched categories and internal categories [Thu Aug 14 17:35:05 2014] but i reserve the right to switch goals =) [Thu Aug 14 17:35:11 2014] :) [Thu Aug 14 17:35:20 2014] creativity in action [Thu Aug 14 17:36:30 2014] do you know of any attempts to do n-categories in coq that worked out at all, etc? i'm curious to scan prior art in this space [Thu Aug 14 17:36:51 2014] i don't particularly care about that problem, but i do care about the space of solutions around it if that makes sense [Thu Aug 14 17:37:49 2014] edwardk: this thread may be of no interest whatsoever, but: https://groups.google.com/forum/#!topic/sci.physics.research/HM623jsEvrQ [Thu Aug 14 17:38:13 2014] napping: Stare carefully at the manual and the difference between tactics and tactic expressions. Prefix you're tactics with [idtac; ]. Bury your desire to stab the coq devs. [Thu Aug 14 17:38:17 2014] also possibly of interest: http://arxiv.org/pdf/1010.1810.pdf [Thu Aug 14 17:39:10 2014] thanks [Thu Aug 14 17:39:45 2014] johnw: I've got some idtac; already, it's especially not nice when I want to pass things through a few layers [Thu Aug 14 17:40:27 2014] CPDT covers a lot of stuff too [Thu Aug 14 17:40:38 2014] good refreshser [Thu Aug 14 17:40:49 2014] yes, I really liked CPDT this time aruond [Thu Aug 14 17:40:53 2014] edwardk: http://mathoverflow.net/questions/152497/formalizations-of-category-theory-in-proof-assistants, http://www.megacz.com/berkeley/coq-categories/, https://bitbucket.org/JasonGross/catdb/src/4eb6407c6ca3200bebefaa3a1834d05c49b01846/EnrichedCategory.v?at=default [Thu Aug 14 17:41:03 2014] I don't remember it answering this problem [Thu Aug 14 17:41:08 2014] i skipped through some of the sections on different embeddings of non-terminating programs [Thu Aug 14 17:41:11 2014] but the rest was pretty valuable [Thu Aug 14 17:41:18 2014] ooh, I could use some of that [Thu Aug 14 17:41:45 2014] megacz's coq-categories is a repo that I based a lot of my stuff on, after starting with Mathieu's development [Thu Aug 14 17:41:47 2014] ideally embeddings which can be upgraded to executable by proving a termination lemma [Thu Aug 14 17:42:42 2014] jgross: hg, really? [Thu Aug 14 17:42:55 2014] i read megacz's code when he threw some arrow stuff at ghc as a plugin based on it way back when, i'll go see if it has changed [Thu Aug 14 17:44:14 2014] how do I tell mercurial to just ignore ca-certificates? [Thu Aug 14 17:44:14 2014] napping: CPDT does not talk about this, because it never came up for Adam (I asked him about it recently after it tripped me up in https://coq.inria.fr/bugs/show_bug.cgi?id=3498). Whenever you start a tactic with [let ... := ... in ...] or [match ... with ... end] or [lazymatch ... with ... end], prefix the [match], [lazymatch], or [let] with [idtac; ]. You only have to do this at top level when you define something with [Ltac foo := ... ], or [Thu Aug 14 17:44:14 2014] when you explicitly pass a [let], [match], or [lazymatch] to a tactic with [ltac:(...)]. [Thu Aug 14 17:44:22 2014] it can't clone because it's trying to read a file that doesn't exist [Thu Aug 14 17:44:37 2014] johnw: I was just copying my predecesors: https://bitbucket.org/JasonGross/catdb/commits/branch/default?page=19 [Thu Aug 14 17:44:47 2014] jgross: I think I'm already doing that everywhere [Thu Aug 14 17:45:04 2014] but if you have something like Ltac foo arg := ... ; bar arg ; ... [Thu Aug 14 17:45:17 2014] ah, --insecure [Thu Aug 14 17:46:38 2014] napping: that's fine, and doesn't need an [idtac; ], unless it's secretly [Ltac foo arg := let baz := qux in ... ; bar arg ; ...] (in which case it's actually [Ltac foo arg := let baz := qux in (... ; bar arg ; ...)], in which case you need an [idtac; ] to prevent [qux] from being run immediately and assigned to [baz]. [Thu Aug 14 17:47:08 2014] huh, I thought I already had idtac in all the right places and another indirection was messing it up [Thu Aug 14 17:47:26 2014] what about a tactic defined like solve[ .... ] or first[ ... ]? [Thu Aug 14 17:47:40 2014] btw, johnw, edwardk: feel free to improve http://mathoverflow.net/a/176817 [Thu Aug 14 17:48:11 2014] we should really reference github.com/ekmett/homotopy there now too [Thu Aug 14 17:48:27 2014] hmm, inlining some definitions into the tactic I was calling, seemd to cure the problem, without any changes to the final call site or the stuff I was passing in [Thu Aug 14 17:48:32 2014] though my repo is likely to stay a bit more "traditional" until I integrate these fancy new homotopy concepts [Thu Aug 14 17:49:03 2014] solve, first, repeat, do, abstact, and some others are fine as top-level things. What's the tactic you're passing as an argument? [Thu Aug 14 17:49:45 2014] i'd rather wait until i had more than 1 file full of thoughts before announcing it to stack overflow, but hey =) [Thu Aug 14 17:49:54 2014] several, first is solve[simpl;reflexivity | equate_maps]. [Thu Aug 14 17:50:29 2014] and not just stackoverflow, but *math*overflow [Thu Aug 14 17:50:40 2014] johnw: Please do, whenever you're ready. Either add it to that answer or make a new answer, if it deserves a separate entry. All the answers to that question so far are mine, and I want other people to add stuff. I don't want to maintain any answers other than http://mathoverflow.net/a/155038. [Thu Aug 14 17:51:03 2014] napping: What's the entire tactic invocation? (Do you have it on pastebin or gist or something, or is it short enough to paste here?) [Thu Aug 14 17:51:08 2014] there's also a econstructor(match goal with ...) and solve[ let [Thu Aug 14 17:51:20 2014] ... ] that I inlined [Thu Aug 14 17:51:31 2014] everything else seems to have a ";" at the top level [Thu Aug 14 17:52:09 2014] econstructor takes a tactic argument? [Thu Aug 14 17:52:24 2014] Or, oh, your match goal with returns a constr? [Thu Aug 14 17:52:41 2014] no, they can't do that [Thu Aug 14 17:52:52 2014] I've cps-transformed stuff in other places to work around that [Thu Aug 14 17:52:54 2014] So what does "econstructor(match goal with ...)" mean? [Thu Aug 14 17:53:11 2014] econstructor() is like econstructor, but applies the tactic to all subgoals [Thu Aug 14 17:53:24 2014] and only sticks with a constructor that both unifies and has no tactic failures [Thu Aug 14 17:53:34 2014] really handy for automatically applying inductively defined relations and such [Thu Aug 14 17:53:57 2014] [let x := (match goal with |- ?G => constr:(G) end) in pose G] works fine. [Thu Aug 14 17:54:10 2014] oh, huh [Thu Aug 14 17:54:16 2014] I'll have to try that in places [Thu Aug 14 17:54:35 2014] Is econstructor() new to trunk, or just undocumented? Anyway, you should see if replacing it with [econstructor(idtac; match goal with ...)] fixes things. [Thu Aug 14 17:54:38 2014] pose x, right? [Thu Aug 14 17:54:43 2014] Yeah, just undocumented [Thu Aug 14 17:54:46 2014] Yes, pose x. [Thu Aug 14 17:55:02 2014] well, inlining that into the tactic that I was calling, but not otherwise changing the call seemed to help [Thu Aug 14 17:56:09 2014] that's also not the thing running too early, according the Ltac Debug [Thu Aug 14 17:56:34 2014] What's the thing running too early? [Thu Aug 14 17:57:08 2014] Is [econstructor(tac)] different from [econstructor; tac]? [Thu Aug 14 17:57:15 2014] jgross: adding program_simpl to the front of the Local Obligation Tactic (not to path_induction) let me clear out the remaining manual cases there. [Thu Aug 14 17:57:27 2014] now i just have some stubborn stuff that doesn't want to figure out how to auto apply [Thu Aug 14 17:57:28 2014] yes, econstructor;tac commits to the first thing that unifies, whether or not tac can deal with the arguments [Thu Aug 14 17:57:32 2014] it's very useful [Thu Aug 14 17:57:37 2014] jgross++ [Thu Aug 14 17:58:13 2014] edwardk: Which thing did I say that you're ++ing? [Thu Aug 14 17:58:28 2014] ++'ing for the help with the obligation tactic stuff [Thu Aug 14 17:58:32 2014] was going nuts on that [Thu Aug 14 17:59:12 2014] :-) Glad I was able to help. [Thu Aug 14 17:59:31 2014] napping: I've made https://coq.inria.fr/bugs/show_bug.cgi?id=3521, asking them to document econstructor(tactic) [Thu Aug 14 17:59:53 2014] I heard of it in an email thread where Voevodsky was digging around in the Coq source [Thu Aug 14 18:00:00 2014] Anyway, if you show me the entire tactic invocation, I can probably point out which bits you might need to change to get it to not run too early. [Thu Aug 14 18:13:08 2014] I got it working by inlining stuff inside the definition, without changing how I called it [Thu Aug 14 18:13:16 2014] I'll see about pasting that [Thu Aug 14 18:13:42 2014] see you guys later [Thu Aug 14 18:14:34 2014] http://lpaste.net/109391 [Thu Aug 14 18:14:44 2014] the commented out "domain_run" wasn't working, the inlined one does [Thu Aug 14 18:15:32 2014] huh, and now it all works the other way too [Thu Aug 14 18:23:03 2014] How'd you call it such that it was failing? [Thu Aug 14 18:23:31 2014] (I'm pretty sure it's how you call it that matters, and not so much what the definition is. But not entirely sure.) [Thu Aug 14 18:23:34 2014] domain_run k trans_domain_solver trans_use_result step_domain_solver ltac:split_stuck done_solver for various definitions [Thu Aug 14 18:24:31 2014] It was trying to run Ltac done_solver := subst;simpl;repeat eexists;... too early, I think [Thu Aug 14 18:33:29 2014] napping: That doesn't seem right. Let me know if you have code I can play with that does this. [Thu Aug 14 19:06:04 2014] edwardk: Without the truncation axiom for precategories (semi-precategories, then?), you will run into issues when you try to prove the laws about composition of natural transformations, necessary to building functor precategories. See https://groups.google.com/d/msg/homotopytypetheory/cYPhbT4HGcs/27-OWTEEavwJ and [Thu Aug 14 19:06:04 2014] https://github.com/JasonGross/HoTT/blob/yoneda-without-truncatedness-trunk/theories/categories/NaturalTransformation/Composition/Laws.v#L39 [Thu Aug 14 20:59:01 2014] jgross: i expect as much [Thu Aug 14 21:03:19 2014] jgross: im willing to keep playing with the foundations in a few different ways. but if i don't smack into where things go wrong i never learn why [Thu Aug 14 21:10:20 2014] edwardk: *nods* That's approximately how I do things, too. [Thu Aug 14 21:10:59 2014] and i figure if i'm going to do any real theorem proving i can't think of a better set of foundational issues to attack [Thu Aug 14 21:15:35 2014] taking the stashef polyhedra point seriously is there a nice coinductive definition of the associahedra that make up the stashef polytopes? [Thu Aug 14 21:15:42 2014] er stasheff [Thu Aug 14 21:17:45 2014] e.g. is there an angle of attack where you take your category, look at its nerve to break it down into sequences of length n, then do what? play with the corresponding stashef polytype for that length and prove the associativity directly or via coinduction / some bisimulation step? [Thu Aug 14 21:18:36 2014] or am i using the associahedron "side-ways" from how it applies here. [Thu Aug 14 22:56:37 2014] hrmm, is there a story for induction-recursion in coq? [Thu Aug 14 22:57:21 2014] I think that you just can't do it [Thu Aug 14 22:57:22 2014] or am i dead in the water if i need it? [Thu Aug 14 22:57:27 2014] blah [Thu Aug 14 22:57:35 2014] sorry :( [Thu Aug 14 22:57:42 2014] * doesn't want to give up tactics and go wander the wilds of agda. [Thu Aug 14 22:59:03 2014] what did you want them for? [Thu Aug 14 22:59:08 2014] just curious [Thu Aug 14 22:59:42 2014] was hoping to play with something like the shulman HIR universe trick and see if i could fix a 'potential' problem that i know will bite me later with my category-theory by building a universe i can exhaustively solve [Thu Aug 14 22:59:57 2014] but i can't build the universe without induction-recursion [Thu Aug 14 23:00:01 2014] and so i get stopped before i start [Thu Aug 14 23:03:47 2014] hrmm, mcbride has a trick for doing induction-recursion for a sufficiently small target type using just induction right? [Thu Aug 14 23:04:00 2014] * tries to page in what he can remember and dig up by google. [Thu Aug 14 23:09:56 2014] Conor showed how to give codes for all the data types, maybe that's not what you mean though? [Thu Aug 14 23:10:06 2014] not sure [Thu Aug 14 23:10:12 2014] because that would be much weaker than the kind of thing ind-rec gives you [Thu Aug 14 23:10:13 2014] fumbling around in this space [Thu Aug 14 23:10:57 2014] i think what i can say in coq isn't enough to say what i want to say, but i don't know enough to know that for sure [Thu Aug 14 23:13:07 2014] i suppose this is the real cultural divide between agda/coq at work [Thu Aug 14 23:13:17 2014] agda throws whatever crap they like in the meta-theory =) [Thu Aug 14 23:13:53 2014] haha [Thu Aug 14 23:14:17 2014] hrmm does universe polymorphism let us dodge the 'small' requirement? [Thu Aug 14 23:14:21 2014] Dybjer's stuff seems to justify inductive-recursive definitions nicely, and it would fit fine in Coq just like mutually recursive functions - it's just kind of scary and probably very hard to implement [Thu Aug 14 23:14:27 2014] * goes off to learn how that encodingworks [Thu Aug 14 23:16:06 2014] There's a paper on 'surreal numbers in coq' [Thu Aug 14 23:16:21 2014] they are defined by an inductive-recursion definition [Thu Aug 14 23:16:29 2014] hrmm [Thu Aug 14 23:16:41 2014] but this guy defines it somehow as two mutually recursive inductive defs [Thu Aug 14 23:16:48 2014] I have no idea how that works [Thu Aug 14 23:17:01 2014] http://types2004.lri.fr/SLIDES/mamane.pdf ? [Thu Aug 14 23:17:02 2014] well the paper to go with that [Thu Aug 14 23:17:19 2014] yeah [Fri Aug 15 00:56:24 2014] does anyone know if http://www.irisa.fr/celtique/pichardie/ext/these/ is available as just a tarball of source files? [Fri Aug 15 00:58:48 2014] edwardk: since you can build Coq terms directly just as you would in Agda, what is it exactly that Agda gives you that Coq can't in the case of induction-recursion? [Fri Aug 15 00:59:01 2014] agda adds it to the core theory [Fri Aug 15 00:59:16 2014] oh, it axiomatizes this particular feature? [Fri Aug 15 00:59:21 2014] yeah [Fri Aug 15 00:59:26 2014] hrpmh [Fri Aug 15 00:59:32 2014] says 'this is okay' and lets you use it [Fri Aug 15 00:59:43 2014] I wonder how hard people have looked for inconsistencies [Fri Aug 15 00:59:44 2014] its just like saying 'generalized recursion is okay' [Fri Aug 15 00:59:48 2014] I'm wary of all axioms now [Fri Aug 15 00:59:54 2014] not an axiom per se [Fri Aug 15 01:00:01 2014] just a change in the way the termination checker works [Fri Aug 15 01:00:08 2014] to permit this thing [Fri Aug 15 01:00:20 2014] anyways, mcbride showed you could do it for 'small' universes in coq [Fri Aug 15 01:00:26 2014] ah [Fri Aug 15 01:00:27 2014] but now we have universe polymorphism [Fri Aug 15 01:00:52 2014] so i'm trying to understand if his approach generalizes to Type : Type now that we have that. to get a 'big enough' universe [Fri Aug 15 01:01:06 2014] right [Fri Aug 15 01:01:27 2014] if so then i can transcode Mike Shulman's fancy higher inductive-recursive hott universe trick to coq [Fri Aug 15 01:01:54 2014] and along the way i'm beating my face into how to do basic things in coq and learning the way things work =) [Fri Aug 15 01:01:55 2014] I wonder how much of regular Coq you're going to be able to use when all is said and done [Fri Aug 15 01:02:30 2014] yes, but you see i have no intuition for what is already there, so i won't miss it so long as i don't taste that sweet sweet forbidden fruit. [Fri Aug 15 01:02:31 2014] =) [Fri Aug 15 01:02:57 2014] google-hangout? [Fri Aug 15 01:03:01 2014] sure [Fri Aug 15 01:03:09 2014] let me get my headphones [Fri Aug 15 02:13:58 2014] if I have existT x y z = existT x y' z', how can I reduce this to needing to prove the equality of xs and zs? [Fri Aug 15 02:15:30 2014] any idea how to proceed on the two lemmas here: https://github.com/ekmett/homotopy/blob/master/Slice.v ? [Fri Aug 15 02:16:11 2014] i don't know how to dig in there to get to the equalities to use them. [Fri Aug 15 02:51:57 2014] ok, so the main takeaway i have from this is to get through the connection between Set/I and (I -> Set) you need uniqueness of identity proofs, which is basically Axiom K, and that's not Hott-compatible, right? [Fri Aug 15 02:58:00 2014] well, i guess we can have it on a type by type basis. [Fri Aug 15 03:01:53 2014] can it be proved that {x : {x : X & f x} & projT1 x = y} = f y? [Fri Aug 15 03:02:07 2014] I don't know how to make "choices" for the witness on the left-hand side of the equality [Fri Aug 15 03:49:37 2014] johnw, around perhaps? [Fri Aug 15 03:50:08 2014] I am [Fri Aug 15 03:50:46 2014] ha :) [Fri Aug 15 03:51:07 2014] so i was playing around with that example of well-founded recursion you gave [Fri Aug 15 03:51:08 2014] https://privatepaste.com/4d5b9f16ea [Fri Aug 15 03:51:22 2014] Coq says failure in proveterminate Error: Partial application of function stratify_rec in its body is not allowed while using Function [Fri Aug 15 03:51:34 2014] does that mean i cant use Function for this type of problem? [Fri Aug 15 03:55:13 2014] let me try [Fri Aug 15 03:56:05 2014] so basically im constructing a tree [Fri Aug 15 03:56:28 2014] and every iteration, the leafs are split into subleafs [Fri Aug 15 03:56:46 2014] what is an fstring? [Fri Aug 15 03:56:46 2014] Coq should recurse into the length of these, and not on the amound of subleafs [Fri Aug 15 03:56:53 2014] its a list [Fri Aug 15 03:57:13 2014] i could paste you the whole file but it uses CoLoR [Fri Aug 15 03:57:26 2014] amount* [Fri Aug 15 03:58:28 2014] yeah, I'm missing too much context to try this here [Fri Aug 15 03:58:41 2014] try not partially applying stratify_rec [Fri Aug 15 03:58:45 2014] write out the lambda [Fri Aug 15 03:58:48 2014] how? [Fri Aug 15 03:58:59 2014] what does it mean to 'partially apply' something? [Fri Aug 15 03:59:01 2014] map (fun x : TYPE => stratify_rec x) [Fri Aug 15 03:59:14 2014] ah it doesnt like that? [Fri Aug 15 03:59:19 2014] well, it MAY not [Fri Aug 15 03:59:20 2014] i don't know [Fri Aug 15 04:00:53 2014] failure in proveterminate Error: Found a lambda which body contains a recursive call. Such terms are not allowed [Fri Aug 15 04:01:02 2014] ah [Fri Aug 15 04:01:14 2014] on this https://privatepaste.com/57fbc0acf8 [Fri Aug 15 04:01:59 2014] why does it not accept that though, i thought the whole point was to be able to make recursive calls [Fri Aug 15 04:02:09 2014] so, it doesn't _know_ what map is going to do with that function [Fri Aug 15 04:02:21 2014] which makes it impossible to reason about the recursion requirements [Fri Aug 15 04:03:18 2014] but there may be a harder requirement by the termination checker going on here [Fri Aug 15 04:03:34 2014] since peering into higher-order function arguments is probably impossibly hard, it won't let you define your recursion over them [Fri Aug 15 04:03:52 2014] or it's just a limitation of the current termination checker [Fri Aug 15 04:04:01 2014] this "measure" stuff is brand new [Fri Aug 15 04:04:03 2014] (8.4) [Fri Aug 15 04:04:06 2014] hm [Fri Aug 15 04:04:28 2014] but the size of these leafs is obviously decreasing [Fri Aug 15 04:04:36 2014] since youre splitting them to create more leafs [Fri Aug 15 04:05:19 2014] i'm not saying it's wrong [Fri Aug 15 04:05:25 2014] the termination checker is not perfect [Fri Aug 15 04:05:36 2014] it errs on the side of caution [Fri Aug 15 04:05:39 2014] do you think its impossible in Coq 8.4? [Fri Aug 15 04:06:32 2014] i don't know [Fri Aug 15 04:06:38 2014] What is VTerm.Fun? [Fri Aug 15 04:06:50 2014] it creates a tree [Fri Aug 15 04:07:18 2014] what is the type of stratify_sub? [Fri Aug 15 04:07:19 2014] by taking a head of the node label's type and arguments of type vterm [Fri Aug 15 04:07:55 2014] it creates from an fstring a list of fstrings, of which the first element is going to be the head of the new subtree that is to be formed from that input fstring, and the rest are going to be the leafs/arguments [Fri Aug 15 04:08:11 2014] (it=stratify_sub) [Fri Aug 15 04:08:27 2014] i see [Fri Aug 15 04:08:40 2014] and you are trying to give evidence that this list of fstrings isn't going to cause infinite recursion [Fri Aug 15 04:08:46 2014] yea [Fri Aug 15 04:08:52 2014] which its not, right [Fri Aug 15 04:09:01 2014] you can only split a list so many times [Fri Aug 15 04:09:14 2014] i have the lemma to prove this ready [Fri Aug 15 04:09:22 2014] well, since I don't know anything about stratify_sub, for all I know it could be doubling its args [Fri Aug 15 04:10:04 2014] instead of using map, write out the recursion manually in another function [Fri Aug 15 04:10:10 2014] stratify_args [Fri Aug 15 04:10:31 2014] you'll need to use mutual recursive function definitions [Fri Aug 15 04:10:49 2014] whether that works with "measure" or not, I don't know [Fri Aug 15 04:10:57 2014] but you aren't going to be able to use "map" here [Fri Aug 15 04:11:00 2014] hm [Fri Aug 15 04:11:28 2014] does Function support mutual recursion? [Fri Aug 15 04:11:32 2014] good question [Fri Aug 15 04:11:41 2014] Function foo : TYPE := BODY with bar : Type := BODY. [Fri Aug 15 04:18:37 2014] would it help to use Program? [Fri Aug 15 04:18:58 2014] I don't know [Fri Aug 15 04:19:03 2014] if it does, tell me :) [Fri Aug 15 04:19:14 2014] haha mehh [Fri Aug 15 04:19:45 2014] what does Program do though [Fri Aug 15 04:19:50 2014] its different from Function? [Fri Aug 15 04:19:56 2014] how do Program, Function and Fix relate? [Fri Aug 15 04:20:15 2014] its hard to find out about these keywords because google will just ignore casing [Fri Aug 15 04:20:17 2014] you'd write "Program Function" [Fri Aug 15 04:20:24 2014] it adds some conveniences [Fri Aug 15 04:20:43 2014] its just syntax sugar? [Fri Aug 15 04:20:52 2014] it helps you manage proof obligations, and will even solve the simplest automatically [Fri Aug 15 04:21:03 2014] there's a chapter in the Coq reference manual about the Program environment [Fri Aug 15 04:21:50 2014] edwardk: https://groups.google.com/forum/#!msg/homotopytypetheory/duXp2K8NcRk/7GWayB4vZY0J suggests that defining the stasheff polytopes in Coq/Agda is an open question. [Fri Aug 15 04:21:59 2014] ok so lets forget about Program [Fri Aug 15 04:22:04 2014] jgross: thx [Fri Aug 15 04:22:10 2014] youre saying write a custom map function [Fri Aug 15 04:22:20 2014] yes, make the recursion explicit [Fri Aug 15 04:22:29 2014] jgross: got bogged down trying to model small induction-recursion in coq [Fri Aug 15 04:22:35 2014] rather than passing your function as an argument to another function [Fri Aug 15 04:22:39 2014] that's my current dilemma [Fri Aug 15 04:22:48 2014] but other than using map, how am i going to apply a function to a list of arguments and then recurse into each argument of the resulting list? [Fri Aug 15 04:22:55 2014] thats exactly what map does right? [Fri Aug 15 04:23:05 2014] yep [Fri Aug 15 04:23:20 2014] 03:23 map _ [] = [] [Fri Aug 15 04:23:21 2014] 03:23 map f (x:xs) = f x : map f xs [Fri Aug 15 04:23:27 2014] it's nothing fancy [Fri Aug 15 04:23:38 2014] in your case, you'd not have the 'f' parameter there [Fri Aug 15 04:23:44 2014] so how does it help to copy this and write it out explicitly myself [Fri Aug 15 04:23:50 2014] in what way would i modify it [Fri Aug 15 04:24:36 2014] trying to figure out if universe polymorphism is enough to build fancy universes ala Tarski with "small IR" for Shulman's higher-inductive-recursive univalent universes trick. [Fri Aug 15 04:24:47 2014] e.g. if universe polymorphism lets small be big enough [Fri Aug 15 04:25:02 2014] something along the lines of: https://gist.github.com/269703e59605b4e6303d [Fri Aug 15 04:25:30 2014] jgross: do you know of anything that makes this a complete non-starter of a direction? [Fri Aug 15 04:25:37 2014] edwardk, vanila: native IR is on the todo list of some of the Coq devs (Matthieu in particular, if I recall correctly). Certainly not for 8.5. Maybe for the version after that. In the mean time, you can fake induction-recursion by indexing by the result you want to compute; see https://sympa.inria.fr/sympa/arc/coq-club/2013-08/msg00201.html [Fri Aug 15 04:26:10 2014] that's the Small IR trick basically [Fri Aug 15 04:26:28 2014] johnw, hm let me try that [Fri Aug 15 04:26:33 2014] figuring universe polymorphism will let that live out in Type [Fri Aug 15 04:27:28 2014] native IR would make life suck a lot less though [Fri Aug 15 04:28:09 2014] Error: Cannot use mutual definition with well-founded recursion or measure [Fri Aug 15 04:28:11 2014] :'( [Fri Aug 15 04:28:23 2014] youch [Fri Aug 15 04:28:24 2014] great link though. that lets me try a much more direct encoding than i was chasing =) [Fri Aug 15 04:28:26 2014] I was afraid of that [Fri Aug 15 04:30:12 2014] edwardk: the small-IR trick just means you have to jump universe levels when you define things, right? You should be totally fine in Type, you just can't model the type _you_ live in, you only get to model the Types below that one. [Fri Aug 15 04:31:07 2014] yeah i just meant that I need to build a Type, not just a Set, which is fine since I can work in Type with a higher universe index, so everything should be good. [Fri Aug 15 04:31:56 2014] johnw, roosbeef: You should be able to do well-founded recursion directly by doing structural recursion on the evidence of well-foundedness? (I've never tried it, but, I don't think well-founded reucrsion gives you anything over structural recusion, other than ease-of-use.) [Fri Aug 15 04:33:05 2014] jgross, what do you mean by "structural recursion over the _evidence_ of well-foundedness"? [Fri Aug 15 04:33:06 2014] jgross: so pass that evidence as an argument, rather than using the nifty {measure...} syntax? [Fri Aug 15 04:35:18 2014] johnw: regarding what exactly agda gives you that Coq doesn't: Agda has mutual blocks and a termination checker. Coq has explicit mutual statements (restricted to handling inductive types) and structural recursion. So they added the appropriate rules to Agda's termination checker to make it accept inductive definitions and function definitions that are mutually recursive, in the same mutual block. In Coq, you'll get stuck with syntax errors [Fri Aug 15 04:35:18 2014] before you get going, and if you want to add it, you'll need to explicitly add the right rules to the guardedness checker (which is currently ad-hoc, and has had two or three bugs in the last few months which allowed proving False, either without axioms, or from propositional extensionality---people are thinking of moving to sized types to be more systematic, but, again, not for 8.5). [Fri Aug 15 04:35:40 2014] johnw: Yes, exactly. [Fri Aug 15 04:36:09 2014] ah, very good to know [Fri Aug 15 04:36:17 2014] I tend to mislike inconsistent systems [Fri Aug 15 04:36:59 2014] i tend to like them -- right up until i'm bit by the inconsistency. so much easier to prove stuff in! [Fri Aug 15 04:37:06 2014] haha [Fri Aug 15 04:37:28 2014] if we just axiomatize False, think of all we could accomplish! [Fri Aug 15 04:37:55 2014] Want a category theory framed on HoTT and bicategories? DONE [Fri Aug 15 04:38:29 2014] roosbeef: There's a type, Acc, I think, in the standard library, that is what I think measure uses internally. Look for Acc, Fix, and Fix_eq as definitions. I think Fix might be a "well-founded fixpoint combinator defined by structural recursion on the evidence". So you should be able to define a well-founded mutual fixpoint combinator similarly, by mutual structural recursion on evidence (you might or might not need to define a new type of [Fri Aug 15 04:38:29 2014] evidence for handling mutual definitions) [Fri Aug 15 04:39:39 2014] I'm not aware of any prior work on this, though googling "mutual well-founded fixpoints Coq" or something might give you useful results (I haven't tried, and I should be heading off to work in a few minutes) [Fri Aug 15 04:39:58 2014] jgross: what is your timezone right now? [Fri Aug 15 04:40:33 2014] edwardk: You're in the same camp as Vladimir, then; he was trying to convince Andrej Bauer to go with type-in-type rather than universe checking for Andromeda (formerly Brazil). [Fri Aug 15 04:40:42 2014] johnw: Cambridge, UK. So, 9:40am. [Fri Aug 15 04:41:00 2014] ah, you exchanged one Cambridge for another I see [Fri Aug 15 04:41:11 2014] jgross: i like universes really, but then i spend a lot of time coding in haskell and just try to get stuff done rather than prove stuff all day. [Fri Aug 15 04:41:29 2014] edwardk: this evening was the stuff of nightmares [Fri Aug 15 04:41:38 2014] these things happen. [Fri Aug 15 04:41:42 2014] I'm sure I'm going to have a dream now about everything hinging on needing to know what "Type" is [Fri Aug 15 04:42:11 2014] Yes. And I exchanged program synthesis and category theory in HoTT for formalized x86 assembly and ... still category theory in HoTT, but much less of it. [Fri Aug 15 04:42:34 2014] What happened this evening? [Fri Aug 15 04:42:46 2014] beating one's head against these sorts of things is valuable, in that we can more quickly realize when we're attempting the impossible next time :) I had a sense that our context was too shallow, and I think we proved it [Fri Aug 15 04:43:04 2014] jgross: try to work through some of Conor's IR stuff [Fri Aug 15 04:43:13 2014] he claimed two definitions were inverses, and we tried to prove it [Fri Aug 15 04:43:23 2014] silly us [Fri Aug 15 04:43:52 2014] formalized x86 assembly? are you working with Greg Morrissett by any chance? [Fri Aug 15 04:44:53 2014] johnw: No, with Andrew Kennedy and Nick Benton. At least this summer. x86proved.codeplex.com Codeplex, because that's what MS said to use, before they came to their sanity and decided on github. We haven't migrated yet. [Fri Aug 15 04:45:18 2014] I know that Greg is working on formalizations of parts of x86 in Coq too [Fri Aug 15 04:46:00 2014] they just finished with the integer or the floating-point units, I can't remember which [Fri Aug 15 04:46:01 2014] jgross, sorry i had to answer the phone. So Fix does support mutual recursion, whereas Function does not? [Fri Aug 15 04:46:08 2014] also, he may be working at the microcode level, not the x86 surface [Fri Aug 15 04:47:51 2014] No. Fix is a Coq function defined in the standard library. I'm thinking you can make a similar definition that does support mutual recursion. [Fri Aug 15 04:48:41 2014] would that require me to prove a gazillion properties of this Fix_alt? [Fri Aug 15 04:49:01 2014] for Coq to accept all conclusions drawn from its use? [Fri Aug 15 04:51:15 2014] edwardk, johnw: You might be interested in Matt Oliveri's (now finished/fully working) type checker for raw syntax into an hSet universe, written in Coq, (https://code.google.com/p/outrageous-interpreter/, http://homotopytypetheory.org/2014/03/03/hott-should-eat-itself/#comment-25555). If you're finding the comments of http://homotopytypetheory.org/2014/03/03/hott-should-eat-itself hard to navigate, Mike Shulman's code is at [Fri Aug 15 04:51:15 2014] http://home.sandiego.edu/~shulman/papers/autophagia/. (All of this is burried deep in the comments of that blog post.) [Fri Aug 15 04:53:34 2014] roosbeef: I think you'd only need the equivalent of Fix_eq. See http://coq.inria.fr/library/Coq.Init.Wf.html. You don't need anything extra to get Coq to accept conclusions about it, but you won't get any syntactic sugar. [Fri Aug 15 04:54:49 2014] heh, the lines of inquiry are exploding faster than my ability to bookmark, be warned, i'll probably ping you for follow up info later ;) [Fri Aug 15 04:58:27 2014] johnw, jgross, thanks a lot for your suggestions, this seems to be exactly what i would need to solve this problem [Fri Aug 15 04:58:43 2014] edwardk: That's fine, though this mostly exhausts my knowledge on type theory interpreters. (For example, I haven't actually read or used either Mike's or Matt's code, though I have followed along with the entire thread of comments as it was happening.) Anyway, I'm off to work now. Enjoy your inquiries and bookmarking. [Fri Aug 15 04:59:00 2014] will do. [Fri Aug 15 04:59:19 2014] i read shulman's code for the HIR interpreter through, now to chase other leads [Fri Aug 15 04:59:22 2014] good night/day all [Fri Aug 15 04:59:26 2014] and eventually do some real work [Fri Aug 15 04:59:44 2014] time to break^H^H^H^H^H fix trifecta! [Fri Aug 15 05:01:02 2014] "Agda fails to forbid them, but that does not mean that they make sense" -- Conor McBride -- is eminently quotable. [Fri Aug 15 07:46:33 2014] what does Agda fail to forbid? [Fri Aug 15 09:32:23 2014] how do people read those very thin comments on wordpress blogs? [Fri Aug 15 09:40:23 2014] s/very thin// [Fri Aug 15 09:41:09 2014] and s/how/why/ (* todo: learn how to do multiple sed expressions in one line *) [Fri Aug 15 11:35:45 2014] hodapp: inductive-inductive data types IIRC [Fri Aug 15 14:28:23 2014] edwardk: yet another development of CT in Coq: http://dl.dropbox.com/u/137615/Category%20Theory%20in%20Coq.pdf [Fri Aug 15 14:28:41 2014] it's setoid-based, and far from where you're headed, but it's another point in the space to compare against [Fri Aug 15 15:46:32 2014] hello [Fri Aug 15 15:46:42 2014] hi [Fri Aug 15 15:52:11 2014] really stuck on split_combine proof http://lpaste.net/4142512831918505984 could someone please give me a hint? [Fri Aug 15 15:56:45 2014] Ainieco, you need that l1 and l2 are not nil [Fri Aug 15 15:57:14 2014] so destruct l1; destruct l2. and discharge the 3 impossible cases to be left with l1 = x0 :: l1' and l2 = y0 :: l2' [Fri Aug 15 15:58:11 2014] then you can use the induction hypothesis on the tails of all these lists [Fri Aug 15 16:01:35 2014] You might need these two lemmas to conclude: split' (combine l1 l2) = l1, split'' (combine l1 l2) = l2 [Fri Aug 15 16:04:40 2014] oh, that makes sense, thanks! [Fri Aug 15 16:19:23 2014] How do you, from an hypothesis [H: (a, b) = (c, d)], deduce [a=c] and [b=d]? I'd like to have those as hypothesis without Coq doing any substitutions. [Fri Aug 15 16:21:28 2014] [inversion H.] [Fri Aug 15 16:21:44 2014] Well, yes, but then Coq starts doing a lot of substituions that complicate the goal way too much [Fri Aug 15 16:21:51 2014] substitutions* [Fri Aug 15 16:22:13 2014] Cypi: sometimes injection works better [Fri Aug 15 16:22:21 2014] because it's not too smart for its own good [Fri Aug 15 16:22:56 2014] Perfect, thanks! [Fri Aug 15 16:25:21 2014] <_cody_> inversion H; subst [Fri Aug 15 16:25:25 2014] <_cody_> works quite well [Fri Aug 15 16:25:42 2014] It doesn't when 'c' and 'd' are subterms of 'a' and 'b'. [Fri Aug 15 16:25:56 2014] It was the case here, and it is what caused Coq's inversion to go crazy on substitutions. [Fri Aug 15 16:26:20 2014] _cody_: your underscore moved! [Fri Aug 15 16:26:37 2014] <_cody_> i was trying to through people off... [Fri Aug 15 16:26:51 2014] <_cody_> Cypi: ah ok [Fri Aug 15 16:27:22 2014] <_cody_> through -> throw [Fri Aug 15 16:27:31 2014] vanila: I didn't need any helper lemmas for split_combine [Fri Aug 15 16:36:26 2014] vanila: https://gist.github.com/0426d2259d4945e5687f [Fri Aug 15 16:58:25 2014] very neat, i couldn't get it to work here though [Sat Aug 16 03:28:00 2014] hi [Sat Aug 16 03:29:47 2014] hi [Sat Aug 16 06:22:59 2014] hello [Sat Aug 16 06:23:41 2014] is it possible to generalize multiple dependent variable without having to repeat "generalize depended a. generalize dependent b" all over agai? [Sat Aug 16 08:47:32 2014] Is it known for which pure type systems typing judgements are decidable? [Sat Aug 16 13:14:46 2014] torfscholle: you probably need atleast weak normalization, but AFAIK there is no clear classification of those that are WN [Sat Aug 16 17:27:51 2014] robbert: hm, ok, that's interesting -- my motivation is that I would like to implement Girard's paradox for learning and I am therefore looking for an interpreter for the final pure type system. but if I understand you correctly, typing in this system is not decidable, since it is not even weakly normalizing - right? [Sat Aug 16 17:44:08 2014] robbert: can you provide references for the positive results (and implementations?) on the decidability of type checking in PTS? [Sat Aug 16 21:27:12 2014] ok, super newbie question, when i have a [Sat Aug 16 21:27:13 2014] X0 : f (fst (o1, o2)) ~{ E }~> g (snd (o1, o2)) -- in my environment, how do i simplify out the fst and snd ? [Sat Aug 16 21:27:49 2014] they are obvious from context, but i'm just blanking on what keyword to guess in the tactic game [Sat Aug 16 21:45:03 2014] simpl in X0. [Sat Aug 16 21:45:39 2014] alternative: unfold fst in *; unfold snd in *. [Sat Aug 16 22:02:41 2014] wound up finding a nicer way [Sat Aug 16 22:02:47 2014] just avoided the whole situation [Sat Aug 16 22:02:59 2014] simpl refused to catch it. primitive projections maybe? [Sat Aug 16 22:16:31 2014] when coqtop decides to spin forever , how do i get control of proof general back and start it over? [Sat Aug 16 22:19:31 2014] ok, it appears i can go to the *coq* buffer, C-x k it and get control back that way [Sat Aug 16 22:21:42 2014] edwardk: C-c C-c may be what you're looking for [Sat Aug 16 22:24:56 2014] thx [Sun Aug 17 02:15:21 2014] Can one make 'print' recursively unfold all definitions? [Sun Aug 17 03:46:28 2014] if I have a hypothesis, can I "copy" before applying an elimination rule so that I can apply a different eliminate rule? [Sun Aug 17 03:47:44 2014] ah, assert (H2 := H1) [Sun Aug 17 04:38:01 2014] would've said [pose proof H1], but it does the same :p [Sun Aug 17 05:10:55 2014] filter_challenge_2 took me far too long; I need to remember that sometimes it's just as important to generalize a hypothesis as with any other variable [Sun Aug 17 05:11:15 2014] https://gist.github.com/ea000d370b14fb3c43a4 [Sun Aug 17 12:26:10 2014] edwardk: There's always [change foo with bar in H] (and a number of other variants) if [foo] is convertible with [bar]. In this case, though, [simpl fst in X0] (or even just [simpl in X0]) should catch that, unless you've done something like [Arguments fst : simpl never.]. It's probably not primitive projections, because turning on primitive projections doesn't retroactively make the [prod] type from the stdlib primitive. It only affects new [Sun Aug 17 12:26:10 2014] records, so you'd've needed to rewrite the [prod] type yourself as a record. If you still have the context where it's failing, see if you can track down the bug? (Or if you don't want to do that, you can point me at it, and I can set up my bug minimizer on it.) [Sun Aug 17 12:28:59 2014] i'll have to rebuild it later. i was building some code for comma categories, but eventually i swtiched styles because i was getting stuck that way and assumed it was me. [Sun Aug 17 12:42:33 2014] How are you doing comma categories? [Sun Aug 17 12:48:55 2014] torfscholle: [Eval compute in foo] will fully unfold and normalize [foo]. See also [Eval cbv delta] in the reference manual. [Sun Aug 17 13:19:10 2014] Do you guys know, if I have a goal like [((a * b) * c) * d) + x], and I have a lemma that ((x*y)*z) = ((x*z)*y),how can I rewrite my goal to [((a * c) * b) * d) + x]? [Sun Aug 17 13:19:27 2014] I tried [rewrite lem at 0], but it didn't work [Sun Aug 17 13:20:25 2014] is that forall x y z, ((x*y)*z) = ((x*z)*y) [Sun Aug 17 13:20:47 2014] you could try: rewrite (lem a b c). [Sun Aug 17 13:20:56 2014] or rewrite <- (lem a b c). [Sun Aug 17 13:29:40 2014] <_cody_> of course, [ring [Sun Aug 17 13:29:44 2014] <_cody_> sorry [Sun Aug 17 13:29:54 2014] <_cody_> [ring] should be enough to attack your goal [Sun Aug 17 13:55:30 2014] jgross: not well, that was the problem ;) [Sun Aug 17 13:56:41 2014] jgross: i was just trying to rephrase some of the standard path groupoid fiber stuff as just talking about a special case of over/under categories in the appropriate places and wound up down a rat-hole. [Sun Aug 17 14:05:31 2014] <_cody_> rat holes abound down that path :) [Sun Aug 17 14:05:38 2014] <_cody_> no pun intended [Sun Aug 17 14:07:52 2014] =P [Sun Aug 17 14:13:20 2014] what do you do for "Anomaly: Uncaught exception Failure("List.chop", _). Please report." errors in proof general. i can't tell if its a proof general bug or a coq issue or what, but they happen a lot to me [Sun Aug 17 15:27:39 2014] today in idiocy: convincing yourself momentarily that False -> A couldn't be constructively valid because there is no way to synthesise an A for a False argument before remembering there aren't any to begin with [Sun Aug 17 15:37:39 2014] edwardk: I have comma categories at https://github.com/HoTT/HoTT/blob/master/theories/categories/Comma/Core.v. What were you trying to phrase that got you in a rat hole? [Sun Aug 17 15:38:14 2014] didn't have enough scaffolding in place yet [Sun Aug 17 15:38:38 2014] starting from scratch -- there is usually something you forgot to get to you need ;) [Sun Aug 17 15:38:49 2014] edwardk: Anomalies are bugs in Coq. Always, unless you have some custom elisp that fakes Coq error messages or something. You should throw the relevant file at coq-bug-finder/find-bug.py, and submit the resulting file to the bug tracker. [Sun Aug 17 15:39:36 2014] alrighty, when i have more bandwidth i'll do that [Sun Aug 17 15:39:53 2014] bandwidth? [Sun Aug 17 15:41:04 2014] (By the way, if you have suggestions for making find-bug.py easier to use, I'd welcome them.) [Sun Aug 17 15:53:35 2014] bandwidth meaning mental bandwidth. juggling a call for participations i have to send out, need to fix up trifecta before work tomorrow, have a dozen balls up in the air with respect to what i'm doing in the little homotopy lib, pushing out updates to some haskell code, etc. [Sun Aug 17 15:54:31 2014] i'm context switching too much right now =) [Sun Aug 17 15:57:52 2014] what is the ! in an Arguments command used for? [Sun Aug 17 16:01:46 2014] edwardk: *nods* My goal with my bug-minimization scripts is to make them as low-bandwidth as possible. (Once you check that they get the right errors, you can ignore them until they're done running.) [Sun Aug 17 16:01:46 2014] http://coq.inria.fr/refman/Reference-Manual010.html#hevea_command232 says """A constant can be marked to be unfolded only if an entire set of arguments evaluates to a constructor. The ! symbol can be used to mark such arguments. [Sun Aug 17 16:01:46 2014] Coq < Arguments minus !x !y. [Sun Aug 17 16:01:46 2014] After that command, the expression (minus (S x) y) is left untouched by simpl, while (minus (S x) (S y)) is reduced to (minus x y).""" [Sun Aug 17 16:03:07 2014] ok, so when i mark inverse , etc. with the ! on the category i'm saying don't simplify unless you know what category i'm working with? [Sun Aug 17 16:03:25 2014] Right. [Sun Aug 17 16:03:29 2014] k [Sun Aug 17 16:03:53 2014] I think that's the default, though? [Sun Aug 17 16:05:18 2014] was trying to understand where it came from in some code i cargo culted and wanted to understand later [Sun Aug 17 16:05:59 2014] going through and clearing out a bunch of explicit %scoping by using Bind Scope .. with .. etc [Sun Aug 17 16:06:09 2014] and trying to get a better understanding of the notation system [Sun Aug 17 16:06:19 2014] and that led me to clean up my Arguments statements [Sun Aug 17 16:06:28 2014] but that was the last thing in them i didn't understand [Sun Aug 17 16:07:21 2014] *nods* I should probably do that with mine, at some point; I think I haven't really updated them for a year or a year-and-a-half, when I knew less about Coq's defaults. (Or possibly the ! behavior is only default on primitive projections.) [Sun Aug 17 16:07:42 2014] I should also figure out a notation for morphisms and functors and natural transformations. [Sun Aug 17 16:09:42 2014] i had notation that was working nicely, then i started playing around with separating category into more record-like parts so i can more easily reason about piling more properties on the hom without getting stuck in lack-of-record-subtyping hell [Sun Aug 17 16:10:30 2014] so i'm trying out a quick variant of things where i instead package up a bunch of classes for structure-like-properties like upgrading a category to a groupoid, which can only be done one way [Sun Aug 17 16:11:01 2014] but then i'm wallowing around in the design space trying to figure out the best balance of what to expose in arguments vs. wrap in the records, etc. [Sun Aug 17 16:13:41 2014] Here are some considerations: Anything you expose that is an argument to things like [Functor] and [NaturalTransformation] will cause exponential blow up in your types, and slow things down. If you need to layer projections to get to things, you loose the benefit of primitive projections, so all of your projections will carry arguments around (not so much of a problem if your top-level record type has no arguments). You can read the papers on [Sun Aug 17 16:13:41 2014] ssreflect and mathclasses to get their view on how to get a nice hierarchy. [Sun Aug 17 16:15:02 2014] I found it sufficient to wrap everything in the records, and then you can have a single typeclass for any other set of properties you need to add on. But I'm not sure if that generalizes well to your domain. [Sun Aug 17 16:15:39 2014] the devil's advocate is that if i don't expose them then i get other explosions making it hard to make deep lattices of properties, so there is a sweet spot in the design space i'm trying to find by flailing all over it ;) [Sun Aug 17 16:16:17 2014] your description is pretty close to what i'm trying now though [Sun Aug 17 16:16:48 2014] Do you have an example of a deep lattice of properties that you need? [Sun Aug 17 16:19:55 2014] well, in haskell i have a bunch of classes that all pile on top of each other to get what i need then i use coherence of instance resolution a lot. here i don't have that. even a trivial example would be starting with category, wanting groupoid to be an enhancement of that, thin category to say the hom-sets are prop-truncated, strict to say they are set-truncated, etc. now the latter few are all property-like-structures, they are [Sun Aug 17 16:19:55 2014] unique if proven, they don't change the thing or equip it so they are pretty easy. but ultimately i'm trying to figure out how to nicely tease apart the difference between what i want to say something is (including everything i equipped it with) and all thing things i can say it has by dint of being what it is (property-like structures) [Sun Aug 17 16:21:34 2014] but when i go from category to monoidal category i wind up making the subclassing relationship by Coercion, but then when i want another point in the lattice off to the side, i wind up paying for all the points in the lattice above me if i'm not careful. [Sun Aug 17 16:21:40 2014] an example that perhaps makes more sense [Sun Aug 17 16:21:51 2014] if we define functors between categories [Sun Aug 17 16:22:00 2014] then they are automatically good enough to be functors between groupoids [Sun Aug 17 16:22:18 2014] but when i define functors between monoidal categories i need to define monoidal functors as well, they don't automatically preserve the extra structure [Sun Aug 17 16:23:18 2014] but if i bake the choice of category into the functor all i do is bake in the category-structure, when i come along later and want to do it with monoidal categories, i have to store the same data again in new slots in another record and define the fields in the functor-part of my monoidal functor to be just the projection from my monoidal-category down to its category component [Sun Aug 17 16:24:05 2014] if i leave it naked on the outside of the record on the other hand, such redundant storage is avoided, and i can use the coercion mechanism, at the cost of blowing up the types [Sun Aug 17 16:24:55 2014] ultimately i think the answer comes down to carefully distinguishing between http://ncatlab.org/nlab/show/stuff,+structure,+property [Sun Aug 17 16:25:50 2014] Can't you say something like [Record MonoidalFunctor (C D : MonoidalCategory) := { FunctorPart :> Functor C D ; }.] and get the projections for free? [Sun Aug 17 16:30:19 2014] that is what i do now [Sun Aug 17 16:31:57 2014] but when i have a diamond, when i have something that is both a strict functor and a monoidal functor for instance, i need to name the pushout of those two theories [Sun Aug 17 16:32:44 2014] for a sufficiently large lattice of properties this is messy =) [Sun Aug 17 16:33:17 2014] hence my desire to distinguish between property-like structure you can grab from any proof of its existence [Sun Aug 17 16:33:26 2014] and stuff you need to bolt into that lattice [Sun Aug 17 16:34:46 2014] i'll give you an example of this in something like haskell [Sun Aug 17 16:34:52 2014] lets say you have a class for Monad [Sun Aug 17 16:34:55 2014] and one for Comonad [Sun Aug 17 16:35:00 2014] both of these are perfectly cromulent things [Sun Aug 17 16:35:32 2014] now we'd like to be able to abuse the fact that given a Monad defined haskell-style you can define the definition of fmap for it 'for free' [Sun Aug 17 16:35:43 2014] you can write out liftM in terms of return and (>>=) [Sun Aug 17 16:35:50 2014] but we can do the same thing on the Comonad side. [Sun Aug 17 16:36:18 2014] since there are potentially multiple derivations we just don't let you fill in your superclass methods in haskell, in this sense haskell is bad at abstraction [Sun Aug 17 16:36:36 2014] why? because as you refine a theory you are adding operations and laws about the operations [Sun Aug 17 16:36:55 2014] and in haskell we pay for all the operations and get none of the benefits of the laws collapsing the space of possible operations we have to consider at any point [Sun Aug 17 16:37:21 2014] going back to Monad and Comonad, you can define a thing that is both a Monad and a Comonad by shoving both into a record [Sun Aug 17 16:37:38 2014] but that is fundamentally the wrong way to pushout the concept of Monad and Comonad to make the proper subclass you want to work with most of the time [Sun Aug 17 16:37:51 2014] consider (,) e, the partial application of the product type [Sun Aug 17 16:38:20 2014] it is a Monad when e is a Monoid. you can return by putting mempty in the side you don't care about, you can (>>=) by gluing together the monoidal values with the monoid. [Sun Aug 17 16:38:25 2014] it is a Comonad all the time though [Sun Aug 17 16:39:11 2014] when we go to push out the Monad theory and the Comonad theory for (,) e we don't want a Monad + Comonad for (,) e -- we want a pushout of two conditional theories, we want the '(,) e is a monad if e is a monoid' theory and '(,) is a comonad' theories to be pushed out [Sun Aug 17 16:39:37 2014] then you can say the obligation becomes that liftM = liftW iff both preconditions for the classes to be present are satisfied [Sun Aug 17 16:41:21 2014] then we can talk about orphans, coherence of instance resolution in this context, etc. that is actually the space where i think the hott approach could be nice. going through and describing all the equalities between parts of records via homotopies of paths, and moving the obligations to the use site, etc. maybe not in coq, but in 'language as yet to be defined in the future where hott is just in the background' [Sun Aug 17 16:44:40 2014] I think you've lost me. Probably because I've never used comonads, and only really started using monads this year, and haven't formalized them categorically, yet. I also don't have the bandwith at the moment to figure it out, since I should be cleaning up some code for verifying `echo` (or a simpler version of it), and writing an abstract for a talk I'm giving on Wednesday, and then sleeping. But I'd love to hear more about this some other [Sun Aug 17 16:44:40 2014] time. [Sun Aug 17 16:46:37 2014] jgross: That reminds me, my talk is colocated with yours, so I guess I should be abstractin' too [Sun Aug 17 16:46:43 2014] jgross: mostly it comes down to the fact that languages like haskell require you to pay for every point above you in the abstraction lattice. the coq approach on the other hand requires you to pay for all the points you directly refine, but costs you coherence of instance resolution, one of my pet research areas is how to get something better than both =P [Sun Aug 17 16:47:23 2014] it always galls me that OOP-style inheritance gets better code reuse out of deep class hierarchies than Haskell does =/ [Sun Aug 17 16:50:02 2014] in coq i get the ability to write a finer grained class hierarchy but it comes at the expense of coherence, so if i instead limit myself to applying it to things that are 'property-like structures' then it doesn't matter where i get them from, and i can fish around for better ways to express pushouts of conditional theories [Sun Aug 17 16:53:26 2014] I'd be interested to see such an expression of pushouts of conditional theories, if you manage to find a nice way to do it. [Sun Aug 17 16:54:45 2014] likewise [Sun Aug 17 16:54:55 2014] its a thing i've been threatening to write a language to do for months now ;) [Sun Aug 17 16:55:40 2014] 'pushouts of theories' is how jacques carette views the way his little type system works, the conditional part was me realizing i didn't want to ever pushout Monad/Comonad directly as constraints [Sun Aug 17 16:55:47 2014] but rather the 'if this then that' part of them [Sun Aug 17 16:57:05 2014] hoping that i get some insight on this via homotopy pushouts [Sun Aug 17 16:57:57 2014] Homotopy pushouts are just \infty-groupoid pushouts in HoTT, right? [Sun Aug 17 16:59:43 2014] as i understand things, yes [Sun Aug 17 17:00:29 2014] what i'm looking at is trying to model a theory so that i can talk about pushouts of theories directly [Sun Aug 17 17:01:14 2014] then a conditional theory is a function space / dependent theory, not just a record [Sun Aug 17 21:42:26 2014] http://perso.ens-lyon.fr/guillaume.allais/pdf/report2012.pdf saw the paper title, expected mcbride. not far off, it is by his student. =P [Mon Aug 18 01:46:40 2014] if I have a Σ, how can I get the type of the witness? [Mon Aug 18 01:46:59 2014] something along the lines of: type of (projT1 x) [Mon Aug 18 01:53:21 2014] ah, found it [Mon Aug 18 01:55:34 2014] if I want a proof to be extracted later on, should I always use sigma types? [Mon Aug 18 01:55:56 2014] that's what I ended up doing [Mon Aug 18 01:56:04 2014] but others may know better [Mon Aug 18 01:56:31 2014] sh1ken: extracted from what? [Mon Aug 18 01:56:43 2014] you only need to use sigma types for the parts that are informative [Mon Aug 18 01:57:30 2014] johnw: from a theorem to ML, for example. I'm assuming this based on the comments on this post: http://stackoverflow.com/questions/13334863/can-i-extract-a-coq-proof-as-a-haskell-function [Mon Aug 18 01:59:09 2014] robbert: informative in which context? [Mon Aug 18 01:59:34 2014] that you care about the witness [Mon Aug 18 02:00:08 2014] oh, indeed [Mon Aug 18 02:00:21 2014] forall x : A, { y : B | exists z, P x y z } gets the type A -> B after extraction [Mon Aug 18 02:00:49 2014] forall x : A, { y : B & { z : C | P x y z }} gets the type A -> (B * C) after extraction [Mon Aug 18 02:01:00 2014] I see [Mon Aug 18 02:01:07 2014] so, whether to use the exists or sigma here depends on whether you do need this z [Mon Aug 18 02:01:44 2014] johnw: note you can have a coercion to both funclass and sortclass for a type,s o the category can be abused notationally as both its hom and ob. [Mon Aug 18 02:02:06 2014] so (x y : C) resolves to ob, while C x y resolves to the hom [Mon Aug 18 02:04:10 2014] yes, I had that working in my version too [Mon Aug 18 02:04:17 2014] "C" is the obj, "C x y" was the hom [Mon Aug 18 02:04:31 2014] and "C x" the Hom [Mon Aug 18 02:06:04 2014] yeah [Mon Aug 18 02:50:31 2014] if I need to apply some definition (e.g. plus) on two values with sigma types, is there anyway that I can "cast" them? or I need to redefine my definition that matches that sigma type? [Mon Aug 18 02:52:58 2014] you could make a plus_sigma that calls projT1 on its arguments [Mon Aug 18 02:58:08 2014] johnw: so I need to redefine the definition either way? [Mon Aug 18 02:58:42 2014] let me see [Mon Aug 18 03:01:09 2014] maybe so [Mon Aug 18 03:01:41 2014] the sigma type is a subtype of nat... and plus do process nat. There must be a easier way... right? [Mon Aug 18 03:03:53 2014] an* [Mon Aug 18 03:10:15 2014] thanks for the help, johnw. I'm going to research a little bit more tomorrow about that. [Mon Aug 18 06:10:21 2014] hello. Is there a way to work with "Record val := { vtype : Type; vval : vtype }." in meaningful way? For example, somehow match on vtype and extract vval. [Mon Aug 18 06:28:33 2014] another question: where can I find papers or slides from http://vsl2014.at/meetings/Coq-index.html ? [Mon Aug 18 10:45:11 2014] Hello. [Mon Aug 18 10:45:36 2014] Is there uniform way to apply arbitrary tactic to hypothesis (if it is possible at all)? [Mon Aug 18 10:46:11 2014] If yes, is it possible to apply tactic/set of tactics to both goal and hypothesis (when it is possible)? [Mon Aug 18 10:47:28 2014] I often suffer of code duplication because of something like "rewrite A; rewrite B; rewrite A in H; rewrite B in H". [Mon Aug 18 10:48:33 2014] And I can't write truly generic tactic which uses rewrite and which I want to use both in goal and hypothesis. [Mon Aug 18 11:02:42 2014] maybe "rewrite A in *" [Mon Aug 18 11:03:45 2014] ijp, no; I mean something like "(rewrite A; rewrite B) in ". [Mon Aug 18 11:04:21 2014] ijp, and if I have tactic like "Ltac do_clever_staff := match ... with .... rewrite ... end" then I can't apply in to hypothesis. [Mon Aug 18 11:04:37 2014] ijp, so I need two versions of tactic: one for goal and one for hypothesis. [Mon Aug 18 18:05:34 2014] Is there a good way to conditionally include a coq_makefile-generated makefile? [Mon Aug 18 18:05:45 2014] or should I just check it in? [Mon Aug 18 18:07:02 2014] The problem is that some of my .v files are generated in fairly expensive ways, but with the output of coq_makefile included into my main makefile, even the clean targets wants to generate them, so it can generate and include .v.d files [Mon Aug 18 18:11:24 2014] you could make the inclusion depend on a Makefile argument [Mon Aug 18 18:11:30 2014] make -DINCLUDE_COQ [Mon Aug 18 18:11:51 2014] I don't check in coq_makefile generated files; I check in a more general Makefile that knows how to make them when needed [Mon Aug 18 18:11:54 2014] the problem is that I need to include the coq_makefile output to get its clean command [Mon Aug 18 18:12:09 2014] then have your clean target depend on Makefile.coq [Mon Aug 18 18:12:10 2014] and that in turn tries to build all the .v.d files, because it includes [Mon Aug 18 18:12:31 2014] I'm going to try invoking the coq_makefile output as a recursive make [Mon Aug 18 18:12:43 2014] example: https://gist.github.com/jwiegley/7b13b9fe219adf7ac5a5 [Mon Aug 18 18:13:09 2014] ah, looks about like what I'm trying [Mon Aug 18 18:13:27 2014] You can also "-include Makefile.coq" at the bottom of your Makefile. [Mon Aug 18 18:13:35 2014] that's what doesn't work right [Mon Aug 18 18:14:01 2014] Basically, I've got expensive.v : \n [Mon Aug 18 18:14:15 2014] Makefile.coq itself ends up doing -include expensive.v.d [Mon Aug 18 18:14:32 2014] so if I ever include Makefile.coq it demands to build expensive.v.d, even if I'm just trying to clean or something [Mon Aug 18 18:17:12 2014] johnw: thanks, that did work out nicely. Just had to make all depend on both coq_makefile.mk and expensive.v, while letting clean depend just on coq_makefile.mk [Mon Aug 18 18:17:24 2014] great! [Mon Aug 18 18:18:46 2014] The only way I know to suppress a include is with a block conditional on a variable [Mon Aug 18 21:37:32 2014] what can I do with an hypothesis of the form H: forall v, P -> Q if I don't have a goal with the form Q? [Mon Aug 18 21:41:55 2014] do you have another hypothesis of the form P? [Mon Aug 18 21:43:04 2014] tautologico: ^^ [Mon Aug 18 21:43:45 2014] I have a theorem of the form P -> R [Mon Aug 18 21:44:07 2014] but no P? [Mon Aug 18 21:44:12 2014] it would be good if I could get to R [Mon Aug 18 21:44:42 2014] no [Mon Aug 18 21:44:51 2014] if you had a P, you could apply H to it, then destruct Q [Mon Aug 18 21:45:03 2014] but without a P, it's not going to be terribly useful [Mon Aug 18 21:45:34 2014] I suppose you could assert Q, apply H, and then see if you can prove P [Mon Aug 18 21:47:25 2014] yeah I think there's something wrong with this hypothesis [Mon Aug 18 21:50:04 2014] this is the last detail in a chain of many theorems... so close yet so far [Mon Aug 18 21:55:51 2014] can you show me what you're seeing now? [Mon Aug 18 21:57:30 2014] basically this [Mon Aug 18 21:57:35 2014] Hfree : forall v' : var, freeIn (\\ t) v' -> v' >= c1 /\ v' >= c2 [Mon Aug 18 21:57:35 2014] ============================ [Mon Aug 18 21:57:35 2014] forall v' : var, freeIn t v' -> v' >= S c1 /\ v' >= S c2 [Mon Aug 18 21:58:15 2014] from freeIn (\\ t) v' I can get freeIn t (S v') [Mon Aug 18 21:58:19 2014] is that even provable? [Mon Aug 18 21:58:25 2014] yeah, I don't think so [Mon Aug 18 21:58:29 2014] knowing that x > y, how can you prove that x > S y? [Mon Aug 18 21:58:40 2014] you'd need some other condition in your context [Mon Aug 18 21:58:49 2014] the v's don't need to be the same [Mon Aug 18 21:59:11 2014] but they'll kind of have to be here [Mon Aug 18 21:59:30 2014] intros; specialize (Hfree v') [Mon Aug 18 21:59:45 2014] there's no other "var" to talk about [Mon Aug 18 22:01:32 2014] yeah [Mon Aug 18 22:06:55 2014] this is from an induction hypothesis, I think I have to reorganize it a bit [Mon Aug 18 22:19:47 2014] can I generalize in an hypothesis? [Tue Aug 19 00:29:03 2014] are there any other Coq extraction backends being developed? Is anyone looking at going straight to LLVM IR, for example? [Tue Aug 19 00:29:17 2014] I see https://github.com/coq-ext-lib/coq-compile [Tue Aug 19 04:06:05 2014] Hi! I've been trying to translate Agda's Parity in coq but I have no idea how to convice it to refine types in pattern match [Tue Aug 19 04:07:03 2014] I've seen a match-as-return-with construct, but I'm honestly not sure if that's even what I want [Tue Aug 19 04:09:51 2014] supki: if you post some broken code I'll take a look [Tue Aug 19 04:14:44 2014] sure [Tue Aug 19 04:14:59 2014] jrw: that's what I have http://lpaste.net/1825874813248339968 [Tue Aug 19 04:15:21 2014] AFAIUI the problem is that the pattern match on parity does not refine the type of n [Tue Aug 19 04:15:59 2014] well, not type [Tue Aug 19 04:18:25 2014] supki: so, one thing is that coq is going to ask you to prove that "S (2 * k) = 2 * k + 1" [Tue Aug 19 04:31:22 2014] supki: http://lpaste.net/109612 [Tue Aug 19 04:31:31 2014] taking a different approach using tactics instead [Tue Aug 19 04:34:18 2014] the second version there is as close as it gets, I'm afraid [Tue Aug 19 04:34:33 2014] with the fancy match in notation + convoy pattern [Tue Aug 19 05:27:12 2014] jrw: thanks, that's something I would never come up with [Tue Aug 19 07:07:09 2014] suppose f: list nat -> list (list nat) [Tue Aug 19 07:07:24 2014] where f simply creates a list of singletons [Tue Aug 19 07:08:22 2014] how can i use sigT to modify f so that it creates a [list {x : list nat & In x (f input_list)}] [Tue Aug 19 07:08:48 2014] if that makes sense? I want Coq to remember where x came from, because im going to be needing that later [Tue Aug 19 07:18:47 2014] what i did so far is create a Definition f' (input_list : list nat) : {x : list nat & In x (f input_list)}. [Tue Aug 19 07:19:42 2014] which gives me as hypothesis input_list : list nat, and as goal list {x : list nat & In x (f input_list)} [Tue Aug 19 07:20:09 2014] my bad the type should be list {... & ...} not just {... & ...} [Tue Aug 19 07:49:37 2014] roosbeef: what would be the output of f' when input_list is nil? [Tue Aug 19 07:49:57 2014] nil :: nil, i guess? [Tue Aug 19 07:50:07 2014] eh, no wait [Tue Aug 19 07:50:36 2014] IIUC, f nil = nil by your specification [Tue Aug 19 07:51:08 2014] yes, f (1 :: 2 :: nil) = (1 :: nil) :: (2 :: nil) :: nil [Tue Aug 19 07:52:08 2014] but im trying to build f' (1 :: 2 :: nil) = {(1 :: nil) & In (1 :: nil) (f' (1 :: 2 :: nil))} :: {(2 :: nil) & In (2 :: nil) (f' (1 :: 2 :: nil))} :: nil [Tue Aug 19 07:52:30 2014] Coq should know where that singleton came from, i need that somewhere in my proof [Tue Aug 19 07:53:10 2014] (im actually using other types, but to simplify the problem lets consider list nat) [Tue Aug 19 08:00:38 2014] is there a tactic to clear a hypothesis and all others that depend on that? [Tue Aug 19 08:01:24 2014] roosbeef: https://paste.debian.net/116339/ [Tue Aug 19 08:02:02 2014] hello. I'm writing some module that must be polymorphic with respect to some types (as I don't know in advance which types will be used). [Tue Aug 19 08:02:07 2014] Inside my module I build "associative list" with cells (nat * that_polymorphic_type), then work with nats (get/put values of polymorphic type from/into this list). [Tue Aug 19 08:02:13 2014] Logic of module doesn't depend on actual type: everything I know (and can guarantee), is that when value of type A was put into list, paired with some n : nat, next "get n" will return value of type A. [Tue Aug 19 08:02:19 2014] So probably I wish to have some "ref A" type, that holds that "n : nat" (ref A will be constructed with some "mkref : A -> assoc_list -> (modified_assoc_list * ref A)"), and allows one to get value of type A with "get : ref A -> assoc_list -> A". [Tue Aug 19 08:02:22 2014] Type A is not fixed, so functor is not a solution. In OCaml I could use dynamic typing via "universal types", but this can't be translated in Coq. Are there any ideas? [Tue Aug 19 08:02:26 2014] :) [Tue Aug 19 08:02:31 2014] after an inversion I'm doing this a lot "clear H4 e0 H2 h0 H6 t0." I'm looking for a shortcut [Tue Aug 19 08:05:16 2014] p.s. heterogeneous lists are an option, but they are heavy-weight for proofs, and I'm not sure it will work at all. [Tue Aug 19 08:05:55 2014] osa1: inversion_clear, maybe? [Tue Aug 19 08:06:54 2014] sgnb: amazing!! I didn't know that tactic, it worked great. thanks! [Tue Aug 19 08:30:59 2014] sgnb: ha nice! Let me have a look at that [Tue Aug 19 08:38:43 2014] sgnb, could you explain in intuitive terms why and how L1 is used? [Tue Aug 19 08:43:48 2014] is there anyway to have a conversion to funclass that starts with implicit arguments? e.g. when i try to change my functor record to auto convert to its action on objects it works fine, but the more interesting usecase is to have it auto-convert to its action on functions, but there it has a member map : ∀ {x y : C}, (x ~> y) → fobj x ~> fobj y [Tue Aug 19 08:44:09 2014] and when i use map :> ∀ {x y : C}, (x ~> y) → fobj x ~> fobj y -- it comes out with the x and y as non-implicit args [Tue Aug 19 08:44:29 2014] as i have no way to write an Arguments statement talking about the extra args you get after implicit conversion I think I'm stuck [Tue Aug 19 08:45:12 2014] i converted 'transport' from hott to be functorial and was able to get everything else to work, but now i have to use map transport instead of transport. [Tue Aug 19 08:45:23 2014] as a sort of concrete motivation [Tue Aug 19 08:45:33 2014] same with map ap [Tue Aug 19 08:51:02 2014] roosbeef: L1 is a kind of "List.map" with a richer function type "forall x, A x -> B x", it is used for casting IHinput_list [Tue Aug 19 08:55:14 2014] so what types are we casting here? [Tue Aug 19 09:12:24 2014] roosbeef: see the call to refine... it is casting IHinput_list's type (list { ... & In x (f input_list) }) into the goal (list { ... & a::nil = x \/ In x (f input_list) }) [Tue Aug 19 09:17:53 2014] hm [Tue Aug 19 09:18:09 2014] dont think i fully understand yet but this seems to be what im looking for, thanks a lot sgnb :) [Tue Aug 19 09:18:22 2014] gotta leave for work [Tue Aug 19 09:18:36 2014] cya [Tue Aug 19 09:23:42 2014] (ignore my question here; asked it in coq-club.) [Tue Aug 19 10:35:05 2014] edwardk: You could do something hacky, like [Tue Aug 19 10:35:05 2014] Set Implicit Arguments. [Tue Aug 19 10:35:05 2014] Record Category := { obj :> Type ; hom :> obj -> obj -> Type }. [Tue Aug 19 10:35:05 2014] Record > PackagedHom (C : Category) := { x : C ; y : C ; unpackage :> C x y }. [Tue Aug 19 10:35:05 2014] Record Functor (C D : Category) := { fobj : C -> D ; map :> forall m : PackagedHom C, D (fobj m.(x)) (fobj m.(y)) }. [Tue Aug 19 10:35:05 2014] Section foo. [Tue Aug 19 10:35:05 2014] Context C D (F : Functor C D) x y (m : C x y). [Tue Aug 19 10:35:05 2014] Check F m. (* F m : D (fobj F (Top.x m)) (fobj F (Top.y m)) *) [Tue Aug 19 10:36:52 2014] hrmm [Tue Aug 19 10:36:56 2014] i might be able to adapt that [Tue Aug 19 10:37:32 2014] e.g. leave map alone, but add a separate packaged hom, write the coercion to it separately so others don't have to see the hack over and over [Tue Aug 19 10:37:39 2014] Actually, I think I have a way to make it work without the intermediate PackagedHom getting in the way. Give me a few minutes. [Tue Aug 19 10:37:40 2014] that would let me use my functorial transport/ap everywhere [Tue Aug 19 10:45:07 2014] what is the Record > PackagedHom syntax above? [Tue Aug 19 10:55:39 2014] hrmm, when i try your trick and use it i get The term "p" has type "x ~{ A }~ y" while it is expected to have type "morphism (Paths ?1370)". -- where my morphism is your PackagedHom [Tue Aug 19 10:56:11 2014] edwardk: It means [Coercion Build_PackagedHom : >-> PackagedHom] [Tue Aug 19 10:56:20 2014] ah [Tue Aug 19 10:57:00 2014] edwardk: First guess: Try turning off primitive projections? Or make a small example displaying that bug and point me at it? (What do you expect it to do?) [Tue Aug 19 10:57:27 2014] I didn't manage to get a nice version without changing the type of [map], but I did find a bug in Coq 8.4: https://coq.inria.fr/bugs/show_bug.cgi?id=3527 [Tue Aug 19 10:58:23 2014] https://github.com/ekmett/homotopy/blob/master/Core.v#L245 [Tue Aug 19 10:58:52 2014] i want to be able to replace use of 'map transports' with 'transports' there [Tue Aug 19 10:59:08 2014] and then eventually to be able to replace all uses of 'transport' with 'transports' [Tue Aug 19 10:59:19 2014] (and then rename that back to transport!) [Tue Aug 19 10:59:25 2014] same with ap vs map aps [Tue Aug 19 10:59:58 2014] the goal is to be able to directly apply my functors and get their action on arrows rather than their action on objects [Tue Aug 19 11:00:06 2014] since the action on arrows is more interesting [Tue Aug 19 11:01:38 2014] this way i can make all the bits of hott that are actually functorial be functorial [Tue Aug 19 11:01:59 2014] right now i have to clutter my code with all sorts of extra 'map' calls [Tue Aug 19 11:02:14 2014] or make helpers that blur away the benefit [Tue Aug 19 11:07:16 2014] hello [Tue Aug 19 11:09:21 2014] i was able to build it by doing something like [Tue Aug 19 11:09:37 2014] Arguments Build_morphism [C x y] f%hom : rename; Program Definition path_morphism {A} {a b: A} (p : paths a b) : morphism (Paths A) := Build_morphism p. [Tue Aug 19 11:10:07 2014] then i can use aps and transports directly on paths [Tue Aug 19 11:11:36 2014] ok, that let me build everything [Tue Aug 19 11:11:56 2014] having really hard time contructing informal proofs - i'm just thinking in coq terms because i never proven anything informally before(really), jumped right into formal proofs. [Tue Aug 19 11:13:12 2014] are ifnormal proofs important or ican just skip on them because i can do formal proofs better? [Tue Aug 19 11:15:50 2014] Ainieco: ultimately proof is about convincing your audience of a fact without wasting their time. proofs vary from audience to audience. to a mathematician with a ton of shared context, often a whiteboard sketch suffices as a proof. to a computer you need to be very explicit [Tue Aug 19 11:17:51 2014] if the goal of a proof is to convey information, then the fact that if you go too far off into a formal proof you can lose your audience (to boredom, confusion, attention limits) should cause you to pause and consider if a more informal proof that leaves a bit more implicit is the right answer to get them convinced of the broad sweeps of your argument [Tue Aug 19 11:20:10 2014] does a match always need to mention all constructors, even if indices rule some out? [Tue Aug 19 11:20:13 2014] edwardk: oh, i got your point, i guess it's fine to develop proofs in formal way to be sure about correctness and then transfer that knowlege in informal way because informal proofs are like comressed formal ones. because it's really hard for me to develop [Tue Aug 19 11:21:02 2014] to develop proofs in informal way from beginning because i often find my self in thingik "rewrite -> here", "apply there". :) [Tue Aug 19 11:21:03 2014] hmm, I have more success with an _ => tt case than I hoped [Tue Aug 19 11:21:20 2014] thinking* [Tue Aug 19 11:21:33 2014] edwardk: The boring parts of the formal proof should be automated away anyway [Tue Aug 19 11:26:14 2014] napping: agreed =) [Tue Aug 19 11:26:55 2014] jgross: anyways, i'm getting more and more happy with the foundational constructions there, now not only are most of the proofs gone but also most of the field definitions. [Tue Aug 19 11:27:09 2014] i'm worrying about such stuff just because SF has "write informal proof for" exercises and i'm really bad at it and wondering if i did something wrong or misunderstood along the way... [Tue Aug 19 11:28:45 2014] Why not separate entirely the goals of giving an informal idea why it might work out, and convincing that it's entirely correct (unless the details of the proof are the point - obstacles carefully avoided, etc.) [Tue Aug 19 11:29:55 2014] For the later, Theorem thm : . Proof. big_hammer_tac. Qed. Print Assumptions thm. seems to be pretty widely respected [Tue Aug 19 11:31:55 2014] napping: i like you definition of infromal proof as just "informal idea why it might work out", in SF examples of informl proofs quite often were 3x larger than formal or at best had the same length... [Tue Aug 19 11:32:51 2014] That's not necessarily the sense of informal proof always [Tue Aug 19 11:33:55 2014] thank you guys for sharing thoughts on topic! [Tue Aug 19 11:34:35 2014] * dives into last bits MoreCoq.v, never been this far [Tue Aug 19 11:41:15 2014] edwardk: You managed to get the coercions working? (Or is https://github.com/ekmett/homotopy/blob/master/Core.v#L245, or some other line, still broke? L245 works for me.) [Tue Aug 19 11:42:04 2014] its working now [Tue Aug 19 11:42:35 2014] if you rewind ~4 commits you get to what i was talking about [Tue Aug 19 11:43:02 2014] https://github.com/ekmett/homotopy/blob/05438d77fa680fbff5c1666b6ed0e4e9df9f38fd/Core.v#L245 [Tue Aug 19 11:43:32 2014] which is fixed in the next patch in by making an explicit case for coercing @paths A to morphism (Path A) [Tue Aug 19 11:43:50 2014] otherwise it doesn't see it [Tue Aug 19 11:44:20 2014] it'll probably never work for functions, but it works fine for paths [Tue Aug 19 11:58:03 2014] Yeah, that's the way to do it. If paths weren't an inductive type, or if Coq were less stupid about identity coercions, you could make path_morphism an identity coercion and then it would never actually show up when it's used. [Tue Aug 19 11:58:55 2014] i've yet to stop and take the time to understand the identity coercion machinery [Tue Aug 19 11:59:13 2014] its phrased somewhat obliquely in the docs and i don't know exactly the kind of problem it solves [Tue Aug 19 12:12:22 2014] It solves the problem where you want to insert a coercion between convertible types, but you don't want the coercion itself (which is just the identity function) to show up in the resulting term. (Unfortunately, it's rather limited, in a very arbitrary way, and while there are hacks to get around some of the limitations, they don't work with inductive types.) [Tue Aug 19 12:13:05 2014] ah [Tue Aug 19 12:15:52 2014] Is there any easy way to write an empty match on a value in an inductive type with impossible values for the indicies [Tue Aug 19 12:16:03 2014] ones that don't even appear to unify with any constructors [Tue Aug 19 12:16:58 2014] match _ => ... end doesn't actually give a match, as far as I can tell [Tue Aug 19 12:17:21 2014] jgross: http://www.lix.polytechnique.fr/coq/bugs/show_bug.cgi?format=multiple&id=3115 being the hack in question? [Tue Aug 19 12:18:31 2014] http://lpaste.net/109626 [Tue Aug 19 12:19:28 2014] with a reflexivity case things are not empty and I can write a somewhat ugly match [Tue Aug 19 12:37:39 2014] is there a better way to write that? [Tue Aug 19 13:04:30 2014] can this be simplified: http://lpaste.net/109626 [Tue Aug 19 14:05:26 2014] How do I add new computation rules to Coq? [Tue Aug 19 14:05:50 2014] is there an extention that lets me easily do this? e.g. if I wanted to axiomatize a data type that isn't strictly positive or something, along with computation rules [Tue Aug 19 14:14:11 2014] Reason: There seems to be one IR definition (Mu) that lets you define any other IR definition via 'codes' that can be defined as a normal inductive type [Tue Aug 19 14:16:21 2014] Actually as a computational rule? [Tue Aug 19 14:16:43 2014] also, is that like a W type? [Tue Aug 19 14:17:28 2014] yes along with computational rules [Tue Aug 19 14:17:51 2014] To make it actually compute I think need to get into O'Caml [Tue Aug 19 14:17:57 2014] I guess it's kind of like a very extreme W type [Tue Aug 19 14:19:45 2014] you can assert equations and rewrite by them, if that's enough [Tue Aug 19 14:20:55 2014] I've lost track of it, but Conor McBride had a blog post about various ways that W types tend to be not canonical enough, is this Mu better? [Tue Aug 19 14:25:39 2014] I dont know what yure referring to sorry [Tue Aug 19 14:25:45 2014] this isnt really like W [Tue Aug 19 14:26:05 2014] https://github.com/spire/spire.github.io/blob/source/source/_code/2014-08-04-inductive-recursive-descriptions/IDescIR.agda this was some of the code [Tue Aug 19 14:26:07 2014] il beb ack later [Tue Aug 19 14:32:28 2014] napping: does that work for 'large' IR as well? [Tue Aug 19 14:32:41 2014] or just small stuff [Tue Aug 19 14:45:59 2014] edwardk: you know as much as I do [Tue Aug 19 14:48:18 2014] I don't see how the Desc type in the linked code would encode a type that was itself inductive-recursive, if that's what you mean [Tue Aug 19 14:49:20 2014] http://spire-lang.org/blog/2014/08/04/inductive-recursive-descriptions/ [Tue Aug 19 14:49:23 2014] there's a blog post about it [Tue Aug 19 14:50:10 2014] This is based on a paper by Dybjer [Tue Aug 19 14:51:10 2014] that sounds pretty nice [Tue Aug 19 14:52:34 2014] certainly it's claimed to have nice properties and be able to encode even large inductive-recursive definitions [Tue Aug 19 14:53:14 2014] i read the paper that covered "small IR" being equivalent to polynomial types, etc. [Tue Aug 19 14:53:36 2014] but if it can do large IR then I can try out some ideas in coq, which'd be nice [Tue Aug 19 14:53:49 2014] I don't know if that encoding flies in Coq [Tue Aug 19 14:54:04 2014] that's what i was afraid of [Tue Aug 19 14:54:16 2014] I guess that explains the original question about extending/axiomatizing it [Tue Aug 19 14:54:18 2014] i tried the one from the small IR paper and smacked into the obvious walls [Tue Aug 19 14:54:23 2014] well, Coq doesn't do induction-recursion in general [Tue Aug 19 14:54:42 2014] napping: sure, the trick was that the small IR paper shows how you can do 'small IR' without IR [Tue Aug 19 14:55:03 2014] hence my question of if this was the same for large IR, which would have been quite surprising to me [Tue Aug 19 14:56:12 2014] ah. No, but it looks like it lets you make a single inductive-recursive definition that then lets you encode others [Tue Aug 19 14:58:52 2014] fair nuff [Tue Aug 19 14:59:28 2014] ok, dumb mac emacs question, i seem to be hitting some key combination recently that causes it to pop up some damned dialog asking if i want to Print buffer Core.v [Tue Aug 19 14:59:32 2014] but i have no way to clear the dialog [Tue Aug 19 14:59:37 2014] this kills my session basically [Tue Aug 19 14:59:43 2014] any idea what i'm hitting [Tue Aug 19 14:59:54 2014] and how the hell i can rebind that thing so i never ever see that stupid dialog again? [Tue Aug 19 15:00:01 2014] maybe it's print-buffer? [Tue Aug 19 15:00:20 2014] that doesn't have a default binding [Tue Aug 19 15:00:24 2014] the main problem is i can't get out of it once i accidentally tap it [Tue Aug 19 15:00:32 2014] so i have no way to save my session, etc. [Tue Aug 19 15:00:37 2014] its _quite_ frustrating [Tue Aug 19 15:00:38 2014] oh, view-lossage is also helpful [Tue Aug 19 15:00:45 2014] or are you just plain stuck? [Tue Aug 19 15:00:48 2014] literally stuck [Tue Aug 19 15:00:49 2014] you can't even close it for a bit? [Tue Aug 19 15:00:52 2014] can't get anything to do anything [Tue Aug 19 15:01:04 2014] huh [Tue Aug 19 15:01:11 2014] clicking on it, just causes it to pop right back [Tue Aug 19 15:01:20 2014] this is now the 3rd time its caused me to stop work [Tue Aug 19 15:01:27 2014] so i'm figuring i should start asking [Tue Aug 19 15:01:41 2014] i'd ask johnw, since he's basically Mr. emacs, but i don't know if he's around. [Tue Aug 19 15:01:48 2014] If you can't see how to do anything, maybe ask in #emacs [Tue Aug 19 15:02:02 2014] If you can't even interact with emacs any more, I don't know what to suggest [Tue Aug 19 15:02:23 2014] i can lose this session if it means i can figure out how to fix it for future sessions [Tue Aug 19 15:02:27 2014] Keep another frame open? [Tue Aug 19 15:02:31 2014] C-g does nothing? [Tue Aug 19 15:02:53 2014] anyway, I certainly don't know enough to recover from that kind of wedged state [Tue Aug 19 15:03:23 2014] I'd suggest view-lossage if you could [Tue Aug 19 15:03:56 2014] can you accept the dialog? [Tue Aug 19 15:04:36 2014] nothing [Tue Aug 19 15:04:51 2014] my proof general session has nothing with "print" in the name with keybindings [Tue Aug 19 15:05:16 2014] except a vc-print-log / vc-print-root-log that are described as listing stuff in a window [Tue Aug 19 15:05:17 2014] i can't get any frame interaction things to happen, new frame, etc. same as everything else, just stuck [Tue Aug 19 15:06:03 2014] Is it a separate dialog window? [Tue Aug 19 15:06:15 2014] might try xkill [Tue Aug 19 15:07:05 2014] well, Coq accepts Desc at least [Tue Aug 19 15:07:19 2014] (after switching Set l to Type) [Tue Aug 19 15:16:18 2014] and El [Tue Aug 19 15:22:52 2014] its running in cocoa mode, so its not under x per se [Tue Aug 19 15:23:15 2014] with universe polymorphism on can you use Type and Type for both? [Tue Aug 19 15:23:20 2014] under trunk? [Tue Aug 19 15:23:30 2014] Does Coq even have universe polymorphism? [Tue Aug 19 15:24:44 2014] yes I think when you write Type it's basically Type[i] for any i - and it maintains an ordering on these indices to ensure consistency [Tue Aug 19 15:25:33 2014] I don't think it's polymorphic in those indices [Tue Aug 19 15:25:38 2014] napping: in trunk, yes [Tue Aug 19 15:26:26 2014] but i don't know what the Set Universe Polymorphism. thing entails [Tue Aug 19 15:26:31 2014] Ah, I'm not following quite that closely [Tue Aug 19 15:52:44 2014] how can I prove e.g Z <> bool? [Tue Aug 19 15:54:00 2014] exists b1, exists b2, exists b3, b1 <> b2 /\ b1 <> b3 /\ b2 <> b3 [Tue Aug 19 15:54:03 2014] is true of Z but not bool [Tue Aug 19 15:54:22 2014] so assume propositional extensionality? [Tue Aug 19 16:06:36 2014] http://stackoverflow.com/questions/12224318/how-to-solve-goals-with-invalid-type-equalities-in-coq [Tue Aug 19 16:06:47 2014] switching to codes was nicer anyway [Tue Aug 19 16:11:54 2014] http://lpaste.net/109648 [Tue Aug 19 16:32:44 2014] jrw: I'm still solving your exercises ;-( [Tue Aug 19 16:32:58 2014] jrw: I have one lemma and main theorem left [Tue Aug 19 16:32:58 2014] osa1: good to hear from you! how's it going? [Tue Aug 19 16:33:09 2014] jrw: not great ;-( let me paste my progress [Tue Aug 19 16:33:58 2014] osa1: sounds good. I'm busy for the next half hour or so, but I'll be happy to take a look after that [Tue Aug 19 16:34:51 2014] jrw: scroll down to see my annotation. sorry for output is a bit noisy because I didn't remove my proof attempts. [Tue Aug 19 16:34:53 2014] http://lpaste.net/109225 [Tue Aug 19 16:35:00 2014] jrw: sure, whenever you're available [Tue Aug 19 16:35:41 2014] ops, I think I forgot to paste some used lemmas [Tue Aug 19 16:37:19 2014] http://lpaste.net/109649 [Tue Aug 19 16:54:37 2014] ok, i'm being an idiot, why am i not getting foo_rect when i define a record foo? [Tue Aug 19 16:54:59 2014] is it in Prop? [Tue Aug 19 16:55:01 2014] no [Tue Aug 19 16:55:09 2014] its just an inductive definition [Tue Aug 19 16:55:12 2014] well [Tue Aug 19 16:55:15 2014] even more boring [Tue Aug 19 16:55:17 2014] just a Record [Tue Aug 19 16:55:46 2014] can you request it yourself? [Tue Aug 19 16:55:48 2014] e.g. Record point := { x : nat; y : nat }. -- i'd expect point_rect to be in scope, no? [Tue Aug 19 16:55:53 2014] how? [Tue Aug 19 16:56:16 2014] point is defined; x is defined; y is defined -- is all i get [Tue Aug 19 16:56:28 2014] "Proof schemes" in the manual, Scheme foo_rect := Induction for foo sort Type. [Tue Aug 19 16:57:09 2014] Also, did you "Check" if it was defined? I'm not sure if stuff you get for free is listed in that sort of message [Tue Aug 19 16:57:43 2014] i tried using it [Tue Aug 19 16:57:57 2014] How did the explicit Scheme request go? [Tue Aug 19 16:58:31 2014] learning about schemes =) [Tue Aug 19 16:59:16 2014] Scheme ident1 := Induction for ident’1 Sort sort1 [Tue Aug 19 16:59:21 2014] that thing works [Tue Aug 19 16:59:27 2014] Scheme point_rect := Induction for point Sort Type. [Tue Aug 19 16:59:42 2014] "Sort sort1"? [Tue Aug 19 16:59:48 2014] that was a mispaste [Tue Aug 19 17:00:02 2014] okay, I worried it was some of this universe polymorphism [Tue Aug 19 17:00:10 2014] does the point_rect work? [Tue Aug 19 17:00:15 2014] it is defined [Tue Aug 19 17:00:16 2014] =) [Tue Aug 19 17:00:21 2014] Huh [Tue Aug 19 17:00:21 2014] and it looks sane [Tue Aug 19 17:01:03 2014] that's odd you didn't get it already, what's the definition:? [Tue Aug 19 17:02:48 2014] point_rect = λ (P : point → Type) (f : ∀ x y : nat, P {| x := x; y := y |}) (p : point), match p as p0 return (P p0) with | {| x := x; y := x0 |} => f x x0 end : ∀ P : point → Type, (∀ x y : nat, P {| x := x; y := y |}) → ∀ p : point, P p [Tue Aug 19 17:03:43 2014] Record point := MkPoint { x := nat; y := nat }. gives me point/point_rect/point_ind/point_rec [Tue Aug 19 17:03:52 2014] it may be a trunk thing? [Tue Aug 19 17:03:57 2014] and puts Point into Prop [Tue Aug 19 17:04:06 2014] Try "Check point" [Tue Aug 19 17:04:07 2014] or maybe its one of the flags i have set? [Tue Aug 19 17:04:20 2014] point : Set [Tue Aug 19 17:04:34 2014] I don't know how my version things it's okay to eliminate a Prop like that [Tue Aug 19 17:04:55 2014] putting it in prop seems weird [Tue Aug 19 17:05:03 2014] wait you have x := nat [Tue Aug 19 17:05:03 2014] oh, I might have the syntax wrong [Tue Aug 19 17:05:06 2014] y := nat [Tue Aug 19 17:05:09 2014] not x : nat [Tue Aug 19 17:05:11 2014] y : nat [Tue Aug 19 17:05:26 2014] yeah [Tue Aug 19 17:05:28 2014] you made a pont be a record that was two definitions both equal to nat, always [Tue Aug 19 17:05:29 2014] I don't know what that means [Tue Aug 19 17:05:30 2014] no content [Tue Aug 19 17:05:42 2014] so of course its a valid prop [Tue Aug 19 17:05:43 2014] =) [Tue Aug 19 17:05:44 2014] okay, that makes a lot more sense. It's in Set now, still getting rect and such [Tue Aug 19 17:06:24 2014] https://github.com/ekmett/homotopy/blob/master/Core.v is the file i'm working on [Tue Aug 19 17:06:47 2014] the one interesting thing i have turned on is -indices-matter [Tue Aug 19 17:07:11 2014] Universe Polymorphism can probably be turned off without effect at this point [Tue Aug 19 17:08:04 2014] but i've never seen a scheme automatically constructed in the entire time i've been working [Tue Aug 19 17:08:33 2014] basically i'm trying to define natural transformations at the moment and to do that i want to say something about how to ap my way to glory through a record type [Tue Aug 19 17:08:56 2014] what are you using from trunk? [Tue Aug 19 17:08:57 2014] but i need to do something 'field by field' or its going to get really repetitive [Tue Aug 19 17:09:13 2014] you may be able to build that without universe polymorphism turned on right now [Tue Aug 19 17:09:33 2014] i'll eventually need universepolymorphism for the category of small categories [Tue Aug 19 17:09:50 2014] or rather the category of infinity groupoids [Tue Aug 19 17:10:30 2014] pretty close at least [Tue Aug 19 17:10:39 2014] is the circle_ind / circle_rect supposed to be special? [Tue Aug 19 17:11:25 2014] i needed 'Set Elimination Schemes' [Tue Aug 19 17:11:44 2014] Is that now off by default? [Tue Aug 19 17:11:47 2014] those can be killed for now, they don't add any value to the current discussion [Tue Aug 19 17:11:54 2014] no idea [Tue Aug 19 17:11:58 2014] but i turned it on and all was good [Tue Aug 19 17:12:06 2014] okay, that and the second Nat and "Private Inductive" were all not supported [Tue Aug 19 17:12:12 2014] maybe from -indices-matter ? [Tue Aug 19 17:12:26 2014] but everything else checks [Tue Aug 19 17:12:28 2014] osa1: looks good. so you're working on find_min_..._correct_succ? [Tue Aug 19 17:13:52 2014] jrw: yes. I can actually prove most part of it but there is one case that occurs twice and I can't prove it. I'm stuck with `member e t` and all I know is `member e (h :: t)` or something like that. [Tue Aug 19 17:14:23 2014] osa1: right. you need to do inversion on the hypothesis 'member e (h :: t)' before you apply the induction hypothesis I think [Tue Aug 19 17:14:36 2014] jrw: I tried different ways but I came across to same goal no matter how I approach [Tue Aug 19 17:14:46 2014] jrw: I tried that too [Tue Aug 19 17:14:52 2014] okay let me see [Tue Aug 19 17:15:13 2014] I don't remember what was problem with that though. let me step through the code one more time. on of the attemps should be that. [Tue Aug 19 17:17:31 2014] ok, guessing indices-matter probably turned off the record eliminators, because of eliminating to prop [Tue Aug 19 17:17:36 2014] osa1: oh, I needed a lemma that it looks like you deleted. find_min_idx_aux_correct_succ_le_min [Tue Aug 19 17:19:51 2014] jrw: I don't think you showed that lemma to me ;-( [Tue Aug 19 17:20:00 2014] oh. hmm. maybe I deleted it :D [Tue Aug 19 17:20:06 2014] jrw: original link http://lpaste.net/109225 [Tue Aug 19 17:20:08 2014] :) [Tue Aug 19 17:20:16 2014] oh wait [Tue Aug 19 17:20:18 2014] it's there [Tue Aug 19 17:20:20 2014] I'm an idiot [Tue Aug 19 17:20:24 2014] hehe [Tue Aug 19 17:20:52 2014] whoever named these lemmas must have been crazy :p [Tue Aug 19 17:21:00 2014] jrw: http://lpaste.net/109660 I was just going to paste you where I stuck when I do inversion on member [Tue Aug 19 17:21:03 2014] heh [Tue Aug 19 17:21:30 2014] okay, yeah, you'll need that lemma there [Tue Aug 19 17:22:01 2014] jrw: awesome! many thanks for help. I'll ping you if I get stuck again. [Tue Aug 19 17:22:35 2014] cool. good luck! [Tue Aug 19 17:23:58 2014] thanks [Tue Aug 19 18:04:24 2014] johnw: around? [Tue Aug 19 18:08:54 2014] jrw: I'm stuck again ;-( http://lpaste.net/109668 [Tue Aug 19 18:13:05 2014] osa1: you'll need to apply the IH to the hypothesis about find_min_idx_aux (after some fiddling) and then use transitivity of <= [Tue Aug 19 18:13:46 2014] nth ... <= h <= m [Tue Aug 19 18:13:50 2014] hm [Tue Aug 19 18:15:39 2014] osa1: btw I think 'inversion eq' is probably not necessary [Tue Aug 19 18:16:10 2014] jrw: it worked! [Tue Aug 19 18:16:18 2014] woohoo [Tue Aug 19 18:16:41 2014] jrw: you're right, removed that part [Tue Aug 19 21:01:15 2014] edwardk: hi [Tue Aug 19 21:01:19 2014] heya [Tue Aug 19 21:01:31 2014] did you need help with Emacs? [Tue Aug 19 21:01:50 2014] some =) [Tue Aug 19 21:01:54 2014] what's up? [Tue Aug 19 21:02:24 2014] weird mac specific nonsense where hitting s-P was causing my emacs to just hang indefinitely in an undismissable dialog box [Tue Aug 19 21:02:38 2014] s = shift? [Tue Aug 19 21:02:48 2014] command [Tue Aug 19 21:02:55 2014] was trying to use actual emacs parlance ;) [Tue Aug 19 21:02:59 2014] M-P [Tue Aug 19 21:03:07 2014] no, not M-P [Tue Aug 19 21:03:10 2014] s-P means "super shift P" actually [Tue Aug 19 21:03:16 2014] the command key, which is super-shift P [Tue Aug 19 21:03:21 2014] whaa? [Tue Aug 19 21:03:35 2014] C-h k and hitting that key report "s-P" at the bottom? [Tue Aug 19 21:03:43 2014] the little thing with the swirly symbol called command. [Tue Aug 19 21:03:45 2014] yes [Tue Aug 19 21:03:48 2014] bizarre [Tue Aug 19 21:03:55 2014] for me that a meta key, as it should be [Tue Aug 19 21:04:06 2014] apparently in the cocoa build we set up it brings in all sorts of fancy mac stuff [Tue Aug 19 21:04:22 2014] meta for me is still hiding under ecape [Tue Aug 19 21:04:27 2014] this is why I like the emacs24Macport build from Nix :) [Tue Aug 19 21:04:33 2014] =P [Tue Aug 19 21:04:36 2014] that's really wrong [Tue Aug 19 21:04:40 2014] you need to make that command key a meta key stat [Tue Aug 19 21:05:00 2014] http://blacka.com/david/2010/01/17/switching-to-cocoa-emacs/ [Tue Aug 19 21:05:02 2014] see "step 1" [Tue Aug 19 21:05:05 2014] anyways that called some ns-print-buffer command [Tue Aug 19 21:05:14 2014] and the way it popped up a dialog or something is probably bugged [Tue Aug 19 21:05:16 2014] yeah, and it's probably waiting on the print to finish or something stupid [Tue Aug 19 21:05:26 2014] well, its got a dialog you can't dismiss [Tue Aug 19 21:05:35 2014] super modal [Tue Aug 19 21:05:54 2014] I just found a new tactics library for Coq that you might be interested in [Tue Aug 19 21:05:55 2014] so i think there's just a bug there, because something else caused emacs to pop up a similar dialog and i couldn't get it off the screen, nothing i could type could do anything [Tue Aug 19 21:06:11 2014] btw- i managed to kill all the uses of inversion [Tue Aug 19 21:06:21 2014] it's called ssreflect, and it pares down the number of tactics you need to think about hugely, by generalizing those few and making them more expressive [Tue Aug 19 21:06:49 2014] I was sold on it by someone turning a 10 line proof i'd written into a 2 line proof with ssreflect [Tue Aug 19 21:06:49 2014] i've heard about ssreflect, but not found a good rundown of how to use it, etc [Tue Aug 19 21:07:31 2014] read this: http://hal.inria.fr/docs/00/97/55/65/PDF/main.pdf [Tue Aug 19 21:07:45 2014] i'm currently digesting/playing around with it [Tue Aug 19 21:08:43 2014] google hangout? [Tue Aug 19 21:09:13 2014] I can for only a little bit [Tue Aug 19 21:09:16 2014] sure [Tue Aug 19 22:57:20 2014] edwardk: Regarding record elims, CHANGES says "The command "Record foo ..." does not generate induction principles (foo_rect, foo_rec, foo_ind) anymore by default (feature wish #2693). A flag "Set/Unset Record Elimination Schemes" allows to change this. The tactic "induction" on a record is now actually doing "destruct"." [Tue Aug 19 22:57:50 2014] jgross: thats perfectly cool, just missed the note [Tue Aug 19 22:57:56 2014] jgross: do you know why that was done? [Tue Aug 19 23:01:11 2014] guessing that the prop version and hott don't play well? [Tue Aug 19 23:01:59 2014] https://coq.inria.fr/bugs/show_bug.cgi?id=2693 says "In particular, induction schemes for records lead to large useless code when extracting via "Extraction Library".". I'm confused by the original report on that page, but this reason makes some amount of sense. [Tue Aug 19 23:02:20 2014] makes sense to me [Tue Aug 19 23:04:19 2014] edwardk: Elims into Prop are fine. It's elims out of prop that can cause trouble. For a while, you could prove False by doing [Set Primitive Projections. Record foo : Prop := { evil : Type }.] and then you'd get an [evil : foo -> Type] and a [build_foo : Type -> Prop] and then you'd have impredicative type. But Matthieu has since fixed that. [Tue Aug 19 23:04:51 2014] fair [Tue Aug 19 23:06:50 2014] jgross: have you ever used ssreflect? [Tue Aug 19 23:13:02 2014] johnw: Yes. I'm working in the same lab as Georges Gonthier this summer, so it's only natrual. Why do you ask? [Wed Aug 20 00:50:05 2014] jgross: I only just discovered it through coq-club, so I'm reading the documentation now; I wondered what your impressions of it were. It looks very nice [Wed Aug 20 01:24:12 2014] johnw: There are some nice things, but it's not super-useful when you automate everything. For not-fully-automated proofs, though, is seems much more well-thought-out and coherent than plain Ltac. [Wed Aug 20 01:27:42 2014] it seems to be constructed very logically [Wed Aug 20 01:27:49 2014] a few generalized parts that fit together nicely [Wed Aug 20 02:02:54 2014] How do I match a term with an output sigma type? Is there a constructor? [Wed Aug 20 02:06:22 2014] I don't fully understand sh1ken, can you clarify? [Wed Aug 20 02:09:18 2014] Let me put it this way: If I have a term of type 'nat' for example, can I cast it to an arbitrary sigma type? [Wed Aug 20 02:09:41 2014] you can use the existsT constructor [Wed Aug 20 02:09:51 2014] you should have to provide it with the nat and the predicate [Wed Aug 20 02:10:53 2014] Oh, I see, no problem. I'm going to check that out. Thanks. [Wed Aug 20 09:41:27 2014] hi, [Wed Aug 20 09:41:55 2014] may i ask a beginnner's question? [Wed Aug 20 09:42:07 2014] http://lpaste.net/109692 [Wed Aug 20 09:42:33 2014] i want to deduce R = square R from the assumption. so what should i do? [Wed Aug 20 09:43:40 2014] hello? [Wed Aug 20 09:44:54 2014] i thought about f_equal tactic, but it doesn't apply to this case. [Wed Aug 20 09:46:12 2014] could anyone give me some hints? [Wed Aug 20 09:58:35 2014] You need functional extensionality. [Wed Aug 20 09:58:52 2014] like what? [Wed Aug 20 09:59:06 2014] and how? [Wed Aug 20 09:59:20 2014] Coq won’t deduce (forall x y, R x y -> square R x y) -> (R = square) by default. [Wed Aug 20 10:00:04 2014] alkabetz: another idea, can i prove this by contradiction? [Wed Aug 20 10:00:17 2014] No. [Wed Aug 20 10:00:31 2014] Your goal cannot be proven from your hypotheses under Coq’s standard axiom set. [Wed Aug 20 10:00:45 2014] You either need to prove a different goal, like [forall x y, R x y -> square R x y] [Wed Aug 20 10:00:51 2014] or you need to import the functional extensionality axiom [Wed Aug 20 10:01:12 2014] hmm... [Wed Aug 20 10:01:14 2014] which allows you to prove your goal from [forall x y, R x y -> square R x y]. [Wed Aug 20 10:01:29 2014] Are you familiar with functional extensionality? [Wed Aug 20 10:01:37 2014] no, i'm new to coq. [Wed Aug 20 10:01:45 2014] Ah, okay. :) [Wed Aug 20 10:02:07 2014] Functional extensionality is the notion that two functions are equal if they both produce equal output for the same input. [Wed Aug 20 10:02:29 2014] why is that an axiom? [Wed Aug 20 10:02:47 2014] Having it built in causes unhappiness with some advanced Coq developments, as I recall. [Wed Aug 20 10:02:50 2014] can't it be deduced from the standard axiom set? [Wed Aug 20 10:02:57 2014] No, it cannot. [Wed Aug 20 10:04:03 2014] Here, hang on, let me find the FAQ about this … [Wed Aug 20 10:04:40 2014] hm, i just thought of the omega-imcompleteness system. [Wed Aug 20 10:04:43 2014] Well, http://coq.inria.fr/cocorico/CoqAndAxioms#Functional_extensionality is the thing I was looking for [Wed Aug 20 10:04:55 2014] Unfortunately, it doesn’t have more info about why it’s optional [Wed Aug 20 10:05:27 2014] ISTR it makes homotopy type theory sad [Wed Aug 20 10:05:32 2014] But also, you might just not want it in general [Wed Aug 20 10:05:43 2014] After all, you can have two functions that both produce the same output for the same input [Wed Aug 20 10:05:52 2014] but one does so more efficiently than the other. [Wed Aug 20 10:06:07 2014] Are two functions equal even if they have radically different running times? [Wed Aug 20 10:06:15 2014] Seems like kind of a philosophical point. [Wed Aug 20 10:06:19 2014] hm, i see.. [Wed Aug 20 10:07:02 2014] so, without the extensionality, can i prove it in other ways? [Wed Aug 20 10:07:04 2014] Anyway, though, if you want functional extensionality, you can [Require Import FunctionalExtensionality], which will get you the axiom [Wed Aug 20 10:07:24 2014] Well, you can prove (forall x y, R x y = square R x y), which is similar but not exactly the same. [Wed Aug 20 10:07:50 2014] (At least, I assume you can. I haven’t actually tried, but it looks possible.) [Wed Aug 20 10:07:51 2014] alkabetz: but this is not provable without that hypothesis. [Wed Aug 20 10:08:50 2014] let me show you the code, http://lpaste.net/109694 [Wed Aug 20 10:09:14 2014] actually 'square' is defined like this: [Wed Aug 20 10:09:14 2014] Inductive square {X: Type} (R: relation X) : relation X := [Wed Aug 20 10:09:14 2014] | sq0 : forall x y z, R x y -> R y z -> square R x z. [Wed Aug 20 10:09:47 2014] so (R = square R) only stands when R is transitive. [Wed Aug 20 10:10:15 2014] Here, let me look at this for a second [Wed Aug 20 10:10:33 2014] alkabetz: thanks a lot! [Wed Aug 20 10:27:38 2014] I’m still working on this; hang tight. [Wed Aug 20 10:28:09 2014] alkabetz: okay, i'm waiting :) [Wed Aug 20 10:30:50 2014] Hmm, should R be reflexive? [Wed Aug 20 10:31:26 2014] actually not necessary isn't it? [Wed Aug 20 10:32:21 2014] I’m not sure; I don’t think I know enough about the underlying math to determine if it is :) [Wed Aug 20 10:32:57 2014] hmm, shall i show you the book i am following? [Wed Aug 20 10:33:32 2014] http://people.umass.edu/klement/imp/imp-a4.pdf [Wed Aug 20 10:33:42 2014] this book, on page 25. [Wed Aug 20 10:34:24 2014] i have proved the reverse, that 'a transitive relation is one [Wed Aug 20 10:34:24 2014] which is implied by its square'. [Wed Aug 20 10:36:20 2014] Have a look at http://lpaste.net/109696#line77. [Wed Aug 20 10:36:32 2014] By switching Coq into classical mode and assuming propositional extensionality, [Wed Aug 20 10:36:41 2014] I’ve managed to get the goals into much nicer looking format. [Wed Aug 20 10:37:18 2014] I’m not sure how Russell would have felt about it, though :) [Wed Aug 20 10:37:29 2014] what is the propositional extensionality here? [Wed Aug 20 10:37:43 2014] It allows you to draw equality between propositions. [Wed Aug 20 10:37:50 2014] okay.. [Wed Aug 20 10:38:01 2014] forall (P Q : Prop), (P <-> Q) -> P = Q. [Wed Aug 20 10:38:14 2014] This is important, because in Coq, a relation has type A -> A -> Prop. [Wed Aug 20 10:38:27 2014] So to equate relations, you need both functional and propositional extensionality. [Wed Aug 20 10:38:47 2014] The [extensionality] tactic uses functional extensionality to introduce [x] and [y] [Wed Aug 20 10:39:19 2014] The [Prop_ext] axiom lets you prove (R x y <-> square R x y) instead of (R x y = square R x y). [Wed Aug 20 10:39:36 2014] I suspect this is closer to Russell’s original intent here, but I haven’t read deeply, so I’m unsure. [Wed Aug 20 10:39:37 2014] i see it. [Wed Aug 20 10:40:26 2014] hmm, i'm yet reading how you get to that :) [Wed Aug 20 10:40:27 2014] I think the larger question that might need to be answered here is, [Wed Aug 20 10:40:34 2014] hm? [Wed Aug 20 10:40:44 2014] ‘What did Russell mean when he said that two relations are equal?’ [Wed Aug 20 10:41:24 2014] Oh, wait, here it is: ‘One relation is said to contain or be implied by another if it holds whenever the other holds.’ [Wed Aug 20 10:41:26 2014] sure, [Wed Aug 20 10:41:36 2014] that's it! [Wed Aug 20 10:42:01 2014] So I think that would be formalized as [Wed Aug 20 10:42:03 2014] so it means i can introduce the propositional extensionality with no problem right? [Wed Aug 20 10:42:09 2014] I don’t think you need to. [Wed Aug 20 10:42:15 2014] I think you should do something like [Wed Aug 20 10:43:09 2014] Definition contains {A} (P Q : relation A) : Prop := forall x y : A, Q x y -> P x y. [Wed Aug 20 10:43:34 2014] hm yup, [Wed Aug 20 10:43:41 2014] and also the implied_by ? [Wed Aug 20 10:44:18 2014] I would just pick one term and stick with it [Wed Aug 20 10:44:23 2014] Either say P is contained by Q [Wed Aug 20 10:44:33 2014] Er, P contains Q [Wed Aug 20 10:44:40 2014] or P is implied by Q [Wed Aug 20 10:44:58 2014] actually i don't really understand why here it uses the conjunction 'or'. [Wed Aug 20 10:45:01 2014] ‘One relation is said to contain or be implied by another if it holds whenever the other holds.’ [Wed Aug 20 10:45:04 2014] in this sentence. [Wed Aug 20 10:45:15 2014] Oh, I think he’s saying that they’re two different terms for the same thing. [Wed Aug 20 10:45:53 2014] so how to express it in math notation? [Wed Aug 20 10:46:32 2014] just as what you previously mentioned right? that definition of 'contains' proposition. [Wed Aug 20 10:46:56 2014] Yep, I think Russell is saying you can also call that ‘is implied by’ instead of ‘contains’ [Wed Aug 20 10:47:10 2014] actually i'm not clear about what this clause means 'if it holds whenever the other holds' [Wed Aug 20 10:47:39 2014] ‘If P holds whenever Q holds’ = ‘Q -> P’ [Wed Aug 20 10:48:11 2014] oh.. [Wed Aug 20 10:48:14 2014] gotcha.. [Wed Aug 20 10:48:17 2014] Russell is implicitly using functional extensionality here, because you really need to quantify over /what/ the relation is holding over. [Wed Aug 20 10:48:28 2014] But you can circumvent that issue by defining your 'contains' predicate nicely. [Wed Aug 20 10:48:49 2014] yes, yes. [Wed Aug 20 10:49:38 2014] Do you feel comfortable proceeding on your own now? [Wed Aug 20 10:49:57 2014] i feel much better now :) [Wed Aug 20 10:50:03 2014] Awesome! Good luck! [Wed Aug 20 10:50:05 2014] thanks, you helped a lot :) [Wed Aug 20 10:50:09 2014] You’re welcome. [Wed Aug 20 10:50:33 2014] This development looks really cool, too – I love seeing mathematical foundations get Coqified like this :) [Wed Aug 20 10:52:29 2014] hm yes～ [Wed Aug 20 10:53:32 2014] alkabetz: btw, can i ask one more question about it? [Wed Aug 20 10:53:41 2014] just ensure if i'm understanding correctly. [Wed Aug 20 10:54:57 2014] So i expressed the statement 'From the definitions it will be seen that a transitive relation is one [Wed Aug 20 10:54:57 2014] which is implied by its square' as 'forall {X} (R: relation X), transitive R <-> (forall x y, square R x y -> R x y).' [Wed Aug 20 10:55:22 2014] is it correct? [Wed Aug 20 11:00:52 2014] That’s the way I interpreted that. [Wed Aug 20 11:01:42 2014] cool :) [Wed Aug 20 12:20:44 2014] hello [Wed Aug 20 12:22:22 2014] could you please give me a little hint on http://lpaste.net/8359810244280320000 ? [Wed Aug 20 12:25:23 2014] Ainieco: what are you stuck on? try doing "simpl in *" and then "destruct (test a) eqn:?." [Wed Aug 20 13:00:07 2014] In a coqtop-session, is there any way to figure out if an axiom has been assumed? I'm familiar with Print Assumptions ident? [Wed Aug 20 13:03:26 2014] That's all I know. [Wed Aug 20 13:06:27 2014] You can use Print Assumptions on a module name too [Wed Aug 20 13:06:45 2014] Aha, thats nice. [Wed Aug 20 13:09:51 2014] Why do you say coqtop specifically? [Wed Aug 20 13:10:03 2014] jrw: proved that, thank you, not sure why did i stumbled on it [Wed Aug 20 13:10:27 2014] Hmm, actually, I would be fine with any of the standard programs. [Wed Aug 20 13:11:11 2014] Well, if you have things in .v files you can do something like coqchk -o on the files, or Print Assumptions on the moduels that came from them, and so on [Wed Aug 20 13:11:21 2014] peterbb: do you want all the assumed axioms or a specific axiom ? [Wed Aug 20 13:11:24 2014] also just plain grepping for admit/Axiom/etc in the source file [Wed Aug 20 13:11:28 2014] elarnon: all [Wed Aug 20 13:11:55 2014] in a single module you can get this information from Print All. [Wed Aug 20 13:12:19 2014] (i.e., in your current module) [Wed Aug 20 13:12:22 2014] cross-module I don't know [Wed Aug 20 13:13:04 2014] Print All do not work cross module. I think coqchk -o looks like the thing. [Wed Aug 20 13:13:30 2014] I doubt you can get a .vo file from a transient coqtop session [Wed Aug 20 13:14:10 2014] but if you have compileable .v files, coqchk is the most comprehensive way to recheck them [Wed Aug 20 13:14:16 2014] jrw: also thanks for nice tricks: "in *" and "eqn:?". [Wed Aug 20 13:14:26 2014] np [Wed Aug 20 13:14:26 2014] yeah [Wed Aug 20 13:14:41 2014] may I tease my current project here? :) http://goto.ucsd.edu:4242/sf/Basics.html#lab23 and http://goto.ucsd.edu:4242/d3tree.html [Wed Aug 20 13:15:56 2014] interesting. A lot of the grey boxes are too short to show any text [Wed Aug 20 13:16:47 2014] napping: which browser? [Wed Aug 20 13:17:17 2014] the firefox in debian stable (iceweasel 24.7) [Wed Aug 20 13:17:29 2014] jrw: by the way, do you know if it's possible to "generalize dependent" multiple things at once? i.e., without hvaing to repeat "generlize dependent" for every variable you want to generalize [Wed Aug 20 13:17:42 2014] afaik, that's not possible, no. [Wed Aug 20 13:17:48 2014] well, after a rewrite it seems to forget the context [Wed Aug 20 13:18:07 2014] yeah a multiple generalize would be cool :( [Wed Aug 20 13:18:13 2014] I guess you can write it yourself... [Wed Aug 20 13:18:16 2014] huh [Wed Aug 20 13:18:28 2014] jrw: okay, thanks for clarifying it for me [Wed Aug 20 13:18:45 2014] yeah, you can probable whip up something hacky at least [Wed Aug 20 13:18:56 2014] using tactic notations, for example [Wed Aug 20 15:12:43 2014] is there a way fold something unfolded back? [Wed Aug 20 15:14:00 2014] Ainieco: what? [Wed Aug 20 15:18:36 2014] sometimes, using the fold tactic [Wed Aug 20 15:18:43 2014] ianjneu: sorry, my term was not actually foldable, just figured that i need to additional lemma to fold it so "fold" didn't worked and i thought that i missused it and decided to ask here. [Wed Aug 20 15:19:14 2014] johnw: yeah, tried that, failed, asked here, figured that i need lemma to fold. sorry [Wed Aug 20 15:19:54 2014] n/p; I rarely can get fold to do anything useful [Wed Aug 20 15:34:09 2014] match doesn't have anything like pattern guards, does it? [Wed Aug 20 15:35:03 2014] er, just plain predicate guards would be enough [Wed Aug 20 15:44:40 2014] hi, [Wed Aug 20 15:44:48 2014] hi shouya [Wed Aug 20 15:44:49 2014] i got stuck, again :( [Wed Aug 20 15:44:53 2014] where? [Wed Aug 20 15:45:01 2014] johnw: wait a second, i show you the code :) [Wed Aug 20 15:45:55 2014] johnw: http://lpaste.net/109716#line136 [Wed Aug 20 15:46:28 2014] i'm unsure if i'm understanding the statement correctly. [Wed Aug 20 15:47:00 2014] the statement on book is shown between line 121 and line 124 in the paste. [Wed Aug 20 15:47:12 2014] I'm afraid this is a bit beyond me just at the moment [Wed Aug 20 15:48:07 2014] hmm, is it so though? [Wed Aug 20 15:48:09 2014] tough [Wed Aug 20 15:48:19 2014] no, but i don't know enough to answer right off [Wed Aug 20 15:48:47 2014] firstly, am i intepreting the statement right? [Wed Aug 20 15:48:54 2014] *interpret [Wed Aug 20 15:49:46 2014] the full text can be found here: http://people.umass.edu/klement/imp/imp.html#page33 [Wed Aug 20 15:50:08 2014] http://lpaste.net/1688314745993560064 could you please give a little hont on that 4 star exercise, i think i did something wrong along the way... [Wed Aug 20 15:50:19 2014] hint* [Wed Aug 20 15:51:48 2014] shouya: looks like you are missing some of the sense [Wed Aug 20 15:51:56 2014] Ainieco: the result will be a whole lot simpler than what you have there [Wed Aug 20 15:52:06 2014] napping: i am mostly afraiding of that XD [Wed Aug 20 15:53:38 2014] Ainieco: you only need an induction and a destruction; the rest is simplification, unfolding and rewriting [Wed Aug 20 15:53:48 2014] no generalization will be necessary [Wed Aug 20 15:53:52 2014] johnw: yeah, i thought that i messed up something along the way [Wed Aug 20 15:53:55 2014] seems like it's some kind of definition that should havea a <-> [Wed Aug 20 15:54:17 2014] "aliorelative" and "contains diversity" seem to be defined as exactly the same thing [Wed Aug 20 15:55:02 2014] A is one which sounds like a definition, except transitive and aliorelative are already defined [Wed Aug 20 15:55:14 2014] Ainieco: if you get too stuck and need to peek at an approach, see https://github.com/jwiegley/software-foundations/blob/master/MoreCoq.v#L1233 [Wed Aug 20 15:55:26 2014] huh [Wed Aug 20 15:55:28 2014] I usually allow myself to read others' solutions after I hit the 8-hours-with-no-progress mark [Wed Aug 20 15:55:39 2014] actually, wasn't transitive defined as containing it's square? [Wed Aug 20 15:55:41 2014] napping: i'm actually not very sure what it means 'in diversity' here. [Wed Aug 20 15:55:55 2014] napping: yes i think so. [Wed Aug 20 15:56:01 2014] reading farther up the book, it seems to be defined as a synonym for aliorelative [Wed Aug 20 15:56:19 2014] so I think the bit you are trying to translated is either vacuous, or just unfolding definitions [Wed Aug 20 15:56:22 2014] so what is meant by 'A transitive aliorelative'? [Wed Aug 20 15:56:37 2014] I presume a relation that's transitive and "aliorelative" [Wed Aug 20 15:56:47 2014] The bit with content seems to be the second part [Wed Aug 20 15:57:02 2014] transitivie R -> (asymmetric R <-> aliorelative R) [Wed Aug 20 15:57:14 2014] hmm... [Wed Aug 20 15:57:47 2014] Or diversity is the inequality relation, that makes sense too [Wed Aug 20 15:58:00 2014] writing R x y -> x <> y instead of just ~(R x x) [Wed Aug 20 15:58:41 2014] pardon me, i still didn't get the point? [Wed Aug 20 15:59:59 2014] well, if aliorelative is defined as "implies diversity", and transitive as "contains it's square" [Wed Aug 20 16:00:16 2014] saying a transitive aliorelative is a relation that implies diversity and is contained in it's square isn't saying much [Wed Aug 20 16:00:18 2014] hm? [Wed Aug 20 16:01:02 2014] please wait a second, i need time to digest what you said :) [Wed Aug 20 16:02:12 2014] okay. [Wed Aug 20 16:03:14 2014] So you could prove that bit as a lemma if you really want, but it's probably just something like "unfold transitive, aliorelative; tauto" [Wed Aug 20 16:03:37 2014] The second part of the quote seems to be making a claim that might actually be interesting to prove [Wed Aug 20 16:03:40 2014] a small question. [Wed Aug 20 16:04:07 2014] what's the difference between 'R x y -> x <> y' and '~(R x x)' [Wed Aug 20 16:04:27 2014] not a whole lot [Wed Aug 20 16:04:29 2014] i interpret them the same thing actually.. [Wed Aug 20 16:04:50 2014] but forall x y, R x y -> G x y is how you would write relation R being contained in relation G [Wed Aug 20 16:05:18 2014] yup, so? [Wed Aug 20 16:05:23 2014] so if you want to read "in diversity" as actually talking about relation containment rather than just being a set phrase [Wed Aug 20 16:05:47 2014] You might prefer to define aliorelative in the R x y -> x <> y way that looks like relation containment [Wed Aug 20 16:06:43 2014] oh yup. [Wed Aug 20 16:06:57 2014] johnw: thanks! [Wed Aug 20 16:07:07 2014] it's shown the previous page... [Wed Aug 20 16:07:15 2014] and also then "diversity" itself makes sense as the x <> y relation [Wed Aug 20 16:08:24 2014] hm... [Wed Aug 20 16:09:08 2014] so can i understand 'in diversity' as a property of a relation? [Wed Aug 20 16:09:39 2014] it seems to be used that way a lot, just as an alternative to "aliorelative" [Wed Aug 20 16:09:53 2014] but you can also understand it as actually saying the relation is contained in the relation "diversity" [Wed Aug 20 16:09:54 2014] okay, [Wed Aug 20 16:10:38 2014] so can i regard the aliorelative as '~(R x x)' and diversity as 'R x y -> x <> y' ? [Wed Aug 20 16:10:55 2014] they're practically same but expressed in different fashions. [Wed Aug 20 16:11:05 2014] I'd say diversity {A} : relation A := fun x y => x <> y. [Wed Aug 20 16:11:30 2014] then maybe prove aliorelative R <-> subrelation R diversity [Wed Aug 20 16:11:41 2014] hm, [Wed Aug 20 16:12:35 2014] so i'd prove this first and will it help to my current goal? [Wed Aug 20 16:12:46 2014] actually i don't have much intuition on that. [Wed Aug 20 16:12:58 2014] what's the current goal? [Wed Aug 20 16:13:34 2014] transitive R -> aliorelative R -> contains R (square R). [Wed Aug 20 16:13:59 2014] if i replace aliorelative with diversity will it be simpler? [Wed Aug 20 16:14:02 2014] you should be able to drop aliorelative entirely [Wed Aug 20 16:14:19 2014] to drop it? why? [Wed Aug 20 16:14:27 2014] why do you need it? [Wed Aug 20 16:14:36 2014] Isn't transitive already defined as containing it's own square? [Wed Aug 20 16:15:06 2014] hm yes, it is though. [Wed Aug 20 16:15:26 2014] my square is defined like this: [Wed Aug 20 16:15:28 2014] Inductive square {X: Type} (R: relation X) : relation X := [Wed Aug 20 16:15:28 2014] | sq0 : forall x y z, R x y -> R y z -> square R x z. [Wed Aug 20 16:16:10 2014] and transitive is defined like 'forall x y z, R x y -> R y z -> R x z.' [Wed Aug 20 16:17:02 2014] should i replace the transitive's definition to indicate clearly as that the relation that contains its own square? [Wed Aug 20 16:17:17 2014] you should be able to prove it if you want [Wed Aug 20 16:17:30 2014] that's probably the transitive you want, anyway [Wed Aug 20 16:17:47 2014] maye redefine square R x z = exists y, R x y /\ R y z [Wed Aug 20 16:18:05 2014] hm, yup. [Wed Aug 20 16:18:43 2014] i would try what you said out :) thank you! i [Wed Aug 20 16:18:54 2014] i'll be back if i get stuck again :) [Wed Aug 20 23:38:37 2014] is Coq pronouced "cock" or "coke" ? [Wed Aug 20 23:38:52 2014] depends on the nationality of the person you ask [Wed Aug 20 23:39:08 2014] a french person says it somewhere in between cock and coke [Wed Aug 20 23:39:31 2014] everyone I know who isn't french says cock [Wed Aug 20 23:51:28 2014] johnw: noted, thanks [Thu Aug 21 00:45:58 2014] yeah it sounds closer to cock [Thu Aug 21 00:46:25 2014] but the "o" is not exactly the English one [Thu Aug 21 00:48:11 2014] kinda like in "solo" [Thu Aug 21 01:00:04 2014] i'm really liking ssreflect [Thu Aug 21 02:49:14 2014] hi, folks. for the statement 'The “R-posterity” of x is all the terms of which x is an R-ancestor', what should be the type of r_posterity? [Thu Aug 21 02:50:09 2014] does 'all terms' implies a Set? [Thu Aug 21 02:52:44 2014] or i should define a Type? [Thu Aug 21 02:53:58 2014] and how should i define r_posterity. [Thu Aug 21 03:02:46 2014] shouya: I would do that as a relation between x and its R-posteriors. [Thu Aug 21 03:03:13 2014] oh I see, that's already what R-ancestor is. [Thu Aug 21 03:03:15 2014] hmm. [Thu Aug 21 03:04:05 2014] what do you want to prove about R-posterity? you can always define it as a sigma: {y : A | y is an R-ancestor of x} [Thu Aug 21 03:04:08 2014] jrw: like this? Definition r_posterity {X} (R : relation X) (x : X) : X -> Prop := [Thu Aug 21 03:04:08 2014] fun y => r_ancestor R y x. [Thu Aug 21 03:04:30 2014] well yeah but that's just the same thing as r_ancestor, no? [Thu Aug 21 03:04:46 2014] yup.. [Thu Aug 21 03:05:17 2014] or i should just leave it utill i need to prove other theorems related to it? [Thu Aug 21 03:05:42 2014] shouya: you can always rephrase any theorem about R-posterity to a statement about all ancestors of x [Thu Aug 21 03:05:57 2014] hm yup. [Thu Aug 21 03:06:10 2014] if you want a type for it, you can use a sigma, like I said. [Thu Aug 21 03:06:19 2014] I would lean toward not doing that though. [Thu Aug 21 03:06:28 2014] does sigma have a built in syntax? [Thu Aug 21 03:06:29 2014] just for convenience [Thu Aug 21 03:07:12 2014] shouya: yeah. {x | P x} [Thu Aug 21 03:07:19 2014] cool. [Thu Aug 21 03:07:50 2014] since now i'm just following the book to formalize all such definitions. [Thu Aug 21 03:09:03 2014] i just did what you said. thank you jrw :) [Thu Aug 21 03:10:48 2014] np [Thu Aug 21 12:37:46 2014] hello [Thu Aug 21 12:38:01 2014] wow, finally made through MoreCoq [Thu Aug 21 12:39:23 2014] johnw: failed at proving existsb = existsb' because existsb was ill defined - for some reason it had forallb in definition http://lpaste.net/1688314745993560064 [Thu Aug 21 12:39:35 2014] otherwise it's really easy [Thu Aug 21 12:39:52 2014] took me quite a lot of time to spot that silly mistake [Thu Aug 21 13:37:22 2014] Ainieco: what is MoreCoq? Set of exercises? [Thu Aug 21 13:38:07 2014] it is a chapter of software foundation [Thu Aug 21 13:39:16 2014] The Benjamin Pierce et al one? [Thu Aug 21 13:40:15 2014] yep [Thu Aug 21 13:40:59 2014] Just started reading up on coq today for school and have been looking at the "Basics" chapter of that. [Thu Aug 21 14:03:41 2014] mads-: what kind of school is that where they teaching you a coq? [Thu Aug 21 14:09:45 2014] Ainieco: Computer Science at University. [Thu Aug 21 14:09:56 2014] It's introduction to functional programming [Thu Aug 21 14:12:43 2014] I actually thought it was mostly used academically. [Thu Aug 21 14:21:14 2014] mads-: ah, it's uni afterall, thought that you meant school as high scool [Thu Aug 21 14:31:48 2014] johnw: just curious, how much time it took you to complete sf? [Thu Aug 21 15:49:12 2014] Hi. To practice using Ltac, I tried to prove an Equivalence property with a tactic that worked for all three subproperties. This tactic introduces everything there is to introduce and then tries to use induction on one element and destruct on all the others. My problem is that I don't know which lists are the tails of original lists and which are not so my tactic keeps destructing tails of tails of .. of tails of the original lists a [Thu Aug 21 15:51:32 2014] I think that could be fixed by adding a boolean to each list when introducing them and then removing it once I have destructed it but that sounds ugly. Is there an elegant way of marking some hypotheses to remember that they have been generated? Thank you in advance for your answers. [Thu Aug 21 15:51:59 2014] xavierm02: the end of your first message got eaten by the size limit on IRC messages ; it ends at "tails of tails of .. of tails of the original lists a" [Thu Aug 21 15:52:55 2014] Hi. To practice using Ltac, I tried to prove an Equivalence property with a tactic that worked for all three subproperties. This tactic introduces everything there is to introduce and then tries to use induction on one element and destruct on all the others. [Thu Aug 21 15:52:58 2014] Ltac is rarely elegant, by the way [Thu Aug 21 15:53:00 2014] My problem is that I don't know which lists are the tails of original lists and which are not so my tactic keeps destructing tails of tails of .. of tails of the original lists and never stops. [Thu Aug 21 15:53:12 2014] did you get it all this time? [Thu Aug 21 15:53:29 2014] yes, only a few chars were missing [Thu Aug 21 15:53:42 2014] do you have the code for your tactics somewhere? [Thu Aug 21 15:55:09 2014] the problematic part is: [Thu Aug 21 15:55:11 2014] Ltac qwe := repeat match goal with [ l : list A |- _ ] => destruct l end. [Thu Aug 21 15:55:45 2014] I only want to destruct the original lists but I end up destructing the tails so i get in an infinite loop [Thu Aug 21 16:00:27 2014] One way of doing that would be to "cache" the current goal and keep matching it instead of the new goal. But that doesn't seem to work: Ltac qwe := let g := goal in repeat match g with | [ l : list A |- _ ] => destruct l end. (I get an error because that's not the kind of match it expects) [Thu Aug 21 16:00:41 2014] so hm, one solution is to match on a big enough number of lists and then decreases [Thu Aug 21 16:01:01 2014] hi elarnon! [Thu Aug 21 16:01:05 2014] i.e match goal with [ l1: list A, l2 : list A, ..., ln : list A ] => ... | ... => ... end [Thu Aug 21 16:01:23 2014] that's very ugly, but i am afraid i have seen similar code in a couple of places [Thu Aug 21 16:01:32 2014] hi johnw! [Thu Aug 21 16:01:55 2014] how are you doing? [Thu Aug 21 16:02:02 2014] doing well, just awaking from a long night [Thu Aug 21 16:02:06 2014] how are things over in France? [Thu Aug 21 16:02:15 2014] I forget whether I'm going to be seeing you at ICFP or not? [Thu Aug 21 16:02:16 2014] well, night is just starting here [Thu Aug 21 16:02:25 2014] unfortunately no [Thu Aug 21 16:02:30 2014] that is too bad!! [Thu Aug 21 16:02:52 2014] elarnon: do you use SSReflect? [Thu Aug 21 16:03:14 2014] i happen to have an oral exam for my internship during icfp [Thu Aug 21 16:03:23 2014] ahh [Thu Aug 21 16:03:35 2014] i would probably use ssreflect if i was using coq seriously [Thu Aug 21 16:04:03 2014] but i have never gotten the time and motivation to get into it [Thu Aug 21 16:04:54 2014] ah, ok [Thu Aug 21 16:05:05 2014] i finished reading its manual last night, and it's very interesting [Thu Aug 21 16:05:30 2014] you only need to keep a few small number of tactics in mind, but they are much more flexible. so it's both simpler and more complex and the same time [Thu Aug 21 16:05:52 2014] but the pattern matching facility along is pretty wicked [Thu Aug 21 16:06:35 2014] oh, they have improved pattern-matching? [Thu Aug 21 16:06:51 2014] yeah [Thu Aug 21 16:07:07 2014] you can say things like: rewrite: [RHS]plus_S_n [Thu Aug 21 16:07:20 2014] or rewrite: [in X in (_ + X) = _]plus_S_n [Thu Aug 21 16:07:38 2014] oh, that looks nice indeed [Thu Aug 21 16:07:41 2014] so instead of just numeric indices that could change, you describe the exact sub-piece you want the rewrite to apply to [Thu Aug 21 16:07:55 2014] reminds me of pvs's matching facilities [Thu Aug 21 16:09:18 2014] elarnon : Ok so no elegant way :( | Thank you for answering :) [Thu Aug 21 16:09:33 2014] xavierm02: no elegant way that i know of at least [Thu Aug 21 16:09:42 2014] maybe ssreflect would have one ;-) [Thu Aug 21 16:10:16 2014] oh well there is something else you should be able to use [Thu Aug 21 16:10:39 2014] let me check something real quick [Thu Aug 21 16:12:42 2014] hello. rewrite tells me "Found no subterm matching "if ?2156 ?2155 ?2155 then ?2157 else ?2158" in the current goal.", indeed, goal has "if then .. else .. as .. return .." (seems it's an invalid construction for Coq parser). [Thu Aug 21 16:12:45 2014] destruct gives "Abstracting over the term "s" leads to a term .. which is ill-typed". Whole development is large enough to show it, so my question: what does your intuition say about these errors? [Thu Aug 21 16:13:52 2014] it sounds like you're doing dependent matches. [Thu Aug 21 16:16:04 2014] xavierm02: try using case_eq instead of destruct and using the generated equality as guards [Thu Aug 21 16:16:11 2014] jrw: right! And how to prove things about them? [Thu Aug 21 16:16:20 2014] gdsfh: you may want to use the "refine" tactic [Thu Aug 21 16:16:25 2014] I had that Abstracting error! [Thu Aug 21 16:16:28 2014] s/had/hate [Thu Aug 21 16:16:52 2014] edwardk: ping [Thu Aug 21 16:16:59 2014] yo [Thu Aug 21 16:17:14 2014] remember how we were looking and looking for a way to say "break this record up and give me goals for matching each member?" [Thu Aug 21 16:17:19 2014] yeah [Thu Aug 21 16:17:37 2014] I think it's called "injection". In either case, ssreflect's "case" tactics does exactly that when used in its defective mode. [Thu Aug 21 16:17:38 2014] gdsfh: have you heard of dependent destruction? [Thu Aug 21 16:17:38 2014] johnw: term that i'm trying to rewrite into is big for copypasting into proof. [Thu Aug 21 16:17:57 2014] yeah, i don't think that is admissable in the world i'm working in [Thu Aug 21 16:17:58 2014] jrw: yes, will try it now. [Thu Aug 21 16:17:59 2014] gdsfh: use _ with refine [Thu Aug 21 16:18:12 2014] edwardk: either way, ssreflect only works with the current 8.4 release [Thu Aug 21 16:18:25 2014] edwardk: which I've switched back to for working on software foundation [Thu Aug 21 16:18:32 2014] johnw: good idea too, will try it too. [Thu Aug 21 16:18:41 2014] edwardk: the "clearing my goals buffer constantly" bug was slowing me down way too much [Thu Aug 21 16:19:00 2014] yeah unfortunately i'm stuck here because i need the bug fixes [Thu Aug 21 16:19:16 2014] yeah, and I need to use HEAD to use universe polymorphism [Thu Aug 21 16:19:23 2014] so I just keep them both installed in different Nix environments [Thu Aug 21 16:19:43 2014] I run "load-env-coqHEAD" to drop into a shell where coqc is the HEAD version [Thu Aug 21 16:20:23 2014] go ahead rub in your perfect little nix environment some more ;) [Thu Aug 21 16:20:46 2014] I've found the best way to Ed's heart is iterative reminders of better things on the other side of the fence :) [Thu Aug 21 16:20:51 2014] i may have to quiz you for some emacs/coq/proof general set up help in a bit [Thu Aug 21 16:21:00 2014] edwardk: cool, I'm not grumpy today :) [Thu Aug 21 16:21:05 2014] hah [Thu Aug 21 16:24:03 2014] ready when you are [Thu Aug 21 16:38:46 2014] elarnon : I tried matching the goal for a list "l" and then doing nothing if I detect and hypothesis "l = _" but since it always tries to match the same one, it just destructs the first one and then stops :/ [Thu Aug 21 16:46:18 2014] jrw: dependent destruction is allowed only on hypothesis, but I have an expression. "set (Q := ). dependent destruction Q." hadn't destructed in goal. It gave me equation for " = .." however, but rewriting this equation fails again, "abstracting .. ill-typed". [Thu Aug 21 16:46:25 2014] xavierm02: try something like [repeat match goal with [ l: list nat |- _ ] => lazymatch goal with [ _: _ = (_::l)%list |- _ ] => fail | [ _: l = _ |- _ ] => fail | _ => destruct l end end] [Thu Aug 21 16:47:06 2014] (lazymatch does the same thing as match but commits to its choice once a matching branch is found and do not backtrack) [Thu Aug 21 16:48:18 2014] and replace destruct by case_eq, obviously [Thu Aug 21 16:50:11 2014] gdsfh: if you don't mind assuming things about JMeq, you can use dep_destruct from cpdt which allows destructing on expressions. [Thu Aug 21 16:50:25 2014] [case_eq q; intros] even [Thu Aug 21 16:52:51 2014] johnw: no success with refine: I have a goal "match (if .. return ..) with | ...end eq_refl = v", so what should I write under refine, "eq_refl _"? It fails, as types doesn't match, type of first expression (match) is a complex one. [Thu Aug 21 16:53:45 2014] jrw: I'll read about dep_destruct; however maybe you know some hints on how to reformulate my terms to avoid JMeq and complex proofs at all? [Thu Aug 21 16:55:12 2014] gdsfh: short, snarky, not-quite-true answer: don't use dependent types in your programs. [Thu Aug 21 16:55:42 2014] gdsfh: longer answer: if you explain what you're trying to do to me, I might be able to give some idea about how to reformulate it. [Thu Aug 21 16:56:24 2014] gdsfh: can you paste me the whole context/goal? [Thu Aug 21 17:04:34 2014] johnw: from what edward said, I reckon you know a little about emacs/coq/proof general. I'm a vim guy myself. Is proof general just an emacs plugin? Should I just use that one-liner, (load-file ....), and nothing else to use proof general with emacs? The folder contains a Makefile and such [Thu Aug 21 17:05:47 2014] And does emacs with proof general hold any advantages over the coqide? [Thu Aug 21 17:06:25 2014] johnw: http://pastebin.com/32NWGPHk , The Expression I Want To Destruct is "kdec ref_raddr ref_raddr" (line 45). It must be equal to "left _". I swear! :) [Thu Aug 21 17:06:53 2014] mads-: it's much better than coqide says everyone I know who has ever tried both [Thu Aug 21 17:07:35 2014] gdsfh: ah, hm.... [Thu Aug 21 17:07:36 2014] mads-: proof general is great. It's just an emacs plugin, yes, but a lot of distros offer a "proofgeneral" package. [Thu Aug 21 17:08:49 2014] chirpsalot: I just downloaded it. It seems easy enough to activate. Though I haven't tried it yet. [Thu Aug 21 17:09:05 2014] mads-: there are some vim plugins, but I don't know how mature any of them are (I suspect not very): http://www.vim.org/scripts/script_search_results.php?keywords=coq&script_type=&order_by=rating&direction=descending&search=search [Thu Aug 21 17:11:39 2014] gdsfh: if you want to plow ahead with your current approach, I suggest dep_destruct. what kind of project is this a part of? [Thu Aug 21 17:12:47 2014] jrw: it's about proving some imperative things. my own silly project. and i can reimplement anything in it. [Thu Aug 21 17:12:51 2014] chirpsalot: I'm a "the right tool for the job" kind of guy. So if emacs and proof general is what everybody else is using I might as well just use that as well. [Thu Aug 21 17:13:15 2014] gdsfh: sounds cool. if you don't mind sharing the whole codebase publicly, I'd be interested to have a look. [Thu Aug 21 17:13:16 2014] I can't imagine that learning a few emacs hotkeys is going to kill me :) [Thu Aug 21 17:14:12 2014] mads-, http://i.imgur.com/P1i1WoA.png [Thu Aug 21 17:14:42 2014] vanila: I might be wrong, though :) [Thu Aug 21 17:14:57 2014] vanila: what is that PNG supposed to mean? [Thu Aug 21 17:15:04 2014] elarnon : It does work. Thank you very much :) | I had to idea you could return fail to send the match to the next thing. That's really cool :) [Thu Aug 21 17:15:56 2014] it's RMS Matthew Stallman after using emacs too long [Thu Aug 21 17:17:01 2014] … i like that nickname [Thu Aug 21 17:17:37 2014] mads-: might kill your pinky ;). [Thu Aug 21 17:18:15 2014] im just kiding but good reminder to take regular breaks, especially because interactive proof is addictive [Thu Aug 21 17:18:23 2014] xavierm02: you're welcome, glad to have been of help even though my initial answer was negative :-) [Thu Aug 21 17:18:41 2014] mads-: but, yeah, it should be fine. Just it'd be nice if you could stick to your editor of choice. [Thu Aug 21 17:19:15 2014] * is an emacs user anyway. [Thu Aug 21 17:19:29 2014] (taking regular breaks may even help you finding proofs faster) [Thu Aug 21 17:19:41 2014] true elarnon :) [Thu Aug 21 17:20:07 2014] elarnon: by setting auto's depth to a higher value when taking a break ;)? [Thu Aug 21 17:20:44 2014] jrw: dep_destruct (copypasted from ..): "In nested Ltac calls to "dep_destruct" and "remember E as x" (expanded to "remember (kdec ref_raddr ref_raddr) as x"), last call failed. Error: The correctness of the conclusion relies on the body of x". [Thu Aug 21 17:20:53 2014] jrw: It's not a cool project, as there exist CFML, "Prop-enriched State monad", Ynot and other really cool stuff. It's just my self-education, and moreover nothing works yet. However I'll share it now. [Thu Aug 21 17:21:21 2014] chirpsalot: by clear brain. [Thu Aug 21 17:21:41 2014] Actually, I kind of want proof general / coq to do that. Put some low priority coq process with auto running in the background with a very high search depth for the current proof. Race the computer! [Thu Aug 21 17:22:10 2014] Of course it won't always solve it -- probably in most cases? I haven't messed with auto much. [Thu Aug 21 17:22:30 2014] a problem with that approache involves really long proof re-run and is probably not that efficient anyway [Thu Aug 21 17:22:50 2014] unless your goal is really huge, that is [Thu Aug 21 17:23:15 2014] elarnon: yeah. Can you save whatever path auto finds if successful, though? [Thu Aug 21 17:23:31 2014] i'm not sure you can, and i'm not sure it is a good idea [Thu Aug 21 17:24:16 2014] mainly 'cause of the whole thing where sometimes the theorem statement changes, or the way Coq introduces named variables changes [Thu Aug 21 17:24:47 2014] wait no that last one doesn't matter [Thu Aug 21 17:25:50 2014] elarnon: it would be less than ideal. Probably long and gross looking, but it might be useful if you don't really care :P. [Thu Aug 21 17:25:58 2014] What do you mean by the first bit? [Thu Aug 21 17:27:26 2014] well if you save an exact proof term you have no modularity at all and it becomes hard to change the theorem statement during development, or if a new constructor is added to an inductive, etc. [Thu Aug 21 17:28:00 2014] if your databases are done well, auto should be able to correctly select them after-the-fact and maybe generate a faster script [Thu Aug 21 17:28:01 2014] Wouldn't that affect a "normal" proof too? [Thu Aug 21 17:28:17 2014] it depends how much automation your proof has [Thu Aug 21 17:28:40 2014] jrw: as for sharing, do you prefer mercurial or git? [Thu Aug 21 17:28:42 2014] maybe calling your long-to-finish [auto] tactic would work again, but then you would need to save both proof scripts in some way [Thu Aug 21 17:29:58 2014] elarnon: http://stackoverflow.com/questions/14917318/verbose-auto-in-coq [Thu Aug 21 17:30:57 2014] Hmmm. [Thu Aug 21 17:31:11 2014] Damn, I need to get back on my Coq-game tonight. [Thu Aug 21 17:31:28 2014] info is broken in 8.4 afaik [Thu Aug 21 17:31:55 2014] what i am trying to say is that storing an exact proof-term is really fragile [Thu Aug 21 17:32:17 2014] elarnon: ah, I guess I can understand that. [Thu Aug 21 17:32:25 2014] Don't really know how proof-terms work at the moment. [Thu Aug 21 17:32:31 2014] does anyone know of any way to ever get a structured term out of coqtop? [Thu Aug 21 17:33:45 2014] Print term. [Thu Aug 21 17:33:49 2014] chirpsalot: they are literally the term that you could write in coq when not using the tactics language [Thu Aug 21 17:34:25 2014] or when you use the [exact] tactic, if you do so [Thu Aug 21 17:34:45 2014] chirpsalot, every proof is done by exhibiting a lambda calculus term -- but Coq lets you build very large complex lambda terms behind the scenes using tactics [Thu Aug 21 17:35:29 2014] for example intro x. just starts a lambda abstraction fun x => _ [Thu Aug 21 17:36:04 2014] vanila: I meant, get a structured term, not a string [Thu Aug 21 17:36:37 2014] vanila: oh, huh. That's exactly how I was thinking of making a proof assistant the other day. [Thu Aug 21 17:36:55 2014] Ptival: what is a structured term? you want an AST? [Thu Aug 21 17:37:07 2014] elarnon: yes [Thu Aug 21 17:37:09 2014] great minds think alike! [Thu Aug 21 17:37:33 2014] vanila: but, uh... Are the coq terms technically Turing complete, then? And Coq just doesn't let you construct a TC subset of them? [Thu Aug 21 17:38:23 2014] coq only lets you construct well-typed terms [Thu Aug 21 17:38:47 2014] and its type systems ensures some strong properties such as termination [Thu Aug 21 17:38:47 2014] And it can only be well-typed if it terminates? [Thu Aug 21 17:38:51 2014] chirpsalot, Coq is strongly normalizing, it's subturing [Thu Aug 21 17:39:06 2014] this is essential because it has to do reduction during type-checking [Thu Aug 21 17:39:22 2014] it would also probably let you prove false if it could do general recursion [Thu Aug 21 17:39:31 2014] vanila: yeah. [Thu Aug 21 17:39:36 2014] but what's great is that Coq can still express turing equivalent languages [Thu Aug 21 17:39:58 2014] like you can make a data type for lambda calculus and express beta reduction as a relation rather than a function, if you want to prove stuf about it [Thu Aug 21 17:39:58 2014] Just with "n steps"? [Thu Aug 21 17:40:03 2014] Ptival: you may want to use the -xml option to coqtop [Thu Aug 21 17:40:11 2014] johnw, edwardk: injection and case both work on hypotheses; I thought you wanted to work on goals? (Did you manage to figure out what I was trying to say with classifying the path space of your record type?) [Thu Aug 21 17:40:20 2014] that's another way! [Thu Aug 21 17:40:29 2014] jgross: ah [Thu Aug 21 17:40:38 2014] jgross: i think ssreflect's "case" works on the goal [Thu Aug 21 17:40:46 2014] elarnon: so far I was using -ideslave, but it still is annoying to get everything as a string, I don't want to parse Coq terms [Thu Aug 21 17:41:01 2014] but I could be wrong [Thu Aug 21 17:41:09 2014] will look into -xml... [Thu Aug 21 17:42:15 2014] johnw: ssreflect in trunk: Enrico said on coq-club: """On Thu, Jul 31, 2014 at 04:28:31PM -0400, Jonathan wrote: > - Is there access to a development version that works with the trunk version > of Coq? [Thu Aug 21 17:42:15 2014] It is there: [Thu Aug 21 17:42:15 2014] https://gforge.inria.fr/scm/viewvc.php/trunk/Saclay/Ssreflect/?root=coq-contribs [Thu Aug 21 17:42:15 2014] But don't use it in "production" """ Not sure how to get svn access to it if you don't want to download the files one by one or something, but feel free to ask on coq-club or coqdev [Thu Aug 21 17:43:24 2014] johnw: case is basically [intro x; case x; revert ] [Thu Aug 21 17:43:45 2014] jgross: ah, ok [Thu Aug 21 17:43:48 2014] It acts on the goal, but only on things to the left of an arrow [Thu Aug 21 17:44:12 2014] I see [Thu Aug 21 17:44:20 2014] johnw: "clearing my goals buffer constantly" bug <- what bug is that? [Thu Aug 21 17:44:26 2014] that's why the example show (a,b) = (c,d) -> P going to a = c -> b = d -> P [Thu Aug 21 17:44:33 2014] jgross: one sec [Thu Aug 21 17:45:52 2014] jgross: http://proofgeneral.inf.ed.ac.uk/trac/ticket/495 [Thu Aug 21 17:46:26 2014] in other words, my *goals* buffer is constantly being cleared by any edits I make [Thu Aug 21 17:46:41 2014] whereas with 8.4 it is always displaying whatever is the current state of affairs [Thu Aug 21 17:48:11 2014] johnw: Just to make sure, you know about C-c C-p, right? (It says "send [Show.]" or "redisplay the goals buffer".) [Thu Aug 21 17:48:51 2014] yes [Thu Aug 21 17:48:55 2014] but I shouldn't have to do it constantly [Thu Aug 21 17:49:01 2014] with 8.4 I almost never need it [Thu Aug 21 17:49:11 2014] with HEAD I am hitting it all the time [Thu Aug 21 17:49:46 2014] johnw: yes, that's why the example is the way it is. As I understand it, you want the other direction, (a,b) = (c,d) to a = c and b = d. I'm suggesting you prove a separate lemma a = c -> b = d -> (a,b) = (c,d) for each type, and apply that lemma to your goal. [Thu Aug 21 17:50:09 2014] jgross: that's unfortunate [Thu Aug 21 17:50:22 2014] jgross: I do have such lemmas, but that seems an annoying requirement [Thu Aug 21 17:50:45 2014] what I want is a tactic that says "If I can prove the projected values are equal for these products, then the products are equal" [Thu Aug 21 17:51:06 2014] for injective things like inductive data types, that should always be the case [Thu Aug 21 17:52:27 2014] Why is that unfortunate? For sufficiently complicated types, you're asking Coq to compute the homotopy groups of your type. It would be nice to get the lemmas automatically for records (i.e., nested sigma types), though they still require transports in the dependent case. In the non-dependent case, you want the [f_equal] tactic. [Thu Aug 21 17:52:50 2014] right, I think refine+f_equal is what I'm looking for [Thu Aug 21 17:53:12 2014] I'm not sure I followed your discussion correctly, but just in case you want to generate the subgoals [a = c] and [b = d] from [(a,b) = (c,d)], f_equal will do it. [Thu Aug 21 17:53:12 2014] If you want, I can hand you a notation that builds the type of the lemma, and another notation that builds its proof, for any record of a fixed number of arguments. [Thu Aug 21 17:53:16 2014] in ssreflect, refine is automatic, and f_equal just comes with case doesn't it? [Thu Aug 21 17:53:18 2014] Aaaand, you just said that. [Thu Aug 21 17:53:35 2014] jgross: I love being handed notations [Thu Aug 21 17:55:03 2014] Er, I guess you also have to fix the number of arguments to the record type. But, give me a few minutes, and I'll hand you one for two component records. (A few more minutes will give you one for three component records. For more, I'll let you generalize yourself.) [Thu Aug 21 17:55:25 2014] k [Thu Aug 21 18:01:45 2014] gdsfh: either hg or git is fine [Thu Aug 21 18:04:35 2014] Is there any other way to extract nat as int that's more concrete than the one in SF? http://www.cis.upenn.edu/~bcpierce/sf/current/Extraction.html [Thu Aug 21 18:05:08 2014] sh1ken: what do you mean by "concrete"? [Thu Aug 21 18:05:29 2014] jrw: ok, hg, https://bitbucket.org/gds/coq-imp/src [Thu Aug 21 18:05:33 2014] if you mean "better", then no, probably not. [Thu Aug 21 18:05:36 2014] gdsfh: thanks! [Thu Aug 21 18:05:44 2014] Yeah, like "better"... [Thu Aug 21 18:05:49 2014] Well, that's a shame. [Thu Aug 21 18:07:12 2014] Hola. [Thu Aug 21 18:15:22 2014] Is there something like "admit", that I can put in normal function definitions as a placeholder? [Thu Aug 21 18:17:56 2014] ijp: something like this? Definition undefined {A : Type} : A. Admitted. [Thu Aug 21 18:18:07 2014] then use 'undefined' as your placeholder [Thu Aug 21 18:18:35 2014] yes, thanks [Thu Aug 21 18:31:27 2014] gdsfh: this is interesting. what's a simple example program you'd like to write and prove something about in your imp language? [Thu Aug 21 18:34:54 2014] jrw: it's a sad story. Program is here: https://bitbucket.org/gds/ocaml_incrcomp/src/tip/lib/incrcomp.ml (interface in .mli), it's buggy (w.r.t. ~eq no-recomputations), and I can't imagine an algorithm and convince myself with paper and pen that this algorithm will be correct. [Thu Aug 21 18:35:40 2014] elarnon: still here? [Thu Aug 21 18:35:46 2014] too many details, code paths, and it's imperative (and should be imperative). [Thu Aug 21 18:37:53 2014] gdsfh: what does that ml program do? what do you mean by recomputation? [Thu Aug 21 18:37:56 2014] without ~eq ("recompute when sources changed, always") it works, but it appeared that some computation values doesn't change even when sources change, so I have big enough performance penalty in most cases. [Thu Aug 21 18:39:47 2014] jrw: this library allows one to introduce "sources" (values that can be set to some value) and "computations" (functions that take sources or other computations and give some result). It's a kind of DAG with automatic dependencies discovery (when computation got a value from source/computation, it is recorded as dependency). [Thu Aug 21 18:40:13 2014] so for dumb people like me, it's like a spreadsheet? [Thu Aug 21 18:41:25 2014] kind of, but cell formulae are not fixed, every new evaluation can change dependencies. [Thu Aug 21 18:41:55 2014] hmm, what about data-conditional dependencies [Thu Aug 21 18:42:08 2014] like 'if (read from source a) then (read from source b) else (read from source c)'? [Thu Aug 21 18:45:25 2014] then last computation will record a and either b or c. Suppose a=true, and it will be b. So, dependencies are [a; b]. If either a or b change, this computation must be recomputed. Neat thing is that c can change when a=true, it doesn't affect actuality of computation's result. When a becomes =false, next recomputation will set dependencies to [a; c]. [Thu Aug 21 18:46:20 2014] johnw: around? [Thu Aug 21 18:46:57 2014] gdsfh: I see. cool. [Thu Aug 21 18:47:03 2014] johnw: https://gist.github.com/JasonGross/d04e770af9342d63fbcf <- path classification for 2-field records. 3-field records are very similar, but require two transports in the third component. I'm disinclined to write it down, though, given that those 50 lines took me 45 minutes to write. [Thu Aug 21 18:47:59 2014] jgross: that's very much what i've been chasing after to do category equality in my toy Core.v [Thu Aug 21 18:49:33 2014] jgross: i want to transport ob C ~ ob D, transport the hom of C to get hom C' ~ hom D, then check identities and composition, then conditional on those 3 levels check the laws [Thu Aug 21 18:49:42 2014] with that then i can get my notion of ~ for categories [Thu Aug 21 18:49:56 2014] and then i can do two more levels of that nonsense to get functors, then i can do nat [Thu Aug 21 18:50:03 2014] no problem, right? =) [Thu Aug 21 18:51:16 2014] edwardk: https://github.com/JasonGross/HoTT/blob/wip-mostly-finished-but-slow-path-precategory/theories/categories/Category/Paths.v <- that, but for precategoies, and with the property fields already solved. But, ew, why do you want to talk about equality of categories. (I guess if you're going to talk about univalence for categories...) [Thu Aug 21 18:52:08 2014] well, i need to talk about two ways of composing functors being 'equal' for Nat in this setting, and i'm not yet willing to assert univalence or something that makes everything easy [Thu Aug 21 18:53:31 2014] edwardk: Which ways of composing functors? Oh, you're trying to do the laws that show that (Functor C D) is a category, but without the truncating the morphisms? [Thu Aug 21 18:53:38 2014] correct [Thu Aug 21 18:53:48 2014] i've done some of the easy parts [Thu Aug 21 18:54:00 2014] now i'm working up through the tower of all the things i have to say to do it in general [Thu Aug 21 18:54:23 2014] You don't need category equality. You don't need functor equality either (though you'll need that for Cat). You just need equality of natural transformations between the same F and G. [Thu Aug 21 18:54:37 2014] yeah for that, but then Cat, yes [Thu Aug 21 18:54:47 2014] Cat doesn't need equality of categories, either. [Thu Aug 21 18:54:59 2014] hrmm [Thu Aug 21 18:55:39 2014] let me see if i can get further without tackling the category case, i was mostly using it as a warmup for how to do bigger records [Thu Aug 21 18:55:48 2014] and category was of course the canonical choice given my chosen subject matter [Thu Aug 21 18:57:07 2014] And the functor composition laws are actually straight forward, because the on-objects and on-morphisms parts are judgmentally equal, and so you don't have any dependency, and can just use f_equal. [Thu Aug 21 18:58:00 2014] hrmm [Thu Aug 21 18:58:25 2014] i've cleaned up a bunch of stuff since the last time i tried, let me see how cleanly that goes through [Thu Aug 21 18:58:27 2014] In terms of size, natural transformation is actually the smallest one (two fields), and category is the biggest one (7 fields). [Thu Aug 21 18:58:46 2014] (This is, size of the paths classification lemma.) [Thu Aug 21 19:00:32 2014] I get down to something like {| map_ob := λ x : C, map_ob f x; map := λ (x y : C) (f0 : C x y), map f f0; map_id := λ x : C, path_compose (map_id f) refl; map_compose := λ (x y z : C) (f0 : C y z) (g : C x y), path_compose refl (map_compose f f0 g) |} ~ f for the right identity law when i just try to pull through [Thu Aug 21 19:00:36 2014] er bull through it [Thu Aug 21 19:00:53 2014] which is just a bunch of eta expanded forms of the right hand side [Thu Aug 21 19:01:05 2014] jgross: thank you! [Thu Aug 21 19:01:26 2014] what does "abstract" do? [Thu Aug 21 19:01:59 2014] ah, you're using the nifty new $()$ feature [Thu Aug 21 19:07:02 2014] gdsfh: can I ask you a random ocaml question? on line 205 of incrcomp.ml you define a local function ret of type unit -> (...) option that returns a constant value. why? is this an idiomatic way of accomplishing something? (forgive me, my ocaml is not great). [Thu Aug 21 19:09:27 2014] gdsfh: I think you are looking for this lemma: https://gist.github.com/JasonGross/4debd69ae85414fc45ca. You should be able to rewrite with it (assuming Coq isn't being terrible at inferring things inside a [match], and then your code will, I think, be a bit simpler (some of the cases will simplify judgmentally). I'm not sure if that'll be enough to fully solve it, but if you show me what it looks like after you rewrite with that, I might be [Thu Aug 21 19:09:27 2014] able to help more. [Thu Aug 21 19:12:17 2014] jrw: value of ret () is used 4 times below, it's just to avoid code duplication. Actually, it's not a good thing to create a closure when it is not needed, GC-wise.. (and no "can I", no "forgive" -- I am responsible for code I wrote; answering any questions about my code is within my responsibility too.) [Thu Aug 21 19:13:01 2014] edwardk: Yes, then you want to [destruct f] and use [f_equal], possibly after a [simpl in *]. [Thu Aug 21 19:13:09 2014] gdsfh: cool, thanks. [Thu Aug 21 19:13:17 2014] trying that [Thu Aug 21 19:15:14 2014] that got me a lot farther. [Thu Aug 21 19:15:57 2014] edwardk: If the coq-devs would implement my request at https://coq.inria.fr/bugs/show_bug.cgi?id=3512, then [reflexivity] would be enough to handle all of the functor composition laws (as long as it's a primitive record), no [destruct]s or [f_equal]s or anything. [Thu Aug 21 19:16:50 2014] But, as it is, you need functional extensionality to handle to remaining obligations. [Thu Aug 21 19:17:25 2014] yeah. i also need to ap out a couple of remaining obligations underneath i think [Thu Aug 21 19:17:39 2014] i get to http://lpaste.net/8815017386848550912 [Thu Aug 21 19:17:50 2014] then i need to get under there and clear out those path_composes [Thu Aug 21 19:17:52 2014] before its equal [Thu Aug 21 19:19:05 2014] so that means building up a couple of compositions involving ap, is there a nice tactic you guys have figured out for saying just the part of the goal you want to swap out and have it figure out the rest of the term? e.g. repeating the whole {| ... |} when i just want to talk about swapping out that path_compose in there is kinda tedious [Thu Aug 21 19:20:22 2014] If you [apply f_equal2] (or you use [f_ap] (https://github.com/HoTT/HoTT/blob/master/theories/Overture.v#L468), which is my HoTT replacement for [f_equal]), that should be what you want. Or are you looking for the [replace foo with bar] tactic? [Thu Aug 21 19:21:03 2014] f_ap should be it [Thu Aug 21 19:24:18 2014] Or maybe you want [pattern (term you care about); refine (transport _ _ _)] or something? (The [pattern] is so that Coq doesn't have to do higher order unification.) This is if you care that the proof term be defined in terms of [transport] rather than [ap]. Or, I guess, [Tactic Notation "HoTT" "replace" constr(from) "with" constr(to) let LHS := match goal with |- ?LHS = ?RHS => constr:(LHS) end in let RHS := match goal with |- ?LHS = ?RHS => [Thu Aug 21 19:24:18 2014] constr:(RHS) end in let LHS' := (eval pattern from in LHS) in let RHS' := (eval pattern from in RHS) in refine (ap _ _).] (untested) [Thu Aug 21 19:25:50 2014] going to need to steal/modify apD10 and ap11 which don't yet exist in my world [Thu Aug 21 19:28:11 2014] They're both very short, so stealing them shouldn't be hard. [Thu Aug 21 19:32:00 2014] well, its mostly that i want them in my own idiom here, which would cast ap11 as the bifunctor for function application, etc. =) [Thu Aug 21 19:32:12 2014] rather than give them one-off names and associated laws [Thu Aug 21 19:32:33 2014] so i'm going to need to figure out the right path through the design space to fit them in by when i need them [Thu Aug 21 19:43:11 2014] i'm trying to avoid proofs/equations in terms (maybe it will simplify proving), and wondering how/why refine changed goal to such a complex one: "Goal forall A (f : A -> option A) (a b : A) (H : f a = Some b), unit. intros. refine (match H with eq_refl => _ end)." There's something I don't know about match. [Thu Aug 21 19:51:51 2014] gdsfh: Higher order unification in Coq is sometimes wonky. If you add [return _], you get your expected [unit] type. If you do [Set Printing All. Check (match H with eq_refl => _ end : unit).], you get the same complicated return annotation. [Thu Aug 21 19:56:36 2014] jgross: really. Interesting. Maybe you know how can I use terms that appear after "match .. with eq_refl" for the great good? They seem to have more information/context (or no?). [Thu Aug 21 19:59:38 2014] gdsfh: Are you talking about my suggestion for your dependent destruction errors (https://gist.github.com/JasonGross/4debd69ae85414fc45ca), or the inferred return clause? (The inferred return clause basically just says that if (f a) is Some x, then you get Some x = Some b, and if (f a) is None, then you don't have to prove anything. [Thu Aug 21 20:03:54 2014] jgross: ohshi.. Sorry, I missed your message with this gist url. I'll try your lemma now. [Thu Aug 21 20:20:38 2014] gdsfh: Don't worry about it. I mentioned it again because I figured you might've missed it, and it might be useful. Anyway, I'm off to sleep for now. [Thu Aug 21 20:30:37 2014] jgross: lemma rewrites well, but anyway Coq doesn't allow me to destruct/rewrite offending "if .. return ..", it's "too dependent". Maybe I'll be able to modify your lemma to make progress, or will continue to fiddle with "no equations, almost no functions, inductive predicates only". Anyway, thank you for "bool-option commutes" approach. [Fri Aug 22 00:16:50 2014] jgross: f_ap is awesome [Fri Aug 22 04:05:29 2014] elarnon: ping [Fri Aug 22 04:18:56 2014] if I have an equality x = y, how do I "apply" it when writing a term in Gallina to change the type of another value? [Fri Aug 22 04:19:07 2014] i.e., as a tactic I would use rewrite, but what is the equivalent in Gallina? [Fri Aug 22 04:20:56 2014] johnw: eq_rect [Fri Aug 22 04:22:01 2014] excellent, thanks [Fri Aug 22 04:22:40 2014] just have to figure out how to call it... [Fri Aug 22 04:24:00 2014] eq_rect _ _ my-result _ equality-to-rewrite? [Fri Aug 22 04:29:50 2014] johnw: pong [Fri Aug 22 04:30:26 2014] hey, I'm still not making any progress on rev_pal. You mentioned a lemma forall X n l, length l <= n -> l = rev l -> pal X l, but I can't see yet how this would even help me [Fri Aug 22 04:30:49 2014] i'm still stuck on the fact that I have an l, and somehow I need to recursively apply the fact that l = x :: snoc m x [Fri Aug 22 04:31:53 2014] so the point is, when you destruct your list [Fri Aug 22 04:32:28 2014] and it is not empty [Fri Aug 22 04:33:15 2014] you need two things: a) proving that the last and first elements are the same b) proving that the middle elements satisfy pal [Fri Aug 22 04:33:30 2014] a) is easy because you know that l = rev l [Fri Aug 22 04:34:22 2014] as for b), if you are doing an induction on the length of the list and proved that fact for all lists of smaller length, as there are strictly less middle elements than elements in your list, you are good to go [Fri Aug 22 04:35:32 2014] you must do the proof by induction on the list length and not on the list itself [Fri Aug 22 04:35:41 2014] well on [n] [Fri Aug 22 04:37:16 2014] 'cause natural numbers don't increase by steps of two [Fri Aug 22 04:37:39 2014] ok, let me think on that for a bit [Fri Aug 22 04:48:55 2014] elarnon: no, still stuck in the same place [Fri Aug 22 04:48:59 2014] let me show you what I have so far [Fri Aug 22 04:49:06 2014] https://gist.github.com/90d9b3df0fa38675512a [Fri Aug 22 04:49:25 2014] in 'both_ends' I get stuck on the same thing: induction is not examining the end of my list [Fri Aug 22 04:50:31 2014] well yes, you are doing induction on the list [Fri Aug 22 04:50:38 2014] that can't work [Fri Aug 22 04:50:40 2014] so I just say "induction (length l)"? [Fri Aug 22 04:51:23 2014] that won't work either because you need to do two steps at once [Fri Aug 22 04:51:36 2014] did you try with the lemma i gave you? [Fri Aug 22 04:51:43 2014] I couldn't prove that lemma [Fri Aug 22 04:52:14 2014] i end up with n <= S m in my context, and a goal of n <= m [Fri Aug 22 04:52:35 2014] hm, that is not right [Fri Aug 22 04:52:41 2014] let me show you that [Fri Aug 22 04:52:51 2014] https://gist.github.com/aa8a5a79a8c6957c256e [Fri Aug 22 04:53:36 2014] but even with rev_pal_length Admitted, I don't see how to use it [Fri Aug 22 04:53:45 2014] I feel like I'm just missing some huge thing with this theorem [Fri Aug 22 04:55:06 2014] well it is the exact theorem you are trying to prove, except that you also have to find an [n] such that [length l <= n] holds [Fri Aug 22 04:55:10 2014] which shouldn't be too hard [Fri Aug 22 04:55:59 2014] so, saying I do: intros. induction n. admit. apply IHn, here is what I'm looking at: [Fri Aug 22 04:56:03 2014] https://gist.github.com/250447073d0f7c80ffc6 [Fri Aug 22 04:56:31 2014] isn't that unprovable? [Fri Aug 22 04:56:47 2014] so first of all [intros. induction n.] is wrong [Fri Aug 22 04:57:21 2014] how do I start? [Fri Aug 22 04:57:32 2014] you prevent yourself from being able to applying your induction hypothesis: it now has to be [l] while you actually want it to be a sublist of [l], and that is why you get stuck on your [n <= m] impossibility [Fri Aug 22 04:57:43 2014] you should keep the [forall l] part; just do [induction n] [Fri Aug 22 04:58:10 2014] intros X n. induction n.? [Fri Aug 22 04:58:17 2014] try writing down the proof by hand on a piece of paper if that might help [Fri Aug 22 04:58:22 2014] the intros part is unnecessary, but yes [Fri Aug 22 04:58:29 2014] that leds me to the exact same place [Fri Aug 22 04:58:42 2014] now the hypothesis is: IHn : forall l : list X, length l <= n -> l = rev l -> pal X l [Fri Aug 22 04:58:55 2014] yes, don't apply that right now [Fri Aug 22 04:59:05 2014] keep it safely and destruct your list [Fri Aug 22 04:59:40 2014] you want to decompose [l = x :: snoc l' x] and only then apply IHn to [l'] which will have a length < to that of [l] [Fri Aug 22 04:59:57 2014] how do I decompose? assert? [Fri Aug 22 05:00:18 2014] you can do that, i did it using destruct and rewrite [Fri Aug 22 05:00:31 2014] what form of destruct is that? [Fri Aug 22 05:01:09 2014] if I assert it, then it says it doesn't know what 'x' is [Fri Aug 22 05:01:36 2014] let me show you the beginning of my proof [Fri Aug 22 05:01:39 2014] please [Fri Aug 22 05:07:49 2014] ok, found my coq files [Fri Aug 22 05:09:14 2014] do you want all the proof or only the beginning? [Fri Aug 22 05:09:41 2014] all of it at this point [Fri Aug 22 05:09:48 2014] I think I've spent enough hours [Fri Aug 22 05:10:01 2014] clearly there's something crucial I just don't have in my mental toolbox yet [Fri Aug 22 05:10:40 2014] https://gist.github.com/Elarnon/16fedecdd382881cf5c7f [Fri Aug 22 05:10:53 2014] that link failed... [Fri Aug 22 05:11:19 2014] oh hm [Fri Aug 22 05:11:32 2014] i really need to get my copypaste working in weechat again [Fri Aug 22 05:11:43 2014] thanks for being patient with me! [Fri Aug 22 05:11:51 2014] je suis fatigue [Fri Aug 22 05:12:13 2014] is http://bit.ly/1lkTUs0 working? [Fri Aug 22 05:12:20 2014] ah, yes [Fri Aug 22 05:12:31 2014] ok, let me step through this in Coq and see what is going on [Fri Aug 22 05:14:12 2014] what is case_eq? [Fri Aug 22 05:14:49 2014] it's more or less the same as [remember (rev l) as revl; destruct revl.] [Fri Aug 22 05:15:40 2014] destructs but with keeping an equality with the term that was destructed [Fri Aug 22 05:16:12 2014] useful when you destruct something else than a variable, usually [Fri Aug 22 05:16:45 2014] good to know! [Fri Aug 22 05:30:48 2014] ok, case_eq was a pretty big missing piece for me [Fri Aug 22 05:31:04 2014] I had tried the destruct (rev l) approach before, but it failed to retain the hypothesis I needed [Fri Aug 22 05:35:01 2014] ah destruct (rev l) eqn:Heqe is good enough too [Fri Aug 22 05:36:21 2014] elarnon: https://gist.github.com/5868f9ca1169a5c9de93 [Fri Aug 22 05:36:32 2014] [destruct (rev l) eqn:Heqe] is probably cleaner [Fri Aug 22 05:40:21 2014] ah, I can now write this "wrapper"A: [Fri Aug 22 05:40:24 2014] Function rev_pal {X} (l : list X) (H: l = rev l) {measure length l} : pal X l := [Fri Aug 22 05:40:25 2014] rev_pal_length X (length l) l (le_n _) H. [Fri Aug 22 05:40:34 2014] which gives me a rev_pal that doesn't need the length as an argument [Fri Aug 22 05:43:47 2014] (note that you don't need a Function for this - [Theorem rev_pal forall {X} (l : list X), l = rev l -> pal X l. Proof. intros. apply (rev_pal_length X (length l)). Qed.]) [Fri Aug 22 05:43:54 2014] aha [Fri Aug 22 05:44:08 2014] hm wait [Fri Aug 22 05:44:15 2014] you probably need a constructor somewhere also [Fri Aug 22 05:44:39 2014] no, that worked [Fri Aug 22 05:44:46 2014] I needed apply (rev_pal_length X (length l)); auto. [Fri Aug 22 05:45:06 2014] ya that works [Fri Aug 22 05:47:54 2014] ok, that all worked out rather nicely in fact: https://gist.github.com/ee0980cf9daa74f0afa6 [Fri Aug 22 05:47:56 2014] thanks elarnon! [Fri Aug 22 05:48:13 2014] the "eqn:Heqe" on the destruct (rev l) was the missing piece [Fri Aug 22 05:48:21 2014] and the induction on length l, of course [Fri Aug 22 05:48:34 2014] that latter wouldn't have occurred to me, so I'll ponder it more [Fri Aug 22 07:44:51 2014] elarnon: up for another q? [Fri Aug 22 07:46:48 2014] i am busy with my report deadline right now, sorry [Fri Aug 22 07:46:53 2014] ok, no problem [Fri Aug 22 09:29:31 2014] edwardk: Glad you're finding it useful [Fri Aug 22 09:41:58 2014] Hello. [Fri Aug 22 09:42:08 2014] Where can I get ZArith version of minus? [Fri Aug 22 09:42:23 2014] I don't see it here http://coq.inria.fr/library/Coq.ZArith.ZArith.html [Fri Aug 22 10:02:47 2014] Ok, so it is Zminus =/ [Fri Aug 22 10:28:54 2014] https://privatepaste.com/883d599d55 [Fri Aug 22 10:29:05 2014] how can i do case analysis on vt? (its a local variable) [Fri Aug 22 10:39:37 2014] roosbeef, you mean the actual argument of (fix flatten (vt : vterm) : fstring := ...)? [Fri Aug 22 10:40:50 2014] yes, the variable vt [Fri Aug 22 11:00:33 2014] roosbeef, I think this http://pastebin.com/raw.php?i=98vjvBSH does what you want [Fri Aug 22 11:00:43 2014] roosbeef, little bit ugly though [Fri Aug 22 11:01:12 2014] roosbeef, does it help? [Fri Aug 22 11:06:52 2014] hm [Fri Aug 22 11:08:19 2014] well i guess its a step forward [Fri Aug 22 11:08:42 2014] :p [Fri Aug 22 11:08:47 2014] the first case is impossible [Fri Aug 22 11:08:57 2014] so id like to just simplify [Fri Aug 22 11:09:06 2014] and 'unfold' to the second case [Fri Aug 22 11:15:46 2014] i can get rid of the first subgoal [Fri Aug 22 11:15:52 2014] but then im stuck with this https://privatepaste.com/6af65cf189 [Fri Aug 22 11:24:25 2014] roosbeef, actually I don't know which cases this step produces, because I don't know where to get fstring and vterm (I just mocked them with "Variable"). [Fri Aug 22 11:25:48 2014] roosbeef, I think you should extract some property of l from Eq_arg. [Fri Aug 22 11:25:58 2014] roosbeef, but I am not very good in proving things :) [Fri Aug 22 11:36:48 2014] elarnon: I was finally able to do pigeonhole [Fri Aug 22 11:36:53 2014] I still can't see how to do it without LEM though [Fri Aug 22 11:39:02 2014] hello [Fri Aug 22 11:39:08 2014] hi [Fri Aug 22 11:40:44 2014] not stuck at anything(yet), just visiting #coq to see how everbody's doing, ha-ha [Fri Aug 22 11:40:55 2014] everybody* [Fri Aug 22 11:41:30 2014] johnw: curious how long it took you to complete sf? [Fri Aug 22 11:42:22 2014] I'm still working on it [Fri Aug 22 11:43:16 2014] oh, just saw last chapter in your repo, haven't actually opened it(afraid of spoilers) and thought that you've completed it [Fri Aug 22 11:43:28 2014] johnw: where are you at now? [Fri Aug 22 11:44:02 2014] tonight I finished the MoreLogic chapter [Fri Aug 22 11:44:18 2014] based on the files in the directory, I'm here: https://gist.github.com/2dc4249b5245ce9dc6d5 [Fri Aug 22 11:45:06 2014] * 3 chapters away from johnw [Fri Aug 22 11:45:21 2014] i'm at Logic [Fri Aug 22 11:47:08 2014] i should get on with SF [Fri Aug 22 11:47:50 2014] well, considering it's 10:47AM and I haven't slept yet tonight [Fri Aug 22 11:47:56 2014] that should indicate how addictive SF gets [Fri Aug 22 11:48:02 2014] eek! [Fri Aug 22 11:48:03 2014] true [Fri Aug 22 11:48:03 2014] yeah! [Fri Aug 22 11:48:09 2014] I just spent 8 hours straight on pigeonhole_principle [Fri Aug 22 11:51:06 2014] johnw: with all due respect, maybe you should have slept instead [Fri Aug 22 11:51:56 2014] no way [Fri Aug 22 11:52:29 2014] the last Qed must feel nice :) [Fri Aug 22 11:52:33 2014] it sure does [Fri Aug 22 11:52:44 2014] I like how Pierce talks about that in his presentation on the first version of SF [Fri Aug 22 11:54:25 2014] not related to SF or Coq but I remember the proof of pigeonhole principle coming to me in a dream [Fri Aug 22 11:54:29 2014] years ago [Fri Aug 22 11:57:58 2014] Ooh, what's that principle, exactly. [Fri Aug 22 11:58:45 2014] if you have N pigeons to put into N-1 boxes, at least two pigeons will have to go into one box [Fri Aug 22 11:58:55 2014] Given two natural numbers a and b, and two sets A and B of cardinality a and b, if a > b, then for every function f : A -> B, then there exist x, y : A such that f(x) = f(y). [Fri Aug 22 11:59:27 2014] yeah, or that :) [Fri Aug 22 11:59:30 2014] Dijkstra rephrased it in a way discussing averages [Fri Aug 22 11:59:34 2014] that was very insightful [Fri Aug 22 11:59:45 2014] 'Course, you have to define "cardinality". [Fri Aug 22 12:00:09 2014] * vi Pigeonhole.v [Fri Aug 22 12:02:04 2014] Nah, I have better ways to spend eight hours. [Fri Aug 22 12:02:27 2014] I keep having to remind myself that I don't have an unlimited amount of free time. [Fri Aug 22 12:04:04 2014] for me those eight hours are about reconfiguring my brain [Fri Aug 22 12:04:15 2014] since math and proving and type theory are all still pretty new to me [Fri Aug 22 12:04:39 2014] so I see it as joyous investment [Fri Aug 22 12:08:17 2014] * nods. [Fri Aug 22 12:08:24 2014] Yeah, that's true. [Fri Aug 22 12:08:41 2014] For me, at the moment, what I'm lacking is money. [Fri Aug 22 12:08:54 2014] ^_^ [Fri Aug 22 12:09:10 2014] In all seriousness who was thinking about stuffing pigeons in holes? [Fri Aug 22 12:11:47 2014] mrs. miggins pie factory and mathematorium [Fri Aug 22 12:14:41 2014] Pigeon pies? If you have N pigeons, but N-1 pie crusts, one pie gets extra filling? [Fri Aug 22 12:16:41 2014] Pigeonpie principle? [Fri Aug 22 12:18:08 2014] johnw: what's LEM? [Fri Aug 22 12:18:22 2014] oh, excluded middle I guess [Fri Aug 22 12:18:38 2014] chirpsalot: I think your name gives away your propigeon bias [Fri Aug 22 12:20:24 2014] ijp: look, somebody has to stand up for pigeon rights. It's atrocious, being packed together in boxes if there are more pigeons than boxes... [Fri Aug 22 12:21:41 2014] the "child's bedroom principle" isn't quite as catchy [Fri Aug 22 12:26:27 2014] Sounds sketchy. [Fri Aug 22 12:28:09 2014] Dammit, I need to get back into the swing of things with Coq. Pigeon hole principle proving sounds like joyous fun times. [Fri Aug 22 12:28:53 2014] I got distracted when looking at polymorphism... Which seems like a bad place to get distracted because it involves a bundle of special syntax. [Fri Aug 22 12:34:56 2014] why does unfold f sometimes replace f with (fix f ...)? [Fri Aug 22 12:35:11 2014] eg. why does https://privatepaste.com/f2eba5e4df unfold to https://privatepaste.com/0357838078 [Fri Aug 22 12:35:43 2014] Coq could also substitute into the definition? [Fri Aug 22 12:42:09 2014] how could it? It's a fixpoint [Fri Aug 22 12:46:43 2014] ah, yea that makes sense :p [Fri Aug 22 12:46:50 2014] thanks [Fri Aug 22 13:11:05 2014] why is it not possible to rewrite inside the body of a fix? [Fri Aug 22 13:11:17 2014] (using a lemma involving some equality) [Fri Aug 22 13:12:11 2014] Coq will just say Error: Found no subterm matching "..." in the current goal. [Fri Aug 22 13:16:20 2014] roosbeef: functional extensionality [Fri Aug 22 13:17:10 2014] could you explain please? [Fri Aug 22 13:18:44 2014] fix is a special function form that allows recursion. Rewriting "under a lambda" requires the ability to say that equal inputs lead to equal outputs means equal functions. [Fri Aug 22 13:18:53 2014] This is not core to Coq, though. [Fri Aug 22 13:19:55 2014] how does that prohibit rewriting? [Fri Aug 22 13:20:45 2014] if equality is proven, wouldnt that mean equal input/output? [Fri Aug 22 13:21:05 2014] yes, but you need the other direction. [Fri Aug 22 13:22:12 2014] what other direction? [Fri Aug 22 13:22:23 2014] you prove that if the fixpoints have equal inputs, the output before rewriting and after rewriting are equal, but that doesn't mean the fixpoints themselves are equal without an extensionality principle. [Fri Aug 22 13:23:15 2014] ah we _dont_ have the ability to say that [Fri Aug 22 13:23:36 2014] much to many's chagrin. [Fri Aug 22 15:07:45 2014] So, I'm looking at the software foundation book in the basics. The first exercise is implementing a nand operator. I have done that in two ways. Now it says I should make Examples for it. Is there a way to say "this function should return the same as the function given any two parameteres of type bool"? [Fri Aug 22 15:09:44 2014] mads-: sure. I bet you can figure it out :) [Fri Aug 22 15:10:15 2014] how would say that in math? [Fri Aug 22 15:11:00 2014] jrw: uuuuh.. I feel like I have it right on my tongue... [Fri Aug 22 15:11:49 2014] for two functions each of a single argument, maybe you could say "forall x, f(x) = g(x)" [Fri Aug 22 15:12:36 2014] oh, I thought we were looking for a name for the concept :) [Fri Aug 22 15:13:02 2014] Can we then say forall x, forall y, f(x,y) = g(x,y) ? [Fri Aug 22 15:13:09 2014] exactly [Fri Aug 22 15:13:18 2014] except the coq syntax is a little different [Fri Aug 22 15:13:33 2014] since you say "andb x y" instead of "andb (x,y)" [Fri Aug 22 15:13:49 2014] coq also lets you introduce multiple universally quantified variables at once [Fri Aug 22 15:14:00 2014] so you can say "forall x y, nand1 x y = nand2 x y" [Fri Aug 22 15:14:35 2014] How does coq know what x and y is? [Fri Aug 22 15:14:43 2014] what do you mean? [Fri Aug 22 15:14:50 2014] do you mean, how does it know they should be booleans? [Fri Aug 22 15:14:54 2014] yeah [Fri Aug 22 15:14:58 2014] type inference [Fri Aug 22 15:15:06 2014] or you can tell it yourself [Fri Aug 22 15:15:08 2014] it knows nand1 takes two booleans [Fri Aug 22 15:15:19 2014] forall (x y : bool), nand1 x y = nand2 x y [Fri Aug 22 15:15:22 2014] Wow. I didn't think the type inference were that strong [Fri Aug 22 15:15:23 2014] or that :) [Fri Aug 22 15:15:49 2014] cool. I will just try that :) Thanks. [Fri Aug 22 15:15:56 2014] It's actually quite fun. [Fri Aug 22 15:16:09 2014] mads-: don't worry, pretty soon you'll think type inference is very weak :p [Fri Aug 22 15:17:31 2014] now if you actually want to prove this statement in coq, you'll have to scroll down to the "proof by case analysis" section of Basics.v to see how. [Fri Aug 22 15:18:11 2014] cool :) Looking forward to it [Fri Aug 22 15:21:38 2014] Another question. Proof General. What does that actually do? Because right now I feel fine doing my coq in vim without any coq-support. [Fri Aug 22 15:23:35 2014] it lets you step through proofs step-by-step [Fri Aug 22 15:23:55 2014] which is essential when developing proofs. not so important for writing programs and the testing exmaples of basics.v [Fri Aug 22 15:27:03 2014] oh damn. Sounds like I should get it then [Fri Aug 22 15:28:07 2014] if you are vehemently anti-emacs, you could use coqide [Fri Aug 22 15:29:16 2014] not vehemently at all. I just know vim and it seems that proof general is made for emacs 23.* and when I compile it for emacs 24.* it gives me an error about something being deprecated [Fri Aug 22 15:33:38 2014] i think coquille is supposed to be somewhat working in vim as well [Fri Aug 22 15:34:57 2014] it is somewhat less advanced and more bugged than proofgeneral, but people are able to use it without suffering too much afaik [Fri Aug 22 15:35:47 2014] some impressive topiary on that hedge [Fri Aug 22 15:37:19 2014] I just booted up Proof General. It gives me a little warning about being compiled for 24.2 and I'm using 24.3. But it seems to be working, the small things I have tried so far though. [Fri Aug 22 15:37:37 2014] what i mean is that vim-users i know are preferring it over coqide, but i also heard quite some curses about it [Fri Aug 22 15:39:47 2014] I was just on the fence about it seeing that it complained about being compiled for my current setup. [Fri Aug 22 16:09:30 2014] If I have a function andb taking two bools and negb taking one bool, both returning a bool, how would I make a nand gate from that? It seems like I can't just do negb andb b1 b2. What is the syntax I am missing here? [Fri Aug 22 16:10:42 2014] negb (and b1 b2) [Fri Aug 22 16:12:25 2014] vanila: like this? http://pastebin.com/2tyZBWUp [Fri Aug 22 16:12:47 2014] yes but without end. just . [Fri Aug 22 16:13:14 2014] aaah yeah, just realized. [Fri Aug 22 16:13:27 2014] So the end is for the match and not the Definition :) [Fri Aug 22 16:19:55 2014] jrw: how would you make that Example we talked about earlier? Like Example nands_test: forall(x y : bool), nandb1 x y = nandb2 x y. Proof. reflexivity. Qed. ? [Fri Aug 22 16:20:44 2014] mads-: the statement is right, but the proof won't work. [Fri Aug 22 16:20:52 2014] have you ready about 'destruct' yet? [Fri Aug 22 16:20:58 2014] nopes. [Fri Aug 22 16:21:15 2014] I guess I will just read some more. I just thought it would be a simple test to make. [Fri Aug 22 16:26:35 2014] it is [Fri Aug 22 16:36:23 2014] vanila: what should be edited from what I wrote? [Fri Aug 22 16:43:36 2014] hi mads- [Fri Aug 22 16:43:57 2014] to prove that nandb1 and nandb2 are the same function, you can use - like jrw said - destruct x; destruct y. [Fri Aug 22 16:44:03 2014] this splits into into all 4 cases possible [Fri Aug 22 16:44:35 2014] e.g. one case will be nandb1 true false = nandb2 true false which you can prove by reflexivity beacuse it reduces: true = true [Fri Aug 22 16:45:07 2014] your theorem statement is fine just the proof needs to be done different [Fri Aug 22 16:48:32 2014] mads-: you can change 'Proof. reflexivity. Qed.' to 'Proof. destruct x, y; reflexivity. Qed.' and it should work. [Fri Aug 22 16:48:46 2014] to understand *why* it works, you'll have to keep reading or ask questions here :) [Fri Aug 22 16:49:18 2014] I didn't know you could do destruct x, y neat [Fri Aug 22 16:49:50 2014] vanila: you're welcome :P [Fri Aug 22 16:51:10 2014] thanks jrw . I just wanted that to compile before moving on from it [Fri Aug 22 16:52:10 2014] mads-: cool. btw, if you ever want to just get something to compile without finishing the proof, you can replace 'Proof. ... Qed.' with 'Admitted.' [Fri Aug 22 16:52:14 2014] and coq will just believe you. [Fri Aug 22 16:52:35 2014] this has obvious negative consequences if you forget you've admitted something, but it can be helpful while developing. [Fri Aug 22 16:52:43 2014] oh yeah. That is described quite early in the Basics chapter [Fri Aug 22 17:47:08 2014] hi there again~ [Fri Aug 22 17:48:27 2014] i gotta some obstacle to describe a recursive type. [Fri Aug 22 17:48:39 2014] please check the question here: http://stackoverflow.com/questions/25455990/describing-a-recursive-type-in-coq [Fri Aug 22 17:49:02 2014] anyone can spare me a hand :) dankon~ [Fri Aug 22 17:50:27 2014] Definition Human (sex_ : Sex) (spouse_ : Human) : Human := [Fri Aug 22 17:50:35 2014] I think it's a problem that "Human" is the name of the function [Fri Aug 22 17:50:42 2014] and "Human" is the name of the type [Fri Aug 22 17:50:51 2014] Definition MakeHuman (sex_ : Sex) (spouse_ : Human) : Human := (sex_, spouse_). [Fri Aug 22 17:50:55 2014] this could work better [Fri Aug 22 17:51:23 2014] or MkHuman [Fri Aug 22 17:51:39 2014] Definition man (h : Human) : Prop := fst h = male. [Fri Aug 22 17:52:10 2014] Definition spouse (h : Human) : Human := snd h. [Fri Aug 22 17:52:37 2014] hmm. [Fri Aug 22 17:53:10 2014] Alternatively http://coq.inria.fr/refman/Reference-Manual004.html#Record [Fri Aug 22 17:53:18 2014] so how do i start to define one of them? [Fri Aug 22 17:53:25 2014] ahh, an instance of a human. [Fri Aug 22 17:53:34 2014] given that all human needs a spouse. [Fri Aug 22 17:53:49 2014] there's a real problem :) [Fri Aug 22 17:53:54 2014] impossible.. [Fri Aug 22 17:54:32 2014] hmm.. alirhgt. [Fri Aug 22 17:55:02 2014] thanks, i would give a trial :) [Fri Aug 22 17:56:17 2014] but the makehuman cannot be defined due to the misfound of the name 'Human' there. [Fri Aug 22 17:59:19 2014] You could do it similar to list [Fri Aug 22 17:59:31 2014] elarnon: Law of the Excluded Middle [Fri Aug 22 17:59:33 2014] seems i'd to define an alias? [Fri Aug 22 17:59:39 2014] Inductive list (A : Type) : Type := [Fri Aug 22 17:59:39 2014] | nil : list A [Fri Aug 22 17:59:39 2014] | cons : A -> list A -> list A. [Fri Aug 22 18:00:06 2014] Inductive Human : Type := | child : Sex -> Human | adult : Sex -> Human -> Human [Fri Aug 22 18:00:31 2014] then adult sex spouse [Fri Aug 22 18:00:35 2014] hmm. it would work. [Fri Aug 22 18:00:45 2014] but how if i only need the adult type? [Fri Aug 22 18:00:57 2014] in that case it's impossible for any humans to exist [Fri Aug 22 18:01:04 2014] probably i don't need an instance. [Fri Aug 22 18:01:13 2014] Inductive ImpossibleHuman : Type := impossible_adult : Sex -> ImpossibleHuman -> ImpossibleHuman. [Fri Aug 22 18:01:15 2014] then you can prove [Fri Aug 22 18:01:24 2014] Theorem no_impossible_humans : ImpossibleHuman -> False. [Fri Aug 22 18:01:37 2014] ahh... [Fri Aug 22 18:02:58 2014] yup. proved. really disappointing :( [Fri Aug 22 18:03:24 2014] You could define humans then spouses as a relation [Fri Aug 22 18:04:32 2014] that was what I originally wanted. [Fri Aug 22 18:05:04 2014] Inductive Human := shouya | other | .... then Inductive spouses : Human -> Human -> Set := couple_1 : spouses shouya other | couple2 : spouses __ __ | ... [Fri Aug 22 18:05:37 2014] I see! I think that's what exactly I wanted! [Fri Aug 22 18:05:48 2014] Thank you very much! [Fri Aug 22 18:05:55 2014] ok :D [Fri Aug 22 20:30:55 2014] * writes the law of the excluded middle on the wall with a spraycan [Fri Aug 22 20:30:59 2014] * runs away cackling [Fri Aug 22 20:40:10 2014] * tries to contain the damage by spray painting a small -1 below and to the right of hodapp's crime. [Fri Aug 22 20:44:02 2014] * sprays zorn's lemma on a different wall [Fri Aug 22 20:59:26 2014] you monster [Fri Aug 22 20:59:40 2014] edwardk: still having fun? [Fri Aug 22 21:00:13 2014] yeah, taking a night off for once [Fri Aug 22 21:00:19 2014] whoa [Fri Aug 22 21:00:26 2014] figured i should do something with amy sometime ;) [Fri Aug 22 21:00:31 2014] * edits his mental image of edwardk [Fri Aug 22 21:00:50 2014] i was wrestling with Coq until 10:30am in the morning, so I'm a touch fried now [Fri Aug 22 21:06:11 2014] is there a way of modeling hyperfunctions in Coq? [Fri Aug 22 21:06:23 2014] i.e., working around the strict positivity requirement [Fri Aug 22 21:07:18 2014] hyperfunctions? [Fri Aug 22 21:07:28 2014] it would be: Inductive Hyper (b c : Type) := | H : (Hyper c b -> c) -> Hyper b c. [Fri Aug 22 21:07:48 2014] i.e., it models an interleaving recursive function type [Fri Aug 22 21:08:52 2014] ((((b -> c) -> b) -> c) -> b) -> c [Fri Aug 22 21:08:55 2014] I'm sorry I have no idea what to thnk of that [Fri Aug 22 21:09:10 2014] that is scary [Fri Aug 22 21:09:22 2014] this excellent paper documents a real use of them: http://arxiv.org/pdf/1309.5135.pdf [Fri Aug 22 21:09:29 2014] i should also not look at ncatlab.org when i feel stupid [Fri Aug 22 21:09:35 2014] it does not help [Fri Aug 22 21:09:48 2014] I wanted to explore them in Coq, since they should make interesting categories and monoids and such [Fri Aug 22 21:13:20 2014] maybe you could get a model of lambda calculus and build these self and '#' functions in there [Fri Aug 22 21:13:55 2014] I think you can define H 0, H 1, H 2 for all n [Fri Aug 22 21:14:07 2014] by Fixedpoint [Fri Aug 22 21:16:05 2014] I'm reading about Mendler-style recursion right now [Fri Aug 22 21:16:38 2014] johnw: mendler-style recursion is just abuse of the yoneda lemma [Fri Aug 22 21:19:13 2014] yeah, I can see that [Fri Aug 22 21:31:18 2014] johnw: there's no way to get around the positivity constraint [Fri Aug 22 21:31:26 2014] otherwise the theory is inconsistent [Fri Aug 22 21:31:54 2014] well I think there are some consistent non-positive definitions [Fri Aug 22 21:32:31 2014] it's undecidable whether or not a data type will be ok, isn't it? and strict positivity is just a nice large decidable subset [Fri Aug 22 21:32:44 2014] sort of [Fri Aug 22 21:33:05 2014] of course the hyperfunction type IS inconsistent [Fri Aug 22 21:33:06 2014] I think.. [Fri Aug 22 21:33:07 2014] negativity is certainly not ok if you can "observe t" [Fri Aug 22 21:33:16 2014] *it [Fri Aug 22 21:33:48 2014] in general functors lead to consistent inductive types [Fri Aug 22 21:35:31 2014] Ralph Mattes basically wrote the book on this [Fri Aug 22 21:35:33 2014] http://www.irit.fr/~Ralph.Matthes/works.html [Fri Aug 22 21:36:51 2014] http://www.irit.fr/~Ralph.Matthes/Coq/MapFusion/LamFlatPred.v [Fri Aug 22 21:37:02 2014] there's some nice stuff on the untyped LC [Fri Aug 22 21:38:21 2014] interesting [Fri Aug 22 21:38:27 2014] cheers :) [Fri Aug 22 21:40:24 2014] sure enough, the only hyperfunction stuff on Hackage is from edwardk :) [Sat Aug 23 02:01:42 2014] what is the Gallina equivalent of "simpl"? [Sat Aug 23 02:02:20 2014] ah, n/m [Sat Aug 23 05:12:48 2014] are there any tactics like auto but also do inversion? [Sat Aug 23 05:14:44 2014] I'm using destruct and 4 out of 4 sub goals are solvable by inversion. I was hoping to eliminate them using destruct _; some_tactic. [Sat Aug 23 07:10:37 2014] IIRC, Coq is pretty conservative about applying [inversion] for you, since it can easily just generate more useless hypotheses. [Sat Aug 23 07:10:48 2014] You should probably just do [inversion; auto]. [Sat Aug 23 08:27:38 2014] [Hint Extern 1 => match goal with H : |- _ => inversion H end.] will tell [auto] to do [inversion] on the hypotheses with shapes you care about [Sat Aug 23 09:33:02 2014] Hello. Is there a "div" function for nat? [Sat Aug 23 09:35:34 2014] hm. coq.arith.euclid looks promising. [Sat Aug 23 09:49:34 2014] hello. Again my "too dependent types", now I've simplified sources: https://gist.github.com/gdsfh/01acad1e1947ece00a38 . jgross showed me that even complicated matches can be rewritten, but I can't imagine how can I rewrite this match. [Sat Aug 23 09:49:36 2014] I need something like "forall .. (H : get_added ..), match get_val_opt n (add_to_lst) .. end = match Some v .. end", or not? Or even "match get_val_opt n (add_to_lst) with Some x => s x .. end = s v". What solutions do you see? [Sat Aug 23 09:52:53 2014] maybe having (H : get_val_opt (add_to_lst ..) = Some v) I can use eq_rect or something like it to change type of one expression to another type, and at least write down the type of my rewriting lemma? [Sat Aug 23 10:13:15 2014] how do i map projT1? [Sat Aug 23 10:13:56 2014] eg. i have a list of type list {x : A & P x} [Sat Aug 23 10:14:05 2014] how do i do map projT1 list [Sat Aug 23 10:14:10 2014] and get a list of type list A [Sat Aug 23 10:14:39 2014] Coq tells me The term "projT1" has type "forall (A : Type) (P : A -> Type), sigT P -> A" while it is expected to have type "?1016 -> ?1017". [Sat Aug 23 10:18:52 2014] "pattern" is more informative, it gave me hint: https://gist.github.com/gdsfh/f6a6d695f30cfb8c7bb6 , but according to proved lemma eq1 (second part of gist) terms are coercible (reflexivity alone proved it). Also rewriting eq1 is not successful. [Sat Aug 23 10:22:27 2014] roosbeef: if you don't know how to write a term as code, try writing it with tactics: https://gist.github.com/gdsfh/0f90ebbda6862d5c79a0 [Sat Aug 23 10:25:46 2014] gdsfh, thank you.. but how can i use this to construct that mapping? [Sat Aug 23 10:29:54 2014] roosbeef: https://gist.github.com/gdsfh/62e2a1fc9531990e1f49 [Sat Aug 23 10:32:32 2014] ha i was just doing that :p [Sat Aug 23 10:32:40 2014] much thanks [Sat Aug 23 11:04:25 2014] Smerdyakov: hello. Can you please suggest which chapter of CPDT can I read to solve my problem: https://gist.github.com/gdsfh/01acad1e1947ece00a38 ? (sorry if I confused you with some guy who probably knows it) [Sat Aug 23 11:07:31 2014] gdsfh, I haven't looked at it in detail, but I don't see anything especially fancy there. [Sat Aug 23 11:07:56 2014] Can you try to define 'get' in a simpler way? [Sat Aug 23 11:08:04 2014] Smerdyakov: can you give me hints about this rewriting then? [Sat Aug 23 11:08:14 2014] gdsfh, maybe later. [Sat Aug 23 11:09:08 2014] Smerdyakov: ok, or just ignore it, if you have no time/.. [Sat Aug 23 11:09:39 2014] gdsfh: [generalize (@eq_refl _ (get_val_opt n (add_to_lst A l n v))). pattern (get_val_opt n (add_to_lst A l n v)) at 2 3. rewrite (get_added A l n v). simpl.] That will get you a bit further. If you then do [hnf in H. Opaque eq_nat_dec get_val_opt mkval projT1. compute.] you can see what the [match]es look like, and see if you can come up with some intermediate stages to rewrite them to. [Sat Aug 23 11:10:36 2014] vanila: it's a function from "api", it will be the base block for coding and future proofs, so I don't know how to make it simpler to make it useful. [Sat Aug 23 11:15:57 2014] just a sec [Sat Aug 23 11:20:39 2014] jgross: really, this made progress, thank you. So I'll try to proceed by myself. [Sat Aug 23 11:30:27 2014] http://lpaste.net/109886 [Sat Aug 23 11:30:36 2014] Here is how to write get in a simpler way [Sat Aug 23 11:31:01 2014] and the proof works out when you do this, except for the last part which is not provable in Coq [Sat Aug 23 11:31:53 2014] A goal like this eq_rec A (fun T : Type => T) v A B = v requires decidable equality on A or the K axiom [Sat Aug 23 11:33:22 2014] in general if you have two dependent pairs (like { A : Type & A }) equal, you can't prove their elements are equal [Sat Aug 23 11:33:35 2014] because Coq doesn't support this [Sat Aug 23 11:34:27 2014] gdsfh, why did you write [get_val_opt] with tactics? [Sat Aug 23 11:35:49 2014] the definition of get uses the idea in here http://adam.chlipala.net/cpdt/html/DataStruct.html [Sat Aug 23 11:35:55 2014] "By pattern-matching on the equality proof pf, we make that equality known to the type-checker" [Sat Aug 23 11:36:08 2014] and see the next chapter for the stuff about how to use K axiom http://adam.chlipala.net/cpdt/html/Equality.html [Sat Aug 23 12:34:44 2014] are there any libs about inverse relations/functions? [Sat Aug 23 12:35:30 2014] id like to say that map g (map f x) = x if g and f are eachothers inverse function [Sat Aug 23 12:35:50 2014] vanila: my definition of get allows rewriting too, when I do "revert B". It's what I needed, thank you. As for proving equality on dependent pairs -- Goal forall A P (x : { y : A & P }), projT1 x = projT1 x. reflexivity. -- works. Maybe you mean something else? [Sat Aug 23 12:36:34 2014] do you see how my definition of get is simpler? [Sat Aug 23 12:36:39 2014] try Print get. on both [Sat Aug 23 12:36:44 2014] anyway [Sat Aug 23 12:37:15 2014] suppose x1 : { y : A & P }, x2 : { y : A & P } then x1 = x2 -> projT1 x1 = projT1 x2 [Sat Aug 23 12:37:21 2014] vanila: really, your definition is simpler, I see. [Sat Aug 23 12:37:34 2014] but you do not have x1 = x2 -> projT2 x1 = [projT2 x2] [Sat Aug 23 12:37:44 2014] where [] means use the previous theore to cast the types to make this well formed [Sat Aug 23 12:38:19 2014] but this stuff about pairs is a diversion [Sat Aug 23 12:38:35 2014] but I don't need to prove that proofs (P) are equal, I need to prove equality on values only. [Sat Aug 23 12:39:42 2014] ok [Sat Aug 23 12:39:58 2014] it's just that you need uniqueness of equality proofs [Sat Aug 23 12:40:01 2014] I think [Sat Aug 23 12:40:10 2014] and that's equivalent to this [Sat Aug 23 12:40:53 2014] but the whole task doesn't require reasoning about proofs equality/uniqueness. [Sat Aug 23 12:42:04 2014] gdsfh, your life will be easier if you avoid using this type of dynamic packages. [Sat Aug 23 12:45:35 2014] Smerdyakov: you are right. But I've asked in coq-club about polymorphism (message from 19 Aug), no one suggested anything at all, so I had no choice. [Sat Aug 23 12:45:50 2014] can you link to the message? [Sat Aug 23 12:47:41 2014] vanila: I've tried to google it, no success. Here is a relevant part of message: http://pastebin.com/raw.php?i=F1QPjC3i [Sat Aug 23 12:50:21 2014] maybe you could have a function typeOf : nat -> Set then your state could be list ({ n : Nat & typeOf n }) [Sat Aug 23 12:50:52 2014] The difference here is that there is decidable equality on 'n', so I think you can avoid the need for extra axioms [Sat Aug 23 12:51:16 2014] im not sure though, this is difficult [Sat Aug 23 12:55:22 2014] vanila: I can't have such function: code will be too ugly. [Sat Aug 23 13:00:08 2014] Smerdyakov: welcome back to IRC, long time no see ;) [Sat Aug 23 13:01:28 2014] edwardk, :) [Sat Aug 23 13:10:35 2014] hm [Sat Aug 23 13:49:12 2014] I am new to both coq, emacs and Proof General. Can anyone tell me what happens here and how I can come back to my actual coq code? http://imgur.com/a/CldDG - It works fine with C-c C-n for next steps as shown on image one. However, when I reach the last tauto or Qed my emacs changes to what you see on image two. How do I get back to my code? [Sat Aug 23 13:50:54 2014] C-x b will let you pick the buffer, you can also sometimes C-x k the buffer that is between you and what you want [Sat Aug 23 13:52:16 2014] thanks. I think I'm going to have a rough start with this emacs :) [Sat Aug 23 13:54:17 2014] mads-: I usually quit PG at that point (C-c C-x) and then restart proof general (C-c C-RET). [Sat Aug 23 13:55:03 2014] hello [Sat Aug 23 13:56:16 2014] could someone give me a hint on http://lpaste.net/4599423457300578304 ? it looks easy but im missing something essential... [Sat Aug 23 13:57:33 2014] Ainieco, that goal isn't provable [Sat Aug 23 13:57:46 2014] you can prove all tautologies with tauto. though [Sat Aug 23 13:58:33 2014] Ainieco : your [left] was a little bit early, you cannot know yet if you will prove [P] or [Q /\ R] [Sat Aug 23 13:58:49 2014] you need to destruct H0 and H1 to know that [Sat Aug 23 14:00:42 2014] oh, thanks [Sat Aug 23 14:03:24 2014] wasn't aware of fact that i can destruct H's. [Sat Aug 23 14:07:23 2014] hm, i guess destructing H's isn't right approach either http://lpaste.net/4599423457300578304 [Sat Aug 23 14:10:47 2014] Ainieco, try this [Sat Aug 23 14:10:50 2014] Proof. tauto. Qed. [Sat Aug 23 14:11:27 2014] here is the bad way to do it http://lpaste.net/109887 [Sat Aug 23 14:15:01 2014] vanila: i wonder what is intended(by Pierce) way to prove it since he havent mentioned neither tauto tactic nor destructing H... [Sat Aug 23 14:15:23 2014] case is the same as destruct in this situation [Sat Aug 23 14:27:13 2014] ugh, forgot i can use inversion on "or", proved it via inversion [Sat Aug 23 14:27:27 2014] tauto looks like cheating [Sat Aug 23 14:28:09 2014] do you know how /\ and \/ are defined? [Sat Aug 23 14:30:53 2014] yup [Sat Aug 23 14:31:29 2014] so case analysis on /\ gives you both proofs, case analysis on \/ splits your goal into two - each having the assumption [Sat Aug 23 14:31:56 2014] you can use the 'case' tactic instead of inversion (which is more powerful than you need) [Sat Aug 23 14:33:15 2014] got it, thanks! [Sat Aug 23 15:39:34 2014] oh gawd, I just wrote "no_whilesR" as "noWhilesR" in 5 places [Sat Aug 23 15:39:41 2014] someone get me some brain bleach to clean the Java out of my head [Sat Aug 23 16:42:56 2014] I need help understanding how physical/logical module paths work. I have a bunch of files in ~/src/foo which I want to reference directory with Require Foo, Require Bar, etc. I have more files in ~/src/bar, which I want to reference from foo's modules as Bar.Baz and Bar.Quux. Is this possible? [Sat Aug 23 16:43:18 2014] I tried -I ~/src/foo -I ~/src/bar -as Bar, but it keeps saying that Bar.Baz.v is required but not found [Sat Aug 23 17:01:10 2014] aha, the problem is really that coqdep and coqc have very different behaviors [Sat Aug 23 17:01:27 2014] coqc succeeds, where coqdep with the exact same source code and options claims that the module cannot be found [Sat Aug 23 17:24:06 2014] sorry for long output but if anyone has any ideas about how to prove last lemma I could use some help :) http://lpaste.net/109898 [Sat Aug 23 17:25:01 2014] destruct l, the go left in the nil case, right in the cons case [Sat Aug 23 17:25:24 2014] in the right case you'll need to destruct n, as you did above [Sat Aug 23 17:25:26 2014] um well I know that much.. problem is how to do rest [Sat Aug 23 17:25:46 2014] I don't think destructs solve it but I can try one more time I guess [Sat Aug 23 17:27:43 2014] johnw: H : find_min_idx (h :: t) = S n' |- S n' < length (h :: t) [Sat Aug 23 17:27:55 2014] with just destruct I'm stuck at this [Sat Aug 23 17:28:04 2014] can you do inversion on that iypothesis? [Sat Aug 23 17:28:19 2014] no, find_min_idx is a function [Sat Aug 23 17:28:30 2014] ah [Sat Aug 23 17:28:50 2014] johnw: I mean I can do that but I'm getting same thing as H1 [Sat Aug 23 17:38:59 2014] ha! I did it! [Sat Aug 23 17:39:03 2014] how? [Sat Aug 23 17:39:40 2014] johnw: http://lpaste.net/109898 [Sat Aug 23 17:40:40 2014] ah, well done :) [Sat Aug 23 17:41:41 2014] thanks. I'll remove [pose proof]s and use [apply] instead. [Sat Aug 23 19:09:19 2014] johnw: That sounds like a bug (coqdep and coqc behaving differently). You should report it. [Sat Aug 23 19:12:12 2014] ok [Sat Aug 23 19:12:16 2014] jgross: have another question for you [Sat Aug 23 19:12:20 2014] https://gist.github.com/6f630649ba0def5606e8 [Sat Aug 23 19:12:28 2014] I'm trying to use coinduction to prove things about hyperfunctions [Sat Aug 23 19:12:38 2014] I'm following the tricks given in Adam's book [Sat Aug 23 19:12:54 2014] but for some reason, 'simpl' is not resolving the applications of 'frob' the way they are for Adam [Sat Aug 23 19:13:24 2014] Which line? [Sat Aug 23 19:13:30 2014] 96 [Sat Aug 23 19:13:38 2014] the call to "simpl" leaves "frob f" in the goal [Sat Aug 23 19:13:42 2014] instead of revealing the constructors [Sat Aug 23 19:13:48 2014] also, I'm not sure what to do about hstream_equality [Sat Aug 23 19:14:02 2014] my Category is not really setup for codata [Sat Aug 23 19:15:24 2014] I guess this is again where setoids would help me? [Sat Aug 23 19:18:48 2014] AFAIK, coinduction in Coq is not very pretty. You could assume [hstream_eq S T] is equivalent to [S = T] as an axiom. (In much the same way you'd assume functional extensionalty as an axiom.) There might be a systematic way of doing coinductive equality, but I don't know it. You could ask on coq-club. (Also, I hear the paco library is nice for coinduction, but don't actually know much about it.) [Sat Aug 23 19:19:49 2014] johnw: "Error: Level 99 is already declared right associative while it is now expected to be left associative." [Sat Aug 23 19:19:59 2014] huh [Sat Aug 23 19:20:03 2014] just change it to 98 [Sat Aug 23 19:20:07 2014] or whatever works [Sat Aug 23 19:20:44 2014] And, uh, your [Class Hyper] definition make Coq loop? [Sat Aug 23 19:21:06 2014] how so? [Sat Aug 23 19:21:16 2014] oh [Sat Aug 23 19:21:38 2014] no, why? [Sat Aug 23 19:21:43 2014] it doesn't here [Sat Aug 23 19:22:00 2014] i'm using 8.4pl4 btw [Sat Aug 23 19:22:20 2014] Oh, I'm using trunk. Let me try 8.4. [Sat Aug 23 19:22:54 2014] you may also need my versions of Category and Functor, right? [Sat Aug 23 19:23:35 2014] http://dl.dropbox.com/u/137615/coq-haskell.tar.gz [Sat Aug 23 19:25:24 2014] be back in 10 [Sat Aug 23 19:25:51 2014] Oh, yeah, that's probably the issue; I was using edwardk's. [Sat Aug 23 19:26:54 2014] er, nope, sorry, I was using https://github.com/jwiegley/category-theory [Sat Aug 23 19:34:51 2014] johnw: I don't see why that should [simpl]? However, [destruct f; simpl; constructor] works fine, as I expect. [Sat Aug 23 19:43:35 2014] I changed Category.v [Sat Aug 23 19:43:38 2014] to work with 8.4 [Sat Aug 23 19:43:47 2014] destruct f. Guarded. shows the problem [Sat Aug 23 19:45:12 2014] in Adam's book, simpl causes frob f to dissolve into a constructor application [Sat Aug 23 19:45:16 2014] not sure why that isn't happening here [Sat Aug 23 19:53:47 2014] ah, this isn't going to work anyway [Sat Aug 23 19:54:04 2014] I can't realize (a ~> a) -> a, since Type is not coinductive [Sat Aug 23 19:55:46 2014] You're applying [frob] to an opaque thing, and [frob] is defined as a match. How does that simpl to a constructor? (Which chapter/definition of CPDT should I look at?) [Sat Aug 23 19:56:33 2014] http://adam.chlipala.net/cpdt/html/Coinductive.html [Sat Aug 23 19:56:41 2014] about halfway through [Sat Aug 23 19:57:52 2014] You mean with [ones] and [ones']? That's because both of those are defined as constructor applications, while your [f] is atomic. [Sat Aug 23 19:58:08 2014] oh [Sat Aug 23 19:58:15 2014] that makes a lot of sense now [Sat Aug 23 19:58:58 2014] it also makes sense that in the inductive world, I need extensionality here typically [Sat Aug 23 19:59:46 2014] if I try it here before apply hstream_equality, I get Error: No matching clauses for match goal [Sat Aug 23 20:00:35 2014] What is "it" that you're trying before hstream_equality? [Sat Aug 23 20:00:45 2014] "extensionality e" [Sat Aug 23 20:03:16 2014] Well, yes, [extensionality e] is basically [apply functional_extensionality_dep; intro e], and [f] is not a function. [Sat Aug 23 20:03:46 2014] what if I add a Funclass coercion? [Sat Aug 23 20:04:38 2014] i'll play with it; thanks jgross [Sat Aug 23 20:07:24 2014] johnw: Obligation 1. apply hstream_equality. rewrite (frob_eq (hcompose f (lift (fun x : A => x)))). rewrite (frob_eq f). simpl. destruct f. simpl. revert b f. cofix. intros. constructor. simpl. destruct f. rewrite (frob_eq (hcompose _ (lift (fun x : A => x)))). rewrite (frob_eq f). simpl. apply HStream_Category_obligation_1. Defined. [Sat Aug 23 20:07:48 2014] whoa [Sat Aug 23 20:08:27 2014] what does "revert b f. cofix" mean? [Sat Aug 23 20:09:08 2014] It means "I want my coinduction hypothesis to start with [forall b f,] rather than being tied to the particular [b] and [f] I've chosen. [Sat Aug 23 20:09:27 2014] s/I've chosen/that happen to be laying around/ [Sat Aug 23 20:09:34 2014] i mean, it seems like you use destruct to get b and f, then you pop b and f, then you push them back on [Sat Aug 23 20:09:41 2014] and somehow that makes things happy? [Sat Aug 23 20:10:04 2014] hmm [Sat Aug 23 20:10:11 2014] how is destruct f suddenly passing the Guarded condition? [Sat Aug 23 20:10:20 2014] when it wasn't just a few minutes ago... [Sat Aug 23 20:10:26 2014] No, what makes things happy is that I [destruct f] before I [cofix] so that, once I've [cofix]ed, I can first [constructor], before I [destruct f] again. [Sat Aug 23 20:10:32 2014] ahhhh [Sat Aug 23 20:10:42 2014] that's the piece I was missing [Sat Aug 23 20:10:47 2014] You had the right idea for the proof, you were just "off by one". [Sat Aug 23 20:11:15 2014] and the revert lets you later use HStream_Category_obligation_1 [Sat Aug 23 20:11:18 2014] I wouldn't have spotted that [Sat Aug 23 20:11:28 2014] thanks jgross! [Sat Aug 23 20:11:36 2014] too bad HStream_run can't be defined :( [Sat Aug 23 20:11:40 2014] https://gist.github.com/5ac200658cb722b591eb [Sat Aug 23 20:11:48 2014] I need that to make an instance for the Hyperfunction [Sat Aug 23 20:12:11 2014] Yes, that's what revert does. (If you go forward with this, you should do cofix as H or whatever lets you name the hypothesis, because generated names are evil.) [Sat Aug 23 20:12:17 2014] Glad I was able to help :-) [Sat Aug 23 20:14:07 2014] yay, Category defined [Sat Aug 23 20:14:52 2014] but I don't think I can get an inductive "output" from this coinductive stream [Sat Aug 23 20:15:09 2014] maybe with an approximator [Sat Aug 23 20:15:55 2014] HStream_run is inconsistent. If you define [rep f] as [HCons f (HCons f ...)], then [HStream_run (rep (@id False)) : False]. [Sat Aug 23 20:16:05 2014] yep [Sat Aug 23 20:16:48 2014] Personally, I'm glad HStream_run can't be defined :-P [Sat Aug 23 20:16:53 2014] haha [Sat Aug 23 20:17:24 2014] at best I can define: https://gist.github.com/ccb5c9a9e7e461b1edc4 [Sat Aug 23 20:19:15 2014] Isn't that just the constant function None? [Sat Aug 23 20:19:26 2014] uh, you're right [Sat Aug 23 20:19:31 2014] a very glorified const None [Sat Aug 23 20:19:37 2014] I think you need to give your approximator a seed value [Sat Aug 23 20:20:10 2014] I might call it pompous rather than glorified [Sat Aug 23 20:20:18 2014] bombastic [Sat Aug 23 20:20:40 2014] Sure, that works too ^.^ [Sun Aug 24 00:24:16 2014] if my goal is RelationClasses.Equivalence_Reflexive = Equivalence_Reflexive, what might I be looking for to complete that? [Sun Aug 24 00:53:00 2014] I'm looking at http://www.cis.upenn.edu/~bcpierce/sf/current/Imp.html#lab431 and I don't actually have any idea how I'd assert that something terminates... [Sun Aug 24 00:53:48 2014] the no_whilesR inductive type cannot be constructed with a non-terminating program [Sun Aug 24 00:53:57 2014] you just need to show that this is the case by induction [Sun Aug 24 00:55:15 2014] but how would I express the general notion of a non-terminating program? [Sun Aug 24 00:55:40 2014] show that it has a terminating case, and that the evaluation of any program reduces to that terminating case [Sun Aug 24 00:56:09 2014] I haven't done this chapter yet, but I imagine there's an 'END' or 'RETURN' instruction of some sort [Sun Aug 24 02:41:04 2014] jgross: is there an easy way to find out why Coq goes into an infinite loop? [Sun Aug 24 02:56:10 2014] hodapp: are you still trying to phrase termination? [Sun Aug 24 03:03:26 2014] anyways, in this case the big step evaluation relation (ceval) implies termination, so I think what they're looking for is something along the lines of: forall c st, no_whilesR c -> exists st', c / st || st' [Sun Aug 24 07:05:50 2014] do we have a proof for this in stdlib: "exists (h0 : list A) (t : A), h :: th :: tt = h0 ++ [t]" ? [Sun Aug 24 07:15:35 2014] is there a simple way to construct from an (L : list A) an (L' : list {x : A & In x L})? [Sun Aug 24 07:16:22 2014] im currently using this: https://privatepaste.com/12dea1f149 [Sun Aug 24 07:17:11 2014] which does work but i have to prove that when doing map projT1 on this list it returns the original list, which seems with this definition more cumbersome than it should be [Sun Aug 24 07:22:05 2014] I have H : S n < S (length l) and when I do rewrite <- lt_n_S in H. I'm having H : S ?9115 < S (length l). why? [Sun Aug 24 07:23:10 2014] you need the other way around [Sun Aug 24 07:23:23 2014] hm nevermind you did <- [Sun Aug 24 07:23:27 2014] id do apply though not rewrite [Sun Aug 24 07:24:05 2014] with implications [Sun Aug 24 07:24:34 2014] try [apply lt_S_n in H.]? [Sun Aug 24 07:32:52 2014] apply is failing with a weird error message [Sun Aug 24 07:33:21 2014] terms in the error message are not the terms I'm working on so I have no idea what's going on. [Sun Aug 24 07:36:03 2014] I have only one lemma left to finish my master theorem :p [Sun Aug 24 07:38:28 2014] nice [Sun Aug 24 07:38:51 2014] whats the error message? [Sun Aug 24 07:55:21 2014] yay i solved my problem too :) [Sun Aug 24 08:02:40 2014] hi, [Sun Aug 24 08:03:21 2014] a little question: how do i define the one-many property of a relation. [Sun Aug 24 08:03:54 2014] following a method mentioned on imp: http://people.umass.edu/klement/imp/imp.html#page45 [Sun Aug 24 08:04:36 2014] they may be defined as relations such that the relative product of one of them and its converse implies identity, where the “relative product” of two relations R and S is that relation which holds between x and z when there is an intermediate term y, such that x has the relation R to y and y has the relation S to z. [Sun Aug 24 08:04:40 2014] here. [Sun Aug 24 08:05:27 2014] my train of thought is to define the concept 'converse', 'relative product', and 'id' first. [Sun Aug 24 08:07:15 2014] http://lpaste.net/109924 [Sun Aug 24 08:07:31 2014] here's my definition. [Sun Aug 24 08:09:27 2014] one_many'' is the definition completely following that statement on the book. [Sun Aug 24 08:09:43 2014] the 'Goal' section below is how i understand it. [Sun Aug 24 08:11:07 2014] while I can't prove that they're equivalent. [Sun Aug 24 08:11:15 2014] johnw: No. If it's typeclasses, you can [Set Typeclasses Debug.] If it's Ltac, you can [Set Ltac Debug.] If it's something else, you can recompile Coq with Ocaml+fp and -debug, and then use gprof, I think. And then you have to figure out how the mangled names correspond to the OCaml methods. While the first two are easy, the last is decidedly not. [Sun Aug 24 08:17:55 2014] edwardk, johnw: You have [Set Primitive Projection] in a bunch of places in https://github.com/jwiegley/category-theory/; the flag is [Set Primitive Projections.] [Sun Aug 24 09:16:15 2014] hm. coq warns me about possible stack overflows because I use huge nat's. I would use BinNat's. But is it possible to use decimal notation for BinNats? [Sun Aug 24 09:18:18 2014] is using N_scope sufficient? [Sun Aug 24 09:19:29 2014] ok, seems like that. [Sun Aug 24 09:47:58 2014] jrw: thanks, that makes some sense. I was trying something similar but was missing the 'exists' part because I forgot that exists, err, exists [Sun Aug 24 09:50:08 2014] This channel is too much for me. Maybe I can handle it better once I'm done with CPDT. [Sun Aug 24 10:07:00 2014] CPDT? [Sun Aug 24 10:07:53 2014] that book by Adam Chlipala [Sun Aug 24 10:36:07 2014] why'd he leave :( [Sun Aug 24 10:36:14 2014] or she. [Sun Aug 24 10:36:15 2014] or it. [Sun Aug 24 10:37:01 2014] or they; don't want to discriminate against the schizophrenic [Sun Aug 24 10:37:40 2014] THAT'S NOT WHAT SCHIZOPHRENIA MEANS [Sun Aug 24 10:39:00 2014] thank you dsm5bot [Sun Aug 24 10:39:56 2014] haha [Sun Aug 24 12:28:03 2014] When using match n with .. S n' => n', does that prime mean anything? Or could I just write S x => x ? [Sun Aug 24 12:33:17 2014] mads-: No, the ' is just part of the name "n'" [Sun Aug 24 13:00:04 2014] bacam: thanks. [Sun Aug 24 14:43:31 2014] hello [Sun Aug 24 14:45:56 2014] why I can't apply excluded middle right away here http://lpaste.net/481715496035549184 ? Pierce says that it's safe to add these classic theorems as axioms but "apply exluded_middle." doesn't work in excluded_middle_irrefutable [Sun Aug 24 14:46:45 2014] aren't those definitions defined by Pierce not axioms enough and i have to do foo-like thing for every one of them? [Sun Aug 24 14:49:12 2014] those definitions are just shorthands for the proposition, not a proof of them, or saying that they are an axiom [Sun Aug 24 14:49:44 2014] coq will accept Definition clearly_not_true := 0 = 1. just fine [Sun Aug 24 14:50:14 2014] oh, so i need to add any of them as axiom myself, got it [Sun Aug 24 14:50:55 2014] ijp: does that means that i can't prove excluded_middle_irrefutable without having excluded_middle as axiom? [Sun Aug 24 14:51:20 2014] well, you can just make it a hypothesis [Sun Aug 24 14:52:01 2014] I did that for my proofs of classical_axioms [Sun Aug 24 14:53:52 2014] or you can use the Axiom command, if you prefer [Sun Aug 24 14:53:59 2014] http://coq.inria.fr/refman/Reference-Manual003.html#hevea_command0 [Sun Aug 24 14:54:43 2014] ijp: sorry but how can i make it hypotesis? i can't just prepend "P \/ ~P -> " to excluded_middle_irrefutable because it's an exercise defined by Pierce [Sun Aug 24 14:55:02 2014] ijp: okay, i'll add it as an axiom, thank you! [Sun Aug 24 14:58:14 2014] Ainieco: I think that may imply you can do it without LEM [Sun Aug 24 14:58:34 2014] that exercise wasn't there when I did sf, but I'll see if I can manage it [Sun Aug 24 15:00:43 2014] ijp: sorry, what is LEM? [Sun Aug 24 15:00:51 2014] excluded middle [Sun Aug 24 15:02:16 2014] ah, can't think about way of proving it without LEM, it'll be interesting to see one tho [Sun Aug 24 15:03:55 2014] yeah, you can solve it without it [Sun Aug 24 15:04:20 2014] quite a cheeky proof really [Sun Aug 24 15:09:04 2014] yup, found a way to solve it without LEM [Sun Aug 24 15:17:38 2014] ijp: by the way do you know what is meant by "equivalent" in that 5 star exercise from paste? [Sun Aug 24 15:17:56 2014] is it pierce = classic? [Sun Aug 24 15:18:13 2014] <-> rather than = [Sun Aug 24 15:19:00 2014] you can get away with only five one way proofs if you do them right [Sun Aug 24 15:19:51 2014] ijp: why? i know you're right because i already failed proving it with = but i just want to learn why in this time equivalent means <-> [Sun Aug 24 15:20:12 2014] because want to reason correctly next time on my own :) [Sun Aug 24 15:20:53 2014] to be honest, I didn't give it a thought [Sun Aug 24 15:22:26 2014] ijp: but you somehow decided that it's <-> rather than =, was it a guess? [Sun Aug 24 15:24:28 2014] Ainieco: I suppose I just assumed it based on the use of the word "equivalent" rather than "equal" [Sun Aug 24 15:26:47 2014] yeah that makess sense [Sun Aug 24 16:38:13 2014] finished all in Logic.v except that 5 star exercise... looks like really though one. [Sun Aug 24 16:39:43 2014] they are not very difficult [Sun Aug 24 16:39:52 2014] just have a go [Sun Aug 24 16:40:02 2014] if you get stuck i could help [Sun Aug 24 16:40:11 2014] I solved these from coq'art a while ago [Sun Aug 24 16:40:26 2014] the peirce ones were harder for me but that's because I didn't really get what the peirce lemma said [Sun Aug 24 16:40:50 2014] by the way, to prove that they are all equivalent yuo just need to show that A -> B, B -> C and C -> A [Sun Aug 24 16:41:10 2014] but I knew it was the type of call/cc, so I figured it out that way [Sun Aug 24 16:41:11 2014] vanila: thank you! [Sun Aug 24 16:43:39 2014] vanila: yeah, because of transitivity [Sun Aug 24 16:43:52 2014] Ainieco: but none of the proofs are very long, they just require careful thought [Sun Aug 24 16:44:17 2014] jgross: thanks [Sun Aug 24 16:44:23 2014] jgross: in one case, it was typeclass instance resolution going into an infinite loop; but making the call to fmap fully explicit, it fixed it [Sun Aug 24 16:44:47 2014] jgross: is there any resource for better understanding how typeclass instance are resolved in Coq? I've run into a few cases where it makes little sense to me, coming from Haskell [Sun Aug 24 16:44:48 2014] ijp: you're right, thank you of encouraging me :) [Sun Aug 24 16:45:08 2014] for example, I have a Maybe and an Either instance, but when I fmap f x on an Either value, it picks the Maybe instance. Stuff like that [Sun Aug 24 16:46:04 2014] johnw: the hint really is the 'typeclass' thing isn't about classes, its implicits, it looks for something that typechecks and plugs it in. [Sun Aug 24 16:46:19 2014] that's why i switched to records rather than classes [Sun Aug 24 16:46:37 2014] edwardk: how did that solve things for you? [Sun Aug 24 16:47:17 2014] because now i'm using reocrds i explicitly pass as needed and am not relying on magic instance resolution to try to find an instance when all instances are the same because you have no parameters! [Sun Aug 24 16:47:28 2014] C : category can always be satisfied [Sun Aug 24 16:47:34 2014] if you have any category [Sun Aug 24 16:47:51 2014] that's why you keep getting the latest thing you made [Sun Aug 24 16:47:51 2014] I see. I would still like to understand what Coq is doing better, and why [Sun Aug 24 16:47:59 2014] Haskell's way of doing things has always made perfect sense [Sun Aug 24 16:48:07 2014] s/better// [Sun Aug 24 16:48:11 2014] I'll take Lakes of the World for $500 [Sun Aug 24 16:48:21 2014] if you make an instance for a thing that has parameters you can actually get something the instance discharge machinery has to fire off of [Sun Aug 24 16:48:42 2014] but with C : category for instance, you have literally nothing for it to dispatch off for instance [Sun Aug 24 16:48:52 2014] ah, so this is the proxy problem [Sun Aug 24 16:49:01 2014] which in Haskell is an error [Sun Aug 24 16:49:18 2014] when you say Program Instance Maybe : Functor Types Types -- you've made 'the functor from types to types' [Sun Aug 24 16:49:25 2014] rather than a functor from types to types [Sun Aug 24 16:49:41 2014] so it feels justified filling in the instance whenever it needs a functor from types to types! [Sun Aug 24 16:49:52 2014] right [Sun Aug 24 16:49:58 2014] in haskell you'd just get yelled at by the compiler [Sun Aug 24 16:50:06 2014] this seems no good [Sun Aug 24 16:50:17 2014] well, you have no coherence guarantees in coq [Sun Aug 24 16:50:23 2014] like i said, they are implicits [Sun Aug 24 16:50:55 2014] in haskell you'd have to make a type constructor to hang the functor off, then the instance would dispatch off that [Sun Aug 24 16:51:11 2014] what I'm doing now is going back to working on my coq-haskell library, which is explicitly for proving properties about typical Haskell code. For that I want a verison of Category which is convenient to work with *in that context*. So I'd like to be able to write code which looks and feels like Haskell, meaning I want to make use of typeclasses [Sun Aug 24 16:51:12 2014] Functor would have a parameter describing the tag/embedding/whatever [Sun Aug 24 16:51:45 2014] but I need to figure out how to make them well-behaved, and how to know when they aren't [Sun Aug 24 16:51:55 2014] hen you really want Functor to take something haskell would say is of kind * -> * as a parameter, in coq you'd probably pass the lambda at the type level [Sun Aug 24 16:52:11 2014] you don't get to know when they aren't [Sun Aug 24 16:52:19 2014] you don't have the global enforcer in the typechecker [Sun Aug 24 16:52:29 2014] edwardk: what looks wrong about this to you: https://github.com/jwiegley/coq-haskell/blob/master/Category.v#L616 [Sun Aug 24 16:52:36 2014] haskell has a whole set of logic to enforce invariants that aren't enforced here [Sun Aug 24 16:53:24 2014] right [Sun Aug 24 16:53:27 2014] just what I'm noticing [Sun Aug 24 16:54:29 2014] can you back up and give me more context of what you are trying to do and what you expect to have ben wrong? [Sun Aug 24 16:54:34 2014] * is kinda checked out at the moment [Sun Aug 24 16:54:42 2014] you mean, with that code I linked you? [Sun Aug 24 16:55:30 2014] es [Sun Aug 24 16:55:44 2014] so, I want to have a category based on setoids so that I can be flexible in the notion of equality [Sun Aug 24 16:55:59 2014] I want this primarily because in order to have a category of hyperfunctions, I need coinductive equality, not inductive equality [Sun Aug 24 16:56:11 2014] with setoids, I can just inject my hstream_eq equality and all is good [Sun Aug 24 16:56:28 2014] but this means that to make Hom, I need to map C^op x C to the category of Setoids, not to plain Sets [Sun Aug 24 16:56:45 2014] and the category of Setoids needs to be based on function equivalence, rather than "equality on the nose" [Sun Aug 24 16:57:03 2014] otherwise, I run into a scenario where given f ≈ g, I need to prove compose f = compose g, which I just can't do [Sun Aug 24 16:57:07 2014] with equivalence on both sides, I can [Sun Aug 24 16:57:22 2014] google hangout real quick, easier =) [Sun Aug 24 16:57:24 2014] however, while this works great for Hom, it breaks simpler things [Sun Aug 24 16:57:25 2014] ok [Sun Aug 24 17:15:33 2014] johnw: It's approximately [eauto with typeclass_instances]. There are a few subtle differences (backtracking across evar instantiations across multiple goals is handled slightly differently) and a few very, very, very subtle differences (I think the algorithm it uses to look things up and what it unfolds are slightly different in a way that I've seen show up in performance bugs and nothing else). But, in general, just look at [Print HintDb [Sun Aug 24 17:15:33 2014] typeclass_instances] and [Set Typeclasses := debug.] (I think that's the right invocation?). [Sun Aug 24 17:18:55 2014] ooh, excellent, I'll try that jgross [Sun Aug 24 17:29:08 2014] edwardk: proved! [Sun Aug 24 17:29:42 2014] johnw: gratz =) [Sun Aug 24 17:29:54 2014] johnw: what was the last step? [Sun Aug 24 17:30:01 2014] https://gist.github.com/a2ee37dfaa575d12672b [Sun Aug 24 17:30:06 2014] I was just missing a destruct [Sun Aug 24 17:30:13 2014] fair nuff [Sun Aug 24 17:30:18 2014] story of my life [Sun Aug 24 17:34:29 2014] when I have trans_sym_co_inv_impl_morphism on one side of my equality, what is Coq expecting me to show? [Sun Aug 24 17:37:16 2014] Is there a way to use "Check" within a definition? I want to double check the type of something mid-definition because I am getting confused. [Sun Aug 24 17:38:58 2014] edwardk: same problem with Hom btw [Sun Aug 24 17:39:05 2014] have to prove f ≈ f' → f = f' [Sun Aug 24 17:39:15 2014] but here equivalence in C is unknown [Sun Aug 24 17:45:00 2014] you're outta luck johnw [Sun Aug 24 17:45:10 2014] haha [Sun Aug 24 17:45:12 2014] I noticed [Sun Aug 24 17:45:15 2014] it's gonna be false in general [Sun Aug 24 17:45:48 2014] chirpsalot: I'm afraid Check is a toplevel command that requires a term argument [Sun Aug 24 17:46:09 2014] you can try Hypothesis my_current_context. [Sun Aug 24 17:46:14 2014] Check my_test_term [Sun Aug 24 17:46:20 2014] Ah, thanks. [Sun Aug 24 17:46:23 2014] or try building your term interactively [Sun Aug 24 17:46:29 2014] Yeah. [Sun Aug 24 17:46:43 2014] It's just a pain to lift all of the context stuff out. [Sun Aug 24 17:47:47 2014] I did figure out my problem, though :). So now I'm not too bitter about that... Until next time. [Sun Aug 24 17:48:36 2014] one trick is to make a goal equal to the type of your term [Sun Aug 24 17:48:52 2014] then use "refine" to put your term, with _ where you aren't sure [Sun Aug 24 17:49:06 2014] that builds your context automagically [Sun Aug 24 17:50:00 2014] I am not sure I know enough of the terminology yet to fully grok what you are saying :(. [Sun Aug 24 17:50:36 2014] Definition myadd : nat -> nat -> nat. [Sun Aug 24 17:50:37 2014] * just got to the MoreCoq section of Coq SF. http://www.cis.upenn.edu/~bcpierce/sf/current/MoreCoq.html [Sun Aug 24 17:51:21 2014] refine (fun x y => _ + x) [Sun Aug 24 17:51:24 2014] . [Sun Aug 24 17:51:43 2014] cody__: so, here's the problem I have in general [Sun Aug 24 17:52:31 2014] johnw: hit me [Sun Aug 24 17:52:50 2014] given that f ≈ f' in some category C, then I have a category of hom-sets, where the morphisms between hom-sets are composition. How can I show that for two equivalence morphisms in C, the arrows representing compositions to/from those hom-sets are equivalent in Set? [Sun Aug 24 17:53:24 2014] right now I'm defining equivalence in Set as: [Sun Aug 24 17:53:25 2014] Definition func_eqv {a b} (f g : a → b) : Prop := ∀ x, f x = g x. [Sun Aug 24 17:53:34 2014] but that doesn't work if f and g are (compose f) and (compose f') from above [Sun Aug 24 17:54:06 2014] um [Sun Aug 24 17:54:10 2014] i'm confused [Sun Aug 24 17:54:19 2014] you're trying to prove the Yoneda Lemma? [Sun Aug 24 17:54:46 2014] no [Sun Aug 24 17:54:56 2014] just that the Hom functor fulfills the "fmap_respects" law [Sun Aug 24 17:55:12 2014] which says that f ≈ f' → fmap f ≈ fmap f' [Sun Aug 24 17:55:36 2014] can you show me the code? [Sun Aug 24 17:56:22 2014] https://github.com/jwiegley/coq-haskell [Sun Aug 24 17:56:35 2014] func_eqv is in Category.v, and fmap_respects and Hom are in Functor.v [Sun Aug 24 17:58:58 2014] I'm afraid I can't find Hom [Sun Aug 24 18:01:02 2014] in Functor.v [Sun Aug 24 18:01:02 2014] your definition of EqualFunctors is a bit strange as well [Sun Aug 24 18:01:17 2014] https://github.com/jwiegley/coq-haskell/blob/master/Functor.v#L439 [Sun Aug 24 18:01:29 2014] I stole that from the coq-categories repo [Sun Aug 24 18:01:46 2014] hmm [Sun Aug 24 18:01:59 2014] I have a feeling that since I'm using setoids, I shouldn't need EqualFunctors [Sun Aug 24 18:02:05 2014] since I already have notions of equivalence everywhere [Sun Aug 24 18:02:19 2014] also, for Hom, I bet I need to use the equivalence of partially applied compositions from C, not from Set [Sun Aug 24 18:02:38 2014] right [Sun Aug 24 18:02:45 2014] so I'm starting with: [Sun Aug 24 18:02:47 2014] fmap_respects := fun a b f f' H => @eqv C a b (compose f) (compose f') [Sun Aug 24 18:02:55 2014] which of course doesn't typecheck [Sun Aug 24 18:03:14 2014] um [Sun Aug 24 18:03:27 2014] let me think for a second [Sun Aug 24 18:04:00 2014] basically you're trying to prove that the hom-functor is indeed a functor [Sun Aug 24 18:04:05 2014] yep [Sun Aug 24 18:04:18 2014] and part of doing so is that fmap respects equivalences [Sun Aug 24 18:04:57 2014] by default, it's choosing Set's version of equivalence, which I cannot prove (and rightfully so) [Sun Aug 24 18:05:09 2014] yes i see [Sun Aug 24 18:05:13 2014] just a second [Sun Aug 24 18:06:03 2014] you need [C, Set]'s version of equivalence rather [Sun Aug 24 18:06:05 2014] no? [Sun Aug 24 18:06:34 2014] this is for the partially applied case [Sun Aug 24 18:06:47 2014] for the non-partially applied case, yes [Sun Aug 24 18:06:57 2014] that's why the instance for Hom has a nested record in there [Sun Aug 24 18:07:59 2014] i.e., you give me an object from C^op, and I'll give you a covariant functor from C → Sets [Sun Aug 24 18:08:30 2014] yea [Sun Aug 24 18:08:38 2014] so now, given equivalence of morphisms in C, I need to show that fmap'ing those morphisms into Set preserves equivalence [Sun Aug 24 18:08:54 2014] I have the nasty feeling the Hom functor isn't a functor in the sense you want it to [Sun Aug 24 18:09:04 2014] it's only a functor over "setoids" [Sun Aug 24 18:09:11 2014] right [Sun Aug 24 18:09:16 2014] I'm OK with that [Sun Aug 24 18:09:19 2014] i.e. sets equipped with an equivalence relation [Sun Aug 24 18:09:24 2014] Sets here should be the category of setoids [Sun Aug 24 18:09:33 2014] very probably [Sun Aug 24 18:09:35 2014] ah, hmmm [Sun Aug 24 18:09:42 2014] so maybe my func_eqv is too specialized [Sun Aug 24 18:10:04 2014] It's annoying because it forces you to change Sets [Sun Aug 24 18:10:09 2014] see https://github.com/jwiegley/coq-haskell/blob/master/Category.v#L653 [Sun Aug 24 18:10:17 2014] which may not be a lot of work depending on how much you use it [Sun Aug 24 18:10:27 2014] i wonder if I need to take in eqv as a parameter to that instance [Sun Aug 24 18:10:48 2014] rather than assuming that ∀ x, f x = g x is good enough to establish equivalence of f and g [Sun Aug 24 18:11:01 2014] you'd need to change ob to pairs Type*some_equivalence [Sun Aug 24 18:11:02 2014] since f and g may not be functions, but rather morphisms from some aribtrary category embedded in Sets [Sun Aug 24 18:11:10 2014] ahhhh [Sun Aug 24 18:11:15 2014] yes, now I see where you're going [Sun Aug 24 18:11:24 2014] and hom to functions that respect the equivalence [Sun Aug 24 18:11:29 2014] right [Sun Aug 24 18:11:41 2014] then I'd have a suitable space for embedding hom-sets [Sun Aug 24 18:11:52 2014] yes [Sun Aug 24 18:11:57 2014] ok, in that case then I'll make yet another category called Coq which is not a setoid at all [Sun Aug 24 18:12:04 2014] because I have need of both of these things [Sun Aug 24 18:12:21 2014] really? [Sun Aug 24 18:12:23 2014] how come? [Sun Aug 24 18:12:31 2014] so, Sets I need for Hom and the more categorical stuff I want to prove [Sun Aug 24 18:12:45 2014] the category Coq I need to model things that more closely hew to what you see in Haskell [Sun Aug 24 18:12:51 2014] without having to bend over backwards everywhere [Sun Aug 24 18:13:10 2014] in Coq, equivalence is just equality assuming functional extensionality [Sun Aug 24 18:13:24 2014] but in Sets, equivalence must respect the origin of objects [Sun Aug 24 18:13:30 2014] ok [Sun Aug 24 18:13:47 2014] i wonder if setoids is worth it [Sun Aug 24 18:13:53 2014] Yes in set theory the two categories are the same [Sun Aug 24 18:14:01 2014] there is only one reason I wanted them [Sun Aug 24 18:14:17 2014] in order to build the category of hyperfunctions, I need to use coinductive equality rather than regular equality [Sun Aug 24 18:14:22 2014] what was that? [Sun Aug 24 18:14:29 2014] ah yes ok [Sun Aug 24 18:14:41 2014] if I drop setoids, I'm rather restricted in what I can talk about [Sun Aug 24 18:14:46 2014] honestly coq support for relations is quite good [Sun Aug 24 18:14:52 2014] yes [Sun Aug 24 18:14:58 2014] it's just a lot of groundwork to setup [Sun Aug 24 18:15:01 2014] but I do like the flexibility [Sun Aug 24 18:15:16 2014] for example, see https://github.com/jwiegley/coq-haskell/blob/master/Hyper.v#L127 [Sun Aug 24 18:15:25 2014] I think it's the right way to go [Sun Aug 24 18:15:49 2014] actually, no, the more important example is https://github.com/jwiegley/coq-haskell/blob/master/Hyper.v#L233 [Sun Aug 24 18:16:04 2014] there are at least 3 ways of modeling hyperfunctions, and Coq can encode two of them [Sun Aug 24 18:16:19 2014] HMachines are inductive, HStreams are coinductive [Sun Aug 24 18:17:59 2014] jgross: in https://github.com/jwiegley/coq-haskell/blob/master/Hyper.v#L223, how do I ask Coq to always prefer ∘ from Sets if no context is given as an argument? [Sun Aug 24 18:18:03 2014] either is probably gonna have drawbacks [Sun Aug 24 18:18:16 2014] cody__: yes, I'm already finding that to be the case :) [Sun Aug 24 18:18:41 2014] with HStream, coinduction can be a pain [Sun Aug 24 18:19:09 2014] with HMachine, that type parameter 'u' (which is hidden away using rank-2 polymorphism in Haskell) is a major pain [Sun Aug 24 18:20:23 2014] there's a nasty axiom you can probably assume [Sun Aug 24 18:20:44 2014] something like "bisim -> =" [Sun Aug 24 18:21:00 2014] that would allow you to work with the "Strict Set" [Sun Aug 24 18:21:17 2014] but you would have to undo all your good work and take a strict = on Hom sets [Sun Aug 24 18:21:29 2014] I would encourage you to work with Setoids [Sun Aug 24 18:21:37 2014] but I know it's hard work [Sun Aug 24 18:22:27 2014] ok, I'll keep going [Sun Aug 24 18:22:31 2014] I'd like more familiarity with them anyway [Sun Aug 24 18:22:37 2014] it's a good tool to have in the toolbox [Sun Aug 24 18:22:51 2014] off to dinner, thanks for your help cody__! I think you've unstuck me [Sun Aug 24 18:23:04 2014] um [Sun Aug 24 18:23:07 2014] you're welcome [Sun Aug 24 18:23:26 2014] though I feel like all I said was: you need to change some basic definitions and work really hard [Sun Aug 24 19:25:46 2014] johnw: [unfold trans_sym_co_inv_impl_morphism]? [Sun Aug 24 19:25:46 2014] johnw: Is there a way to use "Check" within a definition? <- use [$(idtac defn; admit)$]. You'll need to get enough of your definition type-checking that admitting the broken piece is enough to get it to go through, but that should show you the thing you want to see. Or [$(let T := type of defn in idtac T; admit)$]. Or you might need [$(let term := constr:(defn) in let T := type of term in idtac T; admit)$]. [Sun Aug 24 19:30:00 2014] johnw: how do I ask Coq to always prefer ∘ from Sets <- make [Sets] have prioity 0 ([Instance Sets : Category | 0 := ...]), and give all other instances prioity 1 or higher (default is the number of typeclass arguments the instance has) [Sun Aug 24 19:37:25 2014] johnw: Rather than using setoids, you should develop the theory of higher coinductive types, or a sane equality for coinductives. :-P (Is axiomatizing HStream_eq -> eq really that terrible? You should be able to convince yourself in the metatheory that any function out of HStream will respect HStream_eq (because, for cofixpoint functions, you can induct on your proof of HStream_eq, and for non-cofix functions, you can destruct the proof [Sun Aug 24 19:37:25 2014] whatever finite number of times the non-cofix function does. And then you do magic univalence-like things to get it to work with crazy dependent type families like [eq].) And that's basically the definition of [eq]. Furthermore, if you make your axiom that the function [eq -> HStream_eq] is an equivalence, then you can make your axiom disappear whenever you transport across it, in much the same way that we currently make univalence disappear [Sun Aug 24 19:37:25 2014] in HoTT/HoTT. [Sun Aug 24 20:43:20 2014] jgross: thank you so much [Sun Aug 24 20:43:27 2014] jgross: you've been invaluable to learning all of this machinery [Sun Aug 24 20:43:59 2014] jgross: hmm.. maybe setoids are too much then [Sun Aug 24 20:44:07 2014] jgross: since I don't need them for 95% of what I want this code for [Sun Aug 24 20:44:20 2014] jgross: ok, I'll shunt this development into a branch and go back to the simpler form of equality where everything was working [Sun Aug 24 20:47:16 2014] hrmph, I am in the situation that I need to give a witness, but I don't exactly have a value I can give the witness, just a proposition pertaining to it [Sun Aug 24 20:47:24 2014] which I suppose would make the witness nonconstructive [Sun Aug 24 20:47:32 2014] which I guess would make it... not really a witness [Sun Aug 24 20:47:40 2014] can you use eexists? [Sun Aug 24 20:48:44 2014] dunno. There is probably a way to avoid this... [Sun Aug 24 20:50:22 2014] looking at http://www.cis.upenn.edu/~bcpierce/sf/current/Imp.html#lab431 and I've used for the theorem: forall c st, no_whilesR c -> exists st', c / st || st' [Sun Aug 24 20:51:23 2014] and I'm at the case of showing that for ;; (sequencing), but I am struggling to figure out how to construct a value as a witness [Sun Aug 24 20:51:44 2014] as ceval is not a function [Sun Aug 24 20:52:15 2014] well... I guess there is a function which covers some of its behavior [Sun Aug 24 20:52:19 2014] I'll shut up for a bit [Sun Aug 24 20:53:46 2014] what have you got so far? [Sun Aug 24 20:54:12 2014] trying to use ceval_fun_no_while to construct a witness [Sun Aug 24 20:56:52 2014] which differs anywhere there is a 'while', but no_whilesR guarantees none are present, but I may have to show explicitly that no_whilesR c -> (ceval c st (ceval_fun_no_while c st)) [Sun Aug 24 21:51:24 2014] edwardk: jgross convinced me to lay off setoids, so everything I was having trouble with is no longer a trouble; he says to just axiomatize inductive vs. coinductive equality [Sun Aug 24 21:51:40 2014] heh, welcome back [Sun Aug 24 21:52:34 2014] my beautifully short proof of surj_epi is long again, though [Sun Aug 24 21:53:15 2014] well, not that much longer [Sun Aug 24 21:56:40 2014] edwardk: so now I know how to decide which global instance is selected [Sun Aug 24 22:04:45 2014] I read that as "lay off steroids". [Sun Aug 24 22:04:49 2014] I should go to bed. [Sun Aug 24 22:06:44 2014] johnw: Just wait until you move to hProp, which is predicative. Then your proof of surj_epi will be much, much longer. (https://github.com/HoTT/HoTT/blob/master/theories/hit/epi.v#L72, https://github.com/HoTT/HoTT/blob/master/theories/hit/epi.v#L163) [Sun Aug 24 22:20:08 2014] jgross: and the benefit of that approach is what, exactly? [Sun Aug 24 22:20:12 2014] fewer axioms? [Sun Aug 24 22:52:58 2014] johnw: Fewer axioms, and better computational behavior. Prop is broken, because Props can have multiple elements, but you can't prove it, and you can't disprove it. (Props are also erasable, which is subtly different from being an hProp.) I think hProp is roughly Prop + constructive_definite_description (http://coq.inria.fr/library/Coq.Logic.Description.html) + proof_irrelevance (http://coq.inria.fr/library/Coq.Logic.ProofIrrelevance.html) ( [Sun Aug 24 22:52:58 2014] - impredicativity, but that's optional). [Mon Aug 25 02:26:13 2014] jgross: Why is that "broken"? I don't care much for Prop myself, but I'm not sure I understand what would be so bad about types whose number of elements isn't determined... [Mon Aug 25 02:27:05 2014] Oh, you mean for use as hProps? [Mon Aug 25 02:37:45 2014] I've got a vague general question about Coq. Knowing what you do about it, would you say it's useful for designing provably correct algorithms? Or is it more efficient/enjoyable to reason about algorithms with pen and paper? [Mon Aug 25 04:34:35 2014] begriffs: I would say it's extremely useful [Mon Aug 25 07:14:31 2014] Cale: Yes, I mean for use as hProps. [Mon Aug 25 08:04:33 2014] is it possible to do induction on a list without using nil as induction base? [Mon Aug 25 08:04:43 2014] i have a lemma that is true for all cases except nil [Mon Aug 25 08:05:01 2014] you have to prove l <> nil -> Lemma [Mon Aug 25 08:05:45 2014] yes but how? [Mon Aug 25 08:06:08 2014] the IH will say l <> nil -> lemma [Mon Aug 25 08:06:17 2014] with (x :: l) in the goal [Mon Aug 25 08:06:26 2014] and (x :: l) <> nil in the hypotheses [Mon Aug 25 08:06:29 2014] so what base case do you want? [Mon Aug 25 08:06:41 2014] length l > 0 [Mon Aug 25 08:06:42 2014] i guess [Mon Aug 25 08:06:48 2014] err [Mon Aug 25 08:06:50 2014] length l = 1 [Mon Aug 25 08:07:41 2014] so maybe you could try axiomatizing this induction scheme (forall x, P (x :: nil)) -> (forall x xs, xs <> nil -> P xs -> P (x :: xs)) -> (forall xs, xs <> nil -> P xs) [Mon Aug 25 08:07:55 2014] and if it helps prove your lemma, prove it [Mon Aug 25 08:08:08 2014] hm [Mon Aug 25 08:08:16 2014] i dont think i can axiomatize [Mon Aug 25 08:08:26 2014] is there a way to do it without axiomatizing? [Mon Aug 25 08:08:43 2014] you could go to the trouble of proving it before trying to use it to see if it helps [Mon Aug 25 08:08:47 2014] this is more time consuming [Mon Aug 25 08:08:56 2014] hm [Mon Aug 25 08:09:07 2014] well my results have to be solid, i cant just use axioms [Mon Aug 25 08:09:27 2014] isnt this a common issue though? [Mon Aug 25 08:09:56 2014] So I'm reading the sf book. I'm currently in the Basics chapter and at the exercise where I'm supposed to implement factorial. This works, but is it decent? http://pastebin.com/qmMKbVVt [Mon Aug 25 08:10:43 2014] roosbeef, I'm suggesting this: [Mon Aug 25 08:10:52 2014] (1) Declare this induction as an axiom [Mon Aug 25 08:10:58 2014] (2) attempt to prove your lemma with it [Mon Aug 25 08:11:21 2014] then If the induction scheme helped, go back and prove it so you don't have any unproved axioms left [Mon Aug 25 08:11:36 2014] if the induction scheme doesn't help, delete it and maybe ask more etc. [Mon Aug 25 08:15:05 2014] how do i axiomatize it? [Mon Aug 25 08:15:31 2014] as a lemma and then close with [Admitted]? [Mon Aug 25 08:15:42 2014] that works [Mon Aug 25 08:16:34 2014] ok im not sure about this but lets try :p [Mon Aug 25 08:17:10 2014] btw, what are you proving exactly? that is true for a whole list but not nil [Mon Aug 25 08:18:31 2014] i have a data type that can be conceptualized in both string and tree form [Mon Aug 25 08:18:48 2014] nil is equal to (nil :: nil) in tree form [Mon Aug 25 08:19:01 2014] so the length for nil in string form is less than the length in tree form [Mon Aug 25 08:19:19 2014] for all other strings, the length is greater than or equal [Mon Aug 25 08:19:34 2014] (which is the lemma i need) [Mon Aug 25 08:19:51 2014] what about proving your theorem just for strings which are the image of a tree->string function? [Mon Aug 25 08:20:09 2014] how would that work? [Mon Aug 25 08:20:36 2014] forall t, P (t_to_s t) [Mon Aug 25 08:20:43 2014] then you can use t's induction scheme [Mon Aug 25 08:21:04 2014] no that would be horrible :p [Mon Aug 25 08:21:11 2014] because the image function is huge [Mon Aug 25 08:22:17 2014] also the theorem im working on atm is to prove the image function followed by its inverse function maps reflexively [Mon Aug 25 08:22:35 2014] interesting [Mon Aug 25 08:22:48 2014] (just to prove that the function is working correctly) [Mon Aug 25 08:25:20 2014] mads-: Err, so what is your question? [Mon Aug 25 08:29:53 2014] hodapp: I am pretty new to coq. Is that also the way you would define factorial? [Mon Aug 25 08:31:57 2014] ok well thanks anyway vanila :) im going to think about this [Mon Aug 25 08:32:19 2014] okay good luck if you just paste your whole code i could look at it too [Mon Aug 25 08:33:24 2014] nah dont worry about it [Mon Aug 25 08:33:31 2014] maybe for a bigger issue [Mon Aug 25 08:33:45 2014] it wouldnt be worth the effort of installing all the libs required [Mon Aug 25 08:34:15 2014] oh I forgot you use CoLoR or such [Mon Aug 25 08:34:40 2014] yea and Cantor [Mon Aug 25 09:11:04 2014] mads-: I think it'd end up similar for me, yes. [Mon Aug 25 09:11:14 2014] mads-: what led you to SF anyway? [Mon Aug 25 09:16:44 2014] Hello everyone [Mon Aug 25 09:16:57 2014] I am trying to compile the code http://lpaste.net/109975 [Mon Aug 25 09:17:03 2014] but I am getting some error [Mon Aug 25 09:17:17 2014] File "./Induction.v", line 359, characters 14-60: Syntax Error: Lexer: Unterminated string [Mon Aug 25 09:17:47 2014] Could some one please tell me what is wrong with code. [Mon Aug 25 09:24:21 2014] Some one please. [Mon Aug 25 09:24:33 2014] the warnings seem to be caused by the " at the end of the commented out minus_diag theorem [Mon Aug 25 09:25:07 2014] not sure why coq should care about it [Mon Aug 25 09:27:05 2014] ijp: I have removed that part and now it's compiled [Mon Aug 25 09:27:14 2014] but it was comment [Mon Aug 25 09:27:22 2014] ijp: Thank you! [Mon Aug 25 09:43:58 2014] hodapp: It's linked from my course homepage. I'm starting the course tomorrow. Seems quite exciting [Mon Aug 25 09:47:09 2014] oh, a course uses this? [Mon Aug 25 09:47:37 2014] cool mads- good luck :) [Mon Aug 25 09:48:14 2014] yeah, it's called introduction to functional programming. [Mon Aug 25 09:48:34 2014] So I guess it's a mix of learning functional programming and proofing the properties [Mon Aug 25 09:51:25 2014] I need to start a CS degree or something... I'm reading all these papers and textbooks anyhow. [Mon Aug 25 09:52:24 2014] hodapp: any exciting papers on functional programming or similar? [Mon Aug 25 09:52:36 2014] just going to be back later. going home now :) [Mon Aug 25 09:52:41 2014] mads-: I'll go dig around later and send any that I've liked your way :) [Mon Aug 25 09:52:49 2014] mads-: just idle around here so I can find you [Mon Aug 25 11:27:36 2014] hodapp: I am on a irssi screen, so I will be here all day :) [Mon Aug 25 11:34:39 2014] mads-: whaaaat? What course / university / college / whatever you call it wherever you are? [Mon Aug 25 11:38:04 2014] mads-: also that is one fine factorial function y'alls got there ;). If I wasn't using the SF defined naturals, and using the Coq built ins instead, then I would probably use "1" rather than "S 0", but maybe that's just me. [Mon Aug 25 11:38:14 2014] * is also new to Coq. [Mon Aug 25 11:40:33 2014] mads-: oh, you did mention what the course was -- guess I am daft. Is it just Coq on the syllabus? We have a similar course here "non-procedural programming languages". It generally introduces 2 languages... Common lisp and prolog :|. Sometimes it's Scheme (Racket) and Haskell, but that prof is sadly retiring. [Mon Aug 25 11:42:16 2014] chirpsalot: sounds pretty dire. [Mon Aug 25 11:46:43 2014] ianjneu: yeah... I really wish Common Lisp was just replaced with Racket. They try to cripple CL to a "functional" subset and it just doesn't suit it. [Mon Aug 25 11:47:35 2014] I didn't mind Prolog, though. It's kind of cute for "pfff, this problem is NP hard anyway" things. [Mon Aug 25 11:48:13 2014] Serious prolog users use it in a very non-logical way anyway. Cut everywhere. [Mon Aug 25 11:48:19 2014] I would _love_ it if we had a course that did Coq. [Mon Aug 25 11:48:29 2014] I did not like cut D:. [Mon Aug 25 11:48:53 2014] I did like that Prolog had pattern matching, though. I missed that so much when writing crippled common lisp. [Mon Aug 25 11:49:12 2014] PL is a discipline, not a zoo. Too many colleges don't know that. [Mon Aug 25 11:49:30 2014] Racket's match is pretty great. [Mon Aug 25 11:50:10 2014] Common lisp has some pattern matching stuff as well, but we weren't allowed to use it. They literally gave us a list of like 15 functions that we were allowed to use. [Mon Aug 25 11:50:16 2014] I have a PR adding named struct fields so you don't have to specify patterns positionally anymore. [Mon Aug 25 11:50:29 2014] PR? [Mon Aug 25 11:50:34 2014] pull-request [Mon Aug 25 11:50:45 2014] For Racket? [Mon Aug 25 11:50:47 2014] Racket is alive and inviting :) [Mon Aug 25 11:50:52 2014] Cool! [Mon Aug 25 11:51:22 2014] Racket, from what I have seen, is SOOOOOOO much better than Common Lisp. Common Lisp is like trying to program with a museum. [Mon Aug 25 11:51:50 2014] CL has its strengths too. [Mon Aug 25 11:52:01 2014] CLOS is mighty fine. [Mon Aug 25 11:52:05 2014] Absolutely. [Mon Aug 25 11:52:14 2014] But it's also got a lot of old warts that show. [Mon Aug 25 11:52:46 2014] Ya, conflating 0, empty list and false is a sign of dementia. [Mon Aug 25 11:52:59 2014] Like all of the namespace weirdness, and how all symbols are sort of capitalized...? [Mon Aug 25 11:53:10 2014] Very weird. [Mon Aug 25 11:53:17 2014] naming things is hard. [Mon Aug 25 11:53:22 2014] Yeah. [Mon Aug 25 11:53:25 2014] brb [Mon Aug 25 11:54:12 2014] I mean, it's got a lot of stuff for backwards compatibility from ages ago. It's very strange to have a language that uses its own style of format strings as opposed to just using the C-style ones ;). [Mon Aug 25 11:55:23 2014] Racket just seems more lambda calculusy, and clean. [Mon Aug 25 12:03:52 2014] Racket isn't Scheme because it moved away from the timid minimalism that kept Schemes more like calculi than usable tools. [Mon Aug 25 12:05:53 2014] huh, never used Racket myself. [Mon Aug 25 12:09:07 2014] hodapp: It's not as generic as Clojure, but its syntax system, rigorous documentation and vibrant community are top notch. [Mon Aug 25 12:09:27 2014] not as generic? [Mon Aug 25 12:09:55 2014] hodapp: in terms of generic functions. It still has a very Schemey monomorphic programming feel to it. [Mon Aug 25 12:10:25 2014] You write vector-ref, list-ref, struct-ref, etc instead of just ref and depend on dispatch. [Mon Aug 25 12:11:30 2014] Generics were recently added (in the past year or so), so they're not as pervasive in APIs as some people might expect. [Mon Aug 25 12:11:35 2014] strictly, only standard scheme is timid and minimalistic [Mon Aug 25 12:11:48 2014] the rest is a mine field of unportability [Mon Aug 25 15:57:10 2014] chirpsalot: lol [Mon Aug 25 15:57:25 2014] "trying to program with a museum" -- awesome [Mon Aug 25 16:22:26 2014] johnw: I keep saying that and nobody has recognized my wit :P. [Mon Aug 25 16:24:24 2014] it is now recognized; and as a former CLer, even appreciated [Mon Aug 25 16:25:46 2014] johnw: maybe that's the problem -- most people haven't used Common Lisp so they don't get it :P [Mon Aug 25 20:40:58 2014] hrmph, stuck on the same problem, and in a situation where I sort of need to destruct on two... related things [Mon Aug 25 20:42:15 2014] it's basically a boolean, but it's there as a bexp [Mon Aug 25 20:42:25 2014] can i see the code? [Mon Aug 25 20:42:36 2014] maybe i can help [Mon Aug 25 20:42:51 2014] first off, this is for Imp.v in SF [Mon Aug 25 20:43:24 2014] ah think i broke my ability to load SF by getting the head version of coq [Mon Aug 25 20:43:29 2014] http://lpaste.net/110017 [Mon Aug 25 20:43:42 2014] Error: The constructor nil (in type list) expects 1 argument. [Mon Aug 25 20:43:44 2014] frustrating [Mon Aug 25 20:43:47 2014] is this the same problem you were stuck on before? [Mon Aug 25 20:43:56 2014] yeah sorry johnw I forgot the fix :( [Mon Aug 25 20:44:00 2014] johnw: yes, sadly. [Mon Aug 25 20:44:00 2014] before i managed to apply it [Mon Aug 25 20:44:09 2014] oh you didnt mean me [Mon Aug 25 20:44:23 2014] did you try inversion on H, instead of induction? [Mon Aug 25 20:44:59 2014] yes; not sure where it's supposed to get me that is different [Mon Aug 25 20:45:04 2014] let me try proving this [Mon Aug 25 20:47:32 2014] im gettingt the latest head [Mon Aug 25 20:47:40 2014] hopefully they unbroke using any other code [Mon Aug 25 20:50:01 2014] hello. Is it provable at all? : Goal forall (A:Type) (B:A=A) v, match B in (_=y) return y with eq_refl => v end = v. [Mon Aug 25 20:50:47 2014] gdsfh, no [Mon Aug 25 20:51:08 2014] why? [Mon Aug 25 20:51:24 2014] Coq isn't capable of dealing with proper dependent type pattern matching [Mon Aug 25 20:52:08 2014] you need 'uniqueness of identity proofs' for that, which your goal also requres to prove [Mon Aug 25 20:56:02 2014] * . o O ( proper dependent type pattern matching? ) [Mon Aug 25 20:57:40 2014] in this pattern matching B can be only eq_refl, so the whole construction can be simplified (if one applies usual logic of evaluation). What happens here really? [Mon Aug 25 20:58:31 2014] gdsfh, the thing is you can't do pattern matching on a dependent type data structure like that in Coq [Mon Aug 25 20:58:48 2014] this would require an extra axiom which we don't have [Mon Aug 25 21:04:25 2014] hodapp: I'd need your definitions and stuff if I were to give any input but I'd get if you don't want to post it [Mon Aug 25 21:04:59 2014] vanila: strange, other dependent pattern matchings work ok, this one fails. I'm going to ask this question in coq-club, so maybe people who exactly know metatheory behind "match" will enlighten me. Thanks for answer. [Mon Aug 25 21:05:14 2014] gdsfh, you could also ask me [Mon Aug 25 21:06:37 2014] hodapp: for you to finish: https://gist.github.com/6288fe57fc6799a7194e [Mon Aug 25 21:06:49 2014] but that shoudl point you in the right direction [Mon Aug 25 21:06:52 2014] the rest should be mechanical [Mon Aug 25 21:07:57 2014] gdsfh: are you using match with 'return'? [Mon Aug 25 21:08:12 2014] vanila: this is pretty much just Imp.v [Mon Aug 25 21:08:31 2014] ah, you are [Mon Aug 25 21:08:34 2014] hodapp, I'd have to add my own definitions to Imp.v [Mon Aug 25 21:08:42 2014] hodapp: ^^ [Mon Aug 25 21:08:43 2014] they may not be the same as yours [Mon Aug 25 21:08:43 2014] vanila: I'll do so. Why this pattern matching (or data type) is so special so it can't be simplified, also why "destruct B" doesn't work here? [Mon Aug 25 21:09:33 2014] johnw: there exists "return" in my match, but not by my will. [Mon Aug 25 21:10:59 2014] vanila: why do you say that Coq can't do proper dependent type pattern matching? [Mon Aug 25 21:11:18 2014] johnw, the lack of proof irrelevance [Mon Aug 25 21:11:24 2014] axiomatize it [Mon Aug 25 21:11:29 2014] that is not computational [Mon Aug 25 21:11:58 2014] so you're saying we need higher inductive types to do this without axioms? [Mon Aug 25 21:12:10 2014] gdsfh, so you have a dependent typed family (eq or "=") with a dependency between the indices - to do case analysis or destruct you need to apply the eliminator for the data type meaning that you need to create a lambda that generalizes out that particular index [Mon Aug 25 21:12:22 2014] gdsfh, but it's impossible to do this because the lambda abstraction cannot be made in a well typed way [Mon Aug 25 21:12:56 2014] you need an axiom like proof irrelevance or equivalently uniqueness of identity proofs (which is much closer to your situation) [Mon Aug 25 21:13:09 2014] a workaround would be if you had decidable equality on A [Mon Aug 25 21:13:21 2014] but that doesn't let you prove *this* goal, just a similar weaker one [Mon Aug 25 21:14:02 2014] johnw, we need computational proof irrelevance to properly eliminate dependent pattern matching [Mon Aug 25 21:14:18 2014] let's just posit computational irrelevance and be done with it :) [Mon Aug 25 21:14:59 2014] ir's not possible to fix this by adding axioms to the theory, because then nothing we have will beta reduce when used inside types [Mon Aug 25 21:36:48 2014] vanila: seems like I understood it, thank you. [Mon Aug 25 21:42:52 2014] * stares blankly [Mon Aug 25 21:43:17 2014] hodapp: did what I paste you help? [Tue Aug 26 03:48:52 2014] can anyone help me prove this http://lpaste.net/110034 ? [Tue Aug 26 03:57:58 2014] osa1: what have you tried? [Tue Aug 26 03:59:08 2014] btw, did you finish the other theorem? about min? [Tue Aug 26 03:59:44 2014] jrw: yeah I finished it [Tue Aug 26 03:59:48 2014] cool. [Tue Aug 26 04:00:15 2014] jrw: I tried induction on n and l but I don't think it's possible to move from inductive case to general case. [Tue Aug 26 04:00:38 2014] osa1: right, straight induction won't work here. what am I going to say next? :p [Tue Aug 26 04:01:00 2014] invariants? :) [Tue Aug 26 04:02:20 2014] yeah, something like that [Tue Aug 26 04:02:30 2014] I was thinking "generalizing the inductive hypothesis" [Tue Aug 26 04:03:08 2014] hm. I think I'm using it in most general form but I'm not sure. let me make sure that's the case. [Tue Aug 26 04:03:40 2014] so if I just start with "induction n" without doing any intros first I guess that'll give me most general form, right? [Tue Aug 26 04:04:07 2014] yeah, but that's not really what I mean [Tue Aug 26 04:04:17 2014] thought that is also generalizing [Tue Aug 26 04:04:21 2014] I mean even more general [Tue Aug 26 04:04:29 2014] you need to fundamentally strengthen the theorem to prove it [Tue Aug 26 04:07:19 2014] how to "strengthen" a theorem? [Tue Aug 26 04:08:02 2014] hm, maybe it's best to just see what I mean in this case [Tue Aug 26 04:08:10 2014] eventually you'll see the pattern I'm getting at [Tue Aug 26 04:08:34 2014] so in this case, how would you describe the behavior of rev_at_aux in general? what does it do? [Tue Aug 26 04:08:42 2014] at a very high level. [Tue Aug 26 04:09:56 2014] I'd say it reverses the list at index n -- meaning that first n elements stay same, rest is reversed. [Tue Aug 26 04:10:00 2014] yay [Tue Aug 26 04:10:11 2014] exactly [Tue Aug 26 04:10:14 2014] I think we should prove that [Tue Aug 26 04:10:15 2014] work is done, time to play. software foundations here I come... [Tue Aug 26 04:10:25 2014] and then we'll prove your lemma follows from that. [Tue Aug 26 04:11:31 2014] hm. do we have drop, take, splitAt etc. in stdlib to express this idea? [Tue Aug 26 04:11:43 2014] osa1: yeah, look at firstn and skipn [Tue Aug 26 04:13:58 2014] so this is my goal [ rev_at_aux n l = firstn n l ++ rev (skipn n l) ] [Tue Aug 26 04:14:12 2014] looks great. [Tue Aug 26 04:14:19 2014] that should be fairly straightforward by induction on l [Tue Aug 26 04:16:02 2014] yeah it was straightforward. [Tue Aug 26 04:16:08 2014] nice. [Tue Aug 26 04:16:26 2014] okay, now fiddle with your actual goal and see what you see. [Tue Aug 26 04:16:32 2014] okay [Tue Aug 26 04:16:38 2014] (you shouldn't need induction, but you'll need more lemmas.) [Tue Aug 26 04:16:58 2014] (and of course those lemmas might be proved by induction) [Tue Aug 26 04:22:27 2014] I think I need something like this: [n < length l -> head (skipn n l) = nth n l 0]. [Tue Aug 26 04:22:34 2014] yep [Tue Aug 26 04:22:39 2014] or maybe [skipn n l = h :: t -> nth n l 0 = h] [Tue Aug 26 04:22:53 2014] right, I like the second one. [Tue Aug 26 04:34:08 2014] osa1: done yet? :p [Tue Aug 26 04:35:12 2014] jrw: almost. just a little lemma left [Tue Aug 26 04:35:22 2014] nice. [Tue Aug 26 04:35:31 2014] it's very simple one but just not in stdlib or I can't find it [Tue Aug 26 04:36:02 2014] [H0 : (x :: x0) ++ rev (firstn n l) = h :: t] I'm trying to derive [x = h] and then I'm done. [Tue Aug 26 04:37:45 2014] yay [Tue Aug 26 04:38:16 2014] oh I left another lemma as admitted.. [Tue Aug 26 04:38:58 2014] hehe [Tue Aug 26 04:39:32 2014] I assume you figured out that [inversion] does what you want in that previous case. [Tue Aug 26 04:40:13 2014] jrw: http://lpaste.net/110035 [Tue Aug 26 04:40:16 2014] jrw: yeah [Tue Aug 26 04:41:08 2014] osa1: looks all done? nice! [Tue Aug 26 04:41:25 2014] nicely done [Tue Aug 26 04:41:30 2014] thanks! :) [Tue Aug 26 04:41:56 2014] are you interested at this point in learning to write shorter proofs? [Tue Aug 26 04:42:01 2014] here's my version: http://lpaste.net/110036 [Tue Aug 26 04:42:04 2014] johnw: of course! [Tue Aug 26 04:42:20 2014] yeah, like jrw's :) [Tue Aug 26 04:43:10 2014] jrw is using some tricks I haven't learned yet [Tue Aug 26 04:43:20 2014] [destruct _ eqn:?] <- this generates a fresh name for equality? [Tue Aug 26 04:43:25 2014] haha, some pretty ugly tricks. [Tue Aug 26 04:43:27 2014] osa1: yeah [Tue Aug 26 04:43:31 2014] the ? lets Coq pick the name [Tue Aug 26 04:43:40 2014] cool [Tue Aug 26 04:44:12 2014] johnw: what in particular hadn't you seen? [Tue Aug 26 04:44:25 2014] eauto with * [Tue Aug 26 04:44:29 2014] what does the * mean there? [Tue Aug 26 04:44:40 2014] wildcard [Tue Aug 26 04:44:43 2014] means all hint dbs [Tue Aug 26 04:44:46 2014] ahh [Tue Aug 26 04:44:55 2014] in this case, could be replaced by 'arith' [Tue Aug 26 04:45:00 2014] also, I'd never used eqn:?, although I could figure out what it mean [Tue Aug 26 04:45:01 2014] because that's what I'm intending to use. [Tue Aug 26 04:45:13 2014] but '*' is shorter :p [Tue Aug 26 04:45:14 2014] other than that, I've used everything else [Tue Aug 26 04:45:34 2014] cool. [Tue Aug 26 04:46:01 2014] oh, I hadn't used congruence before [Tue Aug 26 04:47:49 2014] congruence is great. I don't have great intuition for its limitations, but it can prove a lot of things about equalities. [Tue Aug 26 04:48:03 2014] nice, that was a great thing to add to my toolbox today [Tue Aug 26 04:48:08 2014] i've been wanting something like that [Tue Aug 26 04:48:14 2014] instead of doing a whole bunch of mechanical rewrites [Tue Aug 26 04:50:11 2014] one thing it's not good at is leveraging extra lemmas. [Tue Aug 26 04:50:12 2014] eauto with * looks great. I'll try to simplify my proofs a bit using it. I have a 507 lines long file full of proofs, I'll go over it step by step and try to replace things with auto/eauto with * or congruence. [Tue Aug 26 04:50:28 2014] two tactics that I haven't used yet: congruence and intuition. [Tue Aug 26 04:51:08 2014] osa1: one trick with eauto and auto (and there 'with *' variants) is to say info_eauto and info_auto instead [Tue Aug 26 04:51:14 2014] which prints a trace of simpler tactics [Tue Aug 26 04:51:23 2014] that are equivalent to its action [Tue Aug 26 04:51:40 2014] this can help you learn what eauto (especially 'with *') is doing under the hood [Tue Aug 26 04:51:42 2014] i've used intuition a lot [Tue Aug 26 04:51:47 2014] for example, what lemmas it used. [Tue Aug 26 04:52:15 2014] basically, if looking at all the logical statements in your goal and context make the goal inferrable, intuition will go through all the hoops necessary [Tue Aug 26 05:34:07 2014] without using functional extensionality, if my goal is forall x : X, (fun x' : X => y) = (fun x' : X => y'), is there a way to collapse that down to y = y'? [Tue Aug 26 05:48:36 2014] yeah [Tue Aug 26 05:49:23 2014] hint? [Tue Aug 26 05:50:20 2014] well, i don't know how you do it in Coq, but it should be from the functoriality of \y -> fun x' : X => y [Tue Aug 26 05:50:43 2014] (hott's sense functoriality) [Tue Aug 26 07:30:10 2014] I just started the induction chapter of sf, it tells me to Require Exports Basics. Where do I need to place Basics.vo for that to work? [Tue Aug 26 08:09:39 2014] * tries to comprehend proof irrelevance... [Tue Aug 26 09:03:27 2014] mads-: In the same directory as whatever else you’re doing. [Tue Aug 26 10:14:49 2014] alkabetz: thanks. [Tue Aug 26 10:15:41 2014] You’re welcome. :) [Tue Aug 26 10:34:04 2014] what's this tactic called and how is it working: [ tactic1 | tactic2 | tactic3 ] ? [Tue Aug 26 10:34:42 2014] foo; [ tactic1 | tactic2 | tactic3 ] says [Tue Aug 26 10:34:52 2014] foo generates three subgoals, solve the first one with tactic1, second one with tactic2, etc [Tue Aug 26 10:38:02 2014] thanks. any name given to this tactic/syntax? (just in case I want to search it in documentation) [Tue Aug 26 10:38:33 2014] http://coq.inria.fr/refman/Reference-Manual011.html#hevea_tactic178 [Tue Aug 26 10:39:03 2014] (I found it by looking at the tactic index) [Tue Aug 26 11:14:58 2014] wat "coqc: --dump-glob: no such file or directory" [Tue Aug 26 13:57:50 2014] what is lia? [Tue Aug 26 14:00:55 2014] linear integer arithmetic [Tue Aug 26 14:52:38 2014] why ->, |- etc. in my coqdoc generated html files are not pretty-printed using unicode chars? [Tue Aug 26 15:08:41 2014] any ideas? [Tue Aug 26 15:09:00 2014] I'm not disabling pretty printing and according to the documentation it should pretty print by default [Tue Aug 26 16:08:28 2014] whats a good setup for coq + vim? [Tue Aug 26 16:11:13 2014] osa1: it's the ; tactical [Tue Aug 26 16:12:21 2014] gratatatata: there's an awesome plugin at vim.org. [Tue Aug 26 16:13:10 2014] gratatatata: there are only two problems with it that I could find. 1) it has hard-coded colors so you need to change them by editing the source 2) you can't use some CoqIDE features but I don't remember what features [Tue Aug 26 16:14:13 2014] gratatatata: I'm using it for very long time now and it's great. when you have to use that features you can switch to CoqIDE temporarily. [Tue Aug 26 16:15:00 2014] gratatatata: there's also this https://github.com/the-lambda-church/coquille . this is more actively developed but last time I tried I didn't like it for several reasons [Tue Aug 26 16:15:20 2014] ah ok [Tue Aug 26 16:15:21 2014] thanks [Tue Aug 26 16:16:06 2014] do we have a chat bot in #coq to save some answers for FAQs and make it answer with a command? [Tue Aug 26 16:39:04 2014] jgross_: latest Coq HEAD is failing to build for me now; I get: codesign: command not found; does that ring any bells? [Tue Aug 26 16:42:18 2014] has anybody here used coquille + vim on windows? [Tue Aug 26 16:44:53 2014] what is the next leetest thing after coq? [Tue Aug 26 16:45:49 2014] coq + homotopy type theory? :) [Tue Aug 26 16:46:14 2014] oh [Tue Aug 26 16:46:25 2014] i tried reading that book [Tue Aug 26 16:46:38 2014] that's how leet it is; people try, and then they try again [Tue Aug 26 16:47:00 2014] mathematical hipsterism: I only know theoris I can't possibly explain [Tue Aug 26 16:47:26 2014] lol [Tue Aug 26 16:47:52 2014] alternatively: Reading stuff like Euler and Gauss (original texts) [Tue Aug 26 16:48:46 2014] anybody use this coquille thing on windows? [Tue Aug 26 16:49:33 2014] I've got (@eq A a b), (forall (a : A) (x y : P a), x = y), and p : P a, q : P b. Can I prove exists P a p = exists P b q? [Tue Aug 26 16:49:51 2014] try f_equal [Tue Aug 26 16:50:26 2014] It fails, can't unify (exists P a) with (exsits P b) [Tue Aug 26 16:50:45 2014] johnw: http://www.smbc-comics.com/?id=3278#comic [Tue Aug 26 16:50:50 2014] johnw: https://github.com/coq/coq/commit/9b0dbb30d653bf35145e1e77f0fecfc9d79aa81d. Do you have $ARCH=Darwin? [Tue Aug 26 16:51:28 2014] I am on Darwin, building under Nix [Tue Aug 26 16:52:21 2014] is it strictly necessary to codesign? [Tue Aug 26 16:52:59 2014] omg nix [Tue Aug 26 16:53:05 2014] Pierre Boutillier thinks you're on Mac OS and your binaries should be signed. Does this give you enough information to fill out the apropriate bug report? (If nothing else, you could submit one that says "the makefile should fallback gracefully in the absence of codesign") [Tue Aug 26 16:53:13 2014] never again [Tue Aug 26 16:53:14 2014] lol [Tue Aug 26 16:53:38 2014] jgross_: will do [Tue Aug 26 16:55:34 2014] napping, subst to use a=b then rewrite the x=y and reflexivity? if not can you paste an actual goal to look at in coq [Tue Aug 26 16:56:14 2014] jgross_: https://coq.inria.fr/bugs/show_bug.cgi?id=3548 [Tue Aug 26 16:56:44 2014] Nobody here uses coquille? [Tue Aug 26 16:56:50 2014] Lemma exist_eq {A} (P : A -> Prop) (P_single : forall a (x y : P a), x = y) : forall (a b : sig P), proj1_sig a = proj1_sig b -> a = b. [Tue Aug 26 16:56:50 2014] * <- Emacs [Tue Aug 26 16:57:17 2014] huh, subst uses the a=b while rewrite fails [Tue Aug 26 16:57:45 2014] ok i thought you meant something totally differnet sorry [Tue Aug 26 16:57:51 2014] misunderstood [Tue Aug 26 16:58:10 2014] you wont' be able to prove this theorem [Tue Aug 26 16:58:19 2014] it requires proof irrelevance [Tue Aug 26 16:58:38 2014] ah [Tue Aug 26 16:58:40 2014] sorry im wrong :) [Tue Aug 26 16:58:50 2014] I had a feeling it needed proof irrelevance [Tue Aug 26 16:58:57 2014] http://lpaste.net/110083 [Tue Aug 26 16:59:15 2014] P_single saved us here [Tue Aug 26 17:14:26 2014] ahaha.. trying to use the CoqIDE on windows... its soooo bad [Tue Aug 26 17:40:34 2014] gratatatata: have you tried ProofGeneral yet? [Tue Aug 26 18:40:21 2014] Are the types of constructors normalized? [Tue Aug 26 21:53:12 2014] /msg tolt File Edit Options Buffers Tools Help [Tue Aug 26 21:53:13 2014] # Sample Keter config file. Would generally be placed at /opt/keter/etc/keter-config.yaml. [Tue Aug 26 21:53:15 2014] [Tue Aug 26 21:53:18 2014] # Directory containing incoming folder, where to store logs, etc. Relative to [Tue Aug 26 21:53:19 2014] # the config file directory. [Tue Aug 26 21:53:22 2014] root: ../keter [Tue Aug 26 21:53:25 2014] [Tue Aug 26 21:53:28 2014] # Keter can listen on multiple ports for incoming connections. These ports can [Tue Aug 26 21:53:31 2014] # have HTTPS either enabled or disabled. [Tue Aug 26 21:53:35 2014] listeners: [Tue Aug 26 21:53:38 2014] # HTTP [Tue Aug 26 21:53:41 2014] # - host: "*4" # Listen on all IPv4 hosts [Tue Aug 26 21:53:44 2014] # port: 80 # Could be used to modify port [Tue Aug 26 21:53:47 2014] # HTTPS [Tue Aug 26 21:53:51 2014] - host: "*4" [Tue Aug 26 21:53:52 2014] port: 443 [Tue Aug 26 21:53:55 2014] key: aacs-us.com.key [Tue Aug 26 21:53:58 2014] certificate: aacs-us.com.csr [Tue Aug 26 21:54:01 2014] [Tue Aug 26 21:54:05 2014] # User to run applications as [Tue Aug 26 21:54:08 2014] [Tue Aug 26 21:54:08 2014] -.- [Tue Aug 26 21:54:11 2014] # setuid: scott [Tue Aug 26 21:54:14 2014] [Tue Aug 26 21:54:18 2014] # Get the user's IP address from x-forwarded-for. Useful when sitting behind a [Tue Aug 26 21:54:21 2014] # load balancer like Amazon ELB. [Tue Aug 26 21:54:25 2014] [Tue Aug 26 21:54:25 2014] # ip-from-header: true [Tue Aug 26 21:54:28 2014] [Tue Aug 26 21:54:31 2014] [Tue Aug 26 21:54:35 2014] [Tue Aug 26 21:54:38 2014] [Tue Aug 26 21:54:41 2014] [Tue Aug 26 21:54:44 2014] [Tue Aug 26 21:54:48 2014] [Tue Aug 26 21:54:51 2014] [Tue Aug 26 21:54:54 2014] [Tue Aug 26 21:54:55 2014] [Tue Aug 26 21:54:58 2014] [Tue Aug 26 21:55:01 2014] [Tue Aug 26 21:55:05 2014] [Tue Aug 26 21:55:08 2014] [Tue Aug 26 21:56:06 2014] TallerGhostWalt: I think you goofed :P [Tue Aug 26 22:02:05 2014] lol [Tue Aug 26 22:02:09 2014] yes, yes I did [Tue Aug 26 22:06:40 2014] Hi. I am in the tedious process of reading SF and I am wondering if I am doing it wrong or is it really that hard to learn Coq. This is my second or third attempt to read it and so far the most succesful but after the first couple of chapters I am still not able to prove the correctness of most of the stuff I know from maths, have no idea how does Coq check the stuff under the hood, and surely am not even close [Tue Aug 26 22:06:42 2014] to being able to prove correctness of any program (what was one of the main reasons I wanted to learn Coq). Am I doing something wrong or I am just too impatient and will never know Coq? [Tue Aug 26 22:07:34 2014] Erraunt, it is difficult [Tue Aug 26 22:07:51 2014] What mathematics do you want to formalize in Coq? [Tue Aug 26 22:08:09 2014] set theory to begin with [Tue Aug 26 22:08:18 2014] well there is sort of a problem with that [Tue Aug 26 22:08:58 2014] ? [Tue Aug 26 22:09:16 2014] Coq is based on type theory, so set theory might not "fit" well although you could axiomatize it and develop some basic theory [Tue Aug 26 22:09:30 2014] (because the two foundations are very different) [Tue Aug 26 22:09:55 2014] and secondly have you seen http://us.metamath.org/mpegif/mmset.html [Tue Aug 26 22:10:20 2014] it's really really time consuming and long to build up even simple parts of set theory rigiously [Tue Aug 26 22:11:34 2014] You might get to your goal of proving programs correct more efficiently if you study CPDT [Tue Aug 26 22:12:09 2014] http://adam.chlipala.net/cpdt/ [Tue Aug 26 22:12:29 2014] the second chapter walks through proving a arithmetic to stack compiler correct [Tue Aug 26 22:12:42 2014] vanila: came across that website but did not understand what was is it about, I will read about it then. [Tue Aug 26 22:13:08 2014] youre welcome to ask for pointers and stuff on the book here too of course [Tue Aug 26 22:14:33 2014] vanila: ok, I will try this way then. (was already adviced to switch to CPDT at some point some time ago) [Tue Aug 26 22:54:32 2014] vanila: should I look at metamaths or read CPDT ? Thought I will fast get to know how metamaths work but it is not that easy… [Tue Aug 26 22:54:45 2014] *works [Tue Aug 26 22:55:30 2014] I only linked metamath to explain how much effort and time and care has to go into formalizing things is [Tue Aug 26 22:56:07 2014] so don't be discouraged if you find it difficult or slow, that's just the nature of this [Tue Aug 26 22:56:29 2014] vanila: isn't that what Coq is all about ? [Wed Aug 27 00:34:33 2014] Set theory is pretty gross to begin with :( [Wed Aug 27 00:35:28 2014] I am hoping to use Coq in my "advanced group theory course". [Wed Aug 27 00:35:35 2014] Hopefully that will work out okay :). [Wed Aug 27 05:49:33 2014] what is this warning trying to warn me about? "Warning: pattern min is understood as a pattern variable" [Wed Aug 27 05:58:37 2014] osa1: not saying I can tell you the solution, but it might be easier if you posted your code as well. [Wed Aug 27 06:10:15 2014] is there an easy way to convince coq that last function here http://lpaste.net/110096 really terminates? other than introducing a timeout argument? [Wed Aug 27 07:39:05 2014] I am a bit surprised. I read about coq and it seemed a little dry and pretty academic. But I most admit it has been some time since I have had so much fun learning something new [Wed Aug 27 08:15:58 2014] mads-: the "interactive" part is really fun. "dependently typed programming" part is not so much. [Wed Aug 27 08:31:15 2014] mads-: It was similar for me, in terms of "perception of Coq" vs. "using Coq". [Wed Aug 27 08:31:26 2014] one of these days I'll get to "using Coq for something useful" :> [Wed Aug 27 08:34:06 2014] Hodapp: Does it have any practical usages? I mean, it's an awesome proof assistant and language. But how is its I/O and such? [Wed Aug 27 08:35:40 2014] one can extract verified code from it, for instance. [Wed Aug 27 08:36:56 2014] ooh, sounds nice. [Wed Aug 27 08:37:09 2014] Did you by the way come to think of any interesting papers? :) [Wed Aug 27 08:44:52 2014] mads-: I/O is just not logical. You can optimistically model it in a way that Haskell does at the cost of soundness in the general case. I would imagine this is why Coq has not embraced I/O, on top of the ease of punting to extracted code. [Wed Aug 27 08:45:36 2014] mads-: ACL2 doesn't really care about the platonic general case, and makes the tradeoff of "good faith" use of the theorem prover http://www-dev.ccs.neu.edu/home/pete/acl206/papers/davisb.pdf [Wed Aug 27 08:47:21 2014] Interesting. I will give that a look-see :) [Wed Aug 27 08:49:13 2014] mads-: see also their file I/O documentation for more details about the logical underpinnings. [Wed Aug 27 08:50:20 2014] How close are ACL2 and Coq related? [Wed Aug 27 08:51:06 2014] Not at all. [Wed Aug 27 08:51:47 2014] ACL2 is an untyped first-order logic that has an interaction mode of a huge ambient tactic. [Wed Aug 27 08:55:07 2014] Equality theorems are by default stored as rewrite rules for the simplifier to use until a fixed-point. It then automatically decomposes all compound data, rewrites with installed congruence rules, removes irrelevant details, generalizes according to a well-known criteria, and then infers an induction scheme that is likely to work. Induction produces new subgoals that the process starts all over again on. [Wed Aug 27 08:56:54 2014] It's really beautiful, powerful, pragmatic, and soooo much different from Coq. It has one way to introduce abstract datatypes, after which point all automation is pretty much forfeit (and the mechanism for doing so has been the primary source of soundness bugs in absolutely every release of ACL2) [Wed Aug 27 08:57:41 2014] and they're not really datatypes, but instead a collection of uninterpreted functions with a fixed collection of constraints/axioms. [Wed Aug 27 08:58:56 2014] if you can write a function that "recognizes" a value of that "type" then you've gotten something. Not a big problem since it's first-order. [Wed Aug 27 08:59:51 2014] If you've seen Adam Chlipala's crush tactic, you'll still be humbled by ACL2's "waterfall" [Wed Aug 27 09:00:47 2014] I just recently started with Coq - so I haven't read that much about it yet. [Wed Aug 27 09:01:00 2014] And also recently started on functional programming. [Wed Aug 27 09:01:17 2014] jesus, you really picked a difficult starting point. [Wed Aug 27 09:01:58 2014] University course. [Wed Aug 27 09:02:08 2014] Introduction to functional programming. [Wed Aug 27 09:02:23 2014] And I think most of the course is on Coq [Wed Aug 27 09:06:01 2014] mads-: way to send them running for the hills, uni. [Wed Aug 27 09:07:10 2014] I'm a mostly functional programmer. I like my ambient monad of concurrency, I/O, and mutable state. [Wed Aug 27 09:08:17 2014] I wish I had invested more time in functional programming before now. Seems like an exciting paradigm. [Wed Aug 27 09:08:57 2014] mads-: It definitely has its strengths, but its weaknesses are too often drowned out by bravado. [Wed Aug 27 09:10:11 2014] Well, lecture time. I'll catch you later :) [Wed Aug 27 09:14:59 2014] ianjneu: I'd say overall that having spent some time in the OOP camp and the FP camp (much more in the former than the latter) that the FP community does a much better job in general acknowledging the weaknesses. [Wed Aug 27 09:40:44 2014] Hodapp: Let's keep it that way. I've seen a lot of marketing nonsense lately. [Wed Aug 27 09:41:06 2014] My whole life is full of marketing nonsense. [Wed Aug 27 09:41:13 2014] or were you talking specifically about FP marketing nonsense? [Wed Aug 27 09:41:36 2014] Specifically FP-related stuff [Wed Aug 27 09:42:09 2014] Look guys, I wrote a functional programming framework in Ruby! [Wed Aug 27 09:42:11 2014] It's functional! [Wed Aug 27 09:43:03 2014] http://new-www.haskell.org/ -- like this thing, please no :( [Wed Aug 27 09:43:38 2014] needs more github. [Wed Aug 27 09:43:46 2014] and a cuter logo. [Wed Aug 27 09:43:59 2014] It's the "Features" section which bothers me [Wed Aug 27 09:45:30 2014] yeah, I wish they hadn't just taken to making this look like every other Next Big Thing marketing page. [Wed Aug 27 09:45:31 2014] Some of the things there are sort of true, but if you say things like that to people who don't have any context for them yet, it's easy to take them the wrong way. [Wed Aug 27 09:45:49 2014] and there are certainly valid interpretations of the things being said which are entirely incorrect [Wed Aug 27 09:47:10 2014] The blurb at the top of www.haskell.org as it exists is already buzzwordy enough. [Wed Aug 27 10:11:07 2014] hello. I want to declare a list of fin 19-s. It would, however, be nice, if I could just write them down as 1 :: 2 :: ... [Wed Aug 27 10:11:32 2014] all of them are constant. is it possible to let coq automatically check that they are sufficiently small to be converted to fin 19? [Wed Aug 27 10:11:38 2014] (eG smaller than 19) [Wed Aug 27 10:13:48 2014] yeah you can do this with reflection [Wed Aug 27 10:14:09 2014] vanila: -v [Wed Aug 27 10:15:06 2014] vanila: how? [Wed Aug 27 10:15:20 2014] I'll make an example give me a sec [Wed Aug 27 10:15:27 2014] http://coq.inria.fr/distrib/8.4beta/stdlib/Coq.Vectors.Fin.html using this? [Wed Aug 27 10:16:22 2014] vanila: yes [Wed Aug 27 10:28:54 2014] vanila: what do you mean by reflection? [Wed Aug 27 10:30:04 2014] vanila: do you mean Ltac macros and refinement? [Wed Aug 27 10:35:54 2014] meh. now he's gone. [Wed Aug 27 10:36:12 2014] he'll be back. [Wed Aug 27 10:36:13 2014] probably. [Wed Aug 27 10:36:27 2014] mads-: re: papers - have you read "Tackling the Awkward Squad" yet? [Wed Aug 27 10:37:02 2014] mads-: also, I found "Total Functional Programming" by D. A. Turner to be an interesting hypothetical one [Wed Aug 27 10:37:40 2014] mads-: "Can programming be liberated from the von Neumann style?" by John Backus [Wed Aug 27 10:42:11 2014] Hodapp: what are those papers about? Their titles sounds interesting. [Wed Aug 27 10:43:45 2014] sh1ken_: The first one is about Haskell and how they addressed some things that are a bit ugly to solve and awkward to explain (like I/O) [Wed Aug 27 10:45:00 2014] sh1ken_: the second one examines the practical implications of avoiding Turing-completeness in some real-world things that need to exist, like operating systems. [Wed Aug 27 10:46:21 2014] third one is a fairly old paper that gives one of the early looks at functional languages ('functional' as they meant it there being more Lispy, I believe) [Wed Aug 27 10:47:03 2014] schoppenhauer, I might have got cut off? I pasted something a bit ago [Wed Aug 27 10:47:34 2014] vanila: your last line: [Wed Aug 27 10:47:36 2014] 09:15:27 vanila | http://coq.inria.fr/distrib/8.4beta/stdlib/Coq.Vectors.Fin.html using this? │ ezyang [Wed Aug 27 10:47:44 2014] http://lpaste.net/110107 [Wed Aug 27 10:47:44 2014] nat_to_fin should be written better but this is the idea [Wed Aug 27 10:48:04 2014] Hodapp: Thanks. I'll check them all out. [Wed Aug 27 10:50:30 2014] Hodapp: functional there means APL-like [Wed Aug 27 10:50:59 2014] I forget how it defined lisp [Wed Aug 27 10:51:14 2014] vanila: hm. this was I would have to pass eq_refl every time. Which is not nice, but at least better than everything I could come up with. [Wed Aug 27 10:51:58 2014] you could shorten it more than this too [Wed Aug 27 10:52:20 2014] yes, I will try. [Wed Aug 27 10:52:36 2014] but at some point ... the question is whether this is more worthwile than just writing it down. [Wed Aug 27 10:52:58 2014] or proving a lemma that l can always be mapped to list (fin (max l)) [Wed Aug 27 10:53:01 2014] (max l) + 1 [Wed Aug 27 10:53:21 2014] that's a good way as well [Wed Aug 27 10:55:17 2014] I don't think so. But it is as it is. [Wed Aug 27 10:55:37 2014] Hodapp: Wow, the third one is a Turing Award lecture. Must read. [Wed Aug 27 10:56:16 2014] sh1ken: Yes. [Wed Aug 27 10:56:22 2014] sh1ken: "Notation as a Tool of Thought" is another good one. [Wed Aug 27 10:56:51 2014] vanila: thanks! [Wed Aug 27 10:56:56 2014] sh1ken: These papers are also depressing, in that their ideas get reinvented, badly, every 5 years, and then forgotten. [Wed Aug 27 10:58:46 2014] Hodapp: That's a shame. I'll be looking into that for sure. I'm highly interested in these topics. [Wed Aug 27 10:59:23 2014] is there a way to write a function of some type T that checks for a condition, and if so, everything is ok, and if not, a type error is raised? [Wed Aug 27 10:59:46 2014] this would be something that could be used here (check whether reall everything is <19, or raise a type error) [Wed Aug 27 11:00:29 2014] it should be similar to vanila's paste [Wed Aug 27 11:00:34 2014] but I guess I don't get something. [Wed Aug 27 11:01:43 2014] ah, I could use the isTrue-thingy and fold it with logical and. [Wed Aug 27 11:01:48 2014] and assume that it is true. [Wed Aug 27 11:01:54 2014] (which should then be computable) [Wed Aug 27 11:01:56 2014] thx. [Wed Aug 27 11:08:57 2014] http://lpaste.net/110108 [Wed Aug 27 13:05:18 2014] Erraunt would be interested in https://github.com/jwiegley/set-theory [Wed Aug 27 13:06:10 2014] chirpsalot: how is it going (with your group theory class)? [Wed Aug 27 13:51:24 2014] johnw: hasn't started yet :). [Wed Aug 27 13:51:54 2014] johnw: so it's going better than it will be in a few weeks, probably :P. [Wed Aug 27 13:52:19 2014] check out the mathcomp library too [Wed Aug 27 13:52:47 2014] Me, or Erraunt? [Wed Aug 27 13:53:00 2014] you [Wed Aug 27 13:53:15 2014] ssreflect and mathcomp contain a lot of tools to make math developments easier [Wed Aug 27 13:53:51 2014] Ah okay, will do. Thanks :). [Wed Aug 27 13:54:08 2014] I'm still working through the SF book at the moment -- I believe it has a chapter on ssreflect? [Wed Aug 27 13:54:28 2014] Right now I am just about finished "More Coq" [Wed Aug 27 13:54:40 2014] it mentions it [Wed Aug 27 13:54:47 2014] but insteadi to develops something called LibTactics [Wed Aug 27 13:55:05 2014] it even says that ssreflect is better for maths, and LibTactics for modeling DSLs [Wed Aug 27 13:55:13 2014] Ah I see. [Wed Aug 27 13:55:35 2014] Are there any good resources for ssreflect / mathcomp that you would recommend? [Wed Aug 27 13:55:49 2014] the manuals for both [Wed Aug 27 13:55:57 2014] http://www.msr-inria.fr/projects/mathematical-components-2/ [Wed Aug 27 13:56:03 2014] Ah, okay :). Sometimes manuals are good, other times not. [Wed Aug 27 13:56:04 2014] click on the Downloads tab [Wed Aug 27 13:56:12 2014] ssreflect's manual is unfortunately dense [Wed Aug 27 13:56:25 2014] i wish there was a tutorial and "best practices" guide [Wed Aug 27 13:56:47 2014] but then again, this was made by mathematicians for handling huge math proofs, so advertising it to newcomers isn't their first objective [Wed Aug 27 13:56:53 2014] Like the coq tutorials and stuff recommended on the coq website were useless to me. Did not get through my tiny brain places. SF just clicks, though :). [Wed Aug 27 13:57:12 2014] yes, with SF Coq would just be a mystery [Wed Aug 27 13:57:14 2014] without [Wed Aug 27 13:57:33 2014] at this point you might find Adam's book valuable, chirpsalot [Wed Aug 27 13:57:37 2014] God yeah. Everything else was confusing and I didn't understand it at all. It seemed like Coq was three things. [Wed Aug 27 13:57:43 2014] johnw: is that Coq'Art? [Wed Aug 27 13:57:47 2014] it's really a good book for those who want to use Coq more effectively [Wed Aug 27 13:57:55 2014] no, http://adam.chlipala.net/cpdt/ [Wed Aug 27 13:58:08 2014] Oh! [Wed Aug 27 13:58:14 2014] I have that on my amazon wishlist :). [Wed Aug 27 13:58:21 2014] the PDF is free :) [Wed Aug 27 13:58:26 2014] Past me looking out for me again. [Wed Aug 27 13:58:31 2014] johnw: ah. [Wed Aug 27 13:58:37 2014] I read it through and it was excellent [Wed Aug 27 13:58:42 2014] johnw: might buy the kindle version if it seems good. [Wed Aug 27 13:58:45 2014] I've been using several of the techniques ever since [Wed Aug 27 13:58:52 2014] (I like reading on my kindle) [Wed Aug 27 13:59:08 2014] johnw: is it worth finishing SF first? [Wed Aug 27 13:59:08 2014] some of the example sections in the latter half of the book aren't worth reading closely unless you are working on exactly that sort of problem at the moment [Wed Aug 27 13:59:14 2014] Or doing them in parallel... Or what? [Wed Aug 27 13:59:16 2014] i'd read it in conjunction with working on SF [Wed Aug 27 13:59:28 2014] that way you can start using some of the tricks in your SF womrk [Wed Aug 27 14:00:18 2014] Ah. [Wed Aug 27 14:01:11 2014] I get distracted easily, though. Having multiple resources scares me :P. I'll look at the PDF first and see if it's something I can read. [Wed Aug 27 14:01:23 2014] I was able to make the proof for filter_challenge *really* short by using an automated proof script [Wed Aug 27 14:01:33 2014] Oh wait, I think I actually started reading this once. [Wed Aug 27 14:02:11 2014] it's not wise to read that book as an introduction to Coq [Wed Aug 27 14:02:29 2014] No, it wasn't :P. [Wed Aug 27 14:02:34 2014] it's best when you really want to *use* Coq, and you're looking to accelerate your workflow [Wed Aug 27 14:02:46 2014] otherwise, it's too much detail too fast [Wed Aug 27 14:02:50 2014] Like I said. Everything before SF was a disaster and brought me to tears. [Wed Aug 27 14:02:59 2014] but when you do need it, there's nothing better (at the moment) [Wed Aug 27 14:03:15 2014] Sweet :). [Wed Aug 27 14:03:23 2014] I'll definitely look into it. [Wed Aug 27 14:03:55 2014] By the time you get to "Imp", it should definitely be interesting [Wed Aug 27 14:04:07 2014] MoreCoq may still be a bit soon [Wed Aug 27 14:04:20 2014] I bet I can get pandoc to spit out an ebook since there's an html version, actually. [Wed Aug 27 14:04:25 2014] For bus reading. [Wed Aug 27 14:04:41 2014] I did that with Software Foundations [Wed Aug 27 14:04:53 2014] then I skimmed it as a book first, before going back to do the work [Wed Aug 27 14:05:10 2014] I'm keeping SF on the computer because I really want to do the exercises :P. [Wed Aug 27 14:05:20 2014] Otherwise SF isn't super useful. [Wed Aug 27 14:05:30 2014] yes, sure, I just found the material so fascinating that forcing myself to complete the exercises was slowing down my enjoyment [Wed Aug 27 14:05:43 2014] I mean, skimming before is something I have been doing too :P. [Wed Aug 27 14:05:46 2014] so I let myself read ahead, and then go back and do the exercises [Wed Aug 27 14:06:00 2014] it gave me more context too [Wed Aug 27 14:06:05 2014] johnw: the exercises have been going pretty fast for me. It's SUPER enjoyable too. [Wed Aug 27 14:06:30 2014] This is the most fun I have had in a long time :). [Wed Aug 27 14:06:49 2014] yeah, I agree with you 100% [Wed Aug 27 14:06:57 2014] working on SF is my "gaming time" now [Wed Aug 27 14:07:03 2014] Yep, same. [Wed Aug 27 14:07:04 2014] it totally replaced playing actual games [Wed Aug 27 14:07:12 2014] Kicking that YouTube habit :). [Wed Aug 27 14:07:36 2014] one night I booted into Windows and was playing Borderlands, and I started getting bored because I just wanted to be doing proofs [Wed Aug 27 14:07:47 2014] Yesterday I went back to mess with Haskell a bit, though. Had to futz with cabal to get pandoc to install so I could submit a patch :P. [Wed Aug 27 14:07:48 2014] now *that's* successful pedagogy [Wed Aug 27 14:08:50 2014] johnw: it's also kind of weird how Haskell feels a little gross now. [Wed Aug 27 14:08:59 2014] It's like "ewww, Turing complete." [Wed Aug 27 14:09:09 2014] hahaha [Wed Aug 27 14:09:24 2014] It's like going back to C from Haskell. [Wed Aug 27 14:09:55 2014] Haskell does force me to pay more attention to what I'm saying, but I still like how effective it is at making my computer do things [Wed Aug 27 14:10:14 2014] I've been developing a library actually: https://github.com/jwiegley/coq-haskell [Wed Aug 27 14:10:24 2014] I use it for formalizing my Haskell ideas [Wed Aug 27 14:11:04 2014] my intention is to create a comprehensive toolkit for importing types and functions from Haskell, proving things about them, and then carrying those results back. Not automatically, but in a way that makes Coq a "workshop" for playing with whatever ideas you're implementing in Haskell [Wed Aug 27 14:13:49 2014] Awesome! [Wed Aug 27 14:14:15 2014] johnw: yeah, Haskell is still great. It's just Coq is so much more fun. [Wed Aug 27 14:14:36 2014] Because Haskell was like "oh, this is like a programming language but 400% more awesome" [Wed Aug 27 14:14:49 2014] But Coq is like "oh, this is a cool programming language + cool proof stuff!" [Wed Aug 27 14:15:24 2014] Well, Haskell is fun too, but you get what I am saying :). [Wed Aug 27 14:15:53 2014] Also I feel like SF is giving me a better introduction with Coq than I ever got with Haskell. [Wed Aug 27 14:16:02 2014] true [Wed Aug 27 14:16:18 2014] plus, in Haskell you should find that DataKinds and libraries like "singleton" now make a whole lot more sense [Wed Aug 27 14:16:26 2014] and the value of GADTs [Wed Aug 27 14:16:52 2014] you still don't get pi types in Haskell, but you can approximate a lot of stuff that in Coq is just "how you do things" [Wed Aug 27 14:16:58 2014] I still need to really learn Haskell. [Wed Aug 27 14:17:12 2014] what are the 3 windows in coqide for? [Wed Aug 27 14:17:25 2014] spaxxo: should be code, goal, response [Wed Aug 27 14:17:42 2014] Like I know enough to work around in Haskell, but I am not super familiar. [Wed Aug 27 14:17:50 2014] Haskell has a lot of value [Wed Aug 27 14:17:57 2014] johnw: what is goal? [Wed Aug 27 14:18:03 2014] Oh yeah, I loooove Haskell. [Wed Aug 27 14:18:08 2014] with all the extensions on, and many of the newer libraries, you get closer to Coq than you might think [Wed Aug 27 14:18:14 2014] spaxxo: the thing you have to prove [Wed Aug 27 14:18:23 2014] oh [Wed Aug 27 14:18:48 2014] Don't get me wrong :). I am just really enjoying Coq, and it's weird going back to Haskell now XD. [Wed Aug 27 14:18:56 2014] Anyway -- lunch time! [Wed Aug 27 14:19:07 2014] is it possible to prove |R| = |R^R| in coq? [Wed Aug 27 14:19:26 2014] size of reals = size of set of functions from reals to reals [Wed Aug 27 14:21:22 2014] spaxxo, there isn't sets in Coq [Wed Aug 27 14:21:34 2014] wat [Wed Aug 27 14:21:40 2014] :/ [Wed Aug 27 14:21:53 2014] lies [Wed Aug 27 14:23:11 2014] vanila: there are sets man [Wed Aug 27 14:23:35 2014] do 'Check unit.' in the repl [Wed Aug 27 14:23:42 2014] unit : Set. [Wed Aug 27 14:24:01 2014] haha [Wed Aug 27 14:24:26 2014] spaxxo: http://math.andrej.com/2009/09/08/constructive-stone-cardinality-of-sets/ [Wed Aug 27 14:24:39 2014] and the book im reading says 'Inductive nat : Set := ...' [Wed Aug 27 14:25:09 2014] johnw: is the theory behind coq based on constructive math? [Wed Aug 27 14:25:13 2014] yep [Wed Aug 27 14:25:23 2014] ah [Wed Aug 27 14:25:25 2014] ok cool [Wed Aug 27 14:25:32 2014] thats what i wanted to know [Wed Aug 27 14:26:18 2014] cause cardinalities above N_0 and cantors diagonal proof etc make no sense to me [Wed Aug 27 14:27:39 2014] johnw: what is the math that coq is based on? [Wed Aug 27 14:27:51 2014] the calculus of (co)inductive constructions [Wed Aug 27 14:28:00 2014] oh ok [Wed Aug 27 14:28:01 2014] the richest of the lambda calcului on the lambda cube [Wed Aug 27 14:28:09 2014] ah [Wed Aug 27 14:28:16 2014] johnw: is coq turing complete? [Wed Aug 27 14:28:26 2014] it's roots are in intuistionistic type theory (aka Martin Lӧf) [Wed Aug 27 14:28:27 2014] no [Wed Aug 27 14:28:36 2014] turing completeness would be inconsistent [Wed Aug 27 14:28:42 2014] oh [Wed Aug 27 14:28:50 2014] johnw: are you a mathematician? [Wed Aug 27 14:28:56 2014] no, not at all [Wed Aug 27 14:29:02 2014] self taught this stuff? [Wed Aug 27 14:29:05 2014] yeah [Wed Aug 27 14:29:08 2014] nice [Wed Aug 27 14:29:14 2014] I aspire to speak intelligently with mathematicians [Wed Aug 27 14:29:23 2014] me too [Wed Aug 27 14:29:29 2014] but im noob level atm [Wed Aug 27 14:29:43 2014] Mathematicians are insane; Coq programmers are more differently insane [Wed Aug 27 14:29:52 2014] I spent my whole life thinking I couldn't learn math, Haskell and Coq showed me a path [Wed Aug 27 14:30:18 2014] johnw: See, now /that/’s what should go on the Haskell home page :) [Wed Aug 27 14:30:35 2014] it's so true [Wed Aug 27 14:30:42 2014] Haskell literally gave my mind a rebirth [Wed Aug 27 14:30:46 2014] I don't even remember who I was before [Wed Aug 27 14:30:50 2014] i spent my whole life thinking i know math, haskell and coq showed me im retarded lol [Wed Aug 27 14:31:37 2014] this is kind of off-topic [Wed Aug 27 14:31:40 2014] maybe move it to a social channel [Wed Aug 27 14:35:10 2014] what are some other channels on freenode related to formal verification and stuff like that? [Wed Aug 27 14:36:43 2014] johnw: can you recommend a book on CoC ? [Wed Aug 27 14:36:59 2014] the Coq reference manual has a chapter on it [Wed Aug 27 14:37:16 2014] http://coq.inria.fr/refman/Reference-Manual006.html [Wed Aug 27 14:37:25 2014] is that enough to understand it? [Wed Aug 27 14:37:38 2014] or is it just an intro/overview? [Wed Aug 27 14:38:24 2014] well, the original paper is by Huet and Coquand [Wed Aug 27 14:38:30 2014] "The Calculus of Constructions", from 1988 [Wed Aug 27 14:38:44 2014] http://ac.els-cdn.com/0890540188900053/1-s2.0-0890540188900053-main.pdf?_tid=5dce9390-2e19-11e4-8c7d-00000aab0f02&acdnat=1409164901_63db239cb53ba4012a18553a2334bdc0 [Wed Aug 27 14:38:48 2014] ah okay, so its not its own huge theory [Wed Aug 27 14:39:03 2014] no, lambda calculi are pretty simple by nature [Wed Aug 27 16:11:39 2014] I seem somewhat lost. Can someone help me with forall A B C: Prop, (A -> C) \/ (B -> C) -> (A \/ B -> C). [Wed Aug 27 16:19:29 2014] you can use the tauto tactic to automatically prove all trivial theorems like that [Wed Aug 27 16:19:58 2014] ah sorry, I said something stupid :) [Wed Aug 27 16:20:07 2014] Error: tauto failed. [Wed Aug 27 16:20:12 2014] this is not constructively provable [Wed Aug 27 16:20:28 2014] Goal forall A B C: Prop, (A -> C) /\ (B -> C) -> (A \/ B -> C). [Wed Aug 27 16:20:30 2014] you could prove, though [Wed Aug 27 16:20:51 2014] vanila elim on A\/B ? [Wed Aug 27 16:22:28 2014] So it can't be proved? [Wed Aug 27 16:22:53 2014] I'm fumbling around with it. And I seem to be doing fine on all the other exercises, but I just can't get that one to play nice. [Wed Aug 27 16:22:55 2014] no, its not true - I thought maybe it was a typo and you wanted /\ at the start? [Wed Aug 27 16:23:00 2014] link to exercise? [Wed Aug 27 16:23:13 2014] course exercise. So it's not online. [Wed Aug 27 16:23:25 2014] email the teacher saying its wrong :) [Wed Aug 27 16:23:33 2014] But he mentioned there might be a few unprovable hidden around. [Wed Aug 27 16:23:38 2014] oh lol [Wed Aug 27 16:23:39 2014] mean [Wed Aug 27 16:23:46 2014] So I just wanted to check if it was me or this exercise. [Wed Aug 27 16:23:50 2014] maybe you could disprove it [Wed Aug 27 16:23:58 2014] by deriving a contradiction from the assumption that it holds [Wed Aug 27 16:23:58 2014] We haven't learned that yet [Wed Aug 27 16:24:16 2014] Theorem unprovable_identity : ~(forall A B C: Prop, (A -> C) \/ (B -> C) -> (A \/ B -> C)). [Wed Aug 27 16:25:02 2014] this is quite easy [Wed Aug 27 16:25:49 2014] What would you do in the case it was a /\ in the start instead of \/ ? [Wed Aug 27 16:26:00 2014] tauto. [Wed Aug 27 16:26:22 2014] on the other hand unprovable_identity is more intersting, you can't just prove it with tauto. You need to pick an assignment for the variables [Wed Aug 27 16:26:25 2014] I mean, how would you destruct/split the (A -> C) /\ (B -> C) up? [Wed Aug 27 16:26:49 2014] Goal forall A B C: Prop, (A -> C) /\ (B -> C) -> (A \/ B -> C). [Wed Aug 27 16:26:49 2014] intros A B C H1 H2. [Wed Aug 27 16:26:49 2014] case H1. [Wed Aug 27 16:27:02 2014] also compare: destruct H1. [Wed Aug 27 17:19:12 2014] what does 'destruct' do? [Wed Aug 27 17:23:25 2014] nvm found that there is docs for all this [Wed Aug 27 17:53:13 2014] spaxxo: have you been given the SF book for learning Coq yet? http://www.cis.upenn.edu/~bcpierce/sf/current/index.html [Wed Aug 27 17:54:12 2014] spaxxo: I didn't understand anything of Coq before going through that. It's very good. [Wed Aug 27 18:16:12 2014] is there a way to redefine coq's number notation? like if I made my own natural number type, could I make 0 and 1 and make values of my own type? [Wed Aug 27 18:37:46 2014] yukko: I am new and don't know, but the Software Foundations book uses "O" and "S" to create its own natural numbers. I suspect that might be because 0 is taken. [Wed Aug 27 18:38:24 2014] yukko: but you can override the notation for '+' and such, I believe. [Wed Aug 27 18:46:08 2014] chirpsalot I see! [Wed Aug 27 18:46:36 2014] I'm making some silly notation that just converts the normal numerals (1, 2, 3, etc) into my own types via something like [1] or whatever [Wed Aug 27 19:17:05 2014] I want to work with a setoid-valued function. I have troubles using the setoid equality when stating axioms. A somewhat minimal working example illustrating the problem is: http://pastebin.com/MajJJ85t [Wed Aug 27 19:18:17 2014] With setoid-valued I mean that its values are setoids, the type is e.g. nat -> {A : Type & Setoid A} [Wed Aug 27 21:15:51 2014] solved it (by overriding implicit arguments for equiv) [Thu Aug 28 03:20:56 2014] hello. I have predicate as a function, now I want to reformulate it as an inductive data type. But I can't draw isomorphism between them: http://pastebin.com/8j0bYuCA . Seems I'm doing something wrong, and these predicates are not equivalent. Right? [Thu Aug 28 03:28:03 2014] but what I _really_ want, is an ability to store misc terms that are produced by my functions (proofs, other functions, values, types) in some big term, that will be available for proofs (after proper destruction). It should be easy, but I miss something. [Thu Aug 28 05:27:29 2014] gdsfh: They are not equivalent, I believe you want: http://pastebin.com/R54fMSf3 [Thu Aug 28 05:31:13 2014] anderslundstedt: really. Thank you! [Thu Aug 28 05:34:34 2014] np [Thu Aug 28 08:26:35 2014] wah ... how do I get the x in {x : A & B} ? [Thu Aug 28 08:26:56 2014] sig_proj1 and proj1 do not work. [Thu Aug 28 08:27:24 2014] schoppenhauer: projT1 [Thu Aug 28 08:30:06 2014] gdsfh: thx. [Thu Aug 28 09:09:14 2014] Is this how you would have done this? http://pastebin.com/sAXPAiWk . It seems a bit odd to me [Thu Aug 28 09:58:52 2014] johnw: CPDT is /really/ cool. Thanks for the recommendation :). [Thu Aug 28 09:59:28 2014] I like how the first example is "LET'S BUILD A STACK MACHINE COMPILER!" [Thu Aug 28 10:00:23 2014] languages are all we know. [Thu Aug 28 10:03:01 2014] this might be the first time I've heard someone call CPDT "really cool" :P [Thu Aug 28 10:03:31 2014] Hodapp: you disagree? :P [Thu Aug 28 10:21:30 2014] chirpsalot: I've not read the book, so I can't offer much opinion. [Thu Aug 28 10:21:34 2014] I'd like to read it once I get through SF. [Thu Aug 28 10:22:02 2014] Hodapp: yeah, I think I might end up doing that. johnw recommended reading it in parallel. [Thu Aug 28 10:22:56 2014] But, I took a peek and it seems like CPDT is pretty neat. [Thu Aug 28 10:23:24 2014] I think I like keeping the flow of going through SF on its own, though. [Thu Aug 28 10:42:06 2014] in parallel?! [Thu Aug 28 10:42:09 2014] oh well. [Thu Aug 28 10:42:59 2014] I am rather liking SF. I like that, about as soon as it makes sense to, it moves into examples that are fairly practical. [Thu Aug 28 10:44:13 2014] Yeah! And all of the exercises are fun. [Thu Aug 28 10:45:27 2014] I liked the one where they had you implement a simple optimizer for a limited set of expressions, and then had you prove that the optimizer was correctness-preserving. [Thu Aug 28 10:45:57 2014] that, to me, is a practical use. [Thu Aug 28 10:49:13 2014] I also think it's pretty neat that the book itself is Coq code. [Thu Aug 28 12:02:20 2014] Hodapp: I believe you are a little farther than I in SF :P. [Thu Aug 28 12:02:28 2014] I am finishing up MoreCoq still. [Thu Aug 28 13:27:08 2014] do any of you guys work in academia? [Thu Aug 28 13:32:19 2014] helpta: PhD student. [Thu Aug 28 13:37:04 2014] ah [Thu Aug 28 13:37:27 2014] i wonder if its possible to get into this field without any formal education [Thu Aug 28 13:40:27 2014] formal education referring to institutionalized education? [Thu Aug 28 13:43:07 2014] yes roosbeef [Thu Aug 28 13:45:22 2014] helpta, yes there are a lot of good free materials you can learn from [Thu Aug 28 13:45:31 2014] helpta: it just takes time and work. [Thu Aug 28 13:45:49 2014] and a helpful community :) [Thu Aug 28 13:46:50 2014] what im talking about is getting a job in academia working with this stuff [Thu Aug 28 13:46:53 2014] not learning it [Thu Aug 28 13:47:26 2014] oh [Thu Aug 28 13:47:49 2014] the normal route is to do an undergrad degree then PhD [Thu Aug 28 13:50:01 2014] that sucks [Thu Aug 28 13:50:10 2014] yeah [Thu Aug 28 13:50:17 2014] i cant to university [Thu Aug 28 13:50:47 2014] even though i really want to and like to learn this stuff [Thu Aug 28 13:51:09 2014] why cant you [Thu Aug 28 13:51:38 2014] cause i have ADD or something [Thu Aug 28 13:51:57 2014] i just lose all interest in everything like one week into it [Thu Aug 28 13:52:07 2014] well how long have you been into this then [Thu Aug 28 13:52:10 2014] i started and dropped out 3 times already [Thu Aug 28 13:52:28 2014] ive been into this for a while [Thu Aug 28 13:52:33 2014] 'a while'? [Thu Aug 28 13:52:38 2014] 'this' being learning math and other stuff [Thu Aug 28 13:52:45 2014] just started coq one week ago [Thu Aug 28 13:53:57 2014] a while is like ~ 2 years [Thu Aug 28 13:54:08 2014] and programming in general 5 years [Thu Aug 28 13:54:17 2014] hm [Thu Aug 28 13:54:19 2014] fair enough [Thu Aug 28 13:54:26 2014] ive been working as a software engineer already for 3 years [Thu Aug 28 13:54:27 2014] why would you want to get into academia though [Thu Aug 28 13:54:48 2014] well i just want to work with math and more theory [Thu Aug 28 13:54:53 2014] doesnt have to be academia [Thu Aug 28 13:55:12 2014] why don't you just enjoy it as a hobby [Thu Aug 28 13:55:19 2014] it isn't really that useful to real programming [Thu Aug 28 13:56:09 2014] really? [Thu Aug 28 13:56:17 2014] it seems very practical to me [Thu Aug 28 13:56:24 2014] and probably will be more so in the future [Thu Aug 28 13:56:40 2014] and doing it as a hobby i dont have enough time [Thu Aug 28 13:58:14 2014] idk i feel like what i currently do is like the computer-equivalent of laying bricks [Thu Aug 28 13:58:36 2014] id rather do research and write papers [Thu Aug 28 13:58:53 2014] oh okay like meta-programming [Thu Aug 28 13:59:23 2014] yeah sure [Thu Aug 28 14:00:17 2014] to be honest with you helpta, i wonder, if youre unable to cope with the boring aspects of formal education, why would you want to burden yourself with the boring aspects of academia [Thu Aug 28 14:00:46 2014] im just a masters student, so i dont even really know the ins and outs of being a PhD or postdoc etc [Thu Aug 28 14:00:59 2014] but thats just a question coming to mind [Thu Aug 28 14:01:28 2014] what boring aspects? [Thu Aug 28 14:01:57 2014] to me it seems like doing research in academia is the perfect job [Thu Aug 28 14:01:58 2014] you dont think there are any? [Thu Aug 28 14:02:18 2014] well i know they dont pay very well, but thats not a huge problem for me [Thu Aug 28 14:03:45 2014] but i dont see any downsides other than that [Thu Aug 28 14:08:20 2014] helpta: academia is fucking dire. I can't wait to get the hell out. [Thu Aug 28 14:08:34 2014] why? [Thu Aug 28 14:09:15 2014] this is the difference between phd and masters [Thu Aug 28 14:09:31 2014] ianjneu: once you get your phd could you become a researcher and study whatever you like in your area? [Thu Aug 28 14:09:46 2014] It's not the ivory tower of people searching for truth. Science is actually pretty rare these days. It's a bunch of egotists fighting over meager resources by stepping on toes, overstating their importance, and spending way more time fundraising than researching. [Thu Aug 28 14:10:26 2014] ah [Thu Aug 28 14:10:39 2014] that sounds like hell [Thu Aug 28 14:11:10 2014] do you need resources to do research in math though? [Thu Aug 28 14:11:20 2014] no [Thu Aug 28 14:11:35 2014] vanila: sometimes computational resources? [Thu Aug 28 14:12:09 2014] you need money to pay rent, buy food, and have health insurance. [Thu Aug 28 14:12:25 2014] also, office space in a university isn't cheap. [Thu Aug 28 14:12:52 2014] dont all the members get that? [Thu Aug 28 14:12:58 2014] People are the most expensive resource in sciences outside of physics. [Thu Aug 28 14:13:08 2014] chirpsalot, it's often rare that this is of use, that depends a lot on what you study though [Thu Aug 28 14:13:32 2014] helpta: to be a member, you must fight the fight. [Thu Aug 28 14:13:39 2014] ah [Thu Aug 28 14:14:34 2014] vanila: the more applied the more likely you need resources, probably :P. [Thu Aug 28 14:14:43 2014] yeah [Thu Aug 28 14:14:54 2014] i guess i should stick with hobbying [Thu Aug 28 14:15:33 2014] if you strike gold you can still publish something cool :) [Thu Aug 28 14:15:40 2014] ianjneu: don't you just get office space as a grad student? [Thu Aug 28 14:15:51 2014] * shrugs [Thu Aug 28 14:15:57 2014] I got an office space as an undergrad ;) [Thu Aug 28 14:16:14 2014] chirpsalot: Most of the time. Publishing is a nightmare though. [Thu Aug 28 14:16:31 2014] the resource fight is more of the professor's job. [Thu Aug 28 14:16:35 2014] ianjneu: publishing sounds horrendously stupid. [Thu Aug 28 14:17:28 2014] journals seem to think publishing is very important [Thu Aug 28 14:17:34 2014] chirpsalot: it's an outdated institution. People should just post papers online and allow social media to do the rest. [Thu Aug 28 14:17:56 2014] Also, I don't know, people seem to take publications as some kind of academic dick-swinging... Most publications are kind of useless and irrelevant, though. [Thu Aug 28 14:18:07 2014] chirpsalot: this is true. [Thu Aug 28 14:18:40 2014] ianjneu: and kickstart their research grant? [Thu Aug 28 14:18:43 2014] bean-counting is the way that universities judge your value, not the actual intrinsic value of your work. [Thu Aug 28 14:18:55 2014] ijp: indiegogo, clearly :P. [Thu Aug 28 14:19:17 2014] I don't know, maybe I should care about publications, but in general it just seems incredibly stupid. [Thu Aug 28 14:20:27 2014] chirpsalot: do interesting work and document it rigorously. If anyone cares and tries to build on it, they'll either find bugs and help fix them or just have benefitted from the wonders of science. [Thu Aug 28 14:22:11 2014] Science is very much not about truth, but at picking away at something that can help do things later. I would prefer to look at it in the software development point of view rather than the shiny glimmer of platonic truth. [Thu Aug 28 14:22:41 2014] platonic truth is mathematics [Thu Aug 28 14:22:46 2014] false. [Thu Aug 28 14:22:50 2014] programming is an engineering discipline [Thu Aug 28 14:23:20 2014] your distinctions are only meaningful in terms of culture. [Thu Aug 28 14:23:21 2014] programming is a construction discipline [Thu Aug 28 14:23:32 2014] since this is a constructivist channel, it should be obvious that maths is invented, not discovered [Thu Aug 28 14:23:36 2014] ianjneu, what subject do you study? [Thu Aug 28 14:23:41 2014] vanila: semantics. [Thu Aug 28 14:23:57 2014] platonic truth, is that like being friend-zoned by truth? [Thu Aug 28 14:24:16 2014] its like liking truth but not being too gay about it [Thu Aug 28 14:24:38 2014] you know what they say right, nothing escapes the friend-zone not even light :p [Thu Aug 28 14:24:58 2014] roosbeef: misogyny aside [Thu Aug 28 14:25:01 2014] except my friends [Thu Aug 28 14:25:11 2014] haha [Thu Aug 28 14:25:13 2014] platonism is about objectivity. If you can imagine an object that has some properties, a perfect object satisfying those properties (if they are consistent) exists in a real sense. [Thu Aug 28 14:25:24 2014] yea i know [Thu Aug 28 14:25:27 2014] i just thought that was funny [Thu Aug 28 14:25:54 2014] roosbeef: some people think rape is funny. Doesn't make it right. [Thu Aug 28 14:26:03 2014] only if you do it right [Thu Aug 28 14:26:10 2014] I'm leaving now. [Thu Aug 28 14:26:13 2014] haha [Thu Aug 28 14:26:31 2014] honestly ianjneu [Thu Aug 28 14:26:38 2014] you are being out of line [Thu Aug 28 14:26:58 2014] wat [Thu Aug 28 14:27:05 2014] did you mean roosbeef? [Thu Aug 28 14:27:17 2014] the troll/sarcasm loops are getting out of hand, lets reset [Thu Aug 28 14:27:22 2014] yep [Thu Aug 28 14:27:26 2014] the one who started accusing people of mysogeny and talking about rape out of no where [Thu Aug 28 14:27:40 2014] vanila: I see what you mean [Thu Aug 28 14:27:56 2014] i cant even tell who is trolling who anymore [Thu Aug 28 14:28:52 2014] is anyone here in the loop of Coq development?: [Thu Aug 28 14:33:56 2014] guess not [Thu Aug 28 14:34:22 2014] why Ptival ? [Thu Aug 28 14:36:04 2014] I'd like to know more about an upcoming feature [Thu Aug 28 14:36:13 2014] which feature? [Thu Aug 28 14:36:46 2014] apparently, an API to replace -ideslave [Thu Aug 28 14:40:14 2014] is anyone actively working on Haskell extraction? [Thu Aug 28 14:41:26 2014] What is Haskell extraction? [Thu Aug 28 14:41:42 2014] Coq can extract functions and types in Set to Haskell code [Thu Aug 28 14:42:19 2014] oh [Thu Aug 28 14:47:39 2014] helpta: we're working on having haskell defect to the wast [Thu Aug 28 14:48:51 2014] huh? [Thu Aug 28 14:50:03 2014] johnw: cold war joke (obviously not funny) [Thu Aug 28 14:50:15 2014] oh, to the west [Thu Aug 28 14:50:54 2014] odd, I read the line over twice, and didn't notice the spelling mistake till you pointed it out [Thu Aug 28 17:23:02 2014] is there a tactical which says ; [a|b|c for all the rest]? [Thu Aug 28 17:24:54 2014] for example, to clean up: https://gist.github.com/e9ec826f3ff72d1247e2 [Thu Aug 28 17:29:13 2014] johnw: I don't know but foo ; [a | b | | | ...] ; c would save you some typing [Thu Aug 28 17:29:39 2014] I think [Thu Aug 28 17:37:22 2014] johnw: http://coq.inria.fr/refman/Reference-Manual011.html#hevea_tactic178 see the .. syntax [Thu Aug 28 17:37:51 2014] looks like [a | b | c ..] should work [Thu Aug 28 20:33:49 2014] vanila: Hi. Concerning my yesterdays (or the day before yesterday) question about proving set theory things in Coq - If we don't want to do that how do we state mathematical problem in Coq at all? We try to do it in typed lambda calculus instead of ZFC ? [Thu Aug 28 20:35:06 2014] exactly [Thu Aug 28 20:35:22 2014] coq uses a different mathematical foundation - type theory. So formulate everything in those terms [Thu Aug 28 20:38:53 2014] vanila: is there a place (on the web) where I could see how do combinatoric proofs look in Coq? Probably the 4-color theorem is not the best example to begin with. [Thu Aug 28 20:41:43 2014] what kind of things? [Thu Aug 28 20:43:19 2014] vanila: simple things about graphs for example [Thu Aug 28 20:44:51 2014] sorry i don't know where tto find examples of that [Thu Aug 28 20:44:57 2014] vanila: (maybe not that simple) correctness of Dijkstra's algorithm [Thu Aug 28 20:45:04 2014] it's definitely something you can do without a lot of trouble [Thu Aug 28 20:45:14 2014] that's a cool idea [Thu Aug 28 20:45:22 2014] that would make a good learning project for Coq [Thu Aug 28 20:46:23 2014] but I don't necessairly know how to state the problem in Coq (after a couple of chapters of SF) [Thu Aug 28 20:46:49 2014] you would have to develop data types that describes graphs and their meaning [Thu Aug 28 20:49:42 2014] how much time would it take for you to make such a proof? [Thu Aug 28 20:50:06 2014] I think it would take a couple weeks, I'm going to try [Thu Aug 28 20:51:27 2014] so I should manage… in a couple of years. Do you have a github account or some other place where I could see the result ? [Thu Aug 28 20:53:23 2014] oh no im sure you could do it faster than that [Thu Aug 28 20:53:46 2014] if i dont give up ill link it here [Thu Aug 28 21:05:38 2014] vanila: thanks for the time. [Thu Aug 28 22:42:12 2014] Huh. I haven't had any problems thus far, but this one theorem has me stuck. So frustrating. Guess I need to take a break. [Fri Aug 29 05:20:22 2014] Is there any way for me to get coq to be verbose with parantheses in my goals? [Fri Aug 29 07:06:32 2014] sigh [Fri Aug 29 07:40:18 2014] in `f : A -> B`, `B` is sometimes called "range" and sometimes called "codomain". are there any differences between those terms? [Fri Aug 29 07:46:54 2014] osa1: I would say no. Though most of the math I have learned is not English. [Fri Aug 29 07:58:29 2014] Usually ‘range’ means ‘image’, but it can also mean ‘codomain’. [Fri Aug 29 07:59:02 2014] I was taught that it meant ‘codomain’, for instance. [Fri Aug 29 07:59:37 2014] Basically, US high school maths teachers are afraid if they use ‘codomain’, parents will throw a screaming fit because the maths is too abstract and useless for everyday life. [Fri Aug 29 07:59:45 2014] So they disguise the terminology by using ‘range’. [Fri Aug 29 08:00:34 2014] In this particular case, though, [B] is the codomain, not the image, so ‘range’ here means ‘codomain’. [Fri Aug 29 08:01:16 2014] Hmm, actually, now that I think about it, my HS maths teachers used ‘range’ to mean both ‘image’ and ‘codomain’. Ugh. [Fri Aug 29 08:02:57 2014] yes, "domain" and "range" are burned into my memory [Fri Aug 29 08:04:07 2014] but I am indebted to a grade school math teacher who explained a good bit of set theory to us when the curriculum didn't call for it, and a high school math teacher who spent some time explaining that "algebra" and "an algebra" are different things. [Fri Aug 29 08:06:48 2014] she had a PhD in applied mathematics and could have gotten all sorts of other jobs (and did, prior) but seemed to just like teaching high school [Fri Aug 29 09:30:28 2014] * shakes fist. [Fri Aug 29 09:30:35 2014] I hate range. [Fri Aug 29 09:31:31 2014] I always get so confused about it. [Fri Aug 29 09:32:11 2014] Like, it seems to me like a function should always be surjective :P. Just be more specific about your range, dammit! [Fri Aug 29 10:10:12 2014] Why is length_snoc''' so difficult o_o. [Fri Aug 29 10:16:45 2014] chirpsalot, are you trying by induction on l? [Fri Aug 29 10:16:50 2014] Yes. [Fri Aug 29 10:17:14 2014] so th problem with that is that the variable 'n' is not being generalized as part of the induction, instead of it's a constant [Fri Aug 29 10:17:26 2014] http://lpaste.net/110180 [Fri Aug 29 10:17:53 2014] if you put n last, induction l or intro X v l; induction l. will let you do the induction with 'n' generalized [Fri Aug 29 10:18:08 2014] lpaste is pornography according to my corporate proxy [Fri Aug 29 10:18:14 2014] all that sexy code [Fri Aug 29 10:18:19 2014] haha [Fri Aug 29 10:18:25 2014] would you like me to use a different serviec from now? [Fri Aug 29 10:18:32 2014] I don't really know which paste site is good [Fri Aug 29 10:18:33 2014] Yeah, I get that, but 'generalize dependent n' isn't doing what I want :|. I thought it would? [Fri Aug 29 10:18:41 2014] nom i like lpaste [Fri Aug 29 10:19:07 2014] no* [Fri Aug 29 10:19:08 2014] intros n X v l; revert n. [Fri Aug 29 10:19:12 2014] vanila: I'll try reorganizing and see if I can do it that way, and if it gives me insight into how to make 'generalize dependent n' work :). [Fri Aug 29 10:19:28 2014] to shuffle the args around 'revert' puts a hyp back into your goal [Fri Aug 29 10:19:38 2014] generalize dependent sounds like a scary tactic [Fri Aug 29 10:19:46 2014] vanila: dunno about revert yet. I'm following SF, and it hasn't introduced revert yet. [Fri Aug 29 10:20:14 2014] revert puts a hypothesis back into the goal, it's fully documented here http://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic39 [Fri Aug 29 10:20:40 2014] vanila: yeah, I mean that I would like to try to do it how SF seems to want me to do it? [Fri Aug 29 10:39:46 2014] I'm trying to define some basic category stuff but I'm stuck right at the beginning http://lpaste.net/110181 I need to somehow derive/define that `f o g = id` then `g o f = id`. [Fri Aug 29 10:41:41 2014] any ideas? [Fri Aug 29 10:42:41 2014] osa1: you can check out jgross's category theory libraries if you're making a serious effort. [Fri Aug 29 10:44:06 2014] osa1, Doesn't you mean to define isomorphism as a two sided inverse rather than just one sided inverse? [Fri Aug 29 10:47:07 2014] indeed you need upper and lower closure. [Fri Aug 29 10:47:13 2014] ianjneu: I'm just following a book, nothing serious [Fri Aug 29 10:47:16 2014] hm [Fri Aug 29 10:48:08 2014] right, that's mentioned in the book too [Fri Aug 29 10:48:10 2014] thanks [Fri Aug 29 11:27:37 2014] how can I write a function `f : Fin.t 3 -> T` where `Inductive T := A | B | C.` ? [Fri Aug 29 11:30:23 2014] I'm trying to use Fin.t for cardinality [Fri Aug 29 11:30:42 2014] a pattern match like this might work: [Fri Aug 29 11:30:42 2014] match i in Fin.t n return match n with | 3 => T | _ => True end with [Fri Aug 29 11:30:46 2014] the technique from CPDT [Fri Aug 29 11:33:32 2014] so-called large eliminations are great. [Fri Aug 29 11:35:40 2014] the "return" type is sometimes called the "motive." If the type of the motive is a universe, then it's sometimes called "large elimination" because some systems don't have universes, just ad-hoc rules for some motives that produce types. [Fri Aug 29 11:36:42 2014] ianjneu++ nice explanation [Fri Aug 29 11:37:09 2014] reminds me about epigram [Fri Aug 29 11:38:04 2014] http://lpaste.net/110186 this doesn't work [Fri Aug 29 11:38:22 2014] Conor McBride reminds me of a physicist that comes up with crazy mathematical theories that might work in some cases, but have just about no physical meaning. [Fri Aug 29 11:38:25 2014] The term "tt" has type "unit" while it is expected to have type "example_set_1". [Fri Aug 29 11:39:17 2014] osa1 right idea, i had a go and it isn't nice at all http://lpaste.net/110187 -- let's see if there's an easier way [Fri Aug 29 11:39:30 2014] in particular line 15 is especially worrying [Fri Aug 29 11:39:50 2014] this wil likely come up as a problem in proofs with this definition [Fri Aug 29 11:40:46 2014] a better way to write this might be to define it 'inductively' [Fri Aug 29 11:41:11 2014] ill just make a paste because I don't think i can explain it [Fri Aug 29 11:44:34 2014] Definition finElim {T} : t 0 -> T. [Fri Aug 29 11:44:38 2014] Definition fromFin {T} {n} (e : T) (g : t n -> T) (f : t (S n)) : T [Fri Aug 29 11:44:57 2014] something like that could let you build it up the function one step at a time [Fri Aug 29 11:50:11 2014] http://lpaste.net/110188#line15 [Fri Aug 29 11:50:16 2014] this could be a lot neater though [Fri Aug 29 11:51:14 2014] oh and actually partially applying Fin n -> Vec n T -> T gives you a much better way to write all this [Fri Aug 29 12:36:57 2014] is there a constructive proof that R is uncountable? [Fri Aug 29 12:37:46 2014] flergs, cantor diagonalization works just the same constructively [Fri Aug 29 12:38:04 2014] wat? [Fri Aug 29 12:38:07 2014] no it doesnt [Fri Aug 29 12:38:09 2014] :( [Fri Aug 29 12:38:13 2014] please don't waste my time [Fri Aug 29 12:38:21 2014] ? [Fri Aug 29 12:38:27 2014] are you serious? [Fri Aug 29 12:38:45 2014] yes please use a single name or something so I don't have to speak to you [Fri Aug 29 12:38:59 2014] why do you say it is constructive? [Fri Aug 29 12:39:10 2014] iirc it is not.. [Fri Aug 29 12:42:04 2014] ah you are right vanila [Fri Aug 29 12:42:09 2014] not need to get pissy though [Fri Aug 29 13:01:35 2014] vanila: 'The interpretation of Cantor's result will depend upon one's view of mathematics. To constructivists, the argument shows no more than that there is no bijection between the natural numbers and T. It does not rule out the possibility that the latter are subcountable.' [Fri Aug 29 13:01:42 2014] http://en.wikipedia.org/wiki/Cantor's_diagonal_argument [Fri Aug 29 13:04:18 2014] so it is constructive, but it doesn't prove that R is uncountable [Fri Aug 29 13:04:52 2014] what do you think about this vanila ? [Fri Aug 29 13:07:07 2014] which definition of uncountability are you using? [Fri Aug 29 13:09:04 2014] larger than N0 [Fri Aug 29 13:10:26 2014] I don't really see how the definition of the element that doesnt fit in the diagonal argument is constructive though [Fri Aug 29 13:11:13 2014] I mean where is the proof that this element exists after all of the previous elements are defined? [Fri Aug 29 13:12:31 2014] im not trying to say it's wrong, i just dont undertsand it [Fri Aug 29 13:14:37 2014] it almost seems like you have to enumerate all of the permutations in order to define s in the first place... which would be a contradiction [Fri Aug 29 13:15:04 2014] do you get what im sayinf ianjneu ? [Fri Aug 29 13:18:45 2014] hello. I want to implement some kind of dsl over my "imperative" stuff using notations. The code after unfolding notations and goal to prove look like this: https://gist.github.com/gdsfh/dc1a5ad1f92acca8075f [Fri Aug 29 13:18:46 2014] But I don't have information about "wcur2 = wnew". Maybe I should implement passing "world" by different means, not by chaining functions, to get such equalities? [Fri Aug 29 13:19:41 2014] gdsfh, why don't you use a monad? [Fri Aug 29 13:20:36 2014] vanila: because it won't simplify anything. Terms will be not simpler than with naive approach. [Fri Aug 29 13:21:27 2014] gdsfh, I don't think that's true, if you use a monad you can also reason monadically [Fri Aug 29 13:22:20 2014] anyawy if you beta reduce, it will substitute wcur2 in [Fri Aug 29 13:22:29 2014] try red. or simpl. or something like that? [Fri Aug 29 13:23:03 2014] vanila: is it possible to prove that |R| > |N0| using coq? [Fri Aug 29 13:23:22 2014] vanila: what my monad should look like? I have not only one "reference" to get/set, there are lot of them, so it's not a State monad. [Fri Aug 29 13:24:48 2014] vanila: it doesn't substitute wcur2 when I have hypotheses I cited: there is no body in wcur2, only type. Also these tactics doesn't work, checked it now. [Fri Aug 29 13:26:30 2014] how about beta reducing it by hand inside refine? [Fri Aug 29 13:32:19 2014] vanila: my notations look like this: https://gist.github.com/gdsfh/d81011e4a26900f13287 , can't imagine such beta reducing. But it seems the whole approach is wrong. [Fri Aug 29 13:32:38 2014] I see [Fri Aug 29 13:32:48 2014] you could always pass in an equality proof [Fri Aug 29 13:33:24 2014] (fun wcur2 (e : wcur2 = wnew) =>) wcur2 (eq_refl _) [Fri Aug 29 13:33:47 2014] it's not clear to me whether this will cause issues later on though, it's nice to avoid if possible [Fri Aug 29 13:35:33 2014] tried this, failed. Because wnew is not available inside notation. Also tried (fun wcur wold (e : wcur = wold) => ..) to chain equalities (in hope that Coq will pass bodies in equality type), but it doesn't work. [Fri Aug 29 14:57:32 2014] what does 'reflexivity.' actually do? I'm having trouble understanding this [Fri Aug 29 14:58:18 2014] im trying to prove 'forall n :nat, O + n = n.' [Fri Aug 29 14:58:58 2014] the book im reading says 'intros n. reflexivity. Qed.' but I don't understand what it does to construct a 'proof' [Fri Aug 29 14:58:59 2014] ? [Fri Aug 29 14:59:30 2014] flerx: it just applies the eq_refl constructor of the eq type, which basically means comparing the normal forms both sides of the equality [Fri Aug 29 15:00:39 2014] Ptival: what is eq_refl? [Fri Aug 29 15:01:09 2014] when I do [Fri Aug 29 15:01:19 2014] flerx: the constructor of the equality type, you haven't seen that yet but equality is "just" defined as an inductive type [Fri Aug 29 15:02:11 2014] to keep it simple, here Coq checks whether "0 + n" and "n" are computationally equal, and it finds that they are because "0 + n" reduces to "n" [Fri Aug 29 15:02:48 2014] if you do "intros n. unfold plus. simpl." you will see why reflexivity holds [Fri Aug 29 15:03:34 2014] Ptival: what does the 'reflexivity' and 'intros' add? Can't it check it based on the sentence 'forall n : nat, 0 + n = n' ? [Fri Aug 29 15:04:19 2014] I have a feeling that the intros and reflexivity are required, but I dont understand why [Fri Aug 29 15:05:47 2014] Ptival: doesnt it determine to check that '0 + n' and 'n' are the same based on the equal sign in the theorem? [Fri Aug 29 15:07:25 2014] Oh I see that '0 n' gets reduced to 'n' in the 'unfold plus' [Fri Aug 29 15:08:22 2014] So it doesn't actually determine how to prove anything itself? [Fri Aug 29 15:08:46 2014] it performs some transformations on the sentence of the theorem based on the proof steps? [Fri Aug 29 15:08:53 2014] Ptival: ? [Fri Aug 29 15:12:16 2014] flerx: it doesn't do anything until you tell it to [Fri Aug 29 15:12:48 2014] so at the beginning you pretend "I will prove that the statement forall n, 0 + n = n is true" [Fri Aug 29 15:13:05 2014] okay [Fri Aug 29 15:13:13 2014] then you tell it "put that n in context" using intro [Fri Aug 29 15:13:39 2014] what does 'put that n in context' mean? [Fri Aug 29 15:13:43 2014] now you have a n, and you need to prove that for this particular n, "0 + n = n" [Fri Aug 29 15:14:50 2014] it just means that you have fixed a name for this arbitrary number [Fri Aug 29 15:15:20 2014] Ptival: btw ' intros n. unfold plus. simpl. Qed. says 'Error: attempt to save and incomplete proof.' [Fri Aug 29 15:15:27 2014] kinda like if you want to prove that "all natural numbers are something", you start by saying "let's pick a number and name it n" [Fri Aug 29 15:15:44 2014] flerx: you still need the "reflexivity." at the end [Fri Aug 29 15:15:50 2014] oh [Fri Aug 29 15:16:16 2014] so what does 'unfold plus' do? [Fri Aug 29 15:16:52 2014] actually you don't need the simpl, my bas [Fri Aug 29 15:16:57 2014] bad* [Fri Aug 29 15:17:29 2014] "unfold plus" unfolds the definition of the plus function (the + is a notation for the plus function) [Fri Aug 29 15:18:00 2014] so it evaluates all of the 'plus' invocations in the proposition? [Fri Aug 29 15:19:28 2014] or not 'evaluates' but replaces '0 + n' with the definition of plus for that pattern? [Fri Aug 29 15:19:33 2014] yes [Fri Aug 29 15:19:53 2014] and then realizing thath it knows the argument's value, it simplifies it [Fri Aug 29 15:20:10 2014] ah [Fri Aug 29 15:20:19 2014] so should the result of the proof steps be a boolean? [Fri Aug 29 15:21:41 2014] and reflexivity checks whether both sides of the '=' are the same? [Fri Aug 29 15:21:48 2014] like the actual strings are the same? [Fri Aug 29 15:23:24 2014] no, it checks that the terms are convertible according to the rules of the calculus, which is bit more general than just checking the strings are the same [Fri Aug 29 15:23:30 2014] flerx: more than textual equality, it normalizes both terms and compares them for structural equality (names are canonicalized in term representation) [Fri Aug 29 15:23:37 2014] and there is no boolean here [Fri Aug 29 15:24:15 2014] so what is the result of 'reflexivity.' why does it 'complete' the proof? [Fri Aug 29 15:24:16 2014] in this particular case it happens that they reduce to exactly the same term [Fri Aug 29 15:24:56 2014] reflexivity asks the system to check whether the two sides are compatible [Fri Aug 29 15:25:18 2014] if they are, then the system knows how to build the proof [Fri Aug 29 15:25:30 2014] Ah [Fri Aug 29 15:25:48 2014] so whats the point of intros? I just changed the proof to just 'reflexivity.' and it works [Fri Aug 29 15:40:34 2014] ? [Fri Aug 29 15:44:05 2014] Ptival: does the intros change anything in this case? [Fri Aug 29 15:48:55 2014] ianjneu: can you explain what the purpose of 'intros n' here is? [Fri Aug 29 16:00:36 2014] intros constructs a function for the proof term, so if you have a goal A -> B, the proof is going to be a function from A to B. If you intro H, then you are in the body of a function (lambda H: A => [Goal]) where Goal is now to construct B, given the additional hypothesis. [Fri Aug 29 16:01:35 2014] with no arguments, intros will introduce as many things as it can, using Coq's naming conventions. [Fri Aug 29 16:08:20 2014] ianjneu: so its only useful where there is an '->' ? [Fri Aug 29 16:12:11 2014] ianjneu: because the book im reading says i need 'intros n. reflexivity.' to prove 'forall n, 0 + n = n.' but just 'reflexivity.' also works [Fri Aug 29 16:12:46 2014] 'forall n: nat, O + n = n.' * [Fri Aug 29 16:16:23 2014] flerx: you'll understand what is "intros" later; my advice is to continue reading the book. Anyway, take a look at the goal and hypotheses before and after "intro n". [Fri Aug 29 16:16:48 2014] oh okay [Fri Aug 29 16:52:43 2014] flerx: http://paste.awesom.eu/mpXO you don't need to understand this just yet, but you can see a more step by step view of what happens underneath [Fri Aug 29 16:53:23 2014] it turns out that the reflexivity tactic has been beefed up so that it performs all of those steps, so that's why it seems to you like they are unneeded/optional [Fri Aug 29 16:53:33 2014] but really they still happen under the covers [Fri Aug 29 16:53:44 2014] ah i see [Fri Aug 29 16:53:46 2014] thanks [Fri Aug 29 16:53:48 2014] at least morally [Fri Aug 29 17:17:05 2014] Are Coq parameterized modules applicative? [Fri Aug 29 17:20:19 2014] Starting with module types A and B, and a Module B_from_A(MA : A) : B [Fri Aug 29 17:20:46 2014] I've also got some parameterized module types of properties, GoodA (MA : A) and GoodB (MB : A). [Fri Aug 29 17:22:01 2014] I'd like to write a parameterized module with a signature like (MA : A) (MAGood : GoodA A) : GoodB (B_from_A MA) [Fri Aug 29 17:22:27 2014] but I don't even know a legal way to declare that, getting "Error: Application of modules is restricted to paths" [Fri Aug 29 17:49:30 2014] Hello again. Did I miss any suggestions? [Fri Aug 29 18:20:49 2014] my attempt to define cardinality has failed http://lpaste.net/110217 [Fri Aug 29 18:34:30 2014] osa1: one way would be [dependent destruction e] [Fri Aug 29 18:34:40 2014] you have to [Require Import Program.] first [Fri Aug 29 18:43:05 2014] jrw: I can't use first [exists] if I import Program [Fri Aug 29 18:44:15 2014] osa1: that's weird. I imported it after that exists and things work :p [Fri Aug 29 18:45:21 2014] I tried doin that with Program but Print Assumptions shows that it uses an extra axiom [Fri Aug 29 18:45:35 2014] is there a way to tell Program not to use any extra axioms? [Fri Aug 29 18:48:02 2014] no, it's fundamental to the approach [Fri Aug 29 18:48:27 2014] [dependent destruction] uses the axiom that JMeq implies propositional equality. [Fri Aug 29 18:48:51 2014] that's a shame, there's a way to prove this without axioms - it's just really hard without automation [Fri Aug 29 19:18:18 2014] should goals like x = eq_rect _ _ x _ H be provable? [Fri Aug 29 19:19:02 2014] napping: usually iff the type has decidable quality [Fri Aug 29 19:20:23 2014] I do, but how do I take advantage of that? [Fri Aug 29 19:20:55 2014] Isn't it some kind of foundational issue about the model of =? [Fri Aug 29 19:22:25 2014] there's an axiom with computation rules that could be added to Coq which would completely solve all these difficulties with pattern matching and equality proofs [Fri Aug 29 19:22:45 2014] it's just that Coq doesn't have this so we're stuck using axioms and difficult workarounds [Fri Aug 29 19:23:37 2014] Is there any model where x can differ from an eq_rect on x? [Fri Aug 29 19:24:55 2014] napping: see Eqdep_dec.eq_rect_eq_dec [Fri Aug 29 19:26:16 2014] napping, there's some homotopy stuff a fields medalist is working on that contradicts uniqueness of equality proofs [Fri Aug 29 19:26:20 2014] napping: re:models, I think so, yes. in hott for example, intuitively eq_rect over a univalence path should apply the equivalence to its argument. if you give it a non-identity equivalence, then that could happen. [Fri Aug 29 19:29:19 2014] osa1: http://lpaste.net/110226 <- here's a proof without axioms. [Fri Aug 29 19:30:08 2014] nice proof jrw! mine was blowing up much more complex [Fri Aug 29 19:30:30 2014] thanks. it was harder than I expected. [Fri Aug 29 19:30:53 2014] that match annotation... [Fri Aug 29 19:30:54 2014] vanila: but it leaves my goal intact - H itself should be/lift to a path from x to the eq_rect [Fri Aug 29 19:31:18 2014] jrw: thanks, that's exactly what I needed, I'll have to see how it works. [Fri Aug 29 19:31:38 2014] jrw: but in hott the goal is still true because the outer = is satisfiable by a path instead of just equality on the nose [Fri Aug 29 19:32:07 2014] well, except the quality may be a parameter to the type function, but it probably ought to lift? [Fri Aug 29 19:32:19 2014] no, that's not true in general. [Fri Aug 29 19:34:56 2014] napping, sorry I don't understand [Fri Aug 29 19:37:56 2014] If there are multiple equailty proofs that H could be, then you can prove x = eq_rect _ _ x _ H in multiple ways anyway [Fri Aug 29 19:41:51 2014] but basically you can't do much proving about equality proofs and similar data types with dependent indices [Fri Aug 29 19:46:13 2014] oh, except eq_rce [Fri Aug 29 19:46:29 2014] eq_rect is dealing with a path between types, not points in a single type [Sat Aug 30 09:27:30 2014] I'm very new to Coq and I'm struggling to understand how plus_assoc works. Is there some other documentation than http://coq.inria.fr/library/Coq.Arith.Plus.html? All it says is: [Sat Aug 30 09:27:33 2014] Lemma plus_assoc : forall n m p, n + (m + p) = n + m + p. [Sat Aug 30 09:27:59 2014] which may be sufficient if you have a general understanding of Coq, but it confuses me [Sat Aug 30 09:28:13 2014] how would I use it? [Sat Aug 30 09:28:48 2014] to prove that the parentheses in addition don't matter [Sat Aug 30 09:59:32 2014] kba_: you can use this lemma to rewrite additions. tactic is "rewrite plus_assoc". you can rewrite "n + (m + p)" in goal and in hypotheses, also you can rewrite both forth and back. [Sat Aug 30 10:01:32 2014] kba_: as for "how to prove that parentheses don't matter" -- take expression with them, use rewrite to rewrite all occurences of "(x + y) + z" into "x + y + z", and you'll get syntactically equal expressions, then tactic "reflexivity" proves that they are equal. [Sat Aug 30 10:02:19 2014] gdsfh: thanks, I actually managed to do it somewhat, but the syntax still confuses me. For instance, if I have an expression `c + (a + b) + d`, I can't figure out how to rewrite it. I'd assume if I did: `rewrite <- (plus_assoc c (a + b)).` [Sat Aug 30 10:02:41 2014] then it would see that c + (a + b) is the same as c + a + b and thus remove the paranthesis [Sat Aug 30 10:02:57 2014] but instead it just puts d in the paranthesis, c + (a + b + d) [Sat Aug 30 10:03:44 2014] gdsfh: I managed to use reflexivity, but I don't fully understand how I can just do that. (Has reflexitivity been proven in the arithemtic library?) [Sat Aug 30 10:04:41 2014] kba_: when I have goal "c + (a + b) + d = c + a + b + d", simple "rewrite plus_assoc" gives syntactically equal expressions. [Sat Aug 30 10:04:57 2014] I believe you write reflixivity when both sides of the equality is the same [Sat Aug 30 10:05:19 2014] So you want to rewrite your expressions using axioms or theorems you know hold [Sat Aug 30 10:05:34 2014] mads-: yes, I know, and the property that x = x is reflexitivity, but I just find it odd that I need to tell it to use that property [Sat Aug 30 10:05:49 2014] unless reflexitivity isn't always available [Sat Aug 30 10:06:07 2014] reflexivity == "if we have goal A = B, and both A and B, when normalized, are equal, then the proof of this goal can be constructed automatically". [Sat Aug 30 10:06:11 2014] gdsfh: ah, I see. But what is it a syntactic sugar for? [Sat Aug 30 10:06:32 2014] which sugar exactly? [Sat Aug 30 10:06:35 2014] how would I write out `rewrite plus_asoc` [Sat Aug 30 10:06:39 2014] doing that is sort of cheating, I feel [Sat Aug 30 10:06:50 2014] I want to know which arguments I should have given plus_assoc to do it manually [Sat Aug 30 10:07:04 2014] rewrite (plus_assoc x y) [Sat Aug 30 10:07:19 2014] reflexivity isn't just for numbers but it proves that any two values of any type are equal by applying a constructor called eq_refl [Sat Aug 30 10:07:24 2014] not a cheating too much. It searches for expressions of given structure. [Sat Aug 30 10:07:28 2014] vanila: yes, but I can't figure out what x and y is in this context [Sat Aug 30 10:07:37 2014] do Check plus_assoc. [Sat Aug 30 10:07:57 2014] and then you can see what sort of pattern it has [Sat Aug 30 10:07:59 2014] I have, it says [Sat Aug 30 10:08:01 2014] plus_assoc: : forall n m p : nat, n + (m + p) = n + m + p [Sat Aug 30 10:08:19 2014] so what about rewrite (plus_assoc c a b)? [Sat Aug 30 10:09:00 2014] oh... the problem was with the arrow [Sat Aug 30 10:09:14 2014] I used `rewrite <-` and I should have used `->` [Sat Aug 30 10:09:20 2014] thanks, just `c a b` actually works [Sat Aug 30 10:10:01 2014] could I do it using `rewrite ->`? [Sat Aug 30 10:10:43 2014] rewrite -> takes from n + (m + p) form to n + m + p form [Sat Aug 30 10:10:49 2014] And <- does it the other way around [Sat Aug 30 10:11:34 2014] So given an expression like a + b + c you can't really rewrite using -> [Sat Aug 30 10:12:05 2014] right, that's what I assumed. So when I say `rewrite -> (plus_assoc c a b).`, I say "I want to arrive at `c a b`". So shouldn't I be able to say something like "I have `c + (a + b) + d`", now rewrite this [Sat Aug 30 10:12:07 2014] kba_: try to use as much automation as you can, otherwise it will be boring soon. [Sat Aug 30 10:12:13 2014] using -> then? [Sat Aug 30 10:13:31 2014] gdsfh: I just feel like I need a basic understanding of what is happening behind the scenes before I start taking shortcuts [Sat Aug 30 10:13:41 2014] otherwise I'll soon finding myself solving harder problems, but with less understanding [Sat Aug 30 10:14:01 2014] I think... [Sat Aug 30 10:16:20 2014] kba_: really. But when you are learning Coq, think about automation. For example, "ok, here I can use just 'rewrite plus_assoc'...". [Sat Aug 30 10:16:20 2014] kba_: silly question: Is this school work? [Sat Aug 30 10:16:33 2014] mads-: it is for a course, yes :) [Sat Aug 30 10:17:53 2014] is this not allowed in herE? [Sat Aug 30 10:18:28 2014] I was just asking because it sounds a bit like what I have as school work as well ;) [Sat Aug 30 10:18:42 2014] Olivier Danvy? [Sat Aug 30 10:19:00 2014] Yeah [Sat Aug 30 10:19:16 2014] :) [Sat Aug 30 10:22:44 2014] but I'm having a hard time accepting that I can't rewrite `b + (d + c) + a` to `b d c a` using -> [Sat Aug 30 10:24:01 2014] If you use plus_comm on (b + (d + c)) a first [Sat Aug 30 10:24:19 2014] Then you can use plus_assoc a b (d + c) [Sat Aug 30 10:24:22 2014] Both with -> [Sat Aug 30 10:28:00 2014] You want me to perform `rewrite -> (plus_assoc a b (d + c)).` on `c + a + b + d = a + b + (d + c)´? [Sat Aug 30 10:28:10 2014] because that isn't working [Sat Aug 30 10:28:40 2014] with `rewrite -> (plus_assoc (a + b) (d + c)).`, I get `Error: Found no subterm matching "a + b + (d + c + ?2050)" in the current goal.` [Sat Aug 30 10:28:48 2014] these ?nnn always confuses me [Sat Aug 30 10:29:08 2014] plus_assoc takes three arguments [Sat Aug 30 10:29:24 2014] And you gave it two [Sat Aug 30 10:29:41 2014] I started with: rewrite -> (plus_assoc a b (d + c)). [Sat Aug 30 10:30:44 2014] Right now I have `c + a + b + d = a + b + (d + c)`. That's the thing. To get there, I used `rewrite -> (plus_assoc a b (d + c)).`. [Sat Aug 30 10:30:55 2014] but I'm not sure how to move forward from here. [Sat Aug 30 10:31:11 2014] It's mixed_a, right? [Sat Aug 30 10:31:14 2014] why don't you use the ring. tactic [Sat Aug 30 10:31:22 2014] mads-: yes [Sat Aug 30 10:31:36 2014] it will automatically do associativity and symmetry and things [Sat Aug 30 10:32:07 2014] vanila: I want to learn the basics before I use automation [Sat Aug 30 10:32:25 2014] but thanks for the suggestion! I'll keep that in mind in the future... once I undersatnd it [Sat Aug 30 10:33:13 2014] ok that's a good idea too :) [Sat Aug 30 10:34:28 2014] I can't even start with rewrite -> (plus_assoc a b (d + c)). on mine [Sat Aug 30 10:34:52 2014] rewrite -> (plus_assoc c a b). rewrite -> (plus_comm (b + (d + c)) a). rewrite -> (plus_assoc a b (d + c)). [Sat Aug 30 10:35:54 2014] I just want to do `rewrite -> (plus_assoc b (d + c)).`, basically. [Sat Aug 30 10:36:23 2014] I have `a + b + (d + c)`, so I want `b + (d + c)` to transform into `b + d + c` [Sat Aug 30 10:36:36 2014] which seems to be exactly what plus_assoc does: n + (m + p) = n + m + p. [Sat Aug 30 10:37:03 2014] but it won't let me because of the a, it seems [Sat Aug 30 10:37:23 2014] ah! I figured it out. rewrite -> (plus_assoc (a + b) d c). [Sat Aug 30 10:43:20 2014] mads-: do you know how I can tell Coq to perform the operation on the right-hand side of the equation? I'm trying to perform `rewrite -> (plus_comm d c).` on `c + a + b + d = a + b + d + c`, but I'm told "Error: Found no subterm matching "d + c" in the current goal." [Sat Aug 30 10:43:31 2014] even though `d + c` is clearly on the right-hand side [Sat Aug 30 10:44:18 2014] kba you just have to find the right term [Sat Aug 30 10:44:33 2014] and remember that Coq isn't totally verbose with parantheses. [Sat Aug 30 10:44:47 2014] So look at your original expression and deduce if you are missing any from the screen [Sat Aug 30 15:47:48 2014] Wooo. I proved length_snoc''', guess I just needed a break. Dunno why that was so hard for me XD. [Sat Aug 30 16:04:43 2014] I swear no matter what I was doing 'n' wasn't being generalized... I think my ProofGeneral is buggy -- it is crashing a lot. [Sat Aug 30 16:10:23 2014] I have had a few times where it isn't sending stuff properly to and from coq -- so maybe that's what's happening. That or I REALLY confused myself (likely). [Sat Aug 30 16:14:48 2014] chirpsalot: are you using the CVS version of ProofGeneral? [Sat Aug 30 16:15:08 2014] elarnon: nope, whatever was in Fedora 20's repositories. [Sat Aug 30 16:15:40 2014] oh, ok [Sat Aug 30 16:16:00 2014] I found the CVS version to have similar bugs as you described, while the last released version works fine for me [Sat Aug 30 16:16:12 2014] When I was on NixOS using the nix version I didn't have any problems. [Sat Aug 30 16:16:31 2014] elarnon: who knows, maybe the fedora version is the CVS version. [Sat Aug 30 16:18:10 2014] elarnon: good to know I might not be crazy ;). [Sat Aug 30 16:19:00 2014] yeah, I would suggest installing another version manually [Sat Aug 30 16:19:36 2014] elarnon: yeah. I have been meaning to install the nix version again since I had no problem with it -- just haven't gotten around to it yet. [Sat Aug 30 16:19:40 2014] if you're having the same kind of troubles I had with the CVS version, it can't possibly get worse [Sat Aug 30 16:22:11 2014] elarnon: ironic that the IDE for the proof assistant is buggy. [Sat Aug 30 16:31:55 2014] yeah, emacs should support gallina scripting [Sat Aug 30 16:32:12 2014] not sure what you could prove about it though [Sat Aug 30 16:32:15 2014] elarnon: I want a new editor built with coq ;). [Sat Aug 30 16:32:42 2014] elarnon: you could prove that transformations on text are correct? [Sun Aug 31 20:56:40 2014] Hi. How pattern match on even and odd numbers seperatelly ? [Sun Aug 31 21:11:18 2014] there is even_odd_dec in Coq.Arith.Even [Sun Aug 31 21:11:42 2014] ijp: thanks [Sun Aug 31 21:12:30 2014] you can match (even_odd_dec n) and check for the sumbool constructors left and right. [Sun Aug 31 21:12:54 2014] ijp: figured that out [Sun Aug 31 22:17:13 2014] Huh. Neat. Hadn't thought about that stuff yet. [Mon Sep 1 01:56:12 2014] hi! beginner here. just out of curiosity: is there a way to do something like what the simpl tactic does (which in my naive understanding is apply whatever beta-reductions it finds it can apply), but specifying precisely what reductions to apply where? [Mon Sep 1 01:57:44 2014] like, in the middle of the proof of an equality, I want to reduce some function application on the left side of the equality that says «foo bar baz», but specifying explicitly «use the definition of foo», or even «use the definition of foo on the left hand side». [Mon Sep 1 01:58:20 2014] not that it’s *necessary* — simpl knows what to do. just wondering if these things *can* be further specified. [Mon Sep 1 01:59:30 2014] i think unfold foo at 1. or simpl foo. will do that. there's also "change" which lets you replace the goal with anything equivalent. [Mon Sep 1 01:59:51 2014] oh neat, I’ll try those (: thanks! [Mon Sep 1 09:07:20 2014] mgomezch: see also "cbv" tactic. [Mon Sep 1 15:00:54 2014] is there a library already out there for heterogeneous maps? [Mon Sep 1 15:01:12 2014] Basically I want finite partial pi types. [Mon Sep 1 19:31:47 2014] The classical axioms equivalence exercise in SF is kind of painful :P. Maybe I am doing it wrong. [Mon Sep 1 19:33:04 2014] chirpsalot: those require a lot of thinking, but they end up being not too long. [Mon Sep 1 19:40:26 2014] jrw: I have got MOST of the implications done. [Mon Sep 1 19:40:43 2014] Just need like one or two more to finish the loop. [Mon Sep 1 19:41:00 2014] chirpsalot: might I suggest working on paper if you're stuck. in the case of this particular exercise, I found that to be helpful. [Mon Sep 1 19:41:21 2014] With excluded middle I am just... Baffled about where to start. It's useless on the left hand side. [Mon Sep 1 19:41:29 2014] jrw: yeah. I'm taking a break now. [Mon Sep 1 19:42:09 2014] Just took a break and bashed my head against it some more and made progress :). Stuck again, but that will probably fix itself up once I start again. Started doing things on paper, because blech. [Mon Sep 1 19:42:31 2014] Significant ramp up in difficulty from the rest of SF thus far :P. Guess that's what 5 stars means ;). [Tue Sep 2 03:35:56 2014] chirpsalot: ha-ha, stuck on peirce -> classic too, lhs looks useless indeed, haven't gave it much time yet tho [Tue Sep 2 03:37:40 2014] can unify lhs with anything... [Tue Sep 2 03:41:23 2014] currently ended up with this http://lpaste.net/6827390183927709696 [Tue Sep 2 03:47:20 2014] can't unify* [Tue Sep 2 03:56:43 2014] why can't i apply H to H0? it looks like ((P -> Q) -> P) part of H should unify with (P -> False) -> False to me [Tue Sep 2 03:56:55 2014] but coq tells me that it can't unify it [Tue Sep 2 03:57:02 2014] why? [Tue Sep 2 04:07:31 2014] well P is not False [Tue Sep 2 04:07:36 2014] ah, because of P <> False. [Tue Sep 2 04:07:41 2014] yeah, silly me [Tue Sep 2 04:10:07 2014] elarnon: is it a dead end i pasted earlier? [Tue Sep 2 04:16:28 2014] elarnon: i mean http://lpaste.net/6827390183927709696 [Tue Sep 2 04:35:09 2014] not sure, i don't really remember the exact proof for this implication [Tue Sep 2 04:35:25 2014] i also don't really have time to look into it deeper right now unfortunately [Tue Sep 2 04:37:41 2014] no that is wrong i think [Tue Sep 2 04:40:11 2014] the [apply H0] is wrong [Tue Sep 2 04:41:13 2014] that exercise is a perfect example of where mindlessly applying tactics videogame-like won't work btw ;-) [Tue Sep 2 04:42:45 2014] Ainieco: ^ [Tue Sep 2 04:43:40 2014] elarnon: got it, thanks for advice :) [Tue Sep 2 11:02:02 2014] Can I ask some basic math questions in here (topology)? [Tue Sep 2 11:07:56 2014] wow, proved 'peirce -> classic' [Tue Sep 2 11:08:19 2014] it was so simple [Tue Sep 2 11:11:31 2014] http://media.tumblr.com/tumblr_m96p8uqB4M1rvw5pd.gif [Tue Sep 2 13:16:08 2014] intros 'grabs' some parts of a proposition and puts it into context of the proof, how do I know for sure which parts it will take and in what order? [Tue Sep 2 13:16:52 2014] It takes as many as it can without destructing them, and it assigns them names over which you don’t exactly have control. [Tue Sep 2 13:17:53 2014] Do you have a specific example you’re wondering about? [Tue Sep 2 13:18:49 2014] yeah alkabetz [Tue Sep 2 13:19:36 2014] 'forall (f : bool -> bool), (forall (x : bool), f x = x) -> forall (b : bool), f (f b) = b.' [Tue Sep 2 13:20:39 2014] alkabetz: it grabs f, H 'forall x : bool, f x = x', and b [Tue Sep 2 13:20:50 2014] Yep, I see that. [Tue Sep 2 13:20:58 2014] im confused about how/why its getting H, and why its not getting x [Tue Sep 2 13:21:10 2014] Ah, gotcha. [Tue Sep 2 13:21:42 2014] Hmm, do you know about Π types? I can explain with or without. :) [Tue Sep 2 13:21:51 2014] No I dont [Tue Sep 2 13:23:12 2014] Okay. So for now, whenever you see [forall X, Y], think of it as a function [X -> Y]. [Tue Sep 2 13:23:41 2014] So think of the goal you’ve specified as [(f : bool -> bool) -> ((x : bool) -> f x = x) -> (b : bool) -> f (f b) = b]. [Tue Sep 2 13:23:55 2014] Does that make sense so far? [Tue Sep 2 13:24:03 2014] yes [Tue Sep 2 13:24:16 2014] Okay. Now, [intros] takes off everything before the last arrow, atomically. [Tue Sep 2 13:24:37 2014] So it takes off [f : bool -> bool], [(x : bool) -> f x = x], and [b : bool]. Does that make sense? [Tue Sep 2 13:24:47 2014] yes [Tue Sep 2 13:25:02 2014] Anything that has a name gets assigned that name in the context, and anything without gets one generated. [Tue Sep 2 13:25:21 2014] So [f] gets called [f], [b] gets called [b], and it makes up a name for [(x : bool) -> f x = x]. [Tue Sep 2 13:25:25 2014] In this case, it picked [H]. [Tue Sep 2 13:25:45 2014] What questions do you have about all this? [Tue Sep 2 13:26:08 2014] Why didn't it deconstruct H further? [Tue Sep 2 13:26:17 2014] like take out x ? [Tue Sep 2 13:26:38 2014] I’m not sure what the actual rationale for it is, but that’s the behaviour that [intros] has. :/ [Tue Sep 2 13:26:46 2014] If you want to get out the [x], you can do [inversion H]. [Tue Sep 2 13:26:56 2014] Oh, wait, that’s a lie [Tue Sep 2 13:27:23 2014] You can’t actually get the [x] out of [H]. [Tue Sep 2 13:27:24 2014] prodolof_: because in some proofs you may want to instantiate the H with different kinds of x [Tue Sep 2 13:27:57 2014] prodolof_: Do you see why Coq won’t allow you to get the [x] out of [H]? [Tue Sep 2 13:28:04 2014] the function H is the argument, not H applied to a particular x [Tue Sep 2 13:28:48 2014] what i was thinking [Tue Sep 2 13:28:56 2014] is that x is 'internal' to H [Tue Sep 2 13:29:04 2014] is this right? [Tue Sep 2 13:29:08 2014] Yes, that’s exactly correct. [Tue Sep 2 13:29:13 2014] ah okay [Tue Sep 2 13:29:14 2014] thanks [Tue Sep 2 13:29:24 2014] You’re welcome. Sorry about the confusion over [inversion] :) [Tue Sep 2 13:30:48 2014] but then it also seems like b is 'internal' to 'forall (b : bool), f (f b) = b' [Tue Sep 2 13:31:55 2014] does it go 'inside' the stuff after the last '->' ? [Tue Sep 2 13:32:27 2014] No. Remember, [forall (b : bool), f (f b) = b] is really [(b : bool) -> f (f b) = b]. [Tue Sep 2 13:33:40 2014] Let me get an exact idea of what you mean by ‘internal’. Are you familiar with the terms ‘bound’ and ‘free?’ [Tue Sep 2 13:33:51 2014] yes [Tue Sep 2 13:34:11 2014] it looks like x and b are both bound [Tue Sep 2 13:34:22 2014] Yes, but they’re bound to different scopes, so to speak. [Tue Sep 2 13:35:13 2014] [x] is bound in [f x = x], while [b] is bound in [f (f b) = b]. [Tue Sep 2 13:35:25 2014] [x] is free in [f (f b) = b], though. [Tue Sep 2 13:35:50 2014] so its based on what is free in the last formula? [Tue Sep 2 13:36:20 2014] Correct. The last formula is what you’re trying to prove, assuming all the formulæ that come before it. [Tue Sep 2 13:37:08 2014] hmm okay, ill have to think about this some more [Tue Sep 2 13:37:18 2014] thanks [Tue Sep 2 13:37:29 2014] That is, in P₁ -> ⋯ -> Pₓ -> Q, you assume P₁, …, Pₓ and try to show Q. [Tue Sep 2 13:37:44 2014] But you can’t assume any variables bound to any particular P to assume Q. [Tue Sep 2 13:38:14 2014] Maybe somebody else can better explain than I can. :/ In the meantime, you’re welcome. :) [Tue Sep 2 13:38:33 2014] alkabetz: so intros will take out all of the P_x and all of the variables from Q ? [Tue Sep 2 13:38:47 2014] Correct. [Tue Sep 2 13:38:53 2014] ah ok [Tue Sep 2 13:39:07 2014] Because secretly, [forall foo, bar] just means [foo -> bar] [Tue Sep 2 13:39:29 2014] ah [Tue Sep 2 13:40:05 2014] Coq won’t let you have free variables in the entire theorem; they have to be explicitly quantified (i.e., bound) at some point. [Tue Sep 2 13:40:17 2014] So you couldn’t prove, for instance, [x = x]. [Tue Sep 2 13:40:23 2014] You’d need to say [forall x, x = x]. [Tue Sep 2 13:40:24 2014] ah [Tue Sep 2 13:40:58 2014] You could do something like [Definition x := 5. Goal x = x.] and prove that, but that would be kind of silly [Tue Sep 2 13:41:23 2014] Usually, when people see free variables, people’s brains implicitly universally quantify them. [Tue Sep 2 13:41:49 2014] ah i see [Tue Sep 2 13:42:02 2014] it makes sense now, thanks [Tue Sep 2 13:42:24 2014] Yay! I’m glad I could help. [Tue Sep 2 13:43:00 2014] :) [Tue Sep 2 13:46:12 2014] Classes are starting tomorrow! Hopefully I have enough Coq-chops to hack it in my "advanced group theory" class as planned :). [Tue Sep 2 13:47:06 2014] I feel like even just having theorem searching will be incredibly useful. [Tue Sep 2 13:59:27 2014] whats the difference between Fixpoint and Definition? [Tue Sep 2 13:59:35 2014] Only [Fixpoint]s are allowed to be recursive. [Tue Sep 2 14:00:05 2014] ah okay [Tue Sep 2 14:07:05 2014] can I somehow define a simple fixpoint without using match? [Tue Sep 2 14:07:33 2014] prodolof_: why would you want to? [Tue Sep 2 14:08:00 2014] I have a very simple function I want to define 'the successor of a number' [Tue Sep 2 14:08:16 2014] prodolof_: you technically can, but it won't be recursive. [Tue Sep 2 14:08:32 2014] oh I dont need it to be recursive [Tue Sep 2 14:08:41 2014] Then you don't need Fixpoint :). [Tue Sep 2 14:08:42 2014] I should use Define for non -recursive? [Tue Sep 2 14:09:17 2014] Definition, yes. [Tue Sep 2 14:09:47 2014] ah yes that worked [Tue Sep 2 14:09:58 2014] so Fixpoint is only for recursive functions? [Tue Sep 2 14:10:10 2014] I believe so. [Tue Sep 2 14:10:22 2014] wait, no Fixpoint also worked [Tue Sep 2 14:10:30 2014] I just had the wrong syntax [Tue Sep 2 14:10:33 2014] I'm a bit of a newby too, so somebody more experienced may have a more rigorous thing to say about that. [Tue Sep 2 14:10:37 2014] You can use [Fixpoint] for nonrecursive functions; it’s just frowned upon. [Tue Sep 2 14:11:05 2014] alkabetz: yeah, but any nonrecursive function can / should be in a definition :). [Tue Sep 2 14:12:35 2014] whats the reason that non-recursive functions should be in definition? [Tue Sep 2 14:13:17 2014] is it a style-type rule, or something to do with performance or correctness? [Tue Sep 2 14:14:55 2014] Is there a good online resource I can use to learn about pi-types? [Tue Sep 2 14:17:00 2014] Just out of curiosity, do the features of dependent types such as checking the length of a list require computations during runtime? Or can these things be checked during compile time? [Tue Sep 2 14:17:05 2014] prodolof_: it's style-driven only by the fact that it blocks some reductions. Coq doesn't have general recursion, so you have to use inductive or recursive type eliminators to perform "recursion." [Tue Sep 2 14:17:19 2014] ah okay [Tue Sep 2 14:17:56 2014] prodolof_: All checking is done at compile-time. [Tue Sep 2 14:18:00 2014] prodolof_: both. If you have a type-level list, you can check its length at typechecking time, but a runtime list you won't actually know what list you need to get the length of. [Tue Sep 2 14:19:35 2014] ianjneu: but this runtime list will not have a type that says it has to be length n right? [Tue Sep 2 14:20:02 2014] dependent types aren't indexed by values. They're indexed by terms. [Tue Sep 2 14:20:50 2014] ianjneu: what is the distinction? [Tue Sep 2 14:21:00 2014] length "n" is symbolic. You don't know what "n" is explicitly. It's a name. You have to perform manipulations based on proof, not arithmetic, to make sure these length indexes stay compatible. [Tue Sep 2 14:22:48 2014] It's not like I can call the length function on some identifier that simply stands for some list and have it tell me, "oh ya, the length of that thing is totally 'n'." That doesn't make sense. [Tue Sep 2 14:23:39 2014] Hodapp: A value is a ground term. There are no neutral terms in it (i.e. it doesn't have free names) [Tue Sep 2 14:27:15 2014] prodolof_: there are functions that can check the length of a list and coerce it into a length-indexed list, say foo : forall l : list A, vec A (length l). Or perhaps bar : forall (l : list A) (n : nat), option (vec A n). [Tue Sep 2 14:29:09 2014] foo would not perform a length computation at runtime or typechecking time, although it does construct a new list at runtime. The type you manipulate at compile time would have to involve proofs about the function length. [Tue Sep 2 14:31:40 2014] ianjneu: what im trying to understand is if it is possible to have certain conditions for all types checked at compile time, so for example you would never have to calculate these values at runtime [Tue Sep 2 14:36:31 2014] ianjneu: nvm, ignore what i asked, thanks [Tue Sep 2 15:54:09 2014] It seems that mult_comm can only be applied to n * m and not (mult n m). Is there a way to interchange between the two notations? [Tue Sep 2 15:54:27 2014] Or would I need to proof that mult n m = mult m n myself? [Tue Sep 2 17:08:24 2014] any good books on intuitionistic logic or constructivism? [Tue Sep 2 17:11:01 2014] is there a way I can look at what the inductive hypothesis is for a particular case? when i use the 'induction' tactic? [Tue Sep 2 17:11:46 2014] for example if I do "induction n as [| n']" how can I see what IHn' is ? [Tue Sep 2 17:12:28 2014] oh wait.. its showing it now.. weird [Tue Sep 2 17:14:40 2014] the coq documentation for tactics is a bit confusing at first because it uses a notation like 'eq term1 term2' instead of term1 = term2, is this because the '=' notation is a special 'Notation' defined to use 'eq'? [Tue Sep 2 17:15:14 2014] oh yeah, it seems like it [Tue Sep 2 17:25:56 2014] I'm having a bit of trouble with implicit arguments. I have a constructor [Tue Sep 2 17:26:02 2014] | term : forall c1 c2, ExactTerm c1 -> subsort c1 c2-> Term c2. [Tue Sep 2 17:26:45 2014] where any value in ExactTerm ends up with a particular result type, and subsort reduces to True if the relation holds [Tue Sep 2 17:27:04 2014] I was hoping to be able to write (term .... I) while building concrete values [Tue Sep 2 17:27:20 2014] but it seems c1 isn't filled in eagerly enough from the context [Tue Sep 2 19:03:21 2014] mads-: not sure if you figured it out, but '*' and 'mult' are the same thing ('*' is a notation for mult), so it should apply just fine. if you post code I can look at it. [Tue Sep 2 19:22:27 2014] unless you locally redefined mult [Tue Sep 2 19:22:58 2014] in which case mult_comm and * refer to Datatypes.mult [Tue Sep 2 20:50:59 2014] Hi! I've got a question about the "induction ... eqn:..." tactic. I have a pastie with the offending code: http://pastie.org/9522880 [Tue Sep 2 20:51:01 2014] It feels like "eqn" is generating the equality at a dumb/wrong time. Has anyone else had problems with it? [Tue Sep 2 21:14:27 2014] hcp_archonn: what do you need 'eqn:' for there? I've only ever used 'eqn:' with destruct... [Tue Sep 2 21:16:51 2014] a friend of mine (the one who wrote the code (but not the final comments)) is going through software foundations, and has started to use "eqn:" as a sort of replacement to SF's "Case" tactic [Tue Sep 2 21:17:53 2014] hcp_archonn: I see. well it does indeed appear to be borked... that is a useless inductive hypothesis. may I susggest sticking with 'Case' ;) [Tue Sep 2 21:30:34 2014] the weirdest part is that, if "induction m ... eqn:Heq" behaved like "remember m as mr;generalize dependent mr;induction m ...;intros m Heq" (plus something to clean the induction hypothesis a little ), it'd work just fine [Tue Sep 2 21:40:29 2014] (actually, you have to generalize the old variable, and do induction on the new variable, as it seems coq replaces occurrences of the old variable by the new one) [Wed Sep 3 02:52:04 2014] jrw: Thanks. I think I made a mistake also. I think I applied mult_comm instead of rewriting with it. Might cause some trouble :) [Wed Sep 3 02:52:52 2014] mads-: yep, that would do it. [Wed Sep 3 02:56:28 2014] jrw: Something odd though. I had j*0 = 0 as my goal and then I did "apply (mult_comm j 0)" to which it seemed to have accepted my goal as solved. Why is that? [Wed Sep 3 02:56:50 2014] I just wanted to rewrite to 0*j = 0 because I had a proof for that [Wed Sep 3 02:59:03 2014] mads-: I'm not sure about this, but my guess is that when it tries to unify the conclusion of mult_comm with your goal it works left to right, so it realizes that m must be j and n must be 0, then it tries to unify the right side of the equality with 0*j, but it uses a little bit of normalization, so this is just 0, so it unifies. [Wed Sep 3 02:59:30 2014] otherwise in this situation you'd expect an error, since you meant to rewrite instead of apply. [Wed Sep 3 03:00:22 2014] OK, cool. [Wed Sep 3 03:01:02 2014] I'm not entirely into Coq yet, but it just seemed off it would just let me prove my goal without actually doing it correctly - I felt like I was missing a couple of steps [Wed Sep 3 07:44:46 2014] Suppose I do "destruct x as [x1|x2]; destruct y as [y1|y2]" and get 4 goals (2 with 2 subgoals). [Wed Sep 3 07:44:52 2014] I want to perform proofscript A for y1 and B for y2; both for each x_i. [Wed Sep 3 07:44:54 2014] How to do it without copy-paste? [Wed Sep 3 08:04:05 2014] Rc43: wrap scripts into named tactics (Ltac A := ...), then "destructs... ; [A; B | A; B | A | B]." [Wed Sep 3 08:06:25 2014] gdfsh, yep, it is possible, but I will lose context and also Ltac scripts will garbage global scope :/ [Wed Sep 3 08:08:45 2014] gdfsh, the least evil here would be tactic for "swapping" goals; like [a; b; a; b] -> [a; a; b; b]. Then I could use just "(try A); B". [Wed Sep 3 08:09:14 2014] gdfsh, not sure if there is such tactic [Wed Sep 3 08:16:11 2014] Maybe it is possible to perform trick with match. [Wed Sep 3 09:06:31 2014] Rc43: one more idea. Use assert (A : hyps -> goal) to introduce local lemma from hypotheses to goal, then "destructs... | [apply A; apply B | ... | apply A | apply B]" (so each goal will be solved by apply and its light magic). You can also use current context in these lemmas. [Wed Sep 3 10:42:45 2014] This looks nice, but I don't see how to do it in Coq: http://gallium.inria.fr/blog/bove-reloaded/ [Wed Sep 3 10:43:35 2014] replacing the interpretation function with a datatype allows defining mu, but then there's trouble writing mapRun [Wed Sep 3 11:42:39 2014] hello. is there a possibility to get peano-style induction for N and Sets instead of Props, because Nind only supports Prop, and Nrec does not provide the proper cases. [Wed Sep 3 11:45:23 2014] ah [Wed Sep 3 11:45:31 2014] I applied peano_rec false. sorry. [Wed Sep 3 11:45:35 2014] s/false/wrong [Wed Sep 3 11:45:39 2014] nevermind. [Wed Sep 3 15:33:44 2014] If I have ex_mid : forall P : Prop, P \/ ~ P in the context, is there any way to instantiate this with a specific P? [Wed Sep 3 15:35:09 2014] I want to do inversion with P \/ ~P, but it seems unhappy about the "forall P" bit :P. [Wed Sep 3 15:35:47 2014] you could destruct (ex_mid MyP) [Wed Sep 3 15:35:56 2014] "specialize" specializes a hypothesis [Wed Sep 3 15:36:11 2014] napping: :O [Wed Sep 3 15:36:14 2014] DESTRUCT! [Wed Sep 3 15:36:38 2014] napping: many thanks :) [Wed Sep 3 15:37:20 2014] Now this is sooooo much easier :). Didn't know destruct worked like that for propositions(?) [Wed Sep 3 15:37:38 2014] it works for any inductive type. I use it when I can [Wed Sep 3 15:38:14 2014] napping: is "forall P : Prop, P \/ ~P" inductive? [Wed Sep 3 15:38:21 2014] Oh, I guess ex_mid P is. [Wed Sep 3 15:38:27 2014] no, but \/ is notation for something that is [Wed Sep 3 15:38:27 2014] Huh. [Wed Sep 3 15:38:33 2014] napping: yeah. [Wed Sep 3 15:38:47 2014] napping: okay! That is where I was confused. [Wed Sep 3 15:39:28 2014] I guess I didn't realize you could supply arguments to something like ex_mid? [Wed Sep 3 15:39:40 2014] some things take terms [Wed Sep 3 15:39:52 2014] also look up the specialize tactic, if you don't need the hypothesis for anything else [Wed Sep 3 15:40:58 2014] napping: ah, yeah. Wasn't sure what to look up. I am following the SF book and trying not to look ahead too much (might cause me to not learn important stuff), but this exercise is from Coq'Art which I think might be where some of the confusion is -- needs a bit more. [Wed Sep 3 16:08:16 2014] I have to say I really don't like all of the unicode in SF, ha. [Wed Sep 3 16:08:43 2014] And sometimes other notations don't seem to work. [Wed Sep 3 16:10:09 2014] For (~(x=y)) I wanted /= or something, but it complains about levels. Blech. [Thu Sep 4 20:40:29 2014] Hmmm. In the relations chapter of SF: http://www.cis.upenn.edu/~bcpierce/sf/current/Rel.html [Thu Sep 4 20:41:02 2014] It starts talking about things like next_nat, total_relation, and empty_relation which are supposedly defined in Logic.v [Thu Sep 4 20:41:20 2014] But I see no such things in Logic.v... Does anybody know what this is referring to? [Fri Sep 5 04:21:59 2014] If I have 1 + n' = S n' in my goal where n' : nat, how do I show that? [Fri Sep 5 04:28:29 2014] simpl? [Fri Sep 5 04:35:52 2014] There is no rewrite to make it verbosely state that 1 + n' = 1 + n'? [Fri Sep 5 05:28:50 2014] Hello all [Fri Sep 5 05:29:10 2014] I am trying to prove a theorem from software foundations http://lpaste.net/110547 [Fri Sep 5 05:29:20 2014] and stuck with goal [Fri Sep 5 05:29:31 2014] which I am not able to simplify. [Fri Sep 5 05:29:48 2014] could some one please give me some hint to solve this goal. [Fri Sep 5 05:29:56 2014] I am not looking for solution. [Fri Sep 5 05:30:13 2014] A hint would be great. [Fri Sep 5 05:38:10 2014] Thank you all. Finally proved it. [Fri Sep 5 09:25:26 2014] mads-: induction? [Fri Sep 5 10:30:16 2014] Hello everyone [Fri Sep 5 10:30:27 2014] I am trying to prove [Fri Sep 5 10:30:38 2014] Theorem dictionary_invariant1' : forall (d : dictionary) (k v: nat), (find k (insert k v d)) = Some v. [Fri Sep 5 10:30:43 2014] http://lpaste.net/110552 [Fri Sep 5 10:30:56 2014] My goal says (if beq_nat k k then Some v else find k d) = Some v [Fri Sep 5 10:31:07 2014] so I want to rewrite ble_nat k k with true [Fri Sep 5 10:31:24 2014] when I am trying to use apply ble_nat_refl. [Fri Sep 5 10:31:39 2014] I am getting this error. [Fri Sep 5 10:31:50 2014] Error: Impossible to unify "true = ble_nat ?2131 ?2131" with "(if beq_nat k k then Some v else find k d) = Some v". [Fri Sep 5 10:32:04 2014] Could some one please tell me how to solve this [Fri Sep 5 10:34:40 2014] keep_learning_: did you try rewrite instead of apply? [Fri Sep 5 10:37:35 2014] jrw: Thank you. Seems like I am applying wrong write. [Fri Sep 5 10:40:54 2014] jrw: Thank you! [Fri Sep 5 10:44:27 2014] I'm looking for tips&tricks to prove this: http://lpaste.net/110553 any ideas? [Fri Sep 5 10:45:46 2014] I'm trying to make my goal look like Permutation_swap but no luck so far ... [Fri Sep 5 10:49:06 2014] if you take n out to the start: Lemma replace_perm_head : forall n h t, [Fri Sep 5 10:49:34 2014] induction on n gives you a sufficiently general induction hypothesis that it's not that hard to get to Permutation (h0 :: t) (nth n t 0 :: replace t n h0) ==> Permutation (h :: n0 :: t) (nth n t 0 :: n0 :: replace t n h) [Fri Sep 5 10:49:58 2014] http://lpaste.net/110554 [Fri Sep 5 11:02:59 2014] wow http://ocaml.org/meetings/ocaml/2014/ocaml2014_15.pdf [Fri Sep 5 11:08:39 2014] now I'm stuck at this [H : Permutation (h :: tt) (nth n' tt 0 :: replace tt n' h) |- Permutation (h :: th :: tt) (nth n' tt 0 :: th :: replace tt n' h)] I need a more general version of perm_cons. [Fri Sep 5 11:17:52 2014] is there a short version of [assert (a = b) as eq; .... rewrite eq.] ? [Fri Sep 5 11:18:10 2014] [assert (a = b) as eq; ... rewrite eq. clear eq.] [Fri Sep 5 11:46:41 2014] there's not but you could define this using ltac [Fri Sep 5 13:08:24 2014] how did that work? I could use rewrite on [H0 : Permutation (e :: a :: b) (a :: e :: b)]. like [rewrite <- H0]. [Fri Sep 5 13:12:38 2014] documentation says "where eq is the Leibniz equality or a registered setoid equality." [Fri Sep 5 13:12:54 2014] is Permutation considered a leibniz equality? [Fri Sep 5 13:15:40 2014] no. [Fri Sep 5 13:17:51 2014] how did that work then? [Fri Sep 5 13:39:39 2014] likely a Proper instance that's congruent with the Permutation equivalence class. [Fri Sep 5 13:46:55 2014] Instance Permutation_Equivalence A : Equivalence (@Permutation A) <- this looks related [Fri Sep 5 13:52:22 2014] osa1: yes it's an equivalence, but you can only rewrite in positions that have Proper instances that state permutation equivalences are respected. [Fri Sep 5 14:38:23 2014] http://people.cs.kuleuven.be/~jesper.cockx/Without-K/Pattern-matching-without-K.pdf [Fri Sep 5 14:38:34 2014] might be of interest here [Fri Sep 5 14:43:55 2014] nice idea to allow full dependent pattern matching on types that do have "K" e.g. using K_Nat when appropriate [Fri Sep 5 15:56:59 2014] vanila: do you know what's up with some of the missing ICFP videos? [Fri Sep 5 15:58:08 2014] ah, it's not in the program, but the session video is at https://www.youtube.com/watch?v=4yCvTaw1nUg [Fri Sep 5 18:04:22 2014] is there a way to see what tactics did auto use? [Fri Sep 5 18:07:01 2014] osa1: "info_auto." [Fri Sep 5 18:07:16 2014] thanks [Sat Sep 6 08:05:34 2014] hi, [Sat Sep 6 08:05:50 2014] i had a struggling question. [Sat Sep 6 08:06:09 2014] when I say A is B, what do I mean in logic language? [Sat Sep 6 08:06:19 2014] do I mean B -> A or A <-> B? [Sat Sep 6 08:08:40 2014] shouya: "is" in English is a bit ambiguous, but if you want to express the idea that A and B are the same thing, then A <-> B [Sat Sep 6 08:09:01 2014] the point is i am not sure... [Sat Sep 6 08:09:26 2014] let me quote the text, wait a second.. [Sat Sep 6 08:09:44 2014] A relation S is said to be a “correlator” or an “ordinal correlator” of two relations P and Q if S is one-one, has the field of Q for its converse domain, and is such that P is the relative product of S and Q and the converse of S. [Sat Sep 6 08:09:52 2014] here it is. [Sat Sep 6 08:10:24 2014] I'm not quite certain about this clause: "such that P is the relative product of S and Q and the converse of S" [Sat Sep 6 08:10:41 2014] That 'is' means = [Sat Sep 6 08:11:56 2014] since my relation is defined as Definition relation {X} := X -> X -> Prop, can I rewrite this clause as 'forall x y, P x y <-> relative_product (relative_product S Q) (converse S) x y'? [Sat Sep 6 08:12:46 2014] yeah, that seems right [Sat Sep 6 08:13:24 2014] But i got stuck with this definition when proving some theorem :( [Sat Sep 6 08:14:02 2014] Can I post the code? [Sat Sep 6 08:15:48 2014] http://lpaste.net/110595 [Sat Sep 6 08:16:39 2014] following the book 'Intro to Math Philosophy', I defined two versions of 'similarity'. [Sat Sep 6 08:17:02 2014] and I got stuck while proving they're equivalence. [Sat Sep 6 08:19:14 2014] I'm totally confused on where I make the mistake(s) :( [Sat Sep 6 12:33:31 2014] I'm doing [pose proof A B C D] and what I get is like this: [1 < 2 -> H]. is there a way to generate LHS of that implication easily? I'm imagining something like [pose proof A B C D _] but that doesn't work. [Sat Sep 6 12:34:46 2014] osa1: you can do it by hand with assert, or write a tactic that does the assert for you [Sat Sep 6 12:35:11 2014] I'm doing manual asserts all time, that's what I'm trying to avoid [Sat Sep 6 12:35:20 2014] my proofs are full of [assert trivial by omega] [Sat Sep 6 12:35:37 2014] by trivial I mean a trivial prop like 1 < 2 [Sat Sep 6 12:36:23 2014] osa1: first step would be something like: [Sat Sep 6 12:36:25 2014] Ltac forward H := [Sat Sep 6 12:36:27 2014] match type of H with [Sat Sep 6 12:36:29 2014] | ?P -> _ => assert P [Sat Sep 6 12:36:31 2014] end. [Sat Sep 6 12:36:43 2014] then [forward H7; omega] does what you want [Sat Sep 6 12:38:54 2014] hm. I should learn ltac sometime. can I chain multiple tactics like [forward H7; omega; omega; omega; ...] for eliminating multiple trivial cases similarly? [Sat Sep 6 12:40:13 2014] osa1: no, but I'm not sure what exactly you're going for. if your goal is already trivial, then it's just [omega] [Sat Sep 6 12:41:14 2014] if you have a hypothesis [H : P -> Q] and you'd like to have Q, and P is a trivial arithmetic fact, then you can do [forward H; [omega|]; intuition] or something, and you should have Q [Sat Sep 6 12:41:41 2014] jrw: the problem is most of the time I'm using [pose proof] instead of [apply] because I think it's leading to cleaner context. but problem with that is then I'm not having that trivial stuff as goals and instead I need to manually pass them to the implication [Sat Sep 6 12:42:36 2014] hm, what do you mean about why you're using pose proof? [Sat Sep 6 12:44:44 2014] jrw: I think it produces better context most of the time but I don't have a small example in mind. let's say I use it to see what I know more clearly. I'm sometimes applying some theorems to stuff in my context just to list some facts etc. [Sat Sep 6 12:46:52 2014] osa1: okay, I'd recommend writing a tactic that takes a theorem and a hypothesis, makes a copy of the hypothesis and applies the theorem to the copy [Sat Sep 6 12:47:12 2014] yeah I guess that'd work too [Sat Sep 6 12:47:36 2014] but really [pose proof] is more useful. I can leave a theorem in form [a -> b], which is not possible with apply [Sat Sep 6 12:47:40 2014] it'll just add [a] as goal [Sat Sep 6 12:48:02 2014] I'm confused, I thought you wanted it as a goal. [Sat Sep 6 12:48:13 2014] I don't want any goals, that's the point [Sat Sep 6 12:48:23 2014] I want stuff in form [a -> b -> ...] [Sat Sep 6 12:49:24 2014] osa1: then what did you mean about eliminating trivial cases? [Sat Sep 6 12:50:32 2014] jrw: let's say I'm using [pose proof] to get something in form [a -> b -> c -> ...]. sometimes a is something trivial like [1 < 2]. I'd like to get [b -> c -> ...] without manually using [assert _ by omega as _; apply _; clear _] etc. [Sat Sep 6 12:50:58 2014] osa1: write a tactic :) [Sat Sep 6 12:51:11 2014] yeah I guess that's my only option. [Sat Sep 6 12:51:41 2014] there are actually a lot of tactics that I want to write to make my tactics a lot more clear but I'm too lazy to learn ltac :o [Sat Sep 6 12:52:22 2014] osa1: you should just do it, it's not hard. [Sat Sep 6 12:52:26 2014] also, I don't want to make my proofs harder to read for others. it it was something in stdlib that I'd have an excuse :-) [Sat Sep 6 12:52:54 2014] for exmaple that's one of the reasons why I don't like CPDT. too much ltac magic. [Sat Sep 6 12:53:07 2014] example* [Sat Sep 6 12:53:12 2014] osa1: there's plenty of middle ground between where you are now and cpdt [Sat Sep 6 12:53:18 2014] right [Sat Sep 6 12:53:38 2014] osa1: http://lpaste.net/110610 <- here's some I use pretty frequently to do what you're talking about [Sat Sep 6 12:54:19 2014] (I just edited it to add one more related one) [Sat Sep 6 12:54:58 2014] then you can say something like [repeat conclude_using omega] to get rid of all the trivial cases [Sat Sep 6 12:55:01 2014] thanks [Sat Sep 6 12:55:04 2014] I'll try to see what they're doing [Sat Sep 6 12:55:25 2014] (as long as they appear as the first hypothesis in the chain, it won't work on [ ... -> 0 < 1 -> ... ]) [Sat Sep 6 12:56:41 2014] yeah actually I want to do that too. when I have an implication and not a forall I sometimes want to swap arguments. like [b -> a -> c] instead of [a -> b -> c]. I'm wondering if there's a theoretical problem with that in general [Sat Sep 6 12:57:43 2014] osa1: as long as there aren't any binders (like forall) that could introduce dependency, it's fine [Sat Sep 6 12:57:55 2014] in other words, if it's just propositional logic, it should work. [Sat Sep 6 12:58:56 2014] yeah no forall [Sat Sep 6 12:59:42 2014] match goal with [Sat Sep 6 12:59:44 2014] | [ H : ?P -> ?Q -> ?R |- _ ] => [Sat Sep 6 12:59:46 2014] assert (Q -> P -> R) by tauto; clear H [Sat Sep 6 12:59:48 2014] end. [Sat Sep 6 12:59:50 2014] something like that [Sat Sep 6 17:34:35 2014] was there any particular reason for ltac being dynamically typed? [Sat Sep 6 17:35:26 2014] it seems surprising given the context [Sat Sep 6 17:54:13 2014] ijp: I don't think you could give it a type system if you tyied [Sat Sep 6 17:54:15 2014] tried [Sat Sep 6 17:54:34 2014] and for well typed automated reasoning you always have reflection [Sun Sep 7 01:03:46 2014] any ideas how do I prove this http://lpaste.net/110649 ? (I have lots of lemmas about replace, member and find_min_idx but I omitted them to make code easier to read) [Sun Sep 7 01:07:34 2014] how do I duplicate a hypothesis? [Sun Sep 7 01:14:48 2014] [pose proof] did it [Sun Sep 7 02:07:15 2014] osa1: still working on that lemma? [Sun Sep 7 04:51:55 2014] jrw: yep [Sun Sep 7 04:56:28 2014] osa1: okay, well it's a kind of overly specific statement. you'll need some lemmas. can you post the full code? [Sun Sep 7 05:01:24 2014] jrw: it's very long, really. 500 lines long. [Sun Sep 7 05:01:32 2014] brb in 10 mins [Sun Sep 7 05:02:15 2014] jrw: https://gist.github.com/osa1/f0acaa31eacfe4dbece3 [Sun Sep 7 05:17:01 2014] jrw: any ideas? [Sun Sep 7 07:12:22 2014] I'll write a ltac program for "duplicate and apply", which takes two arguments H and X then runs [pose proof H; apply X in H]. it'd be nice to have [... as] part too [Sun Sep 7 07:25:31 2014] jrw: isn't more specific better? more specific = more info to use in your proofs which should make proving easier than proving it for more general case. [Sun Sep 7 11:34:34 2014] hey coq experts :-) [Sun Sep 7 11:35:12 2014] I'm very new to coq and I'm currently struggeling with proving contradictions in coq. [Sun Sep 7 11:35:31 2014] suppose, I have some Hypothesis H: something = true as an hypothesis in my context. [Sun Sep 7 11:35:51 2014] I then achieve to deduce a goal something = false [Sun Sep 7 11:35:55 2014] and thus true = false. [Sun Sep 7 11:36:06 2014] that is, assuming my hypothesis H: something = true [Sun Sep 7 11:36:14 2014] I can also derive something = false. [Sun Sep 7 11:36:32 2014] which is obviously a contradiction. [Sun Sep 7 11:36:53 2014] but how do I tell Coq to accept this contradiction? [Sun Sep 7 11:37:19 2014] you could assert (true = false) by congruence. then use discriminate. [Sun Sep 7 11:38:26 2014] vanila: what do you mean by (true = false) by congruence ? [Sun Sep 7 11:38:56 2014] assert (true = false) by congruence. [Sun Sep 7 11:39:04 2014] as a tactic in Coq [Sun Sep 7 11:40:59 2014] vanila: hmm, coq then tells me that congruence failed. [Sun Sep 7 11:41:24 2014] oh [Sun Sep 7 11:41:31 2014] do you have both hypothesis? [Sun Sep 7 11:41:38 2014] something = true and something = false [Sun Sep 7 11:41:41 2014] in your current proof state [Sun Sep 7 11:42:19 2014] vanila: no, I just have H: something = true in my current proof state [Sun Sep 7 11:42:38 2014] and then, however, I can manipulate my goal to something = false. [Sun Sep 7 11:43:06 2014] hmm [Sun Sep 7 11:43:12 2014] can i see the whole proof state? [Sun Sep 7 11:43:20 2014] sure, hold on. [Sun Sep 7 11:47:05 2014] dominik: if you have hypothesis "x=true" and goal is "x=false", you can't prove this goal without additional information. [Sun Sep 7 11:47:59 2014] this is my current proof attempt. http://lpaste.net/6411634738334793728 [Sun Sep 7 11:49:09 2014] gdsfh: hmmm, isn't it the case that when I have x=true as an hypothesis and I can derive from that x = false, then this is contradicts my assumption that x=true [Sun Sep 7 11:49:19 2014] and thus I'm done? [Sun Sep 7 11:50:53 2014] http://lpaste.net/110667 [Sun Sep 7 11:52:21 2014] dominik: if it's a goal, then you haven't derived it [Sun Sep 7 11:52:27 2014] it is something still to be derived [Sun Sep 7 11:56:57 2014] vanila: thanks, what does that omega thing do? [Sun Sep 7 11:57:31 2014] ijp: ah, ok. [Sun Sep 7 11:59:25 2014] dominik, it proves that 0 = x + x implies 0 = x [Sun Sep 7 11:59:51 2014] you could get this from an arithmetic lemma but i didn't want to search around in the stdlib so omega proves it automatically [Sun Sep 7 12:01:16 2014] ok, hold on. I'm trying to rewrite it without omega because we are still at the very basics. Let me try :) [Sun Sep 7 12:14:06 2014] vanila: ok, got it: thanks in particular for showing me on how to use discriminate! [Sun Sep 7 12:15:36 2014] sure :) [Sun Sep 7 15:33:11 2014] osa1: try proving and using this. http://lpaste.net/110673 [Sun Sep 7 16:29:22 2014] jrw: thanks for the tip. I'll try in a minute. [Sun Sep 7 16:50:23 2014] I just proved that. [Sun Sep 7 16:50:51 2014] jrw: do you mean I should be able to prove swap_min_replace with that or should I use that one directly in my master theorem? [Sun Sep 7 16:52:05 2014] osa1: you can prove swap_min_replace using that and your lemmas about find_min_idx I think [Sun Sep 7 16:52:15 2014] I didn't look at anything after swap_min_replace [Sun Sep 7 16:52:41 2014] okay [Sun Sep 7 17:09:55 2014] let's say I generated a name with ?, like [assert _ as ? by omega.] can I use that fresh variable in next tactic in ; chain? [Sun Sep 7 17:31:28 2014] I still can't prove swap_min_replace but I'm too tired to see why. maybe I should try in the morning. [Sun Sep 7 17:32:02 2014] What is swap_min_replace [Sun Sep 7 17:33:46 2014] vanila: minimal version: http://lpaste.net/110649 and this is the whole proof if you're interested: https://gist.github.com/osa1/f0acaa31eacfe4dbece3 [Sun Sep 7 17:36:49 2014] Definition flip_pancakes [Sun Sep 7 17:36:49 2014] lol [Sun Sep 7 17:37:19 2014] lol [Sun Sep 7 17:38:08 2014] what are you reading that's telling you about pancake sorting? simon singh's book on the simpsons and maths? [Sun Sep 7 17:38:44 2014] ijp: it's just a random blog post. I don't have the source. [Sun Sep 7 17:38:50 2014] this looks very hard to prove though, because of the accumulator and stuff [Sun Sep 7 17:39:03 2014] ijp: I thought it might be a good exercise, and it really is. [Sun Sep 7 17:39:32 2014] vanila: actually I'm almost done [Sun Sep 7 17:39:57 2014] vanila: correctness proof of find_min_idx was really the hardest part [Sun Sep 7 17:40:09 2014] I still have no ideas how did that work [Sun Sep 7 17:40:23 2014] basically I proved what jrw suggested and then figured the rest. [Sun Sep 7 17:40:26 2014] I suppose your next project will be to write a "crush" alike so that all those proofs become induction;crush [Sun Sep 7 17:41:23 2014] is it really that powerful? [Sun Sep 7 17:44:22 2014] hm. I just searched for simon singh and the books look interesting. are they good? [Sun Sep 7 17:45:27 2014] the code book was great i read it when i was younger [Sun Sep 7 17:45:30 2014] i dont know his oters [Sun Sep 7 17:45:32 2014] the simpsons one is fun, if you ignore all the BAD maths jokes [Sun Sep 7 17:45:41 2014] his fermat one is okay [Sun Sep 7 17:46:09 2014] I don't know who invented the abelian grape joke, but I wish them nothing but ill [Sun Sep 7 23:29:54 2014] ijp: I think they might be from the Arabelian Peninsula :> [Sun Sep 7 23:31:22 2014] If you travelled there to bring them harm you might be an illegal abelian. [Sun Sep 7 23:48:54 2014] does anyone had any experience compiling coq? [Mon Sep 8 00:11:54 2014] sh1ken_: a little [Mon Sep 8 00:37:26 2014] I have this exact same error: https://lists.macosforge.org/pipermail/macports-users/2008-May/010299.html [Mon Sep 8 00:41:16 2014] Nevermind, I catched the error. I needed a flag while compiling campl5. Thanks anyway. [Mon Sep 8 05:02:21 2014] yay, I proved something [Mon Sep 8 05:02:42 2014] swap_min_replace [Mon Sep 8 05:06:37 2014] wooo [Mon Sep 8 05:10:54 2014] jrw: I still don't understand how you could come up with that lemmas ... :) [Mon Sep 8 05:11:30 2014] osa1: you get better at it. btw, that reminds me about whether "more specific is better" or not. [Mon Sep 8 05:11:43 2014] it's a very intuitive idea that if you have more information, your theorem should be easier to prove [Mon Sep 8 05:11:49 2014] but it turns out to be false. [Mon Sep 8 05:12:12 2014] this is related to the "generalizing the inductive hypothesis" discussions we've had before [Mon Sep 8 05:12:30 2014] if you're going to prove something by induction, that's a very delicate thing and you need everything to fit together [Mon Sep 8 05:12:41 2014] "more specific" often means that things won't fit together well [Mon Sep 8 05:13:07 2014] right. so if we need induction the hypothesis will probably be less general than we need. [Mon Sep 8 05:13:11 2014] so you end up looking for nice, general, simple lemmas that will go through by induction and allow you to prove the facts you want. [Mon Sep 8 05:13:25 2014] osa1: right. [Mon Sep 8 05:17:07 2014] so I now have 3 sorting algorithms proven correct but I'm not happy with their implementation. because in real world you'd use something that operate on mutable and O(1) access arrays instead of persistent linked lists. is it possible to express those in Coq? do I have to reinvent ST monads or something like that? are there any libs? [Mon Sep 8 05:18:07 2014] osa1: it may be possible to do it in coq (by which you mean in gallina, that is, in coq's programming language), but you might be more interested to use coq to reason about a different language [Mon Sep 8 05:18:19 2014] for example, a simple imperative language with arrays [Mon Sep 8 05:18:47 2014] you could build up a floyd/hoare logic for it, and use your functional implementations as the spec [Mon Sep 8 05:18:55 2014] then you'd have an imperative implementation proven correct [Mon Sep 8 05:19:28 2014] yeah actually that'd work even better for me. I'd prefer, for example, to be able to parse a C program to C definition in Coq and prove on that term. [Mon Sep 8 05:22:50 2014] anyways, breakfast time for me. [Mon Sep 8 05:22:52 2014] osa1: that is possible these days but it's still pretty bleeding edge. you should look at VST [Mon Sep 8 05:23:04 2014] osa1: I'd recommend starting with a toy imperative language [Mon Sep 8 05:23:19 2014] jrw: what's VST? google returned unrelated results [Mon Sep 8 05:23:43 2014] jrw: if you mean a languages like those in SF, I solved almost every exercise in that book. [Mon Sep 8 05:23:44 2014] osa1: http://vst.cs.princeton.edu/ [Mon Sep 8 05:23:55 2014] thanks [Mon Sep 8 05:24:10 2014] osa1: I mean something like IMP from SF, but with arrays. [Mon Sep 8 05:24:25 2014] then implement your sorting algorithms in it [Mon Sep 8 05:24:34 2014] then prove they match their spec [Mon Sep 8 06:38:02 2014] uhh ... I just learned about [Hint Rewrite ...] [Mon Sep 8 06:43:22 2014] "Warning: the hint: eapply member_preserved_by_perm will only be used by eauto" why only by eauto? [Mon Sep 8 06:44:39 2014] I have a goal which I solve with [simpl. apply Permutation_cons. apply IHl.] but I can't use [auto] or [eauto] instead. why? [Mon Sep 8 06:46:35 2014] similarly, I'm looking for ways to automate this [simpl. rewrite Permutation_cons_append. apply Permutation_app_tail. apply Permutation_rev.] [Mon Sep 8 06:53:17 2014] you guys may want to use my awesome ltac program http://lpaste.net/110714 :p [Mon Sep 8 06:54:59 2014] lol. it's just stuck in an infinite loop, I guess [Mon Sep 8 06:55:03 2014] how do I terminate it? [Mon Sep 8 06:55:23 2014] I just killed the process [Mon Sep 8 06:58:27 2014] osa1: afaik [e]auto doesn't do "simpl" internally, so write your tactic with "simpl; eauto" if you want "simpl". [Mon Sep 8 06:59:34 2014] gdsfh1: [simpl; eauto with *] or [simpl; auto with *] don't solve what I solve with [simpl. rewrite Permutation_cons_append. apply Permutation_app_tail. apply Permutation_rev.] [Mon Sep 8 07:03:16 2014] osa1: also, if my memory serves me, auto doesn't do rewrites. So first two steps are still necessary. However you can write tactic that rewrites goal with your favorite lemmas. Or maybe "autorewrite" can help, not sure. [Mon Sep 8 07:04:25 2014] right, I remember that too. I just tried now and [auto with *] doesn't even do [apply Permutation_app_tail. apply Permutation_rev.] [Mon Sep 8 07:09:04 2014] are these lemmas declared with Hint Resolve? [Mon Sep 8 07:10:15 2014] also try "eauto with *", if Hint Resolve tells that "auto" won't use some of these lemmas. [Mon Sep 8 07:14:48 2014] [eauto with *] takes too much time, I just had to kill the process again [Mon Sep 8 07:59:52 2014] this link is generated by coqdoc but it's broken http://coq.inria.fr/distrib/8.4pl2/stdlib/Coq.omega.Omega.html# [Mon Sep 8 08:02:24 2014] johnw: Hi there. You went to ICFP, right? How was it? [Mon Sep 8 09:27:46 2014] which haskell libraries have been developed in Coq? [Mon Sep 8 10:34:30 2014] mads-: it was excellent! [Mon Sep 8 10:34:36 2014] vanila: I'm working on trying to bridge the Haskell/Coq gap [Mon Sep 8 10:35:36 2014] ICFP was a lot of fun this year [Mon Sep 8 10:35:48 2014] hi edwardk! [Mon Sep 8 10:36:38 2014] hello hello [Mon Sep 8 10:36:56 2014] you were so deep into your succinct stuff when I had to bug out [Mon Sep 8 10:37:10 2014] my body is on a really screwed up schedule right now, didn't sleep the last night and just hit the airport at 3am for a 7am flight out [Mon Sep 8 10:39:10 2014] does anyone know a good way to prove parametricity properties in Coq? the CoqParam project looks to be a bit too out of date [Mon Sep 8 10:39:52 2014] for example, I want to prove: ∀ (identity : ∀ {X}, X → X), ∀ A (x : A), identity x = x. [Mon Sep 8 10:40:32 2014] johnw, I don't think these theorems are provable [Mon Sep 8 10:41:10 2014] so I have to take them as arguments so that the "caller" is forced to prove them for the definition of identity he cares about? [Mon Sep 8 10:41:23 2014] http://www.lix.polytechnique.fr/~keller/Recherche/coqparam.html [Mon Sep 8 10:41:33 2014] that projects has some ml code for proving such things [Mon Sep 8 10:41:38 2014] there was a lambda calculus + parametricity a while ago but parametricity is a metaresult that dependends on the language not having anything like type inspection for example [Mon Sep 8 10:45:10 2014] johnw, let me be clear [Mon Sep 8 10:45:14 2014] you can prove this of the identity function [Mon Sep 8 10:45:25 2014] but you can't prove it for an arbitrary function of ype ∀ {X}, X → X [Mon Sep 8 10:45:28 2014] right [Mon Sep 8 10:50:27 2014] is it possible to give links in a coqdoc document? [Mon Sep 8 10:50:45 2014] by links I mean link to an arbitrary webpage, not like what coqdoc automatically generates. [Mon Sep 8 10:51:11 2014] you can always use raw HTML wherever you like, and raw LaTeX [Mon Sep 8 10:51:18 2014] but I'd imagine there's a general form of "link" [Mon Sep 8 10:51:48 2014] oh I just saw # ... # stuff. thanks. [Mon Sep 8 10:56:38 2014] vanila: in particular: https://github.com/jwiegley/coq-haskell/blob/master/Duncan.v#L124 [Mon Sep 8 10:56:59 2014] in the pen&paper proof, Duncan uses parametric relations to prove that lemma [Mon Sep 8 10:57:20 2014] does the proof require parametricity of h,k or k'? [Mon Sep 8 10:58:08 2014] i should think its provable without, at any rate you would have to find a differnet proof [Mon Sep 8 10:58:11 2014] not quite sure how to answer that [Mon Sep 8 10:58:46 2014] see page 68 of http://community.haskell.org/~duncan/thesis.pdf [Mon Sep 8 10:59:46 2014] :( [Mon Sep 8 10:59:58 2014] i tried to load this into coq myself [Mon Sep 8 11:00:11 2014] every since I got the HEAD version I can't run anyone elses code [Mon Sep 8 11:00:15 2014] you'll need to clone github.com/jwiegley/coq-haskell [Mon Sep 8 11:00:18 2014] ill upgrade i hope they fixed it [Mon Sep 8 11:00:21 2014] ah, yes, I'm only using 8.4pl4 now [Mon Sep 8 11:00:39 2014] I'm waiting on one specific bug fix before I switch to HEAD [Mon Sep 8 11:00:52 2014] so i should downgrade [Mon Sep 8 11:01:01 2014] i'm not sure my problem is worth your effort [Mon Sep 8 11:01:25 2014] I'm just interested in it because I don't know for sure how to prove it or if it can be done [Mon Sep 8 11:01:35 2014] of course you can add parametricity axioms [Mon Sep 8 11:01:41 2014] gross [Mon Sep 8 11:01:54 2014] :/ [Mon Sep 8 11:02:57 2014] vanila: Dreyer et. al. have work on internalizing parametricity in type theories. [Mon Sep 8 11:03:28 2014] Adam Chlipala adds parametricity axioms to Coq for reasoning about his PHOAS stuff. [Mon Sep 8 11:03:58 2014] ooh, where? [Mon Sep 8 11:06:36 2014] ianjneu, ah I was thinking of Bernardys work [Mon Sep 8 11:06:54 2014] I don't know the relation [Mon Sep 8 11:14:53 2014] johnw: http://www.maximedenes.fr/download/coqeal.pdf <- Maxime Dénès has done some work on parametricity and refinement using typeclasses in the past few years. He might have some work that you'd be interested in. [Mon Sep 8 11:15:10 2014] thanks jgross_ [Mon Sep 8 11:15:40 2014] how do I get Coq to extract records as records to Haskell? [Mon Sep 8 11:17:10 2014] i guess it's too much to hope for it to actually use type classes too, since instance lookup could be different in subtle ways [Mon Sep 8 11:20:09 2014] Google suggests http://coq.inria.fr/refman/Reference-Manual025.html. Typeclasses are resolved at type inference time in Coq, so all your calls will already have the right instances. It's not reasonable to expect future typeclasses to be resolved by Haskell's typeclass machinerary, because Coq lets you use arbitrary Ltac code to resolve instances. [Mon Sep 8 11:23:38 2014] right [Mon Sep 8 11:23:41 2014] that makes sense [Mon Sep 8 11:23:59 2014] otherwise it could be trivial to violate any properties I've proven [Mon Sep 8 12:43:08 2014] using `rewrite`, how can I make the rewrite take place on the right-hand side? [Mon Sep 8 12:43:28 2014] usually rewrite ___ at 2 [Mon Sep 8 12:43:34 2014] or whatever sequence number gets it over there [Mon Sep 8 12:43:45 2014] alternatively, you can specify the exact arguments to the rewrite rule, like: [Mon Sep 8 12:43:51 2014] rewrite (comp_assoc _ _ f) [Mon Sep 8 12:43:58 2014] that's what I'm trying to do [Mon Sep 8 12:44:01 2014] rewrite association for me involving (f . g) [Mon Sep 8 12:48:12 2014] maybe that's not what I want [Mon Sep 8 12:48:22 2014] or that didn't work out at least [Mon Sep 8 12:48:30 2014] it will only allow me to do "at 1" [Mon Sep 8 12:52:41 2014] johnw: maybe you can look at http://paste.debian.net/plainh/c50e2cf3 for a moment [Mon Sep 8 12:53:19 2014] I want to either use: rewrite -> (H_mul_ic n' m). on both sides [Mon Sep 8 12:53:27 2014] so that when I use my IHn.', then both sides are equal [Mon Sep 8 12:53:36 2014] but I can't figure out how to do it on the right-hand side [Mon Sep 8 12:54:02 2014] alternatively, I want to just do it on the left side, then rewrite using IHn', then go back, so the two sides are equal again [Mon Sep 8 12:54:05 2014] but neither approach seems to work [Mon Sep 8 13:03:02 2014] you don't have any lemma that says m + mul m n' = mul m (S n') [Mon Sep 8 13:03:11 2014] unless that's the definition of mul [Mon Sep 8 13:03:21 2014] in which case "reflexivity" should work at the end [Mon Sep 8 13:09:06 2014] No, my definition is: mul (S i') j = j + (mul i' j)) [Mon Sep 8 13:09:07 2014] basically [Mon Sep 8 13:09:14 2014] and mul 0 j = 0 [Mon Sep 8 13:10:51 2014] so no, I don't have a lemma that says that [Mon Sep 8 13:12:25 2014] but I thought... [Mon Sep 8 13:13:59 2014] kba: where are you stuck right now? [Mon Sep 8 13:14:07 2014] mul (S n') m = mul m (S n') [Mon Sep 8 13:14:09 2014] on solving that [Mon Sep 8 13:14:19 2014] commutative? [Mon Sep 8 13:14:21 2014] with pen and paper, that would be so trivial [Mon Sep 8 13:14:22 2014] yes [Mon Sep 8 13:14:29 2014] but Coq won't let me do what I want [Mon Sep 8 13:14:57 2014] If I could do `H_mul_ic` on both sides, then I would have [Mon Sep 8 13:15:12 2014] m + mul n' m = m + mul m n' [Mon Sep 8 13:15:28 2014] and then I could just apply my inductive hypothesis IHn': mul n' m = mul m n' [Mon Sep 8 13:15:30 2014] and be done with it [Mon Sep 8 13:15:37 2014] but for some reason Coq won't let me [Mon Sep 8 13:15:38 2014] But you can't get from mul m (S n') to mul m n', right? [Mon Sep 8 13:16:10 2014] because your definition of mul says mul (S i') j = j + mul i' j [Mon Sep 8 13:16:12 2014] You mean: m + mul m n' = mul m (S n') [Mon Sep 8 13:16:19 2014] and yeah, that's where I'm stuck [Mon Sep 8 13:16:40 2014] I can check what I did, if you want a hint? [Mon Sep 8 13:17:15 2014] I do, even though it would seem most people do it quite differently [Mon Sep 8 13:17:24 2014] by defining bc_left or something [Mon Sep 8 13:17:59 2014] Yeah, I think I have all those lefts and rights [Mon Sep 8 13:18:21 2014] but the most frustrating thing is just that, as I said, it's so trivial on paper [Mon Sep 8 13:18:28 2014] and I can't grasp why Coq won't let me do what I want [Mon Sep 8 13:18:39 2014] then again, I just about half an hour ago found out about assert [Mon Sep 8 13:18:45 2014] so it's likely I just don't know how to do it [Mon Sep 8 13:19:23 2014] Yeah, I have bc_left and bc_right which I use in the base case and ic_right in the inductive case [Mon Sep 8 13:19:41 2014] with ic_right stating that x + mul x y = mul x (S y) [Mon Sep 8 13:19:54 2014] yeah, exactly [Mon Sep 8 13:19:56 2014] So that is essentially what you need to prove, right [Mon Sep 8 13:20:01 2014] Indeed [Mon Sep 8 13:20:26 2014] I would advice you to try to write a proof for why that is. [Mon Sep 8 13:20:37 2014] for why it's true? [Mon Sep 8 13:20:37 2014] The proof itself isn't that difficult and will solve your problem [Mon Sep 8 13:20:45 2014] Yeah, so you can use it as a rewrite [Mon Sep 8 13:23:03 2014] would you do the proof inductively? Or why is it we can't just do it in the other proof? [Mon Sep 8 13:23:23 2014] I would do that inductively, yes. [Mon Sep 8 13:23:55 2014] I'm not sure, but I guess you can do nested induction in Coq. But I would rather do it like this, make Propositions and give them semantically correct names [Mon Sep 8 13:25:07 2014] So this ic_right proposition just requires the bc_left in the base case and H_mult_ic and IHn' in the inductive case. [Mon Sep 8 13:25:20 2014] However, be prepared for some plus_assoc and plus_comm fiddling :) [Mon Sep 8 13:25:27 2014] already did the base case now [Mon Sep 8 13:27:36 2014] You will also need to prove either S(m+n) = S m + n or S n = n + 1 [Mon Sep 8 13:31:29 2014] before I was stuck on: mul (S n') m = mul m (S n') [Mon Sep 8 13:31:42 2014] when I was writing it without an aux function [Mon Sep 8 13:31:45 2014] now I'm stuck on: m + mul m (S n') = mul m (S (S n')) [Mon Sep 8 13:31:48 2014] I'm not sure how that's any better [Mon Sep 8 13:31:53 2014] ^^ [Mon Sep 8 13:34:24 2014] How did you get there? :P [Mon Sep 8 13:36:48 2014] it's the inductive case [Mon Sep 8 13:36:53 2014] for: m + mul m n = mul m (S n). [Mon Sep 8 13:37:06 2014] which is what I'm trying to prove, I assumed [Mon Sep 8 13:37:14 2014] since that was the step I was stuck on in mult_is_comm [Mon Sep 8 13:39:08 2014] or didn't you prove `x + mul x y = mul x (S y)` using induction? [Mon Sep 8 13:40:37 2014] I did, yes. With induction [Mon Sep 8 13:41:17 2014] How long have you been at it now? [Mon Sep 8 13:48:46 2014] been at what? [Mon Sep 8 13:48:48 2014] specifically? [Mon Sep 8 13:49:10 2014] I'm spent a good amount of hours [Mon Sep 8 13:51:41 2014] http://paste.debian.net/plainh/7175062a [Mon Sep 8 13:51:51 2014] as you can see, the inductive case is "m + mul m (S n') = mul m (S (S n'))" [Mon Sep 8 14:34:05 2014] When is this due to? [Mon Sep 8 14:35:23 2014] what is specification_of_multiplication? [Mon Sep 8 14:36:30 2014] mul 0 j = 0 and mul (S i') j = j + (mul i' j)). [Mon Sep 8 14:38:55 2014] I think that specification_of_multiplication thing is getting in your way [Mon Sep 8 14:39:05 2014] using induction and plus_assoc and plus_comm, this proof is about 6 lines long [Mon Sep 8 14:39:19 2014] (if I use ordinary mult) [Mon Sep 8 14:39:44 2014] Indeed. [Mon Sep 8 14:40:02 2014] But the exercise of the assignment is to build it all up from the ground. [Mon Sep 8 14:40:16 2014] Or so we are told :) [Mon Sep 8 14:40:34 2014] ah, I see [Mon Sep 8 14:40:44 2014] then build up plus_assoc and plus_comm from the ground and rejoice :) [Mon Sep 8 14:41:07 2014] I would look hard at how specification_of_multiplication is defined, and what information it is providing you with [Mon Sep 8 14:42:06 2014] We can use plus_assoc and plus_comm though [Mon Sep 8 14:42:40 2014] And plus_0_l and plus_0_r too seeing that we are only allowed to use reflexivity as long as the both sides are perfectly identical [Mon Sep 8 14:42:45 2014] yep [Mon Sep 8 14:52:45 2014] Huh. [Mon Sep 8 14:53:41 2014] My desktop is much faster than my laptop. Proof general takes a while to run my coq file on my laptop... I really should break this up into more files. [Mon Sep 8 14:53:59 2014] mads-: as you know, it was due this Saturday at 23.59 ;) [Mon Sep 8 14:54:39 2014] kba: mads- both taking the same course? [Mon Sep 8 14:54:51 2014] chirpsalot: yup [Mon Sep 8 14:54:55 2014] Awesome. [Mon Sep 8 14:55:03 2014] I'm muy jealous. [Mon Sep 8 14:57:00 2014] mads-: but I assume you've also proven the inductive case for `m + mul m n = mul m (S n).` [Mon Sep 8 14:57:07 2014] which is `m + mul m (S n') = mul m (S (S n'))` [Mon Sep 8 14:57:13 2014] if so, can you give me a hint? [Mon Sep 8 14:59:43 2014] kba: As my induction goal I get S n' + mult (S n') y = mult (S n') (S y) [Mon Sep 8 15:00:11 2014] So I think you are doing induction on the wrong variable [Mon Sep 8 15:01:47 2014] oh you're right [Mon Sep 8 15:19:36 2014] kba: If you are still struggling with it tomorrow and it all seems hopeless, you can just hit me up in my office if you want some hands-on-help. I'm in Turing 116 [Mon Sep 8 15:20:06 2014] what's your full name? [Mon Sep 8 15:24:21 2014] Mads Ravn [Mon Sep 8 15:25:11 2014] thanks [Mon Sep 8 15:25:51 2014] No probs. I will probably be there from around 9, maybe 10. [Mon Sep 8 15:28:52 2014] mads-: you have a building called Turing? [Mon Sep 8 15:29:07 2014] most of our buildings are named after scientists [Mon Sep 8 15:29:13 2014] We don't have anything that cool here :(. [Mon Sep 8 15:31:38 2014] in CS, we have buildings named Turing, Babbage, Shannon, Zuse, Stibitz and more [Mon Sep 8 15:41:45 2014] kba: we have CSC and Athabasca, lol. [Sat Nov 15 17:26:42 2014] [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [Sat Nov 15 21:47:38 2014] What variable to I have to change to make Proof General let me switch away from the *response* buffer? [Sat Nov 15 22:32:18 2014] yeah, proofgeneral does some pain-in-the-ass things with emacs windows [Sat Nov 15 22:32:56 2014] alkabetz: try splitting the window with C-x 2 and then you should be able to change one [Sat Nov 15 22:33:05 2014] if you figure out a real solution, ping me [Sat Nov 15 22:33:20 2014] * sighs [Sun Nov 16 00:12:08 2014] alkabetz: that's what my hack fixes [Sun Nov 16 00:12:19 2014] PG is too aggressive about setting the dedicated flag on buffers [Sun Nov 16 00:14:07 2014] w [Sun Nov 16 00:14:45 2014] Ooh, is this posted somewhere? [Sun Nov 16 00:15:05 2014] it's in my github.com/jwiegley/dot-emacs [Sun Nov 16 00:15:09 2014] look in init.el, and search for coq [Sun Nov 16 04:50:36 2014] hi. I'm trying to implement a tail function for variable length vectors, see http://pastebin.com/DbbiKfrg. applying 'inversion v' to a vector v of length (S n) correctly infers that it must come form a vector v' of length n, but it does not add equality between v and the prolonging of v' to the context - how can I do that? [Sun Nov 16 05:14:21 2014] or maybe it's better just to ask how you would construct the desired tail function :) [Sun Nov 16 06:40:16 2014] torfscholle: http://pastebin.com/FvNqK5Vj It's easier if your functions match well with your datatype. [Sun Nov 16 09:14:21 2014] jgross: thank you! [Sun Nov 16 09:18:22 2014] jgross: I'm wondering, however, if it's possible to encapsulate this compactly using the destruct or inversion tactic. When applying 'inversion v' on 'v : vec_nat (S n)', I'd like to add to the hypotheses 'n0 : nat' 'H : n = n0' 'vp : vec_nat n0' 'm : nat' generated the hypothesis that, up to renaming n by n0 via H, 'v' equals 'concat_vec n0 vp m'. Is there a variant of invertion that does this? [Sun Nov 16 11:59:36 2014] The Lub inductive type is the lower Upper bound I guess ? [Sun Nov 16 14:39:51 2014] johnw: is it okay to bug you every time I find an error in your software-foundations repo? [Sun Nov 16 15:00:16 2014] nkar: I love you ask like it's going to a common occurence :P [Sun Nov 16 15:03:29 2014] mads-: so far, I've found three issues and reported one of them. [Sun Nov 16 17:16:17 2014] nkar: you are most welcome to! [Sun Nov 16 17:16:20 2014] nkar: can you use the GitHub issues? [Sun Nov 16 17:16:27 2014] that way I can process your feedback via normal channels [Sun Nov 16 17:18:18 2014] I'm trying to avoid github. though, I'm thinking I should reconsider this. [Sun Nov 16 17:18:29 2014] well, I stand a much better chance of responding there :) [Sun Nov 16 17:18:41 2014] plus, you can queue the issues up to any depth and I won't care [Sun Nov 16 17:18:57 2014] I understand. [Sun Nov 16 17:19:48 2014] I'll send a pull request or open an issue once (if ever) I decide to create an account. [Sun Nov 16 17:20:04 2014] is this a repo that contains solutions to SF exercises? [Sun Nov 16 17:20:10 2014] ive been looking for an up to date one to compare to [Sun Nov 16 17:20:25 2014] yes [Sun Nov 16 17:20:34 2014] https://gitorious.org/software-foundations [Sun Nov 16 17:20:41 2014] oops, that's mine [Sun Nov 16 17:20:57 2014] https://github.com/jwiegley/software-foundations [Sun Nov 16 17:21:04 2014] adelbertc: ^ [Sun Nov 16 17:21:20 2014] awesome possum [Sun Nov 16 17:21:25 2014] thanks! [Sun Nov 16 17:31:29 2014] I have a feeling that when I resume working on SF, I will start using ssreflect [Sun Nov 16 17:31:36 2014] I'm addicted to some of its simplifications now [Sun Nov 16 17:34:39 2014] anyone got hints on proving rev (rev (h :: t)) = h :: t, given the inductive hypothesis rev (rev t) = t [Sun Nov 16 17:35:15 2014] what happens when you "simpl"? [Sun Nov 16 17:36:11 2014] if nothing, you can make a helper lemma like: rev (h :: t) = rcons t h [Sun Nov 16 17:36:17 2014] Hello :) What is the exact difference between the types Upper_Bound and Lub ? (Defined in Cpo.v) [Sun Nov 16 17:36:19 2014] and then another: rev (rcons t h) = h :: t [Sun Nov 16 17:36:31 2014] simpl gets rev (snoc (rev t) h) = h :: t [Sun Nov 16 17:36:37 2014] and im not sure how to proceed from there either [Sun Nov 16 17:36:38 2014] where is Cpo.v? [Sun Nov 16 17:36:43 2014] in Sets [Sun Nov 16 17:36:58 2014] It's about partial order of sets [Sun Nov 16 17:37:07 2014] adelbertc: ok, then prove that rev (snoc xs x) = x :: rev xs [Sun Nov 16 17:37:23 2014] adelbertc: and then you can use f_equal and you should find yourself at your induction hypothesis [Sun Nov 16 17:38:00 2014] Choups314: I'm not sure what source you're looking at [Sun Nov 16 17:38:01 2014] link? [Sun Nov 16 17:38:14 2014] https://coq.inria.fr/V8.1/stdlib/Coq.Sets.Cpo.html [Sun Nov 16 17:38:31 2014] I guess Lub means Lower Upper Bound ? ^^ [Sun Nov 16 17:38:37 2014] exactlpy [Sun Nov 16 17:38:40 2014] least upper bound [Sun Nov 16 17:40:12 2014] the upper bound of a set is its highest element, according to the ordering relation [Sun Nov 16 17:41:25 2014] see http://en.wikipedia.org/wiki/Least-upper-bound_property [Sun Nov 16 17:41:29 2014] under "Statement of the property" [Sun Nov 16 17:41:47 2014] there you can see that being an upper bound is a component of being a least upper bound [Sun Nov 16 17:44:59 2014] for example, consider the set of numbers [1; 2; 3; 4; 5] [Sun Nov 16 17:45:24 2014] anything >= 5 could be an upper bound, but 5 would be the least upper bound [Sun Nov 16 17:45:47 2014] johnw: ah, got it now. thanks! [Sun Nov 16 17:48:55 2014] johnw : Ok I figured out now ;). In french it's a totally different word .. [Sun Nov 16 17:50:14 2014] johnw: Another thing : The integers set is defined in Integers.v (with the inductive type Integers). But is there a similar type in the standard library for the Reals set (R) ? [Sun Nov 16 18:04:00 2014] that I don't know [Sun Nov 16 23:46:34 2014] Anyone here familiar with PARI/GP? [Mon Nov 17 02:45:51 2014] do I understand correctly that the [rewrite] tactic cannot be used on a hypothesis containing [forall]? [Mon Nov 17 02:50:43 2014] that's correct [Mon Nov 17 02:50:54 2014] you can't rewrite under binders [Mon Nov 17 02:51:30 2014] that's what [apply] is for, got it [Mon Nov 17 02:51:42 2014] well, they don't quite do the exact same thing [Mon Nov 17 02:51:50 2014] yeah, I understand [Mon Nov 17 02:52:19 2014] apply uses a propositional statement P -> Q to change some P into Q. rewrite takes an equality P = Q, to change one or more parts of a statement matching P into Q [Mon Nov 17 02:52:55 2014] so, if the whole statement is P, they will feel awfully similar [Mon Nov 17 02:53:32 2014] wait, but you can use [apply] on a previously defined lemmas [Mon Nov 17 02:53:46 2014] i'm not sure I understand what you mean [Mon Nov 17 02:53:58 2014] let me explain [Mon Nov 17 02:56:18 2014] I'm referring to this "apply uses a propositional statement [...] rewrite takes an equality [...]" but you can do [apply rev_involutive.] where [rev_involutive: forall (X : Type) (l : list X), rev (rev l) = l], which is an equality. am I missing something? [Mon Nov 17 02:57:36 2014] if the statement of your goal (or a hypothesis) is itself an equality, you can use apply [Mon Nov 17 02:57:57 2014] for a hypothesis, it takes a statement of the form P -> Q; for a goal, it can take a statement which is just Q [Mon Nov 17 02:58:39 2014] ah, so you can use it to change a hypothesis, right? [Mon Nov 17 02:58:45 2014] sure [Mon Nov 17 02:58:58 2014] you can even use another hypothesis as the argument to apply [Mon Nov 17 02:59:02 2014] like: apply H in H1 [Mon Nov 17 02:59:10 2014] cool [Mon Nov 17 02:59:10 2014] where H has the form P -> Q, and H1 is of type P [Mon Nov 17 02:59:47 2014] it is actually just function application, hence the name [Mon Nov 17 03:00:20 2014] thanks! [Mon Nov 17 03:00:23 2014] i.e., if my goal is G, and calling function foo gives evidence of G, then the goal is proven [Mon Nov 17 11:00:28 2014] Thinking about proving some things about nonograms. Is there an array type, or should I have two lists with a proof that they are equal length? [Mon Nov 17 11:04:04 2014] eraserhd: there's a Vec type that is a list with a length type. If you have two Vec X n's then you know they're the same length. [Mon Nov 17 11:04:52 2014] the ssreflect libraries also have theorems about matrices, but I don't know how computational they are. [Mon Nov 17 13:28:43 2014] how do i prove that a number is greater than another number [Mon Nov 17 13:28:45 2014] or less than [Mon Nov 17 13:33:32 2014] hi. is there in logic or type theory a concept of quantor variables, for example "variable X is quantified by quantor Q" where Q may turn out to be universal or some other quantifier? [Mon Nov 17 13:33:37 2014] or in coq [Mon Nov 17 14:03:17 2014] benzrf: do you know about the omega tactic? [Mon Nov 17 14:03:29 2014] yea [Mon Nov 17 14:03:40 2014] that will prove a lot of your inequalities for you [Mon Nov 17 14:04:50 2014] oh good [Mon Nov 17 14:04:54 2014] um [Mon Nov 17 14:05:11 2014] the thing is i kind of want to examine the gallina term that it genreates [Mon Nov 17 14:05:19 2014] and i figure omega will probably make it overcomplicated [Mon Nov 17 14:05:21 2014] w/e [Mon Nov 17 14:05:26 2014] by the way i wanted to ask [Mon Nov 17 14:05:31 2014] why are prop, set, and type separate? [Mon Nov 17 14:05:34 2014] why not just have type? [Mon Nov 17 14:11:49 2014] benzrf: set is mostly just old cruft. back in the day it was impredicative but now it's not so it's just an unnecessarily constrained type [Mon Nov 17 14:12:16 2014] prop is useful for extraction. coq guarantees that nothing in set/type depends on anything in prop, so that the extractor can throw all the props away [Mon Nov 17 14:13:10 2014] impredicative? [Mon Nov 17 14:13:15 2014] self-ref? [Mon Nov 17 14:13:17 2014] yeah [Mon Nov 17 14:13:23 2014] what is extraction? [Mon Nov 17 14:13:38 2014] and you mean that you cannot parameterize sets or types with props? [Mon Nov 17 14:13:38 2014] take a gallina term and turn it into an ocaml/haskell/lisp program [Mon Nov 17 14:14:00 2014] you can parametrize/index them on props, but you can't depend on any information in the prop to compute something not in prop [Mon Nov 17 14:30:22 2014] jrw: hmmmmmmmmmmm... ok... [Mon Nov 17 14:30:31 2014] jrw: is there any other difference at all [Mon Nov 17 14:30:42 2014] prop is impredicative [Mon Nov 17 14:30:48 2014] oh [Mon Nov 17 14:31:00 2014] if i take some piece of code and %s/Set/Type/g it, will it still function the same [Mon Nov 17 14:31:12 2014] yes that's true, I think [Mon Nov 17 14:31:21 2014] what about type -> set [Mon Nov 17 14:31:34 2014] ah no then it cant accept props [Mon Nov 17 14:31:44 2014] jrw: why should you ever use set then [Mon Nov 17 14:32:38 2014] benzrf: there may be some corner cases where if you use set you can do something crazy that wouldn't be sound at all levels of the type hierarchy [Mon Nov 17 14:32:44 2014] but generally, there's no reason to use it [Mon Nov 17 14:32:53 2014] alright [Mon Nov 17 14:33:09 2014] how does Prop's impredicativity manifest itsel [Mon Nov 17 14:33:10 2014] f [Mon Nov 17 14:33:18 2014] what exactly can you do that you cant with Set [Mon Nov 17 14:33:21 2014] *Type [Mon Nov 17 14:34:35 2014] in type if you say "forall T : Type, T * T" or whatever, then that pops you up a universe level [Mon Nov 17 14:34:50 2014] but if you say "forall P : Prop, P /\ P" then you get to stay at the same universe level [Mon Nov 17 14:38:34 2014] jrw: hmm... [Mon Nov 17 14:38:39 2014] how so [Mon Nov 17 14:39:06 2014] also, isnt forall just fun [Mon Nov 17 14:39:23 2014] yeah [Mon Nov 17 14:41:34 2014] benzrf: it can be more flexible, so for example if I define "Q := forall P : Prop, A P -> B P" then because that's at the same universe, I could apply Q to itself [Mon Nov 17 14:41:39 2014] I couldn't do that in Type [Mon Nov 17 14:44:05 2014] where does the term "impredicative" come from [Mon Nov 17 14:44:43 2014] Q := fun P : Prop => A P -> B P [Mon Nov 17 14:44:48 2014] er [Mon Nov 17 14:44:55 2014] Q := fun P : Type => A P -> B P [Mon Nov 17 14:45:02 2014] oh i see [Mon Nov 17 14:45:11 2014] that's : Type -> Type [Mon Nov 17 16:40:25 2014] SF question: checking two natlist's for equality, how come Coq will happily simpl beq_natlist (0 :: t) (0 :: t) to beq_natlist t t, but not beq_natlist(S n :: t) (S n :: t) ? [Mon Nov 17 16:40:36 2014] in fact, i dont even know how its simplifying [Mon Nov 17 16:40:43 2014] beq_natlist (0 :: t) (0 :: t) to beq_natlist t t [Mon Nov 17 16:41:29 2014] adelbertc: I think it relies on the definition of :: (or cons). [Mon Nov 17 16:41:43 2014] oh, wait [Mon Nov 17 16:41:47 2014] disregard that [Mon Nov 17 16:42:05 2014] * blinks [Mon Nov 17 16:42:34 2014] if i simpl on the S n :: t bit, all i get is the definition :( [Mon Nov 17 16:43:06 2014] I'm not sure but it's probably because O doesn't accept any arguments. [Mon Nov 17 16:45:14 2014] perhaps then i need to prove if beq_nat (n :: t) (n :: t) then beq_nat(S n :: t) (S n :: t) [Mon Nov 17 16:46:28 2014] adelbertc: does the theorem look like this: forall n, beq_nat n n = true? [Mon Nov 17 16:46:36 2014] yep [Mon Nov 17 16:46:41 2014] Hello, is there a type for the reals Set (I mean R in math), like Integers (Defined in theories/Sets/Integers.v) that works for the natural numbers ? [Mon Nov 17 16:46:44 2014] its the beq_natlist refl exercise [Mon Nov 17 16:46:55 2014] well, beq_natlist, not beq_nat [Mon Nov 17 16:48:29 2014] adelbertc: why are you saying "perhaps"? have you carefully read the induction chapter? [Mon Nov 17 16:48:38 2014] do you understand when it's needed? [Mon Nov 17 16:49:23 2014] i (think?) have a fairly good grasp of when its needed, i can usually anticipate when i need it versus say, just destruct [Mon Nov 17 16:49:43 2014] i also just realized [Mon Nov 17 16:49:45 2014] thats exactly whats happening [Mon Nov 17 16:49:48 2014] i had a brain fart going on [Mon Nov 17 16:49:52 2014] im currently at [Mon Nov 17 16:50:21 2014] given IHt: true = beq_natlist t t and IHn: true = beq_natlist (n :: t) (n :: t) prove true = beq_natlist (S n :: t) (S n :: t) [Mon Nov 17 16:50:58 2014] this is with induction on (l : natlist as [|h t] and induction on (h : nat as [| n]). [Mon Nov 17 16:51:01 2014] so, do you know how to proceed? [Mon Nov 17 16:51:05 2014] yeah, I get it [Mon Nov 17 16:51:28 2014] a bit stuck at the moment [Mon Nov 17 16:52:03 2014] adelbertc: what happens if you simpl [Mon Nov 17 16:52:59 2014] becomes [Mon Nov 17 16:52:59 2014] true = (if beq_nat n n then beq_natlist t t else false) [Mon Nov 17 16:53:19 2014] right, the definition of beq_natlist gets expanded [Mon Nov 17 16:53:50 2014] adelbertc: do you see where to go from here [Mon Nov 17 16:54:02 2014] not sure if thats ever useful or not. if it is, SF hasnt covered how to approach that yet [Mon Nov 17 16:54:11 2014] ive just never done a proof involving the expansion of the def [Mon Nov 17 16:54:17 2014] so i stopped exploring that route [Mon Nov 17 16:54:18 2014] adelbertc: hold on [Mon Nov 17 16:54:22 2014] but maybe in this case i need to? o_O [Mon Nov 17 16:54:22 2014] adelbertc: don't worry, I got confused here too [Mon Nov 17 16:54:23 2014] adelbertc: you're getting closer [Mon Nov 17 16:54:29 2014] adelbertc: you're almost there [Mon Nov 17 16:54:34 2014] adelbertc: what do you have? [Mon Nov 17 16:54:53 2014] i did a simpl which got me that, then i rewrote IHt so i have true = (if beq_nat n n then true else false) [Mon Nov 17 16:55:08 2014] adelbertc: very close [Mon Nov 17 16:55:09 2014] beq_nat_refl time maybe [Mon Nov 17 16:55:21 2014] adelbertc: i'd imagine [Mon Nov 17 16:55:25 2014] adelbertc: you could just use an assert [Mon Nov 17 16:55:46 2014] adelbertc: which tactic are you going to use for that? [Mon Nov 17 16:56:01 2014] nkar: i first tried rewrite but it didnt like that, so yeah now im trying assert [Mon Nov 17 16:56:22 2014] adelbertc: i feel like you probably didn't need to do induction on h [Mon Nov 17 16:56:39 2014] just got it [Mon Nov 17 16:57:00 2014] so i suppose getting the expanded definition isnt necessarily a hint that im doing it wrong [Mon Nov 17 16:57:08 2014] benzrf: yeah let me remove that line and try again [Mon Nov 17 16:57:13 2014] adelbertc: no, its a sign youre doing it right, iff you get closer [Mon Nov 17 16:57:27 2014] adelbertc: what's the overall goal [Mon Nov 17 16:57:35 2014] benzrf: is there a way to solve it without using induction? the current proof relies on the induction hypothesis. [Mon Nov 17 16:57:57 2014] if we don't count tactics which haven't been covered so far [Mon Nov 17 16:58:02 2014] nkar: it doesn't [Mon Nov 17 16:58:04 2014] ? [Mon Nov 17 16:58:06 2014] er, it does? [Mon Nov 17 16:58:23 2014] yes, it does use the induction hypothesis [Mon Nov 17 16:58:29 2014] oh wait [Mon Nov 17 16:58:38 2014] it relies on induction over the list [Mon Nov 17 16:58:40 2014] at least mine does [Mon Nov 17 16:58:43 2014] no, no it doesnt [Mon Nov 17 16:58:49 2014] nkar: the 2nd one isnt used [Mon Nov 17 16:58:58 2014] >IHn: true = beq_natlist (n :: t) (n :: t) [Mon Nov 17 16:59:11 2014] but you can jump straight to true = (if beq_nat n n then true else false) [Mon Nov 17 16:59:17 2014] no IHn needed [Mon Nov 17 16:59:54 2014] benzrf: I /q'd you my proof [Mon Nov 17 17:00:10 2014] yeah [Mon Nov 17 17:00:14 2014] that doesn't need IHn [Mon Nov 17 17:00:52 2014] does adelbertc use induction on n, too? [Mon Nov 17 17:00:53 2014] obviously you need induction but i think adelbertc used an extra induction [Mon Nov 17 17:00:54 2014] ah, so you just need destruct [Mon Nov 17 17:01:00 2014] nkar: nope i took the induction on n out [Mon Nov 17 17:01:01 2014] adelbertc: im not sure you even need that [Mon Nov 17 17:01:16 2014] adelbertc: nkar's proof does not use it [Mon Nov 17 17:01:30 2014] adelbertc: you've nearly proved it already [Mon Nov 17 17:01:43 2014] so if i follow intros l with simpl i get nothing, if i destruct on l i can solve the [] case, and then from the h :: t case i can do the beq_nat_refl stuff [Mon Nov 17 17:01:44 2014] go back to the beq_nat_refl step and see what's left [Mon Nov 17 17:02:09 2014] yeah i got the solution now :-) thanks for the help! [Mon Nov 17 17:02:14 2014] but still interested in seeing how litlte induction i can get away with [Mon Nov 17 17:02:29 2014] no problem [Mon Nov 17 17:03:30 2014] adelbertc: consider uploading your solutions somewhere, so others could learn from them [Mon Nov 17 17:03:42 2014] yep, going to create a github repo very soon [Mon Nov 17 20:14:53 2014] is there a way to debug what a tactic such as [assumption] is doing in terms of type conversions? i have a situation where [assumption] takes a very long time to finish, and i'd like to find a way to pin down what's getting expanded out in the types and causing some kind of explosion.. [Mon Nov 17 20:22:46 2014] nickolai: unfortunately that sort of thing is very difficult to debug and there isn't much tooling to support it. in your case can you try picking the right assumption by hand and seeing how long [apply H] takes? [Mon Nov 17 20:23:53 2014] it takes much longer than i've been willing to wait on any given occasion (e.g., easily minutes) [Mon Nov 17 20:24:48 2014] nickolai: you mean the apply takes that long too? [Mon Nov 17 20:25:39 2014] this general class of problem shows up repeatedly in a larger project i'm working on. each instance can be debugged by manually taking apart the goal and the (almost-matching) hypothesis, until i find some term that can be marked Opaque to stop this degenerate behavior. but each time it takes me quite a while to do this, and it's a lot of manual effort. [Mon Nov 17 20:25:52 2014] yes, [apply H] takes a very long time [Mon Nov 17 20:27:05 2014] what makes this particularly annoying is that, often times, H isn't the right hypothesis, and after a very long time, [apply H] will eventually fail. this annoys me because this means [auto] is unusable, since the first thing it does is try [assumption]... [Mon Nov 17 20:27:53 2014] right [Mon Nov 17 20:28:46 2014] this kind of thing should only happen if you have large concrete values in your context. on abstract values the evaluation will bottom out pretty quickly in my experience. [Mon Nov 17 20:28:54 2014] is that the case for you? [Mon Nov 17 20:29:27 2014] right, it tends to happen in situations that involve conversions between [nat] and our own fixed-width integer representation; as you can imagine, those expand out to large trees of mod/div operations. [Mon Nov 17 20:30:02 2014] yeah [Mon Nov 17 20:30:07 2014] which is why marking things Opaque sometimes (but somehow not always) helps.. [Mon Nov 17 20:31:26 2014] perhaps another thing that could help: is there something like a "Really Opaque"? the only two options i seem to have is the literal [Opaque], which doesn't seem to always "work", and the [Module Type] trick to fully hide the impl details, which is quite hard to apply retroactively to a definition, and is a lot of overhead even when defining something upfront. [Mon Nov 17 20:33:38 2014] (just in case, by the [Module Type] trick i mean defining a module type with just the type signature for some expression, along with a theorem saying it's [eq] to its implementation.) [Mon Nov 17 20:37:52 2014] right, yeah that's high overhead [Mon Nov 17 20:39:15 2014] reading about Coq's conversion rules, it sounds like [Opaque] defers beta-reduction but doesn't prevent it, so probably what i was seeing is that [Opaque] helps in cases when [apply H] is the right answer, but fails to help when [apply H] isn't the right answer.. [Mon Nov 17 20:40:05 2014] i suppose i want my hypothetical [Really Opaque] to prohibit beta-reduction of some term altogether. i wonder if that would still allow theorems involving that term to be type-checked by the kernel.. [Mon Nov 17 20:42:20 2014] nickolai: right. I don't have a great answer to this. could you try something where you introduce section variables for all the concrete values to abstract them and then prove your theorems, introducing section hypotheses as necessary to get properties you need. then when you're done apply the results outside the section to your actual values [Mon Nov 17 20:42:57 2014] kind of a lightweight version of the module type trick [Mon Nov 17 20:44:22 2014] maybe it's my own bias against modules and for sections... [Mon Nov 17 20:44:39 2014] nickolai: for the proof where assumption suceeds but is slow: print the proof term, that should give you a clue at least as to the nature of the massive term being expanded [Mon Nov 17 20:44:50 2014] that's how I usually find out what to mark as 'abstract' or 'Opaque' [Mon Nov 17 20:44:55 2014] (or 'Qed') [Mon Nov 17 20:47:46 2014] ah, good call, that's at least something. [Mon Nov 17 20:48:31 2014] relatedly, turns out there's another trick for making things more opaque than [Opaque]: http://t62744.science-mathematics-logic-coq-club.mathematicstalk.info/making-a-definition-really-opaque-t62744.html [Tue Nov 18 09:32:44 2014] does coq have a built in map/dict/hash library [Tue Nov 18 09:46:31 2014] Does FMap (in the standard library) suit your needs? [Tue Nov 18 11:05:54 2014] Hrmm, am I reading it right that the vector constructor is "t"? [Tue Nov 18 11:06:33 2014] you are. Just don't require import. Require only. [Tue Nov 18 11:06:41 2014] Then you can use Vector.t [Tue Nov 18 11:07:00 2014] it's an odd divergence from the other theories' naming conventions. [Tue Nov 18 11:07:24 2014] If there’s consistency in any of the standard library, it has eluded me. :) [Tue Nov 18 11:07:47 2014] zing [Tue Nov 18 11:15:22 2014] IIRC, https://github.com/coq-ext-lib/coq-ext-lib is supposed to help fix this, but I haven’t used it yet, so I can’t really comment. [Tue Nov 18 11:29:28 2014] Do I even want to use vectors in Coq? What's the best way to represent a nonogram board (an h x w array of bool)? [Tue Nov 18 11:33:54 2014] Well it depends on how much abstraction you want to work through. It's sometimes nice to represent a matrix as a finite function from index to value (say M : matrix A m n is defined as M_{i,j} which is a function fun (i : fin m) (j : fin j) => some_A) [Tue Nov 18 11:36:47 2014] ianjneu: What's `fin`? [Tue Nov 18 11:36:59 2014] (feel free to yell at me if I'm being annoying) [Tue Nov 18 11:38:29 2014] I don’t think you’re being annoying. I’ve struggled several times to figure out how to represent matrices in Coq. :) [Tue Nov 18 11:46:19 2014] eraserhd: fin is the index type for vectors. [Tue Nov 18 11:46:29 2014] It might also be Fin.t [Tue Nov 18 11:56:08 2014] Oh, because they are 1-indexed. [Tue Nov 18 11:56:11 2014] :( [Tue Nov 18 11:56:56 2014] Perhaps I just add a proof parameter that all the rows are the same length and use lists. [Tue Nov 18 12:00:06 2014] eraserhd: look for previous attempts at matrix code. It's more painful than you think to do what you just proposed. [Tue Nov 18 12:05:08 2014] hrmm. [Tue Nov 18 12:06:53 2014] Well, since I'm doing this to learn Coq, and I can't figure out why that doesn't work, I'm gonna do it and either succeed or figure out why it won't work. :D [Tue Nov 18 12:08:48 2014] as conor mcbride would say, "push the types in" instead of having correctness criteria on the outside. [Tue Nov 18 12:13:18 2014] Hello :) [Tue Nov 18 12:13:27 2014] Choups314: ahoy [Tue Nov 18 12:13:35 2014] Why can't I declare this type : "Inductive intervalle : (Ensemble R) := [Tue Nov 18 12:13:35 2014] | intervalle_vide : intervalle. " ? [Tue Nov 18 12:14:04 2014] It complains with "The term "intervalle" has type "Ensemble R" which should be Set, Prop or Type." ... [Tue Nov 18 12:15:11 2014] While "Ensemble R" has type Type .... Anyway, this is what says the Check function [Tue Nov 18 12:17:03 2014] Inductive creates an optionally indexed type family. You can only have Inductive D (I : T) ... : forall (P : U) ..., Set [or Prop or Type] := blah. [Tue Nov 18 12:17:50 2014] Ensemble T has a specific way to inhabit it. You have to use the interface that it gives you. [Tue Nov 18 12:18:14 2014] does coq have a built in map/dict/hash library [Tue Nov 18 12:19:23 2014] benzrf: it has a functor form called FMap that sucks major shit. [Tue Nov 18 12:20:05 2014] There's a user contrib called containers that uses typeclasses, but it still has a big problem that no type theory to date has managed to solve. [Tue Nov 18 12:21:18 2014] You can't define something like Inductive Value : Type := closure : lambda_term -> map name Value -> Value. where map is the type constructor for the abstract map type. [Tue Nov 18 12:21:37 2014] Value is in a negative position, and barf. [Tue Nov 18 12:22:26 2014] but if you don't need nestable maps, you should be fine. [Tue Nov 18 12:22:55 2014] don't even try to key maps by maps though. You will have a terrible time in setoid hell. [Tue Nov 18 12:28:57 2014] Is it possible to use a recursive definition ? [Tue Nov 18 12:30:08 2014] Choups314: depends if your recursion terminates. [Tue Nov 18 12:30:34 2014] You can use the Fixpoint command for structurally recursive definitions. [Tue Nov 18 12:31:44 2014] You can use Program Fixpoint to give a terminating ordering that you prove decreases on each recursive call [Tue Nov 18 13:50:52 2014] nickolai: I'd made a feature request at https://coq.inria.fr/bugs/show_bug.cgi?id=3389. For a while, [Opaque] was really opaque to conversion in trunk; it might have since been switched back. There's also a trick used in ssreflect called locking. See [locked] and [locked_with] at the top of http://ssr.msr-inria.inria.fr/doc/ssreflect-1.5/Ssreflect.ssreflect.html. [Tue Nov 18 15:27:05 2014] For example if I define A with "Parameter A : Set", and then I define B with "Parameter B : A", there is no means to "cast" (Like in C/C++ for instance) the type of B to Set ? [Tue Nov 18 16:10:14 2014] Choups314: no, because B is much, much smaller than Set. If A is Int, then B is a number, which is not the same thing as Set at all [Tue Nov 18 16:16:23 2014] johnw : Ho yes you are right .. I'm not used enough with coq to see this ... :p [Tue Nov 18 16:17:21 2014] how accurate would it be to say the latter half of SF gets more into PL metatheory/type theory than it does say "dependent types" in general? considering stopping for a bit after the first half, learning more about DTs/exploring other DT langs, and then coming back and finishing the 2nd half [Tue Nov 18 16:44:10 2014] adelbertc: I think that's fair. [Tue Nov 18 17:03:35 2014] adelbertc: yeah, I'm doing sort of the same thing [Tue Nov 18 17:03:44 2014] adelbertc: I really like how the second half gets into using Coq to do language modelling, but I want to get some more background before doing it [Tue Nov 18 17:03:53 2014] likewise. [Tue Nov 18 17:03:57 2014] its definitely something im interested in [Tue Nov 18 17:04:06 2014] but i also want to learn more about dependent types in general before diving into that [Tue Nov 18 17:04:08 2014] btw, Chlipala's book is almost all about this [Tue Nov 18 17:04:14 2014] so it makes an excellent companion to the 2nd half of SF [Tue Nov 18 17:04:19 2014] also, see the Ynot project [Tue Nov 18 17:04:26 2014] all about.. PL metatheory? [Tue Nov 18 17:04:28 2014] or DTs [Tue Nov 18 17:04:29 2014] and other things that Appel and Morrisett have done [Tue Nov 18 17:04:36 2014] about using DTs to model systems [Tue Nov 18 17:04:45 2014] and Coq in particular to prove things about those systems [Tue Nov 18 17:04:53 2014] ah cool [Tue Nov 18 17:05:03 2014] i've only heard his approach to Coq is very..... er.... interesting [Tue Nov 18 17:05:41 2014] his book has two components [Tue Nov 18 17:05:48 2014] one is advanced proof automation [Tue Nov 18 17:05:53 2014] the other is leveraging dependent types [Tue Nov 18 17:06:13 2014] it's a great book in both respects [Tue Nov 18 17:06:17 2014] i'm reading it again the second time right now [Tue Nov 18 17:06:30 2014] i've heard lots ofg ood things about it [Tue Nov 18 17:06:41 2014] it's quite excellent, if you intend to really use Coq for anything [Tue Nov 18 17:06:56 2014] if Coq is merely a curiosity, then it may contain too much detail [Tue Nov 18 17:06:59 2014] i ended up starting with SF first because i find i need exercises to verify my understanding of the material [Tue Nov 18 17:07:07 2014] johnw: does coq have anything for assoclists or the like built in [Tue Nov 18 17:07:10 2014] SF is definitely the better place to start [Tue Nov 18 17:07:12 2014] i think i'm past the "merely a curiosity" stage :-) [Tue Nov 18 17:07:19 2014] CPDT is more for "getting real things done in Coq" [Tue Nov 18 17:07:23 2014] DTs are fun [Tue Nov 18 17:07:24 2014] benzrf: yes [Tue Nov 18 17:08:07 2014] benzrf: https://coq.inria.fr/library/Coq.FSets.FMapAVL.html [Tue Nov 18 17:08:24 2014] granted, I found it a tremendous pain to get started with, being used to Haskell [Tue Nov 18 17:08:49 2014] probably an OCaml user wouldn't find it so painful [Tue Nov 18 17:09:02 2014] i've programmed a bit in haskell, most of my time is spent in scala [Tue Nov 18 17:09:27 2014] if i squint enough i can see the resemblance between scala and ocaml. though scala will often yell at me once i try to do anything non-trivial with the type system [Tue Nov 18 17:10:30 2014] thx [Tue Nov 18 17:11:23 2014] benzrf: see also https://github.com/coq-ext-lib/coq-ext-lib/blob/master/theories/Structures/Maps.v [Tue Nov 18 17:11:30 2014] coq-ext-lib tries to bridge some of the Haskell/Coq gap [Tue Nov 18 17:12:30 2014] what does require exp do [Tue Nov 18 17:13:16 2014] what is the literal syntax? [Tue Nov 18 17:15:05 2014] Require Export Sth. [Tue Nov 18 17:16:23 2014] johnw: have you read Coq'Art? [Tue Nov 18 17:16:35 2014] benzrf: That loads the Sth module, imports all its contents into the current module, and re-exports the contents to modules that load the current one. [Tue Nov 18 17:16:55 2014] benzrf: It’s equivalent to [Require Sth. Import Sth. Export Sth.], if that is helpful at all. [Tue Nov 18 17:17:21 2014] aha [Tue Nov 18 17:17:38 2014] oh, i didnt even know Require Foo and Import Foo were separate things [Tue Nov 18 17:17:39 2014] thx [Tue Nov 18 17:17:46 2014] You’re welcome. [Tue Nov 18 17:17:49 2014] what does Import Bluh do if you dont Require Bluh [Tue Nov 18 17:17:57 2014] Gives you an error, usually. [Tue Nov 18 17:18:06 2014] Unless Bluh is defined in the same file as the [Import]. [Tue Nov 18 17:18:18 2014] [Require] deals with files; [Import] and [Export] deal with modules. [Tue Nov 18 17:18:18 2014] kk [Tue Nov 18 17:19:06 2014] https://gist.github.com/24bec55bd1e35f1c8c9a [Tue Nov 18 17:27:25 2014] adelbertc: I haven't read Coq'Art yet [Tue Nov 18 18:28:01 2014] ia0 [Tue Nov 18 18:28:05 2014] johnw: https://gist.github.com/24bec55bd1e35f1c8c9a [Tue Nov 18 23:39:24 2014] benzrf: hmm? [Tue Nov 18 23:41:01 2014] johnw: why do i get that error? [Tue Nov 18 23:42:09 2014] why are you expecting empty to be defined? [Tue Nov 18 23:44:56 2014] because i imported the thing? [Tue Nov 18 23:45:14 2014] and at https://coq.inria.fr/library/Coq.FSets.FMapAVL.html it says Empty Map [Tue Nov 18 23:45:14 2014] Definition empty := Leaf. [Tue Nov 18 23:45:27 2014] there's a different between importing what's called a "library" [Tue Nov 18 23:45:29 2014] and importing a module [Tue Nov 18 23:45:33 2014] you'll need to do this: [Tue Nov 18 23:45:40 2014] Require Import FMapAVL. [Tue Nov 18 23:46:17 2014] Module Import M := FMapAVL.Make(Nat_as_OT). [Tue Nov 18 23:46:24 2014] that gives you a map from nat's to whatever [Tue Nov 18 23:46:42 2014] to use your own key type, you'll need to build your own OrderedType module [Tue Nov 18 23:46:49 2014] see the docs for how Nat_as_OT was constructed [Tue Nov 18 23:47:13 2014] you may additional need Require Export Coq.Structures.OrderedTypeEx. too [Tue Nov 18 23:47:17 2014] http://stackoverflow.com/questions/14489232/finite-map-example [Tue Nov 18 23:49:51 2014] ah [Tue Nov 18 23:49:55 2014] i [Tue Nov 18 23:49:58 2014] i don't know any of this [Tue Nov 18 23:50:12 2014] like, I said, coming from Haskell, using FMap is not fun [Tue Nov 18 23:50:16 2014] scree [Tue Nov 18 23:50:39 2014] can i just use an assoclist [Tue Nov 18 23:50:53 2014] it'll be the exact same [Tue Nov 18 23:50:57 2014] ? [Tue Nov 18 23:51:03 2014] same interface [Tue Nov 18 23:51:28 2014] i mean [(k, v)] in haskell [Tue Nov 18 23:51:34 2014] i know exactly what you mean [Tue Nov 18 23:51:38 2014] ok i thought so... [Tue Nov 18 23:51:47 2014] i didnt understand what you meant so i guessed maybe there was a communicatoin error [Tue Nov 18 23:51:53 2014] :b [Tue Nov 18 23:52:15 2014] johnw: wait, do you mean there's an existing assoclist module that i'd have to do the same dance for [Tue Nov 18 23:52:20 2014] yes [Tue Nov 18 23:52:22 2014] ah [Tue Nov 18 23:52:35 2014] i was thinking of just rewriting naive impls of the basic functions involved [Tue Nov 18 23:52:55 2014] https://coq.inria.fr/library/Coq.FSets.FMapList.html [Tue Nov 18 23:53:00 2014] basically i just want a simple free abelian group setup so i can try out using dependent typing for dimensioned units [Tue Nov 18 23:53:03 2014] that's an FMap based on an assoc list [Wed Nov 19 04:35:31 2014] can I re-open a Module in order to add definitions to it? [Wed Nov 19 05:57:51 2014] johnw: are you looking for a key binding allowing to jump to the Module declaration? [Wed Nov 19 14:38:21 2014] johnw: Modules are not mix-in. However, if you define A.B.x and A'.B.y, and then [Import] A and A', you can refer to both [B.x] and [B.y]. You can also [Include] two modules to make a new module with the definitions of both of your original ones. [Wed Nov 19 14:53:40 2014] jgross: thanks, that's what I've been doing [Wed Nov 19 14:53:53 2014] I was just wondering if there was a way to avoid so many extra module names [Wed Nov 19 19:11:36 2014] does coq have strings [Wed Nov 19 19:53:17 2014] yes [Wed Nov 19 19:53:26 2014] Coq.Strings.String. [Wed Nov 19 19:53:30 2014] Open Scope string_scope. [Wed Nov 19 19:53:42 2014] hmmmmm [Wed Nov 19 19:53:53 2014] what about floats [Wed Nov 19 19:53:56 2014] what is it that you want to do with Coq, benzrf? [Wed Nov 19 19:54:47 2014] something that would probably be better accomplished in idris [Wed Nov 19 19:55:12 2014] i just want me some good old fashioned type level free abelian groups, maaaaaaaan [Wed Nov 19 19:55:46 2014] so i can tag me numbers with em for when i gotta solve annoying problems featuring physical quantities [Wed Nov 19 19:55:58 2014] ah, I see [Wed Nov 19 19:56:54 2014] that way i will get a type error if i fuck up my math [Wed Nov 19 19:57:11 2014] also i can show it to my teacher [Wed Nov 19 19:57:15 2014] ahh [Wed Nov 19 19:57:40 2014] units in phys act like a free abelian group ysee [Wed Nov 19 19:57:53 2014] in that case I'd probably recommend http://ssr2.msr-inria.inria.fr/doc/ssreflect-1.4/Ssreflect.abelian.html [Wed Nov 19 19:57:55 2014] actually i was looking for a structure a while back to fully formalize it [Wed Nov 19 19:58:20 2014] when you restrict yourself to positive reals & mult, it is indeed a product group [Wed Nov 19 19:58:37 2014] also see the quotient library in ssreflect/mathcomp [Wed Nov 19 19:58:48 2014] at least here (http://books.google.com/books?id=7VwlBAAAQBAJ&pg=PA85&lpg=PA85&dq=ssreflect+abelian&source=bl&ots=2ISgCAYI3K&sig=mnyN08GvzGZXVFdu5L5Bb1_vU4E&hl=en&sa=X&ei=hDxtVNfONoujyQTeqYLYCA&ved=0CDYQ6AEwBA#v=onepage&q=ssreflect%20abelian&f=false) they use it to develop a theory of free abelian groups [Wed Nov 19 19:58:53 2014] but im not sure there's an interesting corresponding structure that captures how full mult & addition work [Wed Nov 19 19:59:09 2014] i think there's a category here somewher [Wed Nov 19 19:59:10 2014] e [Wed Nov 19 19:59:12 2014] there always is [Wed Nov 19 19:59:19 2014] groupoids? [Wed Nov 19 19:59:22 2014] perhaps [Wed Nov 19 19:59:50 2014] ski would know [Wed Nov 19 20:02:44 2014] johnw: i already wrote this abomination: [Wed Nov 19 20:03:11 2014] https://gist.github.com/52d28385bf99e1505276 [Wed Nov 19 20:05:13 2014] johnw: the keys are terms & the values are coefficients, naturally [Wed Nov 19 20:05:34 2014] i guess that should be ab_add [Wed Nov 19 20:19:31 2014] Can anybody tell me why this wont work? http://pastebin.com/6QsEqSVE [Wed Nov 19 20:20:13 2014] Captcha257: at a glance, tauto not working suggests you are trying sth that requires dne [Wed Nov 19 20:20:36 2014] Captcha257: have you tried using intro[s] first [Wed Nov 19 20:20:40 2014] i dont know if that affects anything [Wed Nov 19 20:20:54 2014] wouldn't it be: ~(P /\ ~P) -> ~P \/ P? [Wed Nov 19 20:21:20 2014] it should be equivalent. Right? [Wed Nov 19 20:21:26 2014] sure [Wed Nov 19 20:21:46 2014] hmm [Wed Nov 19 20:21:54 2014] apparently, only if P is decidable [Wed Nov 19 20:22:06 2014] from the stdlib: Decidable.not_and : forall A B : Prop, Decidable.decidable A -> ~ (A /\ B) -> ~ A \/ ~ B [Wed Nov 19 20:22:07 2014] [Wed Nov 19 20:22:38 2014] but isn't tauto a classical logic reasoner? [Wed Nov 19 20:22:56 2014] n [Wed Nov 19 20:23:10 2014] johnw: whats Decidable [Wed Nov 19 20:23:14 2014] "tauto succeeds on any instance of an intuitionistic tautological proposition" [Wed Nov 19 20:23:29 2014] it fails saying "Error: Classical tauto failed." [Wed Nov 19 20:23:33 2014] Decidable means there is a way to test whether it is true or not true [Wed Nov 19 20:23:48 2014] note that it says "intuitionistic", not classical [Wed Nov 19 20:24:16 2014] right, but why would the error say "Classical" [Wed Nov 19 20:24:27 2014] good question [Wed Nov 19 20:27:10 2014] strangely enough, this works : http://pastebin.com/0QLzPfg1 [Wed Nov 19 20:27:45 2014] Captcha257: that's trivially easy [Wed Nov 19 20:27:51 2014] ~P is really P -> False [Wed Nov 19 20:27:55 2014] so, [Wed Nov 19 20:28:03 2014] (P /\ (P -> False)) -> False [Wed Nov 19 20:28:06 2014] pretty simpl [Wed Nov 19 20:29:39 2014] this is the LEM, so it should work only if using classical reasoning.. but I'm using tauto. [Wed Nov 19 20:29:52 2014] Captcha257: it's not the LEM [Wed Nov 19 20:30:06 2014] Captcha257: LEM is P \/ ~P [Wed Nov 19 20:30:22 2014] Its not ~(P /\ ~P)? [Wed Nov 19 20:30:41 2014] Captcha257: ~(P /\ ~P) means "not both P and not P" [Wed Nov 19 20:30:52 2014] Captcha257: P \/ ~P means "either P or not P" [Wed Nov 19 20:31:09 2014] the latter is LEM [Wed Nov 19 20:31:52 2014] In intuitionnistic logic, you don't have the usual De Morgan's law [ ~(P /\ Q) <-> ~P \/ ~Q ] [Wed Nov 19 20:32:01 2014] LEM can be axiomated in Coq, and is consistent with its logic if done, but cannot be proven using the logic of Coq alone [Wed Nov 19 20:34:00 2014] Captcha257: when you think 2 props are equivalent but coq acts like they're not, try thinking through why they seem equal [Wed Nov 19 20:34:12 2014] Captcha257: then catch yourself applying DNE without thinking [Wed Nov 19 20:34:48 2014] DNE? [Wed Nov 19 20:37:51 2014] So how can I get Coq to prove ~(P /\ ~P) -> (P \/ ~P) automatically? [Wed Nov 19 20:38:05 2014] if also need to know that P is decidable [Wed Nov 19 20:38:10 2014] if so, you can use that lemma I mentioned before [Wed Nov 19 20:38:15 2014] s/if also/you also [Wed Nov 19 20:38:58 2014] as for automatically... you need to register that lemma as a Hint Resolve, and then use auto [Wed Nov 19 20:38:59 2014] johnw: Decidable.not_and? [Wed Nov 19 20:39:03 2014] right [Wed Nov 19 20:40:03 2014] actually, that's not quite it [Wed Nov 19 20:45:34 2014] Captcha257: https://gist.github.com/786e283198bcf6dabb93 [Wed Nov 19 20:45:59 2014] as you can see, I need decidable P to prove it [Wed Nov 19 20:48:54 2014] i get a syntax error trying to run it. Do I need to add an Require Import? [Wed Nov 19 20:49:05 2014] I used the ssreflect library to write that [Wed Nov 19 20:49:11 2014] i didn't think you'd want to use my actual proof [Wed Nov 19 20:49:20 2014] see if you can rewrite it using regular Coq tactics [Wed Nov 19 20:51:58 2014] I can get this pretty easily : http://pastebin.com/eZTS2ctt [Wed Nov 19 20:52:23 2014] haha [Wed Nov 19 20:52:25 2014] yeah, that's axiom ;) [Wed Nov 19 20:52:28 2014] an axiom [Wed Nov 19 20:52:31 2014] https://coq.inria.fr/library/Coq.Logic.Classical_Prop.html [Wed Nov 19 20:56:06 2014] Ok,I see now : http://pastebin.com/ZLNMzERN . Thanks! [Wed Nov 19 20:56:26 2014] but, you're not proving anything [Wed Nov 19 20:56:31 2014] your antecedent is completely ignored [Wed Nov 19 20:56:38 2014] you might as well not have this lemma [Wed Nov 19 20:57:01 2014] since it simply restates the axiom and then uses the axiom to define itself [Thu Nov 20 02:35:17 2014] I just download coqide-8.4pl5.dmg, I run it on os x 10.10, it pops up a window says that "failed to load coqtop. Reset the preference to default?", I have to choose to path to "/Applications/CoqIDE_8.4pl5.app/Contents/Resources/bin", is there any way to config the coqide path? [Thu Nov 20 02:42:31 2014] Oh, I see, I have to set the coqtop to "/Applications/CoqIDE_8.4pl5.app/Contents/Resources/bin/coqtop" in preferences [Thu Nov 20 10:49:21 2014] hello. are there something like typeclasses/interfaces in coq? that is, abstract types which satisfy certain properties? [Thu Nov 20 11:37:29 2014] schoppenhauer: https://coq.inria.fr/distrib/v8.2/refman/Reference-Manual024.html [Thu Nov 20 11:38:02 2014] kthx [Thu Nov 20 11:38:55 2014] they're not really abstract types that satisfy properties so much as they are a meta-system for working conveniently with their current instantiations. [Thu Nov 20 11:40:00 2014] typeclass resolution happens before you do any proofs, so you have to be careful to not accidentally use implementation details. It's disappointing, but you end up having to break those abstractions to use Coq in most cases. [Thu Nov 20 11:40:39 2014] ok. [Thu Nov 20 11:41:02 2014] if you use modules and signatures, then you're using a second class system and can't quantify over objects that have those signatures. [Thu Nov 20 11:41:18 2014] I can also use dependent records. [Thu Nov 20 11:41:19 2014] Your best bet is to use dependent records [Thu Nov 20 12:25:44 2014] I'm trying to define the set {x \in R | \forall n \in N, x = 2n } (The even naturals) http://latex.codecogs.com/gif.latex?%5C%7Bx%20%5Cin%20R%20%5Cmid%20%5Cforall%20n%20%5Cin%20N%2C%20x%20%3D%202n%20%5C%7D [Thu Nov 20 12:28:50 2014] http://pastebin.com/E7msUzin [Thu Nov 20 12:29:49 2014] I would like to define a set (Of the type "Ensemble nat") that contains all the even natural numbers). I did this ^^^, but this is not working .. [Thu Nov 20 15:04:07 2014] (How) can I write an Ltac that just tries to go through all premises and do inversion once on them, until it works for some of them? [Thu Nov 20 15:04:12 2014] (and fail, if not) [Thu Nov 20 15:49:50 2014] schoppenhauer: solve [match goal with [ H : _ |- _ ] => inversion H] [Thu Nov 20 15:50:07 2014] ianjneu: thx. [Thu Nov 20 15:51:43 2014] schoppenhauer: you may want to check out CPDT's library of tactics, if not the book itself. [Thu Nov 20 16:32:10 2014] johnw : .. hm, would know what ? [Thu Nov 20 16:45:31 2014] ianjneu: I should probably read it, yes. btw, your codeline does not work. to me it seems like it always tries to do inversion on the first assumption. [Thu Nov 20 16:54:39 2014] schoppenhauer: try adding ; fail after inversion H [Thu Nov 20 16:55:46 2014] ianjneu: ah. works \o/ [Thu Nov 20 16:56:54 2014] schoppenhauer: do you know why? [Thu Nov 20 16:58:23 2014] ianjneu: i suppose the problem is that the match will not be recognized if there are remaining goals but no error. [Thu Nov 20 17:01:02 2014] not quite. match searches for the first hypothesis that will make the right hand side succeed. If the inversion doesn't discharge the goal, the tactic still succeeds, making the match stop searching. We want it to search for the first hypothesis for which inversion discharges the goal. The fail is only reached if the inversion doesn't solve the goal. [Thu Nov 20 17:03:14 2014] by failing after an inversion, we force the match to keep searching for a hypothesis for which inversion will solve the goal. Since the match will fail if all hypotheses cause failure, there's no need for the match to be inside "solve" [Thu Nov 20 17:03:29 2014] ++ [Thu Nov 20 17:15:14 2014] is that supposed to be an emoji? [Thu Nov 20 17:15:24 2014] not really [Thu Nov 20 17:18:45 2014] it is more like ... generally positive reaction. [Thu Nov 20 19:34:00 2014] Hey, anyone knows if I can compile a plugin on Coq without recompiling the entire thing? [Thu Nov 20 19:36:51 2014] Only if you have the same version of OCaml that compiled the Coq that you're using. (So, probably yes if you're using Linux, probably not if you're using Mac or Windows, though maybe if you're using 8.4pl5 rather than 8.4pl4 or earlier.) [Thu Nov 20 19:42:32 2014] Yeah, I have no problem with that actually. I'm compiling the entire thing every time I make a change in the plugin, that's why I'm asking. [Thu Nov 20 19:42:56 2014] Is there any intructions anywhere that I can follow? I read through the README and nothing helped me. [Thu Nov 20 19:44:14 2014] (README meaning the README in the root folder of coq's repository) [Thu Nov 20 19:53:22 2014] I assumed by "recompiling the entire thing" you meant "all of Coq's source". If you meant "recompiling the entire plugin", then, I have no idea. [Thu Nov 20 20:02:29 2014] jgross: Woops, I lost my connection. Can you help me in this matter? [Thu Nov 20 20:24:11 2014] < freenode #coq jgross I assumed by "recompiling the entire thing" you meant "all of Coq's source". If you meant "recompiling the entire plugin", then, I have no idea. [Thu Nov 20 20:24:11 2014] You might also want to look at coq_makefile, if you're not already using that. [Thu Nov 20 20:39:29 2014] Oh, yeah, I said: [Thu Nov 20 20:39:33 2014] Yeah, "all of Coq's source". [Thu Nov 20 20:39:38 2014] I'm assuming that this is not the right way to do it, obviously, but I don't have any previous experience with OCaml. [Thu Nov 20 20:45:28 2014] Have you read, e.g., http://gallium.inria.fr/blog/your-first-coq-plugin/? [Fri Nov 21 09:13:25 2014] ok question [Fri Nov 21 09:14:04 2014] what's the accepted way to talk about things like monoids [Fri Nov 21 09:14:37 2014] should i define a predicate that takes a set and an operator and says 'this is monoid' and then define a data type that holds a set, an operator, and a proof? [Fri Nov 21 09:20:10 2014] benzrf: use a monoid typeclass. It's best to try to not think with sets when in type theory. [Fri Nov 21 09:23:28 2014] ianjneu: coq has type clsases?? [Fri Nov 21 09:23:31 2014] hot damn [Fri Nov 21 09:25:32 2014] I forget the syntax, but it'll be something like Class Monoid := {carrier : Type; op : carrier -> carrier -> carrier; assoc : forall x y z, op (op x y) z = op x (op y z); unit : carrier}. I think Bas Spitters has a lot of the classes and theorems written though. [Fri Nov 21 09:25:54 2014] im sure somebody has [Fri Nov 21 09:26:01 2014] but i enjoy defining stuff from scratch myself [Fri Nov 21 09:27:56 2014] it's nice when it all works together, so there has been a lot of work in building the theory https://github.com/Eelis/math-classes/blob/master/src/interfaces/abstract_algebra.v [Fri Nov 21 09:42:05 2014] benzrf: http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf <- a nice intro to typeclasses in Coq [Fri Nov 21 09:42:13 2014] they are slightly different from those of Haskell [Fri Nov 21 09:49:06 2014] oh [Fri Nov 21 10:55:41 2014] jgross: Yeah, I checked that. but I'm not sure if I can use coq_makefile to just compile a plugin that's build in within Coq [Fri Nov 21 10:55:50 2014] and that's almost purely Ocaml code [Fri Nov 21 12:59:13 2014] is -> a primitive notation or is it Notation for sth [Fri Nov 21 13:02:29 2014] benzrf: context-sensitive. The rewrite tactic has -> and <- as directional notation. A -> B where a type is expected is notation for forall x : A, B [where x does not appear in B] [Fri Nov 21 13:05:40 2014] ah [Fri Nov 21 13:05:44 2014] forall is the primitive [Fri Nov 21 14:29:22 2014] sh1ken: Your plugin should not live in the Coq source code directory unless you're actually patching Coq itself. See https://github.com/braibant/Timing-plugin for an example of a plugin that's written almost entirely in OCaml. [Fri Nov 21 16:15:26 2014] jgross: Thanks for the link. I'm going to check it out. I'm actually modifing the extraction plugin so I don't know if it's necessary to patch Coq itself or I can follow the example that you're giving me. [Fri Nov 21 16:18:42 2014] sh1ken: i did some mucking around with the extraction plugin myself a few weeks ago. what are you making it do? [Fri Nov 21 16:22:24 2014] ystael: I'm doing some non-useful stuff actually, haha. I'm printing all the inductive types as a comments into the final extraction through OCaml. [Fri Nov 21 16:31:23 2014] ystael: What did you do with it? [Fri Nov 21 17:28:32 2014] http://gallium.inria.fr/~xleroy/publi/verasco-popl2015.pdf neat. [Fri Nov 21 17:38:54 2014] MoreCoq.v (SF), given (n : nat), (H : beq_nat 0 n = true), prove n = 0 [Fri Nov 21 17:39:06 2014] hints? :( [Fri Nov 21 17:39:11 2014] it looks so easy but i cant get it to work... [Fri Nov 21 17:40:14 2014] adelbertc: have you tried induction on n [Fri Nov 21 17:40:59 2014] benzrf: well dont i feel silly. [Fri Nov 21 17:41:10 2014] i didnt even think to use induction, i kept permuting "inversion" and "apply" [Fri Nov 21 17:41:13 2014] hoping to do [Fri Nov 21 17:41:20 2014] n = 0, then beq_nat 0 n = beq_nat 0 0 [Sat Nov 22 01:10:55 2014] adelbertc: you don't need induction. destruct + inversion should be enough. [Sat Nov 22 02:05:11 2014] So, I undestand the basics of function growth but I do not know how to show decreasing function growth. The question is: Prove the function F: R to R+ is a decreasing function then " F" is O(1). Show by counterexample that the converse is not necessarily true. [Sat Nov 22 02:05:17 2014] It's a confusing question, and I'm not sure where to start? [Sat Nov 22 10:10:32 2014] Hi [Sat Nov 22 10:12:59 2014] I'm trying to work on a mathematical set (What I want to do is purely mathematic for now) such as http://latex.codecogs.com/gif.latex?%5C%7Bx%20%3D%202n%20%5Cmid%20%5Cin%20%5Cmathbb%7BN%7D%20%5C%7D [Sat Nov 22 10:14:27 2014] In order to prove mathematical properties of this set, I don't really know whether I should define a new type in coq (like the sig inductive type : {x:nat | even x}, where even is predicate on naturals) [Sat Nov 22 10:15:14 2014] But then I guess I have to define some injections from this type to natural integers, or it can be done automatically ? [Sat Nov 22 10:16:34 2014] In fact, I would like to define an Ensemble of such a type and to be able to use natural relations on it (lt, le ...) [Sat Nov 22 10:33:49 2014] You mean {2n | n in N} ? [Sat Nov 22 10:35:13 2014] yes, you do [Sat Nov 22 10:35:44 2014] So, sure, you can use a sigma type, and there's already a projection to the first component [Sat Nov 22 10:37:13 2014] Choups314: It's called proj1_sig [Sat Nov 22 10:47:19 2014] Cale : What do you mean by projection ? [Sat Nov 22 10:48:04 2014] Choups314: An element of a sigma type is a pair consisting of an element of the base type together with a proof that the element satisfies the given property [Sat Nov 22 10:48:21 2014] Choups314: and there are projections to each of the components of the pair [Sat Nov 22 10:49:55 2014] (though the second projection has a type which uses the first) [Sat Nov 22 10:53:12 2014] https://coq.inria.fr/distrib/8.3pl4/stdlib/Coq.Init.Specif.html#proj1_sig [Sat Nov 22 11:00:58 2014] Cale: (Sorry for the delay) Ok :), so it is possible to build an Ensemble of such a type (a sigma-type) ? [Sat Nov 22 11:02:10 2014] I'm not exactly sure what you mean by ensemble, but yes, sigma types exist. You can use sig even [Sat Nov 22 11:02:23 2014] Choups314: sorry i confused you the other day [Sat Nov 22 11:02:24 2014] it's Set [Sat Nov 22 11:02:37 2014] Cale: i think french for set is `ensembl' or sth [Sat Nov 22 11:02:44 2014] Yes it is [Sat Nov 22 11:02:50 2014] ensemble* [Sat Nov 22 11:04:07 2014] for some reason rewrite is not working here [Sat Nov 22 11:04:08 2014] https://privatepaste.com/f4056dde10 [Sat Nov 22 11:04:12 2014] am i missing something? [Sat Nov 22 11:05:23 2014] roosbeef: My guess is that there are implicit parameters which don't match [Sat Nov 22 11:05:37 2014] how can i check that? [Sat Nov 22 11:06:04 2014] View -> Display implicit arguments [Sat Nov 22 11:06:32 2014] lets see [Sat Nov 22 11:07:11 2014] nope they match [Sat Nov 22 11:07:27 2014] https://privatepaste.com/c547de7fa6 [Sat Nov 22 11:07:46 2014] (above the error and below H8) [Sat Nov 22 11:07:50 2014] hm [Sat Nov 22 11:19:10 2014] ok managed to make it work with some cutting and using transitivity [Sat Nov 22 11:19:41 2014] still surprised as to why Coq was objecting [Sat Nov 22 11:32:34 2014] Cale: By Ensemble I mean the inductive type defined here : https://coq.inria.fr/library/Coq.Sets.Ensembles.html [Sat Nov 22 11:33:38 2014] Cale: Another thing : Is it possible to define an implicit coercion (Or something similar) to be able to use the relations on nat on my sigma-type (Which is a subset of nat) ? [Sat Nov 22 12:49:05 2014] Is it possible to add "custom" type conversion rules ? [Sat Nov 22 12:58:52 2014] In fact I don't really understand how to implement something like this : http://www.pps.univ-paris-diderot.fr/~sozeau/research/publications/Subset_Coercions_in_Coq.pdf [Sat Nov 22 15:32:50 2014] Hello :) [Sat Nov 22 15:33:07 2014] Can someone explain me how does the subset type coercion works ? [Sun Nov 23 05:21:02 2014] can I limit searchabout to a certain set of files or modules? I only want to search for things that I defined. [Sun Nov 23 19:49:55 2014] hey yo [Sun Nov 23 19:49:59 2014] i have [Sun Nov 23 19:50:03 2014] IHn : forall m : ord, ordle n m \/ ordle m n [Sun Nov 23 19:50:08 2014] but, [Sun Nov 23 19:50:13 2014] ordle_total < destruct IHn. [Sun Nov 23 19:50:16 2014] Error: Unable to find an instance for the variable m. [Sun Nov 23 21:27:12 2014] benzrf: there's apply ... with (m := ...). perhaps [with] works for [destruct], too [Sun Nov 23 21:39:20 2014] In this case, it would be more something like [destruct (IHn your_m).], you just have to apply IHn to something. [Sun Nov 23 21:39:51 2014] ah [Sun Nov 23 21:39:56 2014] Cypi: thanks! [Mon Nov 24 09:13:09 2014] when i find something using Locate inside proof general, can i easily jump to the definition? [Mon Nov 24 09:27:31 2014] chris2: Print [name]. [Mon Nov 24 09:27:59 2014] in the source code i mean [Mon Nov 24 09:47:23 2014] Here is a bit of a challenge: Let n > 1 be an integer. In the space, consider the set: S = (x, y, z) | x, y, z ∈ {0, 1, . . . , n}, x + y + z > 0 [Mon Nov 24 09:47:31 2014] Find the smallest number of planes that jointly contain all (n + 1)3 − 1 points of S but none of them passes through the origin. [Mon Nov 24 09:47:43 2014] It is from A7 in here: https://www.imo-official.org/problems/IMO2007SL.pdf [Mon Nov 24 09:47:51 2014] Is it possible to prove with Coq? [Mon Nov 24 11:47:34 2014] hey guys, so if I have a goal that looks like (a = a), then I can use reflexivity to complete the proof. But what about if I have a goal that looks like (1 > 0)? This is obviously definitionally true, but I'm not sure which tactic I can use. [Mon Nov 24 12:01:44 2014] thinkpad20 : just "auto" is sufficient [Mon Nov 24 12:04:57 2014] awesome, thanks! quite a beginner still :) [Mon Nov 24 12:06:24 2014] If you want to see what exactly auto is doing, you can use "info_auto" instead, which will display the tactics it used to solve your goal. [Mon Nov 24 12:07:11 2014] ah, yeah that's very helpful [Mon Nov 24 12:27:51 2014] how do I do a rewrite in one specific place? For example, I have as a goal `f a b = c b`, and I have a proof that `b = x`, and I want to write my goal as `f a b = c x`, not `f a x = c x`. [Mon Nov 24 12:29:48 2014] you can [rewrite ... at 1] iirc [Mon Nov 24 12:29:58 2014] thinkpad20: there's replace (expr1) with (expr2). [Mon Nov 24 12:31:00 2014] ah, `at` did the trick :) thanks [Mon Nov 24 12:42:57 2014] (it's a shame that coq doesn't have a ctx_rewrite or whatever) [Mon Nov 24 12:43:56 2014] (like in [ctx_rewrite p_b_eq_x H on (_ = _ ?)] or something) [Mon Nov 24 12:45:33 2014] you can do it with matches (even though it's a bit clumsy imho) but it would be worth having in a "vanilla" tactic i think [Tue Nov 25 10:56:49 2014] Hey, is it possible to define something in several [Tue Nov 25 10:57:09 2014] in different manners*, and to choose the best during a proof ? [Tue Nov 25 11:04:50 2014] Choups314: yes. You just have to have proven equalities to rewrite with. [Tue Nov 25 11:05:13 2014] I've done this myself, to get different computational behavior and induction schemes. [Tue Nov 25 11:05:54 2014] That said, I only mean wrt functions, not types. To do the same with types you'd need something like univalence. [Tue Nov 25 11:18:19 2014] ianjneu : My definitions are actually predicates. If I do so, I have to define the several predicates (that are actually verifying the same property) in several definitions (so it means several names right ?) and then prove the equality between those definitions ? [Tue Nov 25 11:30:42 2014] Choups314: no, you can use any equivalence predicate you want in definitions, and in proofs you can move between them by using equality proofs of your various predicates. [Tue Nov 25 11:31:20 2014] is exists defined like [Tue Nov 25 11:31:52 2014] Inductive ex : forall A : Type, (A -> Prop) -> Prop := [Tue Nov 25 11:33:00 2014] Inductive ex (A : Type) (P : A -> Prop) : Prop := ex_intro : forall x : A, P x -> ex _ P. [Tue Nov 25 11:33:11 2014] | witness : forall (A : Type) (P : (A -> Prop)) (a : A), P a -> ex A P. [Tue Nov 25 11:33:16 2014] oh [Tue Nov 25 11:33:17 2014] A and P are indices and not parameters. [Tue Nov 25 11:33:30 2014] wait [Tue Nov 25 11:33:32 2014] ? [Tue Nov 25 11:33:35 2014] whats an index [Tue Nov 25 11:33:53 2014] something that can't change across all variants of an inductive type. [Tue Nov 25 11:34:03 2014] hold on [Tue Nov 25 11:34:20 2014] im confused [Tue Nov 25 11:34:21 2014] parameters can change, like the size of a vector. [Tue Nov 25 11:34:56 2014] They're operationally equivalent, but Coq produces different induction schemes for them. [Tue Nov 25 11:35:07 2014] (i've always seen the terms used the other way around :O) [Tue Nov 25 11:36:08 2014] Saizan: well, that may be true. [Tue Nov 25 11:36:56 2014] Ya, that's probably the right nomenclature. [Tue Nov 25 11:37:46 2014] Adam uses parameter for left of the :, so ya you're right. [Tue Nov 25 11:44:38 2014] and forall is primitive function type not defined, right [Tue Nov 25 13:23:51 2014] hello. does anyone happen to know a good (as in: instructive) book/manuscript on the pi-calculus? [Tue Nov 25 13:25:41 2014] Have you looked at the Wikipedia article? [Tue Nov 25 13:25:50 2014] no [Tue Nov 25 13:26:08 2014] i mean, yes, but ... [Tue Nov 25 13:26:13 2014] that's just a wikipedia article [Tue Nov 25 13:27:07 2014] Sure, sure. I just wanted to bring it up, because it helped me a lot when I was reading a π-calculus paper. It sounds like your needs are greater than mine, though. [Tue Nov 25 13:27:57 2014] hm. ok. but there is the work from milner linked, which is probably enough. [Tue Nov 25 14:00:03 2014] https://api.flickr.com/services/feeds/photos_public.gne?id=36998705@N00&lang=en-us&format=lolcode [Tue Nov 25 14:03:56 2014] That’s fantastic [Tue Nov 25 14:04:36 2014] wah wrong window [Tue Nov 25 14:04:39 2014] -.- [Tue Nov 25 14:04:41 2014] sorry [Tue Nov 25 14:05:04 2014] but yes, it is funny [Tue Nov 25 15:01:46 2014] anyone using coqtags? [Tue Nov 25 19:02:31 2014] not forall doesnt imply exists not, right [Tue Nov 25 19:12:26 2014] Indeed [Tue Nov 25 19:13:18 2014] tfw cant classical [Wed Nov 26 08:15:58 2014] Is there anything coq can do and ocaml can't beside theorem proving? [Wed Nov 26 09:11:05 2014] Necrosporus: in coq, types are first-class citizens [Wed Nov 26 09:11:50 2014] Necrosporus: in ocaml you can search for a proof of the inconsistency of peano arithmetic *duck* [Wed Nov 26 09:14:29 2014] really? [Wed Nov 26 09:14:58 2014] nkar, I know that dependent types in Coq but not present in OCaml [Wed Nov 26 09:15:26 2014] My question is about what exactly I can do with them _beside_ proving my programs are correct? [Wed Nov 26 09:16:07 2014] Do they make anything easier to do? [Wed Nov 26 09:16:39 2014] beside writing complex programs which must be guaranteed to be correct [Wed Nov 26 09:37:53 2014] Necrosporus: no. [Wed Nov 26 09:38:44 2014] (and searching for an inconsistency in PA results in an algorithm of which it is undecidable whether it terminates.) [Wed Nov 26 09:38:58 2014] (just ftr) [Wed Nov 26 09:39:29 2014] (while in coq you must prove that your algorithm terminates, or is at least productive in some way) [Wed Nov 26 09:41:08 2014] schoppenhauer, but in OCaml you could run it on a fast computer and wait for a hour or two? [Wed Nov 26 09:41:34 2014] Necrosporus: you would likely wait forever ... [Wed Nov 26 09:41:44 2014] Necrosporus: or at least until your ram is full. [Wed Nov 26 09:42:19 2014] Necrosporus: but that is the point: you *can* wait forever ... in theory. [Wed Nov 26 09:43:41 2014] Did anyone try to run that program on a sufficiently powerful computer for sufficiently long time? [Wed Nov 26 09:44:28 2014] If yes, then there is no point to run that program on my computer, because it will not produce any useful results before I decide to stop it [Wed Nov 26 09:44:48 2014] also in coq, you have the 'fixpoint', which ensures that successive recursive calls are made on decreasing arguments [Wed Nov 26 09:49:42 2014] what't the rationale for exist2/ex2_intro? [Wed Nov 26 09:54:09 2014] Necrosporus: do you know what a termination of that program would imply? [Wed Nov 26 09:57:31 2014] schoppenhauer, I guess, I understand it wrongly, I though you were talking about proving Goodstein's theorem [Wed Nov 26 09:57:55 2014] no. [Wed Nov 26 09:58:34 2014] But you mean inconsistency, not incompleteness [Wed Nov 26 09:58:52 2014] If it's inconsistent then... probably all of our math is wrong [Wed Nov 26 09:59:59 2014] yes. [Wed Nov 26 10:01:51 2014] just if you dont believe in other foundations [Wed Nov 26 10:16:38 2014] schoppenhauer, have anyone tried to check it anyway? [Wed Nov 26 10:17:01 2014] Run something on a modern supercomputer for few hours for example [Wed Nov 26 10:20:50 2014] I don't think so. [Wed Nov 26 10:27:37 2014] and actually, I don't consider that too interesting. [Wed Nov 26 10:28:04 2014] because you believe in consistency of peano arithmetic? [Wed Nov 26 10:28:18 2014] it's interesting that such an algo exists. [Wed Nov 26 10:28:38 2014] no, but I believe that we would not get any valuable information from it. [Wed Nov 26 10:28:38 2014] Can I see its code if it's not too long? [Wed Nov 26 15:05:50 2014] Hi, so my coqide doesn't seem to be able to find the standard library. Did I miss install something? [Wed Nov 26 19:44:35 2014] this is kind of off topic, but most people here may know a thing or two about induction so hope you don't mind me asking [Wed Nov 26 19:45:06 2014] do you know of any work defining algebras of inductive sets? [Wed Nov 26 19:45:52 2014] by inductive set A = Ind(x,R), here I mean a set generated from an initial set of values x, and a relation R subset of AxA [Wed Nov 26 19:46:01 2014] Like, universe coding? [Wed Nov 26 19:46:14 2014] not sure what that is ezyang [Wed Nov 26 19:46:34 2014] i.e. you define the universe of data types using another data type [Wed Nov 26 19:46:47 2014] with an interpretation function that takes the 'Code' to a 'Type' [Wed Nov 26 19:47:19 2014] not really... I don't think so [Wed Nov 26 19:47:43 2014] all I mean is describing sets from an initial set of values and and a relation [Wed Nov 26 19:48:06 2014] the idea being that if a in A and (a,a') in R then a' in A [Wed Nov 26 19:48:33 2014] so it's like representing sets by their initial 'seed' and a 'iterator' [Wed Nov 26 19:49:00 2014] point being that then you could define functions on sets in terms of functions on these iterator relations [Wed Nov 26 19:49:01 2014] e.g. [Wed Nov 26 19:49:21 2014] intersection of two inductive sets is just the intersection of their initial seeds and relations [Wed Nov 26 19:50:02 2014] for union this wouldn't quite work in general, but it would when adding some restrictions to the relations [Wed Nov 26 19:51:06 2014] then projection on inductive sets of pairs is interesting too, as there would need to be some sort of colapsing in the projection of the relation [Wed Nov 26 19:51:08 2014] etc [Wed Nov 26 19:51:48 2014] this is quite handy because using this, one can substitute inductive proofs by these operations on relations [Wed Nov 26 19:51:59 2014] e.g. you want to prove two inductive sets are the same [Wed Nov 26 19:52:29 2014] instead of using induction you could prove one relation is contained in the other [Wed Nov 26 19:52:43 2014] this seems interesting and would be handy for me [Wed Nov 26 19:52:58 2014] but as I'm defining all this boilerplate, I feel like I must be reinventing the wheel [Thu Nov 27 06:41:14 2014] pokop [Thu Nov 27 07:52:45 2014] hello. is there any predefined error-monad in coq? [Thu Nov 27 09:35:46 2014] hm. my goal contains a match (x :: y) as | [] => ... | a :: b => ... end. obviously, the [] case cannot occur. how can I remove it? [Thu Nov 27 09:38:24 2014] simpl maybe? [Thu Nov 27 10:18:01 2014] indeed. [Thu Nov 27 10:18:03 2014] thx. [Thu Nov 27 10:18:27 2014] np [Thu Nov 27 10:20:39 2014] match..as? [Thu Nov 27 22:45:32 2014] In Coq how would I prove that the relation: x R y = (x^2 - y^2) (xy - 1) = 0 [Thu Nov 27 22:45:41 2014] is transitive? I know the definition, but how do I prove that xRz is really (x^2 - z^2)(xz - 1) = 0? [Thu Nov 27 22:47:16 2014] marvimias: i'd assume induction [Thu Nov 27 22:47:33 2014] that's the usual route =b [Thu Nov 27 22:48:41 2014] I think I know how to prove it manually, I was just curious with Coq. Heard about it but never used it before [Thu Nov 27 22:49:21 2014] benzrf, This is what I got: http://pastebin.com/QRghHYd1 [Thu Nov 27 22:50:06 2014] marvimias: 1 sec [Thu Nov 27 22:51:28 2014] h m m [Thu Nov 27 22:52:02 2014] ok 1 sec [Thu Nov 27 22:52:16 2014] im gonna make a script [Thu Nov 27 22:53:28 2014] ok nvm [Thu Nov 27 22:53:34 2014] marvimias: you've never used coq? [Thu Nov 27 23:00:34 2014] benzrf, Never written a script in Coq, I have used it though [Thu Nov 27 23:00:40 2014] But not much [Thu Nov 27 23:00:49 2014] I have the Coq IDE installed [Thu Nov 27 23:03:45 2014] I have heard Coq does not work well on reals. And it can get a bit messy [Thu Nov 27 23:09:00 2014] er [Thu Nov 27 23:09:06 2014] by script i meant a terminal typescript ;b [Thu Nov 27 23:10:45 2014] benzrf, Oh yes [Thu Nov 27 23:11:44 2014] That would be good [Thu Nov 27 23:28:10 2014] benzrf, You still there? [Thu Nov 27 23:43:32 2014] y [Thu Nov 27 23:49:00 2014] benzrf, Would it be relatively easy in Coq to prove? [Thu Nov 27 23:54:29 2014] mm probably [Thu Nov 27 23:54:40 2014] straightforward induction/simplification dance i'd wager [Fri Nov 28 00:36:57 2014] hi folks, [Fri Nov 28 00:37:38 2014] i wanna know how do you usually prove some artihmetic theorem. [Fri Nov 28 00:38:42 2014] for example for some theorems based on multiplication, doing induction on the variables makes the case more complex. [Fri Nov 28 00:40:12 2014] for a specific example, like this: http://lpaste.net/115249 [Fri Nov 28 00:42:19 2014] shouya: For this one, you want the 'inversion' tactic, not induction. [Fri Nov 28 00:42:57 2014] oh, got that! [Fri Nov 28 00:43:09 2014] I’m not sure if I can offer more general advice, though. My pattern is usually ‘try one or two tactics I know, see if that makes any progress, repeat’. [Fri Nov 28 00:43:30 2014] I nearly forgot this tactic, i've been a long time not using coq. [Fri Nov 28 00:44:02 2014] alkabetz: sure :) thanks [Fri Nov 28 00:44:23 2014] You’re welcome. [Fri Nov 28 00:44:46 2014] If you do end up using inversion a lot, watch out for how it interacts with automation – inversion often generates so many new assumptions that it really can slow down proof search. [Fri Nov 28 00:45:37 2014] In Coq how would I prove that the relation: x R y = (x^2 - y^2) (xy - 1) = 0 [Fri Nov 28 00:45:37 2014] is transitive? I know the definition, but how do I prove that xRz is really (x^2 - z^2)(xz - 1) = 0? [Fri Nov 28 00:45:42 2014] alkabetz, Any idea? [Fri Nov 28 00:46:03 2014] I’ve often used 'inversion H; clear H; subst', which cleans up your proof context quite a bit (but can take you in the wrong direction if you’re not careful). [Fri Nov 28 00:46:21 2014] (That was for shouya, not for marvimias) [Fri Nov 28 00:47:03 2014] alkabetz: yup, which is helpful to make the hypothesis clearer. [Fri Nov 28 00:47:46 2014] marvimias: What type do you want for x and y? [Fri Nov 28 00:51:12 2014] alkabetz, Well this is how I tried proving it manually: http://pastebin.com/CPhtnxji [Fri Nov 28 00:56:37 2014] marvimias: So wait, you want to prove that R is *not* transitive? [Fri Nov 28 00:57:02 2014] alkabetz, Which would be easier in Coq? [Fri Nov 28 00:57:39 2014] alkabetz, I am more just curious about it, don't really need it to be done in Coq, was just curious is all [Fri Nov 28 00:58:39 2014] You can’t prove a false proposition in Coq, so you’d want to prove that R is intransitive. You’d do this by providing Coq a counterexample, just like you’ve done in the English proof. [Fri Nov 28 00:59:31 2014] alkabetz, I see, and how would that be done in Coq syntax? [Fri Nov 28 01:00:12 2014] tbh i think i find it easier to reason on the side of the CHC where forall a : A, P a is rendered as (a : A) -> P a [Fri Nov 28 01:19:22 2014] marvimias: I’m not 100% sure. I’d have to actually prove it to find out, and it’s too late for me to be proving things with real numbers right now ;) [Fri Nov 28 04:07:06 2014] Hi [Fri Nov 28 04:25:35 2014] hi [Fri Nov 28 06:21:44 2014] salut les petits coquard [Fri Nov 28 10:49:06 2014] how do + and * differ from \/ and /\ [Fri Nov 28 10:53:46 2014] Type vs Prop [Fri Nov 28 10:56:27 2014] ianjneu: but Prop is a Type [Fri Nov 28 10:56:35 2014] ianjneu: doesnt + and * work on Prop [Fri Nov 28 10:56:37 2014] what is this nonsense [Fri Nov 28 11:00:57 2014] Prop is impredicative, so specifying Prop is different from just being in the lowest Type universe. [Fri Nov 28 11:11:24 2014] benzrf: with \/ and /\ you stay within Prop, otherwise you go into Type [Fri Nov 28 11:11:39 2014] oh [Fri Nov 28 11:13:07 2014] one of these days I need to understand type universes. [Fri Nov 28 12:54:03 2014] salut les petits coquards [Fri Nov 28 12:55:07 2014] I only speak English and Japanese. [Fri Nov 28 12:55:26 2014] but salut anyway [Fri Nov 28 13:00:38 2014] salut saschmut [Fri Nov 28 15:31:05 2014] [Fri Nov 28 19:50:30 2014] The goo.gl link in the topic points to http://www.lemoniteur.fr/157-realisations/article/actualite/706389-un-pont-de-rouen-transforme-en-mikado, is that intended? [Sat Nov 29 03:49:17 2014] hi everyone, [Sat Nov 29 03:49:37 2014] anyone has idea to prove the goal: forall m n n' a, m <> 0 -> a = m * n -> a = m * n' -> n = n'. [Sat Nov 29 03:54:40 2014] i thought it should be done with induction, [Sat Nov 29 03:59:32 2014] here's my trial: http://lpaste.net/115328 [Sat Nov 29 04:44:33 2014] i'd do induction on m [Sat Nov 29 05:28:48 2014] Saizan: could you please give more hints about how to do that? [Sat Nov 29 05:29:33 2014] Saizan: i tried by failed on proving it in this way. [Sat Nov 29 05:29:39 2014] s/by/but [Sat Nov 29 05:30:21 2014] shouya: mh, i haven't done that proof and i'm not actually a Coq user, so i wouldn't actually know, sorry [Sat Nov 29 05:30:43 2014] i guess it depends on whether * is defined by recursion on the left or on the right [Sat Nov 29 05:31:08 2014] Saizan: i think that would be both okay, [Sat Nov 29 05:31:36 2014] in library there are these lemmas: [Sat Nov 29 05:31:44 2014] Lemma mult_succ_l : forall n m:nat, S n * m = n * m + m. [Sat Nov 29 05:31:44 2014] Lemma mult_succ_r : forall n m:nat, n * S m = n * m + n. [Sat Nov 29 05:36:28 2014] mh, maybe it's just induction on n and n' at the same time and proving the diagonal cases are impossible [Sat Nov 29 05:37:45 2014] Saizan: i'll try that again ;-p [Sat Nov 29 05:38:49 2014] SnmnmmnmnSmnmn [Sat Nov 29 10:40:56 2014] what exactly does Function do [Sat Nov 29 10:41:03 2014] v. Definiiitiiion [Sat Nov 29 11:16:48 2014] > destruct (o a b c f g). [Sat Nov 29 11:16:48 2014] > ^^^^^^^^^^^^^^^^^^^^^^ [Sat Nov 29 11:16:48 2014] Error: f is used in hypothesis n. [Sat Nov 29 11:16:51 2014] ?? [Sat Nov 29 11:16:52 2014] > destruct (o a b c f g). [Sat Nov 29 11:16:52 2014] > ^^^^^^^^^^^^^^^^^^^^^^ [Sat Nov 29 11:16:52 2014] Error: f is used in hypothesis n. [Sat Nov 29 11:17:43 2014] wot the heck is this [Sat Nov 29 11:38:30 2014] h e l p [Sat Nov 29 11:38:34 2014] Cale: can you provide asst? [Sat Nov 29 11:44:03 2014] wat [Sat Nov 29 11:44:26 2014] benzrf: what's up? [Sat Nov 29 11:45:03 2014] I might be slightly distracted, I'm having tons of "fun" fixing broken javascript applets for my panel because some update broke about half of them. [Sat Nov 29 11:45:30 2014] ok thank u [Sat Nov 29 11:45:35 2014] > destruct (o a b c f g). [Sat Nov 29 11:45:35 2014] > ^^^^^^^^^^^^^^^^^^^^^^ [Sat Nov 29 11:45:35 2014] Error: f is used in hypothesis n. [Sat Nov 29 11:45:37 2014] wat [Sat Nov 29 11:45:45 2014] What's the context? [Sat Nov 29 11:46:06 2014] http://benzrf.benzrf.com/imgs/913cef.png [Sat Nov 29 11:46:32 2014] weird [Sat Nov 29 11:56:34 2014] benzrf: I might be able to help if you pasted your script somewhere [Sat Nov 29 12:01:54 2014] script? [Sat Nov 29 12:45:47 2014] Cale: still there? [Sat Nov 29 12:46:00 2014] https://gist.github.com/f712abf520f52fc5566e [Sat Nov 29 13:51:50 2014] benzrf|offline: This doesn't appear to be provable. [Sat Nov 29 13:51:50 2014] I can sort of see where the n is coming from, it's from ncm. [Sat Nov 29 13:51:51 2014] benzrf|offline: If you destruct f and g and unfold ncatcomp, you can reach the goal o n m0 m (ncm m0 m) (ncm n m0) = ncm n m [Sat Nov 29 13:56:35 2014] oh, no, it is [Sat Nov 29 13:56:35 2014] You just need an additional lemma about uniqueness of terms ncatmorph n m [Sat Nov 29 13:56:35 2014] Lemma uniqueness : forall n m, forall (x y : ncatmorph n m), x = y. [Sat Nov 29 13:57:36 2014] That one is easy (destruct x and y, use reflexivity) [Sat Nov 29 13:57:36 2014] You can then apply uniqueness to your goal of o a b c f g = ncatcomp a b c f g [Sat Nov 29 17:29:06 2014] Cale: yes, that's what i was trying to do [Sat Nov 29 17:29:11 2014] Cale: just w/o a lemma, rather inline [Sat Nov 29 17:29:31 2014] Cale: hence why i was trying to destruct o a b c f g [Sat Nov 29 17:29:45 2014] >destruct x and y [Sat Nov 29 17:33:58 2014] benzrf: hi, have you proved 'app_length_twice' from sf? [Sat Nov 29 17:35:19 2014] nkar: probably [Sat Nov 29 17:35:22 2014] i dont remember [Sat Nov 29 17:36:02 2014] benzrf: I got stuck. could you look at my proof and provide a hint without revealing much? [Sat Nov 29 17:36:20 2014] OK [Sat Nov 29 17:36:30 2014] thanks, will paste shortly [Sat Nov 29 17:39:47 2014] benzrf: http://dpaste.com/1YBNMMZ [Sat Nov 29 17:39:59 2014] this is from the 'MoreCoq' chapter [Sat Nov 29 17:41:24 2014] hm [Sat Nov 29 17:41:40 2014] I guess I could prove the goal separately [Sat Nov 29 17:41:50 2014] but it's not allowed [Sat Nov 29 17:42:11 2014] because that's the def'n of app_length, iirc [Sat Nov 29 17:43:43 2014] * stares a lil [Sat Nov 29 17:44:24 2014] (I'm going to take a nap, but I'll read the backlog.) [Sat Nov 29 17:53:50 2014] nkar: ok i probably know less coq than u [Sun Nov 30 04:36:58 2014] benzrf|offline: johnw proved it by introducing a new theorem (the opposite of app_length_cons), so I did the same. I'd thought I could use app_length_cons as is because I forgot that 'if foo then bar' doesn't always holds for 'if bar then foo'. [Sun Nov 30 05:57:35 2014] hi. I'm learning the basics of HoTT and have problems proving the formalization of the following fact: If f: E -> B is a fibration and p: s ~~> t is a path in E which projects to a null-homotopic loop based at some b : B, then p is homotopic to a path in the fiber over b. I formalized this as http://pastebin.com/h0Wvdniz but cannot solve it. any hints? [Sun Nov 30 07:24:44 2014] ah ok... in case anyone is interested: one needs to alter the hypothesis to make path induction in E applicable; instead of only looking at paths connecting points in the same fiber of f, one should associate to *any* path p: x -> y in E a path between y and the transport of x along f p: f x -> f y within the fiber of y. this is part of Thm 2.7.2 in the HoTT book and can be done by path induction [Sun Nov 30 08:31:00 2014] Hello, is it possible to use the absurd reasonning (of the classical logic) in coq ? [Sun Nov 30 08:31:56 2014] I mean, suppose the conclusion is False and proof a contradiction ? [Sun Nov 30 08:47:32 2014] Choups314: To use proofs by contradiction you need to impose the law of exluded middle as an additional axiom. Or do you mean something else? [Sun Nov 30 08:48:54 2014] Choups314: https://coq.inria.fr/library/Coq.Logic.Classical_Prop.html [Sun Nov 30 08:49:07 2014] that's not true, you can prove P x -> False [Sun Nov 30 08:49:22 2014] without needing excluded middle [Sun Nov 30 08:50:07 2014] Choups314 there is an absurd tactic but I'm not sure in what situations it's useful in [Sun Nov 30 08:50:40 2014] there's also elimtype False which makes the current goal into False [Sun Nov 30 08:58:19 2014] yukko: I meant 'proof [of P] by contradiction' as 'it suffices to show that not(P) gives rise to a contradiction', and for that you need excluded middle - but maybe that's not what Choups314 meant [Sun Nov 30 09:00:36 2014] oh okay! [Sun Nov 30 09:06:08 2014] habecker: In fact I don't understand how to turn the current goal (the conclusion) into an hypothesis (i.e. if I have a goal P, turn not(P) to an hypothesis) ? [Sun Nov 30 09:10:11 2014] Choups314: If 'lem : not (not P) -> P' is the law of excluded middle for P and your current goal is P, you can do 'apply lem; intro c.' which will give you an additional hypothesis 'c : not P' and change the goal to 'False'. This is because 'not P' is defined as 'P -> False' [Sun Nov 30 09:11:36 2014] habecker : I got it ! Thanks :) [Sun Nov 30 09:11:57 2014] :) [Sun Nov 30 09:23:40 2014] habecker: This is purely naming convention, but I thought the Law of exluded Middle stated "P or not(P)" ? (And the "not (not P)) was the Double Negation Elimination) [Sun Nov 30 09:31:24 2014] habecker: Nevermind, I understood what you meant ;) (The Law of exluded Middle is required to prove the Double Negation Elimination) [Sun Nov 30 09:44:41 2014] Choups314: Oh yes, you're right, I should have said double negation elimination - but when imposed on all propositions, it is equivalent to the law of excluded middle imposed on all propositions. [Sun Nov 30 09:45:02 2014] i like how ~~LEM can be proved [Sun Nov 30 09:45:07 2014] but not LEM [Sun Nov 30 09:45:15 2014] the ironies [Sun Nov 30 12:32:17 2014] what tactic can I use to discard the '[] = x::xt' goal? [Sun Nov 30 12:32:37 2014] I know that it can be done in the context, using inversion. [Sun Nov 30 13:52:38 2014] nkar: you can't discharge that goal, it's impossible [Sun Nov 30 13:52:49 2014] it's the same as proving False [Sun Nov 30 13:54:03 2014] johnw: I'm proving combine_split from sf. any suggestions? do I need to prove a lemma about split and combine? [Sun Nov 30 13:54:28 2014] can you show me that goal again? [Sun Nov 30 13:55:43 2014] Theorem combine_split : forall X Y (l : list (X × Y)) l1 l2, split l = (l1, l2) -> combine l1 l2 = l. I've tried various things, but all of them lead to something like [] = x::xt in the goal without anything useful in the context. [Sun Nov 30 13:56:03 2014] you are using induction on l? [Sun Nov 30 13:56:06 2014] I've tried to unfold the definitions, but I'm not sure how to work with things inside 'fix' [Sun Nov 30 13:56:30 2014] tried various things, including induction on l. [Sun Nov 30 13:56:57 2014] so, the answer does involve induction on l [Sun Nov 30 13:57:12 2014] what you may be failing to do is to destruct on the right thing after that [Sun Nov 30 13:57:32 2014] when l is broken into x and xs, then you need to know the result of "split xs" [Sun Nov 30 13:58:34 2014] I think I've tried that, too. I'm disassembling a laptop at the moment, so I'll ask more questions a bit later. [Sun Nov 30 13:58:39 2014] k [Mon Dec 1 11:33:58 2014] How to simplify only "if" construct with "simpl" or analogue? [Mon Dec 1 11:40:47 2014] Oh, "cbv iota" does that. [Mon Dec 1 11:48:52 2014] Hello, how do I rewrite an hypothesis with an equivalent ? For example, if I have an hypothesis H:a<>b, how do I rewrite it to a Choups314: but that's not equivalent. If a = 1 and b = 0 you don't get that [Mon Dec 1 11:50:18 2014] Oups :| you are right [Mon Dec 1 11:50:20 2014] sorry [Mon Dec 1 11:50:38 2014] But, just [Mon Dec 1 11:52:26 2014] rewrite Heq in Htorewrite. [Mon Dec 1 11:52:38 2014] I mean, it is an hypothesis, so I can create another hypotheses derived from it no ? If the hypothesis states that a<>b, I can choose as aa no ? [Mon Dec 1 11:54:56 2014] you can't choose that [Mon Dec 1 11:56:24 2014] you can derive [aa] as long as you have e.g. trichotomy [Mon Dec 1 11:56:28 2014] elarnon: In fact, I'm trying to prove an equality (my conclusion). For this, I use an absurd reasoning (apply NNPP ; intro.), but then my hypothesis is the difference [Mon Dec 1 11:57:17 2014] yes but you have to prove it for both cases (aa) [Mon Dec 1 11:57:17 2014] Yes, I have trichotomy (it deals with reals) [Mon Dec 1 11:58:06 2014] then you can split on your trichotomy hypothesis [Mon Dec 1 11:58:07 2014] It is not enough to show a contradiction with one case ? [Mon Dec 1 11:58:21 2014] the case a=b will be easy as you have a<>b, and the cases aa will remain [Mon Dec 1 11:58:31 2014] well no [Mon Dec 1 11:58:58 2014] if you prove [not (a Yes you are right ... [Mon Dec 1 12:00:50 2014] But is it possible to *at least* add an extra condition on the hypothesis, like a<>b such as a yes [Mon Dec 1 12:01:20 2014] [split name_of_trichotomy_lemma] [Mon Dec 1 12:02:28 2014] hm wait, does split work for hypotheses [Mon Dec 1 12:02:47 2014] I don't know [Mon Dec 1 12:02:52 2014] * have not used coq in several months [Mon Dec 1 12:02:57 2014] ^^ [Mon Dec 1 12:03:54 2014] you want [destruct name_of_trichotomy_lemma] [Mon Dec 1 12:03:56 2014] sorry [Mon Dec 1 12:04:20 2014] but you'll still have to prove your goal for both ab [Mon Dec 1 12:04:55 2014] but you will have these as hypotheses [Mon Dec 1 12:05:49 2014] hum, I will look for a repeat tactic ;), the variables a and b aren't important in the proof (they can be interchanged) [Mon Dec 1 12:06:13 2014] if you are looking for automation, then [repeat] and [match goal with ...] should be of help [Mon Dec 1 12:06:41 2014] (but maybe some built-in tactic such as [intuition] is enough to solve your goals once the split has been performed?) [Mon Dec 1 12:07:21 2014] I don't think so, it's a proof of unicity [Mon Dec 1 12:07:34 2014] This is just the begining of the proof ;) [Mon Dec 1 12:08:01 2014] And this is more like training, so I want to practice :p [Mon Dec 1 12:20:12 2014] hi elarnon! [Mon Dec 1 12:34:03 2014] destruct doesn't work with 3 disjunctions ? (with P1 \/ P2 \/ P3 it only generates 2 subgoals ..) [Mon Dec 1 12:34:43 2014] Choups314: one of the subgoals will still have a disjunction in it as a hypothesis, so you have to destruct again. you can use [intuition] to get all the subgoals at once. [Mon Dec 1 12:34:56 2014] jrw : Ok tanks ! [Mon Dec 1 12:35:01 2014] thanks* [Mon Dec 1 16:42:02 2014] How do I unfold in an hypothesis ? [Mon Dec 1 16:42:15 2014] [unfold foo in H] should do it. [Mon Dec 1 16:43:09 2014] Ok thanks ! [Mon Dec 1 17:01:22 2014] You’re welcome. [Mon Dec 1 20:12:55 2014] What is the notation like {m} in a parameter list? [Mon Dec 1 20:16:32 2014] eraserhd: implicit [Mon Dec 1 20:18:21 2014] Oh, interesting. [Mon Dec 1 20:19:13 2014] In Fin.t, what prevents passing a too-large value? [Mon Dec 1 20:23:43 2014] eraserhd: a value morally equivalent to the number n can only have type Fin m where m < n [Mon Dec 1 20:24:59 2014] or dually, a given value of type Fin can only be indexed at a number greater than the one it represents [Mon Dec 1 20:25:22 2014] F1 can only be indexed at Fin 1, Fin 2, Fin 3, ..., but never at Fin 0 [Mon Dec 1 20:26:02 2014] therefore, (FS F1) can only have type Fin 2, Fin 3, ..., but not Fin 0 or Fin 1 [Mon Dec 1 20:26:10 2014] Ptival: Hrmm. I'm not sure how to parse that out of the Inductive statement, is the problem. [Mon Dec 1 20:26:23 2014] so first look at the type of F1 [Mon Dec 1 20:26:34 2014] OH! [Mon Dec 1 20:26:35 2014] F1 : forall {n}, Fin.t (S n) [Mon Dec 1 20:26:51 2014] so F1 {0} : Fin.t 1 [Mon Dec 1 20:26:59 2014] F1 {1} : Fin.t 2 [Mon Dec 1 20:27:05 2014] F1 {2} : Fin.t 3 [Mon Dec 1 20:27:32 2014] now is there a number n such that F1 {n} : Fin 0 ? [Mon Dec 1 20:27:40 2014] now is there a number n such that F1 {n} : Fin.t 0 ? [Mon Dec 1 20:27:44 2014] Got it. [Mon Dec 1 20:27:58 2014] clearly not, because the type of the constructor F1 cannot unify with Fin.t 0 [Mon Dec 1 20:28:08 2014] since (S x) cannot unify with O [Mon Dec 1 20:30:24 2014] then FS just turns a Fin.t n into a Fin.t (n + 1), so it only makes things worse in some sense :) [Mon Dec 1 20:30:56 2014] Ptival: any i : Fin n means i as a nat is < n [Mon Dec 1 20:31:12 2014] you said the opposite when you said that Fin m means m < n [Mon Dec 1 20:37:01 2014] oh sorry I meant to type m > n [Mon Dec 1 20:37:17 2014] johnw: thanks [Mon Dec 1 20:40:43 2014] Ptival: Oh, and thank you. [Mon Dec 1 20:42:14 2014] So, how would one iterate over the possible values of a Fin.t n? I deduce I must match on the type. [Mon Dec 1 20:46:32 2014] yes [Mon Dec 1 20:46:47 2014] it's basically a form of natural, with constructors F1 and FS [Mon Dec 1 20:52:31 2014] Hrmm. I can do it decreasing if I can get the maximal Fin.t n value. [Mon Dec 1 20:52:56 2014] E.g. given 3, I have FS (FS F1). [Mon Dec 1 20:53:06 2014] right [Mon Dec 1 20:53:17 2014] there's a function to convert from Fin n to nat [Mon Dec 1 21:01:29 2014] I want to keep it as Fin.t, but I guess I need to make a dependent match to get the n, then make a Fin.t n with the right number of FS. [Mon Dec 1 22:04:39 2014] johnw: around? [Mon Dec 1 22:04:57 2014] yes, i'm here what you need? [Mon Dec 1 22:05:08 2014] so, do you suggest to start with induction on l? [Mon Dec 1 22:05:17 2014] what are we talking about exactly? [Mon Dec 1 22:05:53 2014] about proving 'combine_split' from sf. we talked about it a couple of days ago. [Mon Dec 1 22:06:06 2014] yes, the beginning of that proof is to start with induction on l [Mon Dec 1 22:06:51 2014] okay, I've done that. how do I get rid of combine (y :: yt) l2 = []? [Mon Dec 1 22:07:05 2014] or do I need to destruct the whole thing on the left? [Mon Dec 1 22:07:38 2014] I don't remember exactly anymore, but if you look in my github you can see the steps of the proof as I did it. Maybe only glance at it briefly so it just gives you a hint [Mon Dec 1 22:08:11 2014] okay, I'll do that. sorry for wasting your time on this. [Mon Dec 1 22:08:26 2014] it's no waste of time, i just don't happen to remember that clearly right at this moment [Mon Dec 1 22:13:20 2014] uh, the trick is to simpl the hypothesis to get ([], []) = (l1, l2) [Tue Dec 2 10:04:02 2014] hey yo [Tue Dec 2 10:04:04 2014] i have this: [Tue Dec 2 10:04:05 2014] H0 : forall i : B, exists p : A, f p = i [Tue Dec 2 10:04:05 2014] X : B [Tue Dec 2 10:04:05 2014] ============================ [Tue Dec 2 10:04:05 2014] A [Tue Dec 2 10:04:19 2014] but: [Tue Dec 2 10:04:20 2014] > apply H0. [Tue Dec 2 10:04:20 2014] > ^^^^^^^^ [Tue Dec 2 10:04:20 2014] Error: Case analysis on sort Type is not allowed for inductive definition ex. [Tue Dec 2 10:04:29 2014] how do i do tihs [Tue Dec 2 10:23:47 2014] Coq is assuming [A] and [B] have type [Type]. If they’re type [Prop], this works just fine. There’s something about destructing an existential in [Type] that breaks predicativity, but I don’t fully understand it; [Prop] is impredicative anyway, so Coq is okay with this. [Tue Dec 2 10:26:50 2014] alkabetz: yeah, but... [Tue Dec 2 10:27:00 2014] Wouldn't the problem be that ex is in Prop, so it has to be erasable, so you cannot destruct it to build something in Type ? [Tue Dec 2 10:27:00 2014] wait [Tue Dec 2 10:27:07 2014] Cypi: oooooooh [Tue Dec 2 10:27:08 2014] that blows [Tue Dec 2 10:27:09 2014] (not sure, actually asking) [Tue Dec 2 10:27:19 2014] Cypi: that does sound right q_q [Tue Dec 2 10:27:41 2014] well i went and defined surjectivity using an existential [Tue Dec 2 10:27:45 2014] er, an existential result [Tue Dec 2 10:27:49 2014] now what .o. [Tue Dec 2 10:27:56 2014] is there, like, Type existential [Tue Dec 2 10:28:26 2014] Isn’t that a sigma type? [Tue Dec 2 10:28:26 2014] Yes: sigT [Tue Dec 2 10:28:40 2014] or sig [Tue Dec 2 10:29:03 2014] Hi ! [Tue Dec 2 10:29:36 2014] Is it possible to do implicit coercions between naturals/reals, while proving a simple equality ? [Tue Dec 2 10:29:41 2014] Maybe with C-Corn ? [Tue Dec 2 10:30:09 2014] what is C-Corn o.O [Tue Dec 2 10:30:40 2014] http://corn.cs.ru.nl// [Tue Dec 2 10:31:21 2014] It define reals constructively, (While the standard library define them as axioms) [Tue Dec 2 10:31:26 2014] It defines* [Tue Dec 2 11:30:38 2014] how can you constructively define reals in a way that the computer can process? [Tue Dec 2 11:30:54 2014] functions of digit position?? [Tue Dec 2 11:39:46 2014] benzrf : reals are constructed with cauchy sequences. But when you want to compute with them, you specify an arbitrary precision [Tue Dec 2 11:42:23 2014] Choups314: ah [Tue Dec 2 12:05:50 2014] I was just explaining the reals in terms of Cauchy sequences to my partner last night. [Tue Dec 2 12:06:12 2014] Explaining that 1.000... and 0.999... are the exact same number is a bit challenging. [Tue Dec 2 12:07:02 2014] but saying that -0.999... = 0 at the end of it got me an, "oh okay, that makes sense." [Tue Dec 2 12:07:07 2014] I bet [Tue Dec 2 12:07:46 2014] "-0.999... = 0" >> what? [Tue Dec 2 12:07:58 2014] ya, I got that one wrong. [Tue Dec 2 12:08:14 2014] ok [Tue Dec 2 12:08:21 2014] haha [Tue Dec 2 12:08:34 2014] I had a couple scotches by that time. [Tue Dec 2 12:12:49 2014] "Scotch: Making Cauchy sequences more comprehensible since the 1800s" [Tue Dec 2 12:15:12 2014] Yes, officer, I saw the man who hit me and his name was Johnny Walker [Tue Dec 2 12:30:06 2014] /window move 234234 [Tue Dec 2 14:34:13 2014] What does the classes represent ? [Tue Dec 2 14:34:36 2014] ? [Tue Dec 2 15:16:54 2014] i have S (length t) = S n' in my hypothesis and need to prove length t = n' [Tue Dec 2 15:17:03 2014] i could've sworn i could do apply f_equal to the hypothesis [Tue Dec 2 15:17:10 2014] but i cant seemt o get it to work.. am i imaginign things? [Tue Dec 2 15:17:33 2014] f_equal should do it, I'd have thought [Tue Dec 2 15:17:33 2014] is there an S_inj? [Tue Dec 2 15:17:40 2014] f_equal gives you [x = y -> f x = f y] [Tue Dec 2 15:17:48 2014] so when applied to an hypothesis like this, it won't work [Tue Dec 2 15:18:12 2014] What you can use is inversion [Tue Dec 2 15:18:39 2014] ohhhhh yes inversion is what i was thinking of [Tue Dec 2 15:19:37 2014] If it was the reverse situation, that is, you have to prove [S (length t) = S n'], then f_equal would transform the goal into [length t = n'], indeed [Tue Dec 2 15:20:07 2014] ah ok. oh right, i remember something about forward reasoning and stuff [Tue Dec 2 15:51:20 2014] ah, i didn't realize you were talking about something in your context instead of the goal [Wed Dec 3 00:15:42 2014] is there sth like existentials that produce type instead of prop [Wed Dec 3 00:16:23 2014] rn i define surjectivity as all-of-codomain-has-a-preimage, but apparently i cant use that to construct an inverse [Wed Dec 3 00:24:25 2014] benzrf: sigT [Wed Dec 3 00:24:32 2014] s-sigT [Wed Dec 3 00:24:40 2014] how do i use it [Wed Dec 3 00:24:46 2014] look up sigT [Wed Dec 3 00:25:12 2014] night [Wed Dec 3 09:43:43 2014] Here’s a math puzzle related to covering numbers. Show that there exists an infinite subset S of the non-negative integers with the following properties: [Wed Dec 3 09:43:44 2014] 1) For every positive integer n, there exist integers i and j in S such that i + j = n [Wed Dec 3 09:43:44 2014] 2) f(S, n) = O(sqrt(n) log^10 n), where f(S, n) = the number of integers less than n in S. [Wed Dec 3 15:09:24 2014] are sigma types commonly used? is the fact that i ended up needing them a sign that i chose the wrong way of defining sth? [Wed Dec 3 15:11:18 2014] they are very common for me [Wed Dec 3 15:11:27 2014] ok phew [Wed Dec 3 15:11:30 2014] dependent records are sigmas [Wed Dec 3 15:12:10 2014] johnw: i assumed that exists works the way it does for a reason so if i have an existential that needs to be a sigT i must be doing soething wrong [Wed Dec 3 15:12:13 2014] now, that doesn't mean that you're using them incorrectly :-) [Wed Dec 3 15:12:36 2014] I tend to avoid using sigT to wherever possible, because it doesn't extract is nicely [Wed Dec 3 15:12:39 2014] s/is/as [Wed Dec 3 15:12:44 2014] :I [Wed Dec 3 15:12:59 2014] can you show me an example of the code where you need to use sigT? [Wed Dec 3 15:25:13 2014] johnw: im defining surjectivity as forall codomain exists preimage [Wed Dec 3 15:25:29 2014] johnw: then im trying to prove that bijective functions have inverses [Wed Dec 3 15:25:43 2014] but i cannot construct an inverse because the existential is a Prop [Wed Dec 3 15:34:47 2014] show code [Wed Dec 3 16:03:47 2014] johnw: one sec [Wed Dec 3 16:08:22 2014] Hello, what does the operator [:>] means ? [Wed Dec 3 16:08:36 2014] sub-typing [Wed Dec 3 16:08:41 2014] o [Wed Dec 3 16:08:44 2014] A :> B means that an A can be coerced to a B [Wed Dec 3 16:08:51 2014] Ok :) [Wed Dec 3 16:08:57 2014] johnw: how does coercion wor [Wed Dec 3 16:08:57 2014] k [Wed Dec 3 16:09:00 2014] I'm assuming you encountered this is the record syntax [Wed Dec 3 16:09:04 2014] johnw: similarly defined constructors? [Wed Dec 3 16:09:08 2014] benzrf: it creates a function to do the coercion [Wed Dec 3 16:09:10 2014] Yes ! [Wed Dec 3 16:09:26 2014] johnw: well i mean how does the function work [Wed Dec 3 16:09:28 2014] that it generates [Wed Dec 3 16:09:36 2014] wot it do [Wed Dec 3 16:09:37 2014] you can write one yourself easily [Wed Dec 3 16:09:43 2014] foo (x : A) : B := ... [Wed Dec 3 16:09:50 2014] oh wait [Wed Dec 3 16:09:52 2014] Coercion foo : A >-> B. [Wed Dec 3 16:10:04 2014] so you mean like [Wed Dec 3 16:10:11 2014] there's no impl, it's unsafeCoerce#? [Wed Dec 3 16:10:18 2014] huh? [Wed Dec 3 16:10:33 2014] it's just a function from A -> B [Wed Dec 3 16:10:36 2014] oh i see [Wed Dec 3 16:10:40 2014] wait [Wed Dec 3 16:10:44 2014] what it does, can be up to you [Wed Dec 3 16:10:49 2014] ahhhh you mean that you pass the function to :> [Wed Dec 3 16:10:54 2014] no [Wed Dec 3 16:11:00 2014] in the :> case, it auto-generates the function in question [Wed Dec 3 16:11:04 2014] johnw: ok, so [Wed Dec 3 16:11:05 2014] I'm not sure what the implementation looks like [Wed Dec 3 16:11:10 2014] my question was, what does that func do [Wed Dec 3 16:11:26 2014] what does it map each thing to? [Wed Dec 3 16:11:26 2014] since A is a superset of B, I imagine it constructs a B using the required elements [Wed Dec 3 16:11:39 2014] required elements? [Wed Dec 3 16:11:55 2014] elements of A that go into B [Wed Dec 3 16:12:08 2014] hmmm... what does a full declaration look like? [Wed Dec 3 16:12:20 2014] i don't want to type one [Wed Dec 3 16:12:22 2014] ok [Wed Dec 3 16:13:04 2014] i dont follow how subtyping works, though... do you specify that you can have these extra constructors too and then the constructors of the supertype can be used for the subtype as well? [Wed Dec 3 16:13:20 2014] i would recommend playing with it, and printing out the generated functions [Wed Dec 3 16:13:27 2014] do you have one constructor that may hold an element of the supertype? [Wed Dec 3 16:13:48 2014] not sure I understand [Wed Dec 3 16:13:55 2014] ok, like [Wed Dec 3 16:14:12 2014] subtypes are supersets aren't they? [Wed Dec 3 16:14:30 2014] no, wait..... [Wed Dec 3 16:14:36 2014] damn ive gone and confused myself [Wed Dec 3 16:30:29 2014] ok [Wed Dec 3 16:30:34 2014] johnw: sorry it took so long https://gist.github.com/ab638e2e71dc13c52c68 [Wed Dec 3 16:32:37 2014] benzrf: Yeah, that looks to be about right [Wed Dec 3 16:32:46 2014] benzrf: my definition of it is almost the same: Definition Surjective `(f : X → Y) := ∀ y, ∃ x, f x = y. [Wed Dec 3 16:32:49 2014] except that I'm using Unicode characters [Wed Dec 3 16:39:30 2014] i and p for image and preimage [Wed Dec 3 16:39:38 2014] johnw: your ∃ is sigT? [Wed Dec 3 16:40:21 2014] benzrf: no, it's "exists" [Wed Dec 3 16:40:24 2014] sig [Wed Dec 3 16:40:42 2014] actually, I think that the word exists can be applied for either one [Wed Dec 3 16:42:15 2014] Coq < Definition eq0 (n : nat) := match n with | O => true | _ => false end. [Wed Dec 3 16:42:25 2014] > Check ex nat eq0. [Wed Dec 3 16:42:25 2014] > ^^^ [Wed Dec 3 16:42:25 2014] Error: The term "nat" has type "Set" while it is expected to have type "?11 -> Prop". [Wed Dec 3 16:42:28 2014] hmm? [Wed Dec 3 16:42:34 2014] ex : forall A : Type, (A -> Prop) -> Prop [Wed Dec 3 16:43:08 2014] Check exist _ [Wed Dec 3 16:43:28 2014] I have never used 'ex' constructor directly [Wed Dec 3 16:43:32 2014] benzrf : A is implicit [Wed Dec 3 16:43:46 2014] put a @ if you reall want to specify every parameter [Wed Dec 3 16:44:41 2014] oh wait that's to bool [Wed Dec 3 16:44:47 2014] Cypi: thanks though :) [Wed Dec 3 16:45:40 2014] johnw: is there notation for sig in the prelude (or w/e coq calls it) [Wed Dec 3 16:46:24 2014] { x : nat | odd x } [Wed Dec 3 16:46:27 2014] that's a sig type [Wed Dec 3 16:46:32 2014] { x : nat & odd x } [Wed Dec 3 16:46:34 2014] that's a sigT type [Wed Dec 3 16:47:12 2014] exist odd 1 odd_1 would construct one of the former (assuming you defined odd_1) [Wed Dec 3 16:47:19 2014] existT odd 1 odd_1 would construct one of the latter [Wed Dec 3 16:47:39 2014] wait, what's the diff [Wed Dec 3 16:47:48 2014] you can typically replace the first parameter when using these constructors with just an underbar [Wed Dec 3 16:47:52 2014] sig vs. sigT [Wed Dec 3 16:48:47 2014] yeah but uh [Wed Dec 3 16:48:52 2014] whats the differenence between sig and sigT [Wed Dec 3 16:49:01 2014] oh ok i see [Wed Dec 3 16:49:02 2014] derp [Wed Dec 3 16:50:14 2014] you've been saying it all along: Prop versus Type [Wed Dec 3 16:55:52 2014] heh [Wed Dec 3 16:58:02 2014] what are the inhabitants of unique [Wed Dec 3 16:58:11 2014] what is unique? [Wed Dec 3 16:59:20 2014] Coq < Check unique. [Wed Dec 3 16:59:20 2014] unique : forall A : Type, (A -> Prop) -> A -> Prop [Wed Dec 3 16:59:37 2014] found it by accident because there's some kind of syntax for exists that involves it [Wed Dec 3 17:00:10 2014] it says that if a property exists for two different values of A, then those two values are the same value [Wed Dec 3 17:00:23 2014] Definition unique (A : Type) (P : A->Prop) (x:A) := P x /\ forall (x':A), P x' -> x=x'. [Wed Dec 3 17:00:42 2014] I really recommend browsing the standard library documentation online: https://coq.inria.fr/library/Coq.Init.Logic.html [Wed Dec 3 17:00:49 2014] since it can answer a lot of these types of questions [Wed Dec 3 17:01:18 2014] sry [Wed Dec 3 17:33:53 2014] yo johnw [Wed Dec 3 17:34:02 2014] theres problem [Wed Dec 3 17:34:02 2014] yo [Wed Dec 3 17:34:13 2014] The term "surjective" has type "Type" while it is expected to have type "Prop". [Wed Dec 3 17:34:22 2014] becaues: [Wed Dec 3 17:34:23 2014] Definition bijective := injective /\ surjective. [Wed Dec 3 17:34:27 2014] oh wait [Wed Dec 3 17:34:40 2014] yea [Wed Dec 3 17:35:06 2014] you will need to define surjectivity as a property [Wed Dec 3 17:35:14 2014] heuh [Wed Dec 3 17:35:23 2014] johnw: btw does it make sense to define them like that [Wed Dec 3 17:35:29 2014] in a section with the function in question as a variable [Wed Dec 3 17:35:34 2014] i.e., Definition Surjective `(f : X → Y) : Prop := ∀ y, ∃ x, f x = y. [Wed Dec 3 17:35:58 2014] actually, that is not going to work. Let me play around with a here for a second [Wed Dec 3 17:36:03 2014] :p [Wed Dec 3 17:36:23 2014] no, that does work [Wed Dec 3 17:38:25 2014] ? [Wed Dec 3 17:38:43 2014] johnw: but ∃ x, f x = y : Type [Wed Dec 3 17:38:58 2014] so ∀ y, ∃ x, f x = y : Type [Wed Dec 3 17:39:27 2014] why is it : Type? [Wed Dec 3 17:41:12 2014] benzrf: https://gist.github.com/c3c16a042cfce3546cad [Wed Dec 3 17:41:15 2014] no Type involved, only Prop [Wed Dec 3 17:42:38 2014] what is move [Wed Dec 3 17:42:54 2014] ignore the contents of the proof [Wed Dec 3 17:43:29 2014] ok so then we're back at my original problem [Wed Dec 3 17:43:50 2014] ooooh wait [Wed Dec 3 17:44:33 2014] johnw: ok but how does this help [Wed Dec 3 17:46:44 2014] how does it help what? I really have no idea what your issue is at this point [Wed Dec 3 17:49:13 2014] johnw: i cannot prove surjective functions have inverses because i cannot construct a function based on an ex [Wed Dec 3 17:49:27 2014] https://gist.github.com/ab638e2e71dc13c52c68 [Wed Dec 3 17:49:34 2014] ^try running that up to where it stops and see the error [Wed Dec 3 17:54:56 2014] you sure that expresses the problem right? [Wed Dec 3 17:55:01 2014] I tried this: https://gist.github.com/1ecb4a49ebbbc2f70c56 [Wed Dec 3 17:55:05 2014] gotta go now, dinner calls [Wed Dec 3 18:27:54 2014] Is there a way to add a new reduction rule to Coq? This isn't useful, but I would've liked to check a few things that could happen if we were to suppose that Coq reduces [nat -> nat] to [nat], for example. [Wed Dec 3 18:30:54 2014] Cypi: wouldnt real work better [Wed Dec 3 18:31:17 2014] It's supposed not to work, indeed, that's why I said it wasn't useful :p [Wed Dec 3 18:31:23 2014] (yes, it would create an inconsistency) [Wed Dec 3 19:19:27 2014] does anyone use ocamlbuild to build coq? [Wed Dec 3 19:20:03 2014] using it on 8.4pl5 fails with an unbound module warning [Wed Dec 3 19:42:48 2014] what is eexists [Wed Dec 3 19:44:25 2014] Like exists, but you don't have to specify a witness, Coq can just replace it with an existential (something like ?123) that you will have to instantiate later [Wed Dec 3 19:44:41 2014] (or it will be automatically instantiated by unification with something else at some point later on) [Wed Dec 3 19:45:12 2014] oh geez [Wed Dec 3 19:47:15 2014] what is inversion [Wed Dec 3 19:57:08 2014] Cypi: how do you instantiate it [Wed Dec 3 19:57:55 2014] Most of the time, by unification with something else [Wed Dec 3 20:00:33 2014] Quick and uninteresting example, just to show it: http://lpaste.net/115613 [Wed Dec 3 20:00:51 2014] eassumption is the version of assumption that can deal with these existential variables [Wed Dec 3 20:01:10 2014] huh [Wed Dec 3 20:03:26 2014] More directly, you could also use [instantiate (1 := n)] (1 is the position of the existential), but really, I never used it in practice [Wed Dec 3 21:34:52 2014] ok so [Wed Dec 3 21:34:53 2014] WHAT [Wed Dec 3 21:34:54 2014] EXACTLY [Wed Dec 3 21:34:56 2014] causes [Wed Dec 3 21:34:56 2014] Error: Case analysis on sort Type is not allowed for inductive definition ex. [Wed Dec 3 21:35:54 2014] Again the fact that you are destructing something in Prop when your goal is in Type, I guess? [Wed Dec 3 21:46:04 2014] benzrf: you really need to start accompanying your questions of code, otherwise it is almost impossible to determine what your problem is [Wed Dec 3 21:46:07 2014] s/of/with [Wed Dec 3 21:46:36 2014] i'm sorry [Wed Dec 3 21:47:08 2014] johnw: what's inversion, then [Wed Dec 3 21:47:57 2014] It takes a statement in your context, and determines pretty much everything that must be true in order for that statement to be true. That is just one of the things that it does, it is rather a complex tactic. [Wed Dec 3 21:48:40 2014] The best that I can recommend is to look at the sections of Software Foundations where they introduce the 'inversion' tactic; they do a bit of explaining there [Thu Dec 4 08:26:15 2014] Hello. [Thu Dec 4 08:28:33 2014] (SSReflect) Is there counterpart from "calculation world" for orders? [Thu Dec 4 08:28:36 2014] I mean there are Prop's /\ and bool's &&, Prop's = and bool's ==. [Thu Dec 4 08:28:38 2014] Is there something like comparing function (Lt,Gt,Eq) in ssreflect with reflection principles into plain Prop's relations? [Thu Dec 4 11:24:30 2014] is there a ssreflect version of "simpl foo"? i know i can lock the other stuff, but i really just want to evaluate one function one step further [Thu Dec 4 13:56:40 2014] what are the implications of using a semicolon vs a period to separate statements? [Thu Dec 4 14:00:34 2014] adelbertc: example? [Thu Dec 4 14:00:57 2014] was stepping through this: https://github.com/jwiegley/software-foundations/blob/master/MoreCoq.v#L1124-1128 [Thu Dec 4 14:01:03 2014] used periods instead of semicolons [Thu Dec 4 14:01:09 2014] didnt work. replaced with semicolons. worked. [Thu Dec 4 14:01:10 2014] o_O [Thu Dec 4 14:01:30 2014] Semicolons have a special meaning in Ltac. [Thu Dec 4 14:01:59 2014] If you say 'induction l1. intros.', Coq will do induction on [l1], and then it will descend into the first goal and do 'intros'. [Thu Dec 4 14:02:13 2014] If you say 'induction l1; intros.', Coq will do induction on [l1], and then execute 'intros' in *both* generated subgoals. [Thu Dec 4 14:02:57 2014] ah.. hm. [Thu Dec 4 14:03:25 2014] Did I lose you? [Thu Dec 4 14:03:37 2014] no i think i get it [Thu Dec 4 15:46:34 2014] alkabetz: oh, cool. it hasn't been covered in the book. [Thu Dec 4 16:43:36 2014] What does IR means in coq ? [Thu Dec 4 16:44:06 2014] I know CR stand for Computable Reals, but what about IR ? [Fri Dec 5 01:51:51 2014] trying to compile some code from SF, but getting "There are pending proofs" yet when I drop into the file, go to the end of file and hit "compile to cursor" everything is OK - any ideas? [Fri Dec 5 01:51:55 2014] $ coqc MoreCoq.v [Fri Dec 5 01:51:55 2014] Error: There are pending proofs [Fri Dec 5 02:41:56 2014] adelbertc: coqc isn't happy if you haven't matched all your theorems to a Qed (or Admitted (or Defined)) [Fri Dec 5 02:52:09 2014] jrw: aha. i didnt end with a Qed with one of my proofs. strange how Proof General was OK with ti though [Fri Dec 5 02:52:11 2014] thanks! [Fri Dec 5 08:18:32 2014] Hello ? To solve basic equalities or inequalities over reals (Such as 2.0 < 3.0 for instance), do I have to use CoRN, or there is an easy workaround with coq ? [Fri Dec 5 09:33:19 2014] How can I solve a goal of record type? Say the name of the record is abc with constructor build_abc, I tried 'apply build_abc', but this yields an error. I tried to search for examples, but in the HoTT sources e.g. I can only find applications of build-constructors in handwritten gallina [Fri Dec 5 09:34:02 2014] Ideally, I'd like to have Coq generate successive subgoals for the fields of the record [Fri Dec 5 09:37:41 2014] habecker: 'split' ought to do the trick. [Fri Dec 5 09:40:45 2014] alkabetz: This doesn't work for me if the fields of the record depend on each other [Fri Dec 5 09:41:03 2014] Oh, yikes [Fri Dec 5 09:41:08 2014] Can you paste your script? [Fri Dec 5 09:44:27 2014] alkabetz: sure - http://pastebin.com/NcKN9xM6 [Fri Dec 5 09:55:19 2014] alkabetz: do you have any idea what's wrong, or which tactic could be used instead of split of that doesn't support dependent record fields? [Fri Dec 5 09:56:40 2014] I don’t know how to destruct dependent records. I tried Googling around for how to unfold a Π type (to which a dependent record is isomorphic), but I’m still not sure how to do that, either. :/ [Fri Dec 5 09:57:28 2014] It might be useful to search for dependent records on the coq-club archive, or to ask there. I think I’m unlikely to be able to be of actual help now, though. I’m interested to hear what ends up being the answer! [Fri Dec 5 10:11:07 2014] alkabetz: Okay, thank you! [Fri Dec 5 10:12:03 2014] gtg, bye! [Fri Dec 5 10:12:09 2014] * waves [Fri Dec 5 11:30:12 2014] am I here? [Fri Dec 5 13:58:15 2014] What is the difference between IR and CR in CoRN ? When should I use one rather than the other ? [Fri Dec 5 14:57:02 2014] No ideas ? :/ [Fri Dec 5 16:18:50 2014] Is it possible to apply the split tactis to goals of dependent record type? If not, how can one solve goals of such types? [Fri Dec 5 16:22:49 2014] habecker: evars are the common tool for those I think [Fri Dec 5 16:30:31 2014] ianjneu: ah ok - do you have an example showing how one can use them for solving dependent record type goals? [Sat Dec 6 00:34:36 2014] "Define an analogous notion of Betti numbers for smooth algebraic varieties of dimension 1 over characteristic p algebraically closed fields." [Sat Dec 6 00:34:43 2014] Can this be proved in Coq? [Sat Dec 6 00:36:20 2014] marvimias: try it [Sat Dec 6 00:36:39 2014] johnw, I imagine reals do not work well in Coq [Sat Dec 6 00:38:19 2014] https://www.kevinjsullivan.com/real-numbers-in-coq-a-tutorial [Sat Dec 6 00:38:26 2014] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.6128 [Sat Dec 6 01:08:01 2014] coachy [Sat Dec 6 01:08:37 2014] you mean Cauchy? :) [Sat Dec 6 01:19:29 2014] johnw: i know what i mean [Sat Dec 6 01:21:38 2014] Cantor count on that ;) [Sat Dec 6 06:18:26 2014] is there a lemma proving decidability of Forall or forall somewhere? [Sat Dec 6 06:30:35 2014] Okay, here is a puzzle; suppose f,g are in Q[x] such that f(Q) = g(Q). show that there exist a,b in Q such that f(x) = g(ax + b) [Sat Dec 6 10:36:42 2014] Anyone using CoRN here ? :) [Sat Dec 6 14:59:27 2014] question about SF Rel.v, on transitive relations [Sat Dec 6 14:59:30 2014] I have (n m o : nat), (Hnm : n <= m), (Hmo : m <= o) in the context, with n <= o in the goal. Why does `inversion Hmo` give `n <= m` and `n <= S m0` as subgoals? Where did the `o` go? [Sat Dec 6 15:00:04 2014] s/induction/inversion [Sat Dec 6 15:00:17 2014] wait no, induction is correct. [Sat Dec 6 15:00:28 2014] bah. restated [Sat Dec 6 15:00:35 2014] I have (n m o : nat), (Hnm : n <= m), (Hmo : m <= o) in the context, with n <= o in the goal. Why does `induction Hmo` give `n <= m` and `n <= S m0` as subgoals? Where did the `o` go? [Sat Dec 6 15:05:03 2014] I’m not 100% sure, but I think that in the first goal, Coq set it as equal to m and substituted. In the second goal, it looks like it got renamed to [m0] for some reason. [Sat Dec 6 15:05:20 2014] If you really want to preserve the names, 'induction Hmo as [| o Hmo IH]' looks like it does the trick. [Sat Dec 6 15:45:04 2014] I don't really understand the constructive definition of binary operations in corn .. [Sat Dec 6 18:11:06 2014] has anyone solved lt_trans'' in Rel.v of SF? [Sat Dec 6 18:11:26 2014] proving transitivity of lt without using transitive of le [Sat Dec 6 18:12:04 2014] yes, I have [Sat Dec 6 18:12:18 2014] oh, interesting [Sat Dec 6 18:12:21 2014] I guess not [Sat Dec 6 18:12:22 2014] one sec [Sat Dec 6 18:12:39 2014] hmm [Sat Dec 6 18:12:46 2014] I guess using omega for both branches is cheating [Sat Dec 6 18:13:07 2014] Wow, how did I do exactly the same? oO [Sat Dec 6 18:13:21 2014] Especially since omega actually immediately solves the goal... [Sat Dec 6 18:14:14 2014] ok, solved it without omega [Sat Dec 6 18:14:48 2014] adelbertc: https://github.com/jwiegley/software-foundations/blob/master/Rel.v#L143 [Sat Dec 6 18:15:12 2014] johnw: that was quick. dont i feel silly :P [Sat Dec 6 18:15:29 2014] I just used the searching facilities of Coq to find the lemmas I needed [Sat Dec 6 18:15:37 2014] SearchAbout? [Sat Dec 6 18:15:42 2014] and SearchIsos [Sat Dec 6 18:15:55 2014] SearchIsos (S _ <= _). [Sat Dec 6 18:16:02 2014] oo [Sat Dec 6 18:16:05 2014] havent seen SearchIsos yet [Sat Dec 6 18:16:05 2014] to be specific, I used ssreflect's more powerful Search command [Sat Dec 6 18:16:06 2014] but nifty. [Sat Dec 6 18:16:11 2014] which subsumes SearchAbout and SearchIsos [Sat Dec 6 18:17:27 2014] oh wait, i had gotten that one [Sat Dec 6 18:17:28 2014] what of https://github.com/jwiegley/software-foundations/blob/master/Rel.v#L158 [Sat Dec 6 18:18:56 2014] adelbertc: solved; refresh [Sat Dec 6 18:19:21 2014] i'm not sure if I'm using things that I shouldn't be or not [Sat Dec 6 18:19:37 2014] Hmm, solved it without external lemmas, thought it was more in the spirit. [Sat Dec 6 18:19:52 2014] because I see that le_Sn_le isn't yet available [Sat Dec 6 18:20:15 2014] i'll undo those solutions until I do that file properly [Sat Dec 6 18:21:03 2014] adelbertc : where are you stuck? [Sat Dec 6 18:22:36 2014] Cypi: i just unstuck myself [Sat Dec 6 18:22:41 2014] used rewrite a lot... maybe thats cheating [Sat Dec 6 18:23:40 2014] I suppose not :) [Sat Dec 6 18:24:02 2014] basically.. transitivity through rewriting [Sat Dec 6 18:24:03 2014] heh. [Sat Dec 6 18:24:26 2014] As long as you didn't use external lemmas, you couldn't have been cheating :p [Sat Dec 6 18:24:34 2014] well, you can always do it with helper lemmas and induction [Sat Dec 6 18:24:37 2014] (well, I did use le_S, but that's a constructor, not really a lemma) [Sun Dec 7 00:45:10 2014] requesting hints/assistance on SF Rel.v, 2nd to last problem https://github.com/adelbertc/software-foundations/blob/master/Rel.v#L359 [Sun Dec 7 00:45:43 2014] i've tried inversion-ing and induction-ing hypotheses and i think i get somewheere, but i always end up back right where i started (refl_step_closure R x z) only with a bunch of garbage (?) in the context [Sun Dec 7 00:52:53 2014] adelbertc: my guess is that you need to use [generalize dependent] or rearrange the statement of the lemma so that you get a strong enough induction hypothesis (with z universally quantified, if you do induction on the first hypothesis) [Sun Dec 7 01:24:46 2014] jrw: aha got it, thanks! [Sun Dec 7 01:25:45 2014] np [Sun Dec 7 09:38:30 2014] Is there a way to automating every proofs involving the basics operations over Z (Like the ones here https://coq.inria.fr/distrib/current/stdlib/Coq.ZArith.BinInt.html) ? [Sun Dec 7 09:38:54 2014] By using the fact that (Z, +, x) is a ring perhaps ? [Sun Dec 7 11:35:18 2014] Is the congruence of two integers (Z) defined is the standard library ? [Sun Dec 7 12:13:06 2014] Choups314: Definition int_cong (n m : Z) := (n mod m = 0%Z) [Sun Dec 7 12:14:01 2014] ZArith has Z.modulo, which has an infix notation a mod b. [Sun Dec 7 12:14:11 2014] It's a part of the stdlib ? [Sun Dec 7 12:14:28 2014] ZArith is standard, ya. [Sun Dec 7 12:14:41 2014] oh yes .. thansk ;) [Sun Dec 7 12:14:44 2014] thanks* [Sun Dec 7 12:17:03 2014] ianjneu: And for example, do I use this definition to express http://latex.codecogs.com/gif.latex?a%20%5Cequiv%20b%20%5Cmod%20n [Sun Dec 7 12:17:04 2014] a equiv b mod n is Definition zcong (a b n : Z) : Prop := (Z.modulo (a - b) n) = 0. [Sun Dec 7 12:17:21 2014] Ok perfect ! [Sun Dec 7 12:17:49 2014] I never thought of it this way ^^ [Sun Dec 7 12:18:46 2014] And there are plenty of theorems about Z.modulo in ZArith, so just use SearchAbout. [Sun Dec 7 12:19:13 2014] Yes, this is why I wanted to use a stdlib definition ! [Sun Dec 7 23:02:49 2014] Hrmm. [Sun Dec 7 23:03:28 2014] Are there boolean equivalents of > or eraserhd: lt_dec etc? [Sun Dec 7 23:07:05 2014] not bools, but sumbools [Sun Dec 7 23:07:11 2014] so probably more useful [Sun Dec 7 23:20:08 2014] wots a sumbool [Sun Dec 7 23:26:49 2014] benzrf: it’s basically just two properties, either A or B.. with runtime representation of a simple bool [Sun Dec 7 23:28:00 2014] so lt_dec : forall n m, {n < m} + {~ n < m} [Sun Dec 7 23:28:10 2014] where {P} + {Q} is a sumbool [Sun Dec 7 23:28:30 2014] so instead of just getting a bool, you also get some interesting proof [Sun Dec 7 23:30:57 2014] whats the {} there [Sun Dec 7 23:31:34 2014] just magic notation for sumbool: [Sun Dec 7 23:31:43 2014] > Print sumbool. [Sun Dec 7 23:31:44 2014] Inductive sumbool (A B : Prop) : Set := [Sun Dec 7 23:31:45 2014] left : A -> {A} + {B} | right : B -> {A} + {B} [Sun Dec 7 23:32:10 2014] oh [Sun Dec 7 23:32:22 2014] I’m not really sure why [Sun Dec 7 23:32:26 2014] so how is sumbool different from just either [Sun Dec 7 23:33:47 2014] so, do you know how/why the universes are divided into Set and Prop? [Sun Dec 7 23:34:05 2014] Sets being computational things, and Props being proofs? [Sun Dec 7 23:35:44 2014] I guess it’s mainly about extracting code, so Sets can be extracted and Props are ignored/erased [Sun Dec 7 23:36:45 2014] so if you extracted a sumbool {P} + {Q}, it’d be erased to something like {} + {} = True | False [Sun Dec 7 23:37:30 2014] but an either wouldn’t erase that [Sun Dec 7 23:37:33 2014] I think [Mon Dec 8 12:45:40 2014] hmm [Mon Dec 8 12:46:10 2014] a nonconstructive proof of existence is really more of a threat than a proof [Mon Dec 8 12:46:22 2014] like, "well if it DOESNT exist then your LOGIC IS INCONSISTENT" [Mon Dec 8 12:46:40 2014] "i cant SHOW you but it BETTER exist" [Mon Dec 8 12:47:10 2014] it relies on you choosing to believe that a thing exists rather than that your logic is inconsistent [Mon Dec 8 12:48:37 2014] it's equally valid to say "no, my logic is inconsistent, and X doesn't exist", but we choose not to because that's what we dont want to think [Mon Dec 8 12:49:14 2014] inconsistent means everything is "provable" [Mon Dec 8 12:49:28 2014] both X exists and doesn't exist. [Mon Dec 8 12:50:19 2014] ianjneu: i mean exists in whatever mental model you're using your logic to reason about [Mon Dec 8 12:50:44 2014] ianjneu: presumably if i prove the well-ordering theorem it corresponds to some idea in my mind about sets as collections of things and putting them in order by settings things in front of each other [Mon Dec 8 12:51:06 2014] you can encode False as forall A, A, and True as forall A, A -> A. This is why the Y combinator is very inconsistent - Y : forall A. (A -> A) -> A. basically says "True implies False" [Mon Dec 8 12:52:21 2014] woah [Mon Dec 8 12:52:37 2014] ya. [Mon Dec 8 12:52:40 2014] Fun fun. [Mon Dec 8 12:52:49 2014] ianjneu: wait a sec [Mon Dec 8 12:53:04 2014] forall A. (A -> A) -> A isnt the same thing as (forall A. A -> A) -> (forall A. A) [Mon Dec 8 12:53:27 2014] ok be back in a minute i have school stuff igotta do :( [Mon Dec 8 13:05:19 2014] ianjneu: 01:04 < benzrf> forall A. (A -> A) -> A isnt the same thing as (forall A. A -> A) -> (forall A. A) [Mon Dec 8 13:17:22 2014] benzrf: it's a rough understanding of the Y combinator, sure. [Mon Dec 8 15:20:12 2014] benzrf: That's only accurate in the sets or propositions model. In the homotopical model, forall A, P A means that P is "continuously" provable of all A, while forall A, || P A || (which is like forall A, ~~P A, but with a better elim) allows discontinuity. For example, there is always merely a path between any point on the circle and the basepoint, but there is no way of continuously assigning such paths to points. So you have forall x : S1, [Mon Dec 8 15:20:12 2014] ~~x = basepoint, but you don't have forall x : S1, x = basepoint. [Mon Dec 8 18:16:21 2014] uuh jgross_ [Mon Dec 8 18:16:26 2014] i dont know ANY of this stuff T_T [Mon Dec 8 18:39:43 2014] benzrf: You should read the HoTT Book (http://homotopytypetheory.org/book/) and/or hang around on ##hott (on freenode). If you want something concrete to wrap your head around, look at http://math.andrej.com/2007/09/28/seemingly-impossible-functional-programs/; the intuition that allows people to come up with stuff like that comes from a topological interpretation of type theory. [Mon Dec 8 18:40:34 2014] bwah [Mon Dec 8 18:40:39 2014] jgross_: i dont know enough math yet [Mon Dec 8 18:40:44 2014] i dont know topology [Mon Dec 8 18:44:20 2014] Munkres' _Topology_ is a good introductory text to point-set topology, if you're looking for a reference. To understand most of the post, I think all you need is continuity of functions, plus possibly compactness for making it seem less magical. [Mon Dec 8 18:50:40 2014] jgross_: i actually started that book [Mon Dec 8 18:50:51 2014] jgross_: but i kinda petered out while still in the review section [Mon Dec 8 18:50:56 2014] i keep thinking ill get back to it [Mon Dec 8 19:02:38 2014] jgross_: question [Mon Dec 8 19:02:53 2014] cant i make an injection Integer -> Cantor [Mon Dec 8 19:03:39 2014] no wait [Mon Dec 8 19:06:18 2014] ok! [Mon Dec 8 19:06:21 2014] jgross_: you there? [Mon Dec 8 19:11:39 2014] jgross_: can't i construct a surjection c :: Cantor -> Integer, then for any f and g :: Integer -> Integer check f . c == g . c to show whether f == g? [Mon Dec 8 19:44:14 2014] benzrf: Cantor = (nat -> bool), and clasically is the size of the reals. How are you surjecting onto the integers? [Mon Dec 8 19:46:16 2014] jgross_: how about, say [Mon Dec 8 19:46:59 2014] jgross_: first bit is sign, after that doubled 1s and 0s for 1 and 0 as a binary natural, terminate with a 01 or 10, then infinite 0s [Mon Dec 8 19:47:48 2014] if it's invalidly formatted, 0 [Mon Dec 8 19:48:32 2014] jgross_: oh... is there an issue when it's infinitely long/valid but never terminates [Mon Dec 8 19:48:35 2014] like 1111111111111111111111111.... [Mon Dec 8 19:52:16 2014] jgross_: damn. is there no total surjection [Mon Dec 8 21:27:56 2014] I thought there was a way to specify to rewrite the value for existential variables, but it appears to not be in the docs. Am I missing something? [Mon Dec 8 21:29:39 2014] eraserhd: do you mean a univerally quantified variable? [Mon Dec 8 21:29:51 2014] you can do that like [rewrite H with (x := val).] [Mon Dec 8 21:30:28 2014] Right, that. [Mon Dec 8 21:38:01 2014] hrmm, can I ask what is probably a _really_ n00b question? [Mon Dec 8 21:38:20 2014] Wait... [Mon Dec 8 21:38:46 2014] eraserhd: go for it [Mon Dec 8 21:39:15 2014] OK, I have (26 <= n - 65). [Mon Dec 8 21:39:26 2014] I want to rewrite with plus_le_reg_l. [Mon Dec 8 21:40:01 2014] When I specify all the things: rewrite plus_le_reg_l with (n := 26) (m := n - 65) (p := 65) in ge_proof2. [Mon Dec 8 21:40:43 2014] I get a crazy long error "Unable to satisfy rewriting constraints:" ... [Mon Dec 8 21:41:41 2014] I'm not even sure where to begin with what I'm missing. :) [Mon Dec 8 21:42:54 2014] eraserhd: yeah that's a horrible error message. what are you trying to do though, because rewrite probably isn't what you meant there [Mon Dec 8 21:43:07 2014] Add 65 to both sides. [Mon Dec 8 21:43:43 2014] eraserhd: if this is in a hypothesis, then plus_le_reg_l won't do that. [Mon Dec 8 21:44:04 2014] you would need [n <= m -> p + n <= p + m] [Mon Dec 8 21:44:24 2014] I tried that one, it won't match. [Mon Dec 8 21:44:45 2014] wait... lemme try again. [Mon Dec 8 21:45:19 2014] [apply plus_le_compat_l with (p := 65) in ] should do the trick [Mon Dec 8 21:45:39 2014] I'd also point out that if you're trying to cancel the [- 65] this won't work unless you know n >= 65 [Mon Dec 8 21:46:30 2014] oh but you do know that. never mind. [Mon Dec 8 21:47:15 2014] OK, what is the difference between rewrite and apply? [Mon Dec 8 21:48:04 2014] (Feel free to tell me if I'm being too annoying.) [Mon Dec 8 21:48:26 2014] rewrite takes something that ends in an equality and rewrites by that equality. apply takes an implication [P -> Q] and a hypothesis [P] and gives you Q [Mon Dec 8 21:48:45 2014] (you can also rewrite by relations that are not equalities, but you can ignore that for now) [Mon Dec 8 21:50:02 2014] OK, so goals and hypotheses are different in what you can do with them? [Mon Dec 8 21:51:51 2014] It seems like goal Q needs P -> Q to get goal P, while hypothesis Q needs Q -> P to get P. Am I confused? [Mon Dec 8 21:54:04 2014] eraserhd: that's roughly right. [Mon Dec 8 21:54:45 2014] in the case of the hypothesis your reasoning forward from what you know. in the case of the goal you're reasoning backwards as in "it suffices to show" [Mon Dec 8 21:55:44 2014] OK, cool. Needed to hear that :) [Mon Dec 8 22:10:10 2014] Hahaha. converting an ascii character to a fin-like letter is done. It's crazy. But it's done. [Mon Dec 8 22:10:16 2014] Glad I like learning this stuff. [Mon Dec 8 22:11:24 2014] jrw: Thanks a lot. [Mon Dec 8 22:12:27 2014] np [Tue Dec 9 14:37:34 2014] hmmm [Tue Dec 9 14:37:55 2014] i have a forall to a sigma type [Tue Dec 9 14:38:21 2014] how can i retrieve a function to the supertype and a theorem about the function [Tue Dec 9 14:38:44 2014] assert a product? [Tue Dec 9 14:39:42 2014] o wait [Tue Dec 9 16:34:31 2014] Hi. I have a bit silly question about Martin-Lof type theory. Question related to the syntax. [Tue Dec 9 16:35:35 2014] When I am reading some old document, like http://www.cip.ifi.lmu.de/~langeh/test/1984%20-%20Loef%20-%20Intuitionistic%20Type%20Theory.pdf, I can see that the system is formulated in a bit different way. [Tue Dec 9 16:36:38 2014] For example, Lambda seems to be a constructor parametrized by some meta-level function. [Tue Dec 9 16:37:16 2014] For example see rule for beta reduction, it has equation: Ap(\lambda x. b(x), a) = b(a) [Tue Dec 9 16:37:54 2014] It looks like: "type ('a, 'b) pi = App of 'a -> 'b" on some meta level. [Tue Dec 9 16:38:51 2014] When I am reading some modern article, like http://www.cs.swan.ac.uk/~csarnold/amllcc/files/07-nbemltt.pdf, I see that type theory is formulated in some modern way. We do not have some meta-level language. Lambda is function, not some wraper for some meta-level function. [Tue Dec 9 16:39:39 2014] My question is: Does the modern-style formulation of the Martin-Lof type thoery has own name? Could I formulate this theory in style similar to the second article and call it Martin-Lof type theory? [Tue Dec 9 16:39:55 2014] Could we call all predicative type theory a Martin-lof type theory? [Tue Dec 9 16:40:26 2014] "all" -> "any" [Tue Dec 9 16:48:54 2014] ööööö [Tue Dec 9 18:39:34 2014] pls help [Tue Dec 9 18:39:44 2014] i am doing an assertion to produce a witness for an existential [Tue Dec 9 18:39:56 2014] but then i cant unfold the asserted thing so i cant prove the constraint [Tue Dec 9 18:40:07 2014] er, idk if constraint is the right word. but i mean the body of the existential [Tue Dec 9 18:40:31 2014] Give some code, please :) [Tue Dec 9 18:41:49 2014] here's where im stuck https://gist.github.com/benzrf/dd48ee2c22f55101f683 [Tue Dec 9 18:43:10 2014] i mean i could manually type out a lambda but that feels so CRUDE [Tue Dec 9 18:43:13 2014] :v [Tue Dec 9 18:43:43 2014] benzrf: Your an_f is a variable, you cannot unfold it. [Tue Dec 9 18:43:54 2014] xenoslav: that seems to be the problem y e s [Tue Dec 9 18:44:05 2014] xenoslav: so what /should/ i do [Tue Dec 9 18:44:17 2014] externally define that bit as a lemma? [Tue Dec 9 18:44:29 2014] i feel like that shouldnt be necessary [Tue Dec 9 18:44:38 2014] You can write term by hand [Tue Dec 9 18:44:43 2014] set (an_f := TERM). [Tue Dec 9 18:44:49 2014] instead of doing assert. [Tue Dec 9 18:45:06 2014] Maybe I am wrong, but I imagine that asserts produces term in this shape: [Tue Dec 9 18:45:09 2014] I'm trying to find a way to do a transparent assert, but according to http://comments.gmane.org/gmane.science.mathematics.logic.coq.club/6820, it doesn't seem easily doable [Tue Dec 9 18:45:25 2014] (well, that was in 2011 after all) [Tue Dec 9 18:45:51 2014] ;-; [Tue Dec 9 18:45:53 2014] let asserted_name := [goal from assert] in [rest of the proof]. [Tue Dec 9 18:46:19 2014] which I imagine as (fun asserted_name in [rest of the proof]) ([goal from assert]) [Tue Dec 9 18:46:37 2014] the asserted_name is a variable in [rest of the proof], cannot be ''unfolded''. [Tue Dec 9 18:46:41 2014] So you can use : refine (let an_f' := (_ : B -> A) in _) [Tue Dec 9 18:46:48 2014] I believe it should work? Maybe. [Tue Dec 9 18:46:55 2014] * uses set [Tue Dec 9 18:46:57 2014] how clunky [Tue Dec 9 18:47:17 2014] With refine you can still use tactics to define your term however you wish [Tue Dec 9 18:47:37 2014] hmm [Tue Dec 9 18:49:12 2014] Cypi: your refine has the same issue [Tue Dec 9 18:49:15 2014] Error: Cannot coerce an_f' to an evaluable reference. [Tue Dec 9 18:51:04 2014] Hmm. :( [Tue Dec 9 18:52:29 2014] I think that computational terms should not be constructed by tactics, but it is philosophy, not strong argument. [Tue Dec 9 18:52:46 2014] m e h [Tue Dec 9 18:53:37 2014] Because tactics are designed to build proofs, in most cases you are not interested in the proof-content. For example, if you have Prf1 : A and Prf : A in a context, then you are really not interested which term was choosen by 'assumption' tactic. [Tue Dec 9 18:53:54 2014] But when you are building computational content it is very important. [Tue Dec 9 18:53:57 2014] bwee [Tue Dec 9 18:55:27 2014] For example, when building term of type 'A -> A -> A', by tactics 'intro a; intro b; assumption.', then you do know if you have 'fun a b => a' or 'fun a b => b'. [Tue Dec 9 18:55:54 2014] But it is my taste, not strong argument in discussion where tactics should be allowed. [Tue Dec 9 18:56:54 2014] do not know* [Tue Dec 9 19:05:13 2014] X : forall i : B, {p : A | f p = i} [Tue Dec 9 19:05:13 2014] b : B [Tue Dec 9 19:05:13 2014] ============================ [Tue Dec 9 19:05:13 2014] f (let (p, _) := X b in p) = b [Tue Dec 9 19:05:18 2014] what do x_ [Tue Dec 9 19:05:19 2014] x [Tue Dec 9 19:05:56 2014] ? [Tue Dec 9 19:06:32 2014] how do i proceed [Tue Dec 9 19:06:40 2014] try 'destruct X b' [Tue Dec 9 19:06:54 2014] or 'destruct (X b)', i do not remember syntax. [Tue Dec 9 19:07:06 2014] hrm [Tue Dec 9 19:07:08 2014] cool [Tue Dec 9 19:07:15 2014] Coq is cool. [Tue Dec 9 19:07:17 2014] thanks :) [Tue Dec 9 19:07:27 2014] that should have been obvious >.< [Tue Dec 9 19:07:45 2014] More experience you have, more things are obvious :) [Tue Dec 9 19:09:37 2014] hmm. [Tue Dec 9 19:09:42 2014] i feel like i'm doing something wron [Tue Dec 9 19:10:20 2014] i'm destructing X b twice, but once for the p and once for the f p = i [Tue Dec 9 19:10:21 2014] Did you lost proof 'f p = i' ? [Tue Dec 9 19:10:29 2014] xenoslav: no, the proof worked [Tue Dec 9 19:10:32 2014] but i didnt save it and undid [Tue Dec 9 19:10:37 2014] there has to be a more elegant way [Tue Dec 9 19:10:43 2014] i'm doing [Tue Dec 9 19:10:51 2014] exists (fun i : B => match X i with exist p _ => p end). [Tue Dec 9 19:10:53 2014] then [Tue Dec 9 19:10:57 2014] extensionality b. [Tue Dec 9 19:11:01 2014] and then i end up where i pasted [Tue Dec 9 19:11:23 2014] but see i'm using X in my witness to produce the result and then i'm applying X again for the theorem [Tue Dec 9 19:11:29 2014] i feel like i should only have to do it once! [Tue Dec 9 19:11:30 2014] >.< [Tue Dec 9 19:11:30 2014] Sorry, I cannot now run coq and track your script. [Tue Dec 9 19:12:21 2014] I treat Coq like programming, when I am computing something twice, then I am trying to rewrite code to compute it in one place and give name to the result and then use result. [Tue Dec 9 19:12:43 2014] xenoslav: same [Tue Dec 9 19:12:46 2014] but i cant figure out how -_- [Tue Dec 9 19:12:54 2014] i dont get b until i do extensionality b [Tue Dec 9 19:13:07 2014] Maybe could you try to do 'set (HXb := X b)' at some moment and use HXb instead of X b later. [Tue Dec 9 19:13:15 2014] no, see [Tue Dec 9 19:13:19 2014] I do not know, I cannot run coq now. [Tue Dec 9 19:13:31 2014] i dont get b until i introduce the forall that i get from extensionality [Tue Dec 9 19:13:38 2014] but that's /inside/ the exists [Tue Dec 9 19:13:51 2014] so i need to produce a witness first [Tue Dec 9 19:14:08 2014] ;] [Tue Dec 9 19:14:11 2014] i tried proving the general case thing but i couldnt figure out how [Tue Dec 9 19:14:13 2014] T_T [Tue Dec 9 19:14:20 2014] keep trying :-) [Tue Dec 9 19:14:22 2014] 1 sec [Tue Dec 9 23:06:33 2014] Hey guys, if I have a goal state which is an obvious contradiction, how can I complete the proof? If there's a contradiction in a hypothesis, I can use inversion, but I don't know how to do this in a goal. For example right now I have a goal saying that (x :: l' = []), which is clearly not true. [Tue Dec 9 23:08:09 2014] thinkpad20: to prove a false goal your only hope is to find a contradiction in your hypotheses. [Tue Dec 9 23:08:19 2014] Well, if you have to prove False, but your hypotheses are not inconsistent, you cannot prove it [Tue Dec 9 23:08:27 2014] thinkpad20: yeah that means your theorem is false [Tue Dec 9 23:08:27 2014] (what he said) [Tue Dec 9 23:08:35 2014] Well, I do have a contradiction in my hypothesis, but it's hidden. [Tue Dec 9 23:08:40 2014] thinkpad20: unhide it then [Tue Dec 9 23:09:00 2014] I have a hypothesis stating (rev (x :: l') = []), which is not true. I don't know how to prove this though [Tue Dec 9 23:09:18 2014] You can start with the tactic exfalso, if you know your hypotheses are inconsistent [Tue Dec 9 23:09:19 2014] Doing `inversion H` only gives me a new goal involving `snoc` which is the simplified form of that hypothesis [Tue Dec 9 23:09:57 2014] I'd love to unhide it; perhaps that's how I should have phrased my question :) [Tue Dec 9 23:10:34 2014] Then we need more details about your context, I believe. [Tue Dec 9 23:10:56 2014] thinkpad20: destruct l' and then in both cases you should be able to do inversion on that hypothesis [Tue Dec 9 23:11:35 2014] Well to explain a bit: I'm trying to prove (forall (T: Type) (lst: list T), rev l = [] -> l = []). [Tue Dec 9 23:11:45 2014] sorry l not lst there [Tue Dec 9 23:11:46 2014] anyway [Tue Dec 9 23:11:59 2014] that if a list reversed is empty, then the list itself is empty [Tue Dec 9 23:12:31 2014] my tactics so far: `intros. destruct l as [|x l']. reflexivity.` [Tue Dec 9 23:13:09 2014] Now I have the hypothesis `H: rev (x :: l') = []` and the goal `x :: l' = []`. [Tue Dec 9 23:13:32 2014] And here I'm struggling to go forward [Tue Dec 9 23:13:33 2014] thinkpad20: if you simplify H, you can get a cons as the outer operation [Tue Dec 9 23:13:41 2014] thinkpad20: then you can probably derive False from that [Tue Dec 9 23:13:54 2014] Doing simpl in H gives me `snov (rev l') x = []` [Tue Dec 9 23:13:59 2014] snoc [Tue Dec 9 23:14:07 2014] ooh [Tue Dec 9 23:14:13 2014] /that/ implementation [Tue Dec 9 23:14:20 2014] yeah [Tue Dec 9 23:14:24 2014] this is software foundations [Tue Dec 9 23:14:26 2014] you may need to use induction [Tue Dec 9 23:14:41 2014] although I'm pretty sure no definition of rev would contain a cons operation... that I can see anyway [Tue Dec 9 23:14:57 2014] thinkpad20: if you do a wrapper over an accumulator [Tue Dec 9 23:15:08 2014] oh tail-recursive? yeah true [Tue Dec 9 23:16:15 2014] But this is really just an example of a larger problem I keep running into: I can see intuitively that certain things are impossible, and in a hand-written proof I'd just say "clearly the list must be non-empty, because `snoc _ _` is always a non-empty list" [Tue Dec 9 23:16:31 2014] but there's no such magic wand I can identify in coq [Tue Dec 9 23:16:58 2014] thinkpad20: make a lemma :3 [Tue Dec 9 23:17:07 2014] snoc _ _ is always non empty [Tue Dec 9 23:17:14 2014] then come back to this and apply it [Tue Dec 9 23:17:25 2014] that looks like trivial induction to me [Tue Dec 9 23:17:51 2014] thinkpad20 : in this case, you can destruct, not on l' but on (rev l'). [Tue Dec 9 23:18:17 2014] Cypi: but then what if rev l' is a cons [Tue Dec 9 23:18:29 2014] oh ait [Tue Dec 9 23:18:32 2014] :) [Tue Dec 9 23:18:35 2014] huh, i didnt think of that :D [Tue Dec 9 23:18:38 2014] nice [Tue Dec 9 23:18:53 2014] You just have to force one step of recursion out of snoc [Tue Dec 9 23:19:15 2014] never occurred to me that snoc /directly/ always results in a cons [Tue Dec 9 23:19:20 2014] forgot it wasnt tail recursive [Tue Dec 9 23:19:49 2014] hmm... reverse in terms of snoc is O(sumtorial(n)) isnt it [Tue Dec 9 23:20:22 2014] I didn't know "sumtorial" was an actual word ^^ [Tue Dec 9 23:20:31 2014] that's O(n^2) innit [Tue Dec 9 23:20:34 2014] yes [Tue Dec 9 23:20:39 2014] nasty [Tue Dec 9 23:20:46 2014] Sorry can you tell me where I would destruct rev l'? [Tue Dec 9 23:20:57 2014] thinkpad20: destruct (rev l') in H. i think [Tue Dec 9 23:20:58 2014] It's not a book about optimized functional programming [Tue Dec 9 23:21:04 2014] Cypi: i know :3 [Tue Dec 9 23:21:17 2014] still, O(n^2) for reverse is p fuckin harash [Tue Dec 9 23:21:20 2014] *harsh [Tue Dec 9 23:21:33 2014] Yeah that leads me to `H: snoc [] x = []` which is def not true [Tue Dec 9 23:21:38 2014] thinkpad20 : after solving the first goal, when you have "the hypothesis `H: rev (x :: l') = []` and the goal `x :: l' = []`", try to destruct (rev l') [Tue Dec 9 23:21:57 2014] Now you can use inversion, because the snoc calls will simplify into a cons [Tue Dec 9 23:22:21 2014] Yeah, and this is my inexperience with inversion, but it gives me something more complicated [Tue Dec 9 23:22:33 2014] Oh, does it? [Tue Dec 9 23:22:40 2014] So I have `H: [x] = []` and I do `inversion H`. [Tue Dec 9 23:23:00 2014] Then it should solve this goal and get you to the next one. [Tue Dec 9 23:23:14 2014] (because the [destruct (rev l')] generated two goals) [Tue Dec 9 23:23:18 2014] Ohhh right this is the second case of destruct now [Tue Dec 9 23:23:28 2014] ah, Ok well let me see if I can power through this one... [Tue Dec 9 23:24:11 2014] OK two uses of inversion got it. Ugly as hell but... it's proven, haha [Tue Dec 9 23:24:25 2014] now let me see if I can prove what I really wanted to prove, which is that `rev` is injective... [Tue Dec 9 23:25:03 2014] thinkpad20: heh heh [Wed Dec 10 09:11:47 2014] hey [Wed Dec 10 09:12:07 2014] how can i define Variables in a Section to be Implicit [Wed Dec 10 09:19:00 2014] h-hello? [Wed Dec 10 09:24:10 2014] anyone home? [Wed Dec 10 09:24:13 2014] x.x [Wed Dec 10 09:41:16 2014] Is there a function forall (T:Type), T -> option T -> T in the coq standard lib? [Wed Dec 10 11:29:49 2014] benzrf: [Context {foo : bar}.] [Wed Dec 10 15:52:07 2014] kk [Wed Dec 10 15:52:11 2014] jgross_: thanks :) [Wed Dec 10 15:52:32 2014] can somebody look over this file & critique my choices of definition and proofs https://gist.github.com/benzrf/5da89a781c843a689079 [Wed Dec 10 15:52:46 2014] it's only 57 lines [Wed Dec 10 15:53:09 2014] in particular i feel like the proof of surj_inv is more complicated than need be [Wed Dec 10 15:58:18 2014] your definition of inverse is the definition of a section, really. You need both sides for an inverse. [Wed Dec 10 16:02:55 2014] ianjneu: oh [Wed Dec 10 16:02:59 2014] w-what's a section [Wed Dec 10 16:04:28 2014] Definition Sect A B (f : A -> B) (g : B -> A) := forall b : B, f (g b) =T b. [Wed Dec 10 16:05:39 2014] inverse f g = Sect f g /\ Sect g f. [Wed Dec 10 16:05:43 2014] huh [Wed Dec 10 16:05:57 2014] changfe =T to =. [Wed Dec 10 16:05:59 2014] change* [Wed Dec 10 16:06:15 2014] apart from that, hows my proof of surjective sections [Wed Dec 10 16:07:05 2014] a little circuitous. You can reduce it the way that I posted in the comments. [Wed Dec 10 16:07:24 2014] oh i didnt see there was a comment [Wed Dec 10 16:07:45 2014] what is hnf [Wed Dec 10 16:08:09 2014] head normal form? [Wed Dec 10 16:08:16 2014] head normal form. It unfolds definitions for you if they're the outermost thing. [Wed Dec 10 16:08:26 2014] kk [Wed Dec 10 16:08:44 2014] more future proof than writing unfold function_name everywhere. [Wed Dec 10 16:09:05 2014] but also not a complete replacement since it doesn't go deeper into a term. [Wed Dec 10 16:09:48 2014] ianjneu: i had something like that but more verbose [Wed Dec 10 16:10:02 2014] but it felt weird doing two destructions of S thing [Wed Dec 10 16:10:12 2014] like it could be factored out [Thu Dec 11 00:11:34 2014] how do I [Print] in proofgeneral? [Thu Dec 11 00:15:55 2014] nevermind, it's C-c C-a C-p coq-Print [Thu Dec 11 00:36:39 2014] night [Thu Dec 11 00:37:26 2014] sleep well [Thu Dec 11 22:59:15 2014] hello. I haven't used Coq for some time, and it seems I forgot too much. "proofs can be eliminated only to build proofs": https://gist.github.com/gdsfh/8ef49723e2c137ef4002 (but both [pr] and [prfix] are in Prop) [Thu Dec 11 22:59:49 2014] right [Thu Dec 11 22:59:52 2014] your pr type is in Prop [Thu Dec 11 23:00:05 2014] so you can only match on it if you are building another Prop [Thu Dec 11 23:00:29 2014] but something in your code wants a Type [Thu Dec 11 23:02:51 2014] I showed the code, don't know what part of it wants any Type. Also "Definition prdef (p : pr) : Prop := True." is accepted. [Thu Dec 11 23:04:06 2014] "Definition prfix (p : pr) : Prop. induction p." gives "Error: Cannot find the elimination combinator pr_rect, the elimination of the inductive definition pr on sort Type is probably not allowed.". Maybe it will help to find the source of problem? [Thu Dec 11 23:07:08 2014] can you do on your side: Check True. [Thu Dec 11 23:09:11 2014] gdsfh1 : Prop is in Type, I believe that's the problem. So indeed, your goal is in Type. [Thu Dec 11 23:09:34 2014] For example, if your goal is P where P is some Prop, then you are able to destruct. [Thu Dec 11 23:18:34 2014] ok, thanks, seems I need to reformulate things to avoid this problem. [Fri Dec 12 12:13:31 2014] anyone worked with multisets in Coq? [Fri Dec 12 12:13:40 2014] im looking for the proper union operator [Fri Dec 12 12:13:48 2014] seems like union is actually sum [Fri Dec 12 12:13:57 2014] for example see http://planetmath.org/operationsonmultisets [Fri Dec 12 12:14:15 2014] roosbeef: iirc there's a page on that in software foundations [Fri Dec 12 12:14:20 2014] search for "bag" or "bags" [Fri Dec 12 12:14:46 2014] bag is just another word for multiset, right? [Fri Dec 12 12:14:51 2014] yes [Fri Dec 12 12:14:59 2014] wait, I'll check myself [Fri Dec 12 12:15:15 2014] yes, bag = multiset [Fri Dec 12 12:16:06 2014] roosbeef: Multiset [sum] is similar to set [union]: [sum a b] contains... [Fri Dec 12 12:16:11 2014] see the Lists chapter [Fri Dec 12 12:17:08 2014] Lists are only multisets if you're proper for the permutation equivalence relation, which is a pain to deal with. [Fri Dec 12 12:23:21 2014] nkar is Multiset [sum] defined somewere? [Fri Dec 12 12:23:58 2014] nkar do you have an url for that page in software foundations? I dont know what that is :p [Fri Dec 12 12:24:01 2014] or im not sure if i do [Fri Dec 12 12:24:25 2014] roosbeef: it's a book, just search for the title [Fri Dec 12 12:25:11 2014] and theres a chapter on Lists? [Fri Dec 12 12:25:25 2014] ah my bad i see it now [Fri Dec 12 12:25:29 2014] Definition sum : bag -> bag -> bag := app. [Fri Dec 12 12:26:29 2014] is there a chapter with the answers to those exercises? :p [Fri Dec 12 12:27:06 2014] wait [Fri Dec 12 12:27:11 2014] thats the definition of sum [Fri Dec 12 12:27:31 2014] so my question is, in Coq it seems like union actually implements sum [Fri Dec 12 12:28:11 2014] roosbeef: no idea, sorry [Fri Dec 12 12:28:19 2014] but is there an implementation of "proper" union [Fri Dec 12 12:28:33 2014] ? [Fri Dec 12 12:37:23 2014] think i got it [Fri Dec 12 12:37:25 2014] Definition union_proper (A : Type) (m1 m2 : Multiset.multiset A) : Multiset.multiset A := [Fri Dec 12 12:37:25 2014] Multiset.Bag (fun a:A => Max.max (Multiset.multiplicity m1 a) [Fri Dec 12 12:37:25 2014] (Multiset.multiplicity m1 a)). [Fri Dec 12 12:37:47 2014] that should do what i meant [Fri Dec 12 12:38:12 2014] typo, second m1 should be m2 [Fri Dec 12 12:39:45 2014] {a, a} U {a} = {a, a, a}, not {a, a}. [Fri Dec 12 12:40:09 2014] you want +, not max. Intersection will use min. [Fri Dec 12 12:40:16 2014] That's why he specified "proper" union. [Fri Dec 12 12:40:28 2014] ah [Fri Dec 12 20:17:41 2014] heatsink pasted “LEM with explanation” at http://lpaste.net/116337 [Fri Dec 12 20:18:32 2014] I'm doing the exercises in Software Foundations. I'm having difficulty explaining one of the proofs. [Fri Dec 12 20:18:56 2014] Can someone look at the comments in the theorem I pasted, and tell me if there's a better explanation? [Fri Dec 12 21:20:49 2014] heatsink: An alternative explanation: It is "obvious" that forall A, ~(A /\ ~A). Since ~(P \/ ~P) is equivalent to ~P /\ ~~P (also relatively obvious), we can plug A := ~P into the first theorem, and hence deduce forall P, ~~(P \/ ~P). [Fri Dec 12 21:28:23 2014] Yeh, it's easier to understand after transforming to a conjunction. [Fri Dec 12 21:29:22 2014] I like that proof. [Fri Dec 12 21:40:12 2014] my favorite way of seeing it is [Fri Dec 12 21:40:27 2014] Definition LEM := forall A, A \/ ~A. [Fri Dec 12 21:40:35 2014] then ~LEM -> LEM [Fri Dec 12 21:40:53 2014] so you can trivially use the proof of the above to show that ~LEM -> False [Fri Dec 12 21:40:55 2014] aka ~~LEM [Sat Dec 13 14:24:18 2014] has anyone done the b_times2' exercise in ProofObjects.v for SF? https://github.com/adelbertc/software-foundations/blob/master/ProofObjects.v#L294 struggling with the (2 * n = n + n) part. So far I have [Sat Dec 13 14:24:30 2014] fun (n : nat) => fun (H : beautiful n) => b_sum n n H H [Sat Dec 13 14:24:38 2014] but that gets me beautiful n + n not beautiful (2 * n) [Sat Dec 13 14:26:24 2014] adelbertc: one option is to look at the proof object generated by the tactics. it will be ugly but you will learn something by cleaning it up. [Sat Dec 13 14:28:57 2014] ah interesting [Sat Dec 13 14:28:59 2014] thanks for the tip [Sat Dec 13 14:29:45 2014] adelbertc: if that doesn't help ask again in here [Sat Dec 13 14:30:05 2014] will do [Sat Dec 13 15:31:48 2014] Hi ! [Sat Dec 13 16:16:46 2014] Is there an algo in the stdlib that allow to compute the prime divisors of an integer ? [Sun Dec 14 00:06:33 2014] what differences, if any, are there between Set and Type [Sun Dec 14 00:09:11 2014] universes [Sun Dec 14 00:09:12 2014] or [Sun Dec 14 00:09:13 2014] something [Sun Dec 14 00:09:29 2014] * blinks [Sun Dec 14 07:12:25 2014] I'm stuck on the last part of the Imp.v chapter of SF - would anyone like to help me with it? [Sun Dec 14 07:18:33 2014] http://lpaste.net/116421 this is where I'm stuck [Sun Dec 14 07:19:14 2014] i need to show that ceval is deterministic [Sun Dec 14 07:19:36 2014] but I get an infinite loop when I try to show this for the loop construct [Sun Dec 14 07:20:16 2014] it should be provable because if a loop terminates it only took finitely many iterations, but I haven't been able to explain that to Coq [Sun Dec 14 10:11:12 2014] Hello ! [Sun Dec 14 10:11:37 2014] Is there a good way to "destruct" the congruences of an integer ? [Sun Dec 14 10:12:20 2014] For example, given an integer n, produce 2 subgoals : n is even and n is odd [Sun Dec 14 10:13:23 2014] (This would be for 2, but for 3 it would be : n match (3k) OR n match (3k+1) OR n match (3k+2) ? [Sun Dec 14 10:29:42 2014] Choups314, cut ({Even.even n} + {Even.odd n});[intro C|apply Even.even_odd_dec]. destruct C. [Sun Dec 14 10:33:36 2014] roosbeef: Ho thanks ! I didn't think to this types .. [Sun Dec 14 10:34:37 2014] I tought I had to introduce a new [lemma n_2_cases : forall n, even n \/ ~ even n] and destruct it .. [Sun Dec 14 10:44:34 2014] decidability lemmas are very useful for case analysis [Sun Dec 14 10:51:54 2014] roosbeef: If I want to wrap this in a tactic, which one is better ? (Use {}+{} I guess ?) [Sun Dec 14 10:52:36 2014] haha to tell you the truth, ive never made a custom tactic :p [Sun Dec 14 10:53:16 2014] ok ^^ [Sun Dec 14 10:57:33 2014] {}+{} is needed if you want to eliminate into Set, \/ for Prop (when you just use it to prove things) [Sun Dec 14 11:14:43 2014] http://lpaste.net/116421 could anyone help me with proving determinism of operation semantics please (from SF Imp.v) [Sun Dec 14 11:21:40 2014] vanila: I would suggest induction on one of the execution derivations instead of on c. that's how to explain that the loop terminates to coq. [Sun Dec 14 11:22:37 2014] thank you [Sun Dec 14 11:43:27 2014] If I am in a Section, and do Variable T : Type, is it possible to make T be implicit when the section is closed? [Sun Dec 14 12:09:11 2014] jrw, Thank you so much! I've been completely stuck on that for weeks, finally got it :D [Sun Dec 14 12:09:16 2014] thanks to your hint [Sun Dec 14 12:09:27 2014] vanila: nice. np. [Sun Dec 14 12:33:31 2014] bennofs: i was just asking that the other day [Sun Dec 14 12:33:33 2014] turns out yes!! [Sun Dec 14 12:33:42 2014] benzrf: how? [Sun Dec 14 12:34:03 2014] Context {T : Type}. [Sun Dec 14 12:34:07 2014] instead of Variable [Sun Dec 14 12:35:52 2014] benzrf: :o it works, thanks. I was using Global Arguments : default implicits everywhere, but now I can finally remove that! [Sun Dec 14 12:36:31 2014] thank u based jgross_ [Sun Dec 14 14:40:14 2014] If you just want [: default implicits], you can [Set Implicit Arguments.] [Sun Dec 14 15:07:54 2014] Is it possible to re-export a single identifier from an imported module? [Sun Dec 14 15:08:41 2014] And if yes, how? [Sun Dec 14 15:54:16 2014] bennofs: [Notation foo := Bar.foo.]? [Sun Dec 14 16:19:23 2014] in proof general, is there a way to run the code in the buffer just to the position of the cursor? [Sun Dec 14 16:19:31 2014] other than using C-c C-n to step manually one line by line [Sun Dec 14 16:20:43 2014] darthdeus: proof-assert-until-point-interactive idk what the default binding is for that [Sun Dec 14 16:20:58 2014] C-c C-RET [Sun Dec 14 16:21:06 2014] if you're in terminal C-RET doesnt work, so i remapped mine to C-c C-m [Sun Dec 14 16:21:14 2014] perfect, thanks guys! [Sun Dec 14 16:21:39 2014] C-c C-c C-ombo breaker [Sun Dec 14 16:30:32 2014] is there also a way to go one step back? other than C-c C-u which is undo [Sun Dec 14 16:30:47 2014] like the equivalent to go one expression up and C-c RET [Sun Dec 14 18:22:37 2014] hey guys, is there a way to see what actual functions some notation refers to? For example, if I want to know the "real" function being applied to a and b when I write "a + b"? [Sun Dec 14 18:23:25 2014] You can use: Locate "_ + _". [Sun Dec 14 18:24:52 2014] You can also disable the usage of notations by Coq with [Unset Printing Notations.], and enable it back with [Set Printing Notations.] if you wish so. [Sun Dec 14 18:24:53 2014] Perfect! Thanks a bunch [Sun Dec 14 18:24:57 2014] hey guys, is there a way to do the "andb_eq_orb" proof here https://www.cs.cmu.edu/~emc/15414-s14/assignment/hw2/Basics_w_ans.v without defining the lemmas for each rewrite? [Sun Dec 14 18:25:02 2014] Ah both of those are very useful [Sun Dec 14 18:25:17 2014] I mean isn't there a way to just compute & rewrite the value for that? [Sun Dec 14 18:26:16 2014] in general you can write "assert X" to introduce an anonymous lemma X. The goal state will change to a proof of that lemma. [Sun Dec 14 18:27:50 2014] darthdeus : you can use, in this case, [simpl in H.], and then rewrite with H. [Sun Dec 14 18:28:10 2014] well anonymous is a mistake actually; it just uses a lambda under the hood. What you actually write is "assert (H: some_type)", where some_type is the type of the lemma you want to prove [Sun Dec 14 18:28:40 2014] And then, once "some_type" has been proven, you will have an assumption "H" in your context [Sun Dec 14 18:29:15 2014] http://www.cis.upenn.edu/~bcpierce/sf/current/Induction.html#lab48 [Sun Dec 14 18:29:30 2014] oh perfect [Sun Dec 14 18:29:46 2014] Cypi: simpl in H. works :) thanks [Sun Dec 14 18:29:55 2014] gonna take a look at the assert, seems like that would be more general approach [Mon Dec 15 08:29:00 2014] hello. I just checked out coq from the git repo, and the Makefile.build is wrong, I think. [Mon Dec 15 08:29:34 2014] well, it is built, of course [Mon Dec 15 08:29:38 2014] but it behaves wrong [Mon Dec 15 08:30:46 2014] in the target "install-library", inside "ifeq ($(BEST),opt)", the $(INSTALLBIN) should be $(INSTALLSH) I think. [Mon Dec 15 08:31:02 2014] line 772 [Mon Dec 15 13:19:22 2014] probably a dumb question, but how can I prove "n : nat, n > 0 -> (exists m : nat, n = S m)"? if I try induction I'll get stuck immediately at n = 0, and not sure what else to do [Mon Dec 15 13:36:09 2014] darthdeus: you shouldn't need induction. just destruct n. inversion in the first case, eauto in the second case. [Mon Dec 15 13:37:24 2014] jrw: cool thanks! didn't know about either of those :) [Mon Dec 15 13:37:54 2014] I'm just following Software Foundations and haven't really gotten to existential quantification yet, so wasn't sure how to appraoch it [Mon Dec 15 13:42:20 2014] darthdeus: it might also be a good exercise to do the second case without eauto then. [Mon Dec 15 13:42:38 2014] you can use the [exists foo] tactic to explicitly give the witness foo [Mon Dec 15 13:42:44 2014] jrw: yeah, I'm trying that right now :) [Mon Dec 15 13:42:49 2014] then you'll be asked to prove that the witness satisfies the property [Mon Dec 15 13:43:02 2014] which should be easy in this case if you picked the right witness :) [Mon Dec 15 13:43:49 2014] yeah then it's just reflexivity [Mon Dec 15 13:44:17 2014] though everything still feels a bit like magic [Mon Dec 15 13:48:52 2014] one way to think of exists is that instead of the caller (user of your lemma) passing in the argument, you are passing it locally [Mon Dec 15 14:18:46 2014] hey guys! [Mon Dec 15 14:19:05 2014] hey benzrf! [Mon Dec 15 14:19:12 2014] is there any kind of shorthand for doing the reverse of extensionality? [Mon Dec 15 14:19:34 2014] to be precise, i have a hypothesis f = g and i want to get a hypothesis forall a, f a = g a [Mon Dec 15 14:19:55 2014] i can just do assert (forall a, f a = g a). rewrite H. reflexivity. [Mon Dec 15 14:20:00 2014] but i feel like there could be something similar? [Mon Dec 15 14:20:03 2014] *simpler [Mon Dec 15 14:20:11 2014] check what's in the FunctionalExtensionality module [Mon Dec 15 14:20:20 2014] johnw: that's not extensionality at all though [Mon Dec 15 14:20:24 2014] I'm pretty sure what you need is there [Mon Dec 15 14:20:27 2014] that's not proving equality from extensionality, it's the reverse [Mon Dec 15 14:20:28 2014] oh, ok [Mon Dec 15 14:21:03 2014] "equal_f" [Mon Dec 15 14:21:13 2014] "The converse of functional extensionality" [Mon Dec 15 14:21:20 2014] another question: [Mon Dec 15 14:21:22 2014] https://coq.inria.fr/library/Coq.Logic.FunctionalExtensionality.html [Mon Dec 15 14:21:30 2014] oh [Mon Dec 15 14:21:34 2014] hah [Mon Dec 15 14:21:34 2014] anyway [Mon Dec 15 14:21:44 2014] how does false-from-trivially-false-equality work [Mon Dec 15 14:21:46 2014] what does a proof term look like [Mon Dec 15 14:21:58 2014] print it [Mon Dec 15 14:22:02 2014] huh [Mon Dec 15 14:22:14 2014] Print . [Mon Dec 15 14:24:13 2014] what does return do [Mon Dec 15 14:24:27 2014] never heard of it [Mon Dec 15 14:24:55 2014] im lookin at the proof term and its a hell of a tangle [Mon Dec 15 14:25:06 2014] ohh [Mon Dec 15 14:25:08 2014] *that* return [Mon Dec 15 14:25:17 2014] match return with ... end [Mon Dec 15 14:25:27 2014] determines the type return by match branches [Mon Dec 15 14:25:27 2014] oh [Mon Dec 15 14:25:43 2014] it can be an arbitrarily complex expression [Mon Dec 15 14:25:48 2014] what does in do [Mon Dec 15 14:25:55 2014] H in (_ = y) <- ?? [Mon Dec 15 14:26:02 2014] match H in (_ = y) return (y = 1 -> False) with [Mon Dec 15 14:26:15 2014] you'll have to check the manual, I haven't used it myself [Mon Dec 15 14:27:16 2014] if you want to be using Coq seriously, I recommend sitting down and reading the manual at some point [Mon Dec 15 14:27:57 2014] fug [Mon Dec 15 17:42:13 2014] I need to fold over a list where the type of the list is dependent on the variable I'm mutating over the course of the fold [Mon Dec 15 17:42:57 2014] whoah [Mon Dec 15 17:43:00 2014] thats nuts [Mon Dec 15 17:43:02 2014] :S [Mon Dec 15 17:43:06 2014] i'm wondering if it's even sane [Mon Dec 15 17:43:10 2014] At first I thought this is #haskell and was like [Mon Dec 15 17:43:10 2014] what [Mon Dec 15 17:43:14 2014] how is that even [Mon Dec 15 17:43:33 2014] johnw: whats the use case o: [Mon Dec 15 17:44:39 2014] I have a list of [foo X] elements, and I want, for each elements of [foo X], to mutate X through several generations. I know that each subsequent element of [foo X] will exist within each X', but I'm having a hard time expressing it [Mon Dec 15 17:44:43 2014] benzrf: hard to describe [Mon Dec 15 17:45:10 2014] probably just some heavy transitivity is needed, along with a proof of existence in latter generations [Mon Dec 15 17:45:28 2014] i'll try writing out the type of the fold function [Mon Dec 15 17:48:08 2014] I think something along these lines: [Mon Dec 15 17:48:09 2014] Definition dep_foldl {A : Type} {B : A -> Type} (f : forall b' : A, B b' -> A) (b : A) (v : seq (B b)) : A. [Mon Dec 15 17:48:36 2014] that expresses what I said above [Mon Dec 15 17:49:07 2014] now, can such a thing be written, and what further evidence will it require... [Mon Dec 15 18:11:10 2014] ok, it can be written! needing two helper lemmas to work: https://gist.github.com/4f5a880c8fc16e0e27cd [Mon Dec 15 19:25:05 2014] how can one do topology in coq? [Mon Dec 15 19:25:11 2014] it's so set based [Mon Dec 15 22:40:04 2014] benzrf: You can do classical topology straightforwardly replacing uses of "set" in the textbook with "type" in Coq. Alternatively, you can do homotopy type theory, where each type comes with a natrual topology. [Mon Dec 15 22:40:31 2014] hh [Mon Dec 15 22:40:35 2014] jgross_: subtypes? [Mon Dec 15 22:40:57 2014] { x : T | P x } is the "subtype" of T classified by P [Mon Dec 15 22:41:06 2014] ah ye [Mon Dec 15 22:41:09 2014] *ah yes [Mon Dec 15 22:41:14 2014] sounds clunky :{ [Mon Dec 15 22:41:46 2014] A bit. It's even more clunky if you want to do anything with the reals or with metric spaces. But homotopy type theory isn't clunky! [Mon Dec 15 22:43:09 2014] i dont think im ready for the homotopy :| [Mon Dec 15 22:43:19 2014] i just learned what a homeomorphism is, dude [Mon Dec 15 22:46:45 2014] Part of the beauty of doing math in Coq is that you can use Coq to build your mathematical intuition, and vice-versa. A homotopy isn't that much more complicated than a homeomorphism. Once you know homotopies, and groups (from algebra), homotopy groups are only a small step beyond that. Once you have homotopy groups, that's probably enough to learn basic homotopy type theory (and you might not even need a rigorous understanding of homotopy [Mon Dec 15 22:46:45 2014] groups). [Mon Dec 15 22:47:03 2014] hh [Mon Dec 15 22:47:22 2014] how do product topologies work [Mon Dec 15 22:47:29 2014] hold on let me try figurin it out [Mon Dec 15 22:47:36 2014] i saw the definition of a homotopy somewhere [Mon Dec 15 22:47:41 2014] so... for that to work... [Mon Dec 15 22:48:02 2014] i assume the points are pairs [Mon Dec 15 22:48:11 2014] and the topology is... [Mon Dec 15 22:48:20 2014] i wanna guess... [Mon Dec 15 22:48:55 2014] open iff the set of the first components is open in the first factor and same in the 2nd [Mon Dec 15 22:49:02 2014] ^probably wrong? [Mon Dec 15 23:01:15 2014] benzrf: See if you can prove that equivalent to the formulation given here: http://mathworld.wolfram.com/ProductTopology.html [Tue Dec 16 00:05:38 2014] jgross_: holy shit i think i was right [Tue Dec 16 00:07:28 2014] night [Tue Dec 16 07:47:13 2014] jgross_: Going to back to what you said about math and Coq - I know that I learned a great deal of math as well when I took a course in Coq [Tue Dec 16 09:23:40 2014] wait, shit [Tue Dec 16 09:23:42 2014] no i wasnt right [Tue Dec 16 09:24:04 2014] the definition is the coarsest such that the projections are continuous [Tue Dec 16 09:24:15 2014] i had such that the projections are the /inverse/ of continuous [Tue Dec 16 09:24:27 2014] i.e., open maps to open [Tue Dec 16 09:24:29 2014] fug [Tue Dec 16 10:48:45 2014] forall x y z, (x - (y + z)) = (x - y) - z. [Tue Dec 16 10:48:50 2014] whats the name for this law again? [Tue Dec 16 10:49:59 2014] nm found it NPeano.Nat.sub_add_distr [Tue Dec 16 10:50:59 2014] ah, I wasn't sure whether that would be call distributive or not [Tue Dec 16 13:41:10 2014] hey guys, how can I figure out what is causing the "Error: There are pending proofs" error? [Tue Dec 16 13:44:16 2014] darthdeus: you're trying to compile a file that has some unclosed theorems (no Qed or Defined) [Tue Dec 16 13:45:11 2014] in terms of finding which one, Coq doesn't have anything built in to help. I think jgross's debugging scripts help, but I haven't personally used them. [Tue Dec 16 13:47:01 2014] ianjneu: thanks, found it :) [Tue Dec 16 16:18:29 2014] anyone knows why proof general suddenly (after pressing some combination) automatically submits when i press .? [Tue Dec 16 16:19:15 2014] I haven't been able to track that down yet. I just restart. [Tue Dec 16 16:19:47 2014] Googled. C-c . toggles this [Tue Dec 16 16:20:10 2014] darthdeus: ^ [Tue Dec 16 16:20:54 2014] ianjneu: cool :) [Tue Dec 16 16:20:56 2014] thanks [Tue Dec 16 16:23:32 2014] how does constructive mathematics as in coq handle things like the halting problem [Tue Dec 16 16:24:11 2014] like classically in math u can show the existence of an uncomputable real number by saying "the nth digit is 0 if the nth turing machine halts, and 1 otherwise" [Tue Dec 16 16:24:22 2014] does such a number exist in constructive math/ [Tue Dec 16 16:24:29 2014] benzrf: Assume LEM [Tue Dec 16 16:24:34 2014] hh [Tue Dec 16 16:24:38 2014] gross [Tue Dec 16 16:24:48 2014] benzrf: "fixpoint" recursive functions as definable in coq are required to terminate by their structure [Tue Dec 16 16:24:51 2014] That's classical math for you. [Tue Dec 16 16:25:49 2014] aside from that, i was also wondering more generally [Tue Dec 16 16:26:31 2014] constructive math isn't hamstrung. It's a discipline that means proofs have canonical forms. If you don't care about that, you can admit more axioms if you so choose. [Tue Dec 16 16:26:39 2014] a. is there a such thing as real number that cannot be defined from a computable function (in the sense that its digits are "random" in such a way that you cannot specify it in finite space) [Tue Dec 16 16:26:44 2014] b. if so, how does that work in coq [Tue Dec 16 16:27:09 2014] would that have something to do with aoc [Tue Dec 16 16:28:32 2014] Coq doesn't internally know that its functions are computable. You can't really grasp computability without embedding an entire model. [Tue Dec 16 16:29:01 2014] You also can't go meta and say, "there is no Coq program such that X" [Tue Dec 16 16:31:49 2014] hrgh [Tue Dec 16 16:32:38 2014] ianjneu: point a is about in classical math i guess [Tue Dec 16 16:34:37 2014] benzrf: well if you just say that all Coq programs have an associated natural number that encodes them, you can just reuse the argument that there is no injection from reals to the nats. [Tue Dec 16 16:37:53 2014] argh [Tue Dec 16 16:38:01 2014] ;-; [Tue Dec 16 16:39:13 2014] hmm... so can you prove within coq that `forall (A : Type) (f : Real -> A), ~injective f' [Tue Dec 16 16:39:17 2014] oh wait no that's absurd [Tue Dec 16 16:39:44 2014] itd need to be a mapping from the /classical/ reals to coq terms [Tue Dec 16 16:39:47 2014] not coq reals [Tue Dec 16 16:40:23 2014] hmm, though [Tue Dec 16 16:40:41 2014] ianjneu: if you axiomatized the reals in Coq in a way faithful to the classical ones, could it be possible to prove that [Tue Dec 16 16:40:51 2014] because if so there's an easy inconsistency... [Tue Dec 16 16:45:31 2014] Let Real = nat -> Z with the Cauchy condition : forall eps : Z, eps > 0 -> exists N : nat, forall m n : nat, m > N -> n > N -> abs((seq m) - (seq n)) < eps [Tue Dec 16 16:45:55 2014] where seq : Real [Tue Dec 16 16:48:53 2014] wait [Tue Dec 16 16:48:56 2014] doesnt it need to be nat -> Q [Tue Dec 16 16:49:52 2014] oh right, yup. [Tue Dec 16 16:50:12 2014] Was thinking "rational" but wrote Z. [Tue Dec 16 16:50:19 2014] btw can you do something like [Tue Dec 16 16:51:06 2014] forall (eps, gt) : {n : Q | n > 0} [Tue Dec 16 16:51:21 2014] hmm i guess that's more redundant [Tue Dec 16 16:51:25 2014] technically [Tue Dec 16 16:51:39 2014] just feel as though the constraint should be part of the forall [Tue Dec 16 16:51:41 2014] I don't think you can. [Tue Dec 16 16:52:06 2014] anyway [Tue Dec 16 16:52:06 2014] am I right in thinking that "refinement types" are simply "sig"? [Tue Dec 16 16:52:41 2014] ianjneu: that definition of the reals is not equivalent to the classical definition [Tue Dec 16 16:52:45 2014] johnw: no, refinement types in literature almost always are decidable and don't require explicit proofs. [Tue Dec 16 16:52:46 2014] since they must be computable [Tue Dec 16 16:52:50 2014] so... [Tue Dec 16 16:52:57 2014] wait, hm [Tue Dec 16 16:53:02 2014] ianjneu: ah! thanks [Tue Dec 16 16:53:04 2014] hmmmmmmmmmmmmmmmm [Tue Dec 16 16:53:17 2014] yes, the article I read did keep repeating the word decidable [Tue Dec 16 16:53:21 2014] fuck [Tue Dec 16 16:53:25 2014] language [Tue Dec 16 16:53:28 2014] sry [Tue Dec 16 16:53:28 2014] :{ [Tue Dec 16 16:53:42 2014] benzrf: forget "computable" when thinking within Gallina's logic. [Tue Dec 16 16:53:59 2014] cant you prove that the ordered field with the least upper bound property is unique [Tue Dec 16 16:54:15 2014] so if you can prove that your Real definition is an ordered field with least upper bounds [Tue Dec 16 16:54:23 2014] then [Tue Dec 16 16:54:29 2014] something fishy is going on... [Tue Dec 16 16:54:36 2014] The reals have a countable model. [Tue Dec 16 16:54:43 2014] ?? [Tue Dec 16 16:54:45 2014] ya. [Tue Dec 16 16:55:09 2014] what does that mean [Tue Dec 16 16:55:16 2014] ok wait can we back up for a second [Tue Dec 16 16:55:25 2014] my prior mentioned halting real... is there a name for it? [Tue Dec 16 16:56:40 2014] I don't know what you mean by halting real. [Tue Dec 16 16:57:01 2014] the one whose nth binary digit is defined as whether the nth turing machine halts [Tue Dec 16 16:57:33 2014] I dunno what to call that. [Tue Dec 16 16:57:38 2014] ok let's call it H [Tue Dec 16 16:57:43 2014] so [Tue Dec 16 16:57:53 2014] H is not an element of your Real definition is it? [Tue Dec 16 16:59:38 2014] You would have to translate decimals into partial sum sequences. [Tue Dec 16 16:59:52 2014] but [Tue Dec 16 16:59:59 2014] ugh [Tue Dec 16 17:00:18 2014] ianjneu: the function that generates the partial sums must be a gallina function, right? [Tue Dec 16 17:00:25 2014] 0.123... = 1/10 + 2/100 + 3/1000 + ... [Tue Dec 16 17:00:53 2014] you can define functions using axioms like LEM, but just don't expect to be able to run them. [Tue Dec 16 17:00:58 2014] hmm [Tue Dec 16 17:01:07 2014] ok, let's assume that LEM doesn't apply here [Tue Dec 16 17:01:15 2014] like [Tue Dec 16 17:01:17 2014] we're not using LEM [Tue Dec 16 17:01:23 2014] then there can't be a gallina function that generates partial sums of H, can there? [Tue Dec 16 19:07:58 2014] shit [Tue Dec 16 19:48:39 2014] language :) [Tue Dec 16 19:49:14 2014] johnw do you know these things [Tue Dec 16 19:49:16 2014] ;-; [Tue Dec 16 19:54:34 2014] nope [Tue Dec 16 19:57:01 2014] tfw [Tue Dec 16 20:13:25 2014] is there a way to not clear hypothesis but to hide it? [Tue Dec 16 20:56:36 2014] hi, how can I import a module hiding certain things? like import Foo hiding (foo) in haskell [Tue Dec 16 20:56:50 2014] good question [Tue Dec 16 20:56:53 2014] nkar: no one knows that [Tue Dec 16 20:58:43 2014] context: I want to solve the 99 haskell questions in coq and (maybe) prove certain things on the go. I wanted to import things from the stdlib, does it mean that I need to start from scratch? [Tue Dec 16 20:58:54 2014] assuming that hiding is not possible [Tue Dec 16 21:10:29 2014] nkar: oo thats a good idea [Tue Dec 16 21:11:03 2014] the wiki contributions are licensed under expat, btw [Tue Dec 16 21:18:00 2014] johnw: did I understand correctly that you abandoned sf in favor of adamc's book? if so, why? [Tue Dec 16 21:18:13 2014] no, not abandoned at all [Tue Dec 16 21:18:35 2014] I've been reading everything related to Coq that I can get my hands on [Tue Dec 16 21:30:27 2014] where can I read about literate coq (or whatever it's called)? I'd like to know how to format the comments, so I could generate nice html files (as done in SF). [Tue Dec 16 21:31:41 2014] you mean, coqdoc? [Tue Dec 16 21:31:45 2014] it's in the manual [Tue Dec 16 21:39:16 2014] ah, I didn't know the name, so I couldn't find anything. thanks [Tue Dec 16 21:40:58 2014] the support for it is pretty spartan, although you can escape to LaTeX [Tue Dec 16 21:41:07 2014] i'd look at the way adamc uses it for his book [Tue Dec 16 21:41:32 2014] or you can check out https://github.com/jwiegley/category-theory [Tue Dec 16 21:41:46 2014] tx [Tue Dec 16 22:04:53 2014] coq doesn't have the 'error' function as haskell, so the solutions are to provide a default element or use the option type, right? [Tue Dec 16 22:08:32 2014] yep [Tue Dec 16 22:08:46 2014] or some kind of Either type that reports an error [Tue Dec 16 22:08:51 2014] s/Either/sum [Tue Dec 16 22:19:54 2014] nkar: the error function is used to indicate that a function is partial [Tue Dec 16 22:20:00 2014] I'm aware [Tue Dec 16 22:20:02 2014] nkar: why would you want a partial function in coq?? [Tue Dec 16 22:20:24 2014] he's asking how we make all functions total in Coq [Tue Dec 16 22:20:34 2014] since you can't do it the Haskell way [Tue Dec 16 22:20:51 2014] no no, I wanted to solve the exercise the haskell way, (last is partial in haskell), but I ended up using option [Tue Dec 16 22:20:57 2014] ah [Tue Dec 16 22:21:03 2014] :) [Tue Dec 16 22:23:47 2014] new problems... proofgeneral fails to parse Require Import Coq.Lists.List (only Require Import List is allowed) and it cannot find the list notation, which is in a separate module (Require Import ListNotations) doesn't work. [Tue Dec 16 22:24:26 2014] Module Import LN := ListNotations. [Tue Dec 16 22:25:23 2014] ahem, how does it work? also, don't I need to use the full module names? [Tue Dec 16 22:25:45 2014] Require Import List. [Tue Dec 16 22:25:48 2014] Module Import LN := ListNotations. [Tue Dec 16 22:26:00 2014] that's all i ever do [Tue Dec 16 22:26:21 2014] yeah, it works, thank you. my question was about the LN := ListNotations bit, why is := needed? [Tue Dec 16 22:27:10 2014] you are assigning LN as the imported module name [Tue Dec 16 22:27:18 2014] in this case it's meaningless [Tue Dec 16 22:27:47 2014] well, it's not meaningless because it doesn't work without the assignment. or is it mandatory? [Tue Dec 16 22:28:01 2014] as far as I know it's mandatory, but it doesn't matter what you call it [Tue Dec 16 22:28:06 2014] since you'll never use that prefix [Tue Dec 16 22:28:16 2014] ugly... [Tue Dec 16 22:28:51 2014] meh, the manual is not helpful either. can't decipher it. [Tue Dec 16 22:29:29 2014] johnw: thanks, it would be much more frustrating without your constant guidance [Tue Dec 16 22:29:50 2014] heh, I endured that frustration so that you won't have to :) [Tue Dec 16 22:37:35 2014] I guess after giving Coq 10 minutes to try and process a Program Fixpoint, I should give up... [Tue Dec 16 22:40:33 2014] ... and ask on the mailing list [Tue Dec 16 22:40:59 2014] maybe it's not hopeless and someone suggests a way to speed it up [Tue Dec 16 22:44:49 2014] why am I getting "no interpretation for string "z" on ["x";"y";"z"]? I've tried to import String and Ascii. [Tue Dec 16 22:44:58 2014] Open Scope string_scope. [Tue Dec 16 22:46:03 2014] I need chars, so I imported Ascii and used char_scope instead. is it the right approach? [Tue Dec 16 22:46:12 2014] i've never done it that way [Tue Dec 16 22:50:46 2014] another way to do this is to use "a"%char or "b"%string [Tue Dec 16 22:51:12 2014] now I recall that it's been mentioned in SF [Tue Dec 16 22:54:40 2014] ah, yes [Tue Dec 16 22:54:47 2014] you can always explicitly specify scopes [Tue Dec 16 22:57:46 2014] why can't coq accept myLast [] without an explicit type declaration? I understand that it cannot infer the X in list X, but I'm interested why it needs to know that. [Tue Dec 16 23:05:26 2014] because you're not using myLast [] in a context where it could infer it [Tue Dec 16 23:16:13 2014] is there a predefined alternative to Case? [Tue Dec 16 23:16:35 2014] no [Tue Dec 16 23:16:40 2014] Case is a clever hack [Tue Dec 16 23:17:34 2014] what do people use outside of SF? [Tue Dec 16 23:17:46 2014] i just use bullets and prooftree [Tue Dec 16 23:17:49 2014] i don't bother with Case anymore [Tue Dec 16 23:18:09 2014] well, I still use it if I have an inductive type with a lot of constructors [Tue Dec 16 23:19:20 2014] oh, thanks for telling me about bullets [Tue Dec 16 23:22:03 2014] yeah, very useful [Tue Dec 16 23:22:55 2014] whoa, coq segmentation fault [Tue Dec 16 23:23:22 2014] hehe [Tue Dec 16 23:33:44 2014] johnw: u broke math :( [Tue Dec 16 23:42:37 2014] phew, found a workaround [Wed Dec 17 00:14:46 2014] I cannot find app_comm in the stdlib. is it really missing? [Wed Dec 17 00:21:38 2014] but app is not commutative, lol [Wed Dec 17 00:26:36 2014] just think, you can be the first to prove it :) [Wed Dec 17 00:28:31 2014] haha [Wed Dec 17 00:29:14 2014] I've been up all night, no wonder I can't think straight [Wed Dec 17 00:57:07 2014] how do I tell coq that yt ++ [x] will never be equal to []? [Wed Dec 17 00:59:37 2014] oh, nevermind, I just destructed the whole thing [Wed Dec 17 01:06:28 2014] coq already knows that, and discrimate can establish it [Wed Dec 17 01:06:34 2014] discriminate [Wed Dec 17 01:13:34 2014] johnw: fyi, the links in the README.md file in the category-theory repo don't work [Wed Dec 17 01:17:44 2014] oh, oops [Wed Dec 17 01:17:56 2014] hmm.. they work here [Wed Dec 17 01:18:06 2014] http://ftp.newartisans.com/pub/hasq/Hasq.pdf [Wed Dec 17 01:18:14 2014] oh, maybe they're just not links [Wed Dec 17 01:30:08 2014] coqdoc fails to render 'inversion IHyt. (* contradiction *)\napply IHyt.' properly (where \n denotes a newline). in particular, it shows both tactics on the same line. the workaround is to move the comment to a separate line, but is there a better way? [Wed Dec 17 01:33:06 2014] the Program environment really is quite cool [Wed Dec 17 01:33:30 2014] nkar: I don't know about embedded comments like that, I don't think [Wed Dec 17 01:50:22 2014] I'm also having problems with << and >>. It's supposed to be verbatim, but coqdoc keeps stripping off the newlines. [Wed Dec 17 01:51:47 2014] [[ and ]] do the right thing, but they are for coq. [Wed Dec 17 01:56:43 2014] :( [Wed Dec 17 01:56:48 2014] no no [Wed Dec 17 01:56:52 2014] disregard that [Wed Dec 17 01:56:55 2014] i'd post these all as bugs to the bugzill [Wed Dec 17 01:56:56 2014] a [Wed Dec 17 01:57:43 2014] I needed to move << and >> to the left. turns out it's getting confused by whitespace. [Wed Dec 17 02:25:09 2014] whitespace confuses everyone [Wed Dec 17 02:34:29 2014] pushed the first problem: gitorious.org/99-problems [Wed Dec 17 08:08:51 2014] Hi [Wed Dec 17 08:35:44 2014] hi [Wed Dec 17 08:40:40 2014] nkar: 'morning [Wed Dec 17 08:45:28 2014] is there a way to see what induction hypothesis is being generated in Coq, when I do `induction' tactic? [Wed Dec 17 08:45:45 2014] To be more specific, what is being instantiated to `P' [Wed Dec 17 08:48:36 2014] notdan: when you finish a proof, you can print the proof term and look for *_ind [Wed Dec 17 08:50:12 2014] in terms of what else, I would imagine that P is the rest of the context /after/ the variable inducted on, which then implies the goal. [Wed Dec 17 08:54:53 2014] Yeah, but I can't finish the proof ): [Wed Dec 17 08:55:18 2014] because I don't understand what Coq exactly tries to formulate [Wed Dec 17 08:58:20 2014] notdan: what do you pass an an argument to induction? [Wed Dec 17 09:00:07 2014] Well I just use `induction H', but H is dependent [Wed Dec 17 09:00:26 2014] in the sense that I did `remember x as y in H' before that [Wed Dec 17 09:00:45 2014] ianjneu: hey [Wed Dec 17 09:00:52 2014] ianjneu: my number H from yesterday [Wed Dec 17 09:01:13 2014] ianjneu: it isnt an inhabitant of the type {f : nat -> Q | cauchy f} is it?! [Wed Dec 17 09:01:39 2014] f must be a gallina function and no gallina function can compute H [Wed Dec 17 09:02:02 2014] which would mean that the classical reals include members that the coq reals do not [Wed Dec 17 09:02:03 2014] y/n? [Wed Dec 17 09:05:33 2014] aaaaaaaaaaaaaaaaaaaa [Wed Dec 17 09:05:49 2014] ok, wait i have an idea for a solution to the question i was gonna ask [Wed Dec 17 09:06:20 2014] is anybody with a strong grasp of computability and coq's relationship with classical math?? [Wed Dec 17 09:06:27 2014] *is anybody ... online [Wed Dec 17 09:35:14 2014] ianjneu: I asked johnw about it yesterday, but maybe you know the answer. why is LN required here: [Module Import LN := ListNotations.]? Isn't there a better way? [Wed Dec 17 10:29:43 2014] How can I find everything (every lemma) about a particular type in coq? [Wed Dec 17 10:30:17 2014] Search ? [Wed Dec 17 10:34:31 2014] in coq [Wed Dec 17 10:34:43 2014] how do you do things like prove that an algorithm in a turing-complete language halts [Wed Dec 17 10:37:20 2014] do you say something like [Wed Dec 17 10:37:21 2014] exists n : nat, Halted (iterate runStep n startState) [Wed Dec 17 10:41:21 2014] Anarchos: for some reason it seems to search only in the current file [Wed Dec 17 10:45:54 2014] nkar: I don't know where "here" is, but you can also write Import ListNotations. to get access to the notations. You don't have to locally bind to a different name. [Wed Dec 17 10:46:23 2014] benzrf it is impossible or it would solve the halting problem, which is undecidable [Wed Dec 17 10:46:55 2014] Anarchos: I think benzrf is referring to proving a specific algorithm halts [Wed Dec 17 10:47:13 2014] Is there a way to prove this easier: http://lpaste.net/4056372126016339968 ? [Wed Dec 17 10:47:23 2014] ijp oh sorry [Wed Dec 17 10:48:14 2014] benzrf: the general answer is something like find a property X of a loop that gets "smaller" in some sense every time round the loop [Wed Dec 17 10:49:41 2014] http://adam.chlipala.net/cpdt/html/GeneralRec.html shows one such example for mergesort [Wed Dec 17 10:50:02 2014] oops actally I want to prove a different thing, sorry :S [Wed Dec 17 10:50:54 2014] ianjneu: "here" referred to the code inside []. thanks, the suggested way of importing it is what I've been looking for. [Wed Dec 17 10:51:31 2014] http://lpaste.net/4056372126016339968 [Wed Dec 17 10:51:46 2014] Basically, I want to show that S has to be an empty set in this case [Wed Dec 17 10:51:54 2014] but I am not sure how to do this constructively [Wed Dec 17 10:52:09 2014] because the emptiness property is not decidable [Wed Dec 17 10:52:31 2014] notdan: what imports do I need to make this denote? [Wed Dec 17 10:52:48 2014] Require Import Coq.Sets.Ensembles. [Wed Dec 17 10:52:48 2014] Require Import Coq.Sets.Constructive_sets. [Wed Dec 17 10:52:48 2014] Require Import Coq.Logic.FunctionalExtensionality. [Wed Dec 17 10:53:20 2014] notdan: S can also be the singleton set {y} [Wed Dec 17 11:05:38 2014] notdan: I have a proof. [Wed Dec 17 11:06:13 2014] Use the fact that the equality implies Same_set, and then use Singleton_inv. [Wed Dec 17 11:07:39 2014] ianjneu revised “No title”: “singleton add one” at http://lpaste.net/4056372126016339968 [Wed Dec 17 11:30:35 2014] ianjneu: oh, thanks! [Wed Dec 17 11:30:43 2014] I didn't manage to find Singleton_inv myself [Wed Dec 17 12:11:18 2014] ianjneu please help me ;-; [Wed Dec 17 12:53:10 2014] wuh? [Wed Dec 17 12:53:22 2014] just got back from lunch. [Wed Dec 17 12:55:38 2014] benzrf: ^ [Wed Dec 17 12:58:35 2014] I'm building coq, and it cannot find camlp5o. which envvar do I need to set? [Wed Dec 17 13:02:00 2014] nkar: when configuring, pass --caml5dir [Wed Dec 17 13:10:14 2014] ianjneu: welcome back [Wed Dec 17 13:16:51 2014] johnw: I find it an odd change of pace that I am the person people ask for help with Coq. [Wed Dec 17 13:17:14 2014] Meanwhile, I'm writing a proof by hand in LaTeX. [Wed Dec 17 13:18:07 2014] ianjneu: why is that an odd change of pace? [Wed Dec 17 13:18:35 2014] johnw: I still feel like a nub. [Wed Dec 17 13:19:02 2014] I can't even install ssreflect, let alone write well-automated proofs. [Wed Dec 17 13:19:09 2014] wow, I had the impression that you are far more advanced than I am [Wed Dec 17 13:19:32 2014] I do love ssreflect [Wed Dec 17 13:19:54 2014] if I would just switch over to n.-tuple's, I wouldn't be importing the stdlib at all in my project [Wed Dec 17 13:33:20 2014] johnw: what do you use ssreflect for, if you don't mind me asking? [Wed Dec 17 13:33:29 2014] https://github.com/jwiegley/linearscan [Wed Dec 17 13:33:56 2014] cool [Wed Dec 17 13:42:49 2014] ianjneu: but then it cannot find camlp5.cma, which is /lib [Wed Dec 17 13:49:27 2014] nkar: well that file is supposed to be in the same directory as camlp5 [Wed Dec 17 13:54:03 2014] johnw: do you know what ocamlfind is? (see the 'default.nix' file of coq in nixpkgs) [Wed Dec 17 13:54:55 2014] no [Wed Dec 17 13:57:49 2014] ah, it seems it comes with findlib [Wed Dec 17 14:57:10 2014] Can any ssreflect users here help me to prove the following lemma: subseq (x :: xs) s -> subseq xs s [Wed Dec 17 14:57:30 2014] it seems like it should be a very easy matter of rewriting, but I'm finding great difficulty with this one. There doesn't seem to be much in the SSReflect library to help. [Wed Dec 17 15:03:58 2014] What does "Small Scale Reflection" actually mean? [Wed Dec 17 15:04:41 2014] "The term small-scale reflection, which gives the name to the whole framework of SSReflect, emphasizes the two complementary ways of building proofs: by means of intuitionistic inference (i.e., using the constructors of datatypes defined in Prop) and by means of mere computation (i.e., with bool-returning function). These two ways, therefore, serve as each other’s “reflections” and, moreover, both are implemented within the same system, [Wed Dec 17 15:04:42 2014] without the need to appeal to Coq’s meta-object protocol,1 which makes this reflection small-scale." [Wed Dec 17 15:05:18 2014] oh, thanks [Wed Dec 17 15:05:51 2014] from the excellent book: http://ilyasergey.net/pnp/pnp.pdf [Wed Dec 17 15:07:57 2014] ah, proved it! [Wed Dec 17 15:08:34 2014] always such a good feeling [Wed Dec 17 15:08:48 2014] benzrf: ping [Wed Dec 17 15:24:30 2014] oo coq book [Wed Dec 17 15:24:33 2014] * downloads [Wed Dec 17 15:26:25 2014] johnw: Coq is actually crack for mathematicians, isn't it? [Wed Dec 17 15:26:48 2014] no [Wed Dec 17 15:27:16 2014] it's crack for me, and I'm not a mathematician [Wed Dec 17 15:27:28 2014] i'm a neophyte computer scientist [Wed Dec 17 15:37:41 2014] hmm... The extraction mechanism does not take advantage of let bindings to avoid redundant computations, since Haskell doesn't always do its own common subexpression elimination [Wed Dec 17 15:52:33 2014] how possible is it to extend coq's extraction mechanism to other langs, and if "yes" are there any guides in doing so? [Wed Dec 17 15:52:50 2014] i'm guessing it requires writing OCaml [Wed Dec 17 15:52:55 2014] I haven't come across any guides [Wed Dec 17 15:53:06 2014] i found another bug in the Haskell extractor yesterday [Wed Dec 17 15:53:11 2014] a function was extracted with no body at all [Wed Dec 17 15:53:15 2014] just 'foo = ' [Wed Dec 17 15:53:26 2014] heh [Wed Dec 17 15:53:32 2014] what was the corresponding coq bit [Wed Dec 17 15:53:36 2014] complicated [Wed Dec 17 15:53:47 2014] maybe it just gave up :-P [Wed Dec 17 15:54:04 2014] it should have correctly extracted as foo = id or foo x = x [Wed Dec 17 15:54:21 2014] since the body was not computationally relevant [Wed Dec 17 15:54:26 2014] i suppose its time for me to learn some ocaml [Wed Dec 17 15:54:41 2014] what language are you intending to extract to? [Wed Dec 17 15:55:14 2014] im entertaining the idea of Scala, mostly in the name of "for fun" [Wed Dec 17 15:55:25 2014] im aware one exists, not sure how updated/reliable it is, but id also like to try my hand at it myself [Wed Dec 17 17:29:14 2014] adelbertc: be very interested to hear how that goes :P [Wed Dec 17 17:29:26 2014] I think you're mad... But in a good way. :D [Wed Dec 17 17:32:41 2014] :-) [Wed Dec 17 18:22:10 2014] johnw: is there a way to not clear hypothesis but to hide it? <- [Definition hidden' (T : Type) := T. Notation hidden := (hidden' _). Ltac hide H := idtac; let T := type of H in change (hidden' T) in H.] Not perfect, but almost what you want? [Wed Dec 17 18:23:25 2014] nkar: There is no import hiding. But you can do [Require foo] rather than [Require Import foo], and then you can prefix everything with [foo.]. Alternatively, you can group the things in the file you're importing into their own modules, and then require the file, and import only some of the modules. [Wed Dec 17 18:24:20 2014] johnw: Why [Module Import LN := ListNotations] instead of just [Import ListNotations]? [Wed Dec 17 18:25:51 2014] johnw: a segfault in Coq is usually just the native-compiled version of a stack overflow in the bytecode version. [Wed Dec 17 18:27:31 2014] nkar: report the comment removing newlines in coqdoc as a bug on the bug tracker: https://coq.inria.fr/bugs/enter_bug.cgi [Wed Dec 17 18:31:11 2014] benzrf: You seem to be assuming that there is a single classical set that corresponds to "the Coq reals". There is not. You might find looking into model theory useful here. [Wed Dec 17 18:31:16 2014] jgross_: lack of experience [Wed Dec 17 18:31:32 2014] good to see you again jgross_! [Wed Dec 17 18:32:27 2014] mfw [Wed Dec 17 18:32:37 2014] hey benzrf [Wed Dec 17 18:32:41 2014] sup [Wed Dec 17 18:32:45 2014] johnw: Good to see you, too! I'm probably only going to be around infrequently (and am in fact disappearing momentarily to shower and eat dinner and go square dancing), but if you mention my name, my irc program will highlight it, and I'll notice it. [Wed Dec 17 18:32:47 2014] I got that wicked dependent fold working [Wed Dec 17 18:32:48 2014] jgross_: hmm, well [Wed Dec 17 18:32:53 2014] https://gist.github.com/2dc2bd6e169d5995e2fb [Wed Dec 17 18:32:54 2014] it's almost silly [Wed Dec 17 18:33:04 2014] but it gets the job done [Wed Dec 17 18:33:13 2014] jgross_: doesn't H have a representation in each classical construction of the reals? [Wed Dec 17 18:33:19 2014] but it isnt in the coq one [Wed Dec 17 18:40:22 2014] benzrf: Coq is a syntactic language. You can choose any consistent semantics you want. You can choose to interpret Coq's type of reals into many models. You can choose to give it all of the clasical real numbers (but you won't be able to write them all down in Coq). You can choose to give it a countable model. You can choose to give it stranger models. If you embed Coq's syntax in a metatheory (such as Coq itself+some extra universes), you [Wed Dec 17 18:40:22 2014] can possibly prove that there are inhabitants of the type of real numbers which do not come from any embedded syntactic expression. [Wed Dec 17 18:41:49 2014] hrg [Wed Dec 17 18:42:19 2014] oh man i just realized [Wed Dec 17 18:42:27 2014] you can't prove the least upper bound property in coq can you [Wed Dec 17 18:42:36 2014] at least, not in its standard classical form [Wed Dec 17 23:32:39 2014] jgross_: thanks for the tips [Wed Dec 17 23:32:54 2014] I'll report the bug as you suggested [Thu Dec 18 00:24:37 2014] is there anyone here who has experience of the Haskell extraction mechanism that can help me with what looks like a major problem with extraction of a type class instance? [Thu Dec 18 00:26:36 2014] johnw: I have never seen good extraction of type classes. [Thu Dec 18 00:28:56 2014] I'm getting this extraction: [Thu Dec 18 00:28:56 2014] coq_IState_IMonad :: IMonad.IMonad (IState a1 () () ()) [Thu Dec 18 00:29:06 2014] which means that the actual types I'm using with IState have been erased [Thu Dec 18 00:29:17 2014] and GHC has no reason not to throw away any interactions with those units [Thu Dec 18 00:29:39 2014] and that's indeed what I'm seeing [Thu Dec 18 00:29:58 2014] I'm mutating the state with "put", but then in the next action that action is undone [Thu Dec 18 00:31:15 2014] johnw: if you're state isn't unit then how does your code typecheck against that signature [Thu Dec 18 00:31:41 2014] stbind = IMonad.ijoin (unsafeCoerce IState.coq_IState_IMonad) [Thu Dec 18 00:31:41 2014] (IEndo.imap (unsafeCoerce IState.coq_IState_IFunctor) f (unsafeCoerce x)) [Thu Dec 18 00:32:02 2014] these unsafeCoerces are throwing away my information [Thu Dec 18 00:33:02 2014] yeah, that's in line what I've seen [Thu Dec 18 00:33:06 2014] i'll see if I can fix this in the extracted code [Thu Dec 18 00:33:19 2014] if I replace the units with type variables, and remove the unsafeCoerces, it should work [Thu Dec 18 00:36:27 2014] ugh, this is nasty [Thu Dec 18 00:36:35 2014] there are units everywhere where I need type variables [Thu Dec 18 00:37:36 2014] aha, sure enough [Thu Dec 18 00:37:47 2014] my typeclasses' fmap :: (a -> b) -> f a -> f b in Coq [Thu Dec 18 00:38:00 2014] is turning in the Haskell into (() -> ()) -> f -> f [Thu Dec 18 00:45:21 2014] johnw: how much experience do you have extracting typeclasses. if you get it to work, I'd be really interested to hear about it. [Thu Dec 18 00:45:32 2014] it's not working at all [Thu Dec 18 00:45:40 2014] okay good. glad we're on the same page :D [Thu Dec 18 00:45:40 2014] in fact, it may kill this project, since I use them everywhere [Thu Dec 18 00:45:51 2014] I'll try disabling type optimizations and inlining [Thu Dec 18 00:49:05 2014] nope, did not help [Thu Dec 18 00:49:12 2014] (although I know for a fact that that cures other issues) [Thu Dec 18 00:49:17 2014] (just not with typeclasses) [Thu Dec 18 00:51:12 2014] johnw: maybe you could hack the extractor to extract to a fresh polymorphic variable each time instead of unit? [Thu Dec 18 00:51:19 2014] with the casts it already inserts this might work... [Thu Dec 18 00:51:44 2014] you mean, hack the ocaml code? [Thu Dec 18 00:52:04 2014] johnw: probably, yeah. [Thu Dec 18 00:52:30 2014] or maybe a bunch of custom extraction rules at the coq level for every parameterized type in your codebase. [Thu Dec 18 00:52:59 2014] that doesn't really make sense though. I think you'd have to go to ocaml. [Thu Dec 18 00:57:26 2014] is there an ssreflect repo that work against coq trunk? if so, i could see if anything has improved [Thu Dec 18 00:59:45 2014] hmmm [Thu Dec 18 00:59:50 2014] this is a serious spanner in the works [Thu Dec 18 01:05:36 2014] :( [Thu Dec 18 01:05:55 2014] there is a lower-level layer of my code that uses no type classes [Thu Dec 18 01:06:06 2014] I may have to rewrite the upper layers in Haskell myself, and then use the lower layer from that code [Thu Dec 18 01:06:11 2014] right [Thu Dec 18 01:06:25 2014] to be honest, it would be a relief to do so [Thu Dec 18 01:06:36 2014] the upper layers are becoming too contorted by the dependent typing, too rigid [Thu Dec 18 01:06:55 2014] whereas the lower-level are just data structures, and so very amenable to inductive predicates and proofs [Thu Dec 18 01:07:27 2014] this week I was forced to write a "dependent fold" for the sake of the upper level code that was frankly an abomination [Thu Dec 18 01:07:45 2014] this belongs in a bestiary somewhere: https://gist.github.com/00be21b45348f9eb34e3 [Thu Dec 18 01:27:07 2014] oof [Thu Dec 18 06:04:13 2014] hello. just starting to read cpdt, and on page 20 it sais: [Thu Dec 18 06:04:17 2014] The important metatheorems [Thu Dec 18 06:04:20 2014] about CIC have not been extended to the full breadth of the features that go beyond the [Thu Dec 18 06:04:22 2014] formalized language, but most Coq users do not seem to lose much sleep over this omission. [Thu Dec 18 06:04:31 2014] - what exactly does that mean? [Thu Dec 18 06:04:50 2014] what are those extensions? [Thu Dec 18 09:20:35 2014] does the notion of provability mean anything in coq [Thu Dec 18 09:20:36 2014] how does it work [Thu Dec 18 09:20:55 2014] not seeing you in #agda benzrf [Thu Dec 18 09:21:00 2014] i dont use agda [Thu Dec 18 09:21:11 2014] oh that reminds me actually [Thu Dec 18 09:21:31 2014] there are proofs that things are unprovable [Thu Dec 18 09:21:40 2014] but you're still in the realm of certainty [Thu Dec 18 09:21:49 2014] could there be a such thing as an infinite chain of [Thu Dec 18 09:22:06 2014] …of? [Thu Dec 18 09:22:16 2014] X is unprovable and you cannot prove that X is unprovable and you cannot prove that ThAT is unprovable, etc [Thu Dec 18 09:22:33 2014] i guess that's not really a well defined notion [Thu Dec 18 09:22:41 2014] "X is un provable" >> so...you've proved hat X is unprovable, right? [Thu Dec 18 09:22:48 2014] Cypi: what i was about to say :| [Thu Dec 18 09:23:05 2014] i guess i still have classical notions of inherent truth value in my brain [Thu Dec 18 09:23:11 2014] :-/ [Thu Dec 18 09:23:26 2014] (X → ⊥) so (X → ⊥) → ⊥ and so on…? [Thu Dec 18 09:24:14 2014] s/so/and/ [Thu Dec 18 09:24:18 2014] afk [Thu Dec 18 09:26:19 2014] hmm what is Tor [Thu Dec 18 09:26:22 2014] wait shit [Thu Dec 18 09:26:26 2014] i got thoughts and typings confused [Thu Dec 18 09:26:29 2014] what is Parameter? [Thu Dec 18 10:04:40 2014] Fuuzetsu: (X -> bot) -> bot is a monad, so it doesn't get bigger than that. [Thu Dec 18 10:06:50 2014] it can, you can just join it ;P [Thu Dec 18 19:44:42 2014] is there a way to search for a theorem that would match an expression? [Thu Dec 18 19:44:57 2014] for example if I know I have one I could apply, but don't remember its name [Thu Dec 18 19:54:47 2014] SearchIsos? [Thu Dec 18 19:54:57 2014] C-c C-a C-o [Thu Dec 18 19:55:37 2014] (in PG) [Thu Dec 18 20:08:23 2014] cool, thanks :) [Thu Dec 18 20:21:02 2014] hmm this is weird, i'm not getting any results in the *response* buffer, but if it doesn't find anything it does show an error [Thu Dec 18 20:54:57 2014] johnw: any progress with extraction? not that I can help, just interested in problem I may run into myself at some point. [Thu Dec 18 20:55:11 2014] problems* [Thu Dec 18 22:41:01 2014] nkar: it wasn't the bug I thought it was [Thu Dec 18 22:41:07 2014] the extracted code actually worked as advertised on the box [Thu Dec 18 22:44:44 2014] johnw: getting a little offtopic, why did you pick coq for linearscan, not idris? just because coq's not as actively worked on? [Thu Dec 18 22:44:55 2014] idris was too immature, frankly [Thu Dec 18 22:45:06 2014] Coq has the sound metatheory I was looking for, too [Thu Dec 18 22:45:18 2014] I would like to see Idris used more in future [Thu Dec 18 23:35:58 2014] Idris is immature? [Thu Dec 18 23:36:09 2014] I've never used it, but it's on my list of things to look at [Thu Dec 18 23:42:58 2014] compared to Coq, yes [Thu Dec 18 23:43:06 2014] for the most part, Coq is a tank [Thu Dec 18 23:43:28 2014] my experiments with Idris left me feeling otherwise; but I intend to use it more as time goes on [Thu Dec 18 23:51:05 2014] yeah, Coq definitely feels like a tank of sorts, but my knowledge in this area is pretty limited [Thu Dec 18 23:53:08 2014] i played around with idris a few days ago, was lots of fun, but didnt feel as refined as coq. granted coq's been around for much longer than idris [Fri Dec 19 00:30:29 2014] is it possible to use custom notation with tactics? e.g., can I do unfold <-> (unfold iff works fine)? [Fri Dec 19 00:34:59 2014] okay, unfold "<->" does the trick. [Fri Dec 19 01:47:20 2014] could anyone suggest a theorem to test my inductive definition of True? [Fri Dec 19 02:55:53 2014] what is your definition [Fri Dec 19 02:59:57 2014] dbelange: I'm not sure how to define it, so I tried various definitions. This is an exercise from Software Foundations, and I'd like to solve it on my own. I gathred I could use a theorem to check whether any of the definitions I made make sense. [Fri Dec 19 03:00:55 2014] The only hint that the book provides is that it's trivial to give evidence for True. [Fri Dec 19 03:10:17 2014] you should be able to give evidence for True with nothing in the context [Fri Dec 19 03:11:15 2014] thanks for the hint, I'll try again later. [Fri Dec 19 03:11:23 2014] what chapter is this? [Fri Dec 19 03:11:31 2014] Logic [Fri Dec 19 03:11:39 2014] Search for "Truth" [Fri Dec 19 03:12:16 2014] ah found it [Fri Dec 19 03:13:11 2014] Turing machines are models of computation without interruptions. Are there modifications of Turing machines who could model computation with interruptions ? [Fri Dec 19 10:57:42 2014] make install ====> /bin/sh: ./install.sh: Argument too big [Fri Dec 19 13:50:06 2014] is there a lemma for transforming a+1 and 1+a into S a? [Fri Dec 19 13:50:27 2014] ah sorry, I meant "a + S b -> S (a + b)" [Fri Dec 19 13:50:36 2014] I already have the first one [Fri Dec 19 13:51:04 2014] i'm not really sure how to look for there things or where to find them [Fri Dec 19 13:52:12 2014] darthdeus: induce on a, i think [Fri Dec 19 13:52:22 2014] oh wait [Fri Dec 19 13:52:23 2014] nvm [Fri Dec 19 13:52:30 2014] that follows from the definition of "+" [Fri Dec 19 13:52:33 2014] just use simpl [Fri Dec 19 13:53:10 2014] johnw: simpl isn't working in my case [Fri Dec 19 13:53:20 2014] johnw: no it doesnt [Fri Dec 19 13:53:23 2014] S a + b, maybe [Fri Dec 19 13:53:57 2014] yeah but my expression has a + S b in it :P [Fri Dec 19 13:54:36 2014] oh wait, I could use plus_comm [Fri Dec 19 13:54:58 2014] though can I somehow apply that to just a part of an expression? like if I have a <= a + S b, and I'd like to apply plus_comm on the (a + S b) [Fri Dec 19 13:55:14 2014] ah [Fri Dec 19 13:55:18 2014] plus_n_Sm is what I was thinking of [Fri Dec 19 13:55:22 2014] plus_n_Sm forall n m : nat, S (n + m) = n + S m [Fri Dec 19 13:56:21 2014] johnw: yes, that one is perfect! [Fri Dec 19 13:56:26 2014] now I just need a way to apply it, hmm [Fri Dec 19 13:56:30 2014] rewrite plus_n_Sm [Fri Dec 19 13:56:41 2014] or rewrite <- plus_n_Sm [Fri Dec 19 13:57:34 2014] ahh, right [Fri Dec 19 13:57:37 2014] thanks [Sat Dec 20 10:22:15 2014] what does stuff like foo%functor mean? [Sat Dec 20 10:22:30 2014] syntax wise [Sat Dec 20 10:24:11 2014] % says which scope a particular term uses for its syntax [Sat Dec 20 10:24:47 2014] ok, thanks [Sat Dec 20 15:15:27 2014] OK, I decided to bite it, and finally read the Chlipala's book [Sat Dec 20 15:15:37 2014] at least like half of it [Sat Dec 20 15:15:39 2014] over the holidays [Sat Dec 20 15:15:45 2014] nice! [Sat Dec 20 15:15:54 2014] I'm on my second reading now, going through more carefully this time [Sat Dec 20 15:17:13 2014] ok, I'll ask you questions then, johnw ;) [Sat Dec 20 15:18:48 2014] shoot [Sat Dec 20 22:44:31 2014] can i prove that 2 types are equal [Sat Dec 20 22:44:39 2014] like [Sat Dec 20 22:45:35 2014] can i prove that {x : nat | x % 10 = 21 % 10} = {x : nat | x % 10 = 31 % 10} [Sat Dec 20 22:45:45 2014] is that what HoTT does [Sun Dec 21 01:35:01 2014] if I have a theorem like this: [forall P Q : Prop, P -> Q], how should I call (in English) the [intros P] step when doing an informal proof? [Sun Dec 21 01:36:38 2014] if [P] is an equality, I usually say something like "assuming that P holds," but it's not going to work when [P] is, well, [P]. [Sun Dec 21 01:39:09 2014] this theorem looks false. What do you mean by "informal proof" [Sun Dec 21 01:41:30 2014] dbelange: informal == in english. that's how the term is used in the software foundations book. sorry for the sloppy example. here's a better one: [Theorem double_neg : forall P : Prop, P -> ~~P.] [Sun Dec 21 01:41:55 2014] (I didn't have to prove much when I was in school, so informal proofs are usually harder for me than formal ones because I always need to think whether the words I'm using make sense in the given context.) [Sun Dec 21 01:41:55 2014] [Sun Dec 21 01:43:31 2014] the coq proof: [intros P H. unfold not. intros G. apply G. apply H. Qed.] [Sun Dec 21 01:44:42 2014] I understand what's going on here, but to explain that we're working backwards I need to reference the P hypothesis somehow, and I don't know how to call the intros step. [Sun Dec 21 01:46:16 2014] (by backwards I mean the apply G step. we first match on the result) [Sun Dec 21 01:47:08 2014] that's in the logic chapter of the book, btw [Sun Dec 21 01:48:56 2014] nkar: maybe you want to think about "evidence semantics" [Sun Dec 21 01:49:51 2014] suppose you have evidence of P. Produce a function that behaves as: [Sun Dec 21 01:50:12 2014] INPUT: any function which maps evidence of P to a contradiction. OUTPUT: a contradiction [Sun Dec 21 01:50:46 2014] what's evidence semantics? [Sun Dec 21 01:51:19 2014] sometimes called BHK semantics, as far as I know it's the usual "informal" way of thinking of these things. Your book may differ [Sun Dec 21 01:53:03 2014] the web search shows some papers, but nothing introductory, it seems [Sun Dec 21 01:53:11 2014] what does BHK mean? [Sun Dec 21 01:53:34 2014] brouwer-heyting-kolmogorov, three dudes' names [Sun Dec 21 01:54:08 2014] anyway, this is how the actual coq proof is structured [Sun Dec 21 01:54:34 2014] ~P is like having a function which maps elements of P to false [Sun Dec 21 01:54:40 2014] ~~P is like having a function which maps those functions to false [Sun Dec 21 01:55:18 2014] if you already have p:P, you can get a function of type ~~P [Sun Dec 21 01:55:36 2014] by mapping any function f of type ~P to f(p) [Sun Dec 21 01:56:50 2014] I need to take a nap; get back in ~20 minutes [Sun Dec 21 01:56:59 2014] I guess you could write this as "lambda p:P.lambda f:~P.fp" [Sun Dec 21 02:26:29 2014] sure, but it doesn't show the steps involved. [Sun Dec 21 02:26:50 2014] I could prove it in coq as [intros P H. unfold not. intros G. apply G in H. apply H. Qed.] and would expect to see a different informal proof. [Sun Dec 21 02:29:05 2014] if you look at other informal proofs in the book, they're more focused on the thing I mentioned. [Sun Dec 21 02:32:19 2014] here's what I've written, but I'm not satisfied because it doesn't convey the idea behind the [apply G] step: By the definition of [~], [~~P] can be expanded to (P -> False) -> False We need to show that [False] follows from [P -> False], which requires only [P], which is trivial due to the definition of the theorem. [Sun Dec 21 02:32:29 2014] the last part of the last sentence could use some work too [Sun Dec 21 09:36:44 2014] Hello, have anyone already used dpgraph ? [Sun Dec 21 12:24:13 2014] can i prove that {x : nat | x % 10 = 21 % 10} = {x : nat | x % 10 = 31 % 10} [Sun Dec 21 13:37:58 2014] I’m not convinced that’s a true statement. A proof that x % 10 = 21 % 10 is probably not equal to a proof that x % 10 = 31 % 10, right? [Sun Dec 21 13:45:04 2014] alkabetz: well they certainly imply each other [Sun Dec 21 13:45:22 2014] alkabetz: the set of actual inhabitants is the same even if the proofs aren't equal [Sun Dec 21 13:45:40 2014] to be precise im trying to find a way of implementing quotient types :i [Sun Dec 21 13:53:33 2014] Choups314: Do you mean dpdgraph (https://anne.pacalet.fr/dev/dpdgraph/)? [Sun Dec 21 13:57:30 2014] benzrf: Does [reflexivity] prove [21 % 10 = 31 % 10]? If yes, then [reflexivity] will also prove [{x : nat | x % 10 = 21 % 10} = {x : nat | x % 10 = 31 % 10}]. In any case, if you want quotients, read http://homotopytypetheory.org/2011/04/23/running-circles-around-in-your-proof-assistant/ and look at http://hott.github.io/HoTT/proviola-html/HoTT.hit.quotient.html [Sun Dec 21 16:15:58 2014] johnw: https://github.com/jwiegley/software-foundations doesn't work for me anymore. did you kill it? [Sun Dec 21 17:43:56 2014] jgross_: god dammit i KNEW this was a HoTT thing [Sun Dec 21 17:44:50 2014] jgross_: what area of mathematics would hott be considered part of [Sun Dec 21 17:50:43 2014] it's the other way round: all mathematics is part of the magical hott foundations [Sun Dec 21 17:52:42 2014] :^) [Sun Dec 21 19:41:06 2014] hey guys, I'm curious about the assertion here https://github.com/moritanon/Coq_study/blob/master/MoreLogic.v#L63 ... isn't that basically duplicating the initial hypothesis just to apply inversion? [Sun Dec 21 20:05:02 2014] also an unrelated question, why can I use intros on inequality? like if I have "n <> 0", I can do "intros foo" and it will work and extract a negated form as a hypothesis [Sun Dec 21 20:05:20 2014] that doesn't look like the initial hypothesis [Sun Dec 21 20:05:24 2014] it looks like excluded middle [Sun Dec 21 20:06:21 2014] ABout inequality, [a <> b] is just [~ (a = b)], which is just [(a = b) -> False] [Sun Dec 21 20:06:41 2014] Cypi: oh that makes sense, thanks :) [Sun Dec 21 20:07:05 2014] dbelange: yeah, excluded_middle is the initial hypothesis [Sun Dec 21 20:11:17 2014] darthdeus_: the initial assumption is universally quantified, and this is a specific instance of it [Sun Dec 21 20:11:42 2014] dbelange: that I understand, but does it really have to duplicate the whole body in the assertion? [Sun Dec 21 20:11:53 2014] isnt' there a tactic that just "removes" the universal quantifier? [Sun Dec 21 20:12:31 2014] i mean if I copy paste the assumption without a quantifier, and then just use "apply" to prove it, it can't really go wrong [Sun Dec 21 20:15:07 2014] You're right, you can just do something like [pose proof (H (P x)).] for example [Sun Dec 21 20:18:30 2014] Cypi: perfect, thanks [Sun Dec 21 20:36:02 2014] excluded middle can b used to write a surjection from the cantor space to the reals as a regular coq function right [Sun Dec 21 20:36:45 2014] i'm thinking it's pretty trivial to write a computable surjection from the cantor space to the reals that is undefined at only 1 point [Sun Dec 21 20:36:59 2014] so then you can apply LEM to check whether the input is equal to that one point [Sun Dec 21 20:37:02 2014] and proceed [Sun Dec 21 23:32:58 2014] does coq have something like [1..5] in haskell? [Sun Dec 21 23:38:20 2014] nkar: im sure u can implement it [Sun Dec 21 23:39:42 2014] benzrf: hi! oh, I'd rather not do it right now. I just wanted to translate a haskell example to coq, but the .. notation is not the point. [Sun Dec 21 23:41:33 2014] kk [Sun Dec 21 23:43:04 2014] is there a ble_nat [Sun Dec 21 23:50:47 2014] do I understand correctly that it's possible to combine patterns inside the match statement if they should result in the same thing? e.g., match xs with | nil | _::nil => None | x::_::nil => Some x | _::xt => myButLast xt [Sun Dec 21 23:51:32 2014] nkar: hmm? [Sun Dec 21 23:51:41 2014] whats bein combined here? [Sun Dec 21 23:51:52 2014] the first two patterns [Sun Dec 21 23:52:02 2014] oh [Sun Dec 21 23:52:05 2014] idk :| [Sun Dec 21 23:52:06 2014] I omitted a None after the first nil [Sun Dec 21 23:52:13 2014] fallthru [Sun Dec 21 23:52:47 2014] well, I proved some theorems about myButLast, so I'm pretty sure it holds [Mon Dec 22 00:06:40 2014] yay my shitty quotient works [Mon Dec 22 04:27:01 2014] Hi, I fail building coq 8.4pl5 on archlinux with ocaml 4.02.1, but it says that tools/compat5.mlp and my pervasives.cmi make inconsistent assumptions: http://pastebin.com/Z1caqDNX [Mon Dec 22 04:27:14 2014] Do you have any advice how to fix this? [Mon Dec 22 04:36:11 2014] (and the git version ends in some more horrible error: DynLoader.Error ("/usr/lib/ocaml/unix.cma", "interface mismatch on String") -- so the git version does not seem to be an option...) [Mon Dec 22 07:09:59 2014] it seems i can get past that point on my other laptop. (also archlinux with ocaml 4.02.1), and I can't tell the difference [Mon Dec 22 07:59:49 2014] as it turns out, broken arch packages caused that trouble. downgrading the ocaml and the libabl-gtk2-package to the version a month ago made it work. [Mon Dec 22 09:57:23 2014] thorsten1: That sounds like you still have some files compiled with your old ocaml / gtk2 packages; `make` will not notice that you upgraded things, and thus need to recompile. Did you try (a) make clean, (b) make distclean, or (c) getting a fresh copy of the sources and building from there? (Feel free to skip (a).) [Mon Dec 22 09:58:02 2014] I always retried it with fresh sources. [Mon Dec 22 09:58:21 2014] and as written above, the problem seems to be with the distro-packages for ocaml [Mon Dec 22 09:59:34 2014] but independently: how can i define something temporarily within a proof? [Mon Dec 22 10:00:06 2014] (i.e. the tactics-equivalence for let...in...) [Mon Dec 22 10:08:13 2014] the pose-tactic seems to work. [Mon Dec 22 10:15:49 2014] Yes, [pose (proof-term) as hyp-name] works. So does [refine (let hyp-name := proof-term in _]. If you're using trunk, you can do [refine (let hyp-name := _ in _)] and then define the body with tactics. If you don't want the body available, you can do [assert (H : type)], [assert (H : type) by tactics], or [assert (H := proof-term)]. [Mon Dec 22 11:12:44 2014] how can I tell the "Eval compute in.." (or any other evaluation) to unfold tactic-proven theorems? [Mon Dec 22 11:19:08 2014] minimal-non-working example: http://pastebin.com/WGxwjCYS [Mon Dec 22 12:22:47 2014] can i pls have the axiom of choice [Mon Dec 22 12:23:08 2014] *snerk* [Mon Dec 22 12:23:59 2014] [was a joek] [Mon Dec 22 12:24:14 2014] to be precise i just did [Mon Dec 22 12:24:15 2014] Definition quot (T : Type) (R : T -> T -> Prop) := {Q : Type | exists d : T, Q = {x : T | R x d}}. [Mon Dec 22 12:24:29 2014] now if i could only aoc i could have a type inhabited by actual Ts !! [Mon Dec 22 15:06:28 2014] nkar: hi [Mon Dec 22 15:07:45 2014] hey [Mon Dec 22 15:08:57 2014] nkar: so, it was pointed out to me by an instructor of a class on Software Foundations, that the authors of the course wish that answers not be posted online [Mon Dec 22 15:09:18 2014] many of this instructors students were copying from my solutions, which made it more difficult for him to teach effectively [Mon Dec 22 15:09:26 2014] so I agreed to take down the repo [Mon Dec 22 15:22:56 2014] johnw: too bad... I (and others, I'm pretty sure) been learning by reading them, as I said previously. also, if some student cheats this way, you can easily find out by asking them to explain what the code is doing. if they cheated but can explain, I don't see a problem, they learned the material. so I'll keep publishing my solutions. [Mon Dec 22 15:23:22 2014] I'm happying to e-mail you a copy, nkar [Mon Dec 22 15:24:47 2014] nkar: it's actually the wish of the Software Foundations authors that they not be published: https://gist.github.com/8e4824bbf4204e09d949 [Mon Dec 22 15:28:48 2014] johnw: that's regrettable, since github does not offer private repos on the free tier account [Mon Dec 22 15:35:05 2014] it's hard because there are multiple audiences for this material [Mon Dec 22 15:35:20 2014] and a frustrated student with a deadline is unlikely to worsen his grade by not looking [Mon Dec 22 15:35:42 2014] johnw: that's not just about me. if I get a copy, I'll be faced with a moral dilemma: deny access to education to those who don't have the privilege to study in an ivy league school; or publish the solutions but look like a jerk in your eyes. so I don't want to have a copy that I won't be able to share, sorry. [Mon Dec 22 15:36:32 2014] fair enough [Mon Dec 22 15:36:54 2014] some of the theorems are in the standard library, should we take it down, too? [Mon Dec 22 15:37:01 2014] I figure if I'm benefiting from all the work the authors of SF put into it, then I'm going to respect their wishes [Mon Dec 22 15:37:36 2014] I hope the standard library is written in a more efficient style :p [Mon Dec 22 15:38:12 2014] don't get me wrong, I'm grateful to them, but I think this doesn't solve the cause of the problem, just the side effects. [Mon Dec 22 15:38:34 2014] right, the cause is inherently difficult to solve, unfortunately [Mon Dec 22 15:39:03 2014] Redirect more people to #coq, that's the right thing to do :p [Mon Dec 22 15:44:17 2014] :-( [Mon Dec 22 15:45:19 2014] I wonder whether exercise solutions are "derivative works" in the eyes of copyright law? I don't see a license on the web published version of SF, which I believe means the authors aren't granting any particular permission to publish derivative works [Mon Dec 22 15:50:28 2014] ystael: if you wget the page, you'll get the license. it's available. [Mon Dec 22 15:52:56 2014] nkar: what page? i don't see it in the source of http://www.cis.upenn.edu/~bcpierce/sf/current/index.html nor toc.html [Mon Dec 22 15:53:11 2014] recursively, I mean [Mon Dec 22 15:53:17 2014] wait, I'll show you the link [Mon Dec 22 15:53:49 2014] http://www.cis.upenn.edu/~bcpierce/sf/current/LICENSE [Mon Dec 22 15:54:16 2014] sounds like a very open, BSD-type license [Mon Dec 22 15:54:34 2014] so legally, one is doing nothing wrong in posting their answers [Mon Dec 22 15:54:52 2014] I'm surprised they don't express their wishes in the LICENSE document [Mon Dec 22 15:54:58 2014] i should mention this to Dr. Pierce [Mon Dec 22 15:55:14 2014] its best that they don't [Mon Dec 22 15:55:17 2014] oh, please don't [Mon Dec 22 15:55:19 2014] why? [Mon Dec 22 15:55:22 2014] Maybe they didn't expect so many people to publish their solutions at the time, or they don't want to enforce it legally [Mon Dec 22 15:55:30 2014] they should just ask it, not out it in the liscence [Mon Dec 22 15:55:34 2014] i didn't mean mention it as a legal restriction [Mon Dec 22 15:55:55 2014] just "and we while we ask that solutions not be posted, no restrictions are made on the use of derivative works" kindo f thing [Mon Dec 22 15:56:07 2014] just to make it clear [Mon Dec 22 15:56:07 2014] or they could, you know, say so anywhere in the text of the book [Mon Dec 22 15:56:11 2014] true [Mon Dec 22 15:56:20 2014] it's odd that it only appears in the "instructor's version" [Mon Dec 22 15:56:29 2014] johnw: ah, but even then it'll make the situation unclear. [Mon Dec 22 15:56:38 2014] I think that teachers should come to a different solution [Mon Dec 22 15:56:59 2014] I should embed a time-bomb in my solutions so that it screams "CHEATER" when submitted [Mon Dec 22 15:57:09 2014] lol [Mon Dec 22 15:57:19 2014] lol [Mon Dec 22 15:57:42 2014] i have a idea: [Mon Dec 22 15:57:51 2014] wait nvm [Mon Dec 22 15:57:57 2014] lol [Mon Dec 22 15:58:04 2014] don't minding is a good idea [Mon Dec 22 15:58:15 2014] not minding* probably [Mon Dec 22 18:23:03 2014] hi i'm beginning with Coq and i can#t figure out what's wrong in the following simple definition of even: http://lpaste.net/117042 [Mon Dec 22 18:25:41 2014] It just works here :x [Mon Dec 22 18:26:44 2014] hmm, weird [Mon Dec 22 18:26:57 2014] that looks like it should work [Mon Dec 22 18:27:57 2014] weird, i closed the ide and reopened it and now everything is fine.. [Mon Dec 22 18:29:56 2014] but thanks for trying [Mon Dec 22 18:30:19 2014] heh [Mon Dec 22 19:36:31 2014] Hi, I have a function f returning an option nat (Some n or None) and g : nat -> Prop. I'd like to define the lemma corresponding to match f x with | Some a => g(a) |None => True [Mon Dec 22 19:36:55 2014] but I'm not sure that this match with in my lemma is a good idea [Mon Dec 22 19:37:28 2014] I'm trying to replace it by something like f x <> None => g ... [Mon Dec 22 19:37:35 2014] it's not ideal but I think it's ok - you could try going with it a bit and if its tricky refactor [Mon Dec 22 19:37:55 2014] but I'm stuck because I don't know how to extract the int inside the Some without a match [Mon Dec 22 19:37:56 2014] you can certainly have a function forall o : option nat, o <> None -> nat [Mon Dec 22 19:38:08 2014] if you construct that, then use it you could write your lemma in that form [Mon Dec 22 19:38:32 2014] yeah, ok [Mon Dec 22 19:38:33 2014] thanks ! [Mon Dec 22 20:38:53 2014] Ok, I'm doing the proof. I have an hypothesis H0 : None = Some n [Mon Dec 22 20:39:04 2014] I would like to derive absurdity from that [Mon Dec 22 20:39:16 2014] discriminate [Mon Dec 22 20:39:29 2014] Oh. [Mon Dec 22 20:39:31 2014] now, you can also do it manually [Mon Dec 22 20:39:33 2014] Thanks a lot ! [Mon Dec 22 20:39:41 2014] one sec [Mon Dec 22 20:40:05 2014] go to http://adam.chlipala.net/cpdt/html/InductiveTypes.html [Mon Dec 22 20:40:13 2014] and search for the section "Manual Proofs About Constructors" [Mon Dec 22 20:40:44 2014] read that carefully, and you'll understand how to derive the absurdity yourself [Mon Dec 22 20:45:47 2014] if I have match compute with y => (a y, b y, c y) end, how can I prevent the extraction mechanism from extracting this as (a compute, b compute, c compute)? [Mon Dec 22 20:45:56 2014] I can't find a way to factor out the common subexpression manually [Mon Dec 22 20:47:32 2014] ah, I have to do this: [Mon Dec 22 20:47:39 2014] (fun y => (a y, b y, c y)) compute [Mon Dec 22 20:49:14 2014] Thanks johnw, the paragraph helped me : by definining a function which maps Some p to True and None to False, I can then change the goal, rewrite and get absurdity [Mon Dec 22 20:49:27 2014] exactly! [Mon Dec 22 22:05:42 2014] how can I tell the "Eval compute in.." (or any other evaluation) to unfold tactic-proven theorems? minimal-non-working example: http://pastebin.com/WGxwjCYS [Mon Dec 22 22:08:32 2014] thorsten1: you need to end that definition with Defined. instead of Qed. [Mon Dec 22 22:10:26 2014] is there any disadvantage when just writing Defined everywhere instead of Qed? [Mon Dec 22 22:14:59 2014] awesome, that works as intended. thank you! [Mon Dec 22 22:15:40 2014] thorsten1: usually you write Qed for things you don't expect to be computationally relevant. [Mon Dec 22 22:19:51 2014] Ok sounds reasonable [Mon Dec 22 22:20:28 2014] thorsten1: there's just Compute [Mon Dec 22 22:26:32 2014] thanks, didn't know that [Mon Dec 22 22:47:03 2014] If k is of type option nat, and I want to destruct k, I will have two branches : one where k has been replaced by None, and one where k has been replaces by Some n. In the branch Some n, is there any possibility to add hypothesis k = Some(n) ? [Mon Dec 22 22:53:59 2014] Lewer: yes, but the method is pretty unintuitive. you can do something like this : http://pastebin.com/TZz99AxQ [Mon Dec 22 22:54:45 2014] in the first branch, H has type [k = Some n] and in the second it has type [k = None] [Mon Dec 22 22:55:15 2014] wow [Mon Dec 22 23:12:23 2014] actually I've found how to avoid doing this. I'm almost done, I have to prove p1 = p2 with H: Some (star p1) = Some (star p2) [Mon Dec 22 23:12:44 2014] (star is the unique constructor of an inductive type) [Mon Dec 22 23:13:07 2014] I've tried discriminate, it does'nt work. I've tried also cut (star p1 = star p2) [Mon Dec 22 23:13:11 2014] Lewer: if you're in tactic mode, congruence will do it. [Mon Dec 22 23:13:48 2014] oh... thanks a lot ! [Mon Dec 22 23:14:18 2014] It worked. [Mon Dec 22 23:14:31 2014] But do you know why discriminate on star p1 = star p1 didn't ? [Mon Dec 22 23:14:40 2014] star p1 = star p2 [Mon Dec 22 23:15:03 2014] discriminate is usually for deriving a contradiction from an equality [Tue Dec 23 05:27:30 2014] Testing grammar/grammar.cma [Tue Dec 23 05:27:30 2014] Error while loading "parsing/compat.cmo": interface mismatch on Grammar. [Tue Dec 23 05:28:08 2014] Any ideas? I am getting warnings that some files are found in two places. [Tue Dec 23 05:28:16 2014] I am guessing it is a path problem. [Tue Dec 23 05:28:39 2014] As I am experimenting with opam, this could be interfering. [Tue Dec 23 05:29:06 2014] It's the latest coq from git [Tue Dec 23 08:34:48 2014] Hi. I'm writing a function which should type lambda-terms. When I have an application term t:= t1 t2, let T1T2 be the type of t1, and T1 the type of t2. I would like to do a pattern matching on (T1T2, T1) as (arrow T1 T2, T1) [Tue Dec 23 08:35:11 2014] But I can't because the two patterns are not independant [Tue Dec 23 08:35:59 2014] I could do match (T1T2, T1) with (arrow T1 T2, T3) => match T3 with T1 => [Tue Dec 23 08:36:06 2014] but it's not really elegant... [Tue Dec 23 09:32:00 2014] I don't understand how the dependant pattern matchin "match E in x as y return U with ... " work [Tue Dec 23 17:33:24 2014] hi. i'm trying to prove commutativity of multiplication on natural numbers but i'm looking for a tactic to do the contrary of a simpl. see http://lpaste.net/117122 [Tue Dec 23 17:57:46 2014] mattby: that is not "true by definition" since the definition of mult does pattern matching on the second argument, not the first. you'll need a lemma about what happens when the first argument is of the form (S _) [Tue Dec 23 18:35:35 2014] thanks jrw [Tue Dec 23 18:35:51 2014] np [Tue Dec 23 23:28:31 2014] has anyone done the "classical_axioms" exercise from software foundations? [Tue Dec 23 23:28:37 2014] from the logic chapter [Tue Dec 23 23:29:02 2014] it also appears in the Coq'Art book (on page 123) [Tue Dec 23 23:31:05 2014] yeah ive done that form coq'art [Tue Dec 23 23:31:17 2014] oh, cool [Tue Dec 23 23:31:41 2014] let me find my definition, and I'll ask a concrete question. [Tue Dec 23 23:32:03 2014] my biggest problem, basically, is that it doesn't seem to be enough information in the context to prove the goal [Tue Dec 23 23:32:34 2014] ok [Tue Dec 23 23:32:42 2014] do yuo want to look at a specific one [Tue Dec 23 23:32:59 2014] and just to check the idea is that you prove C1 -> C2. then C2 -> C3 then ... up to Cn -> C1 [Tue Dec 23 23:33:04 2014] which shows them all equivalent [Tue Dec 23 23:33:13 2014] yeah, that's what I thought [Tue Dec 23 23:33:14 2014] and you can pick an order you want to do them in of course [Tue Dec 23 23:33:18 2014] ok thats a good start! [Tue Dec 23 23:33:28 2014] ythey are quite difficult, some implications are weirder than others [Tue Dec 23 23:42:27 2014] vanila: http://dpaste.com/3YMTM9Z [Tue Dec 23 23:42:42 2014] oh yeah Pierce!! [Tue Dec 23 23:42:46 2014] That's the most evil one :D [Tue Dec 23 23:42:48 2014] basically, I expand everything I can and don't know what to do about it [Tue Dec 23 23:42:50 2014] lol [Tue Dec 23 23:42:56 2014] Pierce is really strange [Tue Dec 23 23:43:01 2014] its's sort of related to continuations, you know? [Tue Dec 23 23:43:13 2014] oh, interesting [Tue Dec 23 23:43:26 2014] one question [Tue Dec 23 23:43:39 2014] do I need to introduce any lemma, or do I have everything I need? [Tue Dec 23 23:44:06 2014] you shouldn't need any lemmas [Tue Dec 23 23:44:22 2014] do you know ~ ~ P is just syntax for (P -> False) -> False? [Tue Dec 23 23:44:30 2014] yes [Tue Dec 23 23:44:36 2014] I expanded the definition :) [Tue Dec 23 23:44:39 2014] ok great [Tue Dec 23 23:45:27 2014] let me try to prove this.. [Tue Dec 23 23:46:18 2014] so (pierce P False) gives you ((P -> False) -> P) -> P [Tue Dec 23 23:46:35 2014] and your goal is P, so you just need to prove (P -> False) -> P [Tue Dec 23 23:46:52 2014] but you have got (P -> False) -> False, which is stronger than (P -> False) -> P [Tue Dec 23 23:47:31 2014] you can use elimtype False. to change a goal P into False [Tue Dec 23 23:47:52 2014] but elimtype hasn't been covered in sf [Tue Dec 23 23:48:03 2014] ah wait [Tue Dec 23 23:48:08 2014] there's a useful lemma [Tue Dec 23 23:48:30 2014] ex_falso_quodlibet [Tue Dec 23 23:49:28 2014] which does the same when you apply it [Tue Dec 23 23:50:01 2014] now I apply H0. [Tue Dec 23 23:50:39 2014] and get P -> False in the goal [Tue Dec 23 23:51:48 2014] which is the same as [not] [Tue Dec 23 23:52:53 2014] what is H0? [Tue Dec 23 23:53:10 2014] oh sorry I see [Tue Dec 23 23:53:10 2014] (P -> False) -> False [Tue Dec 23 23:53:38 2014] now I need to get P somewhere [Tue Dec 23 23:53:45 2014] oh wait [Tue Dec 23 23:53:51 2014] I could try intros [Tue Dec 23 23:53:52 2014] the first thing you should do is apply peirces axiom [Tue Dec 23 23:53:57 2014] before elimtype [Tue Dec 23 23:54:37 2014] wait, no more hints please [Tue Dec 23 23:54:46 2014] I'd like to think a bit on my own [Wed Dec 24 00:01:00 2014] lol [Wed Dec 24 00:01:02 2014] I proved it [Wed Dec 24 00:01:39 2014] the funny thing is that I tried to apply peirce's axiom before by specifying Q using :=, but it didn't work the way it should [Wed Dec 24 00:03:14 2014] good job! [Wed Dec 24 00:03:25 2014] so the computational interpretation is to do with continuations [Wed Dec 24 00:03:28 2014] (of pierce) [Wed Dec 24 00:03:31 2014] its really weird [Wed Dec 24 00:04:40 2014] non delimited ones, i imagine [Wed Dec 24 00:04:50 2014] could you expand on the continuations bit? [Wed Dec 24 00:05:12 2014] ill try :p I don't understand it too twell yet [Wed Dec 24 00:08:06 2014] so in this book what they do is add a new 'proof term' (we have lambda, varables, an application) [Wed Dec 24 00:08:48 2014] with type rules like x : P -> False |- M : False ==> /\x.M : P [Wed Dec 24 00:09:00 2014] so you now have lambda and this /\ thing, which can be used to prove peirces law [Wed Dec 24 00:10:07 2014] then when you look at how it reduces/computes its acting like call-with-current-continuation I think? [Wed Dec 24 00:10:52 2014] vanila: could you say this in english x : P -> False |- M : False ==> /\x.M : P? [Wed Dec 24 00:10:59 2014] a related thing is how you can embed classical logic into Coq by double negation -- that's like doing a continuation passing transform, which is how it gives you excluded middle inside there [Wed Dec 24 00:11:27 2014] what does |- mean? [Wed Dec 24 00:11:47 2014] well it's similar to how lambda works, if given x : A, m : B then \x:A. m : A -> B [Wed Dec 24 00:11:49 2014] I'm aware it's widely used in cs, but I'm not familiar with this notation. [Wed Dec 24 00:12:22 2014] you have a context or your assumptions on hte left of |- [Wed Dec 24 00:12:25 2014] because I haven't come across a good online introduction [Wed Dec 24 00:12:27 2014] and the judgement on the right [Wed Dec 24 00:12:43 2014] so x : A |- m : B means that given that x has type A, you can see that m has type B [Wed Dec 24 00:12:57 2014] but if you changed the type of x it might break, might not typecheck or might have a different one [Wed Dec 24 00:12:59 2014] what does the arrow mean? [Wed Dec 24 00:13:07 2014] ==> is me cheating [Wed Dec 24 00:13:11 2014] its supposed to be [Wed Dec 24 00:13:18 2014] x : P -> False |- M : False [Wed Dec 24 00:13:20 2014] ---------------------- [Wed Dec 24 00:13:27 2014] //\x.M : P [Wed Dec 24 00:13:33 2014] but I didn't want to use up 3 lines [Wed Dec 24 00:13:34 2014] but anyway [Wed Dec 24 00:13:47 2014] what this means is that given the stuff on the top, the thing on the bottom holds [Wed Dec 24 00:13:53 2014] it's actually just like |- again [Wed Dec 24 00:14:00 2014] also this is what you see when you're proving in Coq [Wed Dec 24 00:14:14 2014] -\ [Wed Dec 24 00:14:20 2014] oop [Wed Dec 24 00:15:13 2014] and how do I read the //\x.M : P? [Wed Dec 24 00:15:20 2014] part* [Wed Dec 24 00:15:35 2014] is it a lambda term of type P? [Wed Dec 24 00:17:09 2014] maybe I shouldn't bother with this for now [Wed Dec 24 00:18:12 2014] its a new binding term, different than lamda [Wed Dec 24 00:18:49 2014] if you add this as a new language construct it lets you prove pierce, and you can study how it acts and it turns out to be a control operator [Wed Dec 24 00:18:57 2014] pretty cool stuff [Wed Dec 24 00:19:20 2014] yes, sounds interesting, but it's probably above my head at the moment [Wed Dec 24 00:21:18 2014] I still struggle with continuations even though I've read quite a bit about them. especially, call/cc is giving me headaches. I guess I need to re-read a haskell tutorial on it, and try to expand everything by hand because it looks like magic to me. [Wed Dec 24 00:21:41 2014] yeah they're a really puzzle ^^ [Wed Dec 24 00:21:55 2014] how did you learn them? [Wed Dec 24 00:22:02 2014] what did you read? in what language? [Wed Dec 24 00:22:25 2014] the best thing that helped me understand them was continuation passing style [Wed Dec 24 00:22:34 2014] I learned a bit abou tit from some slides about writing scheme compilers [Wed Dec 24 00:22:42 2014] I tried in scheme and in haskell. haskell worked better, but I still need to do what I said. [Wed Dec 24 00:22:43 2014] and then some of olivier danvys papers [Wed Dec 24 00:23:18 2014] i cant say I got my head around it all yet but i feel like I made some steps :) [Wed Dec 24 00:23:25 2014] SHIFT/RESET is really cool to look into too [Wed Dec 24 00:23:32 2014] oh... [Wed Dec 24 00:23:37 2014] they seem more 'pure' simpler than call/cc [Wed Dec 24 00:23:59 2014] did you publish the compilers? [Wed Dec 24 00:25:04 2014] oh i just meant marc feeleys slides [Wed Dec 24 00:47:12 2014] vanila: seems like I'm doing something wrong [Wed Dec 24 00:47:14 2014] Theorem classic_excluded_middle : classic -> excluded_middle. Proof. unfold classic. unfold excluded_middle. unfold "~". intros. left. apply H. intros. Abort. [Wed Dec 24 00:47:27 2014] since I cannot get P anywhere [Wed Dec 24 00:47:58 2014] hmcan you show me the defs of classic and excluded_middle? [Wed Dec 24 00:48:15 2014] oh wait i have them in this file still [Wed Dec 24 00:48:30 2014] yeah, I pasted them [Wed Dec 24 00:48:52 2014] okay so I think the trick for this is related to what I said earlier on [Wed Dec 24 00:49:05 2014] you can embed classical logic in intuitionistic logic by double negation [Wed Dec 24 00:49:20 2014] so this should be a thoerem on its own in Coq: ~~(P \/ ~P) [Wed Dec 24 00:49:30 2014] and if you have that it's easy to just apply 'classic' to get P \/ ~P [Wed Dec 24 00:50:01 2014] so you might want to try proving ~~(P \/ ~P) as a lemma without any classic logic stuff involved [Wed Dec 24 00:50:56 2014] ah, I've already have the proof [Wed Dec 24 00:51:03 2014] hm I might be wrong about this acutally [Wed Dec 24 00:53:24 2014] though, I don't understand what ~~(P \/ ~P) buys me [Wed Dec 24 00:54:14 2014] yeah I think I made a mistake about that sorry, looking into it [Wed Dec 24 00:55:54 2014] oh no i was right, it's just difficult [Wed Dec 24 00:56:38 2014] want to compare the proofs we came up with? [Wed Dec 24 00:56:51 2014] http://lpaste.net/117136 [Wed Dec 24 00:56:54 2014] of ~~(P \/ ~P)? [Wed Dec 24 00:57:04 2014] just of classic -> excluded_middle [Wed Dec 24 00:57:05 2014] sure [Wed Dec 24 00:57:08 2014] ah [Wed Dec 24 00:57:10 2014] okay [Wed Dec 24 00:57:11 2014] of cours eI went via ~~(P \/ ~P) [Wed Dec 24 00:57:43 2014] wait, I haven't proved class->excluded_middle yet :) [Wed Dec 24 00:57:51 2014] alright ^^ [Wed Dec 24 00:58:07 2014] that's what I'm asking about, actually [Wed Dec 24 00:58:13 2014] basically [Wed Dec 24 00:58:16 2014] ~LEM -> LEM [Wed Dec 24 00:58:25 2014] well classic is ~~X -> X [Wed Dec 24 00:58:28 2014] so if you prove P \/ ~P [Wed Dec 24 00:58:31 2014] sorry [Wed Dec 24 00:58:35 2014] ok, so [Wed Dec 24 00:58:40 2014] if you prove ~~(P \/ ~P), thne classic turns that into P \/ ~P [Wed Dec 24 00:58:43 2014] say foo : ~LEM -> LEM [Wed Dec 24 00:58:44 2014] which completes the proof [Wed Dec 24 00:58:52 2014] then [Wed Dec 24 00:59:09 2014] nnlem disproof := disproof (foo disproof) [Wed Dec 24 00:59:16 2014] nnlem : ~~LEM [Wed Dec 24 00:59:35 2014] and foo is implementable in vanilla coq [Wed Dec 24 01:02:31 2014] vanila: I understand that you can get P\/~P from ~~(P \/ ~P) because ~~P -> P, but how can I used it here? [Wed Dec 24 01:02:46 2014] I have P\/~P in the context [Wed Dec 24 01:02:52 2014] so apply wouldn't work [Wed Dec 24 01:02:59 2014] do I need a separate lemma? [Wed Dec 24 01:03:01 2014] you mean just what tactics etc. to use? [Wed Dec 24 01:03:35 2014] oh,wait [Wed Dec 24 01:03:35 2014] well you know if you have a goal P \/ ~P, then you should be able to apply classic to turn the goal into ~~(P \/ ~P) [Wed Dec 24 01:03:39 2014] I guess I know what to do [Wed Dec 24 01:03:51 2014] you might need to provide it extra vars sometimes [Wed Dec 24 01:03:55 2014] right, it's backwards [Wed Dec 24 01:04:05 2014] yeah the backwards aspect is a bit tricky! [Wed Dec 24 01:04:19 2014] that's why lemmas are nice, you can chain forwards with lemmas - but prove each one backwards [Wed Dec 24 01:04:27 2014] of course its all just preference [Wed Dec 24 01:15:39 2014] I've just proved it, but it was so weird [Wed Dec 24 01:15:53 2014] much weirder than the previous one [Wed Dec 24 01:16:30 2014] its so strange to think about them as functions [Wed Dec 24 01:16:36 2014] yeah [Wed Dec 24 01:16:38 2014] you can Print the proof to see how that looks by the way [Wed Dec 24 01:18:16 2014] lol, I fail to parse the printed function [Wed Dec 24 01:22:16 2014] vanila: oh, your proof is much shorter, but uses intro, exact, and assumption, which I'm not familiar with. [Wed Dec 24 01:22:26 2014] would you like to see mine? [Wed Dec 24 01:22:31 2014] yeah could be interesting [Wed Dec 24 01:22:43 2014] you should know about intro and assumption - i can explain them if you want [Wed Dec 24 01:24:50 2014] vanila: http://dpaste.com/11RZRMM [Wed Dec 24 01:26:38 2014] oh okay, i stepped through it [Wed Dec 24 01:26:41 2014] vanila: I guess I'll read about intro and assumption later. so I don't have the temptation to use them while solving the exercises. [Wed Dec 24 01:28:39 2014] is there a way to unfold a term using a prettier notation? [Wed Dec 24 01:28:50 2014] I'd like to see ~~P rather than (P -> False) -> False [Wed Dec 24 01:29:13 2014] since the latter makes thinking about these things a bit harder [Wed Dec 24 01:30:10 2014] the theorems are defined using the pretty notation, too [Wed Dec 24 01:30:52 2014] there's definitely a way but I dont know it [Wed Dec 24 01:32:52 2014] vanila: thanks for all the tips. especially, this one: "well you know if you have a goal P \/ ~P, then you should be able to apply classic to turn the goal into ~~(P \/ ~P)" [Wed Dec 24 01:33:00 2014] without it I wouldn't be able to prove it [Wed Dec 24 01:33:08 2014] np :) [Wed Dec 24 10:52:57 2014] Hello [Wed Dec 24 10:53:17 2014] To prove something like this [forall z:Z, {z=0} + {z<>0}], do I really have to unfold the definition of Z ? [Wed Dec 24 11:31:18 2014] Also, is there a kind of workaround to use the [cut] tactic in an hypothesis ? (In fact I would like to simplify [a + - a = _] in an hypothesis, so I thought it would be good to use the Zegal_left to do it) [Wed Dec 24 16:19:27 2014] why is unit tt [Wed Dec 24 16:19:34 2014] why not unit_val or something [Wed Dec 24 16:19:35 2014] whats tt [Wed Dec 24 16:22:52 2014] benzrf: the single inhabitant of the type T (aka: top, 1, True) has historically been called tt. in programming that type is more often called unit, but its isomorphic to T, and so the name tt kind of makes sense. [Wed Dec 24 16:23:03 2014] h-huh [Wed Dec 24 16:34:15 2014] adelbertc: I've been wondering why you called the constructor of True tt. now I know :) [Wed Dec 24 16:48:48 2014] :-) [Wed Dec 24 16:49:39 2014] adelbertc: btw, after you hint, I managed to define it on my own. thanks! [Wed Dec 24 17:02:02 2014] Np! [Thu Dec 25 07:18:19 2014] I'm in trouble with lambda calculus pls help me: is n f x= f(f(...f x...))(composed n times) is really lambda term? [Thu Dec 25 07:47:01 2014] Could someone please help me with working through this basic proof: Theorem andb_eq_orb : forall (b c : bool), (andb b c = orb b c) -> b = c. [Thu Dec 25 07:49:11 2014] I seem to be falling down when choosing the hypothesis. I would like to be able to assume b = c and then use the destruct tactic [Thu Dec 25 07:49:50 2014] I proved the contrapositive: Lemma andb_eq_orb_inv : forall (b c : bool), (b = c) -> andb b c = orb b c. [Thu Dec 25 07:49:50 2014] Proof. intros. rewrite -> H. destruct c. reflexivity. reflexivity. Qed. [Thu Dec 25 07:51:49 2014] But I am unaware of a way to apply that to the form of the proposition I am trying to solve. [Thu Dec 25 07:52:06 2014] *trying to prove. [Thu Dec 25 08:16:53 2014] taupe : andb_eq_orb_inv is not the contrapositive, it's the converse of andb_eq_orb [Thu Dec 25 08:17:14 2014] Anyway, to prove andb_eq_orb, you can still use destruct, by destructing over b and c. [Thu Dec 25 08:24:20 2014] Cypi: Thank you for correcting me. When I tried to do this I get a contradiction. [Thu Dec 25 08:25:20 2014] If you have to prove something like [false = true], then hopefully your hypotheses are inconsistent. Here, it's the case. If you have an hypothesis like [false = true], you can use the tactic inversion to prove your goal. [Thu Dec 25 08:33:14 2014] intros. destruct b. destruct c. Gives 3 subgoals and one of the subgoals is invalid (it belongs to one of the two cases where orb b c does not equal andb b c) This should be excluded by the constraint (andb b c = orb b c) [Thu Dec 25 08:33:43 2014] You have to tell Coq thi with inversion [Thu Dec 25 08:34:01 2014] this* [Thu Dec 25 08:47:02 2014] Cypi: Thanks for your help. [Thu Dec 25 11:24:10 2014] ooh, Coq'Art is free as a PDF... in French [Thu Dec 25 11:24:37 2014] I don't grok French though (yeah, that's crazy when I use Coq, I know) [Thu Dec 25 16:47:51 2014] found this today if anyone is interested: https://twitter.com/onepaperperday/status/548231212666736641 [Thu Dec 25 16:51:09 2014] thanks for sharing, I bookmarked it [Thu Dec 25 19:05:34 2014] Anyone want to look at some - probably terrible - newbie Coq code and give feedback or advice? [Thu Dec 25 19:05:40 2014] sure [Thu Dec 25 19:06:29 2014] Here is what I have: https://gist.github.com/eraserhd/4faee58869f5c55333b7 [Thu Dec 25 19:06:54 2014] _Any_ feedback is welcome. [Thu Dec 25 19:07:01 2014] er, _All_, I mean. [Thu Dec 25 19:07:24 2014] But I'm stumped at trying to prove something forall l : letter. [Thu Dec 25 19:07:51 2014] I think all_nat_ge_0 is already available as le_O or something [Thu Dec 25 19:08:22 2014] where are you stumped, which line? [Thu Dec 25 19:08:47 2014] I seem to have deleted it. [Thu Dec 25 19:09:04 2014] also, maybe just Definition letterT := Fin.t 26. [Thu Dec 25 19:09:10 2014] you don't really need to mirror the type [Thu Dec 25 19:09:22 2014] s/T// [Thu Dec 25 19:10:13 2014] Yeah, that makes sense. I was thinking I could make the 26 not a parameter, but that didn't work. [Thu Dec 25 19:10:49 2014] OK, I added the theorem I want to prove at the end. I can't do "induction l." because it wants something to match letterT 27. [Thu Dec 25 19:12:36 2014] perhaps then induction on b? [Thu Dec 25 19:12:46 2014] Er, the error is "Abstracting over terms "26" and "l" leads to a term ... which is ill-typed. [Thu Dec 25 19:12:48 2014] or on "diamond l" [Thu Dec 25 19:13:06 2014] Oh. [Thu Dec 25 19:13:10 2014] Hrmm. [Thu Dec 25 19:13:11 2014] when you get that error, you can try "dependent induction" [Thu Dec 25 19:13:22 2014] What is dependent induction? [Thu Dec 25 19:13:24 2014] you'll have to import Coq.Program.Tactics [Thu Dec 25 19:13:33 2014] it adds some tricks to work around that abstraction problem [Thu Dec 25 19:13:44 2014] it will bring in the JMeq axiom though [Thu Dec 25 19:13:59 2014] no, Coq.Program.Equality [Thu Dec 25 19:14:06 2014] i generally avoid it [Thu Dec 25 19:14:54 2014] gotta head out now [Thu Dec 25 19:14:59 2014] i'll leave the rest to others [Thu Dec 25 19:15:04 2014] Neat. OK. I think induction on (diamond l) is getting me somewhere. [Thu Dec 25 19:15:53 2014] Hrmm. I didn't look in Fin for useful things. [Thu Dec 25 19:16:42 2014] is there a list of all axioms of homotopy type theory? [Thu Dec 25 19:17:02 2014] axioms, derivation rules, etc. [Thu Dec 25 19:17:46 2014] because in the HoTT book there is a lot, and I have to admit I did not read it entirely. but on-the-fly I could not find such a list. [Thu Dec 25 19:30:00 2014] schoppenhauer: the appendix has the rules iirc [Thu Dec 25 19:31:13 2014] Saizan: seems like. I'll read it. [Thu Dec 25 19:31:24 2014] (I did not expect it to be in the appendix) [Thu Dec 25 19:39:42 2014] Saizan: ok ... thisis not really what I hoped to find ... [Thu Dec 25 19:40:32 2014] but well [Thu Dec 25 19:40:35 2014] probably all there is. [Thu Dec 25 19:40:41 2014] thx. [Thu Dec 25 19:45:45 2014] they define natural numbers there ... wtf? [Thu Dec 25 19:46:20 2014] other inductive types are handled "similar" ... [Thu Dec 25 21:58:15 2014] If I have f (match _ with | A => x), how do I rewrite to (match _ with | A => f x)? not lazy beta. [Thu Dec 25 22:09:37 2014] eraserhd: could you destruct _ [Thu Dec 25 22:13:12 2014] benzrf: yeah, that's what I'm doing. I's hoping not to solve so many cases. [Thu Dec 25 22:14:08 2014] eek [Thu Dec 25 22:17:32 2014] ? [Thu Dec 25 22:18:06 2014] he wants to distribute over the 'f' [Thu Dec 25 23:03:17 2014] er, it's just unfolding f? [Thu Dec 25 23:04:07 2014] No, duh. Prolly time for me to sleep. [Thu Dec 25 23:24:03 2014] eraserhd: if I wanted to do that rewrite, I'd prove it as a lemma (specific to the discriminated type, unfortunately) and then rewrite with it. the proof of that lemma is by destruct on the discriminee, but when you rewrite with it no destruct is necessary. [Thu Dec 25 23:53:33 2014] hmm [Fri Dec 26 11:32:31 2014] Hi. Is it possible to include a module inside another without explicitly redeclaring all the fields? Thank you in advance for your answers. [Fri Dec 26 11:41:20 2014] xavierm02: sure, use "Include" [Fri Dec 26 11:48:30 2014] I hadn't even tried that because it's not listed in coqide >_<. Thanks :) [Fri Dec 26 12:11:36 2014] Hello ! [Fri Dec 26 12:12:03 2014] Do you know how to specify the semantic of a user-defined tactic (Ltac) ? [Fri Dec 26 12:13:04 2014] I mean, how do I define a tactic mytactic arg1 in arg2 ? (arg1 and arg2 are arguments, and the in keyword should be always provided) [Fri Dec 26 12:23:31 2014] use Tactic Notation [Fri Dec 26 12:23:37 2014] or Notation Tactic, one of thoes two [Fri Dec 26 12:28:51 2014] Ok thanks ! [Fri Dec 26 12:39:01 2014] I'm getting a syntax error I don't understand with https://gist.github.com/cmr/4a8ecf47ac8f9b0fc325, on line 3 at the =>, "Syntax error: [constr:lconstr] expected after "=>" (in [eqn])." [Fri Dec 26 12:41:04 2014] cmr: did you Import ListNotations. ? [Fri Dec 26 12:41:43 2014] [] and :: are notations for nil and cons [Fri Dec 26 13:08:26 2014] Ptival: hm, that does seem to be the problem, since when I use nil/cons explicitly it works fine. I don't see a ListNotations in https://coq.inria.fr/distrib/current/stdlib/ and when I go try to import it I get "ListNotations is not a module" [Fri Dec 26 13:14:25 2014] Require Import List. [Fri Dec 26 13:14:31 2014] Import ListNotations. [Fri Dec 26 13:14:37 2014] then you can use [] and :: [Fri Dec 26 13:14:53 2014] nil and cons are imported by default [Fri Dec 26 13:15:05 2014] indeed [Fri Dec 26 13:15:07 2014] thanks! [Fri Dec 26 13:20:38 2014] Hi. I hadn't noticet that FSets didn't have maps so I did stuff with them but now I need maps and since I'd prefer avoiding to redo all the proofs, I'm trying to make a functor that goes from the old OrderedType to the new one. But I'm not sure of how to use both in the same file. I tried this but it doesnt seem to work : http://pastebin.com/dP1HsvXG Thanks in advance for your answers. [Fri Dec 26 13:20:55 2014] FSets have maps [Fri Dec 26 13:20:58 2014] FSetAVL [Fri Dec 26 13:21:31 2014] -/b 15 [Fri Dec 26 13:28:32 2014] I meant in Msets. I have modules that verify the interface OrderedType compatible with MSets and I want to be able to use stuff from FSets (maps). [Fri Dec 26 14:26:05 2014] Nevermind. I used Module instead of Module Type and that caused the error. [Sat Dec 27 11:22:25 2014] Is there a way to apply a tactic like cbv to a sub-expression explicitly? [Sat Dec 27 17:56:51 2014] eraserhd: You can do something like [let x := constr:($subexpression) in let y := (eval cbv in x) in change x with y] [Sun Dec 28 00:18:27 2014] how does negation and double negation work with equalities and inequalities in coq [Sun Dec 28 00:23:43 2014] benzrf: what do you mean? [Sun Dec 28 00:33:52 2014] jrw: what rules of derivation may i use [Sun Dec 28 00:34:39 2014] still not sure what you mean. [Sun Dec 28 00:34:47 2014] jrw: can i get x > y from ~(x < y \/ x <> y) [Sun Dec 28 00:34:49 2014] er [Sun Dec 28 00:34:54 2014] jrw: can i get x > y from ~(x < y) /\ (x <> y) [Sun Dec 28 00:35:08 2014] jrw: and more generally which conversions am i allowed to do [Sun Dec 28 00:35:51 2014] oh, that's what you meant by "inequality" not a <> b [Sun Dec 28 00:36:35 2014] benzrf: You may be looking for [Locate "<"], [Locate "<>"], and [Print $name_of_constant]. These are all defined inside of Coq, not primitive notions; the rules follow from the general rules about inductive types. [Sun Dec 28 00:36:48 2014] benzrf: easy answer is you can do any conversion you can prove :) [Sun Dec 28 00:36:54 2014] jgross: i know, but i'm lazy 8D [Sun Dec 28 00:37:02 2014] jrw: sorry [Sun Dec 28 00:37:27 2014] benzrf: you may find it instructive to prove some of those conversions you mentioned "by hand" [Sun Dec 28 00:37:32 2014] ie, without omega [Sun Dec 28 00:38:45 2014] hm [Sun Dec 28 00:39:43 2014] The "cheating" answer is that, with <, <>, etc (for natural numbers), you can do anything you can do classically, because these relations are decidable. You have double-negation elimination for decidable relations, because LEM -> DNE, even when restricted to individual propositions (that is, forall P, (P \/ ~P) -> (~~P -> P)). [Sun Dec 28 00:40:18 2014] aha [Sun Dec 28 00:41:27 2014] oooh because there is a proof of forall x y : nat, x < y \/ x = y \/ x > y [Sun Dec 28 00:41:30 2014] neat! [Sun Dec 28 09:13:37 2014] Hi ! [Sun Dec 28 09:14:12 2014] I have an hypothesis x<>1, and my goal is x=1 [Sun Dec 28 09:14:18 2014] How can I show the contradiction ? [Sun Dec 28 09:14:52 2014] Basically, you have to prove False. So you'd better have a contradiction in your hypotheses :) [Sun Dec 28 09:20:50 2014] Cypi: Ho I see what you mean ... that's why I turned round. ^^ [Sun Dec 28 09:21:04 2014] Choups314: what else do you have inyour context? [Sun Dec 28 09:21:27 2014] notdan: https://imgur.com/fDaowWn [Sun Dec 28 09:22:38 2014] I don't think it's provable [Sun Dec 28 09:22:55 2014] I think it is, I just don't know how to do it because I never worked with Z in Coq [Sun Dec 28 09:23:10 2014] H /\ n /\ n0 is indeed inconsistent in Z. [Sun Dec 28 09:23:20 2014] oh [Sun Dec 28 09:23:25 2014] Yeah you are right, sorry [Sun Dec 28 09:23:42 2014] try `omega' or `ring'? [Sun Dec 28 09:24:31 2014] Actualy, that was my original goal : forall (x y : Z), x * y = 1 -> ((x = 1) /\ (y = 1)) \/ ((x = -1) /\ (y = -1)). [Sun Dec 28 09:25:07 2014] So i split in three cases : x=1 | x=-1 | (x<>1 and x<>-1) [Sun Dec 28 09:25:22 2014] The first two are easy to prove [Sun Dec 28 09:25:55 2014] And I think I have to do the same thing with y [Sun Dec 28 09:26:10 2014] Then it would make 5 cases [Sun Dec 28 09:37:11 2014] Just forget what I said about these 5 cases .. [Sun Dec 28 09:37:30 2014] Prove the inconsistency is enough [Sun Dec 28 09:42:10 2014] notdan : Is it possible to use omega or ring in an hypothesis ? [Sun Dec 28 09:46:04 2014] Hm I don't think so. How would that work? [Sun Dec 28 09:46:21 2014] Hm, weird, I think omega should be able to solve "x * y = 1 -> x = 1 \/ x = -1" [Sun Dec 28 09:50:03 2014] Ok, I might be doing something wrong, because on my set up, omega couldnt even solve x*y = 1 -> y * x = 1 [Sun Dec 28 09:51:25 2014] I don't think omega can solve such an equation, but I don't really now about it .. [Sun Dec 28 09:53:00 2014] Ah, right, omega can only handle addtition ): [Sun Dec 28 16:52:11 2014] i can think of a few ways of excrutiatingly-manually doing this but does anybody know an elegant method: [Sun Dec 28 16:52:14 2014] Trans : transitive T R [Sun Dec 28 16:52:16 2014] Equiv : R d d' [Sun Dec 28 16:52:19 2014] ============================ [Sun Dec 28 16:52:21 2014] {x : T | R x d} = {x : T | R x d'} [Sun Dec 28 16:59:21 2014] you also need simmetry, i think? [Sun Dec 28 17:00:19 2014] uh, no, i misread [Sun Dec 28 17:03:31 2014] Saizan: =) [Sun Dec 28 17:08:15 2014] Saizan: i try to apply (fun x xd => Trans x d d' xd Equiv). [Sun Dec 28 17:08:25 2014] Saizan: but it's not top-level [Sun Dec 28 17:08:42 2014] and besides apply probably isnt relevant here [Sun Dec 28 17:08:48 2014] maybe i should just do it the refine route :\ [Sun Dec 28 17:10:31 2014] it seems like you'd need univalence to me [Sun Dec 28 17:13:50 2014] Saizan: rly? [Sun Dec 28 17:14:02 2014] i feel like i asked about this before and managed to prove it [Sun Dec 28 17:14:13 2014] oh that might have been for a slightly different case... [Sun Dec 28 17:14:26 2014] * checks [Sun Dec 28 17:16:48 2014] Saizan: ahh [Sun Dec 28 17:17:29 2014] Saizan: what i had that worked before was f x = f d :| [Sun Dec 28 17:17:47 2014] so i generalized it since that was R x d := f x = f d [Sun Dec 28 17:18:19 2014] to be very specific, [Sun Dec 28 17:18:24 2014] {x : nat | x % 10 = 21 % 10} = {x : nat | x % 10 = 31 % 10} [Sun Dec 28 17:20:05 2014] and that's simplifiable [Sun Dec 28 17:20:24 2014] Saizan: univalence allows P <-> Q -> P = Q or something? [Sun Dec 28 17:25:58 2014] yeah, when P and Q are propositional [Sun Dec 28 17:58:27 2014] Saizan: onice [Sun Dec 28 17:59:01 2014] is there something like extensionality for sigma types [Sun Dec 28 18:19:37 2014] is coq suited to hott [Sun Dec 28 21:58:24 2014] h-how do i convert Z -> nat [Sun Dec 28 22:07:28 2014] benzrf: there's something like Z.to_nat iirc [Sun Dec 28 22:07:43 2014] depends on what you want to do about negative elements of Z [Sun Dec 28 22:07:54 2014] I think Z.to_nat sends all negatives to 0 [Sun Dec 28 22:08:45 2014] where do i get Z :| [Sun Dec 28 22:08:52 2014] what do i import, rather [Sun Dec 28 22:35:30 2014] benzrf: ZArith I think? [Sun Dec 28 22:35:39 2014] i-i imported that [Sun Dec 28 22:35:50 2014] Coq < Require Import ZArith. [Sun Dec 28 22:35:51 2014] Coq < Check Z.to_nat. [Sun Dec 28 22:35:51 2014] Toplevel input, characters 6-14: [Sun Dec 28 22:35:53 2014] etc [Sun Dec 28 22:36:12 2014] benzrf: how about [Search (Z -> nat).] ? [Sun Dec 28 22:36:24 2014] or maybe SearchAbout [Sun Dec 28 22:36:31 2014] can never remember when you need one or the other [Sun Dec 28 22:37:08 2014] huh [Sun Dec 28 22:37:24 2014] aha [Sun Dec 28 22:37:29 2014] thanks :-) [Mon Dec 29 22:51:02 2014] hmm [Mon Dec 29 22:51:20 2014] is it possible to do something like the berry paradox in coq [Mon Dec 29 22:51:30 2014] i assume you can't embed coq within coq, but [Mon Dec 29 22:51:43 2014] maybe if you embed a simpler language? [Mon Dec 29 22:51:45 2014] :? [Wed Dec 31 01:54:27 2014] how can I make an evaluatable definition within a proof? Concrete: my code looks like: Definition unneeded_def: A. Proof. Bla. Defined. Theorem ...Proof. ex_intro with (x := unneeded_def). Defined. How can i get rid of the name unneeded_def? [Wed Dec 31 01:55:51 2014] note that assert (unneeded_def: A). is not enough, because then I can't compute unneeded_def [Wed Dec 31 01:58:00 2014] The answer was: the tactic Let does this. [Wed Dec 31 02:21:25 2014] hello [Wed Dec 31 02:22:13 2014] ellllo [Wed Dec 31 02:22:18 2014] can't I use [inversion P as [HP|NHP] on [forall P : Prop, P \/ ~P]? [Wed Dec 31 02:22:35 2014] ]* [Wed Dec 31 02:22:54 2014] coq complains that H is not inductive [Wed Dec 31 02:23:30 2014] nkar: isn't that destruct that you want [Wed Dec 31 02:23:44 2014] but it's in the hypothesis [Wed Dec 31 02:23:56 2014] ah wait [Wed Dec 31 02:24:00 2014] :) [Wed Dec 31 02:24:20 2014] also, [Wed Dec 31 02:24:22 2014] >LEM [Wed Dec 31 02:29:14 2014] after [destruct H as [HP|HNP]] coq says it cannot find an instance for [P] [Wed Dec 31 02:29:26 2014] can't it just add a forall? [Wed Dec 31 02:30:27 2014] hhuh [Wed Dec 31 02:30:30 2014] wait, what? [Wed Dec 31 02:30:38 2014] nkar: that's not how it works, bub [Wed Dec 31 02:30:45 2014] anyway, that's probably not what I should do [Wed Dec 31 02:31:07 2014] nkar: a function from P to P \/ ~P cannot yield a function from P to ~P or a function from P to P [Wed Dec 31 02:31:16 2014] see how it works [Wed Dec 31 02:32:09 2014] ah, right, you cannot get two at the same time [Wed Dec 31 02:32:19 2014] that's what \/ is for [Wed Dec 31 02:32:51 2014] nkar: you can destruct the output for some given P [Wed Dec 31 02:34:23 2014] but cannot I consider ~P and P separately? [Wed Dec 31 02:34:28 2014] like with left and right [Wed Dec 31 02:34:32 2014] but in the hypothesis [Wed Dec 31 02:36:16 2014] nkar: well yes [Wed Dec 31 02:36:21 2014] nkar: if you apply LEM to something [Wed Dec 31 02:37:56 2014] hm, here's my goal, and I'm not sure how to proceed [Wed Dec 31 02:38:00 2014] (forall P : Prop, P \/ (P -> False)) -> forall P Q : Prop, ((P -> False) /\ (Q -> False) -> False) -> P \/ Q [Wed Dec 31 02:38:00 2014] [Wed Dec 31 02:38:12 2014] after intros, I mean [Wed Dec 31 02:39:05 2014] nkar: personally i'd reason by cases on P and Q [Wed Dec 31 02:39:10 2014] 's truth values [Wed Dec 31 02:39:21 2014] destruct (LEM P). [Wed Dec 31 02:39:54 2014] then destruct (LEM Q). [Wed Dec 31 02:40:02 2014] in the branches where it becomes necessary [Wed Dec 31 02:40:32 2014] nkar: so either you end up with a proof of P, a proof of Q, or both, so you can exit [Wed Dec 31 02:40:42 2014] nkar: or you get ~P /\ ~Q, so you can inversion [Wed Dec 31 02:41:29 2014] ugh, I didn't know you can apply things inside [destruct] [Wed Dec 31 02:42:40 2014] well, why not? [Wed Dec 31 02:42:49 2014] you apply it to an expression [Wed Dec 31 02:42:55 2014] yeah, I understand [Wed Dec 31 02:43:03 2014] kk [Wed Dec 31 02:43:21 2014] I just haven't tought about it and never seen an example of doing so [Wed Dec 31 02:43:33 2014] hmmmmmmmmmmmm [Wed Dec 31 02:44:31 2014] night [Wed Dec 31 02:44:34 2014] o/ [Wed Dec 31 02:44:39 2014] \o [Wed Dec 31 02:44:41 2014] night [Wed Dec 31 03:10:38 2014] benzrf: proved it. basically, I needed to apply LEM twice: first with (P:=Q), then with (P:=P), so I could get both ~P and ~Q in the hypothesis. after that the proof is trivial. [Wed Dec 31 06:18:47 2014] Hi ! [Wed Dec 31 06:21:07 2014] I have a definition like [Definition id : forall (a : Type), predicate a -> Type] [Wed Dec 31 06:21:51 2014] And I try to define something like : [Definition id2 : id varA.] [Wed Dec 31 06:22:13 2014] But I don't know how to give the proof of the [predicate a] .. [Wed Dec 31 06:28:29 2014] Nevermind, It's just like parameters [Thu Jan 1 07:40:27 2015] hello? [Thu Jan 1 07:48:00 2015] sorry, I've got a fairly simple question about implementing a module of some given module type. In the original module type (it's parameterized over some more modules / a functor) I actually define some useful machinery. When implementing the module type in a real module, how do I access that machinerY/ [Thu Jan 1 07:48:02 2015] *? [Thu Jan 1 17:08:43 2015] hi guise [Thu Jan 1 17:08:48 2015] any idea why this line: [Thu Jan 1 17:08:49 2015] COQC -nois theories/Init/Notations.v [Thu Jan 1 17:08:57 2015] is taking eternity when i make-install coq under cygwin? [Thu Jan 1 17:09:11 2015] and when i say "taking eternity" i mean "probably freezing" [Thu Jan 1 17:17:37 2015] ^ it's the halting problem we face every day [Thu Jan 1 17:21:20 2015] it's been a while since last time I wrote Coq ... any ideas why I'm not getting inductive hypothesis here http://lpaste.net/117590 ? [Thu Jan 1 17:43:46 2015] any indeas what kind of relation is it talking about in 0.3 (f) here: http://adam.chlipala.net/cpdt/ex/exercises.pdf ? [Thu Jan 1 17:52:12 2015] you'll need to define your own function, of type bool -> bool -> Prop [Thu Jan 1 17:58:00 2015] johnw-: can't I just use eq(=) ? [Thu Jan 1 17:58:16 2015] "Your proof here should not be about the standard equality =, but rather about some new equality relation that you define" [Thu Jan 1 17:58:40 2015] I can see that, I'm asking why it has to be a new relation? [Thu Jan 1 17:58:47 2015] I don't know, ask Adam :) [Thu Jan 1 17:59:12 2015] i imagine once you try to do it, it may become clearer [Thu Jan 1 17:59:19 2015] like, do it with eq first [Thu Jan 1 17:59:24 2015] then see if you can change it to do without [Thu Jan 1 18:01:45 2015] johnw-: btw, I think type of the equality relation here is not bool -> bool -> Prop, it's tree bool -> tree bool -> Prop. [Thu Jan 1 18:03:03 2015] ah, fair enough [Thu Jan 1 18:04:03 2015] I'll need to re-read the coinductive chapter of cpdt [Thu Jan 1 18:14:26 2015] I really need to read... all chapters of CPDT >_> [Thu Jan 1 18:14:36 2015] debating that, reading HoTT, or learning about Idris [Thu Jan 1 20:04:04 2015] fucking hell [Thu Jan 1 20:04:17 2015] now i've taken the current version from github and make install fails at a different point [Thu Jan 1 20:04:30 2015] install: cannot stat ‘bin/coqdep.exe’: No such file or directory [Thu Jan 1 20:04:31 2015] etc [Thu Jan 1 20:04:43 2015] "cannot stat"? how hard can it be to stat something? [Thu Jan 1 20:45:37 2015] when it doesn't exist, extremely hard [Fri Jan 2 01:04:10 2015] hmm.. I must be missing something. This is proving tricky: a <> b -> b <> c -> a <> c [Fri Jan 2 01:08:57 2015] Probably because it’s not true: Consider a = 0, b = 1, c = 0. [Fri Jan 2 01:20:52 2015] well, there you go [Fri Jan 2 01:21:14 2015] this tells me that bedtime is well past, good night! [Fri Jan 2 01:21:26 2015] :) Good night! [Fri Jan 2 01:22:26 2015] Axiom thdp : False. [Fri Jan 2 16:32:55 2015] why does this complain about exp not being in scope: [Fri Jan 2 16:32:55 2015] Notation "{exp | a : A, cond}" := (sigf A _ (fun a : A => cond) (fun a : A => exp)). [Fri Jan 2 16:33:13 2015] use a space after { [Fri Jan 2 16:33:20 2015] o.O [Fri Jan 2 16:33:20 2015] or did you want "{exp" to be the notation? [Fri Jan 2 16:33:33 2015] interesting [Fri Jan 2 16:33:38 2015] * doesnt actualoly know the Notation syntax [Fri Jan 2 16:33:43 2015] use spaces around all operators [Fri Jan 2 16:33:48 2015] { exp | a : A , cond } [Fri Jan 2 16:33:48 2015] ok! [Fri Jan 2 16:33:57 2015] indicidentally does sigf already exist [Fri Jan 2 16:34:06 2015] Inductive sigf : forall A B : Type, (A -> Prop) -> (A -> B) -> Type := [Fri Jan 2 16:34:06 2015] | existF : forall (A B : Type) (P : A -> Prop) (f : A -> B) (a : A), P a -> sigf A B P f. [Fri Jan 2 16:34:11 2015] *incidentally [Fri Jan 2 16:34:20 2015] i can't make sense out of it by looking [Fri Jan 2 16:34:21 2015] what does it do? [Fri Jan 2 16:34:35 2015] it's like sig but the type carries a function that is hypothetically applied to the contents [Fri Jan 2 16:34:41 2015] like in math you can write something along the lines of [Fri Jan 2 16:34:53 2015] {x + 1 | x ∈ ℕ, odd x} [Fri Jan 2 16:35:07 2015] ah, a list comprehension basically [Fri Jan 2 16:35:14 2015] i suppose so! [Fri Jan 2 16:35:15 2015] ssreflect has this [Fri Jan 2 16:35:20 2015] interesting [Fri Jan 2 16:35:21 2015] I don't think that stdlib does [Fri Jan 2 16:35:27 2015] to be precise [Fri Jan 2 16:35:32 2015] i was writing something that was like [Fri Jan 2 16:35:57 2015] {t : Type | exists d : DataType, t = } [Fri Jan 2 16:36:02 2015] and i wanted to be able to do [Fri Jan 2 16:36:17 2015] { | d : DataType} [Fri Jan 2 16:36:28 2015] or something along those lines. [Fri Jan 2 16:37:05 2015] elements of the type are clearly the same as sig in practice, but then types are distinguished based on the function [Fri Jan 2 16:37:30 2015] so {x + 1 | x : nat, odd x} is not the same as {x | x : nat, odd x} [Fri Jan 2 16:39:03 2015] why not just map over the latter? [Fri Jan 2 16:39:15 2015] map (plus 1) {x | x : nat, odd x} [Fri Jan 2 16:47:14 2015] johnw: huh [Fri Jan 2 16:47:20 2015] th-that's a thing you can do? [Fri Jan 2 16:47:23 2015] why not? [Fri Jan 2 16:47:27 2015] Error: The reference map was not found in the current environment. [Fri Jan 2 16:47:43 2015] Import List [Fri Jan 2 16:47:47 2015] Require Import List [Fri Jan 2 16:48:02 2015] map : forall A B : Type, (A -> B) -> list A -> list B [Fri Jan 2 16:48:19 2015] {x : nat | odd x} : Type [Fri Jan 2 16:48:31 2015] so, what does your syntax represent? [Fri Jan 2 16:48:40 2015] some coinductive list or something? [Fri Jan 2 16:48:47 2015] no lists involved [Fri Jan 2 16:48:53 2015] rather than ganging everything up into a special notation [Fri Jan 2 16:49:00 2015] it's just a sigma type [Fri Jan 2 16:49:04 2015] oh [Fri Jan 2 16:49:07 2015] du [Fri Jan 2 16:49:09 2015] duh [Fri Jan 2 16:49:26 2015] but the type also carries a function whose domain is the type you're constraining [Fri Jan 2 16:49:37 2015] I see now, sorry, I was confused [Fri Jan 2 16:49:49 2015] it represents the image of the sigma type under the function [Fri Jan 2 16:49:56 2015] you want to return "add 1 to some odd number" [Fri Jan 2 16:50:08 2015] actually this probably isnt the best way to do it [Fri Jan 2 16:50:20 2015] 2 nonequal functions could have identical images [Fri Jan 2 16:50:31 2015] but the types would be considered different [Fri Jan 2 16:50:33 2015] poo [Fri Jan 2 16:50:35 2015] how about: { x : nat & (odd x * x + 1)%type } [Fri Jan 2 16:50:54 2015] ? [Fri Jan 2 16:51:02 2015] x + 1 is not a type [Fri Jan 2 16:51:07 2015] grr [Fri Jan 2 16:51:12 2015] how about: { x : nat & (odd x, x + 1) } [Fri Jan 2 16:51:15 2015] i'm too distracted, I'll stop now [Fri Jan 2 16:51:26 2015] that doesn't work either [Fri Jan 2 16:52:07 2015] well what i'm really looking for is a type constructor such that 2 fully applied versions of it will be equal iff the sets they are meant to represent are equal [Fri Jan 2 16:52:21 2015] oh wait [Fri Jan 2 16:52:25 2015] i know how to do that, duuh [Fri Jan 2 16:54:23 2015] Definition img {A B} (P : A -> Prop) (f : A -> B) = {i : B | exists p : A, f p = i /\ P p} [Fri Jan 2 16:54:40 2015] well... [Fri Jan 2 16:54:45 2015] hm [Fri Jan 2 16:56:30 2015] oh man [Fri Jan 2 16:56:37 2015] that's just what i had before :| [Fri Jan 2 16:56:44 2015] i invented sigf to avoid that >.> [Fri Jan 2 16:56:47 2015] oh well! [Fri Jan 2 16:58:15 2015] yay, full circle [Fri Jan 2 17:43:56 2015] hey guys, any idea why C-c C-a C-o doesn't show any results when searching for a pattern, but doing SearchRewrite for the same pattern returns results? [Fri Jan 2 17:45:42 2015] did you surround the pattern with parens? [Fri Jan 2 17:45:48 2015] is it a rewrite rule? [Fri Jan 2 23:24:49 2015] how can I specify multiple variables in [destruct ... with ...]? what's the proper syntax for [destruct H with (P:=P) (Q:=Q)]? [Fri Jan 2 23:25:04 2015] what do P and Q do in this context? [Fri Jan 2 23:25:17 2015] do you mean: destruct (H (P:=P) (Q:=Q)) [Fri Jan 2 23:25:50 2015] hi, johnw! [Fri Jan 2 23:25:52 2015] yes, that's probably the same thing. let me try that [Fri Jan 2 23:25:58 2015] oh, what do you mean by "do"? [Fri Jan 2 23:26:20 2015] wait [Fri Jan 2 23:26:21 2015] lol [Fri Jan 2 23:26:35 2015] I'm not sure how you want to "apply" P and to what [Fri Jan 2 23:26:45 2015] is it an argument to H? [Fri Jan 2 23:27:01 2015] so, [destruct H with (P:=P) (Q:=Q)] is the right syntax. I discovered it while asking the question :) [Fri Jan 2 23:27:14 2015] ah, ok [Fri Jan 2 23:27:25 2015] the other syntax probably works too [Fri Jan 2 23:27:50 2015] nope, it doesn't [Fri Jan 2 23:28:03 2015] k, good to know :) [Fri Jan 2 23:31:21 2015] unfortunately, that command doesn't do the right thing. I have this hypothesis: H : forall P Q : Prop, (P -> Q) -> (P -> False) \/ Q and my goal is Q. can I apply/simplify H somehow? [Fri Jan 2 23:31:58 2015] I don't think you can [Fri Jan 2 23:32:06 2015] since H needs Q in order to prove Q [Fri Jan 2 23:32:42 2015] so, do I need both P and Q in the context? [Fri Jan 2 23:32:54 2015] I have P and (P -> Q) -> P. [Fri Jan 2 23:32:56 2015] right now [Fri Jan 2 23:33:17 2015] I can't see any way of getting Q [Fri Jan 2 23:34:18 2015] okay, I'll figure it out. it's [implies_to_or -> peirce] from sf if you're interested in trying on your own [Fri Jan 2 23:34:48 2015] oh, you probably already proved it. I forgot that you're leading this race :) [Fri Jan 2 23:41:26 2015] yeah, so, there's a trick with that one [Fri Jan 2 23:41:37 2015] it lies in the fact that you can say what P is [Fri Jan 2 23:41:39 2015] hmm, turns out I can apply H to (P -> Q) -> P. [Fri Jan 2 23:41:54 2015] (both are in the context) [Fri Jan 2 23:42:10 2015] ah, I see my proof of it [Fri Jan 2 23:42:21 2015] I had to walk away from that one for months before I came back to it and did it [Fri Jan 2 23:42:32 2015] you can also say what Q is [Fri Jan 2 23:42:37 2015] hehe [Fri Jan 2 23:43:45 2015] proving some of these five theorems is mind-blowing in some way, it's like a maze of propositions [Fri Jan 2 23:44:01 2015] yeah [Fri Jan 2 23:48:17 2015] johnw that's nonsensical [Fri Jan 2 23:48:42 2015] stop confusing parameter names with types ! [Fri Jan 2 23:48:50 2015] the 2 qs are being used in diferent ways [Fri Jan 2 23:53:19 2015] I have H0: [(P -> Q) -> P] and H: [forall P Q : Prop, (P -> Q) -> (P -> False) \/ Q]. [apply H in H0] results in [((P -> Q) -> False) \/ P], so [Q] gets instantiated to [P], what is the instance of [P]? how does it work? [Fri Jan 2 23:53:58 2015] nkar: no, thats not whats hapening [Fri Jan 2 23:54:08 2015] oh, glad that I asked [Fri Jan 2 23:54:16 2015] could you explain then? [Fri Jan 2 23:54:17 2015] oh, wait [Fri Jan 2 23:54:26 2015] nkar: yes, Q is instantiated to P [Fri Jan 2 23:54:39 2015] nkar: P is instantiated to P -> Q [Fri Jan 2 23:57:27 2015] but why? I don't have [P -> Q], I have [(P -> Q) -> P] and [P] in the context. and I cannot apply the former to the latter (or the other way around). [Fri Jan 2 23:57:34 2015] huh? [Fri Jan 2 23:57:43 2015] nkar: you can appliy H to any 2 propositions [Fri Jan 2 23:57:45 2015] that's its type [Fri Jan 2 23:58:02 2015] nkar: a-are you unfamiliar with the curry-howard correspondence [Fri Jan 2 23:59:29 2015] I know what it is, but I cannot say that I'm familiar with it. [Sat Jan 3 00:00:09 2015] also, I understand that I can apply H to any 2 propositions. that's not what I'm asking about. [Sat Jan 3 00:00:22 2015] ok.. [Sat Jan 3 00:00:27 2015] nkar: remember, P and Q are just names in that hypothesis [Sat Jan 3 00:00:30 2015] free variables [Sat Jan 3 00:00:36 2015] yes, I understand that [Sat Jan 3 00:00:40 2015] you need to prove Q, and it has the form forall P. ... -> P [Sat Jan 3 00:03:00 2015] well, I'm still failing to follow. could you explain what happens when I apply H to H0? [Sat Jan 3 00:03:17 2015] what I'm saying is, what happens if you pass P:=Q [Sat Jan 3 00:03:53 2015] as in, destruct H with (P:=P) (Q:=P) [Sat Jan 3 00:03:59 2015] err [Sat Jan 3 00:04:02 2015] as in, destruct H with (P:=Q) (Q:=Q) [Sat Jan 3 00:04:12 2015] let me try this [Sat Jan 3 00:04:17 2015] one of those two [Sat Jan 3 00:05:38 2015] I get 3 subgoals either way. the current goal is either [P->P] or [Q->Q]. [Sat Jan 3 00:06:08 2015] well, that should be easy then :) [Sat Jan 3 00:06:14 2015] the other two both Q. [Sat Jan 3 00:06:34 2015] womp womp [Sat Jan 3 00:06:43 2015] anyway, this is the avenue I went down, so keep pushing [Sat Jan 3 00:08:38 2015] oh, but that doesn't answer my question: "what happens when I apply H to H0?" [Sat Jan 3 00:08:50 2015] I don't know the context to answer that question [Sat Jan 3 00:08:59 2015] i must have missed something [Sat Jan 3 00:09:34 2015] I have H0: [(P -> Q) -> P] and H: [forall P Q : Prop, (P -> Q) -> (P -> False) \/ Q]. [apply H in H0] results in [((P -> Q) -> False) \/ P], so [Q] gets instantiated to [P], what is the instance of [P]? how does it work? [Sat Jan 3 00:09:40 2015] that's my question [Sat Jan 3 00:10:06 2015] P is instantiated tp P -> Q [Sat Jan 3 00:10:27 2015] ah, I see [Sat Jan 3 00:10:30 2015] he's right [Sat Jan 3 00:10:38 2015] P:=(P -> Q) Q:=P [Sat Jan 3 00:11:30 2015] but I don't have P->Q in the context. isn't it required? [Sat Jan 3 00:11:53 2015] oh, maybe P:=((P -> Q) -> P) [Sat Jan 3 00:12:00 2015] actually, that makes more sense [Sat Jan 3 00:12:10 2015] apply H in H0 is the same thing as passing H0 as the first argument to H [Sat Jan 3 00:12:43 2015] okay, let me try to substitute step by step [Sat Jan 3 00:16:38 2015] I get forall Q : Prop, (((P->Q)->P) -> Q) -> (((P->Q)->P) -> False) \/ Q, how does coq instantiate [Q]? does it use the other hypothesis I have, that is, [H1: P]? [Sat Jan 3 00:16:51 2015] what I'm saying is, don't do that [Sat Jan 3 00:16:57 2015] try: specialize (H P P). [Sat Jan 3 00:17:20 2015] that's another way of passing arguments to a hypothesis with free variables in the context [Sat Jan 3 00:18:41 2015] sure, I can do that, but I'm still interested how it works. [Sat Jan 3 00:19:22 2015] my goal is not to prove this by any means, the process is also important. otherwise, I won't learn much. [Sat Jan 3 00:20:11 2015] that's the right spirit [Sat Jan 3 00:20:15 2015] so, then I've said enough [Sat Jan 3 00:20:30 2015] you should know enough now to figure it all out from here [Sat Jan 3 00:20:57 2015] lol, okay [Sat Jan 3 01:10:53 2015] okay, I proved it with [destruct with (P:=P) (Q:=P)], but I still don't understand the requirements for the instances of P and Q. do I need to have them in the context as P:Prop, Q:Prop, or what? [Sat Jan 3 01:11:23 2015] I'm sorry for reiterating, but I'd really like to understand this. [Sat Jan 3 01:22:20 2015] nkar: H is a function [Sat Jan 3 01:22:24 2015] you are providing it with arguments [Sat Jan 3 01:22:42 2015] forall is a keyword used to write function types [Sat Jan 3 01:25:08 2015] this is clear [Sat Jan 3 01:25:16 2015] forall = pi [Sat Jan 3 01:25:26 2015] maybe you are familiar with that notation [Sat Jan 3 01:25:31 2015] nope [Sat Jan 3 01:27:16 2015] nkar: were you sarcastically saying "this is clear" [Sat Jan 3 01:27:17 2015] or [Sat Jan 3 01:27:20 2015] do you already know this [Sat Jan 3 01:27:39 2015] not sarcastically [Sat Jan 3 01:34:01 2015] okay, I think I got it: I can pass any "combinations" of Props as long I've "considered" them (using [intros]) [Sat Jan 3 01:34:34 2015] yes [Sat Jan 3 01:34:50 2015] you can think about it in two ways: [Sat Jan 3 01:35:00 2015] typing [Sat Jan 3 01:35:39 2015] and math. Usually you start arguments saying "Let ..." [Sat Jan 3 01:38:05 2015] so, here's my H again: [forall P Q : Prop, (P -> Q) -> (P -> False) \/ Q]. if I use [destruct H with (P:=P->P->P->P) (Q:=Q->Q->Q).], the first subgoal becomes [P->P->P->P->Q->Q->Q], the second becomes [P], and the third also [P], why? [Sat Jan 3 01:38:40 2015] sorry, the first subgoal is [(P->P->P->P)->Q->Q->Q] [Sat Jan 3 01:39:29 2015] do you know what destruct does? [Sat Jan 3 01:40:12 2015] performs case analysis, but I was also told that in this case it's the same as applying a function. [Sat Jan 3 01:40:42 2015] [destruct b] where (b:bool) is clear to me, for instance [Sat Jan 3 01:40:59 2015] yea, I think it uses recursion on the type [Sat Jan 3 01:40:59 2015] an additional complication might be that we're destructing a hypothesis here [Sat Jan 3 01:41:02 2015] not the goal [Sat Jan 3 01:41:45 2015] I'm familiar with recursion, but what's "recursion on the type"? [Sat Jan 3 01:42:01 2015] suppose you have a type A [Sat Jan 3 01:42:19 2015] and you have another type, suppose B [Sat Jan 3 01:42:28 2015] if you want a function B->A [Sat Jan 3 01:42:40 2015] you usually use the recursion of A to construct it [Sat Jan 3 01:42:53 2015] something like induction, but nondependent [Sat Jan 3 01:43:31 2015] but a function is not just its type [Sat Jan 3 01:43:41 2015] nkar: for example, take the type Nat. it has constructors 0 : Nat, S : Nat->Nat [Sat Jan 3 01:43:42 2015] how can we "construct" it using just the type? [Sat Jan 3 01:45:38 2015] okay, I think I'm starting to understand, but I'm still failing to see how it's relevant to the "subgoals" question. [Sat Jan 3 01:45:50 2015] nkar: let me think about it [Sat Jan 3 01:46:10 2015] nkar: once you understand what destruct does in general, you will understand it [Sat Jan 3 01:47:11 2015] nkar: destruct on something that is a function will destruct the result, i believe [Sat Jan 3 01:47:24 2015] not sure [Sat Jan 3 01:47:31 2015] yes [Sat Jan 3 01:47:48 2015] destruct lets you "use" the result [Sat Jan 3 01:48:18 2015] yeah, I've done that in the goal before. maybe it's hard to follow because the hypothesis is too general. [Sat Jan 3 01:49:08 2015] like when I needed to get rid of the match statement. instead of performing induction on the argument of a function, I just destructed the whole thing. [Sat Jan 3 01:50:11 2015] yes, destruct is the nondependent version of the induction, so in finite types it let's you do case analysis; e.g. bool [Sat Jan 3 01:52:54 2015] will it be hard to explain nondependent in this context? I don't really know what a dependent type is other than quoting "it's a type that depends on its value," which may or may not be wrong. I haven't encountered any explanation in software foundations so far [Sat Jan 3 01:53:20 2015] w01:50 < godel> yes, destruct is the nondependent version of the induction, so in finite types it let's you do case analysis; e.g. bool [Sat Jan 3 01:53:23 2015] godel: what [Sat Jan 3 01:53:28 2015] i'm sorry what? [Sat Jan 3 01:53:33 2015] that's ridiculous [Sat Jan 3 01:53:40 2015] benzrf: why? [Sat Jan 3 01:53:48 2015] it has nothing to do with being dependent [Sat Jan 3 01:53:55 2015] maybe I said something stupid, I think that's correct [Sat Jan 3 01:54:08 2015] destruct vs induction is just induction gives you an induction hypothesis [Sat Jan 3 01:54:16 2015] nothing to do with dependent types [Sat Jan 3 01:54:47 2015] benzrf: I'm speaking strictly from a strictly type theoretically point of view [Sat Jan 3 01:55:03 2015] * does not know type theory [Sat Jan 3 01:55:07 2015] seriously, though [Sat Jan 3 01:55:16 2015] how is induction dependent in a way that destruct isnt ?! [Sat Jan 3 01:55:42 2015] benzrf: let me think how to explain (don't know much coq!!) [Sat Jan 3 01:56:54 2015] I have to go, thanks for the interesting conversation, at least for me :) [Sat Jan 3 01:57:10 2015] bye [Sat Jan 3 01:59:28 2015] benzrf: an example of the difference [Sat Jan 3 01:59:35 2015] consider the pair type [Sat Jan 3 01:59:42 2015] (a,b) : AxB [Sat Jan 3 01:59:54 2015] the recursion of that type es [Sat Jan 3 02:02:17 2015] rec_AxB : \forall C . (A->B->C) -> AxB -> C [Sat Jan 3 02:02:49 2015] so,give me a type C, give me a function of type A->B->C and I give you a function of type AxB -> C [Sat Jan 3 02:03:14 2015] That's why I said previously you use recursion to construct functions on the type [Sat Jan 3 02:04:02 2015] that's not recursion...? [Sat Jan 3 02:04:03 2015] now, induction on the other hand, has a much more complicated type signature [Sat Jan 3 02:04:09 2015] that's a destructor/eliminator [Sat Jan 3 02:04:19 2015] ok [Sat Jan 3 02:04:25 2015] and what do you call recursion benzrf? [Sat Jan 3 02:04:34 2015] when you recurse?? [Sat Jan 3 02:04:43 2015] it's just a name [Sat Jan 3 02:04:49 2015] recursion vs. induction [Sat Jan 3 02:05:07 2015] recursion is when you have a value defined in terms of itself [Sat Jan 3 02:05:12 2015] I don't really know the origin of the name, it is called like that [Sat Jan 3 02:05:17 2015] o.O [Sat Jan 3 02:05:26 2015] haha [Sat Jan 3 02:05:26 2015] anyway, induction is when the handler is passed a base case [Sat Jan 3 02:05:52 2015] mh [Sat Jan 3 02:06:04 2015] it depends on the type [Sat Jan 3 02:06:14 2015] the induction of Nat has a base case [Sat Jan 3 02:06:26 2015] the induction of product type (AxB) does not [Sat Jan 3 02:07:33 2015] it is not actually a "base case", it's just that way because of how Nat is constructed [Sat Jan 3 02:07:36 2015] 0 : Nat [Sat Jan 3 02:07:40 2015] S : Nat -> Nat [Sat Jan 3 02:07:56 2015] er [Sat Jan 3 02:07:56 2015] shit [Sat Jan 3 02:07:58 2015] not a base case [Sat Jan 3 02:08:01 2015] i meant an induction hypothesis [Sat Jan 3 02:08:18 2015] what do you mean by that? [Sat Jan 3 02:08:25 2015] induction hypotesis [Sat Jan 3 02:08:30 2015] ach [Sat Jan 3 02:08:33 2015] i dont have time for this [Sat Jan 3 02:08:36 2015] i need to sleep [Sat Jan 3 02:08:37 2015] haha [Sat Jan 3 02:08:39 2015] ok [Sat Jan 3 02:08:46 2015] let's continue tomorrow [Sat Jan 3 02:08:58 2015] I'm deeply interested on this [Sat Jan 3 16:20:26 2015] is this a recommended way of approaching topology in coq https://gist.github.com/andrejbauer/d31e9666d5f950dd8ccd [Sat Jan 3 16:23:51 2015] benzrf: it seems good [Sat Jan 3 16:23:57 2015] you can try HoTT too [Sun Jan 4 07:52:14 2015] Hiya! [Sun Jan 4 07:53:54 2015] I have a very basic question : If I try "Section streams. Variable A : Type. CoInductive stream : Type := | Cons : A -> stream -> stream. End streams. CoFixpoint trues_falses : stream bool := Cons true falses_trues" I keep getting the error The term "0" has type "nat" while it is expected to have type "Type". [Sun Jan 4 07:54:26 2015] Even though I got the code from http://adam.chlipala.net/cpdt/html/Coinductive.html [Sun Jan 4 07:54:36 2015] Anybody know what's wrong? [Sun Jan 4 07:56:32 2015] Sorry I mean with "CoFixpoint zeroes : stream nat := Cons 0 zeroes. " [Sun Jan 4 08:02:15 2015] never mind I fixed it :) [Sun Jan 4 08:15:29 2015] Apperantly it is fixed by set implicit arguments [Sun Jan 4 11:32:14 2015] H: true = false goal true = false. Which tactic disregards this case because the hypothesis is not satisfied? [Sun Jan 4 11:33:04 2015] MarcWeber: inversion. [Sun Jan 4 11:33:53 2015] MarcWeber: but also since the goal is the same as the hypothesis you can just use exact H. [Sun Jan 4 13:39:12 2015] MarcWeber: to elaborate a bit, when a hypothesis doesn't make sense, any goal can be proved, so inversion moves to the next one (if any). [Sun Jan 4 14:01:15 2015] MarcWeber: discriminate [Sun Jan 4 14:01:37 2015] which I believe inversion applies to every subgoal to eliminate the impossibles [Sun Jan 4 14:01:59 2015] discriminate says that an equality between different constructors is the same as False [Sun Jan 4 14:02:37 2015] hi, johnw. how's linearscan going? [Sun Jan 4 14:03:13 2015] I'm at the point now of writing tests in Haskell to confirm correctness of the extracted library [Sun Jan 4 14:03:31 2015] I have 9 out of 10 tests working, and after I fixed the 10th one today am going to integrate the library into our real compiler [Sun Jan 4 14:03:46 2015] after that, if it's able to work on simple code examples, I will then start creating trickier tests [Sun Jan 4 14:03:57 2015] which compiler? [Sun Jan 4 14:04:15 2015] a private in-house compiler at the moment, but which will be released on github at some point soon [Sun Jan 4 14:04:25 2015] sweetness! [Sun Jan 4 14:04:29 2015] it targets a custom machine architecture that we've been working on [Sun Jan 4 14:04:54 2015] is it releated to the crash-safe project? [Sun Jan 4 14:05:01 2015] johnw mmix ? (i dream to see a real one of that !) [Sun Jan 4 14:05:10 2015] haha [Sun Jan 4 14:05:20 2015] no, this: http://www.crash-safe.org [Sun Jan 4 14:05:42 2015] this project is the state of the art [Sun Jan 4 14:05:47 2015] so cool [Sun Jan 4 14:06:04 2015] it was a DARPA contract, in its last months now [Sun Jan 4 14:24:40 2015] johnw tagged architecture ,as for the TADD instruction from the SPARC ISA ? [Sun Jan 4 14:25:14 2015] I'm not familiar with that [Sun Jan 4 14:25:30 2015] tagged as in every word in memory has an associated word that contains tagging information [Sun Jan 4 14:25:55 2015] and the CPU has an execution policy that examines tags before executing instructions [Sun Jan 4 14:26:46 2015] things like, "if it's not tagged as a pointer, you can't dereference it; and if it is, the tag indicates the memory block it's allowed to point to" [Sun Jan 4 14:27:34 2015] johnw ok. it is the same, originated from the first Lisp machines : the tag were used to identify a content or a pointer to another cell. [Sun Jan 4 14:27:51 2015] yep [Sun Jan 4 14:27:52 2015] sadly, the ocaml compiler for sparc doesn't use them. [Sun Jan 4 15:23:36 2015] benzrf, nkar, johnw: both inversion and discriminate worked fine in my case. exact didn't apply because H wasn't the goal exactly. [Sun Jan 4 15:24:46 2015] MarcWeber: if you need more examples of using inversion, the software foundations book has some [Sun Jan 4 15:25:37 2015] (it does more than just disregarding the goal) [Sun Jan 4 15:55:37 2015] I guess there is a long way to go .. Going through: http://www.seas.upenn.edu/~cis500/current/sf/Basics.html at the moment. Will be looking at the software foundations book later. [Sun Jan 4 15:56:45 2015] http://dpaste.com/15FP09J What's wrong with this recursive definition line 17 ? [Sun Jan 4 15:56:54 2015] | TP bn' => bnat_to_nat(T bn') + 1 [Sun Jan 4 16:11:40 2015] MarcWeber: in Fixpoint, you're only allowed to perform a recursive call on bn', i.e., something that's less the argument you're matching on. (I hope I've not worded this poorly.) [Sun Jan 4 16:12:08 2015] it's explained in software foundations when fixpoint is used for the first time [Sun Jan 4 16:12:09 2015] Thus coq forces termination this way? [Sun Jan 4 16:12:12 2015] yes [Sun Jan 4 16:14:08 2015] You can also prove to Coq that a function which does not recurse on a structural subterm does terminate, but it’s fairly complicated. Adam goes into it in the ‘well-founded recursion’ section of CPDT. [Sun Jan 4 16:15:28 2015] cool [Sun Jan 4 18:42:29 2015] how does derivation of False from O = S O work [Sun Jan 4 18:42:34 2015] term-wise [Sun Jan 4 18:42:52 2015] is there an axiom? [Sun Jan 4 18:43:04 2015] do you match on the eq_refl argument and do something weird with it? [Sun Jan 4 18:43:55 2015] You can check it if you want: [Goal 0 = 1 -> False. intro H. inversion H. Show Proof.] [Sun Jan 4 18:44:37 2015] benzrf: it uses the elimination principle of equality to replace O with S O in a dependent pattern match where one of the branch requires a proof of True and the other one a proof of False [Sun Jan 4 18:44:39 2015] crud [Sun Jan 4 18:44:50 2015] so you can provide the proof of True (I) to build a proof of False [Sun Jan 4 18:44:53 2015] Ptival: hmm [Sun Jan 4 18:45:08 2015] benzrf: The trick is to define a function that sends 0 to True and 1 to False. Since, to prove f 1, it suffices to prove f 0 (assuming 0 = 1), you can prove f 0 = True by I. [Sun Jan 4 18:45:50 2015] oh neat [Sun Jan 4 18:46:32 2015] * ponders for a moment [Sun Jan 4 18:46:49 2015] jgross: hm, you mean [Sun Jan 4 18:47:06 2015] by "prove f 1" you mean "proof : f 1" [Sun Jan 4 18:47:48 2015] yes [Sun Jan 4 18:49:14 2015] kk [Sun Jan 4 18:49:17 2015] cool [Sun Jan 4 18:49:37 2015] so... [Sun Jan 4 18:50:13 2015] ah, i see [Sun Jan 4 18:50:27 2015] it only works when you have x = y where x and y may be differentiated by pattern matching [Sun Jan 4 18:50:32 2015] so you can make one return True and one False [Sun Jan 4 18:50:47 2015] Yes [Sun Jan 4 18:50:58 2015] Yes, this is basically what inversion does: if the constructors of x and y are different, it derives False [Sun Jan 4 18:51:30 2015] sooo [Sun Jan 4 18:51:41 2015] t := (fun n : nat => match n with | O => True | S _ => False end) O [Sun Jan 4 18:51:52 2015] proof : t := I [Sun Jan 4 18:52:32 2015] er, hm [Sun Jan 4 18:52:36 2015] ok, so from there you can derive False = True [Sun Jan 4 18:52:43 2015] and from there you can convert types [Sun Jan 4 18:52:44 2015] coool [Sun Jan 4 18:53:28 2015] ah, how does one actually implement eq_ind [Sun Jan 4 18:53:30 2015] jgross: hello! [Sun Jan 4 18:53:36 2015] johnw: Hi! [Sun Jan 4 18:53:40 2015] jgross: are you in Boston area the week of the 26th? [Sun Jan 4 18:53:45 2015] hey i met both of u irl [Sun Jan 4 18:54:11 2015] benzrf: :) [Sun Jan 4 18:55:44 2015] benzrf: eq_ind is kind-of primitive. The definition of equality is that, given (x : A), (f : forall y, x = y -> Type), and pf : f x refl, you are given, for any y and (p : x = y), a proof of f y p, and this function is called eq_ind. [Sun Jan 4 18:56:14 2015] benzrf: In Coq, all of the induction principles are aggregated in terms of the primitive [match] (and [fix], for recursive ones) [Sun Jan 4 18:56:31 2015] yeah [Sun Jan 4 18:56:33 2015] well i mean [Sun Jan 4 18:56:40 2015] i see that eq_ind is primitive, theory wise [Sun Jan 4 18:56:49 2015] but in coq specifically, can't you implement it [Sun Jan 4 18:57:05 2015] so eq_ind is just [match (p : x = y) as p' in (_ = y') return (P y' p') with eq_refl => (pf : P x eq_refl) end] [Sun Jan 4 18:57:10 2015] hmm [Sun Jan 4 18:57:29 2015] er, what's the as and in [Sun Jan 4 18:57:43 2015] Things that let you change the return type. dependent pattern matching [Sun Jan 4 18:58:13 2015] how are they used [Sun Jan 4 18:58:17 2015] johnw: I will be away Jan 6 -- Jan 30, in Munich -> Mumbai -> Bristol -> Seattle -> San Francisco [Sun Jan 4 18:58:27 2015] What's the week of the 26th? [Sun Jan 4 18:59:08 2015] me visiting Boston [Sun Jan 4 18:59:15 2015] wanted to see if I could grab dinner with you and edwardk [Sun Jan 4 18:59:41 2015] jgross: th-that seems a little bit roundabout [Sun Jan 4 19:00:00 2015] er, wait [Sun Jan 4 19:00:15 2015] what bristol is this [Sun Jan 4 19:00:49 2015] benzrf: [match as new_arg_name in ( ) return () with constructors => cases (with new time, but with the constructor plugged in) end] [Sun Jan 4 19:01:23 2015] :O [Sun Jan 4 19:01:24 2015] benzrf: the one in the UK. I am going to Mumbai for POPL, and scheduled a bunch of friend-visiting around that. [Sun Jan 4 19:01:31 2015] huh [Sun Jan 4 19:01:53 2015] er, s/new time/new type/ [Sun Jan 4 19:02:04 2015] it seems like it'd be more convenient to go to bristol, THEN munich [Sun Jan 4 19:02:14 2015] purely in terms of geographical distance [Sun Jan 4 19:03:15 2015] jgross: `as' is like @ in haskell? [Sun Jan 4 19:03:19 2015] er, wait nvm [Sun Jan 4 19:04:03 2015] benzrf: yes, I think so [Sun Jan 4 19:04:16 2015] it goes in a different place :u [Sun Jan 4 19:04:24 2015] what are indicies [Sun Jan 4 19:04:26 2015] *indices [Sun Jan 4 19:04:46 2015] Well, @ is for binding the name at in each branch, while `as` is for binding it in the type [Sun Jan 4 19:05:52 2015] quoting http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Data, in "data Vec (A : Set) : ℕ → Set where", A is a parameter, (n : ℕ) is an index [Sun Jan 4 19:06:06 2015] johnw: too bad that I won't be around then [Sun Jan 4 19:07:05 2015] hmmmmmmmmm [Sun Jan 4 19:07:07 2015] ok [Sun Jan 4 19:07:31 2015] so "in" is for pattern matching on the type of the input? [Sun Jan 4 19:08:18 2015] yes, that is really too bad [Sun Jan 4 19:08:35 2015] benzrf: no, it's to bind the type indices to use in the return type annotation [Sun Jan 4 19:09:13 2015] uuuuuh [Sun Jan 4 19:09:19 2015] hmmmm [Sun Jan 4 19:09:27 2015] match x == y as E in x + 1 return nat where ... [Sun Jan 4 19:09:40 2015] is that right? [Sun Jan 4 19:10:06 2015] o.O [Sun Jan 4 19:10:08 2015] benzrf: about indices, I wrote that answer which might help you http://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Sun Jan 4 19:11:19 2015] oh, no, that's not right what I wrote [Sun Jan 4 19:11:50 2015] when you pattern match a value which belongs in an indexed type family, you can give a name to the index in the "in" clause, so that you can refer to the particular index of that value in the "return" clause [Sun Jan 4 19:12:51 2015] say: match f in Fin n return Fin (S n) [Sun Jan 4 19:20:53 2015] o.O [Sun Jan 4 19:20:59 2015] so.. [Sun Jan 4 19:21:03 2015] 07:07 < benzrf> so "in" is for pattern matching on the type of the input? [Sun Jan 4 19:21:09 2015] er, not pattern matching [Sun Jan 4 19:21:19 2015] i meant pattern matching in the sense of [Sun Jan 4 19:21:32 2015] destructing a value and binding its constituents [Sun Jan 4 19:24:51 2015] well with in you're really binding the constituents of its type [Sun Jan 4 19:26:30 2015] i [Sun Jan 4 19:26:54 2015] Ptival: ye, the value in question is the type of the thing being pattern matched on [Sun Jan 4 19:29:58 2015] benzrf: oh I see what you mean, I guess yes, but you may only bind indices, not parameters, and it is only binding, there is no pattern [Sun Jan 4 19:31:12 2015] oh, coq formally differentiates? [Sun Jan 4 19:45:23 2015] benzrf: well, they feel different, in that the value matching is actually a call to the eliminator, while the return type thing has no computation content and is just there for type-checking? [Sun Jan 4 19:45:53 2015] Ptival: er, i mean coq formally differentiates between indices and params [Sun Jan 4 19:46:59 2015] benzrf: oh yes [Sun Jan 4 19:52:28 2015] Ptival: how so [Sun Jan 4 20:00:00 2015] hmm [Sun Jan 4 20:00:17 2015] any idea why coqide crashes in the open-file dialog in linux mint cinammon? [Sun Jan 4 20:02:50 2015] If I have a hypothesis for a(x) but x is a term, how to substitute the term to apply the hypothesis? [Sun Jan 4 20:47:16 2015] seven hells [Sun Jan 4 20:47:21 2015] on linux now, same issue [Sun Jan 4 20:47:23 2015] "COQC -nois theories/Init/Notations.v" [Sun Jan 4 20:47:25 2015] freezes [Sun Jan 4 20:47:54 2015] ah no it works [Sun Jan 4 20:48:08 2015] funny [Sun Jan 4 20:53:47 2015] uhm [Sun Jan 4 20:53:47 2015] File "/home/skraeling/Downloads/coq-8.4pl5/theories/Init/Datatypes.v", line 13, characters 0-38: [Sun Jan 4 20:53:48 2015] Error: interface mismatch on Environ [Sun Jan 4 20:53:49 2015] wtf [Sun Jan 4 20:56:20 2015] Based on https://github.com/coq/coq/blob/V8.4/theories/Init/Datatypes.v#L13, it sounds like either (a) the version of OCaml you used to compile nat_syntax_plugin is different from the version of OCaml you used to compile Coq, or (b), it's picking up nat_syntax_plugin from a different vesion of Coq than the one you're currently using. [Sun Jan 4 20:57:06 2015] oh [Sun Jan 4 20:57:08 2015] thanks a lot [Sun Jan 4 20:57:20 2015] i fear i need to update more dependencies [Sun Jan 4 20:57:30 2015] ("Interface mismatch on Environ" translates, roughly, to "I have two components here, both written in OCaml, and they diagree on what Environ is supposed to export") [Sun Jan 4 20:58:03 2015] wut, synaptic shows ocaml as not installed? [Sun Jan 4 20:58:24 2015] is 4.01.0-3 correct? [Sun Jan 4 20:59:31 2015] In this case, Environ is kernel/environ.ml(i). So it means that nat_syntax_plugin and coqc are linking with different versions of the Coq source file kernel/environ.mli. [Sun Jan 4 21:00:31 2015] What do you mean by "correct"? Any version is fine (well, as long as it's new enough, and not too new, but 4.01.0-3 is probably fine), as long as you use the same version on all the files. If you upgraded half way through the build, you'll have to blow away all the old files and rebuild them. [Sun Jan 4 21:00:58 2015] oh [Sun Jan 4 21:01:10 2015] hmm [Sun Jan 4 21:01:17 2015] ./configure says "You have Objective-Caml 4.01.0. Good!" [Sun Jan 4 21:01:27 2015] let's hope it's the right one [Sun Jan 4 21:02:32 2015] (Note that you might have to `make clean`, or even `make distclean`, and not just re-configure and re-make.) [Sun Jan 4 21:02:38 2015] what package should i get to make it recognize lablgtk? [Sun Jan 4 21:02:42 2015] i know, i just did the distclean [Sun Jan 4 21:03:10 2015] liblablgtk, or liblablgtk2, IIRC? [Sun Jan 4 21:03:51 2015] oh fuck [Sun Jan 4 21:03:53 2015] latex isn't installed :/ [Sun Jan 4 21:03:57 2015] Google is suggesting liblablgtk2-ocaml-dev might be the right one. [Sun Jan 4 21:04:11 2015] thank you [Sun Jan 4 21:04:20 2015] Just pass configure, uh, -nodoc? or was it -doc no? (--help will tell you) [Sun Jan 4 21:04:29 2015] i'd rather install it [Sun Jan 4 21:04:48 2015] ok now that seems to be easier than i thought [Sun Jan 4 21:15:38 2015] still getting the mismatch :( [Sun Jan 4 21:48:53 2015] w00t, ordered HoTT hardcover book. I have already a free digital copy, but in many ways I'm more likely to read a dead tree. [Mon Jan 5 03:56:05 2015] are there any ssreflect users who could help me with the proof of: [Mon Jan 5 03:56:07 2015] forall (a b : eqType) (i : b) (xs : seq (a * b)), all (fun x => (x, i) \in xs) [seq fst x | x <- xs & snd x == i] [Mon Jan 5 03:56:28 2015] I feel like this should be a simple rewriting proof, but I don't know this part of ssreflect very well yet [Mon Jan 5 07:29:10 2015] Hi all! I have a very basic question, what does "~=" mean and how can I find out? [Mon Jan 5 07:30:17 2015] It is generated from dependent induction [Mon Jan 5 07:32:03 2015] Got it "Coq.Program.Equality" [Mon Jan 5 07:32:19 2015] Still, how do I check the type of an infix operator? [Mon Jan 5 08:01:54 2015] Anybody know where I can find this lemma: "forall {F : Set -> Set } {x y : Set}, F x = F y -> x = y." [Mon Jan 5 08:03:47 2015] Is this true? :o [Mon Jan 5 08:04:05 2015] :P [Mon Jan 5 08:04:14 2015] Would be suprised if not. [Mon Jan 5 08:04:42 2015] O wait [Mon Jan 5 08:04:50 2015] You're right [Mon Jan 5 08:04:57 2015] only if F is injective... [Mon Jan 5 08:05:14 2015] hmm [Mon Jan 5 09:10:47 2015] so [Mon Jan 5 09:10:57 2015] what does HoTT net you over standard CoC-type stuff [Mon Jan 5 09:11:09 2015] and at what level of foundation is it? [Mon Jan 5 09:11:30 2015] like would it replace CoC or would it be a layer on top of it or what? [Mon Jan 5 09:11:40 2015] * is a total newb [Mon Jan 5 09:47:28 2015] jgross: thanks a lot [Mon Jan 5 09:47:42 2015] you were right, some remains of a previous install were haunting ocaml [Mon Jan 5 16:12:20 2015] why cant i extract the value in an eq_refl [Mon Jan 5 16:12:26 2015] is it because it lives in Prop [Mon Jan 5 16:13:47 2015] * is trying to trick coq into telling him what value is stored in a proof of x = y [Mon Jan 5 16:14:51 2015] oooooooooooooooooooooooooohhhhhhhhhhh i see [Mon Jan 5 16:15:24 2015] there *is* no value in the constructor, it's a parameter and not an index [Mon Jan 5 16:15:26 2015] right??? [Mon Jan 5 16:33:06 2015] a proof of x = y is different from { p : (a * b) | let (x, y) := p in x = y } [Mon Jan 5 16:33:46 2015] although i wonder if you can't get the info back [Mon Jan 5 16:33:47 2015] let me try [Mon Jan 5 16:34:21 2015] actually [Mon Jan 5 16:34:29 2015] in order to even talk about "x = y", you must have x and y in scope [Mon Jan 5 16:34:42 2015] since that type (x = y) depends on those values [Mon Jan 5 16:34:56 2015] benzrf: or is that not your question? [Mon Jan 5 16:35:41 2015] er, a value of type x = y [Mon Jan 5 16:35:52 2015] (where x and y are existential, not universal!) [Mon Jan 5 16:35:58 2015] johnw: the value contains no values, right? [Mon Jan 5 16:36:03 2015] it's a nullary constructor [Mon Jan 5 16:36:48 2015] because the value argument is a PARAMETER, not an INDEX [Mon Jan 5 16:36:54 2015] y/n? [Mon Jan 5 16:37:48 2015] what do you mean by "existential, not universal"? [Mon Jan 5 16:37:51 2015] can you show me code? [Mon Jan 5 16:38:01 2015] code always makes more sense than interpretation [Mon Jan 5 16:38:01 2015] like x and y are concrete values [Mon Jan 5 16:38:05 2015] i.e., [Mon Jan 5 16:38:17 2015] p : 3 = (2 + 1) [Mon Jan 5 16:38:17 2015] what "value" is it you're looking to find? [Mon Jan 5 16:38:28 2015] p contains no values [Mon Jan 5 16:38:31 2015] eq_refl is nullary [Mon Jan 5 16:38:35 2015] right [Mon Jan 5 16:38:37 2015] kk [Mon Jan 5 16:38:38 2015] but the type refers to values [Mon Jan 5 16:38:41 2015] yes [Mon Jan 5 16:38:48 2015] and those you can recover [Mon Jan 5 16:38:52 2015] i mean you can't pattern match on eq_refl to extract the index :) [Mon Jan 5 16:39:04 2015] because it's a parameter [Mon Jan 5 16:39:11 2015] well [Mon Jan 5 16:39:16 2015] eq_refl has both a parameter *and* an index [Mon Jan 5 16:39:19 2015] Inductive eq (A : Type) (x : A) : A -> Prop := eq_refl : x = x [Mon Jan 5 16:39:28 2015] they just have to be the same, per the constructor [Mon Jan 5 16:39:39 2015] wait, whaa [Mon Jan 5 16:39:54 2015] oh [Mon Jan 5 16:39:56 2015] hmmmm [Mon Jan 5 16:40:17 2015] hhhhhhhmmmmmmmmmmMMMMMMMMMM [Mon Jan 5 16:40:23 2015] see, i thought it was like: [Mon Jan 5 16:41:06 2015] er, 1 sec [Mon Jan 5 16:41:18 2015] Inductive eq : forall A : Type, A -> A -> Prop := [Mon Jan 5 16:41:38 2015] | eq_refl : forall (A : Type) (x : A), eq A x x. [Mon Jan 5 16:41:38 2015] You can't destruct prop into anything but a prop. [Mon Jan 5 16:41:59 2015] yeah, that's not eq [Mon Jan 5 16:42:09 2015] it's what i thought it was though :p [Mon Jan 5 16:42:14 2015] why not check the type? [Mon Jan 5 16:42:25 2015] C-c C-a C-p in Emacs [Mon Jan 5 16:42:28 2015] i did, but i didn't understand indices [Mon Jan 5 16:42:32 2015] ah [Mon Jan 5 16:42:33 2015] er, [Mon Jan 5 16:42:37 2015] i checked the type of eq_refl [Mon Jan 5 16:42:41 2015] ianjneu: I've run into that many a time [Mon Jan 5 16:42:45 2015] but i didnt understand that constructors can have arguments that arent fields [Mon Jan 5 16:42:54 2015] ianjneu: but you're right, I can't just recover the non-Prop value [Mon Jan 5 16:43:15 2015] i came back to it after reading another page of SF that happened to explain that, and realized 8D [Mon Jan 5 16:43:28 2015] The Prop/Type distinction is one of the weakest forms of contextual type. [Mon Jan 5 19:22:00 2015] question [Mon Jan 5 19:22:35 2015] could eq as a type somehow be feasible as a means of comparison in a practical dependently-typed language [Mon Jan 5 19:22:56 2015] like, dispatching on if you can prove equality with a trivial reflexivity attempt? [Mon Jan 5 19:23:14 2015] well i guess that would be compile time... nvm [Mon Jan 5 20:23:06 2015] hmmmmmmmmmmm [Mon Jan 5 20:23:37 2015] it just occurred to me that euclid's proof of the infinitude of primes is by contradiction [Mon Jan 5 20:24:03 2015] is there a constructive proof or something [Mon Jan 5 20:26:07 2015] benzrf: there is a constructive proof... [Mon Jan 5 20:26:10 2015] benzrf: of the last prime. [Mon Jan 5 20:26:13 2015] * stabs benzrf fatally [Mon Jan 5 20:27:25 2015] hodapp: that's a joke, right [Mon Jan 5 20:27:31 2015] This proof is actually constructive, isn't it? Given any finite set of primes, you consider their product plus one. Then you find any prime that divides this number, it's a new prime number. [Mon Jan 5 20:27:44 2015] Cypi: huh? [Mon Jan 5 20:27:51 2015] Cypi: hmm [Mon Jan 5 20:28:02 2015] hmm! [Mon Jan 5 20:28:05 2015] well, I don't know that that tells you how to construct that number, does it? [Mon Jan 5 20:28:12 2015] hodapp: no, it does [Mon Jan 5 20:28:19 2015] hodapp: you only need to scan the section of the nats [Mon Jan 5 20:28:26 2015] below the product [Mon Jan 5 20:28:32 2015] and if you find nothing, then it's prime [Mon Jan 5 20:28:41 2015] either way you have a new prime [Mon Jan 5 20:29:11 2015] "Although the proof as a whole is not by contradiction (it does not assume that only finitely many primes exist), a proof by contradiction is within it, which is that none of the initially considered primes can divide the number q above." [Mon Jan 5 20:29:25 2015] hodapp: it doesnt? [Mon Jan 5 20:29:47 2015] hodapp: anyway DNE works on certain kinds of propositions [Mon Jan 5 20:29:53 2015] What's the number q in your quote? [Mon Jan 5 20:30:04 2015] it's from https://en.wikipedia.org/wiki/Euclid%27s_theorem#Euclid.27s_proof [Mon Jan 5 20:30:07 2015] ~~(x = y) -> x = y where x y : nat [Mon Jan 5 20:30:15 2015] or so i am told [Mon Jan 5 20:30:52 2015] How is that a proof by contradiction? [Mon Jan 5 20:31:10 2015] There are two kinds of proofs that start by assuming something, and then concluding absurdity. Proofs of negations, such as the infinitude of primes, can be constructive; you are proving that "only finitely many primes -> False". Proofs properly called "by contradiction" use double negation elimination, and tend to not be constructive. [Mon Jan 5 20:35:55 2015] jgross: the first time i read the difference i was horribly confused for about 5 minutes before i spotted the DNE [Mon Jan 5 20:36:29 2015] What's "DNE"? [Mon Jan 5 20:39:01 2015] Double Negation Elimination [Mon Jan 5 20:41:07 2015] Q: why are the chalkboards in the intuitionistic math department always in flux? [Mon Jan 5 20:41:11 2015] A: they don't believe in DNE [Mon Jan 5 20:41:24 2015] er, logic [Mon Jan 5 20:42:21 2015] Kind of like the joke about the comp sci and math departments. [Mon Jan 5 20:44:31 2015] eraserhd: oh? [Mon Jan 5 20:45:48 2015] The heads of three departments are standing around, and the comp sci person laments, "it is so expensive to run a comp sci program - the lab costs a quarter million dollars for all the computers, the paper, the pencils, the erasers, the wastebaskets" [Mon Jan 5 20:46:54 2015] The math person, "what a scam. to run a good math program, all you need is the paper, the pencils, the erasers, and the wastebaskets." [Mon Jan 5 20:47:08 2015] The philosophy head said, "heh, you guys need erasers and wastebaskets..." [Mon Jan 5 20:48:00 2015] lel [Mon Jan 5 20:48:05 2015] i think i heard that before [Mon Jan 5 20:48:33 2015] It's pretty old. [Tue Jan 6 06:58:48 2015] gosh... not even sage takes this long to compile :( [Tue Jan 6 07:33:28 2015] Can someone explain the channel topic to me? Like the link? I don't understand. [Tue Jan 6 08:50:27 2015] m4farrel: the link is probably obsolete [Tue Jan 6 08:50:38 2015] but the feit-thompson theorem was formalized in coq by gonthier and his group a while ago [Tue Jan 6 08:51:04 2015] see http://mathoverflow.net/questions/164959/how-do-i-verify-the-coq-proof-of-feit-thompson [Tue Jan 6 09:01:25 2015] how-do-i-verify-coq [Tue Jan 6 09:04:21 2015] arvisrend: wait until you try bedrock [Tue Jan 6 09:04:32 2015] that is my new benchmark for length of compile time [Tue Jan 6 09:26:31 2015] the feeling when make is done compiling and you are looking for the error that made it stop [Tue Jan 6 09:26:52 2015] hahaha [Tue Jan 6 09:26:57 2015] some days I live in that state [Tue Jan 6 09:30:18 2015] is /usr/coqide the right way to start coqide? [Tue Jan 6 09:31:21 2015] that sounds wrong [Tue Jan 6 09:31:29 2015] I would expect /usr/bin/coqide [Tue Jan 6 09:33:55 2015] nope, it's /usr/coqide [Tue Jan 6 09:34:00 2015] it just took a minute until it loaded :) [Tue Jan 6 09:34:04 2015] maybe i ./configured it wrongly [Tue Jan 6 09:35:56 2015] hmm [Tue Jan 6 09:36:00 2015] it's taking a minute again [Tue Jan 6 09:36:01 2015] not good [Tue Jan 6 09:38:05 2015] buggering hell [Tue Jan 6 09:38:18 2015] something has snatched the ctrl+alt+down key combo from coqide [Tue Jan 6 09:38:32 2015] apparently cinnamon makes it its alt-tab [Tue Jan 6 09:38:53 2015] also it doesn't work :( [Tue Jan 6 09:43:54 2015] ok, back to binary build [Tue Jan 6 09:44:01 2015] coqide still crashes on file/open [Tue Jan 6 09:44:10 2015] any idea where and how to report such a thing? [Tue Jan 6 09:44:24 2015] funnily, file/save as work [Tue Jan 6 09:44:30 2015] but file/open and file/save crash [Tue Jan 6 09:45:19 2015] argh [Tue Jan 6 09:45:30 2015] it segfaults when not started with superuser rights [Tue Jan 6 09:45:36 2015] coqide y u need superuser right [Tue Jan 6 09:47:54 2015] whoa [Tue Jan 6 09:47:58 2015] scary [Tue Jan 6 09:48:38 2015] it might be because of some stuff like external drives which pop up in the dialog [Tue Jan 6 09:48:39 2015] still weird [Tue Jan 6 09:48:45 2015] also i don't think gimp has this issue [Tue Jan 6 09:49:02 2015] that's just wrong [Tue Jan 6 09:56:35 2015] https://coq.inria.fr/bugs/show_bug.cgi?id=3902 now [Tue Jan 6 09:58:15 2015] nice :) [Tue Jan 6 10:04:50 2015] where does the coq lib usually live under linux? [Tue Jan 6 10:05:22 2015] oh /usr/lib/coq [Tue Jan 6 10:05:27 2015] at least the binary version does this one right [Tue Jan 6 10:06:21 2015] Hi ! Is it possible to add an extra HTML header in the coqdoc output ? [Tue Jan 6 10:06:34 2015] (I would like to add mathjax) [Tue Jan 6 11:57:14 2015] can i ignore these? [Tue Jan 6 11:57:20 2015] Warning: Overwriting previous delimiting key bool in scope bool_scope [Tue Jan 6 11:57:21 2015] Warning: No global reference exists for projection valuefun [Tue Jan 6 11:57:21 2015] x : pred [Tue Jan 6 11:57:21 2015] _UNBOUND_REL_1 => [Tue Jan 6 11:57:21 2015] x in instance predPredType of topred, ignoring it. [Tue Jan 6 11:57:26 2015] when require-importing parts of ssreflect [Tue Jan 6 11:58:07 2015] yeah, I do [Tue Jan 6 12:18:10 2015] question [Tue Jan 6 12:18:25 2015] if you say that term s unifies with term t [Tue Jan 6 12:18:39 2015] does that mean that "the substitutions necessary to turn s into t are valid"? [Tue Jan 6 12:18:49 2015] or does it mean either that or t into s? [Tue Jan 6 12:18:54 2015] or something else entirely [Tue Jan 6 13:27:31 2015] n-never mind [Tue Jan 6 14:01:20 2015] File "src/ssrmatching.mli", line 4, characters 0-11: [Tue Jan 6 14:01:20 2015] Error: Unbound module Genarg [Tue Jan 6 15:49:18 2015] benzrf: it means that s and t trivially evaluate to equality [Tue Jan 6 22:21:58 2015] roconnor: welcome! [Tue Jan 6 22:22:15 2015] so, I need to model an assembly language IR [Tue Jan 6 22:22:30 2015] IR? [Tue Jan 6 22:22:35 2015] I have a list of basic blocks, where each block has zero or more instructions (I think I can restruct this to one or more) [Tue Jan 6 22:22:40 2015] intermediate representation [Tue Jan 6 22:22:45 2015] sorry, LLVM calls it an IR [Tue Jan 6 22:23:02 2015] ok [Tue Jan 6 22:23:23 2015] so, sometimes I want to view this is a list of "blocks containings instructions", and sometimes I want to view it as a "sequence of instructions", like a view over the list of blocks [Tue Jan 6 22:23:45 2015] however, I need to apply some knowledge, like that the "address" of each instruction is one more than the previous one, no matter which block that previous one happens to be in [Tue Jan 6 22:24:30 2015] so, I have a list of ops, and a block with a list of ops, and my thought right now is to parameterize the block on the list of ops, so that i can relate two blocks [Tue Jan 6 22:24:51 2015] and then have a BlockList inductive type which can establish invariants on the whole chain of operations [Tue Jan 6 22:24:58 2015] so my type right now is: [Tue Jan 6 22:25:02 2015] Inductive BlockList : seq { ops : seq (OpData opType) & BlockData ops } -> Prop := [Tue Jan 6 22:25:16 2015] but I'm at that point of wondering whether I'm inviting a world of pain that I won't know about until next week.... [Tue Jan 6 22:25:23 2015] so what would an ssreflecter recommend? [Tue Jan 6 22:26:25 2015] I tried doing this without dependent types, btw, and ran into lots of problems [Tue Jan 6 22:26:46 2015] the resulting BlockList just didn't have enough structure for me to reason about its contents [Tue Jan 6 22:27:25 2015] if this is too out of left field for you to think about right now, just let me know and I'll keep experimenting [Tue Jan 6 22:27:44 2015] well, the SSReflect approach seems to has been to avoid dependent types at the low level at all costs. [Tue Jan 6 22:27:56 2015] For example [Tue Jan 6 22:29:14 2015] The define F_p, the finite field of Z mod p for all integers, even when p is not prime. When p isn't prime then F_p is defined to be some trivial field like F_2 or something ... I'd have to look it up. [Tue Jan 6 22:29:33 2015] Then all lemmas about F_p have the hypothesis that p is prime. [Tue Jan 6 22:30:01 2015] that's like breaking out the dependency, right? [Tue Jan 6 22:30:11 2015] pass it as separate evidence? [Tue Jan 6 22:30:19 2015] right. SSReflect is done in that style. [Tue Jan 6 22:30:41 2015] what about when you have a list of F _p's [Tue Jan 6 22:30:53 2015] and the status of one needs to relate to the previous member of the list? [Tue Jan 6 22:31:28 2015] johnw: well I'm not sure I've been in that situation. [Tue Jan 6 22:32:03 2015] I ran into this snafu with my ordered set of instructions, where I needed to verify that each member's address was exactly .+2 of the previous member. This proved hard to express [Tue Jan 6 22:32:10 2015] johnw: I'm a bit disinclined to associate absolute addresses to instructions inside blocks. My Haskell assembler got quite a bit simpler when I made everything relative. [Tue Jan 6 22:32:21 2015] (in the context of that list being segregated into small chunks within a list of blocks) [Tue Jan 6 22:32:38 2015] these addresses are symbolic really [Tue Jan 6 22:32:47 2015] I'm using them to establish interval ranges for a register allocator [Tue Jan 6 22:32:54 2015] in order to compute variable lifetimes [Tue Jan 6 22:34:07 2015] johnw: can't you remove the redudency of your data so you don't need dependent types to exclude bad data? [Tue Jan 6 22:34:49 2015] johnw: but if you must, the way SSReflect would typicaly do this is have an external predicate that is used in all lemmas that asserts the instruction addresses are proper. [Tue Jan 6 22:36:11 2015] thanks for the advice roconnor! I'll give it a lot of thought [Tue Jan 6 22:36:20 2015] I have a feeling that these decision choices are going to decide how the rest of the code looks [Tue Jan 6 22:37:29 2015] johnw: oh now I remember where I saw your name today. It says in March 1997 you invented deterministic DSA signatures. [Tue Jan 6 22:38:03 2015] what?? [Tue Jan 6 22:38:12 2015] oh wait it is a different person ... [Tue Jan 6 22:38:16 2015] yeah [Tue Jan 6 22:38:18 2015] John Wigley [Tue Jan 6 22:38:20 2015] I've never even heard of those :) [Tue Jan 6 22:38:22 2015] oh bizarre [Tue Jan 6 22:38:32 2015] ah [Tue Jan 6 22:38:50 2015] I did find it quite surprising. [Tue Jan 6 23:18:32 2015] I found a John Weigley on the web too [Tue Jan 6 23:22:24 2015] :) [Tue Jan 6 23:38:52 2015] tfw i will never find a namealike [Tue Jan 6 23:48:59 2015] I thought I never would either [Tue Jan 6 23:52:48 2015] johnw: yeah my chances are yours squared [Tue Jan 6 23:52:53 2015] i have TWO last names [Tue Jan 6 23:52:59 2015] actually no that's naive [Tue Jan 6 23:53:02 2015] and not Ben Jones Smith? [Tue Jan 6 23:53:19 2015] squaring is the naive version because most ppl dont have 2 last names [Tue Jan 6 23:53:40 2015] i'd be legitimately shocked if there's a single other person in the world with the same last name as my brother and myself [Tue Jan 6 23:53:51 2015] hyphenated & neither is that common [Wed Jan 7 00:37:52 2015] why exactly can't I use inversion in a context like this: https://gist.github.com/6671f78dc520958c8b72 [Wed Jan 7 00:38:13 2015] is it because it would infer values that are not available outside of Prop? [Wed Jan 7 00:54:50 2015] a different question: if in my context I have an inductive proposition applied to a value for which no constructor exists, how can I infer False? [Wed Jan 7 13:46:33 2015] Hey, is there a textbook on coq? [Wed Jan 7 13:46:52 2015] several! [Wed Jan 7 13:46:58 2015] Software Foundations is the best place to start [Wed Jan 7 13:47:10 2015] it teaches Coq at a very nice and enjoyable pace [Wed Jan 7 13:47:31 2015] johnw, are you on every pure CS channel? [Wed Jan 7 13:47:33 2015] Haha. [Wed Jan 7 13:47:36 2015] I try to be :) [Wed Jan 7 13:47:37 2015] But okay, I'll have a look at that. [Wed Jan 7 13:48:34 2015] breadmonster: if you know the basics, but want more automation, Ilya Sergey has a book on tactic design. Adam Chlipala does too, but his book is for a different style of proving. [Wed Jan 7 13:48:57 2015] ianjneu, I'm...totally new. I'd like to start from the basics. [Wed Jan 7 13:49:00 2015] Ilya's book is quite good [Wed Jan 7 13:49:08 2015] so is Adam's, but I'd read Ilya's first [Wed Jan 7 13:49:19 2015] breadmonster: have you read Wadler's propositions as types essay? [Wed Jan 7 13:49:29 2015] ianjneu, Nope. [Wed Jan 7 13:49:38 2015] Well, that's reading material. [Wed Jan 7 13:49:39 2015] maybe that's the very first place to start. [Wed Jan 7 13:50:05 2015] to get a taste of how we approach proof in Coq. [Wed Jan 7 13:50:29 2015] ...or any other type theory based theorem prover. [Wed Jan 7 13:55:45 2015] Hmm, okay. [Wed Jan 7 13:56:01 2015] ianjneu, I'm taking an advanced algebra class next semester. [Wed Jan 7 13:56:13 2015] And I just wanted Coq to make sure that my proofs are correct. [Wed Jan 7 13:56:18 2015] Is that a bit overkill? [Wed Jan 7 13:56:46 2015] that's a neat idea, though the difficulty may get daunting at times [Wed Jan 7 13:57:17 2015] I'd say that if you find yourself spending too much time trying to verify a proof, just skip that proof until later; after all, you don't want to miss the forest for the trees [Wed Jan 7 17:40:40 2015] how do i R [Wed Jan 7 17:40:45 2015] i imported Reals [Wed Jan 7 17:40:49 2015] now i can type 3%R [Wed Jan 7 17:41:03 2015] where's my "is an integer" predicate. how do i indicate ratios [Wed Jan 7 17:42:56 2015] dunno [Wed Jan 7 17:43:21 2015] im doing a real analysis course-of-sorts and i wanna write my proofs as literate coq [Wed Jan 7 17:44:53 2015] excellent [Wed Jan 7 17:45:07 2015] i don't use Coq for numerics, so I'm bad at these questions [Wed Jan 7 17:46:53 2015] * has finally buckled and is installing proof general [Wed Jan 7 17:47:01 2015] is it possible to do literate coq in proof general [Wed Jan 7 17:49:55 2015] what is "literate coq"? [Wed Jan 7 17:50:08 2015] and yay on the proof general :) [Wed Jan 7 17:50:09 2015] [Wed Jan 7 17:50:48 2015] [23:49] johnw: what is "literate coq"? [Wed Jan 7 17:50:50 2015] fucking hell [Wed Jan 7 17:50:57 2015] it pains me that this is a non-notion [Wed Jan 7 17:51:22 2015] let me rephrase [Wed Jan 7 17:51:33 2015] I'm used to liberally annotating my Coq code using coqdoc notations inside comments [Wed Jan 7 17:51:44 2015] I want to know if he means a special kind of syntax aside from this [Wed Jan 7 17:51:53 2015] well [Wed Jan 7 17:52:01 2015] i have searched for some kind of standards for this for a while [Wed Jan 7 17:52:08 2015] nothing, at least nothing that shows up in google [Wed Jan 7 17:52:15 2015] literally all i mean is being able to put > in front of code lines and otherwise be ignored :) [Wed Jan 7 17:52:15 2015] I've been copying what Adam did to produce his CPDT book [Wed Jan 7 17:53:32 2015] benzrf: every instance of the words "literate coq" that I can find on the Web just refer to comments surrounding Coq code, not to bird-track style syntax [Wed Jan 7 17:53:36 2015] oh nice i haven't seen this book so far [Wed Jan 7 17:53:47 2015] it's quite good, arvisrend! I recommend it [Wed Jan 7 17:54:05 2015] also, if you haven't seen it yet, this one is excellent: http://ilyasergey.net/pnp/ [Wed Jan 7 17:54:16 2015] johnw: i mean that's fine, it's just [Wed Jan 7 17:54:16 2015] i hope it's not too emacs-centered though [Wed Jan 7 17:54:21 2015] thanks! [Wed Jan 7 17:54:33 2015] oh WOW [Wed Jan 7 17:54:38 2015] they use ssreflect? [Wed Jan 7 17:54:43 2015] yeah [Wed Jan 7 17:54:49 2015] johnw: (* is a huge pain to type, having to close all of my comments is annoying, and i'll have far more comment lines than non comment lines [Wed Jan 7 17:54:52 2015] well [Wed Jan 7 17:54:53 2015] maybe not FAR more [Wed Jan 7 17:55:01 2015] (* and *) is harder to type than > 18 times? [Wed Jan 7 17:55:02 2015] thank you! [Wed Jan 7 17:55:11 2015] arvisrend: you like ssreflect? [Wed Jan 7 17:55:16 2015] johnw: (* and *) 18 times is harder than > 18 times, yes [Wed Jan 7 17:55:30 2015] johnw: in fact it would be (* and *) /19/ times because fencepost [Wed Jan 7 17:55:31 2015] use (* *) to enclose the whole documentation block [Wed Jan 7 17:55:38 2015] johnw: i was thinking interspersed, though [Wed Jan 7 17:55:41 2015] like, [Wed Jan 7 17:55:52 2015] speaking of tutorials, does anyone know of something noob-readable about setoids? [Wed Jan 7 17:55:59 2015] benzrf: so, in Emacs, you type M-; to introduce a comment, which inserts (* *) for you [Wed Jan 7 17:56:13 2015] arvisrend: specifically using setoids in Coq? [Wed Jan 7 17:56:16 2015] yes [Wed Jan 7 17:56:59 2015] "Linux and Mac OS X users can compile Coq 8.4 and SSReflect from sources, which [Wed Jan 7 17:56:59 2015] would take around two hours of their time. " [Wed Jan 7 17:57:00 2015] what the hell [Wed Jan 7 17:57:03 2015] two hours? two days rather [Wed Jan 7 17:57:10 2015] hahah [Wed Jan 7 17:57:13 2015] We prove this by functional extensionality [Wed Jan 7 17:57:13 2015] > extensionality arg. [Wed Jan 7 17:57:14 2015] ... [Wed Jan 7 17:57:14 2015] This equality is trivial. [Wed Jan 7 17:57:15 2015] > reflexivity. [Wed Jan 7 17:57:17 2015] it certainly doesn't take me two days or two hours [Wed Jan 7 17:57:20 2015] it takes about 15 mins [Wed Jan 7 17:57:33 2015] wow, then something is seriously fucked with my virtualbox [Wed Jan 7 17:57:41 2015] oh, in virtualbox maybe it would take 2 hours [Wed Jan 7 17:57:50 2015] benzrf: Emacs allows you to automate nearly anything [Wed Jan 7 17:57:52 2015] COQC is taking the most time [Wed Jan 7 17:58:01 2015] and ocamlopt is installed and is being used [Wed Jan 7 17:58:26 2015] sadly, the only real resource I know of on setoids is the reference manual: [Wed Jan 7 17:58:27 2015] https://coq.inria.fr/refman/Reference-Manual029.html [Wed Jan 7 17:58:32 2015] I wish there was something gentler [Wed Jan 7 17:58:41 2015] perhaps the end of http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf [Wed Jan 7 17:58:52 2015] thank you [Wed Jan 7 17:59:18 2015] (* benzrf proves this by functional extensionality *) [Wed Jan 7 17:59:19 2015] extensionality arg. [Wed Jan 7 17:59:29 2015] (* This equality is decidely NOT trivial. *) [Wed Jan 7 17:59:33 2015] hahahah. [Wed Jan 7 17:59:39 2015] tomato tomato [Wed Jan 7 18:01:01 2015] but johnw [Wed Jan 7 18:01:12 2015] but, but, but, benzrf [Wed Jan 7 18:01:14 2015] then i have to type (**) for every > i previously had to [Wed Jan 7 18:01:20 2015] don't type (* *) [Wed Jan 7 18:01:22 2015] god knows im lazy [Wed Jan 7 18:01:22 2015] type M-; [Wed Jan 7 18:01:28 2015] b-but i use vim [Wed Jan 7 18:01:33 2015] not if you use Proof General [Wed Jan 7 18:01:54 2015] t_t [Wed Jan 7 18:23:23 2015] argh [Wed Jan 7 18:23:28 2015] i dont know any of the keybinds [Wed Jan 7 18:58:14 2015] benzrf: use one of the many vim emulation things in emacs? [Wed Jan 7 18:58:24 2015] Not sure how well they play with ProofGeneral. [Wed Jan 7 19:01:36 2015] bleh [Wed Jan 7 19:04:27 2015] benzrf: it's probably worth biting the bullet just for ProofGeneral. [Wed Jan 7 19:05:50 2015] yeah [Thu Jan 8 09:13:02 2015] how do i close a Module in coq? [Thu Jan 8 09:13:38 2015] ah, "End" [Thu Jan 8 11:53:56 2015] Hi, is it possible to add extra HTML content (in
) in the coqdoc output ? (When it generates html pages) [Thu Jan 8 11:54:21 2015] For example, to include another css file or a javascript file [Thu Jan 8 12:02:10 2015] Obviously the HTML header is hard-coded in the coqdoc source .. [Thu Jan 8 14:03:30 2015] Coq is really teaching me the express power of relating things to and from natural numbers [Thu Jan 8 14:03:33 2015] expressive [Thu Jan 8 14:09:22 2015] https://bpaste.net/show/8ebaf31dbf29 I'm trying to write a proof that length (xs ++ ys) = length xs + length ys. What is the proper way to introduce the base case here and why I'm getting the "no interpretation for string" error? [Thu Jan 8 14:10:03 2015] have you imported the Case voodoo? [Thu Jan 8 14:12:44 2015] I'm a noob, excuse my ignorance. What exactly am I supposed to import? [Thu Jan 8 14:13:54 2015] you're reading sf, right? [Thu Jan 8 14:14:09 2015] "Require Export Induction." should do it then [Thu Jan 8 14:14:22 2015] Oh, wait. I see what I missed. [Thu Jan 8 14:14:33 2015] oh also [Thu Jan 8 14:14:34 2015] intros X ? [Thu Jan 8 14:14:44 2015] or are types automatically introd? [Thu Jan 8 14:15:16 2015] ah no they aren't [Thu Jan 8 14:15:18 2015] that's your error [Thu Jan 8 14:18:10 2015] Yes, that's my error too. [Thu Jan 8 15:07:34 2015] https://bpaste.net/show/bb62bfd948d6 Why is it impossible to unify? [Thu Jan 8 15:10:18 2015] On a blackboard I would say it's true because + is commutative, how do I say it in coq? [Thu Jan 8 15:10:33 2015] Or I'm missing something else here? [Thu Jan 8 15:16:46 2015] a+b+c means (a+b)+c [Thu Jan 8 15:16:54 2015] so you'll have to rewrite both sides by associativity first [Thu Jan 8 16:12:48 2015] arvisrend: How do I apply something to both sides? Also, should I use the plus_assoc lemma from Arith.Plus for rewrites or something else? [Thu Jan 8 16:14:00 2015] "apply something to both sides"? [Thu Jan 8 16:14:21 2015] Coq makes me feel dumb (maybe it's a good thing). [Thu Jan 8 16:14:39 2015] that's a good thing, if you want to be learning [Thu Jan 8 16:16:01 2015] rewrite -> or <- plus_assoc [Thu Jan 8 16:16:02 2015] johnw: I'm stuck at "foo x + foo y + 1 = foo x + 1 + foo y" where I want to apply reflexivity. [Thu Jan 8 16:16:15 2015] or, if this doesn't do the trick, be more explicit [Thu Jan 8 16:16:25 2015] rewrite -> (plus_assoc (foo x) (foo y) 1) [Thu Jan 8 16:16:31 2015] rewrite -> (plus_assoc (foo x) 1 (foo y)) [Thu Jan 8 16:16:34 2015] or <- if this doesn't work [Thu Jan 8 16:16:44 2015] (i can't remmeber which side it is) [Thu Jan 8 16:17:05 2015] dmbaturin: plus_assoc, selecting the 2nd instance [Thu Jan 8 16:17:17 2015] then plus_comm, selecting the 4th instance [Thu Jan 8 16:17:29 2015] then <- plus_assoc, and reflexivity [Thu Jan 8 16:21:15 2015] "simpl. rewrite -> IHxs. rewrite <- plus_assoc. reflexivity." gives me the same "Impossible to unify "length xs + 1 + length ys" with "length xs + (length ys + 1)" [Thu Jan 8 16:21:40 2015] you still need plus_comm [Thu Jan 8 16:21:42 2015] and plus_assoc [Thu Jan 8 16:21:48 2015] and, you need to target them to the right places [Thu Jan 8 16:22:08 2015] although, maybe regular Coq is only applying it to the right-hand side [Thu Jan 8 16:23:30 2015] Regular? [Thu Jan 8 16:23:54 2015] i use ssreflect, so the rewriting machinery is a bit different [Thu Jan 8 16:24:13 2015] With simpl. rewrite -> IHxs. rewrite <- plus_assoc. rewrite <- plus_comm. I get Impossible to unify "length xs + 1 + length ys" with "length ys + 1 + length xs". [Thu Jan 8 16:24:37 2015] Which is slightly better though. [Thu Jan 8 16:24:41 2015] you'll need plus_assoc twice [Thu Jan 8 16:24:48 2015] once in -> direction, and once in <- [Thu Jan 8 16:24:58 2015] then, you'll need to specify that you want to rewrite the second instance of plus_comm [Thu Jan 8 16:25:04 2015] you can't just say "rewrite plus_comm" [Thu Jan 8 16:26:08 2015] That's the part I'm lost at. How do I apply the tactic to the second isntance? [Thu Jan 8 16:26:17 2015] probably: rewrite plus_comm at 2 [Thu Jan 8 16:26:36 2015] in my world it would be: rewrite [1 + _]plus_comm [Thu Jan 8 16:27:07 2015] <- is LHS and -> is RHS? [Thu Jan 8 16:27:23 2015] of the lemma yes, not of the goal [Thu Jan 8 16:27:31 2015] i.e., rewrite -> with a = b changes a into b [Thu Jan 8 16:33:37 2015] rewrite <- plus_assoc. rewrite <- plus_assoc. rewrite plus_comm. rewrite plus_comm. gives me Impossible to unify "length xs + (1 + length ys)" with "length xs + (length ys + 1)". [Thu Jan 8 16:33:45 2015] Which is almost complete. :) [Thu Jan 8 16:34:35 2015] your two plus_comm's negated each other [Thu Jan 8 16:34:43 2015] you are still not applying plus_comm to the second intsance [Thu Jan 8 16:34:46 2015] rewrite plum_comm at 2 [Thu Jan 8 16:34:53 2015] you should only need to apply it the one time [Thu Jan 8 16:48:31 2015] johnw: Found plus_permute lemma in Arith.Plus, looks like I constructed the right rewrite with it. [Thu Jan 8 16:48:38 2015] Now it compiled successfully. [Thu Jan 8 16:49:53 2015] ah, cool [Thu Jan 8 16:50:27 2015] I guess SearchIso would have found that pretty easily [Thu Jan 8 16:50:35 2015] had you used the search: (_ + (_ + _)) [Thu Jan 8 16:50:39 2015] SearchIsos [Thu Jan 8 16:50:43 2015] or SearchRewrite [Thu Jan 8 16:53:32 2015] johnw: https://bpaste.net/show/0d6aef030878 This is how it looks now. Does it look sane? [Thu Jan 8 16:54:00 2015] Also, if it compiles, does it always mean that the proof is correct in some sense? :) [Thu Jan 8 16:54:18 2015] reflexivity implies simpl [Thu Jan 8 16:54:43 2015] using plus_permute feels odd [Thu Jan 8 16:54:44 2015] one sec [Thu Jan 8 16:56:06 2015] um, I didn't need any of those rewrites at all [Thu Jan 8 16:56:11 2015] just "simpl. rewrite -> IHxs. reflexivity." [Thu Jan 8 16:56:22 2015] can you give me your definition of append? [Thu Jan 8 16:56:30 2015] I tried just using "app" [Thu Jan 8 16:56:34 2015] The whole thing after IH rewrite feels odd to me. Is fiddling with tactics to make them match the goal a normal thing or something pathological? [Thu Jan 8 16:56:37 2015] Sure, hold on. [Thu Jan 8 16:56:52 2015] well, you are doing too much rewriting, instead of being surgical [Thu Jan 8 16:56:56 2015] otherwise, it's not abnormal [Thu Jan 8 16:57:24 2015] fun idea: "wlog" tactic that splits a conjunction and then makes tactics afterward be applied to both branches [Thu Jan 8 16:57:33 2015] benzrf: it's in ssreflect [Thu Jan 8 16:57:38 2015] with that very name, in fact [Thu Jan 8 16:57:40 2015] ahaha [Thu Jan 8 16:57:43 2015] What is ssreflect? [Thu Jan 8 16:57:49 2015] that was about 50% joking on my part [Thu Jan 8 16:57:56 2015] think of it as a different standard library, with a much better rewriting engine [Thu Jan 8 16:58:00 2015] johnw: https://bpaste.net/show/067f2ab75bb9 The whole thing (except for Case magic from SF). [Thu Jan 8 16:58:32 2015] this still worked for me dmbaturin: https://gist.github.com/3d3f74d3e756cab060d5 [Thu Jan 8 16:58:47 2015] also "rewrite ->" is the same as just "rewrite" [Thu Jan 8 16:58:54 2015] after the rewrite IHxs, I get: S (length xs + length ys) = S (length xs + length ys) [Thu Jan 8 16:58:58 2015] wait, so [Thu Jan 8 16:59:10 2015] nvm [Thu Jan 8 16:59:20 2015] was gonna ask what ssreflect was exactly [Thu Jan 8 16:59:41 2015] Hello, I really need your help ! (It drives me crazy ^^). I have two basics files (with definitions) : one depends on the other. When I import them (Require Import ...), I can use definitions of the first one (With no deps), but in the other one it complains : The reference "..." was not found in the current environment [Thu Jan 8 17:00:08 2015] Require Export [Thu Jan 8 17:00:18 2015] if I understand you correctly [Thu Jan 8 17:00:20 2015] johnw: Interesting. What is your coq version? [Thu Jan 8 17:00:24 2015] 8.4pl4 [Thu Jan 8 17:00:27 2015] no, 8.4pl5 [Thu Jan 8 17:00:28 2015] This is mine: The Coq Proof Assistant, version 8.4pl4 (June 2014) [Thu Jan 8 17:01:08 2015] Also, ssreflect is to coq as core or batteries are to ocaml? :) [Thu Jan 8 17:01:19 2015] i don't know ocaml at all! [Thu Jan 8 17:01:49 2015] I bet you if I saw any of that code my first reaction would be that it looks like Gallina :) [Thu Jan 8 17:02:50 2015] core is alternative standard library to ocaml + some tools, so in that way it's similar to ssreflect and coq [Thu Jan 8 17:02:54 2015] johnw: Here are the files : http://pastebin.com/cT1RaJ7G http://pastebin.com/ULX10HGX [Thu Jan 8 17:03:12 2015] I still don't understand Choups314 [Thu Jan 8 17:03:20 2015] arcatan: ah, that sounds very similar then [Thu Jan 8 17:03:42 2015] (sorry, there are a lot of comments, I just want to [Require Import sequences] and be able to use the [Un_limit] definition) [Thu Jan 8 17:03:45 2015] also, ssreflect emphasizes the use of computable, decidable predicate, with reflections into Prop, rather than using inductive predicates as much as the stdlib does [Thu Jan 8 17:04:03 2015] Choups314: where and why can't you use it? [Thu Jan 8 17:04:40 2015] " Error: The reference Un_limit was not found in the current environment. " [Thu Jan 8 17:05:15 2015] what file is saying that? [Thu Jan 8 17:05:52 2015] Let's say I have a file called tmp.v containing http://pastebin.com/7ZCmJSpe [Thu Jan 8 17:06:02 2015] This file produces the error [Thu Jan 8 17:06:26 2015] your pastes before didn't have filenames [Thu Jan 8 17:06:30 2015] so I'm sorry, but I'm still very confused [Thu Jan 8 17:06:42 2015] reals.v : http://pastebin.com/cT1RaJ7G [Thu Jan 8 17:06:49 2015] sequences.v : http://pastebin.com/ULX10HGX [Thu Jan 8 17:06:57 2015] Both compile fine [Thu Jan 8 17:07:01 2015] so, sequences defines something [Thu Jan 8 17:07:06 2015] but when you import sequences, you can't see it [Thu Jan 8 17:07:10 2015] Yes, it defines Un_limit [Thu Jan 8 17:07:31 2015] are you sure you're importing the file that you think you are? [Thu Jan 8 17:07:37 2015] nothing else anywhere on the system has that same name? [Thu Jan 8 17:07:48 2015] huu .. [Thu Jan 8 17:07:52 2015] sequences ? [Thu Jan 8 17:08:01 2015] in some Coq library for example [Thu Jan 8 17:08:21 2015] I check .. [Thu Jan 8 17:08:26 2015] for example, copy sequences.v to FooBarBaz.v [Thu Jan 8 17:08:33 2015] and then import that from your test.v [Thu Jan 8 17:08:55 2015] because ordinarily, dealing with imports and exports in Coq should be dead simple [Thu Jan 8 17:09:13 2015] :o That was the problem .. Thanks ! ^^ [Thu Jan 8 17:09:19 2015] It drove me crazy ^^ [Thu Jan 8 17:09:22 2015] heh, been there :) [Thu Jan 8 17:09:58 2015] Probably in the stdlib .. Are the lib filename case-sensitive ? [Thu Jan 8 17:10:05 2015] I don't even know! [Thu Jan 8 17:10:31 2015] Yeah, "sequences" is a very common name in fact .. [Thu Jan 8 17:13:35 2015] johnw: Tried the same theorem with app and length from the List module, just reflexivity works there. [Thu Jan 8 17:13:56 2015] sometimes the way you write things can make it harder for simplification to do its job [Thu Jan 8 17:14:10 2015] Guess I should go read the module and check what's the difference with my list rewrite. [Thu Jan 8 17:14:26 2015] I found that with some of my functions, if I take time to rewrite them into the simplest form possible, all of a sudden a lot of my proofs get a lot easier to get through [Thu Jan 8 17:20:09 2015] I'm still to learn to recognize the simplest possible form though, as I'm barely familiar with both the syntax and semantics. :) [Thu Jan 8 17:22:39 2015] yeah, it takes time [Thu Jan 8 22:23:20 2015] Is there a way to prove in Coq that `(forall x, f x = g x) -> f = g`? [Thu Jan 8 22:25:24 2015] I ask because there are times when I'm trying to prove two functions are equal (e.g. `fmap (f . g) = fmap f . fmap g` for functors). It's more elegant to express the theorems point-free, but I'd love something like the above lemma when proving [Thu Jan 8 22:26:30 2015] Because then I could just write `apply function_uniqueness` or whatever and my goal would be changed to `fmap (f . g) x = (fmap f . fmap g) x`, for example [Thu Jan 8 22:27:55 2015] you can't prove that, would have to add it as an axiom [Thu Jan 8 22:28:30 2015] you could maybe define a new operation f == g meaning forall x, f x = g y to write the statements pointfree [Thu Jan 8 22:28:55 2015] Is there a better way to prove equality of functions? Or is it "acceptable" to add that axiom? [Thu Jan 8 22:29:03 2015] prove it? you cannot [Thu Jan 8 22:29:09 2015] it's acceptable [Thu Jan 8 22:29:33 2015] there are other theories, like HoTT, that will let you prove that theorem; but to do so you'll just need to axiomatize something even more fundamental [Thu Jan 8 22:29:45 2015] adding the axiom doens't make the logic inconsistent [Thu Jan 8 22:29:51 2015] What does HoTT give you that lets you prove that? [Thu Jan 8 22:29:52 2015] but it has no computational content [Thu Jan 8 22:30:00 2015] right, it's a safe axiom to add that most people regard as a no-brainer [Thu Jan 8 22:30:06 2015] the univalence axiom [Thu Jan 8 22:30:19 2015] Oh awesome, it even has a name :) [Thu Jan 8 22:30:22 2015] so its best to avoid it if possible [Thu Jan 8 22:30:38 2015] in my linearscan work, funext is the only axiom I admit [Thu Jan 8 22:30:46 2015] Why is that? [Thu Jan 8 22:30:54 2015] I mean why avoid it [Thu Jan 8 22:30:54 2015] and only because it makes proving the monad laws *so* much more convenient [Thu Jan 8 22:31:01 2015] than having to pull in setoids everywhere, and, bleh [Thu Jan 8 22:31:04 2015] so, my reason was laziness [Thu Jan 8 22:31:11 2015] avoiding axioms is good hygiene [Thu Jan 8 22:31:25 2015] you can ask Coq to tell you what all axioms you've pulled in [Thu Jan 8 22:31:47 2015] and ask him always makes what you prove, in some sense, conditional [Thu Jan 8 22:31:51 2015] "an axiom" [Thu Jan 8 22:32:15 2015] it certainly seems like a good idea to avoid axioms, but how else to prove function equality? Other than syntactic equality [Thu Jan 8 22:32:51 2015] you can't [Thu Jan 8 22:32:57 2015] because it's an undecidable problem [Thu Jan 8 22:33:13 2015] Ahh, in the general case you mean [Thu Jan 8 22:33:32 2015] The only way to prove that two functions at the same definition, is to prove that for every single argument that have the same result. But how can you prove that in general? [Thu Jan 8 22:33:42 2015] yeah, exactly :) [Thu Jan 8 22:33:51 2015] Now, there are other approaches [Thu Jan 8 22:34:26 2015] such as? [Thu Jan 8 22:34:31 2015] one is to use functional extensionality only in the specific cases where you know the two functions involved. This is what ssreflect does, to give you something that works just like general functional extensionality most of the time [Thu Jan 8 22:34:36 2015] I showed one way already [Thu Jan 8 22:34:59 2015] another is to take the functional extensionality witness as an argument to your function, rather than axiomatizing it globally [Thu Jan 8 22:35:19 2015] right thanks vanila [Thu Jan 8 22:35:33 2015] (or, as a Hypothesis within your section) [Thu Jan 8 22:35:44 2015] that way, it's up to the caller to know whether those two functions are equal [Thu Jan 8 22:35:58 2015] Oh right like proofs that take excluded middle as an argument [Thu Jan 8 22:36:18 2015] yep [Thu Jan 8 22:36:19 2015] (theorems I should say) [Thu Jan 8 22:36:31 2015] by the way is this john from chicago? [Thu Jan 8 22:36:38 2015] I'm John Wiegley from Peoria [Thu Jan 8 22:36:41 2015] south of Chicago [Thu Jan 8 22:36:53 2015] yeah! I was at the Haskell meetup where you talked about coq [Thu Jan 8 22:37:02 2015] I've been hooked ever since [Thu Jan 8 22:37:12 2015] oh, cool!! [Thu Jan 8 22:37:18 2015] what was your name again? [Thu Jan 8 22:37:22 2015] Allen [Thu Jan 8 22:37:33 2015] Friend of David's [Thu Jan 8 22:37:43 2015] he's who got me into Haskell way back when :P [Thu Jan 8 22:37:48 2015] I could sense the appeal of Nix in the room, but I wasn't sure that I had really gotten anyone interested about Coq [Thu Jan 8 22:37:58 2015] nice to meet you again [Thu Jan 8 22:38:14 2015] yeah it definitely interested me. I'm hoping to go to oregon this summer [Thu Jan 8 22:38:33 2015] oh cool! I have already told work I intend to go [Thu Jan 8 22:38:43 2015] if so, we'll definitely have to share a few meals [Thu Jan 8 22:39:03 2015] Yeah for sure. I went to their website and it looks like registration isn't open yet... or at least they didn't say anything that I could find [Thu Jan 8 22:39:45 2015] I've been going through a lot of the lectures on youtube, from 2012 I think [Thu Jan 8 22:39:56 2015] that will be good preparation [Thu Jan 8 22:40:01 2015] I went a little too unprepared the first time [Thu Jan 8 22:40:10 2015] it's a little slow going, I'm definitely glad I'm going through it now [Thu Jan 8 22:40:18 2015] it was like the lecturer literally had a firehose and I was trying to stay in my seat [Thu Jan 8 22:40:27 2015] hahaha indeed [Thu Jan 8 22:40:51 2015] Frank's lectures are particularly tough for me [Thu Jan 8 22:41:07 2015] When he was talking about lax truth and such... I had to watch that one a lot of times [Fri Jan 9 11:39:04 2015] I wonder if I should try proving some free theorems for practice. [Fri Jan 9 11:39:36 2015] free theorems? [Fri Jan 9 11:41:17 2015] Those from P. Wadler's "Theorems for free" 1989 paper. [Fri Jan 9 11:42:11 2015] if you're new to coq, I suggest to do the exercises from software foundations. this way you can at least be sure that you know the material that's required to solve the exercises [Fri Jan 9 11:43:52 2015] otherwise, it may look more like searching the web rather than proving things [Fri Jan 9 11:44:00 2015] Yeah, I'm reading SF and doing exercises too, but I try to also find different to check if I actually can apply what I learned [more or less] independently. [Fri Jan 9 11:44:08 2015] * different examples [Fri Jan 9 11:44:53 2015] then try to solve similar problems but use the standard library instead [Fri Jan 9 11:45:01 2015] that's what I do in gitorious.org/99-problems [Fri Jan 9 11:45:13 2015] Hhm, good point. [Fri Jan 9 11:45:22 2015] not much code there, though [Fri Jan 9 11:45:38 2015] this way you'll learn the stdlib and coqdoc [Fri Jan 9 11:46:28 2015] as a bonus, you could try to extract haskell code from coq and compare it with the answers [Fri Jan 9 11:46:41 2015] I haven't touched the extractor yet [Fri Jan 9 11:48:44 2015] Me neither. I'm more interested in ocaml extraction though. [Fri Jan 9 12:21:17 2015] are there good references on the code extractor? [Fri Jan 9 12:21:46 2015] I'm building CompCert now... which I'd assume has to use it, because it appears to just generate C code that it then uses another compiler to build [Fri Jan 9 12:22:13 2015] but I'm also sort of curious how something like http://plv.csail.mit.edu/bedrock/ fits into this [Fri Jan 9 12:25:17 2015] perhaps it simply doesn't [Fri Jan 9 12:50:29 2015] nkar: Which 99 problems are you porting to coq in your projects? [Fri Jan 9 12:51:05 2015] I know of several similar but not identical collections under this "trademark". [Fri Jan 9 13:00:01 2015] https://www.haskell.org/haskellwiki/H-99:_Ninety-Nine_Haskell_Problems [Fri Jan 9 13:02:33 2015] or, maybe I'm an idiot, and Coq doesn't actually extract C code. yes, that is more likely. [Fri Jan 9 13:04:23 2015] I think it only extracts to OCaml, Haskell, and Scheme (?) [Fri Jan 9 13:05:25 2015] notdan: yes. [Fri Jan 9 13:05:41 2015] notdan: for some reason I had it in my head that it generated C. [Fri Jan 9 13:13:23 2015] hodapp: bedrock is sort of for writing formalized assembly [Fri Jan 9 13:13:27 2015] there is also Ynot [Fri Jan 9 13:13:29 2015] hodapp: CompCert uses ocaml extraction as I understand. [Fri Jan 9 13:13:40 2015] dmbaturin: I was confused because it looked for GCC in ./configure. [Fri Jan 9 13:13:43 2015] and definitely check out Verasco too, if you're into CompCert [Fri Jan 9 13:16:11 2015] johnw: neat, thanks [Fri Jan 9 13:58:27 2015] dmbaturin: notdan is right. it's mentioned in the readme file [Fri Jan 9 14:06:12 2015] hodapp: We're currently working on integrating higher-level langauges into the pipeline. See http://plv.csail.mit.edu/fiat/ [Fri Jan 9 14:07:23 2015] jgross: PM confused me because I said something in another channel for which your message sort of kind of would have applied :) [Fri Jan 9 14:08:04 2015] jgross: this looks neat, and good to see that Adam Chlipala is generating yet more work before I've even had a chance to read CPDT [Fri Jan 9 14:08:26 2015] jgross: interesting! thanks for pointing this out [Fri Jan 9 14:08:53 2015] I might show this to the Comp Sci professor at university just to annoy him [Fri Jan 9 14:09:00 2015] he only wants to use Cryptol, ACL2, and SAT/SMT solvers [Fri Jan 9 14:09:13 2015] anything else is a silly fad [Fri Jan 9 14:09:13 2015] would he like Liquid Haskell then? [Fri Jan 9 14:09:22 2015] There'll be a presentation on it at POPL, and, if all goes well, another paper in PLDI. [Fri Jan 9 14:09:23 2015] he'd probably call it a silly fad [Fri Jan 9 14:10:54 2015] nkar: Oh, yeah, I missed it. Thanks. [Fri Jan 9 14:11:07 2015] hodapp: ha! One of Adam's ideas is that SAT/SMT solvers should be replced by verified roll-your-own synthesized domain-specific compilers/verifiers, and that you shouldn't have to shoehorn your problem into a SAT/SMT problem to get your verifier to accept it. [Fri Jan 9 14:11:48 2015] jgross: this professor's life work appears to be SAT/SMT. [Fri Jan 9 14:12:39 2015] jgross: so the verifiers/compilers themselves should be synthesized? [Fri Jan 9 14:14:20 2015] Ben Delawere would be a perfect person to play a movie adaption of The Count from Sesame Street [Fri Jan 9 14:14:48 2015] I can almost hear him saying, "Two, two verified types! Muhahahaha" [Fri Jan 9 14:16:22 2015] hodapp: Hmmm, that doesn't seem quite right, so perhaps I'm misrepresenting it. The current state of the project (or current ideal) is that the compiler should be extensible with custom scripts to synthesize code from your spec, and the framework will be able to glue various bits together automatically, and ensure that everything in the compilation chain is appropriately verified. [Fri Jan 9 14:16:25 2015] Is it possible to define a Notation depending on the type ? [Fri Jan 9 14:16:38 2015] johnw: Shall I tell him you said that? :-) [Fri Jan 9 14:16:48 2015] use your best judgment :) [Fri Jan 9 14:17:10 2015] (For example, something like : [Notation "a = b" := eq_special a b] only if b has a special type) [Fri Jan 9 14:17:10 2015] he looks like he has a sense of humor [Fri Jan 9 14:17:54 2015] Choups314: Use coercions or typeclasses? See https://github.com/HoTT/HoTT/blob/master/theories/categories/Comma/Core.v#L338 (and below) for the coercions version. [Fri Jan 9 14:18:52 2015] And here's a variant that uses trunk's tactics-in-terms: https://github.com/JasonGross/HoTT/blob/improve-comma-notation/theories/categories/Comma/Core.v#L284 [Fri Jan 9 14:19:28 2015] jgross: it would be nice if your tarball 1) didn't include ._* files, and 2) unpacked into a "fiat" directory [Fri Jan 9 14:20:15 2015] And here's typeclasses: https://github.com/HoTT/HoTT/blob/master/theories/categories/LaxComma/Core.v#L177 [Fri Jan 9 14:20:19 2015] in just a moment, you'll be packaged in Nix [Fri Jan 9 14:20:57 2015] johnw: I'll let the group know. [Fri Jan 9 14:21:14 2015] about the packaging, I hope, not about resemblances to certain fictional vampires [Fri Jan 9 14:21:55 2015] Indeed. I'll share that one only with Ben; I think he'll be amused. [Fri Jan 9 14:23:02 2015] tell Adam that bedrock is in Nix too [Fri Jan 9 14:23:08 2015] although I had to disable running full tests [Fri Jan 9 14:23:12 2015] oh nice! [Fri Jan 9 14:25:03 2015] jgross: ahh, that makes sense then! [Fri Jan 9 14:26:27 2015] one of these days I need to read about what appeals to people about Nix/NixOS. [Fri Jan 9 14:26:47 2015] Sorry if you said something, my connection timed out .. [Fri Jan 9 14:26:49 2015] functional, immutable data store, reproducible builds, rollbacks, declarative syntax, etc. [Fri Jan 9 14:27:03 2015] builds are just functions (same inputs give same outputs) [Fri Jan 9 14:28:26 2015] Choups314: Let me resend my answers [Fri Jan 9 14:28:49 2015] Choups314: Use coercions or typeclasses? See https://github.com/HoTT/HoTT/blob/master/theories/categories/Comma/Core.v#L338 (and below) for the coercions version. [Fri Jan 9 14:28:59 2015] And here's a variant that uses trunk's tactics-in-terms: https://github.com/JasonGross/HoTT/blob/improve-comma-notation/theories/categories/Comma/Core.v#L284 [Fri Jan 9 14:29:07 2015] And here's typeclasses: https://github.com/HoTT/HoTT/blob/master/theories/categories/LaxComma/Core.v#L177 [Fri Jan 9 14:30:05 2015] jgross: after using all three, which do you prefer and why? [Fri Jan 9 14:31:08 2015] hodapp: Mostly the package manager that makes package installation and upgrade atomic. [Fri Jan 9 14:31:25 2015] At least this is what appeals to me. :) [Fri Jan 9 14:34:20 2015] Can anyone recommend good introductory type theory reading? All my knowledge of type systems is way too informal. [Fri Jan 9 14:34:44 2015] dependent types or normal types [Fri Jan 9 14:35:04 2015] Starting with normal I guess. [Fri Jan 9 14:35:56 2015] Peirce's book [Fri Jan 9 14:36:00 2015] Types and Programming Languages [Fri Jan 9 14:36:09 2015] dmbaturin: alright, good to know. [Fri Jan 9 14:36:11 2015] stick through the first three chapters, they are somewhat dry [Fri Jan 9 14:36:17 2015] then it gets really good [Fri Jan 9 14:36:22 2015] type theory? dry? NEVER! [Fri Jan 9 14:36:23 2015] I think the first chapter or two of the HoTT book might be decent for dependent types? (Especially if you have a strong mathemtical background) [Fri Jan 9 14:36:28 2015] Thanks, will have a look. [Fri Jan 9 14:36:28 2015] Yves Girard's Proofs and Types [Fri Jan 9 14:36:36 2015] is a good book [Fri Jan 9 14:36:40 2015] my copy of HoTT ships soon. My maths background is a bit limited though... [Fri Jan 9 14:37:00 2015] undergrad was EE, so a lot of calculus and linear algebra [Fri Jan 9 14:37:11 2015] as someone not having a strong mathematical background, I'd say the first two of HoTT is far too dense [Fri Jan 9 14:37:36 2015] I asked the same old CS professor what he thought of HoTT. He said something along the lines of "BAH HUMBUG". [Fri Jan 9 14:37:42 2015] Type Theory and Functional Programming: https://www.cs.kent.ac.uk/people/staff/sjt/TTFP/ttfp.pdf [Fri Jan 9 14:39:10 2015] johnw: well, I might end up filling the margins with notes... [Fri Jan 9 14:39:42 2015] I liked HoTT, but the acceleration curve was too steep; TAPL was much more digestible [Fri Jan 9 14:41:49 2015] My math background is, uhm, a bit skewed towards the infinitesimal side. [Fri Jan 9 14:42:49 2015] HoTT is surely not an introduction [Fri Jan 9 14:42:59 2015] very little of it is about vanilla type theory [Fri Jan 9 14:48:55 2015] In a sense, I'm catching up on CS education I probably would want to receive way earlier. :) [Fri Jan 9 14:49:08 2015] dmbaturin: are you in the US by chance? [Fri Jan 9 14:49:14 2015] No, I'm in .ru [Fri Jan 9 14:50:14 2015] jgross: BookstoreCache.v no es rapido [Fri Jan 9 14:52:46 2015] Is it possible to define a notation such as "f -x0-> l", where f x0 and l are variables ? [Fri Jan 9 14:53:24 2015] Is it possible to define a notation such as "f -x0-> l", where f x0 and l are variables ? [Fri Jan 9 14:53:29 2015] Notation "f - x0 -> l" := (...). [Fri Jan 9 14:53:37 2015] then, when you write it, you can omit the spaces around x0 [Fri Jan 9 14:53:45 2015] btw, I use -{x0}->, fwiw [Fri Jan 9 14:54:16 2015] to avoid confusing myself if ever reading x = f - x0 -> ... [Fri Jan 9 14:54:16 2015] By the way, is coq parser verified? [Fri Jan 9 14:54:38 2015] nah [Fri Jan 9 14:54:50 2015] it doesn't really need to be [Fri Jan 9 14:55:41 2015] ezyang: where are you located? [Fri Jan 9 14:55:47 2015] Stanford [Fri Jan 9 14:55:50 2015] I guess, still it would be nice if it served as an example of a verified parser. [Fri Jan 9 14:55:56 2015] ah, cool [Fri Jan 9 14:56:10 2015] (I guess it would make it way harder to modify though) [Fri Jan 9 14:56:11 2015] ezyang: I got to play at the same park with SPJ's kids as you did when you were working on backpack :) [Fri Jan 9 14:56:25 2015] johnw: Thanks [Fri Jan 9 14:56:49 2015] johnw: What are you up to? Organizing a theorem proving event? [Fri Jan 9 14:56:58 2015] hahaha! [Fri Jan 9 14:57:08 2015] Man, what a park. [Fri Jan 9 14:57:09 2015] dmbaturin: to what do you refer? [Fri Jan 9 14:57:14 2015] They don't make 'em like that in the States [Fri Jan 9 14:57:30 2015] ezyang: I ended up inadvertantly stealing someone's bag because I thought it was Simon's; but then I rode back and they were still there, so no harm done [Fri Jan 9 14:57:39 2015] johnw: You are asking where people are located, it made me think you are planning some IRL event or something. [Fri Jan 9 14:58:10 2015] ah, no [Fri Jan 9 14:58:11 2015] I just wonder where people are in case I'm visiting their area [Fri Jan 9 14:58:11 2015] I like meeting FP/typetheory/maths people in RL [Fri Jan 9 14:58:22 2015] I've seen ezyang before, though we haven't spoken much [Fri Jan 9 14:58:50 2015] Unfortunately people don't put their IRC names on their name badges ;) [Fri Jan 9 14:59:00 2015] I always do. [Fri Jan 9 14:59:03 2015] next time I'll introduce myself as johnw :) [Fri Jan 9 14:59:15 2015] ezyang: I've seen you at the last two ICFPs [Fri Jan 9 14:59:24 2015] Although there is no much point in it, as I use initials and last name for the IRC name. :) [Fri Jan 9 14:59:41 2015] well, you'd never guess that my real name is John W., but still, the association doesn't get made [Fri Jan 9 14:59:50 2015] Your last name is kind of weird [Fri Jan 9 14:59:56 2015] whereas your IRC handle is pretty generic [Fri Jan 9 15:04:40 2015] But with people from around the globe, it's pretty hard to figure what is a name and what just some online handle chosen at random [Fri Jan 9 15:11:39 2015] huh, the only FP person I know in real life is probably the aforementioned CS professor. A few others there were also big FP proponents, but have since retired. [Fri Jan 9 15:11:46 2015] there is a Cincy FP meetup but I've yet to attend [Fri Jan 9 15:12:51 2015] hodapp: That's not bad. I know exactly zero FP users in real life. [Fri Jan 9 15:15:48 2015] dmbaturin: I'm just glad to have escaped a job full of people who were actively opposed to the idea of FP. [Fri Jan 9 15:16:23 2015] mads-: Max Ads? Is that you? [Fri Jan 9 15:21:46 2015] ok, fiat is in Nix now [Fri Jan 9 15:21:53 2015] minus building of examples [Fri Jan 9 16:20:42 2015] notdan: no. My first name is Mads [Fri Jan 9 16:28:54 2015] I'm hoping that notdan's name is not Dan [Fri Jan 9 16:51:40 2015] johnw: Fiat is awefully experimental to go in Nix, but thanks :-) [Fri Jan 9 16:52:19 2015] I'm building the examples now for the "testing" phase at least [Fri Jan 9 16:53:17 2015] Yeah, the examples are pretty slow. An hour or two for them all, if I recall correctly? [Fri Jan 9 16:57:40 2015] yeah, about that [Fri Jan 9 16:57:47 2015] I enabled parallel building, which helped a lot [Fri Jan 9 17:20:47 2015] mads-: sorry, I was making a stupid joke [Fri Jan 9 17:21:00 2015] johnw: my name *is* Dan! [Fri Jan 9 17:21:06 2015] But i like to prentend that it snot [Fri Jan 9 18:01:51 2015] anyone, an idea how this is supposed to be done? [Fri Jan 9 18:01:52 2015] (** **** Exercise: 4 stars, optional (app_length_twice) *) [Fri Jan 9 18:01:52 2015] (** Prove this by induction on [l], without using app_length. *) [Fri Jan 9 18:01:52 2015] Theorem app_length_twice : forall (X:Type) (n:nat) (l:list X), [Fri Jan 9 18:01:52 2015] length l = n -> [Fri Jan 9 18:01:52 2015] length (l ++ l) = n + n. [Fri Jan 9 18:02:00 2015] this is an exercise in sf [Fri Jan 9 18:02:26 2015] i don't see how to prove this even informally without extending the induction claim [Fri Jan 9 18:03:01 2015] and if i extend the claim i can just as well prove length(l ++ m) = length l + length m, which the exercise wants me to avoid [Fri Jan 9 18:03:47 2015] or maybe it does not [Fri Jan 9 18:03:57 2015] though then it would be a stuid exericse? [Fri Jan 9 18:07:04 2015] oh [Fri Jan 9 18:07:06 2015] i'm misreading the hint [Fri Jan 9 18:15:56 2015] anyone else has CoqIDE occasionally crash on "Find"? [Fri Jan 9 18:17:31 2015] arvisrend: During class I heard different people mention different weird crashes in coqIde. [Fri Jan 9 18:17:50 2015] I think the best favor you can do yourself, is to use Emacs with proof general [Fri Jan 9 18:23:28 2015] i would normally love being able to work in emacs, but i can't see myself getting there in foreseeable time [Fri Jan 9 18:23:47 2015] worst thing is, all the keybindings i am used to from past-1990 editors do something completely different in emacs [Fri Jan 9 18:50:26 2015] i think proof general and emacs are both very approachable, i was able to pick them up and learn the basics in a very short amount of time (ymmv) [Fri Jan 9 18:56:08 2015] I can confirm that first years seem to die less with emacs vs. vim. [Fri Jan 9 18:56:21 2015] Not recommended to mix both. They get very confused :P. [Fri Jan 9 18:56:44 2015] thats cuz emacs is more similar to traditional editors [Fri Jan 9 18:56:48 2015] er, traditional as in notepad [Fri Jan 9 18:57:02 2015] you can get away with learning less at once if you use emacs [Fri Jan 9 18:58:52 2015] Yeah. [Fri Jan 9 18:59:04 2015] It also has options for learning more gradually. [Fri Jan 9 18:59:36 2015] But eh. [Fri Jan 9 18:59:46 2015] Emacs is kind of terrible too. [Fri Jan 9 19:00:32 2015] I hope editors improve more in the future :). [Fri Jan 9 19:06:46 2015] arvisrend: Using proof general will only require you to learn a handful of commands. [Fri Jan 9 19:06:50 2015] Shouldn't be that hard [Fri Jan 9 19:07:15 2015] Yeah, I probably only use ~10 emacs commands. [Sat Jan 10 09:53:14 2015] Is it possible to add a notation in the default scope ? [Sat Jan 10 12:26:14 2015] is the bigop package a proper subset of ssreflect's mathematical components? [Sat Jan 10 15:32:50 2015] anyone want to give me a hint on [Theorem lt_trans''] from software foundations? [Sat Jan 10 15:33:29 2015] it's marked with two stars, but I've been scratching my head for hours [Sat Jan 10 15:34:15 2015] it's in the "Rel" chapter. [Sat Jan 10 15:38:31 2015] I need to prove this by induction on [o]: [Theorem lt_trans'' : transitive lt. Proof. unfold lt. unfold transitive. intros n m o Hnm Hmo.] [Sat Jan 10 15:39:03 2015] where [Definition transitive {X: Type} (R: relation X) := forall a b c : X, (R a b) -> (R b c) -> (R a c).] [Sat Jan 10 15:39:26 2015] and [Definition relation (X: Type) := X->X->Prop.] [Sat Jan 10 15:40:28 2015] no matter what I try, I always end up with something like [S o' <= o'] in the goal. [Sat Jan 10 15:41:22 2015] when I try to quit emacs, it asks "save buffer org-src-fontification:coq-mode?", but I can not see this buffer at all! anyone meet this problem also? [Sat Jan 10 15:42:56 2015] I tried to use [inversion] on the hypotheses and [apply le_n] or [apply le_S] whenever I can. do I need anything else? [Sat Jan 10 15:47:27 2015] nkar: well, the first case ( o = 0) can be solved using inversion [Sat Jan 10 15:50:54 2015] nkar: I managed to solve the second case (o = So') by using induction on Hmo, but I guess that is kind a cheating? [Sat Jan 10 15:55:25 2015] notdan: yes, the first case is trivial. my question is about the second case. don't know whether it's cheating or not. the exercises only requires me to perform induction on [o]. [Sat Jan 10 15:55:38 2015] the exercise* [Sat Jan 10 15:59:37 2015] Well, in that case induction Hmo works [Sat Jan 10 16:42:58 2015] notdan: okay, I'll try that [Sat Jan 10 16:43:00 2015] thanks [Sat Jan 10 17:48:20 2015] weird [Sat Jan 10 17:48:22 2015] I : ~ (exists y : X, ~ P y) [Sat Jan 10 17:48:22 2015] H : exists y : X, ~ P y [Sat Jan 10 17:48:25 2015] apply I in H. [Sat Jan 10 17:48:30 2015] > Error: Unable to unify. [Sat Jan 10 17:48:34 2015] what am i doing wrong_ [Sat Jan 10 17:58:19 2015] Check I H. [Sat Jan 10 18:06:49 2015] The term "H" has type "exists y : X, ~ P y" while it is expected to have type [Sat Jan 10 18:06:49 2015] "exists y : X, ~ P y". [Sat Jan 10 18:07:55 2015] another failure of extensionaltiy? [Sat Jan 10 18:52:57 2015] dang [Sat Jan 10 18:53:26 2015] what the heck is this crap [Sat Jan 10 19:03:45 2015] lack of extensionality i fear [Sat Jan 10 19:03:52 2015] i can get past it using witnesses [Sat Jan 10 19:03:53 2015] it's just annoying [Sat Jan 10 21:39:43 2015] hmmmmmmmmmmm [Sat Jan 10 21:39:56 2015] in coq, LEM -> ~LEM [Sat Jan 10 21:40:16 2015] er no wait [Sat Jan 10 21:40:27 2015] it was ~LEM -> LEM [Sat Jan 10 21:44:11 2015] benzrf: the second one is right. in fact, ~LEM -> False, ie, ~~LEM. [Sat Jan 10 21:44:25 2015] yeah [Sat Jan 10 21:44:40 2015] but ~LEM -> False is /because/ ~LEM -> LEM, not vice versa [Sun Jan 11 00:10:42 2015] I have little to know familiarity with coq, and have some very basic questions that are actually about theorem provers in general. I am not sure if here is the appropriate place to ask such things. Is it? [Sun Jan 11 00:12:05 2015] LordBrain: I'm sure you could ask [Sun Jan 11 01:56:22 2015] thanks Cale, i'm getting help in ##typetheory [Sun Jan 11 03:56:08 2015] what happen when you re-define the type bool and the function andb ? [Sun Jan 11 03:59:22 2015] it simply shadows standard library ? [Sun Jan 11 09:17:46 2015] notdan: how does induction on Hmo work? [Sun Jan 11 09:19:23 2015] I don't remember, let me see [Sun Jan 11 09:20:43 2015] Hmo : S m <= S o'. So, Either S m = S o', or S m <= o', right? [Sun Jan 11 09:21:07 2015] In the first case, we replace our goal S n <= S m. [Sun Jan 11 09:21:19 2015] But we also have Hnm: S n <= m [Sun Jan 11 09:21:27 2015] by using le_S we can solve our goal [Sun Jan 11 09:21:34 2015] Now, in the second case [Sun Jan 11 09:23:39 2015] well, we have S n <= o', f hypothesisby induction [Sun Jan 11 09:23:47 2015] and we apply le_S again [Sun Jan 11 09:24:15 2015] Sorry I am really bad at explaining it. Try stepping through the script yourself: [induction Hmo; apply le_S; assumption.] [Sun Jan 11 11:59:43 2015] notdan: okay, that's cheating. another solution of that kind is to apply le_trans with the proper arguments. [Sun Jan 11 12:01:29 2015] notdan: I gave up and started to search for the proper solution. when I found it, I was like "whoa!" because it's so simple. I'm surprised that I didn't find it myself. [Sun Jan 11 12:03:33 2015] notdan: I sent it to you via /q, so I don't spoil the fun for others. [Sun Jan 11 18:09:15 2015] any hints on how to approach [Theorem le_Sn_n : forall n, ~(S n <= n).]? [Sun Jan 11 18:11:55 2015] the examples shown in the Rel chapter of software foundations so far proved such things by contradiction. but in this case, when I introduce [S n <= n] to the context, it cannot be applied to something gibberish like [1 <= 0]. [Sun Jan 11 18:12:36 2015] it's marked with a single star, but I don't see a way to do it. [Sun Jan 11 18:16:49 2015] nkar: do you have a lemma "S n <= S m -> n <= m"? if so, your lemma should go through by induction, using that lemma in the inductive case. [Sun Jan 11 18:50:07 2015] inversion? [Sun Jan 11 21:24:13 2015] I forgot to mention that I don't understand why coq doesn't discard the current goal when I do [inversion H.] where [H] : [S n = n] or [1 = 0]. [Sun Jan 11 21:26:44 2015] you have to use induction to get a constradiction from a cycle such as S n = n [Sun Jan 11 21:26:50 2015] 1 = 0 can be discriminated immediately though [Sun Jan 11 21:28:53 2015] hm, maybe I didn't manage to introduce 1 = 0 to the context. [Sun Jan 11 21:29:03 2015] vanila: hi :) [Sun Jan 11 22:02:33 2015] ah, I mean 1 <= 0, not 1 = 0. [Sun Jan 11 22:03:55 2015] wait, it gets discarded, too. [Sun Jan 11 22:21:44 2015] yes, 1 <= 0 gets discarded as there is no constructor for it [Sun Jan 11 22:23:30 2015] elimtype False; omega. will solve your goal [Sun Jan 11 22:25:29 2015] how can I use [apply ... with] on a hypothesis? [Sun Jan 11 22:25:43 2015] [apply le_trans in H with (c := b).] doesn't work. [Sun Jan 11 22:25:57 2015] as well as [apply le_trans with (c := b) in H.]. [Sun Jan 11 22:27:28 2015] what do you have and what do you want to get? [Sun Jan 11 22:34:16 2015] that's not important, I think. I'm asking about the proper syntax, basically. [Sun Jan 11 22:34:48 2015] i cant help you because I don't know what you want to do [Sun Jan 11 22:36:45 2015] okay [Sun Jan 11 23:41:58 2015] how can I prove [a <= b -> b <= a -> a = b], that is, the fact that [le] is antisymmetric. knowing that [a <= b] and [b <= a] is enough to conclude that [a = b]. is there a tactic I could use to express this? or do I need to approach this differently? [Sun Jan 11 23:42:39 2015] omega will proves things like this instantly [Sun Jan 11 23:42:54 2015] did you want to do it from first principles? [Sun Jan 11 23:43:30 2015] what does "from first principles" mean? [Sun Jan 11 23:43:45 2015] [omega] hasn't been used in sf so far, so I'd rather not use it. [Sun Jan 11 23:43:45 2015] without automatic tactics like omega [Sun Jan 11 23:43:51 2015] yes, see above [Sun Jan 11 23:44:00 2015] see what? [Sun Jan 11 23:44:40 2015] I was saying that I want to do it without [omega]. [Sun Jan 11 23:44:50 2015] oh, btw. I forgot to mention one thing [Sun Jan 11 23:44:52 2015] I don't see that [Sun Jan 11 23:45:14 2015] maybe you said it before I joined [Sun Jan 11 23:45:34 2015] I already have a proof of ~(symmetric le). I wonder if I can use it. [Sun Jan 11 23:46:16 2015] If I use [ex_falso_quodlibet], I can apply it. but the variables I get in the context will be differnt [Sun Jan 11 23:46:19 2015] different* [Sun Jan 11 23:47:32 2015] I mean the existing hypotheses in the context are not general enough to apply use ~(symmetric le), it seems. [Sun Jan 11 23:47:49 2015] anyway, how would you do it without [omega]? [Sun Jan 11 23:48:14 2015] not sure, im going to try [Sun Jan 11 23:49:45 2015] vanila: it's from the rel chapter of sf. maybe you'll need to use the definitions from the book. [Sun Jan 11 23:56:29 2015] if you destruct hypotheses you are just left with S (S m) <= m which you can disprove by induction [Sun Jan 11 23:56:35 2015] both hypotheses [Mon Jan 12 01:12:06 2015] vanila: what do I need to do next? [Proof. unfold antisymmetric. intros. destruct H. Case "destruct H". reflexivity. destruct H0. SCase "destruct H0". reflexivity. induction m as [|m']. SSCase "m = 0". inversion H. Abort.] [Mon Jan 12 01:12:32 2015] how do I prove [SSCase "m = S m'".]? [Mon Jan 12 01:13:28 2015] I can't step through your proof since unfold antisymmetric doens't work [Mon Jan 12 01:13:44 2015] oh wait if i ignore that i can [Mon Jan 12 01:13:57 2015] H : S m0 <= m [Mon Jan 12 01:13:57 2015] H0 : S m <= m0 [Mon Jan 12 01:13:59 2015] at this point [Mon Jan 12 01:14:17 2015] you can can do assert (S (S m) <= m). [Mon Jan 12 01:14:31 2015] and prove that using le_trans and le_n_S (SearchAbout le to find useful lemmas) [Mon Jan 12 01:14:41 2015] then clear away H, H0 and do the induction [Mon Jan 12 01:14:56 2015] instead of just going straight into the induction [Mon Jan 12 01:17:14 2015] vanila: I cannot apply le_trans: Impossible to unify "transitive le" with "S (S m) <= m". [Mon Jan 12 01:18:15 2015] (le_trans is defined in terms of the transitive relation) [Mon Jan 12 01:21:01 2015] oh, it works if I use [with] [Mon Jan 12 06:51:05 2015] just tried to compile the current git checkout, and got the error http://lpaste.net/118311 [Mon Jan 12 09:37:21 2015] Where do I find the gallina grammar specification? [Mon Jan 12 09:38:49 2015] Curios what else is there but the small part of the language I've already seen. :) [Mon Jan 12 14:31:56 2015] Is-it possible to save several theorems in a kind of record ? [Mon Jan 12 14:33:00 2015] Let's assume I have two theorems proving the same thing, but I have to treat two case (Because it is much more easier to express in the theorem hypothesis, and it's easier for the proof too) [Mon Jan 12 14:34:18 2015] So I create these two theorems (With two different name), but now I would like to be able to use both as one (i.e. apply it with a single name, because it refers to the same theorem) [Mon Jan 12 14:35:11 2015] Of course, it would create a subgoal (or something like that) to prove why do we use one theorem, and not the other one [Mon Jan 12 14:35:29 2015] (I don't know if it is really clear .. :s) [Mon Jan 12 14:35:53 2015] Choups314: not really following. is it like you have P -> Q and ~ P -> Q and you want to be able to apply "both" whenever your goal is Q? [Mon Jan 12 14:53:01 2015] Choups314: did you figure out what it was you were trying to do? [Mon Jan 12 14:54:02 2015] oh, I see you posted on coq club [Mon Jan 12 14:54:13 2015] Yes ;) [Mon Jan 12 14:54:29 2015] Choups314: one idea would be to prove a final theorem that combines theorems by deciding which one to use [Mon Jan 12 14:54:50 2015] (this only works if the predicates that make up the hypotheses are decidable or if you assume lem) [Mon Jan 12 14:55:09 2015] It is decidable [Mon Jan 12 14:55:42 2015] In fact, it is just a case : [equal zero or not], for a specific type [Mon Jan 12 14:56:10 2015] so do you see what I mean? if you have [thm1 : P = 0 -> Q] and [thm2 : P <> 0 -> Q] then you can prove [thm : Q] by destructing on P and applything thm1 and thm2 in the two subgoals [Mon Jan 12 14:56:24 2015] and then you just use thm everywhere [Mon Jan 12 14:56:38 2015] Hooo [Mon Jan 12 14:56:47 2015] That's good ! [Mon Jan 12 14:56:50 2015] Easy and clear :) [Mon Jan 12 14:59:19 2015] The case P=0 leads to completely different hypothesis, that's why I wanted two different theorems [Mon Jan 12 14:59:22 2015] Thanks ! [Mon Jan 12 14:59:45 2015] np, glad to help [Mon Jan 12 15:00:14 2015] I will write your solution on the mailing list, to avoid duplicates ;) [Tue Jan 13 12:40:34 2015] http://en.wikipedia.org/wiki/Calculus_of_constructions#Defining_logical_operators [Tue Jan 13 13:12:50 2015] Hi, is there a reasson that in Lists, In is defined as a Fixpoint rather than an Inductive definition? Is there any difference between the Fixpoint definition and the Inductive definition? [Tue Jan 13 13:18:15 2015] bennofs: they should be logically equivalent, but the fixpoint one might work better with Coq's pattern matching [Tue Jan 13 13:18:43 2015] because you just have to match on the list and the In will be able to simplify [Tue Jan 13 13:19:21 2015] Ah right, so it avoids needing the `inversion` tactic [Tue Jan 13 18:40:38 2015] is there anything in the standard library that takes a (list Set) and gives a Set of values? [Tue Jan 13 18:41:29 2015] I might mean “Type” instead of “Set” [Tue Jan 13 18:51:58 2015] (I ended up just writing it) [Tue Jan 13 19:01:49 2015] amosr: wut [Tue Jan 13 19:01:54 2015] amosr: how does that work [Tue Jan 13 19:02:14 2015] benzrf: I probably just explained it poorly [Tue Jan 13 19:02:16 2015] it’s just this: [Tue Jan 13 19:02:18 2015] Inductive Values : list Type -> Type := [Tue Jan 13 19:02:18 2015] | v_nil : Values [] [Tue Jan 13 19:02:19 2015] | v_cons x xs : list x -> Values xs -> Values (x :: xs). [Tue Jan 13 19:02:50 2015] oh, an HList [Tue Jan 13 19:03:05 2015] er, well [Tue Jan 13 19:03:12 2015] an HList of lists [Tue Jan 13 19:03:18 2015] ah, yup [Wed Jan 14 06:42:00 2015] hm. what would have to be done to be able to utilize multiple cores when compiling coq? [Wed Jan 14 10:27:08 2015] schoppenhauer: run `make -j` or `make -j4` (or however many threads you want) [Wed Jan 14 13:59:18 2015] If I have a Definition foo : list int -> int := bar 3, and bar does a `match` on it's argument, is there a tactic that I could use to simplify `foo (x :: xs)`? (without needing to use unfold manually) [Wed Jan 14 14:01:16 2015] just "simpl" should do it, doesn't it? [Wed Jan 14 14:01:38 2015] johnw: no, simpl will not unfold definitions that don't use match, it seems [Wed Jan 14 14:01:58 2015] then I don't know of any better tactic [Wed Jan 14 14:02:15 2015] hnf seems to work [Wed Jan 14 14:02:25 2015] compute? [Wed Jan 14 14:03:06 2015] benzrf: compute unfold too much in my case, but hnf works fine [Wed Jan 14 14:03:10 2015] computer is nearly always too heavy-handed [Wed Jan 14 14:03:17 2015] ah, yes, hnf [Wed Jan 14 14:03:23 2015] I wonder if "red"would work too [Wed Jan 14 14:03:35 2015] johnw: red does one step, so I'd need to red; simpl [Wed Jan 14 14:03:36 2015] in ssreflect I'd say "move." [Wed Jan 14 14:03:56 2015] I'm slowly getting disconnected from the standard tactics... [Wed Jan 14 14:04:09 2015] I can tell you whether that's a good thing or a bad thing. I guess it all depends on who I might have to collaborate with in the future [Wed Jan 14 14:04:14 2015] s/can/can't [Wed Jan 14 14:04:15 2015] * should learn ssreflect sometime [Wed Jan 14 14:04:20 2015] i love it [Wed Jan 14 14:38:30 2015] jgross: thank you. that works. [Wed Jan 14 14:40:33 2015] another question: I am currently trying to make my code run under the stable coq release (used git so far). Fin.to_nat_inj seems not to be in the stable library yet, what can I use instead? [Wed Jan 14 14:47:38 2015] you can copy it from the unstable version [Wed Jan 14 14:51:05 2015] ok, did so, thx. [Wed Jan 14 15:35:10 2015] is it just me or is the ceval_deterministic exercise in Imp.v of the sf book supposed to take pages of repetitive code? [Wed Jan 14 15:35:34 2015] like, induction over one of the conditions and inversion of the others, totalling to some 100 cases? [Wed Jan 14 17:01:32 2015] arvisrend: in the proof given in the book, they use a semicolon to eliminate most of those cases. [Wed Jan 14 17:01:41 2015] are you trying to reproduce a proof without looking at theirs? [Wed Jan 14 17:04:23 2015] yes [Wed Jan 14 17:04:32 2015] and i can't figure out good ways to use semicolons there [Wed Jan 14 17:04:45 2015] i'd need something like "apply all induction hypotheses to whatever seems reasoanble" [Wed Jan 14 17:04:50 2015] but wait [Wed Jan 14 17:04:53 2015] is there a proof given in the book? [Wed Jan 14 17:05:01 2015] or do you have a solutions manual? [Wed Jan 14 17:05:07 2015] oooh [Wed Jan 14 17:05:09 2015] sorry [Wed Jan 14 17:05:15 2015] i'm talking about the exercise ceval_deterministic [Wed Jan 14 17:05:17 2015] not the theorem [Wed Jan 14 17:05:43 2015] oh I see. [Wed Jan 14 17:05:47 2015] i actually forgot that the theorem existed by the time i came to the exercise [Wed Jan 14 17:05:49 2015] same thing should work though? [Wed Jan 14 17:05:53 2015] probably [Wed Jan 14 17:06:10 2015] I would suggested looking at how they set up their induction [Wed Jan 14 17:07:38 2015] okay, essentially they automate one of the two inductions, leaving the other one expicit [Wed Jan 14 17:07:42 2015] i guess i can do that too, thanks [Wed Jan 14 17:07:55 2015] although i hate the way they use automatically generated hypothesis names [Wed Jan 14 17:11:19 2015] arvisrend: you can always use "try" [Wed Jan 14 17:11:32 2015] induction x; try exact foo. [Wed Jan 14 17:15:41 2015] yes, but i need to know the names of all the hypotheses [Wed Jan 14 17:16:01 2015] and i need to make sure that a tactic that solves one branch doesn't dead-end another [Wed Jan 14 17:16:27 2015] well, exact only fires if it solves that branch [Wed Jan 14 17:16:33 2015] otherwise, it would leave the branch alone [Wed Jan 14 17:16:41 2015] same with the solve tactic [Wed Jan 14 17:16:57 2015] hmm solve [Wed Jan 14 17:17:01 2015] Yeah, I’d use 'try solve [exact foo]' for this. [Wed Jan 14 17:17:20 2015] what exactly does solve do? [Wed Jan 14 17:17:31 2015] ah [Wed Jan 14 17:17:43 2015] it's something like simple? [Wed Jan 14 17:17:51 2015] It takes a pipe-separated list of tactics and tries each one in order. If one succeeds in solving the current goal, it succeeds; if none succeed, it fails with an error. [Wed Jan 14 17:18:18 2015] If you’re writing 'exact foo', though, you might consider writing 'assumption' instead [Wed Jan 14 17:18:21 2015] nice, that's helpful [Wed Jan 14 17:18:39 2015] 'try solve' makes 'solve' not crash your entire proof script if it fails. [Wed Jan 14 17:19:44 2015] is there something like "try to inversion every hypothesis and see if one of them leaves no subgoals"? [Wed Jan 14 17:19:54 2015] without knowing the names of the hypotheses [Wed Jan 14 17:20:04 2015] something like "assumption" [Wed Jan 14 17:20:23 2015] you could do that with repeat and match goal [Wed Jan 14 17:20:29 2015] match goal? [Wed Jan 14 17:20:50 2015] repeat match goal [ H: _ | _] with => solve (inversion H) end [Wed Jan 14 17:20:57 2015] or [inversion H], sorry [Wed Jan 14 17:21:17 2015] repeat match goal with [ H: _ | _] => solve [inversion H] end [Wed Jan 14 17:21:18 2015] hmm [Wed Jan 14 17:21:24 2015] here, failures cause the proof search to continue [Wed Jan 14 17:21:26 2015] ok i have no idea what it means but i'll try it! [Wed Jan 14 17:22:03 2015] I really wish the SF folks weren’t so allergic to automation. [Wed Jan 14 17:22:24 2015] Like, obviously, you can use it as a crutch. But teaching people about Ltac a bit earlier than they do could save a /lot/ of student time [Wed Jan 14 17:22:24 2015] allergic? [Wed Jan 14 17:22:30 2015] they use it too much :/ [Wed Jan 14 17:22:39 2015] Wait, really? [Wed Jan 14 17:22:41 2015] * looks at Imp.v [Wed Jan 14 17:22:42 2015] i wish i had some more stuff to train on manually [Wed Jan 14 17:22:54 2015] although i care more for math theorems [Wed Jan 14 17:23:05 2015] and math theorems don't tend to have these many branches [Wed Jan 14 17:23:28 2015] Ah, [Imp] introduces automation. Never mind. [Wed Jan 14 17:23:38 2015] imp does, although it explains little of it [Wed Jan 14 17:23:44 2015] ltac doesn't appear until, i think, much later [Wed Jan 14 17:24:24 2015] So, basically, Ltac has this construct 'match goal with [STUFF |- GOAL] => TAC end', which kind of mimics the normal Gallina match construct. [Wed Jan 14 17:24:29 2015] (Syntactically, at least.) [Wed Jan 14 17:24:49 2015] It lets you pattern-match on your proof state and then take action based on it. [Wed Jan 14 17:24:52 2015] ah [Wed Jan 14 17:25:02 2015] i thought because of the "goal" word that it would only match the actual GOAL [Wed Jan 14 17:25:18 2015] Yeah, it’s poorly named. [Wed Jan 14 17:25:38 2015] STUFF gets matched against the context, and GOAL gets matched against the goal. [Wed Jan 14 17:25:55 2015] So in johnw’s suggestion, you have '[ H : _ |- _ ]' [Wed Jan 14 17:25:57 2015] i think a different word than match should have been used [Wed Jan 14 17:26:27 2015] ah yes, |- [Wed Jan 14 17:26:42 2015] '[ H : _ |- _ ]' will match any hypothesis and any goal. [Wed Jan 14 17:27:35 2015] So I think the way johnw’s suggestion is supposed to work is to grab some hypothesis and try solving by inverting it. If that fails, 'repeat' with the next hypothesis, and so on. [Wed Jan 14 17:28:02 2015] match itself should continue to the next hypothesis [Wed Jan 14 17:28:12 2015] the repeat is there so that if it succeeds, we try again [Wed Jan 14 17:28:21 2015] Ah, okay, cool. [Wed Jan 14 20:24:05 2015] how readable is sergey's "Programs and Proofs"? [Wed Jan 14 20:27:26 2015] VERY [Wed Jan 14 20:27:28 2015] I love that book [Wed Jan 14 20:27:53 2015] even people who aren't going to use ssreflect should read it, just because it makes so many of the core ideas so much clearer [Wed Jan 14 20:28:12 2015] good to hear [Wed Jan 14 20:28:34 2015] as it seems to be the only introduction into ssreflect beyond the 40-or so page tutorial [Wed Jan 14 20:30:48 2015] yep, and in fact, it is [Wed Jan 14 20:31:01 2015] it was truly like finding an oasis in a desert [Wed Jan 14 20:31:11 2015] I didn't even grasp what reflection really meant until that book [Thu Jan 15 09:16:14 2015] is there any standard way of documenting coq code? [Thu Jan 15 09:16:23 2015] (like javadoc or doxygen) [Thu Jan 15 09:16:28 2015] coqdoc! [Thu Jan 15 09:24:20 2015] coq doc: the doc for yr coq [Thu Jan 15 09:24:52 2015] thx [Thu Jan 15 13:32:38 2015] spermbank.io [Thu Jan 15 14:41:55 2015] m4farrel: your online repository of Coq output? [Thu Jan 15 17:57:22 2015] [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup [Thu Jan 15 18:28:03 2015] hmmmmmm [Thu Jan 15 18:28:28 2015] you cannot prove things about coq from within coq, right? [Thu Jan 15 18:28:45 2015] well... dependeing on their generality? [Thu Jan 15 18:28:59 2015] http://www.lix.polytechnique.fr/~barras/publi/coqincoq.pdf [Thu Jan 15 18:29:22 2015] funny how Google has these things you can search for, isn't it? [Thu Jan 15 18:31:07 2015] blehh [Thu Jan 15 19:17:36 2015] anyway i [Thu Jan 15 19:17:41 2015] was thinking [Thu Jan 15 19:18:05 2015] coq's lack of turing completeness means that you cannot do things like gödel-number its terms, right [Thu Jan 15 19:18:15 2015] er, fuck [Thu Jan 15 19:18:18 2015] i dont know what im doing [Thu Jan 15 19:30:30 2015] anyone knows if "extended" induction principles like the gorgeous_ind_max in sf/MoreInd.v are provable in coq? [Thu Jan 15 19:30:52 2015] here's the page http://www.cis.upenn.edu/~bcpierce/sf/current/MoreInd.html [Thu Jan 15 19:32:16 2015] basically we're inducting over an inductive predicate called "gorgeous", and unlike in the usual induction principle that coq generates from its inductive definition, we want to prove a claim about a piece of evidence for that predicate [Thu Jan 15 19:32:40 2015] whereas the usual induction principle only allows proving a claim about the arguments of the predicate [Thu Jan 15 19:32:44 2015] if this makes any sense [Thu Jan 15 20:05:10 2015] arvisrend: hm, I think so [Thu Jan 15 20:05:14 2015] let me try [Thu Jan 15 20:14:41 2015] arvisrend: http://lpaste.net/118536 [Thu Jan 15 20:17:54 2015] nice! [Thu Jan 15 20:17:55 2015] thank you [Thu Jan 15 20:20:34 2015] so match is a more reliable way to decompose an inductive than induction [Fri Jan 16 08:28:42 2015] question... [Fri Jan 16 08:28:55 2015] is it possible to prove that the natural numbers are well-ordered in coq? [Fri Jan 16 08:28:57 2015] it's not, is it? [Fri Jan 16 08:36:56 2015] I think it is possible [Fri Jan 16 08:38:00 2015] rly? [Fri Jan 16 08:41:06 2015] let me try [Fri Jan 16 08:42:24 2015] doesnt this follow by induction? [Fri Jan 16 08:42:45 2015] (I mean, usually...) [Fri Jan 16 08:43:05 2015] what is it? I just joined [Fri Jan 16 08:47:23 2015] well-orderedness of natural numbers [Fri Jan 16 08:48:17 2015] thats in the standard library (Wf) [Fri Jan 16 09:00:58 2015] o.O [Fri Jan 16 09:01:04 2015] vanila: what type is it [Fri Jan 16 09:06:00 2015] benzrf, it's the Lemma lt_wf in https://coq.inria.fr/library/Coq.Arith.Wf_nat.html . The type well_founded (as well as the underlying inductive predicate Acc) is defined in Coq.Init.Wf [Fri Jan 16 09:25:01 2015] ok I did it [Fri Jan 16 09:25:09 2015] oh snap you guys already found the solution :S [Fri Jan 16 09:25:37 2015] Anyway, here is my take https://gist.github.com/co-dan/79f4f67b3f9566a1eb58 [Fri Jan 16 09:30:16 2015] wwwwwwwwwwwwwwwwwwwwwwwwwwww [Fri Jan 16 09:30:21 2015] oops [Fri Jan 16 09:32:04 2015] errrrr [Fri Jan 16 09:32:12 2015] what does well_founded actually do [Fri Jan 16 09:35:12 2015] benzrf, it's defined in terms of Acc. Acc x states that if all elements smaller than x are accessible, then so is x -- this corresponds to a statement that all decreasing chains from x are finite. [Fri Jan 16 09:35:32 2015] and well_founded says this is the case for all x [Fri Jan 16 09:36:04 2015] o.O [Fri Jan 16 09:36:08 2015] accessible? [Fri Jan 16 09:36:19 2015] well, yeah, hence Acc [Fri Jan 16 09:36:25 2015] no, what does that mean [Fri Jan 16 09:37:29 2015] fisi: well im probably xy'ing over here [Fri Jan 16 09:37:42 2015] I basically wrote out the definition of Acc (specialized to less-than on naturals). An number x is accessible if all smaller numbers are accessible. [Fri Jan 16 09:37:50 2015] s/An/A/ [Fri Jan 16 09:37:57 2015] Maybe you're more used to the definition that says that every non-empty set of integers has a least element, but it's equivalent I believe. [Fri Jan 16 09:39:34 2015] Cypi, that's the thing, classically it definitely is, but here we have subsets and non-emptiness is tricky... I'm not entirely sure what the right formulation of well-ordering would be in the intuitionistic case (and if it'd be equivalent). [Fri Jan 16 09:40:55 2015] http://lpaste.net/118573 >> would something like that satisfy you in the case of subsets of integers? (don't bother with the proofs I guess, just the types are enough) [Fri Jan 16 09:43:11 2015] fisi: basically i worked out that im pretty sure in coq you can prove "not exists a least element of the set of natural numbers that cannot be described in under 1000000 digits of coq's gödel-enumeration" [Fri Jan 16 09:43:27 2015] fisi: and i was wondering if that contradicts the coq formulation of well-ordering [Fri Jan 16 09:50:11 2015] benzrf, I honestly have no clue. Lots of negations, too. [Fri Jan 16 10:59:51 2015] what is the difference between Require Import and Require Export? [Fri Jan 16 11:00:58 2015] the latter makes imported symbols available to downstream importers [Fri Jan 16 11:01:42 2015] ah! [Fri Jan 16 14:28:38 2015] linearscan was pushed to Hackage today; a Haskell library built entirely in Coq! [Fri Jan 16 14:32:19 2015] awesome! [Fri Jan 16 14:32:28 2015] collaborators welcome at this point too [Fri Jan 16 14:33:24 2015] I've completed the first step of integrating the library with our in-house compiler, but there are some nice optimizations laid out in Wimmer's thesis that I may never have time to implement in Coq [Fri Jan 16 14:35:18 2015] is there a paper on how this was done? [Fri Jan 16 14:35:38 2015] there is an experience report under the doc/ directory on GitHub [Fri Jan 16 14:35:47 2015] or do you mean the allocation algorithm itself? [Fri Jan 16 14:35:53 2015] thats perfect! [Fri Jan 16 14:36:21 2015] with luck, I'll be presenting at NASA Formal Methods, let's hope they accept [Fri Jan 16 14:37:03 2015] best of luck! [Fri Jan 16 14:37:07 2015] thanks, vanila [Fri Jan 16 14:37:26 2015] I think you may be one of the only people who actually gets excited when I mention this library :) [Fri Jan 16 14:38:02 2015] i showed my friend too and they're really impressed [Fri Jan 16 14:38:23 2015] i wonder if there's a master list of haskell libs implemented in coq [Fri Jan 16 14:38:58 2015] I know of another, only I've forgotten the name now [Fri Jan 16 14:39:07 2015] and they don't implement the entire thing in Coq, just a verified core [Fri Jan 16 14:49:17 2015] johnw: I'm not as experienced as vanila, but I'm very excited, too. congratulations! [Fri Jan 16 14:49:23 2015] thanks nkar! [Fri Jan 16 14:50:30 2015] you could put it into compcert maybe [Fri Jan 16 14:50:55 2015] perhaps so, if we get to 1.0 [Fri Jan 16 14:51:11 2015] next step is to finish implementation of register spilling [Fri Jan 16 14:54:08 2015] johnw: but compcert is proprietary. I hope you don't change the license. [Fri Jan 16 14:54:17 2015] johnw: will your talk be recorded? [Fri Jan 16 14:54:39 2015] I don't know if they record at that conference; and the license on my side is BSD [Fri Jan 16 14:55:12 2015] compcert is GPL [Fri Jan 16 14:55:44 2015] so, they can use me just fine, I just can't use them, which works in this case [Fri Jan 16 14:55:48 2015] vanila: last time I checked it was for non-commercial use only. maybe parts of it are gpl'd, though. [Fri Jan 16 14:56:30 2015] oh [Fri Jan 16 14:56:59 2015] thats annoying [Fri Jan 16 14:58:26 2015] johnw: consider announcing the package on haskell-cafe. maybe it'll inspire others to use coq the way you do [Fri Jan 16 14:59:21 2015] once I get just a bit more of it completed I will [Fri Jan 16 15:01:19 2015] but I am hoping for this to show that Coq can be seriously used to assist Haskell development [Fri Jan 16 16:14:27 2015] Hi, how can I define a function of type [forall x : T, P x -> T] (where [T] is a type and [P] a predicate) ? [Fri Jan 16 16:17:55 2015] forall (T : Type) (x : T) (P : T -> Type), P x -> T [Fri Jan 16 16:18:34 2015] [fun (x : T) (_ : P x) => x] is such a function, for example. [Fri Jan 16 16:39:24 2015] oh, I'm sorry [Fri Jan 16 16:39:26 2015] *define* it [Fri Jan 16 16:44:41 2015] Thank you @ [Fri Jan 16 16:44:44 2015] !* [Sat Jan 17 11:13:30 2015] referencing automatically named hypotheses [Sat Jan 17 11:13:36 2015] is it bad or just meh? [Sat Jan 17 11:13:56 2015] the danger is that the name might be different if something minor changes [Sat Jan 17 11:14:17 2015] yes, but that's on the other hand relatively easy to bugfix [Sat Jan 17 11:14:30 2015] compared to stuff like leaking into another case [Sat Jan 17 11:14:31 2015] in a small development, sure [Sat Jan 17 11:14:44 2015] but in a larger project it could become a real horror [Sat Jan 17 11:42:20 2015] are permutations (as maps {1,2,...,n} to {1,2,...,n}) somewhere in coq's library? [Sat Jan 17 11:42:36 2015] i see coq has permutations of lists, as inductive predicates, but that's sth different [Sat Jan 17 11:43:14 2015] generally, where do i find the idea that a list of length n corresponds to a function {1,2,...,n} to X modulo equality-upon-application [Sat Jan 17 13:39:48 2015] fucking hell [Sat Jan 17 13:39:55 2015] i feel i'm not getting better but my code is getting uglier :/ [Sat Jan 17 15:07:45 2015] is there a way to use this http://pierre-yves.strub.nu/ with coqide? [Sat Jan 17 15:07:50 2015] the coq bundle imean [Sat Jan 17 15:11:13 2015] ah nice it has coqide already [Sat Jan 17 15:16:20 2015] should i be worried about it only being 8.4pl2 not 8.4pl5? [Sat Jan 17 15:16:27 2015] and ssreflect being 1.4 not 1.5? [Sat Jan 17 16:43:15 2015] I try to avoid auto-named hypotheses as much as possible now [Sat Jan 17 16:43:18 2015] they do get to be a nightmare [Sat Jan 17 18:03:34 2015] what is -> notation for as a type ctor [Sat Jan 17 18:03:57 2015] basically is there an expression i can type : Type -> Type -> Type [Sat Jan 17 18:04:53 2015] Does [fun (x _ : Type) => x] satisfy you? [Sat Jan 17 18:04:59 2015] (maybe I've not understood what you meant) [Sat Jan 17 18:06:36 2015] oh bleh [Sat Jan 17 18:06:41 2015] Cypi: 1 sec [Sat Jan 17 18:07:38 2015] bluuUUUUUUH [Sat Jan 17 18:07:43 2015] this is garbage [Sat Jan 17 18:08:06 2015] i should be doing my homework for once in my life anyway, never mind!!! [Sat Jan 17 18:58:54 2015] so what exactly can i do with Set that i can't with Type? [Sat Jan 17 19:11:21 2015] arvisrend: universe stuff i guess [Sat Jan 17 19:11:58 2015] hmm [Sat Jan 17 19:44:47 2015] benzrf: I don't believe that means anything [Sat Jan 17 19:46:58 2015] arvisrend: for one thing, when you deal with Set, it is always something that should be extracted [Sat Jan 17 19:47:30 2015] when you deal with Type, Coq sometimes can't know whether it should or shouldn't be extracted, so it extracts it anyway [Sat Jan 17 19:47:45 2015] plus, as benzrf hinted, Type can occur at many universe levels, but Set at only one [Sat Jan 17 19:48:34 2015] in general, I like to have all of my "data" types in Set, my propositions in Prop, and only use Type if I need to combine the two, or if I need higher universes [Sat Jan 17 19:48:42 2015] hmm [Sat Jan 17 19:48:42 2015] more here: http://adam.chlipala.net/cpdt/html/Universes.html [Sat Jan 17 19:48:44 2015] ok [Sat Jan 17 19:48:59 2015] so subtypes of sets defined by predicates are only types? [Sat Jan 17 19:49:06 2015] ah, now I see what benzrf means by "universe stuff", yes he is right about that [Sat Jan 17 19:49:43 2015] right: Inductive sig (A : Type) (P : A -> Prop) : Type [Sat Jan 17 19:49:52 2015] A there could be Set [Sat Jan 17 19:49:57 2015] but the type of sig would have to be Type [Sat Jan 17 19:50:04 2015] thank you [Sat Jan 17 19:50:17 2015] how do people in reality work with subtypes defined by predicates? [Sat Jan 17 19:50:31 2015] using predicates [Sat Jan 17 19:50:35 2015] like, what if i want to define a map from such a subtype, and i want to encode the fact that it does not depend on the proof of the predicate [Sat Jan 17 19:50:36 2015] that's the beauty of dependent types [Sat Jan 17 19:50:51 2015] you need to import proof irrelevance [Sat Jan 17 19:51:12 2015] uhm [Sat Jan 17 19:51:26 2015] that's an axiom which maybe does far more than i want? [Sat Jan 17 19:51:43 2015] is this what you mean by a mapping: f : forall a P (x : a), P x -> { x' : a | P x' } [Sat Jan 17 19:51:55 2015] proof irrelevance? it's a pretty simple axiom [Sat Jan 17 19:52:10 2015] basically i want a map from {0,1,...,n-1} to some type T [Sat Jan 17 19:52:13 2015] it just means that all inhabitants of a given Prop type are equivalent [Sat Jan 17 19:52:34 2015] as far as i understand {0,1,...,n-1} is the set of all m : nat with lt m n [Sat Jan 17 19:52:45 2015] unless there is a better way to define it [Sat Jan 17 19:52:54 2015] f : forall (x n : nat), x < n -> T [Sat Jan 17 19:52:56 2015] but now i want to define the notion of a permutation of {0,1,...,n-1} [Sat Jan 17 19:53:05 2015] yes [Sat Jan 17 19:53:32 2015] but what if i want to show that there are exactly n! permutations [Sat Jan 17 19:53:45 2015] of course i'll have to use equality-upon-evaluation instead of equality [Sat Jan 17 19:53:49 2015] but i'm not sure if there is enough [Sat Jan 17 19:53:51 2015] *that [Sat Jan 17 19:53:53 2015] Lemma permutations : forall x, f x = x!. [Sat Jan 17 19:54:00 2015] or whatever T means [Sat Jan 17 19:54:18 2015] something like this is much simpler with ssreflect, btw [Sat Jan 17 19:54:28 2015] in what way? [Sat Jan 17 19:54:36 2015] these sorts of decidable questions involves sets and numbers are computable [Sat Jan 17 19:54:42 2015] involving* [Sat Jan 17 19:54:56 2015] so over there we'd say: [Sat Jan 17 19:55:19 2015] f : forall (x n : nat), x < n -> size (permutations x) == factorial n. [Sat Jan 17 19:55:21 2015] or something like that [Sat Jan 17 19:55:36 2015] that should not be named f, you get the idea [Sat Jan 17 19:55:51 2015] yes, but what is "permutations x" precisely? [Sat Jan 17 19:55:53 2015] and what is "size"? [Sat Jan 17 19:55:59 2015] size is "length" [Sat Jan 17 19:56:02 2015] the length of the list [Sat Jan 17 19:56:06 2015] ok so there is a list? [Sat Jan 17 19:56:09 2015] permutations return a list of lists [Sat Jan 17 19:56:19 2015] yes, ssreflect has a "seq" wrapper around Coq's "list" [Sat Jan 17 19:56:31 2015] it makes working with lists much easier [Sat Jan 17 19:57:06 2015] there may already be code to work with permutations in mathcomp, I don't know [Sat Jan 17 19:57:16 2015] I was proposing a function there that you'd write [Sat Jan 17 19:57:27 2015] oh found it [Sat Jan 17 19:58:08 2015] Lemma permP s t : s =1 t <-> s = t. [Sat Jan 17 19:58:08 2015] Proof. by split=> [| -> //]; rewrite unlock => eq_sv; exact/val_inj/ffunP. Qed. [Sat Jan 17 19:58:08 2015] weird [Sat Jan 17 19:58:18 2015] does this mean funcext holds here? [Sat Jan 17 19:58:32 2015] yeah, a restricted form of it that does not require the general axiom [Sat Jan 17 19:58:40 2015] =1 means that two functions are definitionally equal [Sat Jan 17 19:58:42 2015] hmm i think ssr's permutations are not exactly functions [Sat Jan 17 19:59:14 2015] in ssreflect, sets are functions are predicates [Sat Jan 17 19:59:37 2015] in what sense? [Sat Jan 17 19:59:38 2015] so P x and x \in P mean the same thing [Sat Jan 17 20:00:18 2015] so permP is saying that if P and Q match for all arguments, then P is Q [Sat Jan 17 20:00:22 2015] yeah, funext as you said [Sat Jan 17 20:00:34 2015] i'm trying to understand how ffun is defined [Sat Jan 17 20:00:36 2015] this is weird [Sat Jan 17 20:00:46 2015] it definitely takes getting used to [Sat Jan 17 20:00:48 2015] finfun.v is near completely unreadable without knoiwng their design decisions [Sat Jan 17 20:00:52 2015] it's not like the Coq standard library at all [Sat Jan 17 20:01:03 2015] yes, that is completely true [Sat Jan 17 20:01:12 2015] read Programs and Proofs by Ilya Sergey first [Sat Jan 17 20:01:30 2015] but once you get past the glass wall that is the ssreflect learning curve [Sat Jan 17 20:01:37 2015] then certain mathematical things get REALLY easy [Sat Jan 17 20:01:43 2015] that's why they invented it [Sat Jan 17 20:01:50 2015] so as not to go insane working on the four color theorem [Sat Jan 17 20:01:53 2015] i'm currently reading sergey [Sat Jan 17 20:01:58 2015] though not very far yet [Sat Jan 17 20:02:17 2015] i've read the ssreflect manual page by page four times now [Sat Jan 17 20:02:24 2015] and still a lot of their proofs are pure magic to me [Sat Jan 17 20:02:38 2015] I think sometimes that you have to work an Inria and be engaged in one of their projects to ever truly know the zen of it [Sat Jan 17 20:02:43 2015] Inductive finfun_type : predArgType := Finfun of #|aT|.-tuple rT. [Sat Jan 17 20:03:06 2015] can it be that their finite functions are wrappers for lists? [Sat Jan 17 20:03:17 2015] aT sounds like a list there [Sat Jan 17 20:03:22 2015] and #|| is probably its magnitude [Sat Jan 17 20:03:31 2015] an n.-tuple is list of size n [Sat Jan 17 20:03:41 2015] FinFun of ... is a data constructor [Sat Jan 17 20:04:28 2015] it looks scary because it's dense, but it's actually simpler in my opinion in the end [Sat Jan 17 20:04:39 2015] ok [Sat Jan 17 20:04:46 2015] i think [Sat Jan 17 20:04:58 2015] an "n.-tuple a" is a Vector n a [Sat Jan 17 20:05:06 2015] so the only way to construct an finfun_type object is from a list of elements of rT of the size of size aT [Sat Jan 17 20:05:20 2015] yep [Sat Jan 17 20:05:29 2015] if their maps are glorified lists, then i am not surprised by them satisfying funext at least :) [Sat Jan 17 20:05:41 2015] yeah, it's kind of elegant [Sat Jan 17 20:05:48 2015] and all the setoidery can be avoided too [Sat Jan 17 20:06:02 2015] I wish they did more category theory, because I bet their treatment of representable functors would be magical [Sat Jan 17 20:06:27 2015] as glorified representing objects? [Sat Jan 17 20:06:43 2015] yeah, because they too are just functions from some domain [Sat Jan 17 20:06:51 2015] (or isomorphic to such) [Sat Jan 17 20:07:10 2015] i'd love a general notion of isomorphism in ssreflect [Sat Jan 17 20:07:22 2015] so that once you'd proven it, you could flexibly shift types aruond [Sat Jan 17 20:08:05 2015] what is this lock/unlock stuff? [Sat Jan 17 20:08:11 2015] is this about definitions which never unfold? [Sat Jan 17 20:08:13 2015] prevents simplification by "simpl" or "/=" [Sat Jan 17 20:08:17 2015] ah [Sat Jan 17 20:08:29 2015] it's just a type wrapper, nothing more [Sat Jan 17 20:08:41 2015] i've used it a few times myself in proofs [Sat Jan 17 20:08:52 2015] you can lock down a sub-expression, rather than manually simplifying everything else around it [Sat Jan 17 20:09:50 2015] are there parts of the ssr library that are suitable to reading? [Sat Jan 17 20:10:00 2015] i see, nice [Sat Jan 17 20:10:57 2015] no, not at all [Sat Jan 17 20:11:04 2015] reading the code is not informative at all in the beginning [Sat Jan 17 20:11:14 2015] it just makes you feel that you don't understand even the things you thought you did [Sat Jan 17 22:44:35 2015] even the ssr manual is sometimes weird to read :) [Sun Jan 18 14:16:46 2015] Is there any shorthand for "intro n; ; generalize dependent n." ? [Sun Jan 18 15:34:10 2015] pyon: not that I know of [Sun Jan 18 15:52:51 2015] pyon where have i seen u b4 [Sun Jan 18 16:23:15 2015] Is there a way to use symmetry with <>? [Sun Jan 18 16:24:06 2015] I.e., I want 2 <> 0 to be 0 <> 2? [Sun Jan 18 16:31:30 2015] Nevermind, auto did it. [Sun Jan 18 16:32:03 2015] Hmmm. I kind of wish ProofGeneral let me see the proof state one step back at the same time. [Sun Jan 18 16:32:31 2015] Maybe it does. I dunno. I always get lost, or often end up asking myself "wait... What did that change?" [Sun Jan 18 16:49:28 2015] chirpsalot: i thgouht i was in a haskell channel and wsa extremely confused for a mo [Sun Jan 18 16:50:21 2015] Not mappend :P. [Sun Jan 18 16:54:30 2015] does coq have something analogous to (->) [Sun Jan 18 17:26:50 2015] benzrf: You mean, like, infix symbols? [Sun Jan 18 17:28:19 2015] pyon: i mean is there an expression in coq that corresponds to the expression (->) in haskell [Sun Jan 18 17:28:50 2015] You mean, at the type level? [Sun Jan 18 17:28:58 2015] Because (->) is not a value-level expression in Haskell. [Sun Jan 18 17:29:07 2015] pyon: yeh [Sun Jan 18 17:29:16 2015] benzrf: In Coq, there is no single universe of all types. [Sun Jan 18 17:29:27 2015] benzrf: So that would be ambiguous. [Sun Jan 18 17:29:41 2015] fug [Sun Jan 18 17:29:59 2015] what if i wanna write 'category Type (->) compose' tho [Sun Jan 18 17:30:06 2015] benzrf: Definition foo a b := (a -> b)%type. [Sun Jan 18 17:30:27 2015] benzrf: However, foo will be constrained to a single universe. [Sun Jan 18 17:30:40 2015] pyon: but then compose does not unify because foo a b fails to unify with a -> b [Sun Jan 18 17:30:45 2015] or like [Sun Jan 18 17:30:47 2015] something! [Sun Jan 18 17:31:34 2015] Too bad I do not remember the Coq notation for records... [Sun Jan 18 17:31:41 2015] In a past lifetime, I showed that Hask is a category in Coq. [Sun Jan 18 17:31:50 2015] cool beens [Sun Jan 18 17:47:35 2015] How do I check the associativity and precedence of a stdlib symbol? [Sun Jan 18 18:04:35 2015] benzrf: Compose works just fine: https://gist.github.com/eduardoleon/0bd473804005bfc76f19 [Sun Jan 18 18:04:50 2015] oh my [Sun Jan 18 18:05:25 2015] what to heck is "Module Type" [Sun Jan 18 18:05:41 2015] benzrf: Think of a module as a record. [Sun Jan 18 18:06:00 2015] In ML, a module is just like a record, except it may contain types as members, and it is not a first-class value. [Sun Jan 18 18:06:14 2015] And a module type... is the type signature of a module. [Sun Jan 18 18:06:31 2015] (Well, all of this is super imprecise, but it was just a quick explanation.) [Sun Jan 18 18:07:17 2015] Sadly, I could not use (.) to denote function composition. [Sun Jan 18 18:44:25 2015] What was the tactic for trying a bunch of possibities? I remember it was something like " [ tac1 | tac2 | tac3 ... ]". [Sun Jan 18 19:10:01 2015] How do I say, in the middle of a proof, "the term 't' has exactly the type required by the goal"? [Sun Jan 18 19:13:39 2015] exact t? [Sun Jan 18 19:14:20 2015] Ah! [Sun Jan 18 19:14:22 2015] Thanks! [Sun Jan 18 19:20:04 2015] I have a case analysis with two cases: in the first case, I used "foo" and in the second case I used "bar". I should be able to replace this with "first [foo|bar]", right? [Sun Jan 18 19:20:35 2015] Oh, never mind. I was making a silly mistake [Mon Jan 19 06:44:33 2015] I'm proving rsc_trans from software foundations (the "Rel" chapter). here's my attempt: Theorem rsc_trans : forall (X:Type) (R: relation X) (x y z : X), refl_step_closure R x y -> refl_step_closure R y z -> refl_step_closure R x z. Proof. intros X R x y z H. apply rsc_step. Abort. the hypothesis is refl_step_closure R x y. the goal is R x y. what should be my next step? I have a Theorem rsc_R : forall (X:Type) (R:relation X) (x y : [Mon Jan 19 06:44:33 2015] X), R x y -> refl_step_closure R x y. how can I apply it in H? [Mon Jan 19 06:44:33 2015] [Mon Jan 19 14:05:17 2015] I am stick with one of the exercises from Software Foundations: https://gist.github.com/eduardoleon/2a119e8d89bf956cd212 . I want to prove (line 66) that converting a binary number to unary and then back to binary has the effect of removing leading zeroes. How should I approach this task? [Mon Jan 19 14:05:20 2015] stuck* [Mon Jan 19 14:07:14 2015] is that the 5-star one? [Mon Jan 19 14:07:21 2015] my proof is a fucking mess [Mon Jan 19 14:09:16 2015] Yes, it is the first 5-star one. [Mon Jan 19 14:09:24 2015] -O [Mon Jan 19 14:09:26 2015] :-O * [Mon Jan 19 14:10:39 2015] omg [Mon Jan 19 14:10:49 2015] 11 lemmas [Mon Jan 19 14:10:57 2015] Whoa. [Mon Jan 19 14:11:04 2015] though i suspect half of them are redundant and i was too lazy to delete them [Mon Jan 19 14:11:13 2015] Lemma normalize_E : forall n : bin, [Mon Jan 19 14:11:14 2015] normalize (E n) = E (normalize n). [Mon Jan 19 14:11:20 2015] Lemma normalize_D: forall (n : bin) (m : nat), [Mon Jan 19 14:11:20 2015] bin_to_nat n = S m -> normalize (D n) = D (normalize n). [Mon Jan 19 14:11:21 2015] these might be most useful [Mon Jan 19 14:11:54 2015] D is 2x+1, right? [Mon Jan 19 14:12:04 2015] hmm [Mon Jan 19 14:12:06 2015] my D is 2x [Mon Jan 19 14:12:11 2015] and E is 2x+1 [Mon Jan 19 14:12:14 2015] Oh. [Mon Jan 19 14:12:23 2015] in my first attempt D was 2x+1 and E was 2x+2 but then there would be nothing left to normalize [Mon Jan 19 14:18:16 2015] repeating my question: I'm proving rsc_trans from software foundations (the "Rel" chapter). here's my attempt: Theorem rsc_trans : forall (X:Type) (R: relation X) (x y z : X), refl_step_closure R x y -> refl_step_closure R y z -> refl_step_closure R x z. Proof. intros X R x y z H. apply rsc_step. Abort. the hypothesis is refl_step_closure R x y. the goal is R x y. what should be my next step? I have a Theorem rsc_R : forall [Mon Jan 19 14:18:16 2015] (X:Type) (R:relation X) (x y : X), R x y -> refl_step_closure R x y. how can I apply it in H? [Mon Jan 19 14:18:39 2015] it's a bit hard to read that in IRC [Mon Jan 19 14:18:45 2015] yes [Mon Jan 19 14:18:49 2015] please pastebin [Mon Jan 19 14:18:56 2015] or just multipost [Mon Jan 19 14:19:29 2015] pastebin, always [Mon Jan 19 14:19:37 2015] allows for annotating and edits [Mon Jan 19 14:19:44 2015] okay [Mon Jan 19 14:20:02 2015] also, i used induction in that exercise [Mon Jan 19 14:22:53 2015] johnw: http://dpaste.com/2X3T4QD [Mon Jan 19 14:23:19 2015] wow dpaste has coq highlighting? [Mon Jan 19 14:23:19 2015] what is a refl_step_closure? [Mon Jan 19 14:23:21 2015] ah ocaml [Mon Jan 19 14:23:40 2015] I guess I haven't done this cahpter [Mon Jan 19 14:23:42 2015] so yeah i'd say this require sinduction [Mon Jan 19 14:23:43 2015] it's rel.v [Mon Jan 19 14:24:27 2015] first two lines of my solution -- don't click unless you really want it http://dpaste.com/1TX6HF8 [Mon Jan 19 14:25:19 2015] sinduction?! [Mon Jan 19 14:25:22 2015] how sinful [Mon Jan 19 14:25:47 2015] it's when you recursively try every sin until you hit rock bottom [Mon Jan 19 14:26:02 2015] it's how you generate evil http://comments.gmane.org/gmane.science.mathematics.categories/5459 [Mon Jan 19 14:29:54 2015] arvisrend: I don't want to click. I wonder whether I can apply rsc_R in a hopthesis or not. [Mon Jan 19 14:30:46 2015] "in a hypothesis"? [Mon Jan 19 14:31:03 2015] but i don't think it is reasonable to apply it [Mon Jan 19 14:31:23 2015] it basically goes in the wrong direction [Mon Jan 19 14:31:38 2015] you don't know how many R's there are between y and z, so to speak [Mon Jan 19 14:32:54 2015] arvisrend: okay... so, do I need to do anything special in order be able to lift R into relf_step_closure or unlift relf_step_closure into R? [Mon Jan 19 14:33:10 2015] as i said, this is basically an induction exercise [Mon Jan 19 14:33:32 2015] do I need to perform it on a hypothesis? [Mon Jan 19 14:33:32 2015] the axioms are enough for it [Mon Jan 19 14:33:35 2015] yes [Mon Jan 19 14:34:06 2015] I tried that but didn't push too hard. will try again, thanks. [Mon Jan 19 14:44:17 2015] Is there anything like "simpl", but which lets me control the extent to which the expression is simplified? [Mon Jan 19 14:44:39 2015] (Without having to use stuff like "assert" or "replace", which generate new subgoals.) [Mon Jan 19 14:47:25 2015] Basically, I want something like "simpl the left-hand side only". [Mon Jan 19 14:48:50 2015] pyon: https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_tactic136 [Mon Jan 19 14:49:12 2015] Thanks, checking [Mon Jan 19 14:49:59 2015] Looks like it can do what you want. [Mon Jan 19 14:50:02 2015] * hasn't tried. [Mon Jan 19 14:50:15 2015] I was wondering the same thing, but I didn't look it up until now. [Mon Jan 19 14:50:41 2015] Oh, and another thing. I have something like "foo (match bar with | A m n => baz | B p q => qux)". How do I convert it to "match bar with | A m n => foo baz | B p q => foo qux" ? [Mon Jan 19 14:53:29 2015] pyon: I would normally destruct bar and then simpl, I think. [Mon Jan 19 14:54:04 2015] But there is probably a better way! [Mon Jan 19 14:55:13 2015] Ah! [Mon Jan 19 15:03:49 2015] Are you scared, or did you figure it out? :P [Mon Jan 19 15:05:56 2015] I found a way to prove what I needed... but... I do not like my proof. [Mon Jan 19 15:09:26 2015] https://gist.github.com/eduardoleon/2a119e8d89bf956cd212 -- lines 67-76, there has to be a better way [Mon Jan 19 15:11:21 2015] thank goodness for proof irrelevance, he? :) [Mon Jan 19 15:11:23 2015] eh [Mon Jan 19 15:11:28 2015] lol [Mon Jan 19 15:11:55 2015] And this was just warmup for the actual exercise, proving "forall n, normalize n = from_nat (to_nat n)". [Mon Jan 19 15:12:30 2015] i feel dirty like that whenever i use try constructs :( [Mon Jan 19 15:13:01 2015] something is frighteningly barbaric about this kind of exception catching [Mon Jan 19 15:14:57 2015] Well, how else do I express the fact that, in some branches I need a tactic, and in others I don't? [Mon Jan 19 15:15:17 2015] i don't know -- it's a flaw of coq to me [Mon Jan 19 15:15:58 2015] I am decidedly *NOT* happy with the fact that I cannot understand a proof without stepping through it. [Mon Jan 19 15:21:58 2015] pyon: you could always add comments to your proof that would make it more equivalent to a human readable proof [Mon Jan 19 15:23:41 2015] Yesterday i started self learning some predicate logic and also trying to proof the problems with coq. [Mon Jan 19 15:23:53 2015] its pretty fun [Mon Jan 19 15:24:12 2015] Coq is really good with predicate logic [Mon Jan 19 15:24:22 2015] until you discover "intuition" and all your proofs disappear ;) [Mon Jan 19 15:24:42 2015] :) [Mon Jan 19 15:24:54 2015] maybe even "firstorder" is all you need in that case [Mon Jan 19 15:25:08 2015] jgross__: ping [Mon Jan 19 15:25:47 2015] Is it also possible to let coq use exists and forall symbols? [Mon Jan 19 15:25:56 2015] yep [Mon Jan 19 15:26:08 2015] Require Export Coq.Unicode.Utf8. [Mon Jan 19 15:26:11 2015] and then just use away [Mon Jan 19 15:26:13 2015] ah oke [Mon Jan 19 15:26:22 2015] fun x => y turns into λ x, y [Mon Jan 19 15:26:38 2015] s/Export/Import [Mon Jan 19 15:28:25 2015] Export worked too... [Mon Jan 19 15:29:02 2015] that's fine, if you don't mind that the imports will propagate to whoever imports you [Mon Jan 19 15:30:02 2015] but i need to include Coq.Unicode in every "program"? [Mon Jan 19 15:31:10 2015] you either need to include it in every module they will use the Unicode symbols, or you can do an Export inclusion in some common module that they will all then Import [Mon Jan 19 15:31:54 2015] oke thank you [Mon Jan 19 15:32:38 2015] I had no idea it was part of the module, i thought it was just the IDE that could do that [Mon Jan 19 15:35:35 2015] your actually entering Unicode characters into the source file, so the coqc compiler must be able to interpret what they mean. I think that the module I mentioned simply contains Notations from those Unicode code points to their related syntactic counterparts. [Mon Jan 19 15:37:28 2015] johnw, im just using exists and forall but the output of the CoqIDE now uses the symbols [Mon Jan 19 15:37:42 2015] ah, I see [Mon Jan 19 15:37:54 2015] in one project i get to type in ∀ and ∃ [Mon Jan 19 15:38:10 2015] but I don't use it for projects where I expect to work with other people [Mon Jan 19 15:39:55 2015] but how do you type ∀ and ∃ [Mon Jan 19 15:43:33 2015] johnw with compose key? [Mon Jan 19 15:44:39 2015] I type \all in Emacs with Agda input mode [Mon Jan 19 15:44:54 2015] ah oke :) [Mon Jan 19 15:45:19 2015] i guess i can use compose key, if i know how to change that [Mon Jan 19 15:48:11 2015] well i found out i can use the compose key to do this... ☭ [Mon Jan 19 15:50:26 2015] heh [Mon Jan 19 15:50:43 2015] but not ∀, strange [Mon Jan 19 15:57:36 2015] well thank you for helping johnw, see you later [Mon Jan 19 15:57:50 2015] cya [Mon Jan 19 17:21:21 2015] I have a goal "foo \/ bar", how do I discard one of "foo" or "bar"? [Mon Jan 19 17:22:59 2015] Oh, never mind, "left" and "right". [Mon Jan 19 17:28:01 2015] I have the assumption "moo <> moo", how do I say "from this anything follows"? [Mon Jan 19 17:28:56 2015] 'discriminate' should do the trick. [Mon Jan 19 17:29:28 2015] It does not. :-| [Mon Jan 19 17:30:13 2015] inversion? [Mon Jan 19 17:30:15 2015] Hmm, weird. What about 'inversion'? [Mon Jan 19 17:30:25 2015] well, depends on what type moo is [Mon Jan 19 17:30:33 2015] "moo" is of an inductive type. [Mon Jan 19 17:30:43 2015] But the hypothesis "H : moo <> moo" itself is not. [Mon Jan 19 17:30:46 2015] in the worst case, you use exfalso, and then apply the hypothesis [Mon Jan 19 17:31:01 2015] Oh, right. [Mon Jan 19 17:31:05 2015] Thanks! [Mon Jan 19 17:31:42 2015] yw [Mon Jan 19 17:31:53 2015] though this might not be the most idiomatic way or something, but i never tend to remember those [Mon Jan 19 17:34:10 2015] Basically, in the same problem as before (the 5-star one from SF), I am trying to prove "forall n, normalize n = Z \/ normalize (XO n) = XO (normalize n)". Or, equivalently, "forall n, normalize n <> Z -> normalize (XO n) = XO (normalize n)". After some hacking on my whiteboard, I have a suspicion that this lemma will help me solve the exercise in a simple way. [Mon Jan 19 17:34:25 2015] Errr... I should rather update my gist. [Mon Jan 19 17:35:07 2015] https://gist.github.com/eduardoleon/2a119e8d89bf956cd212 -- line 78 [Mon Jan 19 17:44:15 2015] what is XO? [Mon Jan 19 17:44:19 2015] ah [Mon Jan 19 17:44:32 2015] XO is 2x, XI is 2x+1 [Mon Jan 19 17:44:43 2015] X is the prefix of the number O and I are the last digit. [Mon Jan 19 17:45:18 2015] Perhaps I should use a different lemma: "forall m n, normalize (XO m) = XO n -> normalize m = n". [Mon Jan 19 17:45:59 2015] i like the version with "or" more than the one with the negative hypothesis [Mon Jan 19 17:46:03 2015] but i guess they're equivalent [Mon Jan 19 17:46:25 2015] yeah becausewe can match [Mon Jan 19 17:46:45 2015] Fixpoint normalize n := [Mon Jan 19 17:46:45 2015] match n with [Mon Jan 19 17:46:46 2015] | Z => Z [Mon Jan 19 17:46:46 2015] | XO n => [Mon Jan 19 17:46:46 2015] match normalize n with [Mon Jan 19 17:46:46 2015] | Z => Z [Mon Jan 19 17:46:46 2015] | n => XO n [Mon Jan 19 17:46:47 2015] end [Mon Jan 19 17:46:47 2015] | XI n => XI (normalize n) [Mon Jan 19 17:46:48 2015] end. [Mon Jan 19 17:46:52 2015] please give the auxiliary variable a different name [Mon Jan 19 17:47:38 2015] :-O [Mon Jan 19 17:47:49 2015] actually you have 2 of them [Mon Jan 19 17:47:54 2015] I like neither the \/ nor the negative. [Mon Jan 19 17:48:18 2015] Oh, you mean the n's in normalize? [Mon Jan 19 17:48:27 2015] Yeah, I guess giving them the same name was a bad thing. [Mon Jan 19 17:48:46 2015] yeah there are three of them [Mon Jan 19 18:47:29 2015] pyon: A better way might be to redesign bin so it did not need normalisation. For example, by ensuring that non-zero binary numbers are forced by the Inductive definition to always have a leading one. [Mon Jan 19 18:52:34 2015] mbrcknl: I understand that... but the exercise consists precisely in dealing with this specific representation. [Mon Jan 19 18:53:39 2015] mbrcknl: I could work in terms of a tail, which is essentially a list of bits, and then a binary number is either 1 followed by a tail, or just 0. [Mon Jan 19 18:54:46 2015] pyon: Actually, I thought "Again, feel free to change your earlier definitions if this helps here." was a hint that there was a better representation. [Mon Jan 19 18:55:12 2015] Oh. [Mon Jan 19 19:16:21 2015] hello, is it possible to use coq without admin rights on windows? [Mon Jan 19 19:17:26 2015] or is there maybe some online interpreter to do simple stuff on? [Mon Jan 19 19:19:35 2015] oh i think i found one, proofweb [Mon Jan 19 19:22:44 2015] Wait, Coq needs admin rights on Windows? :-O [Mon Jan 19 19:31:12 2015] i dont know, the installer wants admin rights. but i just want to run in, when im on a windows system sometimes [Mon Jan 19 19:31:28 2015] it* [Mon Jan 19 19:32:20 2015] guess i can try extracting the installer [Mon Jan 19 21:47:17 2015] Nik05: virtual machine, if all else fails? [Tue Jan 20 10:56:54 2015] How do I import all notations defined in another module? [Tue Jan 20 10:58:15 2015] they will automatically be imported, unless they were defined in a sub-module [Tue Jan 20 11:00:07 2015] Oh, by module, I do not mean a "Foo.v", I mean a "Module Foo. (* ... *) End Foo.". [Tue Jan 20 11:03:14 2015] then: Module Import Foo [Tue Jan 20 11:06:39 2015] Never mind, I am splitting my single Everything.v into files for each submodule. [Tue Jan 20 11:06:42 2015] Oh. [Tue Jan 20 11:22:49 2015] How do I prove something about a recursive, higher-order function? [Tue Jan 20 11:23:39 2015] I have a "count {A} p (xs : list A) : nat" function defined in terms of filter and length. [Tue Jan 20 11:23:46 2015] Errr, I have defined filter myself. [Tue Jan 20 11:23:54 2015] length is the one from the stdlib. [Tue Jan 20 11:24:01 2015] usually it's just by induction [Tue Jan 20 11:24:22 2015] I can prove stuff by induction about non-higher-order functions... but for higher-order functions, it is just hard.. [Tue Jan 20 11:24:36 2015] well, that's probably true :) [Tue Jan 20 11:56:27 2015] Oh, well, it turned out to be easier than I foresaw. [Tue Jan 20 12:25:49 2015] What is going in here? -- http://i.imgur.com/kZQ3UPI.png -- A term is not equal to itself? :-| [Tue Jan 20 12:33:47 2015] pyon: Perhaps those two ++ are not what they seem? Try 'Unset Printing Notations.' [Tue Jan 20 12:34:44 2015] Oh. [Tue Jan 20 12:58:41 2015] Say I destruct a bool. [Tue Jan 20 12:59:02 2015] Is there any way to put into the context a hypothesis saying which is the actual value of the bool? [Tue Jan 20 12:59:26 2015] e.g., if I "destruct (foo bar)", I want hypotheses "H : foo bar = true" and "H : foo bar = false". [Tue Jan 20 12:59:59 2015] (Actually, this is not just for bool, but any inductive type... also, not just for "destruct", also for "induction".) [Tue Jan 20 13:08:20 2015] does [destruct (foo bar) eqn:H] work? [Tue Jan 20 13:08:34 2015] i remember that this [eqn:] construct works for two of destruct, induction, inversion [Tue Jan 20 13:08:38 2015] i don't remember which ones :) [Tue Jan 20 13:08:44 2015] Ah, checking! [Tue Jan 20 13:09:09 2015] arvisrend: Yes, worked like a charm! [Tue Jan 20 13:09:23 2015] i must say i never fully figured out the difference between destruct and ivnersion [Tue Jan 20 13:09:54 2015] arvisrend: inversion adds induction principles for recursively defined types. [Tue Jan 20 13:10:07 2015] really? i thought you need induction for that? [Tue Jan 20 13:10:13 2015] oh, my bad [Tue Jan 20 13:10:14 2015] I misread [Tue Jan 20 13:10:21 2015] I was thinking of destruct vs induction [Tue Jan 20 13:10:22 2015] lol [Tue Jan 20 13:10:55 2015] i guess inversion is for equalities [Tue Jan 20 13:11:00 2015] Ah, yes! [Tue Jan 20 13:11:09 2015] Hypotheses that are equalities. [Tue Jan 20 13:30:33 2015] Is there anything like Haskell's "import qualified Whatever as W" ? [Tue Jan 20 13:31:30 2015] I am developing a style in which I write lots of modules with one or two regular definitions, and lots of proofs about them. [Tue Jan 20 13:31:46 2015] maybe you can import stuff into a submdoule? [Tue Jan 20 13:31:54 2015] Oh. [Tue Jan 20 13:32:09 2015] That works. [Tue Jan 20 13:32:17 2015] not sure if it's any good though [Tue Jan 20 13:32:33 2015] Although I still think "Module Foo. Require Import Foo. End Foo." is rather unpleasant. [Tue Jan 20 13:33:44 2015] Wait, no, it does not work exactly that way. [Tue Jan 20 13:35:17 2015] No functional extensionality is going to be the end of me. [Tue Jan 20 13:42:06 2015] where can i find info on operator precedence? [Tue Jan 20 13:42:32 2015] like something nice as http://en.cppreference.com/w/cpp/language/operator_precedence :P [Tue Jan 20 13:43:44 2015] Haaaaaaa! [Tue Jan 20 13:43:49 2015] I would like to know as well. [Tue Jan 20 13:44:03 2015] (But perhaps a better example is ghci's ":i" command.) [Tue Jan 20 13:44:11 2015] thats nice too :) [Tue Jan 20 13:53:01 2015] pyon Locate does somethign... but doesnt show precedence ;) [Tue Jan 20 13:55:50 2015] pyon https://coq.inria.fr/distrib/current/refman/Reference-Manual005.html [Tue Jan 20 13:56:33 2015] but that table doesnt even have → :S [Tue Jan 20 13:58:53 2015] :-O [Tue Jan 20 15:07:27 2015] so i just self learning some predicate logic, and tried if i could also solve the problems with coq. But what other stuff can you proof with coq? [Tue Jan 20 15:08:09 2015] In theory, you can prove pretty much anything that you could prove with ordinary mathematics. [Tue Jan 20 15:08:28 2015] I find Coq really shines at proving properties about computer programs, but then again, that’s my research focus :) [Tue Jan 20 15:09:32 2015] Is Coq equally good at proving properties about entire languages? (not individual programs) [Tue Jan 20 15:12:08 2015] I’ve never tried it, but it seems like you ought to be able to build a formal model of your language and punch that through Coq to derive the properties you want. [Tue Jan 20 15:14:02 2015] thank you alkabetz [Tue Jan 20 15:14:04 2015] Given two lists, how to I perform a "special induction" with three cases: (1) first list is nil, (2) second list is nil, (3) both lists have heads and tails? [Tue Jan 20 16:36:59 2015] pyon: that should be equivalent to [induction l1; destruct l2] modulo goal duplication. [Tue Jan 20 18:48:27 2015] Is there any tactic that lets me simpl a specific subexpression *step by step* ? [Tue Jan 20 18:48:50 2015] "simpl" often goes "all the way", past the point I actually want to get at. [Tue Jan 20 18:49:21 2015] And thus I find myself having to make lots of tiny lemmas whose proof is "reflexivity", just so that I can rewrite them in my main proof. [Tue Jan 20 18:52:24 2015] sometimes unfold [Tue Jan 20 18:52:36 2015] otherwise i use replace...with... [Tue Jan 20 18:52:41 2015] though this is similar to your tiny lemmas [Tue Jan 20 18:55:00 2015] "replace ... with ..." is annoying because it decides when I have to prove that the replacement is valid (after the main goal)... [Tue Jan 20 18:55:22 2015] And now the justification for the replacement is far away from the point where it was actually made. [Tue Jan 20 19:35:27 2015] pyon: you can use "replace ... with ... by (tactic expression)" [Tue Jan 20 19:36:52 2015] to keep the justification close [Tue Jan 20 19:43:19 2015] Ah! [Tue Jan 20 19:43:25 2015] Makes sense! [Tue Jan 20 19:46:07 2015] thanks, jrw!this is very nice [Tue Jan 20 20:21:53 2015] so, I solved that exercise from "software foundations" (http://dpaste.com/3HQBJ84) without checking arvisrend's solution. but I consider it bruteforcing because I don't know what it means to perform induction on H in this case. I have no idea why these particular subgoals and the induction hypothesis are generated. I know, however, what it means to perform induction on naturals and lists. could anyone walk me through this exercise? [Tue Jan 20 20:26:53 2015] nkar: one way to think about it is in terms of proof trees. terms of type [refl_step_closure R x y] are trees of constructors that build up evidence for that proposition. are you familiar with this idea? [Tue Jan 20 20:27:11 2015] induction on H corresponds to structural induction on this tree of evidence. [Tue Jan 20 20:27:20 2015] not really [Tue Jan 20 20:27:24 2015] not at all, actually [Tue Jan 20 20:27:59 2015] I could read something if you know a beginner-friendly source [Tue Jan 20 20:28:08 2015] hm, I thought SF explained this. [Tue Jan 20 20:28:09 2015] one second. [Tue Jan 20 20:28:37 2015] nkar: what chapter is this from? [Tue Jan 20 20:28:43 2015] Rel [Tue Jan 20 20:29:04 2015] second to last exercise [Tue Jan 20 20:29:35 2015] nkar: have you done the Prop chapter? [Tue Jan 20 20:30:25 2015] let me check [Tue Jan 20 20:30:44 2015] in either case, you might want to read/re-read the part about inducting on evidence [Tue Jan 20 20:30:50 2015] and then ask questions in here :) [Tue Jan 20 20:30:53 2015] no, I haven't [Tue Jan 20 20:31:07 2015] read where? [Tue Jan 20 20:32:06 2015] I think you should do the Prop chapter before Rel [Tue Jan 20 20:34:06 2015] well, I've nearly finished the Prop chapte, but I'll look into it, thanks [Tue Jan 20 20:34:12 2015] s/Prop/Rel [Tue Jan 20 20:52:38 2015] jrw: ah, I guess [next_nat_closure_is_le] in the Rel chapter is intended to be a brief introduction to this. [Tue Jan 20 21:07:37 2015] I have proven a "Lemma foo n : bar n <-> baz n", and I need to use the implication in one direction, how do I do it? [Tue Jan 20 21:23:17 2015] pyon : the apply tactics is usually smart enough to do it right for you. You can also destruct your lemma to get both directions. [Wed Jan 21 07:09:16 2015] is there something similar to replace (fold_left ?a ?b ?c ?d) with (H3 :: fold_left ?a ?b H2 ?d). possible? that is, replacement with named wildcards? [Wed Jan 21 08:51:25 2015] hmm [Wed Jan 21 08:51:31 2015] ilya sergey's notes look very nicely written [Wed Jan 21 08:51:36 2015] but i'm not sure his exercises are helpful... [Wed Jan 21 08:57:55 2015] thanks arvisrend [Wed Jan 21 08:58:04 2015] he has a bunch of cool stuff [Wed Jan 21 09:00:28 2015] thanks for what though? [Wed Jan 21 09:18:05 2015] Is there any shorthand for "induction foo; simpl; ; ." ? It is a very common pattern. [Wed Jan 21 09:25:07 2015] Hi, what is the opposite of [apply] ? [Wed Jan 21 09:25:21 2015] I have a lemma that proves [P -> Q] [Wed Jan 21 09:25:44 2015] into [Wed Jan 21 09:25:46 2015] intro* [Wed Jan 21 09:25:54 2015] And in a proof, I have the goal [Q], and an hypothesis [P] [Wed Jan 21 09:26:15 2015] Just [apply] is what you want to use here. [Wed Jan 21 09:26:21 2015] Ho ok [Wed Jan 21 09:26:39 2015] I thought it would applied for the goal [Q] [Wed Jan 21 09:26:47 2015] P* [Wed Jan 21 09:27:00 2015] If you use [apply lemma], then your goal will be transformed into P, and then you can use your hypothesis [Wed Jan 21 09:27:13 2015] you can also do [apply lemma in hypothesis] to transform your hypothesis into Q [Wed Jan 21 09:27:28 2015] ssreflects really speaks of "behead" instead of "tal"? [Wed Jan 21 09:27:32 2015] *"tail" [Wed Jan 21 09:31:18 2015] Is it possible to use [apply] on every parts of a goal like [part1 \/ part2 \/ part3], or I must destruct it ? [Wed Jan 21 09:38:24 2015] when you try to prove a disjonction, you just need to prove one branch (using left or right IIRC) [Wed Jan 21 09:38:58 2015] so there is no need to apply a lemma to all of them, just the one you are interested in [Wed Jan 21 09:41:34 2015] but let me steal his question. what if this is a hypothesis? [Wed Jan 21 09:47:15 2015] arvisrend: if you know H : L + R, and you need on L or an R, you have to prove your goal in both cases, by inversion on H. [Wed Jan 21 09:55:23 2015] I want to prove "forall {A} (xs ys : list A), reverse xs = reverse ys -> xs = ys". My idea is as follows: perform induction on both xs and ys. Discard the cases where exactly one of the lists is nil, by using the fact that "reverse" preserves the length of the list (I have this as a separate lemma). Prove the remaining two cases (both nil or both cons) using the inductive hypothesis. How do I do this? [Wed Jan 21 09:57:30 2015] At some point I have the hypothesis: "H : reverse nil = reverse (a :: ys)". I want to transform this into "H' : length (reverse nil) = length (reverse (a :: ys))", and then "H'' : Z = S (length ys)", so that I can finally "discriminate". [Wed Jan 21 10:00:05 2015] pyon... sorry to beg your question, but i'd use the involutiveness of reverse [Wed Jan 21 10:00:11 2015] you'll have a use for it sooner or later anyway [Wed Jan 21 10:00:47 2015] ianjneu: what i want is to apply some transformation to both L and R at the same time without destructing them and +ingthem again [Wed Jan 21 10:01:01 2015] Oh, I already have the involutiveness of reverse. [Wed Jan 21 10:01:04 2015] I guess your lemma states something like [length (reverse l) = length l]. What you can do is something like [apply (f_equal length) in H] to get your H' [Wed Jan 21 10:01:13 2015] arvisrend: But, still, how do I use it? [Wed Jan 21 10:01:22 2015] rewrite the goal using it [Wed Jan 21 10:01:22 2015] twice [Wed Jan 21 10:01:27 2015] :-O [Wed Jan 21 10:02:52 2015] Oh, it didn't like "apply (f_equal length) in H" because I made length polymorphic. But "apply (f_equal (fun xs => length xs))" did the trick, nice! :-) [Wed Jan 21 10:02:59 2015] :D [Wed Jan 21 10:03:21 2015] i also need trial and error every time to find out whether coq wants me to provide type arguments or not [Wed Jan 21 10:03:48 2015] Does (f_equal (length _)) work, out of curiosity, pyon? [Wed Jan 21 10:03:49 2015] If I am going to apply a lot of tactics on the same hypothesis, is there any shorthand for this? [Wed Jan 21 10:04:00 2015] Cypi: Nope. [Wed Jan 21 10:04:03 2015] ok :) [Wed Jan 21 10:04:18 2015] i thought this is what hint databases are for [Wed Jan 21 10:04:21 2015] but i've never used one so far [Wed Jan 21 10:04:22 2015] I am not using "Set Implicit Arguments", I like manually controlling which arguments are explicit. [Wed Jan 21 10:04:28 2015] arvisrend: If I only knew how to use them! [Wed Jan 21 10:04:37 2015] which arguments are implicit* [Wed Jan 21 10:04:47 2015] Even if an argument is explicit, you can always put a placeholder _ and let Coq try to infer it. [Wed Jan 21 10:04:57 2015] I was just wondering if it would do it here [Wed Jan 21 10:06:24 2015] Ah. [Wed Jan 21 10:21:01 2015] Is there anything like "induction on lists of equal length" ? [Wed Jan 21 10:21:18 2015] pairs of lists of equal length* [Wed Jan 21 10:21:57 2015] Either they are both nil or they are both cons where the tails are of equal length. [Wed Jan 21 10:22:04 2015] No, wait... perhaps I should prove this as a lemma. [Wed Jan 21 10:22:19 2015] i'd induce over the length and use destruct [Wed Jan 21 10:38:44 2015] Apparently there is a subtle difference between "induction xs, ys" and "induction xs; induction ys"... :-| [Wed Jan 21 10:38:55 2015] Regarding how inductive hypotheses are introduced. :-| [Wed Jan 21 10:39:00 2015] Am I right? [Wed Jan 21 10:39:57 2015] i didn't even know there is induction xs, ys [Wed Jan 21 10:39:58 2015] what does it do? [Wed Jan 21 10:40:39 2015] Induction over multiple things at once. [Wed Jan 21 10:41:06 2015] But, apparently, inductive hypotheses are only generated for the first thing being inducted (induced?) over. [Wed Jan 21 10:42:58 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_tactic71 [Wed Jan 21 10:43:01 2015] might be variant 8 [Wed Jan 21 10:48:14 2015] I was just being stupid. There is a difference between "Theorem foo a : bar" and "Theorem foo : forall a, bar". [Wed Jan 21 10:50:15 2015] i have a condition "false" and a goal "False" [Wed Jan 21 10:50:22 2015] what is the "idiomatic" way to get a contradiction? [Wed Jan 21 10:50:38 2015] (i can inversion the condition, but i'd assume SSR has something better readable for this.) [Wed Jan 21 10:53:11 2015] Ok, this is super dumb, but I have "H : S x = S y", and I need "x = y". What do I do? [Wed Jan 21 10:53:33 2015] pyon: [inversion H] [Wed Jan 21 10:53:59 2015] Slightly modified version of the question. [Wed Jan 21 10:54:05 2015] I obtained this hypothesis by doing "intro". [Wed Jan 21 10:54:28 2015] Instead of "intro H; inversion H", is there any one-step tactic that simplifies this directly in the goal? [Wed Jan 21 10:54:56 2015] Basically, my goal, before "intro H", is "S x = S y -> moo_im_a_cow". [Wed Jan 21 10:55:05 2015] And I want "x = y -> moo_im_a_cow". [Wed Jan 21 10:56:15 2015] If the goal were merely "S x = S y", I could do "f_equal". [Wed Jan 21 10:59:54 2015] Any ideas on how to make this proof better? https://gist.github.com/eduardoleon/8309321c189e4b67fa39 [Wed Jan 21 11:03:29 2015] pyon: Hint Constructors eq_len. before the theorem, then induction xs; destruct ys; firstorder (inversion H; auto). [Wed Jan 21 11:04:22 2015] i wouldn't use any automation in such a proof tbh [Wed Jan 21 11:06:16 2015] :-O [Wed Jan 21 11:07:18 2015] This is almost too magical. [Wed Jan 21 11:07:51 2015] Suddenly all my old proofs seem long and verbose and ugly. [Wed Jan 21 11:08:46 2015] Is there any way to explicitly specify an implicit parameter? [Wed Jan 21 11:08:57 2015] pyon: this depends on firstorder introducing "H", so you should probably use match goal to find the = hypothesis. [Wed Jan 21 11:08:59 2015] prefix the function with an @ [Wed Jan 21 11:09:06 2015] like: @cons A h t [Wed Jan 21 11:09:19 2015] Oh. [Wed Jan 21 11:10:15 2015] Is there any way to say "Hint Rewrite "? [Wed Jan 21 11:13:42 2015] Proof. [Wed Jan 21 11:13:42 2015] induction xs as [| hx tx]; destruct ys as [| hy ty]. [Wed Jan 21 11:13:42 2015] intros _; exact nils. [Wed Jan 21 11:13:42 2015] intros H; inversion H. [Wed Jan 21 11:13:42 2015] intros H; inversion H. [Wed Jan 21 11:13:42 2015] intros H; inversion H as [H1]. exact (conses (IHtx ty H1)). [Wed Jan 21 11:13:42 2015] Qed. [Wed Jan 21 11:13:46 2015] this is how i'd do that [Wed Jan 21 11:14:08 2015] of course it's longer but the structure is clearer (at least if you add whatever case declarations you use) [Wed Jan 21 11:14:41 2015] I do not find any case analyses clear in the tactic language. [Wed Jan 21 11:15:25 2015] In my mind, "case analyses" has to look like pattern matching. (I know that, under the hood, pattern matching is still what is happening... but it is no good if I cannot easily identify the cases visually.) [Wed Jan 21 11:15:51 2015] for identifying cases visually, there is the "Case" command from the sf book [Wed Jan 21 11:16:04 2015] pyon: there is no metadata on identifiers that are "induction hypotheses" but you can do repeat (match goal with [H : _ |- _] => try rewrite H end). [Wed Jan 21 11:16:16 2015] arvisrend: Yep, but that just adds manual labels. [Wed Jan 21 11:16:20 2015] b [Wed Jan 21 11:17:44 2015] as i said, "visually" [Wed Jan 21 11:17:44 2015] pyon: + and - are other ways to structure proofs, supported by the proof engine (it will focus the current goal). [Wed Jan 21 11:17:58 2015] i have no idea what to do to make coq actually verify that the cases are the right ones [Wed Jan 21 11:19:11 2015] Ah... [Wed Jan 21 11:19:35 2015] + and -? [Wed Jan 21 11:19:44 2015] (sorry but these are hard to google and i want to know) [Wed Jan 21 11:21:04 2015] arvisrend: say you do a destruct lst. You have two goals. You can write + before your next tactic, and it will focus the first goal. [Wed Jan 21 11:21:25 2015] + and - do the same thing, but are visually distinct to alternate between subgoals. [Wed Jan 21 11:21:36 2015] what do you mean by focus the first goal? [Wed Jan 21 11:21:42 2015] isn#t the first goal automatically focused? [Wed Jan 21 11:22:26 2015] you can use * too, or { ... } [Wed Jan 21 11:22:44 2015] it focuses the first goal and makes the other goals invisible to you [Wed Jan 21 11:22:55 2015] further, you must resolve the goal in order to work on the next bullet [Wed Jan 21 11:23:04 2015] extremely valuable for multiply nested proofs [Wed Jan 21 11:23:32 2015] ah thanks! [Wed Jan 21 11:23:45 2015] very useful for future-proofing i guess [Wed Jan 21 11:23:56 2015] but how do i "end" a bullet? [Wed Jan 21 11:24:27 2015] it ends when the goal is completed automatically [Wed Jan 21 11:24:29 2015] induction n. [Wed Jan 21 11:24:32 2015] + exact foo. [Wed Jan 21 11:24:34 2015] + exact bar. [Wed Jan 21 11:24:39 2015] (or -) [Wed Jan 21 11:24:50 2015] some tools expect the following bullet order: -, then +, then * [Wed Jan 21 11:25:10 2015] (which visually makes sense) [Wed Jan 21 11:26:00 2015] ah! [Wed Jan 21 11:32:00 2015] any idea how to match an hypothesis (in a [match goal with]) depending on its name ? [Wed Jan 21 11:32:34 2015] no, I don't know how to do that [Wed Jan 21 11:32:45 2015] but, if you know it's name, why do you need to match on it? [Wed Jan 21 11:33:24 2015] I am trying to make a tactic that works like [rewrite .. in ..] for example (the [in [Wed Jan 21 11:33:27 2015] part ) [Wed Jan 21 11:33:48 2015] ah [Wed Jan 21 11:34:05 2015] But I don't know what is in this hypothesis :/ [Wed Jan 21 11:34:36 2015] you could go [match H with ...], assuming H is your hypothesis [Wed Jan 21 11:34:41 2015] Is it possible to do [match H with] ? (H is the argument of the tactic) ?] [Wed Jan 21 11:35:03 2015] you can take a context argument [Wed Jan 21 11:35:09 2015] see CPDT, it gives an example of doing this [Wed Jan 21 11:35:20 2015] then, in another Ltac script, you can produce a context narrow to each hypothesis in turn [Wed Jan 21 11:35:42 2015] CPDT ? [Wed Jan 21 11:35:52 2015] http://adam.chlipala.net/cpdt/cpdt.pdf [Wed Jan 21 11:36:01 2015] anyone who is writing Ltac needs to read that [Wed Jan 21 11:36:09 2015] Hoo .. :p [Wed Jan 21 11:36:13 2015] Ok, thanks ;) [Wed Jan 21 11:37:12 2015] Just another quick question, what is the exact role of the syntax "?x" ? (I'm using it to "introduce" variable names) [Wed Jan 21 11:38:40 2015] ?x introduces a variable name ;) [Wed Jan 21 11:38:47 2015] I don't quite understand the question? [Wed Jan 21 11:39:03 2015] How do I complete this proof using proof automation? https://gist.github.com/eduardoleon/8309321c189e4b67fa39 [Wed Jan 21 11:39:12 2015] I saw someone else using it with [Search] [Wed Jan 21 11:43:08 2015] pyon: induction xs; simpl; try rewrite <- IHxs; auto. [Wed Jan 21 11:44:00 2015] My current "manual" proof is already "induction xs; try (simpl; rewrite length_snoc; rewrite IHxs); reflexivity." [Wed Jan 21 11:44:11 2015] i didn't need to mention length_snoc [Wed Jan 21 11:44:18 2015] The point is getting Coq to figure out all the rewrites. [Wed Jan 21 11:44:23 2015] oh, add Hint Resolve length_snoc. [Wed Jan 21 11:45:07 2015] where do i find in ssreflect the fact that x <> y yields (x == y) = false for two nats x and y? [Wed Jan 21 11:45:25 2015] apply/eqP. [Wed Jan 21 11:45:39 2015] thank you! [Wed Jan 21 11:46:05 2015] hmm [Wed Jan 21 11:46:10 2015] "apply/eqP in H" doesn't work for syntax reasons [Wed Jan 21 11:46:12 2015] what am i doing wrong? [Wed Jan 21 11:46:16 2015] move/eqP in H [Wed Jan 21 11:46:26 2015] ah thank you [Wed Jan 21 11:46:32 2015] haven't seen this stuff yet [Wed Jan 21 11:49:35 2015] Asking to prove whether this statement is true or not. http://i.imgur.com/LJBnsko.png Think I've figured this out, if R is '=' or '<' the size of R changes therefore the subset cannot be the size of the set? Anyone at all know if this is the correct train of thought? [Wed Jan 21 11:50:33 2015] what is R ; R ? [Wed Jan 21 11:51:06 2015] remember that a relation is a power set [Wed Jan 21 11:51:35 2015] (subset of the power set) [Wed Jan 21 11:56:47 2015] R ; R' = R' o R = {(x, z) : (x,y) in R, (y,z) in R'} [Wed Jan 21 11:57:22 2015] ahh, right [Wed Jan 21 11:57:27 2015] I have seen ; used for composition before [Wed Jan 21 11:57:53 2015] ; = "then", o = "after" [Wed Jan 21 11:58:09 2015] interesting [Wed Jan 21 11:58:15 2015] in Haskell we've been using & for ; [Wed Jan 21 11:58:18 2015] "and then" [Wed Jan 21 11:58:24 2015] oh, no, never mind [Wed Jan 21 11:58:26 2015] not & [Wed Jan 21 11:58:38 2015] >>> [Wed Jan 21 11:58:42 2015] no mnemonic there [Wed Jan 21 11:59:23 2015] ianjneu, So the answer is no? R = {(1,0), (0,1)}, yet R;R = {(0,0),(0,1),(1,0),(1,1)} [Wed Jan 21 12:03:11 2015] how do you justify (0,1) and (1,0) in R;R? You have to go from 0,1 to 1,0 to get (0,0), or 1,0 to 0,1 to get (1,1). Thus R;R not a subset of R. [Wed Jan 21 12:05:18 2015] Just like a single transition in a turing machine is a decidable set, but multiple (unbounded) transitions is not. If you know how to decide -->, but somehow -->;--> subseteq -->, then -->^+ subseteq -->, but then you've solved the halting problem because you can decide start -->^+ end [Wed Jan 21 12:05:50 2015] generally not true, and also not true for relation {0,1} [Wed Jan 21 12:07:18 2015] ianjneu, oops, sorry, you're right, but still we get R;R = {(0,0), (1,1)} which is not a subset of R [Wed Jan 21 12:07:24 2015] Do you agree? [Wed Jan 21 12:36:55 2015] can one get omega to work with Bignum.N ? [Wed Jan 21 12:47:11 2015] johnw @ 15:25 1/19: pong (I'm around very sporadically as I'm travelling internationally.) [Wed Jan 21 12:47:24 2015] jgross__: hi! [Wed Jan 21 12:47:31 2015] jgross__: I was wondering if you'd be in Boston next week Monday [Wed Jan 21 14:55:18 2015] What am-I doing wrong in this basic [match] : http://pastebin.com/GTyqhVxZ ? [Wed Jan 21 14:57:04 2015] I think you'd need: [ -| context(constr1 ?x ?y) ] => idtac [Wed Jan 21 14:57:06 2015] and then you could refer to y [Wed Jan 21 14:58:50 2015] can one get omega to work with Bignum.N ? [Wed Jan 21 14:58:58 2015] I mean, it is presburger arithmetic. [Wed Jan 21 14:59:16 2015] I don't know if the tactic works with that type, though [Wed Jan 21 15:01:30 2015] johnw : You mean in a match clause ? [Wed Jan 21 15:06:48 2015] yeah [Wed Jan 21 15:07:37 2015] "Syntax error: [match_rule] expected after '|' (in [match_list])." [Wed Jan 21 15:07:54 2015] In fact I would like to match an expression like "x < y" [Wed Jan 21 15:27:10 2015] Is there a way to debug pattern-matchin ? [Wed Jan 21 15:27:13 2015] matching* [Wed Jan 21 16:10:55 2015] johnw: Sorry for the delay; I'm slowly catching up on IRC. I'll be back in Boston on Jan 30, but not before. [Wed Jan 21 16:24:18 2015] jgross__: ok, thanks! [Wed Jan 21 17:01:22 2015] Hey guys, does anyone know how to disable the automatic indentation in emacs coq mode? It's completely terrible. Always indenting my lines as I'm writing them or after I'm done writing them, and guessing the wrong indentation... [Wed Jan 21 17:02:00 2015] thinkpad20: what do you mean by "automatic"? [Wed Jan 21 17:02:06 2015] are you in electic mode or something? [Wed Jan 21 17:03:28 2015] Automatic as in, I'm not actually doing the indents myself [Wed Jan 21 17:03:43 2015] I'm not sure what mode I'm in... I only use emacs for proof general [Wed Jan 21 17:05:30 2015] It also does this really annoying thing where it moves the cursor back a character when I close a parenthesis or type a period... but I can get rid of that with M-x show-paren-mode [Wed Jan 21 17:14:00 2015] hello, after I use Grab Existential Variables. on the following code: https://gist.github.com/90922142f7c962799bd0, I find that Heqe and Hu disappear from my context. What is causing this to happen, and how do I keep them there? [Wed Jan 21 17:17:29 2015] n/m [Wed Jan 21 17:40:01 2015] so... no thoughts? any emacs experts here? [Wed Jan 21 17:53:05 2015] I use Emacs heavily, but no thoughts [Wed Jan 21 18:01:04 2015] thinkpad20: are you using emacs in the terminal by any chance? [Wed Jan 21 18:04:26 2015] no, gui [Wed Jan 21 18:05:24 2015] version 24.4.1 [Wed Jan 21 18:05:37 2015] i'd note that this doesn't happen on my mac, only on the linux box [Wed Jan 21 18:06:19 2015] does PG do its own indentation magic, or are there any other libraries for it? [Wed Jan 21 18:13:30 2015] thinkpad20: can you try running M-x electric-indent-mode [Wed Jan 21 18:14:35 2015] ah man, that totally did it. [Wed Jan 21 18:14:40 2015] woooo [Wed Jan 21 18:15:11 2015] now it doesn't do any auto indentation at all... which is a little unfortunate, but WAY better than the kind of shenanigans it was doing before :) [Wed Jan 21 18:15:20 2015] thanks a ton! [Wed Jan 21 18:26:09 2015] is anyone here versed in how proofgeneral interacts with coqtop? [Wed Jan 21 18:26:31 2015] I'm mostly interested in how they figure out error locations, as it does not seem to be communicated by the -ideslave protocol I am using [Wed Jan 21 18:26:40 2015] browsing through the sources of proofgeneral now... [Wed Jan 21 18:55:28 2015] Ptival: I don't think pg uses -ideslave [Wed Jan 21 18:57:04 2015] it always feels so weird when a proof works out as: [Wed Jan 21 18:57:05 2015] Proof. case: rd => _ _ _ _ [[[_| ] [_| ]] _] _ // in r *. Qed. [Wed Jan 21 18:57:13 2015] all it cared about was the structure [Wed Jan 21 19:07:40 2015] jrw: yeah I just came to that conclusion [Wed Jan 21 19:07:56 2015] their error message comes from toplevel.ml [Wed Jan 21 19:08:33 2015] and coqtop.ml starts Toplevel.loop when not in -ideslave, and Ide_slave.loop in -ideslave [Wed Jan 21 19:08:42 2015] so looks like pg does not use -idesalve [Wed Jan 21 19:08:56 2015] huh I might have to change my full backend @__@ [Wed Jan 21 19:22:14 2015] oh I see they use a Backtrack command [Wed Jan 21 19:24:53 2015] jrw: do you think/know it uses the -emacs mode for figuring out state numbers? [Wed Jan 21 19:29:53 2015] Ptival: I think it does but I don't know for sure [Wed Jan 21 19:30:05 2015] we looked into it briefly for the ltacular stuff [Wed Jan 21 19:32:15 2015] jrw: oh it seems it uses -emacs-U [Wed Jan 21 19:32:44 2015] if I have a record of two fields, foo and bar, how do I prove that x = {| foo := foo x; bar := bar x |}? [Wed Jan 21 19:32:45 2015] which is not documented [Wed Jan 21 19:33:02 2015] that isn't just definitional equality, as reflexivity doesn't like it [Wed Jan 21 19:33:23 2015] oh, "by destruct x" works [Thu Jan 22 01:41:22 2015] Are there any examples of how to use Chlipala-style automation specifically for type safety proofs? [Thu Jan 22 01:44:17 2015] here's his poplmark stuff http://adam.chlipala.net/poplmark/ also examples in lambda tamer [Thu Jan 22 01:46:08 2015] Ah, checking! And thanks! [Thu Jan 22 05:04:51 2015] Is there a function that generates all subsets of a given size in the standard lib ? [Thu Jan 22 06:28:18 2015] is there a way to drop an assumption in a current goal? [Thu Jan 22 06:28:37 2015] clear? [Thu Jan 22 06:29:24 2015] ah, thx [Thu Jan 22 08:13:34 2015] hm. is there exponentiation for nat? [Thu Jan 22 08:17:59 2015] there should be, check the docs [Thu Jan 22 08:18:08 2015] https://coq.inria.fr/library/Coq.Init.Peano.html [Thu Jan 22 08:18:21 2015] https://coq.inria.fr/library/index.html [Thu Jan 22 08:19:28 2015] doesnt actually look like there is though [Thu Jan 22 08:19:37 2015] vanila: the only thing I found was https://coq.inria.fr/library/Coq.Numbers.NatInt.NZPow.html but this is not for nat apparently. [Thu Jan 22 08:19:45 2015] or ... I am not sure how to use this for nat. [Thu Jan 22 08:21:35 2015] I found NPeano.pow from Require Import Arith. then SearchAbout nat. [Thu Jan 22 08:21:46 2015] https://coq.inria.fr/library/Coq.Numbers.Natural.Peano.NPeano.html [Thu Jan 22 08:21:58 2015] this seems to be where they hide all the good bits [Thu Jan 22 08:22:41 2015] so they're defining some kind of "Nat" module [Thu Jan 22 08:22:45 2015] vanila: thank you. [Thu Jan 22 08:22:49 2015] this works. [Thu Jan 22 08:23:06 2015] but if you just Require Import NPeano. you can use pow [Thu Jan 22 08:23:27 2015] (although it might be useful to look into the module stuff if you watned to switch out the implementation of nat later) [Thu Jan 22 09:31:10 2015] is it possible to get omega for N? [Thu Jan 22 09:36:24 2015] no but ring. can help [Thu Jan 22 09:36:35 2015] there may some opther automatic tactics that work on N [Thu Jan 22 09:36:37 2015] presberger amybe [Thu Jan 22 09:36:53 2015] oh wait I think ring does apply to N actually [Thu Jan 22 09:37:15 2015] "Formulas on nat are automatically injected into Z" [Thu Jan 22 09:37:17 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual023.html [Thu Jan 22 09:43:55 2015] strangely, I want to derive (a + b) >= 1 from b >= 1, all in N. [Thu Jan 22 09:44:08 2015] yeah that should definitely work [Thu Jan 22 09:44:14 2015] it doesnt [Thu Jan 22 09:44:23 2015] even when converting it to Z [Thu Jan 22 09:44:55 2015] http://lpaste.net/118997 [Thu Jan 22 09:44:58 2015] this succeeds for me [Thu Jan 22 09:45:17 2015] vanila: N, not nat [Thu Jan 22 09:45:23 2015] ohh [Thu Jan 22 09:45:31 2015] sorry! I misunderstood [Thu Jan 22 09:46:56 2015] vanila: I can manage to get (Z.of_N distsuffixbase >= Z.of_N 1)%Z, and as goal (Z.of_N distsuffixnum + Z.of_N distsuffixbase >= Z.of_N 1)%Z, still, omega sais it cannot solve this system [Thu Jan 22 09:47:05 2015] hm. [Thu Jan 22 09:47:10 2015] maybe with a lemma ... [Thu Jan 22 09:47:22 2015] im trying to see how you would get this lemma for the generic nat structure [Thu Jan 22 09:47:30 2015] and then the modue thing would let you instance that for N [Thu Jan 22 09:48:17 2015] wah [Thu Jan 22 09:48:34 2015] this does not hold for Z i think [Thu Jan 22 09:48:38 2015] I think it would be good to ask this on Coq club [Thu Jan 22 09:49:01 2015] no, it is wrong that b >= c implies (a+b >= c) in general [Thu Jan 22 09:49:07 2015] of couse you can prove it by hand pretty easy, but you really want to be able to apply omega [Thu Jan 22 09:49:07 2015] one needs b >= 0 [Thu Jan 22 09:49:26 2015] so I need Z.of_N distsuffixbase >= 0 [Thu Jan 22 09:50:10 2015] wait a sec [Thu Jan 22 09:50:15 2015] are you just using N because it has exponentiation? [Thu Jan 22 09:50:40 2015] it is probably easier to implement that than working around the difficulty of applying omega to N [Thu Jan 22 09:55:29 2015] vanila: no, I use N at this point since this value is an index of a 32k buffer, and coq warns about possible stack overflows. [Thu Jan 22 09:55:53 2015] ah okay [Thu Jan 22 09:56:46 2015] I wonder why coq does not have and utilize intrinsics. [Thu Jan 22 11:06:27 2015] why are there negative cases for N? [Thu Jan 22 11:09:17 2015] schoppenhauer: context? [Thu Jan 22 11:39:05 2015] ianjneu: N.pow_succ_r: forall n p : N, (0 <= p)%N -> (n ^ N.succ p)%N = (n * n ^ p)%N [Thu Jan 22 11:39:18 2015] ianjneu: isn't 0 <= p unneccessary? [Thu Jan 22 11:42:04 2015] from which library? [Thu Jan 22 11:42:28 2015] because i see that lemma in Coq.ZArith.BinInt, and there things are scoped to Z [Thu Jan 22 12:00:08 2015] http://adam.chlipala.net/cpdt/html/DataStruct.html -- In the section on heterogeneous lists (hlist), wouldn't it have been easier to define hget in the proof language? e.g. "Definition hget xs (ys : hlist xs) : member xs -> B e. Proof. induction ys; intro; inversion X; firstorder. Defined." [Thu Jan 22 12:00:12 2015] Or is there something I am missing. [Thu Jan 22 12:00:13 2015] ? [Thu Jan 22 12:00:32 2015] AFAICT, this type has exactly one inhabitant. [Thu Jan 22 12:00:45 2015] Part of his philosophy is to define all 'programs' explicitly [Thu Jan 22 12:01:03 2015] in general it's a bad idea to program with tactics, they should only be used to build irrelevant terms [Thu Jan 22 12:01:22 2015] Oh. [Thu Jan 22 12:01:46 2015] If only dependent pattern matching weren't so painful... [Thu Jan 22 12:02:10 2015] yeah coq does not have proper dependent type pattern matching, and that makes doing proper programming in it nearly impossible :( [Thu Jan 22 12:02:45 2015] There has to be some way to prune the impossible cases outside of the tactic language. [Thu Jan 22 12:03:11 2015] I mean, something like what "inversion" can do (at least in many cases) in the tactic language. [Thu Jan 22 12:03:18 2015] one thing that you can do is write the program part of a definition using refine, leaving some holes for proof obligations and then fill them in with tactics [Thu Jan 22 12:03:41 2015] the "Program" thing goes further with this style [Thu Jan 22 12:04:55 2015] To get a taste of it... how would "hget" be defined using Program? [Thu Jan 22 12:53:11 2015] waaah ... What is the best way to solve finitely many cases of something? I currently use do (destruct bla as [|bla]; [... | idtac]), and it works, except that when using "Defined." or "Qed." in the end, Coq keeps consuming memory (> 96GiB). [Thu Jan 22 12:59:01 2015] schoppenhauer: I think Adam Chlipala had a similar problem a few years ago, where he had a lot of small datastructures that he kept destructing. The solution was to create really wide datastructures. [Thu Jan 22 13:01:03 2015] schoppenhauer: what if you abstract each step? [Thu Jan 22 13:01:08 2015] do (abstract (...)) [Thu Jan 22 13:06:17 2015] johnw: abstract? [Thu Jan 22 13:06:47 2015] *googles* [Thu Jan 22 13:07:31 2015] ah, looks useful. [Thu Jan 22 13:09:20 2015] yes [Thu Jan 22 13:09:31 2015] it says "I don't need the proof term for this sub-expression", so it gets freed instantly [Thu Jan 22 13:09:43 2015] Adam mentions it in CPDT [Thu Jan 22 13:13:54 2015] ok. [Thu Jan 22 13:14:24 2015] hm. it would be nice if it was possible to parallelize proofs with branches :/ [Thu Jan 22 13:14:32 2015] I have 16 cores with 32 threads ... [Thu Jan 22 13:15:37 2015] and only 1 is used ... [Thu Jan 22 13:16:10 2015] IIRC 8.5 has some work in this department, but unfortunately, the single-threaded assumption is built pretty deep into Coq [Thu Jan 22 13:16:44 2015] Performance is not a priority for the Coq devs. [Thu Jan 22 13:18:05 2015] "Implicit Arguments" is deprecated. What is the replacement for it? [Thu Jan 22 13:18:28 2015] Just [Arguments], I believe [Thu Jan 22 13:18:48 2015] But I don’t remember the syntax off the top of my head. [Thu Jan 22 13:19:22 2015] johnw: worked, thx. [Thu Jan 22 13:19:59 2015] schoppenhauer: what was the impact? [Thu Jan 22 13:20:11 2015] johnw: adding abstract. [Thu Jan 22 13:20:16 2015] i mean, did it reduce memory? [Thu Jan 22 13:37:05 2015] johnw: yes. [Thu Jan 22 13:37:24 2015] johnw: especially, it terminated in a few minutes, instead of runing for hours :3 [Thu Jan 22 13:42:19 2015] sweet! [Thu Jan 22 13:42:22 2015] glad I could help [Thu Jan 22 13:42:28 2015] I thought your problem sounded familiar... :) [Thu Jan 22 13:44:13 2015] Implicit arguments are still explicit in the left-hand side of pattern matching, right? [Thu Jan 22 13:44:41 2015] pyon: it depends [Thu Jan 22 13:44:57 2015] On what? :-O [Thu Jan 22 13:44:59 2015] pyon: implicit parameters, no in 8.4, yes in 8.5; indices, yes in both [Thu Jan 22 13:45:11 2015] 8.5 has a flag to revert to 8.4 behavior [Thu Jan 22 13:45:43 2015] so for example: [Thu Jan 22 13:45:56 2015] match exist _ a b with exist a b => a end [Thu Jan 22 13:46:04 2015] but in 8.5, you'd say: match exist _ a b with exist _ a b => a end [Thu Jan 22 13:48:07 2015] :-O [Thu Jan 22 14:01:49 2015] johnw: Doesn't this make notations less useful in pattern matching? [Thu Jan 22 14:02:03 2015] I mean, notations that stand for constructors with implicit arguments. [Thu Jan 22 14:02:11 2015] I don't know, I haven't used 8.5 enough [Thu Jan 22 14:33:34 2015] Hi, is there a way to debug match clauses ? (i.e. display what is the expression that is testing) [Thu Jan 22 14:34:48 2015] Or at least a workaround to use Check in a tactic (in a match clause) [Thu Jan 22 14:45:00 2015] Choups314: you can match on something and then pose it into your context to see its type. [Thu Jan 22 14:46:38 2015] jrw: Yes it helps, but (it's a different question) is possible to display messages (a kind of user-information messages) ? [Thu Jan 22 14:47:15 2015] depends on the message [Thu Jan 22 14:47:25 2015] you can use idtac to print stuff [Thu Jan 22 14:47:34 2015] but iirc this is broken in proof general [Thu Jan 22 15:46:27 2015] hey guys, if I have a hypothesis like (x <> x), is there a shorthand to prove my goal then and there? [Thu Jan 22 15:46:57 2015] elimtype False; discriminate. [Thu Jan 22 15:48:18 2015] Hmm, that didn't quite work. elimtype False replaced the goal with False, but I still had to do apply H; reflexivity. [Thu Jan 22 15:48:25 2015] or match goal with [H: ?x <> ?x |- _] => destruct (H eq_refl) end [Thu Jan 22 15:48:40 2015] oh sorry, congruence. [Thu Jan 22 15:48:59 2015] discriminate would ony work when x is an actual constructor [Thu Jan 22 15:49:04 2015] oh, that worked. What's that doing at a high level? [Thu Jan 22 15:53:25 2015] Any x <> x hypothesis you have is a function from x = x -> False. Anything is proven by eliminating (destructing) False, so "destruct (H eq_refl)" destructs the false that H gives from an equality proof. [Thu Jan 22 15:54:03 2015] x = x is proven trivially by eq_refl. [Thu Jan 22 15:55:57 2015] cool thanks [Thu Jan 22 17:34:14 2015] I have a situation I'm confused about: I have a definition const_pt {A B : pType} := fun A B : pType => {| pointed_fun := const (point B); point_eq := 1 |}. Then I define wedge_map_f A B := (const_pt: pUnit ->* A) and wedge_map_g A B := (const_pt : pUnit ->* B). Now Coq can't seem to recognize that for ppushl : (f: X ->* Y) -> (g: X->* Z) -> (Y -> ppushout f g) that ppushl (wedge_map f A B) (wedge_map_g A B) is the same type as pp [Thu Jan 22 17:34:21 2015] nst_pt : pUnit ->* B) [Thu Jan 22 17:34:44 2015] The details probably aren't important, just confused because there's two types that I've Defined to be the same [Thu Jan 22 17:35:00 2015] But when I apply a function to them Coq can't unify the two [Thu Jan 22 17:35:55 2015] I.e. copying and pasting the definition in place seems to result in a type that doesn't unify with the original [Thu Jan 22 17:36:32 2015] Any thoughts on what could cause that? [Thu Jan 22 17:43:01 2015] Nevermind; it was a hidden typo! [Thu Jan 22 17:43:35 2015] Hey guys, if I have a variable defined in a Section, is there a way to automatically make that variable implicit when used outside of that section? [Thu Jan 22 17:45:13 2015] For example I'm writing a bunch of functions that operate over a polymorphic set, like union, intersect etc. I don't want to have to keep on typing up the type parameter so I put these in a section. But then when I'm using these functions I want the parameter to be inferred, not explicitly given. I could just `Arguments union {A} _ _` etc but that's tedious... [Thu Jan 22 17:45:14 2015] thinkpad20: Context {var}. [Thu Jan 22 17:45:33 2015] instead of Variable bleh. [Thu Jan 22 17:46:10 2015] sweet! thanks a bunch [Thu Jan 22 18:45:50 2015] hey guys, is there a source from which the online documentation is built? [Thu Jan 22 18:48:45 2015] https://gist.github.com/eduardoleon/caba12251e4cdeffa689 -- How do I rewrite hlist_nil_number without using tactics? (And also without using dependent pattern matching, which is just too unreadable for my eyes.) [Thu Jan 22 18:49:33 2015] hlist_nil_member [Thu Jan 22 18:57:50 2015] pyon: http://pastebin.com/jpyZ2xtP [Thu Jan 22 18:58:33 2015] What if I wanted to inline this inside hget? [Thu Jan 22 18:58:35 2015] I would recommend learning to tolerate both tactics and match annotations :) [Thu Jan 22 18:58:50 2015] What I absolutely cannot tolerate is dependent pattern matching syntax. [Thu Jan 22 18:58:57 2015] I am okay with both programming and proving. [Thu Jan 22 19:00:18 2015] pyon: http://pastebin.com/ZsqHEMxg [Thu Jan 22 19:00:51 2015] yeah, I feel you on the syntax. you get used to it somehow. [Thu Jan 22 19:05:13 2015] Well, thanks! :-) [Thu Jan 22 19:06:29 2015] pyon: by the way, the best way to debug this kind of thing when using Program is to put undercores everywhere [Thu Jan 22 19:06:35 2015] then you get obligations for them [Thu Jan 22 19:07:25 2015] I just realized that, in this case, I could use underscores everywhere without getting any obligations. [Thu Jan 22 19:07:41 2015] I mean, even in the second "match s", in the HCons case. [Thu Jan 22 19:08:01 2015] This type really has only one inhabitant... [Thu Jan 22 19:08:14 2015] No, wait, there is one obligation. [Thu Jan 22 19:14:57 2015] jrw: Just one last question: would it be possible to shift "s" to the topmost argument list [result: "xs (ys : hlist xs) (s : index xs)"], and then pattern-match on "ys, s" ? [Thu Jan 22 19:16:07 2015] pyon: no because of the way coq refines types during dependent pattern matching [Thu Jan 22 19:16:16 2015] Mmm... [Thu Jan 22 19:16:47 2015] since the type of s depends on xs, it has to be in the return type when xs is matched on [Thu Jan 22 19:50:50 2015] ... I still think the extracted code for "Definition hget xs (ys : hlist xs) : index xs -> B e. Proof. induction ys; intro; inversion X; firstorder. Defined." is the best. And it is also what takes the least effort to write. :-| [Thu Jan 22 19:51:10 2015] Err, intro could go before induction ys. [Fri Jan 23 08:33:19 2015] Is there any tactic that means "take all hypotheses [G1,G2...Gm] that are equalities, replace them in all other hypotheses [H1,H2...Hm] (and then possibly discard [G1,G2...Gm]) ? [Fri Jan 23 08:36:42 2015] subst [Fri Jan 23 08:37:34 2015] Ah! [Fri Jan 23 08:37:38 2015] Thanks! [Fri Jan 23 08:37:58 2015] I see that Coq only automatically substs variables inside of sections, right? [Fri Jan 23 08:38:43 2015] That is kinda clever: it alerts me of the fact I haven't wrapped Variable-using code in a section. [Fri Jan 23 08:56:43 2015] Is there any way to say "Variables must become implicit arguments after the end of a section"? [Fri Jan 23 09:10:00 2015] https://gist.github.com/eduardoleon/30da2667dd1465c73c3f -- which one is clearer in STLC.v : termDen or termDenote? [Fri Jan 23 09:11:23 2015] termDenote [Fri Jan 23 09:13:01 2015] I just dislike those "fun xs =>". It like doing "intro xs" immediately after "induction t". [Fri Jan 23 09:13:05 2015] It is* [Fri Jan 23 10:14:02 2015] What exactly does "Obj.magic" do in extracted OCaml code? [Fri Jan 23 10:14:34 2015] its supposd to be the identiry function [Fri Jan 23 10:14:39 2015] its for casting an object from one type to another [Fri Jan 23 10:14:54 2015] when coq knows it is the same thing, but its not clear to the weaker type system [Fri Jan 23 10:15:26 2015] Ah! [Fri Jan 23 10:23:23 2015] Is there any way to provide Coq with information regarding which Variables should be turned into explicit vs. implicit arguments? [Fri Jan 23 10:24:25 2015] Variables are super-convenient, but that convenience is offset by the inconvenience of later on having to specify which variables must be implicit arguments. (Usually, most of them.) [Fri Jan 23 10:39:32 2015] pyon: R.e. your question about implicit arguments after the end of a section, I asked this yesterday. If you write `Context {x:T}.` rather than `Variable x:T.` then it acts the same way inside the Section, but when you leave the section they become implicit rather than explicit arguments. [Fri Jan 23 10:42:22 2015] thinkpad20: Oh! [Fri Jan 23 10:42:24 2015] thinkpad20: Nice! [Fri Jan 23 10:43:34 2015] Now the next tricky question. [Fri Jan 23 10:44:08 2015] Is there any way to control which variables are implicit arguments on a per-definition basis? [Fri Jan 23 10:44:32 2015] you mean inside a section? [Fri Jan 23 10:44:39 2015] Yep. [Fri Jan 23 10:44:56 2015] Hmm, that one's outside my knowledge... [Fri Jan 23 10:45:05 2015] Say, I have a Variable. I want it to be an explicit argument of one definition. But I want it to be an implicit argument in the remainder of the section. [Fri Jan 23 10:45:06 2015] Awww. [Fri Jan 23 10:45:25 2015] Yeah I'm still a beginner [Fri Jan 23 10:45:47 2015] But personally, in that case, I would probably just write different sections [Fri Jan 23 10:46:20 2015] I think the idea behind a Section in the first place is to denote "all of the functions in this section are parameterized by the same set of variables" [Fri Jan 23 10:46:56 2015] buuuut take that with a grain of salt. Hopefully others will chime in and tell you how you can accomplish that [Fri Jan 23 10:47:24 2015] Makes sense. [Fri Jan 23 10:58:37 2015] Is there any way to open a module? (Just like in ML) [Fri Jan 23 11:09:12 2015] Is there any way to tell the extraction facility to use OCaml's built-in "unit" type, rather than create a ridiculous "type unit0 = Tt" ? [Fri Jan 23 11:12:14 2015] yes but i dont remember how [Fri Jan 23 11:12:16 2015] pyon: [Extract Inductive unit => "unit" [ "()" ].] should do it [Fri Jan 23 11:13:20 2015] Ah! Nice! [Fri Jan 23 11:13:24 2015] ty [Fri Jan 23 11:30:29 2015] Does the standard library contain any module specifying the "obvious" extractions for types such as unit, prod, list, etc.? [Fri Jan 23 11:30:52 2015] In Haskell's case, even "sum" (Either). [Fri Jan 23 12:04:37 2015] Hello, I would like to apply the same Lemma on several terms at once [Fri Jan 23 12:04:51 2015] I have an hypothesis like [t1 \/ t2] [Fri Jan 23 12:05:14 2015] Is it possible, after destructing it, to "reconstruct" it ? [Fri Jan 23 12:05:33 2015] (I mean, to have a [\/] structure again) [Fri Jan 23 12:08:35 2015] Well I'm not totally sure I understand what you're saying... when you destruct `a \/ b`, you are looking at two cases, one in which `a` is true, and another in which `b` is true. If you're in the case where `a` is true, then `a \/ b` is trivially true for any `b`, but you've necessarily lost any kind of constraint on `b`. [Fri Jan 23 12:10:13 2015] In fact I would like to rewrite t1 and t2 [Fri Jan 23 12:10:18 2015] (at the same time) [Fri Jan 23 12:10:56 2015] I don't know if destruct is a good idea :/ [Fri Jan 23 12:11:37 2015] Well the problem is that if you have `t1 \/ t2` then there's no guarantee that you have t1 and t2 at the same time. That would be `t1 /\ t2` [Fri Jan 23 12:12:05 2015] For example, if I have an hypothesis [H : x Ohhh, I see. [Fri Jan 23 12:13:15 2015] Well probably what I would do is `assert (H': x -y<0 \/ x-y=0)` and then use the information in `H` to prove that assertion. Then I'd have both. [Fri Jan 23 12:15:16 2015] Just as an aside, though, if you're dealing with `nat`, then it's not the case that `x x-y<0`. [Fri Jan 23 12:15:45 2015] (unless, of course, your minus function returns an `int`) [Fri Jan 23 12:16:06 2015] I'm using the CoRN algebra structures (COrdFields) ;) [Fri Jan 23 12:20:05 2015] thinkpad20: [assert] works well, but I still have to prove the 2 subgoals (I first destruct the hypothesis, and then I used left, right). But it assumes I already now the "final rewrite form" .. and I would really like to do a Ltac for this ^^ [Fri Jan 23 12:20:33 2015] (i.e. just give the tactic an hypothesis and the lemma to use) [Fri Jan 23 12:24:21 2015] yeah I can totally see that. I mean you can easily write a `Lemma apply_or: forall P Q P' Q', P \/ Q -> (P -> P') -> (Q -> Q') -> P' \/ Q'`, which is the propositional logic rule you're using there... maybe that would work? But yeah it seems like a tactic would work for this. The issue is that given some arbitrary P and Q, there are any number of P's and Q's that you could create [Fri Jan 23 12:25:41 2015] If you had that lemma, you could apply it to `H` with the two other lemmas (a proof of `x x-y<0` and a proof of `x=y -> x-y=0`) and you'd get the desired transformation [Fri Jan 23 12:26:55 2015] That a good idea ! [Fri Jan 23 12:27:08 2015] that's [Fri Jan 23 12:27:42 2015] Awesome, hope it helps! [Fri Jan 23 12:28:12 2015] Just in case, do you know if it is possible to define Ltac with an unknow number of arguments ? [Fri Jan 23 12:28:37 2015] (Like optonial arguments) [Fri Jan 23 12:30:18 2015] Unfortunately I'm a relative newcomer to Coq, and a total neophyte when it comes to writing my own Ltacs. That being said, glancing at the software foundations chapter on tactics (which I haven't gotten to yet), it looks like it is: http://www.cis.upenn.edu/~bcpierce/sf/current/LibTactics.html#lab908 [Fri Jan 23 12:31:14 2015] "List of arguments" sounds good [Fri Jan 23 12:31:36 2015] I would use it to extend the tactic for constructions like [t1 \/ t2 ... \/ tn] [Fri Jan 23 12:32:29 2015] ( [intuition] can solve your lemma ^^) [Fri Jan 23 12:32:40 2015] yup, or tauto [Fri Jan 23 12:34:03 2015] And you can write an analogous one for /\ as well :) [Fri Jan 23 12:34:34 2015] Does Coq support quasi-quotation? [Fri Jan 23 12:34:40 2015] Actually only one will do (match .. with) ;) [Fri Jan 23 12:35:57 2015] pyon: I'm not sure, but between its extensible parser and its dependent types, I think most of the use cases of quasi-quotation are covered by the language itself... [Fri Jan 23 12:39:03 2015] I would like to quote terms from an object language, where the object language has symbols like "=", "+", etc. [Fri Jan 23 12:39:25 2015] Perhaps I would have to define my own scopes and work using those. [Fri Jan 23 12:40:23 2015] I think `Notation`s would be your friend. [Fri Jan 23 12:40:59 2015] Yes, I am already using Notations. [Fri Jan 23 12:41:10 2015] I'm not sure how much work it would be, but you can do pretty amazing things with them. For example: http://research.microsoft.com/en-us/um/people/nick/coqasm.pdf where they write valid x86 assembly directly within coq... [Fri Jan 23 12:41:36 2015] But it sucks to have to do something like "Notation "t1 ⊕ t2" := (Plus t1 t2) (at level 50)." [Fri Jan 23 12:41:53 2015] I want to say "+" means something different than "plus" when used on terms from my abstract syntax. [Fri Jan 23 12:42:37 2015] Yeah I think that's what scopes are for [Fri Jan 23 12:49:23 2015] I think Notation take the types in account [Fri Jan 23 12:49:43 2015] into* [Fri Jan 23 13:05:11 2015] Mmm, not directly, but it turns out I can bind scopes to types! :-) [Fri Jan 23 14:30:01 2015] I just noticed that Coq can extract code with different performance characteristics from logically equivalent definitions: https://gist.github.com/eduardoleon/6277d75d56d151fb0636 . Are there any rules for writing Coq code from which "good" code can be extracted? [Fri Jan 23 14:36:36 2015] yeah, there are a few I've discovered [Fri Jan 23 14:36:51 2015] make use the Set/Prop distinction as much as you can [Fri Jan 23 14:37:05 2015] let binding does not translate to let binding (at least, not for Haskell) [Fri Jan 23 14:37:12 2015] so for expensive evaluations I have to write: [Fri Jan 23 14:37:20 2015] let x := foo in ... [Fri Jan 23 14:37:32 2015] as: (fun x => ...) foo [Fri Jan 23 14:37:44 2015] if x is referenced multiple times, these produce very different results [Fri Jan 23 14:39:13 2015] :-O [Fri Jan 23 14:39:14 2015] I just realized that, at least in some cases, it is easier to get good code extracted from programs written in the tactic language rather than Gallina. [Fri Jan 23 14:39:32 2015] yeah, it's a tradeoff [Fri Jan 23 14:39:43 2015] I've rewritten some tactically coded functions in Gallina to get better results [Fri Jan 23 14:39:46 2015] and the reverse [Fri Jan 23 14:48:39 2015] Is there any single tactic that, given a hypothesis H, does the following: (1) generalize any hypotheses [G1,G2...] that H does not depend on, (2) induction H, (3) re-intro [G1,G2...] ? [Fri Jan 23 14:49:05 2015] This would be really, really, really sweet. [Fri Jan 23 16:05:29 2015] im really confused by this classic vs intuistic logic :S [Fri Jan 23 16:05:39 2015] peirce doenst doesnt hold but not not peirce does :S [Fri Jan 23 16:11:18 2015] haha [Fri Jan 23 16:23:17 2015] Nik05: that confuse you? [Fri Jan 23 16:23:20 2015] Nik05: even better... [Fri Jan 23 16:23:36 2015] Nik05: double negation elimination doesnt hold, but doubly negated double negation elimination does >:D [Fri Jan 23 16:28:14 2015] benzrf, Nik05: no, ~~(~~A -> A) does not hold (rather, is not provable nor disprovable). ~~~~A -> ~~A (and, in fact, ~~~A -> ~A) is provable. Similarly, A \/ ~A is not provable, but ~~(A \/ ~A) is. [Fri Jan 23 16:30:24 2015] jgross__: wait, really? [Fri Jan 23 16:30:29 2015] jgross__: oh [Fri Jan 23 16:30:36 2015] jgross__: does DNE not imply LEM? [Fri Jan 23 16:31:59 2015] yes this confuses me :P [Fri Jan 23 16:32:02 2015] jgross__: i thought they were equivalent [Fri Jan 23 16:33:33 2015] benzrf: DNE implies LEM, and LEM implies DNE. But ~~LEM does not imply ~~DNE. [Fri Jan 23 16:33:46 2015] jgross__: oh, shit [Fri Jan 23 16:34:19 2015] jgross__: i was thinking of ~LEM -> ~DNE because then LEM and DNE are in an argument position so you can precompose DNE -> LEM [Fri Jan 23 16:34:22 2015] oops >.< [Fri Jan 23 16:34:49 2015] ho can ~~(A \/ ~A) hold? :S [Fri Jan 23 16:34:53 2015] no... no wait [Fri Jan 23 16:35:04 2015] isnt that the cont functor [Fri Jan 23 16:35:20 2015] hold on... [Fri Jan 23 16:35:31 2015] Nik05: Set it up as a goal in Coq, and follow your nose. The proof is short. [Fri Jan 23 16:36:46 2015] jgross__: ok just hold on [Fri Jan 23 16:36:58 2015] firstorder. Qed. :P [Fri Jan 23 16:38:11 2015] Nik05: Sure. Now your challenge is to understand the proof and break it down into the composition of a few obvious lemmas. [Fri Jan 23 16:39:30 2015] let nnLEM : ((LEM -> False) -> False) and d2l : LEM -> DNE. then isnt (fun nDNE : ~DNE => nnLEM (nDNE ◦ d2l)) : ~~DNE [Fri Jan 23 16:40:52 2015] im now at the point that i need to prove p ∨ ¬p, without any hypothesis... but tauto. still proves it [Fri Jan 23 16:41:59 2015] wait this isnt correct [Fri Jan 23 16:54:52 2015] Nik05: for the vast majority of values of P, you can prove P ∨ ¬P [Fri Jan 23 16:54:58 2015] you just cant prove it in the general case [Fri Jan 23 16:55:38 2015] oke, well i have no idea how to prove ¬¬(p ∨ ¬p)... [Fri Jan 23 16:56:23 2015] jgross__: whats wrong with my double neg DNE proof [Fri Jan 23 17:28:45 2015] benzrf: Nevermind, I was wrong. ~~LEM and ~~DNE are both provable. [Fri Jan 23 17:28:55 2015] i knew it!! [Fri Jan 23 17:30:27 2015] newtype Cont r a = Cont ((a -> r) -> r) -- Cont r is a functor [Fri Jan 23 17:30:55 2015] therefore, Cont False LEM + LEM -> DNE = Cont False DNE [Fri Jan 23 18:52:07 2015] anyone know how to get CoqIDE to apply settings in Windows? :P [Fri Jan 23 18:52:44 2015] i want to change the shortcuts, in Linux i just click apply and then also need to restart the program. But on windows none works [Fri Jan 23 18:55:03 2015] i guess they didnt verified CoqIDE with coq :P [Fri Jan 23 18:55:10 2015] verify* [Fri Jan 23 20:20:07 2015] damn coqide [Fri Jan 23 20:20:25 2015] still not working, it doesnt save any changes [Fri Jan 23 20:20:38 2015] Have you tried Proof General? [Fri Jan 23 20:20:45 2015] uh no [Fri Jan 23 20:20:56 2015] thats emacs right? [Fri Jan 23 20:21:01 2015] Emacs isn't precisely easy to learn, but Proof General is a lot more convenient than CoqIDE. [Fri Jan 23 20:21:14 2015] And, yes, PG is for Emacs. [Fri Jan 23 20:21:57 2015] installing emacs on windows is probably even worse ;P [Fri Jan 23 20:58:54 2015] oh i also proved not not lem... [Fri Jan 23 20:58:58 2015] feels weird [Fri Jan 23 21:25:36 2015] Nik05: u can prove not not lem cause not lem implies lem [Fri Jan 23 21:25:42 2015] Nik05: and then from there you get false [Fri Jan 23 22:51:10 2015] Nik05: emacs on Windows isn't actually that bad iirc. [Sat Jan 24 11:55:49 2015] Hi, is it possible to "evaluate" the result of a Lemma apply call (i.e. get the conclusion of a Lemma in a Ltac) ? [Sun Jan 25 09:41:05 2015] Is it possible to create tactics in caml ? [Sun Jan 25 09:41:21 2015] yes but its a difficult [Thu Jan 29 13:19:27 2015] how can I automatically add loadpaths to proof general? Are there ways I can do this (a) at runtime, (b) globally with some default paths, and (c) on a per-project basis? [Thu Jan 29 13:41:31 2015] OK, got it... `(set-variable 'coq-load-path '("path/to/stuff"))` [Thu Jan 29 13:43:20 2015] dunno how to switch it at runtime or folder-specific but that still helps [Thu Jan 29 14:16:10 2015] In Coq, is it possible to rewrite let (a,b) := c in z such that a is replaced with fst c and b with snd c in z ? [Thu Jan 29 14:17:00 2015] altneratively, is there a way to simplify snd (let x := ... in (a, b)) to let x := ... in a ? [Thu Jan 29 14:17:14 2015] that last a is supposed to be a b [Thu Jan 29 14:38:45 2015] bennofs: I'm not quite sure what you're trying to do. does [destruct (...)] do what you want? [Thu Jan 29 14:44:51 2015] jrw: right, that looks like it could solve my problem. Thanks [Wed Feb 4 01:09:52 2015] if I have “vs : HList [x]” as a hypothesis, and I “inversion” on it, shouldn’t occurences of “vs” in the goal be replaced with the constructor?? [Wed Feb 4 06:30:48 2015] how can I actually compute something in coq? [Wed Feb 4 06:31:18 2015] I have a function ... but when trying to compute, it always just shows the function, without really computing. [Wed Feb 4 06:48:22 2015] schoppenhauer : [Eval compute in expr.] ? [Wed Feb 4 06:54:49 2015] Cypi: no, unfortunately this just shows the function application. [Wed Feb 4 06:55:00 2015] Cypi: ok, maybe because the function is opaque? [Wed Feb 4 06:55:07 2015] anyway, I extracted it to haskell. [Wed Feb 4 06:55:51 2015] If it is opaque, indeed, only the typing information is available. [Wed Feb 4 06:57:11 2015] well then, thx. does anyone know whether there is 1. a command to add an import declaration to an extracted haskell program, 2. a coq-file with definitions for ascii or strings for haskell (I found http://www.cis.upenn.edu/~bcpierce/sf/current/Extraction.html for ML, and can probably adapt it, but if it already exists, I'd prefer it) [Wed Feb 4 19:02:21 2015] can the calculus of inductive constructions be modeled in ZFC? [Wed Feb 4 19:02:49 2015] yes http://www.lix.polytechnique.fr/Labo/Bruno.Barras/proofs/sets-old/sets.pdf [Wed Feb 4 19:02:56 2015] cool, thanks :) [Wed Feb 4 21:19:36 2015] anybody able to help with this simple proof? http://lpaste.net/119994 [Wed Feb 4 21:20:50 2015] I’m trying to prove that, for some nat-indexed vec type, if it’s indexed by 1, then it must be just (cons blah nil) [Wed Feb 4 21:21:39 2015] let me try [Wed Feb 4 21:21:56 2015] thanks johnw [Wed Feb 4 21:25:42 2015] amosr: here you go: https://gist.github.com/b93cf700f8882e6307d4 [Wed Feb 4 21:26:24 2015] I don't know how to do what dependent destruction is doing for you here, without writing a custom induction principle [Wed Feb 4 21:29:25 2015] johnw: woo, thank you! [Wed Feb 4 21:29:31 2015] I didn’t even know about dependent destruction [Wed Feb 4 21:30:00 2015] it comes in handy :) [Wed Feb 4 21:30:05 2015] there is also dependent inductino [Wed Feb 4 21:30:17 2015] there are several Coq.Program modules, and they are all useful [Wed Feb 4 21:33:33 2015] cool, I’ll check them out [Wed Feb 4 21:34:24 2015] be aware, dependent destruction pulls the JMeq axiom into your development [Wed Feb 4 21:34:38 2015] that's why I generally avoid it [Wed Feb 4 21:35:22 2015] hmm. what is JMeq? [Wed Feb 4 21:37:01 2015] John Major equality [Wed Feb 4 21:37:10 2015] https://coq.inria.fr/library/Coq.Logic.JMeq.html [Wed Feb 4 21:39:28 2015] ah, okay. that looks reasonable enough, on first glance [Wed Feb 4 21:52:42 2015] i still don't understand what it does [Wed Feb 4 21:52:51 2015] not that i care much though as it seems to require an axiom [Wed Feb 4 21:53:10 2015] how can two objects of different types be equal? [Wed Feb 4 21:54:34 2015] I think they are the same type? [Wed Feb 4 21:57:02 2015] but why the B then? [Wed Feb 4 21:57:39 2015] ok i guess i just don't understand the definition of JMeq [Wed Feb 4 21:58:02 2015] amosr: if you want an axiom-free version, see http://pastebin.com/8qxnSBd3 (note that I had to define custom induction (perhaps more accurately in this case: destruction) principles like johnw mentioned) [Wed Feb 4 21:58:15 2015] oh, you’re right. huh [Wed Feb 4 21:58:15 2015] arvisrend: that's because it's confusing at first :) [Wed Feb 4 21:58:38 2015] the basic idea is that JMEq allows you to *pose* the equality of terms of two different types as a proposition [Wed Feb 4 21:58:42 2015] what is the role of B? [Wed Feb 4 21:58:57 2015] but you can still only prove equalities between something and itself [Wed Feb 4 21:58:59 2015] hmm [Wed Feb 4 21:59:05 2015] how does it help proving stuff? [Wed Feb 4 21:59:08 2015] yes [Wed Feb 4 21:59:11 2015] makes things more convenient [Wed Feb 4 21:59:30 2015] when you have lots of dependent types floating around you often have two types that you know are equal, but coq doesn't see that they are [Wed Feb 4 21:59:40 2015] aaaaaaah extensionality crap [Wed Feb 4 21:59:40 2015] so you can pose your equality as a JMeq and then prove it [Wed Feb 4 22:00:12 2015] if you don't use jmeq, the problem is that you can't even state the equality as a proposition, much less prove it. [Wed Feb 4 22:00:18 2015] i see [Wed Feb 4 22:00:28 2015] dependent destruction uses this internally to "pass evidence" into each branch of a pattern match [Wed Feb 4 22:00:30 2015] okay. that sounds useful for many of the things I’ve been trying to do lately [Wed Feb 4 22:00:35 2015] when different branches have different types [Wed Feb 4 22:00:54 2015] wondering if the issue can be resolved using custom equalities though [Wed Feb 4 22:01:05 2015] have a good simple example? [Wed Feb 4 22:01:06 2015] amosr: also, if I may make a shameless plug, I talk about how to do this without axioms in a series of blog posts. see http://homes.cs.washington.edu/~jrw12/ [Wed Feb 4 22:01:19 2015] arvisrend: what do you mean by custom equalities? [Wed Feb 4 22:01:52 2015] something like ssreflect's "equality upon applying to one variable", "equality upon applying to two variables" etc. to get past lack of funcext [Wed Feb 4 22:02:14 2015] jrw: great, thanks! [Wed Feb 4 22:02:51 2015] arvisrend: there are a couple ways to get around this. one is you can use "transport" aka eq_rect [Wed Feb 4 22:03:11 2015] which takes a type-level equality A = B and uses it to convert a term of type A into one of type B [Wed Feb 4 22:03:15 2015] hmm [Wed Feb 4 22:03:19 2015] so then instead of saying a = b [Wed Feb 4 22:03:21 2015] but that's if i can prove the types are equal [Wed Feb 4 22:03:31 2015] well yeah, but you're going to have to do that at some point [Wed Feb 4 22:03:53 2015] i was thinking that with dependent types, the lack of funext takes even that away [Wed Feb 4 22:04:26 2015] I don't really see how funext is relevant [Wed Feb 4 22:04:40 2015] you're proving, eg, Vec 3 = Vec (2 + 1) [Wed Feb 4 22:04:55 2015] ok [Wed Feb 4 22:04:59 2015] can't i use rewrite? [Wed Feb 4 22:05:04 2015] (which happens to be definitional, so it's easy) [Wed Feb 4 22:05:20 2015] yeah, usually the type-level equality isn't too hard to prove [Wed Feb 4 22:05:23 2015] i was thinking about things like forall x : Vec (x+1) vs forall x : Vec(1+x) [Wed Feb 4 22:05:28 2015] exactly [Wed Feb 4 22:05:48 2015] which i guess aren't even equal, to coq [Wed Feb 4 22:05:52 2015] they are [Wed Feb 4 22:05:57 2015] but not definitionally :D [Wed Feb 4 22:06:07 2015] yeah, that's this =1 equality [Wed Feb 4 22:06:10 2015] oh I see [Wed Feb 4 22:06:17 2015] well in your case, you've got that forall in there [Wed Feb 4 22:06:23 2015] so they're not unless you use =1 or have funext [Wed Feb 4 22:06:29 2015] yeah [Wed Feb 4 22:06:41 2015] but you *can* prove, for example [forall A n, Vec A (n + 1) = Vec A (1 + n)] [Wed Feb 4 22:06:42 2015] i'm wondering what equality should i expect for elements of those types if the types themselves are only =1 [Wed Feb 4 22:06:44 2015] they imply each other [Wed Feb 4 22:07:04 2015] who? [Wed Feb 4 22:07:20 2015] well a term of type [forall x, Vec (x + 1)] is a very weird term IMO [Wed Feb 4 22:07:30 2015] it's a triangular array of numbers [Wed Feb 4 22:07:33 2015] i wouldn't call it weird [Wed Feb 4 22:07:40 2015] have these things all the time in combiantorics [Wed Feb 4 22:07:45 2015] yeah [Wed Feb 4 22:08:10 2015] I guess I still think the issue of functional extensionality is orthogonal to the JMeq stuff [Wed Feb 4 22:08:16 2015] (forall x, Vec (x + 1)) <-> (forall x, Vec (1 + x)) [Wed Feb 4 22:08:23 2015] you can make a bijection between them [Wed Feb 4 22:08:27 2015] ok [Wed Feb 4 22:08:32 2015] i see [Wed Feb 4 22:08:59 2015] soy ou might need to work with theorems whose assumptions are of the type [Wed Feb 4 22:09:10 2015] P <-> Q -> (something involving P) [Wed Feb 4 22:09:30 2015] oops [Wed Feb 4 22:10:03 2015] I stated that wrong, what I means is proving things up to bi-implication [Thu Feb 5 10:30:03 2015] any ideas why Coq sometimes gives detailed message for why it's unable to unify and sometimes just says "Unable to unify"? [Thu Feb 5 12:38:04 2015] I have a bunch of Coq code I'd like to package up as a library to be distributed and used with other code; but I'm not sure how to do that. Is there a tutorial anywhere? [Thu Feb 5 12:48:15 2015] More particularly, after installing things (via the 'install' target genrated by coq_makefile), how do I actually call in those libraries for client code? [Thu Feb 5 13:45:16 2015] wrengr: once you've installed the library, you should be able to just Require its modules. Does that not work for you? [Thu Feb 5 13:45:53 2015] Additionally, the user contribution submission form is here Please provide a list of other contributions which are necessary to compile this one (they must be referred to by the name given in the description files. [Thu Feb 5 13:45:57 2015] derp, [Thu Feb 5 13:46:00 2015] http://www.lix.polytechnique.fr/coq/pylons/contribs/new [Thu Feb 5 13:50:02 2015] I think the problem is I'm trying to do funny stuff about organizing the repo [Thu Feb 5 13:51:20 2015] I don't understand what that means [Thu Feb 5 13:53:15 2015] When creating a repository for a project, I like to put the code under a subdirectory like ./src so that it's separated from the other stuff in the project; but Coq's standard tooling really doesn't like doing that sort of thing [Thu Feb 5 13:54:45 2015] I'm getting errors like this: The file /sw/lib/coq/user-contrib/WrengrUtils/Tactics/Core.vo contains library [Thu Feb 5 13:54:48 2015] Tactics.Core and not library WrengrUtils.Tactics.Core [Thu Feb 5 14:11:33 2015] wrengr_away: http://adam.chlipala.net/cpdt/html/Large.html#lab102 [Thu Feb 5 16:16:47 2015] does anybody here know about linear typing >.< [Thu Feb 5 16:40:43 2015] benzrf: know to what extent? [Thu Feb 5 16:42:45 2015] to answer my questions [Thu Feb 5 16:42:53 2015] you'd have to ask them first :) [Thu Feb 5 16:43:14 2015] in particular: from looking at linear intuitionistic logic, it looks like you can only use a variable if it's the only one in scope?! [Thu Feb 5 16:43:44 2015] you mean, only use one variable at any given time? [Thu Feb 5 16:43:49 2015] well [Thu Feb 5 16:44:15 2015] it doesnt say "Γ, A ⊢ A" [Thu Feb 5 16:44:19 2015] it says "A ⊢ A" [Thu Feb 5 16:44:29 2015] ah [Thu Feb 5 16:44:35 2015] which translates to "x : A ⊢ x : A" [Thu Feb 5 16:44:39 2015] that strikes me as odd [Thu Feb 5 16:44:50 2015] define "at a time" [Thu Feb 5 16:44:55 2015] what dyou mean by that? [Thu Feb 5 16:45:07 2015] just what you wrote pretty much [Thu Feb 5 16:45:12 2015] ah, heh [Thu Feb 5 16:45:55 2015] i guess using shadowing to allow a new variable to be bound is isomorphic to allowing multiple names but you can only use the most recently bound one [Thu Feb 5 16:47:18 2015] i note that if you're allowed to introduce 1 at any time instead of only from an empty context, you can use cut to use any variable you like :) [Thu Feb 5 16:56:50 2015] writing custom induction hypotheses always feels cool [Thu Feb 5 17:17:41 2015] yay, it worked [Thu Feb 5 17:17:49 2015] elim/list_with_index_rec: xs :) [Thu Feb 5 17:21:58 2015] noob here: install coq8.4pl5 on macosx.. where do I find coqtop? [Thu Feb 5 17:24:46 2015] nm, locate found it [Thu Feb 5 17:37:44 2015] on hold for a second hour.. [Thu Feb 5 17:38:01 2015] oops, wrong channel [Fri Feb 6 01:18:22 2015] how exactly would I use elim/seq2_ind, since it seems to only want an equality? [Fri Feb 6 01:22:15 2015] I would have thought it would be "elim/seq2_ind: xs yss / Hsz.", but that says "too many dependent abstractions" [Fri Feb 6 10:04:50 2015] I want to implement something in coq that extracts to arrays (in haskell, for example). is there any defined way of doing this, or do I need to implement it myself? [Fri Feb 6 10:16:23 2015] hm. probably fmapavl [Fri Feb 6 10:25:53 2015] hm. no. [Fri Feb 6 11:21:39 2015] is Arguments not a command in old versions of coq [Fri Feb 6 13:37:22 2015] schoppenhauer: still here? [Fri Feb 6 13:37:36 2015] johnw: yes [Fri Feb 6 13:38:00 2015] so, create a wrapper in Coq: Inductive Foo a := mkFoo (list a) : Foo a [Fri Feb 6 13:38:23 2015] and make a set of functions for the accessors you want [Fri Feb 6 13:38:36 2015] then, just tell the extractor to extract that type to an Array, and the functions to the array functions [Fri Feb 6 13:38:50 2015] I do this for IntMaps vs. assoc lists, for example [Fri Feb 6 13:39:25 2015] the idea is that if your array is isomorphic to a list of fixed length, then your proofs transport [Fri Feb 6 13:49:42 2015] johnw: thank you, I actually had a similar idea. [Fri Feb 6 13:49:57 2015] maybe it would be nice to have some sort of uniqueness types in coq. [Fri Feb 6 16:08:32 2015] man, some things in Coq you just have to learn by doing, but it would be great if there was a book that covered it [Fri Feb 6 16:08:47 2015] for example, I've discovered the hard way that you can represent an inductive proposition in two very different ways [Fri Feb 6 16:09:11 2015] either as a collection of predicates applied to a data type, or as an inductive proposition whose constructors imply those predicates [Fri Feb 6 16:09:24 2015] and there are definite tradeoffs between those two equivalent representations [Fri Feb 6 16:10:32 2015] I just changed from one to the other in a file of mine, and it greatly simplified many proofs [Fri Feb 6 16:12:57 2015] I thinkt he CPDT book covers that [Fri Feb 6 16:13:02 2015] maybe it does [Fri Feb 6 16:13:06 2015] i haven't finished my second reading [Fri Feb 6 16:13:06 2015] since it defines vector n inductively and as a tuple that it computes [Fri Feb 6 16:15:29 2015] right [Fri Feb 6 16:15:37 2015] I remember that now [Fri Feb 6 16:15:57 2015] I think even software foundations covers this [Fri Feb 6 16:16:01 2015] so maybe it just didn't sink in enough [Fri Feb 6 16:40:38 2015] this proof is screaming for automation so badly I can barely hear myself think: https://gist.github.com/4fe6afa0eb6125686caf [Fri Feb 6 16:50:41 2015] is Arguments not a command in old versions of coq [Fri Feb 6 16:55:18 2015] i really love ssreflect's "by" tactical [Fri Feb 6 16:55:26 2015] it helps with refactoring quite a ibt [Fri Feb 6 18:28:35 2015] help :[ [Fri Feb 6 18:28:46 2015] i cannot compile SF because it complains that Arguments is not understood [Fri Feb 6 18:28:56 2015] i have 8.3pl4 [Fri Feb 6 18:31:00 2015] benzrf: SF? [Fri Feb 6 18:32:31 2015] software foundations [Fri Feb 6 18:35:50 2015] benzrf: it's a command that was added in 8.4. You'll need to upgrade (and it's a really good idea, there are nice, nice features in 8.4) [Fri Feb 6 18:36:38 2015] tfw debian stable [Fri Feb 6 18:36:42 2015] i should really upgrade to testing [Fri Feb 6 18:36:48 2015] do you know what version testing has in the repos [Fri Feb 6 19:57:42 2015] benzrf: sorry, no clue (although I'd expect 8.4, it's been out for years now) [Fri Feb 6 19:57:58 2015] hh [Sat Feb 7 02:10:05 2015] is there any good way to debug stack overflows in Gallina code? [Sat Feb 7 02:10:17 2015] I mean, at compile-time [Sat Feb 7 14:39:32 2015] benzrf: you could always try nix? [Sat Feb 7 14:49:05 2015] I think johnw has made nix's coq support pretty good [Sat Feb 7 14:49:15 2015] with actual libraries and such [Sat Feb 7 17:19:40 2015] yep, Nix makes Coq libraries easy to use [Sat Feb 7 23:19:27 2015] how do I change the color of the typechecked area in proofgeneral? [Sat Feb 7 23:30:56 2015] change proof-locked-face [Sat Feb 7 23:32:25 2015] thanks, ijp [Sat Feb 7 23:32:29 2015] fam I got these proofs on lock [Sun Feb 8 00:10:52 2015] ijp: how do I change it without 'custom'? I currently have this: (custom-set-variables) (custom-set-faces '(proof-locked-face ((t (:background "midnight blue"))))) [Sun Feb 8 00:10:52 2015] [Sun Feb 8 00:16:22 2015] (set-face-background 'proof-locked-face "midnight blue") [Sun Feb 8 00:17:58 2015] or (set-face-attribute 'proof-locked-face nil :background "midnight blue") which is nicer if you want to set multiple properties at once [Sun Feb 8 00:23:28 2015] ijp: thanks. after I re-eval'd my .emacs file, proofgeneral doesn't start when I open a .v file. how do I fix this? I know that restarting emacs will work, but I'd rather not do that. [Sun Feb 8 00:24:26 2015] I have no idea what can have went wrong, let alone how to fix it [Sun Feb 8 00:25:12 2015] I always had this problem. for the record, that's what I have in .emacs: (load-file (concat nix-site-lisp "ProofGeneral/generic/proof-site.el")) [Sun Feb 8 09:15:45 2015] the current version of the manual states, that type classes are extremely experimental [Sun Feb 8 09:16:01 2015] however, the standard library uses them [Sun Feb 8 09:16:44 2015] are they stable enough to use in an own project? [Sun Feb 8 09:16:59 2015] or should I expect major changes in the near future [Sun Feb 8 09:20:13 2015] JanBessai: iirc johnw experienced problems trying to extract the code using typeclasses to haskell. not sure what the details are [Sun Feb 8 09:21:42 2015] so it is probably better to be conservative, and just include the operations I need in module signatures [Sun Feb 8 09:23:23 2015] specifically, I'd just like to have le_trans and le_refl [Sun Feb 8 09:24:30 2015] for which it is not to terrible if a user has to state them manually when instantiating the module [Sun Feb 8 09:24:35 2015] *too [Sun Feb 8 15:19:14 2015] is there a simple example of parsing in coq? [Sun Feb 8 15:21:16 2015] how simple? [Sun Feb 8 15:21:26 2015] beyond lexing? [Sun Feb 8 15:22:01 2015] Beyond grammar acceptance? [Sun Feb 8 15:26:41 2015] there is a little parser in SF actually, isn't there? [Sun Feb 8 15:26:44 2015] for the WHILE language [Sun Feb 8 15:26:49 2015] but it has no correctness proofs [Sun Feb 8 15:26:56 2015] ianjneu: simple in the sense that it's written for people unfamiliar with coq ecosystem and parsing in coq in general. I've written only pure code in coq so far and haven't interacted with external libraries at all. [Sun Feb 8 15:27:18 2015] vanila: I haven't reached that part yet. [Sun Feb 8 15:28:11 2015] Parsing is a messy business. [Sun Feb 8 15:28:19 2015] vanila: would you suggest not to hurry? I can parse in haskell using, e.g., attoparsec. would it be similar in coq besides proofs? [Sun Feb 8 15:28:44 2015] oh! And there is a strongly specified regex example in CPDT! [Sun Feb 8 15:29:02 2015] oh, okay. I should wait, I guess. [Sun Feb 8 15:29:13 2015] yeah ther is noneed to rush, but parsing is quite difficult [Sun Feb 8 15:29:22 2015] in haskell you can use combinator parser libraries [Sun Feb 8 15:29:30 2015] but there is no need to justify termination [Sun Feb 8 15:29:44 2015] you have to fully justify termination in coq so it is harder [Sun Feb 8 15:29:45 2015] ah, right [Sun Feb 8 15:29:49 2015] there is an agda paper about this actually [Sun Feb 8 15:29:59 2015] could you find it for me please? [Sun Feb 8 15:30:08 2015] termination for parsing is a right foul nuisance with CFG parsing. [Sun Feb 8 15:31:40 2015] http://www.cse.chalmers.se/~nad/publications/danielsson-parser-combinators.pdf [Sun Feb 8 15:31:50 2015] thank you! [Sun Feb 8 15:31:57 2015] this uses coinductive data, im not sure if you should read it [Sun Feb 8 15:32:07 2015] well, it could be interesting [Sun Feb 8 15:32:30 2015] but i haven't really studied it myself so I don't want to put you on the wrong path [Sun Feb 8 15:33:10 2015] vanila: well, I'm not planning to dive deep anyway, just want to get a feeling of it [Sun Feb 8 15:34:02 2015] adam.chlipala.net/cpdt/html/MoreDep.html#lab55 [Sun Feb 8 15:34:06 2015] I think this woudl be the best thing to look at [Sun Feb 8 15:36:40 2015] * is looking for a parser for math formulas, able to deal with new notations and notation abuse. [Sun Feb 8 18:24:47 2015] can anyone explain coq 8.5's "fast compilation pipeline"? what sequence of make targets should I invoke and what are their guarantees? also I keep getting an uncaught exception when using any of the -schedule-* options to coqc. has anyone else had this problem? [Sun Feb 8 19:07:43 2015] Uncaught exception is a bug, and you should report it on the bug tracker: https://coq.inria.fr/bugs/enter_bug.cgi [Sun Feb 8 19:07:54 2015] jrw: ^ [Sun Feb 8 19:09:19 2015] jrw: If you use coq_makefile, you can call `make quick -j` and then, I think `make vio2vo J=4` (or however many cores you have). If your proofs are relatively fast, though, disk acess might kill you, because the .vio files get pretty huge. [Sun Feb 8 19:09:39 2015] jgross: this is with 8.5? [Mon Feb 9 07:57:08 2015] is strong induction in some standard lib? [Mon Feb 9 08:53:25 2015] not sure about standard lib, but see here http://stackoverflow.com/questions/20883855/coq-adding-a-strong-induction-tactic [Mon Feb 9 08:53:52 2015] I found this, but it essentially sais "no". I proved it myself, therefore. [Mon Feb 9 08:53:57 2015] joerisamson: thx! [Mon Feb 9 12:57:55 2015] I don't now if this is an Emacs of Coq-specific question, but when I use Proof General in Emacs, the "marker for what has been processed" is a purple background, but I can't figure out how to change that [Mon Feb 9 12:58:04 2015] It doesn't seem to care about any values in change in my theme file [Mon Feb 9 12:58:10 2015] my emacs theme file [Mon Feb 9 12:58:35 2015] kba: hmmmm. I feel like there was a way to change that. [Mon Feb 9 12:59:05 2015] http://proofgeneral.inf.ed.ac.uk/htmlshow.php?title=Proof+General+user+manual&file=releases%2FProofGeneral%2Fdoc%2FProofGeneral%2FProofGeneral_9.html [Mon Feb 9 12:59:32 2015] proof-locked-face [Mon Feb 9 13:01:34 2015] chirpsalot: got it fixed, thanks :) [Mon Feb 9 13:01:56 2015] kba: no problem! [Mon Feb 9 13:21:26 2015] chirpsalot: when I select text that is under proof-locked-face, I can't see my selection [Mon Feb 9 13:21:29 2015] Do you have a fix for that? [Mon Feb 9 13:22:23 2015] kba: not sure... You can turn off the highlighting of the proof-locked-face stuff, if you prefer? [Mon Feb 9 13:22:55 2015] but then how would I know how much has been evaluated? [Mon Feb 9 13:23:25 2015] kba: isn't there an arrow? [Mon Feb 9 13:23:41 2015] well, yeah, there is a small arrow [Mon Feb 9 13:23:53 2015] but it's not that visible [Mon Feb 9 14:40:36 2015] What is the difference between a semicolon and a period in Coq? [Mon Feb 9 14:40:49 2015] Like: a; b. [Mon Feb 9 14:40:51 2015] and a. b. [Mon Feb 9 14:41:54 2015] never mind! I get it [Mon Feb 9 14:42:01 2015] a; b causes b to be applied to all subgoals [Mon Feb 9 14:42:11 2015] if there's only 1 subgoal, no difference [Mon Feb 9 14:42:13 2015] johnw: all subgoals created by a [Mon Feb 9 14:42:20 2015] yes :) [Mon Feb 9 14:42:22 2015] thanks [Mon Feb 9 14:42:29 2015] right, all subgoals in that context [Mon Feb 9 14:42:33 2015] created by a [Mon Feb 9 18:39:41 2015] I have a theorem that goes something like: A -> B or A -> C. In my proof, I need the fact that A -> B. [Mon Feb 9 18:40:01 2015] Obviously, Coq won't let me just do that, because maybe it isn't true, maybe A -> C instead. [Mon Feb 9 18:40:15 2015] How can I use my theorem, and then prove that A !-> C? [Mon Feb 9 18:40:29 2015] kba: destruct your theorem [Mon Feb 9 18:40:43 2015] kba: in the A -> B branch, proceed normally [Mon Feb 9 18:40:56 2015] kba: in the A -> C branch, show that A doesnt imply C, and use inversion or something [Mon Feb 9 18:42:24 2015] you could do something like make Lemma get_left P Q : P \/ Q -> ~Q -> P. tauto. Qed. [Mon Feb 9 18:42:54 2015] then pose (get_left ...) with some proofs (the or and a proof that ~(A -> C)) [Mon Feb 9 18:43:03 2015] hm wait what is pose [Mon Feb 9 18:43:53 2015] it adds an new hypothesis to your contet [Mon Feb 9 18:51:29 2015] thanks, I got it working :) [Mon Feb 9 18:52:55 2015] What exactly does 'discriminate X' do? [Mon Feb 9 18:53:05 2015] Again, the docs are just nonsense to me [Mon Feb 9 18:53:34 2015] I understand from the code i see that it's used to just... solve stuff. [Mon Feb 9 18:53:42 2015] So I should be able to write it out as a series of rewrites [Mon Feb 9 18:55:09 2015] ah... [Mon Feb 9 18:55:12 2015] they broke 'info' [Mon Feb 9 18:56:15 2015] well discriminate is used to disprove assumptions of the type A .. = B .. wher A and B are different constructors [Mon Feb 9 18:56:41 2015] So if I have a subgoal X and I use 'discriminate Y' [Mon Feb 9 18:56:50 2015] I'm saying "not X"? [Mon Feb 9 18:56:58 2015] http://lpaste.net/120239 [Mon Feb 9 18:57:03 2015] here's an example [Mon Feb 9 18:57:17 2015] H is a proof that O = S O, but those are different constructors [Mon Feb 9 18:57:42 2015] so discriminate can finish any proof from a false assumption like that [Mon Feb 9 18:58:16 2015] Oh, so it's just contradiction? [Mon Feb 9 18:58:35 2015] So what we have as a subgoal when we do discriminate [Mon Feb 9 18:58:40 2015] Is that actually true or false? [Mon Feb 9 18:59:10 2015] it's not related to subgoals [Mon Feb 9 18:59:28 2015] It finishes the entire proof? [Mon Feb 9 18:59:32 2015] yeah [Mon Feb 9 18:59:43 2015] So if there's 10 subgoals and I somehow lure Coq into making a false assumption [Mon Feb 9 18:59:48 2015] if you were working inside a subgoal, it would prove the entire subgoal [Mon Feb 9 18:59:55 2015] I can just write "discriminate" and be done with it [Mon Feb 9 19:00:07 2015] Okay, so it's only the subgoal is finishes [Mon Feb 9 19:00:41 2015] Gr, that's so confusing. [Mon Feb 9 20:37:18 2015] when do coq tactics create subproofs, rather than building up the proof term inline? [Mon Feb 9 21:19:39 2015] uucico: only a select few tactics actually create true subproofs. off the top of my head [abstract] and [Program] facilities are the only ones I can think of. [Mon Feb 9 21:50:48 2015] jrw: i thought so too, but then i got this proof that uses only [intuition] and somehow creates a _subproof term.. [Mon Feb 9 21:52:07 2015] uucico: [intuition] is short for [intution auto with *], so it's possible that you have a hint that's causing this. for example [Hint Extern _ => abstract omega.] is a common thing to do [Mon Feb 9 21:53:18 2015] oh, good point, that might explain it.. [Mon Feb 9 21:53:49 2015] is there any way to inline the proofs that [abstract] constructs? [Mon Feb 9 21:56:22 2015] uucico: not that I know of. why is this important to you? [Mon Feb 9 22:01:40 2015] i'm trying to build proofs in parallel, in a system where there are many theorems per file, and where individual proof scripts take a very long time (minutes), but the final [Qed] is much faster. so the tentative plan is to spawn a separate coqtop process to run the proof script for each proof, and use [Show Proof] at the end to dump the raw proof term. then put all raw proof terms back together for a (hopefully faster) compilation and [Mon Feb 9 22:02:01 2015] this actually mostly works, except in a few cases i get proof terms containing references to these abstracted subproofs [Mon Feb 9 22:26:57 2015] uucico: is this related to coq 8.5's parallel proof checking features? [Mon Feb 9 22:31:32 2015] unrelated. i use parallel proof checking in coqide (where it works pretty well), but using [coqc -quick] doesn't seem to produce the expected result (i.e., [coqc -quick] takes about as long as [coqc] itself). it might be because i'm using modules, and async proofs are not compatible with modules. furthermore, since individual proofs are checked at dev time in coqide anyway, one benefit of full compilation is universe checking, which 8 [Tue Feb 10 08:34:46 2015] can I use {measure ...} in the refine-tactic? [Tue Feb 10 12:41:32 2015] what's a good guide for using Acc? [Tue Feb 10 12:51:20 2015] vanila: CPDT has some stuff on it. [Tue Feb 10 12:55:45 2015] I've yet to development an intuition for Acc [Tue Feb 10 12:56:12 2015] I'm trying with Program Fixpoint and measure but I can't get a functional induction scheme, so I can't prove anything about the function [Tue Feb 10 12:56:23 2015] can you show me the function? [Tue Feb 10 12:56:48 2015] http://lpaste.net/120292 [Tue Feb 10 12:57:19 2015] you could use a double-induction principle [Tue Feb 10 12:57:20 2015] one sec [Tue Feb 10 12:57:46 2015] i think if i switch to acc i can easily do the proper induction scheme, but it's so much work setting Acc up [Tue Feb 10 12:58:01 2015] (especially since I havent done it in forever) [Tue Feb 10 12:58:01 2015] in ssreflect they have one called seq2_ind [Tue Feb 10 12:59:20 2015] seq2_ind looks a little different - but it gives me an idea: I'll try to just prove the induction scheme manually like they have there [Tue Feb 10 13:01:27 2015] aha, found it [Tue Feb 10 13:01:30 2015] https://gist.github.com/10291895f72b5799bc0a [Tue Feb 10 13:01:39 2015] it's like more than you need, so you can delete out the "index" part [Tue Feb 10 13:01:51 2015] and I don't think you'll need the witness either [Tue Feb 10 13:01:59 2015] but anyone, as you can see it's a very simple principle to write [Tue Feb 10 13:02:12 2015] anyway* [Tue Feb 10 13:02:42 2015] oh, duh [Tue Feb 10 13:02:46 2015] I may be misunderstanding but I don't think I can apply that lemma directly [Tue Feb 10 13:02:48 2015] forget that, it was an old version of that function [Tue Feb 10 13:02:52 2015] ill definitely try to follow along those lines though [Tue Feb 10 13:03:01 2015] you need to apply it with "induction using ..." [Tue Feb 10 13:03:33 2015] so, the idea is that if your induction principle takes two lists as arguments, with the initial requirement that they be the same length, then it walks them in lock-step [Tue Feb 10 13:03:57 2015] in my case one of the two lists always gets smaller [Tue Feb 10 13:04:00 2015] but it could be any one of them [Tue Feb 10 13:04:05 2015] oh, I see [Tue Feb 10 13:04:10 2015] an either or scenario [Tue Feb 10 13:04:13 2015] but ill prove an induction scheme like that and try it out [Tue Feb 10 13:04:31 2015] it's a bit weird how Program stops you getting a functional induction scheme, I thought it generated them for you [Tue Feb 10 13:04:42 2015] you can also try with Function instead [Tue Feb 10 13:04:58 2015] although it's a bit stricter about the syntax to "measure" [Tue Feb 10 13:05:10 2015] That gives me: Error: Recursive argument must be specified -- maybe if I tuple the parameters together it will work [Tue Feb 10 13:07:26 2015] oh... Function gives me: Warning: Cannot define principle(s) for intp [Tue Feb 10 13:07:48 2015] http://lpaste.net/120293 [Tue Feb 10 13:09:14 2015] I can live with that [Tue Feb 10 13:09:35 2015] you should be able to manually define that principle if you need it [Tue Feb 10 13:09:42 2015] yeah im doing that now [Tue Feb 10 13:09:51 2015] it's a bit of a hassle trying to actually do anything with Coq :p [Tue Feb 10 13:09:56 2015] hahaha [Tue Feb 10 13:10:01 2015] all depends on what you're trying to do! [Tue Feb 10 13:10:11 2015] fancy recursion is in general tough [Tue Feb 10 13:11:49 2015] ahh [Tue Feb 10 13:12:00 2015] I understand why it can't generate a functional induction scheme automatically [Tue Feb 10 13:12:09 2015] why? [Tue Feb 10 13:13:18 2015] it can't take into account lt_eq_lt_dec [Tue Feb 10 13:13:24 2015] ahh [Tue Feb 10 13:13:43 2015] so there's multiple ways to build up any two lists, that's not true though if the constraints i have are enforced [Tue Feb 10 13:18:14 2015] http://lpaste.net/120296 it's not liking this [Tue Feb 10 13:19:12 2015] fanceh [Tue Feb 10 13:52:18 2015] got it [Tue Feb 10 18:18:45 2015] johnw: does LinearScan provide a way to specify the number of registers that you have to allocate from? [Tue Feb 10 18:20:52 2015] I'm reading up on it, and I'm a bit confused. Can I just say "I have these 64 registers to allocate from, transform my references into physical registers / spills?" [Tue Feb 10 18:21:35 2015] I notice that the Coq code https://github.com/jwiegley/linearscan/blob/master/Allocate.v has "maxReg", but I'm not sure how that's exposed Haskell side? [Tue Feb 10 18:21:48 2015] chirpsalot: hi [Tue Feb 10 18:21:57 2015] chirpsalot: yes, 0.3.0.0 will [Tue Feb 10 18:22:02 2015] it's now a parameter to the allocate function [Tue Feb 10 18:22:30 2015] johnw: ooooh, okay, so the hackage version is a bit out of date with respect to that :). [Tue Feb 10 18:22:37 2015] Awesome! [Tue Feb 10 18:22:39 2015] right, I'm hard at work on the next version [Tue Feb 10 18:22:45 2015] hoping to have it out this week [Tue Feb 10 18:22:59 2015] it will also be pretty much feature complete, missing just most optimizations [Tue Feb 10 18:23:59 2015] Good to know. This is a really awesome project! I'm hoping to use it in a toy MIPS DSL. [Tue Feb 10 18:26:59 2015] awesome! I would love to know how it works out for you [Tue Feb 10 18:27:18 2015] I've gotten it intergrated into our compiler at work, but I discovered that lifetime allocation was not fine-grained enough, so that's what I'm working on now [Tue Feb 10 18:27:36 2015] Oh, bleh, I was also looking at version 0.1. Looks like it has grown a bit in 0.2 ;). [Tue Feb 10 18:27:53 2015] and will again in 0.3 [Tue Feb 10 18:27:57 2015] also, the interface is changing a fair bit [Tue Feb 10 18:28:01 2015] so beware [Tue Feb 10 18:28:12 2015] what is your graph representation? Are you using Hoopl? [Tue Feb 10 18:28:18 2015] Changing a bit for 0.3? [Tue Feb 10 18:28:34 2015] yes, changing quite a bit for 0.3 [Tue Feb 10 18:29:02 2015] if you want to get a leg up on the UI changes, I'd recommend building the GitHub version, even though it won't work yet [Tue Feb 10 18:29:23 2015] (i.e., it fails tests and won't allocate anything, but that's soon to be remedied) [Tue Feb 10 18:30:19 2015] johnw: I'm looking into Hoopl. The DSL is basically going to be straight MIPS assembly, but with register allocation so I don't have to think about it. Basically a poor man's LLVM. [Tue Feb 10 18:30:41 2015] Hoopl just makes it easy to manage block ordering [Tue Feb 10 18:30:56 2015] it uses GADTs to enforce the graph shape at compile-time [Tue Feb 10 18:30:59 2015] So I was also thinking of just generating your BlockInfo types and stuff. [Tue Feb 10 18:31:03 2015] and block labels to determine control flow [Tue Feb 10 18:31:09 2015] ah, I don't use those anymore :) [Tue Feb 10 18:31:22 2015] now BlockInfo is a collection of functions to abstract the representation [Tue Feb 10 18:31:40 2015] my tests use Hoopl, so there's an example there not only of how to use Hoopl [Tue Feb 10 18:31:50 2015] but I even have a Free monad based DSL for writing assembly code in do notation :) [Tue Feb 10 18:32:21 2015] see test/Main.hs [Tue Feb 10 18:32:38 2015] I intend to break out the Hoopl stuff into a separate linearscan-hoopl library [Tue Feb 10 18:32:42 2015] to make it easier for just your scenario [Tue Feb 10 18:33:36 2015] Okay. So, I should really look into Hoopl more! Good to know, thank you! [Tue Feb 10 18:34:07 2015] I think it's worth the investment, plus with my examples you shouldn't have too hard a time of it [Tue Feb 10 18:36:50 2015] Yeah, I was looking at tempest a bit already :). I'll have to finish going through the Hoopl papers. Thanks! [Wed Feb 11 02:52:14 2015] does coqide even work? should i figure out why it crashes or does nothing? what else should I use? [Wed Feb 11 02:59:59 2015] (this is on macosx) [Wed Feb 11 03:00:33 2015] you mean in general? yes it should work [Wed Feb 11 03:01:11 2015] I don't run it on OS X though [Wed Feb 11 03:02:02 2015] whats the problem with os x? [Wed Feb 11 03:02:49 2015] (seems polished enough to work in general, though maybe a buggy version was released or something0 [Wed Feb 11 03:04:00 2015] *thought [Wed Feb 11 03:04:33 2015] I don't know, I haven't tried it on OS X [Wed Feb 11 03:04:40 2015] sorry :-< [Wed Feb 11 03:04:51 2015] yeah, misparsed you until just now [Wed Feb 11 03:04:54 2015] it uses GTK which should not be problematic on OS X though [Wed Feb 11 03:05:26 2015] I just cant get it to Check 0. [Wed Feb 11 03:13:22 2015] i must be very confused.. have the same problem with linux/ubuntu version, exxcept now, coqide has no documentation to not give me [Wed Feb 11 03:20:40 2015] one person seems to cuggest proof general is better [Wed Feb 11 03:22:35 2015] suggest [Wed Feb 11 03:22:39 2015] (wow) [Wed Feb 11 03:27:54 2015] hmm..http://web.cecs.pdx.edu/~apt/coq_hints.html seems good [Wed Feb 11 03:37:00 2015] oh, got it to do something.. the gui is very clunky [Wed Feb 11 03:43:32 2015] wagle: for me, coqide has trouble finding coqtop, but once the setting is correct, it seems to work. [Wed Feb 11 03:43:39 2015] mostly i use proof general, though [Wed Feb 11 03:44:20 2015] (this is coqide 8.4pl5 on os x) [Wed Feb 11 03:44:22 2015] yeah, its the path, i think.. i'm switching to PG [Wed Feb 11 03:44:49 2015] the launcher doesnt really set much in the PATH [Wed Feb 11 03:45:25 2015] s/set/put [Wed Feb 11 03:46:01 2015] thanks [Wed Feb 11 19:23:54 2015] http://coq-blog.clarus.me/a-blog-engine-written-and-proven-in-coq.html [Wed Feb 11 21:23:19 2015] yes, but is it provable that folks won't get offended at a name like chickblog? [Wed Feb 11 21:24:27 2015] clearly the author missed a chance at naming it 'nugget' -- easily digestible content [Wed Feb 11 21:25:10 2015] ayy [Thu Feb 12 04:50:11 2015] chirpsalot: ping [Thu Feb 12 11:00:41 2015] johnw: version 0.3 up? :) [Thu Feb 12 11:01:08 2015] Or working, rather? [Thu Feb 12 12:37:30 2015] I have a Definition that says A = B. In my proof, I currently have A = B, so I can just write reflexivity. [Thu Feb 12 12:37:44 2015] But it would be nicer I feel if I could rewrite it so it said "B = B" based on my Definition [Thu Feb 12 12:37:49 2015] How could I do that? [Thu Feb 12 12:39:18 2015] Ah. fold/unfold [Thu Feb 12 13:30:37 2015] chirpsalot: almost [Thu Feb 12 14:11:11 2015] how do i turn a positive nat into a positive [Thu Feb 12 14:11:14 2015] alternatively [Thu Feb 12 14:11:19 2015] how do i do pattern matching on positives [Thu Feb 12 14:19:27 2015] benzrf: what kind of pattern matching? [Thu Feb 12 14:19:40 2015] I assume [match p with ... end] isn't what you're looking for [Thu Feb 12 14:39:26 2015] jrw: that works too [Thu Feb 12 14:39:31 2015] but [Thu Feb 12 14:39:44 2015] basically i want to do natural-style induction [Thu Feb 12 14:39:54 2015] and the actual ctors are arabic [Thu Feb 12 14:39:55 2015] benzrf: there's a lemma for that [Thu Feb 12 14:39:59 2015] er, place-value [Thu Feb 12 14:40:06 2015] jrw: what is [Thu Feb 12 14:40:10 2015] one sec [Thu Feb 12 14:40:19 2015] to be precise [Thu Feb 12 14:40:29 2015] i want to define the harmonic sequence and then its sequence of partial sums [Thu Feb 12 14:40:35 2015] actually, i think it'd be simpler to just convert a nat into a positive [Thu Feb 12 14:42:03 2015] I'm still confused what you're trying to do. but if you [SearchAbout positive] and then look for "peano" [Thu Feb 12 14:42:18 2015] you should get an induction principle that uses the successor function on positives [Thu Feb 12 14:42:21 2015] not sure if this is what you want [Thu Feb 12 14:42:58 2015] oh good :-) [Thu Feb 12 18:45:12 2015] hey [Thu Feb 12 18:46:04 2015] how do i prove 'shift_nat (log2 n) 2 <= Pos.of_nat (S n)' [Thu Feb 12 18:46:37 2015] hm, < even [Thu Feb 12 21:03:37 2015] argh [Thu Feb 12 21:16:51 2015] help please ;-; [Thu Feb 12 21:54:15 2015] please. how do i prove 'shift_nat (log2 n) 2 <= Pos.of_nat (S n)' [Fri Feb 13 01:32:22 2015] chirpsalot: ping [Fri Feb 13 09:25:01 2015] hmm [Fri Feb 13 09:25:30 2015] how do i turn "1#x <= 1#y" into "x >= y" [Fri Feb 13 09:25:40 2015] i tried SearchAbout but didnt see such a lemma [Fri Feb 13 10:04:28 2015] Because it isn't true I guess? [Fri Feb 13 10:05:21 2015] Multiply both sides by x and y and you will find what you want (but only if x and y have the same sign) [Fri Feb 13 10:08:30 2015] oh, x and y must be both positive, so it's true [Fri Feb 13 10:37:55 2015] benzrf: it's easy to prove (once I figured where all the definitions where): unfold Qle. simpl. simpl_mult. repeat rewrite Zmult_1_r. intros. assumption. [Fri Feb 13 10:40:43 2015] Ah no, intros must come first. [Fri Feb 13 10:55:32 2015] ew [Fri Feb 13 10:55:38 2015] how do i multiply both sides? [Fri Feb 13 10:56:08 2015] also what tactic for obviously true ineqs, like "x < x + 1" [Fri Feb 13 11:00:08 2015] turns out that's already the definition of <= for rationals, so just unfold the definition [Fri Feb 13 11:02:36 2015] for your second question, I don't know I've really only worked with nat (I'm new to Coq) [Fri Feb 13 11:05:39 2015] benzrf: I use omega [Fri Feb 13 11:09:45 2015] http://lpaste.net/120468 [Fri Feb 13 11:12:42 2015] ianjneu: ah yes [Fri Feb 13 11:21:20 2015] is there a comand to view docu on a tacctic [Fri Feb 13 13:34:39 2015] benzrf: it's even simpler 1#x <= 1#y -> (' y <= ' x)%Z is solved just by saying assumption. so you only have to prove that y <= x -> x >= y [Fri Feb 13 13:36:41 2015] oh how nice [Fri Feb 13 15:52:06 2015] What is the shortest way to "match on a predicate" ? [Fri Feb 13 15:52:11 2015] Choups314: explain [Fri Feb 13 15:52:34 2015] For example, if I have a variable x of type R, I want a match like : [Fri Feb 13 15:53:26 2015] First case if [predicate1 x] is True, second case if [predicate2 x] is True and so on .. [Fri Feb 13 15:53:33 2015] (It's not clear ...) [Fri Feb 13 15:53:59 2015] A kind of If .. else if .. else .. but in a definition [Fri Feb 13 15:54:13 2015] (And the conditions are predicates on the variable [x]) [Fri Feb 13 15:55:12 2015] Choups314: predicate1 : XType -> bool? [Fri Feb 13 15:55:47 2015] XType -> Prop [Fri Feb 13 15:57:14 2015] I thought I could use an extra inductive type, with one constructor for each predicates [Fri Feb 13 15:57:24 2015] And then match on this type in the definition [Fri Feb 13 15:57:52 2015] But I think it's quite .. *heavy* [Fri Feb 13 16:14:45 2015] In other words, is it possible to build an object (of an inductive type) depending on the value of a variable ? (i.e. choose the constructor according to a variable value) [Fri Feb 13 16:37:16 2015] Is it possible to do somethink like this : http://pastebin.com/0ngvi4de ? [Fri Feb 13 16:37:28 2015] (It complains : Error: This clause is redundant.) [Fri Feb 13 16:54:49 2015] that may be because of the types of P1 x and P2 x [Fri Feb 13 16:55:03 2015] i.e., pattern matching is revealing enough information that it knows one of the cases cannot happen [Fri Feb 13 17:52:08 2015] "From the sounds of it, Coq isn’t quite what I’m really looking for. I might try out some of those really simple proofs you’re talking about to get a feel for it and then move onto learning more about SMT and Idris. [Fri Feb 13 17:52:08 2015] Software verification is definitely the goal, for me :)" [Fri Feb 13 17:52:25 2015] johnw: pong! [Fri Feb 13 18:16:41 2015] this is crazy isnt it? [Fri Feb 13 18:16:57 2015] why do people think you coq isn't the tool for verifying software... [Fri Feb 13 18:23:16 2015] vanila: they might expect something easier or more automated to do it for them [Fri Feb 13 18:59:19 2015] is there a way to get docu on tactics from coqtop [Fri Feb 13 18:59:28 2015] also is there a way to search for what a notation means [Fri Feb 13 19:48:46 2015] benzrf: you can use [Locate "<="] to find notations [Fri Feb 13 19:49:00 2015] coqtop doesn't give live documentation as far as I know [Fri Feb 13 19:49:07 2015] ah thanks :) [Fri Feb 13 22:21:48 2015] jesus christ [Fri Feb 13 22:22:04 2015] ive been spending HOURS trying to prove Lemma Qle_den_ge : forall n m, (n <> 0)%nat -> (m <> 0)%nat -> (n >= m)%nat -> 1#Pos.of_nat n <= 1#Pos.of_nat m. [Fri Feb 13 22:33:48 2015] chirpsalot: heya! [Fri Feb 13 22:33:55 2015] chirpsalot: linearscan is passing tests again, I will release 0.3 tonight and then start on writing more tests [Fri Feb 13 22:38:16 2015] anyone use prooftree? I'm failing to get it to work under macosx [Fri Feb 13 22:38:17 2015] johnw: good to know! I'm working my way through Hoopl right now, and am planning on getting a start to my DSL shortly. [Fri Feb 13 22:38:48 2015] wagle: is it complaining about version differences? [Fri Feb 13 22:39:02 2015] chirpsalot: protocol 2 vs 3 [Fri Feb 13 22:40:12 2015] the error message is confusing [Fri Feb 13 22:40:39 2015] Protocol error! [Fri Feb 13 22:40:39 2015] Communication protocol mismatch. [Fri Feb 13 22:40:39 2015] Proof General uses version 02 [Fri Feb 13 22:40:39 2015] but this version of Prooftree supports version 03 [Fri Feb 13 22:40:39 2015] Closing connection. [Fri Feb 13 22:40:45 2015] eeep [Fri Feb 13 22:40:54 2015] wagle: basically proof general is expecting a different version of proof tree. The protocol doesn't match. [Fri Feb 13 22:41:09 2015] Try getting an older version of proof tree? [Fri Feb 13 22:41:19 2015] really? ok [Fri Feb 13 22:41:23 2015] Or maybe updating proof general. [Fri Feb 13 22:41:27 2015] Not sure which :). [Fri Feb 13 22:41:56 2015] lemme poke around [Fri Feb 13 22:42:12 2015] i had to work to get a modern version of prooftree [Fri Feb 13 22:42:41 2015] http://askra.de/software/prooftree/ [Fri Feb 13 22:42:44 2015] incompatible protocol change: requires Proof General >= 4.3pre130327 [Fri Feb 13 22:43:52 2015] egad. (thanks, didnt think to study that again) [Fri Feb 13 22:44:15 2015] Also "Ready to be used. Prooftree requires Proof General >= 4.3pre130327 and Coq version 8.4beta or greater. [Fri Feb 13 22:47:28 2015] wagle: if you use nix it has proofgeneral_4_3_pre and prooftree. I assume they work. [Fri Feb 13 22:47:50 2015] * has macos/yosemite [Fri Feb 13 22:48:08 2015] and homebrew [Fri Feb 13 22:48:37 2015] soon my MBP will die and I'll switch to linux for want of a matte screen [Fri Feb 13 22:48:51 2015] wagle: nix works on OSX. [Fri Feb 13 22:49:39 2015] ocaml 4 seems to have broken comments in prooftree [Fri Feb 13 22:49:49 2015] ocaml 4 seems to have broken comments in prooftree/input.ml [Fri Feb 13 22:50:02 2015] but i fixed that [Fri Feb 13 22:50:16 2015] well, hacked along it [Fri Feb 13 22:50:44 2015] o_O? [Fri Feb 13 22:51:42 2015] had three "{foo|not-foo}" like things in the comments [Fri Feb 13 22:53:59 2015] somebody please help x_x [Fri Feb 13 22:57:58 2015] ask a question that someone might be able to answer [Fri Feb 13 22:58:06 2015] i pasted it earlier ut ok: [Fri Feb 13 22:58:14 2015] how the hell do i prove Lemma Qle_den_ge : forall n m, (n <> 0)%nat -> (m <> 0)%nat -> (n >= m)%nat -> 1#Pos.of_nat n <= 1#Pos.of_nat m. [Fri Feb 13 22:58:31 2015] i think i might be able to bludgeon something out with 20 or so tactic [Fri Feb 13 22:58:34 2015] *tactics [Fri Feb 13 22:58:43 2015] but i feel like there should be something simpler than that -_- [Fri Feb 13 22:58:56 2015] "omega"? [Fri Feb 13 22:59:04 2015] i dunno, I'm still trying to setup a coq environment to do the tutorial with [Fri Feb 13 23:02:29 2015] johnw: that works on nats doesnt it [Fri Feb 13 23:02:53 2015] it's really really easy to try :) [Fri Feb 13 23:02:59 2015] i already did [Fri Feb 13 23:03:00 2015] it doesnt work [Fri Feb 13 23:17:15 2015] looking for a test program to show that prooftree works (I'm starting on the coq tutorial) [Fri Feb 13 23:19:47 2015] (it does nothing for a really simple example) [Fri Feb 13 23:28:05 2015] gotta have a "Proof." [Fri Feb 13 23:28:15 2015] so I got it to work [Sat Feb 14 06:01:20 2015] chirpsalot: you awake? [Sat Feb 14 06:32:05 2015] chirpsalot: 0.3 is released [Sat Feb 14 06:32:10 2015] and is now feature complete [Sat Feb 14 06:32:32 2015] next I begin documenting and testing toward the 1.0 release [Sat Feb 14 09:55:31 2015] How to deal with hypothesis like : [H : forall (x:T), match x with : | c1 => ... | c2 => ... end] ? [Sat Feb 14 09:55:41 2015] Is there way to "destruct" it ? [Sat Feb 14 09:58:18 2015] Choups314 : what you can destruct is (H x) for some x of type T [Sat Feb 14 09:58:49 2015] Ah wait, that's a match. [Sat Feb 14 09:58:57 2015] Yeah :/ [Sat Feb 14 09:59:00 2015] Sorry, you cannot destruct a match, you just simply it [Sat Feb 14 09:59:09 2015] How ? [Sat Feb 14 09:59:24 2015] With the other hypothesis, only one constructor is possible [Sat Feb 14 09:59:41 2015] But I don't know how to eliminate the others [Sat Feb 14 09:59:42 2015] So, if you do have (x:T) in your hypotheses, you can do something like [pose proof (H x) as H'. simpl in H'.] [Sat Feb 14 09:59:58 2015] Ah. Not [simpl in H'.], rather [destruct x.], if you have to [Sat Feb 14 10:00:00 2015] (sorry) [Sat Feb 14 10:00:30 2015] Wait, I'll pastebin the definition ;) [Sat Feb 14 10:00:36 2015] ok [Sat Feb 14 10:00:39 2015] (very simple one) [Sat Feb 14 10:03:01 2015] Cypi : http://pastebin.com/KWQXLWkA [Sat Feb 14 10:03:56 2015] (The definition may seems weird, but it is the only way I found to "match on a predicate") [Sat Feb 14 10:05:18 2015] Cypi Sorry, typo : http://pastebin.com/ufLzaJZ8 [Sat Feb 14 10:05:48 2015] So I would like to simplify H0 with (* stuff 1 *). Is it possible ? [Sat Feb 14 10:07:22 2015] Yes: pose proof (H0 (pInf x H1)) as blah; simpl in blah [Sat Feb 14 10:10:03 2015] Cypi: Thanks a lot :) [Sat Feb 14 10:45:05 2015] Is it possible to hide an hypothesis ? [Sat Feb 14 11:01:29 2015] Choups314 : you can clear it [Sat Feb 14 11:01:34 2015] I don't know if you can hide it [Sat Feb 14 11:40:56 2015] Why would you hide it? [Sat Feb 14 11:58:24 2015] clear is what I wanted ;) [Sat Feb 14 12:06:33 2015] Choups314: Doing Coq for school or interest? [Sat Feb 14 12:06:44 2015] both ^^ [Sat Feb 14 12:06:50 2015] Not really for school [Sat Feb 14 12:07:04 2015] But I do what I do in school in coq [Sat Feb 14 12:07:05 2015] :p [Sat Feb 14 12:07:08 2015] (I try ^^) [Sat Feb 14 12:07:41 2015] Cool. What are you doing in school? [Sat Feb 14 12:07:52 2015] (Which can be translated to Coq) [Sat Feb 14 12:07:59 2015] Math [Sat Feb 14 12:08:08 2015] I am in a french prep school [Sat Feb 14 12:08:19 2015] Coolio. [Sat Feb 14 12:08:38 2015] I got a better understand about math by taking a course on Coq. [Sat Feb 14 12:08:48 2015] Granted, I was pretty bad at math before that :P [Sat Feb 14 12:09:00 2015] ^^ [Sat Feb 14 12:09:31 2015] For now, the hard point for me is to translate what I know into Coq [Sat Feb 14 12:09:53 2015] Choups314 at my time, we just discovered caml light in prepa..... times change ! [Sat Feb 14 12:10:04 2015] Nop :) [Sat Feb 14 12:10:15 2015] We are still discovering caml there :p [Sat Feb 14 12:10:33 2015] Choups314 if you do things in coq you are ahead of your comrades then ;) [Sat Feb 14 12:10:46 2015] (Coq is not at all in the sylabus ;) ) [Sat Feb 14 12:10:52 2015] Yes, I hope :D [Sat Feb 14 12:11:21 2015] Do you know if there is a "way" to generate a "free" hypothesis name ? [Sat Feb 14 12:11:35 2015] (In a Ltac, I need "temporary" steps) [Sat Feb 14 12:12:06 2015] Anarchos: Now it's ocaml ;) [Sat Feb 14 12:12:19 2015] Choups314 yes there is a way to change the hypothesis name [Sat Feb 14 12:12:43 2015] never touched to Ltac though … [Sat Feb 14 12:12:54 2015] I mean, generate a "random" name, just for the internal work of the Ltac [Sat Feb 14 12:13:20 2015] Choups314 not found something in the manual ? [Sat Feb 14 12:13:50 2015] I don't really know what to look for .. a tactic ? oO [Sat Feb 14 12:15:12 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html maybe there ? [Sat Feb 14 12:15:43 2015] intro ident [Sat Feb 14 12:15:44 2015] This applies intro but forces ident to be the name of the introduced hypothesis. [Sat Feb 14 12:16:29 2015] Anarchos, Exactly, I would like "something" to generate this *ident* [Sat Feb 14 12:16:33 2015] or this one : http://stackoverflow.com/questions/22404394/how-to-automatically-generate-good-names-when-decomposing-existential-hypothes [Sat Feb 14 12:17:39 2015] let h := fresh "h" in idtac h; intros h; [Sat Feb 14 12:17:56 2015] it seems that «fresh» can do the job... [Sat Feb 14 12:18:56 2015] Yes ! perfect :) [Sat Feb 14 12:20:08 2015] Here is what I'm doing with Coq : https://github.com/Choups314/SAMPL [Sat Feb 14 12:21:05 2015] (It's still quite a mess because I started using CoRN, but I have finally stopped ..) [Sat Feb 14 12:21:54 2015] Choups314 good luck :) [Sat Feb 14 12:22:02 2015] Thanks ;) [Sat Feb 14 12:22:14 2015] i work at a lower level : just coding a proof verifier, not in coq, but in ocaml. [Sat Feb 14 12:22:55 2015] To work with Coq ? [Sat Feb 14 12:23:08 2015] (I am really new with caml) [Sat Feb 14 12:23:19 2015] no a standalone verifier . [Sat Feb 14 12:36:54 2015] Is it possible to concatenate strings when displaying a message with idtac ? [Sat Feb 14 12:37:07 2015] (This is probably too python-like) [Sat Feb 14 12:37:38 2015] (i.e. For example to concatenate a string and an hypothesis name) [Sat Feb 14 12:59:57 2015] Hello. Given a Type, how does coq find its induction? Can someone point me to the algorithm or its implementation? [Sat Feb 14 14:10:59 2015] Choups314 let me know if you found how to concatenate ! [Sat Feb 14 14:11:43 2015] Anarchos: I guess it is possible in caml, but I'm still searching for Ltac [Sat Feb 14 14:19:37 2015] sure it is for caml : it is the « ^ » operator [Sat Feb 14 14:35:56 2015] Choups314 and good luck for your first year of CPGE... [Sat Feb 14 14:40:15 2015] Thanks :p [Sat Feb 14 14:40:38 2015] I guess you were in too ? [Sat Feb 14 14:44:31 2015] Choups314 95/96 & 96/97 [Sat Feb 14 16:38:18 2015] [exists (x:R), x >= 0 -> ...] does not mean http://latex.codecogs.com/gif.latex?%5Cexists%20x%20%5Cin%20%5Cmathbb%7BR%7D%5E+ right ? [Sat Feb 14 16:38:34 2015] (If we consider that [R] is the type for real numbers) [Sat Feb 14 16:41:11 2015] I mean, I'm not sure of the [exists], because when I have an hypothesis [H : exists x:R, x>0 -> ..] I can't destruct it properly [Sat Feb 14 17:01:01 2015] First of all, you might want to take a look at sig instead of ex, if you want to extrace the value inside H to compute something [Sat Feb 14 17:01:32 2015] Then, to expresse what you meant, it would probably be something like [exists (x:R), x >= 0 /\ ...] [Sat Feb 14 17:02:02 2015] (but then again, you might want instead [{x : R | x >= 0 /\ ... }] [Sat Feb 14 17:02:03 2015] ) [Sat Feb 14 17:03:13 2015] extract* [Sat Feb 14 17:07:45 2015] johnw: congrats! Nicely done :). [Sat Feb 14 17:08:59 2015] Cypi: Thank you ! That's what I was looking at in the CoRN sources .. [Sat Feb 14 17:10:00 2015] With an hypothesis [H : exists x:R, x>0 -> ..], it would allow me to "destruct" it as [H1 : x H2 : x>0 H3 : ...] ? [Sat Feb 14 17:15:00 2015] If your goal is in Prop, then you can destruct H to get this, indeed. [Sat Feb 14 17:15:13 2015] If your goal is in Set (or Type), then you won't be able to do so [Sat Feb 14 17:15:44 2015] If H is instead {x : R | x >= 0 /\ ... }, then you should be able to destruct it in the later case, though. [Sat Feb 14 18:22:48 2015] Could someone help me understand the difference between these two definitions: http://lpaste.net/120526 [Sat Feb 14 18:25:19 2015] arbelos: https://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Sat Feb 14 18:27:04 2015] benzrf: thanks. I wasn't sure what to search for [Sat Feb 14 18:27:27 2015] no problem :) [Sat Feb 14 18:27:38 2015] good questoin [Sat Feb 14 18:27:42 2015] *question [Sat Feb 14 18:33:35 2015] So my first type there, u.. fails when I try to implement functions that pattern match on the constructor, like "concat". [Sat Feb 14 18:36:57 2015] but let me read the answer on SO properly ... [Sun Feb 15 01:14:14 2015] chirpsalot: thanks [Sun Feb 15 01:14:33 2015] chirpsalot: it still doesn't allocate for all our compiler's test programs, so I will be looking into that later tonight [Sun Feb 15 01:54:28 2015] johnw: awesome. I'm slowly working my way through Hoopl and such. It does more with the Haskell type system than I knew about, so I have been getting somewhat distracted :). [Sun Feb 15 16:00:31 2015] hello [Sun Feb 15 16:00:41 2015] I want to prove that `e = e'` [Sun Feb 15 16:00:54 2015] intro e; exact e. [Sun Feb 15 16:01:04 2015] to do that I want to do a intermediate step `e = prod e e'` and `prod e e' = e'` [Sun Feb 15 16:01:09 2015] should do the trick ? [Sun Feb 15 16:01:29 2015] let me try [Sun Feb 15 16:01:39 2015] you can use the transitivity tactic [Sun Feb 15 16:02:16 2015] vanila: ah that's exactly what I looked for [Sun Feb 15 16:02:17 2015] thanks [Sun Feb 15 16:06:21 2015] i may say «auto», but … [Sun Feb 15 16:09:17 2015] Anarchos: would auto do that automatically? [Sun Feb 15 16:09:35 2015] heinrich5991 i hope auto is able to prove e=e.... [Sun Feb 15 16:10:15 2015] after I applied a relevant property to `e = prod e e'`, it already finished the proof. [Sun Feb 15 16:15:56 2015] Anarchos: or just "exact". [Sun Feb 15 16:16:20 2015] johnw my coq skill is a bit rusty. [Sun Feb 15 16:16:33 2015] I may be thinking of the ssreflect version too [Sun Feb 15 16:17:07 2015] how can I define a inverse function for groups? [Sun Feb 15 16:17:23 2015] (I already have the relevant axiom, prod_inverse [Sun Feb 15 16:17:38 2015] : forall x : G, exists y : G, prod x y = e. [Mon Feb 16 00:46:38 2015] What's the corret <= for int? [Mon Feb 16 00:46:41 2015] *correct [Mon Feb 16 00:47:11 2015] hmm...should I have said "hi" first? [Mon Feb 16 00:47:21 2015] hi! [Mon Feb 16 00:48:25 2015] yes [Mon Feb 16 00:48:35 2015] what's the correct <= for int? [Mon Feb 16 00:48:42 2015] I don't know [Mon Feb 16 00:49:34 2015] it's stupid. I'm following the tutorial for why3 and got stuck [Mon Feb 16 00:49:50 2015] * wonders if there's a coq paste bin [Mon Feb 16 11:57:43 2015] what's the difference between destruct, induction and case? [Mon Feb 16 11:57:47 2015] I feel like they do the same thing [Mon Feb 16 11:58:43 2015] kba: when you define an inductive datatype, Coq creates both dependend and non-dependent eliminators. Induction uses the former, destruction uses the latter. [Mon Feb 16 12:00:16 2015] I thought both destruct and induction were dependent.. but you just don't get induction hyps from destruct [Mon Feb 16 12:00:45 2015] ianjneu: What are eliminators? [Mon Feb 16 12:01:27 2015] It's so difficult to learn Coq, I can't just google "coq eliminators" and get an explanation like with any other language [Mon Feb 16 12:01:35 2015] kba: all types have ways to form elements of the type, introduction rules, and ways to use elements of the type, elimination rules. [Mon Feb 16 12:02:16 2015] I'm not sure what that means. What are the introduction rules and eliminators of the natural numbers? [Mon Feb 16 12:02:16 2015] roughly, "eta rules" mean elim . intro = identity [Mon Feb 16 12:04:01 2015] 0 introduces the zero. S n introduces the sucessor of n. The non-dependent eliminator is nat_fold : forall A : Type, A -> (nat -> A -> A) -> nat -> A. [Mon Feb 16 12:04:52 2015] roughly. I'm still a little groggy. [Mon Feb 16 12:04:56 2015] oh yeah, you're right [Mon Feb 16 12:06:17 2015] Okay, I understand the introduction rules, but not the eliminator. For some type A, ... [Mon Feb 16 12:08:51 2015] Ya I wrote that wrong. Go into coqtop and Print nat_rect. [Mon Feb 16 12:09:09 2015] That gives nothing [Mon Feb 16 12:09:18 2015] Require Import ZArith. first [Mon Feb 16 12:09:22 2015] Ah. . [Mon Feb 16 12:59:44 2015] Hey ! [Mon Feb 16 12:59:44 2015] Is it possible to prove a contradiction if I have an hypothesis [H : ~ P x], where P is predicate and another hypothesis [H1 : forall (Hx : P x), ..] ? [Mon Feb 16 13:00:04 2015] I mean, transform H4 into False [Mon Feb 16 13:00:08 2015] hi Choups314 [Mon Feb 16 13:00:17 2015] Hi :) [Mon Feb 16 13:00:49 2015] elimtype False. [Mon Feb 16 13:00:49 2015] intro H1. intro. contradiction H. [Mon Feb 16 13:00:54 2015] then apply (H H1). [Mon Feb 16 13:17:29 2015] It's my fault (I didn't write enought), but I have other premises after [forall (Hx : P x), ...] in H1 .. So these tactics don't work :( [Mon Feb 16 13:17:49 2015] (It took time to understand ^^) [Mon Feb 16 13:20:24 2015] what I said does not work? [Mon Feb 16 13:20:56 2015] It works if H1 is just [H1 : P x] [Mon Feb 16 13:21:14 2015] ahhh [Mon Feb 16 13:21:36 2015] if you have ~ P x, and P x -> Q, that does't imply Q [Mon Feb 16 13:21:42 2015] because we don't have excluded middle [Mon Feb 16 13:21:59 2015] Let's assume we have it as an axiom ;) [Mon Feb 16 13:22:16 2015] (It's just a hobby proof) [Mon Feb 16 13:22:53 2015] For example https://gist.github.com/Choups314/0b7785403d9bac8e5f33 [Mon Feb 16 13:23:42 2015] Is it possible to finish the proof ? [Mon Feb 16 13:24:02 2015] (If we assume classical logic axioms) [Mon Feb 16 13:24:17 2015] with LEM, ~ P x gives you P x, which lets you get Q [Mon Feb 16 13:24:33 2015] (forall (Hx: P x), 1) I do not think this is well kinded [Mon Feb 16 13:25:03 2015] maybe Variable Q:Prop, then use (forall (Hx: P x), Q) instead [Mon Feb 16 13:26:33 2015] The fact that [forall (Hx: P x)] has no witness cannot be used ? [Mon Feb 16 13:26:42 2015] (To prove False) [Mon Feb 16 13:27:29 2015] I don't understand sorry [Mon Feb 16 13:28:16 2015] you can prove this: X -> ~ X -> False [Mon Feb 16 13:30:57 2015] In fact I have a proof that looks like this https://gist.github.com/Choups314/9184ae51d8844f2ade2e (i.e. I don't have 2=2, but another predicate that requires Hx). But I'm not sure if I can finish the proof only with these hypothesis [Mon Feb 16 13:32:18 2015] this isn't true [Mon Feb 16 13:32:30 2015] you wont be able to prove it [Mon Feb 16 13:50:30 2015] Im' proving some stuff about even/odd numbers, and in the process I end up with an assumption "H_n : False". Right now, I'm doing: apply (False_ind (1 = 2)) in H_n. discriminate H_n. [Mon Feb 16 13:50:32 2015] Which is ugly. [Mon Feb 16 13:50:49 2015] Can I somehow do that nicer? It seems stupid that I have H_n : False, and then I just can't "discriminate H_n." [Mon Feb 16 13:51:01 2015] but that I have to rewrite it into something silly like 1 = 2 before I can discriminate. [Mon Feb 16 13:51:09 2015] [destruct H_n] and [exfalso; assumption] will both work. [Mon Feb 16 13:52:56 2015] exfalso just gives me "False" as my subgoal [Mon Feb 16 13:53:15 2015] destruct H_n gives me 3 other assumptions [Mon Feb 16 13:54:55 2015] Oh, no, never mind. Thanks, jgross [Mon Feb 16 13:55:57 2015] if I just write "destruct H_n." it all goes away [Mon Feb 16 13:56:09 2015] not sure I understand why, though [Mon Feb 16 13:58:49 2015] If you have a hypothesis [H_n : False], then you can solve a subgoal of type [False]. [Mon Feb 16 13:59:32 2015] Regarding [destruct H_n], you are doing case analysis on your proof of [False]. How many ways (cases) are there to prove [False]? (You can print them all with [Print False.]) [Mon Feb 16 13:59:36 2015] Okay, but writing `destruct H_n` just solves it automatically [Mon Feb 16 14:00:29 2015] You can't prove False, I presume? [Mon Feb 16 14:00:38 2015] Also since Print False. gives me nothing [Mon Feb 16 14:00:57 2015] Right. There are zero cases. So when you do case analysis, you have zero cases to consider. [Mon Feb 16 14:01:10 2015] Ah! Of course [Mon Feb 16 14:01:15 2015] Thanks :) [Mon Feb 16 14:01:24 2015] No problem :-) [Mon Feb 16 14:02:35 2015] Now you inspired me to do "Print True." and I get Inductive True : Prop := I : True [Mon Feb 16 14:02:42 2015] What does I mean? [Mon Feb 16 14:02:54 2015] Something of type True? [Mon Feb 16 14:03:27 2015] Or is it like identity? [Mon Feb 16 14:03:36 2015] Since proving True is done by just... True [Mon Feb 16 14:37:22 2015] kba true is a proposition and there is a proof (the « I ») of it. [Mon Feb 16 14:37:39 2015] Is "I" a proof? [Mon Feb 16 14:37:48 2015] kba remember that propositions are types of their proofs in the curry-howard correspondance [Mon Feb 16 14:47:05 2015] kba: any value is an existence proof of its type [Mon Feb 16 14:53:53 2015] So I is the proof that True is a type? Or? [Mon Feb 16 14:53:59 2015] I'm not sure I follow [Mon Feb 16 14:57:10 2015] I is the proof that True is inhabited [Mon Feb 16 14:57:30 2015] any type that is uninhabited is equal to False [Mon Feb 16 14:57:46 2015] so, if you have an inhabitant, you have a proof that your type is not False [Mon Feb 16 15:03:01 2015] Okay, that sort of makes sense, I guess. Thanks [Mon Feb 16 16:05:59 2015] johnw: types that are uninhabited are isomorphic to False, but not equal without univalence. e.g., Empty_set = False is unprovable, even though they're defined as [Inductive Empty_set : Set := . Inductive False : Prop := .] [Mon Feb 16 16:06:15 2015] jgross: ah, thank you [Mon Feb 16 16:06:28 2015] i should have said isomorphic [Mon Feb 16 19:15:42 2015] auuuuugh im going nuts [Mon Feb 16 19:16:04 2015] why is there no even close to simple way to prove Lemma Qle_den_ge : forall n m, (n >= m)%nat -> 1#Pos.of_nat n <= 1#Pos.of_nat m. [Mon Feb 16 19:16:07 2015] GOD [Tue Feb 17 05:07:05 2015] Hi, is it possible to use a previous premise in a definition ? For example with the definition : [Definition test : *premise1* -> *premise2* -> *conclusion*]. Is it possible to use a proof of *premise1* in the conclusion ? (there are all typed Prop) [Tue Feb 17 05:08:55 2015] Do you mean that you already have a proof of premise1 before that? [Tue Feb 17 05:09:40 2015] In which case you don't need to make a function of premise1, test : premise2 -> conclusion [Tue Feb 17 05:11:11 2015] No I don't have it before, but if you use the definition I would have to give the proof right ? [Tue Feb 17 05:12:04 2015] If you're going to apply test, you will apply it to a proof of premise1 indeed. [Tue Feb 17 05:13:31 2015] And there is no *workaround* to extract this proof in the conclusion ? (Still in the Definition) [Tue Feb 17 05:14:48 2015] you can do pattern matching on the proof [Tue Feb 17 05:15:20 2015] assuming there is any pattern to match [Tue Feb 17 05:15:56 2015] For example : Let's assume I'm defining [test], which depends on a variable [x:nat]. In the conclusion of [test] I need a proof that [x<>0], so I thought I could do something like : [Definition test (x:nat), x<>0 -> *conclusion*]. But then in the conclusion I need to *extract* the proof that [x<>0] (still in the definition) [Tue Feb 17 05:17:13 2015] if you start with intros x xNotZero. then when you are proving the conclusion you can make use xNotZero as many times as you like [Tue Feb 17 05:17:54 2015] *conclusion* could be something like : [concl x Hx] (with Hx the proof) and concl like : [Definition concl : forall (x:nat)(H:x<>0), x>0.] [Tue Feb 17 05:18:17 2015] Yes, but how do I write the Definition itself ? [Tue Feb 17 05:18:33 2015] I would need the "proof mode" during the definition ? [Tue Feb 17 05:19:05 2015] oh! [Tue Feb 17 05:19:13 2015] sorry, I thought it was a theorem you wre proving [Tue Feb 17 05:19:20 2015] what you can do in the definitionis [Tue Feb 17 05:19:24 2015] fun x xNotZero => .... [Tue Feb 17 05:19:34 2015] this is equivalent to the doing the intros [Tue Feb 17 05:23:05 2015] Well this works :). However, do you know if I could have a definition like : [Definition test (x:nat), x<>0 /\ *other_predicate* -> *conclusion*] ? (And still in the conclusion I need the proof that [x<>0]) [Tue Feb 17 05:26:46 2015] Probably with proj2 or proj1 lemmas .. Nevermind ;) [Tue Feb 17 05:51:15 2015] vanila : [fun .. ] works very well, but I can't use it with other predicates :/ For example I can't do : [Definition test := exists (d:nat), d > 0 /\ (fun (x:nat)(Hx:(x<>0 /\ x<> d)) => C x (proj1 Hx)) .] [Tue Feb 17 05:51:57 2015] ah [Tue Feb 17 05:52:04 2015] well maybe you woudl rather define this using tactics [Tue Feb 17 05:52:09 2015] i think it would be easier [Tue Feb 17 05:53:08 2015] But how do I determine the type of test ? [Tue Feb 17 05:54:08 2015] Definition test := exists (d:nat), d > 0 /\ (forall (x:nat)(Hx1:x<>0)(Hx2:x<> d), C x Hx1). [Tue Feb 17 05:54:11 2015] maybe this way? [Tue Feb 17 05:57:43 2015] vanila: Actually I already tried this, but the problem is that I can't destruct it properly in a proof :/ [Tue Feb 17 05:58:07 2015] I have to provide a witness for x, Hx1 and Hx2, or I would like to have Hx1 and Hx2 as hypothesis [Tue Feb 17 05:58:30 2015] well im am not too sure what you are doing so maybe if you posted a script with what you awant to do someone could finish it/show how? [Tue Feb 17 05:58:50 2015] Yep sure [Tue Feb 17 05:59:51 2015] https://gist.github.com/Choups314/8570912c3d1d53437335 [Tue Feb 17 06:00:06 2015] In the first case [xReal H] [Tue Feb 17 06:00:43 2015] wow are you doing topology! [Tue Feb 17 06:00:53 2015] hu just trying ;) [Tue Feb 17 06:01:21 2015] that's quite far outside my knowledge, so i probably wont be able to help much [Tue Feb 17 06:01:47 2015] The problem is [forall (x : R)(Hx : I x), Rabs (x - x0) < d -> P x Hx] [Tue Feb 17 06:02:37 2015] In a proof, I end with the hypothesis [H7 : forall (x : R) (Hx : Dom R f x), [Tue Feb 17 06:02:38 2015] Rabs (x - x0) < d1 -> *conclusion (predicate)* [Tue Feb 17 06:06:06 2015] I would like to have something like [H7 : forall (x:R) Dom R f x /\ Rabs (x - x0) < d1 -> *conclusion (predicate)*] instead .. but I still need the proof Hx in the conclusion .. [Tue Feb 17 06:07:38 2015] i thiknk you would be ok to u se just the first H7 [Tue Feb 17 06:07:56 2015] it should be easier to work with, since you can apply its parameters one at a time [Tue Feb 17 08:27:11 2015] is there a function that returns a specific range from a list? [Tue Feb 17 08:27:23 2015] like nth, but for multiple elements? [Tue Feb 17 08:29:57 2015] You have this: https://coq.inria.fr/library/Coq.Lists.List.html#lab374 [Tue Feb 17 08:30:14 2015] which you can use to implement what you said [Tue Feb 17 08:30:18 2015] ha perfect, thank you :) [Tue Feb 17 09:28:43 2015] is `rewrite at` flaky? [Tue Feb 17 09:29:18 2015] `rewrite` works, does two things [Tue Feb 17 09:29:26 2015] `rewrite at 2` only does the second thing [Tue Feb 17 09:29:46 2015] `rewrite at 1` fails, "Tactic failure: Unable to satisfy the rewriting constraints." [Tue Feb 17 09:36:04 2015] are there some useful beginner resources for these kind of start up problems? :) [Tue Feb 17 10:02:24 2015] am I asking the wrong question or providing too little detail? [Tue Feb 17 10:06:52 2015] I think the channel is just very low-traffic. [Tue Feb 17 10:07:16 2015] I think that rewrite at is working ok [Tue Feb 17 10:07:25 2015] rewrite at i. should replace the ith occurence [Tue Feb 17 10:07:38 2015] it's not always possible, because there might be a type dependency [Tue Feb 17 10:25:37 2015] Would anyone happen to have an idea why the 8.5beta1 version of coqtop -ideslave prints Fatal error: exception Errors.Anomaly(0, _) on Mac OS X? [Tue Feb 17 12:04:06 2015] kcking: somebody was asking about this earlier (maybe it was you?) I get the same issue. Not sure what it is. [Tue Feb 17 12:08:17 2015] kcking: it happens on Linux as well, if that's any help. [Tue Feb 17 12:16:30 2015] chripsalot: ok thanks, maybe I will email the devs [Tue Feb 17 17:45:53 2015] chirpsalot: ping [Tue Feb 17 17:46:27 2015] johnw: ohai. [Tue Feb 17 17:47:05 2015] so, 0.3 is out, I just have a FEW more tweaks to do, like support register reservation [Tue Feb 17 17:47:18 2015] and there are still a bug in our work test suite I have to track down [Tue Feb 17 17:47:20 2015] but otherwise, nearly there [Tue Feb 17 17:47:27 2015] I also released linearscan-hoopl as a separate library [Tue Feb 17 17:47:39 2015] which includes a dead simple way to construct assembly language DSLs for building Hoopl graphs [Tue Feb 17 17:47:57 2015] if you do that in your code, you wouldn't need to deal with Hoopl at all [Tue Feb 17 18:03:05 2015] johnw: by register reservation do you mean saying "I want this result in R0?" [Tue Feb 17 18:15:05 2015] no, I mean "I'm going to be using register 0 throughout the program, such as for storing the frame pointer, so don't consider it for allocation at all" [Tue Feb 17 18:15:21 2015] you can already say "I want this result in R0" simply by referring to R0 [Tue Feb 17 18:15:29 2015] and the allocator will take that into accoutn [Tue Feb 17 18:15:37 2015] a reservation blacks out the register from the allocator's consideration [Tue Feb 17 19:11:51 2015] johnw: okay, I thought you already had "I want this result in R0", which is why I was confused :). I'll check out the Hoopl library. I have gotten through most of the Hoopl stuff, and have gotten distracted with free monads and all manner of fun :). [Tue Feb 17 19:56:09 2015] chirpsalot: I use Free monads to build the assembly DSL [Tue Feb 17 19:56:39 2015] johnw: yep! I noticed, that's why I'm going on the tangent :). [Tue Feb 17 19:56:43 2015] ah [Tue Feb 17 19:56:52 2015] I'd enjoy any questions, if you have [Tue Feb 17 19:56:58 2015] Do you really use hoopl for the register allocation? [Tue Feb 17 19:57:06 2015] no, I use my library silly! [Tue Feb 17 19:57:25 2015] Hoopl just provides a shaped graph [Tue Feb 17 19:57:27 2015] Well, I mean, do you convert the hoopl graph to pass it to your allocator? [Tue Feb 17 19:57:32 2015] no conversion needed [Tue Feb 17 19:57:44 2015] linearscan can operate directly on the Hoopl graph, by way of characterization functions [Tue Feb 17 19:58:29 2015] Characterization functions? So much vocab to catch up on with Haskell ;). [Tue Feb 17 19:58:39 2015] instead of you giving me a structure of a certain type [Tue Feb 17 19:58:46 2015] you give me a function from a -> what_i_want [Tue Feb 17 20:31:06 2015] johnw: isn't that the same as a conversion function? [Tue Feb 17 20:34:24 2015] johnw: oh wow, so linearscan-hoopl literally does most of the work for me :P [Tue Feb 17 20:40:17 2015] chirpsalot: yep :) [Tue Feb 17 20:40:41 2015] it's not the same as a conversion function, because it's not isomorphic [Tue Feb 17 20:40:49 2015] in that, using the function I can determine the information that I need [Tue Feb 17 20:40:58 2015] but it's not enough information to reconsistute your structure [Tue Feb 17 20:41:02 2015] I only need a subset of what you know [Tue Feb 17 20:47:14 2015] johnw: oh, I see what you mean. Fair enough. So much Haskell to learn! [Tue Feb 17 20:50:58 2015] and Coq apparently! [Tue Feb 17 20:59:15 2015] Yeah! So much to learn! Haskell and Coq are kind of humbling. [Tue Feb 17 20:59:24 2015] but in the best way [Tue Feb 17 21:02:17 2015] Yeah, well, it's not a bad thing. You just feel like you know nothing once you discover them, which is daunting. Slowly getting there, though :). [Tue Feb 17 21:03:02 2015] guys. pls [Tue Feb 17 21:03:19 2015] why is coq so bad at numbers. [Tue Feb 17 21:03:26 2015] why is it just the absolute goddamn worst at numbers. [Tue Feb 17 21:03:40 2015] benzrf: because representing numbers as lambda terms kind of sucks? [Tue Feb 17 21:03:45 2015] like holy shit using coq with numbers is a freaking penance [Tue Feb 17 21:04:14 2015] i am literally unable to prove Lemma Qle_den_ge : forall n m, (n >= m)%nat -> 1#Pos.of_nat n <= 1#Pos.of_nat m. [Tue Feb 17 21:04:27 2015] or rather, i keep giving up 30 minutes in after scrolling through 5 pages of SearchAbout results [Tue Feb 17 21:04:51 2015] Inequalities are always the worst thing to prove :( [Tue Feb 17 21:05:10 2015] Also, wait... Is that true? [Tue Feb 17 21:06:09 2015] uh, yes? [Tue Feb 17 21:06:28 2015] how could it be false -_- [Tue Feb 17 21:06:38 2015] benzrf: what is 1#Pos.of_nat? [Tue Feb 17 21:06:59 2015] chirpsalot: function application has higher precedence than # [Tue Feb 17 21:08:12 2015] Okay, well I don't think I know what # is or Pos.of_nat, then! [Tue Feb 17 21:10:21 2015] benzrf: what's # and Pos.of_nat? :( [Tue Feb 17 21:10:56 2015] I'm really bad at searching for Coq stuff... [Tue Feb 17 21:12:06 2015] ah [Tue Feb 17 21:12:23 2015] # : Z -> positive -> Q [Tue Feb 17 21:12:36 2015] Pos.of_nat : nat -> positive [Tue Feb 17 21:12:42 2015] (adds 1 if 0) [Tue Feb 17 21:44:29 2015] benzrf: oh, I see. [Tue Feb 17 21:46:43 2015] benzrf: okay, that's definitely true then. I have noticed that a fair number of people get stuck trying to prove false things :). [Tue Feb 17 21:47:39 2015] I haven't looked much into the Coq number stuff. Every time I look at it I get really confused. nat is nice enough, though :). [Tue Feb 17 21:55:54 2015] yeah [Tue Feb 17 22:09:59 2015] benzrf: ssreflect is better at numbers btw [Tue Feb 17 22:10:07 2015] w-well... [Tue Feb 17 22:10:19 2015] what exactly is ssreflect again [Tue Feb 17 22:10:21 2015] and how do you use it [Tue Feb 17 22:10:35 2015] I'm going to leave that to google; it's a big question [Tue Feb 17 22:11:26 2015] but it's what several people who have some serious things to prove about number suse [Tue Feb 17 22:12:23 2015] too big for google i fear [Tue Feb 17 22:25:29 2015] johnw: are you gonna be at the meetup tomorrow [Tue Feb 17 22:25:43 2015] what meetup? [Tue Feb 17 22:25:51 2015] monthly akamai boston one [Tue Feb 17 22:26:01 2015] no, I'm not in Boston until Sunday [Tue Feb 17 22:26:06 2015] o [Tue Feb 17 22:26:19 2015] is there any kind of intro to ssreflect [Tue Feb 17 22:26:32 2015] yeah, "Programs and Proofs" by Ilya Sergey [Tue Feb 17 22:26:36 2015] and the tutorial itself [Tue Feb 17 23:02:23 2015] * adds ssreflect to the list. [Tue Feb 17 23:02:46 2015] it's what linearscan is written with [Tue Feb 17 23:02:53 2015] I really like it [Tue Feb 17 23:06:14 2015] johnw: just in the spec? I assume it's what all this "move=>" stuff is? [Tue Feb 17 23:07:42 2015] yep [Tue Feb 17 23:07:46 2015] I use it everywhere [Tue Feb 17 23:07:52 2015] I should sit down and go through linearscan at some point. It's a bit much for me to chew off right now, though. [Tue Feb 17 23:08:02 2015] Really? I only saw it imported there in my github search. [Tue Feb 17 23:08:17 2015] I have a Ssr.v module that Lib.v re-exports, and everything import Lib.v [Tue Feb 17 23:08:23 2015] Oh, I see. [Wed Feb 18 06:05:55 2015] I have a really annoying problem with proof general. [Wed Feb 18 06:06:22 2015] I don't know what causes it, but some times, when I step into a proof, it "hides" the buffer with the source code and showns only the buffer with the proof status [Wed Feb 18 06:06:38 2015] maybe you could try moviding it to 3 window hybrid mode [Wed Feb 18 06:06:42 2015] I find that best [Wed Feb 18 06:06:43 2015] but when I try to go back to the buffer with the souce code emacs opens a new window [Wed Feb 18 06:06:49 2015] vanila: that's what I am using [Wed Feb 18 06:07:10 2015] https://files.app.net/mq1k0Njf2.png [Wed Feb 18 06:08:26 2015] and now the font is small for some reason and I have to fix it for every buffer [Wed Feb 18 06:08:27 2015] ugh [Wed Feb 18 06:35:26 2015] notdan: I had to hack PG to fix that crazy behavior [Wed Feb 18 07:16:16 2015] johnw: ooh, do you happen to still ahve the patches? [Wed Feb 18 07:16:21 2015] johnw: this drivez me crazy [Wed Feb 18 07:25:43 2015] is there a lemma in the stdlib stating forall m n, m > n <-> n < m? [Wed Feb 18 07:30:50 2015] notdan: johnw's config's at github.com/jwiegley [Wed Feb 18 07:31:22 2015] I don't remember the exact place, tho [Wed Feb 18 07:38:55 2015] roosbeef: well `gt' is defined this way [Wed Feb 18 07:39:02 2015] Definition gt (n m:nat) := m < n. [Wed Feb 18 07:39:05 2015] nkar: thanks [Wed Feb 18 07:39:33 2015] oh haha [Wed Feb 18 07:39:42 2015] then ill just do split and assumption i guess :P [Wed Feb 18 07:39:44 2015] thanks notdan [Wed Feb 18 07:57:55 2015] https://files.app.net/mqs2zvWy9.png ugh I reall have to do something with this proof [Wed Feb 18 19:11:41 2015] hello. I have the problem that I need a data structure which can contain integers that are so large that coq complains that they can cause stack overflows. on the other hand [Wed Feb 18 19:12:03 2015] in some other case where I need that structure, the numbers will never grow that big [Wed Feb 18 19:12:25 2015] can I somehow use some more abstract type instead of nat and N? [Thu Feb 19 22:41:18 2015] is there a way to create a Setoid instance without getting the == notation for the equivalence relation? [Fri Feb 20 05:32:09 2015] Hi, does anyone have a reference for handling permutations of binders in the locally nameless representation in a Coq PL formalisation [Fri Feb 20 13:19:56 2015] ianjneu: thanks :) [Fri Feb 20 16:39:30 2015] wrengr_away: whuh? What'd I do? [Sat Feb 21 11:23:02 2015] [6~[6~[6~[6~[6~[6~[6~[6~/sb goto [Sat Feb 21 11:23:19 2015] uh sorry [Sat Feb 21 11:23:52 2015] johnw: ping [Sat Feb 21 16:35:57 2015] quick coqide question: how do you enable word wrapping in the built-in text editor? [Sat Feb 21 18:32:36 2015] notdan: hi [Sun Feb 22 00:09:49 2015] anyone around who can help me with proof general? [Sun Feb 22 00:13:01 2015] carter: what's up? [Sun Feb 22 00:13:32 2015] jrw:, i'm trying to get coq setup on my mac so i can work through CPDT [Sun Feb 22 00:13:39 2015] okay [Sun Feb 22 00:13:44 2015] but i'm hitting a bit of trouble setting up the path correctly [Sun Feb 22 00:13:49 2015] which path? [Sun Feb 22 00:13:53 2015] Require Import Bool Arith List CpdtTactics. [Sun Feb 22 00:14:00 2015] i get Require Import Bool Arith List CpdtTactics. [Sun Feb 22 00:14:03 2015] eerr [Sun Feb 22 00:14:06 2015] Error: Cannot find library CpdtTactics in loadpath [Sun Feb 22 00:14:22 2015] but in my .emacs i have [Sun Feb 22 00:14:23 2015] (custom-set-variables '(coq-prog-args '("-emacs-U" "-I" "/Users/carter/local/coq-libs/cpdt/src"))) [Sun Feb 22 00:14:23 2015] (load-file "/Users/carter/.emacs.d/ProofGeneral-4.2/ProofGeneral-4.2/generic/proof-site.el") [Sun Feb 22 00:14:36 2015] as per http://adam.chlipala.net/cpdt/html/Intro.html [Sun Feb 22 00:15:00 2015] the cpdt book has a tactics file that it uses for a lotta developments [Sun Feb 22 00:15:15 2015] right [Sun Feb 22 00:15:15 2015] so naturally i want to be able to import it when working through the exercise [Sun Feb 22 00:15:33 2015] am i making sense? [Sun Feb 22 00:15:36 2015] yes [Sun Feb 22 00:15:39 2015] what version of coq are you using? [Sun Feb 22 00:15:52 2015] The Coq Proof Assistant, version 8.4pl5 (February 2015) [Sun Feb 22 00:15:52 2015] compiled on Feb 21 2015 23:21:02 with OCaml 4.02.1 [Sun Feb 22 00:16:29 2015] and can you confirm that there is a CpdtTactics.vo file in /Users/carter/local/coq-libs/cpdt/src [Sun Feb 22 00:16:36 2015] .v yeah [Sun Feb 22 00:16:40 2015] no .v0 [Sun Feb 22 00:17:08 2015] hrmm [Sun Feb 22 00:17:09 2015] okay so you need to build [Sun Feb 22 00:17:21 2015] derp [Sun Feb 22 00:17:22 2015] :) [Sun Feb 22 00:17:37 2015] cd /Users/carter/local/coq-libs/cpdt; make [Sun Feb 22 00:17:40 2015] should do the trick [Sun Feb 22 00:17:42 2015] thanks [Sun Feb 22 00:17:55 2015] stuff is happening at lest [Sun Feb 22 00:18:21 2015] the full build might take a while [Sun Feb 22 00:18:33 2015] but the tactics file will be the first one that's done [Sun Feb 22 00:18:40 2015] so you can go ahead and test before it finishes [Sun Feb 22 00:19:54 2015] successs [Sun Feb 22 00:31:48 2015] jrw: ok, now i have a daft question [Sun Feb 22 00:32:00 2015] carter: go for it [Sun Feb 22 00:32:06 2015] so i have [Sun Feb 22 00:32:33 2015] http://lpaste.net/120951 [Sun Feb 22 00:32:38 2015] from the intro materilas [Sun Feb 22 00:32:47 2015] yep [Sun Feb 22 00:33:02 2015] but it complains in the fixpoint defn that it cant see the binopDenote function [Sun Feb 22 00:33:09 2015] when i try to add the expDenote [Sun Feb 22 00:33:12 2015] and i dont understand why [Sun Feb 22 00:33:18 2015] because it IS a toplevel defn [Sun Feb 22 00:34:52 2015] idk if that makes sense :) [Sun Feb 22 00:35:17 2015] one sec [Sun Feb 22 00:35:22 2015] trying to load it on my machine [Sun Feb 22 00:35:27 2015] haven't looked at cpdt stuff in a while... [Sun Feb 22 00:35:31 2015] you can comment out the cpdt tactics bit [Sun Feb 22 00:35:36 2015] its not used in that bit [Sun Feb 22 00:35:38 2015] oh that's a good point [Sun Feb 22 00:36:05 2015] i'm just like "i really should learn the tactics sledge hammer approach or i may as well use agda " [Sun Feb 22 00:36:14 2015] carter: you misspelled binopDenote :D [Sun Feb 22 00:36:31 2015] missing a trailing e [Sun Feb 22 00:36:49 2015] :) [Sun Feb 22 00:36:53 2015] woops [Sun Feb 22 00:36:58 2015] i thought i checked fo r that [Sun Feb 22 00:36:59 2015] thanksee [Sun Feb 22 00:37:03 2015] np [Sun Feb 22 00:37:51 2015] jrw: do you have a different suggested resource for learning tactics heavy coq? [Sun Feb 22 00:38:01 2015] no [Sun Feb 22 00:38:05 2015] I learned from cpdt [Sun Feb 22 00:38:18 2015] just be aware that basically nobody except adam (the author) is as extreme [Sun Feb 22 00:38:26 2015] i know [Sun Feb 22 00:38:38 2015] jrw: i was in a lab for a summer where he was post docking [Sun Feb 22 00:38:48 2015] and he kept on automating away everything i was trying to do [Sun Feb 22 00:38:48 2015] carter: oh were you at harvard? [Sun Feb 22 00:38:52 2015] for a summer [Sun Feb 22 00:38:54 2015] 2008? [Sun Feb 22 00:38:58 2015] cool [Sun Feb 22 00:39:04 2015] i got nothing done that summer [Sun Feb 22 00:39:07 2015] haha [Sun Feb 22 00:39:17 2015] also proving statful programs correct sucks [Sun Feb 22 00:39:20 2015] dont bother [Sun Feb 22 00:39:25 2015] haha [Sun Feb 22 00:39:26 2015] too hard [Sun Feb 22 00:39:31 2015] pure or fuckit [Sun Feb 22 00:39:32 2015] dare I ask: ynot? [Sun Feb 22 00:39:35 2015] ;) [Sun Feb 22 00:39:40 2015] :'| [Sun Feb 22 00:40:42 2015] i actually was put off from PL a wee bit after that, because i didn't like the mini fad at the time of "we mechanized X" papers being the bulk of what was going on [Sun Feb 22 00:40:50 2015] yeah for sure [Sun Feb 22 00:40:57 2015] so were you an undergrad then? what are you up to now? [Sun Feb 22 00:41:05 2015] yeah [Sun Feb 22 00:41:11 2015] well, right now, goofing off [Sun Feb 22 00:41:46 2015] haha, fair enough [Sun Feb 22 07:01:50 2015] Is it possible to add a ring structure ([Add Ring ..]) for the [ring] tactic, with the real numbers defined in the standard library ? [Sun Feb 22 07:02:32 2015] (Or it must be computable ? [Sun Feb 22 14:35:53 2015] Hi, why P \/ ~ P is an axiom in Coq? Can't it be proved ? [Sun Feb 22 14:36:34 2015] Silnar, it's part of constructive logic that you can't prove that [Sun Feb 22 14:36:59 2015] The idea of \/ in Coq is that the proof actually tells you which side is true [Sun Feb 22 14:37:26 2015] so for example a proof that forall t : TuringMaching, halts t \/ ~ halts t --- would actually be a halting oracle [Sun Feb 22 14:38:02 2015] so you can only prove P \/ ~ P for special types of propositions (decidable ones) [Sun Feb 22 14:41:53 2015] Can you give me an example of such decidables ? Are True and False one of them ? [Sun Feb 22 14:42:28 2015] an example would be forall n : Nat, zero n \/ ~ zero n [Sun Feb 22 14:42:43 2015] hmm [Sun Feb 22 14:42:46 2015] i should write that clearer: [Sun Feb 22 14:42:56 2015] forall n : Nat, (n = 0) \/ ~ (n = 0) [Sun Feb 22 14:43:27 2015] you can prove this because it's decidable whether a number of zero or not -- since you can write a function that checks that [Sun Feb 22 14:48:02 2015] hmm, a function ? I thought that Coq will compare type constructors. So in this example, he will treat 0 as nat O constructor and if I also construct n using O then (n = 0) will be equal by constructor. Am I right ? [Sun Feb 22 14:49:25 2015] Yes. That’s exactly what such a function would do. [Sun Feb 22 14:50:57 2015] In this case, the [constructor] tactic is smart enough to do that as well, but that’s beside the point. [Sun Feb 22 14:54:26 2015] what does the constructor tactic do [Sun Feb 22 14:55:47 2015] Ok. So there is a function that can compare me two nats, but what type does it returns? This decidable equality function? [Sun Feb 22 14:57:11 2015] Silnar: eq_nat_dec : forall n m : nat, {n = m} + {n <> m}. [Sun Feb 22 14:59:28 2015] benzrf: AIUI, it tries to apply each of the constructors of the goal type. For instance, if you do [Definition x : nat. constructor. Defined.] and [Print x], you’ll get [x = 0 : nat]. [Sun Feb 22 14:59:51 2015] hrm [Sun Feb 22 15:00:12 2015] and [Sun Feb 22 15:00:18 2015] it selects the one with the fewest deps or something? [Sun Feb 22 15:02:47 2015] Nope, it selects the first one that works. It’s kind of stupid that way. [Sun Feb 22 15:03:06 2015] (Where by ‘works’, I mean ‘unifies with the goal’, à la [apply].) [Sun Feb 22 15:06:05 2015] Wow, I'm processing all of this... Thanks for answers btw. :) [Sun Feb 22 15:07:52 2015] You’re welcome. [Sun Feb 22 15:25:22 2015] Question: how can I use rewrite tactics when the goal is an existential? I tried eapply ex_into; rewrite ... but then cannot un-eapply. [Sun Feb 22 15:26:01 2015] Try setoid_rewrite, to rewrite under binders [Sun Feb 22 15:26:43 2015] That worked, thanks jgross! [Sun Feb 22 15:31:29 2015] niice [Sun Feb 22 15:46:24 2015] What about autorewrite under binders? M. Sozeau recommended to A. Bauer to use clrewrite_strat (bottomup (hints my_hints)), but clrewrite_strat seems to be missing in in 8.4pl5). [Sun Feb 22 16:12:41 2015] hmmm [Sun Feb 22 16:12:45 2015] if i say, like [Sun Feb 22 16:13:19 2015] Inductive bleh : Type -> Type := | baz : forall t, bleh t. [Sun Feb 22 16:13:28 2015] then if i match on a bleh, i get a type out [Sun Feb 22 16:13:29 2015] right? [Sun Feb 22 16:13:34 2015] er, on a baz [Sun Feb 22 16:13:48 2015] as in "match blehval with | bleh t => ..." [Sun Feb 22 18:14:49 2015] jrw: thanks again [Sun Feb 22 18:15:50 2015] carter: np. good to chat with you :) [Sun Feb 22 18:16:37 2015] if you were serious about being interested in distributed systems verification, I'd love to hear any thoughts you have [Sun Feb 22 18:16:46 2015] also be happy to give you a tutorial on verdi sometime [Sun Feb 22 18:17:24 2015] jrw: that will be awesome [Mon Feb 23 02:48:59 2015] is there a functional equivalent to the rewrite tactic, i.e. rewrite : a = b -> a -> b ? [Mon Feb 23 02:51:06 2015] ah eq_rect should do the trick [Mon Feb 23 02:51:10 2015] nevermind [Mon Feb 23 06:57:32 2015] could anyone provide some background on why Fixpoint is called Fixpoint in Coq? [Mon Feb 23 10:03:30 2015] I need help with setting up ProofGeneral [Mon Feb 23 10:04:04 2015] sure [Mon Feb 23 10:04:20 2015] I installed development version of PG: 4.3pre150202 [Mon Feb 23 10:05:05 2015] when I open COq source file and type C-c i get "Proof process not started!" message [Mon Feb 23 10:05:28 2015] and I think this is not what should happen [Mon Feb 23 10:05:38 2015] oh [Mon Feb 23 10:06:03 2015] and I've set-up .dir-locals.el in the directory with Coq source files [Mon Feb 23 10:06:15 2015] you shouldn't need to do that [Mon Feb 23 10:06:22 2015] (load "~/Code/emacs/ProofGeneral-4.2/ProofGeneral-4.2/generic/proof-site.el") [Mon Feb 23 10:06:22 2015] why? [Mon Feb 23 10:06:32 2015] I only added this one line to ~/.emacs to get the emacs mode working [Mon Feb 23 10:06:56 2015] vanila: author of the source code explicitly stated that this is necessary [Mon Feb 23 10:07:08 2015] my .dir-locals.el contains this: [Mon Feb 23 10:07:09 2015] oh so its a specia lib [Mon Feb 23 10:07:09 2015] ((coq-mode . ((coq-prog-args . ("-emacs-U" "-I" "/dane/projekty/cpdt/src"))))) [Mon Feb 23 10:07:36 2015] (as you can guess from the path name I'm reading Certified Programming with Dependent Types" [Mon Feb 23 10:07:44 2015] http://adam.chlipala.net/cpdt/cpdt.tgz is it this? [Mon Feb 23 10:07:54 2015] http://adam.chlipala.net/cpdt/cpdtlib.tgz and is this needed too? [Mon Feb 23 10:08:38 2015] vanila: Yes to first [Mon Feb 23 10:08:59 2015] vanila: the book does not mention the second one and I have not tried to install it [Mon Feb 23 10:09:08 2015] okay, ill try itout [Mon Feb 23 10:09:12 2015] thanks [Mon Feb 23 10:12:53 2015] I got cpdt and did Make compiled all the sources. Added '(coq-prog-args '("-I" "/home/vanila/Downloads/cpdt/src")) inside custom-set-variables in .emacs [Mon Feb 23 10:13:08 2015] after that I did emacs src/StackMachine.v [Mon Feb 23 10:13:23 2015] and I can step through it running the stuff in Coq, so this worked [Mon Feb 23 10:13:38 2015] how do you step through the code? [Mon Feb 23 10:13:52 2015] well i have electric terminator mode [Mon Feb 23 10:13:54 2015] I only tried using "C-c C-RET" mentioned in the book [Mon Feb 23 10:13:57 2015] so I put the cusor here: [Mon Feb 23 10:13:59 2015] Require Import Bool Arith List CpdtTactics.| [Mon Feb 23 10:14:00 2015] and press . [Mon Feb 23 10:14:04 2015] and it goes blue [Mon Feb 23 10:14:25 2015] I just tried C-c C-RET and that works fine too [Mon Feb 23 10:14:42 2015] did you do 'make' inside cpdt/ ? [Mon Feb 23 10:14:50 2015] I believe I did [Mon Feb 23 10:14:56 2015] let me check [Mon Feb 23 10:15:00 2015] you could do it again & then set .emacs [Mon Feb 23 10:15:06 2015] I think that will be easier than .dir-locals.el [Mon Feb 23 10:15:15 2015] I pasted the relevant part of my .emacs [Mon Feb 23 10:15:37 2015] I fugured that .dir-locals.el is better because it's local to the file I'm working with [Mon Feb 23 10:16:00 2015] if I ever start working in a different directory I'll have tochneg my .emacs config, right? [Mon Feb 23 10:21:44 2015] vanila: I enabled electric terminator mode and it seems that this works [Mon Feb 23 10:22:08 2015] huh!@ [Mon Feb 23 10:22:16 2015] that shouldn't realy affect it, but oh well [Mon Feb 23 10:22:23 2015] pressing . creates several buffers (Coq Script, Coq Response), so I guess that's a sign things are working [Mon Feb 23 10:24:11 2015] I need to read through PG manual - looks like there are some interesting options disabled by default [Mon Feb 23 10:24:29 2015] what I find really good is hybrid/three window mode [Mon Feb 23 10:24:39 2015] so you can see the code, the proof state and the info window all at once [Mon Feb 23 10:25:21 2015] like in CoqIDE? [Mon Feb 23 10:25:31 2015] yeah [Mon Feb 23 10:26:00 2015] ok, I'll figure out how to enable that [Mon Feb 23 11:59:25 2015] another option that isn't enabled in PG by default but I find really useful is hiding of completed proofs (hides everything between Proof. and Qed.) [Mon Feb 23 12:01:17 2015] bennofs: oh so THAT's why Fermat thought he could fit that proof into a notebook's margin but only later realised he hadn't room! [Mon Feb 23 12:01:27 2015] Editor folding. :) [Mon Feb 23 12:01:40 2015] oh I should try that! [Mon Feb 23 13:23:34 2015] mfw i try to do HOAS and it complains about non strictly positive and i google non strictly positive and the first result says " This is a bit of a bother for proponents of higher-order abstract syntax (HOAS)" [Mon Feb 23 15:31:17 2015] Hello, when using [Context ] with generalizable variables, is it possible to specify the name of the implicit arguments ? [Mon Feb 23 19:07:16 2015] hi all [Mon Feb 23 19:07:44 2015] I'm hoping someone can help me with what seems like should be a straightforward lemma [Mon Feb 23 19:07:58 2015] I've been struggling for a while to try to prove forall x xs, x :: xs <> xs [Mon Feb 23 19:08:09 2015] that's actually not too straightward [Mon Feb 23 19:08:10 2015] I feel like I'm missing something *really* obvious [Mon Feb 23 19:08:13 2015] oh [Mon Feb 23 19:08:19 2015] you'll have to prove it by induction on xs [Mon Feb 23 19:09:11 2015] oh heck, sorry, wait, i did manage to prove that one: i'm stuck proving that xs1 ++ ys = xs2 ++ ys -> xs1 = xs2 [Mon Feb 23 19:10:01 2015] it feels like induction over conses is the wrong approach and i want induction over snocs in ys or similar? or something... [Mon Feb 23 19:10:57 2015] I think it would be a lot easier to prove [Mon Feb 23 19:11:06 2015] ys ++ xs1 = y ++ xs2 -> xs1 = xs2 [Mon Feb 23 19:11:13 2015] ys* [Mon Feb 23 19:11:13 2015] yes, that is easier :) [Mon Feb 23 19:11:35 2015] ohh wait [Mon Feb 23 19:11:37 2015] and reverse is a bijection that you can apply to both sides of an equation [Mon Feb 23 19:11:59 2015] tonyg: induction on ys should make that one pretty easy [Mon Feb 23 19:12:02 2015] that's a neat idea [Mon Feb 23 19:12:14 2015] on either side [Mon Feb 23 19:17:43 2015] johnw: thank you for suggesting i take another look at that [Mon Feb 23 19:17:55 2015] it turned out that (as always) i had the foralls in the wrong order leading to the wrong IH [Mon Feb 23 19:18:25 2015] vanila: i'll try the reverse idea later :) [Mon Feb 23 19:18:34 2015] try to have the variable you're doing induction on first [Mon Feb 23 19:18:58 2015] vanila: heh yeah -- it's slowly becoming an instinct, but i find myself making that mistake repeatedly [Mon Feb 23 19:19:39 2015] i wonder if a tactic could be made that does that automatically [Mon Feb 23 19:24:20 2015] you don't always need it first, even though it helps [Mon Feb 23 19:24:32 2015] xs ++ [] = ys ++ [] is easily provable [Mon Feb 23 19:24:56 2015] then you need to prove that xs ++ (z :: zs) = ys ++ (z :: zs), given xs ++ zs = ys ++ zs [Mon Feb 23 19:25:19 2015] which can be rewrite as rcons xs z ++ zs = rcons ys z ++ zs [Mon Feb 23 19:25:22 2015] rewritten [Mon Feb 23 19:26:21 2015] so, then you just generalize over xs and ys in your IH, and that should be it [Mon Feb 23 19:26:37 2015] or maybe just f_equal; f_equal, can't recal [Mon Feb 23 19:26:39 2015] recall [Mon Feb 23 19:34:31 2015] http://lpaste.net/121054 there's a proof using rev [Mon Feb 23 19:35:52 2015] vanila: nice! thank you. i shall study that; i haven't yet learned the proper use of pose [Mon Feb 23 19:40:16 2015] tonyg: here it is without rev: https://gist.github.com/120bb70264db18e7571d [Mon Feb 23 19:43:02 2015] johnw: thanks. i ended up with something similar, but a little more roundabout (essentially, i had a lemma xs ++ a :: ys = (xs ++ [a]) ++ ys, plus a previously-written lemma for xs1 ++ [x1] = xs2 ++ [x2] -> x1 = x2 /\ xs1 = xs2) [Mon Feb 23 21:55:04 2015] hhh [Mon Feb 23 22:18:18 2015] benzrf: triple h is dead. Has been for a while. [Mon Feb 23 22:20:21 2015] wh-wha? [Mon Feb 23 22:21:08 2015] oh wait, nope. I'm thinking of Owen Hart. [Mon Feb 23 22:21:16 2015] WWF wrestling. [Mon Feb 23 22:23:16 2015] ayy lmao [Tue Feb 24 07:05:59 2015] hello. is there anything that can be used as efficient ringbuffer in coq? [Tue Feb 24 09:29:58 2015] hi question [Tue Feb 24 09:30:39 2015] one of the arguments to my function is also used as an index in the type of a later argument [Tue Feb 24 09:31:14 2015] when i match on the later argument, in one branch i know that the index argument must have a particular constructor, because that's forced by the type of the matched constructor [Tue Feb 24 09:31:19 2015] but coq doesnt seem to understand tihs [Tue Feb 24 09:31:22 2015] what do i need to do ? [Tue Feb 24 09:46:46 2015] benzrf: have you taken a look at the convoy pattern in CPDT? [Tue Feb 24 09:49:24 2015] ianjneu: nooo [Tue Feb 24 09:49:32 2015] havent read cpdt at all [Tue Feb 24 09:51:39 2015] ianjneu: how do i get this info [Tue Feb 24 09:51:53 2015] i need to have the knowledge that this list is nonempty!! [Tue Feb 24 09:54:43 2015] benzrf: you seem to write lots of coq, what are you working on? is it available on the interwebs? [Tue Feb 24 10:09:56 2015] hello? [Tue Feb 24 10:16:56 2015] Ohai there. [Tue Feb 24 10:36:50 2015] benzrf: If you have a value v : Ty (cons x l) but the index is some variable l', then you can do match v in (Ty l'') return (l' = l'' -> ) end eq_refl l' [Tue Feb 24 10:37:33 2015] then you can use the proof of equality to get that l' = cons x l in your cases with a fun H : l' = cons x l => [Tue Feb 24 23:50:01 2015] with the property "forall xs ys: list A, f (xs ++ ys) = f ys ++ f xs", the only function that satifies f is the list reverse function. is there a name for properties like this whose proofs essentially define the function? [Wed Feb 25 01:45:41 2015] rola: I'm not sure I've ever heard a name for that. closest thing I can think of would be saying that the property "completely characterizes" the rev function [Wed Feb 25 02:08:42 2015] cool! maybe totally characterizes [Wed Feb 25 05:01:38 2015] how can i apply the same tactic on multiple subgoals? [Wed Feb 25 08:34:30 2015] gaah [Wed Feb 25 08:36:22 2015] ok, os [Wed Feb 25 08:36:24 2015] *so [Wed Feb 25 08:36:33 2015] i have these hypotheses: [Wed Feb 25 08:36:35 2015] l : lam (T :: t) A [Wed Feb 25 08:36:37 2015] v : lam t T [Wed Feb 25 08:36:42 2015] then, [Wed Feb 25 08:36:44 2015] | var : forall {A : Type} {t : list Type}, lam (cons A t) A [Wed Feb 25 08:37:15 2015] but if i destruct l, it doesnt seem to know that v can be lam t A [Wed Feb 25 08:37:19 2015] how can I get that x_x [Wed Feb 25 08:58:42 2015] benzrf: did you try inversion? [Wed Feb 25 08:58:50 2015] on what? [Wed Feb 25 08:58:50 2015] inversion introduces equalities. [Wed Feb 25 08:58:53 2015] on l [Wed Feb 25 08:59:14 2015] ianjneu: but l is not necessarily constructed by var [Wed Feb 25 08:59:21 2015] and if i destruct, l vanishes [Wed Feb 25 09:00:40 2015] if lam (T :: t) A can be constructed by multiple functions, you'll have to handle all those cases. [Wed Feb 25 09:06:21 2015] ahhhh [Wed Feb 25 09:06:23 2015] nice :D [Wed Feb 25 09:06:41 2015] ianjneu: so inversion does destruct automtically before pulling out info/ [Wed Feb 25 09:06:43 2015] *? [Wed Feb 25 09:37:58 2015] benzrf: inversion introduces equalities between the type family's parameters and what it ends up destructing. [Wed Feb 25 09:55:48 2015] I have a question about using proof general [Wed Feb 25 09:56:11 2015] In CoqIDE I can use Ctrl+Alt+arrow up/down to step through the proof [Wed Feb 25 09:56:21 2015] can I do something similar in ProofGeneral? [Wed Feb 25 09:58:33 2015] Yes you can. There is a routine proof-assert-until-point-interactive and another point-retract-until-point-interactive that you can call manually with M-x or bind to keys. [Wed Feb 25 09:58:59 2015] so I put my cursor just past the thing I want to feed in, and press the keybind for proof-assert-until-point-interactive [Wed Feb 25 09:59:35 2015] also, there is proof-assert-next-command-interactive, which feeds the next command in each time you press the key for it. [Wed Feb 25 10:00:55 2015] jstolarek: the default binding for proof-assert-next-command-interactive is C-c C-n [Wed Feb 25 10:01:18 2015] RchrdB: thanks. [Wed Feb 25 10:01:38 2015] C-c C-n tells me "At end of the locked region, nothing to do to!" [Wed Feb 25 10:01:52 2015] pressing "F1" then "f" then typing "proof-assert-next-command-interactive" will cause emacs to pop up a help page describing what proof-assert-next-command-interactive does, and at the bottom, what keys it's bound to [Wed Feb 25 10:02:13 2015] the "locked" region is the region that PG has already coloured in because it's all been fed into coq and proved [Wed Feb 25 10:02:29 2015] that error message means PG thinks you ran out of assertions to feed into coq :) [Wed Feb 25 10:02:56 2015] RchrdB: ok, PG is correct in this case :-) [Wed Feb 25 10:03:01 2015] but how do I go back? [Wed Feb 25 10:03:03 2015] I mean [Wed Feb 25 10:03:21 2015] I used a tactic, which changed my goald [Wed Feb 25 10:03:25 2015] Press "F1" then "f" then type "proof-retract" and press tab instead of enter [Wed Feb 25 10:03:27 2015] s/goald/goal/ [Wed Feb 25 10:03:45 2015] Emacs will auto-complete all of the commands/functions whose names start with "proof-retract" [Wed Feb 25 10:04:29 2015] proof-retract-until-point-interactive is the one I'd normally use [Wed Feb 25 10:04:42 2015] I'm not sure if there are default keybindings for those two? [Wed Feb 25 10:05:03 2015] I have, in my .emacs: (defun my-proof-general-keys () (local-set-key (kbd "") 'proof-retract-until-point-interactive) (local-set-key (kbd "") 'proof-assert-until-point-interactive)) (add-hook 'proof-mode-hook 'my-proof-general-keys) [Wed Feb 25 10:05:16 2015] yes, proof-retract-until-point-interactive does what I want [Wed Feb 25 10:05:29 2015] to bind them to C-M-backspace and C-M-enter (or "control-alt-backspace" and "control-alt-enter" if you're not used to Emacs keyboard notation) [Wed Feb 25 10:05:47 2015] I'll try that, give me a moment [Wed Feb 25 10:06:36 2015] Out of curiosity, am I correct in guessing that you're new to Emacs and are learning up Emacs so that you can use proof general? [Wed Feb 25 10:06:53 2015] hm... no [Wed Feb 25 10:07:02 2015] well [Wed Feb 25 10:07:05 2015] Oh, sorry. :) [Wed Feb 25 10:07:14 2015] I've been using Emacs for ~3 year [Wed Feb 25 10:07:23 2015] not sure if that counts as "new to Emacs" :-) [Wed Feb 25 10:07:25 2015] As far as I can remember, PG was the thing that caused me to move over to emacs. [Wed Feb 25 10:07:48 2015] oh, I moved to Emacs when learning Scheme [Wed Feb 25 10:08:17 2015] but the truth is I still have fairly basic understanding of Emacs' internals [Wed Feb 25 10:08:21 2015] Cool. :) [Wed Feb 25 10:09:58 2015] ROTFL, C-M-Backspace is a very bad key combination if you're on Linux... [Wed Feb 25 10:10:11 2015] it resets the X server [Wed Feb 25 10:10:52 2015] jstolarek: oh crap I'm sorry [Wed Feb 25 10:11:04 2015] jstolarek: I forgot about that because some distros disable it [Wed Feb 25 10:11:13 2015] that's ok [Wed Feb 25 10:11:35 2015] I'm working in a tmux session, so nothing's lost :-) [Wed Feb 25 10:15:15 2015] ok, I have what I want with C-c C-n and C-c C-p [Wed Feb 25 10:24:04 2015] RchrdB: one more question. proof-assert-next-command-interactive works instantaneous, whereas proof-retract-until-point-interactive is very slugish and takes ~1second. Any idea why? [Wed Feb 25 10:31:35 2015] ok, nvm. Emacs is playing tricks on me. The command is slow only with the key combination I assigned to it. After assigning a different one it works just as fast [Wed Feb 25 10:34:34 2015] I'm very glad you solved that yourself because I had no clue. [Wed Feb 25 10:42:26 2015] One more question. How can I run commands like Eval or Check, other than typing them in the .v file I'm currently editing and forcing Coq to evaluate them [Wed Feb 25 10:43:05 2015] is there some way to issue these commands so that the result shows up in Coq Response frame? [Wed Feb 25 10:44:29 2015] There are bindings that start with C-c C-a for that. Check is C-c C-a C-c; I don’t remember Eval, though. (I think you can do C-c C-a C-h for help?) [Wed Feb 25 10:47:27 2015] alkabetz: yes, C-c C-a C-c does Check. There seems to be no shortcut for Eval though. [Wed Feb 25 11:12:53 2015] alkabetz pasted “Proof General shortcut for Eval” at http://lpaste.net/121182 [Wed Feb 25 11:13:03 2015] jstolarek: Have some Emacs Lisp :) [Wed Feb 25 11:14:20 2015] (This is Emacs ≥24.4 only; let me know if you need for <24.4.) [Wed Feb 25 13:02:45 2015] Where can I find a good description of the properties that CompCert guarantees? [Wed Feb 25 13:09:26 2015] gadsdin: what exactly are you looking for? perhaps one of the papers would be a good place to start. [Wed Feb 25 13:11:29 2015] alkabetz: thanks. Sadly, I have Emacs 24.3 and with-eval-after-load does not exist :-/ [Wed Feb 25 13:14:36 2015] alkabetz pasted “with-eval-after-load for Emacs <24.4” at http://lpaste.net/121185 [Wed Feb 25 13:14:49 2015] jstolarek: Stick that in your .emacs file as well, and you should be good to go. [Wed Feb 25 13:16:05 2015] jstolarek pasted “No title” at http://lpaste.net/121186 [Wed Feb 25 13:16:25 2015] thanks [Wed Feb 25 13:16:32 2015] I think I also need some help [Wed Feb 25 13:16:44 2015] I can'f figure out what goes wrong inthe code I pasted [Wed Feb 25 13:18:01 2015] could you repost the link? [Wed Feb 25 13:18:10 2015] jrw: I've looked at the papers and read the intro one and some of the others. However, the actual definitions of correctness were referred to abstractly or incompletely. [Wed Feb 25 13:18:36 2015] vanila: http://lpaste.net/121186 [Wed Feb 25 13:18:46 2015] jrw: I'd love something like "these are the ANSI C undefined behaviors that we consider unacceptable", or something like that [Wed Feb 25 13:18:47 2015] alkabetz: thanks, now Eval works [Wed Feb 25 13:18:59 2015] ah [Wed Feb 25 13:19:13 2015] you need to use a slightly more complicated 'match' features [Wed Feb 25 13:19:15 2015] jrw: Or, "we consider all ANSI C undefined behaviors unacceptable" [Wed Feb 25 13:19:15 2015] gadsdin: I’m not sure if anybody’s actually written anything down in a nice way, but the guarantees are pretty weak [Wed Feb 25 13:19:15 2015] gadsdin: For instance, all bets are off if main takes arguments :) [Wed Feb 25 13:19:24 2015] and let me remark that this is not only the code that I came up with, but also the same code is shown in the CPDT book [Wed Feb 25 13:20:02 2015] match b in tbinop arg1 arg2 res return typeDenote arg1 -> typeDenote arg2 -> typeDenote res with [Wed Feb 25 13:20:06 2015] vanila: surprising. would that code work in an older version of Coq [Wed Feb 25 13:20:07 2015] ? [Wed Feb 25 13:20:14 2015] gadsdin: http://blog.regehr.org/archives/232 has some nice info about how CompCert handles undefined behaviour [Wed Feb 25 13:20:35 2015] i guess [Wed Feb 25 13:22:47 2015] I should really learn how to do dependent pattern matching at some point [Wed Feb 25 13:24:31 2015] jstolarek: your code works, but something else is amiss... need to investigate [Wed Feb 25 13:25:01 2015] I mean if I open the chapter file from CPDT this code works perfectly fines [Wed Feb 25 13:25:15 2015] yet it does not work when I wrote it in a separate file [Wed Feb 25 13:25:26 2015] maybe it sets an option or something [Wed Feb 25 13:25:28 2015] something else must be different in these files... [Wed Feb 25 13:25:29 2015] So something got set in some import somewhere that’s impacting your work [Wed Feb 25 13:25:56 2015] I have the same import list and Set Implicit Arguments [Wed Feb 25 13:26:38 2015] got it [Wed Feb 25 13:26:43 2015] I had [Wed Feb 25 13:26:57 2015] Require Import Arith Bool List CpdtTactics. [Wed Feb 25 13:27:00 2015] the book had [Wed Feb 25 13:27:09 2015] Require Import Bool Arith List CpdtTactics. [Wed Feb 25 13:27:34 2015] Welcome to Coq, the proof assistant with mutation :( [Wed Feb 25 13:27:46 2015] seriously? aargh [Wed Feb 25 13:27:57 2015] that's a shame [Wed Feb 25 13:28:03 2015] that's definitely tricky [Wed Feb 25 13:28:12 2015] I didn't know order of imports was an issue inc oq [Wed Feb 25 13:28:29 2015] vanila: what rang a bell was that after I added your fix the types in the lest branch did not match [Wed Feb 25 13:28:41 2015] I mean leb was reported to work on Bools, not Nats [Wed Feb 25 13:28:53 2015] vanila: Most definitely an issue. A whole bunch of Coq state is global and mutable and changed by vernacular commands. [Wed Feb 25 13:29:23 2015] Coq does encapsulation poorly, IMO. [Wed Feb 25 13:30:08 2015] alkabetz: by "global state" you mean things like scoping (which seems to be the issue with leb) or state as in impure programming? [Wed Feb 25 13:30:36 2015] The former. I mean the state of the proof assistant, not the state of the programs you’re writing in it. [Wed Feb 25 13:30:49 2015] right [Wed Feb 25 13:31:11 2015] another unpleasent surprise: undo-tree does not seem to work in PG [Wed Feb 25 13:31:24 2015] anyone faced that problem before? [Wed Feb 25 13:31:35 2015] I have a friend who has, I think. Let me ask her what she did. [Wed Feb 25 13:32:06 2015] alkabetz: thanks :) [Wed Feb 25 13:32:20 2015] gadsdin: You’re welcome. [Wed Feb 25 13:32:49 2015] alkabetz: thanks. In the meantime I'm googling for a solution [Wed Feb 25 13:33:57 2015] jstolarek: Looks like she’s AFK right now; I’ll let you know if I get in touch with her later. [Wed Feb 25 13:34:25 2015] that would be nice. thanks [Wed Feb 25 13:34:31 2015] You’re welcome. [Wed Feb 25 13:34:47 2015] in the meantime I give up on undo-tree - google shows no meanigful results [Wed Feb 25 13:35:23 2015] (undo-tree users) ∩ (Proof General users) is probably pretty small [Wed Feb 25 13:37:14 2015] maybe I'l try that later [Wed Feb 25 13:37:28 2015] for now I'll just try not to make too many mistakes so that undo is not necessary :-D [Wed Feb 25 14:07:00 2015] this is a very basic question, but how do I solve the following with a simple tactic? S (S (n' + n')) = S (n' + S n') [Wed Feb 25 14:07:22 2015] simpl does nothing. I'm on the third chapter of Software Foundations, fwiw [Wed Feb 25 14:07:40 2015] [omega] works for me. [Wed Feb 25 14:07:58 2015] You’ll need [Require Import Omega.] first. [Wed Feb 25 14:08:23 2015] it could also be proved with ring [Wed Feb 25 14:10:37 2015] alkabetz: was that directed at me? [Wed Feb 25 14:10:56 2015] gadsdin: Yes. [Wed Feb 25 14:10:59 2015] If so, I think I should find out how to do it with what's been introduced in the book so far. Which is almost nothing... [Wed Feb 25 14:11:22 2015] SearchAbout plus. will list all the lemmas that have been proved, you might be able to 'apply' one [Wed Feb 25 14:12:33 2015] alkabetz: This proof is using induction, if that's useful. [Wed Feb 25 14:12:36 2015] vanila: Thanks. [Wed Feb 25 14:13:58 2015] vanila: Wouldn't that kind of thing be used with simpl? simpl doesn't do anything, strangely. [Wed Feb 25 14:14:11 2015] + is defined by recursion on the first argument [Wed Feb 25 14:14:24 2015] so S x + y would reduce to x + S y [Wed Feb 25 14:14:35 2015] but you have n' + S n' so there's nothing to reduce [Wed Feb 25 14:18:55 2015] vanila: I don't think I follow you [Wed Feb 25 14:19:07 2015] at least in the context of what I'm trying to solve [Wed Feb 25 14:19:24 2015] I just don't get why I can't for starters, strip the outermost S's off [Wed Feb 25 14:19:26 2015] I just explained why simpl has no effect on the goal: S (S (n' + n')) = S (n' + S n') [Wed Feb 25 14:19:31 2015] oh okay [Wed Feb 25 14:19:44 2015] simpl is not really "simplifying" the goal [Wed Feb 25 14:19:52 2015] actually what it's doing is beta-reduction [Wed Feb 25 14:20:04 2015] it tries to rewrite a function application with the result value [Wed Feb 25 14:20:43 2015] i see [Wed Feb 25 14:21:03 2015] so how do you think I'm supposed to solve this? [Wed Feb 25 14:21:53 2015] if you just do this: ring. [Wed Feb 25 14:21:56 2015] it should be proved automatically [Wed Feb 25 14:23:26 2015] vanila: Thanks. I'm just really perplexed because I know I'm supposed to be using only what's been covered by the book up to this point, and I can't figure out what I'm supposed to use. [Wed Feb 25 14:30:30 2015] jstolarek: if you get undo-tree to work, ping me :) [Wed Feb 25 15:54:50 2015] Hi, I'm trying to understand theorems. Am I understanding it right, that theorem is a function declaration (name & type) and proving a theorem is a process of finding a function implementation that satisfies the given function type ? [Wed Feb 25 15:56:00 2015] Not necessarily a function, but that's the idea, yes [Wed Feb 25 15:56:17 2015] Types <-> Propositions. And Terms <-> Proofs. [Wed Feb 25 15:57:27 2015] Terms - you mean code/implementation/function body, yeah ? [Wed Feb 25 15:57:44 2015] Yes [Wed Feb 25 15:59:08 2015] What else a theorem can be if you say that it is not always a function ? I assumed it is a function, because always when I print a theorem I get a function-like code in response... [Wed Feb 25 15:59:26 2015] A function type X -> Y is an implication [Wed Feb 25 15:59:44 2015] another type is a predicate e.g. Prime 7 could be a type [Wed Feb 25 16:05:00 2015] ahh ok, so for example "Theorem t : True." would also be a type, because it doesn't use implication, yeah ? [Wed Feb 25 16:05:11 2015] yes [Wed Feb 25 16:05:15 2015] nice :) [Wed Feb 25 16:06:13 2015] how can I paste some code here ? [Wed Feb 25 16:06:24 2015] lpaste.net is good [Wed Feb 25 16:06:30 2015] ok, thx [Wed Feb 25 16:07:02 2015] hm. what is the best way, in coq, to model stateful operations? I know it is purely functional, but I want to verify an imperative algorithm [Wed Feb 25 16:07:50 2015] I looked at the operational semantics from compcert, but are they the right place to start? [Wed Feb 25 16:08:17 2015] schoppenhauer, you could try something like this http://www.staff.science.uu.nl/~swier004/Publications/HoareLogicStateMonad.pdf [Wed Feb 25 16:08:35 2015] Domain-specific imperative languages are the accepted way to do this, so 'sort of' [Wed Feb 25 16:08:53 2015] Ynot may be good to look at too, although maybe there's newer stuff.. [Wed Feb 25 16:09:03 2015] CompCert's semantics are probably overkill [Wed Feb 25 16:09:29 2015] Have you read the Imp chapter in SF? [Wed Feb 25 16:09:37 2015] SF? [Wed Feb 25 16:09:59 2015] what's sf? [Wed Feb 25 16:10:05 2015] http://www.cis.upenn.edu/~bcpierce/sf/current/ [Wed Feb 25 16:10:26 2015] thx [Wed Feb 25 16:10:32 2015] Silnar pasted “Theorem: True & False -> False” at http://lpaste.net/121192 [Wed Feb 25 16:10:42 2015] nice, it worked :) [Wed Feb 25 16:10:55 2015] schoppenhauer: No problem! [Wed Feb 25 16:11:11 2015] alkabetz: the advantage of compcert I would hope to gain is that I could pass the code to compcert directly and get compiled code that can be run. [Wed Feb 25 16:11:58 2015] while defining my own dsl would require me to write a compiler for it [Wed Feb 25 16:12:12 2015] Have you read about Bedrock? [Wed Feb 25 16:12:19 2015] Hello ! Is it possible to use [pattern] with a placeholder ? (Not a "real" placeholder, because it doesn't work, but something similar) [Wed Feb 25 16:12:25 2015] alkabetz: no. [Wed Feb 25 16:12:37 2015] (Shameless plug--it's my group's project) [Wed Feb 25 16:12:42 2015] ah doch, I read about it ... [Wed Feb 25 16:12:45 2015] but forgotten. [Wed Feb 25 16:12:48 2015] Choups314 : do you mean to let Coq choose a name for your variable? If so, you can use ? [Wed Feb 25 16:13:15 2015] Silnar, http://lpaste.net/121192 [Wed Feb 25 16:13:20 2015] alkabetz: ok, looks promising [Wed Feb 25 16:13:25 2015] For example, pattern every applications of [app] (of a type T->T) in the current goal) [Wed Feb 25 16:13:38 2015] Silnar, I think you should file a bug report about this, if you can be bothered - for now, here's how to write that proof as a definition [Wed Feb 25 16:14:04 2015] Ah. I believe you'll need to learn about Ltac. What do you want to do exactly? [Wed Feb 25 16:14:08 2015] schoppenhauer: You should read Imp and Hoare in SF first, though. [Wed Feb 25 16:14:22 2015] ok [Wed Feb 25 16:14:23 2015] Cypi, I'm doing it in a Ltac ;) [Wed Feb 25 16:14:28 2015] (I'm trying at least) [Wed Feb 25 16:15:06 2015] Cypi, I would like to rewrite every applications of a given [app : T -> E] [Wed Feb 25 16:15:48 2015] But rewrite them to what? [Wed Feb 25 16:16:18 2015] To a term of type [E] (if the application is of type [_ -> E] for example. [Wed Feb 25 16:17:13 2015] In fact, I would like to rewrite some injections (I [pose] a witness of the target type that has the same value of the witness, and then I rewrite the injections to this new variable) [Wed Feb 25 16:17:38 2015] Of course it would pattern them only one at once [Wed Feb 25 16:17:51 2015] vanila: can you tell me how this definition should look like ? [Wed Feb 25 16:18:01 2015] So if I understand correctly, everytime there is [app t] in the goal, you want to replace it with [t'] where t' is a new variable of type E? [Wed Feb 25 16:18:16 2015] Yes ! [Wed Feb 25 16:18:32 2015] Hmm, let's see if I can do that, I'm curious :) [Wed Feb 25 16:18:38 2015] :p [Wed Feb 25 16:19:43 2015] But in one goal, it's likely there is several applications : [app t] .. [app t2] .. [app t3] (where t, t2, t3 are different object of the same type) .. that's why I can't use [pattern] :/ [Wed Feb 25 16:20:05 2015] Choups314: can't you repeat? :\ [Wed Feb 25 16:20:50 2015] Ptival, Yes of course :) (I'm not english, so it might be not so clear :s, just say it) : [Wed Feb 25 16:22:55 2015] (don't worry, neither are we for some :-° ) [Wed Feb 25 16:23:09 2015] Would that do it? http://lpaste.net/121194 [Wed Feb 25 16:23:18 2015] In a goal I have several applications [app t1] .. [app t2] .. [app t3] (where t, t2, t3 are different object of the same type). For example let's say the type of [app] is [T -> E], t1, t2, t3 have type T. I would like to rewrite each of these applciations to a corresponding object of type [E]. (So for each of this application, I use [pose t1' : _], and then I can replace the application [app t1] with [t1'] [Wed Feb 25 16:24:02 2015] Ah, you only want to replace one specific [app : T -> E]? [Wed Feb 25 16:24:30 2015] hm. I don't quite understand, when browsing over the chapter of imp in sf ... this is just a DSL, or can I actually extract from it? [Wed Feb 25 16:25:23 2015] Cypi, no, every application of type (T->E). You solution seems to work ! I'm trying ;) [Wed Feb 25 16:26:02 2015] schoppenhauer: You can extract it to an AST and write an interpreter for it. Bedrock, OTOH, compiles down to assembly. [Wed Feb 25 16:26:04 2015] (But of course, it would be better if I could supply (not in this purpose, but for curiosity ;)) the "occurence number" of the application to replace :p [Wed Feb 25 16:26:36 2015] The "occurence number"? As in something like [rewrite H at 1] ? [Wed Feb 25 16:27:02 2015] Yes exactly (I though of [pattern A at 1]) [Wed Feb 25 16:27:38 2015] Well, sorry, I have no idea how to do that :D [Wed Feb 25 16:27:45 2015] ^^ [Wed Feb 25 16:27:59 2015] I'm not really used with [context] .. [Wed Feb 25 16:29:29 2015] Someone advised me a reading .. I don't remember the exact title >< .. something like "CP ..." or "CD ..." (only upper case letters) [Wed Feb 25 16:29:40 2015] CPDT. [Wed Feb 25 16:29:48 2015] Thanks ! :) [Wed Feb 25 16:30:29 2015] You're welcome! That's the other major verification-with-Coq textbookv [Wed Feb 25 16:32:23 2015] alkabetz: thx [Wed Feb 25 16:34:13 2015] You're welcome. [Wed Feb 25 16:34:51 2015] Do you know if it is possible to configure coq_makefile, to generate the .vo files in a separate directory ? I already hacked the generated Makefile to change the directory of the .d files, but there are much more rules for the .vo ... it might break everything if I do the same :| [Wed Feb 25 16:41:33 2015] Choups314 computer programming with dependent types ? [Wed Feb 25 16:41:55 2015] Yes, the name is coherent but I forgot it ;) [Wed Feb 25 16:43:07 2015] Certified Programming with Dependent Types - Adam Chlipala [Thu Feb 26 05:11:53 2015] could anyone help me to decipher a sentence from software foundations? [Thu Feb 26 05:20:04 2015] nm [Thu Feb 26 05:38:38 2015] how do I proceed? [Theorem even5_nonsense : ev 5 -> 2 + 2 = 9. Proof. intros. inversion H. simpl.] [Thu Feb 26 05:38:38 2015] [Thu Feb 26 05:39:37 2015] The comment above the exercise says that "The [inversion] tactic can also be used to derive goals by showing the absurdity of a hypothesis." [Thu Feb 26 05:42:42 2015] I would have to know how 'ev' is defined to help [Thu Feb 26 05:43:11 2015] it's from the Prop chapter in sf [Thu Feb 26 05:43:20 2015] but I can paste if you want [Thu Feb 26 05:43:38 2015] oh i'll check it out [Thu Feb 26 05:43:46 2015] that's a chapter i skipped... [Thu Feb 26 05:43:53 2015] why? [Thu Feb 26 05:44:10 2015] was too excited to get to the Imp stuff :) [Thu Feb 26 05:44:47 2015] yeah, I can't wait to get to the "let's implement a simple language" stuff [Thu Feb 26 05:46:00 2015] well the way I would work at this is try to get the assumption: ev 1 out of ev5 [Thu Feb 26 05:46:49 2015] then when you do inversion on that it will see that no possibly constructor of the 'ev' data type could work - so it will discharge the goal [Thu Feb 26 05:47:02 2015] http://lpaste.net/121222 so just this [Thu Feb 26 05:47:13 2015] just keep doing inversion [Thu Feb 26 05:47:29 2015] well inversion H; subst. is a common pattern, the subst after clears things up loads [Thu Feb 26 05:48:00 2015] wait, let me try to prove it based on just your advice [Thu Feb 26 05:52:08 2015] vanila: yeah, applying SSSSev__even in H, which gives ev1, works [Thu Feb 26 05:52:51 2015] great :) [Thu Feb 26 06:33:10 2015] lots of "Warning : deprecated" when compiling coq. [Thu Feb 26 07:27:52 2015] how do I make a single line comment in Coq? [Thu Feb 26 07:28:05 2015] (* ... *) [Thu Feb 26 07:28:28 2015] well, that's a block comment [Thu Feb 26 07:28:51 2015] I'm looking for a comment that ends automatically with EOL [Thu Feb 26 07:29:30 2015] alkabetz: any news from your friend about using undo-tree with Proof General? [Thu Feb 26 07:29:59 2015] Coq only has block comments [Thu Feb 26 07:31:10 2015] arcatan: thanks. That's a bit inconveniet, but I can live with it [Thu Feb 26 07:34:39 2015] yeah. i wouldn't mind having line comments, either. [Thu Feb 26 08:41:36 2015] is it possible to apply the same tactic to multiple subgoals using a single command? [Thu Feb 26 08:42:09 2015] if a generates many subgoals a; b will do b to each [Thu Feb 26 08:49:28 2015] jstolarek: what editor do you use? there's probably a hotkey that'll insert (* *) for you. [Thu Feb 26 08:49:36 2015] like M-; in emacs [Thu Feb 26 09:40:15 2015] hey ok im pretty confused [Thu Feb 26 09:40:37 2015] i saw that one post about how 2^2^N ~ N [Thu Feb 26 09:40:43 2015] if you accept an independent axiom [Thu Feb 26 09:41:01 2015] but... i just proved powset_greater : forall s : Type, ~ (exists f : s -> s -> bool, surjective f) [Thu Feb 26 09:41:11 2015] huh?? [Thu Feb 26 09:41:15 2015] [Thu Feb 26 09:43:43 2015] ooh wait [Thu Feb 26 09:44:01 2015] ? [Thu Feb 26 09:44:44 2015] to use that to prove a /double/ power set i'd need to be able to break down the double powerset surjection into two component surjections f : N -> 2^N and g : N -> 2^N [Thu Feb 26 09:45:15 2015] shit [Thu Feb 26 09:45:46 2015] so does this mean that smaller-cardinality is not necessarily transitive in constructive math? [Thu Feb 26 09:45:49 2015] are you proving cantor's theorem [Thu Feb 26 09:46:11 2015] yes i did [Thu Feb 26 09:46:16 2015] but it seems to conflict with this http://math.andrej.com/2009/10/12/constructive-gem-double-exponentials/ [Thu Feb 26 09:46:29 2015] * takes his Q to ##math [Thu Feb 26 09:47:09 2015] yeah i think i recall seeing something about that on andrej's blog [Thu Feb 26 10:15:26 2015] is there a simple way to convice coq, that tl l is a subterm of l? [Thu Feb 26 10:15:53 2015] when running coq i got this : http://pastebin.com/GLQ3nHH0 [Thu Feb 26 10:20:08 2015] JanBessai, if you can't match on l to avoid using tl, you might have to use measure and prove the obligations [Thu Feb 26 10:20:42 2015] vanila: I have a proof of l = x::l' in my context [Thu Feb 26 10:21:48 2015] so I probably should match and eliminate the nil case with that proof [Thu Feb 26 10:21:50 2015] thanks [Thu Feb 26 10:58:42 2015] how does one use measure [Thu Feb 26 11:31:33 2015] vanila.. thanks - it finallay worked :) [Thu Feb 26 11:36:27 2015] is there any notion of decidability that coq itself knows about [Thu Feb 26 11:37:02 2015] Do you mean this? https://coq.inria.fr/library/Coq.Logic.Decidable.html [Thu Feb 26 11:38:47 2015] * looks [Thu Feb 26 15:35:54 2015] Hi, how to return 'forall' value ? http://lpaste.net/121247 [Thu Feb 26 15:37:29 2015] fun x : Prop => or_intror x I. [Thu Feb 26 15:38:08 2015] forall x:A, B is a generalized version of A -> B [Thu Feb 26 15:38:17 2015] for either you produce a function to prove it [Thu Feb 26 15:41:52 2015] ah, ok [Thu Feb 26 15:42:36 2015] but, how it is that forall x:True, True becomes True -> True ? [Thu Feb 26 15:43:38 2015] I mean, would it be also possible to convert forall x : Prop, x \/ True into implication ? [Thu Feb 26 15:45:18 2015] A -> B is for when B does not depend on the value passed in [Thu Feb 26 15:45:30 2015] forall x:A, B[x] lets the result type depend on the input value [Thu Feb 26 15:45:48 2015] since there's no dependency in forall x:True, True you can write it as True -> True [Thu Feb 26 15:45:55 2015] but forall x : Prop, x \/ True couldnt be [Thu Feb 26 15:48:25 2015] ok, and anytime I want to satisfy forall x:A, B[x] I need to write a function fun x:A => return value of type B[x], got it [Thu Feb 26 15:57:17 2015] when I write 'Definition or_x_t_fun (x:Prop) : (x \/ True) := or_intror x I.', coq prints its type as 'forall x : Prop, x \/ True'. Why did he insert 'forall' here? Because return type depends on argument x value ? [Thu Feb 26 20:39:25 2015] ok so [Thu Feb 26 20:39:46 2015] is predicate logic in coq inconsistent w/ traditional predicate logic [Thu Feb 26 20:43:07 2015] benzrf: no [Thu Feb 26 20:43:22 2015] benzrf: It just doesn't make as many assumptions [Thu Feb 26 20:43:43 2015] (In particular, you can't prove LEM, but you also can't refute it) [Thu Feb 26 20:44:58 2015] ok then [Thu Feb 26 20:45:20 2015] you can show that a surjection has an injective left inverse in coq [Thu Feb 26 20:45:27 2015] doesnt that require AC in classical ZFC [Thu Feb 26 20:45:30 2015] er [Thu Feb 26 20:45:32 2015] ZF [Thu Feb 26 20:47:07 2015] Cale: ? [Thu Feb 26 20:48:15 2015] Uh, that's not talking about predicate logic any more. You're interepreting certain implications as functions now. [Thu Feb 26 20:48:45 2015] and types as sets [Thu Feb 26 20:59:26 2015] ahh [Thu Feb 26 20:59:44 2015] Cale: can you not eliminate existentials inside a fundef in classical math? [Thu Feb 26 21:01:55 2015] hm? [Thu Feb 26 21:02:07 2015] Well, in ZFC, your functions are particular sets [Thu Feb 26 21:12:49 2015] benzrf: In ZF, knowing that forall x. x in A => exists y. y in B and P(x,y), doesn't give you a way to construct a function f: A -> B such that P(x,f(x)) for every x in A. That's basically what choice is doing for you. The forall doesn't correspond to a function in the sense of ZF. [Thu Feb 26 21:15:33 2015] well [Thu Feb 26 21:15:42 2015] hmm [Thu Feb 26 21:15:45 2015] benzrf: It's down at the level of logic, it's not a set, and it's merely true or false, it doesn't have any sort of content. [Thu Feb 26 21:15:59 2015] hm [Thu Feb 26 21:16:04 2015] hmmmm [Thu Feb 26 21:16:17 2015] so you cant do, e.g., existential eliminiation from inside a function [Thu Feb 26 21:16:26 2015] that only happens at the outer logic level [Thu Feb 26 21:16:34 2015] er, wait [Thu Feb 26 21:16:38 2015] hold on. [Thu Feb 26 21:17:52 2015] Yeah, that's right. [Thu Feb 26 21:18:05 2015] If it were only a finite family of sets, you could prove that there's a function [Thu Feb 26 21:18:19 2015] Because you can eliminate all the existentials one by one [Thu Feb 26 21:18:26 2015] But if it's an infinite family of sets, you can't. [Thu Feb 26 21:19:12 2015] (because your proof isn't allowed to be infinitely long, and you can't defer the choices made until you know what the argument of the function is -- you're trying to build the entire graph of the function at once) [Thu Feb 26 21:19:39 2015] hmm [Thu Feb 26 21:19:56 2015] interesting [Thu Feb 26 21:21:51 2015] The things which choice lets you do in ZFC are much more powerful than what that easily-provable version of choice in Coq lets you do though. [Thu Feb 26 21:22:31 2015] Note that even in ZF, if you can canonically choose an element from each of an infinite family of sets, you can still build a function. [Thu Feb 26 21:22:43 2015] It's just *only* knowing that the sets are nonempty isn't enough to specify one. [Thu Feb 26 21:23:06 2015] If they were, e.g. sets of natural numbers, you could say "oh, pick the minimum element of each one" [Thu Feb 26 21:23:28 2015] Or in any other case where there's a way to compute an element, you're fine. [Thu Feb 26 21:23:53 2015] When you go to use the theorem of choice in Coq, you basically are required to input such an algorithm for making choices. [Thu Feb 26 21:24:19 2015] Whereas in ZFC, when you apply the axiom of choice, there may not be an algorithm. [Thu Feb 26 21:25:20 2015] So at least in terms of what you can actually do with them, they're quite different [Thu Feb 26 21:25:33 2015] HoTT has a lot to say about this [Thu Feb 26 21:27:34 2015] You can express an axiom of choice with a lot of (perhaps all of?) the power of the classical one using truncations. [Thu Feb 26 21:27:49 2015] But again, it's not provable, you have to add that one as an axiom. [Thu Feb 26 21:59:42 2015] hhh [Thu Feb 26 22:00:34 2015] Cale: so using classical logic on ZF[C], applying LEM to the CH doesnt cause weird crap to happen because... [Thu Feb 26 22:00:51 2015] anything you can apply LEM to has to have no free variables? [Thu Feb 26 22:01:08 2015] so instead of CH, it's "ZF implies CH"? [Thu Feb 26 22:01:11 2015] is that right [Thu Feb 26 22:02:53 2015] uhhhh [Thu Feb 26 22:02:54 2015] what? [Thu Feb 26 22:03:06 2015] You're talking about the continuum hypothesis now? [Thu Feb 26 23:10:00 2015] yes [Thu Feb 26 23:10:03 2015] >_> [Thu Feb 26 23:10:11 2015] oh hey that was an hour ago. oops [Thu Feb 26 23:25:14 2015] benzrf: The continuum hypothesis is yet another statement which is independent of ZFC [Thu Feb 26 23:25:24 2015] i know [Thu Feb 26 23:25:53 2015] im thinking about how LEM works in the context of independence of statements [Thu Feb 26 23:26:28 2015] Oh, well, okay, you have that CH or not CH is true, but this doesn't tell you which of those options is the case. [Thu Feb 26 23:29:49 2015] One way to think about it is to think about a first order logical theory of groups with just the group axioms [Thu Feb 26 23:30:05 2015] You can't show that there are any elements other than the identity element [Thu Feb 26 23:30:16 2015] and you also can't show that there aren't [Thu Feb 26 23:31:17 2015] But the statement (exists x. not (x = 1)) or not (exists x. not (x = 1)) is still true [Thu Feb 26 23:31:31 2015] yeah [Thu Feb 26 23:31:42 2015] er, wait [Thu Feb 26 23:31:48 2015] are you describing why LEM doesn't make sense in constructive logic? [Thu Feb 26 23:31:55 2015] in any particular model, yes [Thu Feb 26 23:31:59 2015] interesting... [Thu Feb 26 23:32:00 2015] Well, assuming it's a classical logic [Thu Feb 26 23:32:05 2015] Cale: yeah [Fri Feb 27 02:37:13 2015] Anomaly: Uncaught exception Option.IsNone. Please report. [Fri Feb 27 02:37:44 2015] am I doing something wrong or is this a plain bug? [Fri Feb 27 02:44:10 2015] ah I see. there is just no induction principle for the type I'm trying to perform induction on [Fri Feb 27 02:44:49 2015] so everything is as it should be :) [Fri Feb 27 02:45:23 2015] ugh, how do I prove Theorem ev_plus_plus : forall n m p, ev (n+m) -> ev (n+p) -> ev (m+p). if I'm allowed only to apply existing lemmas. [Fri Feb 27 02:45:27 2015] ? [Fri Feb 27 02:46:58 2015] and here are the lemmas: http://dpaste.com/1KMPEY4 [Fri Feb 27 02:48:33 2015] use ev n \/ odd n, then by case analysis inspect the premisses to obtain even and odd information about m and p [Fri Feb 27 02:48:48 2015] I'm not allowed to perform case analysis [Fri Feb 27 02:49:18 2015] that's from software foundations: (** **** Exercise: 3 stars, optional (ev_plus_plus) *) (** Here's an exercise that just requires applying existing lemmas. No induction or even case analysis is needed, but some of the rewriting may be tedious. *) [Fri Feb 27 02:50:31 2015] you might try type inhabitation ;) [Fri Feb 27 02:50:34 2015] I'm not sure how to do it because every lemma involving sum requires me to talk about elements, too. [Fri Feb 27 02:50:38 2015] what's that? [Fri Feb 27 02:51:49 2015] the first link in my search engine is pubmed [Fri Feb 27 02:52:13 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_tactic141 [Fri Feb 27 02:52:38 2015] i.e. "cheat" using auto [Fri Feb 27 02:52:45 2015] double_even may be useful, but I don't have a lemma allowing me to go from [n + n] to [double n] [Fri Feb 27 02:52:51 2015] oh, it's a tactic [Fri Feb 27 02:53:11 2015] I'm not allowing to use it either. it hasn't been introduced in the book [Fri Feb 27 02:53:53 2015] it might result (if it works) in a solution you can inspect to get an idea [Fri Feb 27 02:54:05 2015] btw. the IRC channel is not in the book, too ;) [Fri Feb 27 02:54:27 2015] :( [Fri Feb 27 03:04:28 2015] can I explicitly pick a subgoal to prove? [Fri Feb 27 03:06:39 2015] okay, Focus does the trick [Fri Feb 27 03:07:50 2015] here's my proof so far: http://dpaste.com/2S2DQH5 [Fri Feb 27 03:11:13 2015] wait, turns out I have a lemma: double n = n + n for all n [Fri Feb 27 03:11:15 2015] lol [Fri Feb 27 03:23:11 2015] okay, proved it: http://dpaste.com/0ZG45EP [Fri Feb 27 11:35:21 2015] where in the docs can i find more info about modules? [Fri Feb 27 11:35:35 2015] theres a small section about them in the tutorial [Fri Feb 27 11:35:55 2015] but is there something more in-depth in the documents? [Fri Feb 27 11:36:57 2015] modules are a source of much aggravation. [Fri Feb 27 11:37:48 2015] adam.chlipala.net/cpdt/html/Large.html#lab101 [Fri Feb 27 11:38:24 2015] nm found it, section 2.5 [Fri Feb 27 11:42:49 2015] but yea i remember having a lot of fun with that ;p [Fri Feb 27 11:43:09 2015] documenting my code now, want to throw in a couple bookmarks to where the reader can find more info [Fri Feb 27 20:36:47 2015] how do I evaluate the goal by a single step? [Fri Feb 27 20:37:14 2015] i.e., the outermost construction is a match ..., and I want to collapse away the match [Fri Feb 27 20:44:50 2015] johnw : is [cbv iota] okay. [Fri Feb 27 20:44:51 2015] ?* [Fri Feb 27 20:45:03 2015] no effect [Fri Feb 27 20:45:20 2015] best I could come up with is to just case analyze on the discriminee, even though it's obvious [Fri Feb 27 20:45:36 2015] Ah, the discriminee is not destructed yet [Fri Feb 27 20:45:46 2015] Hmm, does [lazy iota] do anything? ^^' [Fri Feb 27 20:45:58 2015] no [Fri Feb 27 20:46:12 2015] here's the context: https://gist.github.com/13af20acb6d9ada494ed [Fri Feb 27 20:47:01 2015] Sorry, I don't know then [Fri Feb 27 20:48:29 2015] so, I'm forced to: [Fri Feb 27 20:48:44 2015] case E: (discriminee) => [|? ?]; first by discriminate; rewrite -E. [Fri Feb 27 20:48:50 2015] for what I'd think would happen with "hnf" [Fri Feb 27 20:49:21 2015] oh, at least // discharges it [Sat Feb 28 11:43:51 2015] how much coq do I need to write before I get used to its syntax? [Sat Feb 28 11:45:46 2015] however much is needed :) [Sat Feb 28 12:05:38 2015] Hi, is-it normal that when I use [pattern ..] and then [rewrite ..] it does not "refold" the hypothesis ? (I'm rewriting in an hypothesis) [Sat Feb 28 12:05:45 2015] (I'm using a custom relation) [Sat Feb 28 20:31:56 2015] I find myself slowly evolving an ever-more-complex wrapper around omega for ssreflect [Sun Mar 1 10:23:32 2015] Is it possible to define "polymorphic instances" of classes ? [Sun Mar 1 10:43:19 2015] Choups314: elaborate [Sun Mar 1 16:14:44 2015] Is it possible to disable temporarily notations ? (Displayed in the current goal) [Sun Mar 1 17:18:42 2015] Choups314: [Unset Printing Notations. idtac.] should do the trick. [Mon Mar 2 04:02:46 2015] any hint on proving [Theorem rev_pal : forall (X : Type) (xs : list X), xs = rev xs -> pal xs.]? [Mon Mar 2 04:02:46 2015] [Mon Mar 2 04:03:13 2015] that's the palindrome_converse ex. from software foundations [Mon Mar 2 04:04:54 2015] the only thing I can think of is doing induction on xs, but I don't how to prove the succ case x :: xs = rev (x :: xs) -> pal (x :: xs) [Mon Mar 2 04:05:03 2015] I needed help for that too [Mon Mar 2 04:05:16 2015] :) [Mon Mar 2 04:05:59 2015] I've also tried inversion and induction on the hypothesis. the former doesn't work, and the latter doesn't yield anything useful [Mon Mar 2 04:06:39 2015] In the end what I did was search on google for rev_pal, there was a solution there that had a few ideas that I stole to make my version work [Mon Mar 2 04:07:31 2015] heh, I'm afraid I'll see too much, so it won't be interesting anymore. [Mon Mar 2 04:08:05 2015] One trick that seemed necessary was make an intermediate lemma (defined with Fixpoint instead of Lemma) and do structural recursion on the length of l [Mon Mar 2 04:08:33 2015] Fixpoint rev_pal' X (l: list X) (len: nat) (leneq: length l = len) (reveq: l = rev l) {struct len}: pal l. [Mon Mar 2 04:09:23 2015] The other trick that I needed is that you can do "remember (something) as name", which can help in induction to eliminate impossible cases [Mon Mar 2 04:09:43 2015] I bet that's not the intended solution. I have no idea what the {struct len} syntax means. [Mon Mar 2 04:10:32 2015] I don't know there were other exercises where I had to define Lemmas that were actual later exercises [Mon Mar 2 04:11:54 2015] the {struct len} bit tells Coq that len is decreasing, which it can't deduce otherwise (in my proof at least) [Mon Mar 2 04:13:09 2015] And yes, I'd like a simpler proof too, but I saw no workaround [Mon Mar 2 04:13:33 2015] for those reading the log: I'd appreciate any hints on how to do it properly. I'll think about it more later. [Mon Mar 2 04:13:58 2015] The problem is that I wanted induction on both ends of the list, and normal induction on lists only takes away the first element [Mon Mar 2 04:14:48 2015] and the following is obviously false: pal (x::l) -> pal l [Mon Mar 2 04:15:07 2015] I mean pal l -> pal (x::l) [Mon Mar 2 04:30:12 2015] nkar : 1) It's useful to proceed by strong induction on the length of the list. By that I mean stating a theorem such that [forall X n (l : list X), length l < n -> l = rev l -> pal l] [Mon Mar 2 04:30:32 2015] You can then use this theorem to easily prove your rev_pal [Mon Mar 2 04:30:59 2015] 2) Just in case you don't have it, you might need a theorem about length (snoc l v). [Mon Mar 2 04:40:17 2015] Cypi: thank you, I'll try and ask more questions if I get stuck. [Mon Mar 2 16:02:11 2015] I don't really understand how to define a morphism for setoid_rewrite .. [Mon Mar 2 16:02:28 2015] For example with this error message : https://gist.github.com/Choups314/8ea62bbcca90aa9a01cf, what instances are missing ? [Mon Mar 2 16:17:16 2015] yeah, those setoid errors can be confusing [Mon Mar 2 16:17:37 2015] it looks like Proper is missing for ( ==> ==> flip impl) equiv [Mon Mar 2 16:19:09 2015] johnw, If I want to rewrite under binders (i.e. if I have [inj x], where [inj] is an application), what do I need to be able to rewrite [x] with an hypothesis [H : x=y] for example, (where [=] is a custom relation) ? [Mon Mar 2 16:19:40 2015] you want to rewrite inside a lambda? [Mon Mar 2 16:19:59 2015] yes [Mon Mar 2 16:20:21 2015] Well .. not really. [inj] is a defined application (for example [E->E]) [Mon Mar 2 16:20:48 2015] see the manual section titled "Rewriting under binders"? [Mon Mar 2 16:27:57 2015] Sorry if you said something (or not ^^), I have been disconnected >< [Mon Mar 2 16:28:28 2015] i just said: [Mon Mar 2 16:28:30 2015] 15:20 see the manual section titled "Rewriting under binders"? [Mon Mar 2 16:29:02 2015] Ok I saw this, did you have my messages ? [Mon Mar 2 16:29:08 2015] (After yours) [Mon Mar 2 16:29:19 2015] no [Mon Mar 2 16:29:32 2015] "I already read it (you mean chap 26 right ?), but I don't really understand .. [Mon Mar 2 16:29:32 2015] <Choups314> I know I need to add something like [Add Parametric Morphism ... with signature], but I don't really understand what is signature .. [Mon Mar 2 16:29:32 2015] <Choups314> (https://coq.inria.fr/refman/Reference-Manual029.html ?)" [Mon Mar 2 16:29:45 2015] right, that's it [Mon Mar 2 16:29:52 2015] I'm unfortunately no expert on that stuff [Mon Mar 2 17:18:27 2015] Is there any proof assistant that has coq style tactics and induction recursion? [Mon Mar 2 17:19:16 2015] what is induction recursion :-o [Mon Mar 2 17:20:05 2015] its where you define a data type and a recursive function on it together [Mon Mar 2 17:20:34 2015] vanila: idris has induction-recursion, i don't know if that's tactic-y enough though [Mon Mar 2 17:20:54 2015] the tactics stuff is pretty busted in idris [Mon Mar 2 17:20:57 2015] vanila: i am confused [Mon Mar 2 17:21:08 2015] vanila: oh :( i haven't been keeping current [Mon Mar 2 17:21:51 2015] i can't understand edwins motivation.. [Mon Mar 2 17:42:29 2015] does anyone know what papers are relevant to how functional induction schemes work? [Mon Mar 2 22:40:23 2015] johnw: I have a random software foundations question. what's the best solution you've seen to the 5 star "bin_inverse" exercise in Inductiion.v? [Mon Mar 2 23:28:49 2015] jrw: hi [Mon Mar 2 23:28:56 2015] jrw: that's a really simple proof [Mon Mar 2 23:29:02 2015] jrw: I think it's 5 stars because of where the student is at at that point [Mon Mar 2 23:29:07 2015] but the proof itself is induction and two rewrites total [Mon Mar 2 23:33:21 2015] really? huh. [Mon Mar 2 23:45:10 2015] wtf [Mon Mar 2 23:45:15 2015] that was my longest proof ever [Mon Mar 2 23:45:34 2015] wait, let me make sure I'm looking at the right thing [Mon Mar 2 23:45:55 2015] is this the theorem: Theorem bin_conv : forall (n : nat), n = binn (nbin n). [Mon Mar 2 23:46:30 2015] no [Mon Mar 2 23:47:33 2015] or maybe [Mon Mar 2 23:47:35 2015] Theorem nat_to_bin_to_nat : forall n : nat, [Mon Mar 2 23:47:35 2015] bin_to_nat (nat_to_bin n) = n. [Mon Mar 2 23:47:42 2015] ah ok we have different names for that stuff [Mon Mar 2 23:47:56 2015] no wait [Mon Mar 2 23:48:01 2015] that one is still the easy part [Mon Mar 2 23:48:03 2015] the hard one is this: [Mon Mar 2 23:48:14 2015] Theorem bin_to_nat_to_bin : forall n : bin, [Mon Mar 2 23:48:14 2015] nat_to_bin (bin_to_nat n) = normalize n. [Mon Mar 2 23:49:20 2015] huh [Mon Mar 2 23:49:27 2015] that proof is just "reflexivity" for me [Mon Mar 2 23:49:35 2015] Theorem norm_conv : forall (b : bin), normalize b = nbin (binn b). [Mon Mar 2 23:49:39 2015] really? [Mon Mar 2 23:49:45 2015] then you defined normalize through it [Mon Mar 2 23:49:57 2015] well, normalize was a one-liner [Mon Mar 2 23:49:59 2015] i assume you're suppose to define it inductively inside the type [Mon Mar 2 23:50:26 2015] hmm [Mon Mar 2 23:50:32 2015] maybe that's what made it hard? [Mon Mar 2 23:50:35 2015] Fixpoint normalize (n : bin) : bin := [Mon Mar 2 23:50:35 2015] match n with [Mon Mar 2 23:50:35 2015] | P => P [Mon Mar 2 23:50:35 2015] | D m => match (normalize m) with [Mon Mar 2 23:50:35 2015] | P => P [Mon Mar 2 23:50:35 2015] | D g => D (D g) [Mon Mar 2 23:50:35 2015] | E g => D (E g) [Mon Mar 2 23:50:36 2015] end [Mon Mar 2 23:50:36 2015] | E m => E (normalize m) [Mon Mar 2 23:50:37 2015] end. [Mon Mar 2 23:50:39 2015] that's my def [Mon Mar 2 23:51:00 2015] ah, I used: Definition normalize (b : bin) : bin := nbin (binn b). :) [Mon Mar 2 23:51:00 2015] if you're supposed to go through nat, i finally understand why the exercise is at that early point [Mon Mar 2 23:51:17 2015] which is why the proof is trivial [Tue Mar 3 02:16:21 2015] Cypi: I'm not looking at the lemma you suggested: [forall X n (l : list X), length l < n -> l = rev l -> pal l] and I don't get it. how can length l be less than n forall l and n? it doesn't hold for, say, l := [1] and n := 0. [Tue Mar 3 02:18:42 2015] s/not/now/ [Tue Mar 3 02:31:41 2015] that's not what that says [Tue Mar 3 02:31:55 2015] okay, what does it say? [Tue Mar 3 02:32:55 2015] length l < n implies l = rev l implies pal l, right? [Tue Mar 3 02:34:00 2015] still, I'm failing to grasp the use of forall in this context [Tue Mar 3 02:40:27 2015] my internet connection to the server where irssi is running is flaky [Tue Mar 3 02:40:53 2015] but the overall idea is that it's easier to do induction on (length l) for this theorem [Tue Mar 3 02:42:01 2015] because for a list you normally the property rev (x::xs) = x::xs does not imply rev xs = xs [Tue Mar 3 02:42:22 2015] and you need to preserve that property [Tue Mar 3 02:42:43 2015] at least that's how I remember it [Tue Mar 3 02:44:04 2015] well, but this doesn't answer the initial question. how would you translate this definition to english? in particular, what does forall l n, length l < n mean? [Tue Mar 3 02:44:10 2015] whereas in the (length l) < n you can add to both ends of the list [Tue Mar 3 02:44:39 2015] for all lists l, and numbers n, lenght l is smaller than n [Tue Mar 3 02:44:48 2015] but you shouldn't stop reading there [Tue Mar 3 02:45:36 2015] the full statement is: forall...., if (length l < n) then (if l = rev l then pal l) [Tue Mar 3 02:46:20 2015] okay, got it [Tue Mar 3 02:46:59 2015] though, I don't see how it's connected to being able to add to both ends of the list. [Tue Mar 3 02:47:13 2015] it trivially holds for a list of length 0 and 1 [Tue Mar 3 02:47:13 2015] (I understand why we care about adding to both ends) [Tue Mar 3 02:49:24 2015] and how does that property follow from this? [Tue Mar 3 02:50:12 2015] because you assume it's true for all lists of smaller length [Tue Mar 3 02:53:07 2015] including lists that are 2 elements sho [Tue Mar 3 02:53:07 2015] . [Tue Mar 3 02:53:08 2015] . [Tue Mar 3 03:03:49 2015] Bah, I hate this connection [Tue Mar 3 03:04:43 2015] Anyway, the important part is that with induction on list length you can reduce your list of length n+1 to a list of lengtt n-1 [Tue Mar 3 03:09:21 2015] irishsultan: I'll just try to prove it/play around instead of asking further questions. [Tue Mar 3 03:09:26 2015] thanks for your help! [Tue Mar 3 03:21:57 2015] irishsultan: so, how is this useful? http://dpaste.com/0FQEM32 n is not referenced anywhere and induction doesn't generate anything useful. [Tue Mar 3 03:32:34 2015] that's where the other trick I learned from cheating helped [Tue Mar 3 03:32:52 2015] remember(length xs = len) [Tue Mar 3 03:32:59 2015] then you can do induction on len [Tue Mar 3 03:33:08 2015] what does it do? [Tue Mar 3 03:33:39 2015] correction, remember(length xs) as len [Tue Mar 3 03:34:03 2015] it adds a new variable len:nat and a hypothesis (length xs = len) [Tue Mar 3 03:34:23 2015] if you do induction on len then you will still have your length that can be used [Tue Mar 3 03:35:33 2015] this does the same: induction (length xs) eqn:foo. [Tue Mar 3 03:35:42 2015] ah, good to know [Tue Mar 3 03:35:44 2015] eqn was introduced in the book [Tue Mar 3 03:35:51 2015] but not with induction [Tue Mar 3 03:36:02 2015] yeah, but some things I missed. You can also use it with remember [Tue Mar 3 03:37:03 2015] if the time between referencing a new tactic/trick and needing it is too long then I'll probably miss it [Tue Mar 3 03:39:41 2015] and curse when I finally need it [Tue Mar 3 03:39:55 2015] or feel guilty about referencing the manual [Tue Mar 3 03:58:54 2015] nkar : I would have just done an induction on n, not on (length l), just because it's simpler to me [Tue Mar 3 04:01:22 2015] and actually it seems necessary [Tue Mar 3 04:34:40 2015] ah, you are probably right, as I said I did it in a different way [Tue Mar 3 04:34:55 2015] I'm going to try it with the induction and other new knowledge though [Tue Mar 3 11:16:56 2015] jstolarek pasted “No title” at http://lpaste.net/121501 [Tue Mar 3 11:17:05 2015] I'm trying to understand this simple proof [Tue Mar 3 11:17:20 2015] but I think I don't understand how destruct tactic works [Tue Mar 3 11:18:44 2015] I mean I'm looking at the reference manual but I still don't get it :-/ [Tue Mar 3 11:24:40 2015] jstolarek: try destruct on a natural number [Tue Mar 3 11:27:50 2015] you have two constructors: Inductive nat : Set := | O : nat | S : nat -> nat. so for each of them the goal of the current proof (say it is P) will be duplicated. additionally you get all "contents" of the datatype (i.e. constructor arguments) in your current proof context [Tue Mar 3 11:29:01 2015] so for the O case, you just have to prove P and for the S case you have to prove P given a natural number that was passed to S (i.e. the predecessor o the number you called destruct on) [Tue Mar 3 11:29:23 2015] I need a moment to digest that [Tue Mar 3 11:30:08 2015] ok, I still don't follow :-/ [Tue Mar 3 11:30:13 2015] I mean it must be really trivial [Tue Mar 3 11:30:33 2015] I just have problems with understanding this in Coq [Tue Mar 3 11:30:47 2015] first of all, how would I call destruct on a nat? [Tue Mar 3 11:31:16 2015] if your nat is n and you are in proof mode, you say destrcut n. [Tue Mar 3 11:31:25 2015] *destruct [Tue Mar 3 11:33:01 2015] It's basically a case analysis in maths: "I have a natural number, there are two possible cases : it must be either 0, or the successor of another natural number. If it's 0 then . If it's (S n') then ." [Tue Mar 3 11:33:25 2015] JanBessai pasted “predecessor destruct” at http://lpaste.net/121502 [Tue Mar 3 11:34:17 2015] hm... why does Definition have a proof? [Tue Mar 3 11:34:53 2015] try "Print pred." [Tue Mar 3 11:35:15 2015] then you will see that the proof gets compiled into a lambda function [Tue Mar 3 11:36:21 2015] it is also informative to see what destruct does - it will create a pattern match on the natural number n [Tue Mar 3 11:36:39 2015] give me a moment to play woth this [Tue Mar 3 11:36:49 2015] jstolarek : Definition, Theorem, Lemma, Example, Corollary are just so many keywords for basically the same thing : you are constructing a term which has a given type. If you do it with tactics or directly in Gallina, it's up to you. [Tue Mar 3 11:38:11 2015] ok, so if I write Definition but give only a type, not the body - like JanBessai did with pred - the Coq insists that I construct a proof, ie. create a term of that type [Tue Mar 3 11:38:14 2015] correct? [Tue Mar 3 11:38:20 2015] Yes, that’s correct. [Tue Mar 3 11:45:24 2015] ok, I see how pred works [Tue Mar 3 11:45:51 2015] but I still can't figure out the answer for my original question: http://lpaste.net/121501 :-/ [Tue Mar 3 11:47:19 2015] In this case, you're destructing something of the type [P /\ Q] [Tue Mar 3 11:47:27 2015] jstolarek: you should first perhaps use intro [Tue Mar 3 11:47:29 2015] Which is just a notation for [and P Q] [Tue Mar 3 11:47:37 2015] Inductive and (A B : Prop) : Prop := conj : A -> B -> and A B [Tue Mar 3 11:47:38 2015] in order to name the thing you get [Tue Mar 3 11:47:45 2015] ok, how do I know that 1 refers to /\ ? [Tue Mar 3 11:48:19 2015] destruct 1. is the same as: intro. destruct H. [Tue Mar 3 11:48:20 2015] I think that 1 refers to the first unnamed hypothesis [Tue Mar 3 11:48:32 2015] 1 refers to the first non-dependent product :-° [Tue Mar 3 11:48:45 2015] see [intros until num] [Tue Mar 3 11:50:01 2015] ok [Tue Mar 3 11:50:12 2015] then why does destruct H0 finish the proof? [Tue Mar 3 11:51:16 2015] because there are no way to construct False [Tue Mar 3 11:52:08 2015] so it solves the current goal, and replaces it with new goals for all constructors of False [Tue Mar 3 11:52:23 2015] which means no more goals [Tue Mar 3 11:54:25 2015] I'm not sure what "it solves the current goal" means, but that sounds like a tactic to finish any proof. Obviously what I just said is false, so again I'm not understanding something [Tue Mar 3 11:55:54 2015] That is a way to finish any proof, if False is a hypothesis you can prove anything [Tue Mar 3 11:56:52 2015] note that in this case you could have used the assumption tactic [Tue Mar 3 11:57:15 2015] or "exact H0." [Tue Mar 3 11:57:43 2015] ah, ex falso sequitur quodlibet [Tue Mar 3 11:58:09 2015] Exactly. There is even a tactic called "exfalso" which replaces the current goal with False :p [Tue Mar 3 12:01:55 2015] all of this will take some time for me to digest [Tue Mar 3 12:02:59 2015] changing the topic, but just slightly: [Tue Mar 3 12:03:11 2015] I recall hearing abou a thing called "proof irrelevance" [Tue Mar 3 12:04:06 2015] IIRC this meant that if I have two proofs of some fact then these proofs are interchangable [Tue Mar 3 12:04:11 2015] not sure it that's correct? [Tue Mar 3 12:07:53 2015] Hoping you don't find this answer lazy: https://coq.inria.fr/faq#proof-irrelevance [Tue Mar 3 12:09:29 2015] that's a very good answer [Tue Mar 3 12:09:32 2015] "proof-irrelevance is inconsistent in Set" [Tue Mar 3 12:09:40 2015] that was the question I was about to ask [Tue Mar 3 12:10:01 2015] I mean that is the answer for the question I was about to ask :-) [Tue Mar 3 12:11:07 2015] it is also to be taken with a grain of salt in the real world. since proofs are terms are lambda functions, they may differ in the time you need to execute (normalize) them to the degree that execution theoretically terminates, but practically fails [Tue Mar 3 12:11:53 2015] Except that terms living in Prop are not supposed to be reduced in the case of Coq, since there are meant to be erasable when you are extracting code. [Tue Mar 3 12:12:02 2015] s/there/they/ [Tue Mar 3 13:12:16 2015] jstolarek pasted “No title” at http://lpaste.net/121509 [Tue Mar 3 13:12:25 2015] another question [Tue Mar 3 13:12:54 2015] why does or_x_t''' get the type: forall x : Prop, x \/ True [Tue Mar 3 13:12:57 2015] and not [Tue Mar 3 13:13:08 2015] (x : Prop) -> x \/ True [Tue Mar 3 13:13:09 2015] ? [Tue Mar 3 13:14:58 2015] [(x : Prop) -> x \/ True] is not valid syntax. However, to make a parellel, writing [Prop -> Prop] is the same as writing [forall (_ : Prop), Prop] [Tue Mar 3 13:16:03 2015] Arrow type and forall are quite the same thing, the difference is that when you write [A -> B], you cannot make B depend on the actual value of type A. But when you write [forall (x : A), B], you can mention the value x in the return type B. [Tue Mar 3 13:16:07 2015] (not sure if that makes senses) [Tue Mar 3 13:16:10 2015] (-s) [Tue Mar 3 13:16:59 2015] yes, it does [Tue Mar 3 13:17:16 2015] from what you're saying it looks that this is only a design choice [Tue Mar 3 13:17:30 2015] I mean Agda uses the notation (x : Prop) -> x \/ True [Tue Mar 3 13:18:00 2015] Coq uses a different notation, but I don't see a fundamental difference between the two [Tue Mar 3 13:30:50 2015] jstolarek pasted “No title” at http://lpaste.net/121510 [Tue Mar 3 13:31:06 2015] I would expect that Eval will result in "1 : nat: [Tue Mar 3 13:31:15 2015] but I instead get "const' 0 1 : nat" [Tue Mar 3 13:31:24 2015] looks that const' is not simplified. Why [Tue Mar 3 13:31:25 2015] ? [Tue Mar 3 13:31:45 2015] [Eval compute in const' 0 1.] [Tue Mar 3 13:31:53 2015] The simpl tactic is not agressive enough in this case [Tue Mar 3 13:32:49 2015] hm... why? [Tue Mar 3 13:34:20 2015] You can read the documentation about simpl to know exactly why. But basically, simpl won't unfold a definition if it cannot then do βι-reduction [Tue Mar 3 13:38:01 2015] jstolarek pasted “No title” at http://lpaste.net/121511 [Tue Mar 3 13:38:11 2015] ok, another one :-D [Tue Mar 3 13:38:19 2015] clearly the functions are slightly different [Tue Mar 3 13:38:34 2015] one has inferred arguments, the other does not [Tue Mar 3 13:38:48 2015] but Print prints the same code for them :-/ [Tue Mar 3 13:39:34 2015] Why would it print something different? If you do not provide every types, Coq will try to infer what he can from what you told him and generate a complete definition. [Tue Mar 3 13:40:01 2015] So yes, in the second case, the fact that A and B are of type Type has been inferred, but it doesn't matter after the definition. [Tue Mar 3 13:40:58 2015] The fact that Coq infers Type is debattable of course, maybe you meant Set or Prop, but that's what it does in this case. [Tue Mar 3 13:42:16 2015] well, when I call const' I have to explicitkly give all the arguments [Tue Mar 3 13:42:23 2015] whereas in const'' some can be inferred [Tue Mar 3 13:42:34 2015] so somehow I expected that the code will somehow differ [Tue Mar 3 13:42:38 2015] Ah, for this the difference is the fact that you used curly braces { } instead of parentheses ( ) [Tue Mar 3 13:42:45 2015] yes, I know [Tue Mar 3 13:43:15 2015] but somehow I thought that Print gives me some kind of "internal representation" of what I wrote [Tue Mar 3 13:43:37 2015] and I thought that inferred arguments will be explicitly marked [Tue Mar 3 13:43:49 2015] just like they are marked in the source code using { } [Tue Mar 3 13:44:34 2015] Print prints the Gallina term that defines your variable. [Tue Mar 3 13:45:02 2015] In addition, it provides some information such as what arguments will be inferred, this is what the "Arguments A, B are implicit and maximally inserted" is for [Tue Mar 3 13:45:15 2015] ok [Tue Mar 3 13:45:36 2015] I guess I understand that. It's just that somehow I expected something different :-D [Tue Mar 3 13:46:08 2015] eh :) [Tue Mar 3 13:47:38 2015] perhaps my confusion comes from me being used to Agda [Tue Mar 3 13:48:41 2015] Maybe, I never used Agda :p [Tue Mar 3 15:37:20 2015] Hi! Is it possible to export implicit types beyond the scope of a .v file? [Tue Mar 3 20:11:18 2015] hmm.. is Fixpoint necessary, [Tue Mar 3 20:11:29 2015] couldnt you use induction principles only and have those primitive [Tue Mar 3 20:11:39 2015] i guess that's a less natural primitive part? [Tue Mar 3 20:13:00 2015] benzrf: Fixpoint is vernacular syntactic sugar over [fix] [Tue Mar 3 20:14:38 2015] how does fix work [Tue Mar 3 20:14:50 2015] and i suppose i mean recursive definitions in general [Tue Mar 3 20:26:26 2015] benzrf: what do you mean? fix let's you do recursion. if you understand Fixpoint you understand fix [Tue Mar 3 20:27:24 2015] hh [Tue Mar 3 20:27:25 2015] hm [Tue Mar 3 20:27:28 2015] ok [Wed Mar 4 11:36:21 2015] Hi everyone. I've just started toying with Galina, and I see the `Fixpoint` pragma used for recursive definitions. Now, is there also a `Coinductive` pragma for defining coinductive data types? It doesn't sound possible to me, but if it is, would the Fixpoint take the greatest-fixed mapping, while inductive data would take the least fixed mapping? [Wed Mar 4 11:37:41 2015] There are CoInductive and CoFixpoint vernacular commands, but I’m sufficiently unfamiliar with them that I can’t meaningfully answer your second question. [Wed Mar 4 11:45:42 2015] alkabetz: Ahh okay, thank you! [Wed Mar 4 12:47:45 2015] I've been watching the software foundations lectures by B.C.Pierce, and he alluded to haskell programs being /automatically/ created from coq ones. Is this true? [Wed Mar 4 12:49:20 2015] Yes, that's called extraction: https://coq.inria.fr/refman/Reference-Manual025.html [Wed Mar 4 13:26:59 2015] pierce has lectures? [Wed Mar 4 13:40:59 2015] hodapp: https://www.youtube.com/watch?v=KKrD4JcfW90&list=PLGCr8P_YncjUT7gXUVJWSoefQ40gTOz89&index=1 [Wed Mar 4 13:41:06 2015] Cypi: Thank you :) [Wed Mar 4 13:42:57 2015] athan: thanks! [Wed Mar 4 13:43:05 2015] :) [Wed Mar 4 16:04:27 2015] To be able to rewrite under binders/application, I have to define an instance of Proper for all the applications ? [Wed Mar 4 17:11:16 2015] can I somehow make coq compute an opaque function? [Wed Mar 4 17:47:57 2015] compute in what sense, just get an answer from it? [Wed Mar 4 17:48:15 2015] i'm not sure you can see what the answer is though [Wed Mar 4 20:40:05 2015] This is probably a basic question, but what's the best way to lex some simple assembly in Coq? [Wed Mar 4 20:40:31 2015] Basically, if I were trying to lex textual MIPS assembly [Wed Mar 4 20:53:26 2015] write recursive definitions [Wed Mar 4 20:53:28 2015] ? [Wed Mar 4 20:53:45 2015] and maybe combinators? [Wed Mar 4 20:54:04 2015] (at least that's what I have done so far) [Thu Mar 5 07:26:55 2015] does Coq have any way of inferring that a given function is injective, or do I have to prove it by myself? [Thu Mar 5 07:40:13 2015] you have to prove it yourself [Thu Mar 5 07:42:13 2015] and then appeal to it explicitly whenever it is needed to make progress? [Thu Mar 5 07:44:19 2015] yes, although I guess there are ways to automate it [Thu Mar 5 07:44:25 2015] haven't really done that yet [Thu Mar 5 07:44:42 2015] which function do you need it for? [Thu Mar 5 07:47:19 2015] none :-) Just curious [Thu Mar 5 09:43:29 2015] Check app_nil_end. tells me: [Thu Mar 5 09:43:39 2015] app_nil_end : forall (A : Type) (l : list A), l = l ++ nil [Thu Mar 5 09:43:58 2015] then I use app_nil_end like this: [Thu Mar 5 09:44:14 2015] rewrite (app_nill_end (some_expr)) [Thu Mar 5 09:44:42 2015] why is the first argument to app_nil_end omitted in this call to rewrite? [Thu Mar 5 09:49:21 2015] jstolarek: if an arugment's type contains a previous type in a function signature, it can always be inferred. [Thu Mar 5 09:49:52 2015] list A contains A, so you don't have to write A before you give your expression that is a list A [Thu Mar 5 09:51:09 2015] ha, brilliant [Thu Mar 5 09:51:16 2015] so this means that if I have [Thu Mar 5 09:51:36 2015] It can be a little frustrating if you like to partially apply functions, because the implicit arguments must be inferred from the arguments. You have to supply missing types by using the "uninferring form" of a function name, which has the @ prefix. [Thu Mar 5 09:52:07 2015] jstolarek: are you working through software foundations? [Thu Mar 5 09:52:10 2015] foo : forall (A : Type) (... : A) (B : Type) (... : B), ... then I can call foo with only 2nd and 4th argument? [Thu Mar 5 09:52:24 2015] no, CPDT [Thu Mar 5 09:53:00 2015] ianjneu: I'm afraid I don't understand that last part [Thu Mar 5 09:53:08 2015] jstolarek: yes, as long as your Coq environment has executed Set Implicit Arguments. [Thu Mar 5 09:54:22 2015] jstolarek pasted “No title” at http://lpaste.net/121777 [Thu Mar 5 09:54:29 2015] ok, one more question [Thu Mar 5 09:54:42 2015] why tbinop' (second definition) can't be in Set [Thu Mar 5 09:54:46 2015] ? [Thu Mar 5 09:55:00 2015] Say you want to pass a partially applied foo to a higher-order function. If the type ordering were foo : forall (A B : Type) (... : A) (... : B)) and you want to just pass the A, the B would be orphaned. You'd have to supply it via (@foo _ some-b-type my-A-expr) [Thu Mar 5 09:55:28 2015] ianjneu: that makes sense. thanks. [Thu Mar 5 09:57:01 2015] "Type" is subject to what is technically called "typical ambiguity," meaning it really stands for Type_i, where i is some universe level to be figured out by an underlying constraint solver to ensure you don't try to construct the Burali-Forti paradox [Thu Mar 5 09:57:23 2015] The universe levels go Prop < Set < Type_0 < Type_1 < ... [Thu Mar 5 09:58:09 2015] Set is there mostly historically, but it's also nice to ensure you don't accidentally make "large" constructions, i.e., require going up a universe level. [Thu Mar 5 09:58:21 2015] looks like this is above my paygrade :-( [Thu Mar 5 09:59:02 2015] jstolarek: nah, typical ambiguity is ambiguous because it usually can be ignored. Don't worry about it. [Thu Mar 5 09:59:35 2015] If you're jgross and trying to formalize category theory and "the category of categories" then it slaps you in the face. [Thu Mar 5 10:00:32 2015] :-) [Thu Mar 5 10:01:13 2015] jstolarek: academia is full of, "CITE ME CITE ME" so easy concepts are given foreboding-sounding names. The Burali-Forti paradox is a restatement of Russell's paradox (ha) in the language of mumble mumble it doesn't matter. It breaks shit. [Thu Mar 5 10:02:26 2015] ok :-) [Thu Mar 5 18:55:56 2015] yes hello i am having an utterly infuriating issue [Thu Mar 5 18:56:25 2015] http://benzrf.benzrf.com/imgs/90a46b.png [Thu Mar 5 19:20:49 2015] please help ;-; [Thu Mar 5 19:24:07 2015] benzrf: try [Set Printing All] and then try the rewrite again to get a longer (not necessarily better...) error message [Thu Mar 5 19:26:36 2015] Found no subterm matching "@cons Type T0 [Thu Mar 5 19:26:38 2015] (@Datatypes.app Type e (@cons Type T t))" in X. [Thu Mar 5 19:26:42 2015] X [Thu Mar 5 19:26:44 2015] : lam (@cons Type T0 (@Datatypes.app Type e (@cons Type T t))) A0 [Thu Mar 5 19:27:21 2015] jrw: i see nothing particularly helpful here [Thu Mar 5 19:27:30 2015] * grinds his teeth [Thu Mar 5 19:32:07 2015] benzrf: if you can post some code I can take a look [Thu Mar 5 19:32:22 2015] hng [Thu Mar 5 19:32:27 2015] im ashamed [Thu Mar 5 20:46:42 2015] hmmm [Thu Mar 5 20:47:13 2015] if a constructor uses the same thing twice, how do i recover the implied equality when i match on that ctor [Thu Mar 5 20:47:16 2015] e.g. [Thu Mar 5 20:47:30 2015] constr : forall n : nat, foo n n [Thu Mar 5 20:48:12 2015] then later, | constr n => (* somehow can use knowledge that a = b, where my input was of type foo a b *) [Fri Mar 6 12:31:14 2015] hello. hm, something that frequently happens to me is that I have some theorem about fin's that can just be calculated. in most cases I can hack around with 'do' and 'repeat'. is there any better way? [Fri Mar 6 13:03:20 2015] what is 'do' [Fri Mar 6 13:10:56 2015] benzrf: repeat n times. [Fri Mar 6 13:11:26 2015] is that important? [Fri Mar 6 13:12:04 2015] anyway .. also, I thought the semantics of (A || B) was to try out A, and if it fails, try B [Fri Mar 6 13:14:37 2015] apparently it is not. [Fri Mar 6 13:14:44 2015] so ... what _does_ it do? [Fri Mar 6 13:47:34 2015] schoppenhauer: I thought that's what it did also [Fri Mar 6 13:47:57 2015] hm. it does. but it interferes with tactics that produce goals strangely [Fri Mar 6 13:48:28 2015] johnw: is there a "solve" for just one tactic? eG a tactic that that checks whether the next expression solves, and if not, fails? [Fri Mar 6 13:48:43 2015] solve (tactic)? [Fri Mar 6 13:52:40 2015] hm. ok. [Fri Mar 6 13:54:18 2015] seems legit [Fri Mar 6 14:11:53 2015] Hi, is it possible to define "dependent tactics" (Ltac) ? [Fri Mar 6 14:57:07 2015] where can I see the output of idtac "..."? [Fri Mar 6 16:45:51 2015] How can I nest a square bracket "[" into a latex documentation ? (for coqdoc) [Fri Mar 6 16:45:54 2015] The brackets "[" have higher priority (And it then generates coq documentation) .. [Sat Mar 7 06:02:08 2015] hello. is it possible to extract to coq functions with proofs that these functions really realize the given theorem? [Sat Mar 7 06:17:02 2015] extract from where? [Sat Mar 7 06:17:21 2015] if you're extracting *to* coq, that would have to be the case [Sat Mar 7 06:56:05 2015] johnw: I have a proposition forall x, exists y, some_prop (x, y) and I want a function f and a proof forall x, y, f (x) = y <-> some_prop (x, y) [Sat Mar 7 12:06:13 2015] Hi, is it possible to set an automatic coercion from a "full" sigma type to the type itself ? (i.e. a sigma type like { x | True}) ? [Sat Mar 7 12:36:44 2015] ianjneu pasted “Coerce raises anomaly” at http://lpaste.net/123443 [Sat Mar 7 13:01:08 2015] How can I define a "full sig type" ? [Sat Mar 7 13:01:40 2015] I'm doing something like {x | True}, but I don't think it is the better solution [Sat Mar 7 13:14:22 2015] Choups314: I don't know what you mean by full. [Sat Mar 7 13:15:10 2015] ianjneu, Every elements of the subset belong to the "super"set [Sat Mar 7 13:15:15 2015] Could you define it simply as your correctness criteria that {x | True} is isomorphic to x? [Sat Mar 7 13:15:30 2015] er, {x | P x} [Sat Mar 7 13:15:52 2015] {x : A | P x} \cong A [Sat Mar 7 13:16:16 2015] The problem is that I need a {x | P x} type [Sat Mar 7 13:17:16 2015] I defined a class that takes a parameter of type {x | P x}. Now I would like to use this class with a "full"subset [Sat Mar 7 13:17:26 2015] I don't know how to explain it :p [Sat Mar 7 13:18:17 2015] I defined a math subgroup (algebraic substructure). And I would like for example to prove that R (the reals) is a subgroup of R [Sat Mar 7 13:18:34 2015] So the second R (the subgroup) must be a sigma type :/ [Sat Mar 7 13:19:03 2015] And what's breaking? [Sat Mar 7 13:20:01 2015] Well .. it works but it's really heavy I think :/ (To use something like {x | True}) [Sat Mar 7 13:20:22 2015] That's the double-edged sword of abstraction. [Sat Mar 7 13:20:38 2015] :p [Sat Mar 7 13:21:06 2015] Then I have to unfold/prove everything of the class, while it's obvious that everything is True .. [Sat Mar 7 13:21:42 2015] That should all be automatable. [Sat Mar 7 13:21:54 2015] Proof. crush. Qed. [Sat Mar 7 13:22:42 2015] crush ? [Sat Mar 7 13:22:55 2015] CPDT's infamous tactic. [Sat Mar 7 13:23:20 2015] ianjneu why infamous ? [Sat Mar 7 13:24:56 2015] Anarchos: the book forward references so much without a lot of explanation, so you go through several chapters thinking that the lesson has been punted to "magic" [Sat Mar 7 13:25:18 2015] "you" being me and other people I know that have tried working through the book. [Sat Mar 7 13:30:50 2015] ok [Sat Mar 7 13:56:27 2015] ianjneu: my experience with crush is [Sat Mar 7 13:56:46 2015] ianjneu: johnw showed some kind of proof of categoriness or something at hac boston [Sat Mar 7 13:57:07 2015] ianjneu: and then he scrolled down to the final bit and it was 'crush. crush. crush. crush. crush.' or something [Sat Mar 7 14:07:25 2015] benzrf: you're in Boston? [Sat Mar 7 14:09:28 2015] as my nick would suggest, I'm at neu in Boston. [Sat Mar 7 14:10:21 2015] im in maine [Sat Mar 7 14:12:22 2015] ianjneu: i assumed it was 'ian j neu' or something [Sat Mar 7 14:12:24 2015] whats neu [Sat Mar 7 14:12:36 2015] ah [Sat Mar 7 14:13:04 2015] Ian Johnson is my name, ya. [Sat Mar 7 14:13:41 2015] oh [Sat Mar 7 14:14:01 2015] I added the neu since ianj was taken on freenode. [Sun Mar 8 13:23:54 2015] is it possible to capture a [let '] pattern in notation? i'm trying to define notation along the lines of [mylet (a, b, c) x f] for [let '(a, b, c) := x in f]. [Mon Mar 9 11:27:58 2015] schoppenhauer: are you around? [Mon Mar 9 11:28:17 2015] I didn't see your response last time. Do you have any links to your lexing code? [Mon Mar 9 11:29:43 2015] is there a generally accepted best way of getting outside code that you're trying to prove things about into Coq? [Mon Mar 9 11:30:25 2015] I've been looking into different lexing and parsing tools, but pretty much everything is in Ocaml and I don't know of an easy way to either lex and parse in Coq or move lexed/parse Ocaml types and data into Coq [Mon Mar 9 11:36:05 2015] you could axiomatize the function into Coq [Mon Mar 9 11:36:07 2015] prove with those types [Mon Mar 9 11:36:16 2015] and then hook up the axioms to their Ocaml equivalent during extraction [Mon Mar 9 11:42:59 2015] johnw: I understood some of those words. Do you have a reading suggestion where I could learn more about it? [Mon Mar 9 11:44:26 2015] Actually, I think I understood most of it. I'm just unfamiliar with axiomatization [Mon Mar 9 12:37:07 2015] I have an expression like: (let (acc, _) := fac_v2_acc (S (S n)) 1 1 in acc) = [Mon Mar 9 12:37:14 2015] (and more stuff on the other side, ofc) [Mon Mar 9 12:37:25 2015] In my proof, I'm going to use the part on the right side of the := [Mon Mar 9 12:37:29 2015] so can I somehow remove the left part? [Mon Mar 9 12:37:40 2015] i.e. remove: let (acc, _) := [Mon Mar 9 12:38:33 2015] Does my question make sense? [Mon Mar 9 14:13:41 2015] kba: one way would be [destruct (fac_v2_acc (S (S n)) 1 1)] [Mon Mar 9 14:24:52 2015] jrw: that gives me [n0 = S (S n) * (let (acc, _) := fac_v2_acc (S n) 1 1 in acc)] [Mon Mar 9 14:25:06 2015] that doesn't really make it much easier for me to proceed, I think [Mon Mar 9 14:28:47 2015] kba: it looks like fac_v2_acc got unfolded or simplified in the process. you can either do another destruct, or try to unfold it in advance. if you post some code I can take a look [Mon Mar 9 14:32:12 2015] https://gist.github.com/anonymous/d653f3f9b8976dcd31b4 I think this is the relevant parts, jrw [Mon Mar 9 14:44:58 2015] kba: https://gist.github.com/wilcoxjay/76fe679d68f2ee58d5b3 [Mon Mar 9 14:45:10 2015] if you do enough destructs, the lets go away :D [Mon Mar 9 14:45:25 2015] I had to axiomatize your primitive iteration thingie since you didn't include it [Mon Mar 9 14:45:44 2015] you should be able to delete those axioms and replace them with your actual implementation [Mon Mar 9 14:45:58 2015] assuming you have a proof already that primitive iteration meets its spec [Mon Mar 9 14:47:02 2015] woah, ok, there's a lot of stuff in there I don't understand. :p [Mon Mar 9 14:47:05 2015] What are the -'s for? [Mon Mar 9 14:47:13 2015] and the +'s [Mon Mar 9 14:47:53 2015] those are bullets [Mon Mar 9 14:48:06 2015] they're like the "Case foobar" tactics from software foundations [Mon Mar 9 14:48:09 2015] if you're familiar with that [Mon Mar 9 14:48:19 2015] Hm, nope [Mon Mar 9 14:48:25 2015] they separate cases [Mon Mar 9 14:48:33 2015] so you don't get confused about which case you're in [Mon Mar 9 14:48:45 2015] so it's just for aesthetics? [Mon Mar 9 14:49:07 2015] I guess I would say it's more software engineering than aesthetics, but sure [Mon Mar 9 14:49:20 2015] Right [Mon Mar 9 14:49:24 2015] in the same not writing your entire program in main is "just aesthetics" [Mon Mar 9 14:49:44 2015] indeed [Mon Mar 9 14:50:54 2015] I'm not sure I follow whatever you're doing, especially since there is no H that I can destruct [Mon Mar 9 14:51:07 2015] But on line 47 [Mon Mar 9 14:51:10 2015] is that where you start on fac_v2 (S (S n)) = S (S n) * fac_v2 (S n)? [Mon Mar 9 14:51:27 2015] yeah [Mon Mar 9 14:51:45 2015] the H I destruct is an artifact of the axiomitization of your primitive iteration [Mon Mar 9 14:51:51 2015] you should be able to get rid of it [Mon Mar 9 14:51:57 2015] right [Mon Mar 9 14:52:01 2015] then later whenever i rewrite by Hz or Hs [Mon Mar 9 14:52:14 2015] you'll need to have lemmas about primitive iteration to put in there [Mon Mar 9 14:52:33 2015] what lemmas? [Mon Mar 9 14:52:43 2015] lemmas to unfold the definition? [Mon Mar 9 14:52:45 2015] that your definition of primitive iteration meets the spec you gave me [Mon Mar 9 14:52:47 2015] yeah [Mon Mar 9 14:52:54 2015] right, I do have that [Mon Mar 9 14:57:01 2015] so what is H here? What can I substitute it with? I'm having a hard time being able to understand what I'm looking at with all this unfolding [Mon Mar 9 14:57:07 2015] it's just two big blops to me now :p [Mon Mar 9 14:58:45 2015] yeah, I mean this probably isn't the right way to structure the proof [Mon Mar 9 14:58:54 2015] but it can be done this way [Mon Mar 9 15:01:53 2015] Can you explain the [repeat match goal with] thingy? [Mon Mar 9 15:02:02 2015] What is it you're destructing? [Mon Mar 9 15:04:11 2015] that looks for all occurences of a "let" and destructs the thing to the right of the ":=" [Mon Mar 9 15:04:22 2015] you can get rid of it and do it by hand [Mon Mar 9 15:06:52 2015] * is idle: eating [Mon Mar 9 15:10:50 2015] jrw: I don't get it. What is being destructed? Can you give an example? What is to the right of := is for instance [pair in (acc * y, S y)) n] [Mon Mar 9 15:10:57 2015] that can't be destructed [Mon Mar 9 15:11:17 2015] I mean between the ":=" and the "in" [Mon Mar 9 15:13:09 2015] yeah, the line is let (acc, y) := pair in (acc * y, S y)) n in [Mon Mar 9 15:13:13 2015] so that's what I did [Mon Mar 9 15:13:16 2015] unless you mean destruct pair [Mon Mar 9 15:14:22 2015] but that doesn't make much sense to me either, jrw [Mon Mar 9 15:16:11 2015] yeah, you want to destruct pair [Mon Mar 9 15:18:46 2015] I'm not sure how to do that, "Error: Cannot infer the implicit parameter A of pair." [Mon Mar 9 15:18:51 2015] That would be acc, no? [Mon Mar 9 15:19:03 2015] haha, what? [Mon Mar 9 15:19:13 2015] I'm confused. [Mon Mar 9 15:19:17 2015] Not as much as I [Mon Mar 9 15:19:26 2015] I'm trying to turn the code you gave me into something I understand [Mon Mar 9 15:19:32 2015] I have no clue how to destruct pair [Mon Mar 9 15:19:34 2015] it's just a tuple [Mon Mar 9 15:19:43 2015] can you post what you have? [Mon Mar 9 15:20:00 2015] preferably including the implementation of primitive_iteration [Mon Mar 9 15:20:14 2015] and whatever lemmas you have about it [Mon Mar 9 15:23:39 2015] okay, I put everything that's used together https://gist.github.com/anonymous/4871317c6c1e3bd9b75b [Mon Mar 9 15:24:37 2015] unfortunately I have to go [Mon Mar 9 15:24:40 2015] I'll be back in about an hour [Mon Mar 9 15:24:45 2015] ah, ok [Mon Mar 9 15:24:48 2015] thanks for the help so far [Mon Mar 9 16:38:13 2015] kba: I commented on that gist ( https://gist.github.com/anonymous/4871317c6c1e3bd9b75b ) [Mon Mar 9 16:38:26 2015] note that I'm using coq 8.5, so the lemmas may have changed names [Mon Mar 9 16:38:31 2015] but the destruct should be right [Mon Mar 9 16:43:31 2015] I finished it using another method; the other stuff seemed like a blind alley ;) [Mon Mar 9 16:43:37 2015] but thanks [Mon Mar 9 18:39:16 2015] Hello. [Mon Mar 9 18:39:17 2015] What is good introduction to inductives implementation technics? [Tue Mar 10 06:48:04 2015] Hi [Tue Mar 10 06:48:31 2015] What is the way for me to get rid of all the 'exact L's? https://gist.github.com/co-dan/2273b3331292369edee2 [Tue Mar 10 07:51:02 2015] notdan: repeat (apply L) seems to work well... [Tue Mar 10 07:53:09 2015] well, only one (apply L)is sufficient [Tue Mar 10 07:53:19 2015] but I will still have to sprinkle that all over the place? [Tue Mar 10 07:53:50 2015] I just don't understand, why can't it find L itself? [Tue Mar 10 07:58:13 2015] Cale: i think i might have to rework my definition of a lattice, but I am not sure [Tue Mar 10 07:58:30 2015] I mean, you can use that in place of the command before it :) [Tue Mar 10 07:58:50 2015] apply is smart enough to work out which part of the record you need, it seems [Tue Mar 10 08:01:25 2015] oooh [Tue Mar 10 08:01:27 2015] wow [Tue Mar 10 08:01:28 2015] Cale pasted “shorter at least” at http://lpaste.net/124379 [Tue Mar 10 08:01:34 2015] I can solve all the goals with just apply L [Tue Mar 10 08:01:37 2015] haha this is great [Tue Mar 10 08:01:38 2015] thanks Cale [Tue Mar 10 08:02:05 2015] and it looks like we can factor even more out... [Tue Mar 10 08:03:26 2015] Cale revised “shorter at least”: “No title” at http://lpaste.net/124379 [Tue Mar 10 08:03:39 2015] now... [Tue Mar 10 08:09:29 2015] What about this to finish it off? http://lpaste.net/124381 [Tue Mar 10 08:09:34 2015] (bit ugly as it says...) [Tue Mar 10 08:12:18 2015] ahah that's too hardcore :) [Tue Mar 10 08:14:37 2015] there also seems to be something wrong with my coercion [Tue Mar 10 08:14:47 2015] but I don't know much about those :( [Tue Mar 10 08:16:04 2015] oh, that's cute [Tue Mar 10 08:25:40 2015] Cypi: Could you explain why that fail seems to be required? [Tue Mar 10 08:28:04 2015] If you don't use fail, then the match might use, for example, in the first case : F := join, X := (join x y), Y := z [Tue Mar 10 08:28:30 2015] So, apply (@transitivity ...) will succeed, then the repeat (apply L) will succeed [Tue Mar 10 08:28:45 2015] but at this point, the proof will not be finished, because the wrong choice was made in the first place [Tue Mar 10 08:29:20 2015] however, since we know that the proof could be finished here with the correct choice, adding fail ensures that Coq will try every possible choice until it finds one that completes the proof before the fail [Tue Mar 10 08:29:28 2015] aha, cool [Tue Mar 10 08:30:10 2015] hm I am just not entierly sure what are you talking about [Tue Mar 10 08:30:15 2015] what are F, X, and Y? [Tue Mar 10 08:30:23 2015] match goal with [Tue Mar 10 08:30:23 2015] | [ |- context [?F ?X ?Y] ] => apply (@transitivity _ _ _ _ (F X Y)); repeat (apply L); fail [Tue Mar 10 08:30:23 2015] end. [Tue Mar 10 08:30:49 2015] ah, sorry, I thought you were talking about something else [Tue Mar 10 08:31:26 2015] More intuitively, this would do the same: solve [apply (@transitivity ...); repeat (apply L)] [Tue Mar 10 08:40:21 2015] What do you folks think about the coercion? Why doesn't it work? [Tue Mar 10 08:40:50 2015] sorry, which coercion? [Tue Mar 10 08:41:47 2015] Coercion lattice_ord_alg [Tue Mar 10 08:41:48 2015] : lattice_order >-> lattice_alg. [Tue Mar 10 08:42:10 2015] oh, right, at the end there, hmm [Tue Mar 10 08:42:27 2015] It seems to be accepted, but with a warning [Tue Mar 10 08:44:52 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual021.html seems to describe in more detail what the warning means [Tue Mar 10 08:53:36 2015] what's an inductive product? [Tue Mar 10 08:53:36 2015] [Tue Mar 10 08:55:18 2015] when I try to destruct an inductive definition, I get an error saying that's not an inductive product. [Tue Mar 10 08:55:45 2015] Are you sure that the thing you're trying to destruct is inductively defined? [Tue Mar 10 08:55:48 2015] What is its type? [Tue Mar 10 08:55:49 2015] I expected it to generate n subgoals where n is the number of constructors. [Tue Mar 10 08:55:56 2015] one second [Tue Mar 10 08:56:29 2015] That message usually comes up if you try to apply induction to something which is a function, for example. [Tue Mar 10 08:57:49 2015] Cale: https://gist.github.com/nkaretnikov/3baf1ee07fe0f41646a3 [Tue Mar 10 09:00:55 2015] Cale: and I tried [destruct (pal xs)] in [Theorem rev_pal : forall (X : Type) (xs : list X), xs = rev xs -> pal xs.] [Tue Mar 10 09:01:12 2015] pal is a type constructor [Tue Mar 10 09:01:26 2015] If you had a term of type pal xs, you could destruct it [Tue Mar 10 09:01:40 2015] pal xs : Prop [Tue Mar 10 09:01:54 2015] and Prop is not an inductive type [Tue Mar 10 09:02:53 2015] can I do something to [pal] in order to generate subgoals corresponding to value constructors? [Tue Mar 10 09:04:06 2015] You should be trying to destruct xs to decide which constructor of pal to apply. [Tue Mar 10 09:04:15 2015] I understand that the key here is to destruct xs such that the tail is shown too [Tue Mar 10 09:04:41 2015] Cale: if I just destruct xs, it'll generate (x::xs) in the cons case, which is not enough [Tue Mar 10 09:05:03 2015] well, for sure, you need to use init xs [Tue Mar 10 09:05:10 2015] what's init? [Tue Mar 10 09:05:34 2015] uh, I mean the function which removes the last element [Tue Mar 10 09:07:43 2015] It seems like it would be worthwhile to define the function which removes both the first and last element of a nonempty list and the function which adds an element to both the beginning and end of a list, and prove some lemmas about what happens when you compose them [Tue Mar 10 09:07:47 2015] Cale: I don't seem to have it in scope. and the only way I can define it in Coq (that I know of) is either via Option or by passing the default element in case of []. how can I state something like: length xs > 1 -> head x, for example? [Tue Mar 10 09:08:31 2015] Cale: interesting [Tue Mar 10 09:08:35 2015] Cale: I'll try that [Tue Mar 10 09:08:56 2015] ah, it's called removelast [Tue Mar 10 09:09:03 2015] (it's called init in Haskell) [Tue Mar 10 09:09:32 2015] Cale: yeah, I know haskell. just thought you we're referring to some unknown tactic [Tue Mar 10 09:09:36 2015] were [Tue Mar 10 10:56:01 2015] jstolarek pasted “No title” at http://lpaste.net/124405 [Tue Mar 10 10:56:23 2015] I'm trying to understand the second definition [Tue Mar 10 10:57:00 2015] here's my reasoning: [Tue Mar 10 10:57:34 2015] first argument accepts nat because that's what plus_recursive accepts and returns nat -> nat because that's what plus_recursive returns [Tue Mar 10 10:58:14 2015] question: if plus_recursive took more arguments then the first argument would have to be a fun of more arguments? [Tue Mar 10 10:59:10 2015] second argument (fun m => m) - that I understand [Tue Mar 10 10:59:30 2015] but I'm having trouble wth the third one: (fun _ r m => S (r m)) [Tue Mar 10 11:00:02 2015] what is the first ignored argument? n : nat quantified with forall in the type of nat_rec? [Tue Mar 10 11:02:08 2015] jstolarek revised “No title”: “No title” at http://lpaste.net/124405 [Tue Mar 10 11:06:57 2015] looking at the sugnature of nat_rec I don't see how types match in the last argument... [Tue Mar 10 11:18:20 2015] I am also totally surprised by the Theorem - it seems to compare functions for equality! [Tue Mar 10 11:26:36 2015] jstolarek: given the P argument (fun _ : nat => nat -> nat), the third argument (forall n : nat, P n -> P (S n)) becomes (forall n : nat, (nat -> nat) -> (nat -> nat)) or (forall _ : nat, (nat -> nat) -> nat -> nat) [Tue Mar 10 11:26:51 2015] (fun _ r m => S (r m)) matches _ to the _:nat, r to the nat -> nat, and m to the nat [Tue Mar 10 11:27:45 2015] as for that Theorem... I believe that equality will only work if the functions evaluate to completely equivalent terms. they have to unify as terms, not just act the same way on the same arguments [Tue Mar 10 11:31:08 2015] so it's an unnecessarily strong form of equality, basically saying the functions have exactly the same implementation [Tue Mar 10 11:31:49 2015] after simplification, at least [Tue Mar 10 11:33:10 2015] same up to computational algebra [Tue Mar 10 11:41:19 2015] is there a function that generates the decimal expansion of a nat as a string? [Tue Mar 10 11:44:59 2015] schoppenhauer: yes, of course. [Tue Mar 10 11:45:16 2015] whether it's a standard library function is a different store. [Tue Mar 10 11:45:18 2015] story* [Tue Mar 10 11:46:13 2015] ... [Tue Mar 10 11:49:04 2015] scott: thanks [Tue Mar 10 11:52:59 2015] What's the difference between fix and Fixpoint? [Tue Mar 10 11:54:01 2015] I suspect that Fixpoint is used in places where Vernacular commands are expected (eg. top-level of a source file) [Tue Mar 10 11:54:19 2015] whereas fix is used in places where Gallina terms are expected [Tue Mar 10 11:54:35 2015] but other than that these seem to have exactly the same syntax and sematics [Tue Mar 10 11:54:38 2015] is that correct? [Tue Mar 10 11:57:27 2015] jstolarek: I think Fixpoint is sugar for a Definition involving a fix [Tue Mar 10 12:01:01 2015] yes, it's sugar, but I'm trying to figure out the desugaring :-) [Tue Mar 10 12:06:58 2015] Fixpoint name (p0 : T0) ... (pn : Tn) := body => Definition name := (fix name (p0 : T0) ... (pn : Tn) := body) [Tue Mar 10 12:07:36 2015] or the eta-expansion of that. Not sure. [Tue Mar 10 12:19:35 2015] ianjneu: thanks. That's what I suspected [Tue Mar 10 12:20:00 2015] sometimes the body of fix end with "for name" - I don't get that part yet [Tue Mar 10 14:27:05 2015] OH OH [Tue Mar 10 14:27:20 2015] does rewrite not work right with non Prop s [Tue Mar 10 14:29:33 2015] benzrf: probably. eq_ind expects a family of propositions for a motive, right? [Tue Mar 10 14:32:04 2015] fuck [Tue Mar 10 14:32:11 2015] it doesnt know to use eq_rect ? [Tue Mar 10 14:35:15 2015] ¯\_(ツ)_/¯ [Tue Mar 10 14:36:12 2015] gah [Tue Mar 10 14:36:23 2015] * uses eq_rect manually [Tue Mar 10 14:36:27 2015] I think it does actually. Are you sure it's not something to do with associativity printing ambiguously? [Tue Mar 10 14:36:36 2015] i turned off notation [Tue Mar 10 14:36:46 2015] welp. [Tue Mar 10 15:00:34 2015] oh christ [Tue Mar 10 15:00:52 2015] can i get A = B out of (A -> R) = (B -> R) [Tue Mar 10 15:23:43 2015] no. [Tue Mar 10 15:24:09 2015] I don't think so, anyway. [Tue Mar 10 15:24:18 2015] You should try ##hott :P [Tue Mar 10 15:25:09 2015] R^A = R^B => A = B in standard algebra, but not sure about generally in category theory. [Tue Mar 10 15:25:39 2015] No. That's not right. [Tue Mar 10 15:26:08 2015] If R = 1 , then all you have is 1 = 1 => A = B, which is refutable. [Tue Mar 10 15:32:05 2015] in other words you can't do it because it could be (A -> ()) = (B -> ()) and this doesn't imply A = B because the argument to the function is ignored? [Tue Mar 10 15:33:01 2015] wouldn't A and B have to unify to make that = proof anyway, though? or am I missing something? [Tue Mar 10 15:33:02 2015] in so many words, yes. [Tue Mar 10 15:35:06 2015] scott: for the = proposition, no. [Tue Mar 10 15:35:49 2015] for types A and B, A -> B : Type. So you get (A -> R) = (B -> R) : Type, just like A = B : Type. [Tue Mar 10 15:55:06 2015] ((A -> Type) = (B -> Type)) -> A = B ? [Tue Mar 10 15:55:17 2015] :D [Tue Mar 10 15:57:38 2015] aaaaaargh [Tue Mar 10 15:57:49 2015] this was such a lame idea [Tue Mar 10 15:58:42 2015] in coq doesnt "A = B" mean that they are the same term up to unification [Tue Mar 10 15:59:02 2015] not necessarily even that they are isomorphic [Tue Mar 10 15:59:25 2015] so doesnt (nat -> unit) <> (unit -> unit) [Tue Mar 10 16:03:38 2015] benzrf: MLTT is consistent with HoTT, in which the type A = B is isomorphic to the type of equivalences between A and B (roughly isomorphisms) [Tue Mar 10 16:03:56 2015] a blah [Tue Mar 10 16:04:04 2015] benzrf: But in plain MLTT, you can't prove that [Tue Mar 10 16:04:18 2015] MLTT? [Tue Mar 10 16:04:27 2015] Martin-Löf type theory [Tue Mar 10 16:04:47 2015] hrk [Tue Mar 10 16:04:51 2015] Which is almost but not quite the same as what Coq is... close enough. [Tue Mar 10 16:05:39 2015] is there some kind of connection between co/termination and strict monotonicity [Tue Mar 10 16:06:19 2015] benzrf: the Knaster-Tarski theorem? [Tue Mar 10 16:06:46 2015] Or as a special, simpilified case, Kleene's theorem [Tue Mar 10 16:07:40 2015] Those kinds of termination proofs are the MOST annoying in formal systems. [Tue Mar 10 16:08:28 2015] * applies google [Tue Mar 10 16:16:41 2015] Cale: if HoTT turns out the way people are hoping it turns out, does that mean we'll be able to use isomorphic types more or less interchangeably without friction, or am I misunderstanding the point of univalence? (I'm a pretty amateur type theorist curious how HoTT is expected to impact programming languages) [Tue Mar 10 16:17:06 2015] apologies if I'm asking the wrong person :p [Tue Mar 10 16:18:11 2015] scott: "Without friction" is perhaps a *little* much. There's an explicit operation for using equalities. [Tue Mar 10 16:18:30 2015] because you have to pick which isomorphism to use, right? [Tue Mar 10 16:18:45 2015] You can think of it that way, yeah. [Tue Mar 10 16:19:24 2015] Of course, MLTT is the same in that regard, but equalities of types aren't necessarily the same thing as isomorphisms -- they're just somewhat hard to obtain. [Tue Mar 10 16:20:32 2015] how is that much different from what we can do today? we could already prove isomorphisms and then push things to and from the different types that way [Tue Mar 10 16:20:52 2015] does it just remove a bunch of the plumbing when we can treat isomorphic types as equal? [Tue Mar 10 16:21:07 2015] Well, you get lots of nice little results, for example, one of the most elementary things you can do in the logic is to prove: [Tue Mar 10 16:22:16 2015] for all types A, given x, y : A, and C : A -> Type, and given p : x = y, we have p* : C x -> C y [Tue Mar 10 16:22:41 2015] and later (using univalence), we can actually refine that to C x = C y [Tue Mar 10 16:23:07 2015] So, this means if A is the type of groups, say, and C is some construction depending on a choice of group [Tue Mar 10 16:23:21 2015] then we can turn group isomorphisms into isomorphisms of these C constructions [Tue Mar 10 16:24:35 2015] If C is some property of groups, then this says that the property C respects isomorphism of groups [Tue Mar 10 16:24:56 2015] These are things which we'd have to provide special case proofs for if we were using ZFC, for instance. [Tue Mar 10 16:25:21 2015] ahh, so you can automatically 'upgrade' isomorphisms between things to isomorphisms between things that depend on those things (roughly speaking)? [Tue Mar 10 16:25:26 2015] yeah [Tue Mar 10 16:25:51 2015] e.g. turn isomorphisms of groups into isomorphisms of their group rings [Tue Mar 10 16:26:57 2015] What would be fantastic is a way to separate equalities further along the lines of HTS to bring in a more nuanced view of the more ergonomic OTT. [Tue Mar 10 16:27:11 2015] In ZFC, we often skip the work, but it's formally required to show for every property of groups that we talk about that the property actually respects group isomorphism, and the ZFC proof of that will be different every time, depending on the details of the property. [Tue Mar 10 16:27:58 2015] (of course, nothing special about groups here, I'm just using them as an example) [Tue Mar 10 16:30:25 2015] We use such things all the time in our arguments, and they get in the way of formalisation, because as soon as we want to formalise something in ZFC to the extent that a computer could be convinced, we're faced with a litany of details of this sort where we've implicitly used various isomorphisms to look at our structures a little differently. We're quite good at ignoring them whenever they're sufficiently trivial, but fir [Tue Mar 10 16:30:25 2015] st order logic has no way to deal with them uniformly. [Tue Mar 10 16:31:15 2015] so if we wanted to attempt this in regular Coq... we'd be looking at something like: forall A: Type, x, y: A, C: A -> Type, (x <-> y) -> C x -> C y [Tue Mar 10 16:31:24 2015] and there's just no way to do that for arbitrary C [Tue Mar 10 16:32:08 2015] (x = y) -> C x -> C y [Tue Mar 10 16:32:23 2015] You can do that in Coq [Tue Mar 10 16:32:30 2015] The part you can't do is get C x = C y [Tue Mar 10 16:32:32 2015] yeah, you can do that, but if we wanted to be able to do it without equivalences since we can't upgrade isomorphisms to equivalences [Tue Mar 10 16:32:52 2015] (at least, not without the HoTT stuff) [Tue Mar 10 16:32:57 2015] right [Tue Mar 10 16:34:57 2015] Cale pasted “No title” at http://lpaste.net/124434 [Tue Mar 10 16:35:00 2015] I'm really curious to see where the HoTT stuff goes from here. before I ever heard of it, the "isomorphic types are equivalent" summary of the univalence axiom was sort of already nagging at my brain [Tue Mar 10 16:37:16 2015] one representation might be better than another for computational efficiency, but logically the representation makes no difference [Tue Mar 10 16:37:48 2015] yep [Tue Mar 10 16:37:59 2015] does this tie in to proof irrelevancy? you could prove two forms of proof are equivalent [Tue Mar 10 16:38:10 2015] it like a dream platform for Conal's denotational design [Tue Mar 10 16:38:26 2015] yes, I believe proof irrelevancy comes as a theorem from univalence [Tue Mar 10 16:38:33 2015] Well, if you have x, y : A, and p, q : x = y, then p = q is again a type [Tue Mar 10 16:38:47 2015] cool [Tue Mar 10 16:38:55 2015] which may or may not be inhabited by elements which again may or may not be equal [Tue Mar 10 16:39:00 2015] and so on and so on [Tue Mar 10 16:39:02 2015] I'm very excited to have an environment based on this theory [Tue Mar 10 16:39:32 2015] it will mean designing and coding using the simplest/best abstraction, and allowing the compiler to choose when/where/why to transform between equivalent representations [Tue Mar 10 16:39:33 2015] HoTT pictures x and y as points, and then p and q as paths between those points, and then elements of p = q are 2D sheets connecting those paths [Tue Mar 10 16:39:57 2015] (or maybe I will need to guide it in places, but I needn't always worry about it) [Tue Mar 10 16:40:54 2015] johnw: I'm not sure that's what it'll really mean in most cases -- maybe eventually. [Tue Mar 10 16:41:05 2015] johnw: But right now, you have to explicitly transport [Tue Mar 10 16:41:11 2015] still hard to wrap my head around what is gained... [Tue Mar 10 16:41:29 2015] yes [Tue Mar 10 16:41:37 2015] but in theory, transportation could be determined by the compiler [Tue Mar 10 16:41:53 2015] although, I do wonder if it will be the same sort of problem as automatic paralellization [Tue Mar 10 16:42:21 2015] Well, the problem is, which path you use actually matters [Tue Mar 10 16:42:23 2015] i.e., sometimes frequent transport between certain representations will always be better than persisting in a third representation, and it will be hard to know before executing the code which is better [Tue Mar 10 16:42:49 2015] johnw: I suppose this sort of ties in with what Edward was saying about type classes and canonicity [Tue Mar 10 16:42:56 2015] which Edward? [Tue Mar 10 16:42:59 2015] Kmett [Tue Mar 10 16:43:08 2015] it seems like for simple cases, things like (a, ()) could already easily be replaces mechanically by just `a` in all cases, but I guess HoTT would allow you to teach the compiler more such equivalences without built-in understanding/ [Tue Mar 10 16:43:20 2015] replaced* [Tue Mar 10 16:43:36 2015] scott: right [Tue Mar 10 16:43:48 2015] You'd have a lot of the problems that the other systems with implicit parameter filling have which type classes avoid by uniqueness. [Tue Mar 10 16:44:01 2015] Cale: ah, I see [Tue Mar 10 16:44:10 2015] yeah, HITs have a lot of the feeling of type classes to me [Tue Mar 10 16:44:18 2015] Because you *care* about which proof of equality you use [Tue Mar 10 16:44:36 2015] i.e., you program to an "interface" abstraction, with the only requirement being that the instances can deform into each oter [Tue Mar 10 16:44:46 2015] yes, in this respect it's very proof relevant [Tue Mar 10 16:44:47 2015] and if you get two proofs of equality between things from different places, you *do not* know they are the same [Tue Mar 10 16:45:02 2015] hrm, is it kind of like the program still cares about representation, but univalence lets the type system ignore it to a greater extent? [Tue Mar 10 16:47:46 2015] scott: Well, okay, one thing you gain is that equality has a lot of structure already... [Tue Mar 10 16:48:13 2015] and by turning isomorphisms into equalities, you can take advantage of that structure [Tue Mar 10 16:49:12 2015] e.g. making use of the type system's unification algorithm instead of doing all the back-and-forth yourself? [Tue Mar 10 16:49:14 2015] I guess one analogy could be: No matter what language I'm speaking, I'm always the same person, expressing the same ideas; but different languages carry different costs (to effort, to communicability), and I cannot always use my own native language. So I have to optimize language choice based on circumstances, and this *will* affect how I'm heard, even if the idea in my mind remains uniform. [Tue Mar 10 16:49:50 2015] scott: the paths carry runtime impact as well, since they give you a way to transform data among representations, not just irrelevantly saying "they are transformable" [Tue Mar 10 16:50:15 2015] the type-checker would only care about the latter, but the execution very much requires the formemr [Tue Mar 10 16:50:27 2015] today, you have to express it all manually [Tue Mar 10 16:50:45 2015] I guess I need to rethink the runtime representation of paths, too? I can't think of them as just refl and an invocation of unification in the type system [Tue Mar 10 16:50:54 2015] You can inductively give proofs that equality is transitive: that there's a function which given p : y = z and q : x = y, gives you a composite p . q : x = z, that it's symmetric: there's a function which given p : x = y gives you p^-1 : y = x, and then that these satisfy properties, like associativity: p . (q . r) = (p . q) . r, and p . p^-1 = idpath among them [Tue Mar 10 16:51:11 2015] so as with any advance in CS, what we gain is another level of abstraction at the foundationals of our thinking about how to construct programs [Tue Mar 10 16:51:21 2015] right, "just refl" is no longer the case [Tue Mar 10 16:51:33 2015] and then various coherence laws that those things themselves satisfy [Tue Mar 10 16:51:57 2015] That's all stuff which you can prove almost for free about equality [Tue Mar 10 16:51:58 2015] I wonder if refl could be called "equality blindness" [Tue Mar 10 16:52:14 2015] what? [Tue Mar 10 16:52:25 2015] UIP might be called equality blindness [Tue Mar 10 16:52:29 2015] don't you lose the path of the equality? [Tue Mar 10 16:52:35 2015] refl *is* a path [Tue Mar 10 16:52:44 2015] oh, thanks for clarifying that [Tue Mar 10 16:52:55 2015] For each x in A, you have a path refl x : x = x [Tue Mar 10 16:53:23 2015] is refl just the identity path, then, and HoTT lets you move beyond just id? [Tue Mar 10 16:53:50 2015] MLTT already contains within it the potential for non-identity paths [Tue Mar 10 16:53:58 2015] but it doesn't give you any way to get hold of them [Tue Mar 10 16:54:11 2015] Cale: I think I was thinking that in a system where refl is your only proof of equality, then you have equality blindness, but maybe that's just wrong too [Tue Mar 10 16:54:19 2015] In the same way as in the first order theory of groups, you can't prove that there's a non-identity element of your group [Tue Mar 10 16:55:16 2015] but of course, in most groups, there will be non-identity elements, but since in the first order theory of groups, you can only prove things which hold of the elements of an arbitrary group, you have no hope of showing exists x. not (x = 1) [Tue Mar 10 16:55:22 2015] i keep forgetting that we're talking about equivalences, being equivalent to equality, rather than just equality [Tue Mar 10 16:55:28 2015] (because the trivial group is a group) [Tue Mar 10 16:56:24 2015] would the representation of path be a bijective function? (or something isomorphic to that representation...) [Tue Mar 10 16:56:37 2015] So the uniqueness of identity paths axiom, that for any type A, and any x, y : A, and p, q: x = y, we have p = q, is kind of like an axiom which in the theory of groups would read forall x. x = 1 [Tue Mar 10 16:56:39 2015] or in other words a pair of functions and proofs that they are inverse [Tue Mar 10 16:57:01 2015] oh, I have to go, bbiab [Tue Mar 10 16:59:12 2015] scott: pretty much, a path is an isomorphism [Tue Mar 10 16:59:30 2015] or equivantely, a morphism in a groupoid [Tue Mar 10 16:59:55 2015] and every path has its own identity paths, etc., up to infinity [Tue Mar 10 17:06:44 2015] it's kind of curious how the univalence axiom implies something that also looks like the univalence axiom [Tue Mar 10 17:07:42 2015] it says identity is equivalent to equivalence, which implies identity is identical to equivalence, or something like that [Tue Mar 10 17:14:37 2015] identity is not identical to every equivalence [Tue Mar 10 17:14:40 2015] it's identical to refl [Tue Mar 10 17:14:58 2015] equivalence is equivalent to every equality, though [Tue Mar 10 17:15:38 2015] I guess... we have some notion of equivalence we can build within the type system, and we have a notion of identity/equality built in to the type system, and the univalence axiom asserts that one of these notions is as good as the other [Tue Mar 10 17:15:57 2015] I think that's right [Tue Mar 10 17:16:20 2015] I guess UA is a path between an equivalence and the built-in equality? [Tue Mar 10 17:16:47 2015] I _think_ that's right too, I know HoTT chapter 1 speaks to that [Tue Mar 10 17:19:52 2015] I'm a bit confused how you would represent UA / what kind of computational meaning it has. is this not an issue? an unsolved issue? or actually already figured out? [Tue Mar 10 17:20:12 2015] I think that's the meat of what they're working on [Tue Mar 10 17:20:18 2015] okay, cool [Tue Mar 10 17:21:22 2015] CPDT is not compliant with coq 8.5 [Tue Mar 10 17:21:36 2015] AnarchosF: that's not much of a surprise, since 8.5 is very new and CPDT isn't [Tue Mar 10 17:22:06 2015] johnw the implicit arguments behave differently. [Tue Mar 10 17:22:18 2015] they sure do [Tue Mar 10 17:22:28 2015] and arguments to constructors [Tue Mar 10 17:22:55 2015] but cpdt is really nice to read (just a bit too concise). [Tue Mar 10 17:23:04 2015] th first part was really well weird :) [Tue Mar 10 17:23:12 2015] it makes sense the second time you read it [Tue Mar 10 17:23:21 2015] i.e., why it's presented the way it is [Tue Mar 10 17:23:41 2015] johnw that is why i am reading the following parts :) i had to stop at inductive predicates. [Tue Mar 10 18:11:51 2015] There should be an option to specify the folder of camlp4 : i had to tweak the configure.ml [Tue Mar 10 18:35:07 2015] scott: There's a sort of partial solution to it -- there's a model of homotopy type theory in terms of something called cubical sets, and then a computational interpretation for cubical sets. What we'd really like to have is an understanding of the computational meaning directly though, as some kind of syntactical reduction, so there's some work on type systems that would allow for such a thing. [Tue Mar 10 18:36:43 2015] interesting [Wed Mar 11 02:46:52 2015] Cale: around? [Wed Mar 11 02:55:07 2015] Cale suggested yesterday that in order to prove a theorem, I need to define the function removing the first and last element of a nonempty list. can I express that a certain function takes a nonempty list? I don't think so: that'd mean that such a function is partial, which is not allowed, iiuc. I could probably define a new type for nonempty lists, but that won't help me to prove my theorem since it talks about ordinary lists, and I [Wed Mar 11 02:55:07 2015] cannot go from them to nonempty due to []. or am I missing something? [Wed Mar 11 02:57:36 2015] instead of just taking a list, you can take a list with a proof that it's size > 0 [Wed Mar 11 02:57:42 2015] or, take an element and a list [Wed Mar 11 02:58:15 2015] johnw: could you show how to do the former? [Wed Mar 11 02:58:31 2015] (fyi, I'm currently trying to define it as a theorem) [Wed Mar 11 02:58:34 2015] I can do better than that [Wed Mar 11 02:58:46 2015] https://github.com/jwiegley/linearscan/blob/master/NonEmpty.v [Wed Mar 11 02:58:52 2015] :) [Wed Mar 11 02:59:01 2015] can you show me the type of what you want to prove? [Wed Mar 11 02:59:13 2015] sure, one sec [Wed Mar 11 02:59:38 2015] it's from sf: [Theorem rev_pal : forall (X : Type) (xs : list X), xs = rev xs -> pal xs.] [Wed Mar 11 02:59:55 2015] ah [Wed Mar 11 03:01:22 2015] the trick here is to destruct the list as (x :: xs ++ [y]), which is a challenge [Wed Mar 11 03:01:42 2015] so, yeah, you want a helper lemma of the form: Lemma rev_pal_length : forall X n l, length l <= n -> l = rev l -> pal X l. [Wed Mar 11 03:02:20 2015] for any list whose length is less than some n, we can prove the lemma [Wed Mar 11 03:02:34 2015] someone suggested this already, but I couldn't prove it [Wed Mar 11 03:02:37 2015] this is easier than proving the general case [Wed Mar 11 03:02:47 2015] I don't recall the details [Wed Mar 11 03:02:49 2015] but, using that lemma, you can then prove the general case rather easily [Wed Mar 11 03:02:57 2015] you'll need some other lemmas too [Wed Mar 11 03:03:09 2015] like Lemma length_snoc : forall X x (l : list X), length (snoc l x) = S (length l). [Wed Mar 11 03:03:14 2015] which then needs [Wed Mar 11 03:03:17 2015] Lemma app_length : forall (X:Type) (l1 l2 : list X), length (l1 ++ l2) = length l1 + length l2. [Wed Mar 11 03:03:32 2015] but it's fairly straightforward [Wed Mar 11 03:03:37 2015] one hint is to destruct the (rev l) [Wed Mar 11 03:03:45 2015] that's the only tricky bit I can see [Wed Mar 11 03:04:36 2015] johnw: "instead of just taking a list, you can take a list with a proof that it's size > 0" the link you pasted doesn't show how to do this, does it? NE_from_list accepts a default value. [Wed Mar 11 03:05:07 2015] ignore my first link [Wed Mar 11 03:05:12 2015] i thought you were after something else [Wed Mar 11 03:05:19 2015] :) [Wed Mar 11 03:05:33 2015] okay, I'll try the suggested lemmas (again) [Wed Mar 11 03:06:33 2015] and thanks! [Wed Mar 11 03:06:40 2015] sure [Wed Mar 11 04:51:58 2015] johnw: how do I get anything useful out of the length hypothesis in rev_pal_length? how do I keep the initial hypothesis after using inversion on it, for instance? [Wed Mar 11 09:29:35 2015] hmmmmmmmmm [Wed Mar 11 09:29:54 2015] is it just me or is it impossible to prove the undecidability of termination in coq? [Wed Mar 11 09:30:22 2015] er, hold on [Wed Mar 11 09:31:13 2015] i wrote up the stlc w/ fix & defined a function that performs a reduction step. but from here, at least, i dont think i can do the proof [Wed Mar 11 09:31:13 2015] undecidability is not provable unless you build in a deep embedding of some other model of computation. The negation of (P or not P) is refutable, as you may have seen the double negation of LEM: not not (P or not P) [Wed Mar 11 09:31:26 2015] ah [Wed Mar 11 09:32:06 2015] was gonna say i needed to be able to do case analysis on the result of the halting-checker [Wed Mar 11 09:32:10 2015] The logic is unaware that it is about computable functions. [Wed Mar 11 09:32:14 2015] indeed [Wed Mar 11 09:32:25 2015] what if though [Wed Mar 11 09:32:44 2015] what if i made stlc *without* fix, and then a larger type /with/ fix [Wed Mar 11 09:33:13 2015] then i could prove that no term of the plain stlc can solve halting for the turing complete stlc, couldnt it? [Wed Mar 11 09:33:23 2015] but i guess that's considerably weaker than the full theorem [Wed Mar 11 09:34:27 2015] ianjneu: er maybe i used porr phrasing earlier [Wed Mar 11 09:34:34 2015] STLC without fix is terminating by a logical relation argument that I believe is in the software foundations book. [Wed Mar 11 09:34:40 2015] ianjneu: to be more precise, what i was trying to prove is that [Wed Mar 11 09:35:54 2015] there doesnt exist a term of the stlc + fix that, when applied to a representation of a lambda term, will terminate as one of two terms that then correlates with the haltingness of the passed term [Wed Mar 11 09:35:58 2015] so something like [Wed Mar 11 09:35:59 2015] The usual construction of undecidability doesn't really work, since your decision comes from the metalanguage, and not the language itself. [Wed Mar 11 09:36:56 2015] ~exists oracle, forall l, reduces (app oracle (encode l)) lam_true <-> halts l [Wed Mar 11 09:37:05 2015] ^what i was thinking of [Wed Mar 11 09:37:12 2015] You don't get a "halts or not" decision program in STLC + fix, you just get a proposition that says computation reaches a value, or every reachable state of computation has a next step. [Wed Mar 11 09:37:24 2015] ianjneu: i know [Wed Mar 11 09:37:42 2015] l : LC_Term? [Wed Mar 11 09:37:45 2015] yeah [Wed Mar 11 09:37:52 2015] oracle also LC_Term [Wed Mar 11 09:38:22 2015] encode being something that turns an lc term into its church encoding [Wed Mar 11 09:38:29 2015] as would be needed for an algo to examine it [Wed Mar 11 09:39:01 2015] Your statement is too weak. You need to know that the oracle always halts too [Wed Mar 11 09:39:21 2015] lam_true is normal [Wed Mar 11 09:39:24 2015] oh i see [Wed Mar 11 09:39:39 2015] nice [Wed Mar 11 09:39:52 2015] adding that, though [Wed Mar 11 09:39:53 2015] I think you'll need a Scott encoding. Church encodings don't typecheck well. [Wed Mar 11 09:40:10 2015] ffft [Wed Mar 11 09:40:14 2015] not the point [Wed Mar 11 09:40:17 2015] ianjneu: i can't prove that, right? [Wed Mar 11 09:40:28 2015] oh no wait [Wed Mar 11 09:40:46 2015] yes, if i have the condition that it halts [Wed Mar 11 09:40:53 2015] then i /can/ destruct on what it halts at [Wed Mar 11 09:41:02 2015] oooh [Wed Mar 11 09:43:21 2015] How do you encode (if (oracle lc_encoding) omega true)? [Wed Mar 11 09:43:37 2015] hmm [Wed Mar 11 09:46:08 2015] sorry im in class brb [Wed Mar 11 13:01:05 2015] hello. coq keeps complaining about "Wrong" argument names (in implicit arguments that I need to give explicitly), even though the argument names are the ones I declared. [Wed Mar 11 13:02:22 2015] I can use @Name, but that is ... strange [Wed Mar 11 14:19:52 2015] do you give the implicit arguments in the same declared order? [Wed Mar 11 16:30:04 2015] ianjneu: hi [Wed Mar 11 16:30:14 2015] 09:43:21 ianjneu │ How do you encode (if (oracle lc_encoding) omega true)? [Wed Mar 11 16:30:23 2015] ianjneu: i assume exactly like that? [Wed Mar 11 16:37:20 2015] benzrf: ya, I didn't get the thought out that I really wanted to get out, which was how to use your statement about omega's functionality to derive False. [Wed Mar 11 16:38:13 2015] you mean oracle's? [Wed Mar 11 16:38:21 2015] yes [Wed Mar 11 16:39:41 2015] I'd need ~ exists oracle, (forall v, reduces (app oracle (encode l)) v -> normal_form v -> {v = lam_true \/ v = lam_false}) <-> halts l [Wed Mar 11 16:39:49 2015] oh right [Wed Mar 11 16:39:57 2015] ianjneu: wait, normal_form v? [Wed Mar 11 16:39:59 2015] why? [Wed Mar 11 16:40:30 2015] hold on i think you mangled that a little [Wed Mar 11 16:40:33 2015] whenever oracle terminates (evaluates to a normal form), it produces a boolean. [Wed Mar 11 16:40:34 2015] let me write what i think is needed [Wed Mar 11 16:41:10 2015] oh, right, ya that is mangled a little [Wed Mar 11 16:42:30 2015] ~ exists oracle, forall v, normal_form v -> reduces (app oracle (encode l)) v -> (v = lam_true /\ halts l) \/ (v = lam_false /\ ~ halts l) [Wed Mar 11 16:42:58 2015] ~exists oracle, forall l, halts (app oracle (encode l)) / reduces (app oracle (encode l)) l_true <-> halts l [Wed Mar 11 16:43:20 2015] ? [Wed Mar 11 16:43:24 2015] fuck [Wed Mar 11 16:43:26 2015] ~exists oracle, forall l, halts (app oracle (encode l)) /\ reduces (app oracle (encode l)) l_true <-> halts l [Wed Mar 11 16:43:43 2015] my stupid latex notation plugin thing kills backslash-space [Wed Mar 11 16:44:16 2015] hrm wait im missing something here [Wed Mar 11 16:44:22 2015] oracle has to always halt no matter what, so there's still something missing. [Wed Mar 11 16:44:24 2015] ah no wait [Wed Mar 11 16:44:33 2015] ianjneu: it does? [Wed Mar 11 16:44:39 2015] hold up [Wed Mar 11 16:44:50 2015] benzrf: ya, it has to be a decision procedure [Wed Mar 11 16:45:02 2015] wait give me 1 minute [Wed Mar 11 16:46:13 2015] no yeah pretty sure that's right [Wed Mar 11 16:47:28 2015] ianjneu: i only need to destruct on the oracle's result when applied to the encoding of contrarian ( good name? ) [Wed Mar 11 16:47:46 2015] ianjneu: so i only need to know that it terminates on that [Wed Mar 11 16:48:58 2015] * goes back and rewrites his code to use the untyped LC [Wed Mar 11 16:49:35 2015] my shitty attempt at HOAS ended up requiring so much inversion that my reduction and substition functions are defined using tactic mode :| [Wed Mar 11 16:50:09 2015] PHOAS is necessary in a proof environment. [Wed Mar 11 16:50:22 2015] otherwise you get exotic terms. [Wed Mar 11 16:50:37 2015] (fexpr-like things) [Wed Mar 11 17:04:02 2015] fexpr [Wed Mar 11 17:04:05 2015] ah [Wed Mar 11 17:04:17 2015] wait, fexprs take code and give values right [Wed Mar 11 17:04:30 2015] just auto-quoting [Wed Mar 11 17:04:34 2015] or is it values->code [Wed Mar 11 17:05:56 2015] yay. again I can segfault coq \o/ [Wed Mar 11 17:06:05 2015] good job [Wed Mar 11 17:09:01 2015] ianjneu: how does that work? [Wed Mar 11 17:14:12 2015] argh [Wed Mar 11 17:15:24 2015] benzrf: PHOAS asserts a parametricity axiom so that you get substution from function application. Adam Chlipala has a few papers on it. [Wed Mar 11 17:16:28 2015] Essentially you quantify over the type for names and use a free theorem that the only way to produce a term with the appropriate type is to perform the substitution you mean. [Wed Mar 11 19:41:41 2015] can I tell coq to extract something different from a constant to some specific term? [Wed Mar 11 20:35:00 2015] ianjneu: hm [Wed Mar 11 20:35:13 2015] ianjneu: how can you have exotic terms w/o that [Wed Mar 11 20:35:18 2015] whats an example? [Wed Mar 11 21:28:35 2015] schoppenhauer: can you give an example of what you mean? [Wed Mar 11 21:30:52 2015] johnw: I proved something. but its extracted term is too inefficient at present. so for testing, I would like to tell coq to overload function calls to this. [Wed Mar 11 21:35:07 2015] sure you can do that [Wed Mar 11 21:35:20 2015] you can tell Coq to use specific types/constructors, and specific functions [Wed Mar 11 23:33:22 2015] hey if i import setoid i can rewrite using iff [Wed Mar 11 23:33:23 2015] whats up with taht [Wed Mar 11 23:33:26 2015] axioms? [Wed Mar 11 23:36:41 2015] did those three sentences relate to each other? [Wed Mar 11 23:38:23 2015] hmm uh [Wed Mar 11 23:38:36 2015] something something iff rewrite needs hott [Wed Mar 11 23:39:34 2015] you should try it [Wed Mar 11 23:42:07 2015] er, does it? [Wed Mar 11 23:56:37 2015] tfw coq doesnt allow out-of-order definitions [Thu Mar 12 00:17:53 2015] night [Thu Mar 12 04:42:23 2015] Hi [Thu Mar 12 05:01:38 2015] \exit [Thu Mar 12 05:01:50 2015] \join haskell [Thu Mar 12 05:02:07 2015] \join sml [Thu Mar 12 06:44:56 2015] does (rev zs ++ [z]) ++ [y] mean that rev is applied to zs? [Thu Mar 12 09:17:36 2015] I'm trying to understand definition of ex [Thu Mar 12 09:18:06 2015] what does "exists mean" ? [Thu Mar 12 09:18:28 2015] ex_intro : forall x : A, P x -> exists x, P x [Thu Mar 12 09:19:06 2015] definition given in CPDT differs slightly, so I assume this must have changed in the recet versions of Coq [Thu Mar 12 09:23:48 2015] jstolarek: how does it different? [Thu Mar 12 09:25:25 2015] ex_intro : forall x : A, P x -> ex P [Thu Mar 12 09:25:29 2015] that's the book version [Thu Mar 12 09:25:45 2015] both have common signature: [Thu Mar 12 09:26:04 2015] Inductive ex (A : Type) (P : A -> Prop) : Prop := [Thu Mar 12 09:27:01 2015] benzrf: ^^^ [Thu Mar 12 09:27:41 2015] jstolarek: oh just a notational difference [Thu Mar 12 09:27:57 2015] [exists x, P x] is a notation for [ex (fun x => P x)] [Thu Mar 12 09:28:01 2015] jstolarek: exists x, P x is notation for ex (x => P x) which is then eta equivalent to ex P [Thu Mar 12 09:29:57 2015] I see [Thu Mar 12 09:30:02 2015] one more question [Thu Mar 12 09:30:12 2015] The book proves this theorem: [Thu Mar 12 09:30:27 2015] Theorem exist1 : exists x : nat, x + 1 = 2. [Thu Mar 12 09:30:43 2015] First step is a tactic "exists 1" [Thu Mar 12 09:30:53 2015] could someone explain how that tactic works? [Thu Mar 12 09:31:11 2015] I looked at the manual but the explanation was too cryptic for me :-/ [Thu Mar 12 09:32:28 2015] The intended meaning of this tactic is, when the goal is of the form [exists x, P x], you can use [exists y] to say "y is a witness such that P y". So then, you'll have to prove P y. [Thu Mar 12 09:33:04 2015] So when you want to prove that there exists x such that P x, using [exists y] is like saying "For example, y is such that P y. Now we prove P y." [Thu Mar 12 09:33:39 2015] ok, so it's basically like finding a single example that holds? [Thu Mar 12 09:33:47 2015] yes [Thu Mar 12 09:33:57 2015] that makes sense [Thu Mar 12 09:34:15 2015] though I'm surprised seeing that the goal gets simplified to 1+1=2 [Thu Mar 12 09:35:02 2015] Well, in this case, [P x] is actually [x + 1 = 2]. So if you assert that 1 is a witness, then you need to prove [P 1], which is [1 + 1 = 2]. [Thu Mar 12 09:35:42 2015] ah [Thu Mar 12 09:35:43 2015] I see [Thu Mar 12 09:35:50 2015] when I say [Thu Mar 12 09:35:55 2015] exists foo [Thu Mar 12 09:36:00 2015] the foo is the witness? [Thu Mar 12 09:36:33 2015] yes [Thu Mar 12 09:36:40 2015] I somehow thought that this 1 refers to the goal number or something like it does in tactics like constructor or destruct [Thu Mar 12 09:36:46 2015] Not in this case :) [Thu Mar 12 09:36:54 2015] that was misleading [Thu Mar 12 09:36:55 2015] 1 here is really just a nat [Thu Mar 12 10:42:04 2015] hello. I am trying to use FMapAVL (https://coq.inria.fr/library/Coq.FSets.FMapAVL.html) I need the lemma "add_eq_o", but I cannot figure out how to import and access it. [Thu Mar 12 10:59:25 2015] can somebody please help me. I have my problems with understanding the module system. [Thu Mar 12 11:01:01 2015] hmmm [Thu Mar 12 11:01:19 2015] in my simply typed LC i have an uninhabited type void and then arrow type and that's all [Thu Mar 12 11:01:31 2015] that kind of makes church encoding tricky since no parametricity [Thu Mar 12 11:01:49 2015] what should i use instead? [Thu Mar 12 11:02:01 2015] nvm @ my question [Thu Mar 12 11:05:09 2015] benzrf: uninhabited? Not a unit type? [Thu Mar 12 11:25:49 2015] ok. now ... I don't get the lemma cardinal_2 ... even though I have Module M := FMapAVL.Make(Nat_as_OT) and Module N := FMapFacts.Facts M, it does not find cardinal_2 [Thu Mar 12 11:27:49 2015] SearchAbout M.cardinal only lists M.cardinal_1 [Thu Mar 12 11:40:30 2015] which command invokes SearchRewrite in Proof General ? [Thu Mar 12 11:40:46 2015] It looks like it doesn't have a default binding [Thu Mar 12 11:41:11 2015] So does the documentation you linked earlier [Thu Mar 12 11:44:49 2015] was that @me? [Thu Mar 12 11:45:28 2015] ianjneu: why would a unit type be useful [Thu Mar 12 11:45:53 2015] ianjneu: i can accomplish the same thing with (void -> void) and explicit unit would need a new term [Thu Mar 12 11:47:20 2015] void is only there so that i have somewhere to stop nesting the arrows :) [Thu Mar 12 11:48:41 2015] benzrf: okay sure. Are you trying to encode LC terms? [Thu Mar 12 11:49:04 2015] yeah [Thu Mar 12 11:49:17 2015] i was thinking of just going with lam_bool as the output type instead of being parametric [Thu Mar 12 11:49:41 2015] but im not 100% sure that that such an encoding would have as much information as the original term? [Thu Mar 12 11:50:06 2015] then i thought of lam_list lam_bool as the output type, but how do i do list ;-; [Thu Mar 12 11:50:41 2015] schoppenhauer: yes that was to you [Thu Mar 12 11:51:03 2015] I can't see it listed there [Thu Mar 12 11:51:44 2015] irishsultan: under https://coq.inria.fr/library/Coq.FSets.FMapFacts.html section "Cardinal" [Thu Mar 12 11:51:54 2015] hmm, be back in a bit [Thu Mar 12 11:51:57 2015] gotta lunch [Thu Mar 12 12:06:12 2015] benzrf: a Mogensen-Scott encoding is an n-ary function for n-many variants of a data type DT, where for variant (v_i dt_1 ... dt_j), you have a function fun x_1 ... x_n => x_i (encode dt_1) ... (encode dt_j) [Thu Mar 12 12:06:12 2015] schoppenhauer: are you certain that Make isn't giving you this instead https://coq.inria.fr/distrib/current/stdlib/Coq.FSets.FMapList.html [Thu Mar 12 12:06:50 2015] irishsultan: no. [Thu Mar 12 12:07:41 2015] benzrf: https://en.wikipedia.org/wiki/Mogensen%E2%80%93Scott_encoding#Mogensen.E2.80.93Scott_encoding [Thu Mar 12 14:44:23 2015] i love the irony in how you can prove ~~DNE [Thu Mar 12 14:44:36 2015] like an ice pick trapped under a layer of ice [Thu Mar 12 14:45:15 2015] DNE? [Thu Mar 12 14:47:27 2015] Definition DNE := forall P, ~~P -> P. [Thu Mar 12 15:06:21 2015] Heh. [Thu Mar 12 15:21:34 2015] benzrf: any luck with the encoding? [Thu Mar 12 16:02:18 2015] ianjneu: sorry ive been away for a while now [Thu Mar 12 16:25:15 2015] Why does coq have its own virtual machine ? [Thu Mar 12 16:33:23 2015] <__monty__> Hi, I was wondering why coq focuses on extraction vs compilation. Is it merely because the community is not interested in implementing/maintaining a performant compiler for coq but would still like to be able to run optimized code? Or are there other advantages to extraction? [Thu Mar 12 16:35:23 2015] __monty__: What's the difference? :) [Thu Mar 12 16:35:30 2015] Choice of target language? [Thu Mar 12 16:43:46 2015] <__monty__> cale: I can see how having your verified code extracted to the language you use to implement the rest of your system is attractive. However, coq is the only language I know of that uses extraction, I'm wondering why?h [Thu Mar 12 16:44:22 2015] __monty__: My point was that every compiler could just as well be called an extractor [Thu Mar 12 16:44:38 2015] __monty__: I don't know why Coq uses that particular term [Thu Mar 12 16:44:46 2015] But it's the same thing as a compiler. [Thu Mar 12 16:46:36 2015] Cale: a compiler is a semantics preserving function from Language1 to Language2, albeit most people think of "optimizing compiler" or "bytecode/native code compiler" when they hear the word. [Thu Mar 12 16:47:45 2015] the fact that Coq is written in and looks like OCaml makes it tempting to essentially "desugar" or "extract" a coq program to an ocaml program. I imagine the word "transpiler" wasn't popular when Coq first began :P [Thu Mar 12 16:49:55 2015] <__monty__> ianjneu: Are you referring to me when you say "most people?" Or did you mean to imply that extraction is not a semantics preserving function? [Thu Mar 12 16:52:52 2015] I mean to imply that extraction should be understood as a non-optimizing compiler between two "sister" languages. [Thu Mar 12 16:57:38 2015] <__monty__> One last question: what are your opinions on using coq as a programming language? [Thu Mar 12 16:59:52 2015] __monty__: as opposed to a dish towel? [Thu Mar 12 17:09:50 2015] <__monty__> ianjneu: I was referring to coq being promoted in the first place as a proof assistant, not a programming language. This in contrast to agda and especially idris which are first and foremost programming languages. [Thu Mar 12 17:11:56 2015] Coq does not have enough escape hatches to be a useful programming language. Dependent types are nice sometimes, but a pain most other times. [Thu Mar 12 17:27:54 2015] time till tell if Idris manages to make dependent types less of a pain. [Thu Mar 12 17:38:32 2015] hodapp: Whenever you need to know another property of a datatype to prove something, you have to pass around more proofs. Passing around more proofs means a cascading change in all consumers of the type, proof maintenance, and more garbage. [Thu Mar 12 17:41:52 2015] <__monty__> Ok, Cale, ianjneu thank you for the discussion. [Thu Mar 12 17:45:25 2015] ianjneu i am reading the cpdt for some days. really difficult ! [Thu Mar 12 17:47:21 2015] Anarchos: indeed. [Thu Mar 12 17:47:53 2015] <__monty__> Anarchos: Did you do Soft. Found.'s already? I think it's very accessible. [Thu Mar 12 17:50:26 2015] __monty__ yes i did, but one or two years ago. [Thu Mar 12 17:50:39 2015] ianjneu adam write his book as if everything should be intuitive... [Thu Mar 12 17:53:02 2015] Anarchos: yup. His writing reflects his character. [Thu Mar 12 17:53:10 2015] i have memory troubles, so very difficult to remember the use cases for tactics. Except for apply, simpl. But induction, inversion , destruct .... Could never remember. [Thu Mar 12 17:53:24 2015] ianjneu i don't know him by myself :) [Thu Mar 12 17:53:48 2015] I've dealt with him before. He's very dismissive. [Thu Mar 12 17:53:56 2015] dismissive ? [Thu Mar 12 17:54:40 2015] You're having a hard time? Not my fault. [Thu Mar 12 17:54:55 2015] i can't understand why people who write books to disseminate science can be dismissive to their readers.... [Thu Mar 12 17:55:10 2015] <__monty__> Anarchos: Have you used coq actively over the course of those 2 years? I was hoping to be able to breeze throug cpdt after finishing sofo? [Thu Mar 12 17:55:28 2015] __monty__: hah, it's not breezeable [Thu Mar 12 17:56:07 2015] yes i did most of the exercices from SF. But i always ended to do dirty proofs with only apply ; simpl ; elim ; undo; auto. :) [Thu Mar 12 18:17:24 2015] hmm ianjneu [Thu Mar 12 18:17:34 2015] scott encoding doesnt look terribly helpful [Thu Mar 12 18:17:46 2015] the problem continues to be that i dont have parametric polymorphism for the return type [Thu Mar 12 18:19:05 2015] __monty__: I've been using Coq as a prograomming langauge [Thu Mar 12 18:20:44 2015] <__monty__> johnw: Just to experiment or in a "serious" project? And, do you have any experience with agda or idris? [Thu Mar 12 18:21:23 2015] both [Thu Mar 12 18:21:24 2015] and no [Thu Mar 12 18:21:44 2015] i've been writing a register allocator as my first real programming project in Coq, and it's for a real purpose [Thu Mar 12 18:25:08 2015] <__monty__> johnw: Why did you choose coq? Was formal verification a requirement or a nice bonus? [Thu Mar 12 18:28:11 2015] I wanted to see what it would be like to develop a formally verified component for a critical piece of a compiler architecture [Thu Mar 12 18:29:41 2015] <__monty__> Kind of taking compcert one step further? [Thu Mar 12 18:32:35 2015] johnw oh i read about an internship at inria doing this kind of thing to replace the call to external register allocator + correction verification postponed [Thu Mar 12 18:33:40 2015] __monty__: I guess it's a step beyond what compcert does, but just for this one little piece [Thu Mar 12 18:38:06 2015] <__monty__> johnw: And what's your opinion on coq as a programming language? Is it only barely a programming language, useful only when you need to implement something small with strong verification requirements? Or, do think it's ready (doesn't mean tools aren't currently lacking, etc.) for serious development, regardless of the need for verification? [Thu Mar 12 18:39:04 2015] __monty__ if you want serious dev without verification, coq is really ocaml alike. [Thu Mar 12 18:43:10 2015] so, Coq as a functional language is just fine [Thu Mar 12 18:43:20 2015] however, it lacks nearly every modern convenience that you can think of [Thu Mar 12 18:43:29 2015] even the type classes support does not extract well to Haskell, preventing me from using it [Thu Mar 12 18:43:46 2015] <__monty__> Anarchos: I'm actually looking into how usable dependently typed languages are for programming. [Thu Mar 12 18:43:47 2015] (it led to code that would segfault, due to thunks being incorrectly unsafeCoerce'd) [Thu Mar 12 18:44:05 2015] __monty__: The rest of us are trying to figure that out too :) [Thu Mar 12 18:44:22 2015] __monty__: ‘How useful are depndent types?’ is a big research question right now. [Thu Mar 12 18:44:30 2015] the lack of case guards, view patterns, record access syntax, monads (generally), etc., are a real pain over time [Thu Mar 12 18:44:37 2015] but, I like it as a language per se [Thu Mar 12 18:44:40 2015] __monty__: The Agda folks feel very strongly that they are quite useful. [Thu Mar 12 18:44:53 2015] I like being forced to prove totality, to have complete coverage in my "match" statements, etc. [Thu Mar 12 18:44:54 2015] __monty__: The Coq folks are generally less convinced. [Thu Mar 12 18:44:57 2015] i can't "get away with anything" [Thu Mar 12 18:45:01 2015] <__monty__> alkabetz: Surely at least part of the community around coq is interested more in coq "as a proof assistant" than "as a programming language"? [Thu Mar 12 18:45:45 2015] __monty__: Absolutely. I think a large part of the Coq community is interested in Coq as a proof assistant rather than as a programming language. [Thu Mar 12 18:46:01 2015] johnw: Sorry, ended up talking over you there :/ [Thu Mar 12 18:46:24 2015] n/p [Thu Mar 12 18:46:48 2015] several people in the Coq community are interested in using it as a programming language [Thu Mar 12 18:46:53 2015] For what it’s worth, I would consider writing a large program in Coq only if I were going to prove things about it, and I would not use dependent types. [Thu Mar 12 18:46:55 2015] Gonthier may care more about its use as a proof assistant [Thu Mar 12 18:47:12 2015] I would consider writing a large program in Agda, possibly using dependent types, even if I weren’t going to prove stuff about it explicitly. [Thu Mar 12 18:47:14 2015] but Morrissett and Chlipala want to use it for real stuff [Thu Mar 12 18:47:20 2015] see Bedrock, Fiat, Ynot, etc. [Thu Mar 12 18:47:41 2015] <__monty__> johnw: Do you feel like "not getting away with anything" would be a major plus in development projects where possibly large teams work on the code? [Thu Mar 12 18:47:56 2015] it's definitely a plus in terms of correctness and needing to understand your code [Thu Mar 12 18:48:06 2015] if I had it to do all over again, I wouldn't have done this in Coq [Thu Mar 12 18:48:23 2015] Looking back a couple minutes, I guess making that Coq-versus-Agda comparison isn’t entirely fair, because Agda’s proof style is heavily based on proof-carrying code, whereas Coq’s is more (usually) explicit and external to the code itself. [Thu Mar 12 18:48:36 2015] I would have written it in Haskell in 1/50th of the time, then written a verifier in Coq that I could extract to Haskell, so that the unit tests would be able to prove that anything that claimed it succeeded actually did succeed [Thu Mar 12 18:50:56 2015] <__monty__> johnw: Is the code for this project available somewhere? [Thu Mar 12 18:51:49 2015] <__monty__> alkabetz: Which proofstyle do you believe to be more suited to programming? [Thu Mar 12 18:53:05 2015] __monty__: I haven’t developed sufficiently large applications in both styles to really compare them. Adam Chlipala feels very strongly that the former scales better, and his arguments seem reasonable. [Thu Mar 12 18:53:59 2015] Somebody earlier stated the arguments I’m thinking of – namely, that proof-carrying code requires you to carry around a bunch of garbage proof terms at runtime. [Thu Mar 12 18:54:26 2015] __monty__: https://github.com/jwiegley/linearscan [Thu Mar 12 18:54:31 2015] i'm very, very close to the end [Thu Mar 12 18:54:58 2015] one nice thing about having done it in Coq is that there are parts which, once everything is running correctly, should literally never need to be changed [Thu Mar 12 18:55:28 2015] __monty__: I would definitely not recommend the proof-carrying code approach in Coq; Coq is simply not designed that way. With Agda, it’s a bit of a different story. [Thu Mar 12 18:55:40 2015] and that's an intellectual comfort that no other language can provide, unless it also offers the ability to prove properties about the code (and by proof I include encoding properties in types ala Agda) [Thu Mar 12 18:55:54 2015] I use proof-carrying code in Coq sometimes [Thu Mar 12 18:56:09 2015] there are times when it truly is the easiest way to deal with recursion involving complex predicates [Thu Mar 12 18:56:30 2015] i've found that Coq is really bad at "seeing through" fixpoints and folds at times [Thu Mar 12 18:56:53 2015] having each step of the recursion yields the evidence needed by the step higher up is really convenient [Thu Mar 12 18:57:52 2015] <__monty__> alkabetz: When you said "Chlipala feels strongly..." did you mean proof-carrying by former? [Thu Mar 12 18:58:27 2015] No, the opposite. Adam feels strongly that proof-carrying code is not the right way to do things. [Thu Mar 12 18:58:51 2015] <__monty__> alkabetz: Ok, that makes more sense. [Thu Mar 12 19:01:43 2015] <__monty__> johnw, alkabetz: Thank you this was a very fruitful conversation for me. I'm calling it a night. [Thu Mar 12 19:01:59 2015] Take care! [Thu Mar 12 19:11:26 2015] johnw: so... you (and someone else) suggested to use this: Lemma rev_pal_length : forall X n l, length l <= n -> l = rev l -> pal X l. but how can I get anything useful out of this hypothesis? how do I keep the initial hypothesis after, say, using inversion on it? [Thu Mar 12 19:16:27 2015] That was me I believe [Thu Mar 12 19:16:40 2015] What do you mean by "this hypothesis"? [Thu Mar 12 19:16:46 2015] length l <= n [Thu Mar 12 19:17:21 2015] also, is there a way to prove it by using the init function as Cale suggested? [Thu Mar 12 19:17:49 2015] I spent ~3 hours on it this morning and failed to prove anyway [Thu Mar 12 19:17:59 2015] This hypothesis is not really useful by itself, it's just a way of expression "I want to do a strong induction on the length of the list" [Thu Mar 12 19:18:16 2015] btw, I suggested "length l < n", not "length l <= n", the base case is more simple ^^' [Thu Mar 12 19:18:33 2015] I'm not sure what Cale suggested, I'd have to read it back [Thu Mar 12 19:18:41 2015] nkar: you don't do inversion on it, you simply apply it [Thu Mar 12 19:18:57 2015] remember, it proves that the size of l is <= n, where you get to provide n [Thu Mar 12 19:19:00 2015] hint hint :) [Thu Mar 12 19:19:48 2015] I just gave some vague ideas [Thu Mar 12 19:20:11 2015] you only invert on it to rule out lists who length is > n [Thu Mar 12 19:20:12 2015] That perhaps it would be a good idea to formalise some properties of the function which surrounds a list with an element [Thu Mar 12 19:20:19 2015] and the function which deletes the first and last element [Thu Mar 12 19:20:35 2015] after that, it will become a detail needed by your induction hypothesis [Thu Mar 12 19:20:54 2015] i.e. if we call the first function surround, and the second ablate, then ablate (surround x xs) should be xs [Thu Mar 12 19:22:05 2015] and if the first and last element of xs are both x, and xs has at least 2 elements, then surround x (ablate x xs) is xs [Thu Mar 12 19:22:15 2015] thanks all, I'll try to digest it next morning, just wanted to get more hints while you all are online :) [Thu Mar 12 19:22:19 2015] timezones :\ [Thu Mar 12 19:22:41 2015] This is just general intuition about what sorts of things might be useful to have, I haven't tried to actually do the proof :) [Thu Mar 12 19:24:23 2015] I used two other lemmas in my proof: one about [rev (snoc x xs)], and one about [length (snoc x xs)] [Thu Mar 12 19:24:37 2015] Cale: I failed to prove it because the recursive axiom for pal is : pal xs -> pal (x :: xs ++ [x]). I managed to get to pal (x : xs ++ [x]), but that required me to prove pal xs where xs was something like: init (x :: xs), which doesn't hold [Thu Mar 12 19:25:15 2015] Oh. I expressed pal in terms of snoc [Thu Mar 12 19:25:37 2015] Cypi: you mean the x :: xs ++ [x] part? [Thu Mar 12 19:25:42 2015] I have a snoc_app lemma [Thu Mar 12 19:26:09 2015] Both are fine anyway [Thu Mar 12 19:33:39 2015] frick [Thu Mar 12 19:33:46 2015] how do i prove ~~LEM [Thu Mar 12 19:34:05 2015] the proof i thought was the right one is for [forall P, ~~(P \/ ~P)] [Thu Mar 12 19:38:49 2015] Can you? [Thu Mar 12 19:53:00 2015] benzrf : after trying a little bit, I would be surprised to see it provable :x [Thu Mar 12 19:53:21 2015] i couldve sworn you can [Thu Mar 12 19:56:16 2015] hmm [Thu Mar 12 19:56:20 2015] jgross: are you online? [Thu Mar 12 20:07:11 2015] benzrf: There is a type for which LEM fails in HoTT, so you're going to have a hard time. [Thu Mar 12 20:07:48 2015] oy [Thu Mar 12 20:07:53 2015] Cale: which one? [Thu Mar 12 20:08:00 2015] Anything which isn't a set [Thu Mar 12 20:08:03 2015] hh [Thu Mar 12 20:08:10 2015] Cale: so ~LEM in hott? [Thu Mar 12 20:08:15 2015] right [Thu Mar 12 20:08:28 2015] o.o [Thu Mar 12 20:08:31 2015] At least, the super strong LEM you're probably talking about [Thu Mar 12 20:08:40 2015] which the HoTT book calls LEM_infty [Thu Mar 12 20:08:40 2015] By LEM, we mean [forall (P : Prop), P \/ ~P] I believe [Thu Mar 12 20:08:42 2015] right? [Thu Mar 12 20:08:44 2015] right [Thu Mar 12 20:08:54 2015] Oh, well, what do you mean by Prop? :) [Thu Mar 12 20:08:59 2015] I do mean Prop :p [Thu Mar 12 20:09:14 2015] And I'd think benzrf also meant Prop, but I cannot be sure [Thu Mar 12 20:09:35 2015] hmm [Thu Mar 12 20:09:44 2015] Well, Coq's Prop doesn't exactly correspond to anything in HoTT [Thu Mar 12 20:10:10 2015] Oh right, "in HoTT", sorry. [Thu Mar 12 20:10:21 2015] I'm the one who brought up HoTT though [Thu Mar 12 20:10:33 2015] I misread this "in CPDT" for some reason [Thu Mar 12 20:11:34 2015] benzrf: btw, if you want to see that proof in the HoTT book, see physical page 111 here: https://hottheory.files.wordpress.com/2013/03/hott-online-611-ga1a258c.pdf [Thu Mar 12 20:13:39 2015] But yeah, if you think of the HoTT universe U here as being like an MLTT universe modulo an additional axiom (univalence), then it's clear you shouldn't be able to prove ~~LEM in MLTT. [Thu Mar 12 20:15:19 2015] and that probably doesn't quite get you that you can't prove it in Coq's Prop, because maybe there's some clever use of impredicativity? [Thu Mar 12 20:16:07 2015] But it seems to indicate that at least any proof of it would have to make use of Prop's unique features relative to Type [Thu Mar 12 20:21:10 2015] huh [Thu Mar 12 20:21:13 2015] :| [Thu Mar 12 20:21:23 2015] ive just spent months thinking that you can prove ~~LEM [Thu Mar 12 20:21:25 2015] ;-; [Thu Mar 12 20:21:49 2015] Well, you can prove forall P, ~~(P \/ ~P) [Thu Mar 12 20:22:25 2015] yeah [Thu Mar 12 20:22:50 2015] hmm hmm [Thu Mar 12 20:23:06 2015] does ~~P / ~~Q -> ~~(P / Q) [Thu Mar 12 20:23:10 2015] ah [Thu Mar 12 20:23:11 2015] does ~~P / ~~Q -> ~~(P / Q) [Thu Mar 12 20:23:14 2015] omg [Thu Mar 12 20:23:16 2015] does ~~P / ~~Q -> ~~(P /\ Q) [Thu Mar 12 20:23:24 2015] still have a / there [Thu Mar 12 20:23:29 2015] god dammit [Thu Mar 12 20:23:29 2015] benzrf: [~~forall P, P \/ ~P] <- I don't think that's provable. Knowing [~forall P, P \/ ~P] doesn't really tell you anything. On the other hand, [~exists P, ~(P \/ ~P)] is provable (in particular, because [forall P, ~~(P \/ ~P)] is provable). [Thu Mar 12 20:23:47 2015] ah oh [Thu Mar 12 20:23:56 2015] frick [Thu Mar 12 20:24:50 2015] http://en.wikipedia.org/wiki/Double-negation_translation#First-order_logic [Thu Mar 12 20:25:00 2015] I think you got confused about how this translation works [Thu Mar 12 20:25:13 2015] especially with respect to quantifiers [Thu Mar 12 20:32:36 2015] (I seem to recall being confused about the same thing at one point) [Thu Mar 12 20:51:26 2015] how would you prove forall P, ~~(P \/ ~P) ? [Thu Mar 12 20:54:33 2015] Just try it with Coq, it's easy enough :) [Thu Mar 12 20:55:36 2015] I've been trying in my head with pseudo-Idris :p [Thu Mar 12 20:56:04 2015] aha, I do, in fact, have Coq installed on this computer [Thu Mar 12 21:08:12 2015] I solved it in one step with `firstorder.` then printed the term and manually simplified. now I think I get it :) [Thu Mar 12 21:11:57 2015] the piece I was missing in my head was using ~(P \/ ~P) to prove ~P (which then combined with ~(P \/ ~P) proves ~~(P \/ ~P)) [Thu Mar 12 21:38:03 2015] Try it using intro/apply the whole way, with or_intror and or_introl :) [Thu Mar 12 21:41:34 2015] I ended up writing the proof term directly without tactics (in Idris, but it would be the same in Coq) [Fri Mar 13 05:52:25 2015] jstolarek pasted “Stream equality with co-induction” at http://lpaste.net/124819 [Fri Mar 13 05:52:46 2015] I have problems with conducting a proof of stream equality with coinduction [Fri Mar 13 05:52:53 2015] this is basicaly taken from CPDT chapter 5 [Fri Mar 13 05:53:09 2015] now, the script in the book works without problems [Fri Mar 13 05:53:11 2015] mine does not [Fri Mar 13 05:53:17 2015] and I can't figure out why [Fri Mar 13 05:53:34 2015] obviously, there is *some* difference between my file and the one from the book [Fri Mar 13 05:53:41 2015] but I can't figure out what it is [Fri Mar 13 05:54:34 2015] it must be something very subtle and I'd like to find out what exactlt that is [Fri Mar 13 05:56:20 2015] the last call to apply causes error pasted at the bottom. state of subgoals is given for the last working step of the proof [Fri Mar 13 05:56:46 2015] state of the proof looks identical to the one from the book, so my guess would be that it must be some settings of Coq [Fri Mar 13 05:58:29 2015] ok, nvm - found it! a typo in Cons_case_tl [Fri Mar 13 10:42:51 2015] Why type of term-level lambda is type-level lambda, but type of type-level lambda isn't "higher type"-level lambda? [Fri Mar 13 10:43:37 2015] I mean, type of "fun x => y" is "forall _ : X, Y", but type of "forall (x : X), Y(x)" is plain "Type". [Fri Mar 13 10:52:29 2015] pi-type isn't a type-level lambda. It's a dependent product. A type-level lambda is just a lambda that takes and produces types. [Fri Mar 13 10:53:36 2015] Indeed, a type-level lambda looks like (fun (x:Type) => x) [Fri Mar 13 10:53:48 2015] and you'll discover that its type is also a pi type, at a higher level. [Fri Mar 13 10:55:19 2015] Types are introduceable into the universe(s) of Type(_i). They are not eliminable. They have inhabitants that are terms that have introduction and elimination forms (e.g. lambda introduces, application eliminates) [Fri Mar 13 10:55:28 2015] ccasin, ianjneu, yep, I understand; just thought that we could treat lambdas and pi-types as the single concept, why not? [Fri Mar 13 10:55:47 2015] Why we separate terms on functions and terms but don't separate types with this logic? [Fri Mar 13 10:56:19 2015] ianjneu, ok, so the difference is in elimination logic [Fri Mar 13 10:56:24 2015] ianjneu, understood, thanks [Fri Mar 13 10:57:21 2015] I just try to implement very simple deptyped language and thought to describe both "fun" and "forall" as lambda internally. [Fri Mar 13 10:57:40 2015] Yes, this is a little confusing. [Fri Mar 13 10:58:19 2015] lambda can take types as arguments (that's a polymorphic function) [Fri Mar 13 10:58:30 2015] and it's tempting, but I think misleading, to call that a "forall" [Fri Mar 13 10:58:47 2015] lambda that take term and lambdas that take types are the same thing [Fri Mar 13 10:58:51 2015] but not lambda and the types of lambda [Fri Mar 13 10:58:54 2015] *lambdas [Fri Mar 13 10:58:54 2015] Pure type systems (PTS) treat them all the same. Application with a "forall" is essentially a logical "cut" [Fri Mar 13 10:59:19 2015] even in a PTS, lambdas and arrow types are different syntactic things [Fri Mar 13 10:59:22 2015] The foundational issues change in ways I'm not intimately familiar with. [Fri Mar 13 10:59:41 2015] but we can get away with only one kind of lambda and only one kind of arrow type [Fri Mar 13 10:59:49 2015] even though we have both term-level and type-level lambdas [Fri Mar 13 11:00:03 2015] does that make sense? [Fri Mar 13 11:03:35 2015] So if you have a look at page 88 here: http://ttic.uchicago.edu/~dreyer/course/papers/barendregt.pdf [Fri Mar 13 11:03:53 2015] (this the standard reference for pure type systems) [Fri Mar 13 11:04:07 2015] You'll see, Definition 5.1.10, that in the lambda cube there is a distinction between Lambda and Pi [Fri Mar 13 11:04:22 2015] lambdas are functions, pis are the types of functions [Fri Mar 13 11:05:03 2015] we say this syntax is "collapsed" because: 1) there is only one syntactic category (not separate types and terms) and 2) we just have one lambda syntax, which represents both lambdas that take terms as arguments and lambdas that take types as arguments [Fri Mar 13 11:05:15 2015] (and similarly for PIs) [Fri Mar 13 11:05:21 2015] *Pi [Fri Mar 13 11:05:42 2015] this is certainly confusing, but hopefully that helps a little. [Fri Mar 13 11:17:33 2015] ianjneu, wow, nice pointer, will dig into PTS [Fri Mar 13 14:37:38 2015] i have clone the git repo of coq. How can i get the 8.49l5 version ? [Fri Mar 13 14:40:13 2015] You mean 8.4pl5? [Fri Mar 13 14:40:17 2015] yes [Fri Mar 13 14:40:25 2015] "git checkout V8.4pl5" should work [Fri Mar 13 14:40:31 2015] thks a lot [Fri Mar 13 14:40:35 2015] It's tagged in the repo: https://github.com/coq/coq/releases [Fri Mar 13 14:41:00 2015] pdxleif i didn't know this URL :) [Fri Mar 13 14:41:57 2015] It's the "60 releases" link from the bar on top of the home page of the repo on github [Fri Mar 13 14:45:54 2015] pdxleif my browser is a little broken to render github. sorry. [Fri Mar 13 15:24:57 2015] Anarchos: the other way you can list the releases, from a git repo, is by running "git tag" :) [Fri Mar 13 15:31:03 2015] RchrdB thanks too [Fri Mar 13 15:36:46 2015] Do i need both camlp4 and camlp5 to compile coq ? [Fri Mar 13 23:18:18 2015] Has anyone here worked with Menhir's Coq backend? I have a question about it, but it's sufficiently esoteric that I figured I'd check first. [Sat Mar 14 07:39:37 2015] i am trying to compile coq 8.4pl5 but i got troubles with q_util.cmo complaining about CompatLoc [Sat Mar 14 09:03:11 2015] can all classical theorems be proven doubly negated [Sat Mar 14 09:03:32 2015] http://en.wikipedia.org/wiki/Double-negation_translation [Sat Mar 14 09:03:39 2015] With enough double negations, yes [Sat Mar 14 09:03:43 2015] interesting [Sat Mar 14 09:03:59 2015] But just ~~Theorem won't work in general [Sat Mar 14 15:47:36 2015] if I'm getting an error like "The term "Gram.EOF't" has type "Gram.terminal'" which should be Set, Prop or Type." in a match statement pattern, what am I doing wrong? [Sat Mar 14 15:49:35 2015] The error message index tells me that the type's already defined. I'm trying to figure out how that's relevant... [Sat Mar 14 18:48:39 2015] johnw: could you upload your proof of [Lemma rev_pal_length : forall (X : Type) (n : nat) (xs : list X), length xs <= n -> xs = rev xs -> pal xs.] somewhere? I've been trying to prove the rev_pal exercise (while asking questions on irc) for about two weeks, I think, and I have no idea how to prove this particular lemma, which is required. the key here is the [length xs] hypothesis, but I don't know how to transform it to gain [Sat Mar 14 18:48:39 2015] anything. [Sat Mar 14 19:14:13 2015] nkar`: have you tried inducting on n without introducing xs first (equivalently, using [generalize dependent xs] before inducting)? [Sat Mar 14 19:15:14 2015] jrw: no I haven't. let me try that. [Sat Mar 14 19:23:54 2015] jrw: I always get stuck in the succ case: https://gist.github.com/nkaretnikov/3baf1ee07fe0f41646a3 [Sat Mar 14 19:30:37 2015] nkar`: so your first subgoal there has a contradiction in it [Sat Mar 14 19:30:48 2015] because it says xs has length 0, but also that it equals y :: ys [Sat Mar 14 19:31:02 2015] so you need to mess around with it and convince coq that can't happen [Sat Mar 14 19:31:52 2015] * tries [Sat Mar 14 19:42:12 2015] jrw: I don't know how to "convince" coq nor have a useful lemma. so I changed <= to < in the definition of the lemma (Cypi suggested that in the past) and used inversion. but now I have a similar problem in the next case. I still see no way to connect the length of a list with the list itself, so I'm stuck again. [Sat Mar 14 19:43:58 2015] nkar`: you can do that. you could have also proved the lemma "length xs = 0 -> xs = []" [Sat Mar 14 19:44:22 2015] you could also have just destructed xs, and in the cons case you would have gotten 1 <= 0, which is a contradiction [Sat Mar 14 19:44:41 2015] okay, but what do I need to do now? [Sat Mar 14 19:44:44 2015] but anyways, now you're in the next case? you probably want to destruct xs [Sat Mar 14 19:44:56 2015] okay, trying [Sat Mar 14 19:45:08 2015] then you'll need a way to take the last element off of a list [Sat Mar 14 19:45:13 2015] that's going to be a separate lemma [Sat Mar 14 20:05:23 2015] jrw: I updated the gist, still stuck at the cons step [Sat Mar 14 20:09:32 2015] nkar`: you can't apply the induction hypothesis yet [Sat Mar 14 20:09:42 2015] you'll need to take the end off of xs first [Sat Mar 14 20:10:12 2015] something like [forall xs, xs = [] \/ exists xs' x, xs = xs' ++ [x]] [Sat Mar 14 20:10:20 2015] which you'll have to prove [Sat Mar 14 20:10:52 2015] sf hasn't introduced exists yet [Sat Mar 14 20:11:07 2015] is there another way? [Sat Mar 14 20:11:27 2015] I know how to define the init function, for instance. [Sat Mar 14 20:11:54 2015] which theorems do I need to prove about it in order to use it here? [Sat Mar 14 20:12:03 2015] or is it a wrong approach? [Sat Mar 14 20:13:57 2015] nkar`: not sure what init is. if you want to avoid exists you could define "last" and "butlast" functions [Sat Mar 14 20:15:01 2015] jrw: the function that takes all elements except the last one [Sat Mar 14 20:15:17 2015] okay great, that's what I meant by "butlast" [Sat Mar 14 20:15:34 2015] then prove that, when xs is not nil, xs = init xs ++ [last xs] [Sat Mar 14 20:15:36 2015] or something [Sat Mar 14 20:16:43 2015] aha! so the way to talk about the case when xs is not nil is to use or as you did [Sat Mar 14 20:17:15 2015] okay, I'll try a bit later since I need to sleep [Sat Mar 14 20:17:32 2015] thanks for your help (and patience :)) [Sat Mar 14 20:23:36 2015] np, good luck! [Sun Mar 15 01:16:37 2015] nkar` : (I assume you'll read that somewhere later) A way to get the last element of a list is to destruct (rev xs) :) [Sun Mar 15 01:17:22 2015] However, if you just do [destruct (rev xs)], you will lose some of the information, you need to do [destruct (rev xs) eqn:Hrev] (or any other tactic that allows you to keep that fact) [Sun Mar 15 02:22:11 2015] nkar`: hi, are you still there? [Sun Mar 15 03:33:10 2015] johnw: yes [Sun Mar 15 03:33:18 2015] hi [Sun Mar 15 03:33:34 2015] nkar`: https://gist.github.com/f4f5a2809edab8153332 [Sun Mar 15 03:34:18 2015] johnw: thank you! I'll try what jrw suggested first. if I fail, I'll check your solution. [Sun Mar 15 03:35:24 2015] my solution was ultimately recommended to me by Cale and Basile (who I think isn't here right now) [Sun Mar 15 03:35:57 2015] nkar`: I should mention that the suggestion to [destruct (rev xs) eqn:?] is way better than what I told you to do. [Sun Mar 15 07:01:06 2015] Hello, I am building a coinductive structure called sequence, which can either be finite and infinite. I also built a taken which pop the first n element (or lesser if it reach end of sequence). How can I prove Theorem In_appear a (s : sequence) n : In a (take_n s n) -> appear a s. ?What should I do after cofix? [Sun Mar 15 07:44:38 2015] No need for cofix... Just generalize dependent and induction n. [Sun Mar 15 08:09:46 2015] hello. does anyone know if http://www.math.tau.ac.il/~haimk/adv-ds-2000/jacm-final.pdf has already been implemented in coq somewhere? [Sun Mar 15 15:49:09 2015] I need help to compile coq. [Sun Mar 15 15:57:37 2015] Anarchos: what's the problem? [Sun Mar 15 15:58:17 2015] Error: Unbound module CompatLoc [Sun Mar 15 16:47:25 2015] If terminal is an Inductive that takes no args and symbol_semantic type is an Inductive that takes one arg, what exactly is this? Definition token := {t:terminal & symbol_semantic_type (T t)}. [Sun Mar 15 16:47:54 2015] Where T is a constructor for symbol_semantic_type [Sun Mar 15 16:49:38 2015] ptrz: do you have a paste that typechecks? [Sun Mar 15 16:50:38 2015] ianjneu: I don't, sadly. That's the problem. [Sun Mar 15 16:51:18 2015] The only known usage of this code actually extracts it to OCaml first and then uses Obj.Magic to construct one [Sun Mar 15 16:52:13 2015] When you say an inductive that takes no args, what do you really mean? [Sun Mar 15 16:52:54 2015] do you mean `Inductive terminal :=.` ? Do you mean `Inductive terminal := mk_terminal : terminal.` ? [Sun Mar 15 16:53:05 2015] something else? [Sun Mar 15 16:54:24 2015] ianjneu: https://github.com/plsql/verified-parser-example/blob/master/validator/Grammar.v [Sun Mar 15 16:57:17 2015] so that would be an element of an alphabet paired with whatever its assigned "semantic type" is. Since this has no uses of the modules, I'm not quite sure of its utility. [Sun Mar 15 16:58:53 2015] ianjneu: How would I construct a value of that type? [Sun Mar 15 17:00:04 2015] existT _ [Sun Mar 15 17:00:26 2015] the _ is for the (fun t => symbol_semantic_type (T t)) that should be inferred. [Sun Mar 15 17:05:18 2015] ianjneu: Thanks. Where does the existT come from? [Sun Mar 15 17:05:29 2015] Locate existT ? [Sun Mar 15 17:05:51 2015] I guess I mean more, why is that the constructor? [Sun Mar 15 17:05:55 2015] existT is the introduction form for sigT, the type that { x:A & P x } is sugar for. [Sun Mar 15 17:06:20 2015] I guess, most generally, I don't know what the curly braces and ampersand syntax means, and wasn't able to find out online [Sun Mar 15 17:06:22 2015] sigT (fun x : A => P x) more precisely. [Sun Mar 15 17:06:47 2015] ptrz: when in doubt, Set Printing All. [Sun Mar 15 17:07:29 2015] ptrz it is a subset, as you would write in ZFC standard maths ! [Sun Mar 15 17:07:47 2015] ptrz x is in A and P x holds. [Sun Mar 15 17:07:55 2015] I see. Sorry, I'm very new to Coq and kind of got dropped in head-first [Sun Mar 15 17:08:07 2015] and thanks for all the help [Sun Mar 15 17:08:31 2015] ptrz no troubles, we all were new in some time ! [Sun Mar 15 17:09:13 2015] For what it's worth, my current subproject is to make a minimal example of a formally verified parser using CompCert's implementation [Sun Mar 15 17:09:24 2015] which just got added to Menhir but is as-of-yet undocumented [Sun Mar 15 17:10:05 2015] so, I'm working with undocumented research code and a single obfuscated implementation :-) Quite a sudden introduction to Coq [Sun Mar 15 17:10:36 2015] ptrz: what? The types aren't self-documenting? :P [Sun Mar 15 17:17:05 2015] I really can't understand this error ... http://pastebin.com/Wv4NXU7N [Sun Mar 15 17:17:48 2015] On the 10th line, there IS an instance of "Plus L" .. [Sun Mar 15 17:58:20 2015] ianjneu: are you still around? [Sun Mar 15 17:58:30 2015] ptrz: for the time being. [Sun Mar 15 17:58:54 2015] ianjneu: do you think you could do me a huge favor and show me an example of an expression of type token? [Sun Mar 15 17:59:02 2015] I'm still having trouble putting it together [Sun Mar 15 18:00:26 2015] I think that once I have an example to work off of I'll be fine [Sun Mar 15 18:00:29 2015] that's how it's worked so far [Sun Mar 15 18:00:32 2015] it's whatever you create for your Alphs module that you give to Symbol. [Sun Mar 15 18:01:17 2015] No ideas for my problem ? [Sun Mar 15 18:01:52 2015] Choups314: Make sure it's not a notation problem with Set Printing All ? [Sun Mar 15 18:04:04 2015] HA! I figured it out [Sun Mar 15 18:04:20 2015] I was just being a dope and using "unit" as the unit value instead of tt [Sun Mar 15 18:05:20 2015] if either of you know ghc, I could use some help getting profiling working. #haskell is ignoring me. [Sun Mar 15 18:10:33 2015] ianjneu, Sorry, I was afk, In fact I just realoaded the buffer (coqide) and now it's working .. [Sun Mar 15 18:11:34 2015] I am livid. I can't figure out profiling at all. Nowhere online seems to recount this kind of trouble. [Sun Mar 15 18:19:18 2015] ianjneu: I haven't worked with it in a very long time, but I once did a fair bit [Sun Mar 15 18:19:24 2015] what kind of errors are you getting? [Sun Mar 15 18:21:54 2015] ptrz: it wants me to have the base library compiled for profiling, but gives no instruction on how to do that. All the stuff online says to use cabal sandbox etc., but I can't find where to get cabal sandbox at all. I've upgraded cabal, I've looked in apt-get, I'm just frustrated. [Sun Mar 15 18:22:36 2015] ianjneu: Base library? Like, the GHC base library? [Sun Mar 15 18:22:57 2015] It's asking for Prelude [Sun Mar 15 18:23:16 2015] likely it will ask for more once I give the mouse a cookie. [Sun Mar 15 18:24:27 2015] cabal is... still version 1.16. The fuck. [Sun Mar 15 18:25:25 2015] thanks debian. [Sun Mar 15 18:25:34 2015] Yeah, something is very wrong ianjneu [Sun Mar 15 18:25:37 2015] lol [Sun Mar 15 18:25:55 2015] that's like GCC asking for glibc [Sun Mar 15 18:25:58 2015] something is amiss [Sun Mar 15 18:26:05 2015] how did you install GHC? [Sun Mar 15 18:26:15 2015] ptrz: apt [Sun Mar 15 18:26:23 2015] yeah, bizarre [Sun Mar 15 18:27:57 2015] ianjneu: I'm seeing a package ghc-prof. You've installed that? [Sun Mar 15 18:28:17 2015] Also, mentally review whether you've been doing anything weird with GHC config or with library paths [Sun Mar 15 18:30:07 2015] I downloaded the updated version of cabal, and it's complaining I don't have libgmp, which I do. The rage. It boils. [Sun Mar 15 18:33:37 2015] I had almost forgotten the hell of build systems. I've spent several years in Racket, where I can just run "racket myfile.rkt" and it works. [Sun Mar 15 18:37:16 2015] aaaaaand I can't build cabal-install because I can't cabal install Data.Traversable, and cabal doesn't have a 64-bit prebuilt executable for linux [Sun Mar 15 18:37:19 2015] WINNING [Sun Mar 15 18:38:20 2015] ianjneu: Yeah, the Haskell package system is a nightmare [Sun Mar 15 18:38:36 2015] that whole aspect of the language is really a failure [Sun Mar 15 18:39:00 2015] ianjneu: Are you sure your LIBDIR isn't poisoned somehow? [Sun Mar 15 18:39:11 2015] it sounds like things are just generally having a hard time finding libraries [Sun Mar 15 18:39:38 2015] no idea. [Sun Mar 15 18:40:17 2015] check 'env | grep -i lib' in your shell [Sun Mar 15 18:40:40 2015] I can go into ghci and import Data.Traversable no problem. This is such bullshit. [Sun Mar 15 18:41:07 2015] I don't have a LIBDIR env [Sun Mar 15 18:41:08 2015] On a separate note, is there a way to list all modules declared in a Coq source file? [Sun Mar 15 18:42:05 2015] Print Modules. [Sun Mar 15 18:43:54 2015] thanks [Sun Mar 15 18:44:16 2015] ianjneu: What's your uname -a? [Sun Mar 15 18:46:05 2015] Linux bruce 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [Sun Mar 15 18:47:40 2015] I suspect you'll find your answer if you do enough StackOverflow digging [Sun Mar 15 18:47:55 2015] that said, this kind of stuff happens all the time with Haskell and it's awful [Sun Mar 15 18:50:11 2015] If you were tinkering with some settings, configs, or internals, cleaning house and reinstalling all your Haskell-related packages is sometimes the easiest approach [Sun Mar 15 18:53:04 2015] I got cabal installed miraculously. I have a sandbox created. I am now trying to pull in my dependencies, which ARE written in my .cabal file, but for some reason weren't pulled in with --only-dependencies [Sun Mar 15 18:56:14 2015] and now it wants my .cabal file to use "section syntax" which it says is in the user's guide, but isn't. [Sun Mar 15 19:05:33 2015] Yeah, I wish I had recent enough experience to help you [Sun Mar 15 19:05:46 2015] I'd probably reinstall if possible [Sun Mar 15 19:16:52 2015] ...success? I think? [Sun Mar 15 19:22:51 2015] ianjneu: nice! what did you do? [Sun Mar 15 19:24:31 2015] ptrz: destroyed the sandbox I was in, deleted the old .cabal file, apt-get install'd ghc-prof, did cabal init, cabal install --only-dependencies --enable-library-profiling, cabal build [Sun Mar 15 19:25:01 2015] NO SWEAT! Turns out profiling can't be interrupted. Fucking lame. [Mon Mar 16 08:33:41 2015] ~~~P -> ~P, right [Mon Mar 16 08:40:22 2015] benzrf : yes [Mon Mar 16 08:44:15 2015] hmmm [Mon Mar 16 09:04:52 2015] so... [Mon Mar 16 09:05:05 2015] ~~LEM \/ ~LEM is a theorem [Mon Mar 16 09:05:09 2015] but not ~~LEM [Mon Mar 16 09:06:22 2015] I really don't think so [Mon Mar 16 09:06:25 2015] oh wait [Mon Mar 16 09:06:42 2015] if you really mean [~~ (forall P, P \/ ~P) \/ ~ (forall P, P \/ ~P) ] [Mon Mar 16 09:07:02 2015] hold up [Mon Mar 16 09:07:05 2015] ah i think i see [Mon Mar 16 09:07:20 2015] ~~(P \/ Q) does not imply ~~P \/ ~~Q? [Mon Mar 16 09:08:16 2015] I don't think so [Mon Mar 16 09:08:27 2015] er, as in, you dont think it implies [Mon Mar 16 09:08:34 2015] I don't think it implies [Mon Mar 16 09:11:02 2015] kk [Mon Mar 16 09:11:37 2015] ah yes you cannot destruct on the disjunction because there's no witness [Mon Mar 16 09:11:44 2015] did i misuse witness there [Mon Mar 16 10:07:01 2015] what's new [Mon Mar 16 10:08:45 2015] ianjneu: was that a greeting or was it sarcastically mockery like "what else is new" [Mon Mar 16 10:09:34 2015] benzrf: a greeting. I just rejoined. What context did I just jump into? [Mon Mar 16 10:10:09 2015] 09:11:37 benzrf │ ah yes you cannot destruct on the disjunction because there's no witness [Mon Mar 16 10:10:10 2015] 09:11:43 benzrf │ did i misuse witness there [Mon Mar 16 10:10:15 2015] i didnt see the join cause bouncer playback [Mon Mar 16 10:11:47 2015] witness is usually used for existential (Sigma) types. A disjunction is a simple sum. [Mon Mar 16 10:11:56 2015] "witness" I should say. [Mon Mar 16 10:12:11 2015] the "use mention distinction" is not "enforced here" [Mon Mar 16 10:12:55 2015] You can eliminate a disjunction into a Prop, but you don't get to assume the negation of the other case. [Mon Mar 16 10:15:13 2015] ~~LEM is not a theorem because of the quantifier under the ~~. You can prove forall P, ~~(P \/ ~P). [Mon Mar 16 11:02:02 2015] hhh [Mon Mar 16 11:06:18 2015] ugh [Mon Mar 16 11:06:25 2015] i might just use untyped LC after all [Mon Mar 16 11:06:29 2015] gross [Mon Mar 16 11:08:14 2015] simply typed looks like its gonna force me to add naturals as a primitive or osmething [Mon Mar 16 11:24:39 2015] why? [Mon Mar 16 16:03:45 2015] ianjneu: so that i can encode data [Mon Mar 16 16:13:00 2015] ah. Ya, primitive recursion + stlc > stlc [Mon Mar 16 16:23:45 2015] oh [Mon Mar 16 16:23:52 2015] ianjneu: actually im using stlc + fix [Mon Mar 16 16:24:13 2015] ianjneu: but regardless, the type system is too simple to allow usable data encoding [Mon Mar 16 16:24:21 2015] afaict anyway :| [Mon Mar 16 16:53:40 2015] can you quantify over Type in Prop? [Mon Mar 16 16:54:36 2015] Saizan: forall (X : Type) (P : X -> Prop) (x : X), P x? [Mon Mar 16 16:56:36 2015] johnw: more like, [Mon Mar 16 16:56:51 2015] johnw: actuaally, what's the sort of that type? [Mon Mar 16 16:57:09 2015] that type is in Type [Mon Mar 16 16:57:18 2015] I think all functions are in Type [Mon Mar 16 16:57:53 2015] i'd expect P -> Q to be in Prop for P, Q : Prop [Mon Mar 16 16:58:04 2015] let me check [Mon Mar 16 16:58:19 2015] ah, you are right [Mon Mar 16 16:58:23 2015] the sort of that function up above is in Prop [Mon Mar 16 16:58:49 2015] actually, that should have been obvious, because I have pi-types inside of Records that live in Prop just fine [Mon Mar 16 17:01:31 2015] so i guess an Inductive O : Prop with a contructor lim : forall (X : Type) -> (X -> O) -> O would be fine? [Mon Mar 16 17:02:09 2015] s/->/,/, and yeah [Mon Mar 16 17:03:25 2015] but there's some restriction on how you can eliminate a Prop [Mon Mar 16 17:03:33 2015] correct [Mon Mar 16 17:03:49 2015] you can't eliminate it in any context which would depend on the value at runtime [Mon Mar 16 17:05:55 2015] but things like accessibility proofs for well-founded induction go in Prop, right? [Mon Mar 16 17:06:20 2015] yes, because we only need to know that it is accessible, not how [Mon Mar 16 17:07:50 2015] i guess having only one constructor means there's no way to return different results for different proofs [Mon Mar 16 17:08:20 2015] why would that matter? [Mon Mar 16 17:08:29 2015] you only need the inhabitant, any inhabitant will do [Mon Mar 16 17:08:32 2015] (in Prop) [Mon Mar 16 17:08:52 2015] well, i mean when you build the well-founded induction principle [Mon Mar 16 17:09:14 2015] so, the induction principle is always in Prop, which shouldn't care [Mon Mar 16 17:09:15 2015] johnw: anyhow, got a good reference for the rules of Prop? [Mon Mar 16 17:09:43 2015] sadly, I don't [Mon Mar 16 17:09:50 2015] the rec or rect principles will care, on the other hand [Mon Mar 16 17:09:58 2015] which, for your O, can't be generated [Mon Mar 16 17:10:12 2015] uh, i'd expect to be able to use well-founded induction to define stuff in Set though [Mon Mar 16 17:10:36 2015] oh, sure, the proof of well-foundedness should be in Prop [Mon Mar 16 17:10:46 2015] you just can't use what you learned by proving it in any material way [Mon Mar 16 17:10:59 2015] yeah [Mon Mar 16 17:11:58 2015] Hi, if I define an instance (of a class) in a section (assume it depends on an hypothesis), how can I use this instance outside the section ? [Mon Mar 16 17:12:07 2015] say: Global Instance [Mon Mar 16 17:12:40 2015] But how can I "reconstruct" it, given a proof of the hypothesis ? (Or maybe it's automatic ?) [Mon Mar 16 17:12:59 2015] hmm? did those questions relate to each other? [Mon Mar 16 17:13:49 2015] yes ^^, I mean : Does a simple [Context ..] is enough to use the instance outside the section ? (In this case, how do I give the hypothesis proof ?) [Mon Mar 16 17:14:09 2015] you need to use Global in the section to make the instance visible outside of it [Mon Mar 16 17:14:20 2015] after that, you can use Context to introduce it as an implicit argument, sure [Mon Mar 16 17:14:38 2015] It also works with dependent instances ? [Mon Mar 16 17:14:44 2015] what is a dependent instance? [Mon Mar 16 17:15:08 2015] I use a [Hypothesis ...] in the section to prove the instance [Mon Mar 16 17:15:16 2015] Saizan: is this of interest? http://homotopytypetheory.org/2012/01/22/univalence-versus-extraction/ [Mon Mar 16 17:15:27 2015] Choups314: Hypothesis doesn't prove anything :) [Mon Mar 16 17:15:45 2015] it's a local Axiom, which will turn into an argument to the instance which you use it outside [Mon Mar 16 17:16:09 2015] johnw, Yea exactly, but I would like to give the proof when using [Context] (or equivalent) [Mon Mar 16 17:16:17 2015] it should just be an argument [Mon Mar 16 17:16:31 2015] Context H : MyInstance arg. [Mon Mar 16 17:16:31 2015] ok, but then I use the instance name in [context] ? [Mon Mar 16 17:16:33 2015] Ok [Mon Mar 16 17:19:08 2015] johnw, But then, [MyInstance arg] does not have a Set,Prop,Type type ? [Mon Mar 16 17:19:41 2015] you can evaluate"'Check MyInstance arg" to see what sort it is [Mon Mar 16 17:19:53 2015] It is the type of the instance [Mon Mar 16 17:19:58 2015] (Defined in the section ^^) [Mon Mar 16 17:20:11 2015] then use Check on the name of the class [Mon Mar 16 17:20:18 2015] I'm guessing if you didn't say otherwise, it's in Type [Mon Mar 16 17:20:31 2015] Yes [Mon Mar 16 17:22:16 2015] In fact now it complains "MyInstance arg " has type "ClassName" which should be Set, Prop or Type. [Mon Mar 16 17:22:46 2015] oh, show me the line [Mon Mar 16 17:23:09 2015] The context line ? [Mon Mar 16 17:23:11 2015] yeah [Mon Mar 16 17:23:21 2015] Context {Kone : (Fone L Kprop Hone)}. [Mon Mar 16 17:23:29 2015] btw, this will work too: Context `{Fone L Kprop Hone}. [Mon Mar 16 17:23:29 2015] Fone is the instance defined in a previous section [Mon Mar 16 17:23:36 2015] oh [Mon Mar 16 17:23:37 2015] wait [Mon Mar 16 17:23:39 2015] you can't do that [Mon Mar 16 17:24:03 2015] so, if you want to treat an instance like a record value like this [Mon Mar 16 17:24:12 2015] do: Variable Kone : Fone L Kprop Hone. [Mon Mar 16 17:24:26 2015] now you can call member functions on Kone directly using @ [Mon Mar 16 17:24:31 2015] @method Kone args... [Mon Mar 16 17:24:45 2015] which basically begs the question of why are you using type classes then? [Mon Mar 16 17:25:27 2015] Context brings a family of instances into scope, allowing the type class machinery to pick the appropriate instance [Mon Mar 16 17:25:40 2015] hence the sort error [Mon Mar 16 17:25:56 2015] In fact I'm using MathClasses, and I defined substructures. Now I try to define some vector spaces, but I'm not sure [Mon Mar 16 17:26:41 2015] if these substructures are well defined (i.e. use well the instances/classes system) [Mon Mar 16 17:27:29 2015] johnw: yah, "singleton elimination" is what i needed to google for [Mon Mar 16 17:29:07 2015] ah, right [Mon Mar 16 17:29:13 2015] I had thought your "only one constructor" comment sounded familiar [Mon Mar 16 17:37:19 2015] johnw, The problem if I use [Let] or [Variable] is that there is no such instance defined after .. I would like to use the instance I defined in a previous section, that depend on an argument (i.e. I would like to "import" it in another section, with a certain proof for the argument) [Mon Mar 16 17:37:45 2015] Choups314: can you reduce what you want to a small example? [Mon Mar 16 17:37:52 2015] then maybe I can get it working for you (later tonight) [Mon Mar 16 17:38:08 2015] johnw, I'll try ;) [Mon Mar 16 17:38:12 2015] Just a minute ;) [Mon Mar 16 17:38:28 2015] no hurry, I can't do it right now anyway [Mon Mar 16 17:38:33 2015] ok [Mon Mar 16 17:38:37 2015] but if you ping me again in like 6 hours I'd be more than happy to give it a go [Mon Mar 16 17:38:51 2015] Ok :) [Mon Mar 16 17:43:37 2015] what is the best option to use ocaml/coq on windows to compile compcert ? [Mon Mar 16 17:44:47 2015] Anarchos: you mean, besides a Linux VM? [Mon Mar 16 17:45:29 2015] johnw yes [Mon Mar 16 17:45:45 2015] I have never tried to use Coq on Windows... [Mon Mar 16 17:45:53 2015] compcert needs ocaml 4.02 but the cygwin version seems to be only 4.01.0 [Mon Mar 16 17:47:17 2015] ah [Mon Mar 16 17:49:30 2015] johnw, https://gist.github.com/Choups314/bd832a56d7253ea2b292 [Mon Mar 16 17:50:29 2015] I will have to go in 10 minutes, so I'll ping you later (tomorrow ?) [Tue Mar 17 05:30:02 2015] how can I call Extraction command in Prof General? [Tue Mar 17 05:30:24 2015] I know I can type it in a file and evaluate it to get the result [Tue Mar 17 05:30:39 2015] but I'd rather use M-x some-command-for-extraction [Tue Mar 17 05:30:57 2015] where some-command-for-extraction is the name I don't know [Tue Mar 17 05:50:29 2015] I've run into problems using Notation [Tue Mar 17 05:50:31 2015] if I say [Tue Mar 17 05:50:43 2015] Notation "{ x : A | P }" := sig (fun x : A => P) [Tue Mar 17 05:51:09 2015] that fails with a syntax error: [syntax_modifier] expected after '(' [Tue Mar 17 05:51:27 2015] but if I surround that declaration with (** [[ ... ]] *) the it works [Tue Mar 17 08:39:20 2015] jstolarek: the term after the := must be a single "group". If it's a function application, you need to surround it with parentheses. [Tue Mar 17 16:49:28 2015] johnw, Did you my gist yesterday ? [Tue Mar 17 21:22:40 2015] Choups314: hello? [Wed Mar 18 03:57:04 2015] Hi. I'm trying to follow Software Foundations and I'm up to chapter "MoreCoq" but I can't compile the prerequisite Poly.v. It's failing at "Arguments nil {X}." with "Error: No focused proof (No proof-editing in progress)." [Wed Mar 18 03:58:22 2015] what versions of Coq and SF? [Wed Mar 18 03:59:20 2015] johnw: 8.3pl4 and latest SF. Apparently it's quite ancient... from 2013. Could that be the issue? [Wed Mar 18 03:59:40 2015] the lastet SF is 3.1, from June 2014 [Wed Mar 18 03:59:56 2015] Oh, I meant that version of coq [Wed Mar 18 04:00:06 2015] ah, 8.3 won't work [Wed Mar 18 04:00:08 2015] 8.4pl5 [Wed Mar 18 04:00:22 2015] Damnit, Debian... [Wed Mar 18 04:00:35 2015] johnw: cool, thanks! [Wed Mar 18 04:21:31 2015] jstolarek pasted “No title” at http://lpaste.net/127263 [Wed Mar 18 04:21:48 2015] I don't understand how that notation works [Wed Mar 18 04:22:05 2015] I mean is e2 required to be maybe? [Wed Mar 18 04:22:30 2015] or can it be anything? because if it can ba anything then this would mean branches of if have different types [Wed Mar 18 04:22:46 2015] I know this is possible with dependent types but still that looks weird... [Wed Mar 18 04:30:36 2015] hi jstolarek [Wed Mar 18 04:31:15 2015] I believe e2 can be anything in terms of _using_ the notation [Wed Mar 18 04:31:24 2015] but the expanded code would be in error unless e2 is what it needs to be [Wed Mar 18 04:32:14 2015] johnw: hi [Wed Mar 18 04:32:29 2015] but if the else branch is a maybe [Wed Mar 18 04:32:40 2015] then doesn't e2 need to be a maybe as well? [Wed Mar 18 04:32:47 2015] it would, yes [Wed Mar 18 04:32:57 2015] assuming the condition can evaluate to any of the two constructors [Wed Mar 18 04:33:13 2015] ok, that's what I was asking [Wed Mar 18 04:34:21 2015] yeah, the notation doesn't change anything about Gallina [Wed Mar 18 04:34:25 2015] it's just very fancy macros [Wed Mar 18 04:37:58 2015] jstolarek pasted “No title” at http://lpaste.net/127264 [Wed Mar 18 04:38:08 2015] a quick follow-up question [Wed Mar 18 04:38:34 2015] Notation clearly shows that Unknown takes one argument, while Found takes 3 [Wed Mar 18 04:38:54 2015] ok [Wed Mar 18 04:39:07 2015] but how do I know which argument is which? [Wed Mar 18 04:39:17 2015] what do you mean? [Wed Mar 18 04:39:19 2015] I mean for Unknown, is the one argument A or P ? [Wed Mar 18 04:39:50 2015] I guess you have automatic implicits turned on, in which case it would be P [Wed Mar 18 04:39:52 2015] for Found I guess that first argument is (A : Set), second is (x : A) and the third is (P : A -> Prop) [Wed Mar 18 04:40:05 2015] but what's the rule of thumb here? [Wed Mar 18 04:40:15 2015] the rule of thumb here has nothing to do with Notations [Wed Mar 18 04:40:21 2015] A can be determined from any P [Wed Mar 18 04:40:32 2015] if you didn't have auto-implicits on, Unknown would take two arguments [Wed Mar 18 04:40:37 2015] right, but notation exposes that nicely :-) [Wed Mar 18 04:41:15 2015] so, a Coq reader would know by printing Unknown [Wed Mar 18 04:41:31 2015] which will say that A is implicit [Wed Mar 18 04:41:40 2015] right, that's what it says [Wed Mar 18 04:41:49 2015] ok, what about Found ? [Wed Mar 18 04:41:54 2015] what confuses me here [Wed Mar 18 04:42:13 2015] is that the argument to the type consructor are interleaved with the arguments introduced in forall [Wed Mar 18 04:42:13 2015] somewhere there is a Set Implicit Arguments. [Wed Mar 18 04:42:29 2015] right, all of them are arguments to the constructors [Wed Mar 18 04:42:42 2015] yes, I have implictis turned on [Wed Mar 18 04:42:44 2015] some are notionally "indices", and some are "parameters" [Wed Mar 18 04:42:53 2015] oh, I just realized [Wed Mar 18 04:42:54 2015] but to Coq, they are pretty much all the same [Wed Mar 18 04:43:04 2015] the last argument to Found is not P but (P x) [Wed Mar 18 04:43:08 2015] right [Wed Mar 18 04:43:16 2015] Found's arguments are: P x (_ : P x) [Wed Mar 18 04:43:46 2015] I think that if you also enable Generalizable All Variables., then 'x' would not be needed either there [Wed Mar 18 04:43:52 2015] ok, so indices always go first, unless they are implicit? [Wed Mar 18 04:44:03 2015] indices always go first, even if they are implicit [Wed Mar 18 04:44:06 2015] you just don't have to pass them :) [Wed Mar 18 04:44:21 2015] ok, that is the rule of thumb I was looking for :-) [Wed Mar 18 04:44:47 2015] actually, Found only truly needs one argument [Wed Mar 18 04:44:54 2015] since that argument will determine x, P, and A [Wed Mar 18 04:45:06 2015] I start every file with this: https://gist.github.com/bc11d379475d54d383eb [Wed Mar 18 04:45:17 2015] (this comes from the ssreflect manual, where they use that convention) [Wed Mar 18 04:45:50 2015] "< johnw> actually, Found only truly needs one argument" >> is that true? [Wed Mar 18 04:46:06 2015] johnw: out of curiosity - are you using coq in a "real" project ? [Wed Mar 18 04:46:18 2015] jstolarek: yes, I am [Wed Mar 18 04:46:22 2015] Cypi: let me verify that [Wed Mar 18 04:46:56 2015] yes, that is correct [Wed Mar 18 04:47:02 2015] only the (_ : P x) argument is needed [Wed Mar 18 04:47:11 2015] hmm [Wed Mar 18 04:47:14 2015] "For Found: Arguments A, P, x are implicit" [Wed Mar 18 04:49:05 2015] johnw: can you give any details? :-) [Wed Mar 18 04:49:38 2015] jstolarek: sure, the code is here: https://github.com/jwiegley/linearscan [Wed Mar 18 04:49:47 2015] it's a register allocator to be used in an in-house compiler at work [Wed Mar 18 04:49:58 2015] I have only two implementation details left [Wed Mar 18 04:50:30 2015] it extracts to a Haskell library that's on Hackage [Wed Mar 18 04:50:31 2015] thanks [Wed Mar 18 04:50:35 2015] I'll take a look [Wed Mar 18 04:51:13 2015] johnw : sorry to come back to that, but how can Coq infer A, P and x when you give it, for exemple, [Found I] ? [Wed Mar 18 04:51:37 2015] [Definition foo : maybe (fun (x : nat) => True) := Found I.] doesn't go well [Wed Mar 18 04:51:38 2015] it couldn't be just I [Wed Mar 18 04:51:56 2015] I is an inhabitant of True, which is of the wrong type [Wed Mar 18 04:52:08 2015] the type of P must be A -> Prop [Wed Mar 18 04:52:33 2015] let me try that [Wed Mar 18 04:52:44 2015] You said that P was implicit [Wed Mar 18 04:52:51 2015] the only remaining argument is of type [P x] [Wed Mar 18 04:53:02 2015] which can be True, like in my example [Wed Mar 18 04:53:02 2015] oh sure, that doesn't mean you can't come up with examples where the inference mechanism can't realize an argument [Wed Mar 18 04:53:12 2015] in those cases, you must use @ or (x:=...) [Wed Mar 18 04:53:30 2015] So I think I did not understand "< johnw> since that argument will determine x, P, and A" [Wed Mar 18 04:53:44 2015] I'll show you an example [Wed Mar 18 04:55:24 2015] Cypi: https://gist.github.com/72cd5b90e5b25e586a1b [Wed Mar 18 04:55:43 2015] neatO's type "encodes" sufficient information to package up x and P [Wed Mar 18 04:55:53 2015] johnw: skimmed the files in your project, they are way above my understanding of Coq [Wed Mar 18 04:56:05 2015] jstolarek: also, it's all in ssreflect style [Wed Mar 18 04:56:09 2015] not the Coq standard library [Wed Mar 18 04:56:20 2015] I see. Thanks. [Wed Mar 18 04:56:56 2015] in fact, in the definition of "foo" you can just say "maybe _" [Wed Mar 18 04:57:02 2015] Ok, that's what "Strict Implicit" is for [Wed Mar 18 04:57:05 2015] neatO will provide P there too [Wed Mar 18 04:57:13 2015] what's ssreflect style? [Wed Mar 18 04:57:48 2015] ssreflect is an alternate stdlib that focuses on "small scale reflection", where computable boolean predicates can be easily reflected to decidable inductive predicates and back [Wed Mar 18 04:58:33 2015] it makes certain classes of proofs much smaller, and allows you to prove many things using only term rewriting, without need for induction [Wed Mar 18 04:59:42 2015] for more info, see Ilya Sergey's excellent book, "Programs and Proofs": http://ilyasergey.net/pnp/pnp.pdf [Wed Mar 18 05:00:01 2015] not a huge amount of Coq experience is needed to read that book, either [Wed Mar 18 05:00:01 2015] hm... I don;t understand what you said - sorry :-( [Wed Mar 18 05:00:07 2015] but I'm noting the book reference [Wed Mar 18 05:00:19 2015] jstolarek: the lib was creating to make the Four Color Theorem easier to write, basically [Wed Mar 18 05:00:24 2015] at the moment I am reading CPDT so won't be taking a look in a next couple of weeks [Wed Mar 18 05:00:31 2015] and it turns out, if you're writing real programs with Coq, it makes that easier too [Wed Mar 18 05:00:42 2015] ah, ok, CPDT is much more advanced than that book [Wed Mar 18 05:00:46 2015] so you'll breeze through it [Wed Mar 18 05:02:27 2015] jstolarek: what do you plan on using Coq for? [Wed Mar 18 05:02:33 2015] um... nothing :-) [Wed Mar 18 05:02:40 2015] just learning it for fun [Wed Mar 18 05:02:48 2015] ok, cool! [Wed Mar 18 05:02:51 2015] it is indeed great fun [Wed Mar 18 05:02:59 2015] well, fun and curiosity about how it comapres to Agda or Idris [Wed Mar 18 05:03:18 2015] there are large areas of intersection with both, depending on how you use Coq [Wed Mar 18 05:03:19 2015] as for CPDT: yeah, it's pretty advanced and unfortunatelly far from being self-contained [Wed Mar 18 05:03:31 2015] so, I would read CPDT at a later date [Wed Mar 18 05:03:34 2015] CPDT has a very specific audience [Wed Mar 18 05:03:39 2015] namely? [Wed Mar 18 05:03:53 2015] people are using Coq practically, and who need to know the tricks and techniques to take their use of Coq to the "next level" [Wed Mar 18 05:04:03 2015] I've read like 1/3 of the book so far [Wed Mar 18 05:04:18 2015] if you are a practioner who has struggled with certain issues (like, pattern matching on dependent types, or encoding free structures), then CPDT is a gold mine [Wed Mar 18 05:04:35 2015] it's a great demonstration of what can be done with Coq, not necearilly an explanation of how it can be done... [Wed Mar 18 05:04:36 2015] but if you are just reading to learn more about Coq, there's too much detail, and it's too dense [Wed Mar 18 05:04:50 2015] the first time I read CPDT, it went right over my head [Wed Mar 18 05:04:55 2015] then, six months after using Coq seriously, I read it again [Wed Mar 18 05:04:58 2015] and it was solid gold [Wed Mar 18 05:05:38 2015] well, I don't have any real-life Coq project on the horizon [Wed Mar 18 05:05:50 2015] sadly [Wed Mar 18 05:05:51 2015] then you may never take advantage of what's in CPDT [Wed Mar 18 05:05:56 2015] maybe [Wed Mar 18 05:06:07 2015] unless you find ways to transport those tricks to Agda, say [Wed Mar 18 05:06:14 2015] but the nice thing about CPDT is that it gives also some theoretical insight [Wed Mar 18 05:06:29 2015] he has some pretty cool techniques for modelling turing complete languages in a logic like Coq [Wed Mar 18 05:06:35 2015] true, it does [Wed Mar 18 05:06:44 2015] it's a book worth reading, if one has sufficient time [Wed Mar 18 05:07:11 2015] I'm trying to read 1 sub-section a day [Wed Mar 18 05:07:25 2015] has he gotten into language modelling yet? [Wed Mar 18 05:07:29 2015] which takes ~3-m-1h [Wed Mar 18 05:07:46 2015] there were a couple of examples so far [Wed Mar 18 05:07:47 2015] I [Wed Mar 18 05:07:49 2015] I think he starts out with that really early, actually [Wed Mar 18 05:07:58 2015] so, he's going to come back to that, maybe 5 times over [Wed Mar 18 05:08:03 2015] I'm reading the type-checking example in chapter 6 at the moment [Wed Mar 18 05:08:05 2015] each time using a different technique [Wed Mar 18 05:08:21 2015] :-) [Wed Mar 18 05:08:26 2015] ok, I gotta go [Wed Mar 18 05:08:35 2015] please stop by here if you ever have issues or questions [Wed Mar 18 05:08:42 2015] bye jstolarek [Wed Mar 18 05:08:47 2015] gotta teach my BcS students how to compile GHC [Wed Mar 18 05:08:54 2015] sure, I'll do [Wed Mar 18 05:08:57 2015] bye [Wed Mar 18 08:25:57 2015] johnw: so if CPDT is too advanced what would you recommend as an introduction to Coq? [Wed Mar 18 08:26:24 2015] I'm mostly interested in dependent types (hence CPDT sounds very attractive) [Wed Mar 18 08:40:59 2015] jstolarek: Software Foundations by Ben Pierce. [Wed Mar 18 08:41:26 2015] (and friends) [Wed Mar 18 08:41:28 2015] It's a MUUUCH gentler introduction. [Wed Mar 18 08:56:00 2015] RchrdB: thanks [Wed Mar 18 08:56:22 2015] I don't mind brutality when it comes to dependent types :-) but a more detailed explanation of Coq itself would be nice [Wed Mar 18 08:56:49 2015] BTW. is there a printed version of SF? [Wed Mar 18 08:57:13 2015] You're supposed to go through SF in a Coq session, so I don't think so [Wed Mar 18 09:17:36 2015] too bad. I prefer printed books - much easier to add notes [Wed Mar 18 09:21:31 2015] You're supposed to be editing the source code anyway as you complete exercises. [Wed Mar 18 09:21:41 2015] so adding notes there is a matter of moving a few lines away, genearlly. [Wed Mar 18 09:21:49 2015] s/genearlly/generally/ [Wed Mar 18 09:33:58 2015] is there any MMap implementation around the corner? [Wed Mar 18 09:34:07 2015] google pops up this project https://groups.google.com/forum/?_escaped_fragment_=topic/oplss14/VIBdiX_pG2w#!topic/oplss14/VIBdiX_pG2w [Wed Mar 18 09:34:20 2015] but no hints if it has been done yet [Wed Mar 18 09:35:12 2015] ah the github repo has it [Wed Mar 18 09:39:41 2015] Cypi pasted “Need proof irrelevance?” at http://lpaste.net/127273 [Wed Mar 18 09:39:57 2015] In the linked proof, do I really need proof irrelevance to conclude? [Wed Mar 18 09:40:54 2015] I'm pretty sure I do, but since I know that f goes into something in Type, the return value of f shouldn't depend on the actual value of its argument, right? [Wed Mar 18 16:51:13 2015] jstolarek: probably SF, then Programs and Proofs (although it's geared toward ssreflect), then CPDT [Wed Mar 18 16:51:17 2015] there's not a huge amount of middle ground [Wed Mar 18 16:54:33 2015] i resigned today on CPDT. [Wed Mar 18 16:54:47 2015] too much tricks and no clear explanation of crush. [Wed Mar 18 16:59:31 2015] Anarchos: see http://jozefg.bitbucket.org/posts/2014-07-09-dissecting-crush.html [Wed Mar 18 17:03:58 2015] johnw sure i can find explanation about it somewhere. But hey couldn't Adam do it in his 471pages (or so) book ? [Wed Mar 18 17:08:01 2015] Thanks for the link, I actually wondered how it worked too [Wed Mar 18 17:08:31 2015] I didn't know it used axioms [Thu Mar 19 06:35:53 2015] is there some documentation on the fun x => ... notation? [Thu Mar 19 06:40:38 2015] the closest i could find is https://coq.inria.fr/refman/Reference-Manual003.html#sec31 [Thu Mar 19 06:40:46 2015] but thats kinda indirect [Thu Mar 19 06:41:20 2015] What are you looking for, more precisely? [Thu Mar 19 06:42:58 2015] a definition or explanation of the 'fun' construct for referencing [Thu Mar 19 08:50:51 2015] roosbeef: it is just a lambda term [Thu Mar 19 08:55:37 2015] so im looking for the part of the ref manual where it says that :p [Thu Mar 19 08:57:34 2015] What you linked kind of say that, no? :o Just below it, https://coq.inria.fr/refman/Reference-Manual003.html#sec32 [Thu Mar 19 08:57:59 2015] More precisely, "The expression “fun ident : type => term” defines the abstraction of the variable ident, of type type, over the term term." [Thu Mar 19 08:58:34 2015] type type term term [Thu Mar 19 08:59:38 2015] Well, without the italics, it's less readable, sure :p [Thu Mar 19 09:00:39 2015] ha, yep [Thu Mar 19 09:00:43 2015] thanks Cypi :) [Thu Mar 19 14:52:34 2015] * got coq V8.4pl5 working on HaikuOS o/ [Thu Mar 19 15:29:11 2015] is there a tactic to duplicate a hypothesis? [Thu Mar 19 15:29:47 2015] pose [Thu Mar 19 15:29:56 2015] "pose proof H." will create H0 [Thu Mar 19 16:23:43 2015] is there a way to apply the same tactic n times without repeating it? something like [foo 3 rewrite H.] instead of [rewrite H. rewrite H. rewrite H.] [Thu Mar 19 16:24:17 2015] nkar nothing found in the refman ? [Thu Mar 19 16:24:36 2015] I haven't checked, frankly [Thu Mar 19 16:24:59 2015] the question popped up when this buffer was open, so I just typed it [Thu Mar 19 16:28:33 2015] nkar: foo = do [Thu Mar 19 16:29:09 2015] nkar: Also note the existence of repeat, which repeats a tactic as many times as it succeeds [Thu Mar 19 16:29:10 2015] cool [Thu Mar 19 17:24:42 2015] does constructive logic change anything about russell's paradox [Thu Mar 19 17:24:48 2015] oh wait hold on [Thu Mar 19 17:25:35 2015] R P = ~P P [Thu Mar 19 17:26:04 2015] assuming a type system that would allow that, you need LEM to derive a contra from it, dont you? [Thu Mar 19 17:27:21 2015] or is any type system that allows that already inconsistent for some other reason [Thu Mar 19 17:40:39 2015] "I saw a sign that said falling rocks so I tried and it doesn’t" [Thu Mar 19 17:41:04 2015] and wrong channel [Thu Mar 19 17:41:40 2015] haha [Thu Mar 19 18:09:14 2015] lol [Thu Mar 19 18:10:32 2015] * compiled coq and compcert on haikuOS o/ [Fri Mar 20 06:21:18 2015] johnw, perfect\ thanks! [Fri Mar 20 14:49:08 2015] johnw, ? [Fri Mar 20 14:59:20 2015] Choups314: hi [Fri Mar 20 14:59:35 2015] johnw, Did you see my gist last time ? [Fri Mar 20 14:59:37 2015] so, your Context doesn't work for the same reason this doesn't work: [Fri Mar 20 14:59:42 2015] Variable n : 3. [Fri Mar 20 15:00:21 2015] https://gist.github.com/Choups314/1bd2e9bb65e9fa4e0311 [Fri Mar 20 15:00:26 2015] I change a bit the end [Fri Mar 20 15:05:58 2015] What does [Program Instance] change ? (instead of [Instance] ? [Fri Mar 20 15:12:24 2015] it involves the Program machinery (see that chapter of manual) [Fri Mar 20 15:15:08 2015] Hi everybody, i have a little trouble with an equality predicate. [Fri Mar 20 15:30:30 2015] because my inductive type has 256 constant constructors , coqtop takes a long time to finish the proof, and coqc crashes. [Fri Mar 20 15:31:04 2015] can you paste your predicate? [Fri Mar 20 15:31:54 2015] Lemma eq_dec : forall n m : mreg, {n=m}+{n<>m}. mreg being my type with 256 consntructors named R0,R1,…,R255 [Fri Mar 20 15:32:28 2015] johnw i am trying to port compcert to an architecture with 256 registers, so my modifications in the MAchregs.v file. [Fri Mar 20 15:32:33 2015] what if you write an equality function returning bool [Fri Mar 20 15:32:47 2015] and then use: Lemma eq_dec : forall n m : mreg, is_equal n m = true. [Fri Mar 20 15:33:06 2015] where is_equal looks like: [Fri Mar 20 15:33:08 2015] match n, m where [Fri Mar 20 15:33:13 2015] | A, A -> True [Fri Mar 20 15:33:16 2015] | B, B -> True [Fri Mar 20 15:33:18 2015] ... [Fri Mar 20 15:33:22 2015] | _, _ -> False [Fri Mar 20 15:33:22 2015] end [Fri Mar 20 15:34:19 2015] johnw so the function will be 256 line long, but it is usable. In the first place i thought to use an inductive definition : Inductive mreg : | R :n -> n<256 -> mreg. [Fri Mar 20 15:34:21 2015] Anarchos: is it crucial to the working of compcert that the mreg type be an inductive type with only constant constructors? or can you give it a field from a finite range type where you know equality is decidable [Fri Mar 20 15:34:22 2015] that's not eq_dec, sorry [Fri Mar 20 15:34:40 2015] is_equal is itself decidable [Fri Mar 20 15:34:46 2015] destruct (is_equal n m) eqn:Heqe. [Fri Mar 20 15:34:47 2015] ystael no it is not crucial but i am unable to write it cleanly ! [Fri Mar 20 15:37:16 2015] I don't know if the standard library has a type representing {0, 1, 2, ..., N-1} in it [Fri Mar 20 15:37:26 2015] with all the properties you want for that [Fri Mar 20 15:37:52 2015] you'd think it would but i don't actually know [Fri Mar 20 15:38:10 2015] ystael i don't think so , cause there seem to be such an implementation in compcert, but i am not 100% sure [Fri Mar 20 15:45:11 2015] Is there a way to display the current instances ? (I don't know how it is stored internally, but display a kind of stack maybe ..) [Fri Mar 20 15:56:56 2015] I have no idea, but that's a good question [Fri Mar 20 15:57:32 2015] When doing this : "Instance reflexive proper ‘(Reflexive A R) (x : A) : Proper R x ." [Fri Mar 20 15:57:35 2015] (from the stdlib) [Fri Mar 20 15:58:27 2015] Does it means that when an instance of [Proper R x] is automatically defined when required ? (If it can find a proof of [Reflexive A R]) [Fri Mar 20 16:30:35 2015] nobody knows compcert here ? [Fri Mar 20 23:15:18 2015] Hello everyone, I got struck on a question recently: How can Coq code in one directory Require Import other Coq code in different directory using relative path? I am looking for something like #include"../../blablabla/whatever" in C++, but I can't find anything after searching on stackoverflow and bing... [Sat Mar 21 01:35:47 2015] marisa__: there is a vernacular command for extending the "load path" for Coq [Sat Mar 21 04:08:31 2015] johnw: I know I can Add Load Path, but that would make my code only available on my laptop (other people is not going to run Add LoadPath Marisa/Work/Coq_code/blablabla) [Sat Mar 21 04:08:54 2015] don't relative LoadPath's work? [Sat Mar 21 04:12:10 2015] Nope... Pwd. is /home/marisa, and my code is in /home/marisa/Work/blablabla [Sat Mar 21 04:12:24 2015] ah [Sat Mar 21 07:12:25 2015] johnw: may I ask why you picked coq for the linearscan project as well as the category theory lib? is it because agda lacks tactics and idris is not mature enough? [Sat Mar 21 11:34:17 2015] marisa__: Add the other path to the COQPATH environment variable, and then [Require Import] it as if it were in the same directory. [Sat Mar 21 11:36:20 2015] Thankyou, I will give a try. [Sat Mar 21 12:27:16 2015] jgross, thx, but how can I enable it in COQIDE? [Sat Mar 21 13:35:30 2015] Does it not work automatically if you set COQPATH system-wide before launching coqide, or if you run `COQPATH=... coqide &`? [Sat Mar 21 13:35:35 2015] marisa__: ^ [Sat Mar 21 16:48:25 2015] win 5 [Sat Mar 21 18:09:43 2015] jrw: I'm trying to prove [forall (X : Type) (xs : list X), xs = [] \/ xs = init xs ++ [last xs].], which you suggested some time ago. however, I've just realized that I see no way to define last. what do I need to return if xs == []? [Sat Mar 21 18:10:29 2015] I mean it can't happen in the theorem, but how do I define the function, which doesn't have this constraint? [Sat Mar 21 18:10:49 2015] alternatively, how do I state that a list is nonempty? [Sat Mar 21 18:11:59 2015] I think I could try to return a list in last. so instead of [last xs], it'll be last xs [Sat Mar 21 18:12:09 2015] not sure whether it's useful, though [Sat Mar 21 20:06:32 2015] where can i see the tactic implementations in the coq source? specifically for `intros` and `apply` [Sat Mar 21 20:07:03 2015] if i'm not mistaken this seems to be the implementation for `reflexivity` https://github.com/coq/coq/blob/trunk/tactics/tactics.ml#L4161 [Sat Mar 21 20:07:23 2015] but not sure, and doesn't look like `intros` is in that file [Sun Mar 22 00:11:44 2015] nkar: still there? [Sun Mar 22 04:21:09 2015] johnw: yes [Sun Mar 22 08:52:18 2015] Hello, what is a good precedence level for function composition operator? I never get how I should set the level... [Sun Mar 22 12:59:21 2015] What's a good simple way of representing memory in Coq? I'm working with Bedrock and using their Word type where possible, but I'm having trouble figuring out how to make a memory map with type option (word 32) or option nat [Sun Mar 22 13:17:26 2015] if I have a rule like this [s_rec : forall (x y : X) (xs ys : list X), subseq [x] [y] -> subseq xs ys -> subseq (x::xs) (y::ys).] as a part of the inductive def'n, can I get [subseq [x] [y]] and [subseq xs ys] if I have [subseq (x::xs) (y::ys)] in the hypothesis? [Sun Mar 22 13:39:24 2015] nkar`, I think it depend on your definition of subseq [Sun Mar 22 13:40:40 2015] Don't think s_rec can help you prove what you want. [Sun Mar 22 13:42:29 2015] lolisa: here's my def'n: https://gist.github.com/nkaretnikov/86b84f74ff2cdc216bba [Sun Mar 22 13:42:42 2015] lolisa: but please don't paste yours [Sun Mar 22 13:43:09 2015] instead, tell me what's wrong with it it's the case [Sun Mar 22 13:45:20 2015] OK, I will not paste my. [Sun Mar 22 13:45:49 2015] But I can't see because gov block gist in China. Can you paste it on github repo? [Sun Mar 22 13:47:03 2015] they block only the gist subdomain? [Sun Mar 22 13:47:15 2015] Yes. gov is strange. [Sun Mar 22 13:47:45 2015] I'll just paste it via /q, okay? [Sun Mar 22 13:48:06 2015] OK [Sun Mar 22 13:48:20 2015] done [Sun Mar 22 13:53:32 2015] Your definition of s_req can be simplified : subseq[x][y] imply x = y [Sun Mar 22 13:53:33 2015] Goal forall T (l r : T), subseq [l] [r] -> l = r. [Sun Mar 22 13:53:33 2015] intros. [Sun Mar 22 13:53:33 2015] dependent induction H; [Sun Mar 22 13:53:33 2015] trivial. [Sun Mar 22 13:53:33 2015] Qed. [Sun Mar 22 13:54:16 2015] So you can reduce your s_rec to : forall (x y : X) (xs ys : list X), [Sun Mar 22 13:54:16 2015] x = y -> subseq xs ys -> subseq (x::xs) (y::ys). [Sun Mar 22 13:54:42 2015] and than s_rec : forall (x : X) (xs ys : list X), subseq xs ys -> subseq (x::xs) (x::ys). [Sun Mar 22 13:56:43 2015] as I said privately, I assumed that subseq [x] [y] can match forall xs. subseq nil xs. I'll try the suggested definition, thanks. [Sun Mar 22 13:58:19 2015] And than your definition isn't quite right because I think subseq l r <-> exists blablabla, l ++ blablabla = r, which is not the book want [Sun Mar 22 13:58:47 2015] I think you need more constructors. [Sun Mar 22 13:59:07 2015] the book says that only three cases are needed. [Sun Mar 22 13:59:53 2015] Yes, but your two case overlap [Sun Mar 22 14:00:21 2015] you can get s_one from s_rec and s_nil [Sun Mar 22 14:01:14 2015] Look at the book example for subsequence. Some of them is unprovable with your definition. [Sun Mar 22 14:01:33 2015] [1,2,3][1,2,2,3],for example [Sun Mar 22 14:04:15 2015] hm, I'll think about it later. thanks for the tips! [Sun Mar 22 14:05:18 2015] your wellcome! have a github account? [Sun Mar 22 14:05:46 2015] yes, you can infer it from my gist account. [Sun Mar 22 14:07:12 2015] You know I can't get on gist... [Sun Mar 22 14:07:23 2015] Oh I see... [Sun Mar 22 21:11:53 2015] nkar`: hi [Sun Mar 22 21:22:43 2015] nkar`: I chose Coq mostly because it is very mature and has a proven meta-theory behind it, so it seemed like the most solid foundation to build something whose main selling point was formal verification [Mon Mar 23 01:37:22 2015] johnw: okay, thanks for elaborating. [Mon Mar 23 03:55:16 2015] is it possible to define a "Function" inside a section? I keep getting "No such section variable or assumption" [Mon Mar 23 04:20:29 2015] ah it seems nested matching causes the error [Mon Mar 23 04:23:30 2015] and it is actually reasonable :) [Mon Mar 23 04:33:39 2015] or not :/ [Mon Mar 23 04:34:10 2015] JanBessai pasted “Error: No such section variable or assumption: test.” at http://lpaste.net/128311 [Mon Mar 23 04:34:42 2015] commenting out the match on (1, n) makes the error disappear [Mon Mar 23 04:35:32 2015] that is indeed odd [Mon Mar 23 04:40:27 2015] it also works without the second function-call test(l') [Mon Mar 23 04:41:53 2015] and if I return a constant [Mon Mar 23 04:42:31 2015] but only if I don't match on both arguments o_O [Mon Mar 23 04:42:48 2015] "| (1, n) => 1" is fine [Mon Mar 23 04:43:05 2015] "| (1, 1) => 1" fails [Mon Mar 23 04:51:03 2015] with Program Fixpoint everything works [Mon Mar 23 11:31:25 2015] gaaaaah [Mon Mar 23 11:31:37 2015] how the fuck do i rewrite ONLY THE FIRST OCCURRENCE of the lhs of an equality [Mon Mar 23 11:31:39 2015] >_< [Mon Mar 23 11:32:23 2015] I guess [rewrite foo at 1] did not work. [Mon Mar 23 11:32:39 2015] it says nothing t rewrite [Mon Mar 23 11:33:09 2015] But when you do just [rewrite foo], it does rewrite there? [Mon Mar 23 11:33:13 2015] (among other places) [Mon Mar 23 11:33:23 2015] yes [Mon Mar 23 11:33:25 2015] oh my god [Mon Mar 23 11:33:30 2015] this person to whom i am introducing coq [Mon Mar 23 11:33:32 2015] just [Mon Mar 23 11:33:34 2015] sent me this link [Mon Mar 23 11:33:36 2015] https://privatepaste.com/9dc8c10e94 [Mon Mar 23 11:38:19 2015] and so? [Mon Mar 23 13:00:46 2015] jstolarek pasted “No title” at http://lpaste.net/128360 [Mon Mar 23 13:01:02 2015] I'm trying to defint Fibonacci sequence using zipWith [Mon Mar 23 13:01:07 2015] in the spirit of Haskell's [Mon Mar 23 13:01:13 2015] let fib = zipWith (+) (1:fib) (1:fib) [Mon Mar 23 13:01:24 2015] obviously, my definition of zipWith does not work [Mon Mar 23 13:01:44 2015] I mean it is correct, but Coq's rules for co-recursion reject it [Mon Mar 23 13:02:07 2015] how can I convince Coq that this definition is safe? [Mon Mar 23 13:02:30 2015] jstolarek: well, your zipWith is not obviously a producer [Mon Mar 23 13:02:39 2015] since it recurses on a structural reduction, not on a structural production [Mon Mar 23 13:03:37 2015] I wonder if the Program environment will let you prove that it is productive [Mon Mar 23 13:04:02 2015] but since you aren't wrapping Cons around 'a' or 'b', it's hard for it to see how the inputs relate to the output [Mon Mar 23 13:04:15 2015] * is thinking [Mon Mar 23 13:05:39 2015] (or Cons around x and y; I haven't used co-recursion much yet) [Mon Mar 23 13:06:03 2015] * is still thinking [Mon Mar 23 13:07:37 2015] oh, I see, zipWith is fine [Mon Mar 23 13:07:40 2015] * lets jstolarek think [Mon Mar 23 13:09:22 2015] I can't come up with a different definition of zipWith [Mon Mar 23 13:09:47 2015] that may not be the problem; I'm trying something now [Mon Mar 23 13:10:38 2015] sure [Mon Mar 23 13:14:38 2015] ok, I've simplified to this: https://gist.github.com/4f2241d108c65e68f742 [Mon Mar 23 13:14:44 2015] here, the unguarded nature of the recursion is more obvious [Mon Mar 23 13:18:53 2015] I thought this will be a trivial exercise in co-induction... [Mon Mar 23 13:19:37 2015] and I don't see why your definition is rejected... [Mon Mar 23 13:19:51 2015] I mean call to zipWith is guarded [Mon Mar 23 13:20:16 2015] hmm [Mon Mar 23 13:21:58 2015] I can do this easily: CoFixpoint fib (a : stream) := Cons 0 (Cons 1 (zipWith plus a (tail a))). [Mon Mar 23 13:22:08 2015] but then this is rejected for the same reason: [Mon Mar 23 13:22:08 2015] t [Mon Mar 23 13:22:10 2015] CoFixpoint fibs := fib fibs. [Mon Mar 23 13:22:37 2015] because it doesn't "see" how fibs is being iterated [Mon Mar 23 13:22:47 2015] CoFixpoint [Mon Mar 23 13:22:49 2015] :D [Mon Mar 23 13:26:31 2015] so up [Mon Mar 23 13:26:33 2015] *uh [Mon Mar 23 13:26:40 2015] how much homotopy theory i gotta know to look at hott [Mon Mar 23 13:26:49 2015] not much [Mon Mar 23 13:26:53 2015] hott is a good type theory intro [Mon Mar 23 13:28:00 2015] ooh [Mon Mar 23 13:28:07 2015] jstolarek: I don't see how CoFixpoint x := ... x ... is ever going to work, because the recursion isn't lazy as it is Haskell [Mon Mar 23 13:28:08 2015] so the univalence axiom [Mon Mar 23 13:28:09 2015] let me see if i recall [Mon Mar 23 13:28:20 2015] isomorphisms are isomorphic to equalities? [Mon Mar 23 13:28:33 2015] it would be "lazy" if the recursive call were a direct argument to Cons [Mon Mar 23 13:29:24 2015] * thinks [Mon Mar 23 13:31:17 2015] for example, this works: [Mon Mar 23 13:31:20 2015] CoFixpoint fibs := Cons 0 (Cons 1 fibs). [Mon Mar 23 13:31:39 2015] because we don't need to evaluate fibs to build the Cons [Mon Mar 23 13:31:49 2015] so in homotopy theory two points that are connected by a path are identical? [Mon Mar 23 13:31:57 2015] benzrf: they are equivalent [Mon Mar 23 13:32:07 2015] and equivalence is equivalent to equality [Mon Mar 23 13:32:10 2015] equivalent in what sense hmm [Mon Mar 23 13:32:17 2015] well, keep reading :) [Mon Mar 23 13:32:24 2015] well i mean in the topological thing [Mon Mar 23 13:32:26 2015] not in hott necessarily [Mon Mar 23 13:33:13 2015] any two points on a sphere to can be made to coincidence by deforming the sphere [Mon Mar 23 13:33:51 2015] yeeah [Mon Mar 23 13:34:00 2015] so is a sphere homotopically a 1-point space [Mon Mar 23 13:34:06 2015] yep [Mon Mar 23 13:34:13 2015] oh [Mon Mar 23 13:34:17 2015] any path-connected space would be, really [Mon Mar 23 13:34:21 2015] all points in that space are homotopically equivalent [Mon Mar 23 13:34:24 2015] interesteing [Mon Mar 23 13:34:31 2015] but in a toroidal space, paths have informational content [Mon Mar 23 13:34:38 2015] hold on [Mon Mar 23 13:34:41 2015] in terms of "which way" the paths connect, out of the two possible ways [Mon Mar 23 13:36:24 2015] jstolarek: ok, now I'm confused, because in the case of using zipWith, we don't need to evaluate fibs either to build the cons... [Mon Mar 23 13:38:21 2015] perhaps the problem here is that we're not allowed to both construct *and* deconstruct? [Mon Mar 23 13:39:09 2015] because Cons 0 (Cons 1 fibs) is only construction, but Cons 0 (Cons 1 (tail fibs )) is construction around a deconstruction [Mon Mar 23 13:39:21 2015] the former is fine, the latter fails for the same reason [Mon Mar 23 13:39:38 2015] I quote CPDT: "a co-recursive call must be a direct argument to a constructor, nested only inside of other constructor calls or fun or match expressions" [Mon Mar 23 13:40:41 2015] thanks, Cypi [Mon Mar 23 13:41:10 2015] it can be nested in the body of a match, but not be the discriminee [Mon Mar 23 13:41:29 2015] if i have an inductive with 256 constant constructors, what is the best method to proove decidable equality on it ? Or should i transform those constructors into a unique constructor parametrized with int ? [Mon Mar 23 13:41:46 2015] Anarchos: the boolean predicate approach didn't work? [Mon Mar 23 13:42:14 2015] yeah, what Cypi said [Mon Mar 23 13:42:17 2015] johnw i didn't try, but anyway i am sure there is a smarter way to do it. [Mon Mar 23 13:42:19 2015] you made a predicate f : MyType -> bool [Mon Mar 23 13:43:01 2015] * has the coolest coq invite : Welcome to Coq shredder:/Data1/coq,(d'etach'e de V8.4pl5) (0ec5646cbcc725dbe1121e24258fc060223e4d51) [Mon Mar 23 13:44:40 2015] Anarchos : would [Scheme equality for and an inductive predicate: Inductive MyType_dec (x : MyType) : bool -> Set := is_eq (f x) true | is_neq (~~ (f x)) false. [Mon Mar 23 13:45:37 2015] now you can destruct MyType_dec eqn:Heqe, which becomes a computable match on true/false, but where you get the witness to the decision [Mon Mar 23 13:47:15 2015] actually, it may only be is_eq x true | is_neq x false [Mon Mar 23 13:47:20 2015] Cypi i should try. My type is just Inductive t : R0 | .... | R255. [Mon Mar 23 13:47:31 2015] Then it should generate what you need automagically, I believe [Mon Mar 23 13:48:22 2015] Inside a proof, the tactic [decide equality] would be useful too [Mon Mar 23 13:48:35 2015] anyway, Anarchos, this is the ssreflect methodology for setting up computable decidability [Mon Mar 23 13:48:40 2015] Cypi decide equality takes way to long on this type. [Mon Mar 23 13:48:45 2015] there are many examples in that library [Mon Mar 23 13:48:48 2015] Ah, ok :D [Mon Mar 23 13:49:06 2015] johnw ok. I would prefer to stuck to the compcert way, but no trouble to use it. [Mon Mar 23 13:53:19 2015] Welp, nevermind Anarchos, it takes way too long indeed. [Mon Mar 23 13:53:35 2015] Funny [Mon Mar 23 13:55:32 2015] Cypi did you tried ? [Mon Mar 23 13:55:40 2015] I just did [Mon Mar 23 13:55:48 2015] Didn't have the patience to wait for Coq to finish computing :p [Mon Mar 23 13:56:38 2015] johnw the f predicate should take two MyType parameters , no ? [Mon Mar 23 13:56:51 2015] Cypi i did at work but it is not bearable. [Mon Mar 23 13:57:10 2015] Cypi strange because there are only 65 536 cases ! [Mon Mar 23 13:58:00 2015] Anarchos: full example: https://gist.github.com/f905ff7ced18e6e84487 [Mon Mar 23 13:58:46 2015] matchP "pairs up" the witness with the result, while allowing case matching on the result [Mon Mar 23 13:59:08 2015] so at the bottom, the "case" (aka destruct) does a computed branch while provide you with the decidability witness [Mon Mar 23 14:00:07 2015] the advantage of this approach is that BigType can be arbitrarily large and yet the proof terms should be of constant size [Mon Mar 23 14:00:36 2015] since the proof terms only needs to convey a bit and a value, rather than a proof tree branching at every constructor [Mon Mar 23 14:12:02 2015] johnw let met read it. [Mon Mar 23 14:13:28 2015] johnw did'nt work on my coq 8.4pl5 [Mon Mar 23 14:13:41 2015] you probably don't have ssreflect installed? [Mon Mar 23 14:14:08 2015] seems so : Cannot find library Ssreflect.ssreflect in loadpath and so on for all the lib [Mon Mar 23 14:14:28 2015] yes, you'll need that library [Mon Mar 23 14:14:35 2015] i mean, not technically [Mon Mar 23 14:14:38 2015] let me try to remove the depnedency [Mon Mar 23 14:16:20 2015] Anarchos: there, I've updated the gist [Mon Mar 23 14:16:24 2015] now it's plain Coq stdlib [Mon Mar 23 14:16:31 2015] johnw wow thanks [Mon Mar 23 14:17:58 2015] johnw what means the eqn:E ? [Mon Mar 23 14:18:12 2015] it renames the equation producted ? [Mon Mar 23 14:18:13 2015] it preserves the witness in the context [Mon Mar 23 14:18:22 2015] ok [Mon Mar 23 14:18:58 2015] without eqn, it would be equivalent to an "if" [Mon Mar 23 14:19:06 2015] with eqn, it's like an "if" with a "and here's why" [Mon Mar 23 14:19:17 2015] yes ok ok [Mon Mar 23 14:20:00 2015] note that in a propositional context, you only need destruct (f x) eqn:E [Mon Mar 23 14:20:08 2015] since you don't care about the specifics of the witness [Mon Mar 23 14:20:18 2015] the reason for matchP is that you can recover the information [Mon Mar 23 14:20:36 2015] since true_xor_false has constructor to box the witness [Mon Mar 23 14:21:07 2015] this is why the methodology is named "small scale reflection" [Mon Mar 23 14:21:27 2015] because we are smoothly switching back and forth between inductive predicates in Prop, and computational predicates in Set [Mon Mar 23 14:21:35 2015] without requiring anything beyond ordinary Coq features [Mon Mar 23 14:22:43 2015] johnw way beyond my skill yet... [Mon Mar 23 14:23:09 2015] it takes a while to get used to [Mon Mar 23 14:23:16 2015] but it does address the very problem you ran into :) [Mon Mar 23 14:23:39 2015] johnw it means i have to write 256 predicates like is_B ?? [Mon Mar 23 14:23:47 2015] small scale reflection allows you to transfer the problem to a computable domain where proof terms can be small, and then reflect the answer back when and where you need it [Mon Mar 23 14:24:02 2015] Anarchos: oh no, if you wanted to see what a consturctor was, you'd just destruct x [Mon Mar 23 14:24:14 2015] is_B was just a stupid example of a predicate [Mon Mar 23 14:24:40 2015] ok [Mon Mar 23 14:24:54 2015] if you're logic does have you constantly needing to branch on every constructor [Mon Mar 23 14:25:02 2015] well, then you're in CPDT domain and your proof terms will simply be large [Mon Mar 23 14:25:51 2015] in which case the best way to achieve sanity is through proof automation [Mon Mar 23 14:25:52 2015] johnw i am not in CPDT, but in compcert ;) I am (trying) to port it to a machine with 256 registers. [Mon Mar 23 14:26:08 2015] I'd have to know more about compcert to give you a reasonable answer, then [Mon Mar 23 14:27:01 2015] i modify the file powerpc/Machregs.v [Mon Mar 23 14:51:21 2015] jstolarek pasted “crash coq” at http://lpaste.net/128366 [Mon Mar 23 14:52:50 2015] johnw: found a solution in "Using Structural Recursion for Corecursion" and as a side-effect I managed to crash Coq :-) [Mon Mar 23 14:53:04 2015] crash = cause a segfault [Mon Mar 23 14:53:04 2015] :( [Mon Mar 23 14:53:13 2015] please report on the bug tracker! [Mon Mar 23 14:53:15 2015] they are pretty responsive [Mon Mar 23 14:53:34 2015] if you want, I can report it fory ou [Mon Mar 23 14:53:46 2015] that would be nice - I don't have an account [Mon Mar 23 14:54:23 2015] I only get a stack overflow [Mon Mar 23 14:54:25 2015] reported by Coq [Mon Mar 23 14:54:58 2015] hm... [Mon Mar 23 14:55:11 2015] I'm running this through proof general [Mon Mar 23 14:55:16 2015] me too [Mon Mar 23 14:55:24 2015] if I change "Eval in compute" to just "Compute", it hangs [Mon Mar 23 14:55:33 2015] let me check my versions [Mon Mar 23 14:56:13 2015] ok, my Coq is 8.4pl5 (Feb 2015) [Mon Mar 23 14:56:17 2015] same here [Mon Mar 23 14:57:19 2015] I'm not sure how to check my PG version [Mon Mar 23 14:58:13 2015] but still I'c curious why this does not work [Mon Mar 23 14:58:14 2015] interesting, try this: [Mon Mar 23 14:58:18 2015] Eval hnf in (approx (fib' 1 1) 40). [Mon Mar 23 14:58:20 2015] I mean this should be linear [Mon Mar 23 14:58:24 2015] gives 1 :: approx (fib' 1 1) 39. [Mon Mar 23 14:58:29 2015] but Eval hnf in (1 :: approx (fib' 1 1) 39). [Mon Mar 23 14:58:35 2015] just gives that back [Mon Mar 23 14:58:40 2015] oh, never mind [Mon Mar 23 14:58:43 2015] just being stupid for a moment [Mon Mar 23 14:58:46 2015] gotta run [Mon Mar 23 14:58:56 2015] sure [Mon Mar 23 15:00:04 2015] johnw: for the record: this crash happened on two independent machines [Mon Mar 23 15:29:01 2015] jstolarek: ah, 40 is just too large [Mon Mar 23 15:29:19 2015] because it's a quadratic(?) expansion in the size of the n+m term [Mon Mar 23 15:29:23 2015] 10 works [Mon Mar 23 15:29:31 2015] 1 :: 1 :: 2 :: 3 :: 5 :: 8 :: 13 :: 21 :: 34 :: 55 :: nil [Mon Mar 23 15:29:54 2015] if we had bang patterns here, it would resolve this [Mon Mar 23 16:10:13 2015] johnw: I don't see why this is quadratic.... [Mon Mar 23 16:10:28 2015] looks very linear [Mon Mar 23 16:10:51 2015] I mean fib' calls itself only once [Mon Mar 23 16:15:23 2015] * has returned [Mon Mar 23 16:19:08 2015] jstolarek: https://gist.github.com/a2637035d3d2503c50d5 [Mon Mar 23 16:20:31 2015] urgh [Mon Mar 23 16:20:35 2015] + is lazy [Mon Mar 23 16:20:42 2015] I should have seen this [Mon Mar 23 23:18:23 2015] so in hott [Mon Mar 23 23:18:30 2015] if i have a bijection between A and B [Mon Mar 23 23:18:32 2015] i can get A = B? [Mon Mar 23 23:19:37 2015] benzrf: yeah, that's what the univalence axiom states, I think [Mon Mar 23 23:19:41 2015] neato [Mon Mar 23 23:20:04 2015] or it states there's a bijection between (bijections between A and B) and A = B [Mon Mar 23 23:20:15 2015] yeah [Tue Mar 24 00:22:28 2015] benzrf: A ≈ B is equivalent to A = B [Tue Mar 24 00:22:42 2015] which has some profound implications [Tue Mar 24 00:22:55 2015] including..? [Tue Mar 24 00:23:01 2015] well, think about referential transparency [Tue Mar 24 00:23:09 2015] if substitutes equals for equals does not change the meaning of an expression [Tue Mar 24 00:23:17 2015] then a compiler is free to choose the best substitution [Tue Mar 24 00:23:30 2015] if we now say that equivalence is equivalent to equality, it opens up a whole world of possibilities [Tue Mar 24 00:23:36 2015] isomorphisms now represent rewriting rules! [Tue Mar 24 00:24:20 2015] imagine a world where, without changing a line of code, you can substitute Map for IntMap where the key is an integer... [Tue Mar 24 00:24:50 2015] or where the compiler can determine that such a substitute would profit whatever optimize strategy you've chosen [Tue Mar 24 00:25:04 2015] substitution* optimization* [Tue Mar 24 00:25:47 2015] we have papers like "Reason Isomorphically!" that extol the power of using isomorphisms to reason about types [Tue Mar 24 00:26:02 2015] HoTT brings this down to a fundamental level, where it becomes our way of thinking about the meaning of identity [Tue Mar 24 00:26:14 2015] it's like our most basic types turn into type classes overnight [Tue Mar 24 00:26:35 2015] because they can have as many representations as we can prove that paths exist to other points in the space [Tue Mar 24 00:30:04 2015] hmm [Tue Mar 24 00:32:31 2015] I wrote something on paper a while ago thinking about this... if you had Nat (unary nats) and Bin (binary nats), then wrote a predicate Even : Nat -> Prop, a function double : Nat -> Nat and a proof forall n : Nat, Even (double n), then you could automatically get Even : Bin -> Prop, double : Bin -> Bin, and the proof forall b : Bin, Even (double b) just by [Tue Mar 24 00:32:31 2015] proving the isomorphism between Nat and Bin [Tue Mar 24 00:32:47 2015] I don't know if this is the right way to think about it, but it seems cool [Tue Mar 24 00:33:01 2015] yes, Reason Isomorphically! talks about this too, it's a very nice paper [Tue Mar 24 00:33:11 2015] why prove things multiple times, when the *concept* has been proven [Tue Mar 24 00:33:13 2015] you would get something like doubleBin b = natToBin (doubleBin (binToNat b)) [Tue Mar 24 00:33:15 2015] I imagine [Tue Mar 24 00:33:25 2015] now HoTT stands a chance of formalizing this notion [Tue Mar 24 00:33:34 2015] s/doubleBin/doubleNat/ on the RHS [Tue Mar 24 00:35:24 2015] I guess the compiler can pick the best places to insert the conversion, perhaps [Tue Mar 24 00:35:40 2015] probably only insofar as it can automate parallelization [Tue Mar 24 00:36:00 2015] paths are proof relevant, so the best choice requires understanding [Tue Mar 24 00:36:03 2015] the proof part could just be forall b : Bin, Even (double (binToNat b)) delegating to the Nat proof, without using the Bin versions of anything [Tue Mar 24 00:36:17 2015] I haven't thought about this much [Tue Mar 24 05:07:33 2015] scott: now you have a double on binary numbers that has the same complexity as the one on unary ones :) [Tue Mar 24 05:08:43 2015] yeah, it doesn't really help you there. maybe it could go deeper and use the implementation of the isomorphism to rewrite the definition of double in a more complicated way somehow? [Tue Mar 24 05:12:08 2015] for another example if you had the isomorphism between Bool and Maybe () you could rewrite the pattern matches instead of inserting conversions (sorry for the Haskell types, I've been away from Coq for a while) [Tue Mar 24 05:12:40 2015] *an* isomorphism, I should say, since there's two [Tue Mar 24 05:15:00 2015] yeah, but you wouldn't change anything substantial about the algorithm that way [Tue Mar 24 10:07:09 2015] the thing about hott [Tue Mar 24 10:07:10 2015] the thing about hott is [Tue Mar 24 10:07:30 2015] you can already prove things by isomorphism in standard type theory [Tue Mar 24 10:07:42 2015] and in hott you still have to specifically perform the rewriting, dont you? [Tue Mar 24 10:07:51 2015] or, is it just a matter of there being a lot less? [Tue Mar 24 10:14:00 2015] benzrf: the big advantage i see of univalence is that we can just use the equality type in most places, rather than work with setoids [Tue Mar 24 10:15:02 2015] benzrf: what you get is that every construction is automatically invariant under isomorphism, no need to prove this or require it as an extra hypothesis for your arguments, etc.. [Tue Mar 24 10:15:37 2015] hmm [Tue Mar 24 10:16:02 2015] but yeah, it doesn't make the isomorphisms disappear from the computational behaviour [Tue Mar 24 11:29:34 2015] ah, yes, that's the piece someone taught me the other day that I quickly forgot [Tue Mar 24 11:31:35 2015] the important bit is that something like (A = B -> P A -> P B) which exists today could be used with isomorphisms, too, so e.g. a proof about List Nat would immediately apply for List Bin given an isomorphism between Bin and Nat [Tue Mar 24 11:32:00 2015] whereas without univalence it has to be proven for each type individually [Tue Mar 24 11:32:25 2015] yeah, for each P [Tue Mar 24 11:55:31 2015] hmm ah hmm [Tue Mar 24 13:39:49 2015] how to specify an inductive type like Inductive T := R n where n <256 ? Should i add a parameter for the proof «n<256» in T or in R ? [Tue Mar 24 13:43:00 2015] Anarchos: most likely in R? otherwise you would also need to make n an argument of T [Tue Mar 24 13:43:57 2015] Either [Inductive T := R : forall n, n < 256 -> T.], [Inductive T := R : {n | n < 256} -> T.], or even [Inductive T := R : fin 256 -> T.] [Tue Mar 24 13:44:02 2015] Saizan R is modeling a register of a sparc-like machine. Isn't it annoying to carry over the proof that there is no more than 256 registers ? [Tue Mar 24 13:44:04 2015] I wouldn't know which is better though, sorry [Tue Mar 24 13:44:45 2015] Cypi in which lib is fin ? [Tue Mar 24 13:45:46 2015] https://coq.inria.fr/library/Coq.Vectors.Fin.html apparently. I wasn't sure it was standard [Tue Mar 24 13:47:05 2015] I tried Inductive T := R : {n | n < 256} -> T. How to build a value ? R(1,1<256) doesn't work. I can't remember how to construct value in {n|P(n)} [Tue Mar 24 13:54:21 2015] Again...I'm not sure if it's a good or a bad idea, but something that works is using Program: http://lpaste.net/129122 [Tue Mar 24 13:54:48 2015] (so that you don't have to provide the proof yourself) [Tue Mar 24 13:55:29 2015] Otherwise, a value is of the shape [R (exist _ n p)] where [p : n < 256] [Tue Mar 24 13:55:31 2015] Anarchos: that type is called 'I_256 in ssreflect, and Fin 256 in stdlib [Tue Mar 24 13:56:00 2015] hi, is there a way to write ' Definition vec : t bool 1 := cons bool true 0 (nil bool). [Tue Mar 24 13:56:12 2015] Silnar: sure [Tue Mar 24 13:56:17 2015] shorter [Tue Mar 24 13:56:21 2015] https://gist.github.com/82e11c07626143ff4197 [Tue Mar 24 13:56:24 2015] oh, shorter.... [Tue Mar 24 13:56:33 2015] like cons 0 nil [Tue Mar 24 13:56:39 2015] sorry, like cons true nil [Tue Mar 24 13:56:39 2015] Cypi my goal is to have a decidable equality lemma, which doesn't take ages to compile. [Tue Mar 24 13:56:49 2015] can't coq infer type and n value ? [Tue Mar 24 13:57:00 2015] dunno, I copied that from elsewhere [Tue Mar 24 13:57:02 2015] Silnar Set Implicit Arguments ? [Tue Mar 24 13:57:34 2015] Anarchos: tried, but with no luck [Tue Mar 24 14:00:06 2015] when I write 'Definition vec2 : t bool 1 := cons true nil.' Coq complains that true has type bool and should have type Type. Implicit Arguments are enabled. [Tue Mar 24 14:05:04 2015] Silnar: can you paste 'Print t.' somewhere? [Tue Mar 24 14:05:17 2015] it should tell you which arguments are implicit for each constructor [Tue Mar 24 14:07:15 2015] Anarchos: decidability for Fin should be pretty efficient [Tue Mar 24 14:07:31 2015] Fin is just a dependently typed nat [Tue Mar 24 14:07:49 2015] Ptival: sure, give a moment... [Tue Mar 24 14:08:35 2015] Hmm, for the decidability, I believe you actually need proof irrelevance, don't you? [Tue Mar 24 14:09:17 2015] I think decidability for n | n < 256 will be harder, because you could have two numbers of equal n, but unequal n < 256, which then requires you axiomatize proof irrelevance [Tue Mar 24 14:09:21 2015] http://lpaste.net/129123 [Tue Mar 24 14:09:51 2015] In any case, the extracted code is very simple at least ^^' [Tue Mar 24 14:10:13 2015] Cypi: if your type includes anything from Prop, yes [Tue Mar 24 14:11:13 2015] although, no [Tue Mar 24 14:11:14 2015] Silnar pasted “Declaring a vector in a short way” at http://lpaste.net/129124 [Tue Mar 24 14:11:27 2015] there is some flavor of le_dec in the stdlib [Tue Mar 24 14:11:46 2015] Ptival: here you have, the whole code [Tue Mar 24 14:12:09 2015] so I think you could do that one without proof irrelevance [Tue Mar 24 14:12:32 2015] Ah right, probably [Tue Mar 24 14:19:15 2015] Cypi your code compiled in 2s, compared to 30min for a naive inductive type with 256 constant constructors :) [Tue Mar 24 14:26:30 2015] (btw, no need for an induction, that was dumb of me ^^' ) [Tue Mar 24 14:28:11 2015] Silnar: oh, when you set implicit arguments, you set it for the types that will be defined later [Tue Mar 24 14:28:25 2015] it does not retroactively make implicit the arguments of already existing types [Tue Mar 24 14:28:31 2015] like the ones in library code [Tue Mar 24 14:29:38 2015] Silnar: however if you look here https://coq.inria.fr/library/Coq.Vectors.VectorDef.html you will see they define a notation for cons with implicits [Tue Mar 24 14:31:35 2015] Silnar: http://lpaste.net/129124 so this works (note I import VectorNotations) [Tue Mar 24 14:32:27 2015] Cypi May i copy your http://lpaste.net/129123 into my code ? [Tue Mar 24 14:32:55 2015] Of course :o (I would just suggest replacing the induction with a simple destruct, that's enough) [Tue Mar 24 14:36:00 2015] johnw: The < type and <= type have provable proof irrelevance. [Tue Mar 24 14:36:58 2015] jgross: because of the constructors of "le", right? [Tue Mar 24 14:41:27 2015] Because le is decidable and, uh, there are no duplicate constructors, roughly. [Tue Mar 24 14:46:55 2015] ah, got it [Tue Mar 24 14:47:10 2015] Cypi what is the difference between induction, destruct, and inversion ? [Tue Mar 24 14:50:57 2015] Anarchos: have you done any manual construction of proof terms yet? [Tue Mar 24 14:51:24 2015] if you were writing the proof term yourself [Tue Mar 24 14:51:31 2015] induction would be a recursive call [Tue Mar 24 14:51:34 2015] destruct is a case match [Tue Mar 24 14:52:18 2015] inversion is a bit smarter, it case matches and provides you with the arguments to each constructor in the context, automatically removing impossible branches [Tue Mar 24 14:52:22 2015] Ptival: wow, thanks, didn't know that 'Set Implicit Arguments' work only for my types [Tue Mar 24 14:52:45 2015] so there are cases where all three will yield a similar result, and cases where all three will behave differently [Tue Mar 24 14:53:25 2015] Ptival: this blanks (_) in Notation denote implicits, right ? [Tue Mar 24 14:53:26 2015] johnw i did some years ago when doing the SF from B.C. Pierce. [Tue Mar 24 14:53:44 2015] though inversion is a bit smarter still, in that inverting (a, b) = (c, d) will give you not just the arguments to =, but also a = c and b = d [Tue Mar 24 14:54:11 2015] I read inversion as "tell me what must have been true for this inhabitant to exist" [Tue Mar 24 14:55:18 2015] johnw thanks for the wise explanation of those three tactics ! I actually will retain their different behaviours one day. [Tue Mar 24 14:55:43 2015] my rule of thumb is: use destruct first [Tue Mar 24 14:56:02 2015] if you need to recurse (i.e., you need an induction hypothesis to refer to a prior state), upgrade to induction [Tue Mar 24 14:56:07 2015] if those don't work, try inversion :) [Tue Mar 24 14:56:27 2015] johnw yes case match are a very frequent construction in functional languages. [Tue Mar 24 14:56:33 2015] also, sometimes "eqn" on destruct will provide you with the information you might have just used inversion to get at [Tue Mar 24 14:56:54 2015] in fact, "let" and "match" are pretty much *the* constructions :) [Tue Mar 24 14:57:06 2015] you build data, you reduce data [Tue Mar 24 14:57:22 2015] (I'm assuming here that all functions and applications have simply been unfolded) [Tue Mar 24 15:10:46 2015] johnw but in the middle of a proof, it is difficult to see what tactics to apply ! [Tue Mar 24 15:11:12 2015] you really get a feel for it [Tue Mar 24 15:11:27 2015] my need for inversion is pretty darn rare [Tue Mar 24 15:12:05 2015] destruct and rewrite are 90% of the workload [Tue Mar 24 15:12:19 2015] but then again, I'm using ssreflect, which is optimized so that this is the case [Tue Mar 24 15:12:25 2015] (since destruct and rewrite are both very efficient) [Tue Mar 24 15:23:36 2015] Is there a good simple way of representing a small statically-sized array? [Tue Mar 24 15:23:53 2015] so, do you need it sized for any reason? [Tue Mar 24 15:23:54 2015] each index being tupe type option my_set_type [Tue Mar 24 15:24:05 2015] because they are lots of things that are isomorphic to a statically-sized array, like Vector [Tue Mar 24 15:24:23 2015] johnw: I have exactly 16 indices available in the VM spec (BPF) [Tue Mar 24 15:24:26 2015] or a function that takes a bounds check as a witness [Tue Mar 24 15:24:33 2015] they all start undefined/uninitialized [Tue Mar 24 15:24:42 2015] johnw: I could also do that [Tue Mar 24 15:25:00 2015] Definition Sized (a : Type) (n : nat) := forall x, x < n -> a. [Tue Mar 24 15:25:01 2015] I'm very new to Coq and working on something a non-toy problem, so I'm in a little over my head :P [Tue Mar 24 15:25:04 2015] ah [Tue Mar 24 15:25:09 2015] well, there are lots of ways to do things [Tue Mar 24 15:25:20 2015] and how you do them depends on whether you want code out the other end, or you just want to prove a property [Tue Mar 24 15:25:32 2015] thanks for that. Where is the state stored in that example? [Tue Mar 24 15:25:42 2015] the state is in the closure [Tue Mar 24 15:25:48 2015] That's the other thing: I'm extracting this into OCaml and running it [Tue Mar 24 15:25:58 2015] ah, then that representation will not be so good [Tue Mar 24 15:26:07 2015] better to use Vector from the standard library [Tue Mar 24 15:26:10 2015] which is still just a list, though [Tue Mar 24 15:26:24 2015] but I think you should be able to tell the extractor to turn it into a fixed-length Array on the OCaml side [Tue Mar 24 15:28:03 2015] also, an argument of type forall x, x < n is isomorphic to Fin n from the stdlib (though not equal to it) [Tue Mar 24 15:29:49 2015] thanks [Tue Mar 24 15:29:54 2015] I'm looking into Vectornow [Tue Mar 24 15:30:06 2015] Cypi do you think it is a good idea to import proofirrelevance in compcert this way ? [Tue Mar 24 15:33:12 2015] Honestly, I don't have enough experience to answer questions starting with "do you think it is a good idea" ^^ [Tue Mar 24 15:33:20 2015] it's safe to do, but not a good idea [Tue Mar 24 15:33:38 2015] But I would say: the less axioms you need the better, and since you can prove proof irrelevance on le, you don't need to axiomatize it [Tue Mar 24 15:33:48 2015] what Cypi said [Tue Mar 24 15:46:09 2015] Here's a dumb question, but how do I construct a Vector literal? I have a type defined but I'm trying to play with it to get a better feel for how it works? [Tue Mar 24 15:46:14 2015] so i should try to do the proof without the Require Import proofirrelevance.... [Tue Mar 24 15:48:37 2015] yes, and you should be able to also [Tue Mar 24 15:48:48 2015] if you have difficulties, paste your code here [Tue Mar 24 15:49:15 2015] johnw [Tue Mar 24 15:49:18 2015] thanks [Tue Mar 24 16:07:02 2015] Never mind, I just noticed the to_list and from_list functions [Tue Mar 24 16:09:21 2015] Anarchos pasted “decidable stuck” at http://lpaste.net/129129 [Tue Mar 24 16:11:07 2015] Anarchos: what ist the type of your lemma? [Tue Mar 24 16:12:31 2015] no idea, i would say prop. [Tue Mar 24 16:12:48 2015] The problem is that Anarchos needs both the eta rule for sig, and equality of the < proofs, which is cause for alarm. [Tue Mar 24 16:13:41 2015] Somehow you've stated your property in a proof-relevant way. Likely you didn't mean for that. [Tue Mar 24 16:14:32 2015] Theorem T_eq_dec : forall (t1 t2 : T), {t1 = t2} + {t1 <> t2}. [Tue Mar 24 16:14:51 2015] and T is? [Tue Mar 24 16:18:51 2015] Anarchos: please provide enough information for me to try this here [Tue Mar 24 16:18:55 2015] Inductive T := R : {n | n < 256} -> T. [Tue Mar 24 16:20:55 2015] I would think that nat_le m n is contractible... [Tue Mar 24 16:22:04 2015] le, not nat_le [Tue Mar 24 16:23:58 2015] It needs an encode/decode proof. Blech. I never was good at that. [Tue Mar 24 16:24:33 2015] (le m n) is an hprop, I should say. [Tue Mar 24 16:32:12 2015] no. I must finish writing my defense talk. I will not be distracted! Gah. [Tue Mar 24 16:36:23 2015] Anarchos: https://gist.github.com/197d3f56ecc4e97649ea [Tue Mar 24 16:37:02 2015] that is not how I'd normally write it, but I wanted to do it using the stdlib for you [Tue Mar 24 16:37:30 2015] also so you can step through it easily [Tue Mar 24 16:38:07 2015] johnw: oh, Peano.le_unique. Nice. [Tue Mar 24 16:38:18 2015] thank Search for that :) [Tue Mar 24 16:38:39 2015] I started to prove that as another Lemma, and thought, "No, it has to be there..." [Tue Mar 24 16:39:24 2015] the Arith.Compare import is not needed either [Tue Mar 24 16:39:48 2015] johnw thanks [Tue Mar 24 16:40:05 2015] updated the gist for you [Tue Mar 24 16:40:22 2015] i don't know if abstract is needed with assert [Tue Mar 24 16:40:27 2015] it's just an omega habit I have [Tue Mar 24 16:41:09 2015] johnw i realize, reading that kind of proof for what seemed to be a really simple lemma, that i am really not skilled at all in coq. [Tue Mar 24 16:41:28 2015] oh, I should be using Peano_dec.eq_nat_dec [Tue Mar 24 16:41:45 2015] gist updated again, half the size now :) [Tue Mar 24 16:42:42 2015] I never know when to use revert or generalize dependent, ya. [Tue Mar 24 16:42:54 2015] i was unable to rewrite the terms with them in the context [Tue Mar 24 16:43:01 2015] dependency problems [Tue Mar 24 16:43:24 2015] but if everything using the term is generalized, then my context is free [Tue Mar 24 16:44:44 2015] as for generalizing the dependent, I didn't want to prove an induction on x for some particular x0; I needed to prove forall x as well as forall x0 [Tue Mar 24 16:45:21 2015] if x0 is in the context, induction thinks that the single inhabitant I want for the induction proof [Tue Mar 24 16:46:10 2015] that that is the* [Tue Mar 24 16:46:35 2015] these types of things (revert, generalize dependent, etc) actually become incredibly clear when you use ssreflect, actually, since they are so much more natural there [Tue Mar 24 16:46:54 2015] I only understand them in stdlib because of that [Tue Mar 24 16:47:20 2015] for example, in ssreflect you'd say: elim: x => [|x IHx] in x0 *. [Tue Mar 24 16:47:26 2015] to mean that your proof ranges forall x0 [Tue Mar 24 16:55:03 2015] i am back :) [Tue Mar 24 17:27:08 2015] ianjneu: you probably know this already, but here's what generalize dependent "does": https://gist.github.com/c4e4a02bb1f00ad5daed [Tue Mar 24 17:27:24 2015] (even though the proof doesn't need it, but it shows the point) [Tue Mar 24 17:28:57 2015] ev_sum says, "Give me any m, and I'll prove my proposition for all n." ev_sum' says, "I'll prove that my proposition holds for all m and n" [Tue Mar 24 17:29:25 2015] johnw hey you modified my file :/ [Tue Mar 24 17:29:33 2015] I did? [Tue Mar 24 17:30:47 2015] johnw my inductive type and theorem disappeared :) [Tue Mar 24 17:31:21 2015] https://gist.github.com/jwiegley/197d3f56ecc4e97649ea? [Tue Mar 24 17:38:31 2015] johnw ah yes thanks :) [Tue Mar 24 17:38:48 2015] * is sad, thinking that A. Chlipala could come with a 3-line proof.... [Tue Mar 24 17:41:32 2015] Anarchos: you could also just use: [Tue Mar 24 17:41:37 2015] Definition T := {n | n < 256}. [Tue Mar 24 17:41:43 2015] there is no need for the R constructor wrapper [Tue Mar 24 17:42:03 2015] johnw i need it in my code as a reminder for Register. [Tue Mar 24 17:42:09 2015] ah [Tue Mar 24 17:42:15 2015] you mean, to use it? [Tue Mar 24 17:42:41 2015] Definition R (n : nat) (H : n < 256) := exist _ n H. [Tue Mar 24 17:43:00 2015] and then maybe for your sanity, define R0 through R255 [Tue Mar 24 17:47:02 2015] johnw no cause the "decide equality" tactics takes around 25min for an inductive type with 256 constructors. [Tue Mar 24 17:47:18 2015] no, I mean: [Tue Mar 24 17:47:26 2015] Program Definition R0 := R 0 _. [Tue Mar 24 17:47:27 2015] etc. [Tue Mar 24 17:47:48 2015] johnw with this definition, is the decidable equality proof simpler ? [Tue Mar 24 17:48:00 2015] it just removes two destructs is all [Tue Mar 24 17:48:07 2015] but no simpler than that [Tue Mar 24 17:48:30 2015] johnw Error: Cannot infer this placeholder. [Tue Mar 24 17:48:38 2015] (in the Definition) [Tue Mar 24 17:56:13 2015] Anarchos: well, you'll need a canonical structure to actually infer that. [Tue Mar 24 17:56:44 2015] See https://hal.inria.fr/hal-00816703v1/document page 8. The EQ case is easily modifiable to the LT case [Tue Mar 24 17:57:28 2015] ianjneu which page ? [Tue Mar 24 17:57:33 2015] oh sorry you wrote 8. [Tue Mar 24 17:59:04 2015] too much difficulties for tonight. Maybe i should begin again with coq with simpler types and proofs.... [Tue Mar 24 18:08:21 2015] hacking on compcert is probably not the first project I'd recommend to someone :) [Tue Mar 24 18:08:39 2015] Anarchos: when you get the "Cannot infer" error, try Program. [Tue Mar 24 18:09:54 2015] johnw i was just mimicking the MachRegs.v file with 256 registers instead of 10 ... [Tue Mar 24 18:10:54 2015] for my register allocator, instead of fixing the size bound with each register, I use Fin n and a global parameter that n < machineregistercount [Tue Mar 24 18:11:20 2015] Variable maxReg : nat. (* max number of registers *) [Tue Mar 24 18:11:20 2015] Definition PhysReg : predArgType := 'I_maxReg. [Tue Mar 24 18:11:33 2015] where 'I_maxReg is equivalent to your T [Tue Mar 24 18:11:52 2015] ianjneu: thanks for that link [Tue Mar 24 18:53:49 2015] https://github.com/clarus/falso [Tue Mar 24 18:54:00 2015] :O [Tue Mar 24 18:56:55 2015] Apparently a new proof of False [Tue Mar 24 18:57:15 2015] Does anyone have the 8.5 beta to see if it works there too? [Tue Mar 24 18:58:16 2015] Cale i would thought that edge cases are more toroughly tested... [Tue Mar 24 18:58:42 2015] not speaking of (1+max_int) < 0 in ocaml , without warning... [Tue Mar 24 19:00:25 2015] Wasn't the last proof of False due to a bug in vm_compute as well? [Tue Mar 24 19:03:20 2015] shouldn't the kernel checker catch this? [Tue Mar 24 19:05:04 2015] Unable to communicate with coqtop, restarting coqtop. [Tue Mar 24 19:05:04 2015] Error was: Broken pipe [Tue Mar 24 19:05:23 2015] Trying to Eval vm_compute in hard bool. where hard : forall (A : Type), A. [Tue Mar 24 19:05:28 2015] :D [Tue Mar 24 19:05:46 2015] Cale funny i used a type with 256 constructors this week [Tue Mar 24 19:07:07 2015] Eval compute in hard bool. doesn't crash though [Tue Mar 24 19:07:12 2015] = match (fun (X : Type) (t : X) => t) return (forall A : Type, A) with [Tue Mar 24 19:07:12 2015] end bool [Tue Mar 24 19:07:12 2015] : bool [Tue Mar 24 19:12:30 2015] How would you make a better vm_compute that doesn't let you prove false? [Tue Mar 24 20:42:56 2015] vanila: Maybe write one in Coq? [Tue Mar 24 20:52:17 2015] I don't know if it's because of performance issues or something [Tue Mar 24 20:52:37 2015] but it would nice if Coq were hosted in Coq, but they committed the OCaml extracted files so you could bootstrap on new platforms [Tue Mar 24 20:53:15 2015] I'm not sure that woudl work well for the typechecker itsef [Tue Mar 24 20:55:20 2015] but just for a fast evaluator (like vm_compute) it should be really good [Wed Mar 25 02:58:06 2015] I think I got it right this time: https://gist.github.com/nkaretnikov/86b84f74ff2cdc216bba [Wed Mar 25 03:36:11 2015] nkar``: I think I see a mistake... [Wed Mar 25 03:36:19 2015] subseq [3] [2,2,3] [Wed Mar 25 03:36:19 2015] -------------------- (s_same) [Wed Mar 25 03:36:19 2015] subseq [2,3] [2,2,3] [Wed Mar 25 03:36:31 2015] thanks [Wed Mar 25 03:36:52 2015] should be: subseq [3] [2,3] [Wed Mar 25 03:37:09 2015] yeah, you have an extra s_diff step inserted there [Wed Mar 25 03:37:36 2015] Cale: is there a preferred notation for expressing non-valid cases, like I did with a '!'? [Wed Mar 25 03:40:41 2015] I dunno, you might want not to put a line above the subseq [2,3] [] etc. as that looks like you're saying it's derivable from the empty context [Wed Mar 25 03:40:55 2015] (even though there's (no rule) off to the side) [Wed Mar 25 03:41:14 2015] okay, I'll do that [Wed Mar 25 03:41:54 2015] nkar``: Who is this for? Just for yourself? [Wed Mar 25 03:42:10 2015] Or are you taking a course? [Wed Mar 25 03:42:12 2015] Cale: yes, it's from software foundations, which I'm reading [Wed Mar 25 03:42:20 2015] yes to the first question [Wed Mar 25 03:45:24 2015] btw, did you try proving all these things in Coq? [Wed Mar 25 03:46:04 2015] I do the provided exercises [Wed Mar 25 03:46:24 2015] but I haven't proved anything with this def'n of subseq yet [Wed Mar 25 03:46:37 2015] why are you asking? [Wed Mar 25 03:47:07 2015] Cale: are you trying to hint that a machine checked proof is better than an informal one? if so, I'm well aware :) [Wed Mar 25 03:48:24 2015] Well, you could do the very same thing using a sequence of apply steps, and see how the context changes. [Wed Mar 25 03:49:33 2015] Cale: ah, that's a good idea! [Wed Mar 25 03:51:34 2015] Cale: but how do I express the impossible cases? do I need to [Abort.] a proof in such cases? [Wed Mar 25 03:51:57 2015] Well, you could try to prove not (subseq [1,2,3] [1,2]) [Wed Mar 25 03:52:07 2015] nice! [Wed Mar 25 03:58:08 2015] how do I properly express this: [Lemma app_cons_snoc : forall (X : Type) (xs : list X) (x : X), xs -> x :: xs ++ [x].] I know that [xs] needs to be a [Prop] to be used like this, but I'm not sure how to restate it. [Wed Mar 25 03:58:09 2015] (for that, you'll probably want to use inversion a bunch) [Wed Mar 25 03:58:50 2015] What are you trying to prove? [Wed Mar 25 03:58:57 2015] Are you just trying to define the function which does that? [Wed Mar 25 03:59:26 2015] Cale: I decided to make a few examples for my [pal] definition, which has this rule: [p_rec : forall (x : X) (xs : list X), pal xs -> pal (x :: xs ++ [x]).] since I don't want to use [replace] every time, I want a lemma. [Wed Mar 25 03:59:35 2015] so, do I need a function instead? [Wed Mar 25 03:59:36 2015] why are you making "xs" an argument and an argument type? [Wed Mar 25 04:00:21 2015] johnw: hi! well, it look like a natural translation of the [pal] rule. do I need just [x :: xs ++ [x]]? [Wed Mar 25 04:00:24 2015] I'm not sure I understand what you want the lemma to be [Wed Mar 25 04:00:33 2015] looked* [Wed Mar 25 04:00:55 2015] Can you give more detail about what you're trying to do? [Wed Mar 25 04:00:59 2015] sure [Wed Mar 25 04:01:43 2015] Cale: I want to be able to rewrite things like [pal [1;2;3;4;4;3;2;1]] as [pal (1 :: [2;3;4;4;3;2] ++ [1])] by without using [replace], so I could apply my [pal] rule with [apply]. [Wed Mar 25 04:01:55 2015] s/by// [Wed Mar 25 04:02:26 2015] does this example make it clear? [Wed Mar 25 04:03:21 2015] So you want to apply p_rec? [Wed Mar 25 04:03:36 2015] Or the opposite of p_rec? [Wed Mar 25 04:04:09 2015] forall (x : X) (xs : list X), pal (x :: xs ++ [x]) -> pal xs ? [Wed Mar 25 04:04:55 2015] Cale: I want the proof of [Example pal_1_2_3_4_4_3_2_1 : pal [1;2;3;4;4;3;2;1].] be a sequence of [apply]s. but I need to rewrite the list before I can [apply p_rec]. [Wed Mar 25 04:05:29 2015] I want it to be as transparent as the hand-written inference rule [Wed Mar 25 04:11:31 2015] Cale: I'm going to paste an example shortly [Wed Mar 25 04:13:54 2015] Cale, johnw: instead of using [replace]s here, I just want to apply some lemma: https://gist.github.com/nkaretnikov/3baf1ee07fe0f41646a3 (ignore the lemma) [Wed Mar 25 04:15:17 2015] (so I don't have to prove each [replace] after I applied the rules.) [Wed Mar 25 04:16:41 2015] You could prove [forall X (xs : list X), length xs > 0 -> pal (head xs :: (middle xs) ++ [last xs]) -> pal xs], where head, middle and last are the correct functions, maybe, something like that. [Wed Mar 25 04:18:50 2015] Cypi: but how do I define head/last in a total language (without using Option or a default argument)? I've already asked about this multiple times. [Wed Mar 25 04:19:08 2015] Cypi: because your def'n implies that I need to return an element of type X. [Wed Mar 25 04:25:21 2015] http://lpaste.net/129502 [Wed Mar 25 04:25:38 2015] I actually don't fully know why that works [Wed Mar 25 04:25:57 2015] It does more computation for some reason [Wed Mar 25 04:26:25 2015] I originally intended to put a "simpl in G" in the sapply tactic there [Wed Mar 25 04:26:43 2015] But it turned out not to be required [Wed Mar 25 04:27:45 2015] Oh bizarre [Wed Mar 25 04:27:51 2015] Ltac sapply f := apply f. [Wed Mar 25 04:27:52 2015] also works [Wed Mar 25 04:28:06 2015] errrr [Wed Mar 25 04:28:09 2015] no wait [Wed Mar 25 04:28:12 2015] lol [Wed Mar 25 04:28:18 2015] Why did I think apply wasn't going to work? [Wed Mar 25 04:28:26 2015] apply *does* work [Wed Mar 25 04:28:58 2015] http://lpaste.net/129502 edited :) [Wed Mar 25 04:32:27 2015] * looks [Wed Mar 25 04:34:11 2015] Cale: nice, thank you! [Wed Mar 25 04:35:29 2015] Cale: but I do wonder whether it could be simplified, so you don't have to write down the list every time instead of just applying p_rec. [Wed Mar 25 04:37:18 2015] http://lpaste.net/129519 [Wed Mar 25 04:37:46 2015] You can tell it which steps to apply based on the goal [Wed Mar 25 04:38:53 2015] Cale: oh, that's too advanced for me, and I meant something different. I want to rewrite it as a sequence of [apply p_rec]s. [Wed Mar 25 04:40:52 2015] well, you could have: [Wed Mar 25 04:40:55 2015] Ltac pRec := match goal with [Wed Mar 25 04:40:55 2015] | [ |- pal (cons ?x ?xs) ] => apply (p_rec x (rev (tl (rev xs)))); simpl [Wed Mar 25 04:40:55 2015] end. [Wed Mar 25 04:41:03 2015] just the one thing to try [Wed Mar 25 04:42:37 2015] apply isn't smart enough to figure out what the arguments to p_rec ought to be [Wed Mar 25 04:42:42 2015] But we are [Wed Mar 25 04:43:22 2015] In particular apply doesn't know what ++ does. [Wed Mar 25 04:43:35 2015] It could be an arbitrary list function, for all apply knows. [Wed Mar 25 04:45:05 2015] I don't know Ltac. :\ [Wed Mar 25 04:45:43 2015] Well, you're effectively writing in the Ltac language when you give the tactics which are part of your proof. [Wed Mar 25 04:46:26 2015] well, nevermind, I think it'd be better for me to focus on the things that the book shows [Wed Mar 25 04:46:29 2015] It's just, you can take any command you could have written as part of a proof [Wed Mar 25 04:46:33 2015] and define that as a new thing [Wed Mar 25 04:46:33 2015] and dive in slowly, step by step [Wed Mar 25 04:46:56 2015] The thing which you're really not familiar with is "match goal with" [Wed Mar 25 04:47:50 2015] which is allowed in ordinary proofs, but not so useful unless you use some tactic which is higher order in some way, or as in this case, as part of a defined tactic [Wed Mar 25 04:48:53 2015] Just to be clear, we could have written this: http://lpaste.net/129534 [Wed Mar 25 04:49:08 2015] Cale: how do I prove the not example here? https://gist.github.com/nkaretnikov/3baf1ee07fe0f41646a3 [Wed Mar 25 04:50:28 2015] nkar`` : about your previous question, you can write something like this: http://lpaste.net/129537 [Wed Mar 25 04:50:39 2015] (the "return" annotation is not necessary, just there for clarity) [Wed Mar 25 04:50:51 2015] nkar``: Well, when you do the inversion H there, do you get any suspicious looking things in the context? [Wed Mar 25 04:52:32 2015] Cale: I don't see anything useful: [H1 : pal xs; H0 : x = 1; H2 : xs ++ [1] = [2; 3; 4; 5]] [Wed Mar 25 04:52:54 2015] xs ++ [1] = [2; 3; 4; 5] -- how plausible does this seem? [Wed Mar 25 04:53:10 2015] Remember: you're trying to prove False [Wed Mar 25 04:53:18 2015] Cale: well, it's nonsense, but I don't know how to use it. [Wed Mar 25 04:53:32 2015] So the problem is that there's this (++) in the way [Wed Mar 25 04:53:35 2015] do I need to look for the app lemmas? [Wed Mar 25 04:53:52 2015] okay, let me think a bit [Wed Mar 25 04:53:58 2015] I mean, what if (++) is a constant function which always gives [2;3;4;5] as its result? [Wed Mar 25 04:54:18 2015] That's not the case, but how do we know that here? How can we get the definition of (++) involved? [Wed Mar 25 04:54:38 2015] We need to be able to unfold it by a step at least [Wed Mar 25 04:54:57 2015] and for that to happen, we need to do a case analysis on xs [Wed Mar 25 04:55:14 2015] * tries [Wed Mar 25 05:01:16 2015] The proof you get might be fairly long and messy, but it should be extremely repetitive. [Wed Mar 25 05:02:28 2015] Cale: will it be easier to prove not (pal [1;2]) first? [Wed Mar 25 05:02:39 2015] (so I don't have to deal with many cases) [Wed Mar 25 05:03:03 2015] I'm assuming the repetition you're talking about comes from the number of elements [Wed Mar 25 05:03:14 2015] is it the case? [Wed Mar 25 05:03:17 2015] It does come from the number of elements [Wed Mar 25 05:03:42 2015] okay, then I'll try that first [Wed Mar 25 05:03:57 2015] You're trying to show that forall (xs : list nat), not (xs ++ [1] = [2,3,4,5]). [Wed Mar 25 05:04:33 2015] You could do this by a sequence of lemmas, which proved first forall (xs : list nat), not (xs ++ [1] = []). [Wed Mar 25 05:04:44 2015] and then forall (xs : list nat), not (xs ++ [1] = [5]). [Wed Mar 25 05:04:46 2015] Cale: thanks for your help, it's been a fruitful discussion (at least for me :)) [Wed Mar 25 05:04:49 2015] and so on [Wed Mar 25 05:21:42 2015] Did you manage to get it in the messy way? [Wed Mar 25 05:21:51 2015] nkar``: ^^ [Wed Mar 25 05:23:35 2015] Cale: I proved [not (pal [1;2])] with [Lemma not_xs_1 : forall (xs : list nat), not (xs ++ [1] = []).], now I'm trying to define a more general lemma. [Wed Mar 25 05:23:44 2015] s/define/prove/ [Wed Mar 25 05:24:53 2015] okay, I've just proved [Lemma not_app_nil : forall (X : Type) (xs ys : list X) (y : X), not (xs ++ y :: ys = []).] [Wed Mar 25 05:24:53 2015] [Wed Mar 25 05:32:16 2015] Cale: woo, I proved [Example not_pal_1_2_3_4_5 : not (pal [1;2;3;4;5]).] using the above lemma! [Wed Mar 25 05:32:27 2015] indeed, there's a lot of repetition. [Wed Mar 25 05:34:49 2015] the proof is at the bottom: https://gist.github.com/nkaretnikov/3baf1ee07fe0f41646a3 [Wed Mar 25 05:35:28 2015] Now try not (pal [1;2;3;4;1]) :) [Wed Mar 25 05:36:32 2015] I wanted to try [not (pal [1,2,3,3,4,3,2,1])], but I'll do the suggested one first [Wed Mar 25 05:37:16 2015] Or maybe even just [1;2;3;1], which is the same but with a little less repetitive portion [Wed Mar 25 05:37:36 2015] okay :) [Wed Mar 25 05:38:23 2015] Cale: is there a way to get rid of repetition in [not_pal_1_2_3_4_5] without using Ltac? [Wed Mar 25 05:38:29 2015] nkar``: why don't you prove "pal x" is equivalent to "x = rev x"? [Wed Mar 25 05:38:47 2015] (or define it this way) [Wed Mar 25 05:39:45 2015] sgnb: re: define: the book says: "Define an inductive proposition [pal] on [list X] that captures what it means to be a palindrome. (Hint: You'll need three cases. Your definition should be based on the structure of the list; just having a single constructor c : forall l, l = rev l -> pal l may seem obvious, but will not work very well.)" [Wed Mar 25 05:39:47 2015] Yeah, I suppose the right way is to do that and then use decidable equality. [Wed Mar 25 05:40:41 2015] sgnb: I proved [Theorem pal_rev : forall (X : Type) (xs : list X), pal xs -> xs = rev xs.], but couldn't prove the opposite [Wed Mar 25 05:42:33 2015] Cale: what's decidable equality? this description is to brief for me: http://ncatlab.org/nlab/show/decidable+equality [Wed Mar 25 05:42:53 2015] or, rather, how do I use it? [Wed Mar 25 05:43:43 2015] Having decidable equality for a type T means that you can provide a function [forall (t1 t2 : T), {t1 = t2} + {t1 <> t2}] [Wed Mar 25 05:43:56 2015] in other words: it is possible to decide if two elements of T are equal or not [Wed Mar 25 06:12:42 2015] nkar``: https://paste.debian.net/163128/ [Wed Mar 25 06:17:57 2015] nkar``: then all your "pal " examples become "apply rev_pal; reflexivity" [Wed Mar 25 06:19:09 2015] nkar``: and all your "not (pal )" examples become "intro H; apply pal_rev in H; disciminate" [Wed Mar 25 06:21:49 2015] sgnb: interesting, thanks. but there are tactics, which are not covered in the book, so I'd rather not use this. [Wed Mar 25 06:26:06 2015] nkar``: well, the key thing here is well founded induction... isn't that covered in your book? [Wed Mar 25 06:26:38 2015] I don't think so [Wed Mar 25 06:27:39 2015] that's too bad... [Wed Mar 25 06:28:11 2015] IMHO, it's torture to prove your "pal " examples without using rev_pal [Wed Mar 25 06:29:08 2015] (and conversely, to prove your "not (pal )" examples without using pal_rev) [Wed Mar 25 06:32:44 2015] sgnb: to be fair, there's an example that requires to prove pal_rev. it's just that I don't know how to do it using only the covered tactics. after trying to prove it for two weeks while constantly bugging this channel, I decided to skip it. [Wed Mar 25 09:19:55 2015] channel list [Wed Mar 25 09:19:57 2015] chat list [Wed Mar 25 09:20:01 2015] wah sorry [Wed Mar 25 09:20:04 2015] wrong channel ... [Wed Mar 25 09:20:10 2015] (I'm using bitlbee ... :/ ) [Wed Mar 25 09:24:35 2015] The obvious interpretation is that you mistook the #coq window for your bitlbee chat window. [Wed Mar 25 09:25:16 2015] The funnier interpretation is that you're connecting your IRC client to bitlbee and then having bitlbee connect to an IRC server on your behalf. [Wed Mar 25 12:36:28 2015] Is there an easy way to configure the coq codebase for merlin (in vim) ? [Wed Mar 25 15:46:42 2015] hhhhhmmmmmm [Wed Mar 25 15:46:50 2015] how does path relevance in hott work? [Wed Mar 25 15:47:11 2015] hmm? [Wed Mar 25 15:47:15 2015] where do you find that? [Wed Mar 25 15:47:15 2015] if i can prove nat = bin, how am i not allowed to prove S : bin -> bin [Wed Mar 25 15:49:14 2015] you would be allowed to do that, as I understand it [Wed Mar 25 15:50:08 2015] it would be a different 'version' of S in my mind, but I actually have no idea how this stuff is going to be implemented [Wed Mar 25 16:05:34 2015] benzrf: who says you're not allowed? [Wed Mar 25 16:06:03 2015] o-O [Wed Mar 25 16:06:12 2015] i can do that? [Wed Mar 25 16:06:27 2015] I don't know the answer to that; I want to know why you think you can't [Wed Mar 25 16:06:31 2015] uh [Wed Mar 25 16:06:36 2015] i guess it doesnt make sense to me [Wed Mar 25 16:06:48 2015] so, that's way different from "not allowed" [Wed Mar 25 16:06:55 2015] hha [Wed Mar 25 16:07:02 2015] oooh [Wed Mar 25 16:07:04 2015] wait [Wed Mar 25 16:07:12 2015] i guess the application of the path to S is what has type bin [Wed Mar 25 16:07:14 2015] not S itself [Wed Mar 25 16:07:17 2015] which makes sense kind of [Wed Mar 25 16:07:50 2015] the application of the path would result in S under the isomorphism [Wed Mar 25 16:07:53 2015] n-neat [Wed Mar 25 16:09:35 2015] johnw i kept my inductive type with 256min : the Machregs.v file takes 10 min to compile. [Wed Mar 25 16:09:48 2015] johnw but at least it works without modification. [Wed Mar 25 16:11:48 2015] there is that [Wed Mar 25 16:17:38 2015] johnw but i decided that no register was destroyed by opcodes in mmix . [Wed Mar 25 16:37:50 2015] What do you call the + and -'s you add in front of certain lines to make it more readable? [Wed Mar 25 16:38:45 2015] bullets [Wed Mar 25 16:42:09 2015] Thanks [Wed Mar 25 19:40:23 2015] I may be making a dumb mistake here, but why can't Coq infer an internal placeholder of type Type? http://pastebin.ubuntu.com/10681202/ [Wed Mar 25 19:44:09 2015] You are not providing any return type for your function, so it could actually be many things (like [list (option A)] or [list (option (option A))] ) [Wed Mar 25 19:44:32 2015] Cypi: right, I was coming to that realization [Wed Mar 25 19:44:38 2015] that None doesn't give much information [Wed Mar 25 19:44:41 2015] So have to provide enough hints, e.g. by specifying a return type, or by instantiating nil with some argument [Wed Mar 25 19:44:46 2015] (or cons, for that matter) [Wed Mar 25 19:44:56 2015] I have a bad habit of leaving types implicit in Coq because it's sometimes easier [Wed Mar 25 19:45:13 2015] A return type would be the best thing to do, imo :) [Wed Mar 25 19:45:27 2015] done, worked, thanks [Wed Mar 25 19:45:29 2015] :-) [Wed Mar 25 19:50:08 2015] (fwiw, the Cons None nil should have been just l in the base case, too) [Wed Mar 25 20:04:40 2015] or @None A [Wed Mar 25 21:25:20 2015] (16 [Thu Mar 26 10:02:29 2015] hmmmmmmmm [Thu Mar 26 10:02:43 2015] how do you turn, e.g., group isomorphism, into equality in hott [Thu Mar 26 10:02:54 2015] how do you have a type representing a group such that you can write predicates on that type [Thu Mar 26 10:03:13 2015] about its group props [Thu Mar 26 11:22:34 2015] benzrf: a group type would be a record that contains the carrier type (which you should require to be an hSet) and the operations and the laws [Thu Mar 26 11:23:10 2015] benzrf: then a group isomorphism is defined in the usual way, as an isomorphism that respects the group operations [Thu Mar 26 11:23:41 2015] benzrf: and through univalence and some congruence proofs you can turn that into an equality of the groups [Thu Mar 26 11:54:25 2015] hmmmmmm [Thu Mar 26 11:54:33 2015] hold on [Thu Mar 26 11:54:35 2015] so like [Thu Mar 26 11:54:48 2015] Inductive grp : Type := [Thu Mar 26 11:55:31 2015] | grp : forall (G : Type) (o : G -> G -> G), formsgroup G o, grp. [Thu Mar 26 11:55:37 2015] | grp : forall (G : Type) (o : G -> G -> G), formsgroup G o -> grp. [Thu Mar 26 11:55:42 2015] (the second one is a correction) [Thu Mar 26 11:56:41 2015] yeah [Thu Mar 26 11:57:10 2015] er, hold on [Thu Mar 26 11:57:30 2015] Saizan: grp would have to be parameterized wouldnt it [Thu Mar 26 11:58:09 2015] * has gone and confused himself [Thu Mar 26 12:03:55 2015] benzrf: nope [Thu Mar 26 12:14:45 2015] you could move the (G: Type) argument up to an index, if you wanted to [Thu Mar 26 12:15:01 2015] that would make some uses of grp easier [Thu Mar 26 12:15:10 2015] but not necessary [Thu Mar 26 12:39:33 2015] uhh [Thu Mar 26 12:39:43 2015] ok then what would a grp iso then equality look like [Thu Mar 26 12:39:52 2015] argh [Thu Mar 26 12:39:54 2015] i gotta go [Thu Mar 26 12:40:02 2015] please answer while im gone, ill read it when back :| [Thu Mar 26 12:40:11 2015] is htis about custom-defined paths or something? [Thu Mar 26 12:56:06 2015] http://homotopytypetheory.org/2012/09/23/isomorphism-implies-equality/ [Thu Mar 26 12:56:20 2015] benzrf: no, you don't need an higher inductive type for grp [Thu Mar 26 12:57:06 2015] what would the isomorphism be between [Thu Mar 26 12:57:48 2015] benzrf: fwiw, there's ##hott [Thu Mar 26 12:57:55 2015] Saizan: are you Nils? [Thu Mar 26 12:58:33 2015] let nils = repeat [] [Thu Mar 26 13:00:12 2015] johnw: nope [Thu Mar 26 13:00:21 2015] hold on though [Thu Mar 26 13:00:30 2015] does iso-implies-eq hold beyond just plain types [Thu Mar 26 13:00:38 2015] johnw: nils is in the office in front of mine though :) [Thu Mar 26 13:00:47 2015] ah, cool! [Thu Mar 26 13:00:58 2015] I want to get a better handle on canonical structures [Thu Mar 26 13:01:26 2015] and I still have yet to grasp encoding algebraic signatures with Coq [Thu Mar 26 13:01:32 2015] benzrf: see the blog post, they define what an iso for an algebraic structure should be [Thu Mar 26 13:02:09 2015] benzrf: but it's the same thing you'd get from isos in the category of groups, or from universal algebra [Thu Mar 26 13:03:11 2015] hmmmm hold on [Thu Mar 26 13:03:14 2015] wait, so [Thu Mar 26 13:03:32 2015] what would be the type of a group iso under the encoding i posted above [Thu Mar 26 13:03:40 2015] grp <-> grp? [Thu Mar 26 13:07:01 2015] GrpIso (grp A Ao p) (grp B Bo p) = Sigma (f : Iso A B), (forall a0 a1, applyIso f (Ao a0 a1) = Bo (applyIso f a0) (applyIso f a1)) [Thu Mar 26 13:07:16 2015] GrpIso (grp A Ao p) (grp B Bo q) = Sigma (f : Iso A B), (forall a0 a1, applyIso f (Ao a0 a1) = Bo (applyIso f a0) (applyIso f a1)) [Thu Mar 26 13:07:22 2015] assuming p and q are propositional [Thu Mar 26 13:09:58 2015] tfw i cant read agda [Thu Mar 26 13:10:06 2015] Saizan: good lord [Thu Mar 26 13:10:47 2015] that's more like informal notation than Agda [Thu Mar 26 13:11:08 2015] Saizan: ah no [Thu Mar 26 13:11:13 2015] that was a reponse to your link earlier [Thu Mar 26 13:11:17 2015] *respones [Thu Mar 26 13:11:19 2015] god dammit [Thu Mar 26 13:11:19 2015] ah, fair enough [Thu Mar 26 13:11:30 2015] wait so [Thu Mar 26 13:11:43 2015] what constitutes an iso from the POV of the univalence axiom [Thu Mar 26 13:12:29 2015] same things an iso has always been [Thu Mar 26 13:12:33 2015] to . from = id = from . to [Thu Mar 26 13:12:35 2015] fuck [Thu Mar 26 13:12:37 2015] be back later ;-; [Thu Mar 26 14:40:10 2015] johnw: yeah but [Thu Mar 26 14:40:18 2015] can it be something other than a normal function [Thu Mar 26 14:40:31 2015] like something in an arbitrary category [Thu Mar 26 14:40:33 2015] idk [Thu Mar 26 14:41:27 2015] johnw: ehhhh no. Quasi-inverse versus bi-inverse is a subtle thing. [Thu Mar 26 14:42:05 2015] every time I answer anything about HoTT, somewhere in the back of my mind there is a little voice that says, "It's probably not as simple as that..." [Thu Mar 26 14:43:15 2015] johnw: ya, the subtle ways to shoot yourself with HoTT are reason enough for me to not touch it. It needs more work. [Thu Mar 26 14:46:29 2015] on the plus side, my foot is very well ventilated [Thu Mar 26 14:46:57 2015] reminds me of a comment from Stroustrup about C++ [Thu Mar 26 14:47:13 2015] "We don't just let you shoot yourself in the foot, we give you a shotgun so you can take care of the whole leg." [Thu Mar 26 14:49:56 2015] I'm more a fan of, "C++: An octopus made by nailing extra legs onto a dog." [Thu Mar 26 14:50:55 2015] ianjneu: you can still turn isomorphisms into equalities [Thu Mar 26 14:51:57 2015] benzrf: the blog post attaches a proof that just from the univalence axiom about simple isomorphisms of types you can derive the one about grp isomorphism [Thu Mar 26 14:52:24 2015] i cant read the hardcore agda :| [Thu Mar 26 14:52:40 2015] that's why i'm telling you what it does :) [Thu Mar 26 14:52:51 2015] "how" would be a bit long [Thu Mar 26 14:55:22 2015] hhhh [Thu Mar 26 14:58:08 2015] but it's all about the equality for dependent products and functions working nicely, they are described in one of the first few chapters of the book [Thu Mar 26 17:45:35 2015] * returned to code [Thu Mar 26 21:47:10 2015] I'm trying to use the following to prove that List's skipn function always reduces the list's size in reasonable circumstances: [Thu Mar 26 21:47:24 2015] Lemma skipn_dec : forall (n:nat) (l:list A), gt n 0 * gt (length l) 0 -> lt (length (skipn n l)) (length l). [Thu Mar 26 21:47:43 2015] but it's still trying to get me to prove the case where n = 0. What am I doing wrong? I'm very new to the syntax. [Thu Mar 26 21:48:25 2015] I'm probably not combining the propositions correctly [Thu Mar 26 21:50:41 2015] yup, appears it's assuming they're nats... I should probably go read more [Thu Mar 26 21:52:12 2015] apparently all I needed was 'and' :/ [Thu Mar 26 21:53:49 2015] Ah, this is [and : Prop -> Prop -> Prop]? [Fri Mar 27 00:40:16 2015] night [Fri Mar 27 05:17:45 2015] I keep reading everywhere that "allowing nontermination allows to prove any theorem" [Fri Mar 27 05:18:00 2015] but I have yet not seen an explanation why [Fri Mar 27 05:18:23 2015] so, how would that be possible? [Fri Mar 27 05:20:09 2015] I was thinking that this onle-liner could be such a simple demonstration: [Fri Mar 27 05:23:01 2015] Fixpoint evil (A : Prop) : Prop := evil A. [Fri Mar 27 05:23:08 2015] not sure if that makes sense [Fri Mar 27 05:23:38 2015] (Of course I realize this definition is rejected, but I want to come up with a definition that, *if accepted* would allow to prove anything). [Fri Mar 27 05:25:57 2015] jstolarek: yeah, that's right [Fri Mar 27 05:26:13 2015] you can trivially do something like that in Haskell. foo :: a; foo = foo [Fri Mar 27 05:26:28 2015] so Haskell's type system corresponds to an inconsistent logic [Fri Mar 27 05:29:23 2015] oh, actually the point is that evil could return anything, so maybe something like Fixpoint evil (A : Prop) : A := evil A. [Fri Mar 27 05:29:56 2015] evil takes any proposition A and return a proof of that proposition, but it takes forever to produce it :) [Fri Mar 27 05:33:01 2015] oh, right, the return type was wrong [Fri Mar 27 05:33:03 2015] thanks [Fri Mar 27 05:45:16 2015] jstolarek, Fixpoint b (n:nat) : False := b 0. [Fri Mar 27 06:21:38 2015] hello， are there anyone good at equality proving? (JMeq maybe) https://github.com/lolisa/Category_Theory/blob/master/Category_Theory.v How can I prove this? I am stuck, or do I need to restructure automorphism and isomorphism a bit? [Fri Mar 27 07:32:04 2015] How can I prove that all isomorphism on the same arrow is unique? Do I need to add more axiom to Category to prove this? [Fri Mar 27 11:21:21 2015] hmm [Fri Mar 27 11:21:27 2015] why is × a big deal in hott [Fri Mar 27 11:21:38 2015] isnt it a degenerate form of Σ [Fri Mar 27 11:21:47 2015] asking cause its one of the symobols on the cover of the book [Fri Mar 27 11:23:58 2015] benzrf: it's more traditional than a big deal [Fri Mar 27 11:26:18 2015] rip [Fri Mar 27 11:33:13 2015] nkar`: actually, it is possible to prove it without well founded induction: https://paste.debian.net/163528/ [Fri Mar 27 11:34:09 2015] sgnb: thanks for the follow up! [Fri Mar 27 11:34:11 2015] * looks [Fri Mar 27 11:35:13 2015] omega, constructor, and assumption have not been covered in the book [Fri Mar 27 11:35:56 2015] sgnb: would you like to prove it using the covered tactics if I gave you the list? [Fri Mar 27 11:37:06 2015] sgnb: https://www.cis.upenn.edu/~bcpierce/sf/current/MoreCoq.html#lab182 [Fri Mar 27 11:37:23 2015] replace is missing from the list, though [Fri Mar 27 11:48:26 2015] benzrf: Although the book doesn't say too much about semantics, when you go to talk about categorical semantics of a product, just for the sake of how much more convenient it is, you definitely wouldn't want to treat it as a Sigma type. [Fri Mar 27 11:48:47 2015] benzrf: Compare the diagrams here: http://ncatlab.org/nlab/show/product#relation_to_type_theory with the ones here: http://ncatlab.org/nlab/show/dependent+sum#relation_to_type_theory [Fri Mar 27 11:51:20 2015] that's a scary computation rule [Fri Mar 27 11:54:04 2015] It's formed by combining the diagram for intro and the diagram for elim (and adding an arrow) [Fri Mar 27 11:54:45 2015] It's mostly tricky because the type of p_2 is fancy. [Fri Mar 27 11:54:54 2015] hmm, is that similar to eta expansion? [Fri Mar 27 11:56:07 2015] It's the beta rule [Fri Mar 27 11:56:57 2015] hmm, the combination of introduction + elimination made me think eta [Fri Mar 27 11:57:12 2015] beta and eta both involve an intro and an elim [Fri Mar 27 11:57:16 2015] as in something like eta p = (fst p, snd p), but that doesn't define the computation [Fri Mar 27 11:57:16 2015] it's just which way around :) [Fri Mar 27 11:58:19 2015] Cale: beta is introduce => eliminate while eta is eliminate => (re-)introduce? [Fri Mar 27 11:58:27 2015] yeah [Fri Mar 27 11:58:36 2015] makes sense [Fri Mar 27 13:15:17 2015] nkar` I have ha proof which only uses covered tactics [Fri Mar 27 13:17:44 2015] except ';' because it's just too handy (it's introduced in Imp.v) [Fri Mar 27 13:18:18 2015] I also use a few lemmas from the standard library, but they are mostly similar to properties from later in Prop.v [Fri Mar 27 13:19:03 2015] e.g. S n < S m -> n < m [Fri Mar 27 13:19:43 2015] S n < m -> n < m [Fri Mar 27 13:31:50 2015] irishsultan pasted “proof of rev_pal” at http://lpaste.net/129755 [Fri Mar 27 13:45:36 2015] I allow myself to suggest a shorter proof :p http://lpaste.net/129759 [Fri Mar 27 13:46:50 2015] Oh, right, my definition of pal was not the same, sorry :x [Fri Mar 27 14:02:08 2015] Cypi, your definition works, but they warn that it makes things more difficult [Fri Mar 27 14:02:14 2015] presumably for other reasons [Fri Mar 27 14:03:20 2015] oh, no sorry, it's ok, except it misses an obvious case the empty list [Fri Mar 27 14:04:52 2015] ah, no, it doesn't [Fri Mar 27 14:09:04 2015] Cypi, your proof works too (after some renaming), it's much better than mine [Fri Mar 27 14:11:02 2015] and the reason it works better is that you don't use ';' [Fri Mar 27 14:11:20 2015] and destruct things in a different order [Sat Mar 28 02:35:48 2015] سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ [Sat Mar 28 06:35:20 2015] Hello I have some definitions in CoqIde [Sat Mar 28 06:35:29 2015] how can I run some evaluation queries? [Sat Mar 28 06:35:38 2015] Sort of like Eval compute in ex2 4. [Sat Mar 28 06:35:45 2015] (this is not homework) [Sat Mar 28 06:44:05 2015] Also, a definition working in Coq does not work in CoqIde [Sat Mar 28 06:44:11 2015] ah, nevermind. Forgot to require List [Sun Mar 29 08:42:19 2015] anybody familiar with HoTT? [Sun Mar 29 08:45:42 2015] yes... there is also #hott [Sun Mar 29 08:45:59 2015] oh nice [Sun Mar 29 08:54:48 2015] well, #hott seems pretty empty [Sun Mar 29 08:54:52 2015] 1st question about homotopy type theory: the h-levels seem reminiscent to the chain complexes from homology, and they are also describing relationships between boundaries and interiors, is there a connection here? [Sun Mar 29 08:55:12 2015] are there an IRC for category? [Sun Mar 29 08:57:06 2015] 2nd question about HoTT: i'm i correct in informally interpreting a type of h-level N as being *similar* to an (ND + (N-1)D + ... + 2D + 1D + (true/false)D + (singleton)D) "manifold"? [Sun Mar 29 08:57:15 2015] am i* [Sun Mar 29 08:58:15 2015] i can explain that better if it unintelligible [Sun Mar 29 08:59:48 2015] 1st question is just a curiosity, 2nd question is because i'm trying to come up with a data-structure to adequately model the concept of an "event" [Sun Mar 29 09:02:56 2015] ##hott is the place [Sun Mar 29 12:18:29 2015] Hi, I see it often, but I don't know what it means ... What does the term "evar" refer to exactly ? [Sun Mar 29 12:20:14 2015] an existential variable: ones that still need to be assigned a value [Sun Mar 29 12:20:59 2015] ok, thanks ^^ [Sun Mar 29 16:20:15 2015] "despite its simplicity the language is complete and universal" <- any ideas what does "complete" mean in this sentence? [Sun Mar 29 16:20:37 2015] e.g. is there a widely used notion of "completeness" in programming languages? [Sun Mar 29 16:21:11 2015] I think universal means turing complete in this sentence, so this completeness should mean something else [Sun Mar 29 20:02:34 2015] If I define [Inductive total_relation : nat -> nat -> Prop := | tr : forall (x y : nat), total_relation x y.], I can prove [Theorem lt_total : forall (x y : nat), x < y -> total_relation x y. Proof. intros. apply tr. Qed.], which is nonsense since [lt] is not total. so, is the first definition wrong, or does the second one not imply that [lt] is total? [Sun Mar 29 20:03:06 2015] total_relation doesn't take a relation [Sun Mar 29 20:03:18 2015] so I think both are wrong [Sun Mar 29 20:03:30 2015] you should be proving Theorem lt_total : total_relation lt. no? [Sun Mar 29 20:03:41 2015] total_relation is just some relation on natural numbers which happen to be verified for any pair of nats [Sun Mar 29 20:03:42 2015] no [Sun Mar 29 20:04:04 2015] so indeed, you can prove anything of the form [forall x y, _ -> total_relation x y] [Sun Mar 29 20:04:05 2015] vanila: I'm doing (** **** Exercise: 2 stars (total_relation) Define an inductive binary relation [total_relation] that holds between every pair of natural numbers. *) [Sun Mar 29 20:04:14 2015] oh [Sun Mar 29 20:04:20 2015] Well, you did it, indeed :) [Sun Mar 29 20:04:20 2015] then total_relation is correct [Sun Mar 29 20:04:33 2015] The theorem just doesn't prove anything on lt [Sun Mar 29 20:04:50 2015] You co uld also define [Sun Mar 29 20:04:58 2015] Definition total_relation (x y : nat) : Prop := True. [Sun Mar 29 20:05:43 2015] oh but its supposed to be inductive [Sun Mar 29 20:06:04 2015] Cypi: so this definition can't be used to talk about relations because it doesn't accept a relation, as vanila said. [Sun Mar 29 20:06:33 2015] Yes. You just defined a relation, not a predicate on relations [Sun Mar 29 20:06:55 2015] okay [Sun Mar 29 20:22:42 2015] win 1 [Mon Mar 30 12:22:24 2015] hm. does anybody know about the state of https://github.com/trefis/deques/, or the person who programmed it [Mon Mar 30 14:16:39 2015] `Error: The reference mod was not found in the current environment.`. How do I use `mod`? [Mon Mar 30 14:18:25 2015] I'm using 8.4pl5 [Mon Mar 30 15:40:34 2015] Does the -debug option in the configure enable the debug build (-g) of coq ? [Mon Mar 30 16:09:08 2015] hmm [Mon Mar 30 16:09:09 2015] given [Mon Mar 30 16:09:22 2015] Definition injective {A B} (f : A -> B) : Prop := forall a b : A, f a = b -> a = b. [Mon Mar 30 16:09:24 2015] and [Mon Mar 30 16:09:28 2015] Definition injective' {A B} (f : A -> B) : Prop := forall a b : A, a <> b -> f a <> f b. [Mon Mar 30 16:09:40 2015] then injective f -> injective' f but not vice versa, right? [Mon Mar 30 16:12:24 2015] in general A -> B implies ~B -> ~A but not vice versa, so you're right [Mon Mar 30 16:29:29 2015] goddamn [Mon Mar 30 16:29:30 2015] i [Mon Mar 30 16:29:35 2015] totally missed that that was a contrapositive [Mon Mar 30 16:29:38 2015] o_O [Mon Mar 30 16:29:50 2015] haha [Mon Mar 30 16:46:51 2015] ianjneu doing his PhD defense live: https://www.youtube.com/watch?v=P7LypmE01VI [Mon Mar 30 16:46:54 2015] :D [Mon Mar 30 16:46:54 2015] tha's pretty cool [Mon Mar 30 16:47:36 2015] ianjneu is doing an impressive imitataion of "Flash player out of date" :) [Mon Mar 30 16:47:51 2015] ol [Mon Mar 30 16:47:52 2015] lol [Mon Mar 30 16:48:18 2015] johnw: youtube.com/html5 ? [Mon Mar 30 16:48:20 2015] 'livestreamer' command line program might let you watch it without flash [Mon Mar 30 16:48:34 2015] johnw: youtube-dl? [Mon Mar 30 16:49:39 2015] nkar`: good point [Mon Mar 30 16:49:59 2015] well, I don't know if you can download a livestream [Mon Mar 30 16:50:45 2015] let me try it [Mon Mar 30 16:51:21 2015] I got ERROR: m3u8 download detected but ffmpeg or avconv could not be found. Please install one. [Mon Mar 30 16:51:36 2015] updated flash [Mon Mar 30 16:54:14 2015] notdan goodluck to him !! [Mon Mar 30 17:19:41 2015] is there any documentation for what goes into a .vo file? even pointers to specific Coq source code that exports/imports .vo file contents would be helpful. [Mon Mar 30 17:28:04 2015] ooh i missed his thesis [Mon Mar 30 17:30:35 2015] benzrf neither i could see it :( [Tue Mar 31 13:47:01 2015] I tried making my own definition of mod since I can't seem to find any, https://gist.github.com/anonymous/4393ed91147c9dfcdac6 [Tue Mar 31 13:47:30 2015] But I get `Error: Cannot guess decreasing argument of fix.` and I can't seem to fix it [Tue Mar 31 13:48:34 2015] yeah, that's not going to work as it stands [Tue Mar 31 13:48:51 2015] I understand that it probably doesn't accept "minus" [Tue Mar 31 13:48:59 2015] and maybe I should match om something like (minus x d) [Tue Mar 31 13:49:05 2015] no ,the problem is it doesn't see you reducing x or d structurally [Tue Mar 31 13:49:05 2015] so it knows what's decreasing [Tue Mar 31 13:49:13 2015] yeah [Tue Mar 31 13:49:24 2015] you could say: [Tue Mar 31 13:49:35 2015] Program Fixpoint mod (x d : nat) {measure (minus x d)} ... [Tue Mar 31 13:49:44 2015] then you prove that x - d is smaller at each step [Tue Mar 31 13:50:07 2015] Is there another way without measure? [Tue Mar 31 13:50:16 2015] One using simpler constructs [Tue Mar 31 13:50:29 2015] well, there whatever construct Program Fixpoint is using [Tue Mar 31 13:50:39 2015] you can look at the resulting definition and see what it looks like [Tue Mar 31 13:53:03 2015] I meant if I could do something just using match and stuff, like https://gist.github.com/anonymous/74efc07a6be326d5b4f0 [Tue Mar 31 13:53:13 2015] I'd prefer not to use measure [Tue Mar 31 13:53:15 2015] thanks to those that tuned in yesterday. I passed. [Tue Mar 31 13:53:25 2015] congrats, ianjneu! [Tue Mar 31 13:53:28 2015] I caught the latter half [Tue Mar 31 13:53:39 2015] kba: not without approaching the problem another way [Tue Mar 31 13:53:52 2015] like how? [Tue Mar 31 13:54:03 2015] I haven't the free time right now to think that far into it [Tue Mar 31 13:54:17 2015] you'd need a way that does a match on "x" or "d" [Tue Mar 31 13:54:25 2015] not a match on the result of passing those arguments to a function [Tue Mar 31 13:54:45 2015] Okay, I figured if I used (minus x d) as a match, it would see I was decreasing something [Tue Mar 31 13:55:26 2015] seeing that requires induction [Tue Mar 31 13:55:39 2015] perhaps minus x 1 would work, for example, but not minus x d for any x and d [Tue Mar 31 13:55:58 2015] minus x 1 doesn't work either [Tue Mar 31 13:56:03 2015] but matching on (S x') works [Tue Mar 31 13:56:10 2015] but again, not the right result I gte [Tue Mar 31 13:56:29 2015] and I don't know how to do (S x') a total of d times [Tue Mar 31 13:57:46 2015] that's why I would use Program Fixpoint :) [Tue Mar 31 13:58:21 2015] hm [Tue Mar 31 13:58:52 2015] never used that, don't know how [Tue Mar 31 13:59:07 2015] I showed you earlier [Tue Mar 31 13:59:28 2015] then, after the definition, type: Obligation 1. [Tue Mar 31 13:59:34 2015] and you'll prove the termination condition [Tue Mar 31 13:59:50 2015] You wrote. Program Fixpoint mod (x d : nat) {measure (minus x d)} [Tue Mar 31 13:59:56 2015] I don't even know what { } means here [Tue Mar 31 14:00:07 2015] it provides the measure [Tue Mar 31 14:00:11 2015] that's the exact syntax you need [Tue Mar 31 14:00:20 2015] Program Fixpoint mod (x d : nat) {measure (minus x d)}. [Tue Mar 31 14:00:22 2015] Error: Program Fixpoint needs defined bodies. [Tue Mar 31 14:00:46 2015] if I do := [Tue Mar 31 14:00:48 2015] I get Error: Library Coq.Program.Wf has to be required first. [Tue Mar 31 14:00:56 2015] If that's actually needed, I think I'm going to opt out ^^ [Tue Mar 31 14:01:11 2015] yeah, that is what's needed [Tue Mar 31 14:01:17 2015] Wf is the library for proving well-foundedness [Tue Mar 31 14:01:22 2015] it provides the measure support [Tue Mar 31 14:01:39 2015] fwiw, I use Program Fixpoint pretty regularly [Tue Mar 31 14:01:39 2015] okay, well I don't know what I'm doing anymore and how that would work, so I'll stop here [Tue Mar 31 14:01:44 2015] it doesn't introduce any new axioms or anything [Tue Mar 31 14:01:44 2015] thanks for the help [Tue Mar 31 14:02:00 2015] you're very close to knowing what you're doing, btw :) [Tue Mar 31 14:02:05 2015] I'm sorry if this strange syntax seems confusing at first [Tue Mar 31 14:02:20 2015] I wanted to make some extra for a term project, and we're usually not allowed to use what we haven't been taught [Tue Mar 31 14:02:25 2015] so I feel like I'm going beyond that now [Tue Mar 31 14:02:25 2015] ahh [Tue Mar 31 14:02:43 2015] well, think on it more, see if you can find some way to prove it with ordinary structural recursion [Tue Mar 31 14:03:25 2015] I had an idea, like when I match on stuff like | (S x) => [Tue Mar 31 14:03:29 2015] that defines a decrement [Tue Mar 31 14:04:05 2015] so if I could do something like match with | (plus x' d) => [Tue Mar 31 14:04:10 2015] then that would "give me" the x' I needed [Tue Mar 31 14:04:53 2015] because I want to find x' = x - d, which is x' + d = x [Tue Mar 31 14:05:16 2015] and as long as d>0, then x' < x [Tue Mar 31 14:05:57 2015] but I can't even use plus, Error: Unknown constructor: plus. [Tue Mar 31 14:08:36 2015] https://gist.github.com/anonymous/d8e4488e162a25ab74ed [Tue Mar 31 14:09:04 2015] that certainly feels closer [Tue Mar 31 14:09:15 2015] I bet you only need to match on x [Tue Mar 31 14:09:38 2015] well, I still get the "Unknown construct plus" [Tue Mar 31 14:09:51 2015] you can't call a function at that position [Tue Mar 31 14:09:56 2015] and I felt I needed to match with d = 0, because if d = 0 and I do a recursion, it'll never decrement [Tue Mar 31 14:10:00 2015] constructors only there, like S ' x [Tue Mar 31 14:10:01 2015] S x' [Tue Mar 31 14:10:04 2015] the recursion only terminates with d>0 [Tue Mar 31 14:10:12 2015] ah ,ok [Tue Mar 31 14:10:21 2015] you should only need to match on one of them [Tue Mar 31 14:11:12 2015] well, I have to make sure d>0. Otherwise with a recursive definition that does (mod (x-d) d), that'll just end up going (mod x 0) infinitely [Tue Mar 31 14:11:50 2015] so I don't see how I could remove match d [Tue Mar 31 14:11:59 2015] and I want to find x-d, so I need match x for that [Tue Mar 31 14:20:23 2015] ok, it may be that you need both [Tue Mar 31 14:20:39 2015] as I said, I havent' the mental space to be sure (I'm on the phone as we chat) [Tue Mar 31 14:27:04 2015] I think I'll just skip it, I've already created a ton of stuff other than what was actually asked [Tue Mar 31 14:27:34 2015] :) [Tue Mar 31 14:27:41 2015] nice mind-bending stuff, isn't it [Tue Mar 31 16:21:31 2015] does writing agda feel different from coq because it lacks tactics? I'm concerned that tactics may hide a lot of details from me, which are important for learning how to prove things. is it the case? [Tue Mar 31 16:23:20 2015] that really depends on what you're writing and why [Tue Mar 31 16:23:30 2015] also, you can use tactics less in Coq [Tue Mar 31 16:23:51 2015] and Agda has proving-related macros, like the equational reasoning module [Tue Mar 31 16:24:08 2015] what do you mean by use less? [Tue Mar 31 16:24:19 2015] you can write proof terms ilterally, as you would in Agda [Tue Mar 31 16:24:28 2015] you just less automation from Emacs with creating them [Tue Mar 31 16:24:41 2015] tactics are only macros to build complex proof terms [Tue Mar 31 16:24:57 2015] is it considered okay? [Tue Mar 31 16:25:05 2015] okay from what perspective? [Tue Mar 31 16:25:08 2015] or should it be done only for learning purposes [Tue Mar 31 16:25:16 2015] in general, I don't know [Tue Mar 31 16:25:18 2015] if you are using Coq to write proofs, it's 100% OK [Tue Mar 31 16:25:25 2015] because the proof term truly doesn't matter [Tue Mar 31 16:25:43 2015] if you're trying to build high-performance verified software, it *might* be OK, if you really have a good understanding of what the tactic will generate [Tue Mar 31 16:26:05 2015] you can also use tactics to write just plain old code [Tue Mar 31 16:26:33 2015] in that respect, it's generally not OK, since it's easy to create something that type checks but which is incorrect (at least, until you prove enough properties to guarantee the specified behavior) [Tue Mar 31 16:26:39 2015] do you have examples/pointers on using more explicit style? [Tue Mar 31 16:26:50 2015] oh, that's bad [Tue Mar 31 16:26:54 2015] then, I'd rather not do it [Tue Mar 31 16:27:05 2015] don't shy away from tactics, they are part of Coq's power [Tue Mar 31 16:27:29 2015] for example, you write your code in Coq instead of assembly language why? [Tue Mar 31 16:27:36 2015] for the abstractions and reasoning power that assembly lacks [Tue Mar 31 16:27:39 2015] same thing with tactics [Tue Mar 31 16:27:53 2015] abstractions are never wrong, if you apply them correctly [Tue Mar 31 16:28:06 2015] I happen to use tactics to write ordinary functions all the time [Tue Mar 31 16:28:30 2015] when you do, it's helpful to also prove some properties about those functions, so that you confirm you understand what the tactics are doing [Tue Mar 31 16:28:42 2015] (plus, that's just good form all around) [Tue Mar 31 16:28:44 2015] yeah, I understand that it's better to prove things without much effort. I'm just worried that they prevent me from learning more. [Tue Mar 31 16:29:26 2015] possible [Tue Mar 31 16:29:36 2015] I would suggest then playing with both Coq and Agda, that's what I did [Tue Mar 31 16:30:06 2015] but I guess I'll just stick to the sf course for now, then read a few more books before trying to experiment. [Tue Mar 31 16:30:10 2015] yes [Tue Mar 31 16:30:15 2015] don't worry about these details at this stage [Tue Mar 31 16:30:32 2015] get comfortable with tactic-driven proof, and you can always get into the gnarlier stuff later [Tue Mar 31 16:30:44 2015] every tactic you use corresponds to one or more things you could have written manually [Tue Mar 31 16:30:55 2015] okay, thanks for taking the time to discuss this! [Tue Mar 31 16:30:57 2015] destruct is match, induction is recursion, pose is let, etc. [Tue Mar 31 16:31:17 2015] * goes back to Prop.v [Tue Mar 31 16:34:14 2015] I'm sorry if I sounded condescending just then, that wasn't what I meant [Tue Mar 31 16:34:36 2015] not at all! [Tue Mar 31 18:18:49 2015] hmmmm [Tue Mar 31 18:19:00 2015] if i define functions as kinds of relations [Tue Mar 31 18:19:15 2015] then i can prove the existence of uncomputable "functions", cant i? [Tue Mar 31 18:19:28 2015] since relations can be Props instead of computing something [Tue Mar 31 19:15:19 2015] right, CPDT covers this (not that exact example, but something similar) [Tue Mar 31 19:15:45 2015] for example, n / 0 is impossible, but Divide n 0 is clearly expressible [Tue Mar 31 20:05:42 2015] Can anyone tell me why this weird error is happening on line 69? http://pastebin.ubuntu.com/10715511/ If you run it from the top, it should happen there. [Tue Mar 31 20:05:55 2015] (everything after line 69 is junk - ignore it) [Tue Mar 31 20:06:37 2015] Oh wait... What am I saying. [Tue Mar 31 20:06:54 2015] I haven't proven that IHn yet, have I? [Tue Mar 31 20:15:18 2015] (That was more of a statement than a question :P ) [Tue Mar 31 20:23:38 2015] the IHn is a given [Tue Mar 31 20:23:51 2015] what is the error? [Tue Mar 31 20:27:11 2015] johnw: Error: [Tue Mar 31 20:27:14 2015] Tactic failure:Unable to satisfy the rewriting constraints. [Tue Mar 31 20:27:16 2015] Unable to satisfy the following constraints: [Tue Mar 31 20:27:22 2015] followed by EVARS and a bunch of junk [Tue Mar 31 20:27:45 2015] I was destructing rather inducting on l, which I probably didn't want to do, so I changed dthat [Tue Mar 31 20:27:48 2015] but the error persists [Tue Mar 31 20:28:24 2015] It seems that I should be able to use IHn [Tue Mar 31 20:29:12 2015] johnw: full error: http://pastebin.ubuntu.com/10715646/ [Tue Mar 31 20:31:12 2015] I saw something online about environment pollution or something, and that restarting the IDE solved it. So I commented out all my previous theorems (which aren't used up to that point) and restarted the IDE. No dice. [Tue Mar 31 20:31:43 2015] (Also, I'm very new to Coq, so it's possible that the problem is obvious and trivial.) [Tue Mar 31 20:34:25 2015] I've also been trying to apply the above-defined skipn_head, but I'm getting "Error: Unable to find an instance for the variable a." [Tue Mar 31 20:45:11 2015] interesting [Tue Mar 31 20:45:21 2015] you are bringing in the setoid rewriting stuff [Tue Mar 31 20:45:25 2015] is this with 8.4pl5? [Tue Mar 31 20:50:52 2015] johnw: 8.4pl5 on OpenBSD [Tue Mar 31 20:51:04 2015] nothing's happening aside from what you see there [Tue Mar 31 20:51:16 2015] i.e. the command to open coqide is just "coqide" [Tue Mar 31 20:51:28 2015] I've been experiencing it whenever trying to use an IHn [Tue Mar 31 20:51:36 2015] in this code, anyway [Tue Mar 31 20:52:02 2015] again, it could be something very simple. I don't have enough experience to have intuition about the sanity of what I'm doing. [Tue Mar 31 20:52:52 2015] let me try [Tue Mar 31 20:53:23 2015] ok, IHn here is not an equality [Tue Mar 31 20:53:27 2015] it's a relation [Tue Mar 31 20:55:35 2015] I see. So I'd be applying it, right? [Tue Mar 31 20:55:55 2015] yes, or some other lemma dealing with relations [Tue Mar 31 20:55:59 2015] such as transitivity [Tue Mar 31 20:57:44 2015] so, one hint is that you only need induction on l [Tue Mar 31 21:04:21 2015] johnw: thanks [Tue Mar 31 21:04:34 2015] yeah, I've been going at this from about 12 different angles. [Tue Mar 31 21:04:44 2015] I should probably step back for a minute and think about what I'm doing [Tue Mar 31 21:19:47 2015] ccomp: https://gist.github.com/56d9aba91041ef480aab [Tue Mar 31 21:20:33 2015] the generalize dependent is key here [Tue Mar 31 21:26:51 2015] johnw: thanks for that [Tue Mar 31 22:02:09 2015] thanks again johnw, I got the rest of the proof done [Tue Mar 31 22:08:53 2015] great, though I'm not sure I helped with understanding _why_ that was the answer [Tue Mar 31 22:11:04 2015] No problem - I'm looking into that myself. It's easier with Coq, being able to step through [Tue Mar 31 22:11:13 2015] (than it is with something like a static language) [Tue Mar 31 22:11:16 2015] true [Tue Mar 31 22:11:30 2015] which is funny, because people usually criticize Coq proofs for being too opaque :) [Tue Mar 31 22:17:32 2015] I could understand arguing opaqueness in terms of the actual lemmas used at times [Tue Mar 31 22:18:06 2015] i.e. things like auto and intuition can do black magic that demands more faith in Coq than some people are willing to give [Tue Mar 31 22:18:22 2015] but yeah, in terms of understanding proof techniques, I find it pretty clear [Tue Mar 31 22:18:37 2015] it shouldn't demand too much faith [Tue Mar 31 22:18:46 2015] there's the CiC and nothing else, if you don't use vm_compute [Tue Mar 31 22:19:28 2015] hm, I don't know what either of those things mean. Where should I learn? [Tue Mar 31 22:20:12 2015] the Calculus of (Co)Inductive Constructions [Tue Mar 31 22:20:19 2015] is what every Coq term reduces down to [Tue Mar 31 22:20:33 2015] there's a chapter about it in the manual [Tue Mar 31 22:22:05 2015] nice, thanks [Tue Mar 31 22:22:23 2015] it's the only thing you have to trust [Wed Apr 1 08:56:11 2015] OMG [Wed Apr 1 08:56:15 2015] IM READING THE HOTT BOOK [Wed Apr 1 08:56:17 2015] ITS BLOWING MY FUCKING MIND [Wed Apr 1 09:11:02 2015] i dont know any real homotopy [Wed Apr 1 09:11:07 2015] buy [Wed Apr 1 09:11:10 2015] *but [Wed Apr 1 09:11:18 2015] from the little ive encountered [Wed Apr 1 09:11:23 2015] and what this is talking about [Wed Apr 1 09:11:24 2015] omg [Wed Apr 1 09:11:42 2015] fuckin ∞-groupoids and cw complexes and stuff [Wed Apr 1 09:11:47 2015] this is so goddamn cool [Wed Apr 1 09:12:22 2015] johnw: i want to join you in this world of quotients [Wed Apr 1 11:33:33 2015] johnw: pingue! [Wed Apr 1 11:52:40 2015] benzrf::) [Wed Apr 1 11:52:43 2015] notdan: hi [Wed Apr 1 12:38:04 2015] johnw: I remember you were talking about a script for emacs, that helped you battle with some of the ProofGeneral weirdness [Wed Apr 1 12:38:20 2015] yes, it's called my .emacs ;) [Wed Apr 1 12:38:31 2015] https://github.com/jwiegley/dot-emacs [Wed Apr 1 12:38:34 2015] look for "coq" [Wed Apr 1 12:38:35 2015] johnw: in particular, I want to solve a problem when suddenly ProofGeneral decides to open another separate frame [Wed Apr 1 12:38:44 2015] yeah [Wed Apr 1 12:38:51 2015] also check the coq and pg settings in my settings.el [Wed Apr 1 12:39:20 2015] thanks [Wed Apr 1 13:38:37 2015] what is Type False [Wed Apr 1 13:38:41 2015] Void doesnt seem to exist [Wed Apr 1 13:49:34 2015] ah, nvm [Wed Apr 1 13:49:36 2015] btw [Wed Apr 1 13:50:05 2015] is it possible to prove in coq that coconstant morphisms must come from an empty type [Wed Apr 1 13:51:19 2015] im halfway into a proof and just realized that i think i need decidable equality for the codomain of the coconstant morphism [Wed Apr 1 13:51:58 2015] because to get a contradiction from an inhabitant of the domain, i need to produce two allegedly equal functions that map the image of the inhabitant to true and false respectively [Wed Apr 1 13:52:02 2015] but i cant do that w/o decidable equality [Wed Apr 1 13:52:14 2015] have i misphrased or is coconstancy = initiality not provable in coq [Wed Apr 1 13:53:56 2015] brb please respond while im gone :I [Wed Apr 1 13:55:54 2015] er to be clear i mean coconstant /coq/ functions not morphisms in general [Wed Apr 1 13:56:04 2015] right now i have [Wed Apr 1 13:56:06 2015] Definition coconstant {A B} (f : A -> B) : Prop := forall R (g g' : B -> R), compose g f = compose g' f. [Wed Apr 1 13:56:12 2015] Theorem coq_coconstant_initial : forall A, (exists B (f : A -> B), coconstant f) -> (A -> False). [Wed Apr 1 13:56:17 2015] kk gone for real now. sorry for the spam [Wed Apr 1 14:25:25 2015] relrod pasted “CPDT compile fail on 8.4pl5” at http://lpaste.net/129980 [Wed Apr 1 14:25:52 2015] is this a known thing? Is there a workaround? [Wed Apr 1 14:48:55 2015] relrod: the book only says it's tested with 8.4 and 8.4pl1. could be too new [Wed Apr 1 14:49:38 2015] scott: yeah. Works on a friend's box with p3, wondering if there was a regression somewhere. [Wed Apr 1 17:24:25 2015] hmmm... wtf [Wed Apr 1 17:24:30 2015] vec_idx [Wed Apr 1 17:24:33 2015] : vec ?513 ?514 -> forall i : nat, i < ?514 -> ?513 [Wed Apr 1 17:25:00 2015] but if i do Eval simpl in vec_idx vec_nil 10. [Wed Apr 1 17:25:13 2015] it does not complain a bit; rather it produces a giant contradiction term [Wed Apr 1 17:25:17 2015] what the heck? [Wed Apr 1 17:30:53 2015] benzrf: what is the type of vec_nil? `vec A 0` for an implicit A: Type? then you would end up with something of type 10 < 0 -> A which is inhabited [Wed Apr 1 17:31:29 2015] because you can't produce the necessary 10 < 0 proof to get your A, so it's fine [Wed Apr 1 17:33:56 2015] oh [Wed Apr 1 17:33:58 2015] dammit [Wed Apr 1 17:34:01 2015] wait hold on [Wed Apr 1 17:34:15 2015] im pretttty sure that the proof arg is implicit [Wed Apr 1 17:34:34 2015] yeah look: [Wed Apr 1 17:34:40 2015] Coq < Check vec_idx vec_nil 10. [Wed Apr 1 17:34:42 2015] vec_idx vec_nil 10 [Wed Apr 1 17:34:44 2015] : ?534 [Wed Apr 1 17:35:00 2015] and vec_nil [Wed Apr 1 17:35:03 2015] : vec ?536 0 [Wed Apr 1 17:40:23 2015] benzrf: I guess if you tried to use vec_idx vec_nil 10 it would then complain when it tried to resolve the implicit proof or something [Wed Apr 1 17:40:27 2015] I'm not familiar with how implicits work [Wed Apr 1 17:42:05 2015] Definition false: False := vec_idx vec_nil 10. ought not to work at any rate [Wed Apr 1 17:42:30 2015] (modulo any Coq syntax errors I likely made) [Wed Apr 1 17:48:45 2015] yep, Error: Cannot infer the implicit parameter e of vec_idx. [Wed Apr 1 18:11:35 2015] th anks! [Wed Apr 1 18:15:31 2015] could anyone answer the question in this gist? https://gist.github.com/nkaretnikov/0627697c7e2e6ad401c6 [Wed Apr 1 18:16:15 2015] is it because the hypothesis says that I know that both things hold? [Wed Apr 1 18:17:25 2015] so, it's like having two separate hypotheses such that one of them can be applied, but a bit stronger, right? [Wed Apr 1 18:18:17 2015] nkar`: i didnt know you could do that :-o [Wed Apr 1 18:23:07 2015] benzrf: I think my interpretation is correct because I can do this: [inversion IHle as [F G].] [Wed Apr 1 18:23:19 2015] which splits it apart [Wed Apr 1 18:27:18 2015] apply is really more clever than just "apply an hypothesis" indeed. It can do basic tricks like splitting on and to get the correct one [Wed Apr 1 18:27:44 2015] okay [Wed Apr 1 18:27:55 2015] If you have [H : P <-> Q] and have to prove P, you can also do [apply H] to get Q as a goal, for example [Wed Apr 1 18:28:41 2015] I usually unfold such things, is it a good practice? [Wed Apr 1 18:28:54 2015] or do I need to force myself to think in high-level terms? [Wed Apr 1 18:29:25 2015] right now, if I don't see the plumbing, I can't see how to transform a thing. [Wed Apr 1 18:29:56 2015] Honestly, do it your way, you'll move by yourself to higher level tactics if you feel like it [Wed Apr 1 18:30:26 2015] Cypi: could you suggest how to improve the prove in the gist, btw? [Wed Apr 1 18:30:44 2015] I don't like the repetition in SSCases [Wed Apr 1 18:31:02 2015] the only way to get rid of it that I can think of is to define a lemma [Wed Apr 1 18:31:06 2015] Well. The way I would do it now: [eauto with arith] [Wed Apr 1 18:31:09 2015] given the tactics I know [Wed Apr 1 18:31:13 2015] But it might now be satisfying :p [Wed Apr 1 18:31:19 2015] s/now/not [Wed Apr 1 18:31:51 2015] oh, I'm not "allowed" to use anything advanced. [Wed Apr 1 18:32:23 2015] I know, sorry :) [Wed Apr 1 18:32:23 2015] I was asking about re-structuring the proof using the same tactics [Wed Apr 1 18:32:53 2015] heh, please don't say sorry. there's nothing to be sorry about :) [Wed Apr 1 18:34:58 2015] Do you know about eapply or not? [Wed Apr 1 18:35:26 2015] Also, I'm not sure which lemmas you're allowed to use. [Wed Apr 1 18:36:12 2015] I don't know about eapply [Wed Apr 1 18:36:41 2015] nevermind, then. [Wed Apr 1 18:37:11 2015] I'll try on my own. [Wed Apr 1 18:42:24 2015] http://lpaste.net/129989 >> this is a short proof, but I'm pretty sure it uses lemmas that you don't know about. To re-structure your proof...maybe you could prove some lemmas indeed, like [forall n1 n2, n1 < S (n1 + n2)] [Wed Apr 1 18:42:42 2015] (but I guess that's what you were about to do ^^ ) [Wed Apr 1 18:44:40 2015] this is what I meant by using a lemma: https://gist.github.com/nkaretnikov/0627697c7e2e6ad401c6 [Wed Apr 1 18:45:03 2015] I just moved the identical parts out [Wed Apr 1 18:45:25 2015] That's good I think :) [Wed Apr 1 20:01:33 2015] 01:50:05 benzrf │ is it possible to prove in coq that coconstant morphisms must come from an empty type [Wed Apr 1 20:01:44 2015] (morphisms in the Coq category, i mean) [Wed Apr 1 22:19:41 2015] hey johnw are you around? [Wed Apr 1 22:19:53 2015] indeed [Wed Apr 1 22:20:23 2015] hey [Wed Apr 1 22:20:27 2015] On the other hand, consider the law of excluded middle : “for all A , either A or not A .” Inter- preting this in the pure propositions-as-types logic yields a statement that is inconsistent with the univalence axiom. For since proving “ A ” means exhibiting an element of it, this assumption would give a uniform way of selecting an element from every nonempty type — a sort of Hilber- tian choice [Wed Apr 1 22:20:30 2015] operator. Univalence implies that the element of A selected by such a choice operator must be invariant under all self-equivalences of A , since these are identified with self-identities and every operation must respect identity; but clearly some types have automorphisms with no fixed points, e.g. we can swap the elements of a two-element type. [Wed Apr 1 22:20:34 2015] i dont understand this .-. [Wed Apr 1 22:20:57 2015] keep reading, keep thinking [Wed Apr 1 22:25:15 2015] also, maybe draft the problem in pseudo-Coq [Wed Apr 1 22:25:23 2015] and see if you can identify the exact point where you'd run into this trouble [Wed Apr 1 22:28:49 2015] oy [Wed Apr 1 22:29:08 2015] or just read on [Wed Apr 1 22:29:14 2015] it should get clearer as you go [Wed Apr 1 22:29:36 2015] ahh wait i think i might see [Wed Apr 1 22:29:40 2015] is it becaue [Wed Apr 1 22:29:43 2015] *because [Wed Apr 1 22:29:56 2015] any normal instance of an element of some A can be carried along a path [Wed Apr 1 22:29:59 2015] in Coq style Prop proofs, we don't care what the witness is; HoTT does care, and the witness must exhibit certain properties [Wed Apr 1 22:30:00 2015] so it can respect it [Wed Apr 1 22:30:16 2015] but for LEM, since there's no actual way to implement it, there's no way to show how it behaves wrt paths? [Wed Apr 1 22:30:34 2015] yeah, that's on the right track [Wed Apr 1 22:30:39 2015] hmm wait though [Wed Apr 1 22:30:47 2015] wouldnt that cause problems with extra axioms in general [Wed Apr 1 22:31:27 2015] yeah, in the same way that extracting an axiom from Coq into computationally relevant code will cause an assertion if you try to use the code that required that axiom [Wed Apr 1 23:07:12 2015] hh-hhhhuh [Wed Apr 1 23:07:21 2015] huh [Wed Apr 1 23:07:23 2015] o_O [Wed Apr 1 23:07:30 2015] johnw: so... hmm [Wed Apr 1 23:07:46 2015] full types-as-props is not extensible? [Wed Apr 1 23:12:30 2015] god dammit [Wed Apr 1 23:12:51 2015] how do i destruct a member of a type that has a filled-in index [Wed Apr 1 23:12:58 2015] like [Wed Apr 1 23:13:03 2015] vec 3 nat [Wed Apr 1 23:13:31 2015] why does destruct not work? [Wed Apr 1 23:14:25 2015] Error: Abstracting over the terms "n" and "y" leads to a term [Wed Apr 1 23:14:28 2015] "fun (n : nat) (y : vec R n) => [Wed Apr 1 23:14:30 2015] forall x : eu n, tail3 (vec_add x y) = vec_add (tail3 x) (tail3 y)" [Wed Apr 1 23:14:32 2015] which is ill-typed. [Wed Apr 1 23:15:02 2015] perhaps the problem is that i am explicitly using x and y as 'eu 3' [Wed Apr 1 23:15:04 2015] ok, you need to give more context to your statement [Wed Apr 1 23:15:12 2015] show me the type, and the context [Wed Apr 1 23:15:23 2015] you're not *just* destructing a member of that type [Wed Apr 1 23:15:27 2015] there are other constraints in play [Wed Apr 1 23:15:52 2015] http://benzrf.benzrf.com/imgs/2acde0.png [Wed Apr 1 23:16:08 2015] ah crap port forwarding is broken [Wed Apr 1 23:16:11 2015] 1 sec [Wed Apr 1 23:16:34 2015] http://i.imgur.com/IsXcQ91.png [Wed Apr 1 23:17:53 2015] and you are destructing x or y I take it [Wed Apr 1 23:18:43 2015] yeah [Wed Apr 1 23:18:54 2015] which one? [Wed Apr 1 23:22:52 2015] either [Wed Apr 1 23:22:57 2015] they both cause the same error [Wed Apr 1 23:23:19 2015] well, with x and y swapped [Wed Apr 1 23:24:33 2015] which one do YOU want to destruct [Wed Apr 1 23:26:00 2015] both really [Wed Apr 1 23:26:13 2015] i am trying to prove that tail3 is linear [Wed Apr 1 23:26:15 2015] if x, try this: revert y; destruct x. [Wed Apr 1 23:26:48 2015] that does not work [Wed Apr 1 23:26:52 2015] same error? [Wed Apr 1 23:26:57 2015] yep [Wed Apr 1 23:27:13 2015] try this: [Wed Apr 1 23:27:20 2015] Require Import Coq.Program.Equality. [Wed Apr 1 23:27:26 2015] then, use: dependent destruction x. [Wed Apr 1 23:27:47 2015] o_o [Wed Apr 1 23:28:26 2015] it workd =D [Wed Apr 1 23:28:27 2015] what's that? [Wed Apr 1 23:28:38 2015] well, it uses the JMEq axiom, unfortunately [Wed Apr 1 23:28:44 2015] which is harmless, but it's an axiom [Wed Apr 1 23:28:53 2015] whats jmeq [Wed Apr 1 23:28:56 2015] I don't know the non-JMEq way to solve this [Wed Apr 1 23:28:57 2015] google it [Wed Apr 1 23:29:53 2015] rip [Wed Apr 1 23:30:03 2015] so it's heterogeneous/ [Wed Apr 1 23:30:35 2015] johnw: i assume this is another one of the things that's fixed in hott :p [Wed Apr 1 23:30:55 2015] conor has a new blog post on that [Wed Apr 1 23:31:34 2015] https://pigworker.wordpress.com/2015/04/01/warming-up-to-homotopy-type-theory/ [Wed Apr 1 23:32:57 2015] nice! thanks copumpkin [Wed Apr 1 23:37:37 2015] coo [Wed Apr 1 23:37:40 2015] l [Wed Apr 1 23:53:48 2015] someday [Wed Apr 1 23:53:59 2015] someday i will understand the words when conor mcbride talks [Wed Apr 1 23:54:09 2015] someday i will go on nlab and read a page and understand it [Wed Apr 1 23:54:16 2015] this, i believe [Thu Apr 2 00:08:40 2015] night [Thu Apr 2 03:21:50 2015] benzrf: Conor McBride has some pretty accessible talks. They had one on Agda(?) that was great! [Thu Apr 2 03:22:25 2015] Conor does oodles of cool type theory stuff it seems. [Thu Apr 2 09:12:30 2015] hmm [Thu Apr 2 09:13:10 2015] there must be some way to invent a UI that lets you generate coqish formal proofs by reasoning using common notation [Thu Apr 2 09:13:20 2015] ok that was phrased poorly [Thu Apr 2 09:14:02 2015] but i mean like the way in semiformal math sequences are commonly indicated with some kind of [foo, bar...] and then people reason about them more straightforwardly w/ less induction [Thu Apr 2 09:14:20 2015] i dunno [Thu Apr 2 09:14:35 2015] er, the elipses is what i was talking about, in case that was unclear [Thu Apr 2 11:36:47 2015] can anyone answer a beginner question? i saw a proof that destructed a variable (m) before it was introduced. does destruct m implicitly intro m? [Thu Apr 2 11:37:09 2015] yes, it has the same effect [Thu Apr 2 11:37:25 2015] thank you lolisa. [Thu Apr 2 11:37:28 2015] but, if there is another variable before n, it will be intros. [Thu Apr 2 11:38:02 2015] ah ok. so if you have variables x y z and you destruct z, all three will be introd [Thu Apr 2 11:38:05 2015] Some time, you don't want that because you need to do induction. Use generalize dependent to unput it to the goal [Thu Apr 2 11:38:11 2015] Yep. [Thu Apr 2 11:38:38 2015] thanks. im just working through the SF chapter where they introduce generalize dependent. not quite there yet though. [Thu Apr 2 11:39:12 2015] I have a few solution on it on github.com/lolisa/Coq_code :) feel free to take a look [Thu Apr 2 11:39:49 2015] thanks. i have been trying not to take peeks, but plus_n_n_injective definitely tripped me up. [Thu Apr 2 11:40:18 2015] try omega :) It will probably solve the equation [Thu Apr 2 11:40:45 2015] so i looked and found a solution where they delayed introducing the hypothesis until after destructing m, and, im still not sure i totally grasp that. [Thu Apr 2 11:40:56 2015] not going to use omega. :) i need to understand this stuff. [Thu Apr 2 11:41:14 2015] A general tip is, try to put as much stuff into the goal before you do induction, so your hypothesis will be more powerful. [Thu Apr 2 11:41:46 2015] by put do you mean 'keep'? [Thu Apr 2 11:41:59 2015] :) of course I am kidding about omega. [Thu Apr 2 11:42:02 2015] Nope. [Thu Apr 2 11:42:06 2015] by that i mean, doesn't everthing start in the goal? [Thu Apr 2 11:42:26 2015] Yes, but you can put thing back in the goal. [Thu Apr 2 11:42:47 2015] ah. ok. so you literally mean put it back with GD [Thu Apr 2 11:42:52 2015] Basically, intros is reversible by generalize dependent, so you don't need to worry about not introing all the time [Thu Apr 2 11:43:51 2015] But if keeping it is a option, use it :) generalize dependent is a lot of finger work, and it is unnecessary some time [Thu Apr 2 11:44:54 2015] ok. it will take some practice to get used to that, im sure. [Thu Apr 2 11:47:07 2015] anyway, thank you lolisa. this was definitely helpful. [Thu Apr 2 11:47:47 2015] follow me on github than DAZE =w= [Thu Apr 2 11:48:21 2015] BTW I have quora account marisa kirisame, If you have more problem you can always PM me :) [Thu Apr 2 11:49:04 2015] ok thank you, very nice of you. [Fri Apr 3 04:30:05 2015] I'm new to coq and I'm using it with proof general. however I have the problem that if I put my cursor after "Qed." and press C-c C- the goal doesn't disappear. Only after pressing that three times it disappears. Manually going through each step with C-c C-n works fine. (sorry if this is the wrong channel for that kind of question, I didn't find one for proof general) [Fri Apr 3 05:35:28 2015] interestingly that seem to only happen if I first eval the theorem and then the proof. If I do both at the same time C-c C-RET works fine [Fri Apr 3 08:49:45 2015] is there any difference in Coq between: a) putting some definitions in module A and then importing them into module B and [Fri Apr 3 08:50:05 2015] copy-pasting definitions from module A intpo module B instead of importing? [Fri Apr 3 08:52:43 2015] ok, I'll put it differently, because I just verified that there IS a difference between the two [Fri Apr 3 08:52:49 2015] and now the question is why? [Fri Apr 3 11:46:09 2015] Haskellfant: that's just the display not updating. It's nothing to worry about. [Fri Apr 3 11:48:05 2015] jstolarek: copy/paste is like an [Include], rather than an [Import] or [Export]. You are probably looking for [Export]. There are three things you might want to do with names in module [A]: you may want to make them available without having to type [A.] before each (this is [Import]), you may want to make them available without having to type [A.] before each to both this module, and any module that imports this one ([Export]), or you may want [Fri Apr 3 11:48:05 2015] to give them new names, replacing [A.] with [B.] ([Include]) [Fri Apr 3 14:34:09 2015] I'm having a little trouble figuring out {how to,whether I can} prove a Fixpoint's guardedness manually. It's non-trivial, but it's definitely correct and making it more obvious seriously complicates the entire program [Fri Apr 3 14:37:10 2015] ccomp: yes you can do that. sometimes it's called "general recursion" if you're trying to google for it. there are several different approaches with different trade-offs. I would recommend looking at the [Program] facility first. [Fri Apr 3 14:37:13 2015] I just found page 401 of the manual, which seems relevant [Fri Apr 3 14:37:33 2015] also if you can say a bit more what you're trying to do, people may be able to make suggestions [Fri Apr 3 14:38:07 2015] I'm trying to represent a simple virtual machine's state in a record. It can only step forward, so it reduces on the list of remaining instructions with each eval step [Fri Apr 3 14:45:00 2015] ccomp: and the instr list is one of the fields of the record? [Fri Apr 3 14:45:11 2015] jrw: yeah [Fri Apr 3 14:45:14 2015] I see [Fri Apr 3 15:12:04 2015] jgross: ok thanks [Fri Apr 3 16:25:03 2015] so I've been playing with http://stackoverflow.com/a/24827255/3945 (simple graph theory), but I've been stuck trying to define degree, halp? [Fri Apr 3 16:28:11 2015] I keep on trying to find the cardinality of a Type, which I think is impossible? [Fri Apr 3 16:28:24 2015] yes [Fri Apr 3 16:29:18 2015] how about implement a graph as a list of nodes and a list of edges [Fri Apr 3 16:29:33 2015] then you can compute degree [Fri Apr 3 16:30:08 2015] Yes I should've mentioned I have an implementation of degree where I use sets/lists for verticies/edges [Fri Apr 3 16:30:10 2015] (given decidable equality on node names) [Fri Apr 3 18:33:28 2015] is there a way to print a theorem as it was stated and proved rather than a sequence of lambdas? [Fri Apr 3 19:02:09 2015] nkar`: i wanna say that coq throws that info away [Fri Apr 3 19:02:29 2015] nkar`: like asking for the expression that generated a value, in haskell [Fri Apr 3 19:02:45 2015] im might be worng, idk [Fri Apr 3 21:20:32 2015] nkar`: it doesn't record the tactics used [Sat Apr 4 01:42:12 2015] johnw, benzrf: thanks! [Sat Apr 4 03:13:42 2015] could anyone answer the question in this gist? https://gist.github.com/nkaretnikov/2619738cbb12dca66a4a [Sat Apr 4 03:15:04 2015] that is, why is it possible to apply [H : ble_nat 0 (S m') = true] to this goal: [ble_nat 0 m' = true]? is it because forall (n : nat), 0 <= n? [Sat Apr 4 03:35:14 2015] nkar`` : I don't have the definition of ble_nat, but I guess reflexivity would be enough to conclude? [Sat Apr 4 03:35:31 2015] apply does do a little bit more than applying ^^ [Sat Apr 4 03:50:07 2015] Cypi: you're right [Sat Apr 4 03:50:15 2015] thanks! [Sun Apr 5 02:16:20 2015] How can I add LoadPath in Coq by changing coqc command? [Sun Apr 5 02:26:06 2015] -I. I get it. [Sun Apr 5 02:26:40 2015] But I am having trouble with trying to define the Cat category. It tell me that universe is inconsistent. What can I do? [Sun Apr 5 02:26:49 2015] The term "Category" has type "Type@{max(Category.2+1, Category.3+1)}" [Sun Apr 5 02:26:50 2015] while it is expected to have type "Type@{Category.2}". [Sun Apr 5 02:28:55 2015] It turn out I need polymorphism in both CatCategory and Category. Fix it. [Sun Apr 5 04:28:05 2015] Hi everyone, are there any documentation stating the new features in Coq 8.5 beside the changelog? [Sun Apr 5 04:29:21 2015] there's https://coq.inria.fr/coq-85 [Sun Apr 5 04:30:23 2015] Yes, that's where I get the source and build coq from... [Sun Apr 5 04:30:36 2015] It gives a list of major new things there [Sun Apr 5 04:30:41 2015] I'm not sure what you're looking for :) [Sun Apr 5 04:31:07 2015] I'm more of looking of a guide with example stating how Coq 8.5 will change our live [Sun Apr 5 04:33:05 2015] For example Bjarne Stroustrup made a PPT showing how features of C++11 give benefit of programmer... In short I am looking for https://coq.inria.fr/distrib/V8.5beta1/CHANGES with bunch of examples... [Sun Apr 5 04:43:57 2015] i <3 coq [Sun Apr 5 04:43:58 2015] ty [Sun Apr 5 04:44:05 2015] france [Sun Apr 5 10:22:44 2015] Hi guys, I'd read the CHANGES and I wonder, if I wanted to do an introduction to coq 8.5, how many will be interested? :) [Sun Apr 5 13:55:23 2015] hello. I'm using coqide and I'd like it to show a list of all the theorems I've proved so far. Is this something coqide can do? [Sun Apr 5 20:43:56 2015] BTW are there log on here? [Sun Apr 5 22:22:49 2015] i log [Sun Apr 5 22:23:03 2015] lolisa: ^ [Sun Apr 5 22:23:41 2015] Where is i log? Do you just mean you keep the log on your laptop? [Sun Apr 5 22:24:51 2015] I think it'd be great if we setup something like botbot.me, but I am not the op... [Sun Apr 5 23:27:55 2015] I find the documentation very hard to understand. Can somebody briefly explain the inversion and discriminate tactics? [Sun Apr 5 23:28:51 2015] discriminate prove the goal if there is a a = b hypothesis, where a and b has different constructor [Sun Apr 5 23:29:11 2015] What do you mean different constructor? [Sun Apr 5 23:29:17 2015] inversion... it sort of do the inverse of constructor tactic [Sun Apr 5 23:29:26 2015] constructor in Algebraic Data Type [Sun Apr 5 23:29:34 2015] I don't think I know what a constructor is [Sun Apr 5 23:29:35 2015] like S is a constructor and O is a constructor [Sun Apr 5 23:29:40 2015] Okay [Sun Apr 5 23:30:08 2015] So in short, discriminate will prove anything if there exists a equality that is obviolusly false, like true = false, O = S n [Sun Apr 5 23:30:20 2015] Ah, right. That's what I thought [Sun Apr 5 23:30:37 2015] I've just seen "exact" used as well [Sun Apr 5 23:30:52 2015] In a proof I just did, I ended up with: `H_more_absurd_left : False` as an assumption [Sun Apr 5 23:31:00 2015] then did `exact H_more_absurd_left.` [Sun Apr 5 23:31:09 2015] I suppose it would have been nicer to use discriminate? [Sun Apr 5 23:31:34 2015] I don't know... But I think discriminate only work on equality [Sun Apr 5 23:32:32 2015] Oh wait, no, that was inversion I saw worked [Sun Apr 5 23:32:35 2015] kba: you could also have done 'contradiction' [Sun Apr 5 23:32:37 2015] inversion H_more_absurd_left. [Sun Apr 5 23:32:39 2015] finishes my goal [Sun Apr 5 23:33:06 2015] lolisa: if I go a step back, I have `H_more_absurd_left : e = S e`. [Sun Apr 5 23:33:20 2015] That is an equality with different constructors, right? [Sun Apr 5 23:33:25 2015] not quite [Sun Apr 5 23:33:29 2015] e is not a constructor [Sun Apr 5 23:33:29 2015] what is e? [Sun Apr 5 23:33:35 2015] if e is a constructor, yes. [Sun Apr 5 23:33:42 2015] inversion solves that goal because it discovers that there are no possible goals remaining [Sun Apr 5 23:33:43 2015] if e is an unknown stuff, no. [Sun Apr 5 23:33:51 2015] It's not, it's a natural number [Sun Apr 5 23:33:55 2015] oh, right, constructors can be lower case in Coq [Sun Apr 5 23:34:08 2015] than it is not a constructor. [Sun Apr 5 23:34:22 2015] I still don't understand exactly what a constructor is, other than O and S, as you said [Sun Apr 5 23:34:58 2015] But couldn't I use discriminate in my case, then? [Sun Apr 5 23:35:00 2015] Somehow? [Sun Apr 5 23:35:05 2015] Or should I just use `exact`? [Sun Apr 5 23:35:15 2015] constructor is what you define when you define an "Inductive" [Sun Apr 5 23:35:32 2015] Okay [Sun Apr 5 23:35:44 2015] When you define Inductive x, you state how you can get values of x, that's a constructor [Sun Apr 5 23:39:49 2015] So when you say 'different constructor' you just mean they aren't 'constructed the same way' in the type and are therefore not equal? [Sun Apr 5 23:39:59 2015] Yes. [Sun Apr 5 23:40:05 2015] the constructor for "e" and "S e" won't be equal then [Sun Apr 5 23:40:09 2015] since e is a natural number [Sun Apr 5 23:40:38 2015] Because when you do match x with ..., x is split into a few constructor. different constructor are inherently different [Sun Apr 5 23:40:45 2015] e is not a constructor. [Sun Apr 5 23:41:09 2015] isn't e just a wrapper for (S (S ... (S O) ... )) [Sun Apr 5 23:41:15 2015] a natural number is a variable, not a constructor. You cannot match O, but you can match e. [Sun Apr 5 23:41:25 2015] hm [Sun Apr 5 23:41:40 2015] Do you know e is O or S _ without looking at e = S e? [Sun Apr 5 23:42:09 2015] I just know that e is a natural number [Sun Apr 5 23:42:21 2015] so I know that e is O surrounded by some number of S's [Sun Apr 5 23:42:47 2015] Yes, but if the number is 0 it isn't surronded by any at all [Sun Apr 5 23:42:58 2015] but O is a constructor, too, you said [Sun Apr 5 23:44:24 2015] Yes, but we don't know e is O or S. [Sun Apr 5 23:44:49 2015] We still know they have different constructors, no? [Sun Apr 5 23:44:50 2015] The rule of thumb of determining a constructor is to just print it's type and see what it has to construct it. [Sun Apr 5 23:45:11 2015] "Print nat."? [Sun Apr 5 23:45:13 2015] Yes, but discriminate don't. [Sun Apr 5 23:45:16 2015] Yes. [Sun Apr 5 23:45:32 2015] It give you S and O, and that's the only two constructor of nat. No more. [Sun Apr 5 23:46:14 2015] So is it because we could only do this if e = 0? [Sun Apr 5 23:46:21 2015] Because (S (S 0)) isn't a constructor? [Sun Apr 5 23:46:24 2015] Or what do you mean? [Sun Apr 5 23:46:33 2015] It has to be the "base types", not a combination of many S's? [Sun Apr 5 23:46:51 2015] becuase if e = 0, then it would say O = S O. And then we could discriminate? [Sun Apr 5 23:47:03 2015] Then we can discriminate. [Sun Apr 5 23:47:20 2015] Hm, ok. I get it [Sun Apr 5 23:47:25 2015] S (S 0) is a constructor. [Sun Apr 5 23:47:35 2015] Wait. [Sun Apr 5 23:47:43 2015] But then wh isn't (S e)? [Sun Apr 5 23:47:52 2015] e is just a series of (S (S 0)) [Sun Apr 5 23:48:02 2015] and all of those would be constructors, too [Sun Apr 5 23:48:05 2015] because we don't know the exact of e. [Sun Apr 5 23:48:16 2015] So we can't know if e = S e? [Sun Apr 5 23:48:23 2015] is it because it doesn't see the relation between S e and e? [Sun Apr 5 23:48:34 2015] Could it be saying "x = S y"? [Sun Apr 5 23:48:40 2015] and it would have the same understanding? Is that the problem? [Sun Apr 5 23:48:53 2015] It doesn't realize that obviously: e != S e [Sun Apr 5 23:48:59 2015] Wait... I think S (S O) isn't one... I mess it up [Sun Apr 5 23:49:22 2015] okay [Sun Apr 5 23:49:24 2015] Either way, I get the idea [Sun Apr 5 23:49:44 2015] So what about inversion? [Sun Apr 5 23:50:24 2015] If you don't mind explaining that, too? ;) [Sun Apr 5 23:50:24 2015] I don't really know how it exactly work. I just use it and get the hang of it. [Sun Apr 5 23:50:40 2015] Sorry:) [Sun Apr 5 23:50:51 2015] So how do you use it? [Sun Apr 5 23:50:59 2015] I don't need a deep understanding, I just don't have any idea how it works [Sun Apr 5 23:51:32 2015] I'm amazed that some people can actually get good at this language with the documentation as it is [Sun Apr 5 23:51:39 2015] https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#sec435 this tells me absoluetly nothing [Sun Apr 5 23:52:01 2015] Well... Go look at Coq Art then, I learn all of it from Coq Art... [Sun Apr 5 23:52:40 2015] http://www.labri.fr/perso/casteran/CoqArt/ This one? [Sun Apr 5 23:53:29 2015] Oh it's a book [Sun Apr 5 23:53:42 2015] My eyes are bleeding [Sun Apr 5 23:54:08 2015] Yes. [Sun Apr 5 23:54:16 2015] SoftwareFoundation is also Good. [Sun Apr 5 23:54:17 2015] http://www-verimag.imag.fr/~monin/Proof/SmallInvScalesUp/paper.pdf <- description of a way to write an inversion tactic, roughly [Sun Apr 5 23:54:41 2015] If you believe you are a genius or maschoist, try Certificated Programming with Dependent Type [Sun Apr 5 23:56:02 2015] thanks both, I'll have a look at http://www.cis.upenn.edu/~bcpierce/sf/current/MoreCoq.html#lab162 for starters [Mon Apr 6 01:34:27 2015] When does associativity of append make sense? I mean app_assoc exists and https://cseweb.ucsd.edu/groups/tatami/kumo/exs/list/page1.html also makes it a thing? [Mon Apr 6 01:34:30 2015] Why is it a thing? [Mon Apr 6 01:34:39 2015] There is no operator between list elements per say [Mon Apr 6 01:35:27 2015] It's not like multiplication or something where two elements operator or another. Or... They do, but they just turn into a new list with the two same elements [Mon Apr 6 01:35:38 2015] I don't know what kind of answer I'm expecting to this question, admittedly [Mon Apr 6 01:36:02 2015] It just seems odd to talk about associativity list append at all [Mon Apr 6 06:46:55 2015] hi, I tried to install Coq on Yosemite - the homebrew version of Coq did not include CoqIde - so I installed through the .dmg, and it doesn't work... [Mon Apr 6 06:47:44 2015] ah, now I got it working... [Mon Apr 6 06:55:06 2015] so, I'm gonna start simple - and prove some properties of eulers graph theorems... are there some relevant proofs I can look at? [Mon Apr 6 06:55:26 2015] I need to define the graph type, the edge type, odd/even, and do quite a bit of induction... [Mon Apr 6 07:22:17 2015] Hi, what is the best way to represent a set a objects ? (a set of vectors for example) [Mon Apr 6 07:22:26 2015] (a finite set) [Mon Apr 6 07:23:36 2015] Mathematically, it would be a cartesian product (E * E ... * E), but I don't know if it possible to define such product in coq (i.e. more that ? [Mon Apr 6 07:23:50 2015] (i.e. more than a couple)* [Mon Apr 6 07:43:23 2015] kba: you care because list append is a monoid operator [Mon Apr 6 07:43:24 2015] http://fsharpforfunandprofit.com/posts/monoids-without-tears/ [Mon Apr 6 08:05:20 2015] Choups314, sets are in std lib [Mon Apr 6 08:05:32 2015] Just look them up (I don't know much [Mon Apr 6 08:06:37 2015] In fact, I don't know what is the best : use a type [nat->E] (like a sequence) and an hypothesis that states this sequence has a finite number of objects, or either a list of object [list E] ... [Mon Apr 6 08:07:47 2015] Either assume there's difference in ordering and didn't say any thing about repeat elements. [Mon Apr 6 12:42:22 2015] i UNDERSTAND [Mon Apr 6 12:44:40 2015] what do you understand benzerf? [Mon Apr 6 14:06:46 2015] johnw: i do not know that i have been pingd if u misspell :( [Mon Apr 6 14:07:24 2015] johnw: and that was a mis-send; i meant for ##math (i understoood that möbius strips are fiber bunndles) [Tue Apr 7 09:37:29 2015] How can I specify a type universe in my code? [Tue Apr 7 09:38:28 2015] notdan: hmm interesting [Tue Apr 7 09:38:34 2015] there'd need to be a special syntax for it wouldnt there [Tue Apr 7 09:45:22 2015] Yeah. There is a special syntax for printing, but I cannot find special syntax for the input [Tue Apr 7 09:46:15 2015] On a semi-related note, I have a question about a piece of code that I have. http://lpaste.net/4986409841850318848 [Tue Apr 7 09:46:43 2015] Am I correct to say that [Fin n] has exactly n (canonical) elements? [Tue Apr 7 09:47:00 2015] And also: why won't [fmax] or [fmax'] typecheck? [Tue Apr 7 09:47:17 2015] I guess I need some sort of theorem to say that (Fin n+1) = Unit + Fin n [Tue Apr 7 11:12:43 2015] uh I think I know what is the problem [Tue Apr 7 11:17:20 2015] notdan: you cannot give a specific universe index [Tue Apr 7 16:01:27 2015] What is the difference between a Set and a Type? [Tue Apr 7 16:07:11 2015] kba: universes, i think [Tue Apr 7 16:07:26 2015] How comfortable are you with the universe hierarchy? [Tue Apr 7 16:07:52 2015] hmm [Tue Apr 7 16:08:02 2015] a function from a value to its type couldnt have a valid type, right? [Tue Apr 7 16:08:32 2015] You mean a function that takes any value and return its type? [Tue Apr 7 16:08:37 2015] yeah [Tue Apr 7 16:08:53 2015] that's a notion put forth by "dynamically typed languages" [Tue Apr 7 16:09:07 2015] a "type" in the type theory sense is only static. [Tue Apr 7 16:09:19 2015] there is no run time representation of a type. [Tue Apr 7 16:09:41 2015] [Definition f {X : Type} (x : X) : Type := X.] [Tue Apr 7 16:09:43 2015] There you go :-° [Tue Apr 7 16:11:09 2015] Okay, sure. An uninspectable thing. I'm talking more like Inductive Type_representation : Type := pi_type : blah | inductive_type : blah ... [Tue Apr 7 16:48:30 2015] benzrf: what is a universe? [Tue Apr 7 16:48:57 2015] alkabetz: I don't know what universes are in this sense [Tue Apr 7 16:50:15 2015] kba: type of types kinda [Tue Apr 7 16:50:25 2015] kba: the problem is that if there exists a term T such that T : T [Tue Apr 7 16:50:32 2015] then you have paradoxes oh boy [Tue Apr 7 16:50:42 2015] so coq, at least, uses infinite regress [Tue Apr 7 16:51:09 2015] if you use `Check Type.' it may /claim/ that `Type : Type', but the 2nd `Type' is actually not the same as the first [Tue Apr 7 16:51:17 2015] it's a universe higher [Tue Apr 7 16:51:25 2015] then the type of THAT `Type' is one higher [Tue Apr 7 16:51:26 2015] etc [Tue Apr 7 16:51:42 2015] you can turn on explicit printing of which universe an occurence of `Type' means [Tue Apr 7 16:52:01 2015] So it should say Type : SuperType, but it says Type : Type. [Tue Apr 7 16:52:10 2015] well [Tue Apr 7 16:52:14 2015] But what about Set, then? Set says 'Set : Type'. Should that be 'Set : SuperType', too? [Tue Apr 7 16:52:18 2015] then it'd be SuperType : SuperSuperType [Tue Apr 7 16:52:22 2015] or is a Set in fact a subset of Type? [Tue Apr 7 16:52:24 2015] kba: no! if i recall correctly [Tue Apr 7 16:52:29 2015] Set is like the lowest Type [Tue Apr 7 16:52:32 2015] kba: you mean an inhabitant? [Tue Apr 7 16:52:46 2015] I'm wondering if Sets are a subset of Types [Tue Apr 7 16:52:49 2015] 1 : nat, nat : Set, Set : Type, Type : Type1, Type1 : Type2, ...? [Tue Apr 7 16:52:53 2015] Types are stratified, liek benzrf said. So you have Type.1 : Type.2, then Type.2 : Type.3 and so on [Tue Apr 7 16:52:58 2015] and Set = Type.0 [Tue Apr 7 16:52:58 2015] Coq < Set Printing Universes. [Tue Apr 7 16:53:02 2015] Coq < Check Type. [Tue Apr 7 16:53:04 2015] Type (* Top.1 *) [Tue Apr 7 16:53:06 2015] : Type (* (Top.1)+1 *) [Tue Apr 7 16:53:08 2015] Coq < Check Set. [Tue Apr 7 16:53:10 2015] Set [Tue Apr 7 16:53:12 2015] : Type (* (Set)+1 *) [Tue Apr 7 16:53:26 2015] RchrdB: yeah [Tue Apr 7 16:54:53 2015] Okay, I'll be a bit more concrete... I wrote a definition of a monoid which takes a type. Now I've gotten some feedback and I'm being told that according to the literature I'm using, that's talking about monoids as sets [Tue Apr 7 16:54:58 2015] but I'm representing them as types [Tue Apr 7 16:55:02 2015] and I'm being asked to justify that [Tue Apr 7 16:55:28 2015] and, well, I don't know how this talk about universes is helping me here. [Tue Apr 7 16:55:36 2015] I still don't know the relation between sets and types [Tue Apr 7 16:56:54 2015] For instance, I'm using nat somewhere as a type [Tue Apr 7 16:57:01 2015] But when I do "Check nat.", it says "nat : Set" [Tue Apr 7 16:57:16 2015] Set is basically the same as Type.0 [Tue Apr 7 16:57:22 2015] What does Type.0 mean? [Tue Apr 7 16:57:37 2015] Is that the "first" Type? [Tue Apr 7 16:57:58 2015] If so, that would mean when I write "(T : Type)" in my definition, that is actually a Set? [Tue Apr 7 16:58:57 2015] Okay, so Set : Type. [Tue Apr 7 17:00:49 2015] So. In Coq, there are universes. [Tue Apr 7 17:01:02 2015] These universes are Prop and Type.n for any natural number n [Tue Apr 7 17:01:10 2015] Let put Prop aside for now [Tue Apr 7 17:01:32 2015] We have the property that Type.n is of type Type.(n+1) [Tue Apr 7 17:01:53 2015] and also that if (t : Type.n), then (t : Type.m) for any m ≥ n [Tue Apr 7 17:02:03 2015] Now, Set is just Type.0 [Tue Apr 7 17:02:40 2015] Right, so like inheritance in OO programming languages [Tue Apr 7 17:02:45 2015] When you write (T : Type) in your definition, the type-checker will actually build something like (T : Type.n) [Tue Apr 7 17:02:56 2015] where n is some unspecified natural number [Tue Apr 7 17:04:11 2015] Now, for your original question. The first one, you were talking about Set and Type, which are Coq universes. In the second one, you were talking about sets and types, which can be mathematical or computer science word. Which are you asking about? [Tue Apr 7 17:04:27 2015] But how can Set be Type.0? If nat is a type of Set [Tue Apr 7 17:04:49 2015] Then if Set = Type.n and nat = Type.m, n >= m [Tue Apr 7 17:04:50 2015] I didn't say that all types were either Prop or Type.n [Tue Apr 7 17:05:06 2015] but if nat is a set, and set is a Type, then nat should be a Type, too [Tue Apr 7 17:05:20 2015] You don't have nat = Type.m for any m [Tue Apr 7 17:05:29 2015] Hm, ok [Tue Apr 7 17:05:39 2015] Why not? Does this universe thing only apply to Type and Set? [Tue Apr 7 17:07:34 2015] Prop, Type and Set are the kinds of Coq. That is, "the types of types" [Tue Apr 7 17:07:58 2015] you could say that Set and Prop are at level 0, and Type[n] is at level n+1, only you only see the 'n' if you enable Set Printing Universes [Tue Apr 7 17:08:11 2015] (universe levels, that is) [Tue Apr 7 17:35:18 2015] is it possible to get from `n <= m' to `S n <= S m' w/o using induction or a lemma. [Tue Apr 7 17:35:53 2015] you mean, in the goal? [Tue Apr 7 17:38:25 2015] it has to be done using induction [Tue Apr 7 17:38:43 2015] vanila: thought so [Tue Apr 7 17:38:46 2015] ok! [Tue Apr 7 17:38:52 2015] the le data type only has a constructor for base case and n <= m -> n <= S m [Tue Apr 7 17:38:58 2015] yeah [Tue Apr 7 18:02:08 2015] is there a way to define a structure similar to a haskell record such that some fields of the record must satisfy certain properties? for example, given a record (using Haskell syntax) data Foo = Foo { one :: (String, Double), two :: (String, Double), three :: (String, Double) }, I want to make sure that the 'Double' in 'three' is always the sum of 'Double's in 'one' and 'two'. is it possible? [Tue Apr 7 18:03:10 2015] Inductive Foo : Set := Foo : forall (one : Double) (two : Double) (three : Double), one + two = three -> Foo [Tue Apr 7 18:03:39 2015] vanila: note that I also want to store a string [Tue Apr 7 18:03:58 2015] vanila: would it be something like snd one + snd two = snd three -> Foo [Tue Apr 7 18:03:59 2015] ? [Tue Apr 7 18:04:08 2015] yeah [Tue Apr 7 18:07:22 2015] vanila: is it possible to "lift" string values to the type level, so I don't need to pass them when constructing 'Foo'? for example, in pseudocode, data Foo = Foo { one :: ("one", Double), two :: ("two", Double), three :: ("three, Double) }? [Tue Apr 7 18:07:44 2015] hi, http://pastebin.com/EHPqfFp5 - in Proof General, I get "Wrong type argument: characterp, \," - how do I find out what's wrong? [Tue Apr 7 18:07:48 2015] I'm pretty new to Coq [Tue Apr 7 18:07:49 2015] im not sure what you mean to do with that [Tue Apr 7 18:07:50 2015] forgot the quote, but that's not the point [Tue Apr 7 18:08:41 2015] vanila: I want to make sure that the string value is never changed, but I still need it for documentation purposes, and for pretty-printing later [Tue Apr 7 18:09:52 2015] vanila: does my explanation help, or do I need to rephrase? [Tue Apr 7 18:11:40 2015] i don't know how to do that [Tue Apr 7 18:11:55 2015] vanila: in haskell, I could do it with a smart-constructor that sets the right string values, which is exposed instead of 'Foo', but that's not what I want [Tue Apr 7 18:14:19 2015] I'm getting "Error: Cannot find library CpdtTactics in loadpath" when I run make in cpdt/ [Tue Apr 7 18:16:30 2015] Added 'Add LoadPath "src".' to DepList.v [Tue Apr 7 18:17:25 2015] vanila: thanks for your help [Tue Apr 7 18:21:15 2015] hm [Tue Apr 7 18:21:26 2015] xeno, I was able to load your whole file, it gives 42 as the result [Tue Apr 7 18:21:36 2015] in proof general inside emacs [Tue Apr 7 18:21:43 2015] vanila: in proof general? how do you run it? [Tue Apr 7 18:21:47 2015] I'm not sure what's wrong... [Tue Apr 7 18:22:12 2015] if I just click "Use" to load the whole file [Tue Apr 7 18:22:14 2015] vanila: I did "use buffer", and "next step" - both gave the same error [Tue Apr 7 18:22:23 2015] vanila: what's the coq equivalent of the Double type? [Tue Apr 7 18:22:39 2015] maybe you have a broken version of proof general - you could try to get the version from the site maybe [Tue Apr 7 18:22:51 2015] vanila: I got it from the site [Tue Apr 7 18:22:58 2015] vanila: it's on OS X [Tue Apr 7 18:23:02 2015] sorry im a bit out of ideas then [Tue Apr 7 18:23:31 2015] I guess I'll just go for CoqIDE then - unless there are other viable options? [Tue Apr 7 18:23:54 2015] you could try coqtop [Tue Apr 7 18:24:03 2015] but an ide/editor is much better [Tue Apr 7 18:24:34 2015] I'll check if the eclipse support works [Tue Apr 7 18:25:07 2015] "characterp" sounds like elisp [Tue Apr 7 18:25:26 2015] do you have other emacs modes that might be interacting with proof general? [Tue Apr 7 18:25:47 2015] hmm this could be a problem with mac [Tue Apr 7 18:25:55 2015] http://proofgeneral.inf.ed.ac.uk/trac/ticket/496 [Tue Apr 7 18:26:13 2015] you could try to disable show-paren-mode? random guess [Tue Apr 7 18:26:23 2015] xeno: I'd suggest commenting out stuff in your .emacs and see if it'd make a difference [Tue Apr 7 18:26:54 2015] yeah, I had some problems with show-paren-mode too [Tue Apr 7 18:26:59 2015] but the error was different, iirc [Tue Apr 7 18:28:04 2015] I run it through coqtop, and then it works fine [Tue Apr 7 18:29:29 2015] well, re-read what vanila said [Tue Apr 7 18:29:47 2015] it's something with your emacs configuration [Tue Apr 7 18:29:53 2015] probably with show-paren-mode [Tue Apr 7 18:30:01 2015] vanila: not really, it's just a plain freshly installed emacs [Tue Apr 7 18:30:25 2015] my .emacs has only 2 statements, both coq-related [Tue Apr 7 18:30:45 2015] hopefully someone who uses mac can give some input [Tue Apr 7 18:30:48 2015] for example, I had these settings in .emacs: (show-paren-mode 1) (setq show-paren-delay 0), which caused this error: Error running timer `show-paren-function': (wrong-type-argument characterp nil) [Tue Apr 7 18:30:48 2015] [Tue Apr 7 18:31:14 2015] vanila: could you please answer my question regarding the Double type? [Tue Apr 7 18:31:20 2015] no [Tue Apr 7 18:31:28 2015] you don't know the answer? [Tue Apr 7 18:31:32 2015] yes [Tue Apr 7 18:31:44 2015] unfortunate [Tue Apr 7 18:34:19 2015] vanila: show-paren-mode was nil, tried to set it to 1 to check if it changed anything, but it didn't... [Tue Apr 7 19:45:22 2015] vanila: how do I need to change the inductive def'n, so the examples typechecks? [Inductive Foo : Prop := foo : forall (one : nat) (two : nat) (three : nat), one + two = three -> Foo. Example foo_1_2_3 : foo 1 2 3.] [Tue Apr 7 19:45:44 2015] you need to pass in a proof of one + two = three [Tue Apr 7 19:45:56 2015] foo 1 2 3 (eq_refl _). should work i think [Tue Apr 7 19:46:22 2015] it doesn [Tue Apr 7 19:46:24 2015] 't [Tue Apr 7 19:47:46 2015] (foo 1 2 3) is already a value whose type is not Prop/Set/Type, so you can't declare something of type (foo 1 2 3). [Tue Apr 7 19:48:09 2015] What you can do is declare something of type Foo [Example foo_1_2_3 : Foo.] [Tue Apr 7 19:48:29 2015] and say that it should be (foo 1 2 3 eq_refl) : [exact (foo 1 2 3 eq_refl).] [Tue Apr 7 19:50:10 2015] Cypi: can I change the definition such that I could write the example as was shown previously? [Tue Apr 7 19:52:11 2015] Yes: [Inductive foo (one two three : nat) : Prop := | bar : one + two = three -> foo one two three.] [Tue Apr 7 19:55:31 2015] it doesn't work, does it? [Tue Apr 7 19:55:40 2015] It does? [Tue Apr 7 19:55:40 2015] Example foo_1_2_3 : bar 1 2 3. doesn't typecheck [Tue Apr 7 19:56:05 2015] You said "as was shown" [Tue Apr 7 19:56:17 2015] Cypi pasted “No title” at http://lpaste.net/130323 [Tue Apr 7 19:56:18 2015] ah, I meant as was shown (by me) [Tue Apr 7 19:56:34 2015] Well, yes. What you've shown was "foo 1 2 3" :p [Tue Apr 7 19:56:54 2015] ah [Tue Apr 7 19:56:57 2015] hahaha [Tue Apr 7 19:57:07 2015] You cannot use a constructor of an inductive as a type [Tue Apr 7 19:57:08 2015] well, that's what I wanted. [Tue Apr 7 19:57:11 2015] right right [Tue Apr 7 19:57:34 2015] I just mixed them up in my mind for some reason [Tue Apr 7 19:57:38 2015] Ok :) [Tue Apr 7 19:57:41 2015] not enough practice! [Tue Apr 7 19:58:15 2015] Cypi: does constructor just "unpack" the constructor? [Tue Apr 7 19:58:30 2015] constructor tries to apply every constructor in order [Tue Apr 7 19:59:02 2015] in this case there is only one, so it's really just like [apply bar] [Tue Apr 7 19:59:06 2015] right [Tue Apr 7 19:59:12 2015] just tried it and it work [Tue Apr 7 20:00:50 2015] Cypi: on #idris, someone suggested to represent fixed precision using integers. can I define custom notation such that 10.2 gets translated to 1020 : nat? [Tue Apr 7 20:01:24 2015] why do you want to work with doubles? [Tue Apr 7 20:01:37 2015] I don't want to work with double any more [Tue Apr 7 20:01:44 2015] I realized I need fixed precision [Tue Apr 7 20:03:32 2015] I don't think you can do that easily (as in, just by using Notation), sorry. But I may be wrong, I don't know much about notations :) [Tue Apr 7 20:05:20 2015] anyway, I don't think I'm going to do it in coq. in this case, there isn't much gain but a lot of overhead [Tue Apr 7 20:05:32 2015] do what? [Tue Apr 7 20:05:50 2015] write my program [Tue Apr 7 20:06:05 2015] :/ [Wed Apr 8 07:32:11 2015] http://lpaste.net/130341 >> anyone knows how I could prove this? [Wed Apr 8 07:32:42 2015] Problem is that I have rewriting rules about a function, but I cannot use them to rewrite the type of a variable in the hypotheses, because said variable is used in the conclusion. [Wed Apr 8 07:35:01 2015] Assertion work sometimes... I don't know why [Wed Apr 8 07:35:18 2015] What should I assert? [Wed Apr 8 07:35:52 2015] Oh, by the way, in this case I could do [exfalso] and then it's easy, but my actual case is more complicated, so please don't do that :D [Wed Apr 8 07:36:10 2015] assert false. [Wed Apr 8 07:37:19 2015] Give out your full thing then... I don't know how to state what to do explicitly, I only get the hang of it. [Wed Apr 8 07:37:55 2015] And sorry about exfalso... Never heard about it [Wed Apr 8 07:41:41 2015] Giving the full thing is difficult... exfalso is basically just [elimtype False] [Wed Apr 8 07:43:48 2015] (so in a way it's the same as using [assert False], as you suggested) [Wed Apr 8 07:44:54 2015] I don't know how to describe the procedure, but I usually juggle it using JMeq, f_equal, eq_trans... It always reach using those... [Wed Apr 8 07:45:41 2015] Ah, good idea, I'll try using some JMeq [Wed Apr 8 07:47:08 2015] also, abstraction with sig and sigT sometimes help... [Wed Apr 8 07:47:19 2015] Good luck :) [Wed Apr 8 07:47:46 2015] Thanks [Wed Apr 8 09:04:10 2015] hi [Wed Apr 8 09:04:39 2015] http://research.microsoft.com/en-us/um/people/akenn/coq/jartypedsyntax.pdf [Wed Apr 8 09:04:46 2015] im unable to load the code from this paper into coq [Wed Apr 8 09:05:24 2015] http://research.microsoft.com/en-us/um/people/akenn/coq/simplytyped.v.txt [Wed Apr 8 09:06:18 2015] http://lpaste.net/130343 this where it gets stuck, and the proof state [Wed Apr 8 09:09:42 2015] any ideas how to patch this up? [Wed Apr 8 09:11:50 2015] Can someone help to type check the following function - https://gist.github.com/eldargab/fa7b60dda8db83966054 (currently yields impossible to unify "?9" with "?9") [Wed Apr 8 09:18:59 2015] yeah [Wed Apr 8 09:23:27 2015] its tricky.. [Wed Apr 8 09:23:48 2015] What is tricky? [Wed Apr 8 09:25:31 2015] the thing you asked [Wed Apr 8 09:28:05 2015] bah [Wed Apr 8 09:28:13 2015] i was struggling with convoy pattern stuff but it wasn't needed [Wed Apr 8 09:28:22 2015] http://lpaste.net/130344 [Wed Apr 8 09:28:38 2015] was making things harder than they needed to be [Wed Apr 8 09:29:12 2015] vanilla: what version of coq are you using? [Wed Apr 8 09:29:27 2015] latest [Wed Apr 8 09:29:46 2015] In 8.4p5 the only thing I had to do to make it work was rewriting "Rewrites refl_equal" [Wed Apr 8 09:29:56 2015] to "Rewrites idtac" [Wed Apr 8 09:30:22 2015] Indeed works. Thanks! [Wed Apr 8 09:30:44 2015] where do I put that? [Wed Apr 8 09:31:22 2015] oh that desn't seem to be a probem that's coming up when I try to load it [Wed Apr 8 09:31:44 2015] and it didn't get stuck where it got stuck for you [Wed Apr 8 09:32:23 2015] I think they've changed something in the theory about universe levels thats blocking it [Wed Apr 8 09:36:10 2015] at least now you know for certain that it worked in some version of Coq [Wed Apr 8 09:36:18 2015] and that they weren't making the stuff up [Wed Apr 8 09:36:23 2015] thanks [Wed Apr 8 09:39:48 2015] what that dependent destruction is supposed to do is say e = e0 [Wed Apr 8 09:40:00 2015] and then it replaces all occurrences of e with e0 [Wed Apr 8 09:40:16 2015] yeah i've managed to reduce that to this testcase http://lpaste.net/130345 [Wed Apr 8 09:40:24 2015] gives me the same universe level problem [Wed Apr 8 09:45:11 2015] disappointing :[ [Wed Apr 8 09:49:17 2015] Try coq8.5? [Wed Apr 8 09:49:27 2015] in 85, less universe problem. [Wed Apr 8 09:50:01 2015] For example, id id is OK, and so is my definition of CatCategory, the category of category [Wed Apr 8 09:50:03 2015] well i have the trunk from github [Wed Apr 8 09:50:12 2015] But beware, a lot of bug. [Wed Apr 8 09:50:32 2015] I think 8.5 is on coq.inria.fr= = [Wed Apr 8 09:51:58 2015] Anyway, so ironic that a tool to write bug free program has so much bug on it... You decide. A workaround maybe to write the same thing twice, "building" your own universe, in this way, no problem of universe in 8.4 too, but it is going to look ugly as hell. [Wed Apr 8 09:53:12 2015] haha yeah [Wed Apr 8 09:53:24 2015] it's a bit annoying that they keep changing subtle things to make existing proofs brea [Wed Apr 8 09:53:26 2015] break [Wed Apr 8 09:55:47 2015] I am ok on this... I rather have them not behave like C++, trying to have 100% compatibility. C++ could look 10 time more beautiful if they dare to make breaking changes. [Wed Apr 8 09:56:25 2015] I just get fed up having to delete _'s and add them in pattern matches [Wed Apr 8 09:57:11 2015] This also bug me :) so annoying [Wed Apr 8 11:10:06 2015] why is this evaluating to false? Theorem cons_not_nil : forall A (x:A) (l:list A), (x :: l) <> []. [Wed Apr 8 11:10:44 2015] specifically, its telling me that the subgoal [x] <> [] is false [Wed Apr 8 11:16:19 2015] What do you mean by ‘evaluating to false’? (Can you paste your work?) [Wed Apr 8 11:20:34 2015] alkabetz: yeah, that probably wasn't the best way of phrasing it. All I did was make a theorem out of that and run either intuition or destruct l then intuition. [Wed Apr 8 11:22:45 2015] Ah, that’s because Coq is converting [(x :: l) <> []] to [~(x :: l) = []], which it in turn simplifies to [x :: l = [] -> False]. [Wed Apr 8 11:23:28 2015] Basically, Coq is telling you to do proof by contradiction: it’s assuming [x :: l = []] and telling you to find a contradiction (i.e., a proof of [False]). [Wed Apr 8 11:24:12 2015] discriminate. will get stuff done. [Wed Apr 8 11:28:10 2015] alkabetz: oh, okay. I didn't know that that was an intuition tactic. Thanks. [Wed Apr 8 11:29:10 2015] ptrz: [intuition] does a lot of stuff; converting goals like that is just one of its behaviours. [Wed Apr 8 11:38:29 2015] I hate to ask, but I've been staring at this for way too long. What am I doing wrong? http://pastebin.ubuntu.com/10774054/ [Wed Apr 8 11:38:54 2015] it seems like I'm missing a parameter to exist, but I can't tell what. I've been reading this: http://adam.chlipala.net/cpdt/html/Subset.html [Wed Apr 8 11:46:40 2015] (that should run in an IDE as-is) [Wed Apr 8 11:47:38 2015] check the type of exist [Wed Apr 8 11:47:46 2015] you might need to add more underscores [Wed Apr 8 11:47:53 2015] (exist _ _ (a :: rest) cons_not_nil) [Wed Apr 8 11:47:55 2015] (exist _ (a :: rest) _ cons_not_nil) [Wed Apr 8 11:47:57 2015] (exist _ (a :: rest) _ cons_not_nil _) [Wed Apr 8 11:47:58 2015] just try anything [Wed Apr 8 11:48:03 2015] The constructor exist (in type sig) expects 3 arguments. Clear enough? [Wed Apr 8 11:48:13 2015] oh, or less! [Wed Apr 8 11:48:16 2015] (exist (a :: rest) cons_not_nil) maybe [Wed Apr 8 11:49:01 2015] _ l' _ is what you'r lookin for [Wed Apr 8 11:49:09 2015] vanila: that always seems like the most sensible option, but it gives me "The term "a :: rest" has type "list instr" while it is expected to have type "?35 -> Prop"." [Wed Apr 8 11:49:51 2015] lolisa: it says it can't infer a second placeholder [Wed Apr 8 11:50:45 2015] " match l with exist _ l' _ => " this? Just checking, this is fine on my Coq [Wed Apr 8 11:50:54 2015] Yeah, from looking at the "Print sig." output, I'd think that it would take the type implicitly, and then just the list and the prop [Wed Apr 8 11:51:41 2015] lolisa: doesn't work for me... I'm on the current version in CoqIDE [Wed Apr 8 11:52:13 2015] I'm on 8.5= = [Wed Apr 8 11:52:39 2015] ah [Wed Apr 8 11:53:05 2015] Wait, why don't you do ` l? [Wed Apr 8 11:53:19 2015] yeah, 8.4pl5 here [Wed Apr 8 11:53:39 2015] what exactly do you mean by that? [Wed Apr 8 11:53:57 2015] Require Import Program. [Wed Apr 8 11:54:10 2015] match skipn n (` l) with [Wed Apr 8 11:54:51 2015] basically this take the value out of exists for you. std lib function. [Wed Apr 8 11:55:41 2015] ah thanks, I had no idea that that was a thing [Wed Apr 8 11:55:48 2015] As I think is apparent, I'm pretty new to Coq [Wed Apr 8 11:55:51 2015] :{P [Wed Apr 8 11:55:53 2015] * :P [Wed Apr 8 11:55:54 2015] BTW there are something the same for dependent pair {_&_} too, I forgot the name, but Search will give it out. [Wed Apr 8 11:56:26 2015] hm yeah. I still haven't solved the core problem here. [Wed Apr 8 11:56:29 2015] :-P going pretty fast, I think it took me 3 month to get where you are because I don't know FP before... [Wed Apr 8 11:56:32 2015] how to construct this thing [Wed Apr 8 11:56:50 2015] Some (exist _ (a :: rest) (cons_not_nil _ a rest)) [Wed Apr 8 11:57:21 2015] Awesome! Worked! Thanks so much [Wed Apr 8 11:57:23 2015] Don't expect too much from type inference engine, when it fail do stuff yourself. [Wed Apr 8 11:57:38 2015] By the way, how do I figure out what the inferred values there are? [Wed Apr 8 11:57:41 2015] in the future [Wed Apr 8 11:58:01 2015] If it is an error, read the error. [Wed Apr 8 11:58:07 2015] If it pass, Print it. [Wed Apr 8 11:58:38 2015] If both case fail, do @function, this disable implicit argument so will make things more straight. [Wed Apr 8 11:59:07 2015] I see. Thanks. [Wed Apr 8 11:59:23 2015] Have a github account? Let's follow each other [Wed Apr 8 12:10:48 2015] lolisa: I do - username plsql [Wed Apr 8 12:10:58 2015] let me know yours [Wed Apr 8 12:13:07 2015] lolisa :) [Wed Apr 8 13:44:16 2015] I have a subset type representing non-empty lists. I'm trying to write a head function that returns A instead of option A, because there has to be a head. However, matching doesn't work because Coq doesn't recognize the proof and considers the pattern matching non-exhaustive. What should I do? [Wed Apr 8 13:45:21 2015] I just found this: http://www.di.ubi.pt/~desousa/2011-2012/ComFia/coq_lesson2.pdf [Wed Apr 8 14:12:16 2015] ptrz: https://gist.github.com/wilcoxjay/7793370578da8154472b [Wed Apr 8 14:12:21 2015] there is one way to do it [Wed Apr 8 15:57:31 2015] what exactly is the distinction between something like l <> [] and a Prop? I'm sometimes getting one distinguished from the other with no discernable pattern [Wed Apr 8 15:57:57 2015] as in, I'll take an arg (p:l <> []) and have it sometimes be only a l <> [] and sometimes only a Prop [Wed Apr 8 15:58:42 2015] ptrz: Prop is the type of [l <> []]. [Wed Apr 8 15:59:15 2015] An argument [p : l <> []] is a proof that [l] is nonempty. [Wed Apr 8 15:59:47 2015] alkabetz: I see. Why is Coq letting me use l <> [] as an arg type, then? [Wed Apr 8 16:00:15 2015] ptrz: [l <> []] is the type of proofs that [l] is nonempty. [Wed Apr 8 16:02:22 2015] alkabetz: Right. I guess my confusion stems from the fact that when I take an arg (p:l <> []) and try to use it as the left-hand side of a -> implies lemma, Coq gives me an error telling me it needs a Prop. [Wed Apr 8 16:02:43 2015] ptrz: Can you paste an example? [Wed Apr 8 16:03:50 2015] Lemma impl_subset : forall (l:list instr) (p:l <> []), [Wed Apr 8 16:03:52 2015] p -> length l = length (` (exist _ l p)). [Wed Apr 8 16:04:53 2015] ptrz: What’s that backtick for? I’ve never seen that syntax. [Wed Apr 8 16:06:46 2015] alkabetz: It's from the Program module in the std lib - it just takes the core value out of a subset type [Wed Apr 8 16:07:52 2015] like like proj1_sig, iirc [Wed Apr 8 16:08:00 2015] might actually be a notation synonym [Wed Apr 8 16:09:35 2015] ptrz: Looking, hang on. [Wed Apr 8 16:13:24 2015] ptrz: Can you say in English what you’re trying to prove? [Wed Apr 8 16:16:03 2015] that the length of any non-empty list is equal to the length of that list "packed" into the subset type and then "unpacked" from it [Wed Apr 8 16:16:16 2015] pretty much just a lemma to help prove a larger theorem [Wed Apr 8 16:17:05 2015] I think I'm going to completely reconsider my approach, though [Wed Apr 8 16:17:09 2015] I also have to leave [Wed Apr 8 16:17:14 2015] I appreciate the help, though [Wed Apr 8 16:17:20 2015] Not a problem. Good luck! [Wed Apr 8 22:18:05 2015] Is there any way to tell Coq that because the function its recursive call arg is wrapped in is a Fixpoint, that it must be a Fixpoint? e.g. if f (x:A) is fixpoint, then g (y:A) is a fixpoint if its recursive call is g (f y), directly or indirectly [Wed Apr 8 22:39:48 2015] see my attempts at prog_eval here, if you're interested: https://github.com/plsql/Verified-BPF/blob/master/Analysis.v [Wed Apr 8 23:33:33 2015] can anybody give a simple explanation of how cofix works? I've tried to read http://www.labri.fr/perso/casteran/RecTutorial.pdf and http://adam.chlipala.net/cpdt/html/Coinductive.html, but it's very confusing [Wed Apr 8 23:33:53 2015] using cofix, I can make "infinite proofs", but I'm not exactly sure what that means [Wed Apr 8 23:34:17 2015] and when I use cofix, they give me the thing I'm trying to prove as an assumption, but I can't use that assumption, because it's guarded [Wed Apr 8 23:34:27 2015] and I'm not exactly sure what guardedness is at all [Wed Apr 8 23:36:22 2015] kba: I think guardedness relates to fixpoints, no? [Wed Apr 8 23:36:34 2015] it's the quality that defines something as a fixpoint, iirc [Wed Apr 8 23:36:37 2015] cofixpoints [Wed Apr 8 23:36:42 2015] this is very related to my last question :P [Wed Apr 8 23:37:10 2015] anyway, it seems that maybe this library lets you write mutually recursive functions? [Wed Apr 8 23:37:24 2015] that are recognized as fixpoints [Wed Apr 8 23:37:26 2015] not sure [Wed Apr 8 23:37:32 2015] No, co-induction allows induction on infinite structures [Wed Apr 8 23:37:32 2015] I need to go, anyway [Wed Apr 8 23:37:53 2015] I see. [Wed Apr 8 23:38:02 2015] I wish I had more to share [Wed Apr 8 23:53:42 2015] no, co-induction does not allow induction [Wed Apr 8 23:58:18 2015] hmm [Wed Apr 8 23:58:31 2015] is it possible to model coq in coq? [Wed Apr 8 23:58:33 2015] and if not why not [Thu Apr 9 00:01:46 2015] there is a paper called Coq in Coq that might enlighten you [Mon Jul 13 13:16:33 2015] hello. is there a default implementation of diffarrays for coq? [Tue Jul 14 09:45:57 2015] does anyone else have strange issues when using both Proof General and Paredit? [Tue Jul 14 09:48:20 2015] like, if you do C-left or C-right, which are forward barfing and slurping (paredit jargon...) it doesn't work as it should on parenthesis, and it seems to act weird in the presence of the "end" keyword [Tue Jul 14 10:19:21 2015] doesn't paredit only work for Lisp-like languages? [Tue Jul 14 10:23:00 2015] johnw: not sure about when paredit should work or not, i'm very much new to emacs, but Gallina does use its fair share of parens and it'd be nice to have paredit-like functionality for editing it [Tue Jul 14 10:42:02 2015] johnw: hey, followup on paredit with proof general - just installed smartparens after searching around, seems to work so far. if you ever catch another newb confused by this on irc, tell them to try out smartparens [Tue Jul 14 10:45:43 2015] hcp_archonn: thanks [Tue Jul 14 13:18:41 2015] I have an assumption [f x] and a goal [f y]. What tactic do I use to replace my goal with [x = y]? [Tue Jul 14 13:20:26 2015] I guess I can do [(replace y with x by omega); auto]. Is there a cleaner way? [Tue Jul 14 13:21:52 2015] I think it's fine [Tue Jul 14 13:22:06 2015] You can replace [auto] by just [assumption] to make sure it does not do too much or something [Tue Jul 14 14:09:04 2015] alkabetz: I sometimes use a tactic like this: https://gist.github.com/wilcoxjay/7d38b42f60218b7e5685 [Tue Jul 14 14:09:34 2015] as far as I know there's no built in way to do it, and it's annoying to generalize it to multiple arguments. [Tue Jul 14 14:44:16 2015] hi. hm. what part of the coq source code contains the structure of proofs? [Tue Jul 14 14:56:18 2015] hm. probably kernel/constr.v [Wed Jul 15 08:58:47 2015] is there a priority queue structure in coq? [Wed Jul 15 10:29:39 2015] Something like this? https://github.com/jbapple/priority-queues [Wed Jul 15 10:29:46 2015] Never used it BTW [Wed Jul 15 16:13:00 2015] (Cross posting form #haskell-blah) I have a conceptual question about optimal reduction. I've read in a few papers that if a term has a type on elementary affine logic, then you can use the abstract algorithm to normalize that term without need for the oracle/bookkeeping. In order to decide what rule to apply to duplicators you just have to check its "level"... [Wed Jul 15 16:13:07 2015] The problem is I read it again and again and I don't know what the author means by level... does anyone know or know someone who knows? [Wed Jul 15 16:17:06 2015] SrPx: Do you have a reference to the use of the term? [Wed Jul 15 16:20:26 2015] pardon? [Wed Jul 15 16:28:14 2015] * wonders why papers are made purposely so hard to read :( [Wed Jul 15 16:34:24 2015] i mean, I'm not seeing what you're seeing, so I have no idea [Wed Jul 15 16:42:10 2015] Ahhh... nevermind. I understand it. Labels, not levels. I remember having that explained on the book. Thanks :) [Wed Jul 15 16:42:29 2015] This was the paper I was talking about: "Optimizing Optimal Reduction: A Type Inference Algorithm for Elementary Affine Logic" [Wed Jul 15 23:40:30 2015] can u prove LEM from functional-relation-to-function [Wed Jul 15 23:40:36 2015] they seem about equally nonconstructive >w> [Thu Jul 16 00:24:43 2015] benzrf: Consdier the types [unit] and [P + ~P] for some [P], and the relation [R : unit -> (P + ~P) -> Prop] defined by [R := fun _ _ => True]. Does this example answer your question? (What, precisely, is the definition of a functional relation?) [Thu Jul 16 00:25:16 2015] hmmmmm [Thu Jul 16 00:26:53 2015] i guess... forall (a : A) (x y : B), R a x -> R a y -> x = y [Thu Jul 16 00:28:29 2015] oh and i guess you gotta have it cover the whole domain... but then... the proof itself will be a function [Thu Jul 16 00:28:34 2015] blugh [Thu Jul 16 05:34:37 2015] anyone of you using mac? [Thu Jul 16 05:35:01 2015] I'm trying to get proof general and/or CoqIDE to work with the homebrew installation of coq, and failing [Thu Jul 16 07:23:40 2015] For software foundations, program equivalence, Exercise: 4 stars, advanced, optional (optimize_0plus) <- when it says "extend to handle variables", does it mean that I have to track constants through variables, and eliminate them where the variables are used? [Thu Jul 16 23:50:15 2015] hello there [Thu Jul 16 23:50:35 2015] beginner question, been struggling for two days getting modules loading [Thu Jul 16 23:50:59 2015] in CoqIDE, how do you require modules from some random folder? [Thu Jul 16 23:53:08 2015] viatropos: start it as "coqide -I random/folder/" ? [Thu Jul 16 23:53:30 2015] also, i am on a mac. does that work on a mac? [Thu Jul 16 23:54:19 2015] here's the basic setup what i'm doing [Thu Jul 16 23:54:20 2015] (* in /Users/viatropos/desktop/learncoq/example.v *) [Thu Jul 16 23:54:21 2015] Add LoadPath "/Users/viatropos/dev/coqtest/". [Thu Jul 16 23:54:22 2015] (* a looks like this: [Thu Jul 16 23:54:23 2015] Require Import /Users/viatropos/dev/coqtest/b.v *) [Thu Jul 16 23:54:24 2015] Load "/Users/viatropos/dev/coqtest/a.v". [Thu Jul 16 23:54:44 2015] https://gist.github.com/lancejpollard/09b7cc2e8a9d637a190e [Thu Jul 16 23:56:42 2015] ok updated the example https://gist.github.com/lancejpollard/09b7cc2e8a9d637a190e [Thu Jul 16 23:57:35 2015] https://cldup.com/cLrpQZ6xp7-1200x1200.png [Thu Jul 16 23:58:14 2015] i've tried several ways to do this, from the command line, and from CoqIDE, but it gives the same error [Thu Jul 16 23:58:19 2015] "Error: Cannot find library in loadpath" [Thu Jul 16 23:58:48 2015] I saw this, but didn't seem to help http://stackoverflow.com/questions/16202666/coqide-cant-load-modules-from-same-folder [Thu Jul 16 23:59:03 2015] aj: -bash: coqide: command not found [Fri Jul 17 00:01:20 2015] viatropos: hmm; Add LoadPath "...". Load b. works fine; LoadPath doesn't seem to be passed on to other modules though? [Fri Jul 17 00:02:46 2015] hmm [Fri Jul 17 00:02:55 2015] here is an even more basic example demonstrating https://gist.github.com/lancejpollard/0f80152f7b9b453aa1fb [Fri Jul 17 00:03:24 2015] hmm, what am i doing wrong? [Fri Jul 17 00:04:19 2015] oh, have you compiled b.v to b.vo? [Fri Jul 17 00:04:31 2015] no, is that required? [Fri Jul 17 00:04:47 2015] yeah, you can't require import until it's compiled aiui [Fri Jul 17 00:05:10 2015] oh awesome, ok great that works! [Fri Jul 17 00:05:11 2015] thanks [Fri Jul 17 00:05:38 2015] one more question, do you use proof general or the downloaded coq side? [Fri Jul 17 00:05:40 2015] ide [Fri Jul 17 00:05:41 2015] * [Fri Jul 17 00:06:31 2015] viatropos: i use coqide because it's easy and i'm a newb [Fri Jul 17 00:06:44 2015] cool. do you use the Compile -> Make makefile menu in the CoqIDE or you write the commands like `coqc` manually [Fri Jul 17 00:07:01 2015] wondering how you work with many files "properly" in the CoqIDE [Fri Jul 17 00:07:51 2015] for example [Fri Jul 17 00:07:58 2015] say i find a coq project like https://github.com/dragonwasrobot/simpl-lang [Fri Jul 17 00:08:13 2015] what's your workflow for getting it working in the CoqIDE? [Fri Jul 17 00:08:35 2015] I'm used to just opening a whole folder in a text editor, and browsing the code.. [Fri Jul 17 00:08:55 2015] But since Coq steps through the proofs, you have to start from the files without any `Require` calls [Fri Jul 17 00:09:05 2015] (it seems) [Fri Jul 17 04:03:00 2015] hi [Fri Jul 17 05:40:46 2015] hi [Fri Jul 17 06:02:34 2015] hi [Fri Jul 17 13:48:49 2015] hi, how the hell should I proceed from here? http://pastebin.com/T3WGVvya [Fri Jul 17 13:52:37 2015] xeno: you'll need fact "forall i, st i = st' i". Is it true, after all? [Fri Jul 17 13:55:12 2015] gdsfh: st' is (update st v n) and if i = v, then I can do inversion on H. [Fri Jul 17 13:55:22 2015] problem is, how can I construct that fact? [Fri Jul 17 14:07:05 2015] xeno: try "rewrite Heqst'" or "rewrite <- Heqst'", it may help (depending on how "update" is defined; maybe you'll be able to unfold it and prove the fact). (sorry, have to go afk.) [Fri Jul 17 16:14:06 2015] I was asking about C verification here recently. I stumbled across another related project: http://flint.cs.yale.edu/certikos/ [Fri Jul 17 16:35:14 2015] newsham: huh, neat [Fri Jul 17 16:35:27 2015] newsham: thus far I'd only seen things like Bedrock and VellVM [Fri Jul 17 16:43:44 2015] have you seen http://vst.cs.princeton.edu/ ? [Fri Jul 17 16:43:58 2015] (there's also sel4, which used isabelle/hol rather than coq) [Fri Jul 17 16:44:43 2015] two practical projects using vst: http://www.cs.princeton.edu/~appel/papers/verified-hmac.pdf and http://www.cs.princeton.edu/~appel/papers/verif-sha.pdf [Fri Jul 17 16:45:00 2015] both verifying parts of the openssl code base (with some modifications) [Fri Jul 17 19:53:59 2015] when you generate, say, haskell from coq, is there a way to ensure that the translator is correct? just test it on the haskell side with quickcheck? [Fri Jul 17 19:54:47 2015] nkaretnikov: its proven probably :> [Fri Jul 17 19:55:24 2015] well, I recall people saying things like "it's necessary to postprocess the output after translation with sed" [Fri Jul 17 19:55:30 2015] which is kind of weird [Fri Jul 17 19:56:10 2015] haha what [Fri Jul 17 19:56:37 2015] yeah, maybe it was for agda, not coq, but I do remember something like that [Fri Jul 17 19:57:10 2015] I'm just curious what folks writing high-assurance systems use in such cases [Fri Jul 17 19:58:53 2015] I think I was quoting wouter swierstra, possibly misquoting, dunno [Fri Jul 17 20:00:24 2015] nkaretnikov, benzrf: the translator is not verified, and yes, there exist coq projects that post process some things with sed :) [Fri Jul 17 20:01:13 2015] jrw: I think someone was working on the translator. maybe it was for a different project, though [Fri Jul 17 20:01:20 2015] I recall reading something on the coq list [Fri Jul 17 20:01:38 2015] maybe so. the one that everyone uses today is not verified [Fri Jul 17 20:02:05 2015] it's not clear to me how to approach verifying such a thing [Fri Jul 17 20:02:21 2015] you need a semantics for the source and destination languages [Sat Jul 18 00:08:37 2015] any ideas why on CoqIDE_8.4p15 and ssreflect-1.5, getting this error? https://gist.github.com/lancejpollard/1344e996459158eab557 [Sat Jul 18 00:08:45 2015] [Loading ML file z_syntax_plugin.cmxs ... failed] [Sat Jul 18 00:08:46 2015] Error: implementation mismatch on Notation [Sat Jul 18 00:10:29 2015] ssreflect is importing successfully, but not ssrnat right after [Sat Jul 18 00:16:36 2015] super weird error message, whoops. was because i was using the CoqIDE still inside the .dmg, forgot to pull it to Applications folder :p [Sat Jul 18 14:36:02 2015] hi there, is there a standard workflow for looking up where terms are defined in coq (like a typical IDE or text editor has?) http://stackoverflow.com/questions/31494291/how-do-you-look-up-where-identifiers-are-defined-in-coq-efficiently [Sat Jul 18 14:43:12 2015] Is [Locate] what you're looking for? (Just posted a slightly extended answer to stack overflow.) [Sat Jul 18 14:49:38 2015] jgross: that's close, but Queries -> Locate on `finType` gives this: "Notation Ssreflect.fintype.Finite.Exports.finType" (which is helpful) [Sat Jul 18 14:49:48 2015] but can it link me to the source code, or the docs somehow? [Sat Jul 18 14:50:00 2015] so instead it would go to http://coqfinitgroup.gforge.inria.fr/doc/fintype.html#Finite.Exports.finType [Sat Jul 18 14:50:15 2015] or something along those lines (like the local ssreflect source or something) [Sat Jul 18 15:19:33 2015] No, I don't think there's a way to do that, currently. The source files don't even get installed, though I think they might be fixing that soon (or in the next beta). It might be possible to do with https://itu.dk/research/tomeso/coqoon/, though I haven't tried it. [Sat Jul 18 15:20:40 2015] Hi all, is there any coq library that has tools for working with, say, manifolds? [Sat Jul 18 15:21:53 2015] jgross: Thanks, good to know. [Sat Jul 18 15:22:38 2015] jgross: What is your workflow typically for looking up implementation details of some identifier? [Sat Jul 18 15:26:50 2015] viatropos: I use [Locate]. If it's my own file, I open the relevant source file. If it's Coq.*, I either go to github.coq/coq/coq, or to a local copy of the Coq source code. If it's a library I installed, I go to the directory I installed it from. But, more frequently, I just [Print] the identifier, or use [About] or [Check], instead, which gives me the full definition (less any documentation or formatting). The type signature, plus [Sat Jul 18 15:26:50 2015] sometimes the definition, is often enough. [Sat Jul 18 15:28:45 2015] jgross: perfect, that's super helpful, thank you [Sat Jul 18 16:25:02 2015] jgross: are you coming to the conference in SF this week? [Sat Jul 18 17:24:51 2015] johnw: I am not. Which conference is this? [Sat Jul 18 17:30:16 2015] how do you check the [Record] implementation? [Sat Jul 18 17:30:20 2015] Check Record. [Sat Jul 18 17:30:25 2015] gives "Error: The reference Record was not found in the current environment." [Sat Jul 18 17:31:11 2015] yet, i can use `Record` in the local environment: "Record x:Type := {}." [Sat Jul 18 17:32:17 2015] "Locate Record." -> "No object of basename Record" [Sat Jul 18 17:41:49 2015] jgross: I think CAV, what Adam is going to [Sat Jul 18 18:05:29 2015] what is preferred to compile coq ? camlp4 or camlp5 ? [Sat Jul 18 18:33:33 2015] camlp5 I think [Sat Jul 18 19:27:17 2015] is there a list of operator precedences in coq? [Sat Jul 18 19:27:49 2015] As a newb, it's hard to look at something and know how to read the operator precedence. Any suggestions? [Sat Jul 18 19:30:47 2015] maybe this is it, but doesn't seem to cover everything https://coq.inria.fr/refman/Reference-Manual005.html [Sat Jul 18 19:56:18 2015] viatropos: do you just want the precedence of a specific operator? [Sat Jul 18 20:01:17 2015] When I navigate forward/backward somewhat quickly (back and forth), CoqIDE gives me different output randomly [Sat Jul 18 20:01:23 2015] sometimes this: https://cloudup.com/iyPaXA_8_sn [Sat Jul 18 20:01:33 2015] sometimes this https://cloudup.com/iUVBcb9rTHv [Sat Jul 18 20:02:08 2015] Do I need to be aware of some implementation detail with the proof checker? [Sat Jul 18 20:02:34 2015] Doesn't seem very safe if the result of proof checking is variable like this [Sat Jul 18 20:05:03 2015] Assuming this is just a bug with the IDE, not the compiler [Sun Jul 19 12:35:32 2015] new question trying to understand why you can't leave out the `forall` in a dependent product type, wondering if someone could point me to clarity on it http://cstheory.stackexchange.com/questions/32027/why-does-the-dependent-product-type-need-forall-in-coq [Sun Jul 19 12:51:23 2015] moved to math.stackexchange since cstheory seems inactive [Sun Jul 19 15:42:55 2015] I have Hx : X <> X , and X is of type (Id n). How do I do inversion on it, if I try I get "is not inductive" [Sun Jul 19 15:45:55 2015] "X <> X" is just a notation for "X = X -> False". What you can do is either: 1) [exfalso; apply Hx; reflexivity] 2) [elim Hx; reflexivity] 3) [congruence] [Sun Jul 19 15:50:45 2015] how do I unfold the <> ? [Sun Jul 19 15:51:18 2015] [unfold not in Hx] will do it [Sun Jul 19 15:52:37 2015] Also, I was unprecise: [x <> X] is a notation for [not (X = X)], and not is defined as [fun A => A -> False]. [Sun Jul 19 18:44:56 2015] https://gilith.wordpress.com/2015/07/19/the-slowest-software-development-methodology-in-the-world/ [Sun Jul 19 18:45:05 2015] (not coq, but may be of interest) [Sun Jul 19 19:37:46 2015] newsham: interesting [Sun Jul 19 20:27:34 2015] is there a better place for beginners to ask questions about coq? [Sun Jul 19 20:29:03 2015] or any active places where people hang out? [Sun Jul 19 20:31:28 2015] viatropos : about your question about random answers from CoqIDE, it's (as far as I know) fixed in Coq 8.5 (well, only the beta version of it is out right now) [Sun Jul 19 20:31:45 2015] nice [Sun Jul 19 20:31:45 2015] they changed the way all this works, so it should be really deterministic now [Sun Jul 19 20:32:28 2015] cool, maybe the home-brew version just needs to catch up [Sun Jul 19 20:33:40 2015] Your other question was something about forall? [Sun Jul 19 20:35:33 2015] Ah, it was answered by Ptival, good [Sun Jul 19 20:37:52 2015] what about, how did you guys learn coq, or how long did it take you? [Sun Jul 19 20:38:21 2015] I learned Coq mainly by reading Software Foundations. And then, some of Certified Programming with Dependent Types [Sun Jul 19 20:39:11 2015] cool, ok [Sun Jul 19 20:40:35 2015] I have this book on "theory of finite automata" that i've been using to learn math the past few months.. [Sun Jul 19 20:40:47 2015] I am hoping to be able to translate some of it into Coq [Sun Jul 19 20:40:53 2015] Any tips for how to do that? [Sun Jul 19 20:41:26 2015] Tried starting today with "an alphabet is a finite non-empty set", but the "set" stuff in coq is hard to navigate [Sun Jul 19 20:42:01 2015] Not sure if I should be translating "non-empty set" and "x is an element of alphabet" to "types", or use some set-theory thing in Coq [Sun Jul 19 20:42:27 2015] Any recommendations? [Sun Jul 19 20:46:04 2015] I mainly used Coq for fun and for type-theory-oriented stuff, so I'm not really a competent person in that regard. Anyway, you might find this cheaty or not, but here is a relevent paper on the topic: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.5164 [Sun Jul 19 20:46:43 2015] dang, don't have access [Sun Jul 19 20:46:49 2015] I have seen other related ones [Sun Jul 19 20:48:37 2015] in this paper, they actually axiomatize what finite sets are. They defined two axioms [fset : Set -> Set] and [member : forall (A : Set), A -> fset A -> Prop]. [Sun Jul 19 20:49:05 2015] You can also (apparently it was done in Nuprl) just say an alphabet is just its cardinal [Sun Jul 19 20:51:51 2015] hello are there useful coq libraries for proving things about interacting systems and crypto [Sun Jul 19 20:52:05 2015] like, something you could use to prove the security of diffie helman or something [Mon Jul 20 03:08:39 2015] hi, in Exercise: 2 stars (hoare_asgn_example4), I got into some trouble because I need to prove that X <> Y... which makes sense, given that they're just numerical Id's, how do I know? [Mon Jul 20 09:34:17 2015] hi, I want to install coq on CentOS 7 and I'm a bit confused with the dependencies [Mon Jul 20 09:34:29 2015] Camlp5 (version <= 4.08, or 5.* transitional) [Mon Jul 20 09:35:40 2015] does it mean it's ok to install [Mon Jul 20 09:35:59 2015] camlp5-5.15.tgz in transitional "version" ? [Mon Jul 20 09:38:51 2015] in furhter text it's said "Check that you have Camlp4 installed" [Mon Jul 20 12:28:05 2015] I've finally got it installed in CentOS 7, ignoring any versions recommendation helped the best :) [Mon Jul 20 13:16:02 2015] I have a newbie question: what do square brackets mean? I see this in a proof: [idtac|right; ring]. I know what idtac, right, and ring mean, but I'm not sure about the square brackets or the pipe. [Mon Jul 20 13:30:48 2015] square brakets mean "apply these tactics to the cases generated" and follow the ordering of generation. [Mon Jul 20 13:31:18 2015] Thus if T creates 3 subgoals, T; [T0 | T1 | T2] will apply T0 to the first subgoal, T1 to the second, etc. [Mon Jul 20 13:31:49 2015] Square brakets are also used for pattern syntax with intros and other tactics. [Mon Jul 20 13:32:56 2015] Additionally, the solve, first, and progress tactics take a [T0 | ... | Tn] list of tactics to try on a single goal. [Mon Jul 20 13:34:28 2015] If you can, it's best to avoid T; [ ... ] tactic scripts because they're brittle to refactoring and case additions. [Mon Jul 20 13:36:45 2015] ianjneu: thanks [Mon Jul 20 16:53:49 2015] what tactic can I use for x <= y -> S x <= S y ? [Mon Jul 20 17:00:03 2015] xeno: [omega] should work. but if you're working through SF and want to use tactics as they're introduced, you probably have a lemma that says that. you can just [apply] it [Mon Jul 20 17:00:19 2015] yeah it worked [Mon Jul 20 17:00:37 2015] xeno: did you figure out how to prove [X <> Y] from last night? [Mon Jul 20 17:00:50 2015] I'm past the switch to SfLib, so all my previous lemmas are left in a ton of files... [Mon Jul 20 17:01:02 2015] it was just inversion, dunno why [Mon Jul 20 17:02:04 2015] yeah, if you have [X = Y] in your context, [inversion] will solve your goal [Mon Jul 20 17:03:22 2015] this is because X and Y are defined to be [Id 0] and [Id 1], where Id is the constructor for the type id. [Mon Jul 20 17:03:39 2015] so [X = Y] is really [Id 0 = Id 1]. [Mon Jul 20 17:03:59 2015] and of course 0 is the constructor O of nat, and 1 is [S O] [Mon Jul 20 17:04:47 2015] so inversion is able to deduce [O = S O] from your hypothesis, which is "obviously" false, because two different constructors never yield equal results. [Mon Jul 20 17:28:27 2015] what about y = x + (y - x) ? sam issue there... [Mon Jul 20 17:28:33 2015] omega doesn't catch it [Mon Jul 20 17:29:15 2015] are those nats? [Mon Jul 20 17:30:27 2015] if so, then omega can't solve it unless it knows that y >= x [Mon Jul 20 17:30:38 2015] otherwise, if y is 0, then y - x is also 0, no matter the size of x [Mon Jul 20 17:30:46 2015] i mean, if y < x [Mon Jul 20 18:25:45 2015] johnw: good point [Mon Jul 20 18:25:57 2015] johnw: it is know btw [Mon Jul 20 18:29:02 2015] xeno: and these are Coq stdlib nat's? not ssreflect nats? [Mon Jul 20 18:29:07 2015] yes [Mon Jul 20 18:29:11 2015] hmm [Mon Jul 20 18:29:16 2015] can you show me the full context and goal? [Mon Jul 20 18:30:39 2015] http://pastebin.com/WDhXhGGg [Mon Jul 20 18:31:18 2015] ok, now convert ble_nat x y = true to x <= y [Mon Jul 20 18:31:25 2015] you should have a theorem for that [Mon Jul 20 18:31:54 2015] because I don't believe those two obviously mean the same to omega [Mon Jul 20 18:32:49 2015] that slved it [Mon Jul 20 18:32:53 2015] great [Mon Jul 20 20:34:02 2015] hmmm... what the heck [Mon Jul 20 20:34:13 2015] what is the rule for generating induction principles for Props...?? [Mon Jul 20 20:34:25 2015] benzrf: more context [Mon Jul 20 20:35:20 2015] er, hold on [Mon Jul 20 20:36:31 2015] ah [Mon Jul 20 20:36:58 2015] Prop induction principles leave off the actual values as arguments to the predicate...! [Mon Jul 20 20:37:25 2015] still not sure what you mean [Mon Jul 20 20:38:14 2015] try defining an inductive 'even' predicate twice [Mon Jul 20 20:38:25 2015] once where the codomain is Prop, one where it's type [Mon Jul 20 20:38:27 2015] *Type [Mon Jul 20 20:38:35 2015] then check out the induction principles generated in each case [Mon Jul 20 20:38:38 2015] what do you mean by "inductive 'even' predicate"? do you mean a function in Prop? [Mon Jul 20 20:38:51 2015] Inductive even : nat -> Prop := [Mon Jul 20 20:38:53 2015] ... [Mon Jul 20 20:39:03 2015] can you pastie the principles in both cases? [Mon Jul 20 20:39:13 2015] kk [Mon Jul 20 20:39:16 2015] thx [Mon Jul 20 20:41:12 2015] https://gist.github.com/152539edb40db2f07208 [Mon Jul 20 20:41:31 2015] you might wanna look at the second case first [Mon Jul 20 20:43:40 2015] so, the second principle uses a function n, ev n -> Prop [Mon Jul 20 20:44:01 2015] the first principle doesn't need this, because the data type is already that type of function, and so just nat -> Prop [Mon Jul 20 20:45:13 2015] i.e., the version in Prop doesn't need the evidence; this is what I believe you were getting at? [Mon Jul 20 20:45:36 2015] you could try just writing the second principle yourself for the inductive predicate [Mon Jul 20 20:48:49 2015] hm? [Mon Jul 20 20:50:08 2015] https://coq.inria.fr/faq#htoc123 [Mon Jul 20 21:22:55 2015] hey, i'm working my way through http://www.randomhacks.net/2015/07/19/proving-sorted-lists-correct-using-coq-proof-assistent/ and I can't figure out why the `Fixpoint insert_sorted` bit I've even copied over correctly is failing with coq 8.4pl6. Gist here: https://gist.github.com/jmhodges/33027733dae6b0a6fb1e [Mon Jul 20 21:29:47 2015] jmhodges : you probably need to "Import ListNotations." [Mon Jul 20 21:30:01 2015] The notation [] is not available by default [Mon Jul 20 21:31:30 2015] Cypi: you are probably correct! now to fix my loadpath [Mon Jul 20 21:31:54 2015] "Require Import List." if you haven't done it yet :) [Mon Jul 20 21:32:11 2015] (so: [Require Import List. Import ListNotations.] ) [Mon Jul 20 21:32:27 2015] the newbiest newb right here [Mon Jul 20 21:32:54 2015] No worries [Mon Jul 20 21:33:58 2015] Cypi: i'm guessing there's a thing to import for <=?, too. i will go hunt it down [Mon Jul 20 21:34:05 2015] Cypi: thank you [Mon Jul 20 21:34:19 2015] There should be, yes, but I don't know where :D [Mon Jul 20 21:35:03 2015] Ah, no, it was defined directly by the person who wrote the blogpost [Mon Jul 20 21:35:42 2015] ah ha that Infix bit [Mon Jul 20 22:26:38 2015] is there a way to specify the subterm that a rewrite should apply to [Mon Jul 20 22:44:55 2015] hey so [Mon Jul 20 22:44:58 2015] here's a thing i just found it. [Mon Jul 20 22:45:00 2015] *out [Mon Jul 20 22:45:08 2015] if you do a tactic-based definition of a Fixpoint. [Mon Jul 20 22:45:19 2015] it doesnt helpfully say "Error: Cannot guess decreasing argument of fix." until you Qed. [Mon Jul 20 23:02:56 2015] benzrf: ssreflect can do that quite easily [Mon Jul 20 23:03:05 2015] oh shoosh [Mon Jul 20 23:03:16 2015] and yes, how would it know that it can't guess the argument until you've provided all the code? [Mon Jul 20 23:03:35 2015] rewrite [X in _ = foo _ X]some_law. [Mon Jul 20 23:04:47 2015] true [Mon Jul 20 23:05:48 2015] augh [Mon Jul 20 23:05:50 2015] im tryna prove Lemma center_list_ind : forall (X : Type) (P : list X -> Prop), P [] -> (forall (x : X), P [x]) -> (forall (x y : X) (l : list X), P l -> P (x :: snoc l y)) -> forall l : list X, P l. [Mon Jul 20 23:06:05 2015] t h i s i s h e l l [Mon Jul 20 23:47:48 2015] aHA [Mon Jul 20 23:47:52 2015] BROKE IT [Mon Jul 20 23:47:55 2015] EAT THAT [Tue Jul 21 22:35:05 2015] when using [Print] on a lemma, is it printing the proof too? https://gist.github.com/lancejpollard/f5b43de2e24a25ea2a49 [Tue Jul 21 22:35:24 2015] new to coq, trying to understand what print is actually doing here [Tue Jul 21 22:36:09 2015] anyone know generally what that output is in the second one? [Tue Jul 21 23:22:23 2015] viatropos: Indeed, that’s the proof term corresponding to that proof. When you use [Admitted], Coq doesn’t bother saving a proof term, so you don’t get anything when you [Print] it. [Tue Jul 21 23:23:33 2015] alkabetz: Is a lot of that code showing the expanded proof `decide equality.`? [Tue Jul 21 23:24:16 2015] [decide equality] isn’t the actual proof. It’s a Ltac script which constructs the proof. [Tue Jul 21 23:25:03 2015] interesting, how do i tell that? [About decide equality.] doesn't work [Tue Jul 21 23:25:45 2015] Anything between [Proof] and [Qed] (or [Defined]) is interpreted as Ltac. [Tue Jul 21 23:26:00 2015] You can expand an Ltac tactic with [Print Ltac], but I think [decide equality] is built-in. [Tue Jul 21 23:26:06 2015] is there a way to look up where it's defined? [Tue Jul 21 23:26:45 2015] Similar to how [About bool_rec.] shows you "Expands to: Constant Coq.Init.Datatypes.bool_rec", so you know where it is [Tue Jul 21 23:26:56 2015] [Locate] should do the trick here, IIRC [Tue Jul 21 23:27:27 2015] On the other hand, [decide equality] is definitely a tactic notation, and the normal way I’d go about this ([Locate "decide equality"]) doesn’t seem to work. Does anybody else have ideas? [Tue Jul 21 23:45:22 2015] Anyone know why "Definition id : ID := fun A x => x." is defined in Coq.Init.Datatypes, while "Arguments id {A} x." is defined in Coq.Program.Basics? [Tue Jul 21 23:46:08 2015] just wondering if something magical is happening because "Arguments id {A} x." is defined in Basics.v (and maybe Arguments only applies to the current file or something) [Wed Jul 22 00:06:37 2015] In Coq.Init.Logic, there is "Notation "A -> B" := (forall (_ : A), B) : type_scope." and "Definition not (A:Prop) := A -> False." [Wed Jul 22 00:07:29 2015] but when doing [About not.] with all the Print options turned on, it shows [not : Prop -> Prop] [Wed Jul 22 00:08:07 2015] is there a way to make it expand the notation, so it shows like [forall (_ : A), False] or something? [Wed Jul 22 00:08:12 2015] or is this a special internal notation? [Wed Jul 22 00:08:45 2015] Unset Printing Notations. [Wed Jul 22 00:10:33 2015] johnw: is that different from the CoqIDE menu? https://cloudup.com/iq_2g4cNikc [Wed Jul 22 00:10:56 2015] I really don't know, I've never used CoqIDE before [Wed Jul 22 00:10:59 2015] ok [Wed Jul 22 00:12:03 2015] same situation for coqtop https://cloudup.com/iMVRi50irpb (still not expanding notation) [Wed Jul 22 00:14:03 2015] is -> a "special" notation? [Wed Jul 22 00:15:36 2015] when I use Unset Printing Notations here, with Proof General, and then do Print not., I don't see -> anymore [Wed Jul 22 00:15:55 2015] About not. gives: not : forall _ : Prop, Prop [Wed Jul 22 00:16:17 2015] interesting [Wed Jul 22 00:16:23 2015] what version are you using of coq? [Wed Jul 22 00:16:28 2015] 8.5b2 [Wed Jul 22 00:16:40 2015] i [Wed Jul 22 00:16:48 2015] i'm 8.5, maybe a bug was fixed [Wed Jul 22 00:16:54 2015] thanks for the help [Wed Jul 22 00:16:59 2015] any time [Wed Jul 22 01:02:52 2015] Is it explained anywhere why bool "true" and logic "True" are different in coq? [Wed Jul 22 01:03:31 2015] in programming languages like javascript I am used to `!true` meaning "false" and `!false` meaning "true" [Wed Jul 22 01:03:38 2015] i.e. not(true), not(false) [Wed Jul 22 01:04:21 2015] But [not True] and [not False] don't seem to fit that pattern in Coq, seems like that is in Coq.Bool.Bool. [Wed Jul 22 01:04:29 2015] wondering if i'm missing some reading or something [Wed Jul 22 01:09:32 2015] nvm will look at andb_prop and related [Wed Jul 22 01:09:59 2015] http://www.seas.upenn.edu/~cis500/current/sf/Logic.html#lab211 [Wed Jul 22 01:23:51 2015] actually still don't understand http://stackoverflow.com/questions/31554453/why-are-logical-connectives-and-booleans-separate-in-coq [Wed Jul 22 01:32:03 2015] viatropos: "not False <-> True" is provable in coq, as distinct from "not False = True". "Prop" is all about provability, which is why it's different to what you see in programming languages (where provability isn't even a thing) [Wed Jul 22 01:36:00 2015] viatropos: (you can assume "propositional extensionality" which lets you treat A <-> B as A = B; see Logic/ClassicalFacts [Wed Jul 22 01:37:32 2015] hmm, will have to think about what you're saying for a bit, thanks [Wed Jul 22 01:38:22 2015] what about from a practical perspective, like building models on top of the idea of true/false, does it have to be boolean vs. logic? [Wed Jul 22 01:38:51 2015] seems like you'd do everything with boolean true/false in the typical case, so then it's like what's the use for the logic version [Wed Jul 22 01:39:46 2015] guess that's what the question is sorta about too [Wed Jul 22 01:51:15 2015] viatropos: i think that's something of a stylistic choice? if you start with bool it's easy to convert to prop, not so much the other way around [Wed Jul 22 01:51:31 2015] ok good to know, thanks [Wed Jul 22 10:36:52 2015] is there someone who writes lots of coq in vim? what's your setup? [Wed Jul 22 12:42:34 2015] I'm on http://www.cis.upenn.edu/~bcpierce/sf/current/Hoare.html, Exercise: 4 stars (if1_hoare) - and when I enter the ceval definition, I get that SKIP is expected to have type Imp.com and not com... how come? [Wed Jul 22 14:22:36 2015] in Coq.Reals.Raxioms, there is an axiom called total_order_T. After applying it to two reals, it yields a ternary disjunction. Is there a way to destruct ternary disjunctions like this in a flat manner? I want to destruct this into three cases, with no nesting. [Wed Jul 22 14:23:01 2015] It looks like LibTactics has support for n-ary disjunctions, but I don't think I can use it with total_order_T. [Wed Jul 22 14:25:16 2015] I figured it out. Nevermind. [Thu Jul 23 00:30:03 2015] trying to better understand Prop in coq, don't quite get yet how to interpret this definition: "Definition relation := A -> A -> Prop" [Thu Jul 23 00:32:03 2015] can't seem to expand that notation with my version of coq [Thu Jul 23 00:32:34 2015] but it seems to expand to "Definition relation := forall (_, Type), forall (_, Type), Prop", is that correct? [Thu Jul 23 00:33:05 2015] how does this actually define a relation? [Thu Jul 23 00:33:21 2015] i imagine relation to be like "relation(A, B)", between two different types [Thu Jul 23 00:35:44 2015] nvm, seems to be answered here: "Coq standard library hijacks the generic term "relation" for this specific instance" http://www.cis.upenn.edu/~bcpierce/sf/current/Rel.html [Thu Jul 23 01:40:07 2015] viatropos : (just in case) this does not define a relation. It defines the type of relations on a type A. [Thu Jul 23 01:43:05 2015] Also, your expansion is not correct. The correct expansion would be: "Definition relation := forall (A : Type), forall (_ : A), forall (_ : A), Prop", something like that [Thu Jul 23 01:43:58 2015] Uh, sorry [Thu Jul 23 01:44:26 2015] "Definition relation := fun (A : Type) => forall (_ : A), forall (_ : A), Prop" rather [Thu Jul 23 01:46:01 2015] Ah, that makes more sense, thank you [Thu Jul 23 08:44:39 2015] Hey everyone! I was just wondering if there was a list of projects in Coq I could help with? I feel like trying my skills a bit ^^" [Thu Jul 23 10:04:05 2015] The term "cEq" has type "@c Γ σ p = @c Γ τ p'" while it is expected to have type "@c Γ σ p = @c Γ τ p'". [Thu Jul 23 10:04:31 2015] any idea why such an error would occur? [Thu Jul 23 10:05:07 2015] maybe it's not the same equality? [Thu Jul 23 10:05:29 2015] try 'Set Printing All.' [Thu Jul 23 10:05:49 2015] ahhh... thanks [Thu Jul 23 10:05:55 2015] I only hat printing Implicits [Thu Jul 23 10:06:22 2015] there is a coercion from the eq type :) [Thu Jul 23 10:06:26 2015] 'All' is often overkill but in cases like this, it's very useful [Thu Jul 23 10:09:14 2015] wonderful, thanks! :) [Fri Jul 24 04:59:05 2015] how important is Hoare2 in software foundations? There's hardly any formal exercises there, most are informal... and I have to admit I struggle a bit with the few formal ones, cause there's so many tactics to remember... [Fri Jul 24 08:58:19 2015] https://github.com/dasuxullebt/Pheap.v comments? [Fri Jul 24 15:16:55 2015] How to learn abstract nonsense? [Fri Jul 24 15:26:47 2015] SF, Smallstep, stuck at http://pastebin.com/X3wA0E96 , any tips? [Fri Jul 24 15:28:56 2015] How to learn abstract nonsense? [Fri Jul 24 15:29:48 2015] magistr: read aluffi's "alegbra: chapter 0" [Fri Jul 24 15:30:43 2015] nkaretnikov, it is a popular? [Fri Jul 24 15:30:57 2015] it is a good [Fri Jul 24 15:31:28 2015] but contains a lot of typos, so make sure to read the errata on the author's website [Fri Jul 24 15:31:49 2015] the author introduces everything in the book without omitting any details [Fri Jul 24 15:31:55 2015] that's why I like it and recommend it [Fri Jul 24 15:32:04 2015] there are more popular texts [Fri Jul 24 15:32:04 2015] nkaretnikov, ok, thanks [Fri Jul 24 15:32:24 2015] let me look it up [Fri Jul 24 15:32:25 2015] one sec [Fri Jul 24 15:33:11 2015] magistr: https://www.quora.com/What-is-the-best-textbook-for-Category-theory [Fri Jul 24 16:51:23 2015] Hi guys ! [Fri Jul 24 16:51:25 2015] Do you know if coq has every been used in physics ? [Fri Jul 24 16:52:31 2015] ever been* [Fri Jul 24 17:15:32 2015] if robots is physics: http://www.cs.cornell.edu/~aa755/ROSCoq/ [Fri Jul 24 17:27:56 2015] they left [Fri Jul 24 18:30:41 2015] /quit [Fri Jul 24 18:49:39 2015] hi. noob problem: "Cannot find library CpdtTactics in loadpath" in proofgeneral. I have "(custom-set-variables '(coq-prog-args '("-I" "/tmp/cpdt/src")))" in my ~/.emacs file and /tmp/cpdt/CpdtTactics.v exists [Fri Jul 24 18:50:42 2015] maybe replace /tmp/cpdt/src with /tmp/cpdt ? dunno [Fri Jul 24 18:50:59 2015] newsham: did you compile CpdtTactics.v [Fri Jul 24 18:51:00 2015] ? [Fri Jul 24 18:51:04 2015] no i didnt. [Fri Jul 24 18:51:14 2015] running make now :) [Fri Jul 24 18:51:49 2015] tada. thank you.. I did say "noob" :) [Fri Jul 24 18:52:39 2015] (apparently not so good at reading either) [Sat Jul 25 12:11:20 2015] Hey, do anyone know how to do recursive type on Coq? [Sat Jul 25 12:12:11 2015] lolisa: infinitely recursive? http://adam.chlipala.net/cpdt/html/Coinductive.html [Sat Jul 25 12:13:40 2015] not recursive data, but recursive type [Sat Jul 25 12:14:06 2015] I want to represent the type of UTLC, that is, u t. t -> t (t ~= t -> t) in Coq, but dont know how to do so... is there any facility? [Sat Jul 25 12:16:55 2015] lolisa: probably beyond my knowledge then. what's UTLC? [Sat Jul 25 12:17:31 2015] UnTyped Lambda Calculus, Sorry... [Sat Jul 25 12:23:01 2015] Oh, it seems like inductive can handle recursive type... Thx [Sat Jul 25 12:23:41 2015] lolisa: yeah, inductive should be fine i think [Sat Jul 25 12:23:55 2015] nah, dont think it work, thx anyway [Sat Jul 25 12:26:42 2015] lolisa: something like https://github.com/pi8027/lambda-calculus might help [Sat Jul 25 12:38:40 2015] aj, thx, I'll have a look [Sun Jul 26 14:32:50 2015] What does it mean when a record field is declared with :> rather than :? [Sun Jul 26 14:33:53 2015] I'm looking at a record definition with the following code: "Record ln_beta_prop x := { ln_beta_val :> Z ; ... }" [Sun Jul 26 14:34:33 2015] it would make perfect sense to me if it had "ln_beta_val : Z" rather than "ln_beta_val :> Z" [Sun Jul 26 14:35:20 2015] oh. I think this has something to do with typeclasses. [Sun Jul 26 14:37:34 2015] I think this site explains the :> notation: https://coq.inria.fr/refman/Reference-Manual022.html [Sun Jul 26 14:47:48 2015] haven't figured it out yet. Z doesn't seem to be a typeclass. [Sun Jul 26 14:50:18 2015] kclancy: I believe it introduces an implicit coercion between the record type and the field's type [Sun Jul 26 14:50:24 2015] see https://coq.inria.fr/refman/Reference-Manual021.html [Sun Jul 26 14:50:32 2015] jrw: thanks [Sun Jul 26 14:50:32 2015] search for ":>" [Sun Jul 26 18:29:59 2015] why do I sometimes see programs/proofs that return "True" and "False", which are types? [Sun Jul 26 18:30:09 2015] (instead of, for example, returning I:True) [Sun Jul 26 18:31:09 2015] maybe they are defining a type by recursion? [Sun Jul 26 18:32:21 2015] for example, defining All (ls : list T) : Prop, which returns True or False [Sun Jul 26 18:38:52 2015] oh i think i'm getting my levels mixed up :) [Sun Jul 26 19:10:16 2015] what I sometimes get confuseda bout is that I can freely construct True and False. (but, in moments of clarity I remember that I cant construct a value that inhabits False, but I can use "I : True" for the other) [Sun Jul 26 21:56:24 2015] does anyone here have algebra: chapter 0 at hand? I have a question about a proof in the book. in second part of proof of prop 2.3, I'm confused how the proof is valid. because there may be some set Z and we may choose some a', a'' : Z -> A for which the implication doesn't hold... [Sun Jul 26 21:57:01 2015] to be more specific, I don't understand how does that instantiation of Z to singleton sets make sense. [Mon Jul 27 12:48:50 2015] I'm trying to use eq_nat_is_eq from Arith.EqNat, but I'm getting failure on rewrite, and am a bit lost. here's the coq error: http://sprunge.us/KDZh [Mon Jul 27 12:51:01 2015] this occurs when I attempt a rewrite <- eq_nat_is_eq on a goal {n = m} + {n <> m} where n m : nat. [Mon Jul 27 12:51:18 2015] apologies if this is the wrong place for this kind of query [Mon Jul 27 13:19:33 2015] stelleg: definitely the right place. hang in there. [Mon Jul 27 13:44:33 2015] stelleg: what are you trying to achieve with that rewrite? do you want to replace the goal with {eq_nat n m} + {~ eq_nat n m} ? [Mon Jul 27 14:18:38 2015] jrw: yep, so that I could use eq_nat_decide directly [Mon Jul 27 14:18:58 2015] but I did find that eq_nat_dec is defined in Peano_dec, so I'm just using that instead [Mon Jul 27 14:19:48 2015] stelleg: I see, right. [Mon Jul 27 14:19:50 2015] as a first order approximation, you can only rewrite by things that end in an equality. [Mon Jul 27 14:20:27 2015] jrw: right, I thought that rewrites worked in general for iff as well, but I suppose its a bit more complex? [Mon Jul 27 14:21:03 2015] stelleg: yeah. rewriting by any other relation requires a bunch of side conditions showing that all the relevant parts of your goal respect the relation [Mon Jul 27 14:21:24 2015] jrw: thanks, that's helpful. [Mon Jul 27 14:21:45 2015] so in this case you'd have to show something like "if x is a program for deciding the proposition P, and if P <-> Q, then x is also a decider for Q" [Mon Jul 27 14:22:30 2015] and then you'd need to register that fact with coq. and then you'd be able to rewrite using iff under goals of the form {P} + {~P} [Mon Jul 27 14:22:48 2015] once you get it all set up, it can be really convenient. [Mon Jul 27 14:22:55 2015] but it's annoying to set up, IMHO [Mon Jul 27 14:24:16 2015] jrw: good to know, thanks! [Mon Jul 27 14:25:00 2015] stelleg: np. if you want to google for this, the word you're looking for is "setoid" [Mon Jul 27 14:26:23 2015] jrw: ah I come accross that term when googling the error message. I'll look into it more when I don't have a deadline looming :) [Mon Jul 27 14:26:34 2015] :) good luck! [Mon Jul 27 14:27:01 2015] thanks! [Mon Jul 27 15:00:19 2015] * is compiling CompCert on HaikuOS o/ [Mon Jul 27 23:15:52 2015] does coq have anything similar to haskell iorefs (i.e., mutable containers)? [Mon Jul 27 23:50:31 2015] nkaretnikov: no [Mon Jul 27 23:50:45 2015] nkaretnikov: the Ynot project may have something like that, but not in the Coq stdlib [Mon Jul 27 23:51:48 2015] johnw: hi, I was just thinking of translating this: https://github.com/FranklinChen/spreadsheet-haskell/blob/master/src/Spreadsheet.hs [Mon Jul 27 23:51:59 2015] I guess it could be possible without iorefs, but with them that'd be easier [Mon Jul 27 23:52:30 2015] there are way better way to model a spreadsheet than IORefs [Mon Jul 27 23:52:42 2015] google for "spreadsheet loeb function", for example [Mon Jul 27 23:53:02 2015] okay, noted. [Tue Jul 28 03:50:47 2015] where does coq store the equality schemes used for automatic generation? [Tue Jul 28 03:51:54 2015] I have a type parameterized over a module variable and I'd like to generate an equality over it [Tue Jul 28 03:52:32 2015] the module asks for a hypothesis foo_eq_dec: forall x y : foo, { x = y } + { x <> y } [Tue Jul 28 03:52:54 2015] so it should be possible to have an inductive type with auto generated equality, which internally uses foo [Tue Jul 28 04:20:15 2015] hmpf seems not even possible for list nat [Wed Jul 29 03:12:41 2015] hi, when I do "Proof with <...>." in Coq, it screws up the intendation for the rest of the file. Am I missing something? [Wed Jul 29 03:32:59 2015] thatd be an editor issue i think [Wed Jul 29 05:39:43 2015] Hi! [Wed Jul 29 05:40:11 2015] Is there a setoid instance for the identity relation? [Wed Jul 29 05:42:09 2015] I mean it's trivial to write, but I wanted to know if there is a stanard reference [Wed Jul 29 06:33:37 2015] anyone wanna walk me through this one? : match goal with H1: forall x, ?P x -> ?L = ?R, H2: ?P ?X |- _ [Wed Jul 29 06:34:08 2015] => rewrite (H1 X H2) in * [Wed Jul 29 06:37:53 2015] It replaces ?L with ?R in your current goal [Wed Jul 29 06:38:09 2015] If you have a hypothesis of the form forall x, P x -> L = R [Wed Jul 29 06:50:14 2015] so basically, if you have H2: ?P ?X, it matches forall x, ?P x, so you can apply it and get ?L = ?R, ... [Wed Jul 29 06:50:42 2015] so it basically takes P x -> A = B + P x , and provides A = B ? [Wed Jul 29 08:06:03 2015] xeno_: yeah [Wed Jul 29 09:57:22 2015] is there a possibility to apply omega to N? [Wed Jul 29 09:57:25 2015] instead of nat? [Wed Jul 29 11:59:00 2015] hm. I have a proof that uses "do" and takes long. is it possible to output messages while it runs? [Wed Jul 29 11:59:06 2015] such that I see how far it currently is? [Wed Jul 29 11:59:27 2015] [especially, I see that it is not trapped in an infinite loop, etc., and estimate the time it needs]? [Wed Jul 29 13:44:39 2015] hm. [Wed Jul 29 13:46:46 2015] ok, I have the following problem: I have a finite but large number of cases for a proof. all the cases work similarily. [Wed Jul 29 13:47:35 2015] it is a proposition of the form "forall n, m1 <= n <= m2 -> A", and I can prove A with a simple strategy. [Wed Jul 29 13:47:43 2015] provided I have n given. [Wed Jul 29 13:48:07 2015] n cannot be a nat, because m2 is too large. [Wed Jul 29 13:48:31 2015] I tried N, but the proof is *slow*. [Wed Jul 29 13:48:38 2015] why is "m2 too large"? [Wed Jul 29 13:48:41 2015] Now I try int31. [Wed Jul 29 13:48:51 2015] johnw: m2 = 32768 [Wed Jul 29 13:49:28 2015] is it too large because you want to extract the code? [Wed Jul 29 13:49:34 2015] no. [Wed Jul 29 13:49:43 2015] it is too large because coq stack-overflows. [Wed Jul 29 13:49:43 2015] for the purposes of your proof, do you even need to know what m2 is? [Wed Jul 29 13:49:55 2015] johnw: yes. [Wed Jul 29 13:50:33 2015] johnw: specifically, it is just a finite range of stuff that is given. so the theorem can be proved by just "iterating" through all possibilities. [Wed Jul 29 13:51:02 2015] (and actually, it cannot be proved much simpler ...() [Wed Jul 29 13:51:04 2015] ) [Wed Jul 29 13:51:25 2015] i'm just wondering if there's a different way of expressing the problem [Wed Jul 29 13:51:52 2015] probably. but this will only make the case more complicated. [Wed Jul 29 13:52:15 2015] I actually would prefer to just use the "brute force" method. [Wed Jul 29 15:21:49 2015] is it possible for coq to fail to find a matching subterm when it's clearly there? [Wed Jul 29 15:23:21 2015] stelleg: it's happened to me ;-; [Wed Jul 29 15:23:27 2015] have you tried Set Printing All for debug [Wed Jul 29 15:24:21 2015] benzrf: ah thanks, looks like maybe a type alias issue [Wed Jul 29 15:24:26 2015] :] [Wed Jul 29 15:29:01 2015] benzrf: thanks again, that fixed it. [Wed Jul 29 15:29:25 2015] was disconcerting seeing that. "but it matches character for character!" [Wed Jul 29 15:36:31 2015] can I apply omega to N? [Wed Jul 29 15:36:36 2015] the omega tactic. [Wed Jul 29 15:39:42 2015] hm. I just use Z [Wed Jul 29 15:39:44 2015] nvm [Wed Jul 29 16:40:38 2015] anyone out there? [Wed Jul 29 19:07:06 2015] stelleg: i know that feel [Thu Jul 30 03:52:33 2015] any idea, why Coq.MSets.MSetRBT.Make(Nat_as_OT) produces an error about eq_equiv missing in Nat_as_OT? [Thu Jul 30 03:53:21 2015] in MSetRBT we have Module Make (X: Orders.OrderedType) [Thu Jul 30 03:53:55 2015] and in Structures.OrderedTypeEx there is [Thu Jul 30 03:53:57 2015] Module Nat_as_OT <: UsualOrderedType. [Thu Jul 30 03:56:59 2015] ah I had to import Coq.MSes.MSets first [Thu Jul 30 10:27:29 2015] is it possible to use an MSet with elements and containers in Set instead of Type? [Fri Jul 31 04:27:16 2015] Hi. In this small proof, destruct seems to "drop" H entirely, without introducing any evidence. E.g. in the first subgoal, I'd expect m and n be unified, but that doesn't happen. Can someone please explain what's going on and how to do this properly? [Fri Jul 31 04:27:20 2015] http://lpaste.net/4485317291621220352 [Fri Jul 31 05:01:04 2015] I think this addresses my question: https://homes.cs.washington.edu/~jrw12/dep-destruct.html [Fri Jul 31 16:31:05 2015] <`^_^v> i have a theorem: length (l1 ++ (x :: l2)) = n -> S (length (l1 ++ l2)) = n. [Fri Jul 31 16:31:17 2015] <`^_^v> why can't i apply it to my goal? length (t ++ h :: t) = S (length (t ++ t)) [Fri Jul 31 16:32:39 2015] Does it go through if you do [symmetry] first? [Fri Jul 31 16:33:25 2015] <`^_^v> no [Fri Jul 31 16:55:51 2015] what does apply say, after you use symmetry? [Fri Jul 31 17:02:46 2015] <`^_^v> unable to find an instance for the variable x. but doing apply with (x:=h) actually worked [Fri Jul 31 17:03:09 2015] <`^_^v> hooray [Fri Jul 31 17:03:11 2015] yeah, was gonna say [Fri Jul 31 17:03:14 2015] Ah right :) [Sat Aug 1 23:45:11 2015] fwiw, discovered coquille, a vim mode that works similar to proof general. haven't used it much, but looks promising based on what i've tried [Sun Aug 2 07:54:29 2015] hi, SF, STLC final task, I tend to end up with http://pastebin.com/pqgJ1BAF [Sun Aug 2 07:54:32 2015] how do I prove that? [Sun Aug 2 07:57:25 2015] induction on T11 [Sun Aug 2 11:42:33 2015] what is a existential types? [Sun Aug 2 12:07:13 2015] what nice book to learn type theory? [Sun Aug 2 12:10:44 2015] some people like https://www.cis.upenn.edu/~bcpierce/tapl/ and its followup https://www.cis.upenn.edu/~bcpierce/attapl/ [Sun Aug 2 12:12:14 2015] sanooj, great thank [Sun Aug 2 12:51:43 2015] prolog is nice language? [Sun Aug 2 14:54:56 2015] magistr: it's a language worth knowing [Sun Aug 2 14:55:16 2015] TAPL is great [Sun Aug 2 14:55:38 2015] sanooj: there's also Software Foundations, but types is not the main focus there [Sun Aug 2 14:56:53 2015] xeno_, ok, i must begin on prolog [Sun Aug 2 15:02:58 2015] impication is very weird thing in logic [Sun Aug 2 15:14:25 2015] A->B is not a consequent [Sun Aug 2 15:14:53 2015] A may be a false, but B is true [Sun Aug 2 15:16:06 2015] What's the matter with falsehood implying truth? [Sun Aug 2 15:19:30 2015] the truth follows from everything [Sun Aug 2 15:19:59 2015] from false or true [Sun Aug 2 15:27:43 2015] it is must be logical AND [Sun Aug 2 15:34:27 2015] hello. in https://coq.inria.fr/stdlib/Coq.FSets.FMapAVL.html is there anything comparable to List.Forall ? [Sun Aug 2 15:34:32 2015] for FMapAVL I mean? [Sun Aug 2 15:40:36 2015] schoppenhauer: I don't recall there being one but you could define it using In. [Sun Aug 2 15:41:18 2015] jrw: I was trying to define it with MapsTo. but probably I should try In. [Sun Aug 2 15:42:42 2015] jrw: ah. the problem was that In only tells about the keys. I need to quantify over the values. [Sun Aug 2 15:45:37 2015] schoppenhauer: no you're right, you need MapsTo in that case. what went wrong when you tried that? [Sun Aug 2 15:51:13 2015] jrw: http://lpaste.net/2104595620705599488 I am stuck here. [Sun Aug 2 15:52:49 2015] it should be something around using one of the MapsTo_$n lemmata [Sun Aug 2 15:52:56 2015] but I am somehow stuck [Sun Aug 2 15:55:52 2015] schoppenhauer: yeah it looks like there aren't enough lemmas about M.add [Sun Aug 2 15:56:34 2015] what nice book of graph theory? [Sun Aug 2 15:56:40 2015] you need something that says [M.MapsTo k v (M.add k' v' h) -> (k = k' /\ v = v') \/ M.MapsTo k v h] [Sun Aug 2 15:57:08 2015] magistr: not sure this is super on topic, but I like Diestel's GTM "Graph Theory" :) [Sun Aug 2 15:57:50 2015] jrw, ok, i see it, thanks [Sun Aug 2 16:08:22 2015] jrw: any idea how to get such a thing? [Sun Aug 2 16:08:59 2015] I'm currently trying myself, but the API is a bit strange. [Sun Aug 2 16:09:09 2015] schoppenhauer: I actually have no idea how to use all the FSet/FMap machinery. from like 2 seconds of looking around it looks like the definition of add is exposed, so you could just prove it yourself. [Sun Aug 2 16:10:48 2015] I'll have a go at it [Sun Aug 2 16:22:40 2015] schoppenhauer: okay I think I got it. something like this? https://gist.github.com/wilcoxjay/88f64f6c2d8574263ef6 [Sun Aug 2 16:25:03 2015] updated to clean up the first proof a bit [Sun Aug 2 16:32:12 2015] the FMap stuff is bizarrely difficult to use [Sun Aug 2 16:32:12 2015] jrw: thx. I had to adapt it slightly, my coq version doesn't automatically unify in the line "apply add_MapsTo in Hadd", but it was a trivial change. thank you! [Sun Aug 2 16:34:17 2015] cool. glad it works [Sun Aug 2 16:48:10 2015] what does ? mean in intros? [Sun Aug 2 16:48:20 2015] "I don't care how this arg is named"? [Sun Aug 2 16:48:38 2015] yup [Sun Aug 2 16:48:41 2015] k [Sun Aug 2 16:57:35 2015] hm. I still don't quite understand how these +, *, -, bullets work. [Sun Aug 2 16:57:42 2015] they are there for focussing subproofs [Sun Aug 2 16:57:49 2015] as far as I see. [Sun Aug 2 16:58:02 2015] but what if, for example, I have more than 3 levels? [Sun Aug 2 16:58:14 2015] schoppenhauer: :/ yeah you have to use braces to go deeper [Sun Aug 2 16:58:21 2015] or just don't do that :) [Sun Aug 2 16:58:39 2015] hm. ok, then I rather use the old ; [ ... | ... ] method [Sun Aug 2 16:58:47 2015] In 8.5, you can also use ++, **, -- and so on up to 3 or 4 characters ^^' [Sun Aug 2 16:59:32 2015] Cypi: whoa really? [Sun Aug 2 16:59:34 2015] mind blown [Sun Aug 2 16:59:49 2015] Yeah, technology is amazing these days [Sun Aug 2 17:00:30 2015] Cypi: neat, I didn't know that [Sun Aug 2 17:00:57 2015] Oh, actually, you seem to be able to use any combination of +/*/- and any number of characters :o . Didn't know that. [Sun Aug 2 17:01:36 2015] do people really use bullets? [Sun Aug 2 17:01:41 2015] i do, all the time [Sun Aug 2 17:01:42 2015] I do, yes [Sun Aug 2 17:01:50 2015] anytime I have >2 subgoals [Sun Aug 2 17:01:56 2015] I don't usually, but I see that they might be useful. [Sun Aug 2 17:02:09 2015] with 2 subgoals, I indent the first only [Sun Aug 2 17:02:14 2015] but with >2, I use a bullet for each [Sun Aug 2 17:02:17 2015] i find sf's cases much better suited for this sort of thing [Sun Aug 2 17:02:17 2015] I usually bring all my proofs into braced form afterwards. [Sun Aug 2 17:02:32 2015] I use cases too if it's inductive proposition with a lot of different alternatives [Sun Aug 2 17:02:45 2015] interesting [Sun Aug 2 17:02:48 2015] since cases make it easier to find breakage due to changes in the data type [Sun Aug 2 17:03:02 2015] oh, yeah [Sun Aug 2 17:03:06 2015] but using cases everywhere is laborious [Sun Aug 2 17:03:12 2015] there's an emphasis on that in sf [Sun Aug 2 17:03:30 2015] I never use Case with nat induction, for example [Sun Aug 2 17:03:38 2015] the zero case is almost always so tiny, I just indent that one [Sun Aug 2 17:03:44 2015] wouldn't indentation work, or are you afraid to misalign things? [Sun Aug 2 17:03:53 2015] what, with 2> subgoals? [Sun Aug 2 17:03:58 2015] yeah [Sun Aug 2 17:04:01 2015] how do you indent that? [Sun Aug 2 17:04:06 2015] Insteadof indenting, I sometimes use { } when I generated one tiny subgoal along the proof [Sun Aug 2 17:04:47 2015] johnw: separate each goal with an empty line plus move stuff further to the right if necessary [Sun Aug 2 17:04:59 2015] isn't that equivalent to using bulletns? [Sun Aug 2 17:05:05 2015] you're just using a blank line as your bullet [Sun Aug 2 17:05:06 2015] Cypi: what's the rule for {}? [Sun Aug 2 17:05:15 2015] The rule? What do you mean? [Sun Aug 2 17:05:24 2015] Cypi: can I use them anywhere? [Sun Aug 2 17:05:29 2015] I think so? [Sun Aug 2 17:05:32 2015] k [Sun Aug 2 17:05:36 2015] I think he means where are they syntactically valid... [Sun Aug 2 17:05:43 2015] yeah that [Sun Aug 2 17:06:06 2015] is it a grouping construct that applies anywhere tactics can be used? [Sun Aug 2 17:06:18 2015] i.e., destruct x; { foo; bar }. [Sun Aug 2 17:06:19 2015] I believe they are basically the same thing as bullets, except that you have to close it [Sun Aug 2 17:06:21 2015] johnw: the point I'm trying to make is that bullets add more noise. though, maybe i'm just not used to thme [Sun Aug 2 17:06:22 2015] oh, no [Sun Aug 2 17:06:28 2015] them* [Sun Aug 2 17:06:35 2015] nkaretnikov: "-" adds less noise than a blank line and extra indentation [Sun Aug 2 17:07:28 2015] johnw : sorry for being unclear, you cannot use them inside of tactics, it's, like bullets, a focusing/unfocusing tool, except that you have to close it yourself. [Sun Aug 2 17:07:36 2015] ah, I see [Sun Aug 2 17:08:00 2015] So the usage could be [assert (stuff). { proof. of. stuff. with. tactics. } rest. of. the. proof.] [Sun Aug 2 17:10:53 2015] hi, if I have H = foo, and H2 = foo -> bar, and I do "apply H2 in H", then bar replaces foo in H, and H is lost [Sun Aug 2 17:11:07 2015] can I avoid that (and create a new hypothesis), and if not, is there a shortcut to copy H? [Sun Aug 2 17:11:14 2015] pose will copy the proof [Sun Aug 2 17:11:15 2015] pose proof H [Sun Aug 2 17:11:22 2015] You can do [pose proof (H2 H)] directly [Sun Aug 2 17:11:23 2015] also, you don't need to do the apply [Sun Aug 2 17:11:27 2015] just use (H2 H) where you need to [Sun Aug 2 17:12:01 2015] Also, if it makes sense in your proof, you can use [specialize (H2 H)] (which will replace H2 instead) [Sun Aug 2 17:13:25 2015] well, I sorta want (H2 H) stored as a new hypothesis, I just don't want to overwrite the old ones... at least I don't wanna overwrite H. [Sun Aug 2 17:13:31 2015] if I replace H2 it would be ok [Sun Aug 2 17:13:49 2015] then pose proof (H2 H) [Sun Aug 2 17:17:20 2015] thanks [Mon Aug 3 04:37:28 2015] hi [Mon Aug 3 04:38:01 2015] is there anyway to tell coq that a section parameter should be considered as an implicit parameter outside the section? [Mon Aug 3 04:50:12 2015] ok, Context! [Mon Aug 3 04:50:29 2015] You can use curly braces around parameters I believe? [Mon Aug 3 04:50:45 2015] Nvermind, you can't :D [Mon Aug 3 04:51:06 2015] you can't :) [Mon Aug 3 04:51:42 2015] but apparently you can with Context.. but I'm not sure how it behaves w.r.t sections [Mon Aug 3 04:55:31 2015] seems to behave as expected, great [Mon Aug 3 13:32:29 2015] I have a bunch of lemmas, and I’d like Coq to do a breadth-first search over the tree generated by rewriting with each of them, possibly multiple times, and trying to do [reflexivity] at each node. How do I do so? [Mon Aug 3 13:40:59 2015] alkabetz: have you read about autorewrite and tactic databases? [Mon Aug 3 13:41:07 2015] using smt to do static analysis of binaries [Mon Aug 3 13:41:11 2015] http://static1.squarespace.com/static/53a64cc2e4b0c63fc41a3320/t/55763177e4b099e5803400e7/1433809298780/Course+Overview.pdf [Mon Aug 3 13:54:17 2015] alkabetz: I'm sure you've read http://www.cis.upenn.edu/~bcpierce/sf/current/UseAuto.html? [Mon Aug 3 13:55:33 2015] ianjneu: I forgot you could provide a specific hint database to autorewrite! I think that’ll work nicely. Thanks! [Mon Aug 3 15:03:53 2015] I have problems getting CoqIDE to work with a dark theme. [Mon Aug 3 15:04:29 2015] I can't override syntax highlighting with coqide-gtk2rc. [Mon Aug 3 15:08:09 2015] Editing ide/tags.ml and compiling is not an option, because I don't have the disk space for it. [Mon Aug 3 15:13:32 2015] could you get Gdk.Color.get_system_colormap() to return something you like? [Mon Aug 3 15:13:56 2015] then you could make "orange red" map to whatever you want [Mon Aug 3 15:14:37 2015] Could I perhaps LD_PRELOAD that? [Mon Aug 3 15:15:11 2015] I expect that's a sledgehammer, but sure you could do that. :) [Mon Aug 3 15:16:03 2015] What options do I have? I can't lecture the developers on reasonable user interface design and have them fix it on the spot. [Mon Aug 3 15:17:28 2015] I don't know enough about gtk/gdk to say how gdk_colormap_get_system() works and if it's per-app configurable. [Mon Aug 3 15:21:22 2015] Do you know the exact name of the procedure? [Mon Aug 3 15:22:19 2015] gdk_colormap_get_system() [Mon Aug 3 15:22:51 2015] https://developer.gnome.org/gdk2/stable/gdk2-Colormaps-and-Colors.html [Mon Aug 3 15:23:01 2015] That seems to be in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 for me. Let's tear it open. [Mon Aug 3 15:23:11 2015] gtg, it be commutin time. [Mon Aug 3 15:33:36 2015] what is βι-reduction rule? is this any different than β-reduction rule? [Mon Aug 3 15:35:33 2015] it's that just beta followed by iota? [Mon Aug 3 15:35:53 2015] iota "simplifies a single match term by determing which pattern matches" [Mon Aug 3 15:36:20 2015] oh it reduces a known case. OK, thanks. [Mon Aug 3 15:53:23 2015] I got gdk_color_parse overridden, but apparently CoqIDE only uses that for some of the colors. [Mon Aug 3 15:59:57 2015] Okay, there we go. I'll put it online in case some of you want it. [Mon Aug 3 17:57:06 2015] There we go: https://github.com/Tuplanolla/coqidefix [Tue Aug 4 09:20:52 2015] hi. is anyone here who is familiar with VST? [Tue Aug 4 09:20:59 2015] I need a bit of ... beginner's help. [Tue Aug 4 09:44:19 2015] more specifically, I don't even know how to specify what my program does, because I don't get the formalism. [Tue Aug 4 10:06:14 2015] hm. I'll just ask so [Tue Aug 4 11:04:14 2015] schoppenhauer: you should use the tag verifiable-c on SO, Andrew Appel follows it I believe [Tue Aug 4 11:04:31 2015] Ptival: yes, I do. [Tue Aug 4 11:20:32 2015] whats nice material on mathematical logic? [Tue Aug 4 11:26:28 2015] Here's a good book for basic concepts: http://tellerprimer.ucdavis.edu/ [Tue Aug 4 11:29:20 2015] Tuplanolla, thanks [Tue Aug 4 13:31:07 2015] how to learn Homotopy Type Theory? [Tue Aug 4 13:40:25 2015] magistr: the book is pretty good and readable IMO [Tue Aug 4 13:41:17 2015] jrw, whats book? [Tue Aug 4 13:45:58 2015] This one: http://homotopytypetheory.org/book/ [Tue Aug 4 13:46:32 2015] ok [Tue Aug 4 14:05:22 2015] ok. so ... my question about vst ... http://stackoverflow.com/questions/31813725/array-range-in-precondition [Wed Aug 5 07:45:33 2015] still no answers ;_; @ http://stackoverflow.com/questions/31813725/array-range-in-precondition [Wed Aug 5 08:24:52 2015] hm. different question: What exactly does PArray (in native coq) do? are the created arrays just immutable, or is it some kind of diffarray? [Wed Aug 5 08:26:57 2015] when looking at kernel/parray.ml, it looks like diffarrays, but not sure (I'm not really familiar with ocaml) [Wed Aug 5 08:55:59 2015] ok they are diffarrays. thx. [Thu Aug 6 18:03:25 2015] hi. I'm trying to compile my stuff with native-coq. problem: when trying to compile one of my .v-files, I get the error message "Error: Unbound module Nativevalues" [Thu Aug 6 18:06:07 2015] do I need to install some external library for ocaml? [Thu Aug 6 18:37:54 2015] hm. and coqtop works but rejects my destruct ... eqn:... [Thu Aug 6 18:38:02 2015] it doesn't like eqn:, apparently [Thu Aug 6 18:53:51 2015] ok, apparently, it wants _eqn: [Thu Aug 6 18:55:01 2015] schoppenhauer: "destruct (find_notP x) eqn: Hfound." works fine for me fwiw. _eqn works too though [Thu Aug 6 18:55:30 2015] Hello [Thu Aug 6 18:55:43 2015] aj: under native-coq? [Thu Aug 6 18:55:51 2015] hi QuanticPotato [Thu Aug 6 18:56:04 2015] Do you know if there is any paper dealing with Coq for game AI ? [Thu Aug 6 18:56:17 2015] (Connect Four for example) [Thu Aug 6 19:06:30 2015] In fact, do you think it could be interesting to formalize a Connect Four strategy in Coq ? (I'm thinking of the Velena algo) [Thu Aug 6 19:06:55 2015] (I'm looking for a TIPE subject) [Thu Aug 6 19:09:17 2015] hm, what would you prove about the algorithm? [Thu Aug 6 19:10:25 2015] QuanticPotato: I, for one, would be interested in seeing it. but that's probably because I'm not that familiar with the area itself. I think it would be a good exercise to formalize whatever the results of the area are. [Thu Aug 6 19:10:42 2015] artart78, I don't really know to be honnest ^^ [Thu Aug 6 19:10:46 2015] you could prove if there is or isn't a strategy that can always win [Thu Aug 6 19:11:19 2015] johnw, That's the interesting point ! The first player *always* win [Thu Aug 6 19:11:30 2015] Isn't it supposed to be a draw? [Thu Aug 6 19:11:45 2015] I mean, for Connect Four [Thu Aug 6 19:11:56 2015] (Not tic tac toe) [Thu Aug 6 19:12:00 2015] Yes, I meant Connect four [Thu Aug 6 19:12:39 2015] It is described in this thesis : http://www.informatik.uni-trier.de/~fernau/DSL0607/Masterthesis-Viergewinnt.pdf [Thu Aug 6 19:12:50 2015] Ok, sorry :) [Thu Aug 6 19:13:30 2015] that would be interesting for sure to show that there is a winning strategy for the first player [Thu Aug 6 19:13:36 2015] Cypi, No problem, it's quite hard to figure out :p [Thu Aug 6 19:13:55 2015] but maybe it's a bit hard to prove [Thu Aug 6 19:14:10 2015] Yes, probably :/ [Thu Aug 6 19:14:53 2015] I have using Coq only for one year (Trying to formalize my math courses) [Thu Aug 6 19:16:43 2015] In the mock TIPE, I tried to prove that the signature of a composition is the product of the signatures (for permutations, but I'm not sure of the names in english) [Thu Aug 6 19:17:01 2015] It's was too hard (Or at least too long ^^), and the proof was incomplete [Thu Aug 6 19:18:07 2015] shouldn't "proving" be possible by just brute forcing? [Thu Aug 6 19:18:17 2015] It might take a long time though. [Thu Aug 6 19:18:20 2015] bleh, you're crazy haha [Thu Aug 6 19:19:41 2015] but with modern supercomputers? [Thu Aug 6 19:20:13 2015] let's get an FPGA and build a tuned ConnectFour solver [Thu Aug 6 19:20:52 2015] Nine Men's Morris was solved this way, wasn't it? [Thu Aug 6 19:27:31 2015] ConnectFour has already been proved by brute force [Thu Aug 6 19:27:33 2015] https://en.wikipedia.org/wiki/Connect_Four [Thu Aug 6 19:30:33 2015] so better concentrate on transfinite games like ordinal chomp [Thu Aug 6 19:33:19 2015] did not know that game, funny topic [Thu Aug 6 19:33:40 2015] Brute-forcing would literally take forever in that case indeed. [Thu Aug 6 19:35:25 2015] Cypi: "This took about 40,000 hours of computation on the Sun and SGI workstations at the CWI." [Thu Aug 6 19:35:45 2015] 4.56 years of compute time [Thu Aug 6 19:35:50 2015] < forever [Thu Aug 6 19:36:05 2015] I'm talkking about ordinal chomp :p [Thu Aug 6 19:36:08 2015] talking* [Thu Aug 6 19:36:19 2015] ahh [Thu Aug 6 19:37:43 2015] hah, "The case of ω × ω × ω Chomp is a notable open problem; a $100 reward has been offered[1] for finding a winning first move." [Thu Aug 6 19:37:51 2015] money in proofs, hurray [Thu Aug 6 19:37:54 2015] $100, wouhou [Thu Aug 6 20:06:46 2015] johnw: have you seen proofmarket.org? [Thu Aug 6 20:07:30 2015] i like that there's a proof of false :) [Fri Aug 7 03:43:47 2015] what a nice material to learn homology theory? [Fri Aug 7 05:59:20 2015] <{AS}> Hi, does anyone know if code extractor of Coq (to Caml) has been proven correct? [Fri Aug 7 08:48:16 2015] is there some easy way to separate A /\ B /\ C /\ D (the number of propositions is just an example) without having to run a bunch of inversions and clearing manually? [Fri Aug 7 08:49:15 2015] intuition might do that for you? [Fri Aug 7 08:49:22 2015] (among other things.) [Fri Aug 7 08:49:41 2015] ah perfect, thanks a lot [Fri Aug 7 08:49:56 2015] [repeat match goal with H : _ /\ _ |- _ => destruct H end] can also split everything and will do less than intuition [Fri Aug 7 08:50:33 2015] and if you just want to split one [H : A /\ B /\ C /\ D], you can do something like [destruct H as [? [? [? ?]]].] I believe? (didn't not test, not sure) [Fri Aug 7 08:51:24 2015] cocreature split ? [Fri Aug 7 08:51:29 2015] oh yeah good point Cypi [Fri Aug 7 08:52:19 2015] Anarchos: nope, I want to split a hypotheses not the goal [Fri Aug 7 08:52:29 2015] but the solutions already provided all do the trick [Fri Aug 7 08:58:21 2015] hi [Fri Aug 7 10:39:14 2015] hello everyone! I have a small code snipplet implementing Cantor's diagonal argument, http://pastebin.com/8tCZHJ2b, but I'm wondering why the attempted use of eauto in the end does not work, while an explicit successive invocation of eapply and eauto does. [Fri Aug 7 11:38:15 2015] {AS}: the extractor is not verified. you'd need to verify it wrt a formal semantics of both Coq and OCaml, neither of which exist afaik [Fri Aug 7 11:38:52 2015] habecker: I can't see your paste, but that kind of problem is common and usually comes from the fact that eapply "tries harder" than eauto to unify the lemma with the goal [Fri Aug 7 11:38:59 2015] Ikyushii: hi :) [Fri Aug 7 11:51:09 2015] jrw: ah ok. is there any way to change this? [Fri Aug 7 12:09:27 2015] <{AS}> jrw: Thanks! [Fri Aug 7 12:09:58 2015] <{AS}> I would have expected that Gallina at least had a formal semantics :) [Fri Aug 7 12:12:01 2015] {AS}: specified in which language? [Fri Aug 7 12:12:10 2015] it probably does on paper [Fri Aug 7 12:12:19 2015] habecker: not that I know of :( [Fri Aug 7 12:12:59 2015] <{AS}> ianjneu: I would think that Gallina itself would suffice [Fri Aug 7 12:13:10 2015] <{AS}> F* is self certified [Fri Aug 7 12:14:54 2015] <{AS}> But as jrw mentioned, pen and paper would be fine too. That is how SML is specified [Fri Aug 7 12:16:02 2015] I don't trust anything from the F* crowd. Unethical academic practices. [Fri Aug 7 12:16:41 2015] <{AS}> ianjneu: I do not know anything about the authors. [Fri Aug 7 12:17:13 2015] <{AS}> Just thought the project seemed nice [Fri Aug 7 12:17:35 2015] I'll just channel Dan Friedman and say, "don't believe anything until you implement it yourself." [Fri Aug 7 12:21:13 2015] F*? [Fri Aug 7 12:21:44 2015] ehhh, Microsoft Research [Fri Aug 7 12:21:46 2015] <{AS}> https://www.fstar-lang.org [Fri Aug 7 12:26:19 2015] ianjneu what unethical academic practices did you notice ? [Fri Aug 7 12:29:26 2015] They write papers about underpowered languages that they still call "f star" but with lowercase or something, and then later make the claim that what they proved was for the full F* [Fri Aug 7 12:29:50 2015] lol [Fri Aug 7 12:30:31 2015] ianjneu microsoft still case unaware ? :) [Fri Aug 7 12:30:47 2015] hah [Fri Aug 7 12:37:22 2015] proofs by overloading notation can be quite powerful [Fri Aug 7 12:39:44 2015] habecker: as long as they typecheck. [Sat Aug 8 22:32:22 2015] what are 'proofs by overloading notation'? [Sun Aug 9 13:44:06 2015] hi. anyone here who has some initial experience with vst? [Sun Aug 9 13:44:27 2015] because I currently try to learn it, and I am stuck with an example. [Sun Aug 9 13:44:38 2015] (another one than the unanswered one I already posted) [Sun Aug 9 16:29:53 2015] schoppenhauer: I am also trying to learn it. what's your question? [Sun Aug 9 16:43:26 2015] jrw: http://stackoverflow.com/questions/31907414/proving-correctness-of-xor-swapping [Sun Aug 9 16:43:42 2015] this is interesting because it is a common optimization [Sun Aug 9 16:44:38 2015] and it took me a day to even figure out the specification in vst. somehow, I don't really get it :\ [Sun Aug 9 16:51:35 2015] one problem is thzat all the examples are either at a much higher level, or just a concatenation of two tactics ... [Sun Aug 9 16:51:57 2015] and ... in vst 1.5, it appears that lots of stuff is not available. [Sun Aug 9 16:52:07 2015] from the book PLCC [Sun Aug 9 16:52:11 2015] or has been renamed [Sun Aug 9 16:55:24 2015] yeah it's rough going [Sun Aug 9 16:55:40 2015] I'm trying to fix my vst installation... [Sun Aug 9 17:02:05 2015] my installation works. [Sun Aug 9 17:02:11 2015] I have a nix-expression that installs it. [Sun Aug 9 17:37:05 2015] jrw: so ... you also have no idea? [Sun Aug 9 17:37:23 2015] schoppenhauer: well I got my VST working :) [Sun Aug 9 17:37:30 2015] ++ [Sun Aug 9 17:37:35 2015] I don't understand why [forward] doesn't work [Sun Aug 9 17:37:42 2015] also do you know what MORE_COMMANDS means? [Sun Aug 9 17:37:45 2015] me neither. [Sun Aug 9 17:37:49 2015] no. [Mon Aug 10 13:53:08 2015] hi. hm. ok, vst again. does anyone know how I can evaluate stuff in SEP (...), which contains eval_binop? [Mon Aug 10 13:54:12 2015] sounds like that's SEP to me :> [Mon Aug 10 14:00:44 2015] benzrf: ? [Mon Aug 10 14:01:11 2015] sep = somebody else's problem [Mon Aug 10 14:02:01 2015] i don't really understand want to acronymize everything, since they end up needing to say the full words anyway [Mon Aug 10 14:03:58 2015] i dont rly say 'sep' [Mon Aug 10 14:04:04 2015] i just used it bc schoppenhauer said 'sep' meaning something else [Mon Aug 10 14:04:16 2015] ah, cute! [Mon Aug 10 14:04:18 2015] im not sure that 'sep' has been used that way outside of h2g2 anyway [Mon Aug 10 14:04:23 2015] I just had a co-worker that used to do that [Mon Aug 10 14:04:29 2015] I never understood what he was saying [Mon Aug 10 18:14:27 2015] Hi I have a question regarding proof general and emacs on windows [Mon Aug 10 18:14:32 2015] I can't seem to get the loadpath right [Mon Aug 10 18:14:46 2015] I have set coq-auto-compile to on [Mon Aug 10 18:15:06 2015] and I'm requiring a library in a file [Mon Aug 10 18:15:11 2015] this library has a source file in the same folder [Mon Aug 10 18:15:18 2015] but proof general can't find it [Mon Aug 10 22:59:48 2015] arghh [Mon Aug 10 22:59:52 2015] coq has corrupted me [Mon Aug 10 23:00:01 2015] i keep trying to end my sql queries with periods ;-; [Tue Aug 11 00:39:19 2015] benzrf: I keep interchanging : and :: in Haskell [Tue Aug 11 00:39:26 2015] :} [Tue Aug 11 00:39:35 2015] I do it constantly, and it takes me a minute to figure out what's wrong [Tue Aug 11 00:39:39 2015] length (x :: xs) [Tue Aug 11 00:39:41 2015] what's the problem? [Tue Aug 11 14:36:55 2015] Hi. I've got a question. If I know some coq, is there any project I could join ? Something I could help. [Tue Aug 11 15:07:07 2015] Arthur_Rainbow: what kind of stuff are you interested in? [Tue Aug 11 15:14:53 2015] I would say you should work on whatever is most interesting to you. in my experience, I've learned more from trying to do stuff myself. [Tue Aug 11 15:15:32 2015] but I can understand the appeal of working on something established. I might recommend looking at the verified software tool chain http://vst.cs.princeton.edu/ as an interesting big project [Tue Aug 11 15:15:51 2015] they've designed a verified program logic for a dialect of C that can be compiled by compcert [Tue Aug 11 15:23:42 2015] There's also this project, but I don't know how accessible it is: http://corn.cs.ru.nl/ [Tue Aug 11 21:44:51 2015] hello? I just downloaded coq8.5 beta 2 and installed it to my home directory [Tue Aug 11 21:45:06 2015] however there doesn't seem to be syntax highlighting in coqide [Tue Aug 11 21:46:37 2015] is this expected? because before that I got coq from yum and there seems to be highlighting [Tue Aug 11 21:46:59 2015] FYI it still colors processed proofs green [Tue Aug 11 21:47:20 2015] [Wed Aug 12 07:57:30 2015] How to learn homology theory? [Wed Aug 12 08:40:07 2015] magistr: are you a bot? you keep asking "How to learn x?" every day [Wed Aug 12 08:41:20 2015] nkaretnikov, ok, i'm bot, may be i get answer [Wed Aug 12 08:42:04 2015] what i'm saying is that you shouldn't use this channel for everything [Wed Aug 12 08:42:11 2015] try #haskell-blah [Wed Aug 12 08:42:13 2015] or google [Wed Aug 12 08:42:53 2015] you were asking questions about category theory the other day, have you learned it already? [Wed Aug 12 08:42:54 2015] it is a lot of material on homology and anybody knows nice books [Wed Aug 12 08:43:21 2015] cat theory is a very easy [Wed Aug 12 08:46:03 2015] and axiomatic set theory is more useful [Wed Aug 12 08:49:09 2015] nkaretnikov, and you should ignore me [Wed Aug 12 08:50:19 2015] nkaretnikov, or ask ops [Wed Aug 12 08:51:20 2015] of course i can ignore you, but i don't want this channel to turn into #emacs. [Wed Aug 12 08:54:54 2015] the knowledge of coq implies rather good mathematical preparation and human factor [Wed Aug 12 08:57:20 2015] I don't mind off-topic discussion when there's nothing else. [Wed Aug 12 08:58:18 2015] Tuplanolla: the problem with this is that newcomers may hesitate to ask because the channel is noisy. [Wed Aug 12 08:58:49 2015] should i start asking irrelevant questions just because no one is talking at the moment? [Wed Aug 12 08:59:25 2015] you should chill. [Wed Aug 12 09:05:48 2015] axiomatic set theory is more useful than category theory? [Wed Aug 12 09:23:30 2015] nkaretnikov: already banned from #haskell for similar. [Wed Aug 12 10:18:14 2015] jrw: I do work on my own, trying to prove algorithm I learn or some math properties. But it would be nice to be part of a project, to do some things which as not be done before and which may be used by other people later. [Wed Aug 12 10:18:23 2015] Thanks for the link, I'll look at them [Wed Aug 12 11:22:27 2015] Arthur_Rainbow: also on a more selfish note, I work on verifying distributed systems in coq. if that kind of thing interests you, we'd be very happy to take contributions. you can checkout https://github.com/uwplse/verdi . [Wed Aug 12 12:36:58 2015] I'm playing with proving that a relation along with a proof that said relation is a total function can be converted into a coq function, but struggling a bit. Anyone have suggested readings or resources for this area? [Wed Aug 12 12:39:00 2015] There are total non-computable functions, so you can't. [Wed Aug 12 12:39:55 2015] Showing that a relation is functional doesn't show that it is decidable. [Wed Aug 12 12:40:27 2015] ianjneu: oh right, good point. thanks for saving me some wasted time! [Wed Aug 12 12:42:49 2015] for my own understanding, it would be possible to do the conversion to a Haskell function, which lets you write undecideable functions. [Wed Aug 12 12:42:52 2015] correct? [Wed Aug 12 12:45:05 2015] Nope. [Wed Aug 12 12:46:21 2015] Unless you can enumerate all elements of the type to do a semidecision infinite crawl looking for the output values. [Wed Aug 12 12:50:17 2015] Hmm. I'll have to think/read about that some more. Thanks! [Wed Aug 12 13:35:18 2015] How complicated is Coq's type checking implementation in comparison to, say, GHC's System FC? [Wed Aug 12 13:38:16 2015] I'm merely looking for an estimate, something on a scale from Scheme interpreter to Risch algorithm. [Wed Aug 12 13:52:37 2015] Tuplanolla: what kind of measure are you looking for? [Wed Aug 12 13:52:52 2015] Hand waving is sufficient. [Wed Aug 12 13:53:58 2015] I'm planning to look into implementing a toy type checker. [Wed Aug 12 13:54:05 2015] but, lines of code, or number of rules, or...? [Wed Aug 12 14:42:29 2015] Tuplanolla: if you want "type-checks + ~type-checks" then it's around 1000 lines. If you want a useful typechecker that has source location information, unification, and useful error messages, you're looking at 10K easy. [Wed Aug 12 14:43:46 2015] Just take a look at the cubicaltt repo on github. It's intended to be a toy, but is still fairly large due to trying to be at least a little helpful when something goes wrong. [Wed Aug 12 14:46:01 2015] I'm also looking at Idris. [Wed Aug 12 14:46:50 2015] It seems to be at 10 k. [Wed Aug 12 14:48:36 2015] Tuplanolla: Edwin claims that you shouldn't approach implementing a dependent type checker on its face. Instead you should write a tactic-based proof assistant and get the type-checking as a side-effect. [Wed Aug 12 14:49:11 2015] fp language needs a lot of math knowledge [Wed Aug 12 14:49:44 2015] magistr: nope, just a definition lookup. [Wed Aug 12 14:50:55 2015] Would it be possible to have optional dependent types? [Wed Aug 12 14:51:12 2015] optional or gradual? [Wed Aug 12 14:51:49 2015] I don't remember the difference, but I mean that you could add types as you go, if you wanted to. [Wed Aug 12 14:52:21 2015] Optional: dependency is erased and unchecked with interactions with code that wasn't dependently typed and checked. Just, go. [Wed Aug 12 14:53:00 2015] Gradual: types are translated into higher-order assertions called software contracts and enforced at the boundaries between typed/untyped. [Wed Aug 12 14:53:40 2015] It's obviously true that optional typing is possible due to the existence of extraction. [Wed Aug 12 14:54:39 2015] But your interactions with the code must be with the post-extraction types, which isn't necessarily user-friendly. [Wed Aug 12 14:55:05 2015] Optional was the right word then. I might want to try it myself. [Wed Aug 12 14:57:58 2015] I have this silly idea of an educational language that would be easy enough for students to understand and then implement partially. [Wed Aug 12 14:59:06 2015] Tuplanolla: Look at Conor McBride's paper on it's simply easy [Wed Aug 12 14:59:24 2015] What's the title? [Wed Aug 12 14:59:37 2015] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.207.4850 [Wed Aug 12 14:59:54 2015] Simply eas! - an implementation of a dependently typed lambda calculus. [Wed Aug 12 15:00:03 2015] s/eas!/easy!/ [Wed Aug 12 15:00:14 2015] Thank you. Let's see. [Wed Aug 12 15:02:18 2015] Andrej Bauer has some blog posts about it too [Wed Aug 12 15:06:30 2015] This paper does not mention totality. Is it implied or am I missing something? [Wed Aug 12 15:12:05 2015] hi. where is the calculus of constructions in the way that it is currently used in coq described? [Wed Aug 12 15:12:27 2015] I think it's mentioned in the faq. [Wed Aug 12 15:12:58 2015] Here: https://coq.inria.fr/faq#htoc8 [Wed Aug 12 15:13:43 2015] kthx. [Wed Aug 12 15:35:49 2015] hm. is this let ... in ... construct relevant for the theory? isn't let x := y in T usually just an abbrevitation for (fun x => T) y ? [Wed Aug 12 15:41:14 2015] or do I miss something? [Wed Aug 12 15:49:48 2015] schoppenhauer yes they are the same if y is pure [Wed Aug 12 15:51:23 2015] sunnymilk: pure? [Wed Aug 12 15:52:25 2015] has no side effects [Wed Aug 12 15:52:37 2015] it's coq. it cannot have side effects. [Wed Aug 12 15:52:40 2015] or can it? [Wed Aug 12 15:53:00 2015] thats true but there are other languages with let constructs that can [Wed Aug 12 15:53:28 2015] yes, but why does coq have the let construct in its base theory then? [Wed Aug 12 15:53:41 2015] and not just as a mere abbrevitation [Wed Aug 12 15:54:00 2015] It extracts better, I imagine. [Wed Aug 12 15:54:04 2015] ok [Wed Aug 12 17:04:24 2015] schoppenhauer you may be interested in this: https://coq.inria.fr/refman/Reference-Manual006.html#sec170 , it says ``Remark: We may have let x:=t in u well-typed without having ((λ x:T. u) t) well-typed (where T is a type of t). This is because the value t associated to x may be used in a conversion rule (see Section 4.3).'' [Wed Aug 12 17:04:50 2015] indeed. thx. [Thu Aug 13 17:38:00 2015] any idea what the tactic to pull a function into a let body is? e.g. I have f (let a = b in c) = let a = b in (f c). [Thu Aug 13 17:39:47 2015] maybe a bit more clear: I would like a rule that gives the following implication: "(f (let a = b in c)) -> (let a = b in (f c))" [Thu Aug 13 17:40:01 2015] i recall this being asked not long ago... [Thu Aug 13 17:40:41 2015] apologies if there are logs I should be searching, didn't see them in the header [Thu Aug 13 17:40:53 2015] well, I can't find it so no problem [Thu Aug 13 17:41:23 2015] i'm guessing simplification is not helping? [Thu Aug 13 17:41:37 2015] I've only tried simpl [Thu Aug 13 17:42:07 2015] if there's a more powerful simplification that might do it that would be fine [Thu Aug 13 17:42:09 2015] stelleg: afaik there's no tactic for that. I would prove it as a lemma [Thu Aug 13 17:42:17 2015] simpl is not going to do that for you. [Thu Aug 13 17:42:38 2015] jrw: ok, thanks [Thu Aug 13 17:42:51 2015] this is trivial to prove [Thu Aug 13 17:43:09 2015] Goal forall A f (a b c : A), (f (let a := b in c)) -> (let a := b in (f c)). [Thu Aug 13 17:43:09 2015] Proof. auto. Qed. [Thu Aug 13 17:44:33 2015] johnw: thanks [Thu Aug 13 17:44:46 2015] weird that auto can do it there but not in my special cause [Thu Aug 13 17:47:17 2015] there's something fishy there [Thu Aug 13 17:48:04 2015] because c could depend on a [Thu Aug 13 17:48:07 2015] but that lemma doesn't allow it [Thu Aug 13 17:48:28 2015] that lemma basically shows that it's true in the special case where c doesn't depend on a [Thu Aug 13 17:50:07 2015] and it's goin to be annoying to rewrite by the generalized lemma :/ [Thu Aug 13 17:51:09 2015] stelleg: btw, the tactic [cbv zeta] may also work in your case. [Thu Aug 13 17:53:09 2015] ah [Thu Aug 13 18:03:45 2015] jrw: thanks, i'll try that [Thu Aug 13 18:20:09 2015] hmm [Thu Aug 13 18:20:41 2015] so it seem to have issues because of a pattern matched tuple in the let [Thu Aug 13 18:21:24 2015] using johnw's lemma doesn't seem to unify correctly, and trying to prove it on the more specific case doesn't work [Thu Aug 13 18:22:08 2015] neither does the [cbv zeta] [Thu Aug 13 18:29:07 2015] gives this unification error, although it seems as though it should unify succesfully: http://sprunge.us/QHjN [Thu Aug 13 18:47:58 2015] stelleg: oh, yeah. destructing let is totally different unfortunately :( [Thu Aug 13 18:48:04 2015] give me a sec and I'll try to cook something up [Thu Aug 13 18:51:25 2015] jrw: bummer, but thanks! [Thu Aug 13 19:07:53 2015] so it looks like you destruct the b in johnw's case above then it works it out [Thu Aug 13 19:08:15 2015] yeah I can't get a nice lemma version of it [Thu Aug 13 19:08:22 2015] but destruct will definitely work [Thu Aug 13 19:09:54 2015] i ended up with a specialized lemma for exactly what I wanted to do, not ideal but meh: forall x, fst (fmap_succ x) = fst x [Thu Aug 13 19:11:20 2015] of course now it's not unifying with the hypothesis that it should be :( [Thu Aug 13 19:14:59 2015] thanks again for the help! [Thu Aug 13 23:21:56 2015] *almost* understand now how propositions in coq work now, so excited. wondering one thing now about "less than or equal to" [Thu Aug 13 23:22:17 2015] coq defines it here https://github.com/coq/coq/blob/trunk/theories/Init/Peano.v#L154 [Thu Aug 13 23:22:35 2015] that returns a [nat -> Prop] type [Thu Aug 13 23:22:45 2015] how do you make this act like a programming language? [Thu Aug 13 23:23:00 2015] like in javascript, you can create function le(n, m) { return n < m } [Thu Aug 13 23:23:04 2015] which is a boolean [Thu Aug 13 23:23:09 2015] true/false [Thu Aug 13 23:23:13 2015] how do you do that in coq? [Thu Aug 13 23:23:42 2015] does there need to be a definition that takes the "le as Prop", and maps to true or false? [Thu Aug 13 23:25:53 2015] viatropos : what you can do is write a function like this one [Definition le_lt_dec n m : {n <= m} + {m < n}.] which will either return a proof that n <= m or a proof that m < n [Thu Aug 13 23:26:10 2015] you can do this because you can prove that comparison on natural numbers is actually decidable [Thu Aug 13 23:26:20 2015] (this is not the case for everything in Prop) [Thu Aug 13 23:26:54 2015] Then you could indeed use the result of this function like boolean carrying a little bit more information [Thu Aug 13 23:29:47 2015] Cypi: so that expands to something like [Definition le_lt_dec : forall n m : nat, sumbool (le n m) (lt m n)] [Thu Aug 13 23:30:04 2015] where should i look to learn more? [Thu Aug 13 23:31:11 2015] why can't u just do [Definition is_le n m : match n with n <= m => True ... ] something like that? [Thu Aug 13 23:31:28 2015] About le_lt_dec specifically? You could just take a look at its definition in the standard library: [Require Import Arith. Print le_lt_dec.] [Thu Aug 13 23:31:35 2015] or you could try to write it yourself :p [Thu Aug 13 23:32:03 2015] You cannot match directly on something in Prop, because you can only match on something which is in an inductive type [Thu Aug 13 23:32:13 2015] (or coinductive type, but let's put that aside) [Thu Aug 13 23:32:26 2015] ok cool, well will have to try that then, understanding the implementation of le_lt_dec [Thu Aug 13 23:34:39 2015] You can try to write it yourself using tactics if you want. Start with [Definition le_lt_dec n m : {n <= m} + {m < n}. Proof. revert m; induction n.] [Thu Aug 13 23:35:11 2015] (you might need some auxiliary lemmas about basic stuff about <= and <, or you can use directly [auto with arith] instead, as you wish) [Thu Aug 13 23:36:33 2015] thank you! [Thu Aug 13 23:37:38 2015] Do you mind explaining in a casual way what is required to have "n <= m" be true/false boolean? [Thu Aug 13 23:37:50 2015] so first, we have a proposition [le] [Thu Aug 13 23:38:11 2015] this is just a proposition saying "there are two numbers n and m where n is less than or equal to m", correct? [Thu Aug 13 23:38:19 2015] it doesn't say anything about true or false booleans [Thu Aug 13 23:38:30 2015] So for every natural numbers n m, we get a proposition [le n m] (or [n <= m]) [Thu Aug 13 23:38:31 2015] then the next thing is to do something about decidability [Thu Aug 13 23:38:37 2015] k [Thu Aug 13 23:38:48 2015] indeed. You need to prove that the proposition [n <= m] is decidable [Thu Aug 13 23:39:06 2015] why do you need to do that to get true/false booleans? [Thu Aug 13 23:39:10 2015] and proving this is the same thing as actually giving a function which actually tells if [n <= m] or [~ (n <= m)] [Thu Aug 13 23:39:57 2015] how did you know that you need to prove if it's decidable? [Thu Aug 13 23:40:02 2015] This is basically the same thing: if for some proposition P, you can evaluate P to true or false (while respecting the truth/falsehood of P), then P is decidable [Thu Aug 13 23:40:23 2015] ah [Thu Aug 13 23:40:25 2015] interesting [Thu Aug 13 23:41:02 2015] So you could also write some function [Definition foo n m : bool.], and then prove that [foo n m = true <-> n <= m] [Thu Aug 13 23:43:12 2015] are these ideas sort of encapsulated in this symbol? https://github.com/coq/coq/blob/3fcadca93b8d9dd70d9d93412cbacf8d4e851ed7/theories/Init/Specif.v#L195 [Thu Aug 13 23:43:21 2015] sumbool* (not symbol) [Thu Aug 13 23:44:15 2015] sumbool is just an enriched booleans: it carries a proof in each branch, not just true/false. So it's not directly related, but they are useful to express decidability of some proposition P. [Thu Aug 13 23:44:32 2015] ok [Thu Aug 13 23:44:34 2015] (the decidability of P can just be expressed by [{P} + {~ P}] [Thu Aug 13 23:44:35 2015] ) [Thu Aug 13 23:45:10 2015] ok this is very helpful, will have to learn more about decidability [Fri Aug 14 00:11:26 2015] viatropos: for example, the type "a = b" has a single inhabitant. Since a function accepting such an argument is only callable if you have that inhabitant, there's nothing to "decide". But {P} + {~P} gives you _either_ the witness to the truth of P, or to its falsehood, and this either/or nature of sumbool lets you branch on the difference, i.e., make a decision based on its truth. [Fri Aug 14 00:12:48 2015] where do i get a good foundation on decidability? [Fri Aug 14 00:16:03 2015] viatropos: https://en.wikipedia.org/wiki/Decidability_(logic) [Fri Aug 14 00:16:42 2015] oh wondering if there's a particular book with many examples and such [Fri Aug 14 00:17:00 2015] well, it's such a basic idea that I've actually never run into a good discussion about it [Fri Aug 14 00:17:32 2015] interesting [Fri Aug 14 00:17:38 2015] if you can use a piece of information to decide between multiple courses of action, meaningfully in each direction, then that thing is decidable [Fri Aug 14 00:18:10 2015] what about, is decidability directly tied to the idea of "booleans"? [Fri Aug 14 00:18:39 2015] booleans are decidable [Fri Aug 14 00:18:50 2015] given some x : bool, you can test whether x is true or not [Fri Aug 14 00:19:02 2015] they just aren't terribly meaningful (boolean blindness) [Fri Aug 14 00:19:04 2015] but a bool _is_ true by definition (or false) [Fri Aug 14 00:19:32 2015] right, and you can ask which one it is [Fri Aug 14 00:19:44 2015] if a thing is undeciable, you might know it exists, but you can't ask [Fri Aug 14 00:19:54 2015] so something is decidable if it returns a boolean true or false only? [Fri Aug 14 00:19:59 2015] no [Fri Aug 14 00:20:19 2015] wikipedia says "an algorithm that can and will return a Boolean true or false value (instead of looping indefinitely)" [Fri Aug 14 00:20:34 2015] take {P} + {~P}, for example [Fri Aug 14 00:20:47 2015] this is really a type: sumbool := inl P | inr (~ P) [Fri Aug 14 00:20:56 2015] it's like an enriched boolean [Fri Aug 14 00:21:07 2015] the trueness or falseness carries evidence of the decision [Fri Aug 14 00:21:43 2015] i'm not quite there yet, i'm not too familiar with sumbool or inl/inr [Fri Aug 14 00:21:57 2015] i get a vague sense of what you're saying, but still isn't clicking [Fri Aug 14 00:24:15 2015] if you're googling, also look at descriptions of undecidability [Fri Aug 14 00:24:22 2015] it might make more sense from that perspective [Fri Aug 14 00:24:42 2015] ok sounds good [Fri Aug 14 00:29:40 2015] so both decidability / undecidability are about decision problems https://en.wikipedia.org/wiki/Decision_problem [Fri Aug 14 00:29:54 2015] and they keep saying it leads to a "yes" or "no" answer, which is a boolean basically [Fri Aug 14 00:30:16 2015] other descriptions you'll find say that it consists of being to identify the member of a set [Fri Aug 14 00:31:41 2015] ah, and the set they're referring to is booleans [Fri Aug 14 00:31:55 2015] so you decide if something belongs to a set, where the common case is boolean true/false? [Fri Aug 14 00:31:56 2015] yeah, for decision problems it's just yes/no [Fri Aug 14 00:32:13 2015] that's a little less common when doing constructive proofs, but sure [Fri Aug 14 00:37:30 2015] ok, it's starting to sink in some more [Fri Aug 14 00:37:37 2015] starting to make sense [Fri Aug 14 00:40:14 2015] i guess the main thing that's tripping me up is i keep thinking about this thing (function or whatever, that tests if n <= m) is actually doing some computation [Fri Aug 14 00:40:32 2015] like in javascript, it performs some machine code computation to get the value [Fri Aug 14 00:40:42 2015] n <= m is a type [Fri Aug 14 00:40:44 2015] but here there's no computation, you are proving [Fri Aug 14 00:40:47 2015] yeah [Fri Aug 14 00:41:02 2015] now, ssreflect does have a version of <= that is a procedure that returns a boolean [Fri Aug 14 00:41:06 2015] and as a result, it's decidable [Fri Aug 14 00:41:14 2015] interesting [Fri Aug 14 00:41:50 2015] any function less_than_or_equal (x y : nat) : bool has that property [Fri Aug 14 00:41:55 2015] but (x : n <= m) does not [Fri Aug 14 00:42:28 2015] there's only one inhabitant there, so there is no "yes/no"; if it weren't true, "x" wouldn't exist at all [Fri Aug 14 00:42:37 2015] why does coq define le like the later, rather than the former? [Fri Aug 14 00:42:51 2015] well, there's a whole lot of power in being able to say that x only *exists* if n <= m [Fri Aug 14 00:42:59 2015] meaning, the function can't even be called if it's not already true [Fri Aug 14 00:43:06 2015] that's something being decided at compile-time, not runtime [Fri Aug 14 00:43:45 2015] a boolean returning function doesn't convey type-level information, unless you reflect it back to the type level by saying less_than_or_equal x y = true [Fri Aug 14 00:44:15 2015] and this sort of "small scale" reflection is what ssreflect was created for [Fri Aug 14 00:46:28 2015] interesting, what do you mean by reflection here? [Fri Aug 14 00:46:48 2015] like, from [less_than_or_equal x y = true] you can get the type [x <= y] [Fri Aug 14 00:46:49 2015] ? [Fri Aug 14 01:04:46 2015] yeah, there is a way to go between them [Fri Aug 14 10:39:30 2015] one thing I'm stuck on is the inability to use a quantified lemma inside a function body. for a trivial example, trying to use a lemma forall x, id x = x, inside map (fun a => id a). am I missing something? [Fri Aug 14 10:42:41 2015] it seems to fail to unify the quantified x and a, but I'm not sure why. in my particular case, they even have the exact same concrete type [Fri Aug 14 10:50:38 2015] stelleg: do you have Set Implicit Arguments.? [Fri Aug 14 10:52:20 2015] Better yet, a proof script showing where you're stuck would help. [Fri Aug 14 11:09:45 2015] ianjneu: thanks, tried implicit arguments, that didn't seem to help [Fri Aug 14 11:09:56 2015] here's the simple example: http://sprunge.us/fBKU [Fri Aug 14 11:12:21 2015] rewrite id_x fails with goal 'map (fun a : A => id a) x = x', with error Error: Found no subterm matching "id ?1195" in the current goal. [Fri Aug 14 11:15:38 2015] stelleg: you typically can't rewrite under binders [Fri Aug 14 11:15:50 2015] induction x; auto; simpl. rewrite IHx. rewrite id_x. reflexivity. solves your goal [Fri Aug 14 11:17:17 2015] johnw: thanks! I don't quite undersand why you can't rewrite under binders though [Fri Aug 14 11:17:47 2015] if the variable is quantified over all terms of that type, who cares if it is bound locally? [Fri Aug 14 11:17:51 2015] see https://coq.inria.fr/refman/Reference-Manual029.html, section 26.10 [Fri Aug 14 11:17:56 2015] johnw: thanks! [Fri Aug 14 14:13:38 2015] Is there a command like Check for tactics? [Fri Aug 14 14:19:45 2015] Print Ltac trivial. does nothing. [Fri Aug 14 14:29:15 2015] I'm actually looking for Theorem _: forall x : Prop, x -> x., which is trivial. [Fri Aug 14 15:07:37 2015] <`^_^v> dumb question -- i have two hypotheses, "if A then B else C" and "A = true", how can i simplify the former to B? [Fri Aug 14 15:09:09 2015] <`^_^v> never mind, i figured it out. rewrite [Fri Aug 14 16:14:33 2015] Tuplanolla: that should just be "id" [Fri Aug 14 16:16:12 2015] Oh, of course: intro. apply id. Qed.. Thanks for that. [Fri Aug 14 20:21:53 2015] can anyone remind me how to have coq show the defn of a name [Fri Aug 14 20:21:54 2015] ? [Fri Aug 14 20:22:46 2015] [Print name.] [Fri Aug 14 20:22:59 2015] thanks [Fri Aug 14 20:24:37 2015] is there a version of this which does not do the standard "simplifications"? [Fri Aug 14 20:27:57 2015] I don't think Print performs any simplification? [Fri Aug 14 20:28:25 2015] hmm weird [Fri Aug 14 20:28:34 2015] because it prints some huge terms [Fri Aug 14 20:28:38 2015] still quite useful [Fri Aug 14 20:29:03 2015] How are huge terms simplified? [Fri Aug 14 20:29:16 2015] (I think I misunderstood something) [Fri Aug 14 20:29:19 2015] i mean unfolded, sry [Fri Aug 14 20:30:18 2015] Hmm, again, I did not think Print would unfold anything that wasn't unfolded in the first place [Fri Aug 14 20:31:20 2015] ok this is weird http://pastebin.com/fZxCVSYe [Fri Aug 14 20:31:26 2015] because i doubt this is how the function was defined [Fri Aug 14 20:31:56 2015] Ah, I see [Fri Aug 14 20:32:11 2015] There are 2 things here [Fri Aug 14 20:32:13 2015] One is the fixpoint [Fri Aug 14 20:32:27 2015] if you define something using Fixpoint, it will be translated to something with [fix] [Fri Aug 14 20:32:30 2015] which is the case here [Fri Aug 14 20:32:37 2015] yeah that one was clear [Fri Aug 14 20:32:38 2015] but wait [Fri Aug 14 20:32:49 2015] can it be that there was a compound match construct in the def which has become a nested match? [Fri Aug 14 20:32:53 2015] The other thing seems to be a pattern-matching on two expressions at the same time [Fri Aug 14 20:33:02 2015] which is translated, indeed, to successive pattern-matchings [Fri Aug 14 20:33:07 2015] right, so it isn't all that different from the definition [Fri Aug 14 20:33:09 2015] thank you [Fri Aug 14 20:33:10 2015] I believe there is actually a printing option for that one [Fri Aug 14 20:33:37 2015] Set Printing Matching. [Fri Aug 14 20:33:40 2015] maybe [Fri Aug 14 20:34:37 2015] oh right [Fri Aug 14 20:34:43 2015] except coqide wants it to be done somehow differently [Fri Aug 14 20:35:17 2015] It wants you to use the View menu [Fri Aug 14 20:35:27 2015] but I tried it, and it does not seem to work well actually [Fri Aug 14 20:36:01 2015] The match has to be unfolded when you first define the constant, so it is then up to the printer to fold it again if the user wants it to. But apparently it does not always succeed [Fri Aug 14 20:36:33 2015] yeah :/ [Sat Aug 15 16:26:49 2015] question about proving decidability in coq http://math.stackexchange.com/questions/1398519/do-proof-assistants-like-coq-really-need-to-actually-perform-computations-to-pro [Sat Aug 15 16:28:16 2015] are you the one asking this? [Sat Aug 15 16:29:12 2015] yeah [Sat Aug 15 16:29:29 2015] i can answer you here, i don't have an account on that site [Sat Aug 15 16:30:17 2015] ok, that would be very helpful [Sat Aug 15 16:30:44 2015] https://coq.inria.fr/library/Coq.Arith.Le.html [Sat Aug 15 16:31:05 2015] to prove le you need to build up a term with these constructors [Sat Aug 15 16:31:28 2015] there will have to be something like 100000 le_S constructors in your proof term [Sat Aug 15 16:31:48 2015] because it's define in terms of unary natural numbers [Sat Aug 15 16:32:25 2015] when you write 100000 that is just syntactic sugar for S (S (S ...)) with 10000s of constructors [Sat Aug 15 16:32:43 2015] so a direct proof term like this will kill Coq [Sat Aug 15 16:33:10 2015] on the other hand, you could implement base 10 (or binary) numbers and prove that they have a relationship with the unary number system [Sat Aug 15 16:33:31 2015] Here's a more efficient encoding for natural numbers: Inductive bin : Type := Z : bin | T : bin -> bin | ST : bin -> bin. [Sat Aug 15 16:33:41 2015] then you should easily be able to use computation to prove "100000" < "1000000" as base 10 numbers [Sat Aug 15 16:33:57 2015] That one is either zero, twice something or the successor of twice something. [Sat Aug 15 16:35:34 2015] Ok so there are more efficient ways of doing this is what it seems like you're saying [Sat Aug 15 16:35:59 2015] But you're also saying that you *do* have to actually compute every step for it to be "proven"? [Sat Aug 15 16:36:11 2015] sort of [Sat Aug 15 16:36:17 2015] for a direct proof: yes [Sat Aug 15 16:36:45 2015] interesting, how can you prove the same thing using something other than direct proof? [Sat Aug 15 16:36:48 2015] but there are indirect proofs which could be done with less computation (like using base 10 for example) [Sat Aug 15 16:37:40 2015] ok, but even that, you still would do something like 10^2 <= 10^3, 10^3 <= 10^4, etc. [Sat Aug 15 16:37:48 2015] is there a way to do it in only 1 step? [Sat Aug 15 16:37:58 2015] or just a few steps, independent of the size of the number? [Sat Aug 15 16:38:17 2015] like say it was proving 12381871 <= 1874989182 (something arbitrary) [Sat Aug 15 16:38:50 2015] Encode them as strings and compare lengths for example. Is that one enough step? [Sat Aug 15 16:39:14 2015] You need to be the clever one here. [Sat Aug 15 16:39:33 2015] Ah ok, that makes sense [Sat Aug 15 16:39:43 2015] It's all about being clever then :) [Sat Aug 15 16:39:57 2015] But you do actually have to perform all the steps [Sat Aug 15 16:40:22 2015] Definition bar : nat := 1874989182. [Sat Aug 15 16:40:27 2015] this crashes Coq [Sat Aug 15 16:40:39 2015] because the object is gigantic: S (S (S ...)) [Sat Aug 15 16:42:00 2015] so you can't even really talk about this number as a 'nat' in Coq [Sat Aug 15 16:44:08 2015] super interesting, starting to make sense now [Sat Aug 15 16:44:20 2015] so are there standard "efficient" techniques for better defining that number? [Sat Aug 15 16:44:25 2015] you can use BinNat [Sat Aug 15 16:44:28 2015] like how would you prefer to define that number in coq? [Sat Aug 15 16:44:30 2015] ah [Sat Aug 15 16:44:32 2015] Definition bar' : N := 1874989182%N. [Sat Aug 15 16:44:47 2015] this should be fine, and using binnat comparison you can use computation to prove the theorem [Sat Aug 15 16:45:00 2015] but le on N is defined different than on nat, so the proof itself is much much shorter [Sat Aug 15 16:45:43 2015] that's why Coq can handle it [Sat Aug 15 16:46:14 2015] interesting, okay it's starting to make sense, yay [Sat Aug 15 16:52:31 2015] So then, how would this work in practice? Say you have an expression in a programming language like `n <= m`, and they're of type "natural". But they can be any value, say up to 2147483647. Once the proof assistant or verifier comes to that expression `n <= m`, and knows `n == 21474836400` and `m == 2147483647 `, and that they are natural numbers, would the ideal be that it knows natural number proofs of large values are slow, so it [Sat Aug 15 16:52:31 2015] instead uses the BinNat proof, knowing there is an already verified proof of the equality between nat and BinNat? [Sat Aug 15 16:54:12 2015] yeah thats right, although it might be even better to use 32 (or whatever) bit numbers, nat and N let you make numbers arbitrarily high [Sat Aug 15 16:54:20 2015] when modelling a programming language [Sat Aug 15 16:56:49 2015] awesome, thank you [Sat Aug 15 17:01:55 2015] so then if `nat` is so inefficient in practice, where is it useful? [Sat Aug 15 17:03:02 2015] nat is very useful because it has such a simple induction scheme [Sat Aug 15 17:06:22 2015] If you read classical mathematics, you'll rarely encounter numbers greater than 8, viatropos. [Sat Aug 15 17:07:16 2015] For instance, for the Vector type, you do not lose much space by using nat as an index: Inductive Vector (A:Type) : nat -> Type := Nil : Vector A O | Cons : forall n, A -> Vector A n -> Vector A (S n). [Sat Aug 15 17:08:03 2015] You could use BinNat instead of nat in this definition, but it will be certainly less convenient to use. [Sat Aug 15 18:17:47 2015] where is @eq defined in [ascii_dec : forall a b : ascii, sumbool (@eq ascii a b) (not (@eq ascii a b))]? [Sat Aug 15 18:17:51 2015] (in the coq source code) [Sat Aug 15 18:18:28 2015] [About @eq.] doesn't work [Sat Aug 15 18:19:51 2015] or what does @eq mean [Sat Aug 15 18:20:17 2015] @ is just a modifier to say that no arguments should be explicit in the next constant [Sat Aug 15 18:20:28 2015] so @eq is just like eq, but with no implicit arguments [Sat Aug 15 18:20:37 2015] that no arguments should be implicit*, sorry [Sat Aug 15 18:21:16 2015] You can do [Print eq.] if you want, it is just the standard equality [Sat Aug 15 18:22:20 2015] oh ok, makes sense [Sat Aug 15 18:44:14 2015] question about symbol, trying to understand it because a lot of the decidability stuff in coq uses it but it's not explained clearly anywhere [Sat Aug 15 18:44:16 2015] found this http://seb.mondet.org/blog/post/coqtests-02-sumbools.html [Sat Aug 15 18:44:32 2015] by symbol, i mean sumbool (autocorrect :|) [Sat Aug 15 18:44:54 2015] is sumbool basically *creating* a boolean type? [Sat Aug 15 18:45:06 2015] b/c it's of type Set, and it returns a set of 2 items [Sat Aug 15 18:45:14 2015] and those items are propositions [Sat Aug 15 18:45:27 2015] so when it's written sumbool ‘is a boolean type equipped with the justification of their value’ [Sat Aug 15 18:45:36 2015] it's not actually of type "bool" in coq [Sat Aug 15 18:45:41 2015] The keyword "Inductive" introduces the definition of a new inductive type [Sat Aug 15 18:45:47 2015] so now, it's not actually of type "bool" [Sat Aug 15 18:45:48 2015] instead, it's creating a custom type similar to bool, but for your 2 propositions [Sat Aug 15 18:46:13 2015] but since there are 2 constructors, you have a trivial correspondence with the type bool [Sat Aug 15 18:46:18 2015] yup [Sat Aug 15 18:46:27 2015] ok awesome, making more sense now [Sat Aug 15 18:47:16 2015] I believe that when they say "boolean type", they approximately means "a type with two values" [Sat Aug 15 18:47:26 2015] yeah, that should be clarified haha [Sat Aug 15 18:47:30 2015] (even though in that case it is really an approximate meaning) [Sat Aug 15 18:47:31 2015] so confused for a long time [Sat Aug 15 18:47:50 2015] (because you can have non-equal proof of the same proposition) [Sat Aug 15 18:48:12 2015] (so you could have some [p : A] and [q : A] such that you cannot prove [left p = left q]) [Sat Aug 15 18:48:32 2015] (but anyway, the spirit is there :D ) [Sat Aug 15 18:48:58 2015] don't quite understand what you mean there yet [Sat Aug 15 18:49:17 2015] want to get a better sense of how these decidability definitions work, let me try [Sat Aug 15 18:49:18 2015] so a decidability definition like [le_lt_dec : forall n m : nat, sumbool (le n m) (lt m n)] is says "for all natural numbers n and n, there is a 2-constructor type with the proposition [le n m] and [lt n m]"? [Sat Aug 15 18:49:35 2015] "natural numbers n and m" [Sat Aug 15 18:50:10 2015] No, it's better than that. This type exists anyway. But what you need to prove is that this type is inhabited. This is what [le_lt_dec] does. [Sat Aug 15 18:50:26 2015] For any [n m : nat], it gives you an inhabitant of the type [sumbool (le n m) (lt m n)] [Sat Aug 15 18:50:43 2015] what "gives an inhabitant", is it the proof? [Sat Aug 15 18:51:11 2015] Yes. In Coq, proving is the same as giving an inhabitant [Sat Aug 15 18:51:26 2015] Type <-> Theorems, Terms <-> Proofs [Sat Aug 15 18:52:49 2015] (going to switch to using ascii_dec as an example, it seems simpler than <= https://coq.inria.fr/library/Coq.Strings.Ascii.html#ascii_dec) [Sat Aug 15 18:53:09 2015] so where is the proof for ascii_dec that proves the type is inhabited? [Sat Aug 15 18:53:14 2015] it seems to be defined without a proof [Sat Aug 15 18:53:38 2015] They skip proofs in the documentation, that's why [Sat Aug 15 18:54:09 2015] https://github.com/coq/coq/blob/trunk/theories/Strings/Ascii.v#L36 for the proof [Sat Aug 15 18:54:10 2015] op, sorry https://github.com/coq/coq/blob/trunk/theories/Strings/Ascii.v#L36 [Sat Aug 15 18:54:12 2015] ok [Sat Aug 15 18:54:15 2015] haha [Sat Aug 15 18:54:28 2015] but it's really short because it uses a tactics which decides equality when it's easy [Sat Aug 15 18:54:58 2015] (in that case, the tactic will in turn ask for a proof of the decidability of equality on booleans, which is proved by bool_dec) [Sat Aug 15 18:55:12 2015] (this is because of the encoding of ascii characters that has been chosen) [Sat Aug 15 18:57:08 2015] ok [Sat Aug 15 18:57:21 2015] so is this basically the expanded/complete proof of ascii_dec then? https://cloudup.com/cnTt3cqpvLT [Sat Aug 15 18:57:58 2015] (that's what the decide equality does?) [Sat Aug 15 18:59:24 2015] bool_dec is much simpler in that case [Sat Aug 15 18:59:41 2015] https://cloudup.com/i7JsRQ4PLoQ [Sat Aug 15 19:03:28 2015] This is what the automatic tactic will produce, yes [Sat Aug 15 19:04:24 2015] k [Sat Aug 15 19:04:32 2015] it has to test the equality of 8 successive fields, so yes, it's a little bit big, but it's simple [Sat Aug 15 19:10:38 2015] why do some decidability definitions use [Decidable.decidable] while others use [sumbool]? [Sat Aug 15 19:10:41 2015] eg [BinNat.N.lt_decidable: forall n m : BinNums.N, Decidable.decidable (BinNat.N.lt n m)] [Sat Aug 15 19:10:51 2015] [ascii_dec: forall a b : ascii, sumbool (@eq ascii a b) (not (@eq ascii a b))] [Sat Aug 15 19:11:14 2015] is that just a refactoring thing or do they mean two different things? [Sat Aug 15 19:11:42 2015] (wondering if all "decidability definitions" have pretty much the same format) [Sat Aug 15 19:12:48 2015] it seems like it's two different coding styles i'm guessing [Sat Aug 15 19:13:18 2015] just a refactoring style, I believe [Sat Aug 15 19:13:27 2015] ok [Sat Aug 15 19:13:45 2015] Ah, nevermind [Sat Aug 15 19:13:52 2015] Decidable.decidable is for things in Prop [Sat Aug 15 19:14:14 2015] but so is [@eq ascii a b] [Sat Aug 15 19:14:18 2015] so yeah, refactoring :) [Sat Aug 15 19:14:24 2015] ok cool [Sat Aug 15 19:15:54 2015] Uh, I'm terrible. There is another difference. [Sat Aug 15 19:16:12 2015] Decidable.decidable returns something in Prop, whereas sumbool is in Set [Sat Aug 15 19:16:54 2015] Decidable.decidable is just defined as [fun (P : Prop) => P \/ ~ P] [Sat Aug 15 19:17:30 2015] So it's using the inductive type [or], which is exactly the same as [sumbool], except that it lands in Prop, not in Set [Sat Aug 15 19:17:48 2015] ok, when would you pick one or the other? [Sat Aug 15 19:18:08 2015] like could the bool_dec be rewritten to use [Decidable.decidable]? [Sat Aug 15 19:18:22 2015] You could, yes [Sat Aug 15 19:18:45 2015] If you are just proving stuff, then using things in Prop is fine [Sat Aug 15 19:18:58 2015] but if you need to compute, like you would do with actual booleans, then you need something in Set [Sat Aug 15 19:18:59 2015] what is the benefit of using sumbool then? [Sat Aug 15 19:19:02 2015] ok [Sat Aug 15 19:22:11 2015] just playing with ideas here, not good at writing this so it works yet, but.. [Sat Aug 15 19:22:25 2015] could you rewrite the original bool_dec [bool_dec: forall b1 b2 : bool, sumbool (@eq bool b1 b2) (not (@eq bool b1 b2))] as... [Sat Aug 15 19:22:30 2015] [bool_dec: forall b1 b2 : bool, Decidable.decidable (@eq bool b1 b2)] [Sat Aug 15 19:22:37 2015] and then make [Sat Aug 15 19:22:39 2015] [bool_dec_computable: sumbool bool_dec] [Sat Aug 15 19:22:55 2015] [sumbool bool_dec] does not really make much sense [Sat Aug 15 19:23:17 2015] yeah, don't know how to "wrap" that properly, but the basic idea: [Sat Aug 15 19:23:22 2015] - write the Prop version [Sat Aug 15 19:23:31 2015] - use that Prop version to create a "computable" Set version [Sat Aug 15 19:23:32 2015] ? [Sat Aug 15 19:23:40 2015] You cannot use something in Prop to compute something in Set, basically, so no [Sat Aug 15 19:23:50 2015] ok [Sat Aug 15 19:25:13 2015] wait but sumbool itself uses something in Prop to make a Set https://github.com/coq/coq/blob/trunk/theories/Init/Specif.v#L195 [Sat Aug 15 19:25:17 2015] how is that different? [Sat Aug 15 19:26:26 2015] It's not computing in that case. To be more specific: you cannot examine the value of some [p : P] if [P : Prop], when what you want to build is in Set [Sat Aug 15 19:26:57 2015] For instance, consider the type [True \/ False -> nat.] [Sat Aug 15 19:26:58 2015] k [Sat Aug 15 19:27:20 2015] it is a perfectly valid type, and you can even build values of that type, such that [fun (P : True \/ False) => 0] [Sat Aug 15 19:27:41 2015] but what you cannot do is build a function which has this type, and whose return value depends on its input [Sat Aug 15 19:28:05 2015] so you basically cannot make use of that argument of type [True \/ False] to decide which natural number you should return [Sat Aug 15 19:28:27 2015] You can try it yourself if you want: [Goal True \/ False -> nat. intros P. destruct P.] [Sat Aug 15 19:32:06 2015] where is the "decide equality" tactic defined in Coq? https://github.com/coq/coq/blob/trunk/tools/gallina-syntax.el#L266 [Sat Aug 15 19:32:29 2015] Probably directly in OCaml, but I can check this [Sat Aug 15 19:32:32 2015] can't seem to find it [Sat Aug 15 19:35:27 2015] https://github.com/coq/coq/blob/trunk/tactics/eqdecide.ml [Sat Aug 15 19:35:28 2015] there [Sat Aug 15 19:36:31 2015] thanks [Sat Aug 15 22:11:56 2015] whats best way to set loadpath for coq using proof general? [Sat Aug 15 22:12:13 2015] using chlipala's text [Sat Aug 15 22:27:19 2015] why does `Max.max_dec` get extracted to this ocaml? [let max_dec0 = Nat.max_dec] [Sat Aug 15 22:28:00 2015] whereas bool_dec is more readable https://gist.github.com/lancejpollard/dcbc87799d93388b164d [Sat Aug 15 22:28:21 2015] Max.max_dec is actually defined as Nat.max_dec [Sat Aug 15 22:28:50 2015] there is probably something to do to tell it to inline the definition, but I'm not really well-versed in extraction :/ [Sat Aug 15 22:31:53 2015] moo.. adam's latest tarball is wrong [Sat Aug 15 22:32:11 2015] [Extraction Nat.max_dec.] goes to [let max_dec = Private_Dec.max_dec] [Sat Aug 15 22:32:23 2015] where is Private_Dec defined? [Sat Aug 15 22:33:10 2015] [Print Nat.Private_Dec.max_dec.] [Sat Aug 15 22:33:27 2015] You can do [Recursive Extraction .] if you want every dependency to be extracted [Sat Aug 15 22:33:31 2015] (it can go a long way, though) [Sat Aug 15 22:33:33 2015] oh ok [Sat Aug 15 22:33:35 2015] awesome [Sat Aug 15 22:33:56 2015] that's perfect [Sat Aug 15 22:35:03 2015] On the way, note that now that everything in Prop has been erased, the definition of sumbool is actually exactly this of booleans [Sat Aug 15 22:35:06 2015] haha.. the paper book is obselete! [Sat Aug 15 22:35:20 2015] (you could actually for Coq to extract it to actual OCaml booleans) [Sat Aug 15 22:35:27 2015] (ask for*) [Sat Aug 15 23:12:23 2015] can you get coq 8.5b2 from opam? [Mon Aug 17 13:02:58 2015] hello. is anyone using native-coq? [Mon Aug 17 13:05:11 2015] because it ... doesn't work ... well, it works. but only sort of. [Mon Aug 17 13:05:51 2015] it seems to call ocamlc [Mon Aug 17 13:06:26 2015] but ocamlc does not recognize the ocaml libraries [Mon Aug 17 13:44:42 2015] hm. calling ocamlopt the way strace sais that coqc does works. [Mon Aug 17 13:44:47 2015] but apparently not inside coq. [Mon Aug 17 14:12:40 2015] hm. maybe I'll ask coq-club [Tue Aug 18 06:22:43 2015] hi [Tue Aug 18 06:24:43 2015] That was fast. [Wed Aug 19 08:37:33 2015] hey all. [Wed Aug 19 08:38:00 2015] I'm reading through ssreflect's code, and am hitting all sorts of stumbling blocks. [Wed Aug 19 08:38:51 2015] one is the definition of funcomp in ssrfun.v. it is "Definition funcomp u (f : B -> A) (g : C -> B) x := let tt := u in f (g x)." [Wed Aug 19 08:39:04 2015] sorry, that's let: instead of let. [Wed Aug 19 08:39:08 2015] what's the point of the u and tt ? [Wed Aug 19 08:39:35 2015] it then later defines comp f g to be notation for funcomp tt f g, so it's doubly confusing. [Wed Aug 19 11:22:58 2015] Hi. is there an implementation of diffarrays for coq? (I asked this in coq-club but got no answer so far.) native-coq had "PArray". I can write bindings myself, but if there was something predefined, I would prefer it. [Wed Aug 19 20:31:06 2015] *push* Hi. is there an implementation of diffarrays for coq? (I asked this in coq-club but got no answer so far.) native-coq had "PArray". I can write bindings myself, but if there was something predefined, I would prefer it. Someone found https://www.mpi-sws.org/~viktor/arefs/ but the Parrays there extract to "Perarray.t", and I have no idea what that is, ocaml doesn't know it. [Thu Aug 20 01:04:58 2015] lmgtfy, https://www.mpi-sws.org/~viktor/arefs/Parray.html [Thu Aug 20 01:05:40 2015] gah. cake on face. [Thu Aug 20 01:15:12 2015] I have never extracted in my life, but I think Perarray is supposed to be defined by the extraction. [Thu Aug 20 01:35:07 2015] or not... maybe ask viktor by email? [Thu Aug 20 01:41:25 2015] maybe he just forgot to include the unsafe parts as a perarray.ml/mli in arefs.zip, with Parray.v only providing the proofs based on the ug* axioms in that file. [Thu Aug 20 01:43:34 2015] that's probably it, because in the paper he says he assumes the module Parray, implementing functional arrays. [Thu Aug 20 03:01:19 2015] is there a convenient way to inspect proofs that use long ;-chained things using proofgeneral? [Thu Aug 20 03:02:54 2015] I've been manually rewriting ;-chains by separating out the individual commands, and for ssreflect, rewriting tactics to use mostly defective tactics. [Thu Aug 20 03:03:49 2015] C-c C-n goes to the end of the command up to the next period, so something more fine grained than that. [Thu Aug 20 13:28:40 2015] http://lpaste.net/139278 <- I'm stuck, would someone mind helping? [Thu Aug 20 13:31:50 2015] pharpend : since you've alread used [firstorder], you can use it again if you want. The more manual solution is to do the only thing you can do: [apply H0; intros]. Then you have [X] and [X -> False] in your environment. [Thu Aug 20 13:32:22 2015] Cypi: firstorder solves it after the destructs =p. I'm trying to do the type tetris on my own. [Thu Aug 20 13:32:31 2015] Hmm, I guess that was not a very subtle hint... Maybe a better hint: you don't need H anymore, you can clear it. [Thu Aug 20 13:38:33 2015] http://lpaste.net/139279 <-- stuck again [Thu Aug 20 13:39:03 2015] Well, why "right"? :p [Thu Aug 20 13:39:15 2015] oh I was just trying each branch [Thu Aug 20 13:39:21 2015] left was a dead-end as well [Thu Aug 20 13:39:52 2015] Yes, that's normal: let's say that [right] as a first step will work. Then that basically that, assuming Peirce law, every proposition is false :D [Thu Aug 20 13:40:07 2015] (same for [left], which would prove that every proposition is true) [Thu Aug 20 13:46:01 2015] Yay figured it out: http://lpaste.net/139285 . Thanks Cypi [Thu Aug 20 13:46:10 2015] nice :D [Thu Aug 20 15:02:27 2015] hi. does coq extract int31 to ocaml integers? and ascii strings to native ocaml strings? [Thu Aug 20 15:17:33 2015] hm. it doesn't. [Thu Aug 20 15:17:36 2015] but why? [Thu Aug 20 15:20:53 2015] why doesn't it? [Thu Aug 20 15:56:19 2015] why doesn't it extract to native int [Fri Aug 21 14:02:44 2015] where in the coq source code is the definition of proofs? [Fri Aug 21 14:45:28 2015] schoppenhauer: what do you mean? [Fri Aug 21 14:47:40 2015] johnw: I want to write a custom extraction mechanism. or at least try to do so and fail. [Fri Aug 21 14:48:34 2015] I still don't know what that has to do with "proof definition" [Fri Aug 21 14:48:47 2015] do you mean the Gallina term that witnesses a proof ? [Fri Aug 21 14:50:21 2015] yes. [Fri Aug 21 14:51:32 2015] so why would that be "in the source code"? [Fri Aug 21 14:51:46 2015] I assume you mean, which variable/map holds the proof terms? [Fri Aug 21 14:51:57 2015] sadly, I don't know the internals of coq yet [Fri Aug 21 14:52:35 2015] ... [Fri Aug 28 14:03:27 2015] Hi, I'm trying to use CoqIDE without the Prelude [Fri Aug 28 14:03:34 2015] can anyone help me? [Fri Aug 28 14:07:00 2015] Hello? [Fri Aug 28 14:07:15 2015] Does anyone know how I can use Coq without the Prelude [Fri Aug 28 14:41:16 2015] Semper: try running it with the commandline parameter -nois. [Fri Aug 28 14:41:18 2015] coqide -nois [Fri Aug 28 14:57:59 2015] does coq have any examples involving proving gender in a family tree? [Fri Aug 28 14:58:23 2015] or wolf/cabbage/goat on a boat examples? [Fri Aug 28 14:58:38 2015] I get the feeling that a SAT solver would fit those purposes better. [Fri Aug 28 14:59:08 2015] well i want to have proofs of how the solver arrived at such deductions [Fri Aug 28 14:59:18 2015] but perhaps [Fri Aug 28 15:00:41 2015] I recently read Software Abstractions and it discussed solutions to both of those problems. [Fri Aug 28 15:00:55 2015] That's not helpful for learning Coq, but still. [Fri Aug 28 15:01:59 2015] what resource should i look at for seeing examples of the kinds of problems i can solve using a proof engine ? [Fri Aug 28 15:03:21 2015] (I used to use CYC as a proof engine. where I'd ask it questions and it would answer but with 50 step proofs .. is this what a proof engine does sometimes?) [Fri Aug 28 15:03:58 2015] (if i disagreed with a step in the proof i'd go and modify the mistakes) [Fri Aug 28 15:04:11 2015] then ask again and get sometimes better answers [Fri Aug 28 15:04:29 2015] (or worse answers if i messed up!) [Fri Aug 28 15:05:36 2015] ( proof were a list of axioms and facts ) [Fri Aug 28 15:06:11 2015] typical question might be: why does john eat fish every day? [Fri Aug 28 15:06:56 2015] proof might be he was an organic being who lived nearby the ocean where fish was cheap [Fri Aug 28 15:07:37 2015] then i checnge the fact he lives by the sea and then it might decide he does it becasue tuna is on sale at the supermarket and he was broke [Fri Aug 28 15:08:25 2015] I don't really understand what you're after. [Fri Aug 28 15:08:38 2015] if i should expect to do these things with coq [Fri Aug 28 15:08:59 2015] (of course not in natrual langauge but in logical language) [Fri Aug 28 15:09:52 2015] after a document that gives an example of asking and then modifying coqs axioms to change its proofs [Fri Aug 28 16:17:13 2015] thanks arcatan [Fri Aug 28 16:17:23 2015] I didnt know coqide had arguments too [Fri Aug 28 16:17:30 2015] but [Fri Aug 28 16:17:53 2015] I was wondering [Fri Aug 28 16:18:20 2015] in Init.Logic it says [Fri Aug 28 16:18:20 2015] Notation "A -> B" := (forall (_ : A), B) : type_scope. [Fri Aug 28 16:18:53 2015] yet I can still use -> normally [Fri Aug 28 16:19:04 2015] does that mean that it still imports Notations [Fri Aug 28 16:19:15 2015] or is this something built into Coq [Fri Aug 28 16:21:55 2015] * slaps arcatan around a bit with a large fishbot [Fri Aug 28 16:22:00 2015] uhhhh [Fri Aug 28 21:50:12 2015] What lemma lets me transform "f (if x then y else x)" to "if x then (f y) else (f z)"? [Fri Aug 28 22:07:26 2015] mdmkolbe: idk, but you could just destruct x [Fri Aug 28 22:50:35 2015] benzrf: destruct x is what I ended up doing [Fri Aug 28 22:50:54 2015] kk [Fri Aug 28 22:53:16 2015] mdmkolbe: afaik, there's no lemma for that in the stdlib. you could prove your own lemma. [Sun Aug 30 08:57:40 2015] hi [Sun Aug 30 08:57:48 2015] does anyone have ashort confluence proof in coq [Sun Aug 30 08:57:53 2015] for lambda calculus [Sun Aug 30 09:05:54 2015] confluence [Sun Aug 30 20:41:44 2015] hm [Sun Aug 30 20:43:40 2015] eauto is annoying me. At the end of the proof i have existential variables left. If i do "Grab Existential Variables." i get 3 subgoals, all of which are "X", all of which are solvable by "assumption." because "X : Type" is in the context. [Sun Aug 30 20:43:43 2015] :/ [Sun Aug 30 20:44:03 2015] that doesn't make sense to me [Sun Aug 30 21:05:51 2015] RegEchse: if you paste your code somewhere I can take a look [Sun Aug 30 21:13:34 2015] jrw: thx, but i'm leaving in an instant now. good night. [Mon Aug 31 07:12:41 2015] my goal has this [Mon Aug 31 07:12:52 2015] lift (S u) (if le_gt_dec v n then var (S n) else var n) = ... [Mon Aug 31 07:13:05 2015] how do I write a tactic that searches for le_gt_dec ?x ?y and destructs it? [Mon Aug 31 11:36:01 2015] vanila: something like this https://gist.github.com/wilcoxjay/c98e6bb39847bce69065 [Mon Aug 31 11:36:31 2015] oh excellent thanks ill try it [Wed Sep 2 10:26:51 2015] hello. I want to define a datatype that depends on two lists (the list of "done"-objects, and the list of "todo"-objects). the "done" list is only for proving properties, and should *not* be contained in extracted code, while the "todo" one (obviously) is computational. how can I achieve this? [Wed Sep 2 10:31:48 2015] schoppenhauer: unfortunately, the only way I know how to do that is to write the code twice -- once with and once without the stuff that you want erased -- and then prove them equivalent. [Wed Sep 2 10:32:14 2015] alternatively, if you can find a way of encoding what you want as a Prop, then you can do it in one go [Wed Sep 2 10:32:43 2015] jrw: the definition makes no sense without the stuff I did ("done"). [Wed Sep 2 10:33:00 2015] jrw: what about using "exists ..." ? will this be extracted? [Wed Sep 2 10:33:25 2015] (normally, exists ... is in prop, iirc.) [Wed Sep 2 10:34:01 2015] the problem is, I could define an inductive prop IsValid (done : List A) (todo : List A) [Wed Sep 2 10:35:13 2015] and then a function transform : forall (todo done : List A), IsValid done todo -> { todo2 | exists done2, IsValid done2 todo2 } [Wed Sep 2 10:35:34 2015] jrw: but then I would still have the "done" as an argument for this function. [Wed Sep 2 10:36:10 2015] hm. ok. but your suggestion is probably to just write a function List A -> List A, and then prove that everything is valid. [Wed Sep 2 10:38:08 2015] Maybe you could have the type [transform : forall (todo : List A), (exists (todo : List A), IsValide done todo) -> {todo2 | exists done2, IsValide done2 todo2}] ? [Wed Sep 2 10:38:54 2015] IsValid* [Wed Sep 2 10:38:57 2015] you mean done in the first quantor, but yes. this would probably be right. [Wed Sep 2 10:39:08 2015] and yes, done*, sorry [Wed Sep 2 10:39:10 2015] `exists` is non-computational, right? [Wed Sep 2 10:39:21 2015] that is, it will always be extracted to unit. [Wed Sep 2 10:39:26 2015] or to __ or whatever [Wed Sep 2 10:39:28 2015] It's in Prop, so yes [Wed Sep 2 10:39:35 2015] ok then I'll do it this way. [Wed Sep 2 11:06:35 2015] gallais pasted “coq:coqide installation fail” at http://lpaste.net/140123 [Wed Sep 2 11:07:02 2015] I get this weird error when trying to install coq:coqide using opam. Any clue? [Wed Sep 2 11:11:46 2015] Trying to find "bin/coqide" catches my eye. [Wed Sep 2 11:46:04 2015] Trying to configure coqide by hand yields an explanation: [Wed Sep 2 11:46:07 2015] Incomplete LablGtk2 (via ocamlfind): no /home/gallais/.opam/system/lib/lablgtk2/gSourceView2.cmi. [Wed Sep 2 11:47:25 2015] Shouldn't the build simply fail at this stage? [Wed Sep 2 15:13:07 2015] is anyone using proofgeneral-emacs in the terminal? [Wed Sep 2 15:13:28 2015] because ... I would like to do, but it underlines everything instead of changing its background color. [Wed Sep 2 15:14:52 2015] Does setting TERM=xterm-256color help? [Wed Sep 2 15:46:21 2015] Tuplanolla: no [Wed Sep 2 19:03:05 2015] is it just me or [Wed Sep 2 19:03:10 2015] is this not a theorem: [Wed Sep 2 19:03:55 2015] er, wait one sec [Wed Sep 2 19:05:31 2015] forall seq : nat -> list bool, (forall n : nat, seq n <> nil) -> (forall n : nat, list_subset (seq (S n)) (seq n)) -> exists b : bool, forall n : nat, elem b (s n) [Wed Sep 2 19:34:43 2015] Yeah, that's not a theorem. It requires an additional hypothesis like [forall b, (forall n, elem b (seq n)) \/ (exists n, ~elem b (seq n))]. There's no constructive way to go from [forall n : nat, P n + ~P n] to [(forall n, P n) + ~(forall n, P n)] (let alone to [(forall n, P n) + (exists n, ~P n)]) [Wed Sep 2 19:36:25 2015] jgross: thought so [Wed Sep 2 21:43:53 2015] how do i prove an equivalence in SSR? [Wed Sep 2 21:45:25 2015] ("split" does the trick, but doesn't look SSR-style to me) [Wed Sep 2 21:45:51 2015] (then again maybe it is) [Wed Sep 2 21:46:15 2015] ah it is, sorry [Wed Sep 2 23:39:19 2015] Is there an online tutorial/REPL? [Thu Sep 3 12:02:20 2015] Hey, everyone/close [Thu Sep 3 16:34:02 2015] is there a good tutorial on using the haskell extractor? [Thu Sep 3 16:34:42 2015] never tried it and too tired to read the wall of text, that is, a manual [Thu Sep 3 16:35:34 2015] there was a post on haskell planet quite recently but i cannot remember [Thu Sep 3 16:35:41 2015] who wrote it [Thu Sep 3 16:39:12 2015] found out that it's covered in the sf book [Thu Sep 3 16:57:56 2015] ugh [Thu Sep 3 16:58:02 2015] i don't get it [Thu Sep 3 16:58:15 2015] how do i extract option as maybe? [Thu Sep 3 16:58:49 2015] there is an example for the list type, but my adaptation of it doesn't work [Thu Sep 3 17:00:24 2015] ah. it's parsed top to bottom [Thu Sep 3 17:00:51 2015] you have to put it before the command that extracts into a file [Thu Sep 3 17:01:07 2015] doesn't work yet, but at least i can see the output [Thu Sep 3 17:05:41 2015] oh wow, the order of constructors inside the value constructor list matters [Thu Sep 3 17:05:55 2015] so you can get nonsense if you mess it up [Thu Sep 3 17:19:26 2015] how do i change the import list of the generated haskell code? [Thu Sep 3 17:20:40 2015] i wrote a line that maps option to maybe, but it doesn't export the data declaration itself and the module cannot find a proper library definition because prelude is imported qualified [Thu Sep 3 17:20:42 2015] halp [Thu Sep 3 17:23:09 2015] I haven't looked into this yet, but can you use it qualified too? [Thu Sep 3 17:24:43 2015] i haven't considered this [Thu Sep 3 17:24:52 2015] it'll probably work [Thu Sep 3 17:24:57 2015] but it's verbose [Thu Sep 3 17:25:03 2015] and unnecessary [Thu Sep 3 17:25:05 2015] for this code [Thu Sep 3 17:25:50 2015] i'm currently looking at johnw's linearscan trying to understand how things are organized there [Thu Sep 3 17:31:11 2015] i dont't know perl, but it seems it just substitutes the name like sed [Thu Sep 3 17:31:56 2015] https://github.com/jwiegley/coq-haskell/blob/a30a8975c524279a009625fd4a53e2fdb9d0b9dc/fixcode.pl [Thu Sep 3 17:53:21 2015] https://github.com/nkaretnikov/99-problems/commit/7b656c8347c91f36f669c21c2028e272c8c6aa9d here's what i ended up with [Thu Sep 3 17:53:37 2015] i'll try the notation trick from the repo i linked earlier [Thu Sep 3 17:53:44 2015] and see whether it'll make things prettier [Thu Sep 3 21:55:02 2015] i want to do a: "unfold func; simpl; fold func", but the func has some implicit type arguments and when I do the "fold func" it says it cant figure out what they are [Thu Sep 3 21:55:12 2015] how can I specify the implicit arguments to the fold tactic? [Thu Sep 3 21:55:52 2015] (I figured out my proof without it, by doing the unfold before induction, so that my IH had the unfolded statement in it, but I imagine this will come up again some time) [Thu Sep 3 22:11:52 2015] hrmm.. "Error: Universe inconsistency" [Thu Sep 3 22:11:55 2015] what did I do to get here? :) [Thu Sep 3 22:17:32 2015] trying to do pierce's SF exercise on church numerals, and for my definition of "succ" I get "Universe inconsentency" when I do: "Check three _ succ". [Thu Sep 3 22:18:34 2015] is this exercise not possible? [Thu Sep 3 23:35:30 2015] newsham: re: fold. sometimes it helps to say [fold (@foo x y z)], so that you can explicitly instantiate the implicit arguments. [fold] is generally not very well behaved IMHO, and I avoid using it. [Thu Sep 3 23:35:42 2015] newsham: re: universes. if you paste some code, I'd be happy to look at it. [Thu Sep 3 23:59:10 2015] jrw: let me put sometihng together ot paste [Fri Sep 4 00:04:25 2015] http://pastebin.com/KcTCAtuf [Fri Sep 4 00:05:00 2015] i imagine i have to do it "the hard way" to avoid the universes problem [Fri Sep 4 00:12:01 2015] (btw, this isn't for a class and I'm not asking for someone to do my hw :) [Fri Sep 4 00:17:03 2015] newsham: okay so like they say you can't iterate over nat because of universe stuff. [Fri Sep 4 00:17:24 2015] but there is an easy way around it. [Fri Sep 4 00:18:06 2015] if I want to do something n + m times, that's the same as doing it m times and then doing it n times again [Fri Sep 4 00:18:12 2015] see how far that gets you. [Fri Sep 4 00:23:22 2015] *nod* I know how to d it without incr.. its just more painful and not particularly enlightening [Fri Sep 4 00:23:38 2015] ditto for mult and exp. [Fri Sep 4 00:27:25 2015] newsham: yeah, it is frustrating, since most people's first instinct is to reuse previous definitions [Fri Sep 4 00:30:00 2015] newsham: one option is to define your succ/plus/mult to have a slightly different type, namely, try my_succ with type [forall X : Type, ((X -> X) -> X -> X) -> ((X -> X) -> X -> X)] [Fri Sep 4 00:30:14 2015] then you'll be able to use that to define plus [Fri Sep 4 00:33:18 2015] interesting [Fri Sep 4 14:35:53 2015] I'm having a hard time with an exercise to prove: n + n = m + m -> n = m. [Fri Sep 4 14:36:15 2015] What kind of a hard time? [Fri Sep 4 14:36:44 2015] using induction on n, I can prove the n=0 case by destruct m and then inversion [Fri Sep 4 14:37:08 2015] but for the inductive case where S n' + S n' = m + m -> S n' = m I am getting stuck [Fri Sep 4 14:38:00 2015] newsham: do you do induction before or after introducing m? [Fri Sep 4 14:38:14 2015] the exercise primed me by doing induction after intorducing n only. [Fri Sep 4 14:38:20 2015] the rest was left to me [Fri Sep 4 14:38:36 2015] Have you tried destruct m right there? [Fri Sep 4 14:39:27 2015] That should give you S n' = 0 and S n' = S m, which is much better than S n' = m. [Fri Sep 4 14:40:02 2015] yah, i need to destruc ton m [Fri Sep 4 14:40:08 2015] i just thought of that while asking the question :) [Fri Sep 4 14:42:51 2015] Extra credit: don't use inversion at all. [Fri Sep 4 14:43:41 2015] ok, got it done. [Fri Sep 4 14:43:55 2015] well the current exercise was to teach us to use inversion [Fri Sep 4 14:44:04 2015] Do it anyway. [Fri Sep 4 14:44:55 2015] ok, so this worked, but it seems long winded.. am I missing a more elegant solution? http://pastebin.com/iqNb69Xk [Fri Sep 4 14:45:52 2015] (using earlier: Theorem plus_n_Sm : forall n m : nat, S (n + m) = n + (S m). [Fri Sep 4 14:46:51 2015] The first branch can be dealt with destruct m. reflexivity. discriminate. to start. [Fri Sep 4 14:47:33 2015] It's not really more elegant; just shorter. [Fri Sep 4 14:53:20 2015] why do you recommend doing it without inversion? how would you approach it? [Fri Sep 4 14:53:51 2015] I don't recommend it. It's just an alternative to look at. [Fri Sep 4 14:57:56 2015] Here's one way to do it: do 2 rewrite plus_Sn_m in H. do 2 rewrite <- plus_n_Sm in H. do 2 apply eq_add_S in H. apply IHn' in H. apply f_equal. apply H. [Fri Sep 4 14:58:39 2015] ahh,, but f_equal is built using inversion :) [Fri Sep 4 14:58:54 2015] but i see where you're going with that [Fri Sep 4 14:59:16 2015] err. wait.. [Fri Sep 4 14:59:34 2015] f_equal does not use inversion.. nevermind [Fri Sep 4 15:11:22 2015] does "intros n m. generalize dependent n." come up often? is there a tactic that pulls in intros "over" others? [Fri Sep 4 16:07:42 2015] This is confusing me: http://pastebin.com/qQgx8dYa [Fri Sep 4 16:10:11 2015] Do you know the difference between forward and backward reasoning? [Fri Sep 4 16:11:05 2015] yes. when applying on the goal, "apply" should unify with the RHS of the theorem, and rewrite to the LHS, right? [Fri Sep 4 16:11:21 2015] and applying in a hypothesis would unify LHS and rewrite to RHS [Fri Sep 4 16:11:35 2015] Indeed. Now take a look at the arrow direction in app_length_cons. [Fri Sep 4 16:12:32 2015] app_length_cons says if I want to prove "S (length (l1 ++ l2)) = n." it suffices to prove "length (l1 ++ (x :: l2)) = n" [Fri Sep 4 16:13:01 2015] and my goal is "S (length (l' ++ x :: l')) = S (n' + S n')" [Fri Sep 4 16:13:46 2015] so shouldnt it rewrite my goal to "length (l' ++ l') = S (n' + S n')"? [Fri Sep 4 16:15:38 2015] oops, i did the rewrite wrong [Fri Sep 4 16:16:18 2015] It tries to unify S (length (l' ++ x :: l')) = S (n' + S n') with S (length (l1 ++ l2)) = n and fails, because there's no x. [Fri Sep 4 16:16:44 2015] Hint: assert (Ha : ...). [Fri Sep 4 16:30:03 2015] stuck.. [Fri Sep 4 16:31:50 2015] Further: assert (Ha : forall (l1 l2 : list X), ...). [Fri Sep 4 16:35:50 2015] i dont get what you're getting at [Fri Sep 4 16:37:05 2015] You need to prove an additional lemma. [Fri Sep 4 16:38:04 2015] btw, they asked us not to use length(l1 ++ l2) == length l1 + length l2. [Fri Sep 4 16:39:16 2015] That's fine. You just need to get that cons out from the middle of your list. [Fri Sep 4 16:42:00 2015] i'll just make a theory of the other direction of that cons implication [Fri Sep 4 16:44:29 2015] I was just trying to say that it's more convenient to prove on the spot: assert (Ha : forall (l1 l2 : list X), length (l1 ++ x :: l2) = S (length (l1 ++ l2))). [Fri Sep 4 16:45:39 2015] ahh, got it. [Fri Sep 4 16:45:52 2015] i ended up making the theory with an implication that did the same thing effectively. [Fri Sep 4 19:37:44 2015] Can I use a theory like this in forward reasoning? IHl1' : forall (l2 : list X) (l : list (X * X)), [Fri Sep 4 19:37:47 2015] length l1' = length l2 -> combine l1' l2 = l -> split l = (l1', l2) [Fri Sep 4 19:38:29 2015] for example I have an l2 and a theory that "lenght l1 = l2" right now. [Fri Sep 4 19:40:07 2015] s/theory/hypothesis" [Fri Sep 4 19:40:23 2015] and I have another hypothesis that "combine l1' l2' = l'". [Sat Sep 5 02:21:53 2015] can i make a model in verdi and somehow use it with c? [Sat Sep 5 14:56:00 2015] If I have a radical equation and I raise both sides to an integer power, is the set of solutions to the resulting equation always a superset of the original? [Sat Sep 5 14:56:12 2015] Does this theorem perhaps have a name or a known proof? [Sat Sep 5 14:59:57 2015] Tuplanolla: Not that I'm an analyst, but you could take any polynomial P(x) = 0 and then take the nth root of both sides. Should you have fewer solutions? [Sat Sep 5 15:00:45 2015] Intuition says so, but my common sense license was revoked in 2012, so I can't tell. [Sat Sep 5 15:00:55 2015] Similarly if you do P(x)*P(x) = 0... I think each of those zeros will be repeated twice. [Sat Sep 5 15:01:15 2015] So, if you do P(x)^n, you'll have n copies of the zeros in P(x) [Sat Sep 5 15:01:26 2015] This is multiplicity [Sat Sep 5 15:02:07 2015] Does that make sense? Want an example? [Sat Sep 5 15:02:29 2015] It does, but I'm concerned with sets instead of bags here. [Sat Sep 5 15:02:54 2015] I see x and x² being a trivial example of that. [Sat Sep 5 15:03:34 2015] (x_i - a_i) for x_i = a_i [Sat Sep 5 15:04:06 2015] Then you'd just have a_i repeated [Sat Sep 5 15:04:59 2015] also, my intuition license was revoked last night... 1 + 2 + 3... = -1/12 [Sat Sep 5 15:05:26 2015] Oh, Ramanujan's sums are fun. [Sat Sep 5 15:06:48 2015] I saw a few "proofs" but dang this is nonsense. [Sat Sep 5 15:07:24 2015] Any suggestions to get more nonsense like this? [Sat Sep 5 15:08:23 2015] They seem to come up wherever you look. The axiom of choice is usually involved though. [Sat Sep 5 15:10:41 2015] Would you like some examples? [Sat Sep 5 15:17:10 2015] sure [Sat Sep 5 15:17:20 2015] Tuplanolla: [Sat Sep 5 15:17:54 2015] There's a way to build a compact set that's connected but not path-connected, which involves some limit tricks. [Sat Sep 5 15:18:06 2015] There's also a way to build a compact set with an infinitely long boundary, which involves taking a Peano curve and making it sparse. [Sat Sep 5 15:18:52 2015] Where I learn this, Munkres? [Sat Sep 5 15:19:30 2015] There are also theorems named after von Neumann, Banach and Tarski, all describing ways to make seemingly impossible reconstructions of geometric objects. [Sat Sep 5 15:20:34 2015] I don't really know where to look. I usually hear colleagues describe them or find them in shady Wikipedia articles I drift to. [Sat Sep 5 15:20:42 2015] I'm familiar with the banach-tasrki paradox [Sat Sep 5 15:21:36 2015] The best I've seen before this is the 28 year trip to Andromeda. [Sat Sep 5 16:29:24 2015] jrw: hi, i have a question about verdi. is it somehow possible to make the verdi code talk to c? or are you aware of any tools that can do that? i know about the promela/spin pair, but they don't allow to generate c. so you need to write similar code twice. [Sat Sep 5 16:29:47 2015] nkaretnikov: depends on what you mean by "talk to C" [Sat Sep 5 16:29:58 2015] if you mean interface with C code somehow, that shouldn't be too bad [Sat Sep 5 16:30:03 2015] since ocaml has good support for that [Sat Sep 5 16:30:06 2015] and we extract to ocaml [Sat Sep 5 16:30:17 2015] jrw: integrate that into existing c project [Sat Sep 5 16:30:18 2015] if you mean "generate C code from your Verdi code", that would be hard [Sat Sep 5 16:30:36 2015] how reliable is the ocaml route? [Sat Sep 5 16:30:54 2015] ocaml itself is awesome [Sat Sep 5 16:31:04 2015] i've recently tried to extract to haskell (for other purposes), and the result required some modifications [Sat Sep 5 16:31:07 2015] extraction is fragile because it is hacky and syntactic and hard to audit [Sat Sep 5 16:31:19 2015] but we have mostly handled that for you [Sat Sep 5 16:31:19 2015] will the output be readable? [Sat Sep 5 16:31:24 2015] not really, no. [Sat Sep 5 16:31:35 2015] Is there a browser version of coq? [Sat Sep 5 16:31:38 2015] do you have any pointers? [Sat Sep 5 16:31:45 2015] pointers to what? [Sat Sep 5 16:31:55 2015] jrw: i've seen something about bytecode or some such [Sat Sep 5 16:31:59 2015] jrw: ocaml -> c [Sat Sep 5 16:32:02 2015] extraction [Sat Sep 5 16:32:11 2015] * has to go now, but i'll read the backlog [Sat Sep 5 16:33:21 2015] QF-MichaelK: you could check out PeaCoq. there's an instance running at http://goto.ucsd.edu:4242/ , but I don't think most people are supposed to know that yet :) [Sat Sep 5 16:34:00 2015] nkaretnikov: I'm still not sure what you mean. extraction is coq -> ocaml. to get the ocaml to talk to C, you would just use the normal ocaml ffi stuff. [Sat Sep 5 16:34:13 2015] ocaml also has a bytecode compiler, but that's mostly orthogonal [Sat Sep 5 16:34:55 2015] jrw: I hope someone is working on a scratch*coq system. [Sat Sep 5 16:35:16 2015] QF-MichaelK: not that I know of. how would that work? [Sat Sep 5 16:35:49 2015] jrw: Right now the best I have is figuring out the order... of the proof [Sat Sep 5 16:36:25 2015] But I imagine in this precise form of proofs that definitions and theorems can be used like lego blocks. [Sat Sep 5 16:36:51 2015] But, I don't understand how to modularize proofs. [Sat Sep 5 16:37:28 2015] Maybe it would be only useful for already done proofs, but could be a powerful teaching aid with some visualizations [Sat Sep 5 16:38:36 2015] hmm, I think that sounds pretty similar to peacoq's proof mode [Sat Sep 5 16:42:30 2015] also, there should be some sample proofs on peacoq [Sat Sep 5 16:43:30 2015] I don't know what you mean by proof mode [Sat Sep 5 16:54:25 2015] QF-MichaelK: peacoq is a very early stage project, so I wouldn't expect too much polish out of it yet. it's such a cool idea though. [Sat Sep 5 16:54:36 2015] QF-MichaelK: to see the proof mode just start a proof. [Sat Sep 5 17:01:29 2015] jrw: How can I trigger it? [Sat Sep 5 17:02:44 2015] okay so type some text in the box like "Lemma my_nat_fact : forall n, n + 0 = n." and then click the "Next" button [Sat Sep 5 17:05:07 2015] Oh, wow [Sat Sep 5 17:05:13 2015] not expected [Sat Sep 5 17:05:22 2015] It just... did it [Sat Sep 5 17:05:35 2015] automated theorem proving? [Sat Sep 5 17:06:10 2015] haha, something like that [Sat Sep 5 17:06:25 2015] it knows about all the tacitcs and which ones might be a good idea in the current goal [Sat Sep 5 17:06:35 2015] can't copy paste... [Sat Sep 5 17:06:55 2015] huh, I can. [Sat Sep 5 17:06:57 2015] nvm settings [Sat Sep 5 17:12:37 2015] jrw: Is this instance yours? [Sat Sep 5 17:12:48 2015] QF-MichaelK: no it's Ptival's [Sat Sep 5 17:12:52 2015] he's the author [Sat Sep 5 17:13:34 2015] is there a github for it? [Sat Sep 5 17:14:04 2015] yeah http://goto.ucsd.edu/peacoq/ [Sat Sep 5 17:14:11 2015] there's a github link there [Sat Sep 5 17:14:43 2015] thanks [Sat Sep 5 17:17:22 2015] This is dandy. [Sat Sep 5 17:17:31 2015] It's even got a small Vim in it. [Sat Sep 5 17:20:53 2015] :) [Sat Sep 5 18:02:50 2015] jrw: okay, i'll take a look [Sat Sep 5 19:43:24 2015] what is the ssreflect way to do [inversion]? [Sun Sep 6 15:05:55 2015] hey guys. I'm still on my headbrick project of understanding ssreflect. [Sun Sep 6 15:06:41 2015] I'm slowly getting the hang of the basics, although some proofs I'm running through are still giving me the "computer says your thing is proved!" error. [Sun Sep 6 15:07:31 2015] (... and I don't actually understand why.) [Sun Sep 6 15:08:05 2015] anyway, I'm going through ssrbool.v atm, and there's this big thing made about collective vs. applicative predicates. [Sun Sep 6 15:09:01 2015] can someone hold my hand and explain in small words why? [Sun Sep 6 22:26:03 2015] sanooj: hi [Mon Sep 7 03:02:29 2015] How would I set up a comparison between definitions? [Mon Sep 7 03:05:53 2015] Rather, how do I define a continuous function? [Mon Sep 7 07:48:04 2015] hello, How can I split a goal A <-> B into two subgoals? [Mon Sep 7 07:48:11 2015] split [Mon Sep 7 07:48:40 2015] asmanur: huh. the question is the answer. Thanks! [Mon Sep 7 10:11:37 2015] what's wrong with this definition: http://lpaste.net/140442 ? I'm getting "Last occurrence of "InIdx" must have "n" as 4th argument" error but I don't understand the reason. [Mon Sep 7 10:12:51 2015] You put [n : nat] as a parameter, wheareas you want an index here [Mon Sep 7 10:13:03 2015] so just replace the first line by [Inductive InIdx {A : Type} (a : A) (s : Stream A) : nat -> Prop :=] [Mon Sep 7 10:15:37 2015] thanks [Mon Sep 7 10:58:04 2015] how do I pass <= to a function that expects a -> a -> Prop? I think I'm doing the syntax wrong. [Mon Sep 7 10:58:22 2015] I'm trying (<=) but I'm getting Syntax error: [constr:operconstr level 200] expected after '(' (in [constr:operconstr]). [Mon Sep 7 10:59:01 2015] Refer to its name, le. [Mon Sep 7 10:59:24 2015] The <= is just notation. [Mon Sep 7 10:59:25 2015] ah right, forgot about "Locate" command. [Mon Sep 7 10:59:33 2015] got it. [Mon Sep 7 15:21:31 2015] Is it too much to do something like proving that the topological definition of continuity implies the convergent sequence definition? [Mon Sep 7 16:14:55 2015] QF-MichaelK: the annoying part of that will be writing down all the set theory stuff. [Mon Sep 7 16:22:17 2015] jrw: Hm, yeah, I'm not sure where to start, haven't "coded" or "proved" much in this realm. My analysis skills are also not so good [Mon Sep 7 16:22:32 2015] I was hoping it'd be easier to use the "proof assistant" ^.^ [Mon Sep 7 16:24:44 2015] Ideally working with Coq would be easier than without... [Mon Sep 7 16:25:04 2015] indeed [Mon Sep 7 16:26:34 2015] I did see some set theory stuff [Mon Sep 7 16:26:54 2015] https://gist.github.com/andrejbauer/d31e9666d5f950dd8ccd [Mon Sep 7 16:27:00 2015] Not sure if that's reasonable [Mon Sep 7 16:28:43 2015] http://geocoq.github.io/GeoCoq/ also not sure how this might mesh, but says except the tarski and hilbert continuities [Mon Sep 7 16:29:54 2015] Ah: https://coq.inria.fr/library/ maybe I include some library here [Mon Sep 7 16:34:32 2015] http://www.lix.polytechnique.fr/coq/pylons/contribs/files/Topology/v8.3/Topology.Continuity.html [Mon Sep 7 16:35:03 2015] sorry... no idea if this is a sane thing to do with limited experience [Mon Sep 7 16:44:55 2015] Definition continuous : Prop :=   forall V:Ensemble (point_set Y), open V -> open (inverse_image f V). .... I may be dumb but this doesn't look quite the same as: A function $f : X \rightarrow Y$ is said to be continuous if $\forall$ open sets $A\epsilon Y, f^{-1}(A)$ is open in $X.$ [Mon Sep 7 16:47:13 2015] What's this epsilon? [Mon Sep 7 16:47:26 2015] inclusino [Mon Sep 7 16:47:42 2015] That should be $\in$. [Mon Sep 7 16:47:48 2015] Ah! Thanks [Mon Sep 7 16:47:49 2015] nope, \subset [Mon Sep 7 16:48:50 2015] A function $f : X \rightarrow Y$ is said to be continuous if $\forall$ open sets $A, y\in A, f^{-1}(A)$ is open in $X.$ [Mon Sep 7 16:49:16 2015] no [Mon Sep 7 16:49:17 2015] what is y [Mon Sep 7 16:49:19 2015] you're right [Mon Sep 7 16:49:34 2015] just replace your \epsilon by \subset and everything's fine [Mon Sep 7 16:49:56 2015] Yeah, thanks [Mon Sep 7 16:50:07 2015] or \subseteq (depending on your intrepretation of \subset and \subseteq) [Mon Sep 7 16:50:50 2015] and that's exactly what the 'continuous' definition states, no? [Mon Sep 7 16:52:15 2015] eq, yeah, I think so [Mon Sep 7 16:54:17 2015] QF-MichaelK: that looks very reasonable to me. do you know if it's been ported to 8.4 or 8.5? [Mon Sep 7 16:55:39 2015] oh, yeah it's in the contribs. cool. [Mon Sep 7 16:55:41 2015] jrw: the 8.3 topology? No, I'm about as green as grass [Mon Sep 7 16:55:55 2015] where? [Mon Sep 7 16:56:04 2015] http://www.lix.polytechnique.fr/coq/pylons/coq/pylons/contribs/list/v8.4 [Mon Sep 7 16:56:44 2015] 8.4 works but not 8.5 http://www.lix.polytechnique.fr/coq/pylons/contribs/view/Topology/v8.4 [Mon Sep 7 16:57:34 2015] QF-MichaelK: this looks cool, but if you're doing it to learn, you might have a better time starting from scratch. [Mon Sep 7 16:58:34 2015] jrw: Hm, that's a good point. But, seeing how other people code helps me learn how I should be coding [Mon Sep 7 16:58:41 2015] that's also true [Mon Sep 7 16:59:12 2015] is there an apt-get coq ide? [Mon Sep 7 16:59:35 2015] oh, coqide [Mon Sep 7 16:59:36 2015] wow [Mon Sep 7 17:32:00 2015] QF-Michaelk, AFAIK debian and ubuntu does not have 8.5 in their repository, that's why I build them from source. It's also easy to do so [Mon Sep 7 18:56:55 2015] Is cow supposed to come with these standard libraries? [Mon Sep 7 18:57:09 2015] ex: Require Export Ensembles. [Mon Sep 7 19:11:22 2015] mine does [Mon Sep 7 19:12:18 2015] you can investigate your installation of coq and look in the "theories" directory [Mon Sep 7 19:13:32 2015] QF-MichaelK: also https://coq.inria.fr/distrib/current/stdlib/ lists the complete stdlib [Mon Sep 7 19:14:25 2015] you _should_ have those, unless your distro packager removed it or put it into a different package :) [Mon Sep 7 19:15:21 2015] Hello Coquettes! [Mon Sep 7 19:19:22 2015] psnively: hello [Mon Sep 7 19:19:33 2015] jrw: Good afternoon! [Mon Sep 7 19:20:26 2015] I’m afraid I’ve forgotten how to solve pretty basic implications that (look like they) are distributive over disjunctions. Can anyone take 5 minutes to point me in the right direction? I put a pastie at http://lpaste.net/140457 [Mon Sep 7 19:21:31 2015] I mean, unfold _says in *; tauto. of course proves it, because it’s a propositional tautology, but I’d like to understand how to use more basic tactics (again). [Mon Sep 7 19:21:35 2015] RegEchse: thanks [Mon Sep 7 19:24:29 2015] psnively: there are several ways to approach this. how would you convince me it's true intuitively? [Mon Sep 7 19:26:20 2015] jrw: I’d say: Knight A implies not Knight A or not Knight B. Knight A implies not Knight A is a contradiction, so the not Knight B case is the correct one, therefore Knight A and not Knight B. [Mon Sep 7 19:27:17 2015] okay, good. so let's try to translate that into basic tactics. [Mon Sep 7 19:27:27 2015] jrw: Thanks. :-) [Mon Sep 7 19:29:09 2015] the naive translation would be something like "either Knight A or not (Knight A). consider each case..." [Mon Sep 7 19:29:18 2015] but we don't want to do that in a constructive setting [Mon Sep 7 19:29:36 2015] jrw: Right. [Mon Sep 7 19:29:55 2015] especially since we know [tauto] can solve it, so there *is* a constructive proof out there :) [Mon Sep 7 19:30:15 2015] jrw: I thought about using cut (Knight A), but I’m not convinced I’ll be able to handle the later proof obligation. [Mon Sep 7 19:30:22 2015] +1. [Mon Sep 7 19:31:04 2015] right. [Mon Sep 7 19:34:59 2015] jrw: It does seem like I should be able to distribute Knight A right over the disjunction, i.e. that I should be able to derive (Knight A /\ ~Knight A) \/ (Knight A /\ ~Knight B). Or is that only true classically? [Mon Sep 7 19:35:41 2015] Actually, that’s not even right. [Mon Sep 7 19:35:59 2015] psnively: which disjunction are you talking about? [Mon Sep 7 19:36:21 2015] (Knight A -> ~Knight A) \/ (Knight A -> ~Knight B). [Mon Sep 7 19:36:48 2015] jrw: Sorry, in the hypothesis. [Mon Sep 7 19:37:18 2015] that seems right to me, yeah :) [Mon Sep 7 19:37:58 2015] jrw: Can I rewrite the hypothesis, then? [Mon Sep 7 19:38:19 2015] hmm, well maybe that's not right. now I've gotten myself confused [Mon Sep 7 19:38:29 2015] jrw: Glad it’s not just me. :-D [Mon Sep 7 19:39:55 2015] psnively: okay, yeah, that's not necessarily true in general. but what is true is that if you have [P -> (~ P \/ Q)] then you can get [P -> Q] [Mon Sep 7 19:40:48 2015] jrw: OK. Then it seems like, thanks to the bi-implication, we can get the other way, assuming we can keep P -> Q in the context. [Mon Sep 7 19:41:21 2015] But one step at a time: how do I get P -> Q out of P -> (~P \/ Q)? [Mon Sep 7 19:41:38 2015] I think you should try to prove that as a lemma [Mon Sep 7 19:41:50 2015] [Lemma imp_or_distr : forall P Q : Prop, (P -> ~ P \/ Q) -> (P -> Q).] [Mon Sep 7 19:41:59 2015] if you follow your nose, you should get it. [Mon Sep 7 19:42:17 2015] Hmm. Is that not in the standard library somewhere? [Mon Sep 7 19:42:40 2015] Anyway, I’ll give it a shot. Thanks! [Mon Sep 7 19:42:40 2015] psnively: it might be, but you might learn more by proving it :) [Mon Sep 7 19:43:07 2015] jrw: I was just thinking that. Thanks again! [Mon Sep 7 19:51:57 2015] jrw: And I was hoping to avoid introducing the quantifiers just yet, but oh well. [Mon Sep 7 19:54:06 2015] jrw: [Mon Sep 7 19:54:07 2015] Lemma imp_or_distr : forall P Q : Prop, (P -> ~ P \/ Q) -> (P -> Q). [Mon Sep 7 19:54:08 2015] Proof. intros. pose proof (H H0) as NPQ. inversion NPQ. contradiction. assumption. [Mon Sep 7 19:54:09 2015] Qed. [Mon Sep 7 19:54:14 2015] cool [Mon Sep 7 19:54:30 2015] Yeah, but quantifiers and “pose proof” for something that basic? [Mon Sep 7 19:55:02 2015] jrw: Is this where you tell me it already is in the standard library? :-) [Mon Sep 7 19:55:07 2015] well, there's [tauto] :) [Mon Sep 7 19:55:19 2015] jrw: Yeah, fair enough! [Mon Sep 7 20:07:10 2015] psnively: okay so have you applied that lemma? [Mon Sep 7 20:07:59 2015] jrw: Well, I’m trying to make the lemma a bi-implication. [Mon Sep 7 20:10:19 2015] okay, but I don't think you'll need that [Mon Sep 7 20:14:14 2015] jrw: Really? Hmm. [Mon Sep 7 20:15:35 2015] jrw: OK, took it out... [Mon Sep 7 20:18:00 2015] Now I have... [Mon Sep 7 20:18:02 2015] H : ~ Knight B [Mon Sep 7 20:18:02 2015] H0 : ~ Knight A \/ ~ Knight B -> Knight A [Mon Sep 7 20:18:03 2015] Knight A /\ ~ Knight B [Mon Sep 7 20:18:21 2015] inversion H0 doesn’t work because H0 isn’t inductive... [Mon Sep 7 20:21:02 2015] Ugh… and nevermind… apply imp_or_distr with (Q := ~Knight B) in H also gives me an unbelievably hairy second proof obligation. I think I’m still on the wrong track. [Mon Sep 7 20:22:45 2015] I'm sorry to barge in in the middle of all this, but you want to prove [Knight A /\ ~ Knight B] with the previous assumptions, right? Why not start with a [split], and then it should be natural. [Mon Sep 7 20:24:15 2015] I want to show that topological continuity implies metric continuity, but am having a lot of trouble getting it set up still [Mon Sep 7 20:29:45 2015] Cypi: Sorry, where? [Mon Sep 7 20:30:39 2015] If you have [H : ~ Knight B] and [H0 : ~ Knight A \/ ~ Knight B -> Knight A] and want to prove [Knight A /\ ~ Knight B], then starting with a [split] might be a good idea [Mon Sep 7 20:30:46 2015] Cypi: Here’s the full starting script: http://lpaste.net/140457 [Mon Sep 7 20:30:48 2015] (sorry if I misunderstood everything) [Mon Sep 7 20:31:11 2015] Cypi: No, it’s not a bad suggestion. [Mon Sep 7 20:34:23 2015] I don’t know. Anytime I actually use imp_or_distr, I get a gargantuan proof obligation I don’t have any idea what to do with. [Mon Sep 7 20:36:03 2015] hmmm forward conflict, crtl + alt + down is also a windowing command [Mon Sep 7 20:37:19 2015] You can configure the "Ctrl + Alt" part in Edit >> Preferences >> Shortcuts [Mon Sep 7 20:38:46 2015] sorry if this is a dumb question, but can anyone give me an example of a system where equality of nats is undecidable? when I read something like "in a system with decidable equality of nats" it makes zero sense to me. [Mon Sep 7 20:39:42 2015] Cypi: thanks [Mon Sep 7 20:42:17 2015] Cypi: Hm, not sure how to use this... ctl, alt... all over the place here [Mon Sep 7 20:42:28 2015] no specific key bindings [Mon Sep 7 20:42:31 2015] like, how can you not decide equality of nats? isn't it just data Nat = Zero | Succ Nat etc. [Mon Sep 7 20:44:45 2015] nope, can't seem to use that to change anything [Mon Sep 7 20:44:45 2015] QF-MichaelK : on the "Modifiers for Navigation Menu", you can choose which combination of modifiers should enable the Navigation shortcuts [Mon Sep 7 20:44:56 2015] Oh, also, you need to restard CoqIDE [Mon Sep 7 20:44:58 2015] for reasons... [Mon Sep 7 20:45:20 2015] ahhhhh [Mon Sep 7 20:46:14 2015] Yes, much better, restarting, silly me [Mon Sep 7 20:46:30 2015] Too bad it doesn't say that in the panel [Mon Sep 7 20:46:50 2015] The UI is not perfect indeed [Mon Sep 7 20:47:31 2015] yes, but I'm glad it exists [Mon Sep 7 21:13:36 2015] Can anyone else suggest a “just basic tactics” approach to http://lpaste.net/140457 ? I’m afraid I’m still stuck. :-) [Mon Sep 7 21:14:27 2015] I started by just proving [Knight A] [Mon Sep 7 21:15:23 2015] The first step is obvious, and then you have to prove [~ Knight A \/ ~ Knight B]. You cannot prove (~ Knight A] there, but you can prove [~ Knight B] [Mon Sep 7 21:16:11 2015] Cypi: What approach did you take, if I may ask? [Mon Sep 7 21:16:22 2015] Do you want directly the script? [Mon Sep 7 21:17:22 2015] Well, sure, that’s one way. :-) [Mon Sep 7 21:17:59 2015] As you wish: http://lpaste.net/140459 [Mon Sep 7 21:18:39 2015] Thanks! Ah, using the proof structuring support. Nice. [Mon Sep 7 21:19:42 2015] Yeah, I figured I’d need assert or cut. Very good. [Mon Sep 7 21:20:59 2015] while using auto is there a way to print used tactics? [Mon Sep 7 21:21:10 2015] You don't _need_ assert/cut, but obviously it's shorter :) [Mon Sep 7 21:21:29 2015] osa1 : with some luck, [Info 1 auto] might do that. It can also print useless stuff, sadly [Mon Sep 7 21:21:45 2015] (not every tactic has been transitioned to the new tactics engine, this is why) [Mon Sep 7 21:25:44 2015] thanks, will try that.. [Mon Sep 7 21:31:10 2015] Cypi: This is exactly what I was struggling with/wanted. Thanks so much! [Mon Sep 7 21:41:52 2015] Anyone know of jobs in Coq [Mon Sep 7 21:52:11 2015] reading some basics: https://coq.inria.fr/tutorial-nahas [Mon Sep 7 21:52:43 2015] I skipped way ahead without understanding this stuff... [Mon Sep 7 21:53:25 2015] Big_G: You could presumably make something cool with coq and make it your own job... Ex: math education for kids coq*scratch? [Mon Sep 7 22:03:56 2015] I meant in an established company [Mon Sep 7 22:04:58 2015] Big_G: I think not enough people are aware of it yet, and the people who are would mostly be researchers. Maybe a professorship or math PhD? [Mon Sep 7 22:05:24 2015] I don't have either [Mon Sep 7 22:05:57 2015] I meant to pursue a math PhD... Lots of programs pay PhD students [Mon Sep 7 22:10:35 2015] ohh I think I finally get it... "equality of nats is decidable" <- this basically means that we can have eq_nat_decide in Coq. e.g. I can destruct (eq_nat_decide n1 n2) in my proofs. [Mon Sep 7 22:11:09 2015] although I'm still having trouble imagining a system without that. [Mon Sep 7 23:05:33 2015] osa1: but you could have other types where equality isnt decidable, like constructive reals. [Mon Sep 7 23:08:32 2015] [15:53] < QF-MichaelK> Big_G: You could presumably make something cool with coq and make it your own job... Ex: math education for kids coq*scratch? [Mon Sep 7 23:08:37 2015] are there any kids lessons with coq? [Mon Sep 7 23:16:47 2015] newsham: Depends on what you mean by a kid. But, probably no, I don't suspect it'd be appropriate until there's an associated visual programming language [Mon Sep 7 23:17:03 2015] I don't think that is in the works yet. You should make it! [Mon Sep 7 23:18:11 2015] It'd be nice to construct some pictoral representations of states during the proof. I think this would be part of that goal. [Tue Sep 8 00:33:45 2015] like https://www.cs.washington.edu/verigames ? [Tue Sep 8 00:48:57 2015] newsham: Ah, yes, but for math instead of code. And more geared to making the players become experts than simplifying the problems. [Tue Sep 8 00:49:04 2015] thanks for the share! [Tue Sep 8 05:28:26 2015] hello, I have a H2: 'andb testa testb = true'. how can I get 'testa = true' and 'testb = true'? [Tue Sep 8 05:30:55 2015] split H2? [Tue Sep 8 05:32:03 2015] QF-MichaelK: huh, solved. There's already a theorem defined as (andb b1 b2 = true -> b2 = true) [Tue Sep 8 05:33:10 2015] riaqn: so intros? [Tue Sep 8 05:33:46 2015] QF-MichaelK: so I just apply it. with (b1:=testa) (b2:=testb) [Tue Sep 8 05:33:47 2015] Getting started with coq, intros. [Tue Sep 8 05:34:07 2015] there's a decent pun in there somewhere [Tue Sep 8 05:34:25 2015] ah, yes [Tue Sep 8 05:34:50 2015] I'm trying to prove without coq, couldn't figure out how to phrase my problem. [Tue Sep 8 06:42:07 2015] same error: http://www.lix.polytechnique.fr/coq/pylons/logs/view/ZornsLemma/-5673840384087064485 [Tue Sep 8 06:43:56 2015] Trying to get http://www.lix.polytechnique.fr/coq/pylons/contribs/view/Topology/v8.4 to work again... [Tue Sep 8 06:44:06 2015] tried http://stackoverflow.com/questions/16202666/coqide-cant-load-modules-from-same-folder [Tue Sep 8 06:44:29 2015] make from the directory starts to do stuff then fails with that error [Tue Sep 8 06:44:52 2015] tried as in, added: Add LoadPath "". [Tue Sep 8 07:40:36 2015] hello, in proof general, is there anyway to jump to the definition of a type/function? [Tue Sep 8 08:05:25 2015] riaqn: I *think* it is M-x . but I am not sure. [Tue Sep 8 08:05:50 2015] (but it is sure worth a try ;) ) [Tue Sep 8 08:07:18 2015] ok. so I have the following problem: I need to work with a file that should be streamed. so far I did this using lists and relying on haskell's lazyness. but now I want to extract to ocaml. I *could* rewrite everything into thunk encoding, this would be the "obvious" way. but is there another way? [Tue Sep 8 08:07:31 2015] schoppenhauer: M-x and what? M-x only brings out a prompt for further invocation. [Tue Sep 8 08:07:52 2015] you go to the name of the definition and do M-x . [Tue Sep 8 08:08:26 2015] riaqn: ah ok, sry, I mixed it up with SLIME [Tue Sep 8 08:20:59 2015] I guess you will have to use etags then [Tue Sep 8 08:21:16 2015] (which I never did ... but gugel probably knows) [Tue Sep 8 08:37:03 2015] which level does the notation _ :: _ have? [Tue Sep 8 08:38:49 2015] schoppenhauer: Notation "x :: l" := (cons x l) (at level 60, right associativity). [Tue Sep 8 08:39:07 2015] riaqn: thx [Tue Sep 8 08:39:24 2015] it's defined in Lists.v, SF. [Tue Sep 8 08:45:04 2015] thx [Tue Sep 8 08:51:45 2015] Some x => unsafeSlowResolveBackRefs r (x :: l) [Tue Sep 8 08:51:51 2015] wah sorry. window focus fail. [Tue Sep 8 11:13:47 2015] Is there any tactics library that solves stuff for lists? because ... equalities containing :: and ++ can often be resolved pretty automatically. [Tue Sep 8 15:31:59 2015] is it just me or has ssreflect jumped over the deep end wrt. notations? [Tue Sep 8 16:15:22 2015] I'm having trouble getting zornslemma to compile, help? [Tue Sep 8 16:15:32 2015] same as : http://www.lix.polytechnique.fr/coq/pylons/logs/view/ZornsLemma/-5673840384087064485 [Tue Sep 8 17:52:06 2015] woah. reading coq's Bool/*.v is like a leisurely walk in the park on a lazy sunday afternoon compared to ssrbool. [Tue Sep 8 17:53:15 2015] haha [Tue Sep 8 17:53:25 2015] sanooj: ssreflect does have a certain... information density to it [Tue Sep 8 17:53:53 2015] optimized for terseness. reminds me of forth or j. [Tue Sep 8 17:55:31 2015] I still have yet to master n-tuple's [Tue Sep 8 17:55:57 2015] so my actual goal is to prove the AKS algorithm correct. [Tue Sep 8 17:57:00 2015] the basic proof is not all that hard, but it does require a little bit of theory from cyclotomic fields. [Tue Sep 8 17:57:37 2015] hence, I figured ssreflect + the mathematical components would be just what I need. [Tue Sep 8 17:57:42 2015] sure [Tue Sep 8 17:58:59 2015] to be honest, the underside of the carpet is frickin scary, I'm not really sure anymore. [Tue Sep 8 18:00:17 2015] it just takes getting used to [Tue Sep 8 18:00:27 2015] I really enjoy ssr+mc, even though I'm still in Padowan stage [Tue Sep 8 18:01:09 2015] thanks for the encouragement. :) [Tue Sep 8 18:02:46 2015] but today, the brein is full to the brim with ssrbool already. must crash and forget some. [Tue Sep 8 18:02:51 2015] nite [Tue Sep 8 18:02:53 2015] what's cool is thinking you understand it, writing a neat 3 line proof, and then asking Gonthier about it and he sends you back a 1 liner [Tue Sep 8 18:03:36 2015] I feel like I'd need to sit in a Master Class with him for a semester to really know the best way to approach the sorts of problems ssr+mc are good at solving [Tue Sep 8 18:04:13 2015] I'd settle for "just" a proof. :) [Tue Sep 8 18:04:27 2015] anyway, must really sleep. ttyl. [Tue Sep 8 18:04:32 2015] sleep well [Tue Sep 8 18:26:16 2015] do anyone have an idea of what Coq CreateHintDb do? Funny stuff are happening... https://github.com/lolisa/CoqCore/blob/master/MoreJMeq.v  line 42 is doing nothing while it should be at least as powerful as line 43, also removing "discriminated" from line 4 also fix the problem [Wed Sep 9 05:06:54 2015] I'm trying to build an Inductive type similar to a (list (nat * nat)), but with a further constraint [Wed Sep 9 05:07:43 2015] the fst natural is increasing [(1,_), (2,_), (3,_)] [Wed Sep 9 05:08:31 2015] Can I express this constraint in the type itself? [Wed Sep 9 05:09:07 2015] I would like to say something like: [Wed Sep 9 05:09:15 2015] [] is a mylist [Wed Sep 9 05:09:30 2015] [(0, _)] is a mylist [Wed Sep 9 05:10:25 2015] You can put the start index in the type [Wed Sep 9 05:10:29 2015] if l = (n, _) :: _ is a mylist, then (S n, _) :: l is a mylist [Wed Sep 9 05:10:45 2015] have mylist : nat -> Set [Wed Sep 9 05:11:17 2015] and then do the union (eg. with an exists: mylist' = exists n, mylist n) [Wed Sep 9 05:13:08 2015] asmanur: thx! I have to try, since I'm not sure to have understood your second hint... [Wed Sep 9 05:31:48 2015] hi, I just tried http://pastebin.com/w9YM0U2j [Wed Sep 9 05:32:05 2015] and then I get the error that "id" has type ID while it should be Set,Prop or Type [Wed Sep 9 05:32:08 2015] why? What? [Wed Sep 9 05:33:27 2015] how is id defined ? [Wed Sep 9 05:33:51 2015] in an arrow type you should have types/prop things not values (what is the meaning of 3 -> 2 ?) [Wed Sep 9 05:34:35 2015] I'm just trying to define simple untyped lambda calculus [Wed Sep 9 05:35:02 2015] where x for instance is a valid lambda term, in the form of a symbol [Wed Sep 9 05:35:31 2015] yes, but how is id defined? [Wed Sep 9 05:36:06 2015] how it seems it is a Coq builtin for the identity [Wed Sep 9 05:36:08 2015] two secs, it's the builtin definition [Wed Sep 9 05:36:20 2015] ah [Wed Sep 9 05:36:21 2015] yes it's the identity function, so i don't think you want that here [Wed Sep 9 05:36:21 2015] opps [Wed Sep 9 05:36:27 2015] that's very correct :) [Wed Sep 9 05:36:52 2015] I guess I want it inductive too, Id int ... [Wed Sep 9 08:05:39 2015] asmanur: my solution http://paste2.org/ByL6INLv [Wed Sep 9 08:06:51 2015] manwaz: I don't think it's correct. Doesn't it accept [(1, _), (2, _), (1, _), (2, _)] ? [Wed Sep 9 08:16:22 2015] asmanur: you are right, the recursive step should read indexed t, without the prime [Wed Sep 9 08:16:43 2015] es [Wed Sep 9 08:16:44 2015] yes [Wed Sep 9 08:17:27 2015] how do I check if a list has type mylist? [Wed Sep 9 08:18:36 2015] Check [(1,2) ; (2, 0) ; (3,99)] gives list (nat * nat) [Wed Sep 9 08:26:45 2015] well [Wed Sep 9 08:27:04 2015] elements of type mylist are pairs (liste, proof_that_the_list_is_indexed) [Wed Sep 9 16:36:15 2015] I'd like to write a predecessor function that only works on natural numbers greater than 0 [Wed Sep 9 16:37:40 2015] i.e. kind of like Definition pred (n:nat) := match n with S n' => n' end. [Wed Sep 9 16:38:21 2015] that gives a "non exhautive pattern-matching" error [Wed Sep 9 16:39:01 2015] heinrich5991: there are basically two approaches: return a bogus value in the case that shouldn't happen and then all theorems about pred take a hypothesis that the argument is valid, or you can make the type of pred contain the precondition using a [sig] type for the argument. [Wed Sep 9 16:39:26 2015] something like pred : {n : nat | n <> 0} -> nat [Wed Sep 9 16:40:28 2015] I'm interested in the latter approach, since the standard library takes the former [Wed Sep 9 16:41:34 2015] heinrich5991: you might like to look at the Program commands, since they support this style [Wed Sep 9 16:44:04 2015] ok thanks so far, will follow your pointers [Wed Sep 9 16:46:06 2015] Or you may want to have a look at the match...return...with construct. Spoiler: http://lpaste.net/140560 [Wed Sep 9 16:50:37 2015] I think false_rect is what I'm looking for [Wed Sep 9 16:52:06 2015] gallais: how did you construct the proof of False for False_rect? [Wed Sep 9 16:53:51 2015] you pass False_rect whatever from your context is False, and you'll get back whatever you want [Wed Sep 9 16:54:16 2015] it's the same as Haskell's "absurd" [Wed Sep 9 16:54:29 2015] The trick is that the "as...return" clause make it so that "m <> 0 -> _" becomes "0 <> 0" in the 0 branch [Wed Sep 9 17:09:21 2015] heinrich5991 revised “pred with precondition”: “No title” at http://lpaste.net/140560 [Wed Sep 9 17:10:10 2015] gallais: I'm having serious problems understanding this function. do you know where I can read up on "as" or "return"? [Wed Sep 9 17:10:55 2015] (I tried to comment in the paste what I already understand, but it's not much) [Wed Sep 9 17:15:02 2015] npr is the argument of type {n : nat | n <> 0} [Wed Sep 9 17:16:29 2015] what are the elements of the pair [Wed Sep 9 17:16:31 2015] ? [Wed Sep 9 17:16:42 2015] the natural number and a PRoof? [Wed Sep 9 17:19:10 2015] I guess this is a fairly good step by step introduction: http://matthew.brecknell.net/post/pattern-matching-dependent-types-in-coq/ [Wed Sep 9 17:19:38 2015] yes: the natural number n and the proof pr that it is different from 0 [Wed Sep 9 17:20:14 2015] ok, thanks for the link and your help! [Wed Sep 9 17:38:38 2015] No bother! [Wed Sep 9 17:57:28 2015] 5/quit [Thu Sep 10 07:53:48 2015] Hello everyone. [Thu Sep 10 07:54:13 2015] I am trying to prove http://lpaste.net/140598 [Thu Sep 10 07:55:04 2015] classical (Definition classic := forall P : Prop, ~~P -> P.) implies excluded middle ( Definition excluded_middle := forall P:Prop, P \/ ~P.) [Thu Sep 10 07:55:36 2015] but in the proof I am stuck with circular definition [Thu Sep 10 07:56:12 2015] could some one please give me some hint how to get out of this circle. [Thu Sep 10 07:57:21 2015] keep_learning: after "apply or_introl" you're trying to prove an arbitrary P is true [Thu Sep 10 08:00:04 2015] To elaborate on that, if you do [apply or_introl], then it means that [classic] implies that any proposition P is true. Similarly, if you do [apply or_intror], then it means that [classic] implies that any proposition P is false. So you have to do something else. [Thu Sep 10 08:02:17 2015] aj: Cypi Thank you. [Thu Sep 10 08:29:20 2015] Cypi: We can write P \/ Q as ~P => Q so in this case P \/ ~P is ~P => ~P. is this correct line of thought ? [Thu Sep 10 08:33:52 2015] This only holds classically, but since you assume a classical axiom, then it's correct, yes [Thu Sep 10 08:34:11 2015] except that I don't think it will help you prove [classical -> excluded_middle] :) [Thu Sep 10 08:36:16 2015] keep_learning: i found "~ (P \/ Q) <-> (~ P) /\ (~ Q)" a helpful lemma fwiw. it's provable with just tauto fwiw [Thu Sep 10 08:36:57 2015] Cypi: yes because I am not able to rewrite the goal ( P \/ ~P ) with ~P => ~P [Thu Sep 10 08:46:52 2015] keep_learning: you don't have to. [spoiler alert] Note that your hypothesis H applies to _any_ P : Prop, e.g. your current goal. ;) [Thu Sep 10 08:47:14 2015] eh, with "current" i meant "initial" [Thu Sep 10 10:53:58 2015] is it possible in coq to tell that the termination of a function is proved in a second theorem (that is: defining functions that might not terminate)? [Thu Sep 10 10:54:20 2015] (they terminate, but I want to prove this later, because it makes the term more complicated otherwise) [Thu Sep 10 10:54:48 2015] (I mean, otherwise I would just pass a dummy-upper-bound that is much too large and use it, but well, that is less beautiful) [Thu Sep 10 10:55:08 2015] In the built-in stuff, I think Function can do that, right? I never used it though [Thu Sep 10 10:55:18 2015] Maybe even Program [Thu Sep 10 10:55:29 2015] (sorry, cannot help much more) [Thu Sep 10 10:58:00 2015] schoppenhauer: http://adam.chlipala.net/cpdt/html/GeneralRec.html [Thu Sep 10 10:58:05 2015] "well-founded recursion" [Thu Sep 10 10:59:49 2015] hm. I know well-founded recursion. ok, according to this text, I will have to introduce a dummy bound. [Thu Sep 10 10:59:52 2015] then I will do so. [Thu Sep 10 11:01:28 2015] thx [Thu Sep 10 11:01:58 2015] schoppenhauer: your can use Program Fixpoint. [Thu Sep 10 11:02:13 2015] s/your/you/ [Thu Sep 10 11:02:29 2015] but program fixpoint has this strange obligation stuff which I do not really like [Thu Sep 10 11:02:54 2015] I can give an upper bound (something like exp(exp(exp(list-length)))) and thats probably easier. [Thu Sep 10 11:02:56 2015] but thx. [Thu Sep 10 11:03:10 2015] You said you wanted to prove it later. You can admit the obligation for now. [Thu Sep 10 11:13:54 2015] also, obligations are exactly that: delayed proofs [Thu Sep 10 13:51:04 2015] I'm attempting to build ProofGeneral 4.2 with emacs 24.4.1, but make is reporting that the function 'isar-markup-ml' is undefined. Has anyone encountered this? There is a bug report indicating that this was fixed in the latest ProofGeneral release. Or perhaps a different channel is appropriate? [Thu Sep 10 13:56:23 2015] Nevermind; I apparently missed the link for the latest release of ProofGeneral on the website. Thanks anyways. [Thu Sep 10 18:09:07 2015] I'm trying to work on a definition that uses '|-' in a notation, but I can't write "match goal" tactics [Thu Sep 10 18:09:33 2015] Is there any way to fix that? [Thu Sep 10 18:10:14 2015] that is, the notation is taking precedence over a "[_ |- _]" goal pattern [Thu Sep 10 18:29:20 2015] ah [Thu Sep 10 18:29:28 2015] napping: I've wondered that before myself [Thu Sep 10 18:29:37 2015] I've found nothing [Thu Sep 10 18:30:04 2015] Looks like the changing to unicode Γ ⊢ tfalse ∈ TBool [Thu Sep 10 18:30:07 2015] works well enough [Thu Sep 10 18:30:53 2015] Unicode is the solution to all problems except itself [Thu Sep 10 18:31:55 2015] I guess that was accidental - the html pages of software foundations render it as unicode, but the actual file does say Reserved Notation "Gamma '|-' t '\in' T" (at level 40). [Thu Sep 10 18:33:38 2015] A boring '|--' would probably work just as well [Thu Sep 10 18:34:04 2015] time for me to head out [Thu Sep 10 19:17:42 2015] interesting. ltac expressions seem to ignore notation scopes. Is that a bug? o.o i mean, if i define |- as notation in "myscope" but do _not_ open that scope, i still can't use |- in match goal afterwards. that's ... strange to me [Fri Sep 11 08:01:23 2015] hi [Fri Sep 11 08:02:59 2015] how do de bruijn substitutions commute? [Fri Sep 11 13:50:43 2015] hooray \o/- [Fri Sep 11 13:50:51 2015] finally completed my proof of confluence [Fri Sep 11 13:51:05 2015] that was hard work [Fri Sep 11 13:52:28 2015] vanila: of what TRS? [Fri Sep 11 13:53:24 2015] de brujin terms of lambda calculus [Fri Sep 11 18:04:21 2015] is there a such thing as a coinduction principle [Fri Sep 11 18:07:07 2015] also: someone come up with a proper pun involving the duction of coins [Fri Sep 11 18:22:17 2015] benzrf: I feel as though I've encountered something like this [Fri Sep 11 18:22:25 2015] perhaps in the paper Total Functional Programming [Fri Sep 11 19:03:35 2015] what does coinduction on nats look like [Fri Sep 11 19:03:37 2015] augh [Fri Sep 11 19:09:03 2015] wait never mind!!!! [Fri Sep 11 19:09:19 2015] aaaaaaAAAAAAAAAAA I think i might have figured out how to do the thing im trying to figure out :DDD [Fri Sep 11 20:55:54 2015] if anybody's here [Fri Sep 11 20:56:09 2015] is it the case that [Fri Sep 11 20:56:53 2015] ugh, how to put this [Fri Sep 11 20:57:28 2015] it seems like any proof of ~~P must contain a proof of P, since the only way to get a False to return is to supply a P to the negation argument [Fri Sep 11 20:58:22 2015] so in the event that ~~P is provable but P is not, that means that it must be possible to construct a P using a ~P, in a way less trivial than explosion [Fri Sep 11 20:58:32 2015] is that roughly right? [Fri Sep 11 20:58:41 2015] * hopes to ear an ansewrt [Fri Sep 11 20:58:50 2015] * hopes to hear an answer to [Fri Sep 11 21:03:50 2015] 'less trivial than explosion' because you cant get a False until you have a P [Fri Sep 11 21:13:07 2015] makes me think all logic is auto-epstomologic [Fri Sep 11 21:17:46 2015] that is that all logics have to be aware of the fact they are part of their own universes and deal with their language... that mean P and ~P and ~~P must be undertood to be understood outside of just logic [Fri Sep 11 21:26:28 2015] loves(A,_) => capableOfLove(A). [Fri Sep 11 21:27:08 2015] ~capableOfLove(rock). [Fri Sep 11 21:27:29 2015] means: ~loves(rock,_) [Fri Sep 11 21:28:16 2015] or is already "loves(rock,_)" not even wff? [Fri Sep 11 21:28:33 2015] lets say its wff [Fri Sep 11 21:29:05 2015] thus ~loves(rock,_) is fine [Fri Sep 11 21:31:16 2015] benzrf, i think what you are saying is P has to be compatable with negation and say nothing absurd [Fri Sep 11 21:31:26 2015] uhh [Fri Sep 11 21:31:43 2015] and say nothing absurd while its both negative or not negatibe both? [Fri Sep 11 21:32:38 2015] what i mean is that the quantification of the variables inside of P have to continue to make sense [Fri Sep 11 21:33:25 2015] that somehow double negation has to not accidently lose information [Fri Sep 11 21:34:48 2015] why would ~P be an explosion? [Fri Sep 11 21:37:50 2015] or why would P be an explosion? [Fri Sep 11 21:39:33 2015] to not explode out to the full meaning would to have be akin to "accidently losing information"? [Fri Sep 11 21:43:30 2015] i guess the bad example i think of is if loves(z,a) is T.. thus I could reduce loves(z,a) to T .. thats what i mean by information loss [Fri Sep 11 21:44:16 2015] since i lose the interesenting qunatifications of a and z [Fri Sep 11 21:44:20 2015] uhhh [Fri Sep 11 21:47:32 2015] benzrf, i am describing a different problem but please descibe yours [Fri Sep 11 22:50:28 2015] benzrf: Yes, that's about right. Look at the proof that (forall P, ~~P -> P) -> (forall P, P \/ ~P) for inspiration. [Fri Sep 11 23:01:31 2015] kk [Fri Sep 11 23:03:39 2015] jgross: anyway ive been chewing on the proof-by-contradiction in heine-borel, trying to work out if it can be 'inverted' (?) into a proof that directly provides a subcover (albeit probably invoking LEM at some point) [Fri Sep 11 23:04:11 2015] i tried tracing the usage of the negated argument thru the proof [Fri Sep 11 23:04:30 2015] it gave me a headache ;-; [Fri Sep 11 23:05:04 2015] but there seems to be /something/ about the induction involved that's difficult when you do the contrapositive [Fri Sep 11 23:05:12 2015] augh its all vague hunches [Sat Sep 12 00:12:03 2015] vague hunches is what i had .. that proof by refutation was not complete [Sat Sep 12 00:12:30 2015] and maybe even unsound [Sat Sep 12 00:12:57 2015] i think once i found that anyhting inclomplete was also unsound [Sat Sep 12 00:13:13 2015] due to the fact i cant do full TMS [Sat Sep 12 00:14:21 2015] and i may habve axioms in the system that have snuck in that i didnt realize their full potential due to the fact i was not complete [Sat Sep 12 00:15:18 2015] and now can be sititng there with a database full of unsound things [Sun Sep 13 03:47:13 2015] I have a strange problem with Notation: http://paste2.org/75bpJcgw [Sun Sep 13 03:49:09 2015] Maybe I use it in the wrong way, but why 'Check FBAR 42 _ (FBAR 0 _ (FOO 5)).' prints the intended use, while 'Check [[42; 0; 5]]' (the intended use) raises an error? [Sun Sep 13 04:55:27 2015] Hello, can anyone give me some references about the equality(the = Notation) in coq? [Sun Sep 13 04:58:58 2015] I 'm writing a proof in a function-like way. And I don't know how to use a Theorem of equality. In Proof-like way I can just use the rewrite tactic. [Sun Sep 13 05:01:36 2015] OK, so 'Locate "="' prints "x = y" := eq x y. I will dig into that. [Sun Sep 13 05:07:11 2015] If the only constructor of eq is 'eq_refl : eq A x x', then where comes things like 4 = 2 + 2 ? [Sun Sep 13 05:43:42 2015] riaqn: because Coq computes 2+2 using the def. of + and ends on four so for Coq those are the same thing (we write 2+2 ≡ 4) [Sun Sep 13 05:44:20 2015] riaqn: the trick here is that the def. of eq is non-linear (2 occurences of x) and for that to make sense, there needs to be a preexistant notion of equality [Sun Sep 13 07:15:34 2015] asmanur: Thanks, I think I get it. So there's a built-in equality(based on constructor-tree ? ) in coq, and the eq is just an application of this kind of equality. [Sun Sep 13 07:17:19 2015] yes [Sun Sep 13 07:17:31 2015] it's a way to import this builtin equality into a type [Sun Sep 13 19:25:32 2015] riaqn: at a formal system level [Sun Sep 13 19:25:42 2015] riaqn: the formal system that coq is based on is a type system [Sun Sep 13 19:25:59 2015] riaqn: so it has rules like [Sun Sep 13 19:26:33 2015] Γ ⊢ f : A → B Γ ⊢ x : A [Sun Sep 13 19:26:36 2015] ---------------------------------------------------- [Sun Sep 13 19:26:47 2015] \Gamma \vdash f x : B [Sun Sep 13 19:26:57 2015] argh what [Sun Sep 13 19:27:15 2015] riaqn: but anyway, this system has a notion of equality [Sun Sep 13 19:27:39 2015] notably, the provability of any given theorem of this system (that is, a type or equality judgement) is decidable [Sun Sep 13 19:28:09 2015] so coq can automatically prove or disprove any type judgement that you submit to it [Sun Sep 13 19:28:28 2015] including ones that rely on rewriting by equality-in-the-type-system [Sun Sep 13 19:29:22 2015] obviously the fact that the type-system notion of equality is decidable means that it's much weaker than the system-internal notion of equality (e.g., existence of an e such that e : a = b) [Sun Sep 13 19:34:32 2015] since whether 'a = b' is provable within coq is not generally decidable [Sun Sep 13 21:58:18 2015] how to solve this? The term "b_sum n n Hn Hn" has type "beautiful (n + n)" while it is expected to have type "beautiful (2 * n)". [Sun Sep 13 21:58:18 2015] [Sun Sep 13 21:58:44 2015] I already have a theorem saying 2 * n = n + n; just don't know how to use it. [Sun Sep 13 21:59:11 2015] riaqn: rewriting doesn't work? [Sun Sep 13 21:59:35 2015] johnw: I 'm proving a theorem in a functional programming way.. [Sun Sep 13 21:59:51 2015] Definition b_times2': forall n, beautiful n -> beautiful (2*n) := fun n => fun Hn => b_sum n n Hn Hn. [Sun Sep 13 22:00:06 2015] ah [Sun Sep 13 22:00:11 2015] you're writing the proof term yourself [Sun Sep 13 22:00:29 2015] yep. so no tactics. [Sun Sep 13 22:00:30 2015] in Coq.Program.Equality there is a notation called "rew" that let's you rewrite in terms [Sun Sep 13 22:01:20 2015] what I usually do here is: use the tactics, print the proof term, learn how Coq does it :) [Sun Sep 13 22:01:36 2015] it's probably going to involve a dependent type match [Sun Sep 13 22:03:03 2015] johnw: Yeah I already have a tactic version. How can I get the proof term? using PG. [Sun Sep 13 22:07:34 2015] Print . [Sun Sep 13 22:07:34 2015] johnw: huh, just Print b_times2. do the trick. Thanks. [Sun Sep 13 22:21:58 2015] In the end, I understand the proof term generated by tactics. Well, now I know the usefullness of tactics. [Sun Sep 13 22:22:40 2015] hand-written term is kinds of brain-damaging. [Sun Sep 13 22:45:18 2015] riaqn: It's really useful to know *how* to do it, but always necessary to actually do it :) [Sun Sep 13 22:45:25 2015] not always* [Sun Sep 13 22:45:34 2015] plus, sometimes I even write regular programming terms using tactics [Sun Sep 13 22:45:36 2015] they can be convenient [Mon Sep 14 08:02:07 2015] what is the delimiting scope for vectors? [Mon Sep 14 08:02:18 2015] because I normally have list notations [1;2;3;etc.] [Mon Sep 14 08:02:23 2015] but now I want a single vector [Mon Sep 14 08:02:43 2015] [1;2;3]%vec %vector %vector_scope ... does all not work [Mon Sep 14 08:04:39 2015] when using of_list, I get the problem that I always have a "vec.t (length ...)" instead of a "vec.t 3" [Mon Sep 14 09:00:39 2015] Can we prove nat_ind ourselves? [Mon Sep 14 09:01:11 2015] in coq, I mean. [Mon Sep 14 09:01:35 2015] you can use a refiner [Mon Sep 14 09:01:39 2015] if you want [Mon Sep 14 09:02:00 2015] but that doesn't really prove nat_ind. as it uses nat_ind in the background. [Mon Sep 14 09:02:08 2015] (or at least nat_rec9 [Mon Sep 14 09:02:10 2015] ) [Mon Sep 14 09:04:14 2015] riaqn : look at the definition of nat_ind, and then nat_rect [Mon Sep 14 09:04:23 2015] You can write the term yourself, and boom, you've proved nat_ind [Mon Sep 14 09:05:21 2015] still, that term will use nat_rec [Mon Sep 14 09:06:33 2015] Well, no, nat_rect uses a fixpoint [Mon Sep 14 09:06:58 2015] schoppenhauer: do you mean nat_rect? it seems to be defined(in user space) too. [Mon Sep 14 09:08:01 2015] silly me, I was going to rave about the incompleteness of coq. [Mon Sep 14 09:11:28 2015] hmm, I check the nat_rect and it 's quite easy to understand. [Mon Sep 14 14:44:29 2015] so I have written a priority queue which ist verifiedly correct. the only problem I now have is that removing an element from it does not allow me to make recursive calls, because coq does not recognize it as "smaller". [Mon Sep 14 14:44:45 2015] can I somehow add a view for it, so coq recognizes it? [Mon Sep 14 14:44:57 2015] or do I always have to use program fixpoint, and measures? [Mon Sep 14 14:45:25 2015] [if I wanted to extract to haskell, I'd just convert it to a list, because lazy, but I want to extract to ocaml] [Mon Sep 14 14:47:11 2015] schoppenhauer: you'll need program fixpoint and a measure, as far as I know [Mon Sep 14 14:47:21 2015] because in a way that is the "view" [Mon Sep 14 14:47:24 2015] ok :( [Mon Sep 14 14:48:25 2015] the alternative is to use a nested fixpoint that recurses on Acc or something [Mon Sep 14 14:48:31 2015] as discussed in http://adam.chlipala.net/cpdt/html/GeneralRec.html [Mon Sep 14 14:48:44 2015] (by nested I just mean "let fix ...") [Mon Sep 14 14:48:54 2015] hm. probably program fixpoint is easier. [Mon Sep 14 14:49:01 2015] yeah, it's pretty easy to use [Mon Sep 14 14:49:05 2015] I've used it a lot [Mon Sep 14 14:49:15 2015] but the terms are growsome [Mon Sep 14 14:49:20 2015] haha [Mon Sep 14 14:49:54 2015] you could prove independently that certain functions always reduce the measure [Mon Sep 14 14:50:03 2015] and then use those lemmas in your proof of well-foundedness [Mon Sep 14 14:50:22 2015] alternatively, turn your "let fix..." function into proof-carrying code [Mon Sep 14 14:50:35 2015] so that the base case percolates up evidence about the measure [Mon Sep 14 15:33:14 2015] What exactly does JMeq do, it appears to me that it can postulate equality between any two sets, but what does it actually accomplish? [Mon Sep 14 15:41:18 2015] korta: check out the difference between refl and JMeq_refl [Mon Sep 14 15:41:49 2015] check out http://adam.chlipala.net/cpdt/html/Equality.html, under the section "Heterogeneous Equality" [Mon Sep 14 17:34:05 2015] does anyone have a BibTeX database of commonly cited papers about Coq? For example, I'm looking for a citation for the Coq theorem prover itself [Mon Sep 14 18:05:21 2015] nice, it's in the FAQ [Tue Sep 15 01:24:11 2015] hi. I'm working through SF exercises and I'm stuck on one.. Any hints? http://pastebin.com/fJEXn5kz [Tue Sep 15 01:24:25 2015] seems like it should be easy... [Tue Sep 15 01:27:40 2015] I havent run your code [Tue Sep 15 01:28:03 2015] But from what I see, you can do a little simpl and than rewrite on Induction Hypothesis is possible. [Tue Sep 15 01:29:02 2015] if I simpl it, I lose the "split" and "combine" in the goal [Tue Sep 15 01:29:09 2015] so I dont see how I can simpl and then use the IH [Tue Sep 15 01:32:43 2015] simpl;erewrite IHl1';inversion Hlen;trivial. [Tue Sep 15 01:35:03 2015] what is erewrite? [Tue Sep 15 01:36:26 2015] basically rewrite, but when rewrite find some unspecify variable (those in your forall), instead of failing it generate more hole for you to fill [Tue Sep 15 01:36:51 2015] you can break ; into . to step through and see what is done [Tue Sep 15 01:38:37 2015] BTW similarly there is a 'e' version of apply, auto, destruct, and a few more... [Tue Sep 15 01:38:55 2015] we havent been introduced to erewrite at this point. :( [Tue Sep 15 01:39:49 2015] Yes I know, but you can do the same by rewrite (IHl1' somevar somevar) [Tue Sep 15 01:41:18 2015] Also I recommend you to not only read the book; also try using coqmanual in the same time, I think it will help :) [Tue Sep 15 01:43:30 2015] can it be done with "apply IHl1' with ..." ? [Tue Sep 15 01:44:33 2015] I dunno, I already closed it. But I think f_equal will be helpful if you want to do so. go have a try :) [Tue Sep 15 01:45:03 2015] i have tried to use f_equal but it couldnt unify [Tue Sep 15 01:45:47 2015] after simpl or before simpl? [Tue Sep 15 01:47:18 2015] after simpl. [Tue Sep 15 01:50:35 2015] after "inversion H. rewrite -> H2. simpl" I have goal: " match split l' with | (xs, ys) => (x1 :: xs, x2 :: ys) end = (x1 :: l1', x2 :: l2')" [Tue Sep 15 01:51:11 2015] Try using assert, the direct route probably isnt gonna work [Tue Sep 15 01:55:16 2015] i wish there were answers for these online.. i would love to see how the author did it with the toosl he's given us [Tue Sep 15 02:00:42 2015] ok, i got it with "assert (split l' = (l1', l2'))." [Tue Sep 15 02:00:47 2015] and lots of other steps :) [Tue Sep 15 02:00:50 2015] ty for the help! [Tue Sep 15 02:01:16 2015] I cant help but think this proof is way longer than what the author had in mind [Tue Sep 15 02:01:30 2015] feels like I'm missing some key insight or proof step [Tue Sep 15 02:03:36 2015] you're only lacking practice, happen on me when I first learn coq [Tue Sep 15 02:04:15 2015] do more exercise and all will be fine :) [Tue Sep 15 02:58:10 2015] thank's for the encouragement. [Tue Sep 15 02:58:16 2015] thats one reason i'm doing all the exercises in this. [Tue Sep 15 02:58:47 2015] and hopefully afterwards I'll work through some of the techniques in CPDT (which does a lot more automation) [Tue Sep 15 12:13:39 2015] hi, I am trying to compile coq from source, but first I need ocaml and camlp5. INSTALL says ocaml >= 3.11.2 and camlp5 <= 4.08 or 5.* transitional but this version won't work with the latest ocaml (and it's old too), can I use camlp5 6.* anyway? and is ocaml 4.* OK? [Tue Sep 15 12:13:59 2015] I don't understand what transitional means either? [Tue Sep 15 12:56:04 2015] sorry to have bothered you, I finally found out what this transitional meant, and I could install coq correctly :) [Tue Sep 15 22:01:07 2015] why does inversion on "H: P <-> Q" split it into the two components? [Tue Sep 15 22:05:49 2015] SF says that "rewrite can be used with iff statements, not just equalities" but when I try to use "PISQ : P <-> Q" on goal "P <-> R" with "rewrite -> PISQ" it fails. [Tue Sep 15 22:05:53 2015] is that supposed to work? [Tue Sep 15 22:12:45 2015] newsham: because the notation P <-> Q is defined as (and P -> Q Q -> P). [Tue Sep 15 22:13:23 2015] newsham: Inductive and (P Q : Prop) : Prop := conj : P -> Q -> P /\ Q [Tue Sep 15 22:15:08 2015] so it's split to 'P->Q' and 'Q->P'. (note that the P and Q in these two lines are different) [Tue Sep 15 22:16:04 2015] why does "inversion" on "and (P->Q) (Q->P)" split into the two components? [Tue Sep 15 22:17:11 2015] does "inversion" on any constructor of more than one element split it into all of the elements? [Tue Sep 15 22:17:27 2015] since we have the evidence of 'and (P->Q) (Q->P)', and the only possible ways to get this evidence is by (conj P->Q Q->P). so we must have the evidence of (P->Q) and (Q->P). [Tue Sep 15 22:19:07 2015] i guess it "makes sense". i just didnt realize inversion did that [Tue Sep 15 22:20:57 2015] newsham: yes. [Tue Sep 15 22:25:07 2015] any thoughts on the "rewrite" question? [Tue Sep 15 22:26:06 2015] newsham: though it's better to say 'inversion on evidence'. since there maybe more than one constructor for a Prop. [Tue Sep 15 22:53:37 2015] newsham: you cant actually rewrite on a <-> [Tue Sep 15 22:53:43 2015] not without extra axioms [Tue Sep 15 22:53:52 2015] i think Setoid gives you those [Tue Sep 15 23:34:54 2015] hrmm.. so why did SF say that rewrite works with iff? :( [Tue Sep 15 23:35:07 2015] not that its important. [Tue Sep 15 23:35:08 2015] idk [Tue Sep 15 23:35:20 2015] is it in the context of setoids? [Tue Sep 15 23:35:32 2015] no, its an aside after introducing iff. [Tue Sep 15 23:35:39 2015] huh [Tue Sep 15 23:35:42 2015] odd [Tue Sep 15 23:36:14 2015] "Some of Coq's tactics treat iff statements specially, thus avoiding the need for some low-level manipulation when reasoning with them. In particular, rewrite can be used with iff statements, not just equalities. [Tue Sep 15 23:36:21 2015] http://www.cis.upenn.edu/~bcpierce/sf/current/Logic.html#lab202 [Tue Sep 15 23:36:32 2015] :\ [Wed Sep 16 22:14:36 2015] This exercise is baffling me and I wondering if they intended us to prove it classically or intuitionistically: Theorem excluded_middle_irrefutable: ∀(P:Prop), ¬ ¬ (P ∨ ¬ P). [Wed Sep 16 22:14:41 2015] is that valid in intuitionistic logic? [Wed Sep 16 22:14:47 2015] it's valid! [Wed Sep 16 22:14:58 2015] pretty frickin weird [Wed Sep 16 22:15:12 2015] i dont believe i got that one myself [Wed Sep 16 22:15:17 2015] in fact i think jgross mightve shown me the answer [Wed Sep 16 22:17:17 2015] i've worked on it for a while and keep getting stuck.. [Wed Sep 16 22:18:01 2015] well [Wed Sep 16 22:18:03 2015] consider this: [Wed Sep 16 22:18:18 2015] given the context P : Prop (and ONLY that) [Wed Sep 16 22:18:26 2015] clearly you cannot prove (P ∨ ¬ P) [Wed Sep 16 22:18:47 2015] furthermore, any proof of ¬ ¬ (P ∨ ¬ P) must contain a term of type False [Wed Sep 16 22:19:03 2015] the only way to get a term of type False in that context is to pass a (P ∨ ¬ P) to the 'callback' [Wed Sep 16 22:19:21 2015] therefore, (P ∨ ¬ P) must be provable in some context within the term [Wed Sep 16 22:19:33 2015] ?djinn ((Either a b) -> Void) -> Void [Wed Sep 16 22:19:33 2015] if it's provable in that context but not in the context P : Prop [Wed Sep 16 22:19:37 2015] cheater!!! [Wed Sep 16 22:19:39 2015] djinn wasnt able to do it [Wed Sep 16 22:19:53 2015] oops, i messed it up :) [Wed Sep 16 22:20:11 2015] did you follow what i was saying [Wed Sep 16 22:20:15 2015] i'm reading now [Wed Sep 16 22:20:44 2015] i dont quite get what you're saying [Wed Sep 16 22:20:55 2015] sorry let me back up [Wed Sep 16 22:21:00 2015] i do know this is related to callcc and embedding classical logic in intuitionistic [Wed Sep 16 22:21:03 2015] but i'm still confused :) [Wed Sep 16 22:21:10 2015] ok, the first two lines ok? [Wed Sep 16 22:22:28 2015] i got that i cannot use the excluded middle [Wed Sep 16 22:22:38 2015] 10:18:18 benzrf │ given the context P : Prop (and ONLY that) [Wed Sep 16 22:22:39 2015] 10:18:26 benzrf │ clearly you cannot prove (P ∨ ¬ P) [Wed Sep 16 22:22:40 2015] and I got that the NOTs mean an implication of false [Wed Sep 16 22:24:33 2015] newsham: does that make sense? [Wed Sep 16 22:24:37 2015] yes [Wed Sep 16 22:24:45 2015] kk [Wed Sep 16 22:24:48 2015] no LEM [Wed Sep 16 22:24:50 2015] yeah [Wed Sep 16 22:24:54 2015] so, continuing [Wed Sep 16 22:25:10 2015] a proof of ~~(P \/ ~P) is a lambda term [Wed Sep 16 22:25:23 2015] I need (P \/ (P -> False) -> False) -> False from "P : Prop" alone. [Wed Sep 16 22:25:27 2015] yes [Wed Sep 16 22:25:33 2015] hold on one second [Wed Sep 16 22:25:47 2015] ok, consider the lambda term you need to create [Wed Sep 16 22:25:58 2015] since its return type is False, its body must have type False, right? [Wed Sep 16 22:26:00 2015] you're going the curry-howard route.. but... cant this be done with basic tactics? [Wed Sep 16 22:26:08 2015] * shrugs [Wed Sep 16 22:27:39 2015] ok, just verified in coq [Wed Sep 16 22:27:40 2015] it can indeed [Wed Sep 16 22:30:18 2015] i cant see how without perhaps some very clever assertion. [Wed Sep 16 22:30:29 2015] nah [Wed Sep 16 22:30:48 2015] super basic tactics [Wed Sep 16 22:30:55 2015] I've tried using Theorem not_both_true_and_false : ∀P : Prop, ¬ (P ∧ ¬P). [Wed Sep 16 22:30:57 2015] somehow [Wed Sep 16 22:31:00 2015] but that didnt seem to help [Wed Sep 16 22:31:16 2015] just use Goal forall P, ~~(P \/ ~P). [Wed Sep 16 22:31:24 2015] at each step there will be only a few choices [Wed Sep 16 22:31:36 2015] usually you will be able to absolutely rule out all but one [Wed Sep 16 22:31:38 2015] heh. i've played with that for an hour already :) [Wed Sep 16 22:31:43 2015] well [Wed Sep 16 22:31:49 2015] try again [Wed Sep 16 22:31:51 2015] and tell me how it goes [Wed Sep 16 22:31:51 2015] i can pretty easily get to the point where its true if LEM :) [Wed Sep 16 22:31:54 2015] i can give hints :) [Wed Sep 16 22:33:39 2015] newsham: basically [Wed Sep 16 22:33:43 2015] woot, got it [Wed Sep 16 22:33:47 2015] oh [Wed Sep 16 22:33:49 2015] lmao [Wed Sep 16 22:34:11 2015] if I had just tried "left" earlier.. :) [Wed Sep 16 22:34:16 2015] err.. I mean "right" [Wed Sep 16 22:34:24 2015] thats what i meant by 10:31:36 benzrf │ usually you will be able to absolutely rule out all but one [Wed Sep 16 22:34:26 2015] :) [Wed Sep 16 22:34:56 2015] I kept freaking out when I got to the point where LEM was the goal [Wed Sep 16 22:35:01 2015] haha [Wed Sep 16 22:35:06 2015] what i was explaining earlier is [Wed Sep 16 22:35:06 2015] but its not naked LEM, its LEM iwth assumptions [Wed Sep 16 22:35:09 2015] yeah [Wed Sep 16 22:35:20 2015] additionally, it's instantiated LEM [Wed Sep 16 22:35:29 2015] ~~LEM is not a theorem afaik [Wed Sep 16 22:36:21 2015] djinn can do ~LEM but not ~~LEM [Wed Sep 16 22:36:27 2015] so I assume you're right [Wed Sep 16 22:37:27 2015] I kind of wish this book had been more explicit with examples in doing forward reasoning with or_introl and or_intror. [Wed Sep 16 22:37:35 2015] it took me a long time to realize I can do that [Wed Sep 16 22:38:01 2015] apply or_introl with (Q := ...) in H. [Wed Sep 16 22:38:52 2015] >djinn can do ~LEM [Wed Sep 16 22:38:54 2015] wait what [Wed Sep 16 22:38:57 2015] that shouldnt be possible [Wed Sep 16 22:39:01 2015] LEM is compatible with coq [Wed Sep 16 22:40:15 2015] here's my proof btw: [Wed Sep 16 22:40:17 2015] intros P callback. apply callback. right. intro. apply callback. left. assumption. [Wed Sep 16 22:43:11 2015] unfold not. intros P H. apply H. right. intros HP. apply or_introl with (Q := (P -> False)) in HP. apply H in HP. inversion HP. [Wed Sep 16 22:56:24 2015] how can I do forward reasoning from "0 = 0 -> P" ? is there a simple reflexivity rule I can apply? [Wed Sep 16 22:57:24 2015] ? [Wed Sep 16 22:57:38 2015] newsham: oh, you mean thats a hypothesis? [Wed Sep 16 22:57:47 2015] in my environment I have "H : 0 = 0 -> P" [Wed Sep 16 22:57:50 2015] uh [Wed Sep 16 22:57:54 2015] try 'reflexivity in H'? [Wed Sep 16 22:57:57 2015] no idea if that would work [Wed Sep 16 22:58:15 2015] nope :( [Wed Sep 16 22:59:25 2015] i can do this iwthout that.. but being able to do this would cover several cases [Wed Sep 16 23:00:21 2015] * shrugs [Wed Sep 16 23:00:28 2015] im pretty un-knowledgable about coq tbh [Wed Sep 16 23:01:46 2015] newsham: specialize (H refl) should do it [Wed Sep 16 23:02:13 2015] ty. [Wed Sep 16 23:02:48 2015] is there an easy way to search for theorems by type? ie "S n = S m -> n = m" ? [Wed Sep 16 23:02:52 2015] what does specialize do here johnw [Wed Sep 16 23:02:53 2015] newsham: About [Wed Sep 16 23:02:55 2015] er, Search [Wed Sep 16 23:02:58 2015] SearchAbout (S _ = S _). [Wed Sep 16 23:03:05 2015] th-that too [Wed Sep 16 23:03:07 2015] * clams up [Wed Sep 16 23:03:18 2015] specialize un-generalizes a hypothesis by applying arguments to it [Wed Sep 16 23:04:07 2015] thank you [Wed Sep 16 23:24:14 2015] sweet, chapter done.. enoughof that for now :) [Wed Sep 16 23:24:17 2015] thanks for the help! [Wed Sep 16 23:34:04 2015] any time :) [Thu Sep 17 12:15:26 2015] johnw: does specialize examine the syntactic form given to it and require that it be application with the deepest function being a variable in scope as a hypothesis? [Thu Sep 17 13:42:49 2015] hello, I'm trying to refine something like (Fix _ _ (match x with | true -> foo | false -> bar)), but the generated goals (which are specified by blanks _ in foo and bar) do not take the fact that 'x = true' (in foo) and 'x = false' (in bar) as an hypothesis, but I do need them [Thu Sep 17 13:43:09 2015] any way to add the x value to the context? [Thu Sep 17 13:43:18 2015] (note that x is an element of a Record, maybe it causes problems) [Thu Sep 17 13:50:43 2015] artart78: you need to introduce that equality explicitly using a return annotation. [Thu Sep 17 13:51:08 2015] this is sometimes called "the convoy pattern", see for example http://adam.chlipala.net/cpdt/html/MoreDep.html [Thu Sep 17 13:51:24 2015] if you post a self-contained code snippet, I can show you how it would work. [Thu Sep 17 13:54:22 2015] aah thanks, let me try by myself first [Thu Sep 17 14:01:43 2015] Anomaly: add_args : todo. Please report. [Thu Sep 17 14:01:45 2015] wtf [Thu Sep 17 14:16:27 2015] jrw: ok, I gave up, the record seems to make stuff more complicated, here is a self-contained snippet: http://pastebin.com/RNUvdvJ1 [Thu Sep 17 14:16:43 2015] the problem is for the first 'admit': I'd like to know that 'mode st = true' [Thu Sep 17 14:16:52 2015] some help would be very welcome [Thu Sep 17 14:17:13 2015] sure, just let me have a look [Thu Sep 17 14:20:01 2015] artart78: http://lpaste.net/141195 [Thu Sep 17 14:36:03 2015] hm. so I have two definitions of a function. one uses Program Fixpoint, and the functional induction is bloated with existT-stuff... the other one does not, but I cannot define functional induction for it. [Thu Sep 17 14:40:17 2015] benzrf: "deepest function"? [Thu Sep 17 14:46:05 2015] jrw: aaaah very nice, thank you [Thu Sep 17 16:47:15 2015] johnw: if you have 'f x y' then 'f x' is a function in the expression [Thu Sep 17 16:47:24 2015] f is the 'deepest' in that it is in the deepest node of the tree [Thu Sep 17 16:47:41 2015] benzrf: ok, can you re-ask your question again in different terms? [Thu Sep 17 16:47:44 2015] I really didn't follow it at all [Thu Sep 17 16:47:47 2015] er ok [Thu Sep 17 16:47:57 2015] what terminology should i use to refer to f in an expression like 'f x y' [Thu Sep 17 16:48:26 2015] I don't know, but I know what you mean now [Thu Sep 17 16:48:31 2015] I just don't understand the question overall [Thu Sep 17 16:48:35 2015] what is it that you want to do? [Thu Sep 17 16:48:55 2015] er [Thu Sep 17 16:49:34 2015] does the argument to the specialize tactic need to be the application of some function to several arguments, and furthermore that the function in question be syntactically a variable that is in scope as a hypothesis. [Thu Sep 17 16:49:51 2015] ah [Thu Sep 17 16:49:55 2015] I believe the answer is "yes" [Thu Sep 17 16:49:57 2015] kk [Thu Sep 17 16:50:03 2015] you are refining a hypothesis in the context by applying argument [Thu Sep 17 16:50:05 2015] s [Thu Sep 17 16:50:16 2015] otherwise im not sure what kind of black magic would be necessary to make it work :> [Thu Sep 17 16:50:32 2015] let's step outside of tactics for a moment [Thu Sep 17 16:50:39 2015] we have "f" want "x" and "y" [Thu Sep 17 16:50:42 2015] no i understand what it does [Thu Sep 17 16:50:48 2015] here's what specialize (f x) does in non-tactics: [Thu Sep 17 16:50:49 2015] just wondering how it knows which thing to replace, etc [Thu Sep 17 16:50:52 2015] let f' := f x in [Thu Sep 17 16:51:02 2015] (or let f, and shadowing) [Fri Sep 18 00:48:54 2015] Hello, what 're some top proceedings in this field(type theory/PL)? [Fri Sep 18 01:57:13 2015] riaqn: check out POPL and ICFP papers, among other related conferences [Fri Sep 18 04:14:07 2015] johnw: thanks! [Fri Sep 18 06:15:18 2015] Hi everyone! I’m trying to prove http://lpaste.net/141235 with just basic tactics, but I keep boxing myself into a corner. firstorder does it in one shot, so I know I’ve expressed it correctly, but I’m struggling to see how the existential quantifier helps express the contradiction. Can anyone offer a pointer? [Fri Sep 18 06:31:57 2015] psnively : the reasoning with this one is the following. First of all, either everyone is a Knight, or nobody is. If nobody is, we're already done. If everyone is a Knight, then let's take some native. We know, since he is a Knight, that he doesn't smoke and that someone else smokes [Fri Sep 18 06:32:42 2015] Cypi: Right. [Fri Sep 18 06:32:44 2015] Now consider that someone else. He's also a Knight, and he smokes. However, he's a Knight, so someone else smokes, and he doesn't smoke: this is a contradiction. [Fri Sep 18 06:34:14 2015] Cypi: yep. I’ve gotten the existential native out of SomeoneElseSmokes, but am having trouble 1) showing he’s a Knight, 2) showing the contradiction. [Fri Sep 18 06:35:12 2015] The first thing you should do in your proof, is destructing SameType, in order to have either everyone is a Knight, or nobody is a Knight [Fri Sep 18 06:35:18 2015] if everyone is a Knight, that solves 1) [Fri Sep 18 06:44:11 2015] Cypi: OK, I’ve managed to get both Knight n and Knight x in a context where all natives are Knights. [Fri Sep 18 06:45:00 2015] I’m guessing I need to apply SomeoneElseSmokes, somehow substituting Knight x for Knight n. [Fri Sep 18 06:45:21 2015] Yup, you'll have to apply twice, for different natives [Fri Sep 18 06:45:33 2015] Then I can break it down to Smokes x -> False, and contradiction. [Fri Sep 18 06:46:21 2015] It tells me it wants a Knight n, not a Knight x. Dependent types FTW! [Fri Sep 18 06:50:42 2015] http://lpaste.net/141235 updated. [Fri Sep 18 06:53:10 2015] From there, you can do [apply SomeoneElseSmokes in KnightX] [Fri Sep 18 06:57:38 2015] * smacks self. [Fri Sep 18 06:57:43 2015] Thanks! [Fri Sep 18 07:02:41 2015] Cypi: I’m blind and you’re a lifesaver. Thank you so much! [Fri Sep 18 07:03:30 2015] No probleù [Fri Sep 18 07:03:34 2015] m* [Fri Sep 18 16:41:53 2015] does anyone know how to use FMap's? I'd like to define something mapping all the integers i = 0..n-1 to some f(i) so that I don't have to calculate them again (I use this for efficiency when extracting) [Sun Sep 20 21:57:26 2015] is there an easy way to specify a specific instance of a rewrite when there are multiple rewrites possible with the "rewrite _" tactic? [Sun Sep 20 21:57:46 2015] instead of forcing it with assert or replace [Sun Sep 20 23:12:30 2015] newsham: i wish] [Sun Sep 20 23:12:35 2015] newsham: well there might be, idk [Sun Sep 20 23:15:14 2015] newsham: https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic113 found this link, but don't know how. [Mon Sep 21 01:08:24 2015] i always seem to get bogged down trying to do assoc and comm over plus in places that seem trivial on paper and pencil [Mon Sep 21 01:08:44 2015] perhaps the better answer would be for me to use mroe tactic automation in the future [Mon Sep 21 01:10:35 2015] any good example of using "rewrite ... at ..." ? [Mon Sep 21 03:31:16 2015] newsham: http://www.lix.polytechnique.fr/coq/pylons/contribs/view/AACTactics/trunk [Mon Sep 21 08:31:15 2015] hello is there any uncountable set with decidable equality... [Mon Sep 21 08:57:44 2015] Question: it seems that a term that pattern matches on opaque proofs doesn't reduce fully. However, if the proof was an equality one, does it still has to be this way? [Mon Sep 21 08:58:21 2015] I'm kinda bugged by this because if I use opaque proofs from the library in my functions, I get this problem [Mon Sep 21 08:59:47 2015] dramforever pasted “My full program, in case you somehow want to look at it” at http://lpaste.net/6588606202886750208 [Mon Sep 21 09:06:13 2015] dramforever: I bet something would go wrong if your equality proof involves a false axiom [Mon Sep 21 09:06:31 2015] sgnb: hmm....that's more interesting, I haven't thought of it [Mon Sep 21 09:07:03 2015] You cannot prove, a priori, that an equality proof is equal to the reflexivity [Mon Sep 21 09:07:17 2015] so in any case, it's normal that you cannot reduce that kind of pattern-matching [Mon Sep 21 09:07:45 2015] (but you can with additional axioms, it will just imply some rewriting, unless I'm mistaken) [Mon Sep 21 09:07:53 2015] Cypi: oh okay, I wasn't really expecting that [Mon Sep 21 09:07:58 2015] sorry [Mon Sep 21 09:08:15 2015] screw it ignore these three messages [Mon Sep 21 09:09:34 2015] Cypi: okay, so if I work in a language like Agda where the K rule thing was built in, I'm able to do that? [Mon Sep 21 09:09:45 2015] I mean, even if the number wasn't known beforehand? [Mon Sep 21 09:10:04 2015] I don't know if Agda can indeed reduce that judgmentally. Maybe :D [Mon Sep 21 09:10:14 2015] but yes, you typically need K [Mon Sep 21 09:11:47 2015] sgnb: hmm wait, so if you make a false axiom like 1 = 0, you'll be able to screw up the type checker if that reduction were allowed? [Mon Sep 21 09:12:15 2015] if that weren't allowed it would only screw up the logic [Mon Sep 21 09:13:42 2015] dramforever: yes [Mon Sep 21 09:13:54 2015] ok, good to know [Mon Sep 21 09:15:15 2015] now I'll just make do with this, and if I ever need to somehow get rid of it I'll probably read more about those axiom K/UIP/proof irrelevance/... things [Mon Sep 21 09:15:25 2015] I was thinking more a a false equality between types [Mon Sep 21 09:15:41 2015] sgnb, Cypi: thanks a lot for clearing things up for now [Mon Sep 21 09:16:27 2015] sgnb: yeah it would probably allow something like unsafeCoerce in Haskell (if you know what that means) [Mon Sep 21 09:16:54 2015] exactly [Mon Sep 21 09:17:03 2015] thanks [Mon Sep 21 09:19:08 2015] is there any uncountable set with decidable equality tho [Mon Sep 21 09:36:51 2015] benzrf: I have the feeling that one can construct an enumeration from the decision procedure, but I don't have a formal proof [Mon Sep 21 09:50:31 2015] sgnb: i'd buy a well-ordering, but a full-on countability proof seems unlikely [Mon Sep 21 09:50:31 2015] to me at least [Mon Sep 21 10:10:26 2015] chat, how do you use the quote tactic to reify a subterm? as in, if you have an inductive type for a simple AST with nats as leaves, and your goal is an equality of two nats, how do you use the quote tactic to reify just the nats? [Mon Sep 21 10:11:12 2015] sgnb: yeah [Mon Sep 21 10:11:26 2015] sgnb: if you have LEM in coq, R doesnt become countable [Mon Sep 21 10:11:36 2015] sgnb: but LEM definitely gives you "decidable equality" for reals [Mon Sep 21 10:11:59 2015] For example, say you have "Inductive expr := | plus_exp : expr -> expr -> expr | const_exp : nat -> expr | var_exp : index -> exp." where index comes from the Quote module [Mon Sep 21 10:12:21 2015] hcp: id help you if i had any knowledge about this whatsoever :} [Mon Sep 21 10:12:46 2015] benzrf: yeah, documentation on Quote is kinda limited [Mon Sep 21 10:31:48 2015] benzrf: I was thinking about an actual (axiom-free) decision procedure, not LEM [Mon Sep 21 10:34:53 2015] ah [Mon Sep 21 10:34:57 2015] so you mean in a metatheoretical sense [Mon Sep 21 10:49:03 2015] hcp: something like https://paste.debian.net/312740/ ? [Mon Sep 21 10:53:07 2015] is there a classically countable set that has undecidable equality in coq [Mon Sep 21 10:53:39 2015] oh wait... [Mon Sep 21 10:53:42 2015] truth values duh :[ [Mon Sep 21 10:54:51 2015] benzrf: what about two functions from bool -> bool? [Mon Sep 21 10:55:02 2015] oh crap [Mon Sep 21 10:55:09 2015] i guess i was assuming extensionality [Mon Sep 21 10:55:10 2015] :v [Mon Sep 21 10:56:47 2015] How do you prove that [bool -> bool] is classically countable, exactly? (without assuming extensionality) [Mon Sep 21 10:56:52 2015] (sorry if that's obvious) [Mon Sep 21 10:57:14 2015] I guess I can never decide if they are the identical function [Mon Sep 21 10:57:39 2015] but without assuming extensionality, I can enumerate all inputs and compare all outputs [Mon Sep 21 10:57:48 2015] so, manual extensionality for those two functions [Mon Sep 21 10:58:17 2015] Oh, you really a meant a set that consists only of those two functions ? [Mon Sep 21 10:58:21 2015] -a [Mon Sep 21 10:58:39 2015] I see what you mean, Cypi; I guess it's not a countable set [Mon Sep 21 10:58:46 2015] I was thinking of counting the possible behaviors [Mon Sep 21 11:03:37 2015] sgnb: hey, i think that works! thanks for the help with the quote thing [Mon Sep 21 13:25:55 2015] sgnb: thank you [Mon Sep 21 14:01:15 2015] hi [Mon Sep 21 14:01:39 2015] is there any way to reduce typing when proving? [Mon Sep 21 14:01:46 2015] like autocomplete for tactics or something [Mon Sep 21 14:13:20 2015] also is there any way to get a dependency graph of theorems? [Mon Sep 21 14:15:46 2015] vanila: i'd love that too [Mon Sep 21 23:20:46 2015] Definition a {A} (P : A -> Prop) : Type := {x : A | P x}. [Mon Sep 21 23:20:55 2015] circle : a manifold [Tue Sep 22 00:52:31 2015] haha [Tue Sep 22 00:54:16 2015] that's pretty cute [Tue Sep 22 06:17:10 2015] how can I use functional induction on a fixpoint that I defined using refine (...) [Tue Sep 22 06:17:12 2015] ? [Tue Sep 22 11:01:00 2015] "Recursive call to e has not enough arguments" how can this even be an error message? [Tue Sep 22 11:01:04 2015] I mean ... seriously? [Tue Sep 22 11:02:41 2015] schoppenhauer: recursive functions must have a decreasing argument... and all recursive calls must have this argument [Tue Sep 22 11:02:49 2015] sgnb: they do. [Tue Sep 22 11:03:27 2015] but even if not ... the proof mode should have found out ... [Tue Sep 22 11:03:55 2015] did you use the "fix" tactic? [Tue Sep 22 11:04:06 2015] ? [Tue Sep 22 11:04:11 2015] no, I used refine. [Tue Sep 22 11:04:37 2015] refine with a fixpoint? [Tue Sep 22 11:04:42 2015] yes [Tue Sep 22 11:04:47 2015] it doesn't do much checks [Tue Sep 22 11:05:30 2015] I would say it's a feature, otherwise you wouldn't be able to do much [Tue Sep 22 11:19:34 2015] http://lpaste.net/6626105107081592832 [Tue Sep 22 11:19:40 2015] if anyone likes to look at it ... [Tue Sep 22 11:19:51 2015] the final definition blows. [Tue Sep 22 11:20:26 2015] but I only call the fixpoint e with its first argument, which is the one in {struct}. [Tue Sep 22 11:22:09 2015] in fact, there is only one recursive call. [Tue Sep 22 11:34:28 2015] the recursive call to f did not have its decreasing argument, but it was inferred (and I made it explicit now ...) [Wed Sep 23 02:37:55 2015] blah, stuck again.. tryin to prove "l = rev l -> palindrome l" [Wed Sep 23 02:38:06 2015] but having a hard time figuring out how induction could work. [Wed Sep 23 02:39:03 2015] destruct l and destruct rev l' lets me handle the base cases fine, and get to a point where i need to prove "palindrome l''" for the inner list [Wed Sep 23 03:17:59 2015] newsham: prove "forall n, length l <= n -> l = rev l -> palindrome l" instead (by induction on n) [Wed Sep 23 03:19:48 2015] you have to rephrase somehow your goal since the inner list is not structurally a subterm of the outer list [Wed Sep 23 03:40:35 2015] ty [Wed Sep 23 08:01:47 2015] host imapmail.intel.com -> 3(NXDOMAIN) [Wed Sep 23 08:02:12 2015] oops. wrong window. [Wed Sep 23 13:40:14 2015] Cannot find Z._ in the environment? [Wed Sep 23 13:40:20 2015] How to add Z to the loadpath? [Wed Sep 23 15:44:12 2015] I have "Hlen: S (length l1) <= n'" and I do "inversion Hlen. apply le_n" and for some reason I'm left with "H3: S (length l') <= n'". [Wed Sep 23 15:44:16 2015] wtf? [Wed Sep 23 15:44:41 2015] oops, "Hlen: S (length l1) <= S n'". [Wed Sep 23 15:45:55 2015] ahh, I wanted le_S_n [Wed Sep 23 16:23:03 2015] if I have "forall n, length l <= n -> P l." how can I get a proof of "P l" ? [Wed Sep 23 16:23:17 2015] I used the forall n thing to get strong induction on the list. [Wed Sep 23 16:24:13 2015] newsham : instantiate that proof with [n := length l] [Wed Sep 23 16:24:22 2015] providing a proof of [length l <= length l] should be trivial then [Wed Sep 23 16:25:46 2015] the part I dont understand is how to whip up an [n := length l] out of thin air [Wed Sep 23 16:25:50 2015] syntax wise [Wed Sep 23 16:27:38 2015] i think I understand how I would do it by defining it as a function, but I dont see how I would do it using tactics [Wed Sep 23 16:28:02 2015] Say you have [H : forall n, length l <= n -> P l] in your hypotheses [Wed Sep 23 16:28:53 2015] then you can use the tactics [pose proof (H (length l))] to get a proof of [length l <= length l -> P l], for instance [Wed Sep 23 16:33:03 2015] ahh.. havent learned "pose proof" yet. [Wed Sep 23 16:33:34 2015] or you can use specialize, if you don't need to keep H around [Wed Sep 23 16:33:36 2015] If your goal is [P l], you can also do something like [apply (H (length l))] [Wed Sep 23 16:33:50 2015] Or [apply H with (n := length)] [Wed Sep 23 16:34:46 2015] I tried "apply H with (n:=length l)" and it gave me "no such bound variable n" [Wed Sep 23 16:35:28 2015] apply (H (n:=length l)) [Wed Sep 23 16:35:30 2015] http://pastebin.com/iQnpcG6U [Wed Sep 23 16:35:54 2015] actually, that should get the same error [Wed Sep 23 16:36:18 2015] diff err "wrong argument name n" [Wed Sep 23 16:36:39 2015] well, there is no "forall n," in front of your hypothesis :p [Wed Sep 23 16:36:50 2015] what about just apply H with (length l)? [Wed Sep 23 16:36:54 2015] You should move that "forall n" inside the "length l <= n -> P l" [Wed Sep 23 16:38:14 2015] currently, your theorem is actually wrong [Wed Sep 23 16:38:51 2015] fixed. ty :) [Wed Sep 23 16:39:40 2015] cool "apply H with (n:=length l). apply le_n" worked. [Wed Sep 23 16:39:59 2015] Yay :) [Wed Sep 23 16:42:31 2015] now the problem is that what I proved originaly was "Theorem rev_pal_n : forall n X (l : list X), length l <= n -> l = rev l -> pal l." [Wed Sep 23 16:43:05 2015] by induction on n. [Wed Sep 23 16:44:30 2015] Ah yes, your "induction" principle is probably not very useful, stated as is. I would write it something like: "forall X (P : list X -> Prop), (forall n l, length l <= n -> P l) -> forall l, P l" [Wed Sep 23 16:45:51 2015] oh, the rev_pal thing [Wed Sep 23 16:45:54 2015] man that was a tough one [Wed Sep 23 16:46:07 2015] There are always a lot of questions on that one, on #coq :p [Wed Sep 23 16:46:09 2015] indeed. [Wed Sep 23 16:46:25 2015] my proof used several theorems proved later in that same exercise.. which seems.. a bit weird. [Wed Sep 23 16:46:29 2015] btw, you don't need to move forall n into the argument [Wed Sep 23 16:46:39 2015] it will work with it on the outside [Wed Sep 23 16:50:40 2015] ok, abstracing out the strong induction stuff is becoming more work than its worth.. but proving rev_pal from rev_pal_n is pretty easy now that I know the "with (n:=length l)" trick [Wed Sep 23 16:51:13 2015] did everyone else do this with the "forall n. length l <= n"/induction on n method? [Wed Sep 23 16:52:08 2015] I did it that way, yup [Wed Sep 23 16:52:25 2015] and that's my advice for anyone who asks for it here :p [Wed Sep 23 16:52:49 2015] newsham: that's exactly how I did it [Wed Sep 23 16:52:58 2015] based on advice from people here :) [Wed Sep 23 16:53:08 2015] some day, someone will discover a new way [Wed Sep 23 16:53:51 2015] seems a little unfair to not have at least broached the subject of strong induction earlier [Wed Sep 23 16:53:55 2015] :) [Wed Sep 23 16:54:09 2015] what is "strong" induction? [Wed Sep 23 16:54:35 2015] when you prove P n based on knowledged that P m is valid for all m instead of just knowledge of P (n-1) [Wed Sep 23 16:55:37 2015] I think this was a fun exercise, but I think they could have prepped people for it a little more (and also included it AFTER you've proven the other le_* theorems that immediately follow in the chapter) [Wed Sep 23 16:55:58 2015] also I had to go back and generalize some of the proofs that were done earlier over natlist. [Wed Sep 23 16:56:25 2015] like length_snoc, rev_length and rev_injective [Wed Sep 23 16:56:45 2015] [Wed Sep 23 19:44:08 2015] 22:51:13 newsham | did everyone else do this with the "forall n. length l <= n"/induction on n method? [Wed Sep 23 19:44:14 2015] actually, i can say: no [Wed Sep 23 19:44:16 2015] ;D [Wed Sep 23 19:45:31 2015] RegEchse: oh ho, how did you do it? [Wed Sep 23 19:47:19 2015] my first solution was via defining a "symmetric list" version if 'list' which made the theorem to prove almost trivial. Then i defined conversion functions between list and slist and proved "that they are isomorphic via these functions" and that they commute with rev (and i don't know whether this would be the correct phrase in terms of type theory, therefore the ""). [Wed Sep 23 19:47:26 2015] it was quite long and bla [Wed Sep 23 19:47:40 2015] but it worked and i liked it from a conceptual point of view :) [Wed Sep 23 19:48:06 2015] cool [Wed Sep 23 19:49:06 2015] i can upload the code somewhere, if you want. Then i was unsatisfied with my way, btw, because i got the feeling that the point of the exercise couldn't be to define a new type and so on. ;D [Wed Sep 23 19:49:56 2015] Then i actually _thought_ about the problem, solved it with pen and paper in a way that i could translate to coq and yeah, that also was a "induction over length of the list" solution. :D [Wed Sep 23 20:04:43 2015] RegEchse: interesting. [Wed Sep 23 20:04:52 2015] i guess i could have done that with only techniques already learned [Wed Sep 23 20:09:36 2015] funny that in the end paper and pencil still turns out to be easier sometimes :( [Wed Sep 23 20:19:56 2015] yes, i think it only uses techniques one learns in the book up to that point. [Wed Sep 23 20:20:15 2015] newsham: what exactly do you mean by your last statement? I mean, p&p proofs are much easier in quite many cases. [Wed Sep 23 20:21:29 2015] but then most of the times you don't work in CIC when writing down a proof. [Wed Sep 23 20:23:37 2015] e.g. exactly that exercise about rev and pal is an example where most authors would write "trivial" or "left as an exercise"; even if you do some induction in the proof you'd simply "destruct the list from the left and right" ... [Wed Sep 23 20:24:42 2015] But doing p&p proofs _that work in coq_, i don't find any "easier". It's just that i can structure my thought better and also that doodling helps my brain to think ... :D [Wed Sep 23 20:29:50 2015] whats p&p [Wed Sep 23 20:33:17 2015] paper and pencil [Wed Sep 23 20:33:21 2015] ha [Wed Sep 23 21:00:58 2015] sry, i was lazy :/ [Thu Sep 24 00:15:43 2015] how come I cant search about "_ ++ _" ? [Thu Sep 24 00:18:21 2015] newsham: iirc, SearchAbout doesn't handle notations. use [Lookup "_ ++ _".] to find its real name and then search about that. [Thu Sep 24 00:36:33 2015] subseq_trans seems like its going to be a tricky one to [Thu Sep 24 00:36:35 2015] too [Thu Sep 24 01:08:54 2015] newsham: yes but not as tricky as the palindrome one :) [Thu Sep 24 02:08:30 2015] What was the tactical for repeatedly trying a bunch of tactics (alternatedly, not in sequence) until none succeeds? [Thu Sep 24 02:11:24 2015] Alternatively, what's the most efficient way to provide that `a + b + (c + d) = a + c + (b + d)`. [Thu Sep 24 02:12:02 2015] (I can do it the hard way manually invoking plus_assoc and plus_comm where necessary, but it feels clumsy.) [Thu Sep 24 02:42:11 2015] hamilto-nyan: unfortunately, plus_comm will happily continue to swap the same plus back and forth, so you can't just wait for it not to succeed [Thu Sep 24 02:48:00 2015] hamilto-nyan: try `ring`? [Thu Sep 24 03:30:32 2015] jrw: Yeah, I have noticed. :-| [Thu Sep 24 03:30:37 2015] asmanur: Is that a tactic? :-O [Thu Sep 24 03:30:40 2015] asmanur: Where's it defined? [Thu Sep 24 05:27:20 2015] hamilto-nyan: it depends on the type of your variables... if it's nat, it's available after a mere "Require Import Arith" [Thu Sep 24 05:28:21 2015] ring is documented in the reference manual [Thu Sep 24 22:14:48 2015] hi [Thu Sep 24 22:17:42 2015] hi [Thu Sep 24 22:17:45 2015] * meow [Fri Sep 25 15:14:09 2015] afternoon, fellow provers [Fri Sep 25 15:28:39 2015] good night, johnw ;) [Fri Sep 25 15:29:36 2015] I can prove constructively that it is the afternoon. hah! [Fri Sep 25 15:30:06 2015] :D i guess it's the context that matters ;) [Fri Sep 25 15:30:25 2015] true, I've axiomatized pacific daylight time [Sun Sep 27 11:45:39 2015] hello [Sun Sep 27 11:45:52 2015] does anyone know how to list the theorems that a theorems proof uses? [Sun Sep 27 11:46:05 2015] (I want to do this recursively to generate a dependency graph of theorems) [Sun Sep 27 13:05:56 2015] vanila: Print Opaque Dependencies will give you some of it [Sun Sep 27 13:06:02 2015] as well as Print Assumptions [Sun Sep 27 13:21:57 2015] thanks! [Sun Sep 27 13:22:07 2015] opaque deps seems to be transitive dependencies [Sun Sep 27 13:22:18 2015] i might need to hack coq to get a way to print a single step of deps.. [Sun Sep 27 14:34:27 2015] so what is everyone working on? :) [Sun Sep 27 14:37:49 2015] a theorem in ACL2 [Sun Sep 27 14:38:33 2015] interesting, i haven't used ACL2 [Sun Sep 27 14:38:49 2015] i wonder if its similar to jbob from the little prover book [Sun Sep 27 14:41:14 2015] it seems that J-Bob can run on ACL2 [Mon Sep 28 10:58:09 2015] hi is it possible to get a version of coq with Type : Type so that i can try russelling it [Mon Sep 28 10:58:11 2015] c [Mon Sep 28 11:00:21 2015] There is the flag -type-in-type [Mon Sep 28 12:22:49 2015] Cypi: is that during compilation? [Mon Sep 28 12:25:18 2015] You can append this flag to most Coq utilities [Mon Sep 28 12:25:30 2015] "coqide -type-in-type", "coqc -type-in-type", "coqchk -type-in-type" [Mon Sep 28 12:25:38 2015] and so on [Mon Sep 28 12:25:52 2015] [~]$ coqtop -type-in-type [Mon Sep 28 12:25:55 2015] Don't know what to do with -type-in-type [Mon Sep 28 12:26:12 2015] Hmm? It works for me [Mon Sep 28 12:26:19 2015] Maybe it's a 8.5 thing [Mon Sep 28 12:28:08 2015] is 8.5 the beta version? [Mon Sep 28 12:28:19 2015] It's still in beta, yes [Mon Sep 28 12:29:39 2015] kk [Mon Sep 28 12:30:56 2015] Since I got ignored in #archlinux: I'm trying to install coq, which requires camlp5-transitional. However, when trying to build that, I get shouted at: http://hastebin.com/ahodayejam.txt - I did try to stick -fPIC in various places, but to no avail. What can I do to resolve this issue? [Mon Sep 28 12:31:05 2015] benzrf: 8.5b2 has been working well for me [Mon Sep 28 12:34:24 2015] johnw: was just wondering why i was a version behind when im on Arch [Mon Sep 28 12:46:39 2015] Oh, looks like I can use camlp4, which is in an official repo and therefore a binary package! Let's go with that, then :D [Mon Sep 28 12:47:04 2015] Unfortunately, I get a very similar error when compiling coq -_- [Mon Sep 28 12:58:16 2015] xandaros: I built 8.5b2 with camlp5 [Mon Sep 28 12:58:54 2015] Well, I can't even build camlp5, so that's not an option [Mon Sep 28 12:59:58 2015] oh, hmm [Mon Sep 28 13:00:10 2015] sorry, I have to run now and can't help debug further [Mon Sep 28 13:01:20 2015] hmm, k [Mon Sep 28 14:17:52 2015] xandaros: i can give you my PKGBUILD that i used to build camlp5-t... [Mon Sep 28 14:18:09 2015] xandaros: i don't remember exactly but i changed some lines (compared to the aur version) xD [Mon Sep 28 14:18:37 2015] ah, diff helps: i just updated it to use version 6.14 [Mon Sep 28 14:19:12 2015] RegEchse: I think I need to compile ocaml with -fPIC for it to work. I'll try it one I get home, on a tram at the moment [Mon Sep 28 14:19:20 2015] thanks for the offer, though [Mon Sep 28 14:20:41 2015] oh sry, i was talking nonsense anyway. Well, nevermind then. good luck [Mon Sep 28 14:21:25 2015] I do wonder why it doesn't work for me, but does for others, though. always found that curious when compiling [Mon Sep 28 14:21:42 2015] you'd think it's somewhat consistent, but no... [Mon Sep 28 14:25:28 2015] is there a such thing as two closed terms that are propositionally but not definitionally equal [Mon Sep 28 14:25:42 2015] in vanilla coq [Mon Sep 28 14:55:15 2015] benzrf: I don't think so, no. [Mon Sep 28 14:58:14 2015] hm [Mon Sep 28 14:58:16 2015] bbl [Mon Sep 28 14:59:54 2015] benzrf: if you have [. |- pf : a = b] then pf must normalize to refl by canonicity, which means a and b must be definitionally equal. [Mon Sep 28 15:31:26 2015] what about fun x => x + 2 = 0 vs. fun x => 2 + x = 0. is that what you mean? [Mon Sep 28 16:09:36 2015] johnw: can you prove those equal? [Mon Sep 28 16:09:53 2015] sadly I cannot prove it except by extensionality [Mon Sep 28 16:10:18 2015] so I guess by propositionally equal, he meant = equal [Mon Sep 28 16:10:27 2015] right, exactly. [Mon Sep 28 16:10:36 2015] if you add funext, then you break canonicity [Mon Sep 28 16:10:41 2015] and my argument goes out the window [Mon Sep 28 16:10:45 2015] the one thing that always trips me up about type theory is how many equals there are [Mon Sep 28 16:10:50 2015] :D [Mon Sep 28 16:10:53 2015] the more the merrier [Mon Sep 28 16:10:54 2015] or something. [Mon Sep 28 16:10:57 2015] := = == ≡ ≅ ... [Mon Sep 28 16:11:21 2015] have a problem you can't solve, define a new equality! [Mon Sep 28 16:11:27 2015] pretty much [Mon Sep 28 16:52:41 2015] I got coq to work now, but I can't use arrow keys in coqtop. Is that normal? :( [Mon Sep 28 16:53:31 2015] do you mean, in coqide? [Mon Sep 28 16:56:12 2015] No, in coqtop [Mon Sep 28 16:56:21 2015] I like my terminal [Mon Sep 28 16:59:14 2015] oh [Mon Sep 28 16:59:27 2015] um, normal? You can always use rlwrap to give readline behavior to anything [Mon Sep 28 17:00:13 2015] Hmm, never heard of that. I'll try [Mon Sep 28 17:01:07 2015] just: rlwrap some-command [Mon Sep 28 17:02:21 2015] Yeah, need to update my system before I can install rlwrap. It'll take a moment :) [Mon Sep 28 17:13:28 2015] johnw: This is awesome. It works, thank you! :) [Mon Sep 28 17:14:26 2015] jrw: yeah, canonicity [Mon Sep 28 17:14:44 2015] i was thinking about the computational meaning of an equality [Mon Sep 28 17:45:47 2015] so i was reading this https://www.quora.com/What-is-Girards-paradox and it mostly makes sense, but [Mon Sep 28 17:46:10 2015] >and subset:U→P(U) (subset a intuitively says "let us think the element a of U as a subset of U") [Mon Sep 28 17:46:18 2015] i dont follow how this is possible [Mon Sep 28 17:46:54 2015] there's no decision procedure for whether a given type is a sigma type, let alone extracting its predicate [Tue Sep 29 01:54:59 2015] why does Coq flatten parameterized types in extracted Haskell code? Are there conflicts etween the type theories if they are kept? [Tue Sep 29 07:20:37 2015] hello [Tue Sep 29 07:20:46 2015] how do we know that excluded middle is independent from coqs theory? [Tue Sep 29 07:28:33 2015] vanila: the best i've found was http://cstheory.stackexchange.com/questions/4905/where-is-the-proof-that-coq-excluded-middle-is-consistent [Tue Sep 29 07:28:44 2015] so as long you have predicative Set you're fine [Tue Sep 29 07:30:47 2015] thanks [Tue Sep 29 11:27:52 2015] Has anyone made an online coqide pastebin kind of thing? I wanted to send a simple coq proof to a non coq user and let them step through it without forcing them to install coq locally [Tue Sep 29 11:37:39 2015] oh, I guess it's not so bad. I didn't realize coq had autoinstallers that came with coqide for windows and mac :) [Tue Sep 29 12:00:46 2015] that actually sounds interesting [Tue Sep 29 12:39:28 2015] https://ssrg.nicta.com.au/jobs/proof-engineers2015 [Tue Sep 29 12:40:56 2015] can they do it remotely? >_> [Tue Sep 29 12:41:33 2015] not my listing. i doubt it. [Tue Sep 29 12:41:38 2015] dang [Tue Sep 29 12:41:39 2015] http://sel4.systems/pipermail/devel/2015-September/000528.html [Wed Sep 30 12:05:14 2015] hello. what is the best way to extract coq's strings into ocaml? ocaml appears to only have immutable strings. [Thu Oct 1 15:14:49 2015] hi, I have a question about universes: it is only by quantifying over values of type Type_i that the result has type Type_{i+1}, isn't it? [Thu Oct 1 15:18:08 2015] Coq < Check Type -> Type. [Thu Oct 1 15:18:10 2015] Type (* Top.1 *) -> Type (* Top.2 *) [Thu Oct 1 15:18:12 2015] : Type (* max((Top.1)+1, (Top.2)+1) *) [Thu Oct 1 15:20:21 2015] companion_cube: whenever Type_i must be a subtype of some Type_{i+1}, for example records, functions, product or sum constructions, etc. [Thu Oct 1 15:20:58 2015] Type_i -> Type_j has type Type_{lub{i+j}+1} [Thu Oct 1 15:23:01 2015] so, for instance, list : Type_i -> Type_i, and (Type_i -> Type_i) : Type_{i+1}? [Thu Oct 1 15:23:18 2015] so unless I quantify over unary type constructors I can stay in the same univers [Thu Oct 1 15:23:19 2015] e [Thu Oct 1 15:24:13 2015] not quite sure what you mean by that [Thu Oct 1 15:24:20 2015] but Type_i -> Type_i is Type_i+1, yes [Thu Oct 1 15:24:30 2015] ok, thanks [Thu Oct 1 15:25:34 2015] (I'm asking that because I wonder whether "simple" Coq programs typically live in the few lowest universes) [Thu Oct 1 15:33:39 2015] turn on Set Printing Universes. [Thu Oct 1 15:35:26 2015] oh, thanks. [Fri Oct 2 07:30:28 2015] hi. is it possible to extract lists to lazy lists in ocaml? [Fri Oct 2 07:31:17 2015] because I have an algorithm that reads a file bitwise... and writes it bitwise... which works perfectly in Haskell, but will probably break ocaml. [Fri Oct 2 07:34:26 2015] I'm not sure a lazy list is a good way to do IO anyway [Fri Oct 2 07:34:49 2015] you mean you read the file bit by bit? [Fri Oct 2 12:49:41 2015] greetings fine people ... how do I export definitions that i made in coqtop [Fri Oct 2 13:03:46 2015] artart78: tag your logs ... i'm here [Fri Oct 2 15:16:48 2015] companion_cube: yes [Fri Oct 2 15:17:34 2015] if you want efficiency, you should rather use bigarrays and Bigarray.Array1.map_file [Fri Oct 2 15:17:41 2015] but we should discuss this on #ocaml [Fri Oct 2 15:26:09 2015] companion_cube: I know that this would be better, but currently I want lazy arrays. [Sat Oct 3 02:18:17 2015] Hi all, I have trouble running example from http://adam.chlipala.net/cpdt/html/Cpdt.StackMachine.html [Sat Oct 3 02:18:31 2015] it says it cannot find the library [Sat Oct 3 02:19:04 2015] even through i have coq-prog-args set to ("-emacs-U" "-R" "~/.emacs.d/src/cpdt/src" "Cpdt") [Sat Oct 3 02:19:18 2015] that dir is where the lib is at [Sat Oct 3 02:19:30 2015] make finished without error in it [Sat Oct 3 02:21:19 2015] I do have a warning that proofgeneral is compiled for emacs-24.2, while mine is 24.5 [Sat Oct 3 02:21:31 2015] can that be the issue here? [Sat Oct 3 08:13:02 2015] hello, can someone give reference to Prop, Type, Set, etc? I 'm totally confused. [Sat Oct 3 08:13:30 2015] sorry, not reference. just some tutorials explaining their relations. [Sat Oct 3 08:23:19 2015] ok, some tutorials here: http://adam.chlipala.net/cpdt/html/Universes.html [Sat Oct 3 21:11:43 2015] cannot load CpdtTactics :( [Sat Oct 3 21:12:07 2015] Cannot find library Cpdt.CpdtTactics in loadpath [Sat Oct 3 21:12:39 2015] coq-prog-args is a variable defined in `pg-custom.el'. [Sat Oct 3 21:12:41 2015] Its value is ("-emacs-U" "-R" "~/.emacs.d/src/cpdt/src" "Cpdt") [Sat Oct 3 21:15:37 2015] so, what is in that directory? [Sat Oct 3 21:15:37 2015] sizur: can you double check that there is a file CpdtTactics.vo in that directory? [Sat Oct 3 21:15:43 2015] yeah [Sat Oct 3 21:16:08 2015] ls ~/.emacs.d/src/cpdt/src | grep CpdtTactics | column [Sat Oct 3 21:16:10 2015] CpdtTactics.glob CpdtTactics.v.d [Sat Oct 3 21:16:12 2015] CpdtTactics.v CpdtTactics.vo [Sat Oct 3 21:16:41 2015] sorry, dont know what happened with that paste, but the file is there [Sat Oct 3 21:16:48 2015] sizur: this is what I would do [Sat Oct 3 21:16:59 2015] in the project where you want to *use* CpdtTactics, make a file called _CoqProject [Sat Oct 3 21:17:05 2015] the first line of this file should be: [Sat Oct 3 21:17:19 2015] -R /.emacs.d/src/cpdt/src Cpdt [Sat Oct 3 21:17:23 2015] where is expanded by hand there [Sat Oct 3 21:17:30 2015] then, after that line, list every .v file in your project [Sat Oct 3 21:17:34 2015] this is what works for me [Sat Oct 3 21:18:05 2015] proofgeneral knows to parse this file and sniff out the project-specific options [Sat Oct 3 21:18:18 2015] and coq_makefile knows to read it for generating the Makefile.coq [Sat Oct 3 21:18:34 2015] ah, it doesn't expand ~? [Sat Oct 3 21:18:52 2015] then maybe just modifying that in the coq-prog-args should work? [Sat Oct 3 21:18:59 2015] I really don't know [Sat Oct 3 21:19:07 2015] duh, that makes sense, it's not expanded by shell when it's called like that [Sat Oct 3 21:19:19 2015] I've had every kind of failure trying to do it the non-_CoqProject ways, so now I just stick to what works [Sat Oct 3 21:25:44 2015] it's so incredibly frustrating when so many books just skim over the setup step. if one cannot setup, the rest of the book you spent money on is just trash [Sat Oct 3 21:26:08 2015] so true, sizur [Sat Oct 3 21:27:36 2015] alright, now it works [Sat Oct 3 21:29:01 2015] (load-file "~/.emacs.d/src/ProofGeneral/generic/proof-site.el") [Sat Oct 3 21:29:03 2015] (eval-after-load 'coq [Sat Oct 3 21:29:05 2015] '(setq coq-prog-args [Sat Oct 3 21:29:07 2015] `("-emacs-U" [Sat Oct 3 21:29:09 2015] "-R" [Sat Oct 3 21:29:11 2015] ,(expand-file-name [Sat Oct 3 21:29:13 2015] "~/.emacs.d/src/cpdt/src") [Sat Oct 3 21:29:15 2015] "Cpdt"))) [Sat Oct 3 21:29:30 2015] johnw: thank you! [Sat Oct 3 21:31:16 2015] ProofGeneral functions should really expand their filename arguments before useage. [Sun Oct 4 02:54:32 2015] welcome [Sun Oct 4 02:54:39 2015] heya [Sun Oct 4 02:54:51 2015] Are you good with Coq? [Sun Oct 4 02:55:10 2015] not really. I'm on a slow train to upload ssreflect into the brain. [Sun Oct 4 02:55:17 2015] why, you got a problem? [Sun Oct 4 02:55:26 2015] just a newbie struggling to prove things >_< [Sun Oct 4 02:55:54 2015] welcome. :) [Sun Oct 4 02:56:25 2015] is anyone else alive at the moment? probably not. it's usually pretty quiet. [Sun Oct 4 02:57:20 2015] what are you proving? [Sun Oct 4 02:57:42 2015] I'm trying to show that two functions that sum elements in a tree are equal. [Sun Oct 4 02:57:50 2015] So I have a fold function [Sun Oct 4 02:57:52 2015] Fixpoint fold (alpha : Type) (f : alpha -> Z -> alpha) (a : alpha) (t : inttree) : alpha := match t with | Empty => a | Node j l r => fold f (fold f (f a j) l) r end . [Sun Oct 4 02:58:09 2015] Here inttree is [Sun Oct 4 02:58:10 2015] Inductive inttree := | Empty : inttree | Node : Z -> inttree -> inttree -> inttree. [Sun Oct 4 02:58:19 2015] And I want to show these two sum functions are equal [Sun Oct 4 02:58:26 2015] Fixpoint sum1 (x:inttree) : Z := match x with | Empty => 0 | Node j l r => j + (sum1 l) + (sum1 r) end . [Sun Oct 4 02:58:35 2015] Fixpoint sum2 (x:inttree) : Z := fold (fun x y => x + y) 0 x. [Sun Oct 4 02:59:06 2015] in other words [Sun Oct 4 02:59:17 2015] Proposition sum_equivalence : forall x : inttree, sum2 x = sum1 x. [Sun Oct 4 03:00:13 2015] I can do it if I can prove this lemma [Sun Oct 4 03:00:15 2015] Lemma sum2_lemma : forall z : Z, forall x1 x2 : inttree, sum2 (Node z x1 x2) = z + sum2 x1 + sum2 x2. [Sun Oct 4 03:00:22 2015] But I get tangled up in the definition of fold. [Sun Oct 4 03:01:06 2015] right. seems like it should go by structural induction pretty easily. [Sun Oct 4 03:01:56 2015] Hmm, what do you mean by that more precisely? [Sun Oct 4 03:02:06 2015] I've tried inducting on everything I could think of [Sun Oct 4 03:02:31 2015] hang on, I'll get my editor up. [Sun Oct 4 03:02:36 2015] thank you so much [Sun Oct 4 03:04:27 2015] I use this header [Sun Oct 4 03:04:28 2015] Require Import ZArith. Open Scope Z_scope. Require Import Le Gt Minus Bool Setoid. Set Implicit Arguments. Open Scope list_scope. [Sun Oct 4 03:04:35 2015] probably not all required but anyway. [Sun Oct 4 03:13:36 2015] I think we'd want to show a lemma like forall z, z + (sum2 l) + (sum2 r) = sum2 (Node z l r). [Sun Oct 4 03:13:41 2015] then the induction is easy. [Sun Oct 4 03:14:23 2015] Lemma sum2_lemma : forall z : Z, forall x1 x2 : inttree, sum2 (Node z x1 x2) = z + sum2 x1 + sum2 x2. [Sun Oct 4 03:14:34 2015] That's what I was trying. [Sun Oct 4 03:14:36 2015] Yours is the same right? [Sun Oct 4 03:14:39 2015] Let me try that again. [Sun Oct 4 03:14:56 2015] yeah, the same. [Sun Oct 4 03:16:39 2015] And this is where I drown in definition of fold. [Sun Oct 4 03:20:58 2015] I see. :) [Sun Oct 4 03:24:18 2015] At least I know I had one thought that might have been on the right track though :) [Sun Oct 4 03:24:38 2015] hey dram [Sun Oct 4 03:24:52 2015] tamago: hey, but...do I know you? [Sun Oct 4 03:25:02 2015] do you know me? [Sun Oct 4 03:25:27 2015] I don't know you in particular [Sun Oct 4 03:25:42 2015] Right now everyone is the same to me: someone who knows more :p [Sun Oct 4 03:26:16 2015] tamago: sorry but you are so friendly that I get a bit confused [Sun Oct 4 03:26:22 2015] now it's fine, don't worry [Sun Oct 4 03:26:53 2015] lol [Sun Oct 4 03:34:24 2015] Dram are you still there? [Sun Oct 4 03:34:45 2015] yep [Sun Oct 4 03:35:35 2015] Can I pick your brain on a proof? [Sun Oct 4 03:35:49 2015] It should be easy but I've been working on it for days. [Sun Oct 4 03:37:09 2015] tamago: perhaps, I'm free for a while [Sun Oct 4 03:37:22 2015] so [Sun Oct 4 03:37:31 2015] here is my code [Sun Oct 4 03:37:38 2015] It's holiday here in China, but that's not exactly important [Sun Oct 4 03:37:43 2015] Ah [Sun Oct 4 03:37:51 2015] I hope I'm not disturbing anything. [Sun Oct 4 03:37:58 2015] I don't follow holidays :p [Sun Oct 4 03:38:15 2015] nope, it's fine [Sun Oct 4 03:38:33 2015] Anyway, even hearing if this is hard or not would help [Sun Oct 4 03:38:36 2015] Require Import ZArith. Open Scope Z_scope. Require Import Le Gt Minus Bool Setoid. Set Implicit Arguments. Open Scope list_scope. [Sun Oct 4 03:38:48 2015] stop, stop pasting [Sun Oct 4 03:38:54 2015] ah I'm sorry [Sun Oct 4 03:39:00 2015] I think we need to show that fold over an associative function can be rewritten like we want to. [Sun Oct 4 03:39:04 2015] http://lpaste.net/new/coq maybe? [Sun Oct 4 03:39:10 2015] ah kk thanks [Sun Oct 4 03:39:25 2015] Oh sanooj you're still working on it o.O [Sun Oct 4 03:39:28 2015] Thank you so much [Sun Oct 4 03:39:33 2015] But I don't quite follow >_< [Sun Oct 4 03:40:23 2015] tamago: wait a sec...I'm not exactly sure it's easy... [Sun Oct 4 03:41:30 2015] ZArith? Setoid? ok now you can take that statement back because I obviously know less than you [Sun Oct 4 03:42:03 2015] tamago: before I get into the land of infinite folds I have something like this: fold add 0 (Node z l r) = z + (fold 0 l) + (fold add 0 r), which is just a small step away from the general property of folding over an associative f. [Sun Oct 4 03:42:36 2015] ah no, that was just a header I got from somewhere. [Sun Oct 4 03:42:37 2015] dramforever: you don't need any of that. I just set Z := nat and got on with it. [Sun Oct 4 03:42:57 2015] I don't use all of that lol. [Sun Oct 4 03:43:19 2015] http://lpaste.net/142274 [Sun Oct 4 03:43:42 2015] ZArith I think I need because this is done with Z and not nat. [Sun Oct 4 03:44:04 2015] Then the code uses implicit arguments for the fold function, but I think I don't need the rest. [Sun Oct 4 03:48:29 2015] sanooj I agree with you that seems easier, but I still can't do it :p [Sun Oct 4 03:49:02 2015] me neither. working on it. [Sun Oct 4 03:54:59 2015] I don't really want to unfold fold, since the definition is gigantic. [Sun Oct 4 03:55:09 2015] But maybe it's unavoidable [Sun Oct 4 03:58:19 2015] ok, so I have it down to something similar to this: fold f x t = f x (fold f 0 t) [Sun Oct 4 03:58:45 2015] Better than me. [Sun Oct 4 03:58:54 2015] Although I've gotten things that looked like that before. [Sun Oct 4 03:58:59 2015] Try unfold fold? [Sun Oct 4 03:59:46 2015] I guess I'll start on that as a lemma. [Sun Oct 4 04:04:15 2015] status report: I was doing induction in different ways. Nothing good so far [Sun Oct 4 04:04:27 2015] *trying to do induction in... [Sun Oct 4 04:04:31 2015] Same! [Sun Oct 4 04:04:44 2015] Thank you both sooooo much!!!! [Sun Oct 4 04:04:56 2015] tamago: no I don't deserve any thanks for not helping at all [Sun Oct 4 04:05:01 2015] haha [Sun Oct 4 04:05:11 2015] But you convinced me that the problem is actually tricky. [Sun Oct 4 04:05:17 2015] Which is some sort of progress. [Sun Oct 4 04:06:23 2015] yeah, so you are not missing anything too obvious [Sun Oct 4 04:09:02 2015] So one idea I had if this simply won't work, is to define inttree as a dependent type in terms of the sum of elements. I'm not sure if that would help. [Sun Oct 4 04:15:03 2015] I think I'm pretty close with the lemma. just need to coerce coq into doing the rewrites I want. [Sun Oct 4 04:16:36 2015] oh wow! [Sun Oct 4 04:16:48 2015] *bows* [Sun Oct 4 04:16:57 2015] better wait for it. [Sun Oct 4 04:25:22 2015] tamago: hey I have an idea: maybe strengthen the induction hypothesis to something like fold (fun x y => x + y) r (Node z x1 x2) = z + sum x1 + sum x2 + r [Sun Oct 4 04:27:29 2015] ah, I want to do something like that [Sun Oct 4 04:27:49 2015] Gotta search for how to strengthen induction >_< [Sun Oct 4 04:28:05 2015] tamago: just prove another lemma :) [Sun Oct 4 04:28:17 2015] ah, lol [Sun Oct 4 04:28:25 2015] I was thinking there was a keyword [Sun Oct 4 04:29:42 2015] Ah, that's like sanooj was doing. [Sun Oct 4 04:30:26 2015] I worked on this, which is basically the same I think. [Sun Oct 4 04:30:26 2015] Lemma sum2_lemma : forall z : Z, forall x1 x2 : inttree, sum2 (Node z x1 x2) = z + sum2 x1 + sum2 x2. [Sun Oct 4 04:31:56 2015] tamago: I think the r might help induction [Sun Oct 4 04:41:23 2015] mh. I'm stuck reorganizing a sum. :( [Sun Oct 4 04:43:39 2015] sanooj: try the magical omega [Sun Oct 4 04:46:14 2015] okay then. magic it is! [Sun Oct 4 04:47:12 2015] http://pastebin.com/sTBuXtxn [Sun Oct 4 04:48:07 2015] * hasn't quite gotten the hang of proof golfing. [Sun Oct 4 04:48:26 2015] WOOOOW [Sun Oct 4 04:48:29 2015] Nice!! [Sun Oct 4 04:48:32 2015] Thank you so much! [Sun Oct 4 04:49:36 2015] you'll need to put the generic into f again, as I simplified it to be over Z always. [Sun Oct 4 04:49:54 2015] wow [Sun Oct 4 04:50:14 2015] Yea, some details left. I'm going to try to do it for Z also instead of nat. [Sun Oct 4 04:50:39 2015] so you proved it? too bad can't visit pastebin here [Sun Oct 4 04:51:15 2015] I would be greatful if you code repaste it here http://lpaste.net/new/coq [Sun Oct 4 04:51:20 2015] Man, some of the stuff sanooj did was pretty close to what I tried. I feel better about myself now. [Sun Oct 4 04:51:30 2015] kk [Sun Oct 4 04:51:57 2015] http://lpaste.net/142277 [Sun Oct 4 04:52:03 2015] http://lpaste.net/142278 [Sun Oct 4 04:52:05 2015] oopps lol [Sun Oct 4 04:52:07 2015] sanooj: thanks...lol [Sun Oct 4 04:52:16 2015] tamago: thanks for you too [Sun Oct 4 04:52:54 2015] I had done something like in fold_pull_out_plus, but I didn't think to apply the inductive hypotheses twice >_< [Sun Oct 4 04:53:07 2015] I was like "welp that didn't work" [Sun Oct 4 04:53:09 2015] I expect the expert ssreflectors could slim it down to one line of totally unreadable line noise. [Sun Oct 4 04:53:49 2015] sanooj: oh that fold_pull_out_plus thing was excellent =P [Sun Oct 4 04:53:57 2015] It's funny to me how languages rise to the heights of well typedness in Coq, only to completely morph back into obfuscation in Ltac. [Sun Oct 4 04:53:58 2015] freeing us from fold [Sun Oct 4 04:54:28 2015] tamago: the true magic of coq isn't inside gallina the CIC thing [Sun Oct 4 04:54:30 2015] Yea, part of me thought that just couldn't be done o.O [Sun Oct 4 04:54:32 2015] it's ltac [Sun Oct 4 04:54:41 2015] True [Sun Oct 4 04:55:38 2015] Man thank you so much again, this is really really nice, despite all what you say about it not being golfy :p [Sun Oct 4 04:55:39 2015] sanooj: that makes it easier to work with [Sun Oct 4 04:55:58 2015] sanooj: thanks for you too [Sun Oct 4 04:56:13 2015] yeah. stumbling on the right thing to factor out was the accident that worked. :) [Sun Oct 4 04:58:41 2015] Ah, and just a few changes and it works for Z as well, not just nat. [Sun Oct 4 04:59:06 2015] tamago: *that's* what I mean by magical omega :P [Sun Oct 4 04:59:22 2015] literally suits all your linear integer arithmetic needs [Sun Oct 4 04:59:33 2015] Also sanooj you can use the intuition tactic in some places to be more golfy [Sun Oct 4 05:00:28 2015] thanks. although to be honest, I'm not a fan of the automagic bits yet. [Sun Oct 4 05:00:56 2015] I have almost no feeling for how coq searches for proofs or does type inference. [Sun Oct 4 05:01:34 2015] I like automagic where it's easy to find a long boring proof. I'm a bit more uneasy about the places where I don't know how it actually proved it. [Sun Oct 4 05:01:42 2015] in my mind it's like a supercharged hindley-milner. [Sun Oct 4 05:02:24 2015] Well I think that example didn't use anything beyond hindley milner [Sun Oct 4 05:02:48 2015] (not counting whatever theory goes into proof terms) [Sun Oct 4 05:04:28 2015] so I actually popped in here looking for some help understanding the proof od le_irrelevance in ssrnat.v [Sun Oct 4 05:04:49 2015] Ah, well, I can try? :p [Sun Oct 4 05:04:49 2015] *of le_irrelevance. [Sun Oct 4 05:05:04 2015] have you used ssreflect before? [Sun Oct 4 05:05:10 2015] nope [Sun Oct 4 05:06:09 2015] ah, hang on: http://lpaste.net/142279 [Sun Oct 4 05:06:20 2015] so. line noise. [Sun Oct 4 05:06:44 2015] oops. I've duplicated the first line of the proof. ignore that [Sun Oct 4 05:07:23 2015] wait is this your proof? what is this? [Sun Oct 4 05:07:28 2015] I'm trying to get it to run..... [Sun Oct 4 05:07:45 2015] oh, you wouldn't be able to. you'd need to get the ssreflect package installed on your system. [Sun Oct 4 05:08:11 2015] ah ic [Sun Oct 4 05:08:11 2015] that paste was just to see what it looks like. [Sun Oct 4 05:08:15 2015] Okay [Sun Oct 4 05:09:41 2015] Man, I really wish I could understand this. [Sun Oct 4 05:09:52 2015] so for most ssreflect proofs I've looked at I've been able to deconstruct the noise into its individual components. [Sun Oct 4 05:10:41 2015] sanooj: also thanks for telling me about the bullets things! they are indeed interesting [Sun Oct 4 05:11:19 2015] bullets? [Sun Oct 4 05:11:38 2015] the hyphens in the proof. [Sun Oct 4 05:11:45 2015] ah [Sun Oct 4 05:21:53 2015] Well thank you again so much. [Sun Oct 4 05:22:00 2015] I hope to see you guys around. [Sun Oct 4 05:22:13 2015] Sorry I'm not of any use with ssreflect >_< [Sun Oct 4 05:25:26 2015] np. there's more to upload even if I skip that proof. [Sun Oct 4 05:46:56 2015] dramforever pasted “As an exercise, I golfed your proof :)” at http://lpaste.net/7157656852409352192 [Sun Oct 4 05:47:10 2015] sanooj: ^ [Sun Oct 4 05:48:07 2015] to me, line 18-19 the pose proof -> congruence is the funniest part [Sun Oct 4 05:52:10 2015] I get "Omega can't solve this system" when solving doing r = r + 0 in the first omega. [Sun Oct 4 05:53:00 2015] hmm...that's a bit weird and that's what I get for golfing [Sun Oct 4 05:53:21 2015] perhaps auto with * could do it? [Sun Oct 4 05:55:35 2015] mh. fixing that, then I get "congruence failed" [Sun Oct 4 05:55:54 2015] sanooj: arrgh, the funniest part isn't it [Sun Oct 4 05:56:15 2015] I'm using coq8.5, perhaps those tactics got waaaay smarter [Sun Oct 4 05:56:49 2015] perhaps. I'm on 8.4 I think. [Sun Oct 4 05:57:05 2015] yeah. [Sun Oct 4 05:57:10 2015] sanooj: tbh I didn't even expect congruence to do that [Sun Oct 4 05:57:25 2015] heh. [Sun Oct 4 05:57:54 2015] it's pretty slick. [Sun Oct 4 05:58:20 2015] sanooj: I guess with coq8.4 you will have to rewrite fold_plus_out twice, like you did it in the original one [Sun Oct 4 07:58:48 2015] pppppppppppp [Sun Oct 4 09:38:02 2015] hello, how can I write circular definition? https://bpaste.net/show/b3e39a3eab66 [Sun Oct 4 09:42:44 2015] use "with"? [Sun Oct 4 09:43:30 2015] sanooj: more details please? [Sun Oct 4 09:44:56 2015] I don't know for sure as I've never done it, but iirc you should be able to just separate your mutually recursive definitions using "with". [Sun Oct 4 09:45:13 2015] a little googling gives me an example like this: [Sun Oct 4 09:45:16 2015] Inductive mtree (A : Type) : Type := [Sun Oct 4 09:45:16 2015] mnode : A -> forest A -> mtree A [Sun Oct 4 09:45:16 2015] with forest (A : Type) : Type := mnil : forest A [Sun Oct 4 09:45:16 2015] | mcons : mtree A -> forest A -> forest A. [Sun Oct 4 09:45:58 2015] sanooj: awesome! thanks. [Sun Oct 4 09:46:20 2015] if you look at the manual under the production fix_bodies, it shows about the same thing. [Sun Oct 4 09:46:35 2015] (figure 1.2) [Sun Oct 4 09:47:09 2015] or 1.3, syntax of terms. [Sun Oct 4 09:48:21 2015] where is "production fix_bodies"? [Sun Oct 4 09:50:04 2015] https://coq.inria.fr/refman/Reference-Manual003.html#sec26 [Sun Oct 4 09:51:18 2015] https://coq.inria.fr/refman/Reference-Manual003.html#sec39 <- described here [Sun Oct 4 09:52:00 2015] well, I say described, but like a lot of the manual, really more like "eluded to". [Sun Oct 4 09:53:44 2015] *alluded [Sun Oct 4 09:54:14 2015] but often it eludes me anyway. :) [Sun Oct 4 18:20:23 2015] greetings fine people .. what's the -outputstate coqtop option about [Sun Oct 4 18:28:00 2015] is there a way to save a coqtop session [Sun Oct 4 18:29:02 2015] you could try some of the unix process saving tools, like hol light does. [Sun Oct 4 18:29:16 2015] they seemed to work with an ml toplevel reasonably well. [Sun Oct 4 18:29:44 2015] what is it you want to do? [Sun Oct 4 18:32:17 2015] wait .. i'll try something [Sun Oct 4 18:33:24 2015] I used dmtcp on linux with hol light. it was okay. [Sun Oct 4 18:35:48 2015] i think it worked [Sun Oct 4 18:36:05 2015] so it's BWrite State "some.file.coq" [Sun Oct 4 18:36:15 2015] Write State "some.coq" [Sun Oct 4 18:36:27 2015] and then Restore State "some.coq" [Sun Oct 4 18:40:10 2015] thank you .. buddha bless you [Sun Oct 4 18:45:17 2015] also .. i have defined some module in coqtop .. is there a way to export it to a file [Sun Oct 4 19:07:49 2015] sorry, I don't really use coqtop so much. [Sun Oct 4 19:08:00 2015] I mainly use proof general through emacs. [Sun Oct 4 19:20:10 2015] sanooj: i absolve you [Sun Oct 4 19:31:28 2015] so i have a definition in my current state [Sun Oct 4 19:31:32 2015] how do i override it [Sun Oct 4 19:32:17 2015] I think you can Retract the definition [Sun Oct 4 19:32:25 2015] but I'm not entirely sure that's the verb [Sun Oct 4 20:43:40 2015] so if ident already exists i have to choose another name :\ [Sun Oct 4 22:59:03 2015] hello, I got H: S n = n. How can I skip the goal? inversion H doesn't help. [Sun Oct 4 23:02:11 2015] induction over n [Sun Oct 4 23:02:34 2015] to prove S n = n -> False? [Sun Oct 4 23:02:38 2015] yeah [Sun Oct 4 23:02:50 2015] ok, I 'll try. [Sun Oct 4 23:04:57 2015] (then you can just contradiction once you get False in the context) [Mon Oct 5 00:06:46 2015] riaqn: thats a valid equality for coinductive nats [Mon Oct 5 00:06:51 2015] its not a trivial fact w/o induction [Mon Oct 5 11:39:14 2015] phew. seq.v seems like a normal straightforward file again. [Mon Oct 5 11:39:32 2015] not quite sure about the seqn_type though. [Mon Oct 5 11:40:44 2015] it seems to build a kind of curried thing to make seqn n work as advertised. [Mon Oct 5 11:59:09 2015] how to induction over two circular defined Inductive Type? [Mon Oct 5 11:59:30 2015] https://bpaste.net/show/231dbba4613a [Mon Oct 5 12:00:10 2015] you probably need to prove your own induction principle. [Mon Oct 5 12:00:12 2015] well, maybe my question itself is not clear...what's the meaning of 'induction over two types' [Mon Oct 5 12:01:16 2015] sanooj: Thanks, I 'll try. [Mon Oct 5 12:01:43 2015] although your paste does create tree_ind and forest_ind that look normal. [Mon Oct 5 12:05:59 2015] sanooj: hmm, I don't know how to express my needs. let me do some try and error first. [Mon Oct 5 13:27:01 2015] seq.v is like ten miles long. I'm not reading all of this! [Mon Oct 5 13:34:57 2015] mh. coq segfaulted on me. [Mon Oct 5 13:35:19 2015] Compute (code [:: 1;2;3;4;5]). -> SIGSEGV. [Mon Oct 5 13:35:42 2015] oh, with unary nats that's going to be a pretty large list. [Mon Oct 5 13:38:07 2015] about a million entries? [Mon Oct 5 13:41:59 2015] looks like coq can't deal with unary numbers > about 50k. [Mon Oct 5 13:45:14 2015] why's it segfaulting? ocaml programs shouldn't be segfaulting like that. [Mon Oct 5 13:46:30 2015] may be OS-specific heap and stack limits [Mon Oct 5 13:49:23 2015] i think stack overflows are one of the few things that will make compiled ocaml code segfault [Mon Oct 5 13:51:20 2015] indeed. increasing the stack limit to 16MB fixes that. [Mon Oct 5 13:52:41 2015] didn't realise I was using coqtop.opt. [Mon Oct 5 14:39:19 2015] if i constructed CIC-within-coq, and did something like [Mon Oct 5 14:40:04 2015] Definition provable (p : CICType) := exists e : CICExpr, checks e p. [Mon Oct 5 14:40:13 2015] and then [Mon Oct 5 14:40:56 2015] Axiom self_awareness : forall (P : Prop), exists (p : CICType), P <-> provable p. [Mon Oct 5 14:41:12 2015] can i derive False from this without LEM? [Mon Oct 5 16:31:46 2015] hello - is anyone working on something interesting in coq? [Mon Oct 5 16:41:51 2015] vanila: is it possible to do uninteresting things with coq? :) [Mon Oct 5 16:42:37 2015] touche :) [Mon Oct 5 16:43:12 2015] vanila: have you seen Fiat, from MIT? [Mon Oct 5 16:43:31 2015] that's the next thing I'll be playing with [Mon Oct 5 16:43:51 2015] i read atiny bit about it [Mon Oct 5 16:44:06 2015] oh, and QuickChick [Mon Oct 5 16:44:06 2015] http://sigops.org/sosp/sosp15/current/2015-Monterey/printable/013-chen.pdf [Mon Oct 5 16:44:09 2015] im not sure if this is related [Mon Oct 5 16:44:42 2015] I don't think that's related, but similar team [Mon Oct 5 16:44:47 2015] at least, the Adam aspect :) [Mon Oct 5 16:56:03 2015] vanila: are you looking for something to contribute to? if you say something more about your interests, maybe people can point you to relevant projects. [Tue Oct 6 08:14:51 2015] gah. ssr's .+ binding tighter than * is pretty confusing. [Tue Oct 6 08:50:37 2015] choice.v is giving me a headache. [Tue Oct 6 09:10:39 2015] could someone help me grok how to dig out the proofs in a canonical class structure? [Tue Oct 6 09:11:50 2015] for example in choice.v the [Lemma correct P n x: find P n = Some x -> P x] seems to be basically giving a name to the unnamed proof of the same fact in the choice Mixin. [Tue Oct 6 09:12:44 2015] I don't understand how it destructs everything using [by case: T => _ [_[]] in P n x *] and then just *bam* proved. [Tue Oct 6 09:13:42 2015] usually with these long sequences of case or rewrite I know how to split it up into the individual steps, but everything I've tried with this just comes up with a lot of "you can't do that" [Tue Oct 6 10:09:59 2015] i kinda wanna try using coq to formalize the topology ive been learning [Tue Oct 6 10:10:09 2015] but theres a ton of classical logic and set theory and real numbers ;-; [Tue Oct 6 10:11:03 2015] how painful would it be to build up enough set theoryish general topology stuff to, say, establish the IVT for functions R -> R? [Tue Oct 6 10:11:13 2015] are there any decent set theory libs for coq? [Tue Oct 6 10:11:47 2015] i think there are some formalizations of the reals [Tue Oct 6 10:12:22 2015] yeah but how much do they suck ass to work with [Tue Oct 6 10:12:42 2015] suck coq* [Tue Oct 6 10:12:47 2015] :] [Tue Oct 6 10:14:11 2015] dunno [Tue Oct 6 11:22:19 2015] benzrf: I have some basic set theory stuff that you could hack apart and build upon; it's based on some paper that I read [Tue Oct 6 11:29:16 2015] hm [Tue Oct 6 11:29:21 2015] maybe i should check out nuprl :> [Tue Oct 6 11:29:25 2015] or jonprl [Tue Oct 6 11:30:01 2015] benprl [Tue Oct 6 11:30:14 2015] wew [Tue Oct 6 12:08:15 2015] hello, I 've defined two mutual recursive [fix], how can I return F0 /\ F1 ? a final [for] clause can only return one of them. [Tue Oct 6 12:11:32 2015] riaqn: can you show some code? [Tue Oct 6 12:12:45 2015] https://bpaste.net/show/3a1b77576c79 [Tue Oct 6 12:14:45 2015] I've never seen this use of "for"; what does it do? [Tue Oct 6 12:14:51 2015] sadly, it's incredibly hard to google or search the docs for [Tue Oct 6 12:14:51 2015] for x in xs: [Tue Oct 6 12:14:54 2015] ha [Tue Oct 6 12:15:06 2015] johnw: you could grep the docs for it in code tags [Tue Oct 6 12:15:14 2015] assuming I had that [Tue Oct 6 12:16:00 2015] johnw: when you define two mutually recursive anonymous functions, you must specify what the definition returns. [Tue Oct 6 12:16:17 2015] oh, that's like "return", but for those two functions [Tue Oct 6 12:16:39 2015] well, /\ wants propositions, but F0 and F1 are both functions [Tue Oct 6 12:16:43 2015] wondering why I have to 'specify', rather than just return P0 /\ P1. [Tue Oct 6 12:16:50 2015] for (forall t : tree, F0 t /\ F1 t) perhaps [Tue Oct 6 12:17:14 2015] oh yes.. function is a "proof", isn't it. [Tue Oct 6 12:18:50 2015] then I want to return [conj F0 F1]. [Tue Oct 6 12:19:20 2015] isn't that the exact same thing? [Tue Oct 6 12:19:26 2015] as F0 /\ F1 [Tue Oct 6 12:20:27 2015] I don't think so. (typeof F0) /\ (typeof F1) returns a Prop, while conj F0 F1 returns a proof to that Prop. [Wed Oct 7 09:15:29 2015] Hello guys, I have an issue... I need to prove `prod n 0 = 0`, with the following inductive definition for `prod`: [Wed Oct 7 09:15:42 2015] Fixpoint prod (n m : nat) : nat := [Wed Oct 7 09:15:42 2015] match n, m with [Wed Oct 7 09:15:43 2015] _, 0 => 0 [Wed Oct 7 09:15:43 2015] | 0, _ => 0 [Wed Oct 7 09:15:43 2015] | 1, _ => m [Wed Oct 7 09:15:43 2015] | _, 1 => n [Wed Oct 7 09:15:43 2015] | (S k), _ => sum (prod k m) m [Wed Oct 7 09:15:43 2015] end. [Wed Oct 7 09:16:50 2015] I don't know why: `Eval simpl in (forall n: nat, prod n 0 = 0).` doesn't reduce the term `prod n 0` to `0` (`prod 0 n` is reduced to `0`, though) [Wed Oct 7 09:17:10 2015] I think that case there [Wed Oct 7 09:17:14 2015] | _, 1 => n [Wed Oct 7 09:17:20 2015] is making it much harder than it would be otherwise [Wed Oct 7 09:17:24 2015] what about matching only on n [Wed Oct 7 09:17:55 2015] yes, my problem is I have to demonstrate `prod n m = prod m n` [Wed Oct 7 09:18:11 2015] so are you ok t ochange the definition of prod to make the proofs easier? [Wed Oct 7 09:18:15 2015] or would you rather keep it as written [Wed Oct 7 09:18:27 2015] and it doesn't evaluate the term `prod n 0` to `0` directly [Wed Oct 7 09:18:42 2015] why am I getting a complaint about prod k m having type nat instead of Type? [Wed Oct 7 09:18:44 2015] Even though you wrote a match on n and m simultaneously, it is actually, internally, a match on n followed by a match on m [Wed Oct 7 09:18:45 2015] yeah, I just wanted to make easier the proof [Wed Oct 7 09:18:53 2015] so the first match cannot reduce in the `prod n 0` case [Wed Oct 7 09:19:06 2015] ok so if you change it to 'match n with' [Wed Oct 7 09:19:15 2015] and delete that line _, 1 => n [Wed Oct 7 09:19:30 2015] yes, my previous definition was a match on n [Wed Oct 7 09:19:34 2015] proof by induction on n might work to show prod n 0 = 0 [Wed Oct 7 09:19:58 2015] You probably only need one destruct on n to prove that with your original definition, no need for induction [Wed Oct 7 09:19:59 2015] no, the problem is it wasn't show that in one step [Wed Oct 7 09:20:35 2015] ok thanks, yes, with a destruct I can show that [Wed Oct 7 09:20:35 2015] (maybe 2 destructs because you're matching on 1) [Wed Oct 7 09:20:45 2015] (but no induction required, as far as I can guess!) [Wed Oct 7 09:21:03 2015] http://lpaste.net/142472 [Wed Oct 7 09:21:15 2015] here's a hint how to start off [Wed Oct 7 09:21:19 2015] but I was wondering if it's possible to change the definition to show `prod n 0 = 0` in one `simpl`, just like `prod 0 n` does [Wed Oct 7 09:21:33 2015] I don't think that's possible [Wed Oct 7 09:21:47 2015] nicolas12 : you can, by swapping n and m in the match :p [Wed Oct 7 09:21:57 2015] But then you lose the reduction of `prod 0 n`, of course [Wed Oct 7 09:22:09 2015] Cype: :) yes, haha [Wed Oct 7 09:22:17 2015] vanila: thanks !! :) [Wed Oct 7 09:22:29 2015] thank you all, you were very helpful [Wed Oct 7 09:24:07 2015] nicolas12: are you using 8.5? [Wed Oct 7 09:24:33 2015] version 8.3pl4 :P [Wed Oct 7 09:24:54 2015] weird. I'm on 8.4, and coq isn't liking your Fixpoint prod. [Wed Oct 7 09:26:32 2015] why is that? [Wed Oct 7 09:27:00 2015] I don't know. it says 'The term "prod k m" has type "nat" while it is expected to have type "Type"' [Wed Oct 7 09:27:16 2015] but I thought nats were always Types. [Wed Oct 7 09:27:16 2015] ah, I see [Wed Oct 7 09:27:25 2015] I have another `sum` defined for nats [Wed Oct 7 09:27:53 2015] maybe coq's trying to match the other `sum` from prelude [Wed Oct 7 09:28:04 2015] yes, but shouldn't it work anyway? [Wed Oct 7 09:28:16 2015] An inhabitant of nat is not a Type [Wed Oct 7 09:28:18 2015] I really don't know [Wed Oct 7 09:28:19 2015] the sum from the prelude is Type -> Type -> Type. [Wed Oct 7 09:28:42 2015] Cypi: ah. [Wed Oct 7 09:28:48 2015] You have [2 : nat] and [nat : Set], but you don't have [2 : Set] for instance [Wed Oct 7 09:29:04 2015] I see. [Wed Oct 7 09:31:51 2015] what's the best tactic for solving something alike: http://lpaste.net/142473? [Wed Oct 7 09:32:34 2015] destruct m. [Wed Oct 7 09:34:08 2015] thanks [Thu Oct 8 08:49:31 2015] Hello people, I have to write an inductive relation on postfix lists, I did the following: http://lpaste.net/142573 [Thu Oct 8 08:51:02 2015] I don't know if that's OK, as I've been stuck in the proof of the lemma and I couldn't continue [Thu Oct 8 08:55:59 2015] Oh I see what you did wrong here [Thu Oct 8 08:56:41 2015] A rule of thumb is, when you do induction, you want an inductive hypothesis as generalize as possible, so you want l2 l3 on the forall stack [Thu Oct 8 08:57:05 2015] So just remove the intro, you will go further] [Thu Oct 8 09:01:50 2015] thanks lolisa , let me try it out ! [Thu Oct 8 09:03:38 2015] * meow [Thu Oct 8 09:04:19 2015] Also, when you want to put something back on the forall stack, use generalize dependent n. or revert n m p as much number of ident as you like. [Thu Oct 8 09:06:58 2015] lolisa, I just updated the paste http://lpaste.net/142573 with your suggestions, the thing is I get the same result [Thu Oct 8 09:13:59 2015] Yeah, but now youe IHl1 get better - now it is more generalized [Thu Oct 8 09:14:49 2015] maybe you should try subst; eapply IHl1. [Thu Oct 8 09:21:45 2015] Oh you need to apply postfixL [Thu Oct 8 09:23:49 2015] I already solved it: http://lpaste.net/142573 [Thu Oct 8 09:24:02 2015] but I needed to define a helper lemma [Thu Oct 8 09:24:27 2015] Idk whether or not that's a good resolution [Thu Oct 8 09:25:53 2015] Good :) BTW you might like to have a look at list at standard library (Require Import List [Thu Oct 8 09:28:13 2015] lolisa thanks :) [Thu Oct 8 09:28:38 2015] but it's for a course homework, so we are playing a bit with inductive definitions [Thu Oct 8 09:29:00 2015] I'll try it though! [Fri Oct 9 10:42:41 2015] kini: I forgot what you were working on. Remind me? [Fri Oct 9 11:47:01 2015] Hi, I have started learning coq today (using https://www.cis.upenn.edu/~bcpierce/sf/current/index.html) and have a couple of questions [Fri Oct 9 11:47:19 2015] I have seen you can use the hypothesis in a proof by typing H [Fri Oct 9 11:47:56 2015] is there another letter (or something) to use a sub-hypothesis? [Fri Oct 9 11:47:57 2015] for instance [Fri Oct 9 11:48:06 2015] if I want to proof that A -> B -> C [Fri Oct 9 11:48:14 2015] H = A [Fri Oct 9 11:48:46 2015] And I am looking for something like SubH = B [Fri Oct 9 11:50:28 2015] Let's say your current goal is indeed [A -> B -> C]. When you use the tactic [intros H.], it will give you as a hypothesis [H : A], which is to say : the variable H has type A. [Fri Oct 9 11:50:41 2015] and then you have to prove [B -> C], with this variable H in your environment [Fri Oct 9 11:51:14 2015] However, the name H is arbitrary, you could have writtent instead [intros SomethingElse.], and it would have given you the hypothesis [SomethingElse : A] [Fri Oct 9 11:51:53 2015] So, starting from the goal [B -> C], you can do [intros SubH] if you want to bring the hypothesis [SubH : B] in your context. [Fri Oct 9 11:52:23 2015] (Note that I'm writing [H : A] and not [H = A], because you are actually bringing in your context something _of type_ A, not something equal to A) [Fri Oct 9 11:57:11 2015] thanks! [Fri Oct 9 11:58:33 2015] I was stuck at a proof and now I have finished it :) [Fri Oct 9 14:50:16 2015] Which tactic can I use to get to a goal from a contradiction? [Fri Oct 9 14:56:07 2015] inversion ? [Fri Oct 9 14:57:24 2015] I have the goal false <> true [Fri Oct 9 14:57:28 2015] but I don't know how to prove it [Fri Oct 9 14:58:27 2015] this goal is not a contradiction [Fri Oct 9 14:58:30 2015] simpl. [Fri Oct 9 14:58:51 2015] oh, no [Fri Oct 9 14:59:00 2015] right ;) [Fri Oct 9 14:59:15 2015] unfold not; intro H; inversion H. [Fri Oct 9 14:59:29 2015] let's see [Fri Oct 9 15:00:13 2015] it works :) [Fri Oct 9 15:00:25 2015] now I will have to understand it [Fri Oct 9 15:00:27 2015] :p [Fri Oct 9 15:02:19 2015] first, `unfold not` transforms the goal in `false = true -> False` [Fri Oct 9 15:02:34 2015] then `intro H` introduces an hypothesis `false = true`, named H [Fri Oct 9 15:02:52 2015] then `inversion H` concludes because the assumption `false = true` is absurd [Fri Oct 9 15:03:39 2015] so you can use inversion to take any conclusion from false = true? [Fri Oct 9 15:03:51 2015] does it have other uses besides that? The docs say there are many forms of inversion [Fri Oct 9 15:04:55 2015] if you have false = true in your context, then discriminate will always solve the goal [Fri Oct 9 15:04:58 2015] in general it deconstructs inductive types in hypothesis, I think [Fri Oct 9 15:05:36 2015] hmmm... too much alternatives for a beginner [Fri Oct 9 15:05:39 2015] I will have to read more [Fri Oct 9 15:05:42 2015] thanks! [Fri Oct 9 15:10:44 2015] the number of alternatives is truly daunting as a beginner [Fri Oct 9 15:10:55 2015] I remember thinking I'd never, ever understand them all, or when to use which [Fri Oct 9 15:11:15 2015] fortunately, you can get pretty far knowing only a subset twlel [Fri Oct 9 15:11:17 2015] well [Sat Oct 10 09:47:10 2015] Is there a standard proof that (S n) = (S m) -> n = m? [Sat Oct 10 09:48:15 2015] injectivity H. [Sat Oct 10 09:49:49 2015] do I need to import a module in order to use that? [Sat Oct 10 09:50:13 2015] no I don't think so [Sat Oct 10 09:51:16 2015] I get this: Error: The reference injectivity was not found in the current environment. [Sat Oct 10 09:52:52 2015] can I see the code ? [Sat Oct 10 09:53:51 2015] I am working through the book of Pierce [Sat Oct 10 09:54:04 2015] shall I paste it on a GitHub gist? [Sat Oct 10 09:54:14 2015] in a proof, you should be able to use the tactic injectivity [Sat Oct 10 09:56:01 2015] This is it: https://gist.github.com/aochagavia/7b9e62e2853d0f34a5d3 [Sat Oct 10 09:57:12 2015] the syntax is injectivity [Sat Oct 10 09:58:44 2015] ok, thanks! [Sat Oct 10 10:00:25 2015] * it looks like the tactic is called injection [Sat Oct 10 10:03:28 2015] oh yeah [Sat Oct 10 10:03:35 2015] close enough sorry [Sat Oct 10 10:06:30 2015] ;) [Sat Oct 10 10:33:48 2015] I want to use list concatenation (++) but I keep gettin "Error: Unknown interpretation for notation "_ ++ _"." [Sat Oct 10 10:33:58 2015] any ideas? [Sat Oct 10 10:35:30 2015] solved using Local Open Scope list_scope. [Sat Oct 10 11:17:29 2015] what is the syntax used to write a function that requires that some property holds? [Sat Oct 10 11:17:59 2015] for instance (A -> B), only if P(A) [Sat Oct 10 11:18:26 2015] You can use dependent sums: {x : A | P x} -> B [Sat Oct 10 11:19:04 2015] See the type sig [Sat Oct 10 11:19:52 2015] thanks! [Sat Oct 10 11:35:41 2015] is there any straightforward way to use sig with a tuple? [Sat Oct 10 11:36:06 2015] something like { (x : A) (y : B) | P x y } [Sun Oct 11 08:46:19 2015] hey guys, I'm having trouble proving that strong antisymmetry -> antireflexivity ... I can do it on paper, but in Coq I end up being stuck at this point http://i.imgur.com/MgeM31E.png ... it seems there should be an obvious contradiction, but I can't figure out how to do it https://gist.github.com/darthdeus/df7850132764fef32c6d [Sun Oct 11 08:46:35 2015] trying contradict H or H0 doesn't seem to lead anywhere [Sun Oct 11 08:46:59 2015] I mean, I somehow need to say that H0 contradicts H [Sun Oct 11 08:47:11 2015] and somehow imply that b=a in that case [Sun Oct 11 08:47:29 2015] darthdeus: hint: "H0 contradicts H" it doesn't [Sun Oct 11 08:48:02 2015] because a is one thing and b could potentially be something else [Sun Oct 11 08:48:11 2015] dramforever: but if "R a a" is true, then for H I'd get "R a a -> ~ R a a" [Sun Oct 11 08:48:28 2015] no you don't =) [Sun Oct 11 08:48:38 2015] R a a by no means imply R a b [Sun Oct 11 08:48:46 2015] hmm [Sun Oct 11 08:48:52 2015] but R a a doesn't work in H [Sun Oct 11 08:49:01 2015] exactly [Sun Oct 11 08:49:21 2015] then H and H0 can't be true at the same time [Sun Oct 11 08:49:48 2015] uh wait by "R a a doesn't work in H" you mean they contradict? then no [Sun Oct 11 08:49:55 2015] like 1 = 1 doesn't mean 1 = 2 [Sun Oct 11 08:50:09 2015] hmm [Sun Oct 11 08:50:51 2015] I commented on your gist, I didn't check, I don't have coq here [Sun Oct 11 08:52:15 2015] def`: thanks, I'll check it out [Sun Oct 11 08:57:27 2015] hmm interesting, it's much simpler to prove with the different forall placement :) [Sun Oct 11 08:57:30 2015] Just curious: what do you use coq for? fun? work? university course? [Sun Oct 11 08:57:52 2015] dramforever: I'm taking a basic algebra course, and had to do some proofs for assignment, and thought I'd try to do them in coq [Sun Oct 11 08:58:07 2015] so "fun" I guess [Sun Oct 11 08:58:09 2015] yeah [Sun Oct 11 08:58:53 2015] thought it might help me adding a bit of rigor to my proofs [Sun Oct 11 08:58:59 2015] instead of just trying to wing it [Sun Oct 11 08:59:30 2015] darthdeus: Now you can try to prove that your previous theorem was wrong :) [Sun Oct 11 08:59:40 2015] (assume it, prove False) [Sun Oct 11 09:02:10 2015] darthdeus: tip: you could use generalize dependent to put back into a forall. [Sun Oct 11 09:04:56 2015] def`: you mean taking just the "forall a b: A, (R a b -> not (R b a)) -> not (R a a)" and proving False from that? :O [Sun Oct 11 09:07:28 2015] dramforever: in what case would I want to generalize it again thuogh? maybe for applying an existing more general theorem? [Sun Oct 11 09:08:10 2015] yep, or doing induction. (pun warning) generally when you need something more general [Sun Oct 11 09:08:21 2015] hehe [Sun Oct 11 09:18:15 2015] darthdeus: Theorem foo: ~(forall A : Type, forall R : A -> A -> Prop, (forall a b: A, (R a b -> not (R b a)) -> not (R a a))). [Sun Oct 11 09:19:07 2015] You have to generalize a bit to prove it was wrong. "for an arbitrary relation" it is false [Sun Oct 11 09:19:24 2015] Then you just have to find one relation for which it is wrong. [Sun Oct 11 09:22:33 2015] hmm, interesting, I'll give it a try, thanks! [Sun Oct 11 10:33:03 2015] Has anyone heard of jobs using Coq? [Sun Oct 11 10:47:19 2015] Big_G: subscribe to the mailing list [Sun Oct 11 17:54:42 2015] Hi people, I have to define the inductive relation `isSet` using the following: http://lpaste.net/142790 [Sun Oct 11 17:55:29 2015] Could anyone help me to do it? I don't know how to write `isSetCons` properly [Sun Oct 11 17:55:42 2015] I have to use what is there [Sun Oct 11 17:57:43 2015] For [consL x l] to be a set, you need the fact that x is not in l. So you need [~ MemL x l]. [Sun Oct 11 17:58:58 2015] Cypi thanks, I wrote that but just guessing it, I don't understand what MemL tells me, though [Sun Oct 11 18:00:29 2015] [MemL x l] expresses "x is in l" [Sun Oct 11 18:02:09 2015] Cypi Oh, I got it. Now I understand what the second constructor does [Sun Oct 11 18:02:12 2015] thanks!! [Sun Oct 11 19:11:11 2015] Hi guys, I don't know how to keep going with this proof : http://lpaste.net/142790 [Sun Oct 11 19:11:17 2015] any hint? [Sun Oct 11 23:54:06 2015] gallina is strong enough to simulate any guaranteed-halting turing machine right [Mon Oct 12 00:01:44 2015] guaranteed-halting? [Mon Oct 12 00:03:01 2015] er, specific guaranteed-halting programs on a turing machine [Mon Oct 12 00:03:04 2015] bleh [Mon Oct 12 00:03:17 2015] i think i went too specific without thinking about what i was specifying :) [Mon Oct 12 00:03:36 2015] really what i'm asking is. anything that you can do in a turing complete language which will always halt can be done in gallina, right? [Mon Oct 12 00:04:35 2015] and the extra power you get from turing completeness is simply that it becomes possible to write functions that are not well-defined in general but make sense on some non-decidable part of their domain [Mon Oct 12 00:13:05 2015] benzrf: I think no, since the set of gallina programs is decidable and the set of programs that terminate for all of their inputs is not. [Mon Oct 12 00:13:26 2015] o [Mon Oct 12 00:13:54 2015] mea-culpa: could they be equivalent, but not constructively so? [Mon Oct 12 00:15:12 2015] oh, I'm saying foolish things. Don't pay attention to them please. *Since the language codes the programs which always terminate [Mon Oct 12 00:16:29 2015] benzrf: I mean there is a program which cannot be described by Gallina and which always terminates. [Mon Oct 12 00:17:29 2015] how do u know? [Mon Oct 12 00:20:47 2015] Hmm, maybe I'm wrong... [Mon Oct 12 02:33:10 2015] benzrf: termination of some programs is undecidable [Mon Oct 12 02:33:17 2015] therefore you cannot write those programs in Coq [Mon Oct 12 02:33:32 2015] because Coq asks for a termination proof, so I agree with mea-culpa [Mon Oct 12 08:07:25 2015] is there some tactic that automatically can convert a proposition about N or Z into a proposition about nat? [Mon Oct 12 08:10:00 2015] ah. omega can. nice. [Mon Oct 12 08:13:09 2015] benzrf: there's always a way to describe them, even when they do not terminate, for those that do the termination proof might be arbitrarily large, and for some programs you won't be able to do the termination proof for goedelian reasons [Mon Oct 12 08:15:19 2015] companion_cube: interesting [Mon Oct 12 08:15:26 2015] ok [Mon Oct 12 08:16:57 2015] companion_cube: what's a program for which termination is undecidable? [Mon Oct 12 08:18:47 2015] hmm [Mon Oct 12 08:19:00 2015] hold on so [Mon Oct 12 08:19:17 2015] alright nvm [Mon Oct 12 08:19:37 2015] Saizan: perhaps something whose termination hinges on a constructively unprovable fact? [Mon Oct 12 08:21:30 2015] benzrf: could be [Mon Oct 12 08:21:33 2015] * asks ##math [Mon Oct 12 08:22:28 2015] wait. im stupid [Mon Oct 12 08:22:30 2015] omg [Mon Oct 12 08:22:48 2015] any halting program can be shown to halt simply by enumerating its states [Mon Oct 12 08:24:44 2015] that tells you that halting is semi-decidable [Mon Oct 12 08:25:44 2015] benzrf : take the program that takes a program as an argument and executes it. Its termination is undecidable [Mon Oct 12 08:25:53 2015] (ok, you might find that this is a cheat :p ) [Mon Oct 12 08:26:04 2015] 08:25 oh, well, i was assuming a self-contained program [Mon Oct 12 08:26:06 2015] 08:25 benzrf: given by a Turing machine? [Mon Oct 12 08:26:08 2015] 08:25 i suppose saying 'this function terminates on all inputs' cannot be done that way [Mon Oct 12 08:26:10 2015] 08:25 'self-contained' meaning that theres a single initial state that you proceed from, not something parameterized [Mon Oct 12 08:26:12 2015] hm [Mon Oct 12 08:40:40 2015] Saizan: an evaluator [Mon Oct 12 08:40:45 2015] I guess [Mon Oct 12 08:41:02 2015] for a non terminating language, applied to some program [Mon Oct 12 08:41:20 2015] knowing if it will terminate on some input depends on the program, and reduces to the halting problem [Mon Oct 12 08:50:44 2015] i mean, undecidable in the sense of the halting problem cannot really be applied to a single program [Mon Oct 12 08:51:46 2015] but fair enough [Mon Oct 12 08:54:10 2015] Saizan: eval : program -> input -> output [Mon Oct 12 08:54:20 2015] now you apply partially (eval p) to some program [Mon Oct 12 08:54:36 2015] I think the termination of this particular function is undecidable (but it can be terminating) [Mon Oct 12 08:54:44 2015] (unlike eval itself which is clearly non terminating) [Mon Oct 12 23:18:52 2015] has anyone ever run into rewrite being too smart? it's rewriting by additional hypotheses without me asking for it. at the very least, this appears to be undocumented. http://lpaste.net/142887 [Tue Oct 13 12:02:19 2015] Hi guys, I don't know how to keep going with this proof : http://lpaste.net/142790 [Tue Oct 13 12:02:20 2015] any hint? [Tue Oct 13 12:19:31 2015] you can use `destruct (equal x a) eqn:xa_equal` to get an equation that knows in which branch you are [Tue Oct 13 12:21:10 2015] which means you get an assumption (equal x a = false) at the point where you're stuck [Tue Oct 13 12:38:34 2015] irishsultan thanks for your help, but I don't get it :( [Tue Oct 13 12:39:08 2015] also, it didn't work [Tue Oct 13 12:41:08 2015] pumita: you changed the line [destruct (equal x a)] to [destruct (equal x a) eqn:Hxa] and then what didn't work? [Tue Oct 13 12:41:48 2015] it throws me this: Syntax error: '.' or '...' expected after [tactic:tactic] (in [subgoal_command]). [Tue Oct 13 12:43:57 2015] jrw maybe I'm using an old version [Tue Oct 13 12:44:13 2015] pumita: what version are you using? [Tue Oct 13 12:44:48 2015] 8.3pl4 [Tue Oct 13 12:46:39 2015] I've never used 8.3, so I don't know off the top of my head whether eqn: works [Tue Oct 13 12:47:02 2015] one thing would be to explicitly introduce the equality [Tue Oct 13 12:47:25 2015] something like `cut (equal x a)` ? [Tue Oct 13 12:47:34 2015] something like [remember (equal x a) as y] followed by [destruct y] [Tue Oct 13 12:48:52 2015] jrw let me try it out, thanks! [Tue Oct 13 14:39:51 2015] if i can prove ~P -> ~Q constructively in a way that involves induction, what can i say about reverse engineering a proof of Q -> P? [Tue Oct 13 14:45:46 2015] benzrf: well if you start your proof of [~P -> ~Q] by changing the goal to [Q -> P] and then proceeding by induction, then there's nothing to say. [Tue Oct 13 15:40:27 2015] Ccan the proof in http://lpaste.net/142790 be improved a little? Thanks! [Tue Oct 13 15:55:17 2015] jrw: :p [Tue Oct 13 15:55:53 2015] jrw: well to be more precise, i recently spent some time trying to figure out a version of heine-borel that isnt by contradiction [Tue Oct 13 16:31:52 2015] benzrf: on paper or in coq? [Tue Oct 13 16:32:20 2015] either, reall [Tue Oct 13 16:32:22 2015] *really [Tue Oct 13 16:43:50 2015] benzrf: well if you're interested in constructive analysis, I recommend bishop's "foundations of constructive analysis" [Tue Oct 13 16:44:05 2015] that sounds like pain [Tue Oct 13 16:44:14 2015] :) [Tue Oct 13 16:44:26 2015] :D [Tue Oct 13 16:44:44 2015] although I believe the usual approach is to *define* compactness (on metric spaces) as "complete and totally bounded" [Tue Oct 13 16:45:18 2015] jrw: constructive analysis doesn't use an algebra of infinitesimals, does it? [Tue Oct 13 16:45:35 2015] ianjneu: I don't know what that is :) [Tue Oct 13 16:46:01 2015] well to be precise [Tue Oct 13 16:46:10 2015] i was analyzing why contradiction was necessary in the proof they used [Tue Oct 13 16:46:20 2015] and it seemed to be an induction thing [Tue Oct 13 16:46:21 2015] i dunno [Tue Oct 13 16:46:47 2015] jrw: ACL2(r)'s formalization of real numbers uses a "non-standard" real analysis. Although ACL2 is not a constructive logic, many uses of it is constructive. [Tue Oct 13 16:47:57 2015] interesting. yeah, I think bishop takes a different approach, not using infintesimals [Tue Oct 13 17:01:06 2015] is there a not for bool inductive type? [Tue Oct 13 17:01:38 2015] pumita: yes I think it's called negb [Tue Oct 13 17:01:56 2015] thanks! [Tue Oct 13 18:14:16 2015] Hi, I have to define the following grammar: http://lpaste.net/142964 [Tue Oct 13 18:14:28 2015] Do I have to write a constructor for every case? [Tue Oct 13 18:20:21 2015] Is this correct? http://lpaste.net/142964 [Tue Oct 13 18:30:13 2015] pumita: looks good [Tue Oct 13 18:30:45 2015] jrw :) [Tue Oct 13 20:20:37 2015] is there a visual coq? [Tue Oct 13 20:40:21 2015] QF-MichaelK: you might like to check out http://goto.ucsd.edu/peacoq/ [Tue Oct 13 20:40:50 2015] it's still early stage, and I'm not sure it's exactly what you're looking for, but I have found it helps to teach beginners. [Tue Oct 13 21:25:51 2015] Hi guys, I'm struggling a bit with this last proof: http://lpaste.net/142964 [Tue Oct 13 21:26:03 2015] any hint? thanks [Tue Oct 13 21:26:51 2015] do I have to consider all the cases? [Tue Oct 13 22:04:19 2015] pumita: I think this will be hard to prove directly by induction. [Tue Oct 13 22:04:35 2015] I believe it follows from the fact that the evaluator is deterministic [Tue Oct 13 22:04:40 2015] which should be provable by induction [Tue Oct 13 22:06:32 2015] Could you explain it? I'm trying it through inversion in H, and I'm about three cases to finish it :P [Tue Oct 13 22:08:10 2015] here it is: http://lpaste.net/142964 [Tue Oct 13 22:08:56 2015] I guess the proof is getting a bit long... [Tue Oct 13 22:11:35 2015] pumita: sorry I can't look at it right now :\ I might be able to take a look later [Tue Oct 13 22:11:57 2015] jrw no problem at all ! :) [Tue Oct 13 22:12:01 2015] thanks! [Tue Oct 13 22:42:46 2015] pumita: okay looked at it briefly, I think this approach will not work. you haven't even finished the first top-level subgoal yet. [Tue Oct 13 22:53:16 2015] jrw okay, what would you suggest me then? [Tue Oct 13 22:53:30 2015] I would prove that evaluation is deterministic. [Tue Oct 13 22:53:38 2015] your result follows from that. [Tue Oct 13 22:54:09 2015] I think I don't get how to prove determinism there :/ [Wed Oct 14 03:55:36 2015] I have `f h :: map f t`, how can I fold that into `map f (h :: t)`? I am trying (fold map) but it doesn't work. [Wed Oct 14 04:00:11 2015] aochagavia: you will likely have to do it explicitly. something like [change (f h :: map f t) with (map f (h :: t)).] [Wed Oct 14 04:01:26 2015] is change a tactic? [Wed Oct 14 04:01:54 2015] hmmm I see it in the docs [Wed Oct 14 04:01:56 2015] thanks! [Wed Oct 14 04:14:12 2015] aochagavia: change is like replace except that it requires the equality to be provable by reflexivity [Wed Oct 14 04:20:09 2015] nice [Wed Oct 14 05:06:15 2015] jrw: O [Wed Oct 14 05:06:30 2015] I'm thinking of coq + some visual language, particularly scratch [Wed Oct 14 05:07:27 2015] So that people can learn without as much for syntax issues [Wed Oct 14 10:13:19 2015] is there any recommended way of doing file-i/o with coq? so far I always used lazy lists, and wrote the glue in the extracted language (haskell mostly) [Wed Oct 14 10:29:07 2015] schoppenhauer: i think most axiomatize an i/o monad and then write the instance in ocaml. think lazy i/o tends to be frowned upon because it makes an effectful computation look pure [Wed Oct 14 10:29:57 2015] rmk0: well, I write something that reads stdin and writes to stdout. I wouldn't call that "effectful". [Wed Oct 14 10:30:39 2015] rmk0: it explicitly processes a stream. [Wed Oct 14 10:31:14 2015] i think we could debate this all day [Wed Oct 14 10:31:38 2015] ok. hm. but IO monad sounds complicated. [Wed Oct 14 10:37:26 2015] rmk0: the problem is, I need *some* possibility to reason about the output, which is streamed. when writing a lazy list, I can directly reason about that lazy list. all things about IO monads I found so far make this kind of reasoning extremely hard. [Wed Oct 14 10:38:01 2015] http://coq.io/getting_started.html [Wed Oct 14 10:38:18 2015] that seems to have appeared recently... it's basically an i/o monad [Wed Oct 14 10:40:53 2015] Hello! how do I define mutually recursive inductive types? [Wed Oct 14 10:40:55 2015] this looks nice [Wed Oct 14 10:42:00 2015] pumita : [Inductive foo := C : bar -> foo with bar := D : foo -> bar.] for instance. [Wed Oct 14 10:42:23 2015] (those types are empty, but that's just an example) [Wed Oct 14 10:42:40 2015] Cypi thanks, I had forgotten with :) [Wed Oct 14 10:46:10 2015] this IO system looks great [Wed Oct 14 10:51:25 2015] companion_cube, rmk0: I wonder ... there is only one function to read from a file. and it reads the whole file into a string. [Wed Oct 14 10:51:51 2015] as far as I can tell (because the code is scattered) [Wed Oct 14 10:52:28 2015] https://coq-io.github.io/doc/system/2.3.0/Io.System.System.html indeed [Wed Oct 14 10:52:36 2015] this is *definitely* worse than doing it lazily. [Wed Oct 14 10:52:42 2015] when you want to be able to stream. [Wed Oct 14 10:52:44 2015] but it shouldn't be too hard to add bindings to Lwt [Wed Oct 14 10:52:50 2015] I mean bindings to more Lwt functions [Wed Oct 14 10:53:13 2015] yes, but then you again have the problem: you cannot talk about the contend of the file. [Wed Oct 14 10:53:19 2015] and the content of the output file. [Wed Oct 14 10:53:41 2015] because it is not "there" before you finished your computation. [Wed Oct 14 10:54:12 2015] I suppose the haskell community has interesting things for pure IO [Wed Oct 14 10:54:28 2015] iteratees, etc. might make it possible to reason in a pure way about streams of data [Wed Oct 14 10:55:23 2015] i think because lazy i/o looks pure, you are not reasoning about what you think you're reasoning about [Wed Oct 14 10:55:38 2015] oleg is colourful on the subject: http://okmij.org/ftp/Haskell/#lazyIO-not-True [Wed Oct 14 10:55:49 2015] I wasn't thinking about lazy IO [Wed Oct 14 10:55:54 2015] but iteratees [Wed Oct 14 10:56:05 2015] yeah, iteratees were oleg's solution to the problem! [Wed Oct 14 10:57:50 2015] http://okmij.org/ftp/Streams.html#iteratee [Wed Oct 14 11:04:23 2015] In a proof, I have `a = b`. How can I rewrite that into `f a = f b`? [Wed Oct 14 11:05:48 2015] I found information about f_equal, but I am not sure about how to use it here [Wed Oct 14 11:06:31 2015] If you haveIf you have the hypothesis [H : a = b], then you can do [apply (f_equal f) in H] [Wed Oct 14 11:06:42 2015] it will replace it with [H : f a = f b] [Wed Oct 14 11:07:25 2015] well, it would be nice to have uniqueness types :\ [Wed Oct 14 11:08:35 2015] interesting [Wed Oct 14 11:09:16 2015] awesome, thanks! [Wed Oct 14 11:18:35 2015] rmk0: hm. before I try to understand them entierly … do you think it is easier to formalize iteratees in coq, than IO monads? [Wed Oct 14 11:19:31 2015] i think doing a basic i/o monad is easier, but how you do it probably has a bearing on how much you can reason about it [Wed Oct 14 11:20:06 2015] well, in the end, it is really just an algorithm that reads stdin and writes stdout. [Wed Oct 14 11:20:36 2015] in "further work" I want to re-implement it with VST anyway. [Wed Oct 14 11:21:19 2015] and I have a property "the input list ... corresponds to the output list ..." [Wed Oct 14 11:25:23 2015] Not sure whether one can reason about the content of a file on the whole. [Wed Oct 14 11:26:04 2015] My experience sais that it is... Hard in any case. [Wed Oct 14 12:51:46 2015] pumita: btw, I looked at your eval thing again, see http://lpaste.net/142995 [Wed Oct 14 14:21:56 2015] if I say "exists x, ...", then this x will not be computational, right? that is, in extracted code, it will not be calculated? [Wed Oct 14 14:44:43 2015] schoppenhauer : yup, that will be erased completely [Wed Oct 14 14:47:41 2015] ++ thx [Wed Oct 14 16:13:41 2015] is there anything decent in the stdlib for reasoning about lists [Wed Oct 14 16:13:55 2015] including things like how folds distribute over ++ [Wed Oct 14 16:56:18 2015] and for example that 'sorted under this total order' is a unique property [Wed Oct 14 16:56:27 2015] more pressingly does omega work on rationals [Wed Oct 14 19:55:25 2015] benzrf: you probably want the [field] tactic [Wed Oct 14 19:56:25 2015] asf [Fri Oct 16 17:27:12 2015] next time someone tries to learn ssr and mathcomp you point them at https://hal.inria.fr/hal-00825074/. you point them at that and tell them they just dodged a bullet. [Fri Oct 16 17:43:04 2015] sanooj: how does this show that theyre bad? [Fri Oct 16 17:43:27 2015] also unrelated question: how long have proof assistants been around for? [Fri Oct 16 17:45:16 2015] benzrf: ever since that guy who used to go fetch wine for Euclid [Fri Oct 16 17:45:22 2015] ha [Fri Oct 16 17:45:27 2015] https://en.wikipedia.org/wiki/Logic_for_Computable_Functions [Fri Oct 16 17:45:28 2015] srsly tho [Fri Oct 16 17:45:42 2015] at least 1972 [Fri Oct 16 17:45:44 2015] grah [Fri Oct 16 17:45:55 2015] but I think there was one earlier,by De Bruijn ("automath"?) [Fri Oct 16 17:46:06 2015] i was thinking about the sad state of computer proving in general [Fri Oct 16 17:46:53 2015] and hoping that the problems are eventually tractable & the current clunkiness is just a matter of immaturity of the field [Fri Oct 16 17:46:55 2015] :I [Fri Oct 16 17:47:15 2015] well it's a small area of research, and it's very difficult [Fri Oct 16 17:47:21 2015] ;-; [Fri Oct 16 17:47:34 2015] benzrf's wishlist: [Fri Oct 16 17:48:31 2015] benzrf: ssr and mathcomp are very difficult to get into based on just reading the source. [Fri Oct 16 17:50:04 2015] - get a hundred billion dollars to pour into setting up a collaborative long term research organization involving mathematicians and computer scientists and linguists and stuff to FUCKING FIGURE OUT how it is that humans are able to intuitively reason about mathematical objects so that we can build something nonshit out of it [Fri Oct 16 17:50:08 2015] * dreams [Fri Oct 16 17:50:30 2015] there are lots of papers about individual components, tutorials and manuals of course, but this was the first that gives an appropriate birds eye view. [Fri Oct 16 17:50:34 2015] benzrf: this kind of exists already [Fri Oct 16 17:50:44 2015] sanooj: thanks for that link [Fri Oct 16 17:50:48 2015] johnw: yeah? [Fri Oct 16 17:51:14 2015] academia + DARPA + INRIA + NICTA + etc. [Fri Oct 16 17:51:32 2015] those arent hundred billion dollar projects t h o [Fri Oct 16 17:51:47 2015] over time they are [Fri Oct 16 17:52:15 2015] wot about involvement of ppl versed in How Humans Think as opposed to just ppl versed in the practice of thinking [Fri Oct 16 17:52:49 2015] benzrf: would your dream tool check proofs rigorously? [Fri Oct 16 17:53:11 2015] yes [Fri Oct 16 17:53:15 2015] sorry i may have been unclear [Fri Oct 16 17:53:31 2015] I feel like a lot of the coq proofs I've seen, and ssr in particular, could do more to be understandable by humans as well as puters. [Fri Oct 16 17:53:52 2015] because the usual mathematician-level proof doesn't specify the details that are required for checking [Fri Oct 16 17:53:57 2015] I think some humans could do more to be understandable by humans [Fri Oct 16 17:54:10 2015] so either your tool would infer the missing steps, or it couldn't check properly proofs [Fri Oct 16 17:54:10 2015] i meant, in particular, an interface-to-a-formal-system like in coq, but with a really fucking well designed interface that matches how human thought works much better [Fri Oct 16 17:54:31 2015] yeah, some money could be well used improving the UI of coq [Fri Oct 16 17:54:32 2015] obviously many many proofs in textbooks are still insufficiently rigorous for any kind of non-sentient program, but [Fri Oct 16 17:54:52 2015] I read a lot of code. a lot of shit code, some really nice code, and then I met interactive proofs. [Fri Oct 16 17:54:53 2015] there are a lot of non-reducing-to-hard-ai problems like heuristic search for lemmas that plug gaps [Fri Oct 16 17:55:44 2015] and finding formal abstractions that are higher level than the existing ones [Fri Oct 16 17:56:06 2015] like, the way humans think about something as commonplace as /lists/, is clearly much much much much much higher level than anything ive seen in coq [Fri Oct 16 17:56:50 2015] you can say something like "procedure X will reduce the incidences of subsequence Y by at least 1 and wont introduce any, so a finite number of iterations will remove all instances of Y" [Fri Oct 16 17:57:01 2015] this is not something that is anywhere near easy to say in coq [Fri Oct 16 17:57:18 2015] but i think its entirely possible to find formal abstractions that make it almost as easy [Fri Oct 16 17:57:22 2015] g2g, bbl [Fri Oct 16 19:35:36 2015] johnw: also, the quotients in mathcomp are apparently based on this: http://perso.crans.org/cohen/papers/quotients.pdf [Sat Oct 17 02:53:14 2015] Something that puzzles me about well-founded induction, as defined in the standard library... [Sat Oct 17 02:53:14 2015] The accessibility relation Acc is defined in Prop, yet Coq generates Acc_rect, and Acc_rect appears to perform elimination from Acc (in Prop) to (P x) which is in Type. I thought that was not allowed. [Sat Oct 17 02:53:14 2015] Usually, when I define an Inductive Foo (...params...) : (...indicies...) -> Prop := ..., I only get Foo_ind, and if I try to define Foo_rect, I get the "incorrect elimination" error. That's what I would have expected for Acc. [Sat Oct 17 02:53:14 2015] What am I missing about the restriction on elimination from Prop to Set/Type? [Sat Oct 17 02:54:38 2015] https://github.com/coq/coq/blob/trunk/theories/Init/Wf.v#L51 [Sat Oct 17 04:42:43 2015] mbrcknl: RecTutorial.pdf says of _rect in a footnote that "whenever possible, Coq generates the weaker principle I_rect, then derives from it the weaker principles I_ind and I_rec." [Sat Oct 17 04:45:14 2015] what does the comment about Acc_rect being generated because it is a singleton type actually mean? [Sat Oct 17 04:47:14 2015] If there is only one constructor, you can still derive an elimination principle in Type [Sat Oct 17 04:51:36 2015] I honestly don't mean to regress back to 5yo, "but why?" :-D [Sat Oct 17 04:53:28 2015] I would have added a reason if I were sure I know it ^^' . But my guess would be: if there is only one constructor, then you don't need to perform an actual elimination to know the shape of your term, since it can only be an application of that constructor. [Sat Oct 17 04:53:33 2015] Something along those lines [Sat Oct 17 04:54:21 2015] fair enough. [Sat Oct 17 04:56:45 2015] Ah. There are additionnal restrictions actually. [Sat Oct 17 04:56:57 2015] Every argument of the constructor needs to be in Prop, apparently [Sat Oct 17 05:00:03 2015] where is this in the code? [Sat Oct 17 05:01:18 2015] or rather, where did you get that from? [Sat Oct 17 05:01:59 2015] There is a comment about in https://github.com/coq/coq/blob/trunk/kernel/indtypes.ml#L660 [Sat Oct 17 05:02:06 2015] but I got that from trying myself ^^' [Sat Oct 17 05:03:04 2015] If you define [Inductive I : Prop := C : True -> I.], then every sort of elimination is allowed, but not with [Inductive I : Prop := C : nat -> I.] [Sat Oct 17 05:04:09 2015] I'm going to have to eventually learn me some more type theory. [Sat Oct 17 05:05:32 2015] I guess the reason why the rooster and butterfly paper I linked to before felt so good was that it was in familiar language again. most of the time it seems like I'm going ass backwards up a tree. :) [Sat Oct 17 05:07:17 2015] granted, I'm only doing this on random nights when I have time, but still it's taking months and months. [Sat Oct 17 06:54:33 2015] Cypi sanooj: Thanks for your comments. This makes a little more sense now! [Sun Oct 18 08:32:08 2015] How do I temporarily move to a next subgoal? [Sun Oct 18 08:33:26 2015] Focus . https://coq.inria.fr/distrib/current/refman/Reference-Manual009.html#hevea_command208 [Sun Oct 18 09:08:02 2015] Thanks! [Sun Oct 18 14:39:38 2015] hey, what's https://github.com/math-comp/math-comp ? [Sun Oct 18 14:41:42 2015] the source directory structure is different from the mathcomp-1.5 I have, and it also includes ssr and feit thompson. my mathcomp-1.5 is for 8.4 from http://ssr.msr-inria.inria.fr/ [Sun Oct 18 15:32:49 2015] ah right, that's cyril cohen's repo. [Sun Oct 18 15:34:49 2015] or enrico tassi's. [Sun Oct 18 16:19:12 2015] why are d and r implicit arguments in mathcomp-1.5/theories/div.v:edivn_eq? [Sun Oct 18 19:11:40 2015] Do minor version updates to Coq break all existing proofs? Both the Feit-Thompson and four color theorems are failing to verify in Coq 8.4pl5; anyone had any luck with these? [Sun Oct 18 19:13:24 2015] haven't been around that long, but breakage seems to be common. [Sun Oct 18 19:20:33 2015] maybe theyre not true theorems anymore, havr you ever considered that [Sun Oct 18 19:43:55 2015] nice [Mon Oct 19 19:34:05 2015] someone remind me [Mon Oct 19 19:34:13 2015] oh, wait [Mon Oct 19 19:34:17 2015] .v is for 'vernacular', right? [Tue Oct 20 09:34:49 2015] if i have a goal of C x = C y, how can i shift the goal to x = y? [Tue Oct 20 09:36:07 2015] you can use f_equal [Tue Oct 20 09:36:27 2015] ahh nice [Tue Oct 20 09:36:30 2015] thanks :) [Tue Oct 20 18:25:47 2015] is there a way to get less computation done when i destruct [Tue Oct 20 18:25:58 2015] one of the cases has a term that's simplified a bit too far :x [Tue Oct 20 18:28:35 2015] Try case? Try simple destruct? Try writing your own term by hand, e.g., [refine (match ... with ... end).]? [Tue Oct 20 18:29:43 2015] simple destruct? [Wed Oct 21 15:54:35 2015] hi #coq [Wed Oct 21 15:55:10 2015] i heard that you can define functions that dont pass the coq termination checker, and then prove their totality as a standalone theorem [Wed Oct 21 15:55:17 2015] or something to that effect anyway [Wed Oct 21 15:55:23 2015] does anyone have any information on how to do this? [Wed Oct 21 16:00:01 2015] sunnymilk: sure [Wed Oct 21 16:00:24 2015] sunnymilk: if you use Program Fixpoint, and supply a measure, you'll be required to prove the decreasing nature of the measure before the function is defined. [Wed Oct 21 16:00:58 2015] i see! [Wed Oct 21 16:00:59 2015] another approach is to use a local fixpoint (let fix) that receives an argument of type Acc, and then prove the Accessibility of decreasing arguments [Wed Oct 21 16:01:20 2015] I use the measure approach quite frequently [Wed Oct 21 16:01:21 2015] is there some example code somewhere with either or both of those approaches? [Wed Oct 21 16:01:28 2015] of the former, I have one [Wed Oct 21 16:01:39 2015] for the latter, check Chilpala's book, one sec [Wed Oct 21 16:01:46 2015] http://adam.chlipala.net/cpdt/html/GeneralRec.html [Wed Oct 21 16:02:39 2015] here's the former: https://gist.github.com/a3fc227679ab02f82293 [Wed Oct 21 16:03:00 2015] i'm proving that grouping subsets from a list will eventually consider all elements of the list and terminate [Wed Oct 21 16:03:01 2015] thank you very much!!!! [Wed Oct 21 16:16:08 2015] i was wonder if you could do that in coq [Wed Oct 21 16:16:10 2015] nice [Fri Oct 23 06:22:52 2015] how do i use integers in coq [Fri Oct 23 06:23:13 2015] like, is there a library i can import, where i iwll get a Z type and have +, -, etc be integer operations? [Fri Oct 23 06:23:55 2015] theres ZArith but it doesnt give you nice infix notations [Fri Oct 23 06:32:55 2015] sunnymilk: Require ZArith and open the scope Z_scope. See here https://coq.inria.fr/refman/Reference-Manual005.html (search for Z_scope). [Fri Oct 23 06:33:45 2015] also you can do "Print Visibility" in coqtop (after opening Z_scope) to see exactly which notations are provided ... [Fri Oct 23 06:34:08 2015] (i gotta go, good luck) [Fri Oct 23 07:04:26 2015] ah! [Fri Oct 23 07:04:40 2015] thank you mysterious and flighty stranger [Fri Oct 23 07:12:31 2015] hm i get an error, Error: Scope Z_Scope is not declared. [Fri Oct 23 10:53:16 2015] sunnymilk: did you specify "Require Import ZArith."? because that's the form used in the reference manual [Fri Oct 23 10:54:54 2015] yeah, its Z_scope not Z_Scope [Fri Oct 23 10:55:06 2015] that was my problem [Sat Oct 24 18:04:36 2015] is Scott semantics same thing as denotational semantics? [Sat Oct 24 19:26:34 2015] Hi, I have the hypothesis: x = y -> False [Sat Oct 24 19:26:54 2015] how can I apply symmetry inside that hypothesis, to obtain: y = x -> False [Sat Oct 24 19:26:54 2015] ? [Sat Oct 24 19:28:11 2015] You could do something like [assert (y = x -> False) by (intro; apply H; symmetry; assumption).], if you have [H : x = y -> False] [Sat Oct 24 19:28:22 2015] I can't think of a more direct way right now [Sat Oct 24 19:28:57 2015] Cypi thanks! yeah, I was thinking in a more direct way :) [Sat Oct 24 19:35:54 2015] I'd say you can replace intro;apply... chain by congruence... Or just write a helper lemma [Sat Oct 24 19:42:32 2015] lolisa thanks :) [Sun Oct 25 04:15:08 2015] Hey all. Is it right that primitive recursion in Coq would be a sufficient recursion scheme. It's just inefficient? [Sun Oct 25 16:27:07 2015] chattered: I'm not sure what you mean? the only kind of recursion in coq is structural recursion on some inductive datatype. for the natural numbers, this corresponds roughly with the classical notion of primitive recursion, except that in a higher-order language like coq, you can actually write many more functions than are classically primitive recursive. for example, you can write the ackermann function in coq [Sun Oct 25 16:27:09 2015] but it's not primitive recursive in the classical sense. [Sun Oct 25 16:42:44 2015] jrw: For Ackermann, don't you have to find an appropritae well founded relation? [Sun Oct 25 16:43:07 2015] You can't just do it naively as you would in Ocaml. [Sun Oct 25 18:13:59 2015] Hi, I need some help with this proof: http://lpaste.net/143905 [Sun Oct 25 18:14:58 2015] I haven't understood well how to work in Coq with specifications and program extractions, is there a well article where I can read from? thanks [Sun Oct 25 18:38:43 2015] I could prove it :) [Tue Oct 27 12:43:51 2015] can I get some help with a basic proof? [Tue Oct 27 12:48:21 2015] sure [Tue Oct 27 12:50:49 2015] Lemma test : (forall x:A, exists y : B, R x y) -> exists y : B, forall x : A, R x y. [Tue Oct 27 12:51:08 2015] @johnw, thanks it's mainly the relation at the end (R x y) I don't understand how to go about. [Tue Oct 27 12:51:48 2015] I believe "auto" would solve that [Tue Oct 27 12:52:02 2015] since your goal matches the arguments [Tue Oct 27 12:52:04 2015] have to go about it manually :p [Tue Oct 27 12:52:18 2015] what is "R x y" named in your context? H? [Tue Oct 27 12:52:48 2015] R is a A->B->Prop [Tue Oct 27 12:53:01 2015] I mean, you should have something in your context of type "R x y" [Tue Oct 27 12:53:02 2015] but yeah the first thing I\ve put is intro H [Tue Oct 27 12:53:10 2015] so, it would be: exact (H x y). [Tue Oct 27 12:53:54 2015] sorry, when you refer to context are you talking inside the lemma [Tue Oct 27 12:54:03 2015] or where the variables are defined [Tue Oct 27 12:54:17 2015] everything "above the line" [Tue Oct 27 12:54:37 2015] oh right [Tue Oct 27 12:54:58 2015] okay [Tue Oct 27 12:55:06 2015] so I need to destruct the statement to get R x y on it's own [Tue Oct 27 12:55:34 2015] in your context right now there's a function [Tue Oct 27 12:55:44 2015] you just need to call that function to produce the evidence that will satisfy your goal [Tue Oct 27 12:56:14 2015] there's nothing in my context yet [Tue Oct 27 12:56:19 2015] besides the variables [Tue Oct 27 12:56:27 2015] theres' a function too [Tue Oct 27 12:56:34 2015] H : forall x:A, exists y : B, R x y [Tue Oct 27 12:56:46 2015] okay yeah [Tue Oct 27 12:57:21 2015] but I can't just apply it straight away [Tue Oct 27 12:57:29 2015] you should, if you supply its argument [Tue Oct 27 12:57:32 2015] apply (H x y). [Tue Oct 27 12:57:59 2015] reference y not found [Tue Oct 27 12:58:05 2015] i think i have to go about it manually [Tue Oct 27 12:58:09 2015] i've never seen that sort of thing [Tue Oct 27 12:58:18 2015] can you use pasting service and show me your entire context and goal? [Tue Oct 27 12:58:22 2015] okay [Tue Oct 27 12:58:26 2015] I may just have the names wrong [Tue Oct 27 12:59:14 2015] http://mathb.in/45415 [Tue Oct 27 12:59:19 2015] sorry i've probably being really unclear [Tue Oct 27 12:59:42 2015] only been learning coq/proofs for like a week so they want us to use stuff like destruct etc [Tue Oct 27 12:59:42 2015] ah, that's not what I meant [Tue Oct 27 12:59:48 2015] oh [Tue Oct 27 12:59:49 2015] context [Tue Oct 27 12:59:50 2015] my bad [Tue Oct 27 12:59:54 2015] I wanted to see what your CoqIDE or Emacs is showing you as your current context, yeah [Tue Oct 27 13:00:11 2015] http://mathb.in/45416 [Tue Oct 27 13:00:14 2015] like that? [Tue Oct 27 13:00:21 2015] yeah, exactly [Tue Oct 27 13:01:01 2015] so, you need to prove something of type "B" [Tue Oct 27 13:01:04 2015] provide* [Tue Oct 27 13:01:14 2015] but you don't have anything of type B [Tue Oct 27 13:01:28 2015] let me try this here [Tue Oct 27 13:01:31 2015] okay [Tue Oct 27 13:05:02 2015] this is how the homework assignment is written? [Tue Oct 27 13:05:38 2015] I don't see a way to unify the two existentials [Tue Oct 27 13:05:41 2015] yeah, just says proove it either intuitionally or classically [Tue Oct 27 13:05:45 2015] unless its unproovable [Tue Oct 27 13:05:56 2015] hmmmmmmm [Tue Oct 27 13:06:03 2015] brb [Tue Oct 27 13:06:36 2015] maybe the converse is provable [Tue Oct 27 13:13:23 2015] The converse is certainly provable. This however does not look provable, even classically. [Tue Oct 27 13:18:13 2015] if you take R to be x = 2 * y, then H is true but the goal is false [Tue Oct 27 13:19:39 2015] ergo it cannot be true for all R [Tue Oct 27 13:22:32 2015] if my goal is 'c a = c b', how do i leverage injectivity of constructors to get a goal of 'a = b' [Tue Oct 27 13:22:56 2015] inversion can do it, or f_equal with a function that strips off c [Tue Oct 27 13:23:17 2015] no, inversion operates on hypotheses [Tue Oct 27 13:24:45 2015] just use f_equal with c then, that doesn't use injectivity [Tue Oct 27 13:24:55 2015] ohhh right [Tue Oct 27 14:49:36 2015] is there a way to define notation along with a typeclass [Tue Oct 27 14:50:22 2015] something like, Class ... { } where "a + b" := (add a b) (at level 75, right associativity). [Tue Oct 27 14:50:37 2015] (that obviously does not work) [Tue Oct 27 20:21:28 2015] is there a way to do a reduction such that whenever a given term appears in the process of reducing it gets rewritten by a supplied equality [Tue Oct 27 20:29:49 2015] replace X with Y should replace X wherever it occurs, if they are equal... [Tue Oct 27 20:30:04 2015] so long as it's not under a binder, which requires setoid rewriting [Tue Oct 27 20:31:59 2015] no, see [Tue Oct 27 20:32:14 2015] i have an expression that is not expanded and unfolded as much as it could be [Tue Oct 27 20:32:24 2015] in it current form, it does not contain the lhs of my equality [Tue Oct 27 20:32:31 2015] once fully simpl'd, it wont [Tue Oct 27 20:32:36 2015] *in an intermediate step*, it will [Tue Oct 27 20:32:48 2015] oh, I see what you mean [Tue Oct 27 20:32:52 2015] you want it to try at every step [Tue Oct 27 20:32:54 2015] yeah [Tue Oct 27 20:32:56 2015] :| [Tue Oct 27 20:33:34 2015] I'm not sure how to do that; you may want to ask on the list [Tue Oct 27 20:39:25 2015] :( [Tue Oct 27 23:28:24 2015] list /whois cale [Tue Oct 27 23:28:31 2015] err [Tue Oct 27 23:28:31 2015] hi [Tue Oct 27 23:28:41 2015] I was just interested in what channels you were in [Tue Oct 27 23:28:48 2015] I am looking for a channel on SAT solvers [Tue Oct 27 23:28:50 2015] uhh, I'm in a lot of channels :) [Tue Oct 27 23:28:55 2015] and I figured I would just whois you [Tue Oct 27 23:29:00 2015] But nothing on SAT solvers in particular [Tue Oct 27 23:29:03 2015] but I had a list in front :( [Tue Oct 27 23:29:12 2015] You could ask in #haskell-blah or something [Tue Oct 27 23:29:27 2015] hmm, i will do that [Tue Oct 27 23:29:33 2015] while you are around though.... [Tue Oct 27 23:29:47 2015] I have a coq question that I have never thought anyone would answer [Tue Oct 27 23:29:47 2015] I don't actually know much about SAT solvers [Tue Oct 27 23:30:07 2015] Fully SAT-unrelated :) [Tue Oct 27 23:30:21 2015] Oh, what's the Coq question? I'm a bit of a noob in Coq as well, but I find it pretty intuitive most of the time [Tue Oct 27 23:30:42 2015] (I didn't so much learn Coq as realise that I already knew how to program in it :P) [Tue Oct 27 23:31:22 2015] haha [Tue Oct 27 23:31:38 2015] Do you have experience in type or computing theory? [Tue Oct 27 23:32:09 2015] Yeah, I've been programming in Haskell since 2001, often professionally [Tue Oct 27 23:32:18 2015] and I have a degree in pure mathematics [Tue Oct 27 23:32:29 2015] and so I've studied type theory in my free time a bunch [Tue Oct 27 23:33:00 2015] i see [Tue Oct 27 23:33:58 2015] so i'll try to make this as quick as possible [Tue Oct 27 23:36:29 2015] what tactic is available in coq to find the roots of a cubic equation expressed in a closed form [Tue Oct 27 23:36:56 2015] (sorry if that is vague or inaccurate, I havent yet attended university) [Tue Oct 27 23:37:11 2015] so for example fibonacci [Tue Oct 27 23:37:23 2015] but I am actually interested in the fibonacci sequence plus one term [Tue Oct 27 23:37:42 2015] i.e f(x) = f(x - 3) + f(x - 2) + f(x - 1) [Tue Oct 27 23:39:54 2015] Oh, hmm [Tue Oct 27 23:40:07 2015] I haven't played around with any of the arithmetic solver things [Tue Oct 27 23:40:33 2015] Usually if there's arithmetic to be manipulated, I just end up with messy complicated proofs and live with it :P [Tue Oct 27 23:40:47 2015] But there are some tactics which can do related things... [Tue Oct 27 23:41:52 2015] Omega won't do it because even the square term is a problem [Tue Oct 27 23:42:54 2015] haha [Tue Oct 27 23:43:31 2015] (it's a solver for things in Presburger arithmetic) [Tue Oct 27 23:46:17 2015] There's a tactic called 'ring' which might help sometimes [Tue Oct 27 23:48:00 2015] (and/or field) [Tue Oct 27 23:48:27 2015] https://coq.inria.fr/refman/Reference-Manual027.html [Tue Oct 27 23:48:58 2015] So you could probably pose the solution and prove that it's correct using that [Tue Oct 27 23:53:28 2015] zv: if you want to *find* possible solutions, then SAT [Tue Oct 27 23:54:06 2015] johnw: I want the closed form [Tue Oct 27 23:54:21 2015] what does that mean? (I'm not a mathematician) [Tue Oct 27 23:55:50 2015] i.e, I want to map f(x) = f(x - 1) + f(x - 2) = k / k^2 - k - q [Tue Oct 27 23:55:57 2015] or what I *REALLY* want [Tue Oct 27 23:56:43 2015] which is to convert lim x->inf Fib_n+1/Fib_n = sqrt(5) + 1 / 2 [Tue Oct 27 23:56:49 2015] aka phi or the golden ratio [Wed Oct 28 00:08:45 2015] you mean, you want to prove the equality? [Wed Oct 28 00:11:49 2015] no, I want to find the explicit value of the limit as a rational expression [Wed Oct 28 00:14:06 2015] and then prove the equality :0 [Wed Oct 28 06:23:36 2015] probably zv would've needed to prove a great deal about the theory of linear recurrences. sounds like a pretty big job. [Wed Oct 28 16:19:34 2015] ok, here's my situation [Wed Oct 28 16:19:43 2015] (i xy'd about this the other day a bit) [Wed Oct 28 16:20:23 2015] i have a slightly complicated recursive function that calls out to a few other sorta complicated recursive functions [Wed Oct 28 16:20:50 2015] i'm trying to prove a thing involving it that involves working with expressions where it's applied to opaque (b/c universally quantified) variables [Wed Oct 28 16:21:41 2015] thing is, it produces RIDICULOUS MASSIVE terms because it can do half of the complicated recursive expansion but then simplification gets stuck matching on opaque terms [Wed Oct 28 16:23:27 2015] i have in context an equality or two saying things along the lines of "complex_test opaque_var = 3", which provide enough info to hypothetically end up with a small result term if applied judiciously during reduction [Wed Oct 28 16:23:33 2015] what do i do? [Wed Oct 28 16:23:37 2015] alternatively, what am i doing wrong? [Wed Oct 28 16:26:00 2015] can you add hints to the simplifier? [Wed Oct 28 16:27:17 2015] i dunno, never learned about any such thing [Wed Oct 28 16:27:20 2015] link? [Wed Oct 28 16:35:01 2015] sorry wasn't paying attention. https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#hevea_command233 [Wed Oct 28 16:40:17 2015] sanooj: this is for auto; you said something about simplifier hints? [Wed Oct 28 17:07:55 2015] Is there a tactic that gets me from "x : T, H: x = c ... |- ..." to "x : T := c ... |- ..."? (I tried writting one in Ltac but ran into trouble because I couldn't figure out how to do a "rewrite" for all defined constants in the current context.) [Wed Oct 28 17:10:13 2015] I wonder if "subst" does something like this? [Wed Oct 28 17:14:51 2015] mdmkolbe: i'm fairly sure that you're asking for a way to get a definitional equality from a propositional one [Wed Oct 28 17:16:07 2015] benzrf: yes [Wed Oct 28 17:20:15 2015] benzrf: ... but googling around for those terms doesn't seem to turn up anything useful [Wed Oct 28 17:20:43 2015] companion_cube: it looks like subst doesn't know to replace inside a defined constant [Wed Oct 28 17:20:58 2015] mdmkolbe: you literally can't do that [Wed Oct 28 17:21:00 2015] sorry :> [Wed Oct 28 17:21:09 2015] I was not sure it would work [Wed Oct 28 17:21:15 2015] for the same reason that you can't define arbitrary recursive functions [Wed Oct 28 17:21:18 2015] it causes problems with the theory [Wed Oct 28 17:21:43 2015] benzrf: what happens if you destruct x=c? don't you get Refl, that makes x and c the same? [Wed Oct 28 17:21:53 2015] oh uh [Wed Oct 28 17:21:59 2015] wait fff im stupid [Wed Oct 28 17:22:09 2015] you can't get definitional from propositional *in general*, but [Wed Oct 28 17:22:25 2015] there are subcases that are useful [Wed Oct 28 17:22:29 2015] so nvm >_< [Wed Oct 28 17:23:19 2015] um. s/"there are subcases that are useful"/"there are some use cases that you can accomplish anyway" [Wed Oct 28 17:27:41 2015] Yeah, "set y := c; [rewrite -/y in H]; rewrite H in A B C" does the trick if x is used only in A, B and C. [Wed Oct 28 17:28:10 2015] destruct H. eliminates x (or c), as far as I can tell [Wed Oct 28 17:28:19 2015] wait a sec [Wed Oct 28 17:28:31 2015] what is 'rewrite -/y' [Wed Oct 28 17:29:15 2015] I wrote a tacktic to do this, but I wanted it to figure out "A B C" for me. so "rewrite H in * |- *" does the rewrite I want except in the locally defined constants [Wed Oct 28 17:29:37 2015] "rewrite -/y" is ssreflect notation for folding the definition of y [Wed Oct 28 17:29:52 2015] * see the word 'ssreflect' [Wed Oct 28 17:30:01 2015] * recoils as would a vampire from the sun [Wed Oct 28 17:30:07 2015] but more seriously: [Wed Oct 28 17:30:20 2015] You could just as easily write "fold y in H" instead of "rewrite -/y in H" [Wed Oct 28 17:30:21 2015] rewrite does replacement in the *type* of a local var [Wed Oct 28 17:30:27 2015] soz [Wed Oct 28 17:30:55 2015] ssreflect's rewrite does fold/unfold when a variable is prefixed with "/" [Wed Oct 28 17:32:27 2015] ssreflect's rewrite tactic is a reason on its own to use it [Wed Oct 28 17:35:25 2015] eh. [Wed Oct 28 17:35:27 2015] :] [Thu Oct 29 02:01:30 2015] benzrf: there are rewrite hints also. [Thu Oct 29 02:01:48 2015] but yeah, not really sure what you were going for. idle thought. [Thu Oct 29 14:13:22 2015] is there a way to reset coq's state from inside coq? ie, have some directive in a file that completely removes anything in scope including implicit/standard library stuff [Thu Oct 29 14:14:48 2015] i tried creating a state with Save/Restore State and -nois but that didnt work [Thu Oct 29 14:23:50 2015] i dont know what a rewrite hint is, sanooj [Thu Oct 29 14:23:52 2015] :> [Thu Oct 29 14:24:17 2015] Hint Rewrite foo. [Thu Oct 29 14:24:29 2015] Hint Rewrite foo in bar. or something with a database name [Thu Oct 29 14:25:09 2015] anyway, check the manual if you want to know [Thu Oct 29 14:25:19 2015] and also Chlipala's book [Thu Oct 29 18:52:09 2015] Hi guys, could anyone help me with this proof? http://lpaste.net/144217 [Thu Oct 29 18:52:12 2015] thanks in advance [Thu Oct 29 18:53:09 2015] I don't know how to proceed after the first case [Thu Oct 29 18:53:23 2015] inside the induction on a [Thu Oct 29 19:22:34 2015] how would you prove this statement on paper? Would you really proceed by a simple induction on a or would you require a more powerful principle? [Thu Oct 29 19:23:09 2015] I guess I'd prove it by induction on a [Thu Oct 29 19:23:21 2015] (also, you should use "destruct x" rather than "elim x": with elim you lose the connection between the x in the goal and the one in the assumption y" [Thu Oct 29 19:23:27 2015] and, actually, I'm asked to do it by induction on a [Thu Oct 29 19:24:07 2015] do you know a tactic for working with lets? [Thu Oct 29 19:24:21 2015] because I don't know how to keep going from there [Thu Oct 29 19:25:26 2015] It's going to be hard to prove that "y : a = b * n + n0 /\ n0 < b" implies "S a = b * n + n0 /\ n0 < b" [Thu Oct 29 19:26:15 2015] that's why I was asking what the on paper proof should be: if you have no idea what the actual proof is, it's way harder to build one in coq [Thu Oct 29 19:27:10 2015] thanks [Thu Oct 29 19:27:28 2015] but it can be proven by induction on a [Thu Oct 29 19:27:42 2015] the problem is that, in the second case of the induction [Thu Oct 29 19:28:06 2015] I have to proceed by cases on r [Thu Oct 29 19:28:20 2015] 23:25 < gallais> It's going to be hard to prove that "y : a = b * n + n0 /\ n0 < b" implies "S a = b * n + n0 /\ n0 < b" [Thu Oct 29 19:28:21 2015] and I don't have it in my scope [Thu Oct 29 19:28:51 2015] if you can prove this, then you have found a contradiction in the system. Hence my "it's going to be hard to prove" [Thu Oct 29 19:30:00 2015] gallais: thanks, maybe if you erase the lasts tactics I've written: http://lpaste.net/144217 [Thu Oct 29 19:30:50 2015] that's what I want to prove [Thu Oct 29 20:15:53 2015] Is there a way to show this : S m = m + 1 ?? [Thu Oct 29 20:16:48 2015] I'm almost there: http://lpaste.net/144217 :) [Thu Oct 29 20:17:05 2015] You can prove this by induction over m. Also, there should be a lemma in the standard library, just have to find it :) [Thu Oct 29 20:19:02 2015] yes, I don't want to define another lemma, but I've been looking for and I couldn't find one [Thu Oct 29 20:19:53 2015] There is [Nat.add_1_r: forall n : nat, n + 1 = S n] [Thu Oct 29 20:20:06 2015] oops, I missed that one [Fri Oct 30 08:24:57 2015] hi [Fri Oct 30 08:25:23 2015] is there a tactic that will automatically try to rewrite the goal using available assumptions and then reflexivity? [Fri Oct 30 08:30:00 2015] Not really, but you can write it quite easily: [repeat (match goal with H : _ |- _ => rewrite H end; try reflexivity).] [Fri Oct 30 08:30:10 2015] (or something along those lines) [Fri Oct 30 08:51:17 2015] autorewrite isnt exactly the thing you're looking for, but I think you should have a look [Sat Oct 31 22:37:07 2015] hey jgross im signing up for mit splash should i take your HoTT class [Sun Nov 1 07:57:37 2015] löb's theorem sounds interesting. [Sun Nov 1 13:07:11 2015] http://coq.io/opam/ btw [Mon Nov 2 14:10:05 2015] Is it possible to define mutually recursive inductive data types in Coq? [Mon Nov 2 14:15:53 2015] yes! [Mon Nov 2 14:23:19 2015] can I get some help with a simple proof with booleans? [Mon Nov 2 14:23:30 2015] 'Lemma bool : ~(exists x : bool, forall y : bool, x <> y).' [Mon Nov 2 14:29:25 2015] gwm_: well I think the naive approach should work: do case analysis on x and then in each case show that there is a y that contradicts the hypothesis [Mon Nov 2 14:30:26 2015] sanooj: any pointers? My googling is just up function recursion. [Mon Nov 2 14:31:36 2015] *turning up [Mon Nov 2 14:32:42 2015] @jrw - i don't understand how to apply false to the subgoal 'true <> y' [Mon Nov 2 14:32:48 2015] my current proof is: intro h. destruct h. destruct x. [Mon Nov 2 14:33:45 2015] gwm_: you should have a hypothesis [H : forall y, true <> y] and a goal of False [Mon Nov 2 14:33:47 2015] nonloopy: Inductive T := ... with M := ... . and fix f0 (args, ...) := ... with f1(args, ...) := ... [Mon Nov 2 14:34:15 2015] @jrw yeah, my goal is forall y: bool, true <> y [Mon Nov 2 14:34:29 2015] what's the next step with 2 sub goals False and False [Mon Nov 2 14:34:39 2015] i mean't my context* [Mon Nov 2 14:34:45 2015] my goals are false and false [Mon Nov 2 14:34:56 2015] right [Mon Nov 2 14:35:07 2015] so now your hypothesis is a contradiction [Mon Nov 2 14:35:18 2015] because it can't be the case that for all booleans, they are not equal to true [Mon Nov 2 14:35:26 2015] in particular, it is not the case that true is not equal to true [Mon Nov 2 14:36:12 2015] i see [Mon Nov 2 14:36:22 2015] @jrw how do i go about prooving this negation then? [Mon Nov 2 14:36:31 2015] sry very new to proofs and coq in general [Mon Nov 2 14:37:02 2015] gwm_: you could do it a couple ways. one would be [specialize (H true)] [Mon Nov 2 14:37:13 2015] haven't learn't that syntax [Mon Nov 2 14:37:19 2015] perhaps assert? [Mon Nov 2 14:37:23 2015] okay [Mon Nov 2 14:37:41 2015] you could [assert (true <> true)] [Mon Nov 2 14:37:47 2015] which is provable by [apply H] [Mon Nov 2 14:38:03 2015] ianjneu: thanks! [Mon Nov 2 14:38:12 2015] and then if you apply the new hypothesis from the assert, you can finish with reflexivity [Mon Nov 2 14:39:19 2015] @jrw ahh perfect. [Mon Nov 2 14:39:23 2015] thanks for the help :) [Mon Nov 2 14:42:46 2015] gwm_: intros [[t|t]]; [specialize (t true)| specialize (t false)]; destruct t; reflexivity. [Mon Nov 2 14:42:49 2015] :) [Mon Nov 2 14:43:28 2015] @ianjneu seems a lot cleaner but I think we're only allowed to use syntax which has been covered, thanks though I'll look into specialise. [Mon Nov 2 14:47:51 2015] gwm_: you can also destruct directly: intros [[t|t]]; [destruct (t true)| destruct (t false)]; reflexivity. [Mon Nov 2 14:50:48 2015] ahh ok [Mon Nov 2 16:42:18 2015] nonloopy: use Inductive with ... with . [Mon Nov 2 16:42:51 2015] sorry wasn't paying attention. :| [Tue Nov 3 21:52:02 2015] Hi guys, I need some help with a proof [Tue Nov 3 21:52:07 2015] pumita: go on... [Tue Nov 3 21:52:10 2015] http://lpaste.net/144549 [Tue Nov 3 21:52:53 2015] I don't understand really well how to start proving well founded relations [Tue Nov 3 21:56:20 2015] oh wow [Tue Nov 3 21:56:30 2015] i didnt even realize well_founded was in the default imports [Tue Nov 3 21:56:32 2015] :D [Tue Nov 3 21:57:12 2015] it's just an extract of my full file though :P [Tue Nov 3 21:57:47 2015] any hint? [Tue Nov 3 21:59:35 2015] sorry, unfamiliar with coq's well_founded stuff [Tue Nov 3 21:59:38 2015] im looking right now actually [Tue Nov 3 22:00:14 2015] pumita : it should go quite easily by induction on a [Tue Nov 3 22:00:40 2015] Cypi: yes, I tried that [Tue Nov 3 22:00:53 2015] but I don't know what to do after [Tue Nov 3 22:01:02 2015] After, there is only one choice: constructor [Tue Nov 3 22:01:50 2015] Then in one part of the induction, you should get an impossible hypothesis. In the other one, you should have enough hypotheses to complete the proof. [Tue Nov 3 22:01:55 2015] Cypi : it's looking good ... :), let me try that [Tue Nov 3 22:02:22 2015] what does the ctor tactic do? [Tue Nov 3 22:02:55 2015] If your goal is an inductive type, it tries to apply each constructor of this type in order [Tue Nov 3 22:03:15 2015] oh, handy [Tue Nov 3 22:03:16 2015] It's just a way to not have to remember the name of a constructor :p (also, serves for some automation, of course) [Tue Nov 3 22:03:51 2015] There is also [econstructor] which does [eapply] instead of just [apply]. Also, you can do [constructor n] to specifically apply the n-th constructor [Tue Nov 3 22:04:09 2015] if anyone wants to see the proof: http://lpaste.net/144549 [Tue Nov 3 22:04:19 2015] Cypi : thanks you a lot! :D [Wed Nov 4 06:43:07 2015] pumita: very short and sweet proof, nice. :) [Wed Nov 4 06:43:24 2015] and clear. [Wed Nov 4 10:32:01 2015] Hi all. Am just getting started with coq, is it common to use proofgeneral for all editing? [Wed Nov 4 11:58:20 2015] so it looks like the Fin.to_nat function only proves that there exists an i less than n, but doesn't give it to you, any idea why? [Wed Nov 4 12:14:21 2015] stelleg: you get a pair back. proj1_sig will let you project out the nat [Wed Nov 4 12:15:05 2015] shlevy: yeah, I think so. [Wed Nov 4 12:15:47 2015] some people like coqide. [Wed Nov 4 12:16:27 2015] gallais_: ah thanks! [Wed Nov 4 13:07:17 2015] is there an term equivalent to admit? [Wed Nov 4 13:07:27 2015] like undefined in haskell? [Wed Nov 4 13:08:28 2015] you can make it with Axiom [Wed Nov 4 13:23:58 2015] you can use _ for placeholders but it must be able to infer its type [Wed Nov 4 13:32:10 2015] thanks guys [Wed Nov 4 14:02:06 2015] in common mathematical writing, how do you usually denote dependent functions? using indexed product notation? [Wed Nov 4 14:02:16 2015] or some adapted coq like form? [Wed Nov 4 14:02:42 2015] big Pi is good [Wed Nov 4 14:03:26 2015] (Πx:X)A(x) [Wed Nov 4 14:03:34 2015] vanila: do you know if they are used by non computer science mathematicians these days? [Wed Nov 4 14:05:27 2015] in other words any mathematician will recognise A^X as the space of functions from A to X... but how about (Πx:X)A(x) [Wed Nov 4 14:06:27 2015] is that something only a few select CS people will get? or is it something plenty of mathematicians will recognise as a dependent function space [Wed Nov 4 14:06:30 2015] just cite something that introduces type theory [Wed Nov 4 14:06:54 2015] yeap I will, was just curious about it [Wed Nov 4 14:07:08 2015] I think category theory people will get it [Wed Nov 4 14:07:12 2015] right [Wed Nov 4 14:08:42 2015] just one more question, with regards to theoretical introduction, aside from Martin-Lof's "Constructive Mathematics and Programming", are there any other classics I should be awere of? [Wed Nov 4 14:09:59 2015] *and computer programming [Wed Nov 4 14:10:02 2015] "lectures on the curry-howard isomorphism" ive heard good things about too, although ive only read a bit of it [Wed Nov 4 14:10:04 2015] I think Luo UTT is important [Wed Nov 4 14:11:21 2015] sunnymilk: ok will get it too [Wed Nov 4 14:11:38 2015] vanila: Luo UTT? [Wed Nov 4 14:12:29 2015] Z. Luo. Computation and Reasoning: A Type Theory for Computer Science. OUP, 1994. [Wed Nov 4 14:13:07 2015] vanila: interesting, I didn't know about it [Wed Nov 4 14:21:02 2015] vanila: is there any practical system based on UTT? e.g. Coq like theorem prover or anything of the sort? [Wed Nov 4 14:21:25 2015] I'd never heard of unintentional type theory [Wed Nov 4 14:22:16 2015] idris and agda ive heard are based on UTT [Wed Nov 4 14:22:19 2015] but im not sure about that [Wed Nov 4 14:22:22 2015] oh [Wed Nov 4 14:23:28 2015] https://cstheory.stackexchange.com/questions/22498/rules-about-prop-and-set-in-utt [Wed Nov 4 14:24:59 2015] I think UTT introduced the universe hierarchy we have in coq today [Wed Nov 4 14:25:44 2015] yeah, and impredicative prop like in that link [Wed Nov 4 14:34:56 2015] I see [Wed Nov 4 14:35:02 2015] got a lot of reading to do [Thu Nov 5 09:59:09 2015] hello [Thu Nov 5 10:00:29 2015] absurdium: g'day [Thu Nov 5 10:03:01 2015] I'm an absolute beginner with coq (absolute beginner with proofs too, I have to admit) - is there some resource which shows how normal reasoning in proofs is done in coq? [Thu Nov 5 10:03:19 2015] e.g. how do I rewrite my goal into contrapositive form [Thu Nov 5 10:03:46 2015] (if the goal is an implication, of course) [Thu Nov 5 10:03:48 2015] absurdium: Software Foundations by Pierce, et. al. [Thu Nov 5 10:04:13 2015] http://www.cis.upenn.edu/~bcpierce/sf/current/toc.html [Thu Nov 5 10:04:18 2015] ianjneu: I hoped I could postpone reading that book for some while [Thu Nov 5 10:04:43 2015] I'm currently reading "How to Prove it" by Daniel J. Velleman [Thu Nov 5 10:05:01 2015] absurdium: you don't have to read it all. It has very beginner exercises bundled with it. Perhaps just step through those [Thu Nov 5 10:05:02 2015] I wanted to tackle SF after I'm done with "How To Prove It" [Thu Nov 5 10:05:23 2015] ah, ok [Thu Nov 5 10:05:27 2015] How To Prove It is more informal math than it is a constructive approach. [Thu Nov 5 10:05:55 2015] what do you want to do with coq? [Thu Nov 5 10:06:06 2015] or what is your goal more generally? [Thu Nov 5 10:06:13 2015] vanila: the exercises in How To Prove It which have no solution in the appendix [Thu Nov 5 10:07:24 2015] ianjneu: what do you mean with a constructive approach? [Thu Nov 5 10:13:03 2015] absurdium: Reasoning without the law-of-excluded-middle, considering theorems as proof-transforming functions, logical connectives as various datatypes (conjunction is pairing, disjunction is injection into the Either (AKA Sum) datatype, etc.) [Thu Nov 5 17:50:06 2015] https://www.youtube.com/watch?v=JpK9e__q5Ts [Thu Nov 5 17:50:30 2015] just watching this talk on abstract interp, really nice tool that might be good to do in coq [Sun Nov 8 20:28:23 2015] is there a nice to prove uniqueness of identity for eg multiplication over positive integers [Sun Nov 8 20:28:36 2015] identity as in multiplicative identity [Sun Nov 8 20:28:55 2015] i want to prove forall a. a * a = 1%positive -> a = 1%positive [Sun Nov 8 20:29:05 2015] i kjnow its in the standard library somewhere but i cant find it [Sun Nov 8 20:38:39 2015] in fact how the heck do i convert positive to Z [Sun Nov 8 20:38:47 2015] i cant find a function to do that anywhere [Sun Nov 8 20:40:54 2015] oh its Zpos [Mon Nov 9 11:09:38 2015] sunnymilk: in module Mult there is mult_is_one : forall n m, n * m = 1 -> n = 1 /\ m = 1. [Mon Nov 9 11:11:21 2015] what type is * over? [Mon Nov 9 11:13:07 2015] ohhh [Mon Nov 9 11:13:09 2015] oh sorry! [Mon Nov 9 11:13:10 2015] nats [Mon Nov 9 11:13:22 2015] didnt see you wanted positives [Mon Nov 9 11:26:01 2015] hello i am reading https://coq.inria.fr/refman/Reference-Manual006.html [Mon Nov 9 11:26:11 2015] why are let-terms a primitive syntax [Mon Nov 9 11:26:36 2015] is [let x := y in z] different from [(fun x => z) y] [Mon Nov 9 11:34:26 2015] so, afaik, the difference is that `let x := y in z` doesn't type exactly the same as (fun x => z) y [Mon Nov 9 11:34:41 2015] because in the let-case, the typer knows that x converts to y [Mon Nov 9 14:19:53 2015] companion_cube: so iow the let-case has an additional definitional equality in ctx? [Mon Nov 9 14:19:57 2015] interesting. [Mon Nov 9 14:21:13 2015] yes [Mon Nov 9 16:18:46 2015] hello [Mon Nov 9 16:19:29 2015] is there a way to convert the current goal to be a closed term applied to all relevant assumptions in scope [Mon Nov 9 16:20:58 2015] e.g., if the context is [x : nat; y : nat; H : y = S x] and the goal is [x < y], is there a way to automatically rewrite such that the goal becomes [(fun a b => a < b) x y] [Mon Nov 9 16:41:53 2015] benzrf: in this case, you could do [pattern x; pattern y] [Mon Nov 9 16:42:02 2015] not sure whether that's exactly what you're looking for in general [Mon Nov 9 16:45:09 2015] hmmmmm [Mon Nov 9 16:45:22 2015] aaaaahh NICE [Mon Nov 9 16:45:25 2015] :D [Mon Nov 9 16:45:26 2015] nice nice [Tue Nov 10 09:22:44 2015] is there a way to get in Ltac the hypothetical result goal of applying some tactic [Tue Nov 10 09:22:59 2015] in particular, can i get what the current goal would look like if i applied generalize dependent x [Tue Nov 10 09:28:23 2015] I don't know, but isn't it possible to use 'try'? [Tue Nov 10 09:29:36 2015] * shrugs [Tue Nov 10 09:29:39 2015] oh wait nvm [Tue Nov 10 09:29:45 2015] ok real question [Tue Nov 10 09:29:54 2015] 1 sec... [Tue Nov 10 09:30:23 2015] guh [Tue Nov 10 09:30:58 2015] Hello, I 've written a function "factorial". Now how can I prove it DO compute the factorial? [Tue Nov 10 09:31:13 2015] riaqn: what are you trying to prove? [Tue Nov 10 09:32:08 2015] benzrf: nothing to prove..just curious. [Tue Nov 10 09:32:16 2015] umm [Tue Nov 10 09:32:25 2015] oh [Tue Nov 10 09:32:39 2015] riaqn: i dont mean the idiom, i mean very literally, what theorem are you trying to prove? [Tue Nov 10 09:33:16 2015] yeah, I guess to write the theorem is the first and the most hard step. [Tue Nov 10 09:33:57 2015] Just want to know "how to convince someone that my factorial is correct". [Tue Nov 10 09:34:25 2015] riaqn: usually you prove that the functions you write satisfy certain propositional properties, or compute things related by an intuitively correct relation [Tue Nov 10 09:35:06 2015] riaqn: for example, if you write a function that calculates whether a number is even, you could prove that it's "correct" by showing that it says true if and only if there's some x such that the input is x * 2 [Tue Nov 10 09:35:07 2015] benzrf: like "factorial (S n) = (S n) * factorial n"? [Tue Nov 10 09:35:19 2015] riaqn: exactly [Tue Nov 10 09:35:22 2015] but the thing is [Tue Nov 10 09:35:31 2015] your implementation already says that straight up (assuming you implemented factorial the obvious way) [Tue Nov 10 09:35:38 2015] so there's not much you can usefully prove [Tue Nov 10 09:35:44 2015] yeah, so it's should very easy to prove. [Tue Nov 10 09:35:51 2015] well, there's not really any point in proving it [Tue Nov 10 09:35:56 2015] ok, I see. thank you! [Tue Nov 10 09:35:57 2015] it's just a reflexivity [Tue Nov 10 09:35:59 2015] no problem :) [Tue Nov 10 09:36:24 2015] riaqn: proving that as its own theorem would be kind of like providing an implementation of some type by just setting the implementation to a constructor [Tue Nov 10 09:36:39 2015] riaqn: like implementing 'zero : nat' by setting 'zero := O' [Tue Nov 10 09:36:42 2015] there's no real point there [Tue Nov 10 09:36:54 2015] and similarly there's no real point in proving a theorem that just states your function's definition [Tue Nov 10 09:37:10 2015] riaqn: that theorem could be interesting if you defined factorial by means of an imperative for loop, or something [Tue Nov 10 09:38:05 2015] benzrf: so the implementation is so straightforward that it's a copy of definition, which makes it point-less to prove. [Tue Nov 10 09:38:26 2015] otoh it can be useful to prove that you compute the Fibonacci function by specifying it naively, but implementing it in a more efficient way [Tue Nov 10 09:39:52 2015] companion_cube: yes, like some linear algebra tricks. [Tue Nov 10 09:40:06 2015] riaqn: right [Tue Nov 10 09:40:08 2015] :) [Tue Nov 10 09:42:07 2015] or even the linear version, which is still much better than the direct definition [Tue Nov 10 12:18:39 2015] is there a way to apply functions to either side of an equality constructor? e.g. I have an axiom H : a = b, and would like H' : f a = f b [Tue Nov 10 12:19:23 2015] Seems like theres probably a tactic for that but I'm not seeing it [Tue Nov 10 12:20:49 2015] i believe that's equal_f [Tue Nov 10 12:21:14 2015] as in: apply (equal_f f := f) in H. or something along those lines [Tue Nov 10 12:21:40 2015] it requires functional extensionality [Tue Nov 10 12:30:42 2015] johnw: thanks, trying that. not familiar with the := syntax (and neither is my Coq apparently) though [Tue Nov 10 12:31:09 2015] oh, maybe: [Tue Nov 10 12:31:18 2015] apply (equal_f (f := f)) in H. [Tue Nov 10 12:32:17 2015] oh, never mind [Tue Nov 10 12:32:28 2015] equal_f isn't what I was thinking about [Tue Nov 10 12:33:55 2015] stelleg: you could always assert that forall a b, a = b -> f a = f b, and then apply that to your hypothesis. [Tue Nov 10 12:33:56 2015] johnw: yeah seems a little stronger than what I need [Tue Nov 10 12:34:16 2015] it amounts to proving f is injective [Tue Nov 10 12:34:44 2015] Injectivity is [f a = f b -> a = b], not the other way around [Tue Nov 10 12:34:52 2015] [a = b -> f a = f b] is always true [Tue Nov 10 12:34:59 2015] leibnitz equality? [Tue Nov 10 12:35:07 2015] I do get those confused often [Tue Nov 10 12:35:24 2015] I would call that the functionality of f, but I don't know :) [Tue Nov 10 12:35:33 2015] (in the sense that equal inputs produce equal outputs) [Tue Nov 10 12:35:49 2015] right, what was I thinking [Tue Nov 10 12:35:57 2015] sorry to send you down blind alleys, stelleg [Tue Nov 10 12:36:12 2015] johnw: no problem, its helpful [Tue Nov 10 12:36:19 2015] to learn [Tue Nov 10 12:37:06 2015] Cypi_: well, no, the functionality is only the fact that to one output corresponds at most one output [Tue Nov 10 12:37:30 2015] [a = b -> f a = f b] is a property of the equality [Tue Nov 10 12:37:37 2015] (it being a congruence) [Tue Nov 10 12:37:57 2015] stelleg: it's this: apply f_equal with (f := f) in H. [Tue Nov 10 12:38:05 2015] actually tried it here this time [Tue Nov 10 12:38:40 2015] quelu: congruence is a tactic that worksf or that! [Tue Nov 10 12:38:47 2015] johnw: oh cool thanks! [Tue Nov 10 12:38:59 2015] appreciate the help guys [Tue Nov 10 12:39:54 2015] johnw: oh yeah f_equal is exactly the right theorem, thanks [Tue Nov 10 12:40:06 2015] quelu : yes, you're right. I meant "functional" not in a set-theoretical sense, but in a "programming language" sense [Tue Nov 10 12:43:17 2015] You can write a bit of Ltac doing exactly this: http://lpaste.net/144997 [Tue Nov 10 12:46:54 2015] gallais_: thanks! [Tue Nov 10 14:54:56 2015] Can somebody explain to me how to solve the definition: (A -> C) -> (B -> A) -> (B -> C) := [Tue Nov 10 14:55:07 2015] In terms of sets, have to use curry howard [Tue Nov 10 14:58:36 2015] fun f g x => f (g x) [Tue Nov 10 19:45:29 2015] does anyone have any tips for working with different number systems (eg, theorems involving all of natural numbers, integers, positive integers, rationals, etc) [Tue Nov 10 19:46:21 2015] an example of a nic ething i would like is to be able to take a goal/hypotheses and convert them all to a single number system with some additional theorems (ie, if a variable x is of type positive, it would be nice to rewrite everything such that it is now a natural number + a hypothesis that it is non-zero) [Tue Nov 10 19:46:31 2015] that sounds a bit far-fetched though [Tue Nov 10 19:50:25 2015] i dont even really know how to like, rewrite a goal/hypothesis from one number system to another [Tue Nov 10 19:54:44 2015] so i might have some equality about natural numbers, but i cant apply it because my goal is wrapped with Pos.to_nat (Zpos ...) [Tue Nov 10 21:34:34 2015] sunnymilk: might want to check out the "zify" tactic, which converts lots of stuff to Z [Tue Nov 10 21:37:08 2015] ooh [Tue Nov 10 21:37:09 2015] thank you! [Tue Nov 10 22:07:37 2015] is there a nice way to turn (x ?= y)%positive = Lt into (y ?= x)%positive = Gt [Tue Nov 10 22:08:11 2015] i cannot figure it out [Tue Nov 10 22:51:39 2015] sunnymilk: have you searched for relevant theroms [Wed Nov 11 10:54:36 2015] benzrf yes [Wed Nov 11 11:38:08 2015] in Martin Lofs "Constructive Mathematics and Computer Programming" isn't the Sigma-elimination rule wrong? [Wed Nov 11 11:38:22 2015] https://i.imgur.com/JrCC6jg.png [Wed Nov 11 11:38:58 2015] in the bottom line, shouldn't that `d` be `d((x,y)/z)` [Wed Nov 11 11:53:03 2015] jabesed: No, it's fine. This is how you'd write it using Coq syntax: http://lpaste.net/145050 [Wed Nov 11 11:53:44 2015] gallais_: hmmm let me see [Wed Nov 11 11:58:40 2015] gallais_: my doubt is in the definition of `d` [Wed Nov 11 11:59:33 2015] gallais_: how is your definition equivalent to the one in the rule? [Wed Nov 11 12:01:12 2015] the one in the rule appears to say `d` has a free var `z` [Wed Nov 11 12:01:19 2015] not free vars x and y [Wed Nov 11 12:01:39 2015] wait [Wed Nov 11 12:01:48 2015] nevermind that's C [Wed Nov 11 12:02:23 2015] nevermind... I was misreading this, sorry about that [Wed Nov 11 12:02:38 2015] and thanks for the code! [Wed Nov 11 13:41:34 2015] i spent hours proving that my recursion was well-founded, only to find out that my implementation is actually wrong :( [Wed Nov 11 13:54:23 2015] sunnymilk: that's a pretty common for me too, actually [Wed Nov 11 13:54:31 2015] that's why proof is so good :) [Wed Nov 11 13:54:53 2015] no matter how invested you get in perceiving the quality of your implementation, the type checker just won't accept untruth ;) [Wed Nov 11 14:01:18 2015] hehe [Wed Nov 11 14:02:18 2015] a large part of my proof though was just moving between number types :| [Thu Nov 12 06:14:02 2015] still on Martin Lofs paper, "Constructive Mathematics and Computer Programming" [Thu Nov 12 06:14:17 2015] this is how he formulates the axiom of choice: https://i.imgur.com/wm1705d.png [Thu Nov 12 06:15:18 2015] it's relatively easy to read, given a function from A and returning a dependent pair, he extracts a dependent pair of functions from A [Thu Nov 12 06:16:31 2015] looking up AC, I get that it states "the Cartesian product of a collection of non-empty sets is non-empty" [Thu Nov 12 06:17:51 2015] so how does that formula specify the AC?... [Thu Nov 12 06:18:40 2015] because we are starting with what seems like a choice function from the cartesian product [Thu Nov 12 06:19:13 2015] and it appears it should be the other way around [Thu Nov 12 06:21:49 2015] "sigma B C" can be seen as the set of (b : B) such that C(b) holds true [Thu Nov 12 06:22:51 2015] "pi (x : A) (sigma (y : B (x)) (C x y))" can be seen as "a collection (indexed by A) of non empty sets of elements (y : B(x)) such that C x y" [Thu Nov 12 06:24:45 2015] hmmm [Thu Nov 12 06:25:56 2015] right [Thu Nov 12 06:27:13 2015] I get do that... but it seems like we are showing that given a non-empty cartesian product, each of the sets in the product is non-empty [Thu Nov 12 06:27:26 2015] while what I wrote above says the reverse [Thu Nov 12 06:28:03 2015] or is what I wrote above wrong? i.e. that the AC states "the Cartesian product of a collection of non-empty sets is non-empty" [Thu Nov 12 06:30:23 2015] put simply the formula appears to show that "if AxB non-empty then A non-empty and B non-empty", and the definition appears to state that if "A non-empty and B non-empty then AxB is non-empty" [Thu Nov 12 06:31:06 2015] wait [Thu Nov 12 06:34:40 2015] You could try to replace A with Bool to have a look at a simpler case [Thu Nov 12 06:35:24 2015] gallais_: so that would give me the binary cartesian product, right? [Thu Nov 12 06:35:32 2015] Yes [Thu Nov 12 06:35:39 2015] ok let me see [Thu Nov 12 06:38:34 2015] ok so the left hand side would represent a product B_1 x B_2 of sets , whose elements satisfy respectively conditions C_1 and C_2 [Thu Nov 12 06:40:29 2015] and (if that is right) therein lies my problem, that we are starting with the cartesian product [Thu Nov 12 06:41:19 2015] but let me think, maybe I see what what's wrong [Thu Nov 12 06:41:23 2015] in my thinking [Thu Nov 12 06:43:42 2015] I think I see... so the right hand side is a single set (i.e. a cartesian product) because it is defined as having one condition determining what the set it [Thu Nov 12 06:43:45 2015] *is [Thu Nov 12 06:44:49 2015] and the left hand side, because there is a condition C x y for each B x, then it is a collection of sets, not a single set (i.e. not a cartesian product) [Thu Nov 12 06:44:53 2015] is that right? [Thu Nov 12 06:45:44 2015] Yes: you take "A" sets on the left hand side and spit out a single set on the right hand side [Thu Nov 12 06:46:08 2015] right, thanks a lot gallais_, that was really helpful [Thu Nov 12 06:49:18 2015] No bother ;) [Thu Nov 12 11:44:48 2015] what's an induction scheme? [Thu Nov 12 11:45:55 2015] i know a bit about induction, like how every inductive datatype gets an induction axiom (eg, for nat, its forall n (P : nat -> Prop), P 0 -> (P n -> P (S n)) -> P n or something like that [Thu Nov 12 11:46:20 2015] but i dont know too much about things like functional induction [Thu Nov 12 11:46:54 2015] it gives you some extra hypotheses for reasoning about the return values of functions but i dont understand it too well [Thu Nov 12 11:49:53 2015] If you want to prove that a function satisfies a property, you will often have to repeat the precise sequence of "match...with" used when the function was defined [Thu Nov 12 11:50:31 2015] (e.g. if you prove properties about addition of natural numbers, you will proceed by induction on *the first argument* because _+_ was defined by inspecting the first argument) [Thu Nov 12 11:50:42 2015] ohhh i see! [Thu Nov 12 11:50:58 2015] functional induction automates this: it defines an induction principle corresponding to the call graph of the function [Thu Nov 12 16:47:42 2015] hello [Thu Nov 12 16:47:50 2015] hi vanila [Thu Nov 12 16:48:20 2015] I'm stuck with functional induction [Thu Nov 12 16:48:35 2015] paste code, paste error [Thu Nov 12 16:48:38 2015] https://bpaste.net/show/83ca6ecd0b5b [Thu Nov 12 16:49:07 2015] if I just use Fixpoint and no {measure ..} then i can derive a functional scheme, but what do you do when you are using Program and a measure? [Thu Nov 12 16:50:01 2015] {measure n}, and Program should be redundant on that first Fixpoint [Thu Nov 12 16:50:15 2015] it's pretty clear that that is structural induction [Thu Nov 12 17:06:06 2015] any ideas? [Thu Nov 12 17:42:52 2015] I want a functional induction scheme for a function defined with Program [Thu Nov 12 18:51:07 2015] is anyone familiar with coq Program? [Thu Nov 12 18:51:24 2015] I use Program all the time [Thu Nov 12 18:51:37 2015] your question is a bit more specific than that [Thu Nov 12 18:51:40 2015] know how to get functional induction scheme? [Thu Nov 12 18:53:43 2015] no [Thu Nov 12 18:53:50 2015] other than Functional Scheme, as you already put it [Thu Nov 12 18:56:32 2015] so how to prove something about a recursive function defined with program? [Fri Nov 13 02:12:57 2015] in ssreflect what is the idiomatic way of doing case analysis on the result of a boolean expression, so that I get [x = true] and [x = false] in the two subgoals? [Fri Nov 13 02:13:25 2015] normally I would do [destruct x eqn:?] but curious what the ssreflect-ese is for this [Fri Nov 13 05:34:06 2015] ; [Fri Nov 13 05:34:08 2015] gah [Fri Nov 13 12:58:41 2015] I have some goal [t = x], and I want to replace that goal by [u = x] and [t = u]. The problem is: the type of [u] is only propositionally equal to the type of [t] and [x]. What can I do? [Fri Nov 13 12:59:39 2015] To put it more clearly: [t : A], [x : A], [u : B], [H : A = B], and I want to from [t = x] to something along the lines of [u = x]. [Fri Nov 13 13:14:40 2015] can you use `subst` to rewrite A into B? [Fri Nov 13 13:15:32 2015] A and B are both expressions, not just one variable [Fri Nov 13 13:19:23 2015] dependent rewrite <- H in u [Fri Nov 13 13:41:17 2015] Thanks, I will try that kind of things whenever I can [Fri Nov 13 13:43:03 2015] then, I suppose you know how to use trans_eq ;) [Fri Nov 13 13:45:47 2015] I don't think it will work anyway in my case: u is also some expression, so actually I have [u := expr : B], and when I rewrite, Coq "forgets" u's expression. [Fri Nov 13 13:52:00 2015] aww [Fri Nov 13 16:07:43 2015] hello [Fri Nov 13 16:07:52 2015] is anyone good with Program? I can't get functional induction t owork with it [Fri Nov 13 22:49:57 2015] hello, I would really like to learn logic and I also like programming. So to me Coq sound like a new program to use [Fri Nov 13 22:50:14 2015] But where do I start learning logic and using Coq? [Fri Nov 13 22:50:22 2015] Any books you can recommend? [Fri Nov 13 22:51:05 2015] I have finished Calculus and Linear Algebra courses [Fri Nov 13 22:51:15 2015] if that is of any help [Fri Nov 13 22:52:19 2015] Thank you very much [Fri Nov 13 23:17:52 2015] Nik05: have you heard of software foundations by pierce et al? [Fri Nov 13 23:18:05 2015] https://www.cis.upenn.edu/~bcpierce/sf/current/index.html [Fri Nov 13 23:18:33 2015] that's a good intro to coq that focuses on functional programming ang logic [Sat Nov 14 08:05:38 2015] thank you jrw1 [Sat Nov 14 08:06:13 2015] I will take a look [Sat Nov 14 09:41:44 2015] jrw1 my little Haskell experience comes to great use :) [Sat Nov 14 12:59:08 2015] maybe i should stop now :P [Sat Nov 14 12:59:19 2015] I dont know how to prove false = true -> false = true.... [Sat Nov 14 13:00:02 2015] oh just an intro ofcourse [Sat Nov 14 13:00:12 2015] but why does reflexivity not work? [Sat Nov 14 13:02:00 2015] don't you want symmetry? [Sat Nov 14 13:02:22 2015] what do you mean? [Sat Nov 14 13:03:25 2015] oh sorry, thought the goal was true = false [Sat Nov 14 13:03:40 2015] I dont get it anymore... got the Hypothesis : flase = true [Sat Nov 14 13:03:44 2015] then you shoudl use assumption, or exact H (where H is the introduced hypothesis) [Sat Nov 14 13:03:47 2015] and need to prove false = true [Sat Nov 14 13:04:16 2015] ooh [Sat Nov 14 13:04:17 2015] yes, reflexivity is for solving a goal a=a [Sat Nov 14 13:05:13 2015] Im followng the book Software Foundations. And it has an exercise i need to solve. But the book didnt talk about exact or assumption yet [Sat Nov 14 13:06:01 2015] you also can use inversion there [Sat Nov 14 13:06:08 2015] because false=true is absurd [Sat Nov 14 13:07:02 2015] the book only really talked about intro, rewrite and reflexivity. [Sat Nov 14 13:07:10 2015] and destruct [Sat Nov 14 13:07:21 2015] oohhh [Sat Nov 14 13:07:26 2015] rewrite -> H [Sat Nov 14 13:07:30 2015] then reflexivity [Sat Nov 14 13:07:47 2015] ah like that, wow stupid me :P [Sat Nov 14 13:10:01 2015] how can I apply a command and if it fails, ignore the command? [Sat Nov 14 13:10:16 2015] I got 4 subgoals, and just need to do a rewrite on 2 of the goals [Sat Nov 14 13:10:21 2015] try foo [Sat Nov 14 13:11:02 2015] thank you :) [Sat Nov 14 13:12:41 2015] Got a last question: what is the difference between destruct a, b. and destruct a; destruct b. ? [Sat Nov 14 13:12:56 2015] no idea, sorry [Sat Nov 14 13:13:09 2015] must be explained in the tactics documentation [Sat Nov 14 13:13:13 2015] oke [Sat Nov 14 13:14:47 2015] hm it says destruct term1, .., termn is a shortcut for destruct term1; ..; destruct termn [Sat Nov 14 13:14:59 2015] really strange, because i get different results [Sat Nov 14 13:15:25 2015] or maybe not... [Sat Nov 14 13:15:31 2015] oke discard that :P [Sat Nov 14 13:30:56 2015] so listset seems kind of problematic, e.g. you can't prove that forall A eq (x : A) xs, ~set_In x (set_remove eq x xs). Do people roll their own instead or just use diff instead of remove? [Sat Nov 14 14:53:38 2015] hello [Sat Nov 14 14:54:05 2015] does anyone know an example of getting a functional induction scheme for a Program defined function (with measure)? [Sat Nov 14 14:54:28 2015] I can get it for a normal structurally recursive function but it's not giving me one for Program [Sat Nov 14 14:58:35 2015] vanila: I don't think Program supports that [Sat Nov 14 14:58:42 2015] oh darn it [Sat Nov 14 14:58:54 2015] I wonder how to get a functional scheme for a function defined with a measure then? [Sat Nov 14 14:59:11 2015] since i don't see how i'll prove facts about such functions otherwise [Sat Nov 14 14:59:20 2015] those induction schemes are very useful [Sat Nov 14 14:59:32 2015] in general, Program is not so good at proving stuff about already defined things [Sat Nov 14 14:59:40 2015] interesting [Sat Nov 14 14:59:46 2015] it works best when you incorporate all the things you want into the type of the function [Sat Nov 14 14:59:49 2015] and then do it all in one go [Sat Nov 14 14:59:53 2015] so I guess people generally use it for strongly specified functions [Sat Nov 14 14:59:57 2015] yep [Sat Nov 14 15:00:48 2015] vanila: you might be able to prove an induction principle using Program itself [Sat Nov 14 15:01:04 2015] i've never tried though [Sat Nov 14 15:02:50 2015] that's a nice idea! i'll try that [Sat Nov 14 22:05:36 2015] wow finally i proofed it :D [Sat Nov 14 22:05:58 2015] I should use more Lemmas to prove my theorem [Sat Nov 14 22:06:04 2015] much easier [Sat Nov 14 22:06:45 2015] who needs lemmas when you have assert [Sat Nov 14 22:06:47 2015] (just kidding) [Sat Nov 14 22:06:53 2015] ;p [Sat Nov 14 22:07:23 2015] i was messing around a lot, but i should just create some lemmas... [Sat Nov 14 22:07:37 2015] well almost finished first chapter of the Software Foundation [Sat Nov 14 22:08:38 2015] and another thing, dont start proofs with forall if you can just put it as an argument of your theorem [Sat Nov 14 22:08:59 2015] not sure if i explain this correctly :P [Sun Nov 15 08:41:08 2015] why is this coqide in windows so shit? [Sun Nov 15 08:41:30 2015] I cant even write ' or " [Sun Nov 15 08:41:39 2015] i should switch to linux [Sun Nov 15 11:30:14 2015] anyone know how to solve this problem with my keyboard in windows? [Sun Nov 15 11:30:35 2015] If i type " i get this in CoqIDE -> ¨ [Sun Nov 15 11:32:01 2015] and when i type ' i get -> ´ [Sun Nov 15 11:43:39 2015] that is strange [Sun Nov 15 11:43:49 2015] i cant really imagine what the problem there would be [Sun Nov 15 11:43:58 2015] make sure unicode mode isnt on? [Sun Nov 15 12:17:03 2015] sunnymilk how would i do that? [Sun Nov 15 12:37:23 2015] sunnymilk i think this is the same problem http://superuser.com/questions/440096/windows-pidgin-gtk-cannot-type-quotes-properly [Sun Nov 15 14:09:10 2015] sunnymilk i fixed the issue [Sun Nov 15 14:09:21 2015] looks like CoqIDE always presses + [Sun Nov 15 14:11:26 2015] ahhh [Sun Nov 15 19:58:37 2015] how could i prove 0 = b with the hypothesis 1 = S b? [Sun Nov 15 20:08:26 2015] Nik05: if I remember correctly, you have to use injectivity of inductive type constructors, but I don't remember the name tactic [Sun Nov 15 20:08:43 2015] oke i will try to find it [Sun Nov 15 20:09:38 2015] Oh you mean a = b -> S a = S b zozozo ? [Sun Nov 15 20:12:11 2015] im trying to prove S a = S b -> a = b [Sun Nov 15 20:14:13 2015] hm i proofed a = b -> S a = S b. [Sun Nov 15 20:14:23 2015] how do i rewrite 0 = b to 1 = S b? [Sun Nov 15 20:14:35 2015] rewrite doesnt seem to work [Sun Nov 15 20:42:35 2015] only auto works :P [Mon Nov 16 03:55:21 2015] Nik05: the tactic is simplify_eq [Mon Nov 16 05:35:31 2015] Nik05: actually, I was thinking about the "injectivity H" tactic, which given 'S a = S b' as hypothesis, should add 'a = b' to the context [Mon Nov 16 06:43:15 2015] oh oke thank you zozozo [Mon Nov 16 06:44:30 2015] and zyla [Mon Nov 16 06:45:21 2015] hm nice Coq 4.8 in Linux compiles different than 4.8 in Windows [Mon Nov 16 06:45:45 2015] Compiled library makes inconsistent assumptions over library Coq.Init.Notations [Mon Nov 16 06:59:50 2015] I guess the Windows version is just broken [Mon Nov 16 06:59:59 2015] changing shortcuts also doesnt do anything [Mon Nov 16 07:25:24 2015] I guess I will stay on Linux then :P [Mon Nov 16 08:04:25 2015] how would you prove something like "b + c + a' * b + a' * c = b + a' * b + c + a' * c"? [Mon Nov 16 08:04:45 2015] And then I mean, by using tactics. I already proved commutativity of + [Mon Nov 16 08:06:04 2015] Ah i think it just needs one assert [Mon Nov 16 08:06:15 2015] maybe with Ring? [Mon Nov 16 08:07:55 2015] H : a' * b + c = c + a' * b (* i have just asserted this *) [Mon Nov 16 08:08:16 2015] but when i try to rewrite my first line i posted here, it says found no subterm match ... [Mon Nov 16 08:08:50 2015] thank you companion_cube [Mon Nov 16 08:11:21 2015] I dont get why the rewrite doesnt work [Mon Nov 16 08:11:51 2015] Error: Found no subterm matching "plus (mult a' b) c" in the current goal. [Mon Nov 16 08:11:59 2015] @eq nat (plus (plus (plus b c) (mult a' b)) (mult a' c)) (plus (plus (plus b (mult a' b)) c) (mult a' c)) [Mon Nov 16 08:12:02 2015] last one is the goal [Mon Nov 16 08:12:38 2015] oh huh [Mon Nov 16 08:13:54 2015] is that my problem? [Mon Nov 16 08:14:31 2015] its not visible when low-level content is disabled [Mon Nov 16 08:16:59 2015] oh just when notation is turned off [Mon Nov 16 08:19:10 2015] http://lpaste.net/145374 >> would anyone know how to complete this proof, or provide an argument as to why it is not provable? [Mon Nov 16 08:20:39 2015] :q [Mon Nov 16 08:20:42 2015] duh [Mon Nov 16 08:21:24 2015] why doesnt a rewrite -> H. just work? [Mon Nov 16 08:22:08 2015] Because you need to abstract the body of g (or f) to do such a rewrite, and the typability of the conclusion relies on the fact that [f true] and [g true] are convertible [Mon Nov 16 08:23:15 2015] hm oke [Mon Nov 16 08:25:22 2015] Oke i finished the proof with just 4 rewrite :) [Mon Nov 16 08:25:29 2015] my own proof, not yours Cypi ... [Mon Nov 16 08:25:56 2015] ^^' [Mon Nov 16 08:27:34 2015] I wonder, doesn't that depend on functional extensionality? [Mon Nov 16 08:28:25 2015] I can use functional extensionality if needed [Mon Nov 16 08:28:31 2015] (I already use it somewhere else anyway) [Mon Nov 16 08:44:46 2015] Oke i do know i should take a break after spending some time on Coq [Mon Nov 16 08:45:13 2015] The proofs i was stuck on, I just all proved... [Mon Nov 16 09:42:37 2015] and stuck on another one [Mon Nov 16 11:57:21 2015] what am i doing... Im proving something really simple and I just got an stack overflow... [Mon Nov 16 11:57:57 2015] perhaps you're using numbers that are too large. [Mon Nov 16 11:58:19 2015] oh no i was usng rewrite -> !mult_comm [Mon Nov 16 11:58:33 2015] guess its applying the theorem on the same part over and over again [Mon Nov 16 11:58:54 2015] ah, yeah that'd likely do it [Mon Nov 16 11:59:58 2015] hi. is there any default interface/typeclass for natural numbers/integers in coq? because I want to prove stuff about natural numbers/integers, but in many cases I can just use omega, and I would like to not stick to a certain representation of them. [Mon Nov 16 12:00:18 2015] there is nat [Mon Nov 16 12:00:34 2015] i guess there are probably integers as well [Mon Nov 16 12:00:51 2015] Nik05: nat is one possible representation. but it takes up a lot of space. [Mon Nov 16 12:01:19 2015] Nik05: I thought maybe something like a typeclass that specifies the peano axioms or so. [Mon Nov 16 12:01:45 2015] I can write one myself, but if it already exists, then I would take it [Mon Nov 16 12:03:48 2015] https://coq.inria.fr/library/Coq.Init.Peano.html schoppenhauer [Mon Nov 16 12:04:45 2015] this has nothing to do with my question [Mon Nov 16 12:05:14 2015] Sorry I dont know anything about Coq or formal mathematics [Mon Nov 16 12:07:06 2015] :3 [Mon Nov 16 12:09:02 2015] oh this is nice. I got an error in coq and closed the program -_- [Mon Nov 16 12:09:14 2015] just because i forgot a . [Mon Nov 16 12:10:24 2015] And ofcourse i didnt save... [Mon Nov 16 12:13:02 2015] hm then what does autosave do? [Mon Nov 16 12:29:57 2015] Nik05: if you're in emacs and you're editing a file that currently exists on the drive, it will occassionally back it up in filename~ [Mon Nov 16 12:30:21 2015] if you're in an unsaved buffer, then there it doesn't back that up. [Mon Nov 16 12:31:10 2015] ianjneu CoqIDE... [Mon Nov 16 12:32:08 2015] I have no experience with that. [Mon Nov 16 12:33:47 2015] I don't got EmacsOS on my pc :P [Mon Nov 16 14:45:51 2015] there's no lemma in the standard library like "eq_nat_refl_neq (m n : nat) (p : m <> n) : eq_nat_refl m n = right p" is there? [Mon Nov 16 14:47:10 2015] i ask because it would be nice, given a proof that m <> n, one could say that (if eq_nat_dec m n then a else b) = b [Mon Nov 16 14:48:11 2015] doubtful. There aren't many theorems about the structure of proof objects, though the decideable equality for nats should make identity proofs unique. [Mon Nov 16 14:48:57 2015] you can use destruct (eq_nat_dec m n) to normalize that. [Mon Nov 16 14:49:15 2015] ianjneu: oh good point [Mon Nov 16 14:49:19 2015] duh [Mon Nov 16 14:49:22 2015] thanks [Tue Nov 17 13:32:13 2015] yo [Tue Nov 17 13:32:51 2015] lo [Tue Nov 17 13:33:43 2015] is there a tactic that can solve this https://gist.github.com/9f733774915ddc3858d5 [Tue Nov 17 13:34:03 2015] i dont think its too unreasonable to expect a tactic that can solve this :[ [Tue Nov 17 13:34:57 2015] intro x H0. rewrite H0. exact. [Tue Nov 17 13:35:06 2015] doesn't "intuition" work here? [Tue Nov 17 13:35:08 2015] does firstorder do it? [Tue Nov 17 13:35:26 2015] or yeah, firstorder being a bit lighter-handed than intuition [Tue Nov 17 13:36:07 2015] johnw: I thought firstorder was heavier than intuition [Tue Nov 17 13:36:44 2015] hmm [Tue Nov 17 13:36:50 2015] it looks like they are both extensions of tauto [Tue Nov 17 13:37:03 2015] firstorder certainly allows for more syntax, so you are probably right [Tue Nov 17 13:37:26 2015] tauto = intuition fail [Tue Nov 17 13:39:59 2015] tfw no crush [Tue Nov 17 14:27:01 2015] tfw? [Tue Nov 17 14:28:02 2015] "that feel when" [Tue Nov 17 14:28:10 2015] or "that feeling when" [Tue Nov 17 14:28:40 2015] also FYI, TIL = "today, I learned" [Tue Nov 17 14:28:45 2015] yeah, TIL I know [Tue Nov 17 14:28:49 2015] these young people [Tue Nov 17 14:28:54 2015] TIL TFW [Tue Nov 17 14:29:09 2015] smh = "shaking my head" [Tue Nov 17 14:29:20 2015] I have a macro in my IRC called /wtf that decodes most acronyms, but they are being created too rapidly for it to keep up [Tue Nov 17 16:36:16 2015] make it look it up in urbandictionary [Tue Nov 17 16:36:57 2015] ooh, good idea [Tue Nov 17 16:49:44 2015] 'tfw' is very much a chan ism [Tue Nov 17 17:00:12 2015] daily reminder to keep your subculture jargon where you found it [Tue Nov 17 17:02:54 2015] :I [Tue Nov 17 17:03:02 2015] sunnymilk: nonsense. [Tue Nov 17 17:03:24 2015] to be fair [Tue Nov 17 17:03:28 2015] chans are a pretty shitty subculture [Tue Nov 17 17:04:13 2015] use your judgment. "tfw" is not an expression of oppression than chan culture usually nutures. [Tue Nov 17 17:05:26 2015] If we mandated all subcultures cloister themselves off, then we get stuff like white supremacy and Jim Crow laws. [Tue Nov 17 17:06:04 2015] who defines what's "sub", "lesser", or "unimportant"? [Tue Nov 17 17:06:37 2015] sub as in subset not as in subhuman [Tue Nov 17 17:07:19 2015] Then your distinction is moot. All cultures are subsets of "culture" [Tue Nov 17 17:11:32 2015] the point at which you can reasonly expect almost everyone else to not understand your jargon is the point at which you should probably not use it [Tue Nov 17 17:12:25 2015] this point also differentiates between "where you found it" and everywhere else [Tue Nov 17 17:12:53 2015] Are you familiar with redlining? [Tue Nov 17 17:13:07 2015] not really [Tue Nov 17 17:13:36 2015] It's policy that denied housing to people of color in predominantly white areas. They didn't want them to spread their culture. [Tue Nov 17 17:13:40 2015] it's amazing how everything is about racism somehow [Tue Nov 17 17:14:16 2015] lol [Tue Nov 17 17:15:03 2015] vanila: if by 'racism' you mean 'human behavior operating under the same kind of dynamics as racism', then yes, it's pretty amazing [Tue Nov 17 17:15:24 2015] vanila: Racism is a prime example to illustrate power dynamics that lead to oppression and negative affect. There are plenty of communities that build more negative biases towards and actively push out people of other mindsets, background, group, etc. [Tue Nov 17 17:15:36 2015] wow, so how about that dependent type theory, guys [Tue Nov 17 17:15:41 2015] :^] [Tue Nov 17 17:15:51 2015] nah this is an interesting discussion johnw [Tue Nov 17 17:15:52 2015] don't ruin it [Tue Nov 17 17:15:57 2015] prove it :) [Tue Nov 17 17:16:40 2015] you could create #coq-blah to discuss it, maybe [Tue Nov 17 17:16:41 2015] johnw: classic deflection. [Tue Nov 17 17:17:02 2015] ;) [Tue Nov 17 17:17:16 2015] intuististic deflection is hard, because I have to provide an alternate subject [Tue Nov 17 17:17:26 2015] haha [Tue Nov 17 17:17:28 2015] nice [Tue Nov 17 17:17:33 2015] good one [Tue Nov 17 17:17:36 2015] hold on a second [Tue Nov 17 17:18:00 2015] that deflection is ill-formed [Tue Nov 17 17:18:08 2015] uh oh [Tue Nov 17 17:18:13 2015] you can't just use deflection as the alternate subject in a deflection [Tue Nov 17 17:18:17 2015] that's ill-founded [Tue Nov 17 17:18:26 2015] I'm using deflection[+1]? [Tue Nov 17 17:18:41 2015] hmmmmm [Tue Nov 17 17:18:45 2015] * summons the aid of impredicativity [Thu Nov 19 16:12:39 2015] hello everyone, i have a quick question about vim setting for coq. [Thu Nov 19 17:15:53 2015] nullcatxxx_: wwwwwwwwwwwwthe golden rule is to now ask to ask, but just ask. [Thu Nov 19 17:16:06 2015] ooh. terminal wedge there. anyway, just shoot. [Thu Nov 19 17:16:28 2015] s/now/not/ [Thu Nov 19 17:16:52 2015] it's more about vim setting i think. i'd like to have feature described in this issue https://github.com/the-lambda-church/coquille/issues/29 [Thu Nov 19 17:17:19 2015] i move cursor on a symbol. after some keystrokes, ":Coq Check xxx." is called [Thu Nov 19 17:17:21 2015] and i can see the result [Thu Nov 19 17:17:59 2015] i don't want to type ":Coq Check abcdefg." everytime [Thu Nov 19 17:18:02 2015] or Print [Thu Nov 19 17:18:13 2015] I go to the church of emacs myself, so I cannot help you infidel. [Thu Nov 19 17:18:26 2015] * smites nullcatxxx_ ! [Thu Nov 19 17:18:27 2015] does emacs have this feature..? [Thu Nov 19 17:19:07 2015] yes, with proofgeneral you can press C-c n and it will take you to the next statement automatically and show you the proof state [Thu Nov 19 17:19:37 2015] there's probably a key binding you can do with vim. [Thu Nov 19 17:19:49 2015] ok [Thu Nov 19 17:20:26 2015] oh wait, that's not what you actually asked. I do end up writing Check xxx a lot. [Thu Nov 19 17:20:39 2015] but there's no doubt a key binding for that. :) [Thu Nov 19 17:23:40 2015] i'd like to have one... [Thu Nov 19 17:23:43 2015] thanks anyway! [Thu Nov 19 17:27:01 2015] np. glad to have helped the best way I can. [Thu Nov 19 17:27:11 2015] sanooj : besides Software Foundations, what other resources do you recommend to learn Coq? [Thu Nov 19 17:27:14 2015] maybe someone else who lurks and knows shit will pick up on it. :) [Thu Nov 19 17:27:33 2015] well, I really like SF. I didn't complete all of it, but the bits I did were awesome. [Thu Nov 19 17:28:08 2015] CPDT is great [Thu Nov 19 17:28:11 2015] yes, I agree it is an awesomebook [Thu Nov 19 17:28:16 2015] oh i see [Thu Nov 19 17:28:42 2015] i highly recommend it [Thu Nov 19 17:28:51 2015] CPDT is pretty good too. it's a bit like "learn coq the hard way" [Thu Nov 19 17:29:17 2015] it's highly focused on automating things. [Thu Nov 19 17:29:23 2015] i see. i'll finish Pierce's book first. [Thu Nov 19 17:30:03 2015] I think it depends on what you want to do with coq. if you want to do practical software stuff then those are the way to go probably. [Thu Nov 19 17:30:39 2015] i see [Thu Nov 19 17:31:21 2015] if you want to do every day mathematics, then probably you need to get into things like the mathematical components library or the corn library and the research reports that go with them. [Thu Nov 19 17:32:14 2015] emm, one thing I would like to write is formalizing meta-theory of system f-omega [Thu Nov 19 17:32:16 2015] for example [Thu Nov 19 17:32:18 2015] I personally have spen way too much time learning ssreflect and mathematical components. I thought it would be the best fit for my application domain, but honestly I haven't put equivalent time into other roads. [Thu Nov 19 17:34:02 2015] that's quite out of my field I'm afraid, so I don't have anything useful to say about formalizing system f-omega. :/ [Fri Nov 20 13:36:23 2015] johnw: I saw your coq-club post about the register allocator. what exactly did you manage to prove vs what's left to prove? [Fri Nov 20 13:36:59 2015] so, for example, the proof that no register allocations overlap [Fri Nov 20 13:37:17 2015] in the end, this was achieved using decidability in a way that generates an "error result" if they do in fact overlap [Fri Nov 20 13:37:29 2015] I was unable to prove that given the current algorithm, they cannot ever overlap [Fri Nov 20 13:37:34 2015] even though I think this should be possible [Fri Nov 20 13:37:49 2015] I see, makes sense. [Fri Nov 20 13:38:00 2015] in Spill.v and Split.v, you'll see lots of "jww" comments about things I'm deciding on that should be provable [Fri Nov 20 13:38:20 2015] you mentioned in your post something about "coverage". what exactly do you mean by that? [Fri Nov 20 13:38:23 2015] however, determing the evidence required was beyond the context provided (or my skills), which leads me to think that the code needs to become more proof-carrying to allow this [Fri Nov 20 13:38:39 2015] coverage meaning: there is a theorem governing every aspect of the defined semantics [Fri Nov 20 13:40:59 2015] so you're saying that there's code in this program that hasn't had anything proved about it? or is it more that some code hasn't had *everything possible* proved about it? [Fri Nov 20 13:41:07 2015] correct [Fri Nov 20 13:41:18 2015] for example, computing loop depths for basic blocks [Fri Nov 20 13:41:35 2015] that code is purely just a functional algorithm, no proofs whatsoever that the loop depths so computed are correct with respect to the code flow [Fri Nov 20 13:42:29 2015] which might cause us to make a poor choice of where to spill a variable; it won't lead to an incorrect allocation, but technically speaking it's not correct either; they could be random values for all I _know_ [Fri Nov 20 13:43:48 2015] another one, and this is much more important, is calculating the live sets for entry and exit of blocks [Fri Nov 20 13:43:57 2015] proofless code, once again [Fri Nov 20 13:43:58 2015] cool. one last question: it sounds so far like nothing you've mentioned can affect correctness per se, because you either error out, in which case the caller will have to handle that error, or you make a suboptimal choice. is that fair? or are there ways in which correctness could be violated? [Fri Nov 20 13:44:29 2015] if live set calculation were wrong, I'd inject an incorrect move resolution, and I wouldn't know that it had happened [Fri Nov 20 13:44:39 2015] the runtime verifier would catch that, but the code wouldn't stop it from happening [Fri Nov 20 13:45:17 2015] I don't even think that proving live set calculation correct is even hard; I just lacked enough days in the week to do it all [Fri Nov 20 13:45:42 2015] the file Spec.v contains all the theorems that were proven about correctness that have no computational bearing on the extraction [Fri Nov 20 13:47:14 2015] do you have any sense of how much more time you would have needed to finish the proofs to your own satisfaction? [Fri Nov 20 13:47:20 2015] my final takeaway: I should have written this in Haskell, and used Coq for the runtime verifier, and then spent the extra time on an exhaustive test suite [Fri Nov 20 13:47:52 2015] to my satisfaction? Perhaps another six months. I have a feeling that there would need to be some redesign to enable sufficient propagation of the required evidence [Fri Nov 20 13:48:21 2015] cool, it's an interesting project. thanks for sharing :) [Fri Nov 20 13:48:23 2015] note: I am happy with how certain segments of the code turned out [Fri Nov 20 13:48:40 2015] for example, the code dealing with use positions, range and intervals, is 100% proven [Fri Nov 20 13:49:10 2015] and since that's the foundation of the algorithm, it's very valuable to have that level of certainty [Fri Nov 20 13:49:38 2015] the code that allocates registers is also very solid [Fri Nov 20 13:49:56 2015] but the code that assigns registers, and thus generates spills and restores, and resolving moves based on the live set information, that code is the Wild West, effectively [Fri Nov 20 13:50:47 2015] it was also the code "written at the end", when time pressures started forcing me to throw correctness out the window to produce something that functioned [Fri Nov 20 13:51:26 2015] I've written an experience report on this implementation that was rejected for CPP, but hopefully after incorporating the reviewer's feedback, I'll be able to present at another venue next year [Fri Nov 20 13:51:56 2015] thanks for asking, jrw [Fri Nov 20 13:52:56 2015] nice. I'd be interested to look at a draft of the experience report if/when one is available. [Fri Nov 20 13:53:37 2015] jrw: sure, I'll send you one after I've incorporated the recent feedback [Fri Nov 20 13:53:46 2015] thanks :) [Tue Nov 24 22:16:10 2015] Is the "induction principle" generated by "Scheme" referring to a proof term? [Thu Nov 26 15:20:29 2015] I'm a beginner with coq. I have the term n*1 = n that I want to prove... how can I get coq to see that? [Thu Nov 26 15:21:40 2015] nevermind [Thu Nov 26 15:23:00 2015] rather, I have n + m = n* 1 + m* 1 [Thu Nov 26 15:23:06 2015] and I have a lemma that already proves that [Thu Nov 26 15:23:24 2015] and I want to rewrite it with something that matches just one of the variables at a time on one side of the = [Thu Nov 26 17:41:46 2015] I have this inductive hypothesis in my local context [Thu Nov 26 17:41:52 2015] I would like to unify p with S p [Thu Nov 26 17:41:54 2015] IHp : (n + m) * p = n * p + m * p [Thu Nov 26 17:43:36 2015] because I have something identical, and if I could just rewrite one side they would be reflexive [Thu Nov 26 20:26:48 2015] KaneTW pasted “No title” at http://lpaste.net/9193144310428598272 [Thu Nov 26 20:26:56 2015] i'm trying to prove that ^ is well-founded [Thu Nov 26 20:27:19 2015] but i'm kind of stuck. i want to reduce that to well-foundedness of lt [Mon Dec 21 18:22:42 2015] strange code also doesnt work on linux... [Mon Dec 21 18:23:49 2015] I got the file Basics.v from Software Foundations which defines evenb for natural numbers [Mon Dec 21 18:24:25 2015] In the file Induction.v Basics is mentioned in "Require Export Basics." [Mon Dec 21 18:25:06 2015] When I click on go to end everything goes fine, but if I try to compile the buffer it says. "Error: The reference evenb was not found in the current encironment" [Mon Dec 21 18:34:43 2015] hi, anyone around? [Mon Dec 21 18:35:36 2015] hello MitchellSalad [Mon Dec 21 18:37:58 2015] hi, moment... making an lpaste with my question [Mon Dec 21 18:39:06 2015] ok: http://lpaste.net/147621 [Mon Dec 21 18:39:48 2015] I'm working through a simple proof that involves unfolding a function definition, and now I want to fold the RHS back up to apply the induction hypothesis [Mon Dec 21 18:40:28 2015] but I'm getting an error (see paste), and I'm not sure what the right syntax is to get around it, although I do understand the problem [Mon Dec 21 18:41:40 2015] I don't know much about Coq. But I do know Haskell so folds oke :P [Mon Dec 21 18:42:15 2015] heh, ok. well this is #coq [Mon Dec 21 18:42:35 2015] I know :P [Mon Dec 21 18:45:14 2015] hi MitchellSalad [Mon Dec 21 18:45:24 2015] hi [Mon Dec 21 18:45:52 2015] did you just join the channel? I have joins turned off. I can re-post my question if you can't see it [Mon Dec 21 18:45:52 2015] there are many times when you can't refold [Mon Dec 21 18:45:58 2015] I'm always here [Mon Dec 21 18:46:01 2015] I see your question [Mon Dec 21 18:46:04 2015] ok [Mon Dec 21 18:46:34 2015] so, is this one of those times? [Mon Dec 21 18:46:58 2015] let me check [Mon Dec 21 18:47:29 2015] where is your definition of fold? [Mon Dec 21 18:48:00 2015] oh im interrested in that as well [Mon Dec 21 18:48:57 2015] oh, edited the paste. it's just foldr [Mon Dec 21 18:50:25 2015] so, do you want the answer, or just a hint? [Mon Dec 21 18:50:38 2015] I guess a hint :) [Mon Dec 21 18:51:00 2015] it seems like I should be able to rewrite the unfolded fold_length as just fold_length, though [Mon Dec 21 18:51:01 2015] instead of refolding fold, thinking about how you could further simplify your goal [Mon Dec 21 18:51:11 2015] alternatively, consider whether you have a rewrite available [Mon Dec 21 18:51:46 2015] because you're one rewrite away from reflexivity, at the point where you are stuck [Mon Dec 21 18:52:06 2015] i am? [Mon Dec 21 18:52:09 2015] yes [Mon Dec 21 18:52:24 2015] oh [Mon Dec 21 18:52:40 2015] got it :D thanks [Mon Dec 21 18:52:43 2015] :) [Mon Dec 21 18:53:23 2015] oke now im going to try to solve it [Mon Dec 21 18:56:58 2015] Oh it was that simpl [Mon Dec 21 18:57:03 2015] lol [Mon Dec 21 18:57:12 2015] simple* [Mon Dec 21 18:59:04 2015] fold_length (x :: l') = S (fold_length l') [Mon Dec 21 19:00:48 2015] how can you prove that with just reflexivity? [Mon Dec 21 19:02:08 2015] just unfold fold_length; reflexivity. [Mon Dec 21 19:03:38 2015] i dont even need to do an unfold [Mon Dec 21 19:05:41 2015] Nik05 : those two terms are convertible, so reflexivity will solve that. In other words, they have the same normal form [Mon Dec 21 19:06:03 2015] oke [Mon Dec 21 19:07:30 2015] when i unfold fold. I see :: is used in my subgoal window instead of cons. How would I be able to use the :: in my script? [Mon Dec 21 19:07:49 2015] I get Unknow interpretation for notation [Mon Dec 21 19:07:53 2015] import the list notations [Mon Dec 21 19:08:37 2015] Module Import LN := ListNotations. [Mon Dec 21 19:09:24 2015] or just [Import ListNotations.] [Mon Dec 21 19:09:30 2015] ah, good to know! [Mon Dec 21 19:09:49 2015] Cypi Error: ListNotations is not a module [Mon Dec 21 19:10:19 2015] You need [Require Import List.] beforehand, sorry [Mon Dec 21 19:10:46 2015] Ah oke, I didnt had the Import there [Mon Dec 21 19:11:00 2015] still trying to do Software Foundations chapter 3... [Mon Dec 21 19:11:07 2015] But Coq cant compile it :( [Mon Dec 21 19:11:27 2015] can't compile SF, or can't compile what you've added to it? [Mon Dec 21 19:11:30 2015] which version of Coq? [Mon Dec 21 19:11:38 2015] johnw the beta [Mon Dec 21 19:11:46 2015] 8.5rc1 came out today [Mon Dec 21 19:11:46 2015] 8.5 [Mon Dec 21 19:11:51 2015] good luck getting SF to build with it though [Mon Dec 21 19:12:10 2015] johnw yes it came out 3 days ago. Had problems on my Windows [Mon Dec 21 19:12:18 2015] It keeped crashing in Windows [Mon Dec 21 19:12:24 2015] what came out 3 days ago? [Mon Dec 21 19:12:25 2015] In linux I get the compile errors [Mon Dec 21 19:12:28 2015] the rc1 [Mon Dec 21 19:12:28 2015] Hmm, I wonder if putting the time to produce a diff for a 8.5 SF would be worth it [Mon Dec 21 19:12:32 2015] ah, I only saw the rc1 announcement today [Mon Dec 21 19:12:47 2015] Cypi: I'd wait until after release [Mon Dec 21 19:12:59 2015] there, Nix is now updated with 8.5rc1 [Mon Dec 21 19:13:08 2015] it works with ssreflect 1.6 too, as does 8.4pl6 [Mon Dec 21 19:13:30 2015] But why would it be hard to get SF compiled with it? [Mon Dec 21 19:13:38 2015] THe first 3 chapters are really basic... [Mon Dec 21 19:13:40 2015] I don't know if Pierce actually has plans to update SF. Probably? [Mon Dec 21 19:13:58 2015] And I already get errors when compiling the 2nd chapeter\ [Mon Dec 21 19:14:18 2015] I'm sure he will at some point [Mon Dec 21 19:14:23 2015] it's a course they still teach [Mon Dec 21 19:14:59 2015] Actually, I'm surprised you have trouble compiling [Mon Dec 21 19:15:19 2015] Is it the Require Export Basics? [Mon Dec 21 19:15:20 2015] -I changed its meaning [Mon Dec 21 19:15:25 2015] oh [Mon Dec 21 19:15:25 2015] constructors require additional arguments now [Mon Dec 21 19:15:31 2015] there are a few major things that need tightening up [Mon Dec 21 19:15:32 2015] I just compiled the first files (Basics, Induction, Lists) without any problems [Mon Dec 21 19:15:38 2015] really Cypi ? [Mon Dec 21 19:15:41 2015] ah, nice [Mon Dec 21 19:15:48 2015] Error: The reference evenb was not found in the current [Mon Dec 21 19:15:50 2015] maybe they fixed those gratuitous incompatibilities [Mon Dec 21 19:15:50 2015] environment. [Mon Dec 21 19:15:59 2015] oh this is beta im on... [Mon Dec 21 19:16:03 2015] let me get the rc1... [Mon Dec 21 19:16:04 2015] Well, I think so. Let me make sure I have a fresh version of SF. [Mon Dec 21 19:17:11 2015] "coqc Basics.v Induction.v Lists.v" just works out of the box for me [Mon Dec 21 19:17:18 2015] hm strange [Mon Dec 21 19:17:57 2015] Ah, I start having troubles at Poly.v though :) [Mon Dec 21 19:17:59 2015] I just downloaded sf again and tried it on a fresh one. Still got the error [Mon Dec 21 19:18:11 2015] as johnw, because of constructors which require additional arguments [Mon Dec 21 19:18:17 2015] But what does it mean the reference was not found in the current environment? [Mon Dec 21 19:18:36 2015] there's a way to revert back to the old constructor behavior [Mon Dec 21 19:18:40 2015] it's in the NEWS file [Mon Dec 21 19:19:04 2015] It basically means that "evenb" is not defined, that's all [Mon Dec 21 19:19:12 2015] so probably a problem of modules that are not correctly imported [Mon Dec 21 19:19:18 2015] Oke [Mon Dec 21 19:19:44 2015] Really strange. In CoqIDE can just proof everything [Mon Dec 21 19:19:51 2015] but when I compile i get the error [Mon Dec 21 19:20:02 2015] so CoqIDE knows evenb but the compiler doesnt... [Mon Dec 21 19:20:09 2015] or something probably the same thing i dont know [Mon Dec 21 19:20:23 2015] So, if you do "coqc Basics.v Induction.v Lists.v", you get an error? Also, "coqc -v" returns the expected version of Coq? [Mon Dec 21 19:21:03 2015] h [Mon Dec 21 19:21:09 2015] Oh, I know, maybe [Mon Dec 21 19:21:14 2015] have you indeed compiled Basics.v? [Mon Dec 21 19:21:40 2015] If I just do "coqc Induction.v", I get your error, so I hope that's just that [Mon Dec 21 19:21:43 2015] Cypi coqc Basics.v Induction.v Lists.v gives no errors [Mon Dec 21 19:21:50 2015] Well, there you go then ^^' [Mon Dec 21 19:22:00 2015] but but.... [Mon Dec 21 19:22:14 2015] Don't ask what CoqIDE did, I have no idea I must say :p [Mon Dec 21 19:22:18 2015] :P [Mon Dec 21 19:23:45 2015] well it probably cant find Basics or something.... [Mon Dec 21 19:23:56 2015] well atleast I can continue now [Mon Dec 21 19:24:21 2015] With Lists.v [Mon Dec 21 19:24:41 2015] nope still not [Mon Dec 21 19:24:49 2015] Cypi Unable to locate library Induction [Mon Dec 21 19:24:57 2015] it didnt create the library... [Mon Dec 21 19:25:42 2015] This is confusing... So, there is no "Inductiion.vo" file in your folder? [Mon Dec 21 19:25:55 2015] -i [Mon Dec 21 19:26:00 2015] there is... [Mon Dec 21 19:26:14 2015] hum. [Mon Dec 21 19:26:54 2015] Hmm. Maybe the working directory of CoqIDE is not the correct one. [Mon Dec 21 19:26:55 2015] og wait [Mon Dec 21 19:27:16 2015] I guess by clicking on Compile -> Compile Buffer, something strange happend again [Mon Dec 21 19:27:23 2015] so I did another coqc and now it works [Mon Dec 21 19:28:26 2015] Hum, ok [Mon Dec 21 19:30:18 2015] thank you Cypi and johnw [Mon Dec 21 19:30:37 2015] I hope coq in Windows gets fixed as well... [Mon Dec 21 19:31:11 2015] The bar in the new CoqIDE is really nice [Tue Dec 22 08:37:57 2015] * just found out about SearchAbout [Tue Dec 22 08:38:12 2015] Is there a command window in CoqIDE? [Tue Dec 22 08:38:45 2015] using SearchAbout in script and then remove it after usage is not really prefered [Tue Dec 22 08:41:15 2015] oh there is Queries -> Search [Tue Dec 22 08:41:33 2015] but it doesnt work on Notation it seems [Tue Dec 22 08:41:56 2015] oh SearchAbout also doesnt work on notations [Tue Dec 22 08:57:57 2015] oke wow [Tue Dec 22 08:58:20 2015] Sometimes it just goes over Qed. even though the proof has not been given yet [Tue Dec 22 08:58:37 2015] in the Coq 8.5b3 [Tue Dec 22 08:58:48 2015] strange [Tue Dec 22 08:59:06 2015] what do you mean? [Tue Dec 22 08:59:58 2015] I got an unfinished proof and I clicked go to end. It goes to the end but does give an error for that proof [Tue Dec 22 09:00:23 2015] when I got to the proof and use the forward command it just steps over the proof and doesnt give any errors anymore [Tue Dec 22 09:01:35 2015] And now it doesnt [Tue Dec 22 09:01:39 2015] its a little bugged [Tue Dec 22 09:01:49 2015] Oke now it keeps complaining [Tue Dec 22 09:02:35 2015] artart78 i cant reproduce it now [Tue Dec 22 09:03:04 2015] But it is pretty nice how it does checks in the future [Tue Dec 22 09:06:22 2015] artart78 it looked like it was admitting the proof but it marked it as proofed [Tue Dec 22 09:09:08 2015] well if you can't reproduce then that's good lol [Tue Dec 22 09:13:12 2015] no that is not good :P [Tue Dec 22 09:13:24 2015] artart78 are you a dev? [Tue Dec 22 09:14:32 2015] nope [Tue Dec 22 09:14:40 2015] CoqIDE is able to see, sort of, if the content of a proof is independent of the rest of the file [Tue Dec 22 09:14:54 2015] if so, then it can just assume the proof is correct (even if it is not) to compile the rest of the file [Tue Dec 22 09:15:03 2015] sometimes it can, sometimes it can't [Tue Dec 22 09:15:08 2015] Cypi you that is really nice [Tue Dec 22 09:15:17 2015] but it also gives an error that the proof isnt solved yet [Tue Dec 22 09:15:27 2015] but i just got that it didnt give an error at all [Tue Dec 22 09:15:47 2015] but cant reproduce it, it gives errors again, which is good :P [Tue Dec 22 09:20:22 2015] I have to go, have a good day. [Tue Dec 22 21:05:55 2015] Where should I look at if I want to do real analysis on coq? [Tue Dec 22 21:06:07 2015] There are some papers about it, but nothing like a tutorial...ç [Tue Dec 22 21:14:58 2015] elpetrero: it's probably gonna be a pain in the ass, i can tell you that much [Tue Dec 22 21:15:07 2015] as far as i can tell coq isn't too great at working with very set-y stuff [Tue Dec 22 21:17:39 2015] is there another theorem prover more suited for set-y stuff? [Tue Dec 22 21:19:24 2015] What is set-y stuff? [Tue Dec 22 21:19:34 2015] well proof assistant [Tue Dec 22 21:19:52 2015] Nik05: standard math basically [Tue Dec 22 21:19:59 2015] standard analysis* [Tue Dec 22 21:20:19 2015] oke [Tue Dec 22 22:23:11 2015] how would i prove (if c then x + z else y + z) = (if c then x else y) + z ? [Tue Dec 22 22:24:29 2015] by "destruct c" and then reflexivity? [Tue Dec 22 22:26:04 2015] ah yes sorry. c = beq_nat a b [Tue Dec 22 22:26:23 2015] Then "destruct (beq_nat a b)" :p [Tue Dec 22 22:26:27 2015] oh [Tue Dec 22 22:26:32 2015] its that simpl [Tue Dec 22 22:26:39 2015] as long as it's the same 'c' in both sides, that should go fine [Tue Dec 22 22:26:45 2015] oke [Tue Dec 22 22:27:21 2015] it worked :) [Tue Dec 22 22:28:02 2015] Thank you Cypi :P [Tue Dec 22 22:43:20 2015] Oh man, finding the proof is so hard. Even though the proof can be so simple... [Tue Dec 22 22:43:42 2015] Wanted to prove this. rev l1 = rev l2 → l1 = l2 [Tue Dec 22 22:44:34 2015] Tried induction, couldn't get it. Turns out it was just 3 rewrites. I had already proven rev rev l = l... [Tue Dec 22 23:15:20 2015] So what was the thing in Poly.v about constructors that has changed in 8.5? [Wed Dec 23 08:40:27 2015] So in 8.5 you now need to add an argmument to all your contructors of polymorphic data types? [Wed Dec 23 12:18:41 2015] Nik05: only if you don't enable the compatability flag [Wed Dec 23 12:18:47 2015] or make those arguments implicit some other way [Wed Dec 23 12:19:01 2015] thank you johnw [Wed Dec 23 16:22:54 2015] johnw where can i find information on why it is changed? [Wed Dec 23 16:23:44 2015] you could ask on the Coq-club mailing list [Wed Dec 23 16:23:46 2015] I don't know why [Wed Dec 23 16:23:53 2015] Oke [Thu Dec 24 15:02:37 2015] has anyone else here, not involved with MIT, ever played with Fiat? [Thu Dec 24 15:07:20 2015] whats that [Thu Dec 24 15:08:59 2015] http://plv.csail.mit.edu/fiat/ [Thu Dec 24 15:09:14 2015] it's a program synthesis system built on Coq [Thu Dec 24 15:10:05 2015] for some reason i thought adam chlipala was xplat [Thu Dec 24 15:10:07 2015] idk why [Thu Dec 24 15:10:29 2015] he's Smerdyakov on IRC [Thu Dec 24 15:10:53 2015] is there any docu for this [Thu Dec 24 15:11:38 2015] see the aformentioned URL [Thu Dec 24 15:12:19 2015] they have a POPL paper that is quite good [Thu Dec 24 15:14:10 2015] m [Thu Dec 24 15:14:49 2015] I was just curious if anyone else had tried using it for anything [Thu Dec 24 19:28:14 2015] Favorite quote of the day from someone's master's thesis: "This may be an instance of a more general phenomenon present when programming with dependent types: subtle friction between what you think you are doing and what you are actually doing often manifests as impossible proof goals." [Thu Dec 24 19:31:42 2015] nice [Thu Dec 24 19:31:43 2015] n i ce, nice [Thu Dec 24 19:32:01 2015] is there a tweet of that i can retweet [Thu Dec 24 19:33:03 2015] no [Thu Dec 24 19:33:20 2015] it's by jgross [Thu Dec 24 19:38:40 2015] neat [Thu Dec 24 19:39:47 2015] wait, did he just publish his thesis or did you just read it today [Thu Dec 24 19:42:44 2015] I have a pre-release copy [Thu Dec 24 19:42:52 2015] cool [Thu Dec 24 19:42:57 2015] it's really good too, look for it when it hits bookstores near you ;) [Thu Dec 24 19:43:31 2015] as of now ive ran into him 3 times as the teacher of mit esp classes i signed up for [Thu Dec 24 20:49:34 2015] to what extent does HoTT eliminate the need for sets when talking about quotients [Thu Dec 24 20:49:47 2015] like, in practice [Thu Dec 24 20:50:31 2015] if i knew hott properly and i opened up coq in hott, could i go and define the reals using cauchy sequences and then feasibly reason about them without having to resort to manipulating sets? [Sat Dec 26 11:46:37 2015] Goodmorning [Sat Dec 26 12:29:16 2015] hey Nik05 [Sat Dec 26 12:30:16 2015] hey benzrf [Sat Dec 26 19:24:15 2015] Hello [Sat Dec 26 19:25:55 2015] in the SF there is an exercise to prove forall (n m o p : nat), m = (minustwo o) -> (n + p) = m -> (n + p) = (minustwo o). And it should be done with an `apply with`. But how? [Sat Dec 26 19:27:18 2015] I can do a rewrite and then an apply... [Sat Dec 26 19:27:42 2015] * still don't get the usage of apply. Now it just seams like an rewrite. reflexivity. [Sat Dec 26 20:30:11 2015] oh I guess I know what apply does [Sat Dec 26 20:30:48 2015] Now inversion, and apply with [Wed Dec 30 18:54:01 2015] I learned haskell some time ago. I read about Coq also being a functional programming language, but you could prove thing with it. I like it, but I need to know some more theory to understand constructive logic and differnece with classical logic. Does someone have some reading material? [Wed Dec 30 18:59:13 2015] Nik05: you're reading software foundations, right? [Wed Dec 30 18:59:34 2015] yes [Wed Dec 30 19:00:25 2015] have you done the Logic chapter? [Wed Dec 30 19:00:38 2015] correct [Wed Dec 30 19:00:42 2015] uh i mean yes [Wed Dec 30 19:01:06 2015] okay, I feel like that chapter is a decent introduction to the relevant issues. what do you want to know more about? [Wed Dec 30 19:01:30 2015] you did the exercises classical_axioms and excluded_middle_irrefutable? [Wed Dec 30 19:02:14 2015] I could prove the equivalence of the classical axioms [Wed Dec 30 19:02:23 2015] I did do the excluded middle irrefutable [Wed Dec 30 19:02:30 2015] Can we start with the last? [Wed Dec 30 19:02:38 2015] This theorem implies that it is always safe to add a decidability [Wed Dec 30 19:02:47 2015] axiom" [Wed Dec 30 19:03:15 2015] What do they mean there? [Wed Dec 30 19:03:41 2015] they mean that if you add a decidability axiom (an instance of LEM) then the resulting system is still consistent [Wed Dec 30 19:05:04 2015] How does that theorem imply that? [Wed Dec 30 19:05:45 2015] oh wait [Wed Dec 30 19:05:47 2015] okay let's say P0 is a particular proposition, and suppose adding P0 \/ ~ P0 as an axiom was inconsistent [Wed Dec 30 19:06:01 2015] then we would have a proof of false based on that axiom [Wed Dec 30 19:06:03 2015] oke? [Wed Dec 30 19:06:34 2015] so in other words we'd have a proof (P0 \/ ~ P0 -> False), or in yet other words, a proof of ~ (P0 \/ ~ P0) [Wed Dec 30 19:06:59 2015] ah oke [Wed Dec 30 19:07:04 2015] but the irrefutability of LEM says forall P, ~ (~ (P \/ ~ P)) [Wed Dec 30 19:07:24 2015] and the proof of ~ (P0 \/ ~ P0) would contradict that by plugging in P0 for P [Wed Dec 30 19:07:57 2015] so if coq without axioms is consistent, then irrefutability of LEM shows that coq-with-instance-of-LEM is also consistent [Wed Dec 30 19:08:10 2015] Ah I get it [Wed Dec 30 19:08:17 2015] thank you jrw [Wed Dec 30 19:08:21 2015] np [Wed Dec 30 19:08:35 2015] Is it hard to prove the equivalent of the classical axioms? [Wed Dec 30 19:09:19 2015] I thought you said you did it :p [Wed Dec 30 19:09:31 2015] no i couldnt prove them [Wed Dec 30 19:09:39 2015] oh, okay :) depending on how exactly you go about it, some parts will be easy and some will be hard [Wed Dec 30 19:10:22 2015] which one is the easiest? :P [Wed Dec 30 19:10:48 2015] to prove 5 things equivalent, the most "efficient" way is to pick an ordering and then to prove the first implies the second, the second implies the third, ... and the fifth implies the first [Wed Dec 30 19:11:00 2015] that was my idea [Wed Dec 30 19:11:11 2015] some of those implications are harder than others, though [Wed Dec 30 19:11:32 2015] Yes, do you know which one is not the hardest? [Wed Dec 30 19:11:35 2015] classic -> excluded middle should be relatively easy [Wed Dec 30 19:11:40 2015] oke [Wed Dec 30 19:12:03 2015] I tried peirce -> classic, but was stuck [Wed Dec 30 19:12:12 2015] anything with peirce is hard [Wed Dec 30 19:12:19 2015] oh oke :P [Wed Dec 30 19:13:19 2015] well thank you jrw, will try to work on it now [Wed Dec 30 19:13:29 2015] cool, good luck! [Wed Dec 30 19:15:14 2015] oh that one is much easier than perice -> classic [Wed Dec 30 19:16:38 2015] the other thing to remember about all of these is that they all have short proofs, but the proofs are hard to find [Wed Dec 30 19:16:47 2015] oke [Wed Dec 30 19:20:54 2015] hi Nik05 [Wed Dec 30 19:21:09 2015] peirce -> classic is hard, come back to it later [Wed Dec 30 19:21:25 2015] all of those proofs are short, but most of them are highly non-obvious [Wed Dec 30 19:21:36 2015] Oke thank you [Wed Dec 30 19:21:51 2015] I certainly did not solve them on the first go [Wed Dec 30 19:21:56 2015] more like the 8th attempt a month later :) [Wed Dec 30 19:26:29 2015] oh, well we will see :) [Wed Dec 30 19:52:38 2015] how can i specialize an hypothesis and leave the general hypothesis? [Wed Dec 30 19:53:08 2015] oh a remember works [Wed Dec 30 19:53:17 2015] oh cant [Wed Dec 30 19:53:18 2015] wait [Wed Dec 30 20:02:50 2015] Oke is this my lack in knowledge on Logic or [Wed Dec 30 20:03:25 2015] johnw oh its johnw not jrw. Why cant i specialize and forall P, ... for a proposition P and one for Q? [Wed Dec 30 20:04:07 2015] ... i specialize a hypothesis forall ... * [Wed Dec 30 20:04:30 2015] can I see the theorem type? [Wed Dec 30 20:05:47 2015] (P \/ ~P) -> ~(~P /\ ~Q) -> P\/Q [Wed Dec 30 20:06:00 2015] is what i want to prove [Wed Dec 30 20:06:11 2015] ok, so what was your question? [Wed Dec 30 20:07:09 2015] sorry thats not correct (∀P, P \/ ~P) -> ∀P Q, ~(~P /\ ~Q) -> P\/Q [Wed Dec 30 20:07:31 2015] how can i specialize the hypothesis (∀P, P \/ ~P)? [Wed Dec 30 20:11:23 2015] Nik05: if the hypothesis is named H and you want to specialize it to x, you can say "pose proof H x" [Wed Dec 30 20:12:01 2015] there's probably also a way to do it using only tactics SF has taught you, but I don't remember [Wed Dec 30 20:12:12 2015] ah oke [Wed Dec 30 20:12:18 2015] that will help me, thank you [Wed Dec 30 20:12:27 2015] so what does `specialize` do then? [Wed Dec 30 20:12:41 2015] specialize "updates" H in place [Wed Dec 30 20:12:51 2015] ah oke [Wed Dec 30 20:12:52 2015] but you want to copy it [Wed Dec 30 20:13:18 2015] yes, so i tried remember, but that creates a third hypothesis: H = Hspec [Wed Dec 30 20:15:30 2015] maybe it doesnt help me... [Wed Dec 30 20:18:53 2015] or also: specialize (H x). [Wed Dec 30 20:25:24 2015] yes i finished it :) [Wed Dec 30 20:33:16 2015] I like this prove [Wed Dec 30 20:34:24 2015] http://lpaste.net/6903500333012484096 [Wed Dec 30 20:39:47 2015] but any idea how to do it without pose proof and specialize? Because I havent seen it in SF. [Wed Dec 30 20:43:25 2015] Nik05: one way would be to use assert [Wed Dec 30 20:43:38 2015] you have to write out the conclusion though :\ [Wed Dec 30 20:44:08 2015] ah oke [Wed Dec 30 20:51:38 2015] oh this one is really simple [Wed Dec 30 20:52:01 2015] had a pretty long proof but i did some circular things i could remove [Wed Dec 30 20:52:29 2015] This one is really simple. http://lpaste.net/3668674061090684928 [Wed Dec 30 20:56:01 2015] now the peirce ones [Wed Dec 30 21:21:12 2015] I like the LEM to de Morgan prove. Peirce I have no idea how. [Wed Dec 30 21:29:40 2015] There's this really neat way of describing the proof of Peirce -> LEM, where you show that, with a time machine, the devil can offer you the deal of either a million dollars, or the granting of any wish for the price of a million dollars (he gets to chose). ^.^ [Wed Dec 30 21:30:08 2015] lol [Wed Dec 30 21:34:31 2015] http://math.stackexchange.com/questions/447098/why-peirces-law-implies-law-of-excluded-middle [Wed Dec 30 21:35:08 2015] whats all the delta, iota, alpha, gamma etc? [Wed Dec 30 21:35:28 2015] lambda calculus? [Wed Dec 30 21:36:54 2015] jgross: hello! [Wed Dec 30 21:37:30 2015] johnw: Hi! [Wed Dec 30 21:38:02 2015] jgross: nice to see you here again ;) [Wed Dec 30 21:40:32 2015] I'm around on-and-off. Usually if you mention my name, I'll see it ;) [Wed Dec 30 21:43:16 2015] good to know :) I'll have questions for you soon [Wed Dec 30 22:26:42 2015] Oh I just proofed peirce -> classic, its the easiest... [Wed Dec 30 22:27:21 2015] Solved it in 2 minutes... [Wed Dec 30 22:28:02 2015] Well before I couldn't solve it. But After I did all the others and tried implies_to_or -> peirce [Wed Dec 30 22:28:08 2015] so only need to do that one [Wed Dec 30 22:28:35 2015] jrw one left to prove :) [Wed Dec 30 22:44:55 2015] oh the tactice contradiction does apply ex_falso_quodlibet. apply .. apply .. for you [Wed Dec 30 22:45:25 2015] than the proofs are even shorter, well "shorter" [Wed Dec 30 22:51:21 2015] oh wait i can just use destruct [Wed Dec 30 22:57:00 2015] "shorter": Like [firstorder.]? [Wed Dec 30 22:57:15 2015] firstorder doesnt work :P [Wed Dec 30 23:04:13 2015] feel like im almost there... [Wed Dec 30 23:04:22 2015] only need to prove False :P [Wed Dec 30 23:09:34 2015] have a good evening everyone [Thu Dec 31 10:01:05 2015] goodmorning [Thu Dec 31 13:29:33 2015] Nik05: good morning! [Thu Dec 31 13:33:57 2015] hey johnw [Thu Dec 31 13:34:08 2015] how're the proofs coming along? [Thu Dec 31 13:34:42 2015] im stuck with the last one impl_to_or -> peirce [Thu Dec 31 13:34:56 2015] you've done the other 4? [Thu Dec 31 13:35:06 2015] yes [Thu Dec 31 13:35:41 2015] ah yes, impl_to_or -> peirce was the last one I did too [Thu Dec 31 13:36:18 2015] turns out peirce to classic was the easiest :P [Thu Dec 31 13:36:26 2015] yes [Thu Dec 31 13:36:28 2015] looked at it yesterday and solved it really fast [Thu Dec 31 13:36:32 2015] same [Thu Dec 31 13:36:43 2015] the last 3 were the hardest for me [Thu Dec 31 13:37:19 2015] de_morgan_not_and_not -> implies_to_or was also pretty easy [Thu Dec 31 13:37:54 2015] implies_to_or -> peirce is even a bit easier than that one, once you see it [Thu Dec 31 13:38:02 2015] oh :P [Thu Dec 31 13:53:44 2015] oh [Thu Dec 31 13:53:48 2015] i thnik i got it... [Thu Dec 31 13:54:07 2015] no... [Thu Dec 31 13:54:40 2015] what i tried before was apply (P -> Q) -> P before the indcution step... [Thu Dec 31 13:54:50 2015] changed those around and proof... [Thu Dec 31 13:59:50 2015] and now I forgot what inversion does again... [Thu Dec 31 14:00:28 2015] basically it takes a hypothesis, and renders it into the truth necessary to allow that hypothesis [Thu Dec 31 14:00:43 2015] i.e., "what you can deduce from the hypothesis" [Thu Dec 31 14:01:06 2015] thus, inverting S n = S m, you know that n = m [Thu Dec 31 14:02:04 2015] right oke [Thu Dec 31 14:02:46 2015] they are all pretty simple except for excluded_middle -> de_morgan_not_and_not [Thu Dec 31 14:02:59 2015] or maybe I just did it the hard way [Thu Dec 31 14:03:27 2015] that one is just as trivial as implies_to_or -> peirce [Thu Dec 31 14:04:16 2015] well oke, you are right [Thu Dec 31 14:05:31 2015] Oke now im at Prop.v and after that MoreLogic [Thu Dec 31 20:40:17 2015] Happy New Year ##coq [Thu Dec 31 22:10:46 2015] This seems like I should be able to prove it, but I'm stuck... am I wasting my time? http://pastebin.com/MBWb5FFc [Thu Dec 31 23:12:02 2015] tejing: this is interesting [Thu Dec 31 23:16:55 2015] benzrf: any progress? [Thu Dec 31 23:17:44 2015] not really [Thu Dec 31 23:17:47 2015] im gonna get up and think about it a lil [Thu Dec 31 23:19:14 2015] all i can think is that this would presumably be trivial in extensional type theory :| [Fri Jan 1 00:55:42 2016] tejing: had any luck? [Fri Jan 1 00:55:45 2016] this is now bugging me [Fri Jan 1 05:09:10 2016] benzrf: nope I'm still stuck [Fri Jan 1 16:28:04 2016] tejing: http://pastebin.com/Afqmgivf [Fri Jan 1 18:48:35 2016] jrw: aha, thanks :-) [Sat Jan 2 13:39:22 2016] jgross_: ping [Sat Jan 2 13:41:02 2016] is there any way to "admit with existentials"? [Sat Jan 2 13:42:37 2016] ah, SF has just the thing: skip_with_existential [Sat Jan 2 14:45:11 2016] johnw: [exfalso; clear; admit]? [Sat Jan 2 14:45:27 2016] jgross_: hello! [Sat Jan 2 14:45:38 2016] johnw: hi! [Sat Jan 2 14:45:42 2016] jgross_: I had a question for you about why finish honing wasn't passing, but it was a problem with my abstraction relation [Sat Jan 2 14:45:54 2016] now my only proof left is that carried addition is associativity, and this example is done [Sat Jan 2 14:47:20 2016] Nice! What example are you working on? And what were you changing the representation to? [Sat Jan 2 14:47:32 2016] https://gist.github.com/22918b08df887deaf7a4 [Sat Jan 2 14:47:49 2016] just something simple and yet more difficult to a Fiat newbie than working with plain sets [Sat Jan 2 16:24:20 2016] how do I change some EXPR as NAME throughout the goal? [Sun Jan 3 00:48:17 2016] is it possible to create a local hypothesis in a proof that has implicit arguments? some variation on assert? [Sun Jan 3 01:02:08 2016] to be clear, I mean the hypothesis has implicit arguments, not the proof. [Sun Jan 3 01:06:19 2016] assert (forall {n a} (x : Vec n a), ...) as H. [Sun Jan 3 01:06:21 2016] you mean like that? [Sun Jan 3 01:09:28 2016] johnw: yes, like that, but if I do that then try to use H the argument isn't actually implicit. [Sun Jan 3 01:09:53 2016] I would just pass "_" for the arguments you don't want to spcify [Sun Jan 3 01:11:25 2016] johnw: I'm looking at a case with like 6 implicit arguments, and I use it about 100 times in the proof... could get awful wordy. Right now it's a separate lemma, but this proof is the only place I use it, so I'd sort of prefer not to pollute the namespace. [Sun Jan 3 01:11:39 2016] put it into a Section [Sun Jan 3 01:11:49 2016] or, just use "Lemma" inside the proof itself [Sun Jan 3 01:12:12 2016] sorry, it wolud have to be in a Module, not a Section, to avoid being visible outside [Sun Jan 3 01:14:15 2016] johnw: hmm, I'll have to think about how I want it structured I guess [Sun Jan 3 03:27:20 2016] Hi, I'm currently working through https://www.cis.upenn.edu/~bcpierce/sf/current/Basics.html (Exercise andb_eq_orb) [Sun Jan 3 03:27:26 2016] There it says "Remember that you do not have to introduce all hypotheses at the same time." [Sun Jan 3 03:27:29 2016] What does that mean? [Sun Jan 3 03:30:08 2016] Also, what do I do when I have: [Sun Jan 3 03:30:14 2016] H : false = true [Sun Jan 3 03:30:16 2016] ==== [Sun Jan 3 03:30:19 2016] true = false [Sun Jan 3 03:30:23 2016] in proof general? [Sun Jan 3 03:30:55 2016] (Oh, figured it out, nevermind) [Sun Jan 3 03:53:14 2016] Also, if I have to inductive types in scope. How do I disambiguate in case their constructors have the same names? [Sun Jan 3 03:53:22 2016] *have two inductive types [Sun Jan 3 07:43:49 2016] rrika: not sure if someone already answered, but you can do something like intros H. instead of just intros. or intros H G K. [Sun Jan 3 07:44:19 2016] ah, just read your "nevermind" comment :) [Sun Jan 3 12:46:58 2016] rrika: "discriminate" [Sun Jan 3 12:47:10 2016] rrika: whenever you have an obvious inequality being expressed as an equality [Sun Jan 3 12:47:28 2016] e.g., two things that cannot be equal due to injectivity of constructors [Sun Jan 3 13:41:27 2016] how can I avoid Stack_overflow when using large natural numbers? I'd like to just give Coq 8G of stack, is there an option for that? [Sun Jan 3 13:46:01 2016] johnw: Use binary numbers rather than unary ones. [Sun Jan 3 13:46:10 2016] well [Sun Jan 3 13:46:34 2016] I wanted to use [nat] in my Fiat spec specifically to show that the specification can be liberated from all performance concerns [Sun Jan 3 13:46:51 2016] in order to establish the meaning of the "result domain", I have an axiom [Sun Jan 3 13:46:51 2016] Why are you using large numbers, then? [Sun Jan 3 13:46:58 2016] I want to test that axiom using QuickChick [Sun Jan 3 13:47:12 2016] which wants to round-trip through up to 2^31 in the naturals [Sun Jan 3 13:47:26 2016] my refinement uses binary numbers [Sun Jan 3 13:48:43 2016] Use the native version rather than the bytecode version? I think the native version spins where the bytecode version stack overflows? [Sun Jan 3 13:48:56 2016] how do I use a bytecode version? [Sun Jan 3 13:49:15 2016] coqtop.opt vs coqtop.byte, I think [Sun Jan 3 13:50:00 2016] i don't even know [Sun Jan 3 13:50:08 2016] johnw: Fiat as in the car brand? [Sun Jan 3 13:50:09 2016] I'm just using "coqtop" [Sun Jan 3 13:50:21 2016] no, Fiat as in the program synthesis framework from MIT [Sun Jan 3 13:50:33 2016] johnw: check your PATH [Sun Jan 3 13:50:38 2016] i have coqtop.opt etc [Sun Jan 3 13:50:50 2016] ah, I do too [Sun Jan 3 13:50:50 2016] coq lists them [Sun Jan 3 13:50:52 2016] which should I be using? [Sun Jan 3 13:54:00 2016] johnw: See if using coqtop.opt instead makes it work better. [Sun Jan 3 13:54:50 2016] same overflow [Sun Jan 3 13:54:56 2016] I mean granted, these are possibly HUGE naturals [Sun Jan 3 13:55:00 2016] so maybe this isn't even worth attempting [Sun Jan 3 13:55:35 2016] I'll try constraining it to a sub-domain [Sun Jan 3 13:56:14 2016] Yeah, try keeping it below 20000 [Sun Jan 3 13:59:27 2016] yeah, that does work, it just makes for a pretty weak test :( [Sun Jan 3 14:01:08 2016] im a finitist i dont believe in numbers greater than 20000 [Sun Jan 3 14:01:23 2016] i mean have you ever tried counting that high [Sun Jan 3 14:01:30 2016] haha [Sun Jan 3 14:02:17 2016] induction on int31 numbers is not fun [Sun Jan 3 14:36:19 2016] is there a good way of inducting over something like N, but as if it were a natural? That is, I want to use the equivalence to prove in terms of naturals, and have the proof apply to N. induction x using as_a_natural. [Sun Jan 3 14:37:01 2016] a generic tactic like "induction_as Type x", provided proofs of equivalence are available, would be neat [Sun Jan 3 14:38:45 2016] You can prove N_as_nat_rect : forall (P : N -> Type), P 0 -> (forall x, P x -> P (x + 1)%N) -> forall x, P x. [Sun Jan 3 14:39:11 2016] how is that N_as_nat? [Sun Jan 3 14:39:23 2016] That's the induction principle for nat [Sun Jan 3 14:39:27 2016] I mean, I want P : nat -> Type [Sun Jan 3 14:39:45 2016] ending as forall x, P (N.to_nat x) or something [Sun Jan 3 14:39:53 2016] except that of course this doesn't apply [Sun Jan 3 14:40:05 2016] Are you looking for https://github.com/HoTT/HoTT/blob/master/theories/Tactics/EquivalenceInduction.v ? [Sun Jan 3 14:40:33 2016] thats' a lot of code, but it feels about right [Sun Jan 3 14:40:47 2016] especially the example at the end [Sun Jan 3 14:40:56 2016] equiv_induction! but I'd need a ton of HoTT machinery? [Sun Jan 3 14:41:46 2016] You need HoTT.Basics and HoTT.Types [Sun Jan 3 16:57:18 2016] how would I go about proving "forall q p, S q = S p -> q = p"? [Sun Jan 3 16:57:32 2016] inversion on the hypothesis [Sun Jan 3 16:57:50 2016] since constructors are known to always be injective, it can deduce q = p from it [Sun Jan 3 16:58:26 2016] if it had been a function, like foo q = foo p, you'd need a proof like inj_foo to show this fact [Sun Jan 3 16:59:02 2016] does the proof of injectivity of constructors have a name, by which I can refer to it? [Sun Jan 3 16:59:16 2016] it's a feature of CiC, there is no proof [Sun Jan 3 16:59:47 2016] I see. So what tactic would be useful here? [Sun Jan 3 16:59:59 2016] intros q p H; inversion H. [Sun Jan 3 17:00:22 2016] rrika: see http://stackoverflow.com/questions/32662889/how-do-we-know-all-coq-constructors-are-injective-and-disjoint [Sun Jan 3 17:00:54 2016] I see, thank you. [Sun Jan 3 17:02:44 2016] "there is no proof" >> what of the proof term that "Show Proof." shows? Is that not a proof? [Sun Jan 3 17:04:20 2016] it's a proof term that relies on a fact of the environment, though, what does that tell you? [Sun Jan 3 17:06:29 2016] I'm not sure what you mean. Just to be clear, [fun q p H => f_equal (fun e => match e with O => q | S n => n end) H] is a term that has the type [forall q p, S q = S p -> q = p]. Is that not a proof of the injectivity of S? [Sun Jan 3 17:07:25 2016] yes, but doesn't that proof rely on the definitional equality provided by CiC from the eq_refl constructor? [Sun Jan 3 17:08:19 2016] in which case, you're relying on the machinery of CiC to establish the equality for you, which is to say that you didn't define the semantics of constructor injecitivity yourself [Sun Jan 3 17:08:49 2016] although, I guess in the end everything arrives at an axiom, so maybe there's no point to be made here [Sun Jan 3 17:09:06 2016] "Why are constructors injective in Coq? Because they are." [Sun Jan 3 17:09:26 2016] Show Proof. is pretty cool [Sun Jan 3 17:09:32 2016] though a bit verbose [Sun Jan 3 17:09:41 2016] more similar to what I'm used to from LEAN [Sun Jan 3 17:10:41 2016] "the definitional equality provided by CiC from the eq_refl constructor" >> which definitional equality do you mean? [Sun Jan 3 17:10:46 2016] is there a way to hover over something like "f_equal" and get the signature displayed? (in emacs) [Sun Jan 3 17:10:51 2016] Cypi: if you look at how f_equal is defined [Sun Jan 3 17:10:59 2016] Yes, I expanded that definition [Sun Jan 3 17:11:15 2016] It just relies on pattern-matching [Sun Jan 3 17:11:20 2016] it just does a match on eq_refl; there's no *code* there, just computation happening at the type -level [Sun Jan 3 17:11:50 2016] hmm [Sun Jan 3 17:12:00 2016] I could be totally wrong here, Cypi, just ignore me and I'll think on this for a while [Sun Jan 3 17:12:12 2016] I don't know either, just wondering :) [Sun Jan 3 17:12:45 2016] when you have H : foo x = foo y, I can't just do inversion H, I have to apply inj_foo that proves the injectivity [Sun Jan 3 17:12:52 2016] but when I Have H : S x = S y, I can just inversion H [Sun Jan 3 17:13:05 2016] since I never proved inj_S, it's a fact that I get from defining "nat" [Sun Jan 3 17:13:33 2016] and I don't think this proof is one of the definition generated by Inductive either; I think it's just a consequence of it being an inductive datatype [Sun Jan 3 17:13:57 2016] that's the only distinction I meant to point out [Sun Jan 3 17:14:00 2016] Indeed: you can pattern-match on an inductive datatype, and S is one of its constructors, that's why it works [Sun Jan 3 17:14:23 2016] injectivity of constructors is something you get from CiC by definition, it's not its own proof term [Sun Jan 3 17:14:46 2016] i.e., what would inj_S look it? it would just be a match on eq_refl [Sun Jan 3 17:14:51 2016] s/look it/look like [Sun Jan 3 17:16:41 2016] but inj_foo would have a term behind it with some code (assuming foo isn't just calling constructors) [Sun Jan 3 17:20:29 2016] I still feel like "there is no proof" is technically incorrect, since there is an actual proof which relies solely on the typing of pattern-matching in general. [Sun Jan 3 17:20:55 2016] I don't know the exact syntax of match yet, but it seems to me that that's where the magic is happening. [Sun Jan 3 17:21:01 2016] unifying S x with S y [Sun Jan 3 17:21:15 2016] Yes, dependent pattern-matching is complicated ^^' [Sun Jan 3 17:21:21 2016] (I think) [Sun Jan 3 17:21:25 2016] "match H in (_ = y) return (y = S p -> q = p) with | eq_refl =>" [Sun Jan 3 17:21:45 2016] (using p and q here instead of x and y) [Sun Jan 3 17:24:50 2016] johnw : actually, now that I think about it, it works because we can define some function f such that [f (S q) = q] forall q...which is another way of saying that S is injective. And we can define this function easily by pattern-matching. So in some sense you're right, the injectivity of constructors is given by CiC because we're allowed to pattern-match on inductive datatypes. [Sun Jan 3 17:35:57 2016] that makes sense [Sun Jan 3 17:37:23 2016] I guess an interesting point here would be to do a pen-and-paper proof of the injectivity of constructors, and see what it is necessary to assume to make that possible [Sun Jan 3 18:07:59 2016] So, the inversion of S is really easy, it's just (f_equal pred). The inversion of more complicated types basically involves defining a function that tells you which ones you have. There's some work on describing how to do these kinds of things in general in the HoTT book, under the encode-decode method. [Mon Jan 4 03:53:14 2016] http://lpaste.net/148409 [Mon Jan 4 03:53:34 2016] I don't understand the definition of `semantics` in my paste [Mon Jan 4 03:54:03 2016] waht is the curly braces notation? And what does & mean ? [Mon Jan 4 04:03:54 2016] I suspect { } is the dependent product and & the Set-level conjunction (whereas /\ is for Prop) [Mon Jan 4 04:24:30 2016] companion_cube: thanks. [Mon Jan 4 04:24:45 2016] Locate "&" tells me: "{ x : A & P }" := sigT (fun x : A => P) [Mon Jan 4 04:25:29 2016] oh I see, it's part of the { } [Mon Jan 4 04:29:33 2016] and is there a way to check the type of P ? [Mon Jan 4 04:29:58 2016] or, in general, binders introduced using fun [Mon Jan 4 04:31:19 2016] the type of fun x:A => P is, in general, forall x:A, type_of_p [Mon Jan 4 04:31:29 2016] where x:A |- P : type_of_p [Mon Jan 4 04:33:41 2016] right, but if I have "fun a => ..." how do I learn the type of "a" ? [Mon Jan 4 04:33:52 2016] or, in your example [Mon Jan 4 04:34:15 2016] if the source code contains "fun x => P" how do I learn that x : A ? [Mon Jan 4 04:34:44 2016] it's inferred by Coq [Mon Jan 4 04:34:50 2016] (inference can fail) [Mon Jan 4 04:35:04 2016] but for instance, if you write fun x -> x /\ ~x [Mon Jan 4 04:35:10 2016] Coq can infer that x : Prop [Mon Jan 4 04:35:40 2016] but in general, for a definition of a lambda is there a way to ask Coq what types did it infer for the binders? [Mon Jan 4 04:35:59 2016] so in my example: [Mon Jan 4 04:36:00 2016] fun P s => { p : pre pt s & subset (post pt s p) P } [Mon Jan 4 04:36:10 2016] I want to ask Coq what types for P and s did it infer [Mon Jan 4 04:36:20 2016] and I want it to tell me that P : Type and s : P [Mon Jan 4 04:36:26 2016] can I do that somehow? [Mon Jan 4 04:38:39 2016] I don't know how to do it directly [Mon Jan 4 04:38:57 2016] you can use Check (fun P s => { p : ....... }). [Mon Jan 4 04:39:02 2016] it will give you the result type [Mon Jan 4 08:50:56 2016] I just proved 'mult_comm' from Software Foundations/Induction but it turned out to be quite ugly. Anyone have an elegant solution for it? [Mon Jan 4 10:48:32 2016] I'm trying to write a recursive function that returns a tuple of two natural numbers [Mon Jan 4 10:48:37 2016] I wrote "Fixpoint log2_and_remainder (n unit: nat) : (nat, nat) := …" [Mon Jan 4 10:48:48 2016] Gave me: The term "(nat, nat)" has type "(Set * Set)%type" which should be Set, Prop or Type. [Mon Jan 4 10:49:03 2016] what does that mean? [Mon Jan 4 10:51:16 2016] The type that you are looking for is "nat * nat" [Mon Jan 4 10:51:45 2016] ah [Mon Jan 4 10:51:59 2016] (a, b) is an inhabitant of some type A * B, which is why Coq is complaining: (nat, nat) is an inhabitant of Set * Set (because nat has type Set) [Mon Jan 4 10:52:11 2016] right, makes sense [Mon Jan 4 11:08:33 2016] Is there anyway to show Fixpoint that an argument is decreasing? [Mon Jan 4 11:10:54 2016] Fixpoint foobar (n : nat) : … := … (foobar (decrement n))… [Mon Jan 4 11:12:31 2016] You can add {struct n} to your definition to specifiy which argument is decreasing [Mon Jan 4 11:12:46 2016] Fixpoint foobar (n : nat) {struct n} : ... := ... [Mon Jan 4 11:12:51 2016] but maybe that's not what you asked for [Mon Jan 4 11:13:26 2016] yeah, that doesn't help here [Tue Jan 5 09:58:46 2016] Hey, I've worked on the vim plugin that talks to coqtop, what's changed in 8.5? [Tue Jan 5 09:59:02 2016] Is there a summary of the changes that impact the protocall? [Tue Jan 5 10:04:07 2016] https://github.com/coq/coq/blob/trunk/CHANGES#L503 [Tue Jan 5 10:04:17 2016] is the best you're going to get I think [Tue Jan 5 10:08:46 2016] I'd maybe look at the -toploop option if I were you [Tue Jan 5 10:47:46 2016] I did look at that changelog. Where can I read more about how toploop is supposed to work? [Tue Jan 5 10:51:41 2016] in the source code... [Tue Jan 5 10:51:57 2016] or send an email to coq-club (or coq-dev?) [Tue Jan 5 11:00:44 2016] Sure. [Tue Jan 5 12:58:10 2016] so I have: assert (inv x * (x * y) = inv x * (x * z)) as Hinv. then when I try "rewrite assoc in Hinv." on next line it complains that hypothesis Hinv doesn't exist. What am I doing wrong? [Tue Jan 5 12:58:59 2016] First you have to prove your hypothesis. When it's proven, then you can use it (use Hinv) to prove your original goal [Tue Jan 5 13:01:18 2016] oh I see [Tue Jan 5 13:01:31 2016] I can only rewrite that term after I prove it [Tue Jan 5 13:03:43 2016] Cypi: thanks, now I understand how it is supposed to be used :) [Tue Jan 5 13:04:12 2016] I skipped ahead in my infinite wisdom and assumed things which aren't true [Tue Jan 5 13:35:29 2016] I used 'elim' to break apart a conjunctive assumption, then the tutorial mentions 'split', but why would I used that over simply 'intros' to pull in the two parts [Tue Jan 5 14:32:56 2016] anyone knows how I re-run a proof in Proof General (in emacs) C-c C-p tells me no proof is focused, and I don't know how to focus it [Tue Jan 5 15:30:08 2016] I have H : A -> B and H0 : A, how do I do modus ponens? [Tue Jan 5 15:30:51 2016] [apply H in H0] or [specialize (H H0)] or [pose proof (H H0) as H1] depending on how you want to manage your hypotheses. [Tue Jan 5 15:30:59 2016] (the "as H1" is optional) [Tue Jan 5 15:32:09 2016] thanks [Tue Jan 5 15:35:21 2016] I'm getting a bit confused about apply reasoning "backwards", but I suppose I'll get used to it. [Tue Jan 5 15:35:32 2016] well... it can go both ways [Tue Jan 5 15:43:50 2016] backwards is going from what you have to what you need to have it [Tue Jan 5 15:44:01 2016] forward is going from what is needed to what results from it [Tue Jan 5 15:44:22 2016] actually, backwards is going from what is needed to what you need to obtain it [Tue Jan 5 15:47:18 2016] Yes. I mean I know how it works just the UI seems a bit confusing :P [Tue Jan 5 15:47:30 2016] I have the proof on paper on 3 lines and in coq on 20 :D [Tue Jan 5 15:47:40 2016] show me yoru proof? [Tue Jan 5 15:47:52 2016] I'm just doing simple stuff about groups, I started with Coq today [Tue Jan 5 15:47:57 2016] I need to get more familiar with it [Tue Jan 5 15:48:05 2016] I'm pretty sure the 20 lines isn't Coq's fault then :) [Tue Jan 5 15:48:14 2016] it's not indeed [Tue Jan 5 15:48:22 2016] as I said I just started today [Tue Jan 5 15:48:44 2016] someone in #haskell linked an interesting post so I said what the hell, let's see what the fuss is about :D [Tue Jan 5 15:49:05 2016] so, if you show me the proof, I could help reduce its size [Tue Jan 5 15:49:27 2016] I already got it down to 3 after figuring apply can do this backward chaining [Tue Jan 5 15:49:31 2016] or whatever we call it [Tue Jan 5 15:49:53 2016] what I did was 'assert' lots of inbetween results I proved separately and then applied modus ponens [Tue Jan 5 15:50:04 2016] ah [Tue Jan 5 15:50:26 2016] what was the theorem you were trying to prove? [Tue Jan 5 15:50:37 2016] that x-1-1 = x [Tue Jan 5 15:51:03 2016] in the end I just used uniqueness of inverse element and left inverse law and that's it [Tue Jan 5 15:51:05 2016] I guess I don't know what - means [Tue Jan 5 15:51:11 2016] oh, x^-1^-1 [Tue Jan 5 15:51:16 2016] x^-1, yea sorry [Tue Jan 5 15:51:22 2016] somehow that got lost [Tue Jan 5 15:51:36 2016] iow inversion is involution [Tue Jan 5 15:51:48 2016] involutive [Tue Jan 5 15:51:52 2016] right? [Tue Jan 5 15:52:02 2016] a function is involution if f(f(x)) = x [Tue Jan 5 15:52:14 2016] oh, I've always said "a function is involutive if..." [Tue Jan 5 15:52:17 2016] https://en.wikipedia.org/wiki/Involution_(mathematics) [Tue Jan 5 15:52:32 2016] both are OK, one is noun and the other adjective [Tue Jan 5 15:53:06 2016] foote and mac lane use involution at least, so that's what I use :P [Tue Jan 5 15:54:03 2016] but they don't say "is involution" [Tue Jan 5 15:54:10 2016] maybe "is _an_ involution" [Tue Jan 5 15:55:07 2016] I guess proper english would be with an article, sure [Tue Jan 5 15:56:44 2016] when I have "x * y * inv y * inv x = e" and a theorem "foreach x: x * inv x = e", how would I apply that to the y * inv y in the middle? [Tue Jan 5 15:56:52 2016] forall* [Tue Jan 5 15:57:37 2016] you'd need to exactly apply assocativity theorems for * until you had x * (y * inv y) * inv x [Tue Jan 5 15:57:46 2016] bleh [Tue Jan 5 15:57:56 2016] let's left and right multiply then [Tue Jan 5 15:58:17 2016] then a commutitivity, another assocativity, and you'd have e * (x * inv x) = e [Tue Jan 5 15:58:29 2016] commutativity isn't free [Tue Jan 5 15:58:40 2016] ah [Tue Jan 5 15:58:48 2016] i guess then just x * e = x, right? [Tue Jan 5 15:58:56 2016] so then you'd have x * inv x = e, and you'd be done [Tue Jan 5 15:59:01 2016] yea [Tue Jan 5 16:03:57 2016] when I have a rule R, a = b and I do 'rewrite R' it replaces a with b, how can I use the substitution b = a? [Tue Jan 5 16:05:12 2016] 'rewrite <- R' [Tue Jan 5 16:44:36 2016] so this is how I defined groups: http://sprunge.us/EiNg, now how would I define something like a group homomorphism? [Tue Jan 5 16:44:48 2016] I guess this definition is too simplistic to allow that, but that's what the tutorial started with [Tue Jan 5 16:45:01 2016] I need to get some solid book on this... the internet is surprsingly useless [Tue Jan 5 16:46:28 2016] so, you can do something like this in several different ways [Tue Jan 5 16:46:35 2016] module types, as you've started here [Tue Jan 5 16:46:38 2016] type classes, ala Haskell [Tue Jan 5 16:46:42 2016] and canonical structures [Tue Jan 5 16:47:52 2016] there are lots of math libraries out in the wild, you could derive inspiritaion for how to deal with homomorphisms from one of them [Tue Jan 5 16:50:55 2016] Are "canonical structures" Records in practice? [Tue Jan 5 16:52:27 2016] they use records, but that's not the whole story [Tue Jan 5 16:52:39 2016] it's what ssreflect uses for its algebraic structures [Tue Jan 5 16:52:54 2016] more info here: https://hal.inria.fr/hal-00816703/en [Tue Jan 5 16:53:01 2016] "Canonical Structures for the working Coq user" [Tue Jan 5 16:53:04 2016] that describes their motivation and approach [Tue Jan 5 16:55:18 2016] Thanks [Wed Jan 6 04:03:18 2016] I'm reading "Software Foundations" and I've just proved `andb b c = true -> c = true`. I used `destruct b` and was asked to prove `c = true` for both `b = true` and `b = false`. But when `b = false` the hypothesis is `andb false c = true`. But that is clearly false. Why should I do a proof when the hypothesis is false? [Wed Jan 6 04:03:54 2016] Here is my proof: http://lpaste.net/148516 [Wed Jan 6 04:05:24 2016] paldepind: disproving things is just as important [Wed Jan 6 04:06:02 2016] You can just consider negating the statement and proving that [Wed Jan 6 04:08:22 2016] QF-MichaelK, but if I did the proof on paper then for `b = false` I'd say that the goal `andb b c = true -> c = true` is equal to `andb b c != true \/ c = true`, and `b = false` so `andb b c = false`. [Wed Jan 6 04:08:32 2016] Does that make sense? Can I do the same in Coq? [Wed Jan 6 04:09:43 2016] if you have `andb false c = true`, you could `destruct c` and disprove each case [Wed Jan 6 04:11:21 2016] companion_cube, I did complete the proof by doing `destruct c`. But it seems a bit unnatural to me. [Wed Jan 6 04:12:03 2016] well, it is 'clearly false' only because you know the truth table by heart :) [Wed Jan 6 04:12:16 2016] I suspect there are already some lemmas proving this kind of stuff, though [Wed Jan 6 04:12:37 2016] But I can get the goal down to `false = true -> c = true`. That's obviously true. [Wed Jan 6 04:13:24 2016] That is `false != true \/ c = true`. [Wed Jan 6 04:13:43 2016] no, that is not the same thing (-> is intuitionistic implication) [Wed Jan 6 04:13:57 2016] for `false = true -> c = true`, you can `intro H; inversion H.` [Wed Jan 6 04:15:10 2016] So what I'm saying is only true in classical logic? [Wed Jan 6 04:15:39 2016] `A -> B` is only the same as `~A \/ B` in classical logic, yes [Wed Jan 6 04:16:48 2016] Ok. Then that is probably why I am confused. I think classical logic is what I've learned. [Wed Jan 6 04:17:26 2016] intuitionistic logic is a subset of classical logic, it should not be too surprising; but indeed -> is much more important [Wed Jan 6 04:18:50 2016] Does that mean that in intuitionistic logic `->` has a different truth table? [Wed Jan 6 04:19:16 2016] paldepind: lose the idea of truth tables... they implicitly assume the law of the excluded middle :-) [Wed Jan 6 04:20:23 2016] yeah, I was talking about the truth table of andb, earlier, not of /\ [Wed Jan 6 04:21:54 2016] tejing, ok. I'll try to forget about them. [Wed Jan 6 07:16:20 2016] Hi. I am trying to prove this: {a = a0 \/ List.In a l} + {~ (a = a0 \/ List.In a l)} given: X : forall x y : A, {x = y} + {x <> y} [Wed Jan 6 07:18:33 2016] I would like to have the goal {a = a0} + {~ a = a0} \/ {List.In a l} + {~ List.In a l} [Wed Jan 6 07:18:44 2016] But I dont know how to get there [Wed Jan 6 07:19:15 2016] Can someone help? [Wed Jan 6 07:31:58 2016] wouter__: maybe rewrite negb_orb? not sure if this ~ is negb though [Wed Jan 6 07:33:44 2016] This second goal does not have a valid type. A \/ B requires A and B to be Prop, which is not the case here [Wed Jan 6 07:34:08 2016] ah owke [Wed Jan 6 07:34:59 2016] You could probably [destruct (X a a0)] and do the same with your induction hypothesis (I suppose you have one), and select accordingly which side of the goal you can prove [Wed Jan 6 07:37:02 2016] destruct (X a a0) helps [Wed Jan 6 07:37:07 2016] thank you [Wed Jan 6 07:47:14 2016] is there some point of using (A /\ B) -> C instead of A -> B -> C ? [Wed Jan 6 07:48:35 2016] this is basically result of 'curry' on the first "type" [Wed Jan 6 07:48:58 2016] so there is maybe some case where that form is superior, but when [Wed Jan 6 09:24:11 2016] Who does use compcert ? [Wed Jan 6 10:28:45 2016] Anarchos: I heard Airbus was interested [Wed Jan 6 10:36:23 2016] there must be commercial users: http://www.absint.com/compcert/ [Wed Jan 6 13:44:06 2016] hello all [Wed Jan 6 13:44:20 2016] I want to run the Coq interpreter from the command line, but I want to import a file as well [Wed Jan 6 13:44:23 2016] like GHCI's :load [Wed Jan 6 13:44:26 2016] is it possible? [Wed Jan 6 13:44:45 2016] let me see [Wed Jan 6 13:45:00 2016] go into the SF directory [Wed Jan 6 13:45:02 2016] run "coqtop" [Wed Jan 6 13:45:07 2016] then type "Require Import Prop." [Wed Jan 6 13:45:23 2016] (for example) [Wed Jan 6 13:46:43 2016] johnw: I think Require Import "Basics." worked :) [Wed Jan 6 13:46:45 2016] thanks a lot! [Wed Jan 6 13:46:48 2016] sure [Wed Jan 6 13:46:53 2016] although, really, Proof General is the way to go [Wed Jan 6 13:46:57 2016] (in Emacs) [Wed Jan 6 13:47:07 2016] oh, I tried looking for it in MELPA and it wasn't there [Wed Jan 6 13:47:16 2016] I assumed it was discontinued or something [Wed Jan 6 13:47:19 2016] I'll install it [Wed Jan 6 13:54:27 2016] a friend of mine just mentioned that fact yesterday [Wed Jan 6 13:54:34 2016] also, install the development version, 4.3pre [Wed Jan 6 14:01:09 2016] the released version doesn't build on newer emacsen yea... if at all :/ [Wed Jan 6 15:06:04 2016] I think I don't understand how introducing variables works... I have 'Variable G : Set.' and then define some group stuff with that. BUt how would I add another group without redefining all the properties with 'H'? [Wed Jan 6 15:06:34 2016] not *entirely* clear on what you mean [Wed Jan 6 15:06:45 2016] the Section should group all definitions that rely on a common G [Wed Jan 6 15:06:48 2016] I now want to prove something involving two groups [Wed Jan 6 15:06:55 2016] you put definitions that don't after the close of that section [Wed Jan 6 15:06:56 2016] but I always only used forall x : G ... [Wed Jan 6 15:07:04 2016] now I need forall G, H : "GROUP" [Wed Jan 6 15:07:11 2016] just add an H parameter then [Wed Jan 6 15:07:19 2016] and leave G to come from the environment [Wed Jan 6 15:07:56 2016] right, but I have no "group" type, that's my issue I guess [Wed Jan 6 15:08:10 2016] and if I just add H : Set it doesn't have the group laws on it, or the operation [Wed Jan 6 15:08:24 2016] I have "Variable mult : G -> G -> G" but how would I get a mult for H? [Wed Jan 6 15:09:21 2016] all links I found online mentioning groups are either dead or completely over my head (like the Lagrange's theorem proof which is 2000 lines or something... it's fairly simple theorem!) [Wed Jan 6 15:13:12 2016] this isn't making enough sense for me to have a reasonable suggestion for you [Wed Jan 6 15:13:17 2016] if you show me some code, that would help [Wed Jan 6 15:20:58 2016] johnw: https://gist.github.com/Fuco1/4532228923c0249faecf I have more theorems later which aren't relevant. Now I want to define for example what is a subgroup [Wed Jan 6 15:21:02 2016] how would I do that/ [Wed Jan 6 15:21:38 2016] I need two objects of type "group", but I don't even understand if I am defining a type like that anywhere... or if that is how things are done in Coq [Wed Jan 6 15:21:43 2016] one sec [Wed Jan 6 15:28:48 2016] Fuco: https://gist.github.com/1a2bbec51df2956daab6 [Wed Jan 6 15:28:55 2016] you may find this much easier to work with [Wed Jan 6 15:30:44 2016] johnw: that seems like what I was after, thanks [Wed Jan 6 15:30:51 2016] johnw: one question, what is group_scope? [Wed Jan 6 15:31:02 2016] well, you are overloading the definition of * [Wed Jan 6 15:31:12 2016] so defining a scope allows user to clarify which version of % they want [Wed Jan 6 15:31:22 2016] (x * y)%group_scope vs. (x * y)%N_scope, etc. [Wed Jan 6 15:31:32 2016] which version of *, I meant [Wed Jan 6 15:31:38 2016] I see [Wed Jan 6 15:31:44 2016] opening the scope makes it the default from that point forward [Wed Jan 6 15:31:59 2016] you'll see that in normal developments, "+" has like 5 meanings, one of which is always the default [Wed Jan 6 18:39:33 2016] can someone help me with a SF exercise? [Wed Jan 6 18:39:42 2016] Nik05: probably! [Wed Jan 6 18:39:43 2016] found one i didnt solve [Wed Jan 6 18:40:36 2016] It's theorem ev_plus_plus : forall n m p, ev (n+m) -> ev (n+p) -> ev (m+p). And the exercise says to don't use any induction or case analysis. but just application and rewriting [Wed Jan 6 18:41:41 2016] I have this theorem to use ev_sum: ∀ n m : nat, ev n → ev m → ev (n + m) [Wed Jan 6 18:41:52 2016] And this one ev_ev__ev: ∀ n m : nat, ev (n + m) → ev n → ev m [Wed Jan 6 18:42:28 2016] oh wait what [Wed Jan 6 18:43:31 2016] /no/ case anal? [Wed Jan 6 18:43:32 2016] oh right correct sorry, read the last one wrong [Wed Jan 6 18:43:51 2016] o induction or even case analysis is needed [Wed Jan 6 18:43:58 2016] Thats what it says [Wed Jan 6 18:44:01 2016] huh [Wed Jan 6 18:44:23 2016] And I got the plus theomres like n + S m = S (n + m), etc [Wed Jan 6 18:44:39 2016] ooh i got an idea [Wed Jan 6 18:44:44 2016] not sure it's right [Wed Jan 6 18:45:58 2016] So first applying ev_plus_plus doesnt work because you need to prove ev m and ev p. And they could be odd. So then we have the ev_ev__ev [Wed Jan 6 18:46:24 2016] gimme a minute =p [Wed Jan 6 18:46:31 2016] oke :) [Wed Jan 6 18:47:23 2016] Nik05: are those the only two theorems? [Wed Jan 6 18:47:55 2016] do you have something like forall n, ev (n + n) [Wed Jan 6 18:48:04 2016] yes got that one too [Wed Jan 6 18:48:11 2016] i know how to do it then c= [Wed Jan 6 18:48:17 2016] that might be the only clue you need [Wed Jan 6 18:49:09 2016] oh dont got it but, can try [Wed Jan 6 18:49:27 2016] oh i got itdouble_even: ∀ n : nat, ev (double n) [Wed Jan 6 18:57:36 2016] benzrf just apply and rewrite? [Wed Jan 6 18:57:46 2016] yep [Wed Jan 6 18:57:49 2016] roughly [Wed Jan 6 18:58:02 2016] maybe an assert or two, but [Wed Jan 6 18:58:11 2016] oke [Wed Jan 6 18:58:53 2016] thank you, will look again :p [Wed Jan 6 18:58:57 2016] kk [Wed Jan 6 19:03:13 2016] benzrf where should i begin? apply to hypotesis or to the goal? [Wed Jan 6 19:03:25 2016] one sec [Wed Jan 6 19:03:28 2016] im trying to get mine working [Wed Jan 6 19:07:46 2016] you very rarely should need intermediate asserts [Wed Jan 6 19:08:19 2016] oke [Wed Jan 6 19:09:03 2016] grrr [Wed Jan 6 19:09:08 2016] how do you rewrite only one occurence >:O [Wed Jan 6 19:09:16 2016] rewrite foo at . [Wed Jan 6 19:09:25 2016] or, use replace X with Y. [Wed Jan 6 19:09:32 2016] hi johnw [Wed Jan 6 19:09:39 2016] hi Nik05! [Wed Jan 6 19:10:03 2016] johnw: tyvm [Wed Jan 6 19:12:46 2016] ok ye i proved it [Wed Jan 6 19:12:57 2016] the part that i had trouble with was some extremely finicky rewriting [Wed Jan 6 19:13:07 2016] which wouldve been trivial to any human ;-; [Wed Jan 6 19:13:42 2016] the plus associativity and commutivity? [Wed Jan 6 19:14:46 2016] oh man i just dont see it :P [Wed Jan 6 19:15:06 2016] and im not missing some theorem. I can do it with apply ev_ev__ev and ev_sum? [Wed Jan 6 19:17:11 2016] well and double you said [Wed Jan 6 19:21:43 2016] Nik05: if you can show me, I could offer a hint [Wed Jan 6 19:22:03 2016] Starting over, i have no idea what im doign [Wed Jan 6 19:23:07 2016] elo guys, i want to define partial mappings like this: f : a -> option b [Wed Jan 6 19:23:37 2016] what woukd be the best way to do it in coq? [Wed Jan 6 19:24:41 2016] I mean, I'd like to have an operator like "|->", that will work just like "->" does [Wed Jan 6 19:25:04 2016] and define the partial functions as f : A |-> B [Wed Jan 6 19:25:20 2016] f : A |-> B would be equivalent to say f : A -> option B [Wed Jan 6 19:26:31 2016] you could do it exactly as you've described [Wed Jan 6 19:26:42 2016] Definition partial (A B : Type) := A -> option B. [Wed Jan 6 19:26:51 2016] Infix "|->" := partial. [Wed Jan 6 19:32:40 2016] oh maybe i got it [Wed Jan 6 19:37:19 2016] im almost there [Wed Jan 6 19:37:28 2016] johnw: thank you :), it works like a charm! [Wed Jan 6 19:40:40 2016] benzrf how do you rewrite ev (n + n + m + p + (m + p)) to ev((n+n)+(m+m)+(p+p)) ? :P [Wed Jan 6 19:41:07 2016] Nik05: it's not easy [Wed Jan 6 19:41:51 2016] that's actually fairly straightforward [Wed Jan 6 19:42:17 2016] oh [Wed Jan 6 19:43:04 2016] so, NPeano.Nat.add_shuffle1 has type: forall n m p q : nat, n + m + (p + q) = n + p + (m + q) [Wed Jan 6 19:43:28 2016] which is exactly what you need; you just have to use associativity to move the initial "n + n" out of it [Wed Jan 6 19:43:41 2016] it's also called: plus_permute_2_in_4 forall n m p q : nat, n + m + (p + q) = n + p + (m + q) [Wed Jan 6 19:43:58 2016] but I imagine that if this is for SF, you'll need to write it yourself [Wed Jan 6 19:45:00 2016] johnw: jesus christ how horrifying [Wed Jan 6 19:45:19 2016] why is that horrifying? [Wed Jan 6 19:45:29 2016] random special-case equalities like that [Wed Jan 6 19:45:52 2016] must be useful more often than you'd think, or why would it be in the stdlib in two places :) [Wed Jan 6 19:45:54 2016] when i go to college my research project will be investigating how human understanding of algebra works & developing better tools for this kind of nonsense [Wed Jan 6 19:46:00 2016] :P [Wed Jan 6 19:46:12 2016] johnw: no the horrifying thing is that it's the Right Solution [Wed Jan 6 19:46:18 2016] well, "omega" is the real answer here [Wed Jan 6 19:46:26 2016] doesn't that just do inequalities [Wed Jan 6 19:46:26 2016] "f_equal; omega" will solve Nik05's goal [Wed Jan 6 19:46:37 2016] it solves math equality like this too [Wed Jan 6 19:47:05 2016] but you don't learn anything [Wed Jan 6 19:51:56 2016] now i dont even get my prove when i try to go over it again... [Wed Jan 6 20:06:49 2016] oke now i dont understand apply [Wed Jan 6 20:07:03 2016] So I got ev_ev__ev: ∀ n m : nat, ev (n + m) → ev n → ev m [Wed Jan 6 20:07:10 2016] Hnm : ev (n + n + m + p) [Wed Jan 6 20:07:18 2016] And my goal is ev (m + p) [Wed Jan 6 20:07:36 2016] So I apply ev_ev__ev with (m:=m+p). [Wed Jan 6 20:07:57 2016] This give me the hypotheis m + p [Wed Jan 6 20:08:17 2016] and i can prove my goal with this, and it gives a subgoal [Wed Jan 6 20:08:42 2016] But I would think the subgoal would be prove ev (n + n), but i need to prove ev (n + n + m + p + (m + p)) [Wed Jan 6 20:08:45 2016] what is happening there? [Wed Jan 6 20:10:10 2016] I apply ev_ev__ev in Hnm ofcourse. [Wed Jan 6 20:18:50 2016] johnw still here? [Wed Jan 6 20:20:13 2016] or benzrf ? [Wed Jan 6 20:21:07 2016] hey Nik05 [Wed Jan 6 20:21:30 2016] Nik05: im reading now [Wed Jan 6 20:21:36 2016] Can you help me whats going on when i apply ev_ev__ev to Hnm, oke thank you [Wed Jan 6 20:22:09 2016] Nik05: are you applying it to Hnm, or to your goal? [Wed Jan 6 20:22:23 2016] yeah that was my mistake, im applying it to Hnm [Wed Jan 6 20:28:11 2016] Nik05: it works now? [Wed Jan 6 20:28:24 2016] well the proof works, but i dont get how :P [Wed Jan 6 20:28:29 2016] i was just lucky [Wed Jan 6 20:29:25 2016] http://lpaste.net/1932201908391378944 [Wed Jan 6 20:29:30 2016] I dont get line 7 [Wed Jan 6 20:31:20 2016] After line 6 I got Hnm : ev ( n + n + m + p ) [Wed Jan 6 20:31:41 2016] when i apply ev_ev__ev : ∀ n m : nat, ev (n + m) → ev n → ev m [Wed Jan 6 20:32:22 2016] i would expect ev (n' + m') == ev ( (n + n) + (m + p)) [Wed Jan 6 20:32:42 2016] which then gives me ev (n + n) -> ev (m + p) [Wed Jan 6 20:32:55 2016] i dont get it now [Wed Jan 6 20:36:07 2016] i can prove (ev (m + p)), but why do i need to prove ev (n + n + m + p + (m + p)) instead of ev (n + n)? [Wed Jan 6 20:37:10 2016] like how ev_sum gets appled in line 5 [Wed Jan 6 20:37:37 2016] So my question is, why is my 2nd subgoal not ev (n + n)? [Wed Jan 6 20:37:58 2016] Maybe its relaly obvious and i should just take a break... [Wed Jan 6 20:42:40 2016] maybe! [Wed Jan 6 20:43:20 2016] no wait now it works... [Wed Jan 6 20:43:21 2016] :S [Wed Jan 6 20:43:47 2016] ahah [Wed Jan 6 20:43:52 2016] eugh [Wed Jan 6 20:44:00 2016] meant to type 'haha' [Wed Jan 6 20:44:06 2016] the guy i know who says 'ahah' is awful [Wed Jan 6 20:44:08 2016] http://lpaste.net/5058733706680729600 [Wed Jan 6 20:44:23 2016] so whhy doesnt this do the same :S [Wed Jan 6 20:44:26 2016] this is much easier... [Wed Jan 6 20:44:55 2016] Im think this should be equivalent :p [Wed Jan 6 20:45:40 2016] oke im doing something stupid with (m:=m+p) when apply ev_e... [Wed Jan 6 20:46:03 2016] but what? :S [Wed Jan 6 20:46:34 2016] ho sorry for my indentations in my pastes... [Wed Jan 6 20:58:39 2016] http://lpaste.net/4521939266573434880 but benzrf is your proof like this as well? [Wed Jan 6 20:59:17 2016] I would like to use Case to make it a little more clear what im doing, but how to name these cases? [Wed Jan 6 21:00:16 2016] After the first apply what would be an appropriated case name? [Wed Jan 6 21:00:40 2016] Nik05: sorry let me check [Wed Jan 6 21:01:11 2016] And then still my question, but doesnt line 7 work with "with (m:=m+p)" ? [Wed Jan 6 21:01:40 2016] its not even that much rewrite in this proof [Wed Jan 6 21:01:41 2016] ummmm why dont i just paste what i did do you can compare c: [Wed Jan 6 21:01:50 2016] i dont feel like going to the trouble to read proof scripts :> [Wed Jan 6 21:02:47 2016] :P [Wed Jan 6 21:03:08 2016] I guess i dont know how the "with" syntax works in apply [Wed Jan 6 21:04:25 2016] http://lpaste.net/148565 [Wed Jan 6 21:05:53 2016] thank you benzrf [Wed Jan 6 21:15:41 2016] np [Wed Jan 6 21:47:02 2016] have a good night everyone [Wed Jan 6 21:47:06 2016] thank you benzrf :) [Wed Jan 6 21:50:57 2016] np [Thu Jan 7 09:12:45 2016] Hi guys, I defined in a separated file an infix operator named "|-> [Thu Jan 7 09:12:50 2016] "|->" [Thu Jan 7 09:13:10 2016] the thing is, when I import the file inside another one, I can't use that operator [Thu Jan 7 09:13:15 2016] it throws me the following: Syntax error: '.' expected after [vernac:gallina] (in [vernac_aux]). [Thu Jan 7 09:13:35 2016] but, if I define the operator inside the same file I use it, it works [Thu Jan 7 09:13:43 2016] do you know why is that happening? thanks [Thu Jan 7 12:20:51 2016] "|->" [Thu Jan 7 12:21:00 2016] Hi guys, I defined in a separated file an infix operator named "|-> [Thu Jan 7 12:21:08 2016] the thing is, when I import the file inside another one, I can't use that operator [Thu Jan 7 12:21:13 2016] it throws me the following: Syntax error: '.' expected after [vernac:gallina] (in [vernac_aux]). [Thu Jan 7 12:21:20 2016] but, if I define the operator inside the same file I use it, it works [Thu Jan 7 12:21:24 2016] do you know why is that happening? thanks [Thu Jan 7 12:26:50 2016] pumita: It's been a while since I've done this, but you might need to define your operator in a specified "Scope" and in your importing module, use "Open Scope scope_name." [Thu Jan 7 12:31:51 2016] pumita: see the uses of Infix and : X_scope in https://github.com/coq/coq/blob/trunk/theories/Init/Datatypes.v [Thu Jan 7 12:34:27 2016] The Bind Scope command is useful if you plan on not overloading that notation https://coq.inria.fr/distrib/current/refman/Reference-Manual014.html#hevea_default799 [Thu Jan 7 12:36:44 2016] Thanks ianjneu [Thu Jan 7 12:36:52 2016] how do you declare a scope? [Thu Jan 7 12:37:30 2016] because I did basically what's on Datatypes.v, and it throws me "Error: Scope maps_scope is not declared." [Thu Jan 7 12:37:39 2016] when I do "Open Scope maps_scope" [Thu Jan 7 12:41:36 2016] did you do the Infix ... : maps_scope, or Bind Scope maps_scope with your_map_type before the open? [Thu Jan 7 12:42:55 2016] yes [Thu Jan 7 12:43:03 2016] I did that in the separated file Maps.v [Thu Jan 7 12:43:19 2016] Did you compile Maps.v? [Thu Jan 7 12:43:22 2016] Infix "|->" := partial (at level 62, left associativity) : maps_scope. [Thu Jan 7 12:43:26 2016] yes [Thu Jan 7 12:44:14 2016] Can you do Local Open Scope maps_scope in Maps.v after your Infix just for a sanity check? [Thu Jan 7 12:45:02 2016] yes, that works [Thu Jan 7 12:45:50 2016] Do you Require or Require Import Maps.v? [Thu Jan 7 12:46:09 2016] Require Import [Thu Jan 7 12:48:21 2016] Before you open the scope, what does the command Print Visibility maps_scope. give you? [Thu Jan 7 12:49:03 2016] Error: Scope maps_scope is not declared. [Thu Jan 7 12:49:18 2016] Does Print Scopes. contain maps_scope? [Thu Jan 7 12:50:13 2016] no :(, it contains others though [Thu Jan 7 12:50:55 2016] pumita: is the infix command in a section? [Thu Jan 7 12:51:21 2016] jrw yes! maybe that's the problem [Thu Jan 7 12:51:36 2016] right, they don't survive sections, just modules. [Thu Jan 7 12:51:45 2016] try redeclaring infix after the section [Thu Jan 7 12:52:08 2016] that was the problem [Thu Jan 7 12:52:18 2016] thanks ianjneu and jrw :) ! [Thu Jan 7 12:56:32 2016] np [Thu Jan 7 20:36:43 2016] So I've defined a record called Category. How can I get a list of all the identifiers which this definition has produced? [Thu Jan 7 20:38:43 2016] Something like [Search Category] or [SearchAbout Category] might do it [Thu Jan 7 20:38:55 2016] (I never remember the difference between the two, if any) [Thu Jan 7 20:39:16 2016] Mostly unrelated: the "Show" family of commands is only used during an interactive proof, right? [Thu Jan 7 20:39:57 2016] Looks like both of your commands do the trick. Thanks! [Thu Jan 7 20:40:18 2016] Most of them yes. There is [Show Obligation Tactic] which is related to Program [Thu Jan 7 20:43:35 2016] I'm a little surprised that although the record's constructor and destructors are now named constants, there are no named constants which relate the constructor and destructors. [Thu Jan 7 20:44:28 2016] tswett: what kind of relation are you looking for? [Thu Jan 7 20:45:21 2016] my guess is that what you're looking for is captured by computation, so you should be able to prove it directly with [reflexivity.], for example. [Thu Jan 7 20:45:37 2016] Things saying that applying destructors to the output of the constructor gives you back the original arguments, and applying the constructor to the outputs of all the destructors will give you the original Category. [Thu Jan 7 20:45:40 2016] You're probably right. [Thu Jan 7 20:45:42 2016] or, in the context of a larger proof, you should be able to use [simpl] to do the rewrite you're looking for [Thu Jan 7 20:45:49 2016] Note that you can print said destructors if you want. Nothing special about them, it's just handled by Coq [Thu Jan 7 21:07:52 2016] What's the command to enable universe polymorphism in 8.5beta1? [Thu Jan 7 21:10:04 2016] [Set Universe Polymorphism] or just add [Polymorphic] before some definition [Thu Jan 7 21:13:56 2016] Cool, thanks. [Thu Jan 7 21:14:27 2016] That makes this file complete. [Thu Jan 7 21:14:35 2016] A definition of what a category is, in only 41 lines! [Thu Jan 7 21:50:05 2016] tswett: "a collection of 'objects', a collection of 'morphisms' for each pair of objects, & an associative, unital operation whose type rules are analogous to that of function composition" [Thu Jan 7 21:50:10 2016] 1 line [Thu Jan 7 21:50:13 2016] c= [Thu Jan 7 21:51:03 2016] https://pastebin.mozilla.org/8856164 - my definition is clearly much better than yours. [Thu Jan 7 21:57:08 2016] 'arrows' [Thu Jan 7 21:57:11 2016] not 'morphisms' [Thu Jan 7 21:57:12 2016] smh [Thu Jan 7 21:57:43 2016] You don't like the word? [Thu Jan 7 21:59:35 2016] just being fractios [Thu Jan 7 22:00:08 2016] *fractious [Thu Jan 7 22:01:53 2016] Hey, I never used the word "arrows" once in my definition! [Fri Jan 8 13:17:25 2016] how can I split the proof in two cases where in one branch I assume x and in one I assume ¬x [Fri Jan 8 13:20:55 2016] rrika: you have to prove decidability for the proposition in question. once you've done that you simply destruct that proof. (or you have to take the law of the excluded middle as an axiom) [Fri Jan 8 13:23:02 2016] how does that work? [Fri Jan 8 13:23:29 2016] basically I'm trying to prove: f x = f y → x = y [Fri Jan 8 13:23:47 2016] And for that, handle the cases x = y and x != y [Fri Jan 8 13:24:01 2016] Not even sure if that leads anywhere, just trying out stuff [Fri Jan 8 13:25:21 2016] rrika: what is the type of x and y ? [Fri Jan 8 13:25:24 2016] Perhaps just admit a proposition T_dec: forall x y : (type of x and y), {x=y}+{x<>y}. and use that in your proof attempt. [Fri Jan 8 13:25:27 2016] rrika: you'd need a proof of "forall x y : , x = y \/ x <> y", which for simple types is usually easy enough to prove by induction [Fri Jan 8 13:25:42 2016] sgnb, x and y are of the same inductive type I defined [Fri Jan 8 13:25:49 2016] tejing: or just the "decide equality" tactic. [Fri Jan 8 13:25:58 2016] or that [Fri Jan 8 13:26:04 2016] right [Fri Jan 8 13:26:04 2016] (specifically the binary number as linked list type from that manual) [Fri Jan 8 13:26:28 2016] ianjneu, what does "+" do here? [Fri Jan 8 13:26:50 2016] + is a sum type constructor. Either the left or right proposition. [Fri Jan 8 13:26:52 2016] tejing, and then destruct on that? [Fri Jan 8 13:26:59 2016] rrika: it's a notation for 'sumbool'... it's like \/, but the result is a type, not a prop [Fri Jan 8 13:27:16 2016] what's the difference between prop and type? [Fri Jan 8 13:27:56 2016] Prop is not allowed to be inspected for constructing anything other than another prop [Fri Jan 8 13:28:24 2016] It's a syntactic restriction for extraction. [Fri Jan 8 13:28:27 2016] Are Types and Props disjunct or subset of each other? [Fri Jan 8 13:28:30 2016] rrika: yes. apply it to the x and y in your specific situation, then destruct it... as for prop and type, the main thing to know is that you cannot pattern match on a prop to produce a type, unless it's a prop with only 1 constructor. that's so that extraction works, since it leaves out anything in prop [Fri Jan 8 13:30:46 2016] >you'd need a proof of "forall x y : , x = y \/ x <> y" [Fri Jan 8 13:31:09 2016] In models of the gallina logic, Prop is considered the smallest type, followed by Set then Type. Type is ramified behind the scenes to an unbounded tower of Type0 < Type1 < Type2 ... [Fri Jan 8 13:31:12 2016] if I have a case of an inductive type with 0 arguments, shouldn't "casename <> casename" simplify to false? [Fri Jan 8 13:31:28 2016] ianjneu, I see. [Fri Jan 8 13:31:52 2016] It would not simplify to false since they are equivalent but not equal types. [Fri Jan 8 13:32:26 2016] huh? their type should be the same [Fri Jan 8 13:33:14 2016] False is an inductive type with 0 constructors. x = y -> False is a function. [Fri Jan 8 13:34:18 2016] does false also exist as value, not as type? [Fri Jan 8 13:34:49 2016] rrika: of type bool, yes [Fri Jan 8 13:35:04 2016] false is a bool, but equality is a proposition. [Fri Jan 8 13:35:10 2016] Oh, = is a function building expressions, not actually comparing things [Fri Jan 8 13:35:35 2016] rrika: = is a binary predicate... so it's more like a function building types [Fri Jan 8 13:35:35 2016] It is the identity type constructor, yes. [Fri Jan 8 13:35:45 2016] It's not binary. [Fri Jan 8 13:35:53 2016] er, 2-ary yes. [Fri Jan 8 13:36:13 2016] but really it takes the type of the following two arguments, so 3-ary. [Fri Jan 8 13:36:36 2016] (I was thinking binary as in LEM) [Fri Jan 8 13:37:18 2016] ianjneu: technically, true... I still think it's valid to call it binary though. (and yea, I meant 2-ary, not LEM) [Fri Jan 8 13:39:56 2016] binary presentation with Set Implicit Arguments, sure. [Fri Jan 8 13:40:58 2016] arity is not an internally expressible notion in gallina, so "valid" is an informal concept. [Fri Jan 8 21:57:02 2016] hi [Fri Jan 8 21:57:07 2016] https://www.youtube.com/watch?v=zmhd8clDd_Y [Fri Jan 8 21:57:14 2016] was watching this video and i had a question [Fri Jan 8 21:57:30 2016] since excluded middle is independent, can we add an axiom ~(forall P : Prop, P \/ ~P) consistently? what would it mean [Fri Jan 8 23:16:59 2016] well it makes more sense to add axioms that violate EM, rather than just its negation [Fri Jan 8 23:18:18 2016] an example of an axiom that violates EM is the kock-lawvere axiom: https://ncatlab.org/nlab/show/Kock-Lawvere+axiom [Fri Jan 8 23:19:49 2016] i think some continuity axioms are anti-classical too [Fri Jan 8 23:22:58 2016] here's a blog post discussing that http://math.andrej.com/2009/10/12/constructive-gem-double-exponentials/ [Fri Jan 8 23:24:16 2016] church's thesis ("all functions are computable") is also anti-classical i think: https://en.wikipedia.org/wiki/Church%27s_thesis_(constructive_mathematics) [Fri Jan 8 23:25:18 2016] thanks! [Sat Jan 9 08:42:04 2016] how can I use numbers in coq? Normal integers, 1, 2,3... not 'nat' [Sat Jan 9 08:47:07 2016] Fuco, is there anything you can't do with nats? [Sat Jan 9 08:47:49 2016] -4 [Sat Jan 9 11:56:29 2016] Anyone an hint on how to proof palindrome_converse : ∀ X (l : list X), l = rev l -> pal l from SF? [Sat Jan 9 11:56:30 2016] when I have a goal S m = S n, how do I simplify it to m = n? [Sat Jan 9 11:57:17 2016] Fuco, inversion [Sat Jan 9 11:57:20 2016] ah [Sat Jan 9 11:57:25 2016] just too late :P [Sat Jan 9 11:57:34 2016] I had the same question few weeks back :P [Sat Jan 9 11:57:53 2016] Fuco or you can apply f_equal [Sat Jan 9 11:58:14 2016] what do you mean inversion? [Sat Jan 9 11:58:37 2016] vanila, isnt that when the hypothesis is S m = S n? [Sat Jan 9 11:58:45 2016] Fuco apply f_equal on your goal [Sat Jan 9 11:58:53 2016] yes [Sat Jan 9 11:59:17 2016] I have no idea how people read the documentation, it's so chaotic :/ [Sat Jan 9 11:59:35 2016] H : S m = S n [Sat Jan 9 11:59:37 2016] inversion H. [Sat Jan 9 11:59:53 2016] it's the goal not hypothesis [Sat Jan 9 12:00:03 2016] oh okay [Sat Jan 9 12:02:28 2016] Fuco, if you have a helper theorem like [Sat Jan 9 12:02:29 2016] Lemma strip_s : forall q p, q = p -> S q = S p. [Sat Jan 9 12:02:35 2016] you can then "apply strip_s" [Sat Jan 9 12:02:45 2016] rrika its called f_equal [Sat Jan 9 12:02:56 2016] Nik05, so "apply f_equal"? [Sat Jan 9 12:03:06 2016] should've read the log [Sat Jan 9 12:06:22 2016] :) [Sat Jan 9 12:07:08 2016] how can I move a function application out of a match [Sat Jan 9 12:07:09 2016] as in [Sat Jan 9 12:07:40 2016] match x with | y => f(1) | z => f(2) end → f (match x with | y => 1 | z => 2 end) [Sat Jan 9 12:09:38 2016] is that term your goal [Sat Jan 9 12:10:30 2016] oh I was going to say the 'change' tactic but it wont work, you would have to these two terms equal by case on x [Sat Jan 9 12:10:49 2016] the match is one on side of a "=" that is my goal [Sat Jan 9 12:11:12 2016] … = match … f() f() → … = f ( match … () ()) [Sat Jan 9 12:11:24 2016] maybe just destruct x [Sat Jan 9 12:11:51 2016] IIRC it doesn't let me [Sat Jan 9 12:11:55 2016] x is a complex expression [Sat Jan 9 12:12:10 2016] you could make a lemma where x really is just a variable [Sat Jan 9 12:12:12 2016] then apply that [Sat Jan 9 12:12:49 2016] oh, "destruct" works, should've used () with destruct. [Sat Jan 9 14:11:28 2016] how can I split a<->b into a->b and b->a? [Sat Jan 9 14:11:58 2016] destruct [Sat Jan 9 14:12:10 2016] destruct with what argument? [Sat Jan 9 14:12:15 2016] H : a<->b [Sat Jan 9 14:12:17 2016] destruct H [Sat Jan 9 14:12:21 2016] ah [Sat Jan 9 14:12:35 2016] oh, what if it's my goal though? [Sat Jan 9 14:13:13 2016] Then "split" [Sat Jan 9 14:13:29 2016] Cypi, thank you [Sat Jan 9 14:16:17 2016] can infinite terms exist in coq? [Sat Jan 9 14:16:19 2016] in other words [Sat Jan 9 14:16:26 2016] is (S x) = x provable? [Sat Jan 9 14:16:55 2016] You can prove "forall x, ~ (S x = x)" actually [Sat Jan 9 14:17:09 2016] Infinite terms do exist, but only in the context of coinductive definitions [Sat Jan 9 14:17:17 2016] I see. [Sat Jan 9 14:17:26 2016] So if you were to define coinductive natural numbers, then yes, you would have some x such that S x = x [Sat Jan 9 14:23:31 2016] if I have a hypothesis H : eq_rect _ _ constr1 _ p = constr2, where constr1 and constr2 are have different annotation terms, how can I generate a contradiction? I'm basically trying to do 'discriminate H' but it's complicated by the eq_rect, and I can't use decideable equality to remove it because constr1 = constr2 cannot be proposed. [Sat Jan 9 14:23:45 2016] s/are have/have/ [Sat Jan 9 14:50:44 2016] got it... need to transform it into existT _ _ constr1 = existT _ _ constr2 then discriminate. [Sat Jan 9 15:01:35 2016] how do I prove "1 <> 0" [Sat Jan 9 15:03:12 2016] congruence [Sat Jan 9 15:03:18 2016] Pick what you prefer: "discriminate", "congruence", "intros H; inversion H", ... [Sat Jan 9 15:03:43 2016] cool, thank you [Sat Jan 9 18:45:25 2016] Can someone give a hint on how to proof ∀l, l = rev l -> palindrome l? Where palindrome is inductively defined := | p_nil : palindrome [] | p_one : ∀x, palindrome [x] | p_cc ∀x l, palindrome -> palindrome (x :: snoc l x). [Sat Jan 9 18:45:53 2016] lets abbreviate to pal, like SF does [Sat Jan 9 19:15:10 2016] Nik05: that one is tricky, especially given what the book has taught you at the point when the exercise is assigned. what have you tried so far to solve it? [Sat Jan 9 19:40:04 2016] jrw inductions on l but then im stuck with pal (x :: l') [Sat Jan 9 19:40:32 2016] inversions to proof subgoals [Sat Jan 9 19:40:38 2016] but stuck every time [Sat Jan 9 19:41:03 2016] Nik05: okay good. I assume you believe it to be true informally? do you have an informal argument as to why it's true? [Sat Jan 9 19:42:13 2016] I do believe its true :P [Sat Jan 9 19:42:25 2016] good :) [Sat Jan 9 19:42:28 2016] what about an argument? [Sat Jan 9 19:42:28 2016] let me think about the informal proof [Sat Jan 9 19:42:32 2016] okay [Sat Jan 9 19:47:08 2016] jrw i would say i could do it with induction on l [Sat Jan 9 19:47:27 2016] well maybe not wait [Sat Jan 9 19:47:35 2016] :D [Sat Jan 9 19:48:03 2016] just induction on l is not possible [Sat Jan 9 19:48:08 2016] okay why? [Sat Jan 9 19:50:06 2016] uhm [Sat Jan 9 19:51:27 2016] well you get the induction hypothesis l' = rev l' -> pal l'. To proof pal (x :: l') [Sat Jan 9 19:51:29 2016] which is not possible [Sat Jan 9 19:53:25 2016] induction on rev l isnt possible either [Sat Jan 9 19:54:37 2016] No idea how to do this informally [Sat Jan 9 19:55:50 2016] okay good [Sat Jan 9 19:55:58 2016] first step is figuring out how to do it informally [Sat Jan 9 19:56:03 2016] no hope of doing it in coq otherwise [Sat Jan 9 19:56:06 2016] oke [Sat Jan 9 19:56:25 2016] it might help to think a bit *more* informally [Sat Jan 9 19:56:38 2016] oke will try that [Sat Jan 9 19:56:42 2016] it looks to me like you basically tried to do as much detail as possible on paper, roughly the level of coq detail [Sat Jan 9 19:56:52 2016] instead, start from the other end of the spectrum, all the way at "why is this true?" [Sat Jan 9 19:58:06 2016] letting yourself use whatever reasoning principles you are comfortable with, even if you don't know how to formalize them in coq [Sat Jan 9 19:59:26 2016] Oke i will try to write something down [Sat Jan 9 20:13:30 2016] This is confusing. Because well l = rev l is the definition of a palindrome. [Sat Jan 9 20:14:13 2016] I thought about doing an inevrsion on H, but how [Sat Jan 9 20:14:35 2016] ah, yeah, that's confusing. [Sat Jan 9 20:16:07 2016] it might be helpful to think of "palindrome l" as meaning "l consists of the same first and last element, and the middle is also a palindrome" [Sat Jan 9 20:16:24 2016] which is just an englishification of the inductive definition [Sat Jan 9 20:18:19 2016] well yes thats how i defined pal [Sat Jan 9 20:18:42 2016] right, so we're taking that as the definition of palindrome, and not rev l = l [Sat Jan 9 20:20:23 2016] one place to start would be to prove (informally) that if rev l = l then l is either empty, a singleton, or can be written in the form [x] ++ l' ++ [x] for some x and l' [Sat Jan 9 20:21:39 2016] and then we are doing a induction [Sat Jan 9 20:23:03 2016] if you mean we could prove that by induction on l, then yes, that sounds good. [Sat Jan 9 20:23:26 2016] if you mean something else, then that also potentially sounds good [Sat Jan 9 20:23:42 2016] No i meant you are already doing an induction [Sat Jan 9 20:23:52 2016] or case analysis, not sure what it is [Sat Jan 9 20:24:21 2016] l = rev l, so for l is empty: [] = rev [] -> pal [], true by definition [Sat Jan 9 20:24:34 2016] [x] = rev [x] -> pal [x], true by definition [Sat Jan 9 20:26:08 2016] right [Sat Jan 9 20:26:14 2016] and we have [x] ++ l' ++ [x] = rev "" -> pal [x] ++ l' ++ [x] [Sat Jan 9 20:26:32 2016] with the induction hypothesis l' = rev l' -> pal l' [Sat Jan 9 20:26:39 2016] right, nice. [Sat Jan 9 20:26:43 2016] but [Sat Jan 9 20:28:09 2016] so, that's a nice informal argument. let's analyze the principles behind it. [Sat Jan 9 20:28:57 2016] first thing I notice is that you're using a slightly nontrivial form of case analysis, which is like the lemma I suggested above, that splits into empty, singleton, or equal-front-and-back-plus-a-middle-bit [Sat Jan 9 20:29:35 2016] do you notice anything about the inductive hypothesis? [Sat Jan 9 20:30:01 2016] it's what we want to proof [Sat Jan 9 20:30:45 2016] okay, sure [Sat Jan 9 20:31:09 2016] uh what do you mean? :P [Sat Jan 9 20:31:11 2016] the thing I was noticing was that usually when you do a proof by (structural) induction, you have a head and a tail, and you get the inductive hypothesis about the tail [Sat Jan 9 20:31:19 2016] but here we get it about the middle [Sat Jan 9 20:31:29 2016] yes [Sat Jan 9 20:32:28 2016] I tried to write a inductive, sorry not sure how to say this [Sat Jan 9 20:32:44 2016] so when formalizing this argument, we're going to have to figure out how to convince coq to give us such a hypothesis [Sat Jan 9 20:33:05 2016] ah oke, so we have to go this way [Sat Jan 9 20:33:10 2016] already tried to do this [Sat Jan 9 20:33:25 2016] Noticed coq writes these induction axioms, and tried to write my own... [Sat Jan 9 20:33:34 2016] nice [Sat Jan 9 20:34:29 2016] oh wait SF mentions them aswell [Sat Jan 9 20:35:07 2016] I think a custom induction principle is a really elegant way of phrasing this proof, but the hard part is proving the principle [Sat Jan 9 20:35:59 2016] oke [Sat Jan 9 20:36:46 2016] so if you want to start thinking about that, I would recommend thinking about why such a principle is valid [Sat Jan 9 20:39:22 2016] oh SF was just updated, the chapters are all merged and it has editting annotations... [Sat Jan 9 20:39:26 2016] oke i will jrw [Sat Jan 9 20:43:32 2016] also it might be helpful to remind yourself why "normal" list induction is valid [Sat Jan 9 20:45:15 2016] normal list induction i get [Sat Jan 9 20:45:30 2016] but how exactly do we do the head-tail induction? [Sat Jan 9 20:45:40 2016] or head-end* [Sat Jan 9 20:46:05 2016] what do you mean? [Sat Jan 9 20:46:16 2016] I mean, what do you mean by "how do we do it"? [Sat Jan 9 20:46:53 2016] So we proof it holds for [], [x], and do the induction step x ++ l ++ y? [Sat Jan 9 20:47:04 2016] [x], [y]* [Sat Jan 9 20:47:50 2016] that's the principle that we want to justify, yes [Sat Jan 9 20:48:17 2016] oke i get why it works [Sat Jan 9 20:48:51 2016] same for "normal" induction on lists like natural numbers [Sat Jan 9 20:49:37 2016] okay, right. can you say a bit more about why normal induction works, if you're claiming this works for the same reason? [Sat Jan 9 20:51:55 2016] First we proof a base case. And the second step is to proof the inductive step l -> x :: l. [Sat Jan 9 20:52:34 2016] if we have [] as the base case, with the inductive step we can proof al possible lists [Sat Jan 9 20:52:47 2016] damn explaining is hard [Sat Jan 9 20:52:49 2016] :) [Sat Jan 9 20:53:28 2016] maybe another way to ask it is, "how would you *prove* that 'normal' induction on lists is true, if you were doing paper-and-pencil math?" [Sat Jan 9 20:55:16 2016] uh [Sat Jan 9 20:56:44 2016] the proving of induction oh uh [Sat Jan 9 20:57:58 2016] If you assume the proof holds for some l' and we can prove it holds forall x, x :: l'. And we can proof a base case we can proof it for all lists of lengthe >= base list [Sat Jan 9 20:58:02 2016] but how to proof that [Sat Jan 9 20:58:39 2016] ah, okay, nice, you mentioned length [Sat Jan 9 20:58:43 2016] can you run with that? [Sat Jan 9 20:58:59 2016] what do you mean? [Sat Jan 9 21:00:10 2016] well, one way to prove 'normal' induction on lists is to use so-called "mathematical" induction (ie, induction on the natural numbers) [Sat Jan 9 21:00:20 2016] basically by inducting on the length of the list [Sat Jan 9 21:00:31 2016] oh oke [Sat Jan 9 21:01:45 2016] so we can do the same for natural numbers if we proof two consecutive base cases and the inductive step n' -> SS n' [Sat Jan 9 21:01:48 2016] ? [Sat Jan 9 21:02:19 2016] and with that proof the head-end induction of lists? [Sat Jan 9 21:03:42 2016] right, that's not a bad idea [Sat Jan 9 21:04:56 2016] but is it a good idea? :P [Sat Jan 9 21:05:38 2016] I'm checking :D [Sat Jan 9 21:05:50 2016] it was different from the way I was planning, but I like it better because you came up with it :) [Sat Jan 9 21:11:09 2016] yeah, I think this works [Sat Jan 9 21:11:16 2016] what is nat_rect? Do i need that? [Sat Jan 9 21:15:35 2016] that's the induction principle for natural numbers. it's what gets used when you say "induction n" [Sat Jan 9 21:15:38 2016] when n is a nat [Sat Jan 9 21:15:58 2016] oke then what is nat_ind? [Sat Jan 9 21:16:08 2016] isnt that the principle? [Sat Jan 9 21:18:22 2016] yeah, they're related [Sat Jan 9 21:18:32 2016] there's a separate one for Prop, Set, and Type [Sat Jan 9 21:19:22 2016] oh oke [Sat Jan 9 21:19:47 2016] and how would I do the induction with my own inductive principle? [Sat Jan 9 21:21:36 2016] you're going to use normal induction to prove your principle [Sat Jan 9 21:21:59 2016] it's a good idea to look at the type of nat_ind, so you know what an induction principle typically looks like [Sat Jan 9 21:22:17 2016] it starts with a property P that you want to prove for all elements of a type [Sat Jan 9 21:22:23 2016] in this case nat, so P has type nat -> Prop [Sat Jan 9 21:22:51 2016] then it takes a proof of the base case, P 0, and a proof of the inductive case, forall n, P n -> P (S n) [Sat Jan 9 21:23:05 2016] finally, it returns a proof for all nats, forall n, P n [Sat Jan 9 21:24:15 2016] Just a Definition right? [Sat Jan 9 21:25:51 2016] sure, or a lemma [Sat Jan 9 21:28:04 2016] oke [Sat Jan 9 21:35:09 2016] my inductive principle can be proven, right jrw ? :P [Sat Jan 9 21:46:47 2016] Nik05: I proved the P n -> P (S (S n)) one, yeah [Sat Jan 9 21:46:59 2016] oke [Sat Jan 9 21:47:12 2016] This is the correct lemma right? Lemma nat_indSS : ∀ (P : nat -> Prop), P 0 -> P 1 -> (∀ n, P n -> P (S (S n))) -> ∀ n, P n. [Sat Jan 9 23:15:10 2016] jrw thank you very much for helping. I will look into it later. [Sat Jan 9 23:15:13 2016] Have a good night [Sun Jan 10 00:14:48 2016] Nik05: that's the right lemma [Sun Jan 10 08:45:05 2016] thank you jrw [Sun Jan 10 16:05:34 2016] Nik05: how's it going? [Sun Jan 10 16:05:57 2016] hey jrw [Sun Jan 10 16:06:36 2016] stuck with proofing things about <= and stuck with the palindrome :) [Sun Jan 10 16:07:29 2016] cool. is the <= stuff related to the palindrome or is it a separate exercise? [Sun Jan 10 16:07:36 2016] its seperate [Sun Jan 10 16:12:34 2016] Im already stuck with proofing the natural induction with two base cases [Sun Jan 10 16:23:51 2016] Nik05: okay, can you say why you're stuck? [Sun Jan 10 16:26:54 2016] jrw because i have to base cases i think i have to do two inductions but in the final induction step im left with P (S (S n'')) [Sun Jan 10 16:27:15 2016] and my induction hypothesis are P (S n'') and P n'' -> P (S n'') [Sun Jan 10 16:29:20 2016] right, so if you just try to proceed by induction on n, you'll get stuck because you'll have P (S n') and need to prove P (S (S n')) but you won't have anything about P n' [Sun Jan 10 16:30:12 2016] but if you think about induction as a process of building up a proof from the base cases, then it seems like it should work, because when you're trying to prove P (S (S n')), you have "already proved" P n' two iterations ago [Sun Jan 10 16:30:16 2016] but you've just "forgotten" it [Sun Jan 10 16:30:19 2016] and can't reuse it [Sun Jan 10 16:30:44 2016] this is one of those cases where you actually need to prove something stronger in order to get induction to work [Sun Jan 10 16:31:32 2016] so instead of trying to prove ... -> forall n, P n, you need to prove something that "remembers" the previous proof [Sun Jan 10 16:31:36 2016] is this making any sense? [Sun Jan 10 18:06:37 2016] sorry jrw, had a visitor [Sun Jan 10 18:06:44 2016] no worries [Sun Jan 10 18:07:05 2016] well should have told you [Sun Jan 10 18:08:07 2016] "you need to prove somethign that remembeers the previous proof" [Sun Jan 10 18:10:46 2016] right, you want to rephrase the statement of the theorem so that the induction hypothesis will give you the proof not only from "last time" but also from "two times ago" [Sun Jan 10 18:13:39 2016] jrw i dont know what you mean [Sun Jan 10 18:13:51 2016] is my lemma not provable? [Sun Jan 10 18:14:31 2016] it is proveable, but not directly by induction [Sun Jan 10 18:14:56 2016] you need to prove something slightly different by induction, and your lemma will follow [Sun Jan 10 18:15:01 2016] oh oke [Sun Jan 10 18:17:45 2016] I can give you slightly more to go on if you're stuck [Sun Jan 10 18:18:50 2016] Oke just a little :) [Sun Jan 10 18:21:01 2016] change your lemma to ... -> forall n, P n /\ P (S n) and see what happens [Sun Jan 10 18:22:10 2016] hm interesting [Sun Jan 10 18:23:46 2016] Now it is really easy [Sun Jan 10 18:25:08 2016] jrw thank you, this is an interesting way to look at a proof [Sun Jan 10 18:25:27 2016] now you should be able to prove the old version of the lemma as a consequence of the new version [Sun Jan 10 18:26:40 2016] solved [Sun Jan 10 18:26:47 2016] I have to go at the moment, but you should be able to finish the palindrome exercise now by inducting on the length [Sun Jan 10 18:26:50 2016] keep me posted! [Sun Jan 10 18:27:01 2016] thank you very much jrw [Sun Jan 10 18:27:10 2016] oh how do you do the induction on the length? [Sun Jan 10 18:27:34 2016] you can say "remember (length l) as n" [Sun Jan 10 18:27:40 2016] and then "generalize dependent l" [Sun Jan 10 18:27:41 2016] oke thank you [Sun Jan 10 18:27:51 2016] and then "induction n using my_new_lemma" [Sun Jan 10 18:28:01 2016] or just apply your new lemma [Sun Jan 10 18:28:09 2016] oke, thank you :) [Sun Jan 10 18:28:17 2016] np, good luck! [Sun Jan 10 21:56:53 2016] have a good night [Sun Jan 10 22:11:35 2016] jrw http://www.labri.fr/perso/casteran/CoqArt/inductive-prop-chap/SRC/palindrome.v in Coq d'Art they have a long proof for the head tail induction... Is it possible flr me to do it with my induction principle? [Sun Jan 10 22:12:21 2016] Nik05: yes, I did it your way last night [Sun Jan 10 22:12:25 2016] it was much nicer than that proof [Sun Jan 10 22:12:36 2016] oh oke [Sun Jan 10 22:13:02 2016] oh i see they also have the proof por palindrome, but im not going to look at it [Sun Jan 10 22:14:33 2016] i tried proving it but was stuck with provkng n = length l with a hypothesis SS n = length l [Sun Jan 10 22:14:57 2016] guess i need to do the same trick as with the natural induction principle [Sun Jan 10 22:17:12 2016] Nik05: did you generalize dependent? [Sun Jan 10 22:17:21 2016] if not, you need to do that before induction [Sun Jan 10 22:17:50 2016] yes i did [Sun Jan 10 22:17:51 2016] if you did do that and still get that subgoal, then you're picking the wrong value for l in the inductive hypothesis when you try to use it [Sun Jan 10 22:18:42 2016] oh do i need to generalize n as well? [Sun Jan 10 22:20:02 2016] i generalized l... [Sun Jan 10 22:21:15 2016] no you only need to generalize l [Sun Jan 10 22:21:37 2016] but then when you use the induction hypothesis, you have a to pick a value for l that is exactly two shorter than the "current" one [Sun Jan 10 22:22:59 2016] hm, there was no picking... [Sun Jan 10 22:26:14 2016] jrw i will try again tomorrow. i have to go now [Sun Jan 10 22:26:23 2016] thank you for helping, have a nice day [Mon Jan 11 01:29:28 2016] How can I state that a value will not be a certain case of an inductive type. Like a <> S _. [Mon Jan 11 01:29:41 2016] Without having to specific arguments to construct an S-value. [Mon Jan 11 01:32:52 2016] you could go the other way, and say that it has a certain form (rather than saying the inverse) [Mon Jan 11 01:34:14 2016] in general its better to state things in the positive [Mon Jan 11 01:35:26 2016] but how to do exactly what you said, i dont really know, except with something convoluted like "forall n. ((fn n' => match n' with Z => true | _ => false) n) = true, ... [Mon Jan 11 01:36:42 2016] you could also define another inductive type without the case in question [Mon Jan 11 01:41:50 2016] you could go the other way, and say that it has a certain form (rather than saying the inverse) [Mon Jan 11 01:41:56 2016] it has more than two cases [Mon Jan 11 01:42:10 2016] I'll go with the bool thing [Mon Jan 11 02:06:53 2016] rrika : is there a problem with "forall b, a <> S b"? [Mon Jan 11 02:07:59 2016] oh, I should learn the syntax [Mon Jan 11 02:08:21 2016] thanks [Mon Jan 11 02:11:22 2016] is tauto for tautology or for t-automatic? [Mon Jan 11 02:28:44 2016] oh thats even better [Mon Jan 11 04:01:29 2016] I found a weird bug in proof general. Sometimes I try "simpl in H." and it doesn't modify H. Only when I change it to "in *" and back to "in H" it works. [Mon Jan 11 04:14:14 2016] oh, silly me, I confused "simpl H" with "simpl in H". [Mon Jan 11 08:58:36 2016] jrw how would i choose this l that is 2 shorter? [Mon Jan 11 09:03:59 2016] i only got l, nothing else [Mon Jan 11 09:08:33 2016] oh maybe i can do it with a replace [Mon Jan 11 09:08:43 2016] ooh [Mon Jan 11 09:17:29 2016] i guess not [Mon Jan 11 09:24:01 2016] jrw I got the induction hypothesis ∀ l : list X, n = length l → P l [Mon Jan 11 12:21:16 2016] rrika: what would 'simpl H' do? [Mon Jan 11 12:31:37 2016] Nik05: right, so notice that hypothesis is for all l, so you have to pick l. [Mon Jan 11 12:31:55 2016] now, your proof may not make it seem like you're picking l, but you are [Mon Jan 11 12:36:00 2016] for example, your goal may have been "P foo and you did "apply IH", that's picking l to be foo [Mon Jan 11 12:38:06 2016] intuitively, you need to peel off the head and tail of the list before applying the IH [Mon Jan 11 12:39:07 2016] jrw my goal is P l, just l [Mon Jan 11 12:39:14 2016] i cant peel off anything else [Mon Jan 11 12:39:50 2016] okay but that l probably doesn't have the right length right? [Mon Jan 11 12:40:11 2016] you probably need to figure out a way to pull off the *last* element [Mon Jan 11 12:40:35 2016] oke [Mon Jan 11 13:06:46 2016] jrw do you mean to jse skmething like the "init" function frlm haskell? [Mon Jan 11 13:06:56 2016] use something* [Mon Jan 11 13:07:21 2016] something like that would work, yes [Mon Jan 11 13:07:32 2016] I think it should also work to just "destruct (rev l)" [Mon Jan 11 13:07:54 2016] benzrf, it does nothing in my case, but it's accepted syntactically. [Mon Jan 11 13:10:55 2016] ah oke destruct l and its rev. thank you hrw [Mon Jan 11 13:11:08 2016] mobile typing is not easy [Mon Jan 11 14:21:34 2016] jrw im back behind a pc. But how would i destruct (rev l) if i dont got any rev l? [Mon Jan 11 14:24:58 2016] you can destruct anything you like [Mon Jan 11 14:25:24 2016] if it doesn't relate to anything in the context or the goal, you'll end up with the same goal [Mon Jan 11 14:25:30 2016] yes [Mon Jan 11 14:31:20 2016] but i dont got anything related to rev l... [Mon Jan 11 14:31:49 2016] well, it wasn't in your goal or context [Mon Jan 11 14:32:02 2016] so it's branching on the list constructors, but you won't see any "effect" of that [Mon Jan 11 15:47:33 2016] how can I swap a=b in the goal? [Mon Jan 11 15:47:50 2016] apply symmetry [Mon Jan 11 15:47:56 2016] or symetry, I don't recall [Mon Jan 11 15:48:05 2016] symmetry [Mon Jan 11 15:48:32 2016] ah thanks [Mon Jan 11 15:48:43 2016] just "symmetry" actually, it's not a lemma [Mon Jan 11 15:50:50 2016] if I have a rewrite rule with too many placeholders and coq can't infer the values, how can I help it out? [Mon Jan 11 15:51:32 2016] you can probable specify the variables, check the tactics list [Mon Jan 11 15:52:09 2016] https://coq.inria.fr/distrib/current/refman/Reference-Manual010.html#sec381 [Mon Jan 11 15:52:13 2016] thank you [Mon Jan 11 15:52:52 2016] i suppose you can also write intermediate steps with assert [Mon Jan 11 15:53:23 2016] like, to rewrite a into c, you might assert (a = b), prove it, then assert (b=c), prove it, and rewrite [Mon Jan 11 15:53:44 2016] or replace [Mon Jan 11 16:33:40 2016] Nik05: you should try "remember (rev l) as foo. destruct foo." or "destruct (rev l) eqn:?" [Mon Jan 11 16:41:13 2016] jrw oh what does the eqn:? do? [Mon Jan 11 16:41:37 2016] eqn:NAME remember the relation of the original subject of destruction to each case it generates [Mon Jan 11 16:41:44 2016] oh right [Mon Jan 11 16:41:50 2016] Nik05: it basically gives you an equality for each case [Mon Jan 11 16:41:54 2016] ah that is it [Mon Jan 11 16:42:06 2016] the "remember ..." is a manual way of doing the same thing [Mon Jan 11 16:42:17 2016] oke [Mon Jan 11 16:49:03 2016] jrw I got the hypothesis rev l = []. Why cant i reduce this to l = [] with inversion? [Mon Jan 11 16:49:59 2016] you need to prove this, I think [Mon Jan 11 16:50:02 2016] rev is not a constructor [Mon Jan 11 16:50:05 2016] Nik05: inversion doesn't typically work with functions, only with constructors. you can either destruct l or prove a lemma [Mon Jan 11 16:50:16 2016] oh oke [Mon Jan 11 16:55:02 2016] ironically, I always forget about the remember tactic [Mon Jan 11 16:55:09 2016] I end up using pose proof ... as instead [Mon Jan 11 16:57:59 2016] :D [Mon Jan 11 16:58:11 2016] now i feel so stupid [Mon Jan 11 17:03:38 2016] i cant even proof rev l = [] -> l = [] [Mon Jan 11 17:17:43 2016] just destructing l, simplifying and using discriminate for the cons case should do it [Mon Jan 11 17:21:38 2016] what does discriminate do? [Mon Jan 11 17:22:31 2016] any obvious inequalities in the context are resolved ex nihilo [Mon Jan 11 17:22:47 2016] that is, they can be rewritten as derivations of False, and thus trivial [Mon Jan 11 17:31:24 2016] well it doesn't seem to work, there [Mon Jan 11 17:31:32 2016] the hypothesis contains a ++ [Mon Jan 11 17:32:27 2016] ah, right [Mon Jan 11 17:32:40 2016] induction then [Mon Jan 11 17:35:39 2016] even then, it's not trivial going from rev tail ++ head :: nil to the induction hypothesis [Mon Jan 11 17:35:49 2016] I suspect you need a lemma for that [Mon Jan 11 17:37:29 2016] true [Mon Jan 11 17:40:14 2016] ah, no, no other lemmas needed [Mon Jan 11 17:40:26 2016] the trick is to destruct twice [Mon Jan 11 17:40:56 2016] first destruct l to get the bogus hypothesis of rev l ++ [a] = [], then destruct (rev l) to show that no matter what it returns, the hypothesis is false (via discriminate) [Mon Jan 11 17:43:25 2016] johnw it doesnt do it... [Mon Jan 11 17:43:42 2016] Nik05: https://gist.github.com/87e2928b29761e17b427 [Mon Jan 11 17:44:06 2016] oh [Mon Jan 11 17:44:35 2016] in fact, the "simpl; " can be deleted too [Mon Jan 11 17:46:11 2016] So discriminate does the same as inversion H? [Mon Jan 11 17:46:32 2016] it requires an inequality, in this case: cons _ _ = nil [Mon Jan 11 17:46:44 2016] or rather, an equality that cannot be true [Mon Jan 11 17:46:59 2016] inversion could work here too, hadn't tried [Mon Jan 11 17:47:05 2016] (might work here too) [Mon Jan 11 17:47:13 2016] >(** **** Exercise: 3 stars (binary_commute) *) [Mon Jan 11 17:47:21 2016] Either I'm missing the obvious or this should be 5 stars. [Mon Jan 11 17:47:29 2016] johnw yes inversion works [Mon Jan 11 17:47:35 2016] Solved everything before that really quickly. [Mon Jan 11 17:47:57 2016] Oh, I read the wrong header. >(** **** Exercise: 5 stars, advanced (binary_inverse) *) [Mon Jan 11 17:48:00 2016] 5 stars after all [Mon Jan 11 17:48:05 2016] rrika is it from SF? [Mon Jan 11 17:48:07 2016] yes [Mon Jan 11 17:48:11 2016] oke [Mon Jan 11 17:48:12 2016] rrika: there are times when the stars won't match your individual experience [Mon Jan 11 17:48:31 2016] sort of depends on your background [Mon Jan 11 17:48:34 2016] oh nice [Mon Jan 11 17:48:39 2016] I'm much further than yesterday. :) [Mon Jan 11 17:49:16 2016] Todays breakthrough was not intro-ing everything, do induction, then intro the rest. [Mon Jan 11 17:50:25 2016] rrika which chapter are you doing? [Mon Jan 11 17:50:55 2016] rrika: and you learned why not intro-ing everything works? [Mon Jan 11 17:51:23 2016] Nik05, I'm at the bottom of Inductions.v [Mon Jan 11 17:51:29 2016] ah oke [Mon Jan 11 17:52:16 2016] for me it started to become difficult with proving classical logic in Logic.v and Prop.v now... [Mon Jan 11 17:55:05 2016] johnw, to be honest, I don't know. Now that I think about it, it shouldn't matter. [Mon Jan 11 17:55:23 2016] uh, damn, just when I thought I had it nailed. [Mon Jan 11 17:55:30 2016] well, it's a fine point, but a very good one to understand thoroughly [Mon Jan 11 17:55:40 2016] what language are you used to coding in? [Mon Jan 11 17:55:48 2016] you mean other than coq? [Mon Jan 11 17:55:50 2016] yes [Mon Jan 11 17:55:55 2016] python, c++ [Mon Jan 11 17:56:04 2016] here C++ and some haskell [Mon Jan 11 17:56:14 2016] (I also did Rust and Prolog before) [Mon Jan 11 17:56:46 2016] when you "intro" too much, you take away variables from your hypotheses, fixing them to specific values [Mon Jan 11 17:57:04 2016] but then you have generalize, right? [Mon Jan 11 17:57:11 2016] right, generializing goes in the other directiosn [Mon Jan 11 17:57:21 2016] in a lot of cases, it doesn't matter [Mon Jan 11 17:57:32 2016] the destruct (rev l) was brilliant [Mon Jan 11 17:57:37 2016] the more general version always works when the less general version works [Mon Jan 11 17:57:46 2016] but the converse is not true, and that's when it matters [Mon Jan 11 17:58:02 2016] shouldn't every occurance of the induction variable get replaced for the case I'm currently in. regardless if in hypothesis or goal. [Mon Jan 11 17:58:22 2016] yes, it's the *other* variables that are in play that this is concerning [Mon Jan 11 17:58:31 2016] say you have two lists, xs and ys [Mon Jan 11 17:58:40 2016] forall xs ys, rev xs = rev ys -> xs = ys [Mon Jan 11 17:58:47 2016] and you use "intros." [Mon Jan 11 17:59:16 2016] just use inversion :P [Mon Jan 11 17:59:39 2016] now your hypothesis says that rev xs = rev ys. If you induct on xs, then you have to prove that rev [] = rev ys [Mon Jan 11 18:00:02 2016] sorry, you have to prove [] = ys, given rev [] = rev ys [Mon Jan 11 18:00:16 2016] one sec, this may not be a case where it matters [Mon Jan 11 18:00:17 2016] that's the problem I ran into a lot [Mon Jan 11 18:00:19 2016] let me find one that does [Mon Jan 11 18:00:39 2016] don't bother too much actually, I've got plenty of opportunity to mess up my intros. [Mon Jan 11 18:00:45 2016] johnw im working on one where it matters [Mon Jan 11 18:00:47 2016] and analyze [Mon Jan 11 18:00:50 2016] Lemma list_ind_middle : ∀ X (P : list X -> Prop), P [] -> (∀ x, P [x]) -> (∀l, P l -> ∀ x y, P (x :: snoc l y)) -> ∀ l, P l. [Mon Jan 11 18:00:53 2016] :) [Mon Jan 11 18:01:26 2016] ah, right it does matter here [Mon Jan 11 18:01:33 2016] so, in the "cons" case, we end up with this: [Mon Jan 11 18:01:36 2016] H : rev (a :: xs) = rev ys [Mon Jan 11 18:01:37 2016] IHxs : rev xs = rev ys -> xs = ys [Mon Jan 11 18:01:41 2016] well, that's never going to be provable [Mon Jan 11 18:01:44 2016] what we *wanted* was this: [Mon Jan 11 18:01:52 2016] H : rev (a :: xs) = rev ys [Mon Jan 11 18:02:00 2016] IHxs : forall ys, rev xs = rev ys -> xs = ys [Mon Jan 11 18:02:14 2016] to say that if rev xs = rev something, then xs = that something [Mon Jan 11 18:02:21 2016] the "intros." took the "ys" away from our IHxs [Mon Jan 11 18:03:37 2016] if that doesn't make sense, just let it sit in the back of your brain, it'll came back later [Mon Jan 11 18:03:43 2016] will do [Mon Jan 11 18:18:38 2016] how do you go from the goal a::l1 = b::l2 to goals a=b, l1=l2 ? [Mon Jan 11 18:18:46 2016] f_equal [Mon Jan 11 18:19:22 2016] so, this is a lemma? [Mon Jan 11 18:19:34 2016] yes [Mon Jan 11 18:19:36 2016] a very simple one, yes [Mon Jan 11 18:19:51 2016] weird [Mon Jan 11 18:19:52 2016] thanks [Mon Jan 11 18:20:11 2016] the proof of rev l1=rev l2 -> l1=l2 was a bit cumbersome... [Mon Jan 11 18:20:17 2016] It's just: x = y → f x = f y [Mon Jan 11 18:21:06 2016] dont you ned f_equal2? [Mon Jan 11 18:21:41 2016] oh in this case I actually had a :: l1 = a :: l2 ;) [Mon Jan 11 18:21:58 2016] so I got lucky that f_equal worked well with currying (I guess) [Mon Jan 11 18:34:42 2016] jrw still have no idea how to get this [Mon Jan 11 18:34:48 2016] get what? [Mon Jan 11 18:35:20 2016] companion_cube: that rev proof required also proving "app_inj_tail", which was much more cumbersome [Mon Jan 11 18:35:33 2016] :s [Mon Jan 11 18:35:36 2016] I did use it [Mon Jan 11 18:35:40 2016] since it involved a lot of sub-destructions and eliminating impossible hypothesis [Mon Jan 11 18:36:04 2016] companion_cube: https://github.com/jwiegley/notes/blob/master/ListRev.v [Mon Jan 11 18:36:23 2016] where app_inv = app_inj_tail [Mon Jan 11 18:36:41 2016] eww [Mon Jan 11 18:37:08 2016] hm i need that proof actually... [Mon Jan 11 18:37:09 2016] http://vrac.cedeela.fr/lists.v mine [Mon Jan 11 18:37:31 2016] intros ... x. generalize dependent x. == intros .... [Mon Jan 11 18:37:43 2016] just don't intros the variable you want to be generalized [Mon Jan 11 18:37:46 2016] yeah yeah right [Mon Jan 11 18:39:43 2016] johnw im trying to proof the middle induction principle for lists [Mon Jan 11 18:40:15 2016] custom induction principles are fun [Mon Jan 11 18:40:28 2016] no :P [Mon Jan 11 18:40:47 2016] im stuck for a few days :P [Mon Jan 11 18:41:11 2016] Have found the proof in Coq d'Art, but its really ugly :P [Mon Jan 11 18:41:33 2016] so im trying to proof it with another custom induction principle on natural numbers [Mon Jan 11 18:41:39 2016] jrw already solved it a few days ago :) [Mon Jan 11 18:41:57 2016] Coq isn't ready yet for daily usage by mathematicians, I'm afraid :/ [Mon Jan 11 18:42:44 2016] companion_cube: see the mathcomp project; or did you mean non-compsci mathematicians? [Mon Jan 11 18:44:07 2016] I mean mathematicians who aren't interested in Coq in itself, but just want to prove their stuff [Mon Jan 11 18:45:49 2016] luckely im not a mathematician :P [Mon Jan 11 18:47:05 2016] well even a computer scientist might not care about type theory :) [Mon Jan 11 18:49:05 2016] Nik05: no? [Mon Jan 11 18:49:10 2016] then why are you messing with coq? [Mon Jan 11 18:49:21 2016] benzrf i think its interesting [Mon Jan 11 18:49:31 2016] well what do you consider to be the meaning of 'mathematician' [Mon Jan 11 18:50:20 2016] people that work with math on a daily basis [Mon Jan 11 18:50:32 2016] no wait i do that too... but not this kind of math [Mon Jan 11 18:51:26 2016] Im just using math for engineering and describing some physics [Mon Jan 11 18:51:48 2016] maybe i should have studied mathematics [Mon Jan 11 19:08:18 2016] I think i just need to proof rev xs = ys -> xs = rev ys [Mon Jan 11 19:09:02 2016] Nik05: isn't that the same as saying rev (rev xs) = xs? [Mon Jan 11 19:09:07 2016] aka, rev_involutive [Mon Jan 11 19:09:34 2016] oh already proved rev_involutive [Mon Jan 11 19:09:58 2016] but how is that the same? [Mon Jan 11 19:09:59 2016] that should make "rev xs = ys -> xs = rev ys" trivial [Mon Jan 11 19:10:00 2016] one sec [Mon Jan 11 19:12:07 2016] forall (H : rev xs = ys), xs = rev ys. Proof. rewrite <- H. [Mon Jan 11 19:12:13 2016] that leaves you at "xs = rev (rev xs)". :) [Mon Jan 11 19:12:18 2016] oh :P [Mon Jan 11 19:12:27 2016] oh damn [Mon Jan 11 19:12:40 2016] im thinking way to hard :P [Mon Jan 11 19:12:53 2016] was doing all these inductions... its just a simple rewrite [Mon Jan 11 19:12:55 2016] usually if you see f x = y -> x = g y, it's the same as f (g x) = x [Mon Jan 11 19:13:28 2016] that's how I noticed it [Mon Jan 11 19:13:45 2016] yes :) [Mon Jan 11 19:16:48 2016] Looks like my Search isnt working at all... [Mon Jan 11 19:16:55 2016] Search length rev, i get nothing [Mon Jan 11 19:17:11 2016] as a hint, ssreflect's Search (provided by its ssrmatching plugin) is all kinds of better [Mon Jan 11 19:17:28 2016] after you install ssreflect 1.6, you put: [Mon Jan 11 19:17:29 2016] Require Import mathcomp.ssreflect.ssreflect. [Mon Jan 11 19:17:29 2016] From mathcomp Require Export ssrmatching. [Mon Jan 11 19:17:34 2016] oh oke [Mon Jan 11 19:17:37 2016] and now "Search (length (rev _))". [Mon Jan 11 19:17:54 2016] actually, I think you only need the second line [Mon Jan 11 19:18:33 2016] it immediately finds: [Mon Jan 11 19:18:34 2016] rev_length forall (A : Type) (l : list A), length (rev l) = length l [Mon Jan 11 19:18:44 2016] maybe i should recompile everything... [Mon Jan 11 19:20:56 2016] wtf Error: The reference rev_length was not found in the current environment. [Mon Jan 11 19:21:23 2016] did you Require Import List.? [Mon Jan 11 19:21:51 2016] johnw im not using any Coq libraries everything from proofed myself or preproven in SF [Mon Jan 11 19:21:56 2016] ah, ok [Mon Jan 11 19:22:10 2016] and SF should import everything recursively [Mon Jan 11 19:23:35 2016] Result for command Search rev length . : [Mon Jan 11 19:23:37 2016] i dont get it [Mon Jan 11 19:24:56 2016] :S [Mon Jan 11 19:25:20 2016] oh maybe because its in a Module? [Mon Jan 11 19:25:36 2016] hmm? [Mon Jan 11 19:25:47 2016] is it in a module that's not imported? [Mon Jan 11 19:25:58 2016] maybe it is [Mon Jan 11 19:26:12 2016] how do i know if its in a module? [Mon Jan 11 19:26:27 2016] that's a great quetsion [Mon Jan 11 19:26:52 2016] ;p [Mon Jan 11 19:27:55 2016] so strange, because rev_involutive is just below it [Mon Jan 11 19:30:00 2016] :S [Mon Jan 11 19:31:04 2016] really strange that SF put it in a module, thats why its not shown [Mon Jan 11 19:31:16 2016] and rev_involutive is in two .v files [Mon Jan 11 19:32:36 2016] oh wait rev_length is just for list of natural numbers -_- [Mon Jan 11 19:33:31 2016] all these theorems are missing [Mon Jan 11 19:38:25 2016] well atleast i can solve these really easy [Mon Jan 11 19:40:13 2016] jrw finally I proofed it :P [Mon Jan 11 19:40:24 2016] list_ind_middle is defined [Mon Jan 11 19:40:30 2016] thank you johnw [Mon Jan 11 19:41:33 2016] now to the proving of ∀ (X : Type) (l : list X), l = rev l → pal l [Mon Jan 11 19:42:33 2016] oh, that's an unpleasant one [Mon Jan 11 19:42:43 2016] I never could do it entirely on my own [Mon Jan 11 19:42:52 2016] i should try again [Mon Jan 11 19:46:01 2016] wait i now have this custom inductive principle, but how does the naming with as work? [Mon Jan 11 19:48:53 2016] ah now it works better [Mon Jan 11 20:10:11 2016] oh f_equal is a tactic. I was doing apply f_equal all the time [Mon Jan 11 20:33:13 2016] Nik05: it's both [Mon Jan 11 20:34:28 2016] i know now :) [Mon Jan 11 20:38:48 2016] I only need to proof this: snoc l1 x = snoc l2 x -> l1 = l2 Am I thinking to hard? [Mon Jan 11 20:39:36 2016] Nik05: no, that's nontrivial [Mon Jan 11 20:39:52 2016] Nik05: you need to know that snoc partially applied on its second arg is injective [Mon Jan 11 20:41:24 2016] yes [Mon Jan 11 20:41:31 2016] But how? :) [Mon Jan 11 20:41:48 2016] probably induction on l1 [Mon Jan 11 20:42:00 2016] tried induction on l1, on (snoc l1 x) [Mon Jan 11 20:42:51 2016] 1 sec [Mon Jan 11 20:43:58 2016] Nik05: should follow by induction on l1 provided you haven't intros'd l2 (or just do "generalize dependent l2" before inducting) [Mon Jan 11 20:44:18 2016] oke [Mon Jan 11 20:45:17 2016] ah hey jrw [Mon Jan 11 20:45:25 2016] hey :) [Mon Jan 11 20:45:39 2016] I proofed my induction principle, finally [Mon Jan 11 20:46:16 2016] nice [Mon Jan 11 20:55:27 2016] i dont see how i can use the induction hypothesis in this proof [Mon Jan 11 21:08:44 2016] palindrome_converse is defined [Mon Jan 11 21:09:01 2016] still need to proof the injectivity of snoc... [Mon Jan 11 21:52:17 2016] Nik05: what's the definition of snoc again? [Mon Jan 11 21:57:39 2016] jrw snoc l v = match l with | [] => v | h :: t => h :: snoc t v [Mon Jan 11 21:57:57 2016] ah okay, one sec [Mon Jan 11 21:59:07 2016] Nik05: I was able to prove it by induction on l1 [Mon Jan 11 21:59:17 2016] you need to make sure l2 is *not* intro'd [Mon Jan 11 21:59:57 2016] hm that fast... [Mon Jan 11 22:01:23 2016] but the second goal is x :: l1' = l2 with the hypothesis snoc (x1 :: l1') x = snoc l2 x [Mon Jan 11 22:01:56 2016] right, so you'll need to destruct l2 [Mon Jan 11 22:02:07 2016] to use the induction hypotehesis i have to somehow remove x1... [Mon Jan 11 22:02:34 2016] yes thats what i have here as well [Mon Jan 11 22:04:15 2016] if l2 is [], you should be able to derive a contradiction [Mon Jan 11 22:04:44 2016] if it is x2 :: l2', then you can simplify the hypothesis and use inversion to get x1 = x2 [Mon Jan 11 22:04:55 2016] then f_equal will reduce the goal to the induction hypothesis [Mon Jan 11 22:05:12 2016] this is ofcourse a contradiction: snoc l1' x = [ ] [Mon Jan 11 22:07:22 2016] oh wait got it :P [Mon Jan 11 22:07:40 2016] got a sublemma to proof snoc l x = [] -> False [Mon Jan 11 22:07:51 2016] But why can't inversion figure this out? [Mon Jan 11 22:08:07 2016] you could "destruct l; discriminate" [Mon Jan 11 22:08:42 2016] oh [Mon Jan 11 22:08:51 2016] inversion isn't so great at seeing through fixpoints [Mon Jan 11 22:09:05 2016] yes you told this earlier today :P [Mon Jan 11 22:09:34 2016] oh right, thats it... [Mon Jan 11 22:13:36 2016] oh man, the proof was really simple... [Mon Jan 11 22:14:07 2016] just shortend my proof by moving a inversion upwards [Mon Jan 11 22:15:38 2016] Thank you jrw and johnw [Mon Jan 11 22:15:59 2016] Nik05: np. does that mean you finished a complete proof of the pal thing? [Mon Jan 11 22:16:32 2016] yes jrw :P [Mon Jan 11 22:17:00 2016] cool. congrats! [Mon Jan 11 22:17:14 2016] thank you [Mon Jan 11 22:17:16 2016] this is the first "new" solution to that exercise I've seen in ~5 years [Mon Jan 11 22:17:26 2016] cool [Mon Jan 11 22:18:17 2016] what is the normal way to do it? [Mon Jan 11 22:21:18 2016] Nik05: the way I've always seen people do it is by so-called "strong induction" on the length [Mon Jan 11 22:21:30 2016] which is where you prove the following related lemma: [Mon Jan 11 22:21:47 2016] forall n l, length l <= n -> rev l = l -> pal l [Mon Jan 11 22:21:50 2016] by induction on n [Mon Jan 11 22:22:00 2016] (without introducing l) [Mon Jan 11 22:22:09 2016] oh <= n... [Mon Jan 11 22:22:12 2016] your induction hypothesis then says something about every list of any smaller length [Mon Jan 11 22:22:22 2016] so when you peel the head and the end of the list off [Mon Jan 11 22:22:33 2016] you just prove it's shorter, and you get the induction hypothesis [Mon Jan 11 22:24:05 2016] trying to do it in my head now [Mon Jan 11 22:26:25 2016] who found out to do induction on less than or equal the length of the list? [Mon Jan 11 22:26:59 2016] oh you already said "strong induction", will search for it [Mon Jan 11 22:27:20 2016] "strong induction" just means you get to assume the IH for all smaller values, not just the previous one [Mon Jan 11 22:27:49 2016] modifying the theorem to include a hypothesis of the form ... <= n, and then inducting on n is a way to achieve strong induction in coq [Mon Jan 11 22:31:03 2016] and then just do a destruct on l and you have proven the first step [Mon Jan 11 23:15:24 2016] i wonder how anyone is supposed to do rev_pal knowing only what SF has taught them up to that point [Mon Jan 11 23:15:57 2016] both the custom induction principle, and the "length trick" would be beyond anyone at that point in the text, as far as I can tell [Mon Jan 11 23:19:37 2016] yeah I have no idea [Mon Jan 11 23:19:48 2016] you don't need the custom induction principle [Mon Jan 11 23:19:54 2016] you can just do it "inline" [Mon Jan 11 23:20:08 2016] but you definitely need something like the length trick to get a stronger IH [Mon Jan 11 23:30:18 2016] yeah, tried another few hours, I give up again (on doing it without the length trick) [Mon Jan 11 23:35:23 2016] what other approaches are there? [Mon Jan 11 23:35:52 2016] I'm wondering which approach the SF authors had in mind [Mon Jan 11 23:37:18 2016] https://stackoverflow.com/questions/24363319/proving-that-a-reversible-list-is-a-palindrome-in-coq [Mon Jan 11 23:37:23 2016] the standard two approaches :( [Mon Jan 11 23:37:34 2016] I'll ask Pierce the next time I see him [Mon Jan 11 23:40:23 2016] johnw: you going to POPL? [Mon Jan 11 23:40:27 2016] sadly, no [Mon Jan 11 23:40:39 2016] :\ [Tue Jan 12 00:16:17 2016] johnw: okay here's a third way https://gist.github.com/wilcoxjay/3657f69f0168a223d930 [Tue Jan 12 00:16:39 2016] I think this might be the most "elementary" [Tue Jan 12 00:16:44 2016] though it's long-winded [Tue Jan 12 00:17:12 2016] basic idea is to define an inductive type with nil, singleton, and add-to-front-and-back-at-once constructors [Tue Jan 12 00:17:18 2016] convert back and forth to regular lists [Tue Jan 12 00:17:25 2016] use that to prove induction principle [Tue Jan 12 01:14:51 2016] that's the "custom induction principle" approach though [Tue Jan 12 01:15:01 2016] one of the two approaches I know of so far, that I wouldn't have known up until that point in the text [Tue Jan 12 01:21:26 2016] I'm not sure the custom induction principle is fundamental [Tue Jan 12 01:21:50 2016] I'm pretty sure I could redo that proof to get rid of the principle and just use its proof inline [Tue Jan 12 01:22:18 2016] what I wonder is, would you, as an SF student, have known how to do this then [Tue Jan 12 01:22:48 2016] hell no [Tue Jan 12 01:23:14 2016] maybe it's different for people who actually take the class in person [Tue Jan 12 01:23:20 2016] that could be [Tue Jan 12 02:02:59 2016] I believe the "length trick" is in the realm of what you can do at this point, as long as you already know about strong induction (which you usually do?) [Tue Jan 12 02:15:30 2016] I don't think I did, then... [Tue Jan 12 02:15:33 2016] anyway, night all [Tue Jan 12 03:29:43 2016] Lesson learned: removing an surjective function with apply f_equal is a good way to get into the position of having to prove impossible things. [Tue Jan 12 14:29:52 2016] goodmorning [Tue Jan 12 15:02:27 2016] I've noticed that a lot of my proofs seem to be "assert (H : foo). exact (bar _ _ _)." [Tue Jan 12 15:02:44 2016] Is that an idiomatic style, or is there a better way usually? [Tue Jan 12 15:06:13 2016] tbelaire: you can also use "assert ... by exact ... ." to connect the two statements together. or use "pose proof (bar ...) as H" as an alternative [Tue Jan 12 15:06:53 2016] okay. [Tue Jan 12 15:20:21 2016] tbelaire : if you just use exact, you can directly do: "assert (H := bar ...)" too [Tue Jan 12 15:20:37 2016] ah, nevermind, did not see the "pose proof" suggestion, which does basically the same [Tue Jan 12 15:20:37 2016] ah, nice [Tue Jan 12 15:58:36 2016] pose proof is what I would use too [Tue Jan 12 19:09:18 2016] jrw are you here? [Tue Jan 12 19:09:27 2016] Nik05: yep [Tue Jan 12 19:10:11 2016] Im now trying to prove basic things about <=, but I don't really see what to do. On which argument i should use induction on [Tue Jan 12 19:10:46 2016] how is <= defined? [Tue Jan 12 19:10:51 2016] and what properties are you proving? [Tue Jan 12 19:11:41 2016] Inductive le (n : nat) : nat → Prop := le_n : n ≤ n | le_S : ∀ m : nat, n ≤ m → n ≤ S m [Tue Jan 12 19:11:59 2016] okay [Tue Jan 12 19:12:14 2016] so then you probably want to induct on the proof of le itself, rather than an argument [Tue Jan 12 19:12:29 2016] I proofed ∀n 0 <= n, and n <= m -> S n <= S m [Tue Jan 12 19:12:50 2016] okay, which one are you stuck on? [Tue Jan 12 19:13:04 2016] oh [Tue Jan 12 19:13:19 2016] forall m n o, m <= n -> n <= o -> m <= o and Sn_le_Sm__n_le_m [Tue Jan 12 19:13:27 2016] but the last one i can solve with the first [Tue Jan 12 19:16:01 2016] oh sorry the last one is S n <= S m -> n <= m. [Tue Jan 12 19:16:12 2016] right [Tue Jan 12 19:16:48 2016] so, the general advice is to just try everything [Tue Jan 12 19:17:01 2016] making sure to leave as many things generalized/not-intros'd as possible [Tue Jan 12 19:17:21 2016] oke :P [Tue Jan 12 19:17:22 2016] more specific than that, there are a few heuristics that I use, but I always fall back on trying everything if they fail [Tue Jan 12 19:17:42 2016] one is to induct on hypotheses themselves instead of arguments [Tue Jan 12 19:20:15 2016] if you're stuck on a specific thing and can tell me what you've tried, I can give you more hints [Tue Jan 12 19:20:16 2016] oh already got it... [Tue Jan 12 19:20:23 2016] ah thank you :) [Tue Jan 12 19:20:39 2016] I had such a long proof with multiple inductions etc [Tue Jan 12 19:20:51 2016] but it was just an induction the hypothesis with o [Tue Jan 12 19:21:33 2016] not even a generalisation was needed [Tue Jan 12 19:22:24 2016] it's very rare to need more than one induction [Tue Jan 12 19:22:31 2016] it's common to need an induction + one or more destructions [Tue Jan 12 19:22:40 2016] oke [Tue Jan 12 19:22:58 2016] in programming terms, an induction is a recursive call, while a destruction is merely a "case" pattern match [Tue Jan 12 19:23:25 2016] (well, induction case matches too, but then recurses in some of the branches, if the constructor at that branch is recursive) [Tue Jan 12 19:23:32 2016] that's great advice [Tue Jan 12 19:23:41 2016] ah oke [Tue Jan 12 19:24:17 2016] nested inductions are like nested while loops or nested letrecs [Tue Jan 12 19:24:30 2016] further, if you never use your induction hypothesis, you can safely downgrade to a destruct [Tue Jan 12 19:24:44 2016] they occasionally show up, but rarely, especially in exercises :) [Tue Jan 12 19:25:46 2016] and when they do, you probably want to split that in another lemma :p [Tue Jan 12 19:26:57 2016] My proof of n <= m -> S n <= S m uses two inductions :P [Tue Jan 12 19:27:11 2016] But proofed that before i proofed le_trans... [Tue Jan 12 19:29:16 2016] oh no [Tue Jan 12 19:29:25 2016] that is also just a induction on a hypothesis [Tue Jan 12 19:30:24 2016] oh jrw I had a question about custom induction principles. How can i give my own names to the variables it uses? [Tue Jan 12 19:30:30 2016] using induction as [Tue Jan 12 19:32:32 2016] does "as" not work? [Tue Jan 12 19:32:57 2016] I tried but I have no idea how the syntax works with my custom principle [Tue Jan 12 19:33:27 2016] should be something like "induction x as [a | b c] using my_ind." [Tue Jan 12 19:34:02 2016] ah wait it follows the order of my forall arguments [Tue Jan 12 19:34:40 2016] i got it i think [Tue Jan 12 19:43:00 2016] I proofed them all [Tue Jan 12 19:44:30 2016] nice :) [Tue Jan 12 19:45:57 2016] earlier i was laying in bed trying to figure out on how to do the induction on the arguments... [Tue Jan 12 19:46:20 2016] just trying in my head if it made any sense... [Tue Jan 12 23:26:34 2016] how to do dependent destruction manually [Tue Jan 12 23:28:15 2016] or how to tell the dependent destruction tactic that the indices have decidable equality [Tue Jan 12 23:59:27 2016] noob0: I have a blog post about how to write the matches manually: http://homes.cs.washington.edu/~jrw12/dep-destruct.html [Tue Jan 12 23:59:42 2016] lol i am reading it now [Tue Jan 12 23:59:45 2016] :D [Tue Jan 12 23:59:46 2016] about cardinals [Tue Jan 12 23:59:53 2016] good good .. [Wed Jan 13 00:00:06 2016] if you post an example of where you're stuck, I can take a look [Wed Jan 13 00:00:21 2016] dependent destruction is the most powerful and also the most nasty thing in coq [Wed Jan 13 00:01:16 2016] .. it is strange that even CPDT settle with his wrapper dep_destruct around dependent destruction instead of addressing the real problem [Wed Jan 13 00:04:17 2016] what is the real problem? [Wed Jan 13 00:09:22 2016] well how to tell the dependent destruction tactic that the indices have decidable equality [Wed Jan 13 00:09:39 2016] or how to write specialized dependent destruction [Wed Jan 13 00:11:16 2016] by the way the last goal in refine (match x as x' in ... => _ | => _ end eq_refl _) is simply eq_refl... because eq_rect eq_refl is identity [Wed Jan 13 00:18:09 2016] noob0: I'm not sure what you mean, are you saying I can get rid of the convoy? [Wed Jan 13 00:18:53 2016] I just say you could put eq_relf instead of the final _ [Wed Jan 13 00:19:48 2016] oh, totally [Wed Jan 13 00:21:20 2016] jrw: yeah hehe [Wed Jan 13 00:29:26 2016] haha you talk about dep_destruct (cfold e1) of CPDT hehe great great [Wed Jan 13 00:31:12 2016] jrw: haha yeah haha clap clap [Wed Jan 13 01:09:24 2016] jrw: at the end in term_case you are a bit confused.. [Wed Jan 13 01:10:12 2016] jrw: the decidable equality thing and inversion pf happen in the tactic AFTER you have applied term_case [Wed Jan 13 01:11:02 2016] because inside term_case we know eq_rect eq_refl is identity [Wed Jan 13 01:11:42 2016] noob0: can you tell me what part of the post you're talking about? [Wed Jan 13 01:12:01 2016] at the end Lemma term_case : [Wed Jan 13 01:13:17 2016] there are basically two ideas : 1. the destruction principle 2. the auxilliary tactic that does pattern; apply des_principle; transport along any pf is identity by decidability of indices [Wed Jan 13 01:13:42 2016] right [Wed Jan 13 01:14:33 2016] I'm still not seeing what's wrong? [Wed Jan 13 01:14:39 2016] do I get them confused somewhere? [Wed Jan 13 01:16:35 2016] yes for example in the proof of term_case you specialize say X1 with eq_refl.. therefore we know stuff is identity [Wed Jan 13 01:23:16 2016] noob0: right, but I don't know before I do the destruct that it's going to work out, right? [Wed Jan 13 01:24:50 2016] jrw: well the way you state your lemma is so that it work out, right? [Wed Jan 13 01:25:23 2016] noob0: sure, but I don't see any other way to state the lemma [Wed Jan 13 01:25:33 2016] I guess I'm asking, how would you write it differently? [Wed Jan 13 01:26:34 2016] jrw: instead of rewrite <- decstuffstuff .. you may do simpl in X0. [Wed Jan 13 01:26:47 2016] ah [Wed Jan 13 01:26:51 2016] cool [Wed Jan 13 01:27:20 2016] so you're saying there's only need for transport in the aux tactic, never in the destruction principle? [Wed Jan 13 01:27:27 2016] those decstuffstuff happen outside at the time that you do your auxilliary tactic [Wed Jan 13 01:27:36 2016] yep [Wed Jan 13 01:27:38 2016] nice [Wed Jan 13 01:27:48 2016] can I acknowledge you in an updated version of the post? [Wed Jan 13 01:28:02 2016] lol 1337777 [Wed Jan 13 01:28:15 2016] nah forget [Wed Jan 13 01:28:55 2016] you sure? [Wed Jan 13 01:29:41 2016] the little piece which is lacking is to write clearly your auxilliary tactic and I am too lazy to write it for you [Wed Jan 13 01:31:16 2016] when I originally wrote the post I did write the tactic, just didn't include it in the published part [Wed Jan 13 01:31:29 2016] I wanted to make sure that the CPDT proof went through with the new tactic [Wed Jan 13 01:31:31 2016] and it did [Wed Jan 13 01:31:59 2016] yes [Wed Jan 13 01:32:22 2016] all I did was remind you hehe [Wed Jan 13 01:32:44 2016] well it was useful :) [Wed Jan 13 01:33:02 2016] I would prefer to mention you, but you'd rather I not, that's fine too [Wed Jan 13 01:33:12 2016] haaa this was good read.. YOU MUST ask this to be included in CPDT !! [Wed Jan 13 01:34:36 2016] glad you enjoyed it :) [Wed Jan 13 01:35:16 2016] hehe zleep time [Wed Jan 13 02:53:05 2016] does the mac CoqIDE have a REPL ? I am just getting started with Software Foundations... [Wed Jan 13 03:42:14 2016] i just write the stuff in the ide (or proof general) and jump back and forth [Wed Jan 13 04:42:12 2016] ok, right [Wed Jan 13 12:15:36 2016] What's the way to get a contradiction out of "S n = n"? [Wed Jan 13 12:17:11 2016] discriminate? [Wed Jan 13 12:17:51 2016] What does "No primitive equality found" mean? [Wed Jan 13 12:19:43 2016] tbelaire: by induction on n [Wed Jan 13 12:40:48 2016] How do I use the injective property of constructors? E.g. n <> n' -> S n <> S n' ? [Wed Jan 13 12:47:39 2016] in https://www.cis.upenn.edu/~bcpierce/sf/current/Basics.html#lab22 it is written : [Wed Jan 13 12:48:04 2016] https://www.irccloud.com/pastebin/XatQIoUD/ [Wed Jan 13 12:48:18 2016] what does it mean to -step through- ? [Wed Jan 13 12:48:21 2016] how ? [Wed Jan 13 12:48:35 2016] i am using coqide on mac [Wed Jan 13 12:48:58 2016] is it f2, f3, f4? [Wed Jan 13 12:49:16 2016] To step {back, forward} and to the cursor [Wed Jan 13 12:49:23 2016] ahha [Wed Jan 13 12:49:24 2016] ok i try [Wed Jan 13 12:50:12 2016] i see :) [Wed Jan 13 12:50:15 2016] :) [Wed Jan 13 12:50:20 2016] ctrl+cmd+down [Wed Jan 13 12:51:18 2016] ah, okay. [Wed Jan 13 12:51:27 2016] I am using coquille (the vim plugin) [Wed Jan 13 12:52:00 2016] hmmm... well, maybe terminal is better... [Wed Jan 13 12:53:33 2016] Unfortunately 8.5rc broke the plugin. There are changes to the ipc protocall. [Wed Jan 13 12:53:57 2016] what about emacs? [Wed Jan 13 12:57:50 2016] i cannot explain why that happens... [Wed Jan 13 12:57:59 2016] https://www.irccloud.com/pastebin/XatQIoUD/ [Wed Jan 13 12:58:07 2016] why ? [Wed Jan 13 13:00:58 2016] commutativity? [Wed Jan 13 13:03:24 2016] emacs works well with proof general [Wed Jan 13 13:03:56 2016] + is defined by induction on the first variable, right? [Wed Jan 13 13:04:21 2016] yeah [Wed Jan 13 13:04:55 2016] but we don't have any information about the first variable, only the second [Wed Jan 13 13:05:02 2016] so it fails to simplify [Wed Jan 13 13:05:19 2016] hmm, interesting, thanks [Wed Jan 13 13:31:54 2016] Ah, "unfold not. inversion." did what I needed. [Wed Jan 13 16:14:11 2016] tbelaire: for S n = n, you'd need: destruct n; discriminate [Wed Jan 13 16:14:30 2016] actually, that might not work either; it might need to be an induction [Wed Jan 13 16:15:04 2016] unfold not. then an inversion did the trick [Wed Jan 13 16:15:14 2016] yeah, that will work too [Wed Jan 13 16:17:05 2016] so, other ways to solve that: omega, intuition, auto, unfold not; intro; inversion H; contradiction, unfold not; intro; contradiction H; assumption [Wed Jan 13 16:17:08 2016] I'm sure there are others [Wed Jan 13 16:17:42 2016] jgross_: ping [Wed Jan 13 16:19:13 2016] omega? [Wed Jan 13 16:19:30 2016] omega solves basic algebra [Wed Jan 13 16:23:16 2016] New question. I'm trying to show a particular expression is in normal form [Wed Jan 13 16:23:18 2016] Example mistyped_program_can_go_wrong : [Wed Jan 13 16:23:20 2016] normal_form (tm_succ tm_true). [Wed Jan 13 16:23:44 2016] (Where normal form is ~ exists t', eval t t') [Wed Jan 13 16:24:57 2016] And I do unfold normal_form. unfold not. intros H. induction H. [Wed Jan 13 16:25:03 2016] and things are looking okay [Wed Jan 13 16:25:19 2016] why induction on H? [Wed Jan 13 16:25:33 2016] bring out the existential [Wed Jan 13 16:25:38 2016] just destruct [Wed Jan 13 16:25:42 2016] sure [Wed Jan 13 16:25:52 2016] have some x, and H : eval (tm_succ tm_true) x [Wed Jan 13 16:26:03 2016] but if I try and induct on the possible ways H is created [Wed Jan 13 16:26:07 2016] I just got [Wed Jan 13 16:26:17 2016] t2: tm, t2: tm ========== False [Wed Jan 13 16:26:19 2016] so you tried inversion on H? [Wed Jan 13 16:26:42 2016] That's something [Wed Jan 13 16:26:44 2016] hmm [Wed Jan 13 16:27:39 2016] Yes, that helps [Wed Jan 13 16:28:34 2016] Alright, off to make some "well typed" proposition [Wed Jan 13 16:28:40 2016] :) [Wed Jan 13 18:24:10 2016] does coq have dicts in the stdlib [Wed Jan 13 18:43:43 2016] yes [Wed Jan 13 18:43:45 2016] FMap [Wed Jan 13 18:44:12 2016] please, write a tutorial on how to use them once you figure it out :) [Wed Jan 13 18:44:21 2016] for the sake of proof, Ensemble (K * V) is better [Wed Jan 13 19:12:43 2016] strange SF says that is easiest to use induction on m in theorems ble_nat_true le_ble_nat [Wed Jan 13 19:13:03 2016] I tried that, couldn't proof it. So I tried induction on n and it was relaly easy [Wed Jan 13 19:19:18 2016] Oke solved everything for le. Went really fast now. [Wed Jan 13 19:29:00 2016] congrats [Wed Jan 13 19:29:41 2016] jgross_: ping [Wed Jan 13 19:30:08 2016] thank you [Wed Jan 13 19:33:13 2016] johnw: pong [Wed Jan 13 19:33:24 2016] that last tactic was no go either [Wed Jan 13 19:33:30 2016] exact same end situation [Wed Jan 13 19:33:43 2016] i just can't seem to prevent the "empty" case from taking over the evar [Wed Jan 13 19:33:58 2016] do you have ssreflect installed? do you want to play with my example? [Wed Jan 13 19:36:44 2016] jgross_: is it hurting me that my abstract representation is dependently typed? [Wed Jan 13 19:36:58 2016] I don't have ssr installed on the machine I'm using right now (but it's not too much trouble to install it), and am not sure I'll get a chance to play with it tonight, but I'll see if I can figure it out when I get a chance. [Wed Jan 13 19:37:33 2016] In the meantime, see if you can prove intermediate refinement lemmas, without destructing any variable in the main refinement proof. [Wed Jan 13 19:37:35 2016] ok, I've tried everything I can think of, but I'm not understanding something fundamental about these refinement proofs; and grokking that will be far more valuable than simply getting this dummy example to work [Wed Jan 13 19:37:46 2016] jgross_: oh hey, that's a good idea [Wed Jan 13 19:38:49 2016] jgross_: hmmm [Wed Jan 13 19:38:55 2016] jgross_: something about my initial goal actually looks fishy to me now [Wed Jan 13 19:39:01 2016] https://gist.github.com/bc1d18af7991b87c6939 [Wed Jan 13 19:39:11 2016] note what I'm returning at the bottom: (r_n', r_o'.2) [Wed Jan 13 19:39:19 2016] it shouldn't be mixing representations like that, should it? [Wed Jan 13 19:39:32 2016] that is, all my picks should be choosing r_n-based values, and never r_o-based values [Wed Jan 13 19:40:14 2016] but then again, I'm not sure [Wed Jan 13 19:53:09 2016] No, your statement looks fine. I think the issue is just that you're not allowed to destruct anything in the middle of refinement without jumping through a lot of hoops. [Wed Jan 13 19:53:20 2016] why is that? [Wed Jan 13 19:58:04 2016] Because you're essentially trying to do this: Goal forall n, exists x, match n with 0 => 0 | S _ => 1 end = x. Proof. intro n. eexists. destruct n. reflexivity. [Wed Jan 13 19:58:53 2016] ahhhh [Wed Jan 13 19:58:57 2016] now that makes sense! [Wed Jan 13 19:59:15 2016] the unification from the first branch is deciding the evar [Wed Jan 13 19:59:22 2016] so then I have to prove it also holds for the next case [Wed Jan 13 19:59:34 2016] this a perfect example, I'll use it in the docs, thanks [Wed Jan 13 20:00:01 2016] No problem. :) [Wed Jan 13 20:00:12 2016] now, what's the right answer :) [Wed Jan 13 20:00:28 2016] I need the branch is exist within my evar as well [Wed Jan 13 20:00:35 2016] which we've done with your new tactic [Wed Jan 13 20:00:43 2016] but at the very end, it still isn't happy [Wed Jan 13 20:04:06 2016] DelegateImpls : forall idx : Fin.t 0, seems to imply that this same issue pertains [Wed Jan 13 20:04:31 2016] (oh, never mind, that's unrelated to my vector) [Wed Jan 13 20:08:21 2016] Something like this? https://gist.github.com/JasonGross/ddaeb29c1a29fe819883 (I modified my tactic slightly. It's still kind-of fiddly. Works better for finite types like bool.) [Wed Jan 13 20:09:36 2016] huh, let me try [Wed Jan 13 20:12:59 2016] same result [Wed Jan 13 20:13:10 2016] here's how I'm using it now: https://gist.github.com/d2ae978997c950e95212 [Wed Jan 13 20:13:49 2016] do I have to destruct on r_n, and not n, because n doesn't exist in the concrete representation? [Wed Jan 13 20:13:53 2016] I'll try n now jic [Wed Jan 13 20:17:11 2016] how do I ask for the type of an existential? [Wed Jan 13 20:31:15 2016] Error: Instance is not well-typed in the environment of ?634 [Wed Jan 13 20:31:20 2016] is there any way to get the actual type error? [Wed Jan 13 20:31:32 2016] "I expected FOO but you gave me BAR"? [Wed Jan 13 20:32:40 2016] johnw: in the case of existentials, those errors are almost always caused by using something that wasn't in scope when the existential was introduced [Wed Jan 13 20:32:53 2016] ahh [Wed Jan 13 20:32:57 2016] so what you're really looking for is an error message like "you used variable x which wasn't in scope" [Wed Jan 13 20:33:02 2016] now, I don't know how to get such a msg [Wed Jan 13 20:33:03 2016] so, here's my problem [Wed Jan 13 20:33:12 2016] but maybe looking for that kind of error in your code will help [Wed Jan 13 20:33:18 2016] my "push" specification branches on n, but my implementation will branch on the concrete list representation [Wed Jan 13 20:33:34 2016] okay [Wed Jan 13 20:34:39 2016] in fact, that's the only way I can get the honing through [Wed Jan 13 20:34:55 2016] but honed that way, I end up with an unresolved goal after finishing the sharpening [Wed Jan 13 20:35:27 2016] so, keeping in mind that I have no idea what you're talking about, I would suggest trying to express the value of the existential that you want manually in the context where you introduce it [Wed Jan 13 20:35:35 2016] if you can't figure out what it should look like, then that's a fundamental problem [Wed Jan 13 20:35:42 2016] not any sort of problem that the right tactic will fix [Wed Jan 13 20:35:56 2016] jrw: https://gist.github.com/3d9d43579cc84218bdef [Wed Jan 13 20:36:01 2016] this is all about "push" [Wed Jan 13 20:36:32 2016] okay, one sec [Wed Jan 13 20:36:39 2016] jrw: ok, let me try expressing the existential manually [Wed Jan 13 20:36:59 2016] in the early context, not where you got stuck! [Wed Jan 13 20:37:00 2016] :) [Wed Jan 13 20:37:05 2016] right [Wed Jan 13 20:37:08 2016] at the very beginning [Wed Jan 13 20:37:14 2016] yep [Wed Jan 13 20:38:37 2016] ok, check this out: [Wed Jan 13 20:39:06 2016] https://gist.github.com/63cae8f0fdbd9f5a1b34 [Wed Jan 13 20:39:19 2016] I've instantiated exactly what I want the refinement to end up being [Wed Jan 13 20:39:24 2016] and it shows me that now in the final goal [Wed Jan 13 20:40:18 2016] but I still end up with: [Wed Jan 13 20:42:31 2016] added another note there [Wed Jan 13 20:42:35 2016] yeah I see it [Wed Jan 13 20:43:06 2016] unfortunately this looks like I'd have to understand the library you're using to help further :\ [Wed Jan 13 20:43:25 2016] you mean, the vectors? [Wed Jan 13 20:43:31 2016] that should be the only library code I'm using [Wed Jan 13 20:43:40 2016] i'm not using any ssreflect tactics [Wed Jan 13 20:43:50 2016] it's just that Vectors was built using ssreflect ordinals, and I was too lazy to rewrite it [Wed Jan 13 20:44:22 2016] no I mean wherever the custom tactics like "finish honing" are coming from [Wed Jan 13 20:44:29 2016] oh, ignoring those [Wed Jan 13 20:44:41 2016] it's just subst_evars; higher_order_reflexivity [Wed Jan 13 20:44:55 2016] you might need to know finish_SharpeningADT_WithoutDelegation [Wed Jan 13 20:45:17 2016] that's what might be biting me [Wed Jan 13 20:45:31 2016] i'll try poking around there [Wed Jan 13 20:45:33 2016] thanks, jgross_! [Wed Jan 13 20:45:50 2016] I thought you might have me confused with him :) [Wed Jan 13 20:46:01 2016] oh, haha [Wed Jan 13 20:46:08 2016] the whole time I thought you were still him [Wed Jan 13 20:46:12 2016] lol [Wed Jan 13 20:46:32 2016] too many nicks starting with j [Wed Jan 13 20:47:26 2016] digging into this library is a fun but deep rabbit hole :) [Wed Jan 13 20:47:46 2016] it's for doing program synthesis: going from a mathematically specified program to an optimized implementation by a series of provable refinement steps [Wed Jan 13 20:48:18 2016] this is fiat? [Wed Jan 13 20:48:21 2016] in this case, I'm building a Stack library based on sized vectors, and refining to an implementation based on linked lists [Wed Jan 13 20:48:22 2016] yes [Wed Jan 13 20:48:24 2016] cool [Wed Jan 13 20:49:15 2016] johnw: does it require 8.4pl2? [Wed Jan 13 20:49:27 2016] pl2-pl6 is fine [Wed Jan 13 20:49:30 2016] almost works with 8.5 [Wed Jan 13 20:51:50 2016] johnw: are you using this at bae or just on your own? [Wed Jan 13 20:52:02 2016] bae [Wed Jan 13 20:52:05 2016] cool [Wed Jan 13 20:52:32 2016] we intend to use this for building real software someday [Wed Jan 13 20:52:35 2016] I'm impressed that bae does stuff like this [Wed Jan 13 20:52:46 2016] yes, I like the research group there [Wed Jan 13 20:52:57 2016] it's not hard to get them excited about cool stuff in PL and type theory [Wed Jan 13 20:56:30 2016] johnw: what is Ensemble [Wed Jan 13 20:56:37 2016] mathematical sets [Wed Jan 13 20:56:52 2016] membership, but no equality tests [Wed Jan 13 20:56:59 2016] it's the A -> Bool type of set, but A -> Prop in this case [Wed Jan 13 20:57:03 2016] so really not computable [Wed Jan 13 21:03:02 2016] jgross_: did it! [Wed Jan 13 21:36:36 2016] is there a 'dependent split' [Wed Jan 13 22:05:40 2016] given [x : Fin (S n)], how can i get out a [Fin n + x = of_nat n] [Wed Jan 13 22:05:54 2016] (that's a type [+] there, not a nat [+] ) [Wed Jan 13 22:11:25 2016] benzrf: check out the lemmas with "caseS" in their name [Wed Jan 13 22:11:36 2016] it's not exactly what you're looking for, but I think it implies your thing [Wed Jan 13 22:20:46 2016] jrw: not really [Wed Jan 13 22:36:13 2016] shit how do i eliminate [x < 0] [Wed Jan 13 22:38:36 2016] oh no can i not implement, say, 'forall A : Type, 1 < 0 -> A' [Thu Jan 14 00:29:44 2016] benzrf: 'forall A : Type, 1 < 0 -> A is just "omega", isn't it? [Thu Jan 14 01:08:44 2016] johnw: To get better error messages, switch to 8.5. (You should be able to build enough of Fiat to get the relevant refinement goals in there, probably.) Then you get messages like "cannot instantiate ?X because "x" is not in its scope (variables in its scope are "a", "b", "c")." [Thu Jan 14 01:08:57 2016] jgross_: hey there [Thu Jan 14 01:09:10 2016] I'm looking forward to moving up to coq 8.5 once Ben is ready [Thu Jan 14 01:11:48 2016] Hey! Sorry I disappeared earlier. [Thu Jan 14 01:12:00 2016] no problem, it worked out [Thu Jan 14 01:12:06 2016] and solving it myself was worthwhile [Thu Jan 14 01:12:25 2016] ^.^ [Thu Jan 14 01:12:25 2016] now I get both why destruction was failing, and why it wasn't happy after getting the evar right [Thu Jan 14 01:12:59 2016] Yeah, I'm looking forward to 8.5 too. They're planning the first stable release this weekend. [Thu Jan 14 01:13:12 2016] what I need now is a DSL for describing what resource metrics matter, and then how to parameterize refinements based on what was specified [Thu Jan 14 01:13:16 2016] (There's still one major bug that I know of, where you can get [assert True] to fail with a unification error: https://coq.inria.fr/bugs/show_bug.cgi?id=4415) [Thu Jan 14 01:14:13 2016] jgross_: fwiw, I'd also like to see progress on the Javascript parser :) [Thu Jan 14 01:14:33 2016] I'm going to want to start writing an HTML4 parser soonish [Thu Jan 14 01:16:11 2016] I recently (like, two days ago) got the synthesized (ab)* parser to be the same speed as my hand-written one. [Thu Jan 14 01:16:28 2016] (I've been dealing with a lot of painful evar issues myself, recently.) [Thu Jan 14 01:16:58 2016] yeah, I saw your msg to the fiat mailing list; congrats! [Thu Jan 14 01:17:02 2016] Thanks! [Thu Jan 14 01:17:10 2016] will you be at MIT on Feb 11? I'm planning to come that day [Thu Jan 14 01:19:35 2016] So now I'm going to go back to working on moving closer to JavaScript for a bit (next up, I think, is coding up whitespace and comments and string literals, and a full arithmetical expression grammar; I think the only thing that'll need a new building block is combining comments with the arithmetical expression grammar). I am worried that the more interesting grammars are still going to be horrendously slow. [Thu Jan 14 01:20:00 2016] Alas, I'll be in NY 2/10-2/15; I'm mentoring a CFAR Workshop (rationality.org). [Thu Jan 14 01:20:01 2016] btw, how do I specify newline as a token? [Thu Jan 14 01:20:10 2016] What are you coming for? [Thu Jan 14 01:20:18 2016] Fiat discussions [Thu Jan 14 01:20:53 2016] i'll be in town that week meeting with various team members, but I want to spend time with just Clémente and Ben on Thu [Thu Jan 14 01:21:11 2016] well, and you if you'd been there :( [Thu Jan 14 01:21:19 2016] anyway, I'm heading off to finish reading your thesis now :) [Thu Jan 14 01:21:33 2016] newline: [Eval compute in String.String (ascii_of_nat 13) (String.String (ascii_of_nat 10) EmptyString)]? [Thu Jan 14 01:21:52 2016] i mean, matching it in your parser grammar [Thu Jan 14 01:22:31 2016] [[[ ("newline" ::== << $< ascii_of_nat 13 >$ >>) ]]]%grammar? [Thu Jan 14 01:22:42 2016] Yeah, something like that [Thu Jan 14 01:22:57 2016] nice, good to know! I didn't know if you pre-absorbed whitespace or something [Thu Jan 14 01:23:12 2016] (If you have suggestions for better notations, feel free to suggest them / make a pull request.) [Thu Jan 14 01:23:48 2016] this BNF syntax is a bit... syntax heavy... but not sure if I can do much better [Thu Jan 14 01:23:53 2016] Nope, I don't. You can see all the definitions in Parsers/ContextFreeGrammar/Core.v; that defines what a parse tree is, and how a grammar defines a parse tree. [Thu Jan 14 01:23:57 2016] too bad Coq doesn't support quasi-quoting [Thu Jan 14 01:24:10 2016] or have decent string handling [Thu Jan 14 01:24:14 2016] What do you want to quasiquote? [Thu Jan 14 01:24:25 2016] specify the BNF is a textual block that looks like a yacc BNF [Thu Jan 14 01:24:37 2016] then translate to this form [Thu Jan 14 01:24:49 2016] What does a yacc BNF look like? [Thu Jan 14 01:25:01 2016] ("nat" ::== << $< "digit" >$ | $< "digit" $ "nat" >$ >>) [Thu Jan 14 01:25:09 2016] would be: nat := digit | digit nat [Thu Jan 14 01:25:26 2016] Also, re timing, yeah, I'm disappointed, too, that the timing won't work out for us seeing each other. (But feel free to ask any questions about my thesis, or whatever, remotely.) [Thu Jan 14 01:25:45 2016] some day you and Ed and I can hang out [Thu Jan 14 01:25:53 2016] Yeah, I'd like that! [Thu Jan 14 01:26:55 2016] jgross_: example yacc grammar: https://www.lysator.liu.se/c/ANSI-C-grammar-y.html [Thu Jan 14 01:27:26 2016] you can attribute grammers by putting { CODE } after any right-side terminal or non-terminal [Thu Jan 14 01:27:43 2016] Hrm, you might be able to do "nat" := "digit" | "digit" "nat".... if you define a coercion from strings to items (via nonterminals), and define a coercion from item to production, and a coercion from production to Funclass which is concatenation, and then define | as an infix operator on production, and define := appropriately in the right context... [Thu Jan 14 01:28:00 2016] hmm.. that could work [Thu Jan 14 01:28:35 2016] The reason I don't do this is that I don't have a way to distinguish terminals from nonterminals. [Thu Jan 14 01:29:02 2016] what about "digit" for non-terminal, and #"digit" for terminal, as you have been doing? [Thu Jan 14 01:29:07 2016] But I could do something silly like disallowing single-character terminals and having the notation go to a terminal if it is a single character, or a nonterminal if its multiple characters [Thu Jan 14 01:29:19 2016] that could work too [Thu Jan 14 01:30:17 2016] Which do you think is better? [Thu Jan 14 01:30:31 2016] i think special handling of single-character is better [Thu Jan 14 01:31:00 2016] being single should be indication enough that it's terminal [Thu Jan 14 01:33:37 2016] jgross_: good night! [Thu Jan 14 01:35:58 2016] johnw: goodnight! I'll probably have the new notation pushed within half an hour. [Thu Jan 14 02:38:08 2016] johnw: Pushed. Now you can write things like "(ab)*" ::== "" || "a" "b" "(ab)*" [Thu Jan 14 03:11:37 2016] why does this work : [Thu Jan 14 03:11:41 2016] https://www.irccloud.com/pastebin/7Ksot22U/ [Thu Jan 14 03:11:46 2016] but this does not : [Thu Jan 14 03:12:00 2016] https://www.irccloud.com/pastebin/Pfr7T3Hb/ [Thu Jan 14 03:12:15 2016] from https://www.cis.upenn.edu/~bcpierce/sf/current/Basics.html#lab15 [Thu Jan 14 03:12:45 2016] the difference is in the direction in "rewrite -> plus_1_l." vs "rewrite <- plus_1_l." [Thu Jan 14 03:13:14 2016] the <- direction give : [Thu Jan 14 03:13:19 2016] https://www.irccloud.com/pastebin/ZrwhjDPO/ [Thu Jan 14 03:13:30 2016] but the -> direction gives: [Thu Jan 14 03:13:52 2016] Error: Tactic generated a subgoal identical to the original goal. [Thu Jan 14 03:14:09 2016] https://www.irccloud.com/pastebin/JDc3vmV0/ [Thu Jan 14 03:14:38 2016] so why is it so that (1+n) in "S n * (1 + n) = S n * S n" cannot be replaced with "S n " ? [Thu Jan 14 03:14:56 2016] why only the other way works ? [Thu Jan 14 03:17:04 2016] joco42: i'm not sure, but I wonder if rewrite is correctly finding the argument, try specifying it "rewrite -> (plus_1_l n)" [Thu Jan 14 03:17:40 2016] ahh [Thu Jan 14 03:17:42 2016] thanks [Thu Jan 14 03:17:56 2016] np [Thu Jan 14 03:18:02 2016] that works :) [Thu Jan 14 03:18:51 2016] what is the difference between "rewrite -> (plus_1_l n)" and "rewrite -> plus_1_l." ? [Thu Jan 14 03:20:24 2016] joco42: rewrite can ultimately only work on equalities, so if you give it a universally quantified equality it has to try to find the instantiation that you meant... I think it does this by something to do with existential variables, but I'm honestly not sure. [Thu Jan 14 03:21:54 2016] joco42 : (1 + n) is literally the same as (S n), which is why it's sometimes having trouble to rewrite with (1 + n = S n) [Thu Jan 14 03:22:07 2016] You can actually just do "reflexivity" instead of a rewrite with plus_1_l [Thu Jan 14 03:22:12 2016] ah, hadn't thought of that [Thu Jan 14 03:22:50 2016] (just to be clear, (1+n) is not syntactically the same as (S n), but they are convertible) [Thu Jan 14 03:29:45 2016] tejing: thanks [Thu Jan 14 03:30:03 2016] Cypi: thanks, i try that [Thu Jan 14 03:31:31 2016] ok, reflexivity works :) [Thu Jan 14 04:11:24 2016] is the pattern match in coq lazy ? [Thu Jan 14 04:11:32 2016] it seems so [Thu Jan 14 04:11:53 2016] Coq supports several reduction strategies [Thu Jan 14 04:12:10 2016] aham, ok :) [Thu Jan 14 04:12:23 2016] i was looking at this example from SF: [Thu Jan 14 04:12:26 2016] https://www.irccloud.com/pastebin/sxxuBrvW/ [Thu Jan 14 04:12:36 2016] and from this it seems that it is lazy... [Thu Jan 14 04:13:15 2016] Why? [Thu Jan 14 04:13:32 2016] because n' is not "evaluated" [Thu Jan 14 04:13:51 2016] or reduced [Thu Jan 14 04:14:05 2016] the 7th line [Thu Jan 14 04:14:26 2016] What is there to reduce? [Thu Jan 14 04:16:28 2016] well if n' were some more complex expression [Thu Jan 14 04:16:31 2016] i suppose [Thu Jan 14 04:16:56 2016] i am only having this idea because it reminds me of haskell evaluation [Thu Jan 14 04:17:02 2016] I'm not sure I understand where you would think Coq could/should do something differently [Thu Jan 14 04:18:18 2016] i was just trying to draw an analogy between haskell lazy evaluation and the reduction i see in coq - my question was if it makes sense to draw such analogy [Thu Jan 14 04:18:20 2016] or not ? [Thu Jan 14 04:18:30 2016] joco42: reductions in coq can be done in any order, and will both always terminate, and always reach the same normal form.. both properties are vital to the logic represented in coq being consistent. [Thu Jan 14 04:18:46 2016] As I said, you can ask Coq to to call-by-value or call-by-name if you want to. As it supports full-beta reduction, it does not matter [Thu Jan 14 04:18:51 2016] to do* [Thu Jan 14 04:19:03 2016] hmm [Thu Jan 14 04:19:09 2016] joco42: in coq, unlike in haskell, reduction MUST actually be done in the presence of free variables... this changes the dynamic in important ways [Thu Jan 14 04:19:10 2016] (or any other strategy, for that matter) [Thu Jan 14 04:19:14 2016] from SF: What we need is to be able to consider the possible forms of n separately. If n is O, then we can calculate the final result of beq_nat (n + 1) 0 and check that it is, indeed, false. And if n = S n' for some n', then, although we don't know exactly what number n + 1 yields, we can calculate that, at least, it will begin with one S, and this is [Thu Jan 14 04:19:14 2016] enough to calculate that, again, beq_nat (n + 1) 0 will yield false. [Thu Jan 14 04:19:44 2016] it will begin with one S, and this is _enough_ to calculate that, again, beq_nat (n + 1) 0 will yield false. [Thu Jan 14 04:20:04 2016] ahh [Thu Jan 14 04:20:15 2016] ok, so the point is having free variables [Thu Jan 14 04:20:42 2016] i was missing that [Thu Jan 14 04:20:49 2016] n is a free variable here [Thu Jan 14 04:21:43 2016] joco42: in any dependently typed language this difference becomes important, since computation must be done at compile time by the typechecker, and thus must be done in the presence of unknown values/free variables [Thu Jan 14 04:22:01 2016] ok, thanks for pointing that out [Thu Jan 14 04:22:24 2016] i keep this in mind [Thu Jan 14 05:12:20 2016] johnw: Is there any good literature on Coq you could recommend? The things I'm reading are either very basic or uncomprehensible :D. I don't need explanation on math, I just need explanation on coq. [Thu Jan 14 05:12:33 2016] johnw: you seem to be very knowledgable so I'd like some opinions :) [Thu Jan 14 05:17:09 2016] Fuco: https://coq.inria.fr/documentation (section "Other documentation") [Thu Jan 14 08:53:00 2016] I thought I could compare to values with "match a, b with | x, x => (* they're equal *) | _, _ => (* they're not *) end" [Thu Jan 14 08:53:09 2016] Gives me errors though, what do? [Thu Jan 14 08:55:24 2016] You probably have to prove that the type of a and b has decidable equality [Thu Jan 14 08:56:03 2016] hm, they're nats [Thu Jan 14 08:56:07 2016] So either directly prove "forall (a b : T), {a = b} + {a <> b}", or have a function "T -> T -> bool" with some properties that prove that this function is correct [Thu Jan 14 08:56:14 2016] then you already have that in the stdlib, a second [Thu Jan 14 08:56:46 2016] eq_nat_dec in Arith, or Nat.eq_dec provides the former [Thu Jan 14 08:57:00 2016] So you can match on "eq_nat_dec a b" [Thu Jan 14 08:58:53 2016] I see, thank you [Thu Jan 14 09:07:00 2016] rrika: coq would interpret what you wrote as two binds of the same variable x, not a requirement that b have the same value as a, so the first case of your match would always fire. (if coq didn't disallow it because they were the same variable anyway) [Thu Jan 14 09:30:17 2016] how do I use a sumbool value? [Thu Jan 14 09:31:14 2016] with "if" apparently [Thu Jan 14 09:41:14 2016] Greetings. [Thu Jan 14 09:41:37 2016] I'm trying to define an apparantly-incomplete recursive function, that I can prove to be complete due to some lemma. [Thu Jan 14 09:42:51 2016] Specifically, I have a Record consisting of a list of items, along with an axiom saying that at least one item with some property P exists in the list, and I want to define a function that --given the struct-- returns a list item that satisfies P. [Thu Jan 14 09:43:15 2016] I haven't been able to find any documentation on how to do this. [Thu Jan 14 09:43:24 2016] Are there some clues I could look at? [Thu Jan 14 10:11:56 2016] redlizard_, what do you mean by incomplete? [Thu Jan 14 10:13:02 2016] you're not removing one link from the list with each call? [Thu Jan 14 10:19:31 2016] rrika it has to be obviously complete [Thu Jan 14 10:19:52 2016] really obviously [Thu Jan 14 10:20:37 2016] Forexample, this is not possible: [Thu Jan 14 10:20:38 2016] merge [] ys = ys [Thu Jan 14 10:20:39 2016] merge (x:xs) ys = x:merge ys xs [Thu Jan 14 10:21:33 2016] it looks complete to me [Thu Jan 14 10:21:40 2016] rrika: I mean that when searching in this list, I don't want to define a value for the function for the empty list. [Thu Jan 14 10:21:44 2016] oh, it'd need one "merge" with match [Thu Jan 14 10:21:56 2016] I'm no expert on coq but I'm curious. Do you have example source? [Thu Jan 14 10:23:21 2016] rrika: Something like `Fixpoint search_P (mylist: list T): T := match mylist with |cons l ll => if P(l) then l else search_P ll end.` [Thu Jan 14 10:23:28 2016] Note the incomplete matching. [Thu Jan 14 10:23:37 2016] Because I don't want to define this function on the empty list. [Thu Jan 14 10:23:48 2016] redlizard_, if a list that contains one element that fulfills (P elem) you could say it fulfills (Q list), and then for all lists you say ((not (P head)) and Q list implies Q tail) [Thu Jan 14 10:24:05 2016] And if a list that fulfills Q has one element left, then it obviously fulfills P. [Thu Jan 14 10:24:19 2016] rrika: Sure. But how do you define the function in the first place? [Thu Jan 14 10:24:37 2016] Reasoning about the list containing a P isn't the problem. [Thu Jan 14 10:24:41 2016] Defining the search function is. [Thu Jan 14 10:25:09 2016] you could have the function take a value of the return type, that it uses in case it reaches a nil branch [Thu Jan 14 10:25:21 2016] like [Thu Jan 14 10:25:58 2016] pop_element (in_case_of_end: E) (list: List_of E) := match list with | head :: tail => head | [] => in_case_of_end end [Thu Jan 14 10:37:26 2016] oke its really annoying that split intros the forall variables... [Thu Jan 14 10:37:38 2016] trying to do a prooof... stuck on induction [Thu Jan 14 10:38:04 2016] Just had to generalize [Thu Jan 14 10:42:12 2016] redlizard_, I almost got it I think. [Thu Jan 14 10:45:49 2016] how can I specify a type that includes values of another type that fulfill a certain criterium? [Thu Jan 14 10:56:21 2016] redlizard_, I see your problem now [Thu Jan 14 11:21:09 2016] I was thinking maybe you could use (mylist: list T | mylist <> nil) [Thu Jan 14 11:21:15 2016] but I don't know how to go from there [Thu Jan 14 11:28:02 2016] coqide tells me on mac os: "Error: Cannot find library Induction in loadpath"- what should i do ? [Thu Jan 14 11:29:31 2016] http://stackoverflow.com/questions/16202666/coqide-cant-load-modules-from-same-folder [Thu Jan 14 11:29:33 2016] found it [Thu Jan 14 12:19:53 2016] redlizard_, I found something: http://seb.mondet.org/blog/post/coqtests-01-subsets.html [Thu Jan 14 12:20:07 2016] this seems like exactly what you need [Thu Jan 14 12:23:28 2016] rrika: This seems to mess with the codomain though. [Thu Jan 14 12:23:41 2016] @_@ codomain? [Thu Jan 14 12:24:04 2016] rrika: I want the function to actually return an argument. [Thu Jan 14 12:24:08 2016] Not a wrapper around one. [Thu Jan 14 12:24:17 2016] Or I would juse use Maybe. [Thu Jan 14 12:24:45 2016] I think it's possible using this, though I still need to read more about it [Thu Jan 14 12:35:14 2016] redlizard_: what about something like this? https://gist.github.com/wilcoxjay/91615af74c1c6cbdaf56 [Thu Jan 14 12:35:20 2016] Can I within one branch of a "match" get access to the proposition that the current pattern has matched, and none of the before? [Thu Jan 14 12:35:59 2016] What's the difference between False_rec and False_rect (used in the gist) [Thu Jan 14 12:36:11 2016] rrika: yes, sort of. you can use the "convoy pattern" to get an equality in each branch [Thu Jan 14 12:36:30 2016] how does that worK? [Thu Jan 14 12:36:37 2016] rrika: no real difference, they have slightly different types that have different consequences as far as universes are concerned [Thu Jan 14 12:37:09 2016] rrika: search for "convoy" in this page: http://adam.chlipala.net/cpdt/html/MoreDep.html [Thu Jan 14 12:37:17 2016] thank you [Thu Jan 14 12:38:46 2016] how does the second gap in False_rect get filled here? [Thu Jan 14 12:39:12 2016] rrika: the second gap is asking for a proof of False, which is the first goal after the refine. I solved it with firstorder [Thu Jan 14 12:39:37 2016] you could also solve it more directly by pulling out the contradiction from the fact that the list is empty [Thu Jan 14 12:40:46 2016] that's where I was going with the question about match. [Thu Jan 14 12:41:52 2016] right, so in this case coq noticed that the discriminee (the thing being matched on) appears in the type of the proposition that's the second argument to getP', and so it refines the type in each branch to be that case [Thu Jan 14 12:42:04 2016] one thing you can never do in coq is "leave out" a case of a match [Thu Jan 14 12:42:14 2016] instead you have to go inside the case and then prove a contradiction [Thu Jan 14 12:42:16 2016] is there a way to do this without using any tactics [Thu Jan 14 12:42:29 2016] rrika: of course, there's always a way because tactics generate programs [Thu Jan 14 12:42:30 2016] by saying Fixpoint … := match … False_rec … (*False here*) [Thu Jan 14 12:42:36 2016] and programs don't use tactics [Thu Jan 14 12:42:47 2016] if you just do Print getP' [Thu Jan 14 12:42:53 2016] you'll get a (bad) tacticless version [Thu Jan 14 12:42:55 2016] ooh [Thu Jan 14 12:43:00 2016] you could also clean it up by hand [Thu Jan 14 12:43:03 2016] right, the same thing as "Show Proof." [Thu Jan 14 12:43:12 2016] Ooh, I managed something. [Thu Jan 14 12:43:32 2016] nice [Thu Jan 14 12:44:13 2016] welp, this is really long [Thu Jan 14 12:44:33 2016] rrika: yeah, I warned you :) [Thu Jan 14 12:45:02 2016] I defined a recursive function, that for the undefined case calls itself. [Thu Jan 14 12:45:25 2016] I then used wellfoundedness termination on some random function parameter. [Thu Jan 14 12:45:34 2016] redlizard_, show source [Thu Jan 14 12:45:54 2016] Eh [Thu Jan 14 12:46:23 2016] My actual work is confidential. [Thu Jan 14 12:46:28 2016] Maybe I can write up a quick example, sec. [Thu Jan 14 12:51:13 2016] rrika: here's a cleaned up one without tactics: https://gist.github.com/wilcoxjay/6089b2c0d386275d6b19 [Thu Jan 14 12:52:10 2016] Thanks you! [Thu Jan 14 12:52:13 2016] -s [Thu Jan 14 12:55:46 2016] rrika, jrw: http://pastebin.com/jsshyJUY [Thu Jan 14 12:57:01 2016] It's a function listhead: (T: Type) (l: list T) (not_empty: length l > 0): T. [Thu Jan 14 12:57:33 2016] This is not the actual search function I implemented, but the essence is the same. [Thu Jan 14 13:01:14 2016] There really should be a tactic or module for resolving this nasty hack though. [Thu Jan 14 13:06:39 2016] >Definition falseP (T: Type) (t1: T) (t2: T): Prop := False. [Thu Jan 14 13:06:52 2016] so this discards its arguments T, t1 and t2? [Thu Jan 14 13:06:58 2016] Indeed. [Thu Jan 14 13:07:03 2016] It's a trivial relation. [Thu Jan 14 13:13:54 2016] I have to run. Thanks for the help, all./ [Thu Jan 14 14:00:42 2016] Fuco: hi! [Thu Jan 14 14:00:48 2016] Fuco: SF, "Programs and Proofs" by Ilya Sergey, CPDT by Chlipala, and other articles written about various aspects of Coq [Thu Jan 14 14:02:18 2016] jgross_: awesome! [Thu Jan 14 15:22:22 2016] hey all. beginner question. How do I construct a set using the modules here? https://coq.inria.fr/library/Coq.MSets.MSetInterface.html [Thu Jan 14 15:22:36 2016] chrisbarrett: hi! [Thu Jan 14 15:22:46 2016] chrisbarrett: you need to instantiate the module for your carrier type [Thu Jan 14 15:23:15 2016] *frantic googling* [Thu Jan 14 15:23:52 2016] cool, thanks :) [Thu Jan 14 15:25:08 2016] I have an example use, I believe [Thu Jan 14 15:25:18 2016] I symphathize, it's impenetrable if you haven't done it before [Thu Jan 14 15:26:44 2016] oh, an example would be welcome if you have one handy :D [Thu Jan 14 15:26:53 2016] sure, let me write one, since I seem to have lost the earlier one I had [Thu Jan 14 15:28:42 2016] aha, found my old example [Thu Jan 14 15:33:46 2016] chrisbarrett: https://gist.github.com/e3bdfe2db692b91184a9 [Thu Jan 14 15:33:52 2016] chrisbarrett: ok, here's what's happening [Thu Jan 14 15:34:03 2016] first, you define your type and Ord on it, basically [Thu Jan 14 15:34:23 2016] then you instantiatate the OrderedType module, to prove that your type is well ordered [Thu Jan 14 15:35:20 2016] once you have that, you can instantiate MSet (either the list-based version, or the AVL-based version) on your proof of well-orderedness [Thu Jan 14 15:35:33 2016] this give you a module, S, whose type S.t, is the MSet of your type [Thu Jan 14 15:35:58 2016] now you can use this type and know that sets of such types are ordered, which comes with all the helper proofs and utility functions available [Thu Jan 14 15:41:43 2016] great! [Thu Jan 14 15:42:00 2016] so the ordering requirement is an implementation detail, ala Haskell? [Thu Jan 14 15:42:39 2016] yes, almost exactly in the same way that Data.Set in Haskell has an Ord constraint [Thu Jan 14 15:42:52 2016] except that here, you must provide proof that it fulfills this constraint [Thu Jan 14 15:43:06 2016] note that this work was done prior to typeclasses, which is why it uses Modules like this and will appear totally unfamiliar to a Haskell programmer [Thu Jan 14 15:43:19 2016] in future, there may be a type-classes based Set and Map, which would look and feel very much like the Haskell versions [Thu Jan 14 15:43:33 2016] (in fact, it wouldn't be terribly hard to retrofit such an interface on top of this one) [Thu Jan 14 15:46:38 2016] cool, good to know [Thu Jan 14 15:46:59 2016] thanks for your time :D [Thu Jan 14 15:47:43 2016] no problem, this was already written, I found it in the Git history for one of my projects [Thu Jan 14 15:47:48 2016] chrisbarrett: what are you using Coq for? [Thu Jan 14 15:48:30 2016] I've just read through TAPL, now I want to go back over it doing the full proofs [Thu Jan 14 15:49:12 2016] ooh, nice [Thu Jan 14 15:49:36 2016] my pie-in-the-sky dream is to implement a System FC -> Elisp Lapcode compiler [Thu Jan 14 15:49:51 2016] that shouldn't be too hard, actually [Thu Jan 14 15:49:52 2016] but lots of foundations to get to grips with ;) [Thu Jan 14 15:50:13 2016] there already exist formalizations of System FC you can crib from too, I believe in HOL? [Thu Jan 14 15:51:36 2016] oh cool, that'll help a lot [Thu Jan 14 15:52:13 2016] ha, even better: http://www.seas.upenn.edu/~cse400/CSE400_2014_2015/reports/11_report.pdf [Thu Jan 14 15:52:15 2016] in Coq :) [Thu Jan 14 15:52:27 2016] hah! YUSS [Thu Jan 14 15:52:30 2016] https://github.com/zilberstein/system-fc-coq [Thu Jan 14 15:53:03 2016] bookmarked for later plundering [Thu Jan 14 16:02:21 2016] anyone here? [Thu Jan 14 16:02:25 2016] hi [Thu Jan 14 16:03:40 2016] oh nice [Thu Jan 14 16:03:58 2016] I'm installing coqide and would like some help with trouble shooting if anyone has some time ! :D [Thu Jan 14 16:04:11 2016] I know zero about coqide [Thu Jan 14 16:04:27 2016] oh so you use emacs? [Thu Jan 14 16:04:36 2016] and proof general? [Thu Jan 14 16:04:36 2016] yes [Thu Jan 14 16:05:46 2016] may i ask you to walk me thru the installationa nd getting started process? [Thu Jan 14 16:05:50 2016] I'm pretty new to emacs [Thu Jan 14 16:06:00 2016] I'm afraid that would take more time than I have available today [Thu Jan 14 16:06:19 2016] ok all good thanks! [Thu Jan 14 17:25:07 2016] jgross_: ping [Thu Jan 14 19:36:23 2016] johnw: pong [Thu Jan 14 19:50:38 2016] jgross_: hi [Thu Jan 14 19:50:42 2016] jgross_: still there? [Thu Jan 14 19:55:46 2016] dont you love when that happens [Thu Jan 14 19:56:26 2016] he'll be back :) [Thu Jan 14 19:56:40 2016] johnw: I'm here intermittantly. [Thu Jan 14 19:56:53 2016] jgross_: so, I really have no idea what your e-mail was about; should I have known? [Thu Jan 14 19:57:04 2016] I know your parsers stuff as far as specifying a grammar right now, but no further [Thu Jan 14 19:57:16 2016] I guess I worded it poorly [Thu Jan 14 19:58:02 2016] Do you have any examples where you'd use the parsers stuff as part of something larger, rather than to synthesize a standalone parser? [Thu Jan 14 19:58:17 2016] yes, that's how I'm using it now actually [Thu Jan 14 19:58:30 2016] although I haven't written the ADT yet that "binds" the parser ADT to the query structures ADT [Thu Jan 14 19:59:34 2016] Okay, I was just asking for an example like that, where you get to some point in the refinement proof, and you have a Pick, and you think "gee, it'd be nice if there were a tactic that synthesized a parser here inline, so I don't have to factor out separate lemmas and such", because I want to write that tactic, and it'll be easier if I have an example to work from. [Thu Jan 14 20:00:45 2016] ah, ok [Thu Jan 14 20:00:54 2016] I'll see how far I can get this weekend; will you be around here then? [Thu Jan 14 20:02:13 2016] It doesn't have to be a very interesting example. I'm just looking to know what goal is like when you get to the point that you want a parser. [Thu Jan 14 20:02:25 2016] I'll be around a little bit this weekend, but not very much. [Thu Jan 14 20:02:48 2016] can I hide a Module in Coq? [Thu Jan 14 20:02:50 2016] (And I'm currently trying to synthesize a JSON parser, but running into troubles with term size and rewriting and simpl) [Thu Jan 14 20:02:57 2016] What do you mean by hide? [Thu Jan 14 20:03:02 2016] not see it [Thu Jan 14 20:03:12 2016] Print Foo. is printing out a module definition [Thu Jan 14 20:03:15 2016] I want to undefine it [Thu Jan 14 20:03:46 2016] or, can I import a module under a binding name [Thu Jan 14 20:03:46 2016] You don't get to remove names from the kernel, nor overwrite absolute names. That could introduce soundness bugs. [Thu Jan 14 20:03:48 2016] like Require Foo as F? [Thu Jan 14 20:04:11 2016] mainly, I have two Monad abstractions fighting with each other [Thu Jan 14 20:04:39 2016] Require Foo. Module F. Include Foo. End F. will almost do what you want. Or Require Foo. Module F := Foo. [Thu Jan 14 20:04:52 2016] ah, ok [Thu Jan 14 20:05:00 2016] should have thought of that [Thu Jan 14 20:05:19 2016] Unless you're trying to hide typeclass instances or something. The fact that hints follow Require rather than Import is terrible. [Thu Jan 14 20:06:00 2016] well, here's what I want to do [Thu Jan 14 20:06:20 2016] instead of working with Comp A in refinemetns [Thu Jan 14 20:06:47 2016] I'd like to work with CompT m A, where m is any monad in the specification, but where a particular monad (like Either) can be chosen at refinement time [Thu Jan 14 20:06:53 2016] thus allowing me to parameterize error handling [Thu Jan 14 20:07:43 2016] i mean, I can do it all manually, but making a Comp transformer would give me back the nice bind notation [Thu Jan 14 20:07:52 2016] What are the semantics of refinement w.r.t. errors? [Thu Jan 14 20:08:09 2016] at refinement time, you're dealing with a concrete transformer stack [Thu Jan 14 20:08:14 2016] so, however that stack defines bind [Thu Jan 14 20:09:29 2016] And you're saying that you want a method that returns Error T rather than T, and you want to be able to use monad syntax inside that method? [Thu Jan 14 20:09:34 2016] example: x <- mzero; ret x. Where mzero is "failure". If at refinement I choose the Maybe monad, then this becomes: x <- ret None; match x with None => ret None | Some x => ret (Some x) [Thu Jan 14 20:09:52 2016] jgross_: instead of working with rep -> A -> rep * B [Thu Jan 14 20:09:58 2016] I'd like to work with A -> DSL B [Thu Jan 14 20:10:17 2016] where DSL is effectively "StateT rep m" for some 'm' to be chosen at refinement time [Thu Jan 14 20:10:30 2016] and so during refinement, just imagine all binds have been unfolded down to the Comp monad [Thu Jan 14 20:11:20 2016] You want this only for notation, or for some other reason? [Thu Jan 14 20:11:24 2016] in the case of the Maybe/Either monad as a choice for 'm', it will mean a ton of 'match' statements [Thu Jan 14 20:11:34 2016] I want it for the abstraction in the denotational specification [Thu Jan 14 20:11:43 2016] since the spec shouldn't care about which 'm' is used [Thu Jan 14 20:11:49 2016] that's a computational context decided by refinement [Thu Jan 14 20:11:58 2016] Can't you just parameterize your own spec over a monad? [Thu Jan 14 20:12:15 2016] you mean: rep -> A -> m (rep * B)? [Thu Jan 14 20:13:07 2016] No, rep -> A -> rep * m B. I don't think it'll let you do rep -> A -> m (rep * B), and for good reason; you don't get to destroy your state just by wrapping your method in a monad. [Thu Jan 14 20:13:16 2016] yeah, it won't [Thu Jan 14 20:13:56 2016] so, then I'd need to either have two bind notations, one for Comp and one for the 'm' layer, or literally call "bind" for the 'm' layer, or unify them somehow? [Thu Jan 14 20:14:17 2016] I suppose that does work [Thu Jan 14 20:14:21 2016] Comp A becomes Comp (m A) [Thu Jan 14 20:14:43 2016] Yeah, the notation is annoying. You could make a Monad typeclass and bind the notation to that, and that'll probably work? [Thu Jan 14 20:14:59 2016] yeah, I have that already, hence my module hiding questions :) [Thu Jan 14 20:15:08 2016] Fiat's >>= notation is colliding with my own [Thu Jan 14 20:15:37 2016] Feel free to submit a pull request where all of the Comp notation goes through a typeclass (as long as it doesn't slow things down significantly). [Thu Jan 14 20:15:44 2016] if I can instance Monad Comp, then it should all work [Thu Jan 14 20:16:08 2016] ouch, then Fiat would have to deal with instance lookup [Thu Jan 14 20:16:09 2016] Put your notation in a different scope, and open that? [Thu Jan 14 20:16:20 2016] yeah, the scoping suggestion is the right one [Thu Jan 14 20:16:24 2016] Fiat should be a fiat_scope too [Thu Jan 14 20:16:30 2016] there's already a comp_scope [Thu Jan 14 20:16:36 2016] I wonder if it's being auto-opened [Thu Jan 14 20:16:39 2016] one sec [Thu Jan 14 20:16:43 2016] Close Scope comp_scope? [Thu Jan 14 20:16:58 2016] jgross_: hey so i volunteered to remote participate in the mystery hunt tomorrow - dont suppose you have any idea if there might be any type theory related puzzles :V [Thu Jan 14 20:17:31 2016] jgross_: even when I close the scope, the fact that our bind exist at different levels makes the parser unhappy [Thu Jan 14 20:17:35 2016] benzrf: I'm doubtful that there will be type theory puzzles, but I'm not writing it, so I don't know [Thu Jan 14 20:17:47 2016] Oh, yeah, don't put your bind at a different level :P [Thu Jan 14 20:17:52 2016] ugh [Thu Jan 14 20:18:02 2016] how much thought went into choosing Fiat's levels? [Thu Jan 14 20:18:09 2016] changing all my levels will be non-trivial [Thu Jan 14 20:18:11 2016] If Fiat's bind clashes with, e.g., ssr, or mathclasses, or whatever, feel free to change Fiat's levels. [Thu Jan 14 20:18:16 2016] (this is the coq-haskell library that I'm trying to use with Fiat) [Thu Jan 14 20:18:32 2016] my own levels weren't chosen from the perspective of an expert [Thu Jan 14 20:18:47 2016] Not all that much thought went into Fiat's Comp levels. Some, but not a great deal. Feel free to make a pull request that changes them, so long as it all builds. [Thu Jan 14 20:20:13 2016] jgross_: oh, the "_ <- _ ; _" notation should run afoul of ssreflect's seq notation [Thu Jan 14 20:20:21 2016] though maybe mine did because of bad levels, checking now [Thu Jan 14 20:43:19 2016] how does one go about proving something like: (exists a0 : a, x a0 /\ Singleton a a0 z) = x z [Thu Jan 14 20:46:19 2016] You can prove it by induction on z, or using the univalence axiom, or it's unprovable. [Thu Jan 14 20:46:31 2016] z is an unknown type [Thu Jan 14 20:46:35 2016] and, lol at UA [Thu Jan 14 20:46:46 2016] not something I can easily bring in here ;) [Thu Jan 14 20:46:59 2016] in ordinary stdlib Coq is there a way? [Thu Jan 14 20:47:04 2016] You can use propositional extensionality from the stdlib instead. :P [Thu Jan 14 20:47:11 2016] ah, ok [Thu Jan 14 20:47:14 2016] It's UA restricted to Props [Thu Jan 14 20:48:38 2016] my z is: a : Type, x : Comp a, z : a [Thu Jan 14 20:48:39 2016] [Thu Jan 14 20:48:52 2016] trying to apply proof_irrelevance, I get Cannot unify Type with Prop [Thu Jan 14 20:50:00 2016] ah, I see [Thu Jan 14 20:50:48 2016] You want something of type prop_extensionality from https://coq.inria.fr/library/Coq.Logic.ClassicalFacts.html [Thu Jan 14 20:50:53 2016] no, right, I got it [Thu Jan 14 20:51:07 2016] that did the trick [Thu Jan 14 21:28:45 2016] Greetings. [Thu Jan 14 21:28:47 2016] I'm trying to get this function definition to work: http://pastebin.com/YStZsx1U [Thu Jan 14 21:28:48 2016] But coq doesn't accept it, because in the Foo match rule, (state w) has type WidgetState (widgetTypes w) instead of bool -- even though this rewrites to bool after substituting Foo for (widgetTypes w). [Thu Jan 14 21:28:50 2016] I've seen several references to the difficulties with dependent matching, but they were all about the case in which the result type of the match depends on the matched value, which is not the case here. [Thu Jan 14 21:28:51 2016] Any clues as to the magic incantations I need to get this to work? [Thu Jan 14 21:30:20 2016] I've tried some blind shotgunning of magic keywords, but to no avail, and I don't really understand them properly. [Thu Jan 14 21:32:43 2016] Undoubtedly one of the mysterious match annotations is involved, but I don't know which one, or why exactly. [Thu Jan 14 21:34:10 2016] hey redlizard [Thu Jan 14 21:34:19 2016] Yo. [Thu Jan 14 21:34:20 2016] pass 'state w' as an argument to the output of the match, and use return type specialization [Thu Jan 14 21:35:28 2016] tejing: Can you elaborate? [Thu Jan 14 21:35:38 2016] redlizard: this function doesnt make sense [Thu Jan 14 21:35:52 2016] no wait nvm i misread >.< [Thu Jan 14 21:36:32 2016] redlizard: you can do definitions with tactics, which might help [Thu Jan 14 21:36:40 2016] i don't know if that's a /good/ way to do it [Thu Jan 14 21:36:48 2016] 'match widgetTypes w as w' return WidgetState w' -> with Foo => fun statew => statew | Bar => fun _ => true end (state w)' [Thu Jan 14 21:36:59 2016] oops [Thu Jan 14 21:37:14 2016] s/->/-> bool/ [Thu Jan 14 21:39:11 2016] tejing: That seems to do the job. Let me state at it a bit until I understand it. [Thu Jan 14 21:43:03 2016] w' is a new name for (widgetTypes w) which is only in scope in the return annotation, and gets specialized appropriately on each branch [Thu Jan 14 21:44:28 2016] Right. [Thu Jan 14 21:45:02 2016] tejing: Do you know why coq can't just substitute the matched term inside the entirity of the rhs expansion? [Thu Jan 14 21:45:24 2016] That doesn't look undecidable to me. [Thu Jan 14 21:46:35 2016] That is to say, I understand the solution, but I don't understand why the problem is there in the first place. [Thu Jan 14 21:47:28 2016] some use cases wouldn't be writable that way I think... one of the things one often does is carry in an equality between the original form of the matched term and the specialized form. what you said would convert both sides of the equality, making it useless [Thu Jan 14 21:48:55 2016] But coq does most of such substitutions already, doesn't it? [Thu Jan 14 21:49:03 2016] It seems it doesn't do it only for dependent types. [Thu Jan 14 21:51:23 2016] without any dependent types, there's no need for the different branches of the match to have different types, so the whole issue doesn't exist... [Thu Jan 14 21:52:05 2016] But different branches of the match DON'T have different types in my original example. [Thu Jan 14 21:54:16 2016] in this situation, what is determined about the value of w by a match on widgetTypes w is straightforward, but 'widgetTypes' could be an arbitrarily complex calculation... coq would need to understand how to invert that function, no matter how complicated it is [Thu Jan 14 21:56:57 2016] Why does it need to invert anything? [Thu Jan 14 21:57:16 2016] All it needs to do is substitute the entire term (widgetTypes w) in the right hand side. [Thu Jan 14 21:57:48 2016] redlizard: to know if 'state w' is well-typed [Thu Jan 14 21:58:03 2016] That is, rewrite (widgetTypes w) -> Foo in (any expansions of) the rhs of the Foo case. [Thu Jan 14 21:58:30 2016] tejing: Yet I get the following error: [Thu Jan 14 21:58:41 2016] > The term "state w" has type "WidgetState (widgetTypes w)" while it is expected to have type "bool". [Thu Jan 14 21:58:53 2016] So all it needs to do is perform the substitution during this check. [Thu Jan 14 21:59:36 2016] That doesn't take inversion, does it? [Thu Jan 14 22:00:46 2016] in this case, no, it can get by without inverting, but only because the situation happens to line up that way... and personally, I'd rather have the behavior be simple than have it try to be smart in all kinds of edge cases [Thu Jan 14 22:01:51 2016] But isn't this exactly the type of substitution coq already does in non-dependent matchings? [Thu Jan 14 22:03:44 2016] That is to say, it would seem that coq performs a certain set of heuristics or incomplete simplifications only in the nondependent case, even though some of them could apply in some of the dependent cases. [Thu Jan 14 22:03:55 2016] Which means coq is being more conservative than it needs to be. [Thu Jan 14 22:04:38 2016] redlizard: yes, except it's no longer guaranteed that inversion won't be an issue, and doing that substitution could make it impossible to write something you want to be able to write [Thu Jan 14 22:04:59 2016] Hm. Okay. [Thu Jan 14 22:05:39 2016] I'm not sure I understand that, which probably means I should stop arguing about it and concede the point :) [Thu Jan 14 22:05:46 2016] redlizard: hehe [Thu Jan 14 22:06:13 2016] In any case, thanks for the help, this trick seems to the the job. [Thu Jan 14 22:08:00 2016] redlizard: coq also just isn't built for ease of dependently typed programming. it's built for proving things with tactics. there are certainly a lot of things that could be made more elegant in that regard. [Thu Jan 14 22:08:39 2016] I did notice. [Thu Jan 14 22:10:12 2016] Earlier I tried to define a function: forall a: A, P a -> B, with an incomplete definition that covers all `a` for which `P a` holds. [Thu Jan 14 22:10:26 2016] I managed eventually but it was a complete pain in the butt. [Thu Jan 14 22:12:12 2016] That's the sort of thing you would hope to be easier in a system really designed for dependently typed programming. [Thu Jan 14 22:24:58 2016] Okay, I have to run. [Thu Jan 14 22:25:03 2016] tejing: Thanks for all the help :) [Thu Jan 14 22:25:16 2016] redlizard: np :-) [Thu Jan 14 22:30:16 2016] hmmm, hold on [Thu Jan 14 22:30:22 2016] so when you do a match [Thu Jan 14 22:30:41 2016] it releases a definitional equality? [Thu Jan 14 23:13:13 2016] hey man [Thu Jan 14 23:13:13 2016] anyone around? [Thu Jan 14 23:55:16 2016] hi lpaste [Thu Jan 14 23:55:20 2016] ling oh wait [Thu Jan 14 23:57:05 2016] rule n°1 of the IRC: if someone asks "anyone here" just after coming, it means they'll be left before you can answer [Thu Jan 14 23:59:01 2016] im guilty of that :D [Fri Jan 15 00:37:29 2016] redlizard: it actually does get easier if you use Program Definition [Fri Jan 15 00:38:05 2016] redlizard: when you match on 'a', just use "_" for the cases that are absurd (although, granted it would be better to just not have to state them at all), and they should be provided automatically [Fri Jan 15 00:49:53 2016] jgross_: ping [Fri Jan 15 01:57:14 2016] is there any reason why coqIDE 8.4pl5 should crash while importing String ? [Fri Jan 15 01:58:03 2016] in : [Fri Jan 15 01:58:08 2016] https://www.irccloud.com/pastebin/LlF4UtdC/ [Fri Jan 15 01:58:31 2016] does anyone else experiencing crashes like that ? [Fri Jan 15 01:58:38 2016] on - Require String. [Fri Jan 15 01:58:46 2016] mac os ? [Fri Jan 15 02:21:53 2016] try Require Import String. [Fri Jan 15 02:22:06 2016] anyone know how to match goal on: exists a0 : a, In a x a0 /\ In a (ret a0) z [Fri Jan 15 02:22:18 2016] I've tried [ |- ex _ _ ] and [ |- ex _ ], but nothing matches [Fri Jan 15 02:23:05 2016] ahh [Fri Jan 15 02:23:12 2016] ex ?X [Fri Jan 15 02:36:29 2016] thanks [Fri Jan 15 02:41:15 2016] johnw: Goal forall a x (a0 : nat) ret, exists a0 : a, List.In a x /\ List.In a (ret a0). Proof. intros. match goal with | [ |- ex _ ] => idtac end. works fine for me. Maybe try [Set Printing All]? [Fri Jan 15 02:41:30 2016] johnw: that crashes too [Fri Jan 15 02:41:38 2016] jgross_: I got it working, thanks [Fri Jan 15 02:41:59 2016] jgross_: so, rep -> (rep * m a) isn't going to work [Fri Jan 15 02:42:09 2016] I can't write join for that [Fri Jan 15 02:42:15 2016] joco42: :( [Fri Jan 15 02:42:32 2016] i guess i just use proof general then [Fri Jan 15 02:42:38 2016] joco42: does it crash if you use coqtop from the comman-dline? [Fri Jan 15 02:42:58 2016] lemme try [Fri Jan 15 02:46:10 2016] coqtop -l Induction.v , this does not crash, < johnw [Fri Jan 15 02:46:28 2016] how about coqtop, and then at the prompt: Require String. [Fri Jan 15 02:46:59 2016] lemme see [Fri Jan 15 02:47:10 2016] no problem [Fri Jan 15 02:47:15 2016] apparently [Fri Jan 15 02:47:30 2016] but i have no idea how to use coqtop [Fri Jan 15 02:49:05 2016] so, if that worked, Proof General should work [Fri Jan 15 02:49:12 2016] I know nothing about coqide [Fri Jan 15 02:51:11 2016] coqtop is not doing anything... except when i hit ctrl-D... [Fri Jan 15 02:51:31 2016] johnw: rep -> m (rep * a) is impossible to implement generically. Consider the reader monad, implemented as m T = R -> T. rep -> (R -> rep * a) isn't the type of a method. One way or another, you need to specify the state at the end of execution. [Fri Jan 15 02:51:35 2016] is there a simple way to test coqtop? [Fri Jan 15 02:51:57 2016] what should i type/press to get some/any response from coqtop ? [Fri Jan 15 02:52:21 2016] joco42: Type "Check True." and then press enter [Fri Jan 15 02:52:28 2016] ahh [Fri Jan 15 02:52:29 2016] ok [Fri Jan 15 02:52:34 2016] maybe the dot was missing [Fri Jan 15 02:52:46 2016] that worked [Fri Jan 15 02:52:52 2016] Yes, coqtop waits until you finish a command before giving you any feedback. [Fri Jan 15 02:52:54 2016] jgross_: rep -> rep * m a will require m to be distributive, I think [Fri Jan 15 02:53:19 2016] Require String. works fine... [Fri Jan 15 02:53:37 2016] maybe i just use emacs then [Fri Jan 15 03:21:20 2016] jgross_: actually, 'm' just needs to be Traversable, which works for me [Fri Jan 15 04:15:09 2016] jgross_: ack, nothing worse than importing a module and getting just "Universe inconsistency." [Fri Jan 15 06:25:35 2016] johnw: Ah, that program definition worked! That's great :) [Fri Jan 15 08:16:31 2016] Can I have a Fixpoint decrease on an argument like (l: list T | foobar l = true) ? [Fri Jan 15 10:55:41 2016] hey all [Fri Jan 15 10:55:47 2016] does anyone have compnay-coq? [Fri Jan 15 11:37:47 2016] johnw: When you [Set Printing Universes], which universe variable do you get? You can try using the bug minimizer to find which imports break things. [Fri Jan 15 11:40:42 2016] lingxiao: Sure, I wrote it. [Fri Jan 15 12:38:11 2016] coq tells me "Error: Only structural decreasing is supported for a non-Program Fixpoint" [Fri Jan 15 12:38:15 2016] what's a "program fixpoint" [Fri Jan 15 12:39:49 2016] rrika: "Program Fixpoint" is a command that let's you do general recursion and prove termination separately [Fri Jan 15 12:40:08 2016] as opposed to "Fixpoint" which is the usual way to define recursive functions, which only supports structural recursion [Fri Jan 15 12:40:41 2016] also, to answer your earlier question, no, you cannot do structural recursion on a type like {l : list T | P l} [Fri Jan 15 12:41:02 2016] because that type is not recursively defined the way you want it to be [Fri Jan 15 12:41:14 2016] you need to separate the list from the proof and then do recursion on the list [Fri Jan 15 12:46:06 2016] Hi [Fri Jan 15 12:46:20 2016] dash_: hi [Fri Jan 15 12:47:29 2016] i got a problem which seems trivial and yet i haven't found a solution for an hour or so, maybe somebody here can help... [Fri Jan 15 12:48:59 2016] during a proof i have proposition in my context "~(exists n, (exists m, P m n))" (note the nested quantifiers)"... somehow this is syntactically different from "~exists n m, P m n" [Fri Jan 15 12:49:32 2016] is there a way to "transform" the first to the latter? [Fri Jan 15 12:50:35 2016] since I can't apply (for example) "not_ex_all_not" on the first one [Fri Jan 15 12:50:47 2016] as a consequence [Fri Jan 15 12:54:49 2016] dash_: Yes you could. [Fri Jan 15 12:55:01 2016] `apply not_ex_all_not; intros; apply not_ex_all_not` should work fine. [Fri Jan 15 12:55:53 2016] I mean in proposition in my context [Fri Jan 15 12:56:28 2016] Ah. [Fri Jan 15 12:56:46 2016] :) [Fri Jan 15 12:57:04 2016] dash_: those are not syntactically different for me. [Fri Jan 15 12:57:07 2016] dash_: the notations mean the same expression [Fri Jan 15 12:57:09 2016] just tested it [Fri Jan 15 12:57:17 2016] yeah [Fri Jan 15 12:57:18 2016] i be right back (have to disconnect for a minute...) [Fri Jan 15 12:57:31 2016] library's closing :) [Fri Jan 15 13:02:38 2016] morning [Fri Jan 15 14:08:30 2016] jgross_: I really need to master the use of your bug minimizer [Fri Jan 15 14:14:12 2016] redlizard: nice! [Fri Jan 15 14:36:35 2016] johnw: Much better than my attempt involving a recursive function with a nonterminating recursive call for the absurd cases, proved terminating by a trivial well-founded relation. [Fri Jan 15 14:36:57 2016] lol [Fri Jan 15 14:37:07 2016] It was the only thing I could think of... [Fri Jan 15 14:37:19 2016] In it did in fact work, but ew. [Fri Jan 15 14:38:43 2016] redlizard, it is quite effective IMO [Fri Jan 15 14:38:46 2016] and not too long [Fri Jan 15 14:38:55 2016] rrika: What is? [Fri Jan 15 14:39:09 2016] your use of the relation that is False all the time for well-founded ness [Fri Jan 15 14:39:19 2016] Well, it works. [Fri Jan 15 14:39:26 2016] But the Program Definition solution is much much better. [Fri Jan 15 14:40:04 2016] programs is great for "something goes here, I'll prove it after" [Fri Jan 15 14:41:44 2016] redlizard, out of curiosity I'm still trying to get my own version to work. [Fri Jan 15 14:42:01 2016] but I still have a custom induction [Fri Jan 15 14:42:05 2016] (non structural) [Fri Jan 15 15:23:32 2016] What's a short way to turn (x : false = true) into (x : False)? [Fri Jan 15 15:23:42 2016] Without tactics that is. [Fri Jan 15 15:23:53 2016] you can find that technique in CPDT [Fri Jan 15 15:24:01 2016] on how to manually build the discriminate tactic [Fri Jan 15 15:24:45 2016] thank you, I didn't want to start two books at the same time, so… [Fri Jan 15 15:25:18 2016] what book are you reading now? [Fri Jan 15 15:25:51 2016] rrika: check out http://adam.chlipala.net/cpdt/html/InductiveTypes.html, search for "Manual Proofs About Constructors" [Fri Jan 15 15:26:07 2016] "It can be useful to understand how tactics like discriminate and injection work, so it is worth stepping through a manual proof of each kind. We will start with a proof fit for discriminate." [Fri Jan 15 15:26:21 2016] johnw, finished the Basics and Inductions chapters of SF (including the five star exercise though) [Fri Jan 15 15:28:15 2016] nice riaqn [Fri Jan 15 15:28:17 2016] if you plan to use Coq seriously, CPDT is an excellent text [Fri Jan 15 15:28:18 2016] rrika [Fri Jan 15 15:29:42 2016] ack [Fri Jan 15 15:30:23 2016] i almost finished Prop... [Fri Jan 15 15:31:46 2016] I lost my will to get all the way through SF, even though there's great stuff in the latter half [Fri Jan 15 15:32:50 2016] maybe because some of my real world tasks are in the same vein; but still, I'd love to get back to it at some point [Fri Jan 15 15:49:21 2016] okay, I'm getting really weird error messages for the last match in https://gist.github.com/rrika/60cd2db31b4c8a3949c7 [Fri Jan 15 15:49:47 2016] what's the error? [Fri Jan 15 15:50:13 2016] Error: Found a constructor of inductive type sig while a constructor of list is expected. [Fri Jan 15 15:50:20 2016] but 'sig' is the right type here [Fri Jan 15 15:50:27 2016] don't use Program [Fri Jan 15 15:51:18 2016] Program tries to save you from certain things [Fri Jan 15 15:51:18 2016] one sec [Fri Jan 15 15:52:29 2016] never mind my previosu comment, the error isn't where I thought it was [Fri Jan 15 15:58:28 2016] rrika: I have no idea yet [Fri Jan 15 16:01:20 2016] rrika: this makes part of the problem easier to see: https://gist.github.com/fece350593c1bcb8a4a7 [Fri Jan 15 16:01:55 2016] that let fix will need to be factored out to its own Program Fixpoint, though, since it's not structurally recursive [Fri Jan 15 16:04:49 2016] Maybe "Program" does weird things with arguments of type "sig" [Fri Jan 15 16:05:03 2016] that doesn't seem to be it [Fri Jan 15 16:05:29 2016] well, unlike lean, I can't just hover over "li" and see the type coq belives it has. [Fri Jan 15 16:05:42 2016] "Check" in the middle of an expression doesn't work either. [Fri Jan 15 16:08:03 2016] rrika: ok: https://gist.github.com/c1d0844d0a9d5df661f6 [Fri Jan 15 16:08:07 2016] prove those two obligations and you're good [Fri Jan 15 16:09:09 2016] what are you trying to prove here, btw? [Fri Jan 15 16:09:34 2016] what redlizard described 1-2 days ago [Fri Jan 15 16:09:43 2016] trying to do it without tactics [Fri Jan 15 16:09:52 2016] what did he describe 2 days ago? :) [Fri Jan 15 16:10:12 2016] basically the signature of search_P_int describes the task [Fri Jan 15 16:10:24 2016] returning an element from a list that fulfills a "P" [Fri Jan 15 16:10:38 2016] using the fact that one element in the list HAS to fulfill it [Fri Jan 15 16:10:45 2016] so the return value is not [Fri Jan 15 16:10:52 2016] maybe E [Fri Jan 15 16:10:55 2016] but E [Fri Jan 15 16:11:05 2016] or even {x : E | P x} [Fri Jan 15 16:11:25 2016] ah, so: [Fri Jan 15 16:11:25 2016] Definition find_P {A} (P : A -> Prop) (xs : list A) : { x : A | P x }. [Fri Jan 15 16:11:45 2016] what does {A} do? [Fri Jan 15 16:11:54 2016] introduces an implicit variable [Fri Jan 15 16:12:05 2016] and ": Type" is implicit too? [Fri Jan 15 16:12:17 2016] because of "list"? [Fri Jan 15 16:12:29 2016] it's implicit too, just because [Fri Jan 15 16:12:39 2016] kk [Fri Jan 15 16:13:50 2016] actually, I think the type has to be: [Fri Jan 15 16:13:51 2016] Definition find_P {A} (P : A -> Prop) (xs : list A) [Fri Jan 15 16:13:51 2016] (H : exists x : A, List.In x xs /\ P x) : { x : A | P x }. [Fri Jan 15 16:13:55 2016] to fully match your specification [Fri Jan 15 16:14:13 2016] that should be trivial [Fri Jan 15 16:16:46 2016] well, this is too easy in fact [Fri Jan 15 16:17:03 2016] if you give me evidence that the element exists, and the goal of find_P is to return such an element, then you've given me what you want me to return [Fri Jan 15 16:17:54 2016] i.e., https://gist.github.com/f5bbfde3b670027a4a9f [Fri Jan 15 16:18:31 2016] indeed [Fri Jan 15 16:18:49 2016] is my Q similarly trivial? [Fri Jan 15 16:19:16 2016] well, your Q is a fixpoint, so that's not as trivial [Fri Jan 15 16:33:47 2016] the last obligation seems very hard to prove [Fri Jan 15 17:02:20 2016] johnw: Now assume you want the *first* item in the list that satisfies P, not just any of them. [Sun Jan 17 03:49:43 2016] ping: jrw [Sun Jan 17 03:49:50 2016] jrw: ping [Sun Jan 17 18:47:05 2016] jgross_: ping? [Sun Jan 17 20:42:52 2016] How can I do induction over something like (n : nat | evenb n = true)? [Sun Jan 17 20:43:00 2016] (If at all) [Sun Jan 17 20:43:41 2016] I thought I could do "induction n" followed by "destruct (evenb n)" but that gives me 'ill-typed expressions' [Sun Jan 17 20:47:08 2016] sorry, "induction n", "induction x", "destruct (evenb n)". [Sun Jan 17 20:52:23 2016] rrika: I would write a custom induction principle with a zero case and a double successor case, or prove the logical equivalence of 'evenb n = true' and an inductively defined 'even' predicate, then induct on the proof of the predicate. [Sun Jan 17 21:27:13 2016] johnw: pong [Sun Jan 17 21:27:28 2016] hey, I forgot what I was going to ask :) [Sun Jan 17 21:32:13 2016] jgross_: so, I'm trying to build an ADT that combines two other ADTs [Sun Jan 17 21:32:31 2016] jgross_: is there a way to do this so that I can "refine the composition", rather than simplify combining two already-refined implementations? [Sun Jan 17 21:32:39 2016] s/simplify/simply [Sun Jan 17 21:35:44 2016] jgross_: example question: is it possible within an ADT method to "call" another ADT method, and then in refinement, refine to a CallMethod of a cADT for that "call"? If that even made sense [Sun Jan 17 21:36:00 2016] I want a non-deterministic equivalent of CallMethod for ADTs [Sun Jan 17 21:36:14 2016] ahh, callADTMethod [Sun Jan 17 22:04:29 2016] could someone give me some tips on this proof? [Sun Jan 17 22:04:34 2016] sorry, heading to dinner :) [Sun Jan 17 22:04:42 2016] I didn't mean to be mean, literally my wife just called me [Sun Jan 17 22:04:44 2016] but I'll be back [Sun Jan 17 22:04:45 2016] I understand the logic "on paper" but not in coq [Sun Jan 17 22:04:49 2016] lol all good thanks man! [Sun Jan 17 22:09:57 2016] Cale here's the lpaste: http://lpaste.net/150112 [Sun Jan 17 22:10:17 2016] and this: [Sun Jan 17 22:10:19 2016] f (f b) = f b] ==> [f b = b] by the fact that [f b = b] [Sun Jan 17 22:10:19 2016] k_bx has joined (~k_bx@100-169-94-178.pool.ukrtel.net) [Sun Jan 17 22:10:20 2016] lingxiao [Sun Jan 17 22:10:21 2016] then I have [f b = b] ==> [b = b] by the previous fact again [Sun Jan 17 22:11:02 2016] okay [Sun Jan 17 22:11:19 2016] and I see this at the current state of my proof: [Sun Jan 17 22:11:20 2016] http://lpaste.net/150113 [Sun Jan 17 22:11:42 2016] see I want to do something like [rewrite f] so that I get [f b = b] [Sun Jan 17 22:11:43 2016] I would have named it P rather than x [Sun Jan 17 22:11:46 2016] but okay [Sun Jan 17 22:11:49 2016] but that's not going to work... [Sun Jan 17 22:11:54 2016] what's P? [Sun Jan 17 22:12:04 2016] P : forall x : bool, f x = x [Sun Jan 17 22:12:05 2016] like what does it stand for? [Sun Jan 17 22:12:18 2016] It's a function which given some x : bool, gives you the equality f x = x [Sun Jan 17 22:12:30 2016] (i.e. the proof of that equality) [Sun Jan 17 22:12:48 2016] ok wait could we back up [Sun Jan 17 22:12:57 2016] how should i read the propositon in egnlish? [Sun Jan 17 22:13:28 2016] is it forall f of type Bool -> Bool, `and` forall x of type bool so that f x = x [Sun Jan 17 22:14:05 2016] I think you understand the proposition, but you could read it as saying that for any function f of type bool -> bool, if, for every x of type bool, we have f x = x, then for every b of type bool, we have f (f b) = b [Sun Jan 17 22:14:22 2016] your layout is a little weird [Sun Jan 17 22:14:35 2016] hmm? what layout? of my proof? [Sun Jan 17 22:14:38 2016] like it's not on one line? [Sun Jan 17 22:14:41 2016] of the statement [Sun Jan 17 22:14:56 2016] or prposition .. oh yeah Im not familiar so I indented it by some whim [Sun Jan 17 22:15:36 2016] but yeah, it's a little funny because of the nested foralls, it's hard to pick something really nice [Sun Jan 17 22:16:39 2016] so the "if, for every x of type bool, we have f x = x," is the proof P? [Sun Jan 17 22:16:50 2016] Theorem identity_fn_applied_twice (f : bool -> bool) (P : forall x : bool, f x = x) (b : bool) : f (f b) = b. -- we could write it like this if we like [Sun Jan 17 22:16:51 2016] so proof by assumption right? [Sun Jan 17 22:17:18 2016] oh so yo named it in the statement [Sun Jan 17 22:17:24 2016] yeah [Sun Jan 17 22:17:34 2016] and again `P`roof by assumption [Sun Jan 17 22:17:43 2016] I don't know what proof by assumption really means [Sun Jan 17 22:17:52 2016] sorry true by assumption [Sun Jan 17 22:17:58 2016] but this P is indeed an assumption [Sun Jan 17 22:18:14 2016] that we need to satisfy if we want to apply our theorem [Sun Jan 17 22:18:45 2016] If we want to later make use of identity_fn_applied_twice, we need to provide a proof P that forall x : bool, f x = x [Sun Jan 17 22:18:46 2016] wait I though we're proving this part? [Sun Jan 17 22:18:53 2016] forall (b:bool), f (f b) = b [Sun Jan 17 22:18:57 2016] yep [Sun Jan 17 22:19:08 2016] but your'e saying we need to satisfy P if we want to apply our theorem? [Sun Jan 17 22:19:20 2016] aren't we using P to prove forrall (b:bool), f (f b) = b [Sun Jan 17 22:19:20 2016] We're just proving the theorem, not applying it :) [Sun Jan 17 22:19:40 2016] But if we wanted to apply it, we'd need to construct a proof that we could supply as the P argument to this [Sun Jan 17 22:20:08 2016] which would be a function that given x : bool, would produce a proof that f x = x [Sun Jan 17 22:20:32 2016] That's what the type forall x : bool, f x = x is [Sun Jan 17 22:20:44 2016] so the type is a proposition [Sun Jan 17 22:20:44 2016] forall x : A, B x [Sun Jan 17 22:20:51 2016] is the type of functions which given some x of type A [Sun Jan 17 22:20:56 2016] produce a result of type B x [Sun Jan 17 22:20:57 2016] and we need to implement a type as a witness right [Sun Jan 17 22:21:01 2016] so ie P true = true [Sun Jan 17 22:21:03 2016] P false = false [Sun Jan 17 22:21:10 2016] P true won't be a bool [Sun Jan 17 22:21:25 2016] It'll be some term of type f x = x [Sun Jan 17 22:21:28 2016] oh opse P : bool [Sun Jan 17 22:21:40 2016] hm? [Sun Jan 17 22:21:44 2016] so f x = x : Bool right? [Sun Jan 17 22:21:48 2016] no [Sun Jan 17 22:21:57 2016] f x = x is itself a type [Sun Jan 17 22:22:17 2016] so what's an insatnce of that type? [Sun Jan 17 22:22:37 2016] Well, I can't write one without knowing what f is :) [Sun Jan 17 22:22:50 2016] so let f = id [Sun Jan 17 22:24:29 2016] Coq < Inductive eq (A:Type) (x:A) : A -> Prop := [Sun Jan 17 22:24:29 2016] Coq < eq_refl : eq A x x. [Sun Jan 17 22:24:34 2016] (from the manual) [Sun Jan 17 22:24:50 2016] oh boy I can't read that [Sun Jan 17 22:24:53 2016] eq_refl is a data constructor of this type eq (which is the desugaring of =) [Sun Jan 17 22:24:54 2016] I'm very green to this [Sun Jan 17 22:25:02 2016] okay [Sun Jan 17 22:25:21 2016] So, when you write f x = x [Sun Jan 17 22:25:37 2016] It really means eq bool (f x) x [Sun Jan 17 22:25:59 2016] so eq is just `=` correct? [Sun Jan 17 22:26:01 2016] what's bool? [Sun Jan 17 22:26:04 2016] (actually, you can't write that, because the first argument to eq is implicit, so you have to make it not implicit) [Sun Jan 17 22:26:10 2016] @eq bool (f x) x [Sun Jan 17 22:26:14 2016] if we want to be picky [Sun Jan 17 22:26:19 2016] ok so what's eq [Sun Jan 17 22:26:25 2016] what's its arity? [Sun Jan 17 22:26:34 2016] what is bool? [Sun Jan 17 22:26:38 2016] is that a type? [Sun Jan 17 22:26:39 2016] eq is a data type which is parameterised over some type A [Sun Jan 17 22:26:48 2016] and a value x of type A [Sun Jan 17 22:27:23 2016] and produces a type function A -> Prop [Sun Jan 17 22:27:37 2016] i.e. given some type A and some value x : A [Sun Jan 17 22:27:42 2016] so eq is a type costructor? [Sun Jan 17 22:27:43 2016] eq A x y : Prop [Sun Jan 17 22:27:45 2016] yeah [Sun Jan 17 22:27:56 2016] what's prop? [Sun Jan 17 22:27:56 2016] and it has one data constructor [Sun Jan 17 22:27:58 2016] is that a type? [Sun Jan 17 22:28:03 2016] Prop is the type of all propositions [Sun Jan 17 22:28:19 2016] aren't all type signatures propositions? [Sun Jan 17 22:28:23 2016] which is similar to a universe of types [Sun Jan 17 22:28:35 2016] so is it like kind *? [Sun Jan 17 22:28:48 2016] yeah, a bit [Sun Jan 17 22:28:52 2016] but * is unary types only? [Sun Jan 17 22:28:57 2016] is there a Prop -> Prop and so on? [Sun Jan 17 22:29:03 2016] but there are some differences when it comes to what's allowed, such that when you extract executable code from Coq, all the stuff of type Prop can be thrown out [Sun Jan 17 22:29:37 2016] You're not allowed to pattern match on values of a type which is in Prop in order to compute a result of a type which is in Type [Sun Jan 17 22:29:49 2016] (in general) [Sun Jan 17 22:30:01 2016] You can pattern match on them to make other Props [Sun Jan 17 22:30:14 2016] It's just a weird Coq thing, kinda :) [Sun Jan 17 22:30:32 2016] There's some other cute differences, the main thing being something called impredicativity [Sun Jan 17 22:30:41 2016] But it's technical [Sun Jan 17 22:30:54 2016] I would actually prefer just to be able to say here that eq A x x : Type [Sun Jan 17 22:31:11 2016] In most other settings, that would be the case :P [Sun Jan 17 22:31:31 2016] wait so in eq A x y, we have x, y : A right? [Sun Jan 17 22:31:35 2016] yeah [Sun Jan 17 22:31:48 2016] ok great i'm learning a lot already thanks :) [Sun Jan 17 22:31:56 2016] so syntax weise i still dont get it [Sun Jan 17 22:31:57 2016] and eq_refl gives you a value of type eq A x x for any x you like [Sun Jan 17 22:32:11 2016] what's eq_refl [Sun Jan 17 22:32:14 2016] equality relfection? [Sun Jan 17 22:32:16 2016] the data constructor [Sun Jan 17 22:32:22 2016] for this type [Sun Jan 17 22:32:36 2016] (or Prop, if you must) [Sun Jan 17 22:32:41 2016] what's the value of eq Bool x x [Sun Jan 17 22:32:46 2016] or a value [Sun Jan 17 22:32:52 2016] Well, we know that eq_refl is [Sun Jan 17 22:33:16 2016] There may be others, but it's actually impossible to prove that there's anything other than eq_refl in plain Coq [Sun Jan 17 22:33:17 2016] so it goes term, type, prop in hiearchy of sets? [Sun Jan 17 22:33:54 2016] sorry my questions are all over the place lol [Sun Jan 17 22:34:03 2016] There are three "sorts", Set, Prop, and Type [Sun Jan 17 22:34:17 2016] hmm which on is on the bottome? [Sun Jan 17 22:34:23 2016] Prop is the universe of logical propositions [Sun Jan 17 22:34:35 2016] Set is the universe of program types [Sun Jan 17 22:34:41 2016] and then Type is the type of Set and Prop [Sun Jan 17 22:35:18 2016] wait is Prop and Set mutally exclusive? [Sun Jan 17 22:35:22 2016] yeah [Sun Jan 17 22:35:39 2016] There's actually a little more going on, which I should probably say something about [Sun Jan 17 22:35:43 2016] so what is Nat? [Sun Jan 17 22:35:48 2016] is that a type? [Sun Jan 17 22:35:56 2016] Type* [Sun Jan 17 22:36:09 2016] so for example 12 is Nat right [Sun Jan 17 22:36:11 2016] If you type Check nat. [Sun Jan 17 22:36:17 2016] and run it [Sun Jan 17 22:36:22 2016] Coq will tell you :) [Sun Jan 17 22:36:57 2016] ah it's a Set [Sun Jan 17 22:36:59 2016] which makes sense [Sun Jan 17 22:37:09 2016] Set is a type [Sun Jan 17 22:37:19 2016] type is type [Sun Jan 17 22:37:19 2016] (actually, Prop and Set are not mutually exclusive. Everything in Prop is also in Type. Not that it matters, really.) [Sun Jan 17 22:37:31 2016] (also in Set*) [Sun Jan 17 22:37:42 2016] Oh, interesting [Sun Jan 17 22:38:01 2016] interesting that Type is a Type? [Sun Jan 17 22:38:02 2016] yeah .. [Sun Jan 17 22:38:23 2016] lingxiao: Oh, hah, I meant the inclusion of Prop in Set [Sun Jan 17 22:38:32 2016] lingxiao: The Type : Type thing is actually a slight lie [Sun Jan 17 22:38:45 2016] oh how so? [Sun Jan 17 22:38:57 2016] if you turn on the option "display universe levels" in the view menu in coqide [Sun Jan 17 22:39:06 2016] and run Check Type. again [Sun Jan 17 22:39:27 2016] You'll see something like Type (* Top.2 *) : Type (* (Top.2)+1 *) [Sun Jan 17 22:39:56 2016] where it's inserted these usually-invisible universe levels as comments, haha [Sun Jan 17 22:40:03 2016] what Top? [Sun Jan 17 22:40:10 2016] or what does it stand for? [Sun Jan 17 22:40:23 2016] Just read that Top.2 thing as a variable, I'm not actually sure what it stands for [Sun Jan 17 22:40:34 2016] oh i thought it mean toplogy haha [Sun Jan 17 22:40:39 2016] just kidding .. [Sun Jan 17 22:40:45 2016] anyways so set is a type [Sun Jan 17 22:40:50 2016] is there another example of type? [Sun Jan 17 22:40:53 2016] but there's like an infinite sequence, for each natural number i, there's Type i [Sun Jan 17 22:41:00 2016] yeah that make sense [Sun Jan 17 22:41:01 2016] and we have Type i : Type (i+1) [Sun Jan 17 22:41:15 2016] (Top is just the placeholder module name for the toplevel stuff. If a universe comes from some specific module, its name might be prefixed by this module's name) [Sun Jan 17 22:41:24 2016] ah i see [Sun Jan 17 22:41:25 2016] ah [Sun Jan 17 22:41:28 2016] that's really nifty acutally [Sun Jan 17 22:41:46 2016] but Coq hides this universe level stuff from you and just checks that the universe levels work out behind the scenes [Sun Jan 17 22:41:54 2016] A lot of the time, that's nice [Sun Jan 17 22:41:58 2016] oh great that's neat yeah [Sun Jan 17 22:41:59 2016] sometimes, it's a total pain [Sun Jan 17 22:42:15 2016] I'm just a baby at this, so I'll put that in the back of my mind for now [Sun Jan 17 22:42:27 2016] wait aren't sets like types? [Sun Jan 17 22:42:35 2016] sets in the math sense ... [Sun Jan 17 22:42:38 2016] kinda, yeah [Sun Jan 17 22:42:52 2016] Sets in the ZFC sense are pretty weird things [Sun Jan 17 22:42:53 2016] so why is a Set an instance of Type? [Sun Jan 17 22:43:09 2016] what when I declare nat as a Set, is that a ZFC set? [Sun Jan 17 22:43:12 2016] Well, it's sort of like the bottom of the hierarchy [Sun Jan 17 22:43:15 2016] no [Sun Jan 17 22:43:20 2016] This isn't ZFC :) [Sun Jan 17 22:43:29 2016] It's a completely separate formalism of its own [Sun Jan 17 22:44:00 2016] so really we have Set is Type0, and Type is Type1, so Type0 : Type1 [Sun Jan 17 22:44:10 2016] yeah, pretty much that's the idea [Sun Jan 17 22:44:12 2016] and Set and Type are just like word? [Sun Jan 17 22:44:17 2016] words* oh ok great [Sun Jan 17 22:44:24 2016] now it makese more sense [Sun Jan 17 22:44:35 2016] and there's cumulativity, so if you have A : Type i, then A : Type (i+1) as well, iirc [Sun Jan 17 22:44:44 2016] (but not the other way around) [Sun Jan 17 22:44:47 2016] right irc as well [Sun Jan 17 22:45:02 2016] from a model theory class that I promptly forgot [Sun Jan 17 22:45:25 2016] and yeah, there's this universe Prop at the bottom [Sun Jan 17 22:45:41 2016] which has some additional weird properties that the other universes don't share [Sun Jan 17 22:45:55 2016] oh so Prop is the lowest ? Prop < Set < Type < Type + 1 < ... [Sun Jan 17 22:46:10 2016] in particular, you might notice that you can write things like (forall (P : Prop), P -> P) : Prop [Sun Jan 17 22:47:31 2016] Whereas if you tried to write this type (and displayed universe levels), replacing Prop with Set or Type, then you'd see that it lives in a higher universe [Sun Jan 17 22:48:01 2016] Prop is sort of weird in that you're allowed to quantify over propositions and just have simple propositions in the same universe, and not a higher one [Sun Jan 17 22:48:17 2016] so the key here is the forall right? [Sun Jan 17 22:49:12 2016] with out it, if we just had (S : Set, S -> S) : Set [Sun Jan 17 22:49:19 2016] that would be ok [Sun Jan 17 22:49:38 2016] uh [Sun Jan 17 22:49:47 2016] S won't be in scope in the second part of that pair [Sun Jan 17 22:49:52 2016] Did you mean a dependent pair? [Sun Jan 17 22:51:44 2016] er nvm haha [Sun Jan 17 22:51:59 2016] wait so here [ (forall (x : bool), f x = x) -> ...] [Sun Jan 17 22:52:22 2016] I see dont see why f x = x is a type? [Sun Jan 17 22:52:36 2016] Well, it's actually a Prop [Sun Jan 17 22:52:42 2016] but Props are a kind of type :) [Sun Jan 17 22:53:07 2016] But yeah, it had better be a type of some sort, because it's the body of a forall [Sun Jan 17 22:53:16 2016] forall (x : A), B x [Sun Jan 17 22:53:19 2016] is the type of functions [Sun Jan 17 22:53:25 2016] which given some x of type A [Sun Jan 17 22:53:30 2016] produce a result of type B x [Sun Jan 17 22:54:22 2016] is somethine like this expressible in haskells' tyepsystem? [Sun Jan 17 22:54:27 2016] if so how would it be expressed? [Sun Jan 17 22:54:27 2016] no [Sun Jan 17 22:54:32 2016] oh ok haha [Sun Jan 17 22:54:38 2016] This is exactly what Haskell's type system is missing [Sun Jan 17 22:54:49 2016] what is this called? [Sun Jan 17 22:54:55 2016] this thing that's missing [Sun Jan 17 22:55:00 2016] In Haskell, you can quantify over types [Sun Jan 17 22:55:19 2016] These are called Pi-types, it's often written Pi (x : A), B x instead [Sun Jan 17 22:55:36 2016] (often with a big capital Greek letter Pi) [Sun Jan 17 22:55:45 2016] (and the x : A just goes underneath) [Sun Jan 17 22:56:00 2016] Or dependent function types [Sun Jan 17 22:56:03 2016] is another term [Sun Jan 17 22:56:14 2016] the type of the result of the function depends on the value of its argument [Sun Jan 17 22:56:47 2016] so forall here translates to Pi? [Sun Jan 17 22:56:52 2016] yeah [Sun Jan 17 22:56:54 2016] as in multicpliaction? [Sun Jan 17 22:57:03 2016] I mean, it's suggestive of that [Sun Jan 17 22:57:05 2016] which is a product? why is not a sum [Sun Jan 17 22:57:17 2016] theres also Sigma (x :A) B x right? [Sun Jan 17 22:57:24 2016] Because it's like you're taking the Cartesian product of the types B x for each x [Sun Jan 17 22:57:41 2016] (a giant Cartesian product) [Sun Jan 17 22:57:54 2016] so we have B x1 * B x2 * ... [Sun Jan 17 22:57:56 2016] and applying the function picks out the appropriate component, indexed by the value of type A [Sun Jan 17 22:58:00 2016] yeah [Sun Jan 17 22:58:08 2016] and yeah, there's also Sigma types [Sun Jan 17 22:58:12 2016] what function? the depnendent typed function [Sun Jan 17 22:58:15 2016] Sigma (x:A), B x [Sun Jan 17 22:58:27 2016] is the type of pairs whose first component is some x of type A [Sun Jan 17 22:58:33 2016] and whose second component is of type B x [Sun Jan 17 22:58:57 2016] why is it a pair? and not like (_, _, _, ... )? [Sun Jan 17 22:59:40 2016] Well, the idea is that we're taking a disjoint union of the types B x over all x [Sun Jan 17 23:00:04 2016] and so you say which component of the disjoint union you're in, and then you say which element of that component [Sun Jan 17 23:00:14 2016] Or thinking logically [Sun Jan 17 23:00:18 2016] Pi (x:A), B x [Sun Jan 17 23:00:29 2016] says "for all x of type A, we have B x" [Sun Jan 17 23:00:41 2016] So this is a function which given x of type A, will provide a proof of B x [Sun Jan 17 23:00:55 2016] That is, that's what a term of this type denotes [Sun Jan 17 23:01:06 2016] while [Sun Jan 17 23:01:11 2016] Sigma (x:A), B x [Sun Jan 17 23:01:21 2016] says "there exists an x of type A, such that B x" [Sun Jan 17 23:01:38 2016] so a proof of this is a pair consisting of the witness x, together with a proof that B x [Sun Jan 17 23:02:00 2016] ahh ok great that really clears it up [Sun Jan 17 23:02:30 2016] so when we see doubly nested forall [Sun Jan 17 23:03:01 2016] So, going back to your example... [Sun Jan 17 23:03:04 2016] forall f : A (forall x : B, f x = x) [Sun Jan 17 23:03:15 2016] that trnaslates to a nested product right? [Sun Jan 17 23:03:45 2016] yeah, or you can think of it as a function of two arguments [Sun Jan 17 23:04:01 2016] it's going to take some f of type A [Sun Jan 17 23:04:02 2016] what's the function and what are the args? [Sun Jan 17 23:04:03 2016] and an x of type B [Sun Jan 17 23:04:09 2016] and produce some result of type f x = x [Sun Jan 17 23:04:35 2016] ohh that's what you meant a long while back haha [Sun Jan 17 23:04:48 2016] ok see it was all syntax to me [Sun Jan 17 23:05:14 2016] forall (f : bool -> bool), (forall (x : bool), f x = x) -> forall (b : bool), f (f b) = b. [Sun Jan 17 23:05:18 2016] We had this type [Sun Jan 17 23:05:25 2016] So a function of this type [Sun Jan 17 23:05:33 2016] takes an argument f of type bool -> bool [Sun Jan 17 23:05:44 2016] and produces a function [Sun Jan 17 23:06:07 2016] which takes a function which accepts an argument x of type bool, and produces a result of type f x = x [Sun Jan 17 23:06:31 2016] and produces a function which accepts an argument b of type bool, and produces a result of type f (f b) = b. [Sun Jan 17 23:06:59 2016] I chose to name that function argument "P" [Sun Jan 17 23:07:22 2016] i.e. we could also write this using more foralls, without the -> [Sun Jan 17 23:07:46 2016] forall (f : bool -> bool), forall (P : forall (x : bool), f x = x), forall (b : bool), f (f b) = b. [Sun Jan 17 23:07:58 2016] A -> B [Sun Jan 17 23:08:02 2016] is the same thing as [Sun Jan 17 23:08:06 2016] forall (x:A), B [Sun Jan 17 23:08:15 2016] where B doesn't depend on x [Sun Jan 17 23:09:38 2016] We can also give the arguments to the theorem directly when we're defining it, which means about the same thing: [Sun Jan 17 23:09:44 2016] Theorem identity_fn_applied_twice (f : bool -> bool) (P : forall x : bool, f x = x) (b : bool) : f (f b) = b. [Sun Jan 17 23:09:51 2016] is that why A -> B is the same as A^B ? [Sun Jan 17 23:10:05 2016] B^A you mean [Sun Jan 17 23:10:10 2016] ops yeah [Sun Jan 17 23:10:24 2016] and I guess you can kind of think of it like that, with respect to why we use the notation [Sun Jan 17 23:10:30 2016] I wouldn't say it's the reason why [Sun Jan 17 23:12:00 2016] A more straightforward reason why we'd use the notation is that if A is a finite set with n elements, and B is a finite set with m elements, then B^A, the set of functions A -> B, has m^n elements. [Sun Jan 17 23:12:58 2016] The reason why A -> B "is" B^A sounds like a philosophical one -- you probably have to provide a bunch more context about what you mean in order to really answer the question. [Sun Jan 17 23:13:24 2016] oh ok I'll veer away from that for now haha :D [Sun Jan 17 23:14:14 2016] So let's try to prove this. The easiest way is to use the rewrite tactic. [Sun Jan 17 23:14:22 2016] yes finally haha! [Sun Jan 17 23:15:17 2016] Theorem identity_fn_applied_twice : forall (f : bool -> bool), (forall (x : bool), f x = x) -> forall (b : bool), f (f b) = b. -- let's preserve your original version [Sun Jan 17 23:15:33 2016] intros f P b. [Sun Jan 17 23:15:42 2016] and you should see in the context: [Sun Jan 17 23:15:47 2016] f : bool -> bool [Sun Jan 17 23:15:47 2016] P : forall x : bool, @eq bool (f x) x [Sun Jan 17 23:15:47 2016] b : bool [Sun Jan 17 23:15:57 2016] oh, let me turn back on the notations :) [Sun Jan 17 23:16:05 2016] f : bool -> bool [Sun Jan 17 23:16:05 2016] P : forall x : bool, f x = x [Sun Jan 17 23:16:05 2016] b : bool [Sun Jan 17 23:16:12 2016] yup i see that [Sun Jan 17 23:16:34 2016] so, we can apply P to b, and we'll have P b : f b = b [Sun Jan 17 23:16:56 2016] yeah? [Sun Jan 17 23:17:01 2016] yup that makese sense [Sun Jan 17 23:17:48 2016] and if we apply the rewrite tactic to that, it will go looking for an occurrence of f b in our goal, and use an operation to substitute across the equality, replacing that with b [Sun Jan 17 23:17:57 2016] rewrite (P b). [Sun Jan 17 23:18:03 2016] and our goal becomes f b = b [Sun Jan 17 23:18:26 2016] Well, we certainly know how to prove that! [Sun Jan 17 23:18:34 2016] exact (P b). [Sun Jan 17 23:18:37 2016] and we're done [Sun Jan 17 23:18:46 2016] or, you can choose to rewrite (P b). again [Sun Jan 17 23:18:55 2016] and that'll get you the goal b = b [Sun Jan 17 23:19:09 2016] and you can use reflexivity to handle that [Sun Jan 17 23:19:35 2016] ahh ok i got [Sun Jan 17 23:19:49 2016] however ... when i say rewrite (P b) on [f (f b) = b] [Sun Jan 17 23:19:53 2016] what is happening here? [Sun Jan 17 23:20:06 2016] the inner (f b) is being reduced right? [Sun Jan 17 23:20:23 2016] but what is happening "behind the scenes" [Sun Jan 17 23:21:18 2016] okay, so we can see what's taking place by finishing up our proof using Defined. [Sun Jan 17 23:21:28 2016] and then Print identity_fn_applied_twice. [Sun Jan 17 23:21:41 2016] and it will print the code which was generated [Sun Jan 17 23:22:09 2016] identity_fn_applied_twice = [Sun Jan 17 23:22:09 2016] fun (f : bool -> bool) (P : forall x : bool, f x = x) (b : bool) => [Sun Jan 17 23:22:09 2016] eq_ind_r (fun b0 : bool => f b0 = b) (P b) (P b) [Sun Jan 17 23:22:09 2016] : forall f : bool -> bool, [Sun Jan 17 23:22:09 2016] (forall x : bool, f x = x) -> forall b : bool, f (f b) = b [Sun Jan 17 23:22:25 2016] woa that's cool [Sun Jan 17 23:22:27 2016] So it's using this thing eq_ind_r [Sun Jan 17 23:22:55 2016] yeah what's ind stand for? [Sun Jan 17 23:22:59 2016] induction [Sun Jan 17 23:23:06 2016] oh and r? right? [Sun Jan 17 23:23:16 2016] yeah, it's a specialisation of eq_ind [Sun Jan 17 23:23:30 2016] what's fun? function? [Sun Jan 17 23:23:43 2016] yeah, lambda basically [Sun Jan 17 23:23:43 2016] is it coq that's output? [Sun Jan 17 23:23:47 2016] yes [Sun Jan 17 23:23:56 2016] can i get it to output haskell for example? [Sun Jan 17 23:24:18 2016] Um... maybe not for this type... [Sun Jan 17 23:24:49 2016] hm but to prove forall n m : nat, n = m -> n + n = m + m [Sun Jan 17 23:24:54 2016] that's possible right? [Sun Jan 17 23:25:01 2016] yeah, that's possible [Sun Jan 17 23:25:23 2016] ah great [Sun Jan 17 23:25:31 2016] so looking at the printed output theres this fat arrow => [Sun Jan 17 23:25:46 2016] yeah, it's fun => [Sun Jan 17 23:26:04 2016] ah so what is being output? [Sun Jan 17 23:26:08 2016] a function? [Sun Jan 17 23:26:11 2016] In Haskell, fun is \ [Sun Jan 17 23:26:14 2016] and => is -> [Sun Jan 17 23:26:20 2016] ah ok that makese sense [Sun Jan 17 23:26:29 2016] so to prove this proposition which is a type [Sun Jan 17 23:26:36 2016] we show it's inhanbited by this function? [Sun Jan 17 23:26:40 2016] yeah [Sun Jan 17 23:26:42 2016] and that's what's being output .. [Sun Jan 17 23:26:45 2016] i see cool [Sun Jan 17 23:27:13 2016] and the tactic language is just a baroque syntax for constructing terms in this lambda calculus [Sun Jan 17 23:27:38 2016] (one which can do fun things like searching through the context or goal for certain bits and making the code it generates depend on that) [Sun Jan 17 23:27:49 2016] ohhh that's cool [Sun Jan 17 23:28:39 2016] 'intros' basically makes a lambda :) [Sun Jan 17 23:28:50 2016] oh that makese sense [Sun Jan 17 23:28:54 2016] and fills the body of the lambda with whatever the rest of the proof constructs [Sun Jan 17 23:29:12 2016] what about rewrite? is it like function application? [Sun Jan 17 23:29:18 2016] rewrite does something more fancy [Sun Jan 17 23:29:31 2016] I couldn't really tell you what it does in very precise terms... [Sun Jan 17 23:29:51 2016] oh haha it's all good [Sun Jan 17 23:29:55 2016] i'm learning a ton as is [Sun Jan 17 23:29:59 2016] But more or less, it uses this equality induction function (or one of its friends) [Sun Jan 17 23:30:27 2016] man this stuff is pretty wild [Sun Jan 17 23:30:27 2016] I know how to use eq_ind, and I know how to use rewrite, but I'd have to think hard about how to write rewrite itself :) [Sun Jan 17 23:30:41 2016] lol yeah guess lots of people did [Sun Jan 17 23:31:24 2016] It has to go structurally digging through the goal recursively, and find an occurrence of the left hand side of the equality [Sun Jan 17 23:32:09 2016] and then supply a function to eq_ind (or one of its variants, based on some stuff...) based on that [Sun Jan 17 23:33:16 2016] yeah, if you look here: [Sun Jan 17 23:33:21 2016] eq_ind_r (fun b0 : bool => f b0 = b) (P b) (P b) [Sun Jan 17 23:33:39 2016] yup i see it [Sun Jan 17 23:33:41 2016] the function it's passing expresses that we're replacing the "b0" part [Sun Jan 17 23:33:53 2016] b0 will be the lhs of the equality [Sun Jan 17 23:34:01 2016] Cale: how much do you use Coq? [Sun Jan 17 23:34:06 2016] johnw: Only a little [Sun Jan 17 23:34:20 2016] johnw: I did a bunch of HoTT related stuff in it which I didn't really distribute [Sun Jan 17 23:34:26 2016] ah, ok [Sun Jan 17 23:34:47 2016] johnw: I woke up one morning and realised that I already knew how to program in Coq [Sun Jan 17 23:34:53 2016] and I have no idea how it happened [Sun Jan 17 23:35:01 2016] not (story of my life) [Sun Jan 17 23:35:24 2016] lingxiao: I think if you hang around in functional programming circles for a decade and read papers and stuff [Sun Jan 17 23:35:43 2016] eventually even if you haven't seen much Coq before, it sort of makes sense [Sun Jan 17 23:35:56 2016] lol yes maybe im on the path who knows hah [Sun Jan 17 23:36:18 2016] lingxiao: did you finally finish this proof? [Sun Jan 17 23:36:26 2016] yup it ended up being really short [Sun Jan 17 23:36:45 2016] but really theres a lot going on both from the semantics perspective [Sun Jan 17 23:37:02 2016] I had: intros; rewrite (H (f b)); apply H. [Sun Jan 17 23:37:07 2016] and just peripheral stuff having to do with coq that i'm still trying to appreicatate [Sun Jan 17 23:37:21 2016] oh havn't learn apply yet [Sun Jan 17 23:37:31 2016] apply is one of the most fundamental ones [Sun Jan 17 23:37:37 2016] johnw: We had intros f P b. rewrite (P b). exact (P b). [Sun Jan 17 23:37:42 2016] it's function application, hence the name [Sun Jan 17 23:37:56 2016] oh that would be very useful haha [Sun Jan 17 23:37:57 2016] so P -> Q can turn a P into a Q, or in the goal, go from needing a Q to needing a P [Sun Jan 17 23:38:07 2016] Yeah, apply is a little more magical than exact [Sun Jan 17 23:38:19 2016] It can go looking for what to apply your hypothesis to :) [Sun Jan 17 23:38:38 2016] oh, intros; rewrite (H b); apply H. works too, thanks [Sun Jan 17 23:39:12 2016] or just s/apply H/auto [Sun Jan 17 23:39:26 2016] Yeah, auto is the next level of magic [Sun Jan 17 23:42:21 2016] opse [Sun Jan 17 23:43:19 2016] haha will stay away from auto for now then [Sun Jan 17 23:43:38 2016] think of "auto" as "do the obvious stuff" [Sun Jan 17 23:43:41 2016] it can never hurt [Sun Jan 17 23:43:45 2016] Another fun thing we could do is to use repeat: repeat (rewrite (P b)). will apply the rewrite (P b) tactic until it fails. [Sun Jan 17 23:44:11 2016] Which will get you straight to b = b [Sun Jan 17 23:44:15 2016] ooo that's fun [Sun Jan 17 23:44:31 2016] (silly in this case, but if there were more occurrences of f, maybe we'd be happy with this) [Sun Jan 17 23:45:15 2016] Some tactics will produce multiple goals, and sometimes you'll want to do a similar thing at the start of solving each goal [Sun Jan 17 23:45:19 2016] yeah I'll keep that in mind [Sun Jan 17 23:45:23 2016] ther's a lot of tactices [Sun Jan 17 23:45:25 2016] For that, using ; is useful [Sun Jan 17 23:45:32 2016] t1 ; t2 [Sun Jan 17 23:45:41 2016] although there's a lot of tactics, there aren't really a lot of tactics [Sun Jan 17 23:45:43 2016] will apply the tactic t2 to each of the goals generated by t1 [Sun Jan 17 23:45:46 2016] it just looks and feels that way [Sun Jan 17 23:46:06 2016] almost always you're doing introduction, elimination, and reasoning using equalities, in some form or another [Sun Jan 17 23:46:21 2016] You can get by with a tiny subset of the available tactics [Sun Jan 17 23:46:25 2016] (oh, and function application) [Sun Jan 17 23:46:46 2016] yeah, the ssreflect library has just 4 core tactics [Sun Jan 17 23:46:50 2016] and some books that teach Coq do this and choose a pretty awkward subset :D [Sun Jan 17 23:47:08 2016] "refine" and that's it? :D [Sun Jan 17 23:47:32 2016] ok so ; is a tactice as well? [Sun Jan 17 23:47:36 2016] just sugared? [Sun Jan 17 23:47:44 2016] or it's more like control flow ... [Sun Jan 17 23:47:48 2016] ; composes tactics [Sun Jan 17 23:47:54 2016] oh ok make sense [Sun Jan 17 23:47:58 2016] It's what is called a tactical: so a "tactic" which acts on tactics [Sun Jan 17 23:47:58 2016] a ; b says "do a, then apply b to all goals it generates" [Sun Jan 17 23:47:59 2016] Yeah, it's part of the tactic language [Sun Jan 17 23:48:10 2016] hm ok great thanks!@ [Sun Jan 17 23:48:44 2016] a ; [ b | c ] is another tactical: "do a, then apply b to its first sub-goal, and c to its second". [Sun Jan 17 23:49:06 2016] although that one is much more often seen in scripts [Sun Jan 17 23:49:16 2016] whats scripts [Sun Jan 17 23:49:26 2016] another time :) [Sun Jan 17 23:49:35 2016] oh haha yeah theres' alot to larn [Sun Jan 17 23:49:37 2016] learn* [Sun Jan 17 23:49:52 2016] scripts let you write your own tactics [Sun Jan 17 23:49:59 2016] by combining other ones [Sun Jan 17 23:50:02 2016] a || b will try to apply a, and if it fails to make progress using that, it will then try b [Sun Jan 17 23:50:11 2016] writing a truly new tactic requires rewriting a plugin with ocaml [Sun Jan 17 23:50:19 2016] like or [Sun Jan 17 23:50:42 2016] which is sometimes nice on the right side of ; when you have a bunch of goals that you're applying the tactic to [Sun Jan 17 23:50:57 2016] Cale: wow, I totally forgot about || [Sun Jan 17 23:50:59 2016] and they're all solved by one or the other [Sun Jan 17 23:51:07 2016] I always use first, even with two tactics [Sun Jan 17 23:53:23 2016] It would be kind of cool if there were a way to see the generated proof terms as you wrote the script, and have your current goal also highlighted as a hole in the proof term [Sun Jan 17 23:53:59 2016] But I suppose it's not terribly straightforward all the time [Sun Jan 17 23:54:14 2016] Cale: funny you should ask... :) [Sun Jan 17 23:54:17 2016] Hmm. Why wouldn't it be actually? [Sun Jan 17 23:54:29 2016] Clémente has a prototype of exactly that working in company-coq [Sun Jan 17 23:54:43 2016] and you described its operation to a T [Sun Jan 17 23:55:38 2016] Would that be very different of outputting what [Show Proof] gives, plus highlighted the currently focused goal as a hole? [Sun Jan 17 23:55:45 2016] hilighting* [Sun Jan 17 23:55:58 2016] ok thanks Cale for all your help! [Sun Jan 17 23:56:00 2016] highlighting*. Gah. [Sun Jan 17 23:56:07 2016] I will prob be back fro more in the coming weeks :) [Sun Jan 17 23:56:11 2016] and you too johnw! [Sun Jan 17 23:56:14 2016] night gusy! [Sun Jan 17 23:56:28 2016] Cale: https://asciinema.org/a/bb3fxq5k9cdekaxnb07owf4gn [Sun Jan 17 23:56:35 2016] ^-- Clémente's demo [Sun Jan 17 23:56:44 2016] Cypi: Well, maybe it is straightforward after all, but I can imagine that there would be some cases where the goal didn't necessarily correspond to a single place in the syntax tree... maybe that doesn't come up [Sun Jan 17 23:57:00 2016] it's showing the extraction [Sun Jan 17 23:57:06 2016] not the proof term [Sun Jan 17 23:57:15 2016] but I wonder if he's thought of it yet [Sun Jan 17 23:57:57 2016] But yeah, that's pretty close to what I was envisioning :) [Mon Jan 18 00:14:24 2016] jgross_: how do I use a splitter ADT as if it were a parser? [Mon Jan 18 00:14:42 2016] ah, that's what your e-mail was about :) [Mon Jan 18 00:15:14 2016] johnw: Yep :) There's a `make_parser` tactic, though, which you can use for now. [Mon Jan 18 00:15:23 2016] within my composing spec? [Mon Jan 18 00:15:30 2016] and I'm on a different branch now [Mon Jan 18 00:15:54 2016] Well, actually, my email was asking for the example from even earlier, before you have the splitter adt in hand. [Mon Jan 18 00:16:09 2016] oh, with just the grammar [Mon Jan 18 00:16:14 2016] that's even better, actually [Mon Jan 18 00:18:02 2016] `make_parser` takes an argument which is a splitter, and solves a goal of type string -> bool. You can look at it's implementation to see what it does to extract the relevant bit, the basic idea is that there's a function of type Splitter -> Parser, and it uses this function, and then does a bunch of reductions so that the extracted code runs fast. [Mon Jan 18 00:18:43 2016] jgross_: Do you have an example of writing a recursive evaluator for a parse tree? [Mon Jan 18 00:19:00 2016] I'm trying to write a spec in terms of a grammar; or should I write it in terms of the splitter? [Mon Jan 18 00:19:03 2016] I guess the latter makes sense [Mon Jan 18 00:19:11 2016] no reason I need to refine these in combination [Mon Jan 18 00:25:02 2016] Write the spec in terms of the grammar. [Mon Jan 18 00:25:10 2016] ok [Mon Jan 18 00:26:16 2016] You can write it in terms of the splitter if you need to do fine-grained work on either the splitter or the parser (i.e., if you're writing code to add to the parser library). But if your goal is just "I need to parse this string", then you shouldn't need to know that splitters exist. [Mon Jan 18 00:26:30 2016] excellent, that's what I had hoped [Mon Jan 18 01:35:58 2016] jgross_: ping [Mon Jan 18 02:03:18 2016] johnw: pong [Mon Jan 18 02:04:21 2016] jgross_: oh hey, thought you went to sleep [Mon Jan 18 02:04:28 2016] jgross_: sent you mail via the ML [Mon Jan 18 02:11:29 2016] I saw; I'm responding to it now (sleeping soon) [Mon Jan 18 04:59:04 2016] does it make sense to use an axiom that says (exist A B X = exist A B Y)? [Mon Jan 18 04:59:18 2016] is there such a thing in the standard library? [Mon Jan 18 05:02:01 2016] Or rather [Mon Jan 18 05:02:12 2016] exist A B X = exist A C Y → B =C [Mon Jan 18 05:27:10 2016] rrika: "exist A B X = exist A C Y" is usually not well typed [Mon Jan 18 05:27:30 2016] rrika: could you be more explicit on the types of A, B, X, C, Y? [Mon Jan 18 05:28:31 2016] exist (fun x : nat => evenb x = true) (double n) (doubles_are_even n) = [Mon Jan 18 05:28:31 2016] exist (fun x : nat => evenb x = true) (double m) (doubles_are_even m) [Mon Jan 18 05:29:31 2016] (Also, I made a mistake again, the direction "exist A B X = exist A C Y → B = C" is easy, the other direction is the one I'm asking about) [Mon Jan 18 05:55:42 2016] rrika: use the "rewrite" tactic? [Mon Jan 18 05:56:25 2016] when I use rewrite on the goal I get an "ill typed expression" [Mon Jan 18 05:56:44 2016] when I use rewrite on "B" it fails because it's used in the goal [Mon Jan 18 05:57:52 2016] oh, I just shouldn't intro B and C before B=C [Mon Jan 18 05:58:49 2016] and then I do X = Y using proof irrelevance [Mon Jan 18 06:00:09 2016] rrika: it would help if you gave a self-contained example of what you're trying to achieve on e.g. paste.debian.net [Mon Jan 18 06:00:15 2016] rrika: as in https://paste.debian.net/366421/ [Mon Jan 18 06:16:01 2016] toc toc mutual recursion definition: start in product type or start separate? then how does it affect unfolding later. [Mon Jan 18 06:16:26 2016] jrw: ping [Mon Jan 18 06:17:19 2016] sgnb: will try next time. what you posted is how I resolved it now. [Mon Jan 18 06:18:17 2016] (what I didn't notice was that while rewriting it for IRC I brought it into a more easily provable form DX) [Mon Jan 18 14:22:58 2016] hello Coq fans [Mon Jan 18 22:26:26 2016] jrw: ping [Mon Jan 18 22:27:11 2016] has the bug about auto's apply not traversing conjunction, but manual apply do traverse conjunction? [Tue Jan 19 02:30:03 2016] is there a difference between Hint Resolve foo and Hint Extern 1 => apply foo? [Tue Jan 19 02:39:12 2016] ugh, "Error: Conversion test raised an anomaly" [Tue Jan 19 02:40:04 2016] Related to universe polymorphism it would appear [Tue Jan 19 03:29:59 2016] I'm stuck at SF chapter "MoreCoq" at "combine_split". [Tue Jan 19 03:30:12 2016] I think it has to do with the body of "split" being missing. [Tue Jan 19 03:30:33 2016] At least when I do "Print split" before the theorem it shows me ":= admit" [Tue Jan 19 06:12:18 2016] Hi! [Tue Jan 19 06:12:30 2016] I wonder if someone have some recommendation for learning coq. [Tue Jan 19 06:12:59 2016] i'm reading coq'art and i really like it, but at some point i felt like i still can't do anything :) [Tue Jan 19 06:13:01 2016] http://www.cis.upenn.edu/~bcpierce/sf/current/index.html is a good book, from the computer science side [Tue Jan 19 06:13:11 2016] (book as in exercises) [Tue Jan 19 06:13:33 2016] i went through the first chapter [Tue Jan 19 06:13:36 2016] it felt nice [Tue Jan 19 06:13:50 2016] do you think it's a good idea to learn it before coq'art? [Tue Jan 19 06:15:22 2016] i have a haskell background and what i really want to do is grasp dependent types and differences to compose a bigger picture of typed functional programming [Tue Jan 19 06:17:53 2016] I started with SF (six chapters in). It's doable. [Tue Jan 19 06:21:03 2016] http://www.amazon.com/Certified-Programming-Dependent-Types-Introduction/dp/0262026651/ref=sr_1_1?ie=UTF8&qid=1453202454&sr=8-1&keywords=certified+programming+with+dependent+types anyone read this? [Tue Jan 19 06:22:27 2016] http://adam.chlipala.net/cpdt/ this ? you can also use the html version [Tue Jan 19 06:22:28 2016] I heard it's nice but more advanced (I just checked a few parts I needed myself) [Tue Jan 19 06:24:12 2016] companion_cube: oh, cool [Tue Jan 19 06:24:32 2016] i'll probably buy the hardcover anyway, would like to see that on my shelf [Tue Jan 19 06:24:44 2016] i'm a little old-fashioned in this matter [Tue Jan 19 06:25:24 2016] also i'm interested if anyone tried to learn CT/abstract algebra concepts with coq? [Tue Jan 19 06:25:27 2016] dredozubov, when working through SF I found it really useful to have all the text and exercises in emacs, to work on them right when I read the accompanying text. [Tue Jan 19 06:25:46 2016] does it make sense to postpone learning math to have a background with coq? [Tue Jan 19 06:26:08 2016] rrika: i'm downloading it right now to have exactly that! [Tue Jan 19 06:26:21 2016] proof general looks pretty nice [Tue Jan 19 06:29:56 2016] I haven't tried coqtop, but I guess the interaction style would be similar. [Tue Jan 19 06:30:28 2016] afaik proof general uses coqtop under the hood. Is that right? [Tue Jan 19 06:30:47 2016] yes [Tue Jan 19 06:30:51 2016] One of the coq binaries runs in background. [Tue Jan 19 06:31:29 2016] btw is it possible to evaluate statements until line number or cursor in proof general? [Tue Jan 19 06:31:46 2016] i see the options to do it one by one and altogether [Tue Jan 19 06:32:14 2016] Ctrl+C Ctrl+Enter [Tue Jan 19 06:32:57 2016] oh, cool! [Tue Jan 19 06:32:58 2016] thanks [Tue Jan 19 06:35:50 2016] You might also find the "Electric Terminator" option useful. It will submit everything to coq everytime you type "." [Tue Jan 19 06:35:56 2016] Toggle with: Ctrl+C . [Tue Jan 19 06:36:05 2016] (not Ctrl+C Ctrl+.) [Tue Jan 19 07:18:22 2016] coq indentation rules in emacs seem broken [Tue Jan 19 07:18:30 2016] any ideas how to fix that? [Tue Jan 19 10:48:02 2016] is there any way ot print what auto tactic did during some step? [Tue Jan 19 10:50:20 2016] dredozubov: "info auto" [Tue Jan 19 10:51:30 2016] is "info auto" repaired in 8.5? [Tue Jan 19 10:51:37 2016] it does not work, but suggests replacements [Tue Jan 19 10:51:37 2016] it doesn't work in 8.4, iirc [Tue Jan 19 10:51:42 2016] such as info_auto [Tue Jan 19 10:51:45 2016] Warning: The general "info" tactic is currently not working. There is an [Tue Jan 19 10:51:45 2016] "Info" command to replace it. [Tue Jan 19 10:51:45 2016] Some specific verbose tactics may also exist, such as info_eauto. [Tue Jan 19 10:52:11 2016] so, info_eauto then [Tue Jan 19 10:52:28 2016] i don't see any output though [Tue Jan 19 10:52:38 2016] info_eauto works just like auto [Tue Jan 19 10:52:56 2016] i'm using 8.4 [Tue Jan 19 10:53:26 2016] I'm using 8.4 and info_eauto seems to work as I expect [Tue Jan 19 10:53:39 2016] do you use proof general? [Tue Jan 19 10:53:49 2016] oh, I was using coqide [Tue Jan 19 10:54:04 2016] :( [Tue Jan 19 10:54:28 2016] I just checked; it works also in PG [Tue Jan 19 10:54:35 2016] is it possible that i should enable something else for it to work? [Tue Jan 19 10:55:03 2016] where should info output appear? [Tue Jan 19 10:56:10 2016] buffer *response* [Tue Jan 19 10:57:28 2016] RegEchse : the replacement, which is kind of working at the moment, is "Info n auto" where n is some depth level (for instance 1) [Tue Jan 19 10:57:41 2016] Oh sorry, it was answered. [Tue Jan 19 10:57:49 2016] sgnb: it's empty :( [Tue Jan 19 10:58:11 2016] sgnb: have you tried it with coq 8.4? [Tue Jan 19 11:01:04 2016] dredozubov: I'm using coq 8.4pl4 [Tue Jan 19 11:01:52 2016] weird [Tue Jan 19 11:02:00 2016] 8.4pl5 here [Tue Jan 19 11:02:25 2016] maybe it works only on the trivial case I'm testing [Tue Jan 19 11:03:19 2016] Info n auto works silently too. [Tue Jan 19 11:03:36 2016] maybe it's misconfigured somehow, i don't have a clue [Tue Jan 19 11:16:42 2016] smerdyakow: pong? [Tue Jan 19 11:19:15 2016] pong hehe [Tue Jan 19 11:19:15 2016] has the bug about auto's apply not traversing conjunction, but manual apply do traverse conjunction? [Tue Jan 19 11:19:35 2016] yes that is a known issue [Tue Jan 19 11:19:49 2016] it's not a bug in the sense that I don't think there are any plans to change the behavior [Tue Jan 19 11:20:18 2016] the problem is that auto is traversing potentially large hint databases, so I guess it might be expensive to try traversing conjunctions for all of them [Tue Jan 19 11:20:24 2016] but with apply you only have a single option [Tue Jan 19 14:27:40 2016] Anyone set up spacemacs with proof general? [Tue Jan 19 14:28:07 2016] I might try it, instead of spending more time fixing up the vim plugin [Tue Jan 19 15:14:27 2016] tbelaire: you can also check out epdtry's plugin for neovim https://github.com/epdtry/neovim-coq [Tue Jan 19 15:15:11 2016] Interesting [Tue Jan 19 15:16:40 2016] ooh, uses async and await python features [Tue Jan 19 15:16:52 2016] I wonder if they have non-blocking mode [Tue Jan 19 15:22:03 2016] aahah, that fakeroot. That's clever. https://github.com/epdtry/neovim-coq/blob/master/xmlutil.py#L12 [Tue Jan 19 15:22:38 2016] Coq really should have a slightly different design so that isn't necessary. [Tue Jan 19 15:22:50 2016] But that is one way to handle it [Tue Jan 19 15:22:52 2016] tbelaire: um, patches welcome? :) [Tue Jan 19 15:23:44 2016] I don't want to touch the protocal, since that would require fixing the CoqIDE and Emacs pluginsa nd everyone else who has plugins's code [Tue Jan 19 15:24:01 2016] it's unfortunate, but I don't think it's better to fix it now [Tue Jan 19 15:24:12 2016] I did poke around there [Tue Jan 19 15:24:54 2016] What was really annoying was sending as "one" response [Tue Jan 19 15:25:18 2016] It would have been nice if there was a wrapper element around that [Tue Jan 19 15:25:45 2016] so you can just stop pulling from the pipe once you get a full, balanced element. [Tue Jan 19 15:26:19 2016] I wish I could do "destruct" on a list, except I split off the last element. [Tue Jan 19 15:26:32 2016] (I'm doing the palindrome_reverse exercise) [Tue Jan 19 15:26:43 2016] rrika: I sometimes see that under the name "snoc" [Tue Jan 19 15:26:47 2016] cons backwards [Tue Jan 19 15:26:59 2016] if you're trying to search for something [Tue Jan 19 15:27:09 2016] yeah, I know about that. [Tue Jan 19 15:27:13 2016] just trying to express that in tactics [Tue Jan 19 15:27:26 2016] consider that either l = [] or l = (snoc l' x) [Tue Jan 19 15:28:38 2016] build a new induction principle? [Tue Jan 19 15:29:32 2016] I did "apply f_equal with (f:=rev) in H." and it looks promising- [Tue Jan 19 15:29:45 2016] (where H was something involving l) [Tue Jan 19 15:29:55 2016] cool [Tue Jan 19 16:07:44 2016] jgross_: how do I use your bug minifier again? [Tue Jan 19 16:09:27 2016] I must be missing something obvious, how do I show that "ble_nat (S n) m = true → ble_nat n m = true" [Tue Jan 19 16:11:32 2016] induction on n [Tue Jan 19 16:13:05 2016] I get no useful IH. [Tue Jan 19 16:13:15 2016] show me [Tue Jan 19 16:13:29 2016] also, did you first generalize m? [Tue Jan 19 16:13:30 2016] IHn: ble_nat (S n) m = true -> ble_nat n m = true [Tue Jan 19 16:13:33 2016] oh [Tue Jan 19 16:13:35 2016] right [Tue Jan 19 16:19:54 2016] i wonder if that proof is easier inducting on m too [Tue Jan 19 16:20:02 2016] not sure [Tue Jan 19 16:23:22 2016] I'm reaching 2 screen pages of length but I think my proof of palindrome_converse is finally reaching its conclusion. [Tue Jan 19 19:31:21 2016] johnw: there should be an invocation in the readme [Tue Jan 19 20:19:50 2016] If I have a parameter in a module (not a module type), how do I provide a definition for that parameter when I import the module? [Tue Jan 19 23:50:15 2016] anyone around? [Tue Jan 19 23:51:19 2016] lingxiao: people are always around :) [Tue Jan 19 23:51:23 2016] or reading the logs later [Tue Jan 19 23:51:31 2016] oh great thanks! [Tue Jan 19 23:51:38 2016] I'd like a little help navigating this proof [Tue Jan 19 23:52:04 2016] I can't seem to express my logic using just intros and destruct [Tue Jan 19 23:52:10 2016] maybe rewrite [Tue Jan 19 23:52:36 2016] and reflexivity [Tue Jan 19 23:52:52 2016] forall b c : bool, b && c = true -> c = true [Tue Jan 19 23:53:13 2016] see b && c = true iff b = true [Tue Jan 19 23:53:28 2016] so then trivially true && c = true iff c = true [Tue Jan 19 23:53:42 2016] but when I destruct b I get both casese where b = true and b = false [Tue Jan 19 23:53:49 2016] I want to say the case where b = false cannot happen [Tue Jan 19 23:54:08 2016] and when i desttruct c i get c = true, which satisfies the conclusion [Tue Jan 19 23:54:36 2016] and c = false, which I want to say does not satisfy hypothesis [Tue Jan 19 23:54:46 2016] but i cant navigate this using the tactics given [Tue Jan 19 23:58:07 2016] lingxiao: do you know inversion yet? [Tue Jan 19 23:58:15 2016] nope but I'll use it! [Tue Jan 19 23:58:45 2016] i mean if i only used [rewrite, intros, destruct, reflexivity] is it possible to prove it? [Tue Jan 19 23:58:53 2016] lingxiao: if you have something like [H : false = true] in your context, you can do [inversion H] to get rid of the whole case [Tue Jan 19 23:59:10 2016] I'm very much at the clumsly finangle results using the language here [Tue Jan 19 23:59:16 2016] hmm let me tryy [Wed Jan 20 00:00:25 2016] I'll be damned [Wed Jan 20 00:00:33 2016] so what does inversion do? [Wed Jan 20 00:01:11 2016] what I ended up using [Wed Jan 20 00:01:12 2016] http://lpaste.net/150289 [Wed Jan 20 00:03:33 2016] lingxiao: looks reasonable. without stepping through the proof, I'm just guessing that you can get rid of the second [destruct c] and just immediately do [inversion H] [Wed Jan 20 00:04:24 2016] lingxiao: how inversion in full generality is a bit complicated, but for now just think about it as saying if you have a hypothesis that is an equation between constructors of this type, it reasons "backwards" to figure out what must have been true to make that equality true [Wed Jan 20 00:04:39 2016] why does inversion H take a long time? [Wed Jan 20 00:04:41 2016] so in the case where you have *different* constructors equated, it just derives a contradiction for you immediately [Wed Jan 20 00:04:46 2016] hmm so its some higher level magic [Wed Jan 20 00:05:04 2016] when you have something like [H : S a = S b] then inversion would give you [H1 : a = b] [Wed Jan 20 00:05:35 2016] so inversion creates a new hypothesis by backward induction? [Wed Jan 20 00:05:41 2016] but only one steop [Wed Jan 20 00:05:46 2016] it reasons backwards one step [Wed Jan 20 00:05:54 2016] it may create 0, 1, or many hypotheses [Wed Jan 20 00:06:06 2016] for example with [false = true] it creates 0 because it just finishes right away [Wed Jan 20 00:06:14 2016] with [S a = S b] it makes one [Wed Jan 20 00:06:44 2016] and for lists with constructor cons, you could have [cons x xs = cons y ys], then inversion would give you two equations [x = y] and [xs = ys] [Wed Jan 20 00:11:35 2016] its so weird at first it worked [Wed Jan 20 00:11:49 2016] now it seems to be stuck in some infinte loop [Wed Jan 20 00:13:51 2016] yeah stuck on the part where true = false for c [Wed Jan 20 00:14:31 2016] lingxiao: that's weird, I've never seen inversion go into a loop [Wed Jan 20 00:14:41 2016] yeah it def worked the first time for me lol! [Wed Jan 20 00:14:52 2016] but in all subsequent times it does not seem to terminate [Wed Jan 20 00:49:32 2016] if I find myself repeating a bunch of Context lines, can I turn that into a private command or something? [Wed Jan 20 01:42:13 2016] I was at least able to reduce it down to one Context line [Wed Jan 20 09:05:45 2016] can i search for relevant lemmas/theorems somehow? [Wed Jan 20 09:06:07 2016] ctrl+c ctrl+a ctrl+a in proof general [Wed Jan 20 09:06:34 2016] cool [Wed Jan 20 09:06:43 2016] can i search by type somehow? [Wed Jan 20 09:07:07 2016] let's imagine i want to gather all of the proved knowledge for the nats [Wed Jan 20 09:07:10 2016] e.g. [Wed Jan 20 09:07:16 2016] how can i do that? [Wed Jan 20 09:07:16 2016] SearchAbout [ name ]. does the same as ctrl+c ctrl+a cltr+a [Wed Jan 20 09:07:32 2016] do exactly that search with "nats" [Wed Jan 20 09:07:43 2016] eh, "nat" [Wed Jan 20 09:08:15 2016] It depends on how much you've "Required" at the beginning though. [Wed Jan 20 09:08:17 2016] I think. [Wed Jan 20 09:08:39 2016] hmm [Wed Jan 20 09:08:40 2016] https://coq.inria.fr/library/ [Wed Jan 20 09:08:42 2016] i see a lot of stuff [Wed Jan 20 09:08:43 2016] ^ search for "nat there [Wed Jan 20 09:08:49 2016] not sure what's relevant [Wed Jan 20 09:08:54 2016] what do you want to show? [Wed Jan 20 09:08:55 2016] i'm going through the SF book [Wed Jan 20 09:09:08 2016] What exercise are you at? [Wed Jan 20 09:09:11 2016] it uses it's own nat implementation through the course [Wed Jan 20 09:09:27 2016] Induction.v: mult_comm [Wed Jan 20 09:10:05 2016] after some assertions i came to the point where i want to show that S b = S c -> b = c [Wed Jan 20 09:10:17 2016] it is pretty obvious, when you look at it [Wed Jan 20 09:10:28 2016] can't explain to it to coq though [Wed Jan 20 09:10:42 2016] I could tell you the tactic to resolve this, but I don't know if you're supposed to know at this stage. [Wed Jan 20 09:10:48 2016] dredozubov you can use inversion on the hypothesis [Wed Jan 20 09:10:50 2016] And looking at my solution I didn't need it. [Wed Jan 20 09:11:07 2016] i had the same problem [Wed Jan 20 09:11:08 2016] Nik05: i think i'm not supposed to do it at this point :) [Wed Jan 20 09:11:11 2016] What Nik05 said, "inversion" will do that. [Wed Jan 20 09:11:23 2016] im working on SF myself as well [Wed Jan 20 09:12:37 2016] i guess i'll try it [Wed Jan 20 09:12:42 2016] dredozubov you can proof mult_comm with some other lemma's [Wed Jan 20 09:12:44 2016] dredozubov, how does your proof look like so far? [Wed Jan 20 09:12:49 2016] so far my proofs look disgusting [Wed Jan 20 09:12:53 2016] no worries [Wed Jan 20 09:13:00 2016] in fact the three lemmas above mult_comm are directly useful [Wed Jan 20 09:13:02 2016] i'd rather not show :D [Wed Jan 20 09:13:14 2016] Is it over 200 lines? [Wed Jan 20 09:13:15 2016] :P [Wed Jan 20 09:13:20 2016] not _yet_ [Wed Jan 20 09:13:25 2016] :P [Wed Jan 20 09:13:25 2016] lol, I know that feeling. [Wed Jan 20 09:13:31 2016] i used 3 lemma's for it :P [Wed Jan 20 09:13:46 2016] additional lemma's i proofed specially for that one [Wed Jan 20 09:13:54 2016] i tried to show that p + n = n + p. [Wed Jan 20 09:14:05 2016] it's pretty obvious [Wed Jan 20 09:14:14 2016] then forall a b c, a + b = a + c -> b = c [Wed Jan 20 09:14:23 2016] and i probably don't need forall there [Wed Jan 20 09:14:25 2016] :\ [Wed Jan 20 09:14:31 2016] You do [Wed Jan 20 09:14:39 2016] You already defined the first one in a previous SF chapter I think. [Wed Jan 20 09:14:39 2016] then i came to S b = S c -> b = c [Wed Jan 20 09:14:42 2016] Called plus_comm. [Wed Jan 20 09:15:03 2016] but for mult_comm. You need to do an induction on n or m. And then just use some rewrites [Wed Jan 20 09:15:18 2016] oh maybe another induction on something you assert [Wed Jan 20 09:15:42 2016] oops, i used induction [Wed Jan 20 09:15:49 2016] and i don't supposed to [Wed Jan 20 09:15:52 2016] ? [Wed Jan 20 09:16:05 2016] just re-read the exercise text for the plus_swap [Wed Jan 20 09:16:29 2016] yes, you can just do a rewrite with plus_comm [Wed Jan 20 09:16:30 2016] i guess i'll look around for the relevant lemmas :P [Wed Jan 20 09:16:39 2016] Good luck [Wed Jan 20 09:16:54 2016] use `Search` [Wed Jan 20 09:16:59 2016] thanks! [Wed Jan 20 09:17:23 2016] if you want to search for lemmas with plus and mult, `Search plus mult` [Wed Jan 20 09:17:41 2016] should it work like full text search? [Wed Jan 20 09:18:00 2016] What do you mean? [Wed Jan 20 09:18:16 2016] For SearchAbout, "plus" doesn't match "plus_foobar" [Wed Jan 20 09:18:23 2016] I don't know about Search. [Wed Jan 20 09:18:30 2016] SearchAbout is deprecated i think [Wed Jan 20 09:18:34 2016] good to know. [Wed Jan 20 09:18:43 2016] i see SearchAbout in proof general [Wed Jan 20 09:18:49 2016] was it deprecated in 8.5? [Wed Jan 20 09:18:58 2016] Nik05: nvm [Wed Jan 20 09:19:39 2016] uh maybe its not deprecated... I thought i saw it somewhere [Wed Jan 20 09:21:32 2016] SearchAbout works kinda strange [Wed Jan 20 09:21:52 2016] i see all kinds of definitions whatever i search about [Wed Jan 20 09:22:46 2016] it says: "SearchAbout (ex "eq_" eq -bool) (default nil):" [Wed Jan 20 09:22:55 2016] i enter "eq_" and get a warning [Wed Jan 20 09:23:10 2016] The reference eq_ was not found [Wed Jan 20 09:23:11 2016] i have to go, see you later and good luck [Wed Jan 20 09:23:25 2016] Nik05: good luck. see you [Wed Jan 20 09:24:17 2016] dredozubov, you can't search for incomplete names [Wed Jan 20 09:24:19 2016] though [Wed Jan 20 09:24:26 2016] (a = b) is just a notation for (eq a b) [Wed Jan 20 09:24:40 2016] so searching for "eq" will show you everything that deals with an "eq" at somepoint [Wed Jan 20 09:24:41 2016] it looks like i was searching for C-c C-f [Wed Jan 20 09:24:59 2016] i can do C-c C-f nat [Wed Jan 20 09:25:11 2016] and i'm getting pretty much what i was expecting to see [Wed Jan 20 09:25:53 2016] rrika: i'm not sure how "=" notation is relevant here [Wed Jan 20 09:26:34 2016] > i enter "eq_" and get a warning [Wed Jan 20 09:26:52 2016] I thought you were looking for things relating to "=" [Wed Jan 20 09:27:10 2016] nope, i just entered what was suggested in the prompt [Wed Jan 20 09:27:16 2016] > it says: "SearchAbout (ex "eq_" eq -bool) (default nil):" [Wed Jan 20 09:27:34 2016] * misunderstood [Wed Jan 20 09:27:45 2016] no worries [Wed Jan 20 09:28:18 2016] oh! [Wed Jan 20 09:28:24 2016] C-c C-t is cool [Wed Jan 20 09:28:46 2016] oh, cool [Wed Jan 20 09:28:59 2016] it shows the whole proof context [Wed Jan 20 09:31:05 2016] what does it do? [Wed Jan 20 09:31:32 2016] i guess it shows all the definitions in the current scopw [Wed Jan 20 09:31:35 2016] scope* [Wed Jan 20 09:32:51 2016] Command: proof-ctxt [Wed Jan 20 09:32:52 2016] Show the current context. [Wed Jan 20 09:33:00 2016] Oke, now im really gone. Bye :P [Wed Jan 20 13:23:08 2016] hey all [Wed Jan 20 13:23:17 2016] I have a question about an odd behavior in my proof [Wed Jan 20 13:25:08 2016] lingxiao post the question :) [Wed Jan 20 13:25:27 2016] yup here;s the code [Wed Jan 20 13:25:27 2016] http://lpaste.net/150320 [Wed Jan 20 13:25:40 2016] the problem is the Theorem pathIndependence at the bottom [Wed Jan 20 13:26:17 2016] so I have intros b. destruct b as [|b'|b']. reflexivity. reflexivity. reflexivity. Qed [Wed Jan 20 13:26:23 2016] on the third reflexivity I'm getting [Wed Jan 20 13:26:32 2016] Toplevel input, characters 0-11: [Wed Jan 20 13:26:32 2016] Error: Impossible to unify "1 + bin_un (Odd b')" with [Wed Jan 20 13:26:33 2016] "bin_un (incr_bin (Odd b'))". [Wed Jan 20 13:26:43 2016] even though it's bascially the same as the other two cases [Wed Jan 20 13:26:45 2016] what gives? [Wed Jan 20 13:27:18 2016] Where you try "reflexivity", you can try to do "simpl" first, just to see which terms you are trying to unify [Wed Jan 20 13:28:13 2016] In that case, you want to prove that "bin_un (incr_bin b') + bin_un (incr_bin b')" and "S (S (bin_un b' + bin_un b'))" are equal. [Wed Jan 20 13:29:27 2016] Now you can see that you need some kind of relation between "bin_un (incr_bin b')" and "bin_un b'" to prove that. So maybe a simple "destruct b" at the beginning of the proof won't be enough [Wed Jan 20 13:30:57 2016] yes use induction hypothesis and rewrite S S (a + b) to S a + S b [Wed Jan 20 13:35:01 2016] ok let me try tthat [Wed Jan 20 14:06:11 2016] lingxiao working? [Wed Jan 20 14:07:35 2016] actually no [Wed Jan 20 14:07:47 2016] but if i changed the definition of bin_un a little it does [Wed Jan 20 14:07:59 2016] not sure why exactly, i have some vague notions [Wed Jan 20 14:09:09 2016] like t his: [Wed Jan 20 14:09:09 2016] http://lpaste.net/150321 [Wed Jan 20 14:09:35 2016] introduce the function double, then it works [Wed Jan 20 14:10:07 2016] so in [bin_un] we have [Even n' => double (bin_un n')] instead of [Even n' = bin_un n' + bin_un n'] [Wed Jan 20 14:10:18 2016] but addition is also inductively defind [Wed Jan 20 14:13:15 2016] Nik05 I don't know if you might elucidate? [Wed Jan 20 14:18:24 2016] that is how I would do it using the original definiton of [bin_un] with [Even n' = bin_un n' + bin_un n'] insetad [Wed Jan 20 14:48:59 2016] lingxiao: http://lpaste.net/150326 [Wed Jan 20 14:52:34 2016] thanks Cale! I'll take alook! [Wed Jan 20 16:44:53 2016] the R type only really works propositionally, right? [Wed Jan 20 16:47:14 2016] oh, Rle_dec is what I was looking for [Wed Jan 20 17:10:43 2016] finally proved plus_comm [Wed Jan 20 17:10:49 2016] had to cheat a little [Wed Jan 20 17:11:11 2016] correct lemma formulation wasn't so obvious [Wed Jan 20 17:11:53 2016] you don't really need inversion to prove this theorem [Wed Jan 20 18:26:28 2016] dredozubov what do you mean with lemma formulation? a + b -> b + a? [Wed Jan 20 18:29:04 2016] we discussed the proof of mult_comm earlier [Wed Jan 20 18:29:41 2016] you were saying that inversion would be helpful [Wed Jan 20 18:30:58 2016] in the end i managed not to use it [Wed Jan 20 18:31:06 2016] that's all i'm saying :) [Wed Jan 20 18:37:07 2016] oke [Wed Jan 20 18:38:35 2016] dredozubov i used lemma's mult_l_0 and mult_a_Sb : a * S b = a + a * b [Wed Jan 20 18:39:36 2016] and in the latter i used plus_swap [Wed Jan 20 18:40:27 2016] jgross_: ping [Wed Jan 20 18:59:05 2016] dredozubov, nice [Wed Jan 20 22:25:23 2016] johnw: pong [Thu Jan 21 01:02:46 2016] jgross_: hi! [Thu Jan 21 08:05:49 2016] how does the coq kernel implement conversion checking? normalizing in call-by-value style? [Thu Jan 21 08:06:34 2016] there are several reduction machines, afaik [Thu Jan 21 08:06:44 2016] but it computes the strong normal form, in any case [Thu Jan 21 08:09:39 2016] how do you control which one is used? [Thu Jan 21 08:10:01 2016] http://gallium.inria.fr/blog/coq-eval/ [Thu Jan 21 08:10:27 2016] (otherwise I don't really know, sorry) [Thu Jan 21 08:11:07 2016] that talks about explicitly computing or evaluating stuff not what the core typechecker is doing [Thu Jan 21 08:13:05 2016] well it's the same mechanisms [Thu Jan 21 08:20:27 2016] but since there's more than one it doesn't tell me which one is actually used, by default at least :) [Thu Jan 21 10:41:05 2016] johnw: hi! Most responses of mine will be delayed, since I'm at POPL. [Thu Jan 21 11:17:23 2016] jgross_ oh all the way in India, cool at Tata [Thu Jan 21 12:48:59 2016] Nik05: POPL is in Florida this year [Thu Jan 21 12:50:06 2016] oh johnw :P [Thu Jan 21 12:50:19 2016] oh right its 2016... [Thu Jan 21 14:21:13 2016] heh, you get to know all the exciting things first hand [Thu Jan 21 14:58:18 2016] Is there a fast way to run coq in the browser? [Thu Jan 21 14:58:54 2016] I've seeen this: https://x80.org/rhino-coq/ is there a faster way too? [Thu Jan 21 14:59:19 2016] Like implementing some bytecode directly in JS instead of using the ocaml to js thing [Thu Jan 21 15:18:24 2016] i'm getting Error: Cannot guess decreasing argument of fix. [Thu Jan 21 15:18:59 2016] dredozubov, can you paste the code somewhere? [Thu Jan 21 15:19:00 2016] is Fixpoint definition gets rewritten with a fix-point combinator and the error is telling me about it? [Thu Jan 21 15:19:19 2016] it looks like i should convince coq that arguments get structurally smaller [Thu Jan 21 15:19:24 2016] any hints? [Thu Jan 21 15:19:30 2016] that's correct [Thu Jan 21 15:20:00 2016] you can define a custom relation that describes which terms are smaller than others [Thu Jan 21 15:20:11 2016] https://gist.github.com/dredozubov/2c686df6ca6c50fc80b7 [Thu Jan 21 15:20:16 2016] and then after defining the fixpoint it will ask you to show that each recursive call fulfills that [Thu Jan 21 15:20:32 2016] though if you can show it by structure it will be much easier [Thu Jan 21 15:21:18 2016] hm, yeah, it will be easier if you can avoid swapping the first and second argument [Thu Jan 21 15:21:26 2016] i know the general idea, but it's not obvious how can i do expose that fact [Thu Jan 21 15:21:43 2016] I think even a custom relation doesn't help here since you span multiple arguments [Thu Jan 21 15:22:01 2016] i think it'll require one more argument [Thu Jan 21 15:22:09 2016] dredozubov, you can do without extra argument [Thu Jan 21 15:22:26 2016] each invocation of alternate could add two values to the result [Thu Jan 21 15:22:29 2016] then it can work [Thu Jan 21 15:22:46 2016] good idea [Thu Jan 21 15:23:34 2016] it works now :) [Thu Jan 21 15:24:21 2016] i don't really get what you mean by custom relation though [Thu Jan 21 15:25:03 2016] well, the idea is that the terms to the recursive function get smaller, and that the function eventually terminates [Thu Jan 21 15:25:36 2016] so you can make a "X -> X -> Prop" [Thu Jan 21 15:27:02 2016] (called R) and then show that all chains R a b, R b c, R c d, eventually end in a R x y which can't be fulfilled for any 'y' [Thu Jan 21 15:27:08 2016] that's where it "stops"? [Thu Jan 21 15:27:18 2016] (I'm not sure if I haven't mixed up left and right in this case) [Thu Jan 21 15:27:20 2016] https://coq.inria.fr/library/Coq.Init.Wf.html [Thu Jan 21 15:27:28 2016] Look at "Inductive Acc" [Thu Jan 21 15:27:47 2016] And "Definition well_founded" [Thu Jan 21 15:29:19 2016] interesting [Thu Jan 21 15:29:46 2016] You can read more about it here: http://adam.chlipala.net/cpdt/html/GeneralRec.html [Thu Jan 21 15:30:49 2016] actually, consult a different source, I just found this via google, and it doesn't seem that on-topic after all [Thu Jan 21 15:31:32 2016] i guess i'll get to it, when i'll encounter this problem again in the future [Thu Jan 21 15:31:52 2016] it's interesting to see how different programming becomes with totality restriction :) [Thu Jan 21 15:32:19 2016] The syntax of Fixpoint allows "Fixpoint (arg1:Type1) {XXX} : ReturnType" where XXX can be "struct arg1" if you have a structurally decreasing argument or "wf TheRelation arg1" if you use the custom approach. [Thu Jan 21 15:32:28 2016] that's all I think [Thu Jan 21 15:32:35 2016] oh, coqtop is now colored [Thu Jan 21 15:33:31 2016] can i make a local fixpoint definition within the other fixpoint definition? [Thu Jan 21 15:43:14 2016] is there a shortcut for "Proof. reflexivity. Qed."? [Thu Jan 21 15:43:52 2016] * is copy-pasting it all over the place [Thu Jan 21 15:44:20 2016] I'm copy pasting it too. [Thu Jan 21 15:47:06 2016] dredozubov that is just the beginning of SF :P [Thu Jan 21 15:47:36 2016] i just copy pasted them [Thu Jan 21 15:47:50 2016] or do a replace of Abort :P [Thu Jan 21 15:48:04 2016] /s/Abort/Admitted/ [Thu Jan 21 15:48:28 2016] Admitted will propagate errors in logic ;) [Thu Jan 21 15:48:39 2016] Proof. reflexivity. Qed. will not [Thu Jan 21 15:49:13 2016] JsCert uses Admitted. instead of Qed. to save computation time according to their website. They say that replacing it all by Qed. will still compile. [Thu Jan 21 16:08:10 2016] can i make a local fixpoint definition within the other fixpoint definition? [Thu Jan 21 16:08:27 2016] maybe with "fix fixname arg := body" [Thu Jan 21 16:22:00 2016] dredozubov: do you use Emacs? [Thu Jan 21 16:22:15 2016] he does IIRC [Thu Jan 21 16:22:28 2016] johnw: yes, i am [Thu Jan 21 16:22:51 2016] are you familiar with abbrev? [Thu Jan 21 16:23:18 2016] type "refl" and then C-x a i l, and then type "Proof. reflexivity. Qed." [Thu Jan 21 16:23:28 2016] Now in future when you type "refl.", it will expand to that [Thu Jan 21 16:23:32 2016] (s/Qed./Qed/) [Thu Jan 21 16:25:04 2016] nice tip, thanks [Thu Jan 21 16:25:35 2016] recently switch to emacs from vim, haven't known that [Thu Jan 21 16:25:40 2016] switched* [Thu Jan 21 16:26:08 2016] oh, "." is over-loaded, you'll need to use "refl" and do keep the "Qed." [Thu Jan 21 16:26:11 2016] can't use it without evil-mode now, hehe [Thu Jan 21 16:27:05 2016] I wish there was coq-integration for sublime text [Thu Jan 21 16:27:10 2016] (and that sublime text was open source) [Thu Jan 21 16:30:25 2016] dredozubov: yasnippet is another great way to automate common things you'll type in Coq [Thu Jan 21 16:31:00 2016] i guess i'll play with it tomorrow, too sleepy to try something meaningful now :) [Thu Jan 21 16:34:11 2016] dredozubov: if you want to lose sleep, then check out company-coq :) [Thu Jan 21 20:06:56 2016] all I want for Christmas is for my universe to be consistent [Fri Jan 22 00:32:53 2016] Coq 8.5 is out: https://coq.inria.fr/news/128.html [Fri Jan 22 01:50:00 2016] excellent phrasing from the Coq team [Fri Jan 22 01:57:02 2016] Saizan: how do you mean? [Fri Jan 22 02:18:27 2016] just another Coq joke, nvm [Fri Jan 22 02:32:08 2016] Saizan: in a public place I told my wife that I'm excited that my work pays me to play with Coq [Fri Jan 22 02:32:18 2016] it's hard to remember sometimes [Fri Jan 22 02:34:19 2016] context is everything [Fri Jan 22 02:39:21 2016] when im out and talking about it i generally call it "proof assistant" [Fri Jan 22 02:39:46 2016] or try to say it with a french accident (am not very good at this) [Fri Jan 22 02:40:55 2016] yeah, I call it "proof language" when there are many ears around [Fri Jan 22 03:05:48 2016] johnw: cool, i was wondering if it's possbile to get paid for it :) [Fri Jan 22 03:09:41 2016] johnw: heh, it wasn't a complaint anyhow [Fri Jan 22 11:18:08 2016] I am trying to just work through a concrete case, and I'm having some problems [Fri Jan 22 11:18:42 2016] If I do Definition example_list := A :: B :: nil. (where A and B are already defined) [Fri Jan 22 11:19:08 2016] but now I'm trying to prove a lemma "Lemma directed_ex : directed example_list." [Fri Jan 22 11:19:23 2016] I don't actually bring the body of my example list into scope [Fri Jan 22 11:19:37 2016] and I can't prove anything about it [Fri Jan 22 11:20:47 2016] 'example_list' is still convertible to 'A :: B :: nil', and if you want to explicit that, you can do [unfold example_list.] to replace it by its definition [Fri Jan 22 11:21:29 2016] ah [Fri Jan 22 11:21:56 2016] great, I was trying destruct, but that got me no where [Fri Jan 22 11:23:34 2016] Ah, my example is not even true, oops [Fri Jan 22 11:24:15 2016] This is exactly why I wanted to do a concrete example [Fri Jan 22 13:42:22 2016] in a notation, how do I capture a subexpression? for example, I have: [Fri Jan 22 13:42:24 2016] Notation "X <- A ; B" := (A >>= (fun p => match p with X => B end)). [Fri Jan 22 13:42:28 2016] and I like to be able to write: [Fri Jan 22 13:42:35 2016] (x, y) <- pure (10, 20) ; pure x [Fri Jan 22 13:42:48 2016] but it's telling me that (x, y) must be a name [Fri Jan 22 13:58:39 2016] what happens if you use small letters for the subexpressions? [Fri Jan 22 14:00:19 2016] no difference; why would there have been? [Fri Jan 22 14:06:18 2016] cpitclaudel: after upgrading to github PG, coq 8.5, and the latest melpa package for company-coq, I get an error "Company: Back-end company-coq-master-backend error "Wrong type argument: listp, "is"" with args (candidates ...)" [Fri Jan 22 14:06:23 2016] any idea what's causing that? [Fri Jan 22 14:06:35 2016] if you're still at POPL I can also track you down in person and show you [Fri Jan 22 16:49:42 2016] hey all i have a syntax question [Fri Jan 22 17:52:29 2016] ask away [Fri Jan 22 17:57:51 2016] heh [Fri Jan 22 17:58:15 2016] this buffer is adjacent to #Mandarin, and lingxiao looks like mandarin, and i misinterpreted that as being about linguistic syntax [Sat Jan 23 11:46:22 2016] Can someone explain to me why in [Sat Jan 23 11:46:23 2016] Inductive foobar (x:nat) : nat -> Type := constructor : foobar (S x) (S x). [Sat Jan 23 11:46:36 2016] the first (S x) is a problem (and should be 'x') but the second is not? [Sat Jan 23 12:05:01 2016] the first one is a "parameter" (and must remain the same); the second is an "index" and can vary [Sat Jan 23 12:10:30 2016] Is there some document that focuses on that distinction? [Sat Jan 23 12:12:11 2016] (also do the jscert people have an IRC channel?) [Sat Jan 23 14:09:27 2016] when do I need to start a proof using "Proof."? the docs make it seem like this is always necessary but when I just start typing in tactics after a theorem it seems to work as well [Sat Jan 23 14:11:33 2016] its not necessary afaiu [Sat Jan 23 14:11:51 2016] alright thanks [Sat Jan 23 14:16:12 2016] rrika: Chlipala's book, CPDT, discusses the distinction a fair bit [Sat Jan 23 14:17:07 2016] basically, arguments may vary by constructor, parameters cannot [Sat Jan 23 14:17:49 2016] An explanation that shows what would break if parameters varied would be nice. [Sat Jan 23 14:17:59 2016] I think I have a rough idea by now [Sat Jan 23 15:11:15 2016] rrika: equality would break :) [Sat Jan 23 15:11:57 2016] (eq a b) works as a type, because it fixes 'a' and then provides you with a single constructor that must then simplify to 'eq a a' [Sat Jan 23 15:12:14 2016] if both 'a' and 'b' were fluid, it would be trivial to use eq_refl, and it wouldn't mean anything [Sat Jan 23 15:12:22 2016] Some inductive declarations just want to see the world burn. [Sat Jan 23 15:13:11 2016] for example, if you wrote: "eq_refl x : eq x x", that's trivially satisfiable [Sat Jan 23 15:14:23 2016] but eq A (x : A) : A -> Prop := eq_refl : eq x x, that can only happen if the argument to eq_refl is exactly x [Sat Jan 23 15:16:26 2016] consider this definition: [Sat Jan 23 15:16:30 2016] Inductive eq' A : A -> A -> Prop := eq_refl x : A -> A -> eq' x x. [Sat Jan 23 15:16:39 2016] Compute eq' 10 20. [Sat Jan 23 15:16:42 2016] works without a hitch [Sat Jan 23 15:17:13 2016] sorry, that was a wrong example [Sat Jan 23 15:17:32 2016] err, I have this wrong, never mind me; too early yet :) [Sat Jan 23 15:17:46 2016] I was about to say [Sat Jan 23 15:17:46 2016] Inductive lol {A}: forall (a b:A), Prop := eq : forall x, eq x x. [Sat Jan 23 15:17:48 2016] works [Sat Jan 23 15:19:20 2016] In coq "match" only considers parameters, but in lean you can match both paramters and indices. [Sat Jan 23 15:19:26 2016] That's interesting [Sat Jan 23 15:19:31 2016] rrika: http://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Sat Jan 23 15:23:49 2016] my eq example was completely the wrong one, even :) [Sat Jan 23 15:24:04 2016] the inhabitants may never vary in type [Sat Jan 23 15:24:06 2016] sigh [Sat Jan 23 15:27:46 2016] rrika: actually, the eq example is not entirely wrong: https://gist.github.com/e78da5b9b2cb0597f4e5 [Sat Jan 23 15:28:19 2016] using a parameter, the first argument to eq provides you with information about the argument, since it cannot vary, making the first proof possible; using only arguments, there is not enough information to complete the proof. [Sat Jan 23 15:29:05 2016] I get »The term "x" has type "A" while it is expected to have type "Type"« [Sat Jan 23 15:29:19 2016] Did you forget to copy something above that snippet? [Sat Jan 23 15:29:46 2016] rrika: yes, one moment [Sat Jan 23 15:30:05 2016] add: Set Implicit Arguments. [Sat Jan 23 15:30:20 2016] or put "A" after eq' in the constructor definition [Sat Jan 23 15:31:00 2016] yeah, that's it! [Sat Jan 23 15:31:15 2016] inversion only works with parameters [Sat Jan 23 15:31:32 2016] after destruction, all I know is that I have an "x", but it doesn't relate to the type strongly enough [Sat Jan 23 15:31:50 2016] if inversion introduced indices you could get a proof of existence that's wrong [Sat Jan 23 15:32:05 2016] yes, the index would tell me exactly what the argument *must* be [Sat Jan 23 15:32:10 2016] since it cannot vary [Sat Jan 23 15:32:19 2016] the type informs us about the value [Sat Jan 23 15:32:39 2016] or conversely, the value tells us about the type [Sat Jan 23 15:33:04 2016] with the non-index version, we only know that the value is an inhabitant of that type [Sat Jan 23 15:34:19 2016] oops, I think we're still off the mark [Sat Jan 23 15:34:23 2016] Lemma should_be_true : forall A (x y : A), eq' A x y -> x = y. [Sat Jan 23 15:34:29 2016] that was easily provable just now [Sat Jan 23 15:34:31 2016] :( [Sat Jan 23 15:34:39 2016] and using that, the other proof is easy too [Sat Jan 23 15:34:46 2016] clearly I need to study up on this myself [Sat Jan 23 15:37:04 2016] I was thinking about [Sat Jan 23 15:37:05 2016] Inductive example (x:nat) : nat -> Type := square : forall (y:nat), lol x (y*y). [Sat Jan 23 15:37:39 2016] Where in "example x y" x can be any value, but y can only be the square of a natural number [Sat Jan 23 15:38:28 2016] Maybe the rules try to avoid getting "squareness" proofs because 'y' doesn't cover all nats [Sat Jan 23 15:38:29 2016] while x does [Sat Jan 23 15:39:19 2016] have to run now, rrika. good luck, and sorry if I further confused the issue [Sat Jan 23 15:39:34 2016] ahaha, no worries, thanks for thinking about it too, see ya. [Sat Jan 23 15:39:44 2016] I updated the gist, if you want to play with it further [Sat Jan 23 15:41:50 2016] what does the "birdface operator" ie :> mean? I found https://coq.inria.fr/distrib/current/refman/Reference-Manual026.html#ProgramSyntax but I am not sure how that relates to the use in typeclasses and records. [Sat Jan 23 15:50:03 2016] it's the typeclass and module one :>? [Sat Jan 23 15:50:07 2016] s/it's/isn't [Sat Jan 23 15:50:19 2016] oh, modules is <: [Sat Jan 23 15:50:34 2016] record coercion is :> [Sat Jan 23 15:50:46 2016] I'm unfamiliar with the one you're pointing to [Sat Jan 23 15:51:31 2016] that was just the first link to docs when I searched. I’m actually looking for the one you’re using in coq-haskell [Sat Jan 23 15:51:51 2016] e.g. is_functor :> Functor f; for applicative [Sat Jan 23 15:52:50 2016] ah that looks better https://coq.inria.fr/distrib/current/refman/Reference-Manual021.html [Sat Jan 23 15:53:29 2016] right; given any Applicative, it lets you reference the Functor laws implicitly [Sat Jan 23 15:54:41 2016] alright, thanks [Sat Jan 23 16:20:20 2016] what is =1 in coq-haskell? extensional equality? turns out it’s not that easy to search for that :) [Sat Jan 23 17:12:27 2016] what [Sat Jan 23 17:12:38 2016] how did i install ssreflect [Sat Jan 23 17:26:08 2016] I forgot how I get access to a value of type (0 = n) in "match n with | 0 => (*here*) | S _ => (*don't care*)" [Sat Jan 23 20:23:05 2016] rrika: something like "match n as n0 return n0 = n -> _ with | 0 => fun H : 0 = n => (* ... *) | S n' => fun _ => (* ... *) end eq_refl" [Sat Jan 23 20:24:14 2016] jrw, I found out the hard way x_x [Sat Jan 23 20:24:19 2016] what does return do? [Sat Jan 23 20:24:29 2016] just specify the type of the expression that match will return? [Sat Jan 23 20:24:41 2016] rrika: exactly [Sat Jan 23 20:26:08 2016] the "as n0" part gives a new name for n. then, in the return annotation, n refers to the "unmatched" version, while n0 refers to the matched version, which is different in each case [Sat Jan 23 20:26:41 2016] so the return annotation adds an argument (the match returns a function) that is a proof that the matched and unmatched values are equal. [Sat Jan 23 20:27:11 2016] this is easy to provide, since the argument is type checked in a context where n0 is replaced by n [Sat Jan 23 20:27:15 2016] so eq_refl works [Sat Jan 23 21:54:13 2016] i am martin [Sat Jan 23 21:54:46 2016] in ubuntu 12 virtual machine using ocqml 3.12.1 but install coq 8.0 got error as stated before. [Sat Jan 23 21:54:46 2016] in ubuntu 14, have 8.4pl6 , have error , so i change to ubuntu 12 machine , then have installation error for coq 8.0. [Sat Jan 23 21:54:46 2016] martin@ubuntu:~$ ocaml -version [Sat Jan 23 21:54:46 2016] The OCaml toplevel, version 4.01.0 [Sat Jan 23 21:54:46 2016] martin@ubuntu:~$ coqc -version [Sat Jan 23 21:54:46 2016] coqc: -version: no such file or directory [Sat Jan 23 21:54:46 2016] martin@ubuntu:~$ coqc --version [Sat Jan 23 21:54:47 2016] The Coq Proof Assistant, version 8.4pl6 (December 2015) [Sat Jan 23 21:54:47 2016] compiled on Dec 18 2015 23:12:11 with OCaml 4.01.0 [Sat Jan 23 21:54:48 2016] martin@ubuntu:~$ [Sat Jan 23 21:55:34 2016] i follow [Sat Jan 23 21:55:35 2016] http://www.lix.polytechnique.fr/~barras/mpri/notes/cours007.html [Sat Jan 23 21:55:35 2016] martintesleft: welcome :) [Sat Jan 23 21:55:36 2016] Preuve de programmes fonctionnels - lix.polytechnique.fr [Sat Jan 23 21:55:36 2016] www.lix.polytechnique.fr [Sat Jan 23 21:55:36 2016] Cours 7 Preuve de programmes fonctionnels. Dans ce cours, nous nous intéressons à la spécification et à la preuve de programmes purement fonctionnels. [Sat Jan 23 21:55:36 2016] got error when run in coqtop [Sat Jan 23 21:59:00 2016] martintesleft: it can be helpful to use a pastebin instead of pasting directly in here [Sat Jan 23 21:59:03 2016] so that you don't get kicked [Sat Jan 23 22:00:20 2016] i get it [Sat Jan 23 22:01:11 2016] https://gist.github.com/LovelyYanki/1853a3c6ff4360ef3ca3#file-gistfile1-txt [Sat Jan 23 22:02:40 2016] looking [Sat Jan 23 22:08:56 2016] https://gist.github.com/LovelyYanki/bc4fa5b19b513e6767a8#file-gistfile1-txt [Sat Jan 23 22:09:02 2016] martintesleft: okay, so it looks like that website may be out of date or using a different version of coq than you. but it should be possible to proceed by annotation y to have type Z [Sat Jan 23 22:11:24 2016] martintesleft: actually, try this: https://gist.github.com/wilcoxjay/349557a4e5a9083588df [Sat Jan 23 22:11:31 2016] I just added an "Open Scope Z" to the top [Sat Jan 23 22:15:12 2016] after tried , https://gist.github.com/LovelyYanki/13b9e84fa24904a12b39#file-gistfile1-txt [Sat Jan 23 22:16:45 2016] error at final line generalize (compare_spec x z); destruct (compare x z). [Sat Jan 23 22:16:45 2016] error at final line, generalize (compare_spec x z); destruct (compare x z). [Sat Jan 23 22:17:51 2016] martintesleft: that line should be part of a proof of mem_correct [Sat Jan 23 22:18:24 2016] the page you're following suggests to start the proof with "inductsion s" and then do a few other things before doing the generalize step [Sat Jan 23 22:22:20 2016] martintesleft: have you considered trying a different book? [Sat Jan 23 22:22:32 2016] and also using proof general or coqide instead of raw coqtop? [Sat Jan 23 22:27:50 2016] i do not understand how to do a few other things before doing generalize step [Sat Jan 23 22:30:01 2016] it said to specify an axiom, which axiom? [Sat Jan 23 22:30:24 2016] martintesleft: by "axiom" it meant the hypothesis thing [Sat Jan 23 22:30:29 2016] you got that part just fine [Sat Jan 23 22:31:44 2016] it says to start by induction on s [Sat Jan 23 22:31:55 2016] then finish the first case on your own (it's supposed to be easy) [Sat Jan 23 22:32:08 2016] then in the second case, use the "generalize ..." stuff [Sat Jan 23 22:33:20 2016] https://gist.github.com/LovelyYanki/37871508ff81dfa28685#file-gistfile1-txt [Sat Jan 23 22:34:09 2016] i first run to Hypothesis compare_spec first and then run induction s. [Sat Jan 23 22:34:56 2016] martintesleft: so far so good [Sat Jan 23 22:35:53 2016] martintesleft: from the way the text is written there, it sounds like the author expects you to be able to do the base case by yourself. have you read the rest of the book? [Sat Jan 23 22:37:09 2016] is the Hypothesis compare_spec already written in the page ? or i should write another hypothesis? [Sat Jan 23 22:38:23 2016] martintesleft: just the one on the page [Sat Jan 23 22:38:32 2016] you don't need it for the first case though [Sat Jan 23 22:39:31 2016] do you mean this book Interactive Theorem Proving and Program Development ? [Sat Jan 23 22:41:07 2016] also called coq'art, yeah, that would be one place to start [Sat Jan 23 22:41:16 2016] or https://www.cis.upenn.edu/~bcpierce/sf/current/index.html [Sat Jan 23 22:43:42 2016] i still have not read, i just google verify program in google, then the first page i find is course 007 [Sat Jan 23 22:44:18 2016] is it possible to generate system from verification rules in coq? [Sat Jan 23 22:44:55 2016] is Extraction command for this purpose? [Sat Jan 23 22:45:04 2016] yes, extraction is the usual way [Sat Jan 23 22:45:17 2016] there are more advanced techniques as well, but this is still an active area of research [Sat Jan 23 22:45:49 2016] where can find existing verification rules or do verification myself with tutorials? [Sat Jan 23 22:45:55 2016] martintesleft: if you're just getting started with coq, I highly recommend the software foundations book that I linked above [Sat Jan 23 22:46:26 2016] it has many examples and exercises [Sat Jan 23 22:46:32 2016] that's where I first learned coq [Sat Jan 23 22:46:44 2016] i downloaded all pages of the web, i would like to see and feel the verification rules first [Sat Jan 23 22:47:09 2016] martintesleft: what do you mean by "verification rules"? [Sat Jan 23 22:47:36 2016] yes [Sat Jan 23 22:48:01 2016] are axioms and verification rules the same thing? [Sat Jan 23 22:48:18 2016] I don't know what "verification rules" are, so I'm not sure [Sat Jan 23 22:50:07 2016] i guess something like Theorem is_empty_correct [Sat Jan 23 22:50:26 2016] in the course 0007 [Sat Jan 23 22:51:53 2016] oh okay, is_empty_correct is a theorem, which is a logical statement that you can try to prove in coq [Sat Jan 23 22:52:23 2016] it seems need to translate haskell or ocaml program into coq syntax first, is there any fast method to translate this to coq for verify? [Sat Jan 23 22:52:45 2016] not that I know of [Sat Jan 23 22:53:08 2016] usually because the proof is so hard, it is worth it to rewrite the code from scratch [Sat Jan 23 22:53:14 2016] if verify linux kernel which is c language, how do people do? [Sat Jan 23 22:53:16 2016] to make it as simple and easy to prove as possible [Sat Jan 23 22:53:37 2016] no one has verified linux, but there is https://sel4.systems/ which is a verified kernel [Sat Jan 23 22:53:57 2016] that project uses isabelle/hol, which is a different proof assistant from coq [Sat Jan 23 22:56:00 2016] has anyone here used Isabella/HOL? whats it like? [Sat Jan 23 22:56:05 2016] i know , i see that some post in email list said that there are 1000 people have ability verify system in the world [Sat Jan 23 22:56:34 2016] i am interested in knowing what system they verify. [Sat Jan 23 22:56:47 2016] if not linux, what system they verify? [Sat Jan 23 22:58:42 2016] martintesleft: it is an L4-like microkernel [Sat Jan 23 22:59:56 2016] can we install L4 like microkernel in VMware ? [Sat Jan 23 23:01:18 2016] i feel that Isabella do not have extraction function like in coq, i give up using it [Sat Jan 23 23:02:28 2016] martintesleft: I have never tried to install seL4, so I can't help you there. [Sat Jan 23 23:02:39 2016] isabelle does have extraction, it's just a little different [Sat Jan 23 23:06:56 2016] thank you, i go to have lunch now , see you [Sat Jan 23 23:18:13 2016] cocreature: =1 is extensionally equal, from ssreflect [Sat Jan 23 23:19:00 2016] hey johnw is there anyway to declare variables in a proof? [Sat Jan 23 23:19:17 2016] say my hypothesis is that f (a + b) = f a + f b [Sat Jan 23 23:19:38 2016] and I have as a goal: f ((x + y) + z) = f (x + y) + f (z) [Sat Jan 23 23:19:55 2016] can i say let a = (x+y), let b = z, so we have the goal ? [Sat Jan 23 23:20:22 2016] replace (x+y) with a. [Sat Jan 23 23:20:27 2016] except you'll have to proof that they're equal [Sat Jan 23 23:20:35 2016] lingxiao: if your hypothesis is universally quantified, then [apply H] should work [Sat Jan 23 23:20:50 2016] where H is the name of the hypothesis [Sat Jan 23 23:21:17 2016] unfortnatly no its not, the H here is the inductive hypotheiss [Sat Jan 23 23:21:22 2016] and I tried .. it didnt work [Sat Jan 23 23:21:54 2016] I can't help just now, but tomorrow I can [Sat Jan 23 23:23:26 2016] lingxiao: can you paste the full context somewhere? [Sat Jan 23 23:23:31 2016] yup here it is [Sat Jan 23 23:23:32 2016] http://pastebin.com/ZZHY7rae [Sat Jan 23 23:23:38 2016] lpaste is borken i think [Sat Jan 23 23:23:44 2016] great thank you! [Sat Jan 23 23:24:08 2016] [nonzeros_app] is where I am stuck [Sat Jan 23 23:24:30 2016] after [rewrite -> cons_app_equiv.] I can [simpl.], but that gives me a giant case staement [Sat Jan 23 23:24:35 2016] and I dont know how to reduce that jrw [Sat Jan 23 23:24:56 2016] lingxiao: also, consider the difference in meaning between these two types: [Sat Jan 23 23:25:15 2016] forall x y z a b, f (a + b) = f a + f b -> f ((x + y) + z) = f (x + y) + f (z) [Sat Jan 23 23:25:25 2016] and: forall x y z, (forall a b. f (a + b) = f a + f b) -> f ((x + y) + z) = f (x + y) + f (z) [Sat Jan 23 23:25:38 2016] in what you asked, the latter is what you need, but the former is what you have (I'm guessing) [Sat Jan 23 23:26:00 2016] in Haskell, the second would be called a 'Rank-2 type' [Sat Jan 23 23:27:03 2016] ok, gotta run now :) [Sat Jan 23 23:27:08 2016] lingxiao: that example isn't self contained so I can't step through it, but I don't think you should need cons_app_equiv [Sat Jan 23 23:27:55 2016] should be something like [simpl. rewrite IH. reflexivity.] [Sat Jan 23 23:28:04 2016] for the indutive case [Sat Jan 23 23:28:50 2016] hmm i cant' do [reflexviity] after [rewrite IH] [Sat Jan 23 23:29:15 2016] what's left? [Sat Jan 23 23:29:22 2016] http://pastebin.com/6kZYw3XT [Sat Jan 23 23:29:33 2016] a case statement [Sat Jan 23 23:29:58 2016] acutally this case statement thing has happend sereval times by now [Sat Jan 23 23:31:05 2016] lingxiao: looks to me like you have a bug in the definition of ++ [Sat Jan 23 23:31:08 2016] can you show me? [Sat Jan 23 23:31:51 2016] http://pastebin.com/24Jzmjtq [Sat Jan 23 23:33:20 2016] oh, right. I wasn't actually reading the goal. [Sat Jan 23 23:33:28 2016] :) [Sat Jan 23 23:33:38 2016] the match statement is coming from the nonzeros thing [Sat Jan 23 23:33:52 2016] just [destruct x] and you're done [Sat Jan 23 23:33:56 2016] yeah is there a better def i can give tht'll simplify it? [Sat Jan 23 23:33:59 2016] hmm ok let me see [Sat Jan 23 23:35:20 2016] ahh great thanks!! [Sat Jan 23 23:36:30 2016] may I ask you another question jrw? [Sat Jan 23 23:37:07 2016] it's this one if you have a minute: http://pastebin.com/AD6EXaqM [Sat Jan 23 23:41:57 2016] lingxiao: would you mind pasting the whole file? [Sat Jan 23 23:42:17 2016] yup! [Sat Jan 23 23:42:17 2016] http://pastebin.com/uwvzUhqe [Sat Jan 23 23:42:30 2016] it's way twoars the bottom [Sat Jan 23 23:44:44 2016] okay got it, looking now [Sat Jan 23 23:44:59 2016] thanks! [Sat Jan 23 23:46:21 2016] lingxiao: okay, so your lemma rev_involutive_1 is on the right track, but you're doing induction on l which is inside a rev before its inside the ++ [Sat Jan 23 23:46:35 2016] so in the case when l is cons, you can't really do anything [Sat Jan 23 23:46:58 2016] instead, you can do induction on [rev l] or, even better, generalize your lemma to get rid of the inner rev [Sat Jan 23 23:47:01 2016] and then induct on l [Sat Jan 23 23:48:46 2016] wait so are you saying: rev (l ++ [x]) = [x] ++ rev l? [Sat Jan 23 23:48:58 2016] yep [Sat Jan 23 23:49:00 2016] or indeed [rev (xs ++ ys) = rev ys ++ rev xs] [Sat Jan 23 23:49:10 2016] yep [Sat Jan 23 23:49:10 2016] yeah stuck there too haha ... :( [Sat Jan 23 23:49:18 2016] with [rev_distrb] [Sat Jan 23 23:49:29 2016] okay, well those ones should be pretty easy [Sat Jan 23 23:49:31 2016] lets see [Sat Jan 23 23:50:23 2016] in rev_distrib, you might need to use the lemma app_nil_r [Sat Jan 23 23:50:33 2016] it looks like you got distracted trying to prove that in line [Sat Jan 23 23:51:05 2016] oh man you're right! [Sat Jan 23 23:51:07 2016] it is there ahah [Sat Jan 23 23:51:15 2016] im so sleepy i cant even remember what i read [Sat Jan 23 23:51:24 2016] lingxiao: also, do you have a lemma app_assoc? [Sat Jan 23 23:51:36 2016] yes i do [Sat Jan 23 23:51:52 2016] okay, you'll need that in the induction step of rev_distrib [Sat Jan 23 23:52:04 2016] but otherwise you should be good to go [Sat Jan 23 23:52:07 2016] ahh that's really helpfull let me see [Sat Jan 23 23:52:34 2016] ahh got it! [Sat Jan 23 23:52:34 2016] :D [Sat Jan 23 23:52:37 2016] nice [Sat Jan 23 23:52:45 2016] oh boy it's just a matter of knowing the right lemmas haha [Sat Jan 23 23:52:47 2016] thanks man! [Sat Jan 23 23:54:24 2016] np [Sat Jan 23 23:54:46 2016] lingxiao: this is something that SF does not teach well: how to know when to look for a lemma [Sat Jan 23 23:54:56 2016] whats SF? [Sat Jan 23 23:55:00 2016] software foundations [Sat Jan 23 23:55:05 2016] oh right haha yup [Sat Jan 23 23:55:11 2016] have you gone thru the class? [Sat Jan 23 23:55:13 2016] when I looked at your problem, I didn't solve it because i remembered the right lemmas, but because I was looking for them [Sat Jan 23 23:55:25 2016] yeah, like 5 or 6 years ago now [Sat Jan 23 23:55:37 2016] boy you have a good memory [Sat Jan 23 23:55:42 2016] no! [Sat Jan 23 23:55:52 2016] that's my point [Sat Jan 23 23:56:15 2016] oh ops read the sentence you wrote wrong haha [Sat Jan 23 23:56:52 2016] I feel like SF really teaches you to just grind and not think, and you end up not even noticing the lemma you need was the previous exercise. [Sat Jan 23 23:57:20 2016] yeah im beginning to see that kind of :( makes me wonder if I should go thru it at all [Sat Jan 23 23:57:29 2016] I was hoping to learn type theory actually haha [Sat Jan 23 23:57:53 2016] which Im guessing would not be this course [Sun Jan 24 00:00:15 2016] to be clear, I think SF is awesome and I learned a lot from it [Sun Jan 24 00:00:47 2016] what did you learn if I could ask? [Sun Jan 24 00:00:55 2016] well I learned coq [Sun Jan 24 00:01:08 2016] but it also was a good jumping off point to learn dependent type theory [Sun Jan 24 00:01:22 2016] haha true .. oh good thats what I was hoping to learn [Sun Jan 24 00:01:57 2016] lingxiao: do you know about OPLSS? [Sun Jan 24 00:02:20 2016] no do you mean :Oregon Programming Languages Summer School? [Sun Jan 24 00:02:25 2016] yeah [Sun Jan 24 00:02:35 2016] oo lots of videos i see [Sun Jan 24 00:02:44 2016] yeah, too many to choose from :) [Sun Jan 24 00:02:47 2016] but they're really good [Sun Jan 24 00:02:50 2016] thats really neat thanks! [Sun Jan 24 00:03:09 2016] will def be taking a look! [Sun Jan 24 02:49:37 2016] johnw: thanks for the answer! [Sun Jan 24 11:22:35 2016] Hey, could I impose on someone to add keywords "haspatch maintainer" to https://trac.macports.org/ticket/50428 ? I forgot when I created the ticket. (Or even just apply the patch. :) ) [Sun Jan 24 12:38:19 2016] also, can we close https://trac.macports.org/ticket/22726 ? [Sun Jan 24 16:38:11 2016] Hey guys [Sun Jan 24 16:39:41 2016] Is there a way to get coqc to backtrack through the Requirements in a directory? So, if X.v requires Y.v; I order compilation of X.v; coqc is smart and compiles Y.v first. [Sun Jan 24 16:46:35 2016] oh goddammit [Sun Jan 24 16:46:48 2016] the newest coq doesn't work with sf [Sun Jan 24 16:47:08 2016] or rather, sf doesn't work with the latest version [Sun Jan 24 16:49:43 2016] pharpend: sf hasn't been updated to 8.5, which was just released a few days ago. my guess is that it will be ported sometime in the next year. [Sun Jan 24 16:50:15 2016] pharpend: about dependency tracking, usually people use coqdep and coq_makefile for this [Sun Jan 24 16:51:05 2016] well, it's a moot point now, because silly Arch Linux decided I need the latest version of Coq [Sun Jan 24 16:51:41 2016] you can see an example of coq_makefile at https://github.com/uwplse/verdi/blob/master/core/Makefile [Sun Jan 24 16:52:53 2016] pharpend: I haven't used arch in a year or so, but I wouldn't be surprised if someone has a package for coq 8.4 [Sun Jan 24 16:53:02 2016] is 8.5 really that not backward compatible?! [Sun Jan 24 16:53:06 2016] yep [Sun Jan 24 16:55:32 2016] jrw: I'm emailing Benjamin Pierce, on the off chance 100 other Arch users haven't emailed him already [Sun Jan 24 16:57:26 2016] 100 Coq users that would also be on arch? that's a lot! [Sun Jan 24 16:57:41 2016] I suppose there aren't many Coq users [Sun Jan 24 16:58:17 2016] There are a lot of Arch users, though, it's one of the more popular Linux distributions [Sun Jan 24 16:58:41 2016] I use arch, but have actually Coq installed through opam [Sun Jan 24 16:58:47 2016] hmm [Sun Jan 24 16:59:00 2016] I used to use Gentoo, and I could just impose version locks [Sun Jan 24 16:59:09 2016] I don't have time to compile everything, though [Sun Jan 24 16:59:19 2016] Let me try the opam method [Sun Jan 24 16:59:41 2016] with opam you can install an older version, indeed [Sun Jan 24 17:02:37 2016] looks like 8.5 also broke Coquille :? [Sun Jan 24 17:02:38 2016] :/ [Sun Jan 24 17:04:08 2016] companion_cube: what's that [Sun Jan 24 17:04:18 2016] a small plugin to vim [Sun Jan 24 17:04:33 2016] I found coquillo, which is completely unrelated software [Sun Jan 24 17:04:53 2016] I don't know about Vim, I use Emacs [Sun Jan 24 17:06:12 2016] I use vim, and the Coq ecosystem isn't very supportive :p [Sun Jan 24 17:06:37 2016] ProofGeneral is pretty nice [Sun Jan 24 17:06:43 2016] I could never get around to figuring out CoqIDE [Sun Jan 24 17:07:39 2016] well that's nice, but it requires using emacs... [Sun Jan 24 17:07:49 2016] You can make Emacs usable [Sun Jan 24 17:07:51 2016] same for company-coq, it looks awesome but not for me [Sun Jan 24 17:07:54 2016] it's difficult [Sun Jan 24 17:07:57 2016] but you can [Sun Jan 24 17:08:10 2016] I spent several years doing so; [Sun Jan 24 17:08:27 2016] There are a number of alternate "distributions" of Emacs that are *much* nicer [Sun Jan 24 17:09:00 2016] yeah but vim is in my muscle memory :/ [Sun Jan 24 17:09:04 2016] One of them, spacemacs I think it's called, has all the vim emulation set up out of the box [Sun Jan 24 17:09:33 2016] so all of your muscle memory would be intact. Your vim extensions wouldn't work, but there are more than likely equivalent extensions to Emacs [Sun Jan 24 17:11:01 2016] okay yay! I installed 8.4, everything works again! [Sun Jan 24 17:11:09 2016] :D [Sun Jan 24 17:12:57 2016] The key to having a stable system is to compile everything by hand [Sun Jan 24 17:13:06 2016] otherwise, when you update your software, everything breaks [Sun Jan 24 17:13:22 2016] so if you compile everything by hand, and never update it, you'll be golden [Sun Jan 24 17:14:38 2016] I learned that the hard way back when I used Gentoo, and I foolishly tried to do a system update [Mon Jan 25 11:54:05 2016] pharpend: or use Nix, which only does atomic upgrades, and supports system rollbacks [Mon Jan 25 12:23:10 2016] I want to use Nix more, but Arch Linux is making that difficult -_- [Mon Jan 25 12:23:23 2016] so I've a NixOS VM in QEMU, and Nix on my Macbook [Mon Jan 25 12:51:17 2016] how does arch make it difficult? [Mon Jan 25 12:52:18 2016] johnw: I keep running into https://github.com/NixOS/nix/issues/599 or possibly unrelated issues discussed therein [Mon Jan 25 12:53:24 2016] oh, yuck [Mon Jan 25 12:53:56 2016] some Nix folks had solutions that "should" "work" [Mon Jan 25 12:54:01 2016] but none of it worked right for me [Mon Jan 25 14:38:55 2016] johnw: I've always had trouble with Nix. I tried to use the whole NixOS once, but I had some blocker issue, I can't remember what it was. I haven't tried just-nix-the-package-manager in a while. My memory is, it generally creates problems on Arch [Mon Jan 25 14:39:23 2016] johnw: Although, maybe in my current line of work, I should switch to a different distribution. Arch seems to be causing many problems recently [Mon Jan 25 14:40:57 2016] I've used Arch for the longest time, mostly because when I get a new computer, Arch is the only distribution that supports the hardware, Arch being super up-to-date and all [Mon Jan 25 14:41:20 2016] I've been on my current set of hardware for some months now, so Debian likely supports it [Mon Jan 25 14:41:22 2016] well [Mon Jan 25 14:41:28 2016] Debian unstable, maybe [Mon Jan 25 14:41:38 2016] In 15 years, Debian stable might work [Mon Jan 25 14:46:30 2016] hahaha [Mon Jan 25 14:48:49 2016] Nix & NixOS worked fine for me outside of Arch [Mon Jan 25 14:48:56 2016] and outside of my RasPi which had its own set of issues o_O [Mon Jan 25 15:27:22 2016] I like Nix (the package manager) especially for keeping separate envirnoments around to run Coq 8.4, Coq 8.5, and Coq HEAD [Mon Jan 25 15:27:33 2016] I just start Emacs up inside which environment is relative to the day's work [Mon Jan 25 23:07:07 2016] h3y all [Mon Jan 25 23:07:13 2016] coudl someone help me prove this? [Mon Jan 25 23:07:57 2016] http://lpaste.net/150880 [Mon Jan 25 23:08:24 2016] i know of no tactics of how to reduce the fucntion! [Mon Jan 25 23:13:16 2016] lingxiao: unfold fold_length. maybe? [Mon Jan 25 23:13:52 2016] so what does unfold do? I see it's expanded the def of fold_length [Mon Jan 25 23:13:56 2016] but what is it in principle [Mon Jan 25 23:13:57 2016] ? [Mon Jan 25 23:14:49 2016] it.. unfolds the definitions :D it's just replacing something with its definition [Mon Jan 25 23:16:11 2016] ah great thansk! [Mon Jan 25 23:16:18 2016] maybe i ask you one more question? [Mon Jan 25 23:16:21 2016] I m realy lost here [Mon Jan 25 23:16:50 2016] http://lpaste.net/ [Mon Jan 25 23:16:53 2016] the last therorem [Mon Jan 25 23:25:36 2016] lingxiao: sure, try giving the correct url though :D [Mon Jan 25 23:25:52 2016] http://lpaste.net/150881 [Mon Jan 25 23:25:53 2016] sorry! [Mon Jan 25 23:26:38 2016] what do you want to know? [Mon Jan 25 23:29:31 2016] how to complete the last proof [Mon Jan 25 23:29:50 2016] once the fold_length def is expanded i am stuck [Mon Jan 25 23:33:15 2016] can you give a full file? I'm lacking cons_app_equiv and app_assoc [Mon Jan 25 23:36:23 2016] yup here it is [Mon Jan 25 23:36:24 2016] http://lpaste.net/150882 [Mon Jan 25 23:36:34 2016] however cons_app_equiv may not be needed [Mon Jan 25 23:36:48 2016] I was just flailing about [Mon Jan 25 23:50:39 2016] lingxiao: damn, sorry, it seems my Coq version is not compatible with software foundations, so I'm just going to say how the proof should go on: [Mon Jan 25 23:50:55 2016] the l1 = nil case should be trivial [Mon Jan 25 23:51:24 2016] then you have l1 = h :: q, you should rewrite (l1 ++ l2) ie ((h :: q) ++ l2) in (h :: (q ++ l2)) [Mon Jan 25 23:51:57 2016] that way, you can put 'h' aside using the definition, and use the induction hypothesis on 'q ++ l [Mon Jan 25 23:52:02 2016] on q and l2* [Mon Jan 25 23:52:14 2016] you shouldn't need an induction on l2 [Tue Jan 26 00:07:33 2016] lingxiao: still there? [Tue Jan 26 00:07:43 2016] yup! will try it out now [Tue Jan 26 00:07:45 2016] thank you! [Tue Jan 26 11:32:10 2016] anyone here? [Tue Jan 26 11:45:09 2016] hi lingxiao [Tue Jan 26 11:45:27 2016] hey man I'm super stuck on a proof and I'm wondering if you might help me? [Tue Jan 26 11:45:31 2016] sure [Tue Jan 26 11:47:08 2016] http://lpaste.net/150932 [Tue Jan 26 11:47:12 2016] it's all the way at the bottom [Tue Jan 26 11:47:18 2016] [lemma fold_len_distr] [Tue Jan 26 11:47:37 2016] now the final goal is to prove [fold_length_correct], so if we can do it w/o the lemma it's also ok [Tue Jan 26 11:47:41 2016] hold brb moving computer [Tue Jan 26 12:04:04 2016] back [Tue Jan 26 12:04:31 2016] evaluating this is the sf directory, I get "Error: Unknown interpretation for notation "_ && _"." [Tue Jan 26 12:04:38 2016] not sure what's going on, and I'm a bit short on time [Tue Jan 26 12:05:31 2016] no its all good! [Tue Jan 26 12:06:57 2016] ah, I was able to skip it [Tue Jan 26 12:09:59 2016] lingxiao: https://gist.github.com/e2f2a45005af3b74b860 [Tue Jan 26 12:12:14 2016] johnw thanks! I'll take a look at it now!! [Tue Jan 26 12:14:03 2016] lingxiao: the reason I unfolded is that you don't have any helper lemmas defined in terms of fold_length, the definition of fold_length is trivial, and we want simplification to result in terms of the same "shape" as the induction hypothesis [Tue Jan 26 12:14:42 2016] higher level definitions are very convenient, but never feel obligation to prove things in terms of them [Tue Jan 26 12:16:15 2016] when it says [unfold fold_length in *.] [Tue Jan 26 12:16:19 2016] what is the [*] [Tue Jan 26 12:16:31 2016] "unfold it everywhere" [Tue Jan 26 12:16:31 2016] does that mean pattern match for fold_length whereever it appears? [Tue Jan 26 12:16:34 2016] ahh ok [Tue Jan 26 12:16:43 2016] yeah I was trying to do that lol [Tue Jan 26 12:16:49 2016] my vocab is very limited in coq ahha [Tue Jan 26 12:17:22 2016] ahh it worked! [Tue Jan 26 12:17:23 2016] thanks man! [Tue Jan 26 12:17:33 2016] learned a new tactic today [Tue Jan 26 12:31:14 2016] If I have a inductive typing rule for a language [Tue Jan 26 12:31:35 2016] and I want to have a proposition for "the typing rule doesn't contain downcasts" [Tue Jan 26 12:31:46 2016] what would be the cleanest way to write that? [Tue Jan 26 12:32:31 2016] I could make a new inductive type over expressions, just without those rules, and a projecting into the more permissive typing rules [Tue Jan 26 12:32:46 2016] or I could make a proposition over typing rules [Tue Jan 26 12:38:03 2016] And I have a similar thing were I want to extend the expression language with a new term LIB, and have some lemmas relating the evaluation of the two [Tue Jan 26 12:38:14 2016] I could make a separate inductive type [Tue Jan 26 12:38:27 2016] but that sounds like I'd need to write all the proofs again [Tue Jan 26 12:38:39 2016] and all the typing rules too [Tue Jan 26 12:38:51 2016] which doesn't sound fun [Tue Jan 26 12:38:55 2016] tbelaire: it's called "the expression problem" [Tue Jan 26 12:38:59 2016] see much research :) [Tue Jan 26 12:39:09 2016] Thanks, now I know what to google [Tue Jan 26 12:39:11 2016] there are ways to build compositional expression languages [Tue Jan 26 12:39:24 2016] tbelaire: for example: https://www.google.com/search?q=data%20types%20a%20la%20carte [Tue Jan 26 12:39:43 2016] nice [Tue Jan 26 12:39:45 2016] thanks [Tue Jan 26 12:40:53 2016] :D [Tue Jan 26 12:54:27 2016] tbelaire: also note that while the Free monad won't work in Coq, the Freer monad will (see the Free I define in coq-haskell, which is actually Freer) [Tue Jan 26 12:54:50 2016] okay [Tue Jan 26 13:13:18 2016] I am working off an existing formalization of featherweight java, so translating everything into the freer monad is a bit more invasive than I'd like [Tue Jan 26 13:13:23 2016] I have another idea [Tue Jan 26 13:13:46 2016] But I have a feeling it might be too clever for it's own good [Tue Jan 26 13:14:21 2016] extend my expression type with a parameter a, then have the lib constructor take an a [Tue Jan 26 13:14:58 2016] to get the version of expr without lib, we pass False in as a, so you can never construct a lib expr [Tue Jan 26 13:15:09 2016] and with lib pass in () [Tue Jan 26 13:53:52 2016] you could certainly make your expr language conditional [Tue Jan 26 14:18:16 2016] I'm a little afraid of the aphorism "Debugging is always harder than coding. If are as clever as you can be when writing your code, how will you debug it?" [Tue Jan 26 14:18:36 2016] But I think I'll give it a try and see how that works [Wed Jan 27 12:06:33 2016] hey is anyone around? [Wed Jan 27 12:07:32 2016] ping connection [Wed Jan 27 12:10:32 2016] Pong [Wed Jan 27 12:12:21 2016] sweet! [Wed Jan 27 12:12:32 2016] I am stuck on a proof, I am wondering if you might be of some help? [Wed Jan 27 12:12:33 2016] :) [Wed Jan 27 12:13:05 2016] Depends on how much context I'd need to consume. If you're in a CompCert proof, I can't help you. [Wed Jan 27 12:14:07 2016] huh? im guesing not haha [Wed Jan 27 12:14:21 2016] but here it is [Wed Jan 27 12:14:23 2016] https://github.com/lingxiao/CIS500/blob/master/hw2/Induction.v [Wed Jan 27 12:14:35 2016] line 647, but you only have to read a few lines to figure out what's going on [Wed Jan 27 12:15:16 2016] You at UPenn? [Wed Jan 27 12:16:43 2016] yup [Wed Jan 27 12:16:48 2016] acgtually that link is out of data [Wed Jan 27 12:16:50 2016] date* [Wed Jan 27 12:16:59 2016] or er it should be up to date if you refresh it [Wed Jan 27 12:17:27 2016] ianjneu did you go here? [Wed Jan 27 12:18:27 2016] lingxia__: no, I got my PhD at Northeastern. We're good friends with UPenn. [Wed Jan 27 12:18:48 2016] I know "CIS" is the course prefix at UPenn too. [Wed Jan 27 12:18:49 2016] oh nice that makes us best of buddies then haha [Wed Jan 27 12:19:02 2016] yeah its either that or CS, are the two that I know of [Wed Jan 27 12:20:31 2016] Sorry, but this is a bit too much to consume to help with while at work. I have to leave in 10 too. I'll give it a go until then. [Wed Jan 27 12:21:46 2016] ok great thanks for even considering ! [Wed Jan 27 12:40:20 2016] lingxiao: try "forall b, bin_un' b = bin_un b", "forall b, un_bin (bin_un (incr_bin b)) = incr_bin (un_bin (bin_un b))" [Wed Jan 27 12:42:53 2016] i'km sorry how does [un_bin (bin_un (incr_bin b)) = incr_bin (un_bin (bin_un b))] come into play in [bin_un_norm_roundrip] [Wed Jan 27 12:43:15 2016] btw the assetion is really: [forall b : bin, un_bin (bin_un' b) = normalize b.] [Wed Jan 27 13:31:53 2016] hey all [Wed Jan 27 13:32:04 2016] true by definiition [Wed Jan 27 13:32:15 2016] how would i say in a proof that something is true by defnitiion [Wed Jan 27 13:34:08 2016] actually nvm [Wed Jan 27 13:40:37 2016] cool 8.5 is out already [Wed Jan 27 14:04:22 2016] just got into debian [Wed Jan 27 22:22:55 2016] does anyone know of performance comparisons between different combinations of {explicit substitutions, hash consing, memoization, etc} for typechecking? [Thu Jan 28 03:21:36 2016] dependent types are driving me nuts [Thu Jan 28 03:21:58 2016] eh [Thu Jan 28 03:22:13 2016] for example, I can prove this easily: [Thu Jan 28 03:22:14 2016] forall (Heqe : x = y), H = rew <- Heqe in J -> existT P x H = existT P y J. [Thu Jan 28 03:22:25 2016] but the existence of "rew <- Heqe" in there is causing me enormous difficult [Thu Jan 28 03:22:29 2016] y [Thu Jan 28 03:22:47 2016] because H is dependent on x, and J is dependent on y [Thu Jan 28 03:23:57 2016] basically I want an f_equal3 that works on existT [Thu Jan 28 03:26:41 2016] What do you mean by 'the existence of "rew <- Heqe"'? [Thu Jan 28 03:26:58 2016] I start from a goal of existT P x H = existT P y [Thu Jan 28 03:27:06 2016] now I have to prove H = rew <- Heqe in J [Thu Jan 28 03:27:11 2016] not sure how to do that [Thu Jan 28 03:30:54 2016] I guess it depends on H and J. You certainly cannot prove that in general, can you? [Thu Jan 28 03:31:23 2016] well, in my current case, J = fmap id H [Thu Jan 28 03:32:51 2016] anyway, I'm trying to prove that a certain sigT is a functor [Thu Jan 28 03:32:59 2016] and this dependency is stopping me cold [Thu Jan 28 03:33:32 2016] it's like "dependent equality", if that makes sense [Thu Jan 28 03:35:11 2016] oh, hey, EqdepFacts uses the same trick in eq_dep1_dep [Thu Jan 28 03:35:19 2016] so maybe I'm not too far off the rails [Thu Jan 28 10:11:51 2016] hey all [Thu Jan 28 10:11:57 2016] is anyone around and would liek to help me with a couple of questions? [Thu Jan 28 10:59:47 2016] lingxiao, ask head [Thu Jan 28 11:00:36 2016] great! [Thu Jan 28 11:00:38 2016] https://github.com/lingxiao/CIS500/blob/master/hw3/Poly.v [Thu Jan 28 11:00:58 2016] search for [exp (n m : nat)] all the way at the bottom [Thu Jan 28 11:01:08 2016] its basically exponentitation in church numuerals [Thu Jan 28 11:01:17 2016] this one's really grinding me rrika [Thu Jan 28 11:14:04 2016] lingxiao, I see [Thu Jan 28 11:14:07 2016] I'm suprised though [Thu Jan 28 11:14:15 2016] that your definition of exp does not build upon "mult" [Thu Jan 28 11:14:15 2016] how so? [Thu Jan 28 11:14:24 2016] oh i tried that one too [Thu Jan 28 11:14:26 2016] but no good [Thu Jan 28 11:14:44 2016] I think you should try that again [Thu Jan 28 11:15:09 2016] was this at one point [Definition exp (n m : nat) : nat := fun X f x => m X ((mult n n) X f) x. ] [Thu Jan 28 11:15:24 2016] which makes no sense since I imeidately get mult n n [Thu Jan 28 11:15:46 2016] i could do [m X f (somewith mult n) ] [Thu Jan 28 11:15:48 2016] ah you need a lamdba [Thu Jan 28 11:15:56 2016] m X (fun … somethingmult) … [Thu Jan 28 11:16:19 2016] basically [Thu Jan 28 11:16:24 2016] 3^5 = [Thu Jan 28 11:16:35 2016] times3 (times3 (times3 (times3 ( 3 ) ) ) ) [Thu Jan 28 11:16:44 2016] And times3 takes an argument [Thu Jan 28 11:17:04 2016] which is the argument to the fun that you apply "m X" to [Thu Jan 28 11:17:21 2016] "times_n" would be more accurate [Thu Jan 28 11:22:24 2016] lingxiao, I gotta go, I'll be back in a few hours [Thu Jan 28 11:22:33 2016] maybe see if "m N … one" gets you anywhere [Thu Jan 28 11:22:36 2016] great thanks! [Thu Jan 28 11:22:44 2016] I'll keep trying [Thu Jan 28 11:22:55 2016] (I tried this but got a "universe inconsistency" so IDK) [Thu Jan 28 11:27:13 2016] I'm currently passing a "flag : Set" into my datastructure to enable/disable a particular case, by passing Empty_set or unit [Thu Jan 28 11:27:30 2016] is there a way to constrain the flag to only being one or the other, and not any set? [Thu Jan 28 11:30:33 2016] I would try an inductive type, but I don't see how it would work [Thu Jan 28 11:36:48 2016] is there some way of making coq not write ... when printing too long lines? [Thu Jan 28 11:39:07 2016] nvm, Set Printing Depth seems to be what I'm looking for [Thu Jan 28 18:11:20 2016] hey is someone around? [Thu Jan 28 19:04:14 2016] lingxi___: someone is always here :) [Thu Jan 28 20:05:00 2016] lingxiao are you at the church numerals? [Thu Jan 28 20:05:47 2016] oh isnt here [Thu Jan 28 20:06:20 2016] but exp := λm.λn.n m [Thu Jan 28 20:10:25 2016] im going to do rel.v tomorrow i think [Thu Jan 28 20:10:44 2016] but first i need to read a little anout sets and relations [Fri Jan 29 07:41:05 2016] :q [Fri Jan 29 07:41:31 2016] that was obviously not intended for this channel [Sat Jan 30 08:20:50 2016] What to do with Anomaly: File "stm/stm.ml", line 1860, characters 53-59: Assertion failed. [Sat Jan 30 08:21:00 2016] Please report. ? [Sat Jan 30 08:26:38 2016] im using the latest Coq [Sat Jan 30 09:03:29 2016] Nik05: https://coq.inria.fr/bugs/ [Sat Jan 30 09:19:53 2016] thank you sgnb [Sun Jan 31 03:52:29 2016] if you model coq in coq, can you prove that LEM is not a theorem of the model [Sun Jan 31 03:52:53 2016] (i'm using model as an english word, not as in model theory) [Sun Jan 31 17:47:37 2016] does anyone know where i can find the terms (just syntax) of CIC written out symbolically e.g. t := Prop | Set | Type | .... ? I see 4.1.3. of http://flint.cs.yale.edu/cs428/coq/doc/Reference-Manual006.html#Cic but I'd rather have a formal definition [Sun Jan 31 18:39:23 2016] Talia: Is appendices A.1 and A.2 of the HoTT Book (http://homotopytypetheory.org/book/) what you're looking for? [Sun Jan 31 18:51:16 2016] Hello to all! I'm having a little trouble in how to import a (compiled) file. I'm formalizing some stuff and, for organization, I've put some files in separate folders, like Data, Tactics and Functions, all in the same root directory. How can use a file in Data folder in a file in Functions folder? [Mon Feb 1 11:51:44 2016] Is there a nice way to get a Type consisting of two Sets, one being isomorphic to unit and the other to emptyset? [Mon Feb 1 11:52:40 2016] tbelaire: well, coq's type system doesn't do subtyping [Mon Feb 1 11:52:51 2016] what do you mean by a type consisting of two sets exactly [Mon Feb 1 11:59:26 2016] tbelaire : do you mean something like "unit + Empty"? Problem is that this type is isomorphic to unit, of course. [Mon Feb 1 11:59:38 2016] Yeah [Mon Feb 1 12:00:03 2016] I wanted to help the inference of my implicit parameters [Mon Feb 1 12:00:12 2016] when it could only be one or the other [Mon Feb 1 12:00:43 2016] maybe a typeclass then? with just those two instances? not sure if it actually helps [Mon Feb 1 12:01:00 2016] https://gist.github.com/tbelaire/b77620217d543134bf0c [Mon Feb 1 12:01:23 2016] I haven't touched typeclasses in Coq yet... [Mon Feb 1 12:01:41 2016] I guess I want True + False [Mon Feb 1 12:01:54 2016] so, Bool instead of bool [Mon Feb 1 12:02:00 2016] if that makes any sense [Mon Feb 1 12:02:11 2016] (I meant "unit + Empty_set" above, not Empty) [Mon Feb 1 12:48:03 2016] Cypi: [unit + Empty_set] is wrong, the elements are elements of the types, not the types themselves [Mon Feb 1 12:50:12 2016] So... {S : Set | S = unit \/ S = Empty_set}? That looks very strange. Well, nevermind, I'm not sure I understand the problem anyway [Mon Feb 1 12:52:54 2016] Cypi: that's what i would've answered if my goal were to get instant "yeah i think that's what I'm looking for", but i doubt it's what tbelaire was looking for [Mon Feb 1 12:53:32 2016] Well, that's actually reasonable, I think [Mon Feb 1 12:53:49 2016] lets see if it fixes the inference problems I've been having [Mon Feb 1 12:54:59 2016] tbelaire: unit : that_type will not check [Mon Feb 1 12:55:09 2016] yeah [Mon Feb 1 12:55:20 2016] I don't mind wrapping it [Mon Feb 1 12:55:32 2016] there's probably a better way to accomplish whatever you're doing :v [Mon Feb 1 12:55:51 2016] That's a common feeling for all my work in Coq [Mon Feb 1 12:55:59 2016] :) [Mon Feb 1 12:56:13 2016] also, if I do Definition HasLib : Type := (*the above*). [Mon Feb 1 12:56:35 2016] I'm getting an error when I try and take it as a constructor argument [Mon Feb 1 12:56:37 2016] with The term "with_lib" has type "HasLib" which should be Set, Prop or Type. [Mon Feb 1 12:57:12 2016] when with_lib : HasLib [Mon Feb 1 12:57:29 2016] oh, wait okay, I get it [Mon Feb 1 12:57:33 2016] told you :P [Mon Feb 1 12:57:45 2016] HasLib is an element of Type, not Type itself [Mon Feb 1 12:57:47 2016] okay [Mon Feb 1 12:57:48 2016] tbelaire: hold on, why are you using it as a constructor argument [Mon Feb 1 12:57:49 2016] yeah [Mon Feb 1 12:57:58 2016] The gist from above [Mon Feb 1 12:58:03 2016] * scrolls up [Mon Feb 1 12:58:25 2016] I've trying to have a particular expression statically ruled out [Mon Feb 1 12:58:46 2016] since I don't want to have two parallel types and repeat allllll the proofs again [Mon Feb 1 12:59:15 2016] tbelaire: why don't you do this: [Mon Feb 1 12:59:24 2016] er, 1 second [Mon Feb 1 12:59:26 2016] sure [Mon Feb 1 12:59:50 2016] oh wait shit [Mon Feb 1 12:59:54 2016] nvm x_X [Mon Feb 1 12:59:59 2016] tbelaire: well, why not just use bool? [Mon Feb 1 13:00:22 2016] how? [Mon Feb 1 13:00:35 2016] I want True + False, not true + false [Mon Feb 1 13:00:40 2016] replace [{with_lib : Set}] with [{with_lib : bool}] [Mon Feb 1 13:00:47 2016] then replace [Mon Feb 1 13:00:49 2016] | tm_lib : with_lib -> tm_helper [Mon Feb 1 13:00:51 2016] with [Mon Feb 1 13:00:59 2016] ooooh [Mon Feb 1 13:01:01 2016] ight [Mon Feb 1 13:01:02 2016] | tm_lib : (if with_lib then unit else False_set) -> tm_helper [Mon Feb 1 13:01:03 2016] this is not haskell [Mon Feb 1 13:01:06 2016] :) [Mon Feb 1 13:01:13 2016] or even: [Mon Feb 1 13:01:18 2016] | tm_lib : tm_helper true [Mon Feb 1 13:01:28 2016] that works [Mon Feb 1 13:01:30 2016] yeah [Mon Feb 1 13:01:33 2016] dang [Mon Feb 1 13:01:34 2016] oh, er [Mon Feb 1 13:01:42 2016] trying it [Mon Feb 1 13:01:44 2016] that would require that with_lib be an argument, not an index [Mon Feb 1 13:02:02 2016] s/argument/parameter [Mon Feb 1 13:02:51 2016] ? [Mon Feb 1 13:03:20 2016] do you know the difference between parameters and indices in an inductive type definition? [Mon Feb 1 13:03:27 2016] no [Mon Feb 1 13:03:29 2016] hoo bo [Mon Feb 1 13:03:31 2016] y [Mon Feb 1 13:03:41 2016] i'm not sure i'm the best person to explain since I only 75% understand them myself [Mon Feb 1 13:03:45 2016] but basically [Mon Feb 1 13:03:45 2016] I'll read something if you've got a reference [Mon Feb 1 13:03:51 2016] let me google =p [Mon Feb 1 13:03:53 2016] indices may vary across constructors, parameters may not [Mon Feb 1 13:04:09 2016] johnw: i don't think that's a very helpful intro [Mon Feb 1 13:04:11 2016] this affects the inversion tactic, for example [Mon Feb 1 13:04:28 2016] okay [Mon Feb 1 13:04:30 2016] reading http://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Mon Feb 1 13:04:56 2016] Yes, I want to index [Mon Feb 1 13:05:28 2016] tbelaire: syntactically speaking, [Inductive foo (bar : X) : Type] declares a parameter, while [Inductive foo : X -> Type] declares an index [Mon Feb 1 13:05:39 2016] cool [Mon Feb 1 13:06:00 2016] tbelaire: if you do the former, the result type of each of your constructors /must/ use 'bar' [Mon Feb 1 13:06:03 2016] like so: [Mon Feb 1 13:06:18 2016] Inductive foo (bar : int) : Type := foo_con : foo bar. [Mon Feb 1 13:06:22 2016] this is invalid: Inductive foo (bar : int) : Type := foo_con : foo 3. [Mon Feb 1 13:06:38 2016] otoh, indices may be filled in with anything in scope of the type expression [Mon Feb 1 13:06:40 2016] Can I do a forall? [Mon Feb 1 13:06:50 2016] yeah, this is fine: [Mon Feb 1 13:07:05 2016] wait [Mon Feb 1 13:07:09 2016] tbelaire: that depends on what you mean [Mon Feb 1 13:07:11 2016] can you be more specific [Mon Feb 1 13:07:19 2016] | tm_false : forall b: bool, tm_helper b [Mon Feb 1 13:07:23 2016] kinda deal [Mon Feb 1 13:07:31 2016] which looks like it's working [Mon Feb 1 13:07:41 2016] yes, that's fine as long as the first argument to tm_helper is an index [Mon Feb 1 13:08:16 2016] | tm_false : tm_helper false [Mon Feb 1 13:08:21 2016] you'll note that in vanilla Haskell, there are only parameters [Mon Feb 1 13:08:31 2016] think Haskell GADTs... [Mon Feb 1 13:08:38 2016] data Foo x = FooCon x Int [Mon Feb 1 13:08:46 2016] yeah [Mon Feb 1 13:08:58 2016] I wanted something like GADTs [Mon Feb 1 13:08:59 2016] the type of 'FooCon' is automatically filled in with the assumption that x is a parameter [Mon Feb 1 13:09:19 2016] let me play around with this a bit [Mon Feb 1 13:09:24 2016] the induction principles that an Inductive declaration generates will treat indices and parameters differently [Mon Feb 1 13:09:24 2016] see if it's working [Mon Feb 1 13:09:49 2016] try defining lists twice, with the element type first as a parameter and then as an index [Mon Feb 1 13:09:56 2016] and look at the differene between the induction principles it gives you [Mon Feb 1 13:11:38 2016] (er, by 'defining lists' i mean making a definition for the list type) [Mon Feb 1 13:11:44 2016] yeah [Mon Feb 1 13:12:02 2016] kk, just realized it could be parsed as meaning [Definition l1 := [1, 2, 3].] [Mon Feb 1 13:13:44 2016] alright looks like it can infer the types well enough [Mon Feb 1 13:13:50 2016] that's helpful [Mon Feb 1 13:14:12 2016] now I need to mark all those "forall b,"s as implicit [Mon Feb 1 13:15:52 2016] uh, is there a better way than doing Argument tm_true [_]. and so on for each constructor? [Mon Feb 1 13:17:42 2016] In the definition of each constructor, you can write "forall {b}, ..." [Mon Feb 1 13:17:47 2016] should work [Mon Feb 1 13:17:48 2016] oh, okay [Mon Feb 1 13:18:11 2016] or even directly " | tm_true {b} : tm_helper b " I believe [Mon Feb 1 13:18:17 2016] Cypi: ooh, nice [Mon Feb 1 13:18:43 2016] ooh [Mon Feb 1 13:35:43 2016] tbelaire: if that doesn't work, then after the inductive definition: Arguments tm_true : default implicits. [Mon Feb 1 13:36:01 2016] It does work nicely, thanks [Mon Feb 1 13:36:45 2016] hold on [Mon Feb 1 13:37:43 2016] tbelaire: isn't the only constructor that takes a bool as an argument, tm_lib? [Mon Feb 1 13:38:14 2016] the others are b: bool -> tm_helper b [Mon Feb 1 13:38:28 2016] generic in having any lib expressions or not [Mon Feb 1 13:38:48 2016] ah [Mon Feb 1 13:39:49 2016] tbelaire: I've used this boolean index trick before too [Mon Feb 1 13:40:06 2016] rather than having separate "raw" and "cooked" types [Mon Feb 1 13:40:52 2016] great [Mon Feb 1 13:40:59 2016] anything to keep in mind? [Mon Feb 1 13:41:34 2016] hmm, this seems slightly off [Mon Feb 1 13:42:01 2016] i'm looking at the gist again and i can't quite infer what you're trying to do [Mon Feb 1 13:42:24 2016] which is usually a sign of some kind of confusion on the part of the author, or that the code is above my level [Mon Feb 1 13:42:51 2016] I've updated the gist [Mon Feb 1 13:42:53 2016] https://gist.github.com/tbelaire/b77620217d543134bf0c [Mon Feb 1 13:43:22 2016] I'm hoping I can keep all the proofs somewhat generic over both [Mon Feb 1 13:43:27 2016] to avoid repeating them [Mon Feb 1 13:44:08 2016] ah, so, the point of b is that if there's a lib anywhere then the index is forced? [Mon Feb 1 13:44:16 2016] exactly [Mon Feb 1 13:44:22 2016] Hmm, anyone know where to read more on existT? [Mon Feb 1 13:44:47 2016] so then you plan on demanding false in the index to ensure the nonpresence of lib? [Mon Feb 1 13:44:55 2016] yup [Mon Feb 1 13:45:09 2016] kk [Mon Feb 1 14:51:15 2016] Hi folks [Mon Feb 1 14:51:47 2016] hey [Mon Feb 1 14:52:58 2016] Are there rules for this chat? [Mon Feb 1 14:55:40 2016] no puns [Mon Feb 1 14:55:49 2016] I'm trying to prove commutativity for natural numbers [Mon Feb 1 14:55:55 2016] I'm not sure how :P [Mon Feb 1 14:56:00 2016] ell: If you mean a Coq CoC, I don't think there is an official one. I would recommend Rust's CoC as a good starting point. [Mon Feb 1 14:56:03 2016] this is my definition of Nat and a start: https://dpaste.de/q0Mk [Mon Feb 1 14:56:23 2016] I just mean "no posting links" or "don't ask to ask, just ask", etc. :) [Mon Feb 1 14:57:13 2016] We use links all the time primarily for pastes. Sometimes we talk politics when no one is looking for help. [Mon Feb 1 14:57:41 2016] Primarily we reason with Coq's logic. We don't admit ad_hominem. [Mon Feb 1 14:58:00 2016] ell, you can define add by just matching on a [Mon Feb 1 14:58:07 2016] and then do induction on only one of the two [Mon Feb 1 15:00:48 2016] Ah yeah of course [Mon Feb 1 15:00:51 2016] I'll try that [Mon Feb 1 15:02:26 2016] like this: https://dpaste.de/7AQ5? [Mon Feb 1 15:02:56 2016] yeah, looks good [Mon Feb 1 15:03:09 2016] well that simplifies it a lot :) [Mon Feb 1 15:03:51 2016] what tutorial are you working with? [Mon Feb 1 15:03:57 2016] I'm not :P [Mon Feb 1 15:04:02 2016] well [Mon Feb 1 15:04:09 2016] I've looked through https://coq.inria.fr/tutorial-nahas [Mon Feb 1 15:04:18 2016] I managed to define associativity of addition earlier [Mon Feb 1 15:04:29 2016] but I have changed my definition of nat a few times since and it no longer worked [Mon Feb 1 15:04:34 2016] so I'm just starting afresh now [Mon Feb 1 15:04:47 2016] but I want to prove all of the properties really [Mon Feb 1 15:04:50 2016] Well, "Software Foundations" helps you step by step in these scenarios [Mon Feb 1 15:05:01 2016] because early exercises happen to be building blocks for later ones [Mon Feb 1 15:05:19 2016] doing all kinds of Nat stuff is in the first two chapters IIRC [Mon Feb 1 15:06:17 2016] ah thanks [Mon Feb 1 15:06:22 2016] I hadn't seen that book [Mon Feb 1 15:07:27 2016] That and http://adam.chlipala.net/cpdt/html/toc.html are two often mentioned ones. [Mon Feb 1 15:09:06 2016] thanks [Mon Feb 1 15:17:08 2016] I guess I'll go read that :P [Mon Feb 1 15:17:10 2016] Bye now :) [Tue Feb 9 20:06:25 2016] I'm having trouble with this code in Coq 8.5: https://github.com/wangpengmit/6887psets/tree/master/pset0 [Tue Feb 9 20:07:18 2016] It builds with 'make', but then I can't get [Require Pset0Sig] to work in another file in the same directory, from Proof General. [Tue Feb 9 20:07:46 2016] I can fix the problem "manually" by running the command lines that 'make' runs, but with these arguments removed: -R "." Top [Tue Feb 9 20:07:51 2016] Anyone know what's up with that? [Tue Feb 9 22:19:58 2016] is [forall P, ~~P = P] consistent with coq [Tue Feb 9 22:21:37 2016] i think so but i do not have a proof of that [Tue Feb 9 22:22:01 2016] wait a sec, equals? [Tue Feb 9 22:22:06 2016] i dont know about that at all [Tue Feb 9 22:46:53 2016] in fact thats an inconsistancy i think, ~~P = (P -> False) -> False, which starts with the function constructor, whereas P doesnt necessarily have a function constructor in it [Tue Feb 9 22:47:16 2016] so if theyre equal then you have two things with different constructors being reflexively equal [Tue Feb 9 22:53:54 2016] benzrf : see proof degeneracy in https://coq.inria.fr/library/Coq.Logic.ClassicalFacts.html . This would suggest that it is consistent. [Tue Feb 9 22:54:07 2016] propositional degeneracy* [Tue Feb 9 22:54:47 2016] sunnymilk: yeah, but you can't distinguish them can you [Tue Feb 9 22:56:52 2016] sunnymilk: HoTT is presumably consistent, and in hott bool -> bool = fin 4 [Wed Feb 10 10:49:28 2016] Hi there does somebody has experience with profiling ocaml toplevel programs? to be more specific HOL Light [Wed Feb 10 11:02:56 2016] I haven't read the paper in a while, but maybe there's some reporting on that in the results of the flyspeck project. [Wed Feb 10 11:44:27 2016] thank I will look into that :) [Wed Feb 10 12:30:09 2016] What's the command to go from H: A /\ B and prove B? [Wed Feb 10 12:30:30 2016] ah, tauto. does it. [Wed Feb 10 12:31:32 2016] destruct H as [HA HB]. exact HB. [Wed Feb 10 12:54:31 2016] Hmm. I'm trying to prove that if (x \in E) and (y \in F) and (no_dups (E ++ F)) then x <> y. [Wed Feb 10 12:54:48 2016] this is surprisingly difficult :/ [Wed Feb 10 12:56:12 2016] What are E and F? Lists? If so, how are no_dups and \in defined? [Wed Feb 10 12:56:51 2016] They are technically association lists, and x, and y are keys [Wed Feb 10 12:58:16 2016] no_dups is inductive, either nil or | forall E x, ok E -> ~ In x E -> no_dups (x :: E) [Wed Feb 10 12:58:28 2016] when I translate away from that into just plain lists [Wed Feb 10 12:58:59 2016] Actual def'ns here https://github.com/tbelaire/FJ-Formalization/blob/master/FJ_Definitions.v [Wed Feb 10 12:59:27 2016] and \in is just In [Wed Feb 10 12:59:39 2016] but infix [Wed Feb 10 13:11:32 2016] tbelaire : alright, an induction on E seemed to work [Wed Feb 10 13:11:46 2016] I just needed one auxiliary lemma, saying "{A : Type} (E F : list A) (x : A) : In x F -> In x (E ++ F) [Wed Feb 10 13:12:13 2016] Yeah, I got that lemma already [Wed Feb 10 13:12:18 2016] I'll try again [Wed Feb 10 13:12:55 2016] In your definition of no_dups, for the cons case, there is actually the hypothesis "no_dups E", right? [Wed Feb 10 13:13:08 2016] yeah, sorry [Wed Feb 10 13:13:20 2016] It's ok, just making sure [Wed Feb 10 13:13:25 2016] I picked a better name for irc than "ok", but missed one spot [Wed Feb 10 13:16:42 2016] How does your induction work? [Wed Feb 10 13:19:56 2016] The case E = [] is trivial. Then for the second one, you consider two cases: either x is the head of E. Then the auxiliary lemma is useful; or x is in the tail of E, and the induction hypothesis applies directly [Wed Feb 10 13:22:32 2016] k [Wed Feb 10 13:50:55 2016] How do you simplify something like " if y == y then true else false " to true? [Wed Feb 10 13:52:24 2016] Depends on '==' [Wed Feb 10 13:52:39 2016] I know it's decidable [Wed Feb 10 13:53:54 2016] Do you have any lemma on this '=='? Like "(x == y) = true" <-> x = y? [Wed Feb 10 13:55:32 2016] yeah [Wed Feb 10 13:55:34 2016] oh I see now [Wed Feb 10 13:55:36 2016] thanks [Wed Feb 10 13:55:37 2016] (the most simple would be a lemma that states the reflexivity of this '==' of course) [Wed Feb 10 13:55:43 2016] Ah, ok :) [Wed Feb 10 14:04:16 2016] Is it possible to "unfold" only one step? [Wed Feb 10 14:06:39 2016] eh, unfold get; fold get. normalized the goal in the same way, don't need it [Wed Feb 10 14:09:18 2016] Is there a way to "unsplit" a split goal? [Wed Feb 10 14:10:07 2016] I needed to apply a tactic to one leaf, but now the induction hypothises is X -> A /\ B when both A and B are goals. [Wed Feb 10 14:45:29 2016] no there isn't, but you can pose your IH on a proof of X and destruct it to get at either A or B. [Wed Feb 10 14:46:00 2016] set (spec := IH x); destruct spec as [a b]. [Wed Feb 10 16:45:47 2016] I'm getting ( Impossible to unify "ok_type D" with "ok_type D".) [Wed Feb 10 16:45:55 2016] Is there a way to display implicit parameters [Wed Feb 10 16:48:54 2016] tbelaire: Set Printing All. [Wed Feb 10 16:49:51 2016] Error: in CoqIde: Use CoqIDE display menu instead [Wed Feb 10 16:49:56 2016] ehh, what? [Wed Feb 10 16:50:14 2016] I'm using the vim coquille plugin [Wed Feb 10 16:50:21 2016] Coq 8.4 [Wed Feb 10 16:50:33 2016] same protocall as CoqIDE [Wed Feb 10 16:50:44 2016] o_O uhh, that's just a vernacular command. [Wed Feb 10 16:51:15 2016] nope, can't execute it :( [Wed Feb 10 16:52:39 2016] Try "Set Printing Implicit." [Wed Feb 10 16:53:02 2016] nope [Wed Feb 10 16:53:14 2016] it's trying to protect me from setting it while in coqide I guess [Wed Feb 10 16:53:21 2016] instead of using the menu [Wed Feb 10 16:53:28 2016] but I'm in VIM and don't have the menu [Wed Feb 10 16:53:30 2016] sigh [Wed Feb 10 16:56:57 2016] hey all I am stuck on what should be a simple proof due to lack of familiarltiy with tactics [Wed Feb 10 16:57:03 2016] Hi [Wed Feb 10 16:57:07 2016] I know that feeling [Wed Feb 10 16:57:53 2016] haha yeah ... [Wed Feb 10 16:58:07 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v [Wed Feb 10 16:58:10 2016] search for ev_sum [Wed Feb 10 16:59:35 2016] You can link to line numbers [Wed Feb 10 16:59:36 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L466 [Wed Feb 10 16:59:53 2016] by clicking on the left hand side line numbers first [Wed Feb 10 17:00:10 2016] ahhh that's so cool nv noticed that [Wed Feb 10 17:02:33 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L467 [Wed Feb 10 17:02:53 2016] so the issue is no matter what I do my proof state reduces to this: http://lpaste.net/152078 [Wed Feb 10 17:03:08 2016] which is really no better than were we started [Wed Feb 10 17:03:15 2016] Hmm [Wed Feb 10 17:03:22 2016] I tried induction on H1 [Wed Feb 10 17:03:27 2016] right at the start [Wed Feb 10 17:03:32 2016] and that seems promising [Wed Feb 10 17:03:39 2016] no inversions though [Wed Feb 10 17:05:39 2016] https://gist.github.com/14e5fdbf7fd60ac3d0bf [Wed Feb 10 17:07:42 2016] lingxiao: hows that look? [Wed Feb 10 17:07:51 2016] taking a look at it now [Wed Feb 10 17:09:19 2016] ahh you can do induction on [ev] directly [Wed Feb 10 17:09:30 2016] yeah [Wed Feb 10 17:09:43 2016] advanced technique :P [Wed Feb 10 17:10:03 2016] haha funny thing is the ex right above the problem deals iwth it [Wed Feb 10 17:10:56 2016] got it! this is what i ended up with http://lpaste.net/152080 [Wed Feb 10 17:11:36 2016] thanks! [Wed Feb 10 17:11:40 2016] np! [Wed Feb 10 17:21:50 2016] I wrote a 353 pages research monograph. How much work it would take to rewrite it with Gallinna+Isar? [Wed Feb 10 17:22:18 2016] tbelaire can i ask you another one? [Wed Feb 10 17:22:29 2016] Some things are not convenient to formalize in English and may be better in Coq. By the way, Coq helps against errors [Wed Feb 10 17:22:36 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L485 [Wed Feb 10 17:23:29 2016] If I work 8 hours per weekday to rewrite my book in Coq, how much months could it take? [Wed Feb 10 17:23:35 2016] my proof state is this: http://lpaste.net/152081 [Wed Feb 10 17:23:35 2016] it seems liek the only thin i can do is [inversion IHev]. [Wed Feb 10 17:23:52 2016] but eventually i encounter this case: http://lpaste.net/152082 [Wed Feb 10 17:23:58 2016] and I dont know what to do about ev' 4 [Wed Feb 10 17:29:01 2016] is there any hope that a Coq expert will help me to formalize my book? [Wed Feb 10 17:48:22 2016] hey is there anyone around that'd like to walk me thru a proof? [Wed Feb 10 17:48:47 2016] porton, this is a slow channel [Wed Feb 10 17:49:03 2016] just out of curiousity, what did you write about? [Wed Feb 10 17:50:04 2016] rrika: I generalized general topology. My book describes basics of general topology with something I call "funcoids" instead of topological spaces. The theory in the volume 1 is very basic (not categorical limits, not traditional pointfree topology, etc.) [Wed Feb 10 17:50:36 2016] rrika: I don't have a scientific degree but have some discoveries in pure math [Wed Feb 10 17:50:58 2016] I don't even understand half of the words… [Wed Feb 10 17:51:05 2016] * is beginner level [Wed Feb 10 17:51:27 2016] hope you find someone though [Wed Feb 10 17:51:35 2016] rrika: all my words except "funcoids" are widely known, every math graduate knows them [Wed Feb 10 17:52:00 2016] I didn't graduate in math [Wed Feb 10 17:58:35 2016] rrika want to take a crack at my proof? [Wed Feb 10 17:58:45 2016] lingxiao, let me see [Wed Feb 10 17:59:05 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L490 [Wed Feb 10 17:59:07 2016] ev'_ev [Wed Feb 10 18:01:15 2016] stuck here: http://lpaste.net/ [Wed Feb 10 18:01:20 2016] nothing in context is helping e [Wed Feb 10 18:01:22 2016] me* [Wed Feb 10 18:01:22 2016] but I [Wed Feb 10 18:01:29 2016] also cant think of anoteher route to take [Wed Feb 10 18:03:49 2016] lingxiao, the lpaste link is lacking an id [Wed Feb 10 18:04:11 2016] http://lpaste.net/152084 [Wed Feb 10 18:06:33 2016] * apply ev'_sum with (n:=2). apply ev'_2. apply ev'_2. [Wed Feb 10 18:08:57 2016] what does apply ev'_sum with (n:=2) do? [Wed Feb 10 18:10:39 2016] well, you're trying to unify (_ + _) from ev'_sum with 4 [Wed Feb 10 18:10:49 2016] which could be anything from 0+4, 1+3, to 4+0 [Wed Feb 10 18:10:55 2016] so we have ev'_sum 2 := forall m. ev' m -> ev' (2 + m) ?? [Wed Feb 10 18:10:55 2016] but what does that mean? [Wed Feb 10 18:11:26 2016] it means that if you try to unify (ev' 2+m) with (ev' 4), m will be inferred as 2 [Wed Feb 10 18:11:34 2016] you could be fully explicit and say [Wed Feb 10 18:11:39 2016] with (n:=2) (m:=2) [Wed Feb 10 18:12:11 2016] so there's two ev'2 gnerenated as goals [Wed Feb 10 18:12:12 2016] so it will behave as if you tried to apply "ev' 2 -> ev' 2 -> ev' (2+2)" [Wed Feb 10 18:12:15 2016] yes [Wed Feb 10 18:12:22 2016] the first one is to prove n:=2 and second one is that m:=2 ? [Wed Feb 10 18:13:15 2016] well, to apply something the last part of the A→B→C→D chain (D) must match your goal after simplification [Wed Feb 10 18:13:26 2016] n+m doesn't simplify to 4 [Wed Feb 10 18:13:45 2016] but S (S _) and S (S (S (S O))) can be matched [Wed Feb 10 18:14:10 2016] so by explicitly mentioning n, you make the last part of the chain match the goal [Wed Feb 10 18:14:23 2016] apply (ev'_sum 2). would've worked too Ithink [Wed Feb 10 18:17:19 2016] hm yup it did [Wed Feb 10 18:17:25 2016] and im equally stuck in this case: http://lpaste.net/152085 [Wed Feb 10 18:17:40 2016] inversion IHev1 deosnt seem to help [Wed Feb 10 18:17:41 2016] lingxiao_, this one is easy though [Wed Feb 10 18:17:52 2016] wait could you give me a hint [Wed Feb 10 18:17:54 2016] you only need apply from here on [Wed Feb 10 18:17:54 2016] first [Wed Feb 10 18:18:15 2016] that's the hint [Wed Feb 10 18:18:30 2016] nothing in contet applies to each other though [Wed Feb 10 18:18:36 2016] and none of them apply to the goal directly [Wed Feb 10 18:18:53 2016] then try random things that have worked before [Wed Feb 10 18:19:22 2016] i see that S S (n+m) = k + (n+ m) [Wed Feb 10 18:19:22 2016] as in [Wed Feb 10 18:19:28 2016] yeah [Wed Feb 10 18:19:35 2016] or S S 0 + (n + m) [Wed Feb 10 18:19:41 2016] so that's the ev'_sum case [Wed Feb 10 18:20:11 2016] both expression simplify to the same [Wed Feb 10 18:22:45 2016] ok now i see this caes: http://lpaste.net/152086 [Wed Feb 10 18:23:11 2016] uh, the first one is literally just ev'_sum [Wed Feb 10 18:23:38 2016] ahh i see [Wed Feb 10 18:24:30 2016] got it! [Wed Feb 10 18:24:33 2016] can I see the whole line? [Wed Feb 10 18:24:41 2016] yeah using propositions as functions with params is killer [Wed Feb 10 18:24:54 2016] http://lpaste.net/152087 [Wed Feb 10 18:24:58 2016] is what i ended up with [Wed Feb 10 18:25:36 2016] * apply ev'_sum with (n:=2). apply ev'_2. apply ev'_2. [Wed Feb 10 18:25:36 2016] * apply ev'_sum with (n:=2). apply ev'_2. apply ev'_sum. [Wed Feb 10 18:25:36 2016] apply IHev1. apply IHev2. [Wed Feb 10 18:25:38 2016] is mine [Wed Feb 10 18:26:42 2016] you don't need to "replace" [Wed Feb 10 18:27:04 2016] apply ev'_sum will operate on the goal "ev' (S (S (n+m)))" [Wed Feb 10 18:27:38 2016] ohh [Wed Feb 10 18:27:41 2016] haha did not know that [Wed Feb 10 18:27:54 2016] or i guess that's the def of + [Wed Feb 10 18:28:00 2016] yes [Wed Feb 10 18:28:11 2016] i guess i shouldv known when i proved that replace by reflexivity. [Wed Feb 10 18:28:17 2016] yes [Wed Feb 10 18:28:54 2016] thanks! [Wed Feb 10 18:29:11 2016] Its like i have an inteaticve theorem prover in coq [Wed Feb 10 18:29:23 2016] and interative theorem proover proover in rrika :) [Wed Feb 10 18:29:30 2016] ^_^ [Wed Feb 10 18:33:06 2016] alright i'm off thanks! and porton you might have some luck in #haskell [Wed Feb 10 18:33:16 2016] alot of people know coq there but dont hang out here [Thu Feb 11 09:30:43 2016] How do I go from (A, B, C) = (A', B', C') to A = A'? [Thu Feb 11 09:32:37 2016] with "inversion" [Thu Feb 11 09:33:51 2016] Nice [Thu Feb 11 09:33:56 2016] makes sense [Thu Feb 11 11:20:24 2016] hey all [Thu Feb 11 11:20:37 2016] anyone care to take a look at this proof? https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L793 [Thu Feb 11 11:58:36 2016] sure [Thu Feb 11 11:58:42 2016] I've got my own question [Thu Feb 11 11:58:45 2016] too [Thu Feb 11 12:00:16 2016] I have a setup where I have H : P( x : lst), H2 : In y lst. And I do case analysis in H, case one, x:lst = nil, but it doesn't become false rihgt away [Thu Feb 11 12:00:28 2016] oh, inversion [Thu Feb 11 12:00:31 2016] I bety [Thu Feb 11 12:03:37 2016] Error: The reference double was not found in the current environment. [Thu Feb 11 12:03:51 2016] err, does that depend on something? trying to view your proof [Thu Feb 11 12:03:59 2016] gets stuck way earlier [Thu Feb 11 12:05:55 2016] okay, cloned your repo [Thu Feb 11 12:06:03 2016] wonder why coq didn't throw some inport error [Thu Feb 11 12:07:18 2016] If you've got conflicting hypothesis, try doing exfalso. then showing a contradiction [Thu Feb 11 12:07:21 2016] ? [Thu Feb 11 12:09:19 2016] oh, or you need to generalize your induction hypothesis [Thu Feb 11 12:09:23 2016] so it says [Thu Feb 11 12:09:59 2016] (forall s, s =~ foo s2 -> s = s2) [Thu Feb 11 12:10:25 2016] then use it and cons back on the missing bit [Thu Feb 11 12:10:37 2016] uh, something something, use generalize before induction [Thu Feb 11 12:10:55 2016] maybe do each half of the proof on it's own [Thu Feb 11 12:12:13 2016] no, you're already doing that [Thu Feb 11 12:13:54 2016] + (* -> *) [Thu Feb 11 12:13:57 2016] generalize s1; clear s1. [Thu Feb 11 12:13:59 2016] induction s2 as [|s s2']; intros s1. [Thu Feb 11 12:14:01 2016] - intros H. inversion H. reflexivity. [Thu Feb 11 12:14:03 2016] - intros H. [Thu Feb 11 12:14:05 2016] Here, try that [Thu Feb 11 12:14:21 2016] lingxiao: take a look [Thu Feb 11 12:21:05 2016] You'll need to destruct s1 and then take apart =~ and put it back together again [Thu Feb 11 12:21:14 2016] but I 'think it'll work eventually [Thu Feb 11 13:32:46 2016] is there a generic way to map w [Thu Feb 11 13:32:59 2016] whoops [Thu Feb 11 13:33:51 2016] is there a generic way to bind a proof of the specific case deconstruction equality in a match expression? [Thu Feb 11 13:34:39 2016] so e.g. match a with | \Some x => \p : a = Some x -> ... [Thu Feb 11 13:35:33 2016] do you mean the convey pattern? [Thu Feb 11 13:36:11 2016] ah thanks, looking at that now [Thu Feb 11 13:36:27 2016] sorry, convoy pattern [Thu Feb 11 13:36:32 2016] it's described in depth in CPDT [Thu Feb 11 13:36:39 2016] yeah google corrected it for me :) [Thu Feb 11 13:36:47 2016] yeah thats what I'm looking at now, thanks [Thu Feb 11 15:45:13 2016] thanks johnw, came up with this: match a as o return a = o -> ... with | Some k => fun p => ... end eq_refl [Thu Feb 11 15:48:20 2016] have a feeling I'll use that a fair amount [Fri Feb 12 10:28:52 2016] hey all [Fri Feb 12 10:29:01 2016] could someone help me thru a proof? I'm really struggling! [Fri Feb 12 10:29:44 2016] this one: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L807 [Fri Feb 12 10:47:12 2016] lingxiao : try to do an induction on s2 instead (also, don't forget to generalize as much as possible before doing the induction) [Fri Feb 12 10:47:51 2016] Cypi I tried that and was stuck on the inductive case. [Fri Feb 12 10:47:55 2016] my proof state is: [Fri Feb 12 10:48:37 2016] http://lpaste.net/152275 [Fri Feb 12 10:49:02 2016] or rather: http://lpaste.net/152276 [Fri Feb 12 10:49:20 2016] and it makes no sense. if I use the ihnduction hypothesis, then I get s1 = s2' [Fri Feb 12 10:49:31 2016] which makes the goal s1 = s :: s2' ==> s1 = s :: s1 [Fri Feb 12 10:49:51 2016] You need to use the hypothesis H first [Fri Feb 12 10:50:11 2016] The right-hand-side has a specific shape, which allows to deduce things from it [Fri Feb 12 10:50:27 2016] so you mean indution on H? [Fri Feb 12 10:51:10 2016] Just inversion [Fri Feb 12 10:52:05 2016] hmm ok i see this: http://lpaste.net/152277 [Fri Feb 12 10:52:29 2016] which makes ore sense, ie s0 match char s and s2 matches reg_exp of s2' [Fri Feb 12 10:53:03 2016] but I'm not sure how to use those premises [Fri Feb 12 10:54:53 2016] First, you might want to simplify that kind of context by just using "subst" [Fri Feb 12 10:55:09 2016] (it will look for equalities like "x = t" where x is a variable, and replace the variable with the term t) [Fri Feb 12 10:55:37 2016] Then, you can now do what you wanted to do before: use the induction hypothesis. [Fri Feb 12 10:55:45 2016] This will get you something more useful [Fri Feb 12 10:59:37 2016] ahh so i see this in context: http://lpaste.net/152278 [Fri Feb 12 10:59:49 2016] now i just have to show s0 = s [Fri Feb 12 10:59:59 2016] and the context says s0 matches Char s [Fri Feb 12 11:00:06 2016] also we have H [Fri Feb 12 11:01:49 2016] but we already used that [Fri Feb 12 11:02:07 2016] H3 should be enough [Fri Feb 12 11:02:11 2016] yup got it! [Fri Feb 12 11:02:33 2016] [subst] is a good trick! thank you! [Fri Feb 12 11:13:57 2016] Hey Cypi this proof state makes a lot of sense but I'm not sure what to do with it [Fri Feb 12 11:14:11 2016] http://lpaste.net/152279 [Fri Feb 12 11:15:30 2016] So in that case, you would like to apply the constructor MApp [Fri Feb 12 11:16:10 2016] Coq will be annoying about it though, because on the left-hand-side, you have "s :: s2" and not something which has the shape "[s] ++ s2", even though both are convertible [Fri Feb 12 11:17:02 2016] An easy fix is to just do "apply (MApp [s])" instead of just "apply MApp", this will help Coq instantiate MApp with the correct terms [Fri Feb 12 11:17:18 2016] ahhh i see it! [Fri Feb 12 11:18:07 2016] ok great thank you! [Fri Feb 12 13:14:39 2016] what's the coq equivalent of ocamlbuild? [Fri Feb 12 13:15:04 2016] or I have to build dependencies using coqc manually? [Fri Feb 12 13:15:56 2016] there is coqdep to figure out dependencies [Fri Feb 12 18:08:56 2016] I have a stupid syntax question [Fri Feb 12 18:10:35 2016] lingxiao: it's better to just ask, rather than announce the question first [Fri Feb 12 18:11:00 2016] ok great johnw: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L905 [Fri Feb 12 18:11:25 2016] so [re_not_empty] should check if some regex re matches some string xs [Fri Feb 12 18:11:46 2016] but there is no parameter to take in a strng ... and the function of type : reg_exp T -> bool [Fri Feb 12 18:11:54 2016] so I can't output lambda that takes in some string [Fri Feb 12 18:12:00 2016] am I understand the fucntion wrong? [Fri Feb 12 18:12:19 2016] you're proving that the regular expression can match "some string" [Fri Feb 12 18:12:21 2016] any string [Fri Feb 12 18:12:25 2016] that it doesn't only match empty strings [Fri Feb 12 18:12:56 2016] ok so by def EmptySet is false [Fri Feb 12 18:13:04 2016] and emptyStr is true or false? [Fri Feb 12 18:13:11 2016] I don't see emptyStr [Fri Feb 12 18:13:30 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L565 [Fri Feb 12 18:14:08 2016] i don't know [Fri Feb 12 18:14:14 2016] i haven't done that exercise I don't think [Fri Feb 12 18:14:18 2016] yeah it's new [Fri Feb 12 18:14:24 2016] I'm not really sure what it's askng [Fri Feb 12 18:14:40 2016] so suppose EmptyStr is false, then all the other cases just recurse, and Char is always true [Fri Feb 12 18:14:42 2016] it's asking if emptyStr is capable of matching non-empty string [Fri Feb 12 18:15:20 2016] huh? wait based on this lemma [(exists s, s =~ re) <-> re_not_empty re = true.] [Fri Feb 12 18:15:23 2016] then empty string should be true [Fri Feb 12 18:15:32 2016] or [EmptyStr => true] [Fri Feb 12 18:16:12 2016] ok [Fri Feb 12 18:16:22 2016] you'll find out soon enough when you do some proofs :) [Fri Feb 12 18:16:33 2016] that's why I love Coq; lies don't last [Fri Feb 12 18:16:54 2016] hahah they changed a bunch of stuff and I wish it was a bit more polished before they published it [Fri Feb 12 18:17:00 2016] what a beautiful sentence [Fri Feb 12 18:19:09 2016] the Coq is a lie? [Fri Feb 12 18:21:27 2016] oh haha nothing [Fri Feb 12 18:22:10 2016] nevermind, it was a "the cake is a lie" pun [Fri Feb 12 21:05:00 2016] hey all [Fri Feb 12 21:07:12 2016] I have a proof in mind but I dont have the tactics to navigate it [Fri Feb 12 21:07:36 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L918 [Fri Feb 12 21:08:11 2016] in the <- case I want to say that the premise [ re_not_empty re = true ] implies several cases as describe in re_not_empty above [Fri Feb 12 21:08:36 2016] and I want to examine each one in turn, and each one will give me a witness for the exits s : list T, s =~re statement [Fri Feb 12 21:09:31 2016] oh wait .. [Fri Feb 12 21:10:18 2016] nvm doing induction on re [Fri Feb 12 21:13:22 2016] ok actually anotehr problem [Fri Feb 12 21:13:34 2016] in this state: http://lpaste.net/152288 [Fri Feb 12 21:13:51 2016] I do not know how to produce a witness [s] so that [s =~ char t] [Fri Feb 12 21:14:33 2016] ahh nvm haha [Fri Feb 12 21:18:50 2016] hm ok now i see this state: http://lpaste.net/152289 [Fri Feb 12 21:19:12 2016] actually not sure what to do here since there's no t : T in context to get rid of the exisential in H1 H2 and the goal [Fri Feb 12 21:19:28 2016] Why would you need a "t : T"? [Fri Feb 12 21:19:54 2016] not sure how to deal with the exists s otherwise [Fri Feb 12 21:20:06 2016] You can destruct existantials in your hypothesis [Fri Feb 12 21:20:18 2016] hypotheses* existentials* [Fri Feb 12 21:20:19 2016] aahh [Fri Feb 12 21:23:24 2016] ok in this state Cypi: http://lpaste.net/152290 [Fri Feb 12 21:23:36 2016] why doesn't [apply (MApp x re1 x0 re2 H H0).] work? [Fri Feb 12 21:24:33 2016] Because (MApp x re1 x0 re2 H H0) proves "x ++ x0 =~ App re1 re2", not "x =~ App re1 re2" [Fri Feb 12 21:24:42 2016] You probably provided the wrong witness [Fri Feb 12 21:26:35 2016] ahh [Fri Feb 12 21:31:30 2016] Thanks Cypi! [Fri Feb 12 22:25:41 2016] hey all [Fri Feb 12 22:25:50 2016] I'm writing my first inductively defined Prop [Fri Feb 12 22:25:58 2016] and I would like a second eye on it and help with a proof [Fri Feb 12 22:26:24 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1197 [Fri Feb 12 22:26:40 2016] in [pal_app_rev] I'm stuck on [apply (pal_cons x1 l IHl).] [Fri Feb 12 22:26:47 2016] I'd like to use the IHl but its type is wrong [Fri Feb 12 22:27:14 2016] so either i'm not massaging it enough or my def of [pal] is wrong [Fri Feb 12 22:30:28 2016] Two things here [Fri Feb 12 22:30:40 2016] yup? [Fri Feb 12 22:31:19 2016] 1) You're not massaging enough: what you want to get as a goal is "pal ([x1] ++ ((x2 :: l) ++ rev (x2 :: l)) ++ [x1])" [Fri Feb 12 22:31:23 2016] (notice the added parentheses) [Fri Feb 12 22:31:52 2016] oh ops i did that.. must've not git pushed [Fri Feb 12 22:32:31 2016] ok pushed again [Fri Feb 12 22:34:19 2016] Ok, now the only thing is that you're instantiating pal_cons with l instead of "(x2 :: l) ++ rev (x2 :: l)" [Fri Feb 12 22:34:48 2016] note that you could just do "apply pal_cons", since the shape of the goal is enough to determine every argument of pal_cons [Fri Feb 12 22:35:26 2016] 2) Your definition is good enough for those two theorems, but it will not suffice for the next one: you actually only characterize the palindromes of even length [Fri Feb 12 22:35:40 2016] yeah I originall had pal_one : forall x, pal [x] [Fri Feb 12 22:35:48 2016] Which is indeed what you want [Fri Feb 12 22:36:06 2016] (no need for pal_two, which is just a special case of pal_cons and pal_nil) [Fri Feb 12 22:36:24 2016] ahh ok great . that makes more sense. could you repeat what you said about pal_cons? [Fri Feb 12 22:36:49 2016] this part: now the only thing is that you're instantiating pal_cons with l instead of "(x2 :: l) ++ rev (x2 :: l)" [Fri Feb 12 22:37:26 2016] You wrote "apply (pal_cons x1 l IHl)", but the list to which you want to concatenate [x] on both sides is not l, it is ((x2 :: l) ++ rev (x2 :: l)) [Fri Feb 12 22:39:31 2016] ahh got it! [Fri Feb 12 22:39:32 2016] thanks! [Fri Feb 12 22:51:43 2016] Cypi is it possible to [induction l .. ] by taking apart the front and the end of a list? [Fri Feb 12 22:52:04 2016] so l as elem1 : xs ++ [elemn] [Fri Feb 12 22:54:23 2016] i'm looking at [palindrome_converse] [Fri Feb 12 22:54:23 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1244 [Fri Feb 12 22:54:38 2016] and doing induction on l as [x1 | [x2 | l]] doesnt seem to help [Fri Feb 12 22:59:33 2016] So, this exercise has been the bane of several people ^^ [Fri Feb 12 22:59:44 2016] I know of two main ways of doing it, let's look at what you suggested [Fri Feb 12 23:00:07 2016] It is indeed possible to do the induction that you described, but you have to prove it first [Fri Feb 12 23:01:00 2016] You can take a look at the type of list_rect, which is the induction principle for lists (used under the hood by the 'induction' tactic), and try to see which should be the type of your custom induction principle. [Fri Feb 12 23:02:01 2016] harhar .. actually not sure how to prove what I'm suggsting [Fri Feb 12 23:02:15 2016] like wouldnt even know where to start .. do i write down an inductive property first? [Fri Feb 12 23:03:14 2016] I guess that would be yet another way to do this: define another inductive type which has the correct induction principle, and prove the equivalence between the two types. [Fri Feb 12 23:03:58 2016] where do i find the type for list_rect? [Fri Feb 12 23:04:12 2016] where do i find any documentation for coq for that mattter? [Fri Feb 12 23:04:31 2016] is this good: https://coq.inria.fr/distrib/current/files/Reference-Manual.pdf ? [Fri Feb 12 23:05:14 2016] You won't find that type directly in the documentation (probably not), but you can just ask Coq: "Check list_rect." [Fri Feb 12 23:05:57 2016] ok so what's the difference between the inductive def of list and list_rect conceptually? [Fri Feb 12 23:06:05 2016] I see they're different in terms of syntax [Fri Feb 12 23:07:31 2016] oh wait i see it for nat_rect [Fri Feb 12 23:07:34 2016] which is easier to digest [Fri Feb 12 23:07:54 2016] foo_rect is teh inductive principle for foo right? [Fri Feb 12 23:07:57 2016] yes [Fri Feb 12 23:09:22 2016] so i might write [Fri Feb 12 23:10:03 2016] forall X P, p [] -> forall x1 x2 l, p l -> p ([x1] ++ l ++ [x2]) -> forall l, P l [Fri Feb 12 23:10:35 2016] or also insert forall x, p [x] after the empty case [Fri Feb 12 23:10:57 2016] Yup, with the "forall x, p [x]" [Fri Feb 12 23:11:21 2016] huh so after i do that i can write induction on list as [...] using my principle [Fri Feb 12 23:11:46 2016] but before that I need to prove they're equivalent? I've never seen such a proof before not sure how t proceed [Fri Feb 12 23:11:49 2016] I guess i can admit it [Fri Feb 12 23:13:35 2016] You "just" need to prove that induction principle, which is not an easy task (this exercise is a 5 stars after all). One intermediate lemma I might suggest is the following: [Fri Feb 12 23:14:28 2016] "forall X P, (P []) -> (forall x l, P (rev l) -> P (rev (x :: l))) -> forall l, P (rev l)" [Fri Feb 12 23:14:49 2016] so basically, sort of another induction principle but about the function rev [Fri Feb 12 23:15:14 2016] Even with that it will require some other lemmas about rev and app [Fri Feb 12 23:15:53 2016] hmm ok so this : "forall X P, (P []) -> (forall x l, P (rev l) -> P (rev (x :: l))) -> forall l, P (rev l)" [Fri Feb 12 23:16:09 2016] is something i'd need to prove the other inductive principle? [Fri Feb 12 23:16:15 2016] Yes [Fri Feb 12 23:16:23 2016] if I just work with the regular stuff w/o rolling a new machinary .. [Fri Feb 12 23:16:30 2016] is the path "easier"? [Fri Feb 12 23:17:00 2016] i think so ^^ [Fri Feb 12 23:17:10 2016] harhar [Fri Feb 12 23:17:13 2016] hints? [Fri Feb 12 23:17:19 2016] the other path is less computer science and more math [Fri Feb 12 23:18:01 2016] Basically, the problem with just a simple induction is that the induction hypothesis only gives a fact about the tail of l, whereas there you would like a fact about l, with its head and its last element [Fri Feb 12 23:18:29 2016] so what you can do is generalize a little bit the theorem so that the induction hypothesis gives you a fact about every list smaller than l [Fri Feb 12 23:19:16 2016] so every list smaller than l would include the very last element in its own list? [Fri Feb 12 23:19:35 2016] when you say: generalize a little bit the theorem, do you mean palindrom_converse? [Fri Feb 12 23:20:28 2016] Yes. I mean adding stuff in front of the goal, basically. It won't make it stronger, but it will make the induction hypothesis stronger. [Fri Feb 12 23:20:51 2016] And by "smaller", I really mean "smaller by length" [Fri Feb 12 23:23:06 2016] hmm ok I'll have to think about it for a while [Fri Feb 12 23:23:13 2016] when I'm more awake [Fri Feb 12 23:56:55 2016] thanks a lot Cypi! [Sat Feb 13 16:00:38 2016] If I have a hypothesis that two constant functions are equal (fun _ => x = fun _ => x'), is there a way that I can deduce that the two constants are equal (x = x')? [Sat Feb 13 16:02:24 2016] Only if you can apply the functions to something. [Sat Feb 13 16:04:42 2016] and if you can apply them to some term t then it's easy, because "x = x'" is the same thing as "f t = f' t", and you can then rewrite [Sat Feb 13 16:04:52 2016] (where f and f' are your two constant functions) [Sat Feb 13 16:07:08 2016] Thanks! did it by change tactic [Sat Feb 13 21:16:04 2016] hey all [Sat Feb 13 21:16:13 2016] I'd like some advice on definiing this propsition [Sat Feb 13 21:16:29 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1598 [Sat Feb 13 21:16:56 2016] the problem is that i'm saying if l1 is a subsequence of l2, then l1 subsequence of [x] ++ l2 ++ [y], essentially [Sat Feb 13 21:17:32 2016] but I dont know how to say something about the possiblity that if l2 = l3 ++ l4, and l1 subsequence of l2, then l1 subsequence of l3 ++ [x] ++ l4 [Sat Feb 13 21:17:58 2016] or something like that .. this case: [1;2;3] <: [1;2;7;3] [Sat Feb 13 21:22:17 2016] i could say something like : http://lpaste.net/152382 [Sat Feb 13 21:22:22 2016] but the hint says 3 cases [Sat Feb 13 21:22:28 2016] and that solution looks pretty bad [Sat Feb 13 21:22:38 2016] as in verbose [Sat Feb 13 21:23:29 2016] and I suppose hd and tl are just special cases of mid where l3 is [] or l4 is [] [Sat Feb 13 21:23:56 2016] and when i do proofs i have to find some witness to the fact that l2 = l3 ++ l4? [Sat Feb 13 21:24:00 2016] that sounds no fun [Sat Feb 13 21:31:26 2016] lingxiao: think about processing one of the lists element-by-element [Sat Feb 13 21:31:39 2016] almost like you were writing a recursive function [Sat Feb 13 21:32:05 2016] so if l1 <: l2 [Sat Feb 13 21:32:11 2016] then i should destruct l2? [Sat Feb 13 21:32:25 2016] sure try that and see what happens [Sat Feb 13 21:39:29 2016] jrw so I'm essentially converting this: http://lpaste.net/152384 [Sat Feb 13 21:39:34 2016] into a Prop? [Sat Feb 13 21:42:46 2016] lingxiao: yep [Sat Feb 13 21:42:56 2016] notice the three cases :) [Sat Feb 13 21:43:25 2016] yeah it's odd haha [Sat Feb 13 21:43:33 2016] but how would i express the false case? [Sat Feb 13 21:43:40 2016] actually now that I think about it it's not quite the same cases [Sat Feb 13 21:43:47 2016] the false case doesn't get translated [Sat Feb 13 21:43:51 2016] i tried [ rt_nil : forall l, subseq l [] -> Fasle] [Sat Feb 13 21:43:51 2016] and the if becomes 2 [Sat Feb 13 21:44:02 2016] yeah that did not work .. oh hmm. [Sat Feb 13 21:45:56 2016] so jrw like this: http://lpaste.net/152385 [Sat Feb 13 21:46:05 2016] except how do you say x not equal to y? [Sat Feb 13 21:46:48 2016] ~(x=y) right? [Sat Feb 13 21:46:51 2016] x <> y [Sat Feb 13 21:46:55 2016] is the same as ~(x=y) [Sat Feb 13 21:48:07 2016] lingxiao: it looks backwards to me [Sat Feb 13 21:49:33 2016] jrw this: http://lpaste.net/152386 ?? [Sat Feb 13 21:49:48 2016] this aint quite as mind bending as when I touched functional programming the first time [Sat Feb 13 21:49:55 2016] but the manner of thought is somewhat new haha [Sat Feb 13 21:50:18 2016] I think i used forward logic when I shouldv used backward logic correct? [Sat Feb 13 21:50:18 2016] yeah that looks pretty good [Sat Feb 13 21:52:52 2016] hmm pretty nifty [Sat Feb 13 21:53:14 2016] although the boolean function looks much more readble to me [Sat Feb 13 21:53:25 2016] what is the advantage of a Prop over just a bool again? [Sat Feb 13 21:53:35 2016] aside from the fact that they are different concepts (?) [Sat Feb 13 21:53:48 2016] lingxiao: it allows more directly inspection (via case matching) of _how_ it's a subseq [Sat Feb 13 21:53:57 2016] but you could also write a boolean-returning subseq, and just say: [Sat Feb 13 21:54:00 2016] subseq xs ys = true [Sat Feb 13 21:54:03 2016] lifting it back into Prop [Sat Feb 13 21:58:21 2016] wait could you say that again? [Sat Feb 13 21:58:31 2016] did you mean True? [Sat Feb 13 21:58:45 2016] how does subseq xs ys = True lift it into prop? [Sat Feb 13 22:02:55 2016] also jrw or johnw I'm stuck in this case of a proof: http://lpaste.net/152387 [Sat Feb 13 22:03:19 2016] in this proof: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1633 [Sat Feb 13 22:03:54 2016] lingxiao: that should follow from your second constructor [Sat Feb 13 22:05:23 2016] jrw ithought so too so i did this: [ apply (x_eq_y (y :: l2) (y :: l0)). ] [Sat Feb 13 22:05:33 2016] but I'm getting can't unify error [Sat Feb 13 22:05:42 2016] lingxiao: why not just try [apply x_eqy] ? [Sat Feb 13 22:06:41 2016] oh because it gave me some case statement haha [Sat Feb 13 22:06:47 2016] but it's good it means it works [Sat Feb 13 22:08:11 2016] yea it unfold the [++] function for some reason [Sat Feb 13 22:08:14 2016] or app [Sat Feb 13 22:08:18 2016] which is ++ i believe [Sat Feb 13 22:08:53 2016] lingxiao: if you [simpl.] first that shouldn't happen [Sat Feb 13 22:09:26 2016] hmm your right thats werid [Sat Feb 13 22:09:30 2016] why did it do that? [Sat Feb 13 22:09:46 2016] unfodl the ++ in this cse [y :: l1 <: (y :: l2) ++ l3 ] [Sat Feb 13 22:09:48 2016] case* [Sat Feb 13 22:10:34 2016] lingxiao: basically because it had to do a simpl for you, and it's overly agressive [Sat Feb 13 22:10:38 2016] so it goes ahead and unfolds [Sat Feb 13 22:10:53 2016] oh ... so many magic going on [Sat Feb 13 22:36:17 2016] anyone know what to do in this state? http://lpaste.net/152429 [Sat Feb 13 22:36:24 2016] further inversion on H does no good [Sat Feb 13 22:36:32 2016] the context is clearly contradictiroy with p and not p [Sat Feb 13 22:36:58 2016] proof hree: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1748 [Sat Feb 13 22:49:10 2016] lingxiao: you can do [contradiction p] or [congruence] or [exfalso. apply H0. apply p.] [Sat Feb 13 22:49:50 2016] why is that [exfalso. apply H0] make ~P into P? [Sat Feb 13 22:50:27 2016] it doesn't what do you mean? [Sat Feb 13 22:50:36 2016] no it does [Sat Feb 13 22:50:39 2016] but I'm wondering why [Sat Feb 13 22:50:49 2016] what's exfalos anyways. i see what it does [Sat Feb 13 22:51:02 2016] and whats congrence? does it just check of the context is consistent ? [Sat Feb 13 22:52:50 2016] jrw I'm sorry exfalose turns the goal to False, then apply H0 turns the goal into P [Sat Feb 13 22:52:56 2016] congruence implements the congruence closure algorithm. it's good at reasoning over equalities [Sat Feb 13 22:53:32 2016] but it will also find stuff like your thing where you have P and ~ P [Sat Feb 13 22:54:43 2016] hmm so heuristically speaking when do i use congruence? [Sat Feb 13 22:55:04 2016] i guess i could read thru this haha: http://www.cse.chalmers.se/~laurako/links/ARVSlides/arv-l6.pdf [Sat Feb 13 22:57:00 2016] you'll get the hang of when to use it after awhile. basically if your goal follows from only rewriting without any quantifiers then congruence can do it [Sat Feb 13 23:09:11 2016] jrw hmm ok i'll start using it whenever i can@ [Sun Feb 14 10:54:01 2016] i have some Goal A ∨ B and I want to apply a constructor to A. How can i do that? [Sun Feb 14 10:54:09 2016] or isn't this logically possible at all? [Sun Feb 14 10:58:29 2016] My Goal is: x ϵ (x' :: xs') ∨ x ϵ ys [Sun Feb 14 10:59:30 2016] And I would like to apply in_later : ∀ b l, a ϵ l → a ϵ b :: l [Sun Feb 14 11:08:11 2016] i thought maybe rewrite could do this [Sun Feb 14 11:08:25 2016] Error: Cannot find an homogeneous relation to rewrite. [Sun Feb 14 11:10:01 2016] Oh I just used `firstorder` no idea it would do anything at all, but it rewrote my hypothesis to what i need [Sun Feb 14 11:11:16 2016] Wtf is firstorder doing... [Sun Feb 14 11:15:08 2016] does firstorder try destructs on or or something? [Sun Feb 14 11:18:54 2016] Well I finished the proof without firstorder by applying the construct on hypothesis, but could I do it on my goal as well? [Sun Feb 14 13:39:27 2016] hey al [Sun Feb 14 13:39:35 2016] could someone take a look at my proof state and suggest a pathway forward? [Sun Feb 14 13:39:52 2016] http://lpaste.net/152448 [Sun Feb 14 13:39:55 2016] proof state --^ [Sun Feb 14 13:40:20 2016] proof: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1846 [Sun Feb 14 13:40:24 2016] [filter_l] [Sun Feb 14 13:42:55 2016] also i'm not confident in my def of [in_order_merge] prop [Sun Feb 14 14:46:46 2016] lingxiao i finished the inorder proofs last week i think [Sun Feb 14 14:46:57 2016] oh great! [Sun Feb 14 14:47:04 2016] so you're just one week ahead of me haah [Sun Feb 14 14:47:15 2016] not really [Sun Feb 14 14:47:26 2016] im at the next exercise :P [Sun Feb 14 14:47:56 2016] in_order_merge l1 l2 l -> filter test l1 = l1 -> filter test l2 = [] -> filter test l = l1. [Sun Feb 14 14:48:01 2016] are you proving that? [Sun Feb 14 14:50:12 2016] yup [Sun Feb 14 14:50:27 2016] but first i'm not sure my ind prop of in_order_merge is well stated [Sun Feb 14 14:50:32 2016] or correct even [Sun Feb 14 14:51:45 2016] lingxiao i got 4 constructors [Sun Feb 14 14:51:59 2016] hmm what were your cases? [Sun Feb 14 14:52:01 2016] you dont need the nils [Sun Feb 14 14:52:14 2016] yeh its a combo of the other two right? [Sun Feb 14 14:52:19 2016] yes [Sun Feb 14 14:52:39 2016] hm ok i'll get rid of that [Sun Feb 14 14:52:43 2016] and not sure if the l1 = l -> is useful [Sun Feb 14 14:53:19 2016] but does by x_eq_z and z_neq_z cases look helpful? [Sun Feb 14 14:53:23 2016] or correct i mean [Sun Feb 14 14:53:35 2016] hmm how do you approach doing these? [Sun Feb 14 14:53:36 2016] and i dont get your last two constructors, why do you cons int he first term? [Sun Feb 14 14:53:46 2016] becuase I just write out a regular function returning a boolean first [Sun Feb 14 14:53:48 2016] iom_cons1 : ∀ x l1 l2 l, in_order_merge l1 l2 l -> in_order_merge (x :: l1) l2 (x :: l) [Sun Feb 14 14:53:51 2016] thats what i used [Sun Feb 14 14:53:53 2016] then translate it back into prop [Sun Feb 14 14:54:55 2016] oh much better stated haha [Sun Feb 14 14:55:33 2016] | iom_nil1 : ∀ l, in_order_merge [] l l [Sun Feb 14 14:56:06 2016] maybe yours is more useful in coq, i dont know [Sun Feb 14 14:56:59 2016] and to proof it i used that the length of filter f l is less than or equal to the length of l [Sun Feb 14 14:57:09 2016] but maybe you can just do induction on the length of l [Sun Feb 14 14:57:09 2016] no luck proving stuff with it so so far not useful [Sun Feb 14 15:02:10 2016] lingxiao not with induction? [Sun Feb 14 15:02:29 2016] oh i mean my construction of in_order_merge [Sun Feb 14 15:02:34 2016] with tings like x = y [Sun Feb 14 15:02:41 2016] i didnt realize you can just write x twice haha [Sun Feb 14 15:05:12 2016] ok doing indction on the prop now in the proof [Sun Feb 14 15:06:09 2016] in this state: http://lpaste.net/152453 [Sun Feb 14 15:07:15 2016] Nik05 did you do induction on the def of In_order_merge at all? [Sun Feb 14 15:07:28 2016] yes [Sun Feb 14 15:07:34 2016] you can proof this right? [Sun Feb 14 15:07:46 2016] hm going thru it now. tbd haha [Sun Feb 14 15:08:05 2016] i think my proof is too long [Sun Feb 14 15:08:23 2016] this is where I am at now: http://lpaste.net/152454 [Sun Feb 14 15:08:30 2016] i think mine will be long too maybe [Sun Feb 14 15:08:51 2016] oh why? [Sun Feb 14 15:10:10 2016] not sure ... i'm about to do [destruct l] given this goal: filter test (x :: l) = filter test (x :: l1) [Sun Feb 14 15:10:18 2016] and a bunch of premises that I dont know how to use [Sun Feb 14 15:10:27 2016] i did a destruct on (test x) [Sun Feb 14 15:11:55 2016] ahh i see this as the goal: [ x :: filter test l = x :: filter test l1] [Sun Feb 14 15:27:54 2016] got it lingxiao ? [Sun Feb 14 15:29:03 2016] nope not yet still on that line haha [Sun Feb 14 15:30:57 2016] here : http://lpaste.net/152458 [Sun Feb 14 15:31:44 2016] lingxiao remove x :: from both sides [Sun Feb 14 15:31:52 2016] then aply the induction hypothesis [Sun Feb 14 15:32:11 2016] you need a lemma to remove the x right? [Sun Feb 14 15:32:25 2016] f_equal? [Sun Feb 14 15:38:24 2016] lingxiao do you see it?> [Sun Feb 14 15:39:09 2016] ahh very need [Sun Feb 14 15:39:11 2016] neat* [Sun Feb 14 15:40:19 2016] my ind hypo is this thougH; [Sun Feb 14 15:40:20 2016] IHin_order_merge : filter test l1 = l1 -> [Sun Feb 14 15:40:20 2016] filter test l2 = [] -> filter test l = l1 [Sun Feb 14 15:40:27 2016] so doesnt directly apply [Sun Feb 14 15:41:51 2016] why noy/ [Sun Feb 14 15:41:53 2016] not? [Sun Feb 14 15:42:50 2016] simpl in H2. destruct (test x) with test x -> True you can proof your goal with (test x -> False) you have a contradiction [Sun Feb 14 15:47:47 2016] how di you appy f_equal in [ H : x :: filter test l1 = x :: l1] though [Sun Feb 14 15:49:01 2016] ah nvm i just replaced it [Sun Feb 14 15:49:06 2016] ill worry about it later [Sun Feb 14 15:49:35 2016] wait no i didnt haha [Sun Feb 14 15:49:37 2016] oh boy [Sun Feb 14 15:49:42 2016] the syntax is very obtuse [Sun Feb 14 16:34:39 2016] im back ling oh gone [Sun Feb 14 16:35:56 2016] keeps happening [Sun Feb 14 16:45:07 2016] hey rrika [Sun Feb 14 16:45:19 2016] hi [Sun Feb 14 16:45:31 2016] what's new? [Sun Feb 14 16:46:23 2016] nothing cant proof it [Sun Feb 14 16:47:01 2016] talking about lingxiao's thing? [Sun Feb 14 16:47:11 2016] no my own :p [Sun Feb 14 20:28:38 2016] i keep seeing 'lingxiao' and thinking i tabbed to #Mandarin [Sun Feb 14 23:31:12 2016] hey does anyone know why I cant do this: http://lpaste.net/152483 [Sun Feb 14 23:31:34 2016] in the state above, i can't do [apply IHin_order_merge in H0] [Sun Feb 14 23:35:50 2016] or better yet in this proof state: http://lpaste.net/152484 [Sun Feb 14 23:36:01 2016] I'd like to turn H2 into [filter test l1 = l1] using [f_equal] [Sun Feb 14 23:36:04 2016] but how would I do it? [Sun Feb 14 23:59:11 2016] anyon around? [Mon Feb 15 03:11:15 2016] hello. Anyone using emacs & ProofGeneral? Is there a way how to create new line after issuing C-c C-n on a line before Qed.? Otherwise I have to do C-p to create new line and add indentation after every C-c C-n when writing a new proof. [Mon Feb 15 03:31:35 2016] I am actually using the electric mode, this might have easier solution. [Mon Feb 15 06:14:00 2016] ling* inversion H2.... [Mon Feb 15 11:03:32 2016] hey all [Mon Feb 15 11:03:42 2016] could someone help me with this proof? [Mon Feb 15 11:03:51 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1883 [Mon Feb 15 11:04:22 2016] it's disconcerning that I am not using icons1 and icons2 form [in_order_merge] in my proof [Mon Feb 15 11:04:41 2016] either I'm not seeing it or my construction of in_order_merge needs some tweaking [Mon Feb 15 11:05:11 2016] and the other case in [ filter_cons] should not occur but there's no contradiction that I can invert [Mon Feb 15 11:15:06 2016] lingxiao_: I'm not able to advance the state to that line. Which version of Coq are you using? [Mon Feb 15 11:15:30 2016] how do i check ianjneu? [Mon Feb 15 11:15:59 2016] coqtop -v [Mon Feb 15 11:16:15 2016] I'm using 8.4pl3 [Mon Feb 15 11:16:31 2016] updated link [Mon Feb 15 11:16:43 2016] 8.4pl6 [Mon Feb 15 11:16:49 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1876 [Mon Feb 15 11:17:07 2016] really my lack of confidence starts with in_order_merge [Mon Feb 15 11:17:23 2016] then it goes to [filter_cons], im not sure how to finish the admitted case [Mon Feb 15 11:18:01 2016] that case should not happen, but I can't find a way to state that using inversion [Mon Feb 15 11:18:19 2016] in the context i see this: http://lpaste.net/152509 [Mon Feb 15 11:18:37 2016] ie: so Hx and H are contradicting each other, but I dont know how to state that [Mon Feb 15 11:21:26 2016] ianjneu does [filter_cons] work for you? [Mon Feb 15 11:22:57 2016] No, I can't get the list notation to work o_O [Mon Feb 15 11:23:16 2016] oh i think it's because I have dependencies that specify the notatioin [Mon Feb 15 11:23:28 2016] changing the (::) to cons and [] to nil will work I believe [Mon Feb 15 11:26:14 2016] You'll probably want to prove something like In x l -> In x (filter test l) <-> test x = true [Mon Feb 15 11:27:02 2016] is this for filter_cons or filter_l? [Mon Feb 15 11:27:57 2016] Both [Mon Feb 15 12:02:19 2016] What is the simplest way to tell Coq that recursion should be on a subterm of an argument of the recursive calls? [Mon Feb 15 12:03:14 2016] You can't express that in the logic itself. [Mon Feb 15 12:03:36 2016] But you can create functional induction schemes from a Fixpoint definition, if that's what you want. [Mon Feb 15 12:05:21 2016] Yes, or I'm also happy to use the Program construct, if that helps [Mon Feb 15 13:12:01 2016] lingxiao inversion [Mon Feb 15 13:12:05 2016] before you are gone again :P [Mon Feb 15 13:12:49 2016] you had something like x :: foo = x :: bar, use inversion on it [Mon Feb 15 13:22:56 2016] and he is gone again :P [Mon Feb 15 13:59:08 2016] Hi Nik05 [Mon Feb 15 13:59:14 2016] inversion will tell from that that foo = bar [Mon Feb 15 14:00:23 2016] oh, you're telling linTghe [Mon Feb 15 14:00:32 2016] you're telling lingxiao [Mon Feb 15 14:02:26 2016] hi johnw [Mon Feb 15 14:02:29 2016] Hi Nik05 [Mon Feb 15 14:02:43 2016] yes lingxiao asked 2 days ago, and yesterday again [Mon Feb 15 14:02:43 2016] :P [Mon Feb 15 15:42:59 2016] How can I rename a term? I have a really hairy term, and just want to henceforth refer to it as "g". Is there a tactic like "name (x + y) as g"? [Mon Feb 15 15:47:08 2016] miles, there's "set" [Mon Feb 15 15:47:23 2016] I think "set (g := (x + y))" [Mon Feb 15 15:48:20 2016] miles, see https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic44 [Mon Feb 15 15:49:49 2016] oh you are my hero! thanks :) [Mon Feb 15 15:53:10 2016] hey rrika could you help me a bit more with the proof we had yesterday? [Mon Feb 15 15:53:28 2016] this one: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1875 [Mon Feb 15 15:55:29 2016] [19:08:37] lingxiao inversion [19:08:41] before you are gone again :P [Mon Feb 15 15:55:45 2016] gotta go shower, I hope ↑ helps [Mon Feb 15 15:56:08 2016] hey sorry ! I thought you left! [Mon Feb 15 16:08:48 2016] anyone know what to do in this proof state: http://lpaste.net/152542? [Mon Feb 15 16:09:19 2016] doing destruct H0 twice gives me two lists to use as witnesses, but applying them to the goal leads to wrong conclusions [Mon Feb 15 16:34:11 2016] lingxiao, where in IndProp? [Mon Feb 15 16:43:43 2016] hey rrika here it is: [Mon Feb 15 16:44:05 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L2126 [Mon Feb 15 16:44:13 2016] [in_split]. the last case [Mon Feb 15 16:46:38 2016] that doesn't look provable [Mon Feb 15 16:46:48 2016] that very last state I mean [Mon Feb 15 16:47:01 2016] yeah i think so too [Mon Feb 15 16:47:10 2016] so it boggles my mind that i can arrive at unprovable states [Mon Feb 15 16:47:17 2016] while doing nothing wrong in particular [Mon Feb 15 16:47:36 2016] does induction on l make sense? I can't think of another thing to induct on ... maybe In? [Mon Feb 15 16:47:51 2016] I'm currently checking if there are better values for the last two "exists" [Mon Feb 15 16:48:49 2016] except H is a function retrning a property ... not an inductive property [Mon Feb 15 16:49:22 2016] yeah, is that the point of the exercise? [Mon Feb 15 16:49:42 2016] (just curious, it seems worth practicing) [Mon Feb 15 16:50:14 2016] hm? no in_split seems almost like a throwaway easy thing to do, so i imagine it's not tehre to practice induction on props [Mon Feb 15 16:50:24 2016] there are many ones above that are for that purpose [Mon Feb 15 16:50:27 2016] and are freaking hard lol [Mon Feb 15 16:50:30 2016] okay, lingxiao [Mon Feb 15 16:50:45 2016] after the two exacts you need only three more steps to finish [Mon Feb 15 16:50:58 2016] oo wati what exact? [Mon Feb 15 16:51:03 2016] eh, exists [Mon Feb 15 16:51:04 2016] sorry [Mon Feb 15 16:51:22 2016] ok just to be sure I see this after two exists: [Mon Feb 15 16:51:27 2016] http://lpaste.net/152544 [Mon Feb 15 16:51:48 2016] you need to choose two different values [Mon Feb 15 16:52:30 2016] rrika before my exists? [Mon Feb 15 16:52:45 2016] or after the exists in the state as I see it .. [Mon Feb 15 16:52:49 2016] exists 1. exists 2. [Mon Feb 15 16:52:55 2016] '1' and '2' need to be changed. [Mon Feb 15 16:53:01 2016] is what I mean [Mon Feb 15 16:53:04 2016] ok great that makes sense [Mon Feb 15 16:53:17 2016] so we are at this state: http://lpaste.net/152545 [Mon Feb 15 16:54:18 2016] keep in mind that you don't have to aim for the goal being showable through reflexivity. [Mon Feb 15 16:54:25 2016] it's okay to rely on the assumtions you have in context [Mon Feb 15 16:54:31 2016] especially H0 [Mon Feb 15 16:54:34 2016] oo ok that's interesting havnt considered that .. [Mon Feb 15 16:54:43 2016] so H0 says l' = x0 ++ x :: x1 right? [Mon Feb 15 16:54:48 2016] yes [Mon Feb 15 16:55:55 2016] and goals says exists l1 l2. a :: l' = l1 ++ x :: l2 [Mon Feb 15 16:56:07 2016] yes [Mon Feb 15 16:56:16 2016] so that means : a :: (x0 ++ x :: x1) = l1 ++ x :: l2 [Mon Feb 15 16:56:25 2016] so a::x0 = l1 [Mon Feb 15 16:56:27 2016] x1 = l2 [Mon Feb 15 16:56:52 2016] basically [Mon Feb 15 16:56:55 2016] yes [Mon Feb 15 16:57:15 2016] got it! [Mon Feb 15 16:57:30 2016] thanks a lot! it really helps to talk this thru and get hints on what to focus on in context [Mon Feb 15 16:59:06 2016] btw rrika have you done NoDup ? [Mon Feb 15 16:59:19 2016] and where it says pick an interesting theoremo relationg disjoint nodup and ++ [Mon Feb 15 16:59:50 2016] my section of that look like this: http://lpaste.net/152546 [Mon Feb 15 16:59:56 2016] Doesn't exist in my copy of SF [Mon Feb 15 17:00:04 2016] hmm are you doing the most recent one? [Mon Feb 15 17:00:10 2016] or the one from 2013 [Mon Feb 15 17:00:23 2016] I think I downloaded the most recent one [Mon Feb 15 17:00:31 2016] not sure anymore [Mon Feb 15 17:00:33 2016] this one: http://www.seas.upenn.edu/~cis500/current/sf/IndProp.html [Mon Feb 15 17:00:38 2016] note the ..../current/.... [Mon Feb 15 17:00:56 2016] well, that seems to be your university's edition [Mon Feb 15 17:00:59 2016] it's a mess btw, it's like a live google doc. all these comments saying stuff doesnt belong or things are just dumped there [Mon Feb 15 17:01:03 2016] yeah haha ... sure is [Mon Feb 15 17:01:16 2016] and the comments really gives me confidence in the system [Mon Feb 15 17:02:15 2016] oh, I'm doing one from 2015 apparently [Mon Feb 15 17:02:18 2016] "version 3.2" [Mon Feb 15 17:02:27 2016] as opposed to your "version 4.0" [Mon Feb 15 17:03:37 2016] yeah it's like i'm doing some nonstable version or something [Mon Feb 15 17:03:41 2016] #cuttingEdge #foreFront [Mon Feb 15 17:03:49 2016] :( [Mon Feb 15 17:04:16 2016] where is the "official" one? [Mon Feb 15 17:04:30 2016] but yea let me know if you want to try it [Mon Feb 15 17:04:42 2016] it's a super fascinating problem i swear [Mon Feb 15 17:04:48 2016] here: http://www.seas.upenn.edu/~cis500/current/index.html#schedule [Mon Feb 15 17:04:54 2016] has all the latest ones [Mon Feb 15 17:05:07 2016] i noticed that given any link ot lecture: ie http://www.seas.upenn.edu/~cis500/current/sf/IndProp.html [Mon Feb 15 17:05:27 2016] if you just delete the bit in the url that says 2015 or w/e and put in current [Mon Feb 15 17:05:40 2016] you might end up with the current one if its released [Mon Feb 15 17:20:24 2016] rrika do you have the pigeon hole principle one in yours? [Mon Feb 15 17:21:31 2016] yes [Mon Feb 15 17:21:36 2016] but I haven't done any of these exercises yet [Mon Feb 15 17:26:44 2016] ok thanks! [Mon Feb 15 23:14:13 2016] hey all [Mon Feb 15 23:14:33 2016] how come I cannot destruct (beq_id x x') in this case? [Mon Feb 15 23:14:42 2016] http://lpaste.net/152572 [Mon Feb 15 23:14:52 2016] is it because x' is not in context? [Mon Feb 15 23:15:39 2016] proof here for anyone intersted : https://github.com/lingxiao/CIS500/blob/master/hw5/Maps.v#L248 [Mon Feb 15 23:25:40 2016] lingxiao: yes, because x' is not in context [Mon Feb 15 23:25:53 2016] more generally you cannot really work under binders very easily in coq [Mon Feb 15 23:26:22 2016] hmm ok i see [Mon Feb 15 23:26:28 2016] what's the startegy for this proof then? [Mon Feb 15 23:26:47 2016] map is defined as follows: Definition total_map (A:Type) := id -> A. [Mon Feb 15 23:26:53 2016] lingxiao: unfortunately that goal is not provable without axioms :( [Mon Feb 15 23:27:13 2016] hmm hint says use : functional extensionality axiom [Mon Feb 15 23:27:19 2016] lingxiao: well there you go :) [Mon Feb 15 23:27:28 2016] strategy is to use that axiom then [Mon Feb 15 23:27:35 2016] haha not sure how it applies though? [Mon Feb 15 23:27:46 2016] Axiom functional_extensionality : ∀{X Y: Type} [Mon Feb 15 23:27:46 2016] {f g : X → Y}, [Mon Feb 15 23:27:46 2016] (∀(x:X), f x = g x) → f = g. [Mon Feb 15 23:28:10 2016] I see here that f is t_update m x (m x) [Mon Feb 15 23:28:13 2016] and g is m [Mon Feb 15 23:28:14 2016] literally [apply functional_extensionality.] [Mon Feb 15 23:30:55 2016] ahh great now i'm at this state: http://lpaste.net/152573 [Mon Feb 15 23:31:34 2016] or backup , after applying that theorem we have this as the goal: [Mon Feb 15 23:31:35 2016] forall x0 : id, t_update m x (m x) x0 = m x0 [Mon Feb 15 23:32:14 2016] i do [intros x'. unfold t_update] and we have: [Mon Feb 15 23:32:23 2016] (if beq_id x x' then m x else m x') = m x' [Mon Feb 15 23:32:45 2016] yep [Mon Feb 15 23:33:13 2016] okay so when you destruct you're going to lose information [Mon Feb 15 23:33:42 2016] so either do [destruct (beq_id x x' eqn:Hfoo).] [Mon Feb 15 23:34:04 2016] or do [remember (beq_id x x') as b. destruct b.] [Mon Feb 15 23:34:19 2016] in either case you'll get an equation in your context that will help you [Mon Feb 15 23:34:26 2016] ahh got it! [Mon Feb 15 23:36:33 2016] Thanks! [Mon Feb 15 23:39:26 2016] any tips on thisone: [Mon Feb 15 23:39:39 2016] http://lpaste.net/152574 [Mon Feb 15 23:39:44 2016] theres no reason why the goal should be true [Mon Feb 15 23:39:56 2016] the proof: https://github.com/lingxiao/CIS500/blob/master/hw5/Maps.v#L278 [Mon Feb 15 23:41:47 2016] ping jrw [Mon Feb 15 23:43:04 2016] lingxiao: you have a contradiction in your context [Mon Feb 15 23:43:11 2016] because you have [x1 <> x2] [Mon Feb 15 23:43:26 2016] how does that contradict things? [Mon Feb 15 23:43:30 2016] but also (via the beq hypotheses and transitivity) [x1 = x2] [Mon Feb 15 23:43:53 2016] ahh Hb1 and Hb2 -> x1 = x2 [Mon Feb 15 23:44:10 2016] hmm how would i use this contradiction though? [Mon Feb 15 23:44:17 2016] so far I only know inversion ... [Mon Feb 15 23:44:28 2016] i guess i could do a bunch of rewrites ... [Mon Feb 15 23:45:16 2016] lingxiao: well for sure you're going to have to use a lemma that tells you that [beq a b = true -> a = b] [Mon Feb 15 23:45:35 2016] jrw yup i did that and now i see this: http://lpaste.net/152575 [Mon Feb 15 23:45:50 2016] after that, the most basic way to leverage a contradiction like this is to do [exfalso.] to convert your goal to False, and then [apply H.] where [H : a <> b] [Mon Feb 15 23:46:04 2016] and then [apply H'.] where [H' : a = b] [Mon Feb 15 23:46:17 2016] ok i'm still confused about that since iv used it [Mon Feb 15 23:46:26 2016] so I do exfalos, stating my goal is false right? [Mon Feb 15 23:46:27 2016] I believe SF has their own version of exfalso if you'd prefer to use that [Mon Feb 15 23:46:40 2016] lingxiao: no, not quite, it means "from False, anything follows" [Mon Feb 15 23:46:40 2016] yeah it's soem longer latin i cant remmeber haha [Mon Feb 15 23:46:48 2016] ex_falso_quod_libet probably [Mon Feb 15 23:47:06 2016] it means "from False, anything follows" :) [Mon Feb 15 23:47:19 2016] ahh cools [Mon Feb 15 23:47:25 2016] so no matter what your goal is, if you can prove False, you can prove your goal [Mon Feb 15 23:47:30 2016] so i apply [H : x <> x] to False [Mon Feb 15 23:47:35 2016] ok i see .. so that becomes x = x [Mon Feb 15 23:47:56 2016] ok i see the gist now thans! [Mon Feb 15 23:47:58 2016] remember that "a <> b" is defined to be [a = b -> False] [Mon Feb 15 23:48:13 2016] so your just applying that like normal [Mon Feb 15 23:48:24 2016] ahh so apply [ a = b -> False] False ===> a = b right? [Mon Feb 15 23:48:28 2016] ok cools [Mon Feb 15 23:48:30 2016] thansk! [Mon Feb 15 23:48:31 2016] if you have [H : A -> B] and a goal of [B] then [apply H] converts your goal to A [Mon Feb 15 23:48:34 2016] right [Mon Feb 15 23:48:43 2016] ok great explanation that actually cleared it up thank you! [Mon Feb 15 23:49:20 2016] np [Mon Feb 15 23:51:21 2016] btw jrw this statement is true right: [Mon Feb 15 23:51:23 2016] forall (X : Type) (test : X -> bool) (l : list X) (x : X), [Mon Feb 15 23:51:23 2016] filter test (x :: l) = x :: l -> filter test l = l. [Mon Feb 15 23:51:36 2016] yes [Mon Feb 15 23:51:42 2016] ok hewww haha [Mon Feb 15 23:52:13 2016] but you might not be able to prove it directly by induction [Mon Feb 15 23:52:17 2016] because i'm in this state for some reason and it's contradictory: http://lpaste.net/152576 [Mon Feb 15 23:52:20 2016] oh boy .. [Mon Feb 15 23:52:38 2016] I destructed (test x) [Mon Feb 15 23:52:45 2016] haven't we talked about this before? [Mon Feb 15 23:52:57 2016] heres the proof:https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1867 [Mon Feb 15 23:53:16 2016] i dont think so? [Mon Feb 15 23:53:22 2016] I wrote this today ... [Mon Feb 15 23:53:36 2016] i was trying to do this: [Mon Feb 15 23:53:38 2016] (* todo: seem to be taking the hard way around ... *) [Mon Feb 15 23:53:38 2016] Theorem filter_spec : forall (X : Type) (test : X -> bool) (l l1 l2 : list X), [Mon Feb 15 23:53:40 2016] in_order_merge l1 l2 l -> filter test l1 = l1 -> filter test l2 = [] -> [Mon Feb 15 23:53:42 2016] filter test l = l1. [Mon Feb 15 23:53:53 2016] errr .. that came out bad .. it's the next theorem in the link i provided [Mon Feb 15 23:54:16 2016] okay, I must have been chatting with someone else with the same question :) [Mon Feb 15 23:54:31 2016] yeah rrika was doing the same thing haha [Mon Feb 15 23:54:40 2016] anyway, the easiest way to get a contradiction there is to prove that fileter can't increase the length of the list [Mon Feb 15 23:54:41 2016] althoguh i dont really understand her proof so theres that [Mon Feb 15 23:55:03 2016] in other words, [length (filter p l) <= length l] [Mon Feb 15 23:55:07 2016] so bascially we should have [filter test l = x :: l = false] [Mon Feb 15 23:55:18 2016] or [filter test l = x :: l -> false ] [Mon Feb 15 23:55:19 2016] it implies False, yes. [Mon Feb 15 23:55:32 2016] (false is a boolean in coq; False is the proposition) [Mon Feb 15 23:55:43 2016] yup muscle memory slipped back in [Mon Feb 15 23:55:52 2016] believe it or not that's one of the few things i know about coq haha [Mon Feb 15 23:55:59 2016] noob otherwise [Mon Feb 15 23:55:59 2016] :) [Mon Feb 15 23:56:38 2016] so it does imply False, and the easiest way to prove that it does is to use that lemma about the length of a filter [Mon Feb 15 23:56:55 2016] because if you have that lemma, then you can apply it to get [S n <= n] [Mon Feb 15 23:57:20 2016] which implies False [Mon Feb 15 23:57:42 2016] now all that being said, I think your definition of in_order_merge is overly complex [Mon Feb 15 23:57:49 2016] and you are running into a lot of trouble because of that [Mon Feb 15 23:58:03 2016] ok but i cannot apply [leamm : length (filter p l) <= length l.] to [H filter test l = x :: l]? [Mon Feb 15 23:58:09 2016] and YES! That was my actual question [Mon Feb 15 23:58:19 2016] i feel like im stating it in a not so good manner [Mon Feb 15 23:58:24 2016] suggestions :) ? [Mon Feb 15 23:58:40 2016] i even wrote: (* todo: seem to be taking the hard way around ... *) [Mon Feb 15 23:59:11 2016] or i mean: (* todo: is this well stated? seems to be really hard to prove things with this *) [Mon Feb 15 23:59:24 2016] see jrw i just write the regular recursive function that returns a bool [Mon Feb 15 23:59:29 2016] and then translate it Prop [Mon Feb 15 23:59:41 2016] but i have no intution for what makes a well state prop otherwise [Tue Feb 16 00:00:32 2016] lingxiao: I think your two constructors l1_nil and l2_nil are redundant [Tue Feb 16 00:00:55 2016] I can replace them by starting with [nils] and building up a bunch of uses of either [icons1] or [icons2] [Tue Feb 16 00:00:58 2016] so i only need nils and icons1 and icons2 ? [Tue Feb 16 00:01:00 2016] yes [Tue Feb 16 00:03:21 2016] hmm but fi they're redudant they dont really do much right? [Tue Feb 16 00:03:42 2016] eg i didnt use l2_nil or l1_nil in my main proof at all [Tue Feb 16 00:04:12 2016] lingxiao: yeah but they make you have a bunch of extra cases when you induct [Tue Feb 16 00:04:24 2016] hmm i see [Tue Feb 16 00:04:45 2016] do you think my [in_order_merge] is sufficent with just nils and icons1 and icons2 then? [Tue Feb 16 00:05:30 2016] yes [Tue Feb 16 00:05:51 2016] but when i took the case out of my function b_inOrder below they fail the tests? [Tue Feb 16 00:07:04 2016] lingxiao: well your definition of b_inOrder isn't correct if you just delete the corresponding cases [Tue Feb 16 00:07:08 2016] you need to restructure the cons case [Tue Feb 16 00:07:21 2016] because you were overly aggressive in matching all three against cons [Tue Feb 16 00:07:35 2016] instead, only match the third one against cons, leaving the first two as variables [Tue Feb 16 00:08:10 2016] wait you mean so i should have: l1, l2, z :: l3' ? [Tue Feb 16 00:08:16 2016] but then what would z match against? [Tue Feb 16 00:11:16 2016] ok followed your advice and delete those two cases! [Tue Feb 16 00:11:31 2016] I'll rework my bool function until it works so I understand what you're saying [Tue Feb 16 00:13:13 2016] lingxiao: right, the point is that you can't know what z will match against. it could match against the head of either l1 or l2. but in the case it maches the head of l1, l2 could very well be nil, but your definition wouldn't allow that. [Tue Feb 16 00:13:40 2016] ahh i see, you mean after i delete the two redudance cases [Tue Feb 16 00:14:05 2016] so I should really just do match l3 with: [] => match l1 l2 with ... [Tue Feb 16 00:14:16 2016] z :: l3' => match l1 l2 with [Tue Feb 16 00:14:23 2016] or l3 is l in this case [Tue Feb 16 00:14:38 2016] so check l first, then on each branch check l1 and l2? [Tue Feb 16 00:19:19 2016] or I'm going to bed now but I'll think about what you said tomorrow! Thank you for all your help!! [Tue Feb 16 09:35:02 2016] hello, anyone using emacs and proofgeneral? [Tue Feb 16 10:57:06 2016] hey all [Tue Feb 16 10:57:10 2016] coudl someone walk me thru this proof? [Tue Feb 16 10:57:24 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1878 [Tue Feb 16 10:57:31 2016] it's day 3 now :( [Tue Feb 16 11:16:21 2016] actually that one i just did! [Tue Feb 16 11:17:11 2016] it's this one now: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1866 [Tue Feb 16 12:08:24 2016] hey all [Tue Feb 16 12:08:52 2016] anyone around? [Tue Feb 16 12:09:15 2016] and want to take a look at this: https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1862 [Tue Feb 16 12:52:01 2016] hey lingxiao [Tue Feb 16 12:52:03 2016] yes im here :P [Tue Feb 16 12:52:08 2016] oh great thanks! [Tue Feb 16 12:52:24 2016] yeah [filter_len] is really givingme a lot trouble! [Tue Feb 16 12:52:27 2016] lol same proof? :P [Tue Feb 16 12:52:39 2016] i already gave you the answer i think 4 days ago :P [Tue Feb 16 12:52:43 2016] just inversion [Tue Feb 16 12:53:29 2016] oh no this stateement: [filter test l = x :: l -> False.] [Tue Feb 16 12:53:33 2016] this is new .. [Tue Feb 16 12:53:37 2016] or kind of [Tue Feb 16 12:54:07 2016] what course is that CIS500? [Tue Feb 16 12:54:11 2016] yup [Tue Feb 16 12:54:25 2016] oh its the course from zdancewic [Tue Feb 16 12:54:27 2016] this is the state i see: http://pastebin.com/42TamR16 [Tue Feb 16 12:54:29 2016] ypu [Tue Feb 16 12:54:31 2016] yup* [Tue Feb 16 12:54:48 2016] I can [simpl.] here [Tue Feb 16 12:55:00 2016] thats a long course [Tue Feb 16 12:55:23 2016] yeah oh boy [Tue Feb 16 12:55:32 2016] and IndProp.v is a long doc [Tue Feb 16 12:55:37 2016] yeah :p [Tue Feb 16 12:55:45 2016] oh right its now called IndProp [Tue Feb 16 12:55:50 2016] oh huh wait [Tue Feb 16 12:55:57 2016] in mine its MoreLogic.v [Tue Feb 16 13:03:45 2016] fuck [Tue Feb 16 13:03:54 2016] i have overwritten my Prop.v.... [Tue Feb 16 13:03:55 2016] shit [Tue Feb 16 13:03:57 2016] ebverything gone [Tue Feb 16 13:04:04 2016] well i still got the .vo file :P [Tue Feb 16 13:05:09 2016] I should use git... [Tue Feb 16 13:07:17 2016] oh no! [Tue Feb 16 13:07:22 2016] yeah he changed a bunch of stuff this year [Tue Feb 16 13:07:40 2016] i changed Prop.v to PropInd.v [Tue Feb 16 13:07:49 2016] then i moved Prop.vo to PropInd.v .... oops [Tue Feb 16 13:08:20 2016] can i disassemble a vo file? :P [Tue Feb 16 13:10:35 2016] Oh Prop.v isnt that large in my version [Tue Feb 16 13:10:55 2016] oh maybe it is... [Tue Feb 16 13:22:19 2016] shit fuck [Tue Feb 16 13:22:30 2016] My complete Prop.v is gone [Tue Feb 16 13:41:55 2016] running recovery software... [Tue Feb 16 14:00:48 2016] ling i think i found it back on my harddisk :D [Tue Feb 16 14:02:09 2016] oke i got it back :) [Tue Feb 16 14:02:20 2016] luckely there is somethign as a journal in filesystems [Tue Feb 16 16:45:42 2016] hey does anyone know how I can get rid of this state? [Tue Feb 16 16:45:48 2016] which has a false coclusion in it: [Tue Feb 16 16:46:00 2016] http://lpaste.net/152604 [Tue Feb 16 16:47:38 2016] lingxiao: remember that false conclusions do you know good [Tue Feb 16 16:47:54 2016] when you see that your conclusion is false, you should get scared. your only hope is to find a contradiction in your hypotheses. [Tue Feb 16 16:48:18 2016] in this case, I don't see that you have one [Tue Feb 16 16:48:24 2016] yeah that's the issue :( [Tue Feb 16 16:48:40 2016] here's the proof: [Tue Feb 16 16:48:42 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1855 [Tue Feb 16 16:48:46 2016] [filter_len] [Tue Feb 16 16:48:48 2016] I know it's correct [Tue Feb 16 16:48:56 2016] Im just trying to find a way to prove it [Tue Feb 16 16:49:23 2016] I thought we already talked about this [Tue Feb 16 16:49:34 2016] but yeah, your statement of filter_len is not proveable directly by induction [Tue Feb 16 16:49:44 2016] you need to generalize [Tue Feb 16 16:49:55 2016] we did and im still struggling [Tue Feb 16 16:50:01 2016] im really struggling on this proof tbh [Tue Feb 16 16:50:12 2016] i feel like a chicken w/ my head cut off [Tue Feb 16 16:50:16 2016] haha [Tue Feb 16 16:50:28 2016] that means you're in a good place to learn something from this one :) [Tue Feb 16 16:50:54 2016] i dont know how to relate something like length (l) < length ( x:: l) to the actual bit of thing I have in my main theorem [Tue Feb 16 16:51:03 2016] yeah im def strugggling not sure about learning [Tue Feb 16 16:51:20 2016] lingxiao: okay why don't you try doing it as two lemmas [Tue Feb 16 16:51:29 2016] lingxiao, I was once stuck on a two star exercise for two days [Tue Feb 16 16:51:34 2016] so you've got the thing about length (filter p l) <= length l right? [Tue Feb 16 16:51:35 2016] always something to learn from it [Tue Feb 16 16:51:57 2016] no but i can put it back [Tue Feb 16 16:52:13 2016] and then you should prove a second lemma that says that filter p l = x :: l -> False [Tue Feb 16 16:53:26 2016] jrw suppose if i back up for a second and Im looking at this sate: http://lpaste.net/152605 [Tue Feb 16 16:53:41 2016] my goal contradicts my premis H, and premis H is wrong [Tue Feb 16 16:53:45 2016] how do I get out of here [Tue Feb 16 16:53:56 2016] we're going to show that H is wrong [Tue Feb 16 16:54:12 2016] because if I can do it w/o lemma : filter test l = x :: l -> False then that's great [Tue Feb 16 16:54:18 2016] yeaht that 's what im trying to do [Tue Feb 16 16:54:39 2016] tbh i think the problems im creating are due to my own stupididy and theres nothing to learn from this other than dont be stupid in this very particular case [Tue Feb 16 16:56:11 2016] or jrw better yet if we see this in the context: [ Hl1 : filter test (x :: l1) = x :: l1 ] [Tue Feb 16 16:56:34 2016] how do i change Hl1 to [filter test l1 = l1] [Tue Feb 16 16:56:40 2016] because that's all i really wanted to do. [Tue Feb 16 16:56:48 2016] and I think im creating so much problems for myself [Tue Feb 16 16:56:54 2016] also rrika if you know please chime in! [Tue Feb 16 16:57:11 2016] lingxiao: so I've already described a strategy that will do this [Tue Feb 16 16:57:25 2016] proceed just like you did to destruct the test [Tue Feb 16 16:57:38 2016] in the first case you did the right thing and reduced it like you wanted [Tue Feb 16 16:57:44 2016] you mean destruct the hyothesis Hl1? [Tue Feb 16 16:57:47 2016] in the second case, we're going to derive a contradiction [Tue Feb 16 16:57:50 2016] no [Tue Feb 16 16:59:00 2016] when you simpl in Hl1 you will get an if [Tue Feb 16 16:59:06 2016] then you destruct (test x) or something [Tue Feb 16 16:59:32 2016] jrw what do you mean 2dn step? [Tue Feb 16 16:59:54 2016] so we have Hl1 in the main proof [filter_spec] [Tue Feb 16 16:59:54 2016] youo're saying *dont* destruct there right [Tue Feb 16 17:02:49 2016] or you're saying get rid of filter len : filter test l = x :: l -> False. [Tue Feb 16 17:03:01 2016] and instead hav lemma : filter test l = x :: l -> False [Tue Feb 16 17:03:33 2016] wait that is filter_len!! [Tue Feb 16 17:04:01 2016] lingxiao: okay let me start from the beginning [Tue Feb 16 17:04:09 2016] yes plese [Tue Feb 16 17:04:39 2016] part of the problem is there are many ways of doing this [Tue Feb 16 17:04:51 2016] and you have asked several people over several days and gotten conflicting advice [Tue Feb 16 17:05:01 2016] and you have implemented some sort of union of these approaches [Tue Feb 16 17:05:04 2016] and it is very messy [Tue Feb 16 17:05:05 2016] yeah pretty much .. and I have no vision of how to go about it [Tue Feb 16 17:05:08 2016] yes i ag ree [Tue Feb 16 17:05:13 2016] or it must be the case [Tue Feb 16 17:05:25 2016] now all that being said, I don't want to do the exercise for you [Tue Feb 16 17:05:34 2016] I could show you what I mean by showing you a proof of this exercise [Tue Feb 16 17:05:38 2016] but that wouldn't be very fun [Tue Feb 16 17:05:54 2016] this one gave me tons of fun so far [Tue Feb 16 17:06:06 2016] tbh the fruastrating is that I'm not actually learning any new concepts [Tue Feb 16 17:06:14 2016] lingxiao: I promise you're learning :) [Tue Feb 16 17:06:16 2016] just a new way to state a lemma that's obv true, but not provable [Tue Feb 16 17:06:21 2016] it may not seem like it, but you are. [Tue Feb 16 17:06:27 2016] and there are inf any lemmas liek that [Tue Feb 16 17:06:32 2016] :\ i hope so [Tue Feb 16 17:06:35 2016] this is a perfect example of a true fact that is not directly proveable by induction [Tue Feb 16 17:06:39 2016] there are many such facts [Tue Feb 16 17:06:50 2016] you mean this fact : filter test l = x :: l -> False. [Tue Feb 16 17:06:53 2016] right [Tue Feb 16 17:07:12 2016] one of the most important skills in verification is being able to recognize those facts and also being able to come up with a different fact that is directly proveable by induction and implies the original fact [Tue Feb 16 17:07:19 2016] you are learning that skill [Tue Feb 16 17:08:08 2016] hm ok great thanks for that [Tue Feb 16 17:08:12 2016] at least it justifies the struggle [Tue Feb 16 17:08:14 2016] :) [Tue Feb 16 17:08:21 2016] okay [Tue Feb 16 17:08:31 2016] so all that meta-level discussion aside, where should we start? [Tue Feb 16 17:08:34 2016] so i need to find some Fact -> ( filter test l = x :: l -> False) [Tue Feb 16 17:08:39 2016] or i dont know tbh [Tue Feb 16 17:08:39 2016] yep [Tue Feb 16 17:08:43 2016] that's right [Tue Feb 16 17:08:57 2016] now, I have already proposed such a fact, do you remember? [Tue Feb 16 17:09:23 2016] too many have beeen suggested so not really: [Tue Feb 16 17:09:26 2016] something about length [Tue Feb 16 17:09:41 2016] exactly [Tue Feb 16 17:09:59 2016] Hi, I wondered if someone could point me to some resources to learning coq and/or other proof verification languages [Tue Feb 16 17:10:07 2016] my proposal is Fact : forall blah blah blah, length (filter p l) <= length l [Tue Feb 16 17:10:26 2016] homevillageness: welcome :) I recommend starting with "software foundations" if you want to learn coq [Tue Feb 16 17:10:36 2016] homevillageness: https://www.cis.upenn.edu/~bcpierce/sf/ [Tue Feb 16 17:10:38 2016] ok so say i have [length (filter p l) <= length l] [Tue Feb 16 17:10:59 2016] lingxiao: now your first job is to convince your self that that implies filter test l = x :: l -> False [Tue Feb 16 17:11:00 2016] then how do i use that in this context: http://lpaste.net/152607 [Tue Feb 16 17:11:08 2016] wait wait let's not get to code quite yet [Tue Feb 16 17:11:53 2016] so you're saying i should have statement: filter test l = x :: l -> false [Tue Feb 16 17:12:11 2016] Also, are there any libraries for general purpose mathematics, e.g. analysis, topology, group theory, algebra? [Tue Feb 16 17:12:17 2016] and use lemma : length (filter p l ) <= length l in the proof of statement above to show that? [Tue Feb 16 17:12:27 2016] lingxiao: yes that would work or you can do it in line. [Tue Feb 16 17:12:37 2016] lingxiao: but right now I want you to convince me that you've convinced yourself that it is true [Tue Feb 16 17:12:42 2016] just on an intuitive level [Tue Feb 16 17:12:45 2016] what is the reason? [Tue Feb 16 17:13:25 2016] homevillageness: yes, there are several. the most famous one is probably the mathematical components library. see http://math-comp.github.io/math-comp/ [Tue Feb 16 17:13:50 2016] length of filter test l is at most length of l [Tue Feb 16 17:13:51 2016] homevillageness: it has been used to verify the four color theorem of graph theory and the feit-thompson theorem of finite group theory. [Tue Feb 16 17:14:00 2016] and length of x :: l is S (length l) [Tue Feb 16 17:14:37 2016] lingxiao: exactly!!! [Tue Feb 16 17:14:42 2016] contradiction! [Tue Feb 16 17:14:57 2016] yeah i mean that's obivous but i dont know how to arrive at that using coq's magic encantations [Tue Feb 16 17:15:06 2016] okay that I'm happy to help with [Tue Feb 16 17:15:13 2016] which is pretty much what they are so far as im concnered modulo some shallow understanding [Tue Feb 16 17:15:21 2016] :) [Tue Feb 16 17:15:30 2016] ok so I'm loooking at this: [Tue Feb 16 17:15:43 2016] [filter_len filter test l = x :: l -> False.] [Tue Feb 16 17:16:06 2016] is this all in constructive logic or in classical logic? [Tue Feb 16 17:16:22 2016] the math comp? [Tue Feb 16 17:16:36 2016] jrw and this is my state: http://lpaste.net/152609 [Tue Feb 16 17:16:36 2016] homevillageness: mostly constructive I believe. [Tue Feb 16 17:17:37 2016] homevillageness: if you're interested in analysis, take a look at http://corn.cs.ru.nl/ as well [Tue Feb 16 17:17:44 2016] As I want to learn proof assistants/checkers as a tool for mathematics [Tue Feb 16 17:18:09 2016] My study is mostly in the geometry part of mathematics [Tue Feb 16 17:18:45 2016] So Algebraic geometry/topology and differential geometry [Tue Feb 16 17:18:46 2016] lingxiao: okay, first thing I would do is introduce the equality as a hypothesis using intros [Tue Feb 16 17:19:04 2016] So I will see a lot of analysis in the differential topology [Tue Feb 16 17:19:11 2016] ok jrw so im just left with false [Tue Feb 16 17:19:16 2016] as a goal [Tue Feb 16 17:19:35 2016] and inversion [H : filter test l = x :: l] doesnt do anyting [Tue Feb 16 17:19:57 2016] i can do induction l [Tue Feb 16 17:19:58 2016] lingxiao: right. okay now let's introduce a use of filter_len [Tue Feb 16 17:20:02 2016] lingxiao: no induction! [Tue Feb 16 17:20:21 2016] this is my prob, even though you said cant prove by induction i know of nothing else [Tue Feb 16 17:20:32 2016] whati what's filter_len? [Tue Feb 16 17:20:37 2016] the lemma [Tue Feb 16 17:20:40 2016] my filter_len is just : filter test l = x :: l -> False. [Tue Feb 16 17:20:47 2016] do you mean length (filter p l ) <= length l. [Tue Feb 16 17:20:50 2016] yes [Tue Feb 16 17:20:56 2016] sorry, that second one [Tue Feb 16 17:21:00 2016] ok how do i introduce that [Tue Feb 16 17:21:02 2016] lingxiao: to use the lemma you can say something like [assert (length (filter test l) <= length l)] [Tue Feb 16 17:21:09 2016] and then apply the lemma [Tue Feb 16 17:21:54 2016] ok i did it [Tue Feb 16 17:22:16 2016] now i have this: http://lpaste.net/152612 [Tue Feb 16 17:22:20 2016] which is where i satarted [Tue Feb 16 17:22:44 2016] w/ the lemma now in context [Tue Feb 16 17:23:09 2016] great [Tue Feb 16 17:23:22 2016] now [rewrite H in H0] [Tue Feb 16 17:23:40 2016] why does that work? [Tue Feb 16 17:23:49 2016] oh wait i see why [Tue Feb 16 17:24:13 2016] ok i did that and simpl [Tue Feb 16 17:24:22 2016] and i have [S (length l) <= length l] [Tue Feb 16 17:24:24 2016] yay [Tue Feb 16 17:24:30 2016] which is obv false but inverting it gets me nowhere [Tue Feb 16 17:24:34 2016] right [Tue Feb 16 17:24:39 2016] this is what i mean by magic [Tue Feb 16 17:24:41 2016] okay now I don't know what kind of lemmas you have about <= [Tue Feb 16 17:25:50 2016] hmm none that seem useful [Tue Feb 16 17:26:06 2016] okay, well let's prove a new one that says [forall n, S n <= n -> False] [Tue Feb 16 17:27:07 2016] it's kind of fraustrating that there isnt an obvious way to get just say contradiciton [Tue Feb 16 17:27:50 2016] jrw, thanks for the pointers. I will be reading the book and taking a closer look at those libraries [Tue Feb 16 17:28:34 2016] homevillageness: unfortunately I think the state of the art in formalizing geometry is not great. I found this paper http://arxiv.org/pdf/1201.3731.pdf and this elementary library http://geocoq.github.io/GeoCoq/ [Tue Feb 16 17:29:36 2016] Maybe I can add something there. I saw a topology library but it did not compile with the instructions given in the git readme [Tue Feb 16 17:30:32 2016] homevillageness: coq versions in general are not forwards or backwards compatible, so if the library is at all older, you'll need to compile it with the version of coq they need [Tue Feb 16 17:31:01 2016] lingxiao: I feel you that it can be frustrating, but just remember how stupid Coq is. the only contradiction it knows about is literally a proof of False. [Tue Feb 16 17:31:18 2016] lingxiao: so it's not so hard to see why it doesn't know what to do with S n <= n [Tue Feb 16 17:31:34 2016] ok and im stupid since i cant even proove that [Tue Feb 16 17:31:50 2016] stuckin this stat: http://lpaste.net/152613 [Tue Feb 16 17:32:42 2016] I want to say [S (S n) <= S n -> S n <= n ] [Tue Feb 16 17:32:46 2016] but again no lemmas for that either [Tue Feb 16 17:33:05 2016] its silly that its called a proof assistant becuase so far it's beena proof resistant [Tue Feb 16 17:33:08 2016] That might explain, this is for coq 8.4 and my installation is the 8.5 [Tue Feb 16 17:33:53 2016] the libary I found was: https://github.com/dschepler/coq-topology [Tue Feb 16 17:39:09 2016] lingxiao: okay prove that as a lemma too :) [Tue Feb 16 17:39:24 2016] jrw i feel like im going down the 'wrong' path [Tue Feb 16 17:39:34 2016] i shouldnt have to build the house to prove one little thing [Tue Feb 16 17:40:54 2016] lingxiao: okay well I should mention that in practice you would have all these lemmas about <= already [Tue Feb 16 17:41:08 2016] lingxiao: the other thing is that you formalized filter_spec differently than I would have [Tue Feb 16 17:41:16 2016] I want to say [S (S n) <= S n -> S n <= n ] [Tue Feb 16 17:41:22 2016] these is such a thing in the standard library [Tue Feb 16 17:41:33 2016] rrika: yeah but he's doint SF [Tue Feb 16 17:41:39 2016] rrrika how did you formalize it [Tue Feb 16 17:41:43 2016] they have their own redefinition of le [Tue Feb 16 17:41:54 2016] and it's woefully incompletee [Tue Feb 16 17:42:01 2016] jrw, I'm using lingxiao's copy of SF [Tue Feb 16 17:42:06 2016] and proof general reported to me [Tue Feb 16 17:42:11 2016] that it has such a theorem available [Tue Feb 16 17:42:24 2016] great! then lingxiao should use it [Tue Feb 16 17:42:28 2016] just C-C C-A C-A for 'le' [Tue Feb 16 17:42:34 2016] what is the name of the lemma? [Tue Feb 16 17:42:34 2016] I just figured it wasn't there because lingxiao said it wasn't [Tue Feb 16 17:42:38 2016] because I see 10000000000 lemmas [Tue Feb 16 17:42:42 2016] me too [Tue Feb 16 17:42:43 2016] scroll [Tue Feb 16 17:42:49 2016] and rrika how did you formalize it? [Tue Feb 16 17:42:53 2016] okay, hint, it has an "lr_" prefix [Tue Feb 16 17:42:54 2016] *ke [Tue Feb 16 17:42:56 2016] *le [Tue Feb 16 17:42:57 2016] because maybe that's whats giving me trouble [Tue Feb 16 17:43:06 2016] lingxiao, I only have that helper theorem so far [Tue Feb 16 17:43:13 2016] I want to say [S (S n) <= S n -> S n <= n ] [Tue Feb 16 17:43:16 2016] oops [Tue Feb 16 17:43:26 2016] for filter_spec, I would have said something like (forall x, In x l1 -> test x = true) instead of filter test l1 = l1 [Tue Feb 16 17:43:27 2016] clipboard error [Tue Feb 16 17:43:28 2016] filter_spec i mean [Tue Feb 16 17:43:41 2016] I have: length (filter test l) <= length l. [Tue Feb 16 17:44:02 2016] [filter_spec] ?? [Tue Feb 16 17:44:20 2016] thats the one thats says if l1 pass the filter and non of l2 passes then filter l = l1 [Tue Feb 16 17:44:24 2016] where l = l1 ++ l2 [Tue Feb 16 17:44:50 2016] lingxiao, what's the current state? [Tue Feb 16 17:45:04 2016] of what? [Tue Feb 16 17:45:05 2016] trying to get from Sx <= Sy to x<=y still? [Tue Feb 16 17:45:30 2016] yeah pretty much [Tue Feb 16 17:45:43 2016] wait how did you formalize filter_spec? [Tue Feb 16 17:45:52 2016] it's not: [Tue Feb 16 17:45:54 2016] in_order_merge l1 l2 l -> filter test l1 = l1 -> filter test l2 = [] -> [Tue Feb 16 17:45:55 2016] filter test l = l1. [Tue Feb 16 17:48:08 2016] and rrika i dont see anything with an lr prefix [Tue Feb 16 17:48:35 2016] I'm sorry "le_" [Tue Feb 16 17:48:48 2016] typo [Tue Feb 16 17:48:50 2016] this one: le_Sn_le: forall n m : nat, S n <= m -> n <= m [Tue Feb 16 17:48:51 2016] ? [Tue Feb 16 17:49:08 2016] for example [Tue Feb 16 17:49:13 2016] there are many similar ones [Tue Feb 16 17:49:34 2016] there's le_S_n. [Tue Feb 16 17:49:44 2016] there's le_n_S. [Tue Feb 16 17:50:20 2016] ok that one worked heww .. [Tue Feb 16 17:51:40 2016] andwhat's the strategy in this caes: http://lpaste.net/152614 [Tue Feb 16 17:51:51 2016] i cant do rewrite since i have a <= not an = [Tue Feb 16 17:52:01 2016] and saying n1 <= n2 -> n1 = n2 \/ n1 < n2 [Tue Feb 16 17:52:02 2016] doesnt help [Tue Feb 16 17:52:18 2016] since i have to show the second case n1 < n2 which cant be shown [Tue Feb 16 17:52:35 2016] lingxiao: that's another lemma. [Tue Feb 16 17:52:38 2016] :D [Tue Feb 16 17:52:47 2016] im saying : n1 <= n2 -> n1 = n2 \/ n1 < n2 [Tue Feb 16 17:52:49 2016] doesnt help me [Tue Feb 16 17:53:01 2016] no but in your lpaste [Tue Feb 16 17:53:06 2016] I think you can use the lemma le_n_S [Tue Feb 16 17:56:24 2016] ahh got it! but why cant' i use reflesxivity in this case: http://lpaste.net/152616 [Tue Feb 16 17:56:31 2016] length l' <= S (length l') [Tue Feb 16 17:57:43 2016] lingxiao: reflexivity is for proving [e = e] [Tue Feb 16 17:57:50 2016] and for nothing else [Tue Feb 16 17:58:01 2016] (this is not quite true, but it's a good first order approximation) [Tue Feb 16 17:58:16 2016] so if an inequality is obv true how should i prove it? [Tue Feb 16 17:59:08 2016] aside from induction on l in this case [Tue Feb 16 17:59:10 2016] lingxiao, I found all theorems I needed for "le" in the search [Tue Feb 16 17:59:43 2016] so i can read length l' <= S (length l') as n <= S n right? [Tue Feb 16 17:59:47 2016] since they have the same type [Tue Feb 16 17:59:54 2016] no [Tue Feb 16 17:59:55 2016] but [Tue Feb 16 17:59:58 2016] is that how aply works? [Tue Feb 16 18:00:01 2016] there are therems that take an argument [Tue Feb 16 18:00:14 2016] apply will figure it out for you [Tue Feb 16 18:00:15 2016] so [Tue Feb 16 18:00:27 2016] it's just "apply theorem_name." [Tue Feb 16 18:00:39 2016] where theorem has the type [Tue Feb 16 18:00:40 2016] forall n : nat, n <= S n [Tue Feb 16 18:01:53 2016] oh so le_n_Sn [Tue Feb 16 18:02:04 2016] yes [Tue Feb 16 18:02:05 2016] so there needs to be a theorem for that .. [Tue Feb 16 18:02:12 2016] what does reflexivity do [Tue Feb 16 18:02:19 2016] just check they are syntacitcally equal? [Tue Feb 16 18:02:22 2016] w/o doing any computations? [Tue Feb 16 18:02:24 2016] apply (forall a: a = a). [Tue Feb 16 18:02:32 2016] ah [Tue Feb 16 18:02:35 2016] not quite [Tue Feb 16 18:02:46 2016] but basically if your goal has the form "a = a", it will remove the goal from the stack [Tue Feb 16 18:03:04 2016] it does simplifications before [Tue Feb 16 18:03:25 2016] imagine doing simpl. and then syntactic equality [Tue Feb 16 18:03:46 2016] ok i see [Tue Feb 16 18:03:59 2016] ok ifnally finished [Tue Feb 16 18:04:16 2016] but w/o triumph since i got so much help and it still took me so long :( [Tue Feb 16 18:04:44 2016] :/ well, there's others exercises still [Tue Feb 16 18:05:09 2016] haha yeah im on pigeon hole now [Tue Feb 16 18:05:17 2016] this one really was the hardest for me by far [Tue Feb 16 18:06:30 2016] but thank you rrika and jrw! [Tue Feb 16 18:06:35 2016] Im going to take a break from all this [Tue Feb 16 18:06:45 2016] coudlnt have done it w/o you guys! [Wed Feb 17 00:36:14 2016] hey guys, I'm having trouble using list_scope. I have `Open Scope list_scope` in my file, but when I try to write for example `Check [1]` I get 'Syntax error: [constr:lconstr] expected after 'Check' (in [vernac:check_command]).' [Wed Feb 17 00:36:57 2016] (and similar syntax also doesn't work) [Wed Feb 17 00:39:15 2016] you also need: Import ListNotations. [Wed Feb 17 00:39:35 2016] the list notations are hidden in a sub-module of the List library [Wed Feb 17 00:39:47 2016] ahh, sweet yeah that did it [Wed Feb 17 00:40:01 2016] thanks! [Wed Feb 17 00:40:03 2016] that's a pretty common practice [Wed Feb 17 00:40:12 2016] there are other notations that do this too, although not all do [Wed Feb 17 00:41:48 2016] good to know. Scopes are kinda confusing to me [Wed Feb 17 00:42:01 2016] what do you find confusing about them? [Wed Feb 17 00:42:34 2016] Well I guess the notation system in general. I'm just not that familiar with it [Wed Feb 17 00:42:50 2016] ah [Wed Feb 17 00:43:21 2016] it allows you to extend Coq's syntax, with extension confined to "scopes" that might automatically apply depending on the context [Wed Feb 17 00:44:12 2016] It's pretty miraculous actually. I've written a lot of parsers but I wouldn't know how to write something like the Coq parser, which is arbitrarily extendable [Wed Feb 17 00:44:36 2016] yeah, I haven't encountered extensible parsers like this in the wild before either [Wed Feb 17 00:45:11 2016] It seems like it'd be pretty easy to break the parser by writing some notations that, e.g. have mismatched parentheses, overload some keywords, etc [Wed Feb 17 00:45:25 2016] sure, you can write notations that make normal code fail to parse [Wed Feb 17 00:45:29 2016] that's not even hard to do :) [Wed Feb 17 00:45:36 2016] haha yeah seems like it [Wed Feb 17 11:04:43 2016] 22:46 < lingxiao> http://lpaste.net/152604 [Wed Feb 17 11:04:45 2016] heatsink pasted “Proof with existentials” at http://lpaste.net/152662 [Wed Feb 17 11:04:47 2016] 22:48 < jrw> in this case, I don't see that you have one [Wed Feb 17 11:04:56 2016] the Hypothesis H is a contradiction [Wed Feb 17 11:06:39 2016] I'm having trouble writing proofs involving existentials. I wrote a proof term for this one. I'd like to know how to solve it uisng the proof language. [Wed Feb 17 11:09:13 2016] heatsink : in general, a match corresponds to a destruct, so your first match would be equivalent to "destruct (IHa1 l) as [m m1]." [Wed Feb 17 11:09:18 2016] likewise for the second match [Wed Feb 17 11:10:16 2016] Then, you use the "ex_intro" constructor to prove the existential. The tactic "exists" is a facility to do just this, so the equivalent way to do it would be to write "exists n." ('n' being your witness), then to prove that your witness is indeed correct [Wed Feb 17 11:10:47 2016] This last proof is your "R_Compose m1 m2", so you can then conclude with "exact (R_Compose m1 m2)" for instance [Wed Feb 17 11:11:27 2016] Great, thanks! [Wed Feb 17 11:12:46 2016] I didn't think of using destruct. Then I couldn't do the later steps because they use those existential variables. [Wed Feb 17 11:13:01 2016] So, destruct does a match. [Wed Feb 17 11:14:11 2016] yup [Wed Feb 17 13:56:35 2016] Nik05: right, good point! [Wed Feb 17 13:57:35 2016] but since he was in the middle of trying to prove length (filter p l) = S (length l) is a contradiction, I'm not sure how much help it would have been [Wed Feb 17 13:57:46 2016] I think he figured it out by another way though [Thu Feb 18 00:39:58 2016] How do you find out what a tactic like `trivial` did under the hood? For example, if I simply have to prove `True` and use the `trivial` tactic, but want to know what tactic might be more specific. [Thu Feb 18 09:53:21 2016] miles: you can use `info trivial' or `info_trivial' [Thu Feb 18 09:53:52 2016] or Show Proof could help [Thu Feb 18 13:12:41 2016] miles: the most specific in that case would be "exact I" (capital i) [Thu Feb 18 18:04:58 2016] jgross: hi :) [Thu Feb 18 20:19:48 2016] morphism_preserves_identity : morphism_functor (monoid_identity domain_monoid) = monoid_identity codomain_monoid [Thu Feb 18 20:19:52 2016] Maybe I'm being a little verbose here. [Thu Feb 18 20:22:02 2016] hi tswett [Thu Feb 18 20:22:10 2016] (That should be morphism_function, not morphism_functor.) [Thu Feb 18 20:22:12 2016] Hi johnw. [Thu Feb 18 20:22:22 2016] you'll find explicit terms mostly easy to write, until you need to deal with rewriting or dependently-typed terms [Thu Feb 18 22:52:05 2016] anyone have git proof general working with use-package? [Thu Feb 18 22:52:31 2016] it's loading coq mode, but I think the generic stuff isn't getting loaded [Thu Feb 18 22:52:44 2016] like none of the proof-foo commands are available [Fri Feb 19 08:54:54 2016] enolan: I actually just realized mine was broken, but it seems to be working now. here’s the relevant part of my config https://github.com/cocreature/dotfiles/blob/master/emacs/.emacs.d/emacs.org#proofgeneral [Fri Feb 19 12:22:58 2016] Hi all, I'm having a weird problem like this: The term "Ha0" has type "I a = I P" while it is expected to have type "I a = I P". [Fri Feb 19 12:23:19 2016] Has anyone seen something like that before? Is there any way to print less-sugared type or something? [Fri Feb 19 12:34:03 2016] There are a lot of options such as "Set Printing Notations.", "Set Printing All.", "Set Printing Implicit." and so on [Fri Feb 19 12:34:26 2016] Your IDE can probably do that too (especially if you're using CoqIDE, these commands won't work, you have to use the "View" menu) [Fri Feb 19 12:36:49 2016] Cypi: thanks! [Fri Feb 19 12:37:41 2016] Now I can see those equalities are of different universes, which doesn't make much sens to me but at least it's something :) [Fri Feb 19 15:02:21 2016] dogui: if they are in different universes, it mean they are not both terms at the same level [Fri Feb 19 15:02:32 2016] for example "nat" and "Set" cannot be compared [Fri Feb 19 15:02:42 2016] even though they are both types, and there terms of a higher level, they are not terms at the same level [Fri Feb 19 15:02:48 2016] s/there/therefore [Fri Feb 19 15:24:31 2016] how do I import a module with a conflicting notation? I don't want the notations in the module, just the definitions [Sat Feb 20 14:53:39 2016] do many people use opam to install coq libraries? [Sat Feb 20 15:14:54 2016] I don't, I use Nix [Sat Feb 20 15:34:05 2016] johnw: hm, thanks. will have to try Nix at some point, heard a lot of good things [Sat Feb 20 15:52:15 2016] I do most of the Coq-related packaging in Nix, so let me know if there are problems [Sun Feb 21 13:20:27 2016] What is a "binder"? Or where can I find good introductory documentation on binders. [Sun Feb 21 13:21:32 2016] miles: something that binds a variable [Sun Feb 21 13:25:49 2016] benzrf: Ok, thanks. I'm looking at Record's grammar. Do you happen to know why there is a difference between "binder" and "ident [Sun Feb 21 13:25:55 2016] " as grammar rules? [Mon Feb 22 06:28:25 2016] there was a way of search for relevant lemmas/thorems in proof general, can't find it for some reason [Mon Feb 22 06:38:48 2016] hi [Mon Feb 22 06:39:06 2016] What is "the" proper way to represent categories in Coq? [Mon Feb 22 06:39:31 2016] and/or subsets of categories, and full subsets in particular [Mon Feb 22 06:46:45 2016] I see Adam Chlipala seems to have one of the many category theory coq theories [Mon Feb 22 07:37:23 2016] Fare: what do you mean by subsets of categories? [Mon Feb 22 07:38:58 2016] I would say that *a* proper way to represent categories would be to use typeclasses, like I did: http://repos.covariant.me/browse?r=cat;a=tree [Mon Feb 22 07:39:05 2016] but the HoTT library for example uses records [Mon Feb 22 08:18:11 2016] notdan: an arbitrary subset of arrows in a category. [Mon Feb 22 08:20:48 2016] what's that backquote notation? [Mon Feb 22 08:22:11 2016] (I haven't use Coq in 10 years) [Mon Feb 22 08:26:16 2016] * goes read about Type Classes in Coq... [Mon Feb 22 08:54:01 2016] hi. from what coq version on, deeper nestings than +, - and * (I think I've seen ++, --, **, etc.) are supported? [Mon Feb 22 09:02:37 2016] 8.5 [Mon Feb 22 09:02:50 2016] 8.4 only has 1 char bullets (but {} which is probably better?) [Mon Feb 22 09:37:00 2016] chris2: what's {}? (I always use [ | ... | ] which is not convenient at all.) [Mon Feb 22 09:42:22 2016] groups bullets? [Mon Feb 22 09:46:50 2016] chris2: hm? [Mon Feb 22 09:47:01 2016] for nesting [Mon Feb 22 09:47:09 2016] } errors if not all goals are done [Mon Feb 22 09:47:17 2016] ok. [Mon Feb 22 09:47:25 2016] can I use + inside { ... } ? [Mon Feb 22 09:47:28 2016] yes [Mon Feb 22 09:47:31 2016] ok [Mon Feb 22 09:47:37 2016] never seen this. [Mon Feb 22 09:47:40 2016] *tries* [Mon Feb 22 09:47:42 2016] also 8.4 iirc [Mon Feb 22 09:48:02 2016] (well, I try it as soon as I slaughtered the last subgoal now ...) [Mon Feb 22 09:49:18 2016] chris2: can {} be used in interactive mode? (because that was one advantage of just nesting +, ... ) [Mon Feb 22 09:49:35 2016] no idea, but i guess it does [Mon Feb 22 09:56:23 2016] Does coq have true(coherent) typeclasses like haskell? I've heard that it doesn't, but i don't know for sure. [Mon Feb 22 10:02:01 2016] https://gist.github.com/dredozubov/647ccf8634f5da975f47 i get this from `Info 1 auto` with coq 8.5 [Mon Feb 22 10:02:15 2016] does it seem like a proof general issue? I have no clue. [Mon Feb 22 10:09:31 2016] Well. Still not understand why all dependent literatures introduce sigma type and pi type as if they are symmetry and primitive. [Mon Feb 22 10:10:44 2016] while sigma is representable by pi, moreover functional type seems more primitive than existential type. [Mon Feb 22 10:18:07 2016] how do you represent sigma types using pi types ? [Mon Feb 22 10:32:55 2016] asmanur maybe I misunderstand the whole thing. but I saw coq standard lib has this: Inductive sig (A:Type) (P:A -> Prop) : Type := [Mon Feb 22 10:32:55 2016] 0811 exist : forall x:A, P x -> sig P. [Mon Feb 22 10:34:29 2016] riaqn: yes but here you are using inductive types as well [Mon Feb 22 10:34:59 2016] and inductive types are nothing but sigma types + sum types [Mon Feb 22 10:35:09 2016] (+ recursion) [Mon Feb 22 10:35:33 2016] asmanur but this definition doesn't use the other features [Mon Feb 22 10:35:49 2016] or it does? [Mon Feb 22 10:36:16 2016] it uses inductive types [Mon Feb 22 11:20:44 2016] Hi, I've successfully defined a custom induction principle (for Java Classes w.r.t. inheritance), P: class -> Prop, but I can't seem to define it for Type or Set. [Mon Feb 22 11:21:37 2016] From the examples in cpdt, it looks like the _ind and _rec principles are usually defined in terms of _rect, but I can't seem to do it that way [Mon Feb 22 11:22:25 2016] I have some hypothesis, such as "The ClassTable is well formed", that live in Prop [Mon Feb 22 11:23:42 2016] would I only be able to define a recursion principle if I instead added these as conditions to the inductive ClassTable type? (Not really feasible, it's currently a list of pairs, and it'd be hard to redefine it now) [Mon Feb 22 11:25:42 2016] tbelaire : you can't in general define an induction principle into Set or Type if your inductive type lives in Prop [Mon Feb 22 11:26:05 2016] because you are not allowed to destruct something that lives in Prop to compute something that lives in Set or Type [Mon Feb 22 11:26:48 2016] ... and I need to destruct a proof of well formedness in my principle [Mon Feb 22 11:26:49 2016] ok [Mon Feb 22 11:28:19 2016] Is there a downside to trying to move everything to Set (not being possible is a downside) [Mon Feb 22 11:28:24 2016] would that solve this? [Mon Feb 22 11:28:38 2016] I'm not super clear on the distinction [Mon Feb 22 11:29:00 2016] Is it only for the ability to strip proofs from progorams? [Mon Feb 22 11:29:07 2016] or is it more meaningful? [Mon Feb 22 11:30:41 2016] I'm not very clear on that myself :/ . Prop brings impredicativity, which can be useful. In your case you could probably lift everything to Type, but it sure looks better to keep separated what is to be computed from that which only serves for proofs [Mon Feb 22 11:31:10 2016] Are you sure that you actually need to define your induction principle into Type/Set? [Mon Feb 22 11:31:39 2016] Hmm, unless I misunderstood your initial question. [Mon Feb 22 11:39:42 2016] Not really sure yet [Mon Feb 22 11:40:30 2016] I think I wanted to do method lookup, and I think it'd be nicer if it's phrased with respect to the same induction principle [Mon Feb 22 11:41:28 2016] I also have a workaround to get `method` working, by first getting a list of ancestors, then doing a finite recursion on that list [Mon Feb 22 11:41:36 2016] but it's a pain to prove anything about [Mon Feb 22 12:05:18 2016] can i use "nested" bullets to structure proofs somehow? [Mon Feb 22 12:05:28 2016] yes [Mon Feb 22 12:05:30 2016] and braces [Mon Feb 22 12:05:32 2016] i'm getting Error: Wrong bullet - : Current bullet - is not finished. [Mon Feb 22 12:05:39 2016] use -, then + then * [Mon Feb 22 12:05:52 2016] braces reset the order [Mon Feb 22 12:05:54 2016] oh, cool [Mon Feb 22 12:06:10 2016] do you mean i have to use braces to go deeper? [Mon Feb 22 12:06:21 2016] than 3? yes [Mon Feb 22 12:06:25 2016] got it [Mon Feb 22 12:07:40 2016] i used to print relevant theorems somehow in PG and i can't remember how i did that [Mon Feb 22 12:08:11 2016] installed company-coq, got a lot of new toys, but still don't know how to get to the relevant stuff [Mon Feb 22 12:08:23 2016] C-s C-a C-a [Mon Feb 22 12:08:41 2016] do you mean C-c C-a C-a? [Mon Feb 22 12:08:47 2016] yes! [Mon Feb 22 12:09:29 2016] that's not it ;( [Mon Feb 22 12:09:46 2016] hmm [Mon Feb 22 12:10:06 2016] there was some magic hotkey that made me happy [Mon Feb 22 12:11:29 2016] I'm not sure what it would have been then [Mon Feb 22 12:12:43 2016] going through the PG documentation, it's the only way to find it again ;| [Mon Feb 22 12:15:58 2016] i'm probably mad, cant' seem to find anything more useful [Mon Feb 22 12:17:44 2016] can't* [Mon Feb 22 13:11:42 2016] i'm going through SF, not sure how to proceed further [Mon Feb 22 13:11:43 2016] https://gist.github.com/dredozubov/f273f2c966259d1e4cd8 [Mon Feb 22 13:12:09 2016] you need to generalize dependent n before doing your induction [Mon Feb 22 13:12:24 2016] (of m) [Mon Feb 22 13:12:35 2016] otherwise, you pin yourself into an unsolvable situation [Mon Feb 22 13:13:14 2016] plus, don't do double induction; only use induction for the outermost (m) [Mon Feb 22 13:13:36 2016] lastly, this is allowed synatx: rewrite A, B, C. [Mon Feb 22 13:17:12 2016] what do you mean by generalizing dependent n? don't introduce it with intros? [Mon Feb 22 13:17:34 2016] you have to un-introduce it [Mon Feb 22 13:17:37 2016] or, drops the "intros" line altogether [Mon Feb 22 13:18:52 2016] is there a tactic for un-introducing it or is done manually with asserts? [Mon Feb 22 13:19:04 2016] "generalize dependent n" [Mon Feb 22 13:19:18 2016] dredozubov, if you have (n m: nat), you can do "intros n m. … generalize dependent n." to only introduce m. but your case is easier [Mon Feb 22 13:20:34 2016] so it's basically the same as doing 'intros x m' in this case? [Mon Feb 22 13:20:52 2016] in this case, the same effect is achieved by just deleting your intros line altogether [Mon Feb 22 13:20:58 2016] johnw: it never occured to me i should do it literally :) [Mon Feb 22 13:22:33 2016] is there a rule of thumb on when i want to do intros? I tend to always do it >_> [Mon Feb 22 13:22:48 2016] "induction x" will auto-intro in everything up to x [Mon Feb 22 19:13:42 2016] Time to define some notations for equalities! [Mon Feb 22 19:14:22 2016] "at p in g p replace f x with y using my_theorem" [Mon Feb 22 19:32:16 2016] huh? [Mon Feb 22 19:32:34 2016] can you show me an example of when you'd use that? [Mon Feb 22 19:42:50 2016] You'd use that in the same place that you'd use "f_equal g my_theorem". [Mon Feb 22 19:43:14 2016] i'm just wondering whether setoid rewriting wouldn't be a lot easier [Mon Feb 22 19:45:22 2016] jgross: ping [Mon Feb 22 19:45:33 2016] Setoid rewriting? [Mon Feb 22 19:45:48 2016] tswett: yeah; can you show me an example hypothesis and goal where you would use your notation? [Mon Feb 22 19:46:35 2016] Axiom fx_y : f x = y. Axiom gy_z : g y = z. Goal g (f x) = z. [Mon Feb 22 19:46:51 2016] wouldn't that just be "congruence"? [Mon Feb 22 19:47:26 2016] Ah... [Mon Feb 22 19:47:37 2016] I never mentioned I'm not using the proof language. [Mon Feb 22 19:47:48 2016] that would really help :) [Mon Feb 22 19:48:24 2016] I guess the concise way to put that would be: "eq_trans (f_equal g fx_y) gy_z". [Mon Feb 22 19:48:55 2016] Which isn't necessarily hard to read. [Mon Feb 22 20:03:13 2016] There's got to be a way to come up with an expression by first writing an expression with holes in it, and then being given the types required to fill those holes—isn't there? [Mon Feb 22 20:07:08 2016] There's "Program". Is that the only way? [Mon Feb 22 20:07:53 2016] Inside a proof, refine also does that: it will generate as many subgoals as there are holes. [Mon Feb 22 20:08:09 2016] (but it is the proof language) [Mon Feb 22 20:08:16 2016] Program can be used with refine btw [Mon Feb 22 20:08:22 2016] Program Definition foo. [Mon Feb 22 20:08:25 2016] Otherwise, well, what's the matter with Program? :) [Mon Feb 22 20:08:27 2016] refine (my code _). [Mon Feb 22 20:08:29 2016] Defined. [Mon Feb 22 20:08:53 2016] the CPDT book uses this approach quite often [Mon Feb 22 20:10:50 2016] what does Program do [Mon Feb 22 20:11:48 2016] Program does kind of a lot. But in short... [Mon Feb 22 20:12:08 2016] Program lets you write code by defining functions first and proving that they work right later. [Mon Feb 22 20:12:43 2016] 'Error: Illegal application: The term "element_type" of type "Monoid -> Type" cannot be applied to the term "monoid2" : "Monoid" This term has type "Monoid@{Top.35}" which should be coercible to "Monoid@{Top.49}".' [Mon Feb 22 20:12:48 2016] Oh, good, my favorite kind of error. [Mon Feb 22 20:13:06 2016] "Set Universe Polymorphism." :-° [Mon Feb 22 20:13:14 2016] (but maybe you don't want it) [Mon Feb 22 20:13:41 2016] I have that written at the beginning of this module. [Mon Feb 22 20:13:53 2016] Ah. Well, sorry then. [Mon Feb 22 20:15:26 2016] Waitamo. [Mon Feb 22 20:15:36 2016] If I just use an underscore, Coq gives this error message... [Mon Feb 22 20:16:09 2016] 'Error: Cannot infer this placeholder of type "compose morphism2 morphism1 (identity monoid1) = identity monoid3" in environment: monoid3 : Monoid / monoid2 : Monoid / monoid1 : Monoid / morphism2 : Morphism monoid2 monoid3 / morphism1 : Morphism monoid1 monoid2 [Mon Feb 22 20:16:50 2016] That's exactly what I wanted in the first place! [Mon Feb 22 20:16:57 2016] I guess I overlooked it since it came in the form of an error message. [Mon Feb 22 20:19:58 2016] Ah. Sometimes it does not work well enough, so another trick for this is to define [Axiom magic : forall A, A.], and then write "magic _" wherever you want to put a hole. Then, when you Print the proof term, you see the type nicely written. [Mon Feb 22 20:20:13 2016] (I don't remember how the "Cannot infer this placeholder" error did not help though) [Mon Feb 22 20:21:19 2016] Huh. [Mon Feb 22 20:21:28 2016] Yeah, that'll work. [Mon Feb 22 20:21:50 2016] All right, so I want to define a notation that looks like this: 'focus' var 'at' expr 'with' proof [Mon Feb 22 20:22:03 2016] And another notation that looks like this: 'focus' var 'at' expr 'with' inner_proof 'endfocus' outer_proof [Mon Feb 22 20:22:37 2016] Coq doesn't like that. If I try to use the first notation, it expects the second notation to follow. [Mon Feb 22 20:23:20 2016] I could just add another token at the end of the first notation... at least, I think that will work. But I don't want to have to do that. [Mon Feb 22 20:24:35 2016] First, let me see if that will even work. [Mon Feb 22 20:25:17 2016] Yeah, that works fine. [Mon Feb 22 20:30:42 2016] Maybe what I'm trying to do just can't be done. [Tue Feb 23 01:56:36 2016] so where do I enter my Eval in CoqIde? [Tue Feb 23 01:57:09 2016] Days of the Week just tells me to do it, as though I know how. http://www.cis.upenn.edu/~bcpierce/sf/current/Basics.html [Tue Feb 23 02:03:13 2016] gfixler : just literally write "Eval ... ." in the text buffer [Tue Feb 23 02:04:49 2016] Cypi: ah, tried that and got a warning about not doing it :) [Tue Feb 23 02:06:42 2016] Indeed, but that's ok ^^ . You can also enter it in the query pane, which you can open with F1, iirc [Tue Feb 23 02:08:39 2016] got it working - thanks, Cypi [Tue Feb 23 05:11:44 2016] hi. so I have some axioms which I need to realize. they contain Prop-parts (as requirements), and I am not quite sure what their extracted type would be. is it possible to show the type of an extracted Axiom, that is, the type that a term would have to have to be correct in the extracted program as a realizer for an axiom? [Tue Feb 23 05:12:11 2016] as a mere guideline how to realize the axiom [Tue Feb 23 05:17:08 2016] Can't you just extract your axiom alone? [Tue Feb 23 05:18:04 2016] "Axiom foo : nat -> False -> nat. Extraction foo." gives me the following for instance: (** val foo : nat -> nat **) let foo = failwith "AXIOM TO BE REALIZED" [Tue Feb 23 05:37:32 2016] Cypi: yes. thx. [Tue Feb 23 05:37:39 2016] i didnt think of this. [Tue Feb 23 07:14:07 2016] asmanur: sorry that I didn't reply you last night. I came up with a sigma type implemented Pi type today. [Tue Feb 23 07:14:40 2016] ah? [Tue Feb 23 07:14:57 2016] asmanur: how about this? \Sigma_{x:A} B(x) = \Pi_{C:*} (\Pi_{x:A} B(x)->C) -> C [Tue Feb 23 07:15:42 2016] that is, it received a type C as return type, then it receive a function A->B->C, and apply two part of the sigma type to that function, and return the C. [Tue Feb 23 07:16:28 2016] iirc if you do that, you don't have all the computation rules [Tue Feb 23 07:16:41 2016] and your quantification over * is problematic [Tue Feb 23 07:16:52 2016] it means either it is prop (then Aand B(x) have to live in prop) [Tue Feb 23 07:16:57 2016] or you cannot eliminate to itself [Tue Feb 23 07:19:58 2016] asmanur: well.. I 'm not expert of coq, could you explain in more details? sorry if it sounds silly.. [Tue Feb 23 07:20:39 2016] with your encoding you cannot define A x B → B x A assuming B does not depend on A [Tue Feb 23 07:21:42 2016] for point (1) in coq you must have pair (pi1 t, pi2 t) = t [Tue Feb 23 07:21:50 2016] but you cannot derive this with your definitions [Tue Feb 23 07:26:12 2016] asmanur: for point 1, do you mean that we cannot get the type A and B from a Sigma type encoding in this way? [Tue Feb 23 07:28:49 2016] it seems more a violation to the convention of coq? or a violation to the type theory itself? [Tue Feb 23 07:38:18 2016] no, with your encoding [Tue Feb 23 07:38:19 2016] try to prove [Tue Feb 23 07:38:24 2016] pair (pi1 t, pi2 t) = t [Tue Feb 23 07:38:40 2016] you'll see that you cannot do it on the judgemental equality level [Tue Feb 23 07:41:00 2016] asmanur: thanks, I 'll check it. [Tue Feb 23 09:13:27 2016] What happens when I do the following: `Class bob : Type := bob_in : bob.`? I expected some sort of parsing error but I get `Error: Unbound reference: The reference 1 is free.` [Tue Feb 23 09:24:15 2016] i was checking out solutions to the SF and it seems that https://github.com/chrisbarrett/software-foundations/blob/master/Lists.v#L860 no longer works [Tue Feb 23 09:25:04 2016] looks like something changed with coq 8.5 in simpl/rewrite [Tue Feb 23 09:26:35 2016] i'm getting Error: Found no subterm matching "nonzeros (xs ++ 0 :: ys)" in the current goal. [Tue Feb 23 09:26:38 2016] any ideas why? [Tue Feb 23 09:32:46 2016] no idea, but that solution is more complicated than it needs to be [Tue Feb 23 09:34:12 2016] oh i proofed another lemma before it too simpify [Tue Feb 23 09:34:21 2016] dredozubov for me the proof works fine in 8.5 [Tue Feb 23 09:34:34 2016] weird [Tue Feb 23 09:34:39 2016] it doesn't for me [Tue Feb 23 09:37:54 2016] hmmm, if i copy the whole file then it works [Tue Feb 23 09:38:09 2016] if i check only one theorem, it doesn't [Tue Feb 23 17:05:00 2016] The link in the topic is pointing somewhere else I think [Tue Feb 23 17:05:34 2016] and 8.5 is out alread [Wed Feb 24 05:13:58 2016] is there a variant of rewrite tactic to target some specific subterm? [Wed Feb 24 12:15:22 2016] morning [Wed Feb 24 12:56:24 2016] dredozubov: in ssreflect there is [Wed Feb 24 12:56:30 2016] it has a very powerful rewriting syntax [Wed Feb 24 13:36:52 2016] jgross: ping [Wed Feb 24 13:49:23 2016] Hey all, I was wondering if there are any open source projects (preferably using coq) that deal with code synthesis [Wed Feb 24 14:08:51 2016] hi GLM! [Wed Feb 24 14:08:58 2016] so, the one I'm using is actually open source [Wed Feb 24 14:09:28 2016] https://github.com/JasonGross/fiat [Wed Feb 24 14:11:02 2016] hey all [Wed Feb 24 14:21:21 2016] johnw:Thanks. So that is the core of your project? [Wed Feb 24 14:21:35 2016] it is one aspect of it, but not even the largest part [Wed Feb 24 14:30:46 2016] What is the largest part then> [Wed Feb 24 14:31:18 2016] many pieces make up the largest part :) [Wed Feb 24 14:31:29 2016] I'd estimate that what I'm doing is a nicely sized chunk, though [Wed Feb 24 14:46:35 2016] I'm having a hard time extracting a witness out of an existential, presumably because I'm trying to use it as a value for something of sort Type. Is there any way to achieve what I'm trying to do here? http://paste.debian.net/403117/ (in essence, I just want to pull out the function from the definition of Surjection f: (forall b : B, exists a : A, f a = b) morally gives a fuction g : B -> A, where b : B gets [Wed Feb 24 14:46:41 2016] mapped to the witness for the existential. [Wed Feb 24 14:49:03 2016] you can't "pull it out" unless you make the resulting Universe Prop [Wed Feb 24 14:50:46 2016] conceptually, you only know that the witness exists, not what it does [Wed Feb 24 14:51:09 2016] I run into this same issue in my library for working with propositional isomorphisms [Wed Feb 24 14:53:37 2016] ryanakca: for example, in the definition of BijectionHasInverse, if you use {A B : Prop}, then you can destruct [Wed Feb 24 14:59:21 2016] Indeed, but this is just a simple example, what I'm actually trying to get to is showing that being isomorphic is an equivalence relation, where A and B are isomorphic if there exists a structure preserving bijection between the two. Showing symmetry requires me to be able to somehow extract the inverse from the surjection claim. [Wed Feb 24 15:04:57 2016] ryanakca: short answer is no, you can't do that. here is a reformulation that might work for you: http://paste.debian.net/403124/ [Wed Feb 24 15:08:18 2016] jrw: Thanks :) [Wed Feb 24 15:38:09 2016] ryanakca: see also https://github.com/jwiegley/coq-haskell/blob/master/src/Control/Iso.v [Wed Feb 24 15:38:26 2016] I define a proposition isomorphic, and then establish it as a parametric relation, parametric over various constructions [Wed Feb 24 15:38:29 2016] johnw: pong [Wed Feb 24 15:38:37 2016] so that after the basics are laid down, you can prove isomorphisms mostly by rewriting [Wed Feb 24 15:38:39 2016] jgross: hi! [Wed Feb 24 15:38:47 2016] jgross: are you anywhere that you could talk on the phone for a bit? [Wed Feb 24 15:41:35 2016] Is ~4:15-4:30 a good time-slot? (35 minutes from now) [Wed Feb 24 17:18:52 2016] johnw: Thanks. [Wed Feb 24 17:19:01 2016] sure [Wed Feb 24 17:19:14 2016] setoids take a bit to get used to, but they are actually quite straightforward [Wed Feb 24 19:02:33 2016] anyone got a clue on the pigeonhole_principle from SF MoreLogic.v? [Wed Feb 24 19:04:21 2016] Nik05: are you trying to do the classical or intuitionistic version? [Wed Feb 24 19:05:31 2016] well until now i havent used the excluded_middle axiom [Wed Feb 24 19:05:46 2016] but i think i want to do both [Wed Feb 24 19:06:33 2016] to do intuitionistic, I think you'd need decidable equality, wouldn't you? [Wed Feb 24 19:08:07 2016] let me read about decidability [Wed Feb 24 19:08:35 2016] oh oke uh [Wed Feb 24 19:11:20 2016] Nik05: I'd recommend doing it classically first. where are you stuck? [Wed Feb 24 19:11:24 2016] jrw is the classical easier? [Wed Feb 24 19:11:27 2016] yes [Wed Feb 24 19:11:46 2016] classical in this context basically just means "we can assume everything is decidable" [Wed Feb 24 19:11:50 2016] oh i need to do an inversion the it [Wed Feb 24 19:12:07 2016] so in particular, at any point in the proof you can do case analysis on "is x in the list l?" [Wed Feb 24 19:12:22 2016] which is not valid intuitionistically unless the type of x has decidable equality [Wed Feb 24 19:12:28 2016] decidable really just means "you can do an if test, and know something what you have based on the truth of it" [Wed Feb 24 19:13:12 2016] so when does a type have decidable equality? [Wed Feb 24 19:13:49 2016] if you use Set Decidable Equality Schemes. [Wed Feb 24 19:14:12 2016] (one sec) [Wed Feb 24 19:15:01 2016] a type T is decidable for propert P, if there exists a procedure to go from some x : T to {P x} + {~ P x} [Wed Feb 24 19:15:22 2016] oh i get how do the classical now [Wed Feb 24 19:15:38 2016] Set Decidable Equality Schemes will auto-generate such a procedure for you in terms of equality, and Set Boolean Equality Schemes will auto-generate a "boolean blind" procedure for equality [Wed Feb 24 19:15:58 2016] hm i dont really get it [Wed Feb 24 19:16:04 2016] sorry, too much info probably [Wed Feb 24 19:16:16 2016] you'll need to add a parameter to your theorem [Wed Feb 24 19:16:28 2016] that says that for any proposition P, one can determine P \/ ~P [Wed Feb 24 19:16:39 2016] johnw: he doesn't need to add it it's already there. [Wed Feb 24 19:16:40 2016] {P x} + {~P x} isn't P x ∨ ~ P x? [Wed Feb 24 19:16:58 2016] johnw: not to be rude, but I feel like you're kind of going off the deep end here [Wed Feb 24 19:17:21 2016] I'm sorry, I did go off the deep end [Wed Feb 24 19:17:25 2016] :P [Wed Feb 24 19:17:28 2016] please ignore all of what I was just saying [Wed Feb 24 19:17:28 2016] :) [Wed Feb 24 19:18:11 2016] Nik05: they have already given you excluded middle. you will want to use that to make the proof easy. [Wed Feb 24 19:18:21 2016] why don't you try that and see if you can get it. [Wed Feb 24 19:18:23 2016] yes I got how to do it now [Wed Feb 24 19:18:27 2016] good [Wed Feb 24 19:20:57 2016] H2 : appears_in x l1' [Wed Feb 24 19:20:57 2016] ______________________________________(1/2) [Wed Feb 24 19:20:58 2016] repeats (x :: l1') [Wed Feb 24 19:21:15 2016] guess i can proof that :) [Wed Feb 24 19:22:45 2016] looks good to me [Wed Feb 24 19:23:10 2016] oh wait a second, i think my definition of repeats is wrong... [Wed Feb 24 19:23:57 2016] and if ever, some day, you find yourself mechanically writing decidable equality procedures, you'll remember me in my deep abyss of impractical knowledge and I will be redeemed [Wed Feb 24 19:24:07 2016] ;p [Wed Feb 24 19:25:58 2016] haha :D [Wed Feb 24 19:26:09 2016] johnw: I actually didn't know about those options so thanks for that :) [Wed Feb 24 19:28:50 2016] oh no im stuck at the same place as i was without using classic:P [Wed Feb 24 19:32:13 2016] i now need to proof repeats (x :: l1'), with H : ~ appears_in x l1' [Wed Feb 24 19:44:17 2016] i think i will look into it tomorrow [Wed Feb 24 19:44:24 2016] thank you jrw and johnw [Wed Feb 24 19:44:29 2016] um, sure? :) [Wed Feb 24 19:44:31 2016] have a good evening [Wed Feb 24 19:44:37 2016] yes im not feeling that well [Wed Feb 24 19:44:40 2016] you too Nik05 [Wed Feb 24 19:44:43 2016] feel better [Wed Feb 24 19:44:47 2016] thank you [Thu Feb 25 07:58:17 2016] hm still cant seem to proof it [Thu Feb 25 08:00:23 2016] I tried to proof with excluded_middle and without but with both i get stuck at H0 : length l2 < length (x :: l1') to proof length l2 < length l1' [Thu Feb 25 08:00:59 2016] SF tells to use induction on l1, should i try something else/ [Thu Feb 25 09:49:01 2016] Hmmm, /topic should probably be updated to read [...] - 8.5 is out: https://coq.inria.fr/news/128.html - [...] [Thu Feb 25 09:56:04 2016] yes same for Feit-Thompson link [Thu Feb 25 10:04:56 2016] yep [Thu Feb 25 12:02:00 2016] Can I ask beginner's questino about proofs here? [Thu Feb 25 12:02:08 2016] yes m1dnight_ [Thu Feb 25 12:03:03 2016] In a simple proof (proving forall n, m: n =m -> n + n = m+ m), when I type "rewrite -> H", is that like the induction step in proof by induction? i.e., "assume the hypothesis is true" ? [Thu Feb 25 12:04:30 2016] You do an intro of H : n = m [Thu Feb 25 12:04:45 2016] and then you rewrite n to m in your goal [Thu Feb 25 12:04:52 2016] what do you mean with induction step? [Thu Feb 25 12:12:51 2016] assuming the hypothesis to be true, but that would be "intros H." (which comes directly before "rewrite -> H" [Thu Feb 25 12:16:37 2016] Well, nvm. I think Im a few miles off getting it. [Thu Feb 25 12:17:01 2016] sorry i dont know the theories behind this [Thu Feb 25 12:25:19 2016] aha I think I got it by trying to make it prove something that was wrong :> [Thu Feb 25 12:25:33 2016] like what? [Thu Feb 25 12:27:41 2016] https://www.refheap.com/115196 [Thu Feb 25 12:28:19 2016] I now figured out that rewrite does *magic* and notices that I have `n = m` in my hypothesis and as such can change n into m and vice versa (depending on the arrow of `rewrite`) [Thu Feb 25 12:28:55 2016] well thats not exactly *magic* [Thu Feb 25 12:29:09 2016] By magic I mean, I dont fully understand it yet :) [Thu Feb 25 12:32:27 2016] well its sort of magic :P [Thu Feb 25 12:32:32 2016] λ (n m : nat) (H : n = m), eq_ind_r (λ n0 : nat, n0 + n0 = m + m) eq_refl H : ∀ n m : nat, n = m → n + n = m + m [Thu Feb 25 12:35:19 2016] oh right you can also do it another way [Thu Feb 25 12:35:49 2016] I think I understand most of that :> [Thu Feb 25 12:37:34 2016] but look indeed like some induction principle of eq [Thu Feb 25 13:22:56 2016] hello. I want to try the first example of this book http://adam.chlipala.net/cpdt/ (source code in tar there, I downloaded it and compiled). When I run coqc StackMachine.v I get "Cannot find library Cpdt.CpdtTactics in loadpath", however when I edit the import from "Cpdt.CpdtTactics" to "CpdtTactics" I get the following after calling coqc: "CpdtTactics.vo contains library [Thu Feb 25 13:23:20 2016] Cpdt.CpdtTactics and not library CpdtTactics". Any guesses why the first doesn't work but with the other command it knows where the library is? [Thu Feb 25 13:23:48 2016] * the import in StackMachine.v [Thu Feb 25 14:00:09 2016] well putting the CpdtTactics.vo file in Cptd/CpdtTactics.vo helped [Thu Feb 25 14:01:03 2016] ping 192.168.1.120 [Thu Feb 25 14:01:26 2016] PING 192.168.1.120 (192.168.1.120): 56 data bytes [Thu Feb 25 14:05:08 2016] :D wrong window, sorry [Thu Feb 25 14:08:00 2016] --- 192.168.1.120 ping statistics --- [Thu Feb 25 14:08:07 2016] 100 packets transmitted, 0 packets received, 100% packet loss [Thu Feb 25 14:08:10 2016] :P [Thu Feb 25 15:30:43 2016] johnw or jrw here? [Thu Feb 25 15:30:51 2016] Nik05: what's up? [Thu Feb 25 15:30:56 2016] hello jrw [Thu Feb 25 15:31:14 2016] about yesterday the pidgeonhole principle [Thu Feb 25 15:31:32 2016] do you need to do some "strong" induction or what am i missing? [Thu Feb 25 15:35:31 2016] hi [Thu Feb 25 15:47:47 2016] Nik05: no the induction they set up for you works [Thu Feb 25 15:48:16 2016] Nik05: when you apply the induction hypothesis, you need to apply it with a smaller l2 than the one you're given [Thu Feb 25 15:48:26 2016] so that you can satisfy the length requirement [Thu Feb 25 15:49:08 2016] hm oke [Thu Feb 25 15:50:00 2016] yes right [Thu Feb 25 15:50:07 2016] a smaller l2, hm [Thu Feb 25 16:17:34 2016] Nik05: ok, I just proved it again from the beginning, and jrw is right [Thu Feb 25 16:18:32 2016] i cant seem to find out how to do it [Thu Feb 25 16:19:11 2016] so, you'll reach a point where you have something like this in your context: [Thu Feb 25 16:19:12 2016] H0 : forall x0 : X, appears_in x0 (x :: xs) -> appears_in x0 l2 [Thu Feb 25 16:19:19 2016] yes [Thu Feb 25 16:19:19 2016] fairly early on [Thu Feb 25 16:19:27 2016] and you'll have a way to satisfy the arguments to this [Thu Feb 25 16:19:37 2016] the key to all of this is using what you know about appears_in and app [Thu Feb 25 16:21:58 2016] oh like that [Thu Feb 25 16:26:05 2016] Nik05: for comparison later: https://gist.github.com/7fa959a318b578656d2a [Thu Feb 25 16:29:31 2016] 22:19 < johnw> H0 : forall x0 : X, appears_in x0 (x :: xs) -> appears_in x0 l2 [Thu Feb 25 16:29:49 2016] But i can never use that one, when i apply the induction hypothesis with a smaller l2 [Thu Feb 25 17:20:10 2016] you'll need to use it before, and after [Thu Feb 25 17:20:25 2016] with two separate proofs [Thu Feb 25 17:20:31 2016] one for ai_here, one for ai_there [Thu Feb 25 17:20:41 2016] there's a symmetry throughout this proof, in fact [Thu Feb 25 17:21:33 2016] this should really be a 5 star exercise, IMHO [Thu Feb 25 17:21:41 2016] it's one of the hardest [Thu Feb 25 17:21:55 2016] for those of us not used to doing pen-and-paper proofs in logic class [Thu Feb 25 18:10:31 2016] still dont got it :( [Thu Feb 25 18:15:37 2016] check out the solution I posted for a brief hint perhaps? [Thu Feb 25 18:16:05 2016] oke [Thu Feb 25 18:17:30 2016] this line? destruct (appears_in_app_split _ _ _ (Happ x (ai_here _ _))) as [? Hsplit]. [Thu Feb 25 18:18:12 2016] i dont even get the syntax [Thu Feb 25 18:18:27 2016] so, destruct H destructions a term in the context [Thu Feb 25 18:18:40 2016] destruct (H a) destructs a functions in the context, passing it an argument [Thu Feb 25 18:18:49 2016] the '_' just says "figure out this argument for me" [Thu Feb 25 18:18:58 2016] the 'as' assigns names to destructed components [Thu Feb 25 18:19:02 2016] where ? means "just make up a name" [Thu Feb 25 18:19:09 2016] oke [Thu Feb 25 18:24:16 2016] destruct (ExM (appears_in x l2)) as [Hx_in_l2 | Hnot_x_in_l2]. apply appears_in_app_split in Hx_in_l2. destruct Hx_in_l2 as [l2' [l2'' Hx_in_l2']]. [Thu Feb 25 18:24:19 2016] does the same as that [Thu Feb 25 18:24:47 2016] which i already had in my proof [Thu Feb 25 18:24:51 2016] well, not exactly the same as that [Thu Feb 25 18:25:05 2016] oh? [Thu Feb 25 18:25:15 2016] you're destructing on LEM there [Thu Feb 25 18:25:22 2016] you didn't include the code where I do that in what you pasted above [Thu Feb 25 18:25:28 2016] so it's not an exact comparison [Thu Feb 25 18:26:13 2016] oh wait [Thu Feb 25 18:27:40 2016] hm [Thu Feb 25 18:29:20 2016] i still dont get your line then [Thu Feb 25 18:32:20 2016] what aobut it? [Thu Feb 25 18:36:38 2016] well hard to ask about it :P [Thu Feb 25 18:39:54 2016] where does it get the information about l2 from? [Thu Feb 25 18:40:48 2016] I guess it comes from Happ x (ai_here _ _) [Thu Feb 25 18:42:13 2016] oke that creates : appears_in x l2 [Thu Feb 25 18:42:28 2016] but how [Thu Feb 25 18:43:33 2016] pose proof (Happ x (ai_here _ _)). [Thu Feb 25 18:43:36 2016] i dont get this [Thu Feb 25 18:46:17 2016] What do you apply to Happ to get appears_in x l2? [Thu Feb 25 18:46:39 2016] i guess you need to apply it to appears_in x (x :: xs) [Thu Feb 25 18:46:50 2016] but your hypothesis H is ~ appears_in x xs [Thu Feb 25 18:54:17 2016] is there some kind of well-known algorithm for pattern matching and substitution and stuff [Thu Feb 25 18:54:26 2016] er ok that was an incredibly unclear question [Thu Feb 25 18:55:29 2016] basically i want to write some kind of graphical program for manipulating expressions rigorously such that you can never end up with a false equation [Thu Feb 25 18:56:00 2016] so i'd need to be able to do things like, given some expression and an equation with some universally quantified variables in it, figure out how the rewriting applies [Thu Feb 25 18:56:09 2016] what would be a good resource for that? [Thu Feb 25 18:58:15 2016] johnw could you ellaborate a little on that? [Thu Feb 25 19:00:03 2016] all these short cuts :p [Thu Feb 25 19:00:40 2016] apply repeats_head. exact H. you write as exact (repeats_head x xs H) [Thu Feb 25 19:01:02 2016] i guess thats explained more in ProofObjects.v [Thu Feb 25 19:01:13 2016] which comes after MoreLogic.v [Thu Feb 25 19:01:57 2016] exact TERM says that TERM is exactly what is needed to satisfy the goal [Thu Feb 25 19:02:07 2016] apply uses heuristics to determine arguments, but exact doesn't do this [Thu Feb 25 19:03:37 2016] i get that one, but not your long destruct that gives you ∃ l1 l3, l2 = l1 ++ x :: l3 [Thu Feb 25 19:04:02 2016] I guess just ignore it then, there are many ways to accomplish the same thing [Thu Feb 25 19:04:20 2016] but how could i accomplish it without your one liner? [Thu Feb 25 19:04:37 2016] pose proof (Happ x (ai_here _ _)) as H'. [Thu Feb 25 19:04:48 2016] apply appears_in_app_split in H'. [Thu Feb 25 19:04:53 2016] yes [Thu Feb 25 19:04:57 2016] but i dont get the first line [Thu Feb 25 19:05:08 2016] what about it? [Thu Feb 25 19:05:09 2016] seems like you get information from nothing [Thu Feb 25 19:06:01 2016] you get information from Happ [Thu Feb 25 19:06:07 2016] Happ takes a variable, here passed as x [Thu Feb 25 19:06:12 2016] now it wants evidence that is trivial to generate [Thu Feb 25 19:06:59 2016] how do you generate that evidence? [Thu Feb 25 19:07:08 2016] (ai_here _ _ ) [Thu Feb 25 19:07:09 2016] is that evidene [Thu Feb 25 19:07:51 2016] :P [Thu Feb 25 19:07:57 2016] sorry i still dont get it [Thu Feb 25 19:08:34 2016] pose proof (ai_here x xs). how does this work? [Thu Feb 25 19:08:46 2016] oooh [Thu Feb 25 19:08:48 2016] -_- [Thu Feb 25 19:08:48 2016] ai_here x xs says that appears_in x (x :: xs) [Thu Feb 25 19:08:55 2016] which is simply evident by definition [Thu Feb 25 19:08:58 2016] oke thats pretty self evident :P [Thu Feb 25 19:09:03 2016] sorry im stupid [Thu Feb 25 19:09:06 2016] that's OK [Thu Feb 25 19:09:16 2016] ai_here _ _ just says "you can figure out which arguments I mean" [Thu Feb 25 19:09:27 2016] type inference is very powerful [Thu Feb 25 19:09:46 2016] yes i knew it would mean something like (ai_here x (x :: xs)) [Thu Feb 25 19:09:59 2016] just ai_here x xs [Thu Feb 25 19:10:05 2016] or not like that, yes that [Thu Feb 25 19:10:53 2016] | ai_here : forall l, appears_in a (a::l) [Thu Feb 25 19:10:55 2016] right oke [Thu Feb 25 19:11:15 2016] oh thats what i didnt get from your proof, felt like you made something from nothing [Thu Feb 25 19:11:35 2016] I only made something from the definitionally obvious :) [Thu Feb 25 19:11:42 2016] right :) [Thu Feb 25 19:13:24 2016] pose proof (ai_here x l1'). apply Hai in H. apply appears_in_app_split in H. destruct H. [Thu Feb 25 19:13:30 2016] so that is what your one liner does [Thu Feb 25 19:13:39 2016] yes, exactly that [Thu Feb 25 19:15:25 2016] couldnt you also merge it with the next destruct? [Thu Feb 25 19:15:44 2016] as [? [? Hsplit]? [Thu Feb 25 19:16:14 2016] sure! [Thu Feb 25 19:18:51 2016] why do you clear IHxs? [Thu Feb 25 19:18:58 2016] i guess i can work further now [Thu Feb 25 19:19:04 2016] totally looked over it [Thu Feb 25 19:26:26 2016] oke i think i will get there now :) [Thu Feb 25 19:26:29 2016] thank you very much johnw [Thu Feb 25 19:30:12 2016] strange cant appleay appears_in_app for some reason [Thu Feb 25 19:30:59 2016] oh i need app_appears_in -_- [Thu Feb 25 19:31:24 2016] yeah [Thu Feb 25 19:40:57 2016] H2 : x0 :: l = l2' ++ x :: l2'' [Thu Feb 25 19:41:08 2016] need to proof : appears_in x0 l2' [Thu Feb 25 19:42:12 2016] oh wait l2' could be [] ofcourse [Thu Feb 25 19:42:55 2016] thank you johnw, i now know how to go further [Thu Feb 25 19:42:57 2016] have a nice evening [Thu Feb 25 19:43:37 2016] you too! [Fri Feb 26 10:01:29 2016] hey all [Fri Feb 26 10:01:34 2016] hey [Fri Feb 26 10:01:43 2016] I'm stuck on a proof and would like some tips [Fri Feb 26 10:02:23 2016] this one: https://github.com/lingxiao/CIS500/blob/master/hw6/Imp.v#L864 [Fri Feb 26 10:02:39 2016] my proof state is as follows: http://lpaste.net/153410 [Fri Feb 26 10:03:08 2016] I need to get the goal to a state that looks like: [ BEq e1 e2 // beq_nat n1 n2] [Fri Feb 26 10:03:30 2016] but see no clear path to do so, the theorem [aeval_iff_aevalR] doesn't seem to help me here [Fri Feb 26 10:03:55 2016] destructing [a] and [a0] does not seem like the way to go [Fri Feb 26 10:04:51 2016] so benzrf i dont know if you see a path forward [Fri Feb 26 10:06:43 2016] sorry back [Fri Feb 26 10:06:52 2016] lingxiao: i can take a look but i'm not super knowledgeable about oq [Fri Feb 26 10:06:53 2016] *coq [Fri Feb 26 10:07:10 2016] any help is appreicated thank you! [Fri Feb 26 10:08:06 2016] yeah i didn't even get that far in sf >.> [Fri Feb 26 10:08:25 2016] oh haha yeah the course can be fraustrating [Fri Feb 26 10:10:18 2016] oh [Fri Feb 26 10:10:21 2016] no, i just kind of [Fri Feb 26 10:10:29 2016] gradually stopped doing it [Fri Feb 26 10:10:35 2016] my attention drifted elsewhere [Fri Feb 26 10:11:03 2016] haha i feel you man [Fri Feb 26 13:20:10 2016] hey lingxiao [Fri Feb 26 13:20:20 2016] hey I figured it out! [Fri Feb 26 13:20:26 2016] what did you figure out lingxiao ? [Fri Feb 26 13:20:34 2016] oh the question i was asking here [Fri Feb 26 13:20:40 2016] or were you going to talk about someting else? [Fri Feb 26 13:20:44 2016] haha sorry ! [Fri Feb 26 13:21:53 2016] oh no not really :) [Fri Feb 26 13:22:34 2016] see you later [Fri Feb 26 13:29:05 2016] oh ok yup see you later too thanks! [Fri Feb 26 14:21:57 2016] morning all [Fri Feb 26 16:48:08 2016] morning johnw [Fri Feb 26 17:56:05 2016] johnw im looking into the pigeons again :P [Fri Feb 26 17:56:14 2016] cool [Fri Feb 26 17:56:23 2016] good to keep doing it until it makes sense [Fri Feb 26 17:59:47 2016] johnw im stuck on something really simple :) [Fri Feb 26 17:59:55 2016] what? [Fri Feb 26 18:00:05 2016] oh wait maybe i got it [Fri Feb 26 18:00:35 2016] i took a look at your proof and you just do "assumption" at line 23. But that didnt seem to work for me [Fri Feb 26 18:00:48 2016] you're using 8.4pl6? [Fri Feb 26 18:00:53 2016] no 8.5 [Fri Feb 26 18:00:59 2016] that could be why [Fri Feb 26 18:01:04 2016] i haven't tried SF with 8.5 [Fri Feb 26 18:01:10 2016] try just applying the matching hypothesis? [Fri Feb 26 18:01:33 2016] so assumption in 8.4 does a better job than in 8.5? [Fri Feb 26 18:01:41 2016] ooooh [Fri Feb 26 18:01:47 2016] i see what you did :) [Fri Feb 26 18:01:50 2016] ah [Fri Feb 26 18:02:08 2016] destruct (long thing) as *[| H2]* that part :P [Fri Feb 26 18:02:12 2016] is another destruct ofcourse [Fri Feb 26 18:02:16 2016] yeah [Fri Feb 26 18:04:46 2016] no sure how your "assumption" works there though [Fri Feb 26 18:04:59 2016] not* [Fri Feb 26 18:08:10 2016] hm your 23-26 are 20 lines for me or something :S [Fri Feb 26 18:22:32 2016] johnw i proof it... [Fri Feb 26 18:22:37 2016] ed [Fri Feb 26 18:22:52 2016] cool; show me? [Fri Feb 26 18:23:08 2016] i did something totally wrong but i proofed it :P [Fri Feb 26 18:23:45 2016] Nik05 pasted “A little long...” at http://lpaste.net/5004518003790839808 [Fri Feb 26 18:24:09 2016] my line 31-64 is your lines 23-26... [Fri Feb 26 18:24:35 2016] huh [Fri Feb 26 18:24:44 2016] :P [Fri Feb 26 18:25:04 2016] and my proof is unreadable... [Fri Feb 26 18:28:41 2016] oh wait a second [Fri Feb 26 18:29:24 2016] im doing something wrong there :P [Fri Feb 26 18:30:30 2016] i guess i dont know what this does :P destruct (appears_in_app _ _ _ _ (Happ _ (ai_later _ _ _ H0))) [Fri Feb 26 18:32:48 2016] its a miracle my proof works i guess [Fri Feb 26 18:33:55 2016] well, keep in mind that proofs are just implementations of functions [Fri Feb 26 18:34:05 2016] all i'm doing is calling a function to produce evidence, and than doing a case analysis on that evidence [Fri Feb 26 18:36:06 2016] i dont get where the evidence is coming from [Fri Feb 26 18:37:50 2016] oke this has to be self evident again... [Fri Feb 26 18:38:28 2016] ooooooooooh [Fri Feb 26 18:39:15 2016] the evidence is return from the function, provided you give it the evidence that IT wants [Fri Feb 26 18:39:20 2016] which we derive from the context [Fri Feb 26 18:39:29 2016] all functions are evidence transformations [Fri Feb 26 18:39:37 2016] and all evidence is just an inhabitant of a type [Fri Feb 26 18:39:43 2016] i get that [Fri Feb 26 18:40:06 2016] just not how you know what functions to apply [Fri Feb 26 18:40:15 2016] i know what return value I want [Fri Feb 26 18:40:23 2016] so I ask, is there a function that returns it? [Fri Feb 26 18:40:27 2016] if so, what does it need? [Fri Feb 26 18:40:34 2016] how do you search for that? [Fri Feb 26 18:40:46 2016] I use SearchAbout, SearchConstant, SearchRewrite [Fri Feb 26 18:40:54 2016] oke [Fri Feb 26 18:42:56 2016] Nik05 pasted “Better” at http://lpaste.net/191237602152546304 [Fri Feb 26 18:44:27 2016] yeah, that's effectively the same proof [Fri Feb 26 18:52:48 2016] yes [Fri Feb 26 18:53:22 2016] i did inversion on the app version of l2... [Fri Feb 26 19:07:59 2016] inversion and destruct are sometimes interchangeable (and sometimes not) [Fri Feb 26 19:12:47 2016] johnw i can do another proof now as well :) [Fri Feb 26 19:12:53 2016] thanks to you [Fri Feb 26 19:13:05 2016] disjoint l1 l2 -> no_repeats l1 -> no_repeats l2 -> no_repeats (l1 ++ l2). [Fri Feb 26 19:13:05 2016] yay! [Fri Feb 26 19:13:15 2016] pose proof (H x (ai_here _ _)). magic :D [Fri Feb 26 19:16:35 2016] Nik05 pasted “Done” at http://lpaste.net/5503864237497253888 [Fri Feb 26 19:16:40 2016] That went a lot faster :) [Fri Feb 26 19:25:35 2016] johnw im now going to do ProofObjects.v [Sat Feb 27 02:55:14 2016] "All the remaining goals are on the shelf." "Error: Attempt to save a proof with shelved goals" [Sat Feb 27 02:55:20 2016] erm.. how do I "unshelf" these goals? [Sat Feb 27 02:55:38 2016] I don't understand the purpose of "hiding" some goals that I have to prove anyway [Sat Feb 27 02:57:54 2016] Unshelve. apparently [Sat Feb 27 03:03:03 2016] oh, thanks! [Sat Feb 27 03:03:51 2016] artart78: I believe it's mostly useful when you're writing a tactic, and expect that some of the goals generated will be solved by unification when the other goals are solved. [Sat Feb 27 03:04:07 2016] It's probably not so useful interactively. [Sat Feb 27 03:06:18 2016] Apparently refine uses shelve_unifiable to leave fewer goals visible afterward. [Sat Feb 27 03:10:50 2016] oh ok [Sat Feb 27 03:27:20 2016] Hi Cale! [Sat Feb 27 03:31:19 2016] hi [Sat Feb 27 03:51:03 2016] Cale: I don't see you in #coq as often [Sat Feb 27 03:51:11 2016] though I guess you're usually here [Sat Feb 27 03:51:14 2016] I'm always here, just not always talking :) [Sat Feb 27 03:58:30 2016] Cale: are you an extraction wizard? [Sat Feb 27 03:58:40 2016] I'd like to know how to extract "foo" as just "foo" [Sat Feb 27 03:59:06 2016] instead of Cons0 (Ascii .....) (Cons0 (Ascii ....) ...) [Sat Feb 27 06:28:52 2016] johnw: saw your post on coq-club. I guess it's awkward to even talk about proof relevance with this kind of extracted terms. [Sat Feb 27 07:11:51 2016] johnw do you know where i can get some information on Search* ? [Sat Feb 27 07:12:56 2016] Oh SearchAbout is just Search now [Sat Feb 27 07:13:34 2016] I dont see SearchConstant in the manual though [Sat Feb 27 07:31:42 2016] Is it possible to utilize free theorems in coq? [Sat Feb 27 14:53:27 2016] good evening [Sat Feb 27 15:15:55 2016] johnw: I don't really know anything about extraction, haven't actually tried it. [Sat Feb 27 15:16:21 2016] johnw: But that seems like a good question :) [Sat Feb 27 16:28:04 2016] Im reading ProofObjects.v and im at exercise 2 now (** Give a proof object corresponding to the theorem [b_times2] from Prop.v *) But what do they want I do? [Sat Feb 27 16:28:25 2016] they havent spoken about induction or rewrites in ProofObjects where I am now [Sat Feb 27 16:34:36 2016] Nik05: then hopefully you won't need either of those :) [Sat Feb 27 16:35:17 2016] The Theorem is beautiful n -> beautiful (2 * n) [Sat Feb 27 16:35:34 2016] right [Sat Feb 27 16:35:39 2016] by definition beautiful n -> beautiful (n + n) [Sat Feb 27 16:35:52 2016] yep [Sat Feb 27 16:36:16 2016] so then i need to rewrite (2 * n) to (n + n) or? [Sat Feb 27 16:36:44 2016] right, so that's one way [Sat Feb 27 16:36:51 2016] but you can do it without rewriting [Sat Feb 27 16:36:56 2016] oh [Sat Feb 27 16:37:00 2016] what does [2 * n] simplify to by itself? [Sat Feb 27 16:38:00 2016] jrw how do i print the definition of *? [Sat Feb 27 16:38:27 2016] well * is a notation, so you have to say [Locate "*".] to get its real name [Sat Feb 27 16:38:33 2016] which is "mult" I believe [Sat Feb 27 16:38:44 2016] and then you say [Print mult.] [Sat Feb 27 16:39:21 2016] well oke i tried Print mult but it dhoes give the definition [Sat Feb 27 16:39:34 2016] It only gives this: Notation mult := Nat.mul [Sat Feb 27 16:40:01 2016] which is really strange because i didnt include the Nat libraary [Sat Feb 27 16:41:02 2016] jrw so it simplifies to n + (n + 0)? [Sat Feb 27 16:41:11 2016] i did Print Nat.mul [Sat Feb 27 16:41:27 2016] no idea where Nat.mul is defined [Sat Feb 27 16:41:49 2016] jrw so how do you simplify with proof objects? [Sat Feb 27 16:41:51 2016] Nik05: I don't have SF installed locally so I can't check exactly what's different there from the standard library [Sat Feb 27 16:42:08 2016] good question. simplification basically comes for free in proof objects [Sat Feb 27 16:42:14 2016] oh oke [Sat Feb 27 16:42:42 2016] so in a proof object you can treat [2 * n] as the same thing as [n + (n + 0)] and it will work [Sat Feb 27 16:43:02 2016] oh oke thank you jrw [Sat Feb 27 16:43:11 2016] so the theorem is the same as proving [beautiful n -> beautiful (n + (n + 0))] [Sat Feb 27 16:43:22 2016] and now hopefully you see how you don't need any rewrites :) [Sat Feb 27 16:43:44 2016] well dont i need to rewrite (n + 0) to n? [Sat Feb 27 16:44:07 2016] again, you *could* do that [Sat Feb 27 16:44:13 2016] :P [Sat Feb 27 16:44:22 2016] but why not just try to prove [beautiful (n + 0)] "directly" [Sat Feb 27 16:44:33 2016] oh right [Sat Feb 27 16:44:42 2016] :) [Sat Feb 27 16:45:00 2016] :) [Sat Feb 27 16:45:05 2016] oke my client cant handle netsplits [Sat Feb 27 16:45:17 2016] brb jrw, everything is slow now [Sat Feb 27 16:45:20 2016] k [Sat Feb 27 16:47:20 2016] λ n H, b_sum n (n + 0) H (b_sum n 0 H b_0). [Sat Feb 27 16:47:23 2016] is that it jrw ? [Sat Feb 27 16:47:44 2016] Nik05: looks good [Sat Feb 27 16:47:48 2016] does it typecheck? [Sat Feb 27 16:47:56 2016] it compiles :) [Sat Feb 27 16:48:02 2016] nice [Sat Feb 27 16:48:39 2016] john told about using Search to find objects to use, but I havent found out how to use it correctly [Sat Feb 27 16:48:45 2016] can you maybe give an example? [Sat Feb 27 16:50:17 2016] jrw has netsplit? [Sat Feb 27 16:50:27 2016] oh guess im back [Sat Feb 27 16:50:37 2016] Nik05: what do you mean about Search? [Sat Feb 27 17:13:27 2016] jrw sorry, johnw helped me with a proof yesterday and day before. And he used a lot of proof object. He said he used SearchAbout, SearchRewrite, etc. to find which proof objects he has to proof something and then look at what else he has to proof. [Sat Feb 27 17:17:27 2016] Nik05: [SearchAbout foo.] will show you all lemmas about foo [Sat Feb 27 17:17:27 2016] so if you do [SearchAbout beautiful.] you'll see b_0, b_sum, etc [Sat Feb 27 17:22:08 2016] oke [Sat Feb 27 21:25:36 2016] hey all [Sat Feb 27 21:25:40 2016] i have a syntax question about a tactic [Sat Feb 27 21:27:34 2016] http://pastebin.com/vxMurqrS [Sun Feb 28 06:25:23 2016] hi. I am currently stuck with something that *should* be easy. I have a function f : forall (n : nat), {m : nat | A(m, n)}. Now I want a function f_ : nat -> nat which is essentialls projT1 ° f, and I want forall n, A (f_ n, n). somehow I am stuck deriving this. [Sun Feb 28 06:25:30 2016] can sb help plz? [Sun Feb 28 06:31:50 2016] so essentially: http://lpaste.net/153530 [Sun Feb 28 06:32:16 2016] I need to prove this goal [Sun Feb 28 06:33:57 2016] ok, I knew I would find the solution as soon as I ask here ^^. got it, thx. [Sun Feb 28 06:34:51 2016] schoppenhauer, I tried it too just now. How many lines did it take? [Sun Feb 28 06:35:08 2016] 2 [Sun Feb 28 06:35:18 2016] but I didn't think I could just apply projT2 [Sun Feb 28 06:35:28 2016] you did apply projT2? [Sun Feb 28 06:35:30 2016] this idea came just now. i thought too complicated. [Sun Feb 28 06:35:33 2016] yes. [Sun Feb 28 06:35:34 2016] mine: intros. destruct (f n). exact a. [Sun Feb 28 06:36:06 2016] intros A f n. apply projT2. [Sun Feb 28 06:36:30 2016] yes, it's easy. but I somehow couldn't manage it ... sometimes it's the easy things that take their time, u know. [Sun Feb 28 06:36:43 2016] I know. [Sun Feb 28 06:39:45 2016] what's the difference between { x : A | P } and { x : A & P }? [Sun Feb 28 06:40:22 2016] i think in the latter, P can have computational content [Sun Feb 28 07:32:02 2016] morning lingxiao [Sun Feb 28 10:53:41 2016] https://blog.uxul.de/e?e=ex_in_coq opinions? [Mon Feb 29 06:35:42 2016] hello, here is my status: https://bpaste.net/show/94a29b1ebf01 , how can I get 'x = pi1 s' ? [Mon Feb 29 06:41:23 2016] OK, I think I can't. Because the 's' just return a C, so in these case I can only get a Prop, but the value may not be 'x = pi1 s'. [Mon Feb 29 07:06:08 2016] anyone know any good reading materials about equality(definitial, prospositional, etc)? [Mon Feb 29 07:50:11 2016] Hrm, I've been stuck on an exercise from the software foundations book :< [Mon Feb 29 07:50:30 2016] m1dnight_ which one? [Mon Feb 29 07:51:04 2016] proving `and b c = ordb b c` [Mon Feb 29 07:51:25 2016] I can "prove" it on paper. It's getting it into Coq thats difficult. [Mon Feb 29 07:51:36 2016] how is that equal? [Mon Feb 29 07:51:57 2016] oh, i forgot a piece.sorry I was distracted. [Mon Feb 29 07:52:20 2016] https://www.refheap.com/115342 [Mon Feb 29 07:52:25 2016] This is where I got so far.. [Mon Feb 29 07:56:27 2016] The problem I think is, when I have the intros of b and c, I should be able to assume that `and b c` is true. then from that derive that b and c are true, then rewrite the left hand side of `and b c = or b c` to true. [Mon Feb 29 07:56:43 2016] But I cant seem to be able to split the `and b c = or b c` in two parts. [Mon Feb 29 08:03:35 2016] m1dnight_ you can just do a case analysis on b and c [Mon Feb 29 08:10:02 2016] oh and m1dnight_ if you do destruct (andb b c) eqn:Hbeqc. you get b = c in your context [Mon Feb 29 08:36:59 2016] Hmm, Ive been trying with destruct on b and c but Im stuck when I have to prove its *not* the case. [Mon Feb 29 08:37:07 2016] I might need a lemma for this, I think. [Mon Feb 29 08:37:39 2016] well you can proof a lemma andb b c = true -> b = c [Mon Feb 29 08:38:03 2016] wait [Mon Feb 29 08:38:09 2016] well yes you can [Mon Feb 29 08:42:21 2016] Yes, that's true but I figured that is basically the same as the definition of and, no? [Mon Feb 29 08:42:45 2016] https://www.refheap.com/115345 [Mon Feb 29 08:43:14 2016] This is where Im stuck. I am trying to prove false = true here :) I should be able to say "This is not possible, but thats the point" [Mon Feb 29 08:44:55 2016] m1dnight_ your hypothesis is false here [Mon Feb 29 08:45:01 2016] and false can proof everything [Mon Feb 29 08:45:28 2016] That's true >:) [Mon Feb 29 08:45:46 2016] Im going to try with the lemma first. See where I end up. [Mon Feb 29 08:46:03 2016] 14:42 < m1dnight_> Yes, that's true but I figured that is basically the same as the definition of and, no? [Mon Feb 29 08:46:12 2016] no its not by definition [Mon Feb 29 08:46:47 2016] definition is that andb b c = true when b and c are true [Mon Feb 29 09:08:49 2016] m1dnight_ got it? [Mon Feb 29 09:09:12 2016] Well, Im trying :D Not going to ask too much questions. Trying to figure out on my own atm. [Mon Feb 29 09:09:45 2016] oke good [Mon Feb 29 09:11:13 2016] m1dnight_ in Prop.v or IndProp now i think, they talk about the difference between computation and inductive definitions [Mon Feb 29 09:11:26 2016] andb and orb are computational definitions [Mon Feb 29 10:09:31 2016] fieuw, Ive got it. [Mon Feb 29 10:09:47 2016] Well, at least `and b c = true -> b = true` [Mon Feb 29 10:49:38 2016] Al. Most. :> [Mon Feb 29 10:50:34 2016] m1dnight_: Ltac identifiers? [Mon Feb 29 10:50:57 2016] Proof with There. Al. Most. There... Qed. [Mon Feb 29 10:53:41 2016] It was more an expression of my dissipating courage :D [Mon Feb 29 10:54:15 2016] That is a familiar feeling. [Mon Feb 29 11:00:52 2016] https://www.refheap.com/115359 <- the first lemma works and executes fine. For the second lemma I get the error when I try the `reflexivity` step. The context, stack and goal are almost identical. I really don't see why it works in the first but not the second case :/ [Mon Feb 29 11:02:39 2016] The only difference is that the operand which is still a variable in the and is now in the first position and not in the second one. However, the error clearly states that it can not unify the two left hand sides (of H and goal) [Mon Feb 29 11:02:45 2016] Why would it work in the previous lemma then. [Mon Feb 29 11:19:24 2016] m1dnight_: taking a look. [Mon Feb 29 11:21:19 2016] m1dnight_: you need to destruct b for the b && false to evaluate to false in both cases. [Mon Feb 29 11:21:27 2016] destruct b; reflexivity. will do it. [Mon Feb 29 12:18:22 2016] m1dnight_ got it? [Mon Feb 29 12:28:12 2016] Thats odd, though. Ill try that approach on the first lemma as well. [Mon Feb 29 12:28:48 2016] Yep, worked in the first lemma as well. [Mon Feb 29 12:28:56 2016] Well, I think I get it though. [Mon Feb 29 12:29:06 2016] Thanks for the help already guys, really appreciate it! :) [Mon Feb 29 12:35:35 2016] m1dnight_ you could proof your original by destructing on both b and c [Mon Feb 29 12:36:05 2016] Im back at that proof now, confident as ever :D [Mon Feb 29 12:37:21 2016] \ [Mon Feb 29 12:37:38 2016] whoops [Mon Feb 29 12:37:42 2016] hello stelleg [Mon Feb 29 12:37:48 2016] howdy [Mon Feb 29 12:46:16 2016] Is there a notation for matching that is a little shorter? [Mon Feb 29 12:47:11 2016] If you only have one constructor, a let-in might work [Mon Feb 29 12:47:16 2016] Forexample for conj there is just one contructor if i have a (H : Q ∧ P) can i write it in something like ((conj HQ HP) : Q ∧ Q) [Mon Feb 29 12:47:31 2016] ah oke Cypi [Mon Feb 29 12:53:45 2016] Ah, I think I have it. I should have written my lemma's the other way around. I.e., `forall b c: bool, c = true -> and c b = true. [Mon Feb 29 12:53:49 2016] this is fun :> [Mon Feb 29 12:54:02 2016] well thats not correct [Mon Feb 29 12:54:53 2016] Ugh, I meant orb. Sorry [Mon Feb 29 12:55:04 2016] I just noticed while typing it out [Mon Feb 29 12:55:12 2016] you mean ∀ b c, b = true -> c = true -> andb b c = true [Mon Feb 29 12:58:18 2016] No. I'm back at the original proof again and I have a goal `true = false` and my H = `andb true c = orb true c`. So I figured that I'd prove `b = true -> orb b c = true`, then I can rewrite my LHS to `orb true c` and use reflexivity. [Mon Feb 29 12:59:20 2016] just use simpl on H [Mon Feb 29 12:59:24 2016] its by definition [Mon Feb 29 12:59:33 2016] andb true c = c [Mon Feb 29 12:59:38 2016] and orb true c = true [Mon Feb 29 12:59:44 2016] Oh, I thought that once it was above the bar I couldn't change it anymore [Mon Feb 29 13:00:12 2016] no you can use `in` to apply a tactic on a hypothesis [Mon Feb 29 13:07:27 2016] `andb_eq_orb is defined` [Mon Feb 29 13:07:30 2016] SUCCES! [Mon Feb 29 13:07:33 2016] :) [Mon Feb 29 13:07:49 2016] With the simpl in H. it was actually very very easy. [Mon Feb 29 13:11:12 2016] johnw are you here? [Mon Feb 29 13:11:21 2016] got a question about proof objects :) [Mon Feb 29 13:14:45 2016] Cypi how could i write it as a let binding? [Mon Feb 29 13:15:33 2016] I'm not entirely sure what you asked for. But if you're writing directly the proof-term, you could have written: "let (HQ, HP) := H in ..." [Mon Feb 29 13:15:48 2016] in a proof, using "destruct H as [HQ HP]" is probably the easiest way [Mon Feb 29 13:16:37 2016] oke thank yo [Mon Feb 29 13:18:55 2016] Cypi it worked, but using match gives me an error :p; [Mon Feb 29 13:19:15 2016] Error: The constructor conj (in type and) expects 4 arguments. [Mon Feb 29 13:19:27 2016] match HPQ with | conj HP _ => [Mon Feb 29 13:19:40 2016] let (HP, _) := HPQ in (* works just fine [Mon Feb 29 13:20:08 2016] oh [Mon Feb 29 13:27:30 2016] Nik05: you may be aware, but you also can use the projections proj1 and proj2 in that case [Mon Feb 29 13:46:57 2016] stelleg oh thank you [Mon Feb 29 13:48:32 2016] stelleg any idea why my Coq says it needs 4 arguments for conj in pattern matching? [Mon Feb 29 13:49:02 2016] although when i write proj1 myself coq generates a proof using just 2 arguments [Mon Feb 29 13:49:11 2016] conj_left = [Mon Feb 29 13:49:11 2016] λ (P Q : Prop) (H : P ∧ Q), [Mon Feb 29 13:49:11 2016] match H with [Mon Feb 29 13:49:11 2016] | Init.Logic.conj H0 H1 => Init.Logic.conj H1 H0 [Mon Feb 29 13:49:15 2016] end [Mon Feb 29 13:49:23 2016] im sorry thought it would be one line [Mon Feb 29 13:50:36 2016] Nik05: yeah sorry not sure why it's asking for the type arguments, they should be implicit [Mon Feb 29 13:51:47 2016] Nik05: the left one should only need the indices; the right one needs anything that's not implicit [Mon Feb 29 13:52:18 2016] unless you're on 8.5 [Mon Feb 29 13:53:03 2016] lpaste not here? [Mon Feb 29 13:53:10 2016] http://lpaste.net/1607022061736165376 [Mon Feb 29 13:53:20 2016] johnw i am on 8.5 [Mon Feb 29 13:53:30 2016] ok, in 8.5 both sides of the => need 4 arguments [Mon Feb 29 13:53:42 2016] unless you turn on the backward compatability flag [Mon Feb 29 13:54:17 2016] "Set Asymmetric Patterns" [Mon Feb 29 13:54:19 2016] http://lpaste.net/153595 johnw Coq doesnt use it [Mon Feb 29 13:54:31 2016] it only uses 2 arguments [Mon Feb 29 13:54:37 2016] try Set Printing All before printing [Mon Feb 29 13:54:48 2016] what you see without Printing All is not necessarily what you need to input [Mon Feb 29 13:54:57 2016] same johnw [Mon Feb 29 13:54:57 2016] (unfortunately) [Mon Feb 29 13:55:01 2016] interesting! [Mon Feb 29 13:55:07 2016] that could be a bug, actually [Mon Feb 29 13:55:21 2016] oh oke [Mon Feb 29 13:55:26 2016] i'm lookign now [Mon Feb 29 13:56:13 2016] johnw and when using let i can just use 2 arugments? why not 4 there as well? [Mon Feb 29 13:56:28 2016] johnw: so the LHS of a pattern match has different implicitness rules than the RHS in general? [Mon Feb 29 13:57:08 2016] the CHANGES file for 8.5 says: "Constructors in pattern-matching patterns now respect the same rules regarding implicit arguments as in applicative position." [Mon Feb 29 13:57:40 2016] before, I think it was treating the constructor as if default implicits had been turned on at definition time or something [Mon Feb 29 13:57:59 2016] cool [Mon Feb 29 13:58:15 2016] now someone just needs to update coquille to work with 8.5 :( [Mon Feb 29 13:58:17 2016] Nik05: I'd report this to either the bug tracker or the mailing list; in general, whenever possible, a Print'd term should evaluate when fed back into Coq [Mon Feb 29 13:58:26 2016] although notations can definitely screw that up [Mon Feb 29 13:58:43 2016] (because a notation may make some arguments implicit that are required for type inference to work in certain situations) [Mon Feb 29 13:59:29 2016] oh oke [Mon Feb 29 14:01:34 2016] Definition conj_fact : forall P Q R, P /\ Q -> Q /\ R -> P /\ R := λ _ _ _ HPQ HQR, conj _ _ (proj1 _ _ HPQ) (proj2 _ _ HQR). [Mon Feb 29 14:01:41 2016] So this is how to do it? [Mon Feb 29 14:01:48 2016] pretty ugly with all the `_` [Mon Feb 29 14:02:04 2016] there are some terms that aren't often used in Gallina, but mainly only in tactics [Mon Feb 29 14:02:19 2016] but yeah, that's what I'd expect to see [Mon Feb 29 14:02:22 2016] you can always do this: [Mon Feb 29 14:02:26 2016] Arguments conj : default implicits. [Mon Feb 29 14:02:28 2016] etc. [Mon Feb 29 14:02:36 2016] to tell Coq to re-assign the implicit arguments [Mon Feb 29 14:02:41 2016] oke [Mon Feb 29 14:03:02 2016] when would you even want to use nondefault arguements in conj? [Mon Feb 29 14:03:22 2016] to guide type inference for surrounding code [Mon Feb 29 14:03:32 2016] in this case you know the types because of the return type of the function [Mon Feb 29 14:03:35 2016] but it's not always so clear [Mon Feb 29 14:03:39 2016] oke [Mon Feb 29 14:04:13 2016] and if you use default implicits, how can you override them? [Mon Feb 29 14:06:27 2016] the Arguments commands changes the role of arguments [Mon Feb 29 14:06:30 2016] and you are free to use it at any time [Mon Feb 29 14:07:57 2016] thank you, will look it up in the manual [Mon Feb 29 14:10:19 2016] How do i find the definition of a notation?> [Mon Feb 29 14:10:42 2016] I believe: LocateNotation ">>=". [Mon Feb 29 14:10:48 2016] thank you johnw :) [Mon Feb 29 14:11:00 2016] in proof general, that's C-c C-a C-n [Mon Feb 29 14:13:13 2016] sorry johnw i still need to learn EmacsOS :P [Mon Feb 29 14:17:27 2016] there's time :) [Mon Feb 29 14:20:42 2016] hmm.. "Anomaly: unknown meta ?21873. Please report." [Mon Feb 29 14:22:03 2016] How did you get that? x) [Mon Feb 29 14:22:07 2016] johnw 8.5? [Mon Feb 29 14:22:13 2016] no, 8.4pl6 [Mon Feb 29 14:22:16 2016] oh [Mon Feb 29 14:25:20 2016] oh wow or has really nice constructor names... [Mon Feb 29 14:26:14 2016] Yup, really short :-° [Mon Feb 29 14:32:25 2016] (** Try to write down an explicit proof object for [or_commut] (without using [Print] to peek at the ones we already defined!). *) [Mon Feb 29 14:32:30 2016] cant use Print :( [Mon Feb 29 14:33:29 2016] thought it was just one pattern match with 2 cases and then apply the other constructor [Mon Feb 29 14:33:52 2016] get large error with funny names ?P3@{h0:= nice names [Mon Feb 29 14:39:27 2016] lpaste test [Mon Feb 29 14:39:33 2016] lpaste is broken [Mon Feb 29 14:40:10 2016] http://lpaste.net/153618 [Mon Feb 29 14:42:53 2016] Anyone a small hint on what im doing wrong? [Mon Feb 29 14:48:13 2016] Oke i just used Print... but I did exactly the same thing :S [Mon Feb 29 14:48:19 2016] johnw is this a bug as well? [Mon Feb 29 14:48:52 2016] http://lpaste.net/5071629083993964544 [Mon Feb 29 14:49:32 2016] no [Mon Feb 29 14:49:39 2016] use "fun", not "forall", to begin your definition [Mon Feb 29 14:49:45 2016] and change , to => [Mon Feb 29 14:51:11 2016] oh [Mon Feb 29 14:51:18 2016] haha [Mon Feb 29 14:51:35 2016] need a lambda ofcourse [Mon Feb 29 14:52:25 2016] Error: Found a constructor of inductive type or while a constructor of Init.Logic.or is expected. [Mon Feb 29 14:52:37 2016] Software Foundations is strange [Mon Feb 29 14:52:54 2016] it doesnt import any libraries from Coq and I still get things like Init.Logic [Mon Feb 29 15:09:57 2016] there are some default imports [Mon Feb 29 15:10:15 2016] oh oke [Mon Feb 29 15:10:23 2016] not sure why exactly [Mon Feb 29 15:10:28 2016] but i've noticed that too [Mon Feb 29 15:10:34 2016] so i implicitly used Init.Logic.or? [Mon Feb 29 15:10:49 2016] maybe: try "Locate or." [Mon Feb 29 15:11:06 2016] Inductive Logic.or [Mon Feb 29 15:11:07 2016] Inductive Coq.Init.Logic.or [Mon Feb 29 15:11:18 2016] strange [Mon Feb 29 15:12:01 2016] so its both in Logic.v and Coq.Init.Logic [Mon Feb 29 15:12:16 2016] ah, maybe that's how it came in [Mon Feb 29 15:12:25 2016] oh i know why... [Mon Feb 29 15:12:34 2016] Coq.Unicode.Utf8 [Mon Feb 29 15:18:13 2016] johnw so when i use ∨ ∧ etc im using the Coq. or and and... [Mon Feb 29 15:18:24 2016] ah [Mon Feb 29 15:18:27 2016] that makes sense [Mon Feb 29 15:18:36 2016] so it's not a default import thing then [Mon Feb 29 15:18:44 2016] let me check [Mon Feb 29 15:18:59 2016] not sure [Mon Feb 29 15:20:13 2016] johnw when I execute Locate or in an empty document it still finds Inductive Coq.Init.Logic.or [Mon Feb 29 15:20:27 2016] :( [Mon Feb 29 15:20:39 2016] i wonder if that can be disabled [Mon Feb 29 15:27:35 2016] -q [Mon Feb 29 15:27:36 2016] Do not to load the default resource file. [Mon Feb 29 15:27:42 2016] could that be it johnw ? [Mon Feb 29 15:27:51 2016] maybe! [Mon Feb 29 15:27:57 2016] i've never researched how to actually disable it [Mon Feb 29 15:30:23 2016] jgross: ping [Mon Feb 29 15:31:23 2016] lpaste ping [Mon Feb 29 15:31:28 2016] all broken [Mon Feb 29 15:32:05 2016] dada [Mon Feb 29 15:32:06 2016] haha [Mon Feb 29 16:26:14 2016] johnw: pong [Mon Feb 29 16:36:15 2016] jgross: one sec, on phone [Mon Feb 29 17:08:08 2016] jgross: I'm back, if you're still here [Mon Feb 29 17:09:58 2016] ghhghh i went and decided it would be a good idea to try implementing the CoC from scratch [Mon Feb 29 17:10:09 2016] benzrf: in what language/theory? [Mon Feb 29 17:10:18 2016] purescript [Mon Feb 29 17:10:32 2016] having fun writing a dependent type checker? [Mon Feb 29 17:10:45 2016] then about 20 lines in i decided to implement the checking logic in prolog to make sure i understood how it worked [Mon Feb 29 17:10:56 2016] ooh, yak recursion [Mon Feb 29 17:11:23 2016] did i mention that when starting out i decided that i wouldn't use de bruijn indices this time around, it would be nice to just use variables again for the first time in years [Mon Feb 29 17:11:28 2016] fml [Mon Feb 29 17:13:36 2016] * goes back and uses some fucking indices [Mon Feb 29 17:13:45 2016] of course then it's complicated by using names for globals and stuff [Mon Feb 29 17:13:47 2016] gaaaah [Mon Feb 29 17:15:21 2016] johnw: what's the practical purpose of having both P and T [Mon Feb 29 17:16:30 2016] I have no clue what P and T are [Mon Feb 29 17:16:58 2016] Prop and Type* [Mon Feb 29 17:17:55 2016] i can never remember this shit [Mon Feb 29 17:17:57 2016] >.> [Mon Feb 29 17:18:38 2016] read CPDT [Mon Feb 29 17:18:48 2016] it goes into great thing in describing the difference, and why they exist [Mon Feb 29 17:18:53 2016] s/thing/length [Mon Feb 29 17:19:03 2016] bah [Mon Feb 29 17:19:16 2016] well, are they relevant to CoC without inductive decls [Mon Feb 29 17:19:43 2016] yeah [Mon Feb 29 17:19:48 2016] how so? [Mon Feb 29 17:20:21 2016] Prop is an impredicative type for propositions, and Type is for everything else [Mon Feb 29 17:20:24 2016] sort of [Mon Feb 29 17:20:32 2016] hm i think i read something nice about this topic recently [Mon Feb 29 17:23:03 2016] but yeah i think this is the gist [Mon Feb 29 17:24:28 2016] i mean [Mon Feb 29 17:24:32 2016] what's the *practical* purpose [Mon Feb 29 17:24:36 2016] what does it change, in practice [Mon Feb 29 17:24:55 2016] impredicative prop is what allows (P Q : Prop), (P \/ Q) /\ (Q \/ P) [Mon Feb 29 17:25:19 2016] well it means you can define certain connectives in terms of others [Mon Feb 29 17:25:20 2016] it's a convenience for keeping proofs within Prop, even if they refer to other proofs [Mon Feb 29 17:25:29 2016] i think thats how it was done in coc [Mon Feb 29 17:25:55 2016] johnw: oh [Mon Feb 29 17:26:28 2016] the formulation on wikipedia seems to only have one Type instead of a hierarchy: [Mon Feb 29 17:26:32 2016] https://en.wikipedia.org/wiki/Calculus_of_constructions [Mon Feb 29 17:26:41 2016] johnw: why do you need an impredicative prop for that? [Mon Feb 29 17:27:02 2016] notdan: oh, maybe I don't need it for that... [Mon Feb 29 17:27:08 2016] anyway, CPDT goes into depth on this exact subject [Mon Feb 29 17:27:12 2016] so no reason to repeat it all here [Mon Feb 29 17:27:16 2016] aw [Mon Feb 29 17:27:41 2016] in a functional language what's the best approach to doing type checking, given that type systems are given as deductive rules [Mon Feb 29 17:28:01 2016] er, by "best approach" i mean what type signatures should i be trying to implement [Mon Feb 29 17:28:20 2016] hasType :: Context -> Term -> Term -> Bool? [Mon Feb 29 17:28:28 2016] typeOf :: Context -> Term -> Term? [Mon Feb 29 17:28:33 2016] Ctx -> Term -> Type -> m Bool? [Mon Feb 29 17:28:44 2016] i mean it depends on what algorithm are you using really [Mon Feb 29 17:28:54 2016] i don't know any algorithms :> [Mon Feb 29 17:29:02 2016] in bi-directional type checking you need both of those functions [Mon Feb 29 17:29:07 2016] ;-; [Mon Feb 29 17:29:10 2016] one sec [Mon Feb 29 17:29:29 2016] http://www.cs.cmu.edu/~fp/courses/15312-f04/handouts/15-bidirectional.pdf [Mon Feb 29 17:29:32 2016] also, where can i find a proper complete formulation of the CoC [Mon Feb 29 17:30:08 2016] that's a harder question :) [Mon Feb 29 17:30:22 2016] * rests his head in his hands [Mon Feb 29 17:30:28 2016] I JUST WANTED TO WRITE A RIGOROUS CAS [Mon Feb 29 17:31:43 2016] the original CoC paper is linked from the wikipedia page, but it doesn't include inductive types, and is behind a paywall I think [Mon Feb 29 17:31:49 2016] http://www.sciencedirect.com/science/article/pii/0890540188900053 [Mon Feb 29 17:31:57 2016] :\ [Mon Feb 29 17:31:58 2016] i can get it for you [Mon Feb 29 17:32:02 2016] i don't need/want inductive types [Mon Feb 29 17:32:25 2016] i'd just like a clean presentation of the basic CoC in full precision [Mon Feb 29 17:32:27 2016] http://www.cse.chalmers.se/~coquand/meta.pdf here's another one [Mon Feb 29 17:32:34 2016] stelleg you can download it from sceincedirect right? [Mon Feb 29 17:32:42 2016] but the one stelleg linked to might be more consice [Mon Feb 29 17:33:05 2016] Nik05: yeah I have a copy if someone wants it [Mon Feb 29 17:33:45 2016] it also doesn't have a universe heirarchy in that presentation [Mon Feb 29 17:33:55 2016] stelleg doesnt look like its behind a wall [Mon Feb 29 17:34:03 2016] or maybe its because im already logged in [Mon Feb 29 17:36:00 2016] maybe i'll try using "pure type system" [Mon Feb 29 17:36:36 2016] benzrf: if you're wanting to implement a simple dependent type system theres this: http://strictlypositive.org/Easy.pdf [Mon Feb 29 17:37:08 2016] ty :) [Mon Feb 29 17:37:15 2016] it's quite close to the CoC [Mon Feb 29 17:37:53 2016] side note: [Mon Feb 29 17:37:58 2016] i'm looking at this page: https://ncatlab.org/nlab/show/pure+type+system [Mon Feb 29 17:38:13 2016] it says CoC has (□,□) [Mon Feb 29 17:38:19 2016] but doesn't that give Type-in-Type? [Mon Feb 29 17:38:48 2016] oh, wait [Mon Feb 29 17:38:51 2016] never mind >.< [Mon Feb 29 17:42:18 2016] Nik05: I assumed it was behind a wall because my institution shows in the upper right [Mon Feb 29 17:42:31 2016] could be wrong though [Mon Feb 29 17:42:58 2016] stelleg im not logged in right now, and i can just download it :) [Mon Feb 29 17:43:11 2016] cool, glad to hear it [Mon Feb 29 17:43:14 2016] its a good paper :) [Mon Feb 29 17:49:45 2016] johnw didnt you say yesterday that you get "simpl" for free in proof objects? [Mon Feb 29 17:50:40 2016] but why do we not get simpl free when using tactics? [Mon Feb 29 17:52:08 2016] you do with some tactics, but I think you have to be careful because evaluation can explode the tactic search space [Mon Feb 29 17:52:16 2016] johnw please correct me if that's wrong [Mon Feb 29 17:54:19 2016] so I think you "get it for free", but don't want to use it in a lot of cases because it won't help and can actually hurt [Mon Feb 29 17:54:31 2016] oh oke [Mon Feb 29 18:02:13 2016] again that could be wrong, so if someone knows better than I please correct me [Mon Feb 29 18:04:28 2016] I don't think it's "for free" either [Mon Feb 29 18:04:31 2016] not sure when I might have said that... [Mon Feb 29 18:04:40 2016] oh maybe it was jrw [Mon Feb 29 18:05:25 2016] I just presumed that meant "without having to prove termination" [Mon Feb 29 18:41:16 2016] Nik05: I said that, yeah [Mon Feb 29 18:41:25 2016] ah hello jrw [Mon Feb 29 18:44:51 2016] Nik05: so I'm not exactly sure what you mean by not getting it for free in tactics. it sort of boils down to syntax vs semantics. many tactics work by looking fairly naively at the syntax of the context and goal. [Mon Feb 29 18:46:11 2016] but if the underlying system can workout the simplifications, why cant it do that as well for tactics? [Mon Feb 29 18:46:43 2016] well so it's an issue of partial proof/proof search vs checking a complete proof [Mon Feb 29 18:47:13 2016] tactics are generally alergic to normalizing everything because things blow up [Mon Feb 29 18:47:29 2016] so they avoid simplifying things [Mon Feb 29 18:48:45 2016] also there's the issue of partial computation. so if I have a goal G that normalizes to Gn, but there's some intermediate state Gi that I want to apply a rewrite to, that's very hard [Mon Feb 29 18:49:24 2016] Oké i think i get it [Mon Feb 29 18:49:57 2016] simpl altough its called simpl[ify] doesn't simplify most of the time [Mon Feb 29 18:50:45 2016] and with using proof object you can give the type checker the type you want it simplified to but with tactics this isnt possible [Mon Feb 29 18:51:06 2016] no idea if this makes any sense but im my head it does :) [Mon Feb 29 18:52:30 2016] that sounds roughly right [Mon Feb 29 23:28:40 2016] hmmmmmm [Mon Feb 29 23:28:52 2016] am i reading this right: https://ncatlab.org/nlab/show/pure+type+system [Mon Feb 29 23:29:00 2016] cause [Mon Feb 29 23:29:16 2016] it looks to me like if you have "x : Type" in your context, you can't conclude x : Type [Mon Feb 29 23:29:26 2016] b/c Type is not a well-typed term [Tue Mar 1 01:14:01 2016] > hasType Data.StrMap.empty (App (App leibRefl pnat') (peano 3)) (App (App (App leib pnat') (App (App peanoAdd (peano 1)) (peano 2))) (App (App peanoAdd (peano 2)) (peano 1))) [Tue Mar 1 01:14:03 2016] true [Tue Mar 1 01:14:06 2016] this is kind of working c= [Tue Mar 1 01:17:21 2016] also i shouldve named that 'church' rather than 'peano' :I [Tue Mar 1 08:27:18 2016] hello, anyone there? [Tue Mar 1 08:27:20 2016] johnw, jgross? [Tue Mar 1 08:27:23 2016] :> [Tue Mar 1 08:34:46 2016] putting my question out there: in the vanilla CoC, am i supposed to not be able to define things with a type like ((Prop -> Prop) -> Prop) [Tue Mar 1 08:35:28 2016] er, hold on [Tue Mar 1 08:37:39 2016] god dammit now i've lost track of what my problem was :( [Tue Mar 1 08:38:08 2016] ok got it [Tue Mar 1 08:38:57 2016] it seems that I can't type things like (Type -> whatever), because i can only type a variable if i can type its type, and Type is untypeable in vanilla CoC... as far as I can tell? [Tue Mar 1 08:39:29 2016] but this seems to be a problem, because then I can't use a church boolean to pick a Prop, which i need to do fun things like proving that false <> true [Tue Mar 1 08:40:09 2016] or rather, i can do that if i make non-polymorphic church bools that pick out Props only, but then I can't prove false <> true for ordinary ones [Tue Mar 1 08:49:49 2016] benzrf: what do you mean by using a "Church boolean to pick a Prop"? [Tue Mar 1 08:50:05 2016] Also what do you mean by Type is untypable? [Tue Mar 1 09:49:56 2016] benzrf: are you lacking universes? [Tue Mar 1 10:13:08 2016] johnw: yeah [Tue Mar 1 10:13:17 2016] i'm going off the definition of CoC that uses just P and T [Tue Mar 1 10:13:40 2016] equivalently, the one that you get by using a pure type system with * and [] and... etc [Tue Mar 1 10:13:45 2016] er, just * and [] [Tue Mar 1 11:24:27 2016] johnw: any further comment :I? [Tue Mar 1 13:52:12 2016] benzrf: I don't really know what I'm talking about, but my understanding is that in the PTS presentation of vanila CoC, Type is not something you really use in the term language. it's just there so that Prop can be used in the term language. [Tue Mar 1 13:53:18 2016] so you shouldn't really think of Prop in that presentation of CoC as irrelevant or erasable. instead, everything is in Prop. [Tue Mar 1 14:07:51 2016] I have an induction principle for Classes, which I've proven, but because it destructs a proof term, it only works on propositions [Tue Mar 1 14:08:00 2016] I would like to define computations in terms of it [Tue Mar 1 14:08:24 2016] so I'm attempting to just change the proof term's definition so that it's in Set [Tue Mar 1 14:08:33 2016] Does that sound reasonable? [Tue Mar 1 14:08:55 2016] And how do I keep the same default names? [Tue Mar 1 14:09:25 2016] i don't think you can, without explicit naming [Tue Mar 1 14:09:45 2016] When ok_type C : Prop, whenever I intros. it, it start with an H. Now that it is in Set, I get "o" [Tue Mar 1 14:09:52 2016] and I don't want to have to fix all the proofs [Tue Mar 1 14:09:57 2016] yep [Tue Mar 1 14:11:12 2016] sigh [Tue Mar 1 14:14:34 2016] How about changing my computations to be prolog style? Instead of lineage CT C = [A;B;C], write "lineage' CT C [A;B;C]" holds? [Tue Mar 1 14:14:48 2016] so I can define it in terms of the induction principle? [Tue Mar 1 15:06:58 2016] tbelaire1: I don't really understand what you mean [Tue Mar 1 15:07:04 2016] who's induction principle? [Tue Mar 1 15:59:42 2016] jrw: yeah, that's the impression i've gotten [Tue Mar 1 15:59:59 2016] the problem is that anything that returns a Prop is in Type, and then you lose the ability to pass it around [Tue Mar 1 16:01:28 2016] johnw: in essence, if P Object, and (Extends C D -> P D -> P C), then P C [Tue Mar 1 16:02:10 2016] so I can use the chains of subclassing that end on Object to prove things about all classes [Tue Mar 1 16:05:47 2016] does anyone ever have issues with the induction tactic? [Tue Mar 1 16:06:21 2016] i have a case where the induction principle looks correct, and inversion will give me something that looks good for the non-recursive references, but induction gives me garbage [Tue Mar 1 16:07:21 2016] You can see what the induction principle for a type is by addending _ind to it's name [Tue Mar 1 16:07:35 2016] stelleg: could it be an issue of indices vs arguments? [Tue Mar 1 16:07:45 2016] tbelaire: yeah I've done that, and it looks right to me [Tue Mar 1 16:07:47 2016] so, for lists, you can check with Check list_ind. [Tue Mar 1 16:07:49 2016] dang [Tue Mar 1 16:07:54 2016] thanks though [Tue Mar 1 16:08:18 2016] benzrf: hm, maybe. I don't know anything about indices [Tue Mar 1 16:10:04 2016] i see "indices" used in the coq reference, but not defined [Tue Mar 1 16:11:38 2016] stelleg: when you do an inductive definition [Tue Mar 1 16:11:51 2016] indices are parameters of the type that are declared to the left of the : [Tue Mar 1 16:12:02 2016] benzrf: ah, thanks! [Tue Mar 1 16:12:04 2016] they behave differently from arguments declared on the right [Tue Mar 1 16:12:13 2016] e.g. [Tue Mar 1 16:12:31 2016] Inductive Foo (A : Type) : nat -> Type [Tue Mar 1 16:12:59 2016] ^index ^argument [Tue Mar 1 16:13:07 2016] good to know, thanks [Tue Mar 1 16:13:14 2016] ya [Tue Mar 1 16:57:00 2016] bleh [Tue Mar 1 16:57:07 2016] i just tried to write 'match ... with' in purescript :x [Tue Mar 1 16:57:52 2016] hah, I have the same problem switching between haskell and coq [Tue Mar 1 16:57:58 2016] benzrf: I think it's ^parameter ^index [Tue Mar 1 16:58:21 2016] is there a way around the variable scoping issue for apply t with (y:=...) where y is in scope? [Tue Mar 1 16:58:42 2016] has matching changed in the latest version of coq? [Tue Mar 1 16:58:47 2016] johnw: shit, is it? [Tue Mar 1 16:58:50 2016] >_ [Tue Mar 1 16:58:52 2016] >_< [Tue Mar 1 16:59:27 2016] god dammit [Tue Mar 1 16:59:31 2016] how do i keep getting this wrong [Tue Mar 1 16:59:42 2016] PARAMETERS are PARAMETRIC [Tue Mar 1 16:59:46 2016] i should be able to remember that [Tue Mar 1 17:03:41 2016] http://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Tue Mar 1 17:22:28 2016] How do you work backwards from equalities [Tue Mar 1 17:22:34 2016] I want to show that C = D [Tue Mar 1 17:23:07 2016] and I have C :: xs = lineage D, and head (lineage D) = D [Tue Mar 1 17:23:20 2016] I can't seem to put the pieces together [Tue Mar 1 17:23:39 2016] Is there a way to map `head` over both halves of an equality? [Tue Mar 1 17:23:43 2016] You can probably "destruct (lineage D)" first, since you need to chop the head off "lineage D" [Tue Mar 1 17:23:56 2016] tbelaire: usually "congruence" solves those [Tue Mar 1 17:24:16 2016] though you may need the destruct first, as Cypi said [Tue Mar 1 17:24:36 2016] destructing requies induciton over another parameter (that I didn't show) [Tue Mar 1 17:24:48 2016] in a really ugly way [Tue Mar 1 17:25:02 2016] lineage is basically doing a lookup in a linear table [Tue Mar 1 17:25:04 2016] Or maybe you can just use "C :: xs = lineage D" to rewrite in "head (lineage D) = D" actually [Tue Mar 1 17:25:12 2016] tbelaire: rewrite <- equality1 in equality2 [Tue Mar 1 17:25:16 2016] simpl in equality2 [Tue Mar 1 17:25:17 2016] :) [Tue Mar 1 17:25:55 2016] I need to go from C :: xs = lineage D to head (C :: xs) = head (lineage D( [Tue Mar 1 17:25:57 2016] )) [Tue Mar 1 17:26:06 2016] which is totally true [Tue Mar 1 17:26:11 2016] is that a list theorem? [Tue Mar 1 17:26:22 2016] I didn't see in on https://coq.inria.fr/distrib/current/stdlib/Coq.Lists.List.html [Tue Mar 1 17:26:35 2016] f_equal, [Tue Mar 1 17:26:40 2016] but i already told you one approach :o [Tue Mar 1 17:27:00 2016] f_equal head in the_equality [Tue Mar 1 17:28:49 2016] oh [Tue Mar 1 17:28:53 2016] I didn't understand [Tue Mar 1 17:29:00 2016] oh [Tue Mar 1 17:29:04 2016] that's much more general [Tue Mar 1 17:29:10 2016] oh, yeah, that's great okay [Tue Mar 1 17:29:22 2016] I guess that didn't actually have anything to do wiht lists [Tue Mar 1 17:42:32 2016] :) [Tue Mar 1 17:42:49 2016] i used coq on and off for several months before finding out about f_equal [Tue Mar 1 17:42:56 2016] and i'd /looked/ a few times [Tue Mar 1 17:43:08 2016] :) [Tue Mar 1 17:43:09 2016] er, looked for something that does what f_equal does, i mean [Tue Mar 1 17:43:25 2016] I use f_equal pretty often [Tue Mar 1 17:43:26 2016] actually maybe it was more like a year, but "on and off" was mostly off [Tue Mar 1 17:43:45 2016] benzrf: there's also f_equiv [Tue Mar 1 17:44:05 2016] right now im busy in another window implementing f_equal by writing out a proof term by hand as its AST in purescript [Tue Mar 1 17:44:08 2016] ~fun~ [Tue Mar 1 17:44:26 2016] i *think* i finally got it to work [Tue Mar 1 17:44:31 2016] it typechecked anyway [Tue Mar 1 17:48:20 2016] WOO [Tue Mar 1 17:48:21 2016] > has f_equal $ Pi "A" Small $ Pi "B" Small $ Pi "f" (Var "A" `arr` Var "B") $ Pi "x" (Var "A") $ Pi "y" (Var "A") $ (leib `App` Var "A" `App` Var "x" `App` Var "y") `arr` (leib `App` Var "B" `App` (Var "f" `App` Var "x") `App` (Var "f" `App` Var "y")) [Tue Mar 1 17:48:23 2016] true [Tue Mar 1 17:49:02 2016] welp, time to scrap my hacky-ass CoC implementation and read up on how to do it nonterribly [Tue Mar 1 17:49:04 2016] There are probably more readable ways of proving that :-° [Tue Mar 1 17:49:11 2016] Cypi: that's not the proof, silly [Tue Mar 1 17:49:16 2016] here's the proof: [Tue Mar 1 17:49:17 2016] Oh, sorry :D [Tue Mar 1 17:49:18 2016] let f_equal = Abs "A" Small $ Abs "B" Small $ Abs "f" (Var "A" `arr` Var "B") $ Abs "x" (Var "A") $ Abs "y" (Var "A") $ Abs "e" (App (App (App leib (Var "A")) (Var "x")) (Var "y")) $ App (App (Var "e") (Abs "z" (Var "A") (App (App (App leib (Var "B")) (App (Var "f") (Var "x"))) (App (Var "f") (Var "z"))))) (App (App leibRefl (Var "B")) (App (Var "f") (Var "x"))) [Tue Mar 1 17:49:22 2016] That's better [Tue Mar 1 18:22:27 2016] jgross: ping [Tue Mar 1 18:35:56 2016] johnw: pong, but I'm disappearing pretty soon [Tue Mar 1 18:36:05 2016] query jgross [Tue Mar 1 21:05:51 2016] So I realized just the other day that you can't really construct free groups in Coq (without any axioms). [Tue Mar 1 21:07:02 2016] If you want to perform the free group construction without normalizing the elements, you need equivalence classes. If you want to perform the free group construction with normalizing the elements, you need decidable equality. [Tue Mar 1 21:16:29 2016] Unrelated... [Tue Mar 1 21:17:01 2016] I can't quite figure out how to get a Coq project with modules working. [Tue Mar 1 21:18:10 2016] Does my project have to have a name for me to stick onto the beginning of all my module paths? [Tue Mar 1 21:18:39 2016] And if so, do my .v files have to be in a directory of the same name? [Tue Mar 1 21:23:22 2016] hmm free commutative monoids should have the same problem, right? [Tue Mar 1 21:23:43 2016] seems that only free monoids avoid it, due to lists being somehow hard-coded in the inductive definition system [Tue Mar 1 21:27:06 2016] Yeah, same problem. I can't imagine that monoids are the *only* algebraic structure without that problem... [Tue Mar 1 21:27:09 2016] (Well, the only common one.) [Tue Mar 1 21:28:59 2016] I guess commutativity and inverses both introduce the problem. Monoids have both of the "usual" axioms that avoid the problem: associativity and identity. [Tue Mar 1 21:31:52 2016] But you can do free categories. [Tue Mar 1 21:33:32 2016] I figured out the modules thing, by the way. I am not specifying a name for the project, and I'm sticking "Top." onto the beginning of all my module paths. [Tue Mar 1 23:57:52 2016] is it possible to prove [true <> false] in the CoC with only Prop and Type, where true and false are polymorphic church bools? [Tue Mar 1 23:58:06 2016] er, and with leibniz equality, and false is forall A : Prop, A [Wed Mar 2 00:02:50 2016] benzrf: so your CoC has equality built in? [Wed Mar 2 00:02:55 2016] no [Wed Mar 2 00:02:59 2016] leibniz eq [Wed Mar 2 00:03:21 2016] leib = Abs "A" Small $ Abs "x" (Var "A") $ Abs "y" (Var "A") $ Pi "P" (Var "A" `arr` Small) $ App (Var "P") (Var "x") `arr` App (Var "P") (Var "y") [Wed Mar 2 00:04:23 2016] ah ok church encoding of eq [Wed Mar 2 00:05:17 2016] benzrf: what is Small? [Wed Mar 2 00:05:38 2016] Prop [Wed Mar 2 00:05:41 2016] ok [Wed Mar 2 00:05:50 2016] I called Prop and Type "Small" and "Large" [Wed Mar 2 00:05:56 2016] sounds good [Wed Mar 2 00:05:58 2016] since Prop and Type are not reflective names in this context [Wed Mar 2 00:06:03 2016] yes I think it should be possible [Wed Mar 2 00:07:16 2016] i cant figure out how [Wed Mar 2 00:07:32 2016] benzrf: what's your encoding of bool? [Wed Mar 2 00:07:45 2016] ah yeah, this is tough without builtin bool [Wed Mar 2 00:07:53 2016] church bools won't cut it [Wed Mar 2 00:08:01 2016] you need the dependent eliminator [Wed Mar 2 00:08:04 2016] :( [Wed Mar 2 00:09:20 2016] well, hm let me think [Wed Mar 2 00:09:27 2016] honestly i have to sleep [Wed Mar 2 00:09:31 2016] :) ok [Wed Mar 2 00:09:33 2016] perhaps you're not in EST, but it's just past midnight [Wed Mar 2 00:09:38 2016] ty for looking though! [Wed Mar 2 00:09:38 2016] PST here [Wed Mar 2 00:09:45 2016] I'll ping you tomorrow [Wed Mar 2 00:09:51 2016] ty [Wed Mar 2 00:09:55 2016] see you [Wed Mar 2 00:10:06 2016] I'm not sure, maybe I did not understand anything, but would that satisfy you benzrf? http://lpaste.net/153843 [Wed Mar 2 00:10:09 2016] Oops, too late [Wed Mar 2 00:11:01 2016] the usual proof is something like: \H : true = false. eq_elim bool (\z:bool. if z then True else False) true tt false H. [Wed Mar 2 00:11:51 2016] Cypi: that looks right to me [Wed Mar 2 10:46:53 2016] I'm pondering whether or not I want to admit uniqueness of identity proofs as an axiom. [Wed Mar 2 10:48:29 2016] On the one hand, my original plan here was to use no axioms. Doing it all without axioms seems a lot more interesting and educational. [Wed Mar 2 10:50:19 2016] On the other paw, proving equalities between equalities sounds like it could be a huge headache. [Wed Mar 2 10:54:30 2016] I dunno. I think I'll try going without it for a while... but it's going to be tough, isn't it? [Wed Mar 2 15:23:12 2016] how do I define things in a module such that clients of the module can never see them? I remember seeing code that did this using an "exports" section, but I can't find that reference anymore [Wed Mar 2 15:29:43 2016] ah, Programs and Proofs uses this [Wed Mar 2 18:20:33 2016] hey so uh, how do i debug plugins with ocamldebug? [Wed Mar 2 18:20:46 2016] i can't set breakpoints [Wed Mar 2 18:20:48 2016] etc [Wed Mar 2 18:23:31 2016] if it typechecks, it's correct [Wed Mar 2 18:24:41 2016] Chouhartem: are you talking to me? [Wed Mar 2 18:28:26 2016] spacekitteh : the way I did it is to create a custom coqtop by using coqmktop, and adding the files of your plugin [Wed Mar 2 18:28:36 2016] hmmm [Wed Mar 2 18:35:51 2016] i don't think coqmktop is working. keeps complaining about now finding threads.cma [Wed Mar 2 18:38:11 2016] not* [Wed Mar 2 19:11:13 2016] the commands in the reference manual for coqmktop don't work :< [Wed Mar 2 19:14:17 2016] someone here said they were doing something with 'fiat' [Wed Mar 2 19:14:27 2016] I tried downloading it and running make [Wed Mar 2 19:14:45 2016] it spends 15+minutes on examples/Bookstore.v [Wed Mar 2 19:14:49 2016] is that normal? [Wed Mar 2 19:56:20 2016] hi [Wed Mar 2 19:56:32 2016] rrika: depends on your machine [Wed Mar 2 19:56:44 2016] it doesn't take 15 mins to build for me, I don't think [Wed Mar 2 20:02:59 2016] I'm gonna go ahead and use UIP. I'm trying to study categories and groups and whatnot, not higher categories and higher groups and whatnot. [Wed Mar 2 20:03:40 2016] tswett: I'd first read the CPDT section that discusses UIP [Wed Mar 2 20:03:56 2016] and how Adam avoids axioms in same cases that would use it [Wed Mar 2 20:16:54 2016] Note that I'm planning on having a lot of things be opaque. [Wed Mar 2 20:18:17 2016] My implementation of free monoids, for instance. The FreeMonoid type will, of course, have a definition, but I'm not going to allow the definition to be used outside of that module. [Wed Mar 2 20:18:50 2016] Of course, that means that you can't use the definition of the identity and multiplication operations, either. [Wed Mar 2 20:37:38 2016] I'd be interested to learn how you achieve your abstraction [Wed Mar 2 21:53:36 2016] anyone got any ideas on how to debug a plugin? [Wed Mar 2 21:53:46 2016] * is trying to make the haskell code extraction better [Wed Mar 2 23:35:12 2016] anyone know how? :( [Wed Mar 2 23:47:38 2016] spacekitteh: oh cool, what have you tried? [Wed Mar 2 23:47:45 2016] I would like to improve Haskell extraction as well [Wed Mar 2 23:48:08 2016] johnw: i'm trying to make extraction of typeclasses better, for starters [Wed Mar 2 23:48:23 2016] better? you mean it exists at all? [Wed Mar 2 23:48:26 2016] but i can't figure out the right combination of type variables etc to print out [Wed Mar 2 23:48:35 2016] it exists in that it extracts dictionaries as datastructures [Wed Mar 2 23:48:55 2016] so you can use typeclasses in coq but it won't create typeclasses in haskell [Wed Mar 2 23:49:11 2016] right [Wed Mar 2 23:49:16 2016] it's doing what Haskell is doing behind the scenes [Wed Mar 2 23:49:27 2016] which makes sense, since instance resolution isn't exactly the same [Wed Mar 2 23:50:43 2016] indeed [Wed Mar 2 23:51:02 2016] but it could probably be made to behave similarly [Wed Mar 2 23:51:34 2016] I very much doubt that [Wed Mar 2 23:51:45 2016] Coq allows for things like instance preferences [Wed Mar 2 23:51:49 2016] that Haskell never will [Wed Mar 2 23:52:07 2016] so, to ensure that what you typecheck in Coq is what you'll get in the extraction, you need to take Haskell out of the loop, so to speak [Wed Mar 2 23:52:24 2016] and just treat Haskell as a capable lambda calculus [Wed Mar 2 23:53:06 2016] i'm thinking about using edkmett's reflection package to emulate it [Wed Mar 2 23:53:27 2016] where you reify a manually made dictionary into a type class instance [Wed Mar 2 23:53:43 2016] i'm interested to see how it works out for you [Wed Mar 2 23:53:48 2016] so am i ahaha [Wed Mar 2 23:53:56 2016] I spend a lot of time fine-tuning Haskell extraction [Wed Mar 2 23:54:02 2016] but not at the Ocaml level yet [Wed Mar 2 23:54:49 2016] * nodnods [Wed Mar 2 23:54:59 2016] this is just a sideproject for me though [Wed Mar 2 23:55:04 2016] we use isabelle at work, not coq [Wed Mar 2 23:55:08 2016] much to my chagrin [Wed Mar 2 23:56:53 2016] some of my co-workers use isabelle too [Wed Mar 2 23:56:56 2016] but I haven't yet [Wed Mar 2 23:57:43 2016] what do you do? [Wed Mar 2 23:59:13 2016] I'm working on DARPA contracts with BAE Systems [Wed Mar 2 23:59:36 2016] so we use formal methods are various kinds in many ways [Wed Mar 2 23:59:41 2016] my last project used ACL2 [Wed Mar 2 23:59:47 2016] i think we are on the same project hahaha [Wed Mar 2 23:59:54 2016] but I prefer Coq so far the most [Wed Mar 2 23:59:55 2016] HACCM/SMACCM? [Thu Mar 3 00:00:05 2016] we did work on HACCMs, yes [Thu Mar 3 00:00:08 2016] not me directly though [Thu Mar 3 00:00:10 2016] ah [Thu Mar 3 00:00:29 2016] which company are you with? [Thu Mar 3 00:00:37 2016] nicta/data61 [Thu Mar 3 00:00:40 2016] ahh [Thu Mar 3 00:00:43 2016] very cool [Thu Mar 3 00:00:50 2016] so in a sense we're very much "industry adjacent" :) [Thu Mar 3 00:00:57 2016] indeed :V [Thu Mar 3 00:01:14 2016] even though i'm just an aerospace engineering undergrad lmfao [Thu Mar 3 00:01:49 2016] i'm an ex-compiler engineer [Thu Mar 3 00:02:25 2016] cool [Thu Mar 3 00:02:32 2016] i'm working on a hott compiler [Thu Mar 3 00:02:38 2016] trying to do the core in coq and extract it to haskell [Thu Mar 3 00:02:43 2016] nice [Thu Mar 3 00:02:45 2016] using 8.5? [Thu Mar 3 00:02:49 2016] ye [Thu Mar 3 00:02:54 2016] well, trunk [Thu Mar 3 00:02:56 2016] the Haskell extraction is much better there [Thu Mar 3 00:02:59 2016] I'm still on 8.4 [Thu Mar 3 00:03:08 2016] oh god, it was worse in 8.4? [Thu Mar 3 00:03:33 2016] oh, FAR worse [Thu Mar 3 00:03:47 2016] i spent several days last week tracking down a SEGV due to a misplaced unsafeCoerce [Thu Mar 3 00:04:05 2016] I use a Perl file called "fixcode.pl" to correct all the errors I find [Thu Mar 3 00:04:10 2016] in 8.5, it's most unnecessary [Thu Mar 3 00:08:13 2016] oh dear [Thu Mar 3 01:20:14 2016] anyone know when SF will reach version 4 officially? [Thu Mar 3 01:28:55 2016] rrika: I heard it would probably this summer [Thu Mar 3 01:29:28 2016] they usually teach the course in the fall each year, so they will have to have it ready in time for that [Thu Mar 3 01:29:46 2016] i see. [Thu Mar 3 01:31:58 2016] right, changing it mid-semester would be insanity [Thu Mar 3 14:46:38 2016] I need some help. [Thu Mar 3 14:47:00 2016] I've sucessfully creating my induction principle for chains of inheritence [Thu Mar 3 14:47:02 2016] https://github.com/tbelaire/FJ-Formalization/blob/master/FJ_Definitions.v#L447 [Thu Mar 3 14:47:05 2016] Hurah [Thu Mar 3 14:47:21 2016] but now I've tried to define method lookup in terms of it [Thu Mar 3 14:47:29 2016] which also worked and looked solid [Thu Mar 3 14:47:42 2016] https://github.com/tbelaire/FJ-Formalization/blob/master/FJ_Definitions.v#L733 [Thu Mar 3 14:48:13 2016] It works and doesn't have to deal with recursing over the list directly [Thu Mar 3 14:48:16 2016] which is great [Thu Mar 3 14:48:46 2016] but now I'm trying to prove that mresolve2 CT m Object = None [Thu Mar 3 14:48:51 2016] for all things [Thu Mar 3 14:49:10 2016] and I have no idea how to go about proving it [Thu Mar 3 14:49:16 2016] hi [Thu Mar 3 14:49:26 2016] really, I guess I'd hoped that it'd apply the P Object case [Thu Mar 3 14:49:29 2016] find that it's null [Thu Mar 3 14:49:36 2016] and be done [Thu Mar 3 14:49:38 2016] where is the proof attempt? [Thu Mar 3 14:49:40 2016] but it's trying to run list_ind first [Thu Mar 3 14:49:45 2016] 1660 [Thu Mar 3 14:50:42 2016] are you familiar with "induction X using Y"? [Thu Mar 3 14:50:47 2016] Not really [Thu Mar 3 14:50:59 2016] you shouldn't need to apply ClassTable_rect directly [Thu Mar 3 14:51:06 2016] however, that's not the problem at 1660 [Thu Mar 3 14:51:19 2016] what I think you'd need to do here is destruct CT [Thu Mar 3 14:51:28 2016] to get the various branches of ClassTable_rect to "fire" and simplify to their contents [Thu Mar 3 14:51:35 2016] rather than unfolding ClassTable_rect [Thu Mar 3 14:52:22 2016] lets see okay [Thu Mar 3 14:53:33 2016] it's getting stuck on eq_rect_r [Thu Mar 3 14:53:41 2016] ah! [Thu Mar 3 14:53:57 2016] there's a section in CPDT about proofs involving such equalities [Thu Mar 3 14:54:06 2016] can you show me the new proof and context+goal? [Thu Mar 3 14:55:11 2016] https://gist.github.com/tbelaire/d1dbe5c41a35c4accd8f [Thu Mar 3 14:55:53 2016] I would just do: [Thu Mar 3 14:56:02 2016] induction CT0; simpl; intros. [Thu Mar 3 14:56:09 2016] well, maybe first an unfold mresolve2 [Thu Mar 3 14:56:27 2016] so, eq_rect_r is the term level expression of a rewrite [Thu Mar 3 14:56:38 2016] (a rewrite <-, to be precise) [Thu Mar 3 14:57:02 2016] apparently "ok_obj nil" is the same thing as None? [Thu Mar 3 14:57:39 2016] that's not right... [Thu Mar 3 14:58:01 2016] this (fun _ : ok_type_ nil Object => None) [Thu Mar 3 14:58:10 2016] is where I'd expect None to come from [Thu Mar 3 15:00:29 2016] since that's the P argument to eq_rect_r [Thu Mar 3 15:01:45 2016] anyways, even if I solve the nil case, the inductive case has a goal over 900 lines long, after I run simpl [Thu Mar 3 15:02:49 2016] that's odd [Thu Mar 3 15:02:55 2016] you'd think that case wouldn't even happen [Thu Mar 3 15:03:05 2016] well [Thu Mar 3 15:03:22 2016] the induction hypothesis should be a clear inequality [Thu Mar 3 15:03:23 2016] It could happen that we're proving something about Object while we have a non-empty class table [Thu Mar 3 15:04:30 2016] I mean, I was hoping to define things in terms of ClassTable_rect to avoid needing to induction on the class table in every proof [Thu Mar 3 15:04:47 2016] and instead show things for just the important cases [Thu Mar 3 15:04:55 2016] in the chains of inheritance [Thu Mar 3 15:05:45 2016] ahh [Thu Mar 3 15:05:47 2016] If I need to induct on CT anyways, well there isn't that much of a point [Thu Mar 3 15:06:00 2016] you want to use recursors [Thu Mar 3 15:06:09 2016] cool, what's that? [Thu Mar 3 15:06:17 2016] ClassTable_rect [Thu Mar 3 15:06:26 2016] it's when you represent your data type as the closure of a fold [Thu Mar 3 15:06:41 2016] in which case I then ask, why have the ClassType inductive type at all? [Thu Mar 3 15:06:44 2016] just use its final encoding [Thu Mar 3 15:06:57 2016] where is ClassTable defined? [Thu Mar 3 15:07:31 2016] with a final encoding, you drop constructors, and values of your data type become closures [Thu Mar 3 15:07:51 2016] you lose the ability to easily pattern match, but you also avoid direct recursion in your proofs [Thu Mar 3 15:07:56 2016] hmm [Thu Mar 3 15:08:09 2016] for example, Inductive List a := Nil | Cons a (List a) [Thu Mar 3 15:08:11 2016] has the final form [Thu Mar 3 15:08:24 2016] Definition ListFinal a := forall r, r -> (a -> r -> r) -> r. [Thu Mar 3 15:08:30 2016] this is flists? [Thu Mar 3 15:08:32 2016] and these two can be proven to be isomorphic [Thu Mar 3 15:08:38 2016] yeah I've seen that for lists before [Thu Mar 3 15:08:55 2016] i don't know what an flist is [Thu Mar 3 15:09:05 2016] and google isn't telling me quickly [Thu Mar 3 15:09:17 2016] ah, maybe that was just the term used on the exam [Thu Mar 3 15:09:22 2016] it's just exactly that [Thu Mar 3 15:09:37 2016] so, any algebraic inductive type has a trivial final encoding [Thu Mar 3 15:09:50 2016] however, I'm not sure that is what you need or want [Thu Mar 3 15:10:06 2016] so, the class table is a list of tuples [Thu Mar 3 15:10:17 2016] with more condidtions imposed [Thu Mar 3 15:10:40 2016] as we want to look up each ancestor for a class [Thu Mar 3 15:11:13 2016] but I really would like to hide that representation [Thu Mar 3 15:11:18 2016] a little from the proofs [Thu Mar 3 15:11:31 2016] how about if you just: [Thu Mar 3 15:11:31 2016] and just talk about each class's ancestor [Thu Mar 3 15:11:37 2016] induction CT using ClassTable_rect? [Thu Mar 3 15:11:51 2016] it claims there are not enough parameters [Thu Mar 3 15:12:01 2016] I think it's because of your "ok_type_ CT C" argument [Thu Mar 3 15:12:10 2016] so try: [Thu Mar 3 15:12:13 2016] Error: in _: Not the right number of induction arguments. [Thu Mar 3 15:12:16 2016] induction CT using (ClassTable_rect X) [Thu Mar 3 15:12:21 2016] where X is of type ok_type_ CT C [Thu Mar 3 15:12:41 2016] Cannot recognize an induction scheme. [Thu Mar 3 15:12:57 2016] hmm [Thu Mar 3 15:13:08 2016] you've got too many arguments there I think still [Thu Mar 3 15:13:12 2016] like "directed_ct CT" [Thu Mar 3 15:13:15 2016] it's not fitting the "shape" [Thu Mar 3 15:13:53 2016] trying to fill them in [Thu Mar 3 15:15:19 2016] I've been considering doing a refactoring to replace all the cnames with dependent tuples of { C; ok_type C} [Thu Mar 3 15:15:23 2016] would that help the shape? [Thu Mar 3 15:15:44 2016] you'd only be able to induct over such things [Thu Mar 3 15:16:16 2016] yeah, but that's fine, I only care about classes that exist in the class table anyways [Thu Mar 3 15:17:11 2016] I'm just concerned that that'll strengthen the requirement to call some lemmas if I do it uniformly [Thu Mar 3 15:17:17 2016] and cause problems [Thu Mar 3 15:17:27 2016] so, here's a way to think about custom induction principles [Thu Mar 3 15:17:40 2016] refine (Class_rect _ _). [Thu Mar 3 15:17:48 2016] where each "_" represent a "branch" of the induction [Thu Mar 3 15:17:49 2016] we should be able to do the same thing as induction _ using _. using apply [Thu Mar 3 15:17:52 2016] yup [Thu Mar 3 15:17:55 2016] this will generate two goals, one for each branch [Thu Mar 3 15:18:02 2016] which is pretty much what "induction using" is going to do [Thu Mar 3 15:18:12 2016] but I don't really want to induct, as that'll erase information I need here [Thu Mar 3 15:18:16 2016] ah [Thu Mar 3 15:18:20 2016] what I really want is some sort of inversion [Thu Mar 3 15:18:32 2016] you could write a custom inversion principle [Thu Mar 3 15:18:40 2016] ah, good idea [Thu Mar 3 15:18:42 2016] that's what I need [Thu Mar 3 15:18:44 2016] that is, given a CT, what truth can be determined from it [Thu Mar 3 15:19:06 2016] Coq's stdlib has lots of these, actually, they are usually named "..._inv" or "..._impl" [Thu Mar 3 15:19:31 2016] let me look for some examples of those [Thu Mar 3 15:19:40 2016] look at List.Forall [Thu Mar 3 15:21:01 2016] sure [Thu Mar 3 15:23:30 2016] Lemma Forall_inv : forall (a:A) l, Forall (a :: l) -> P a. [Thu Mar 3 15:23:32 2016] ? [Thu Mar 3 15:23:43 2016] exactly [Thu Mar 3 15:23:55 2016] something that you'd expect "inversion" to provide [Thu Mar 3 15:24:10 2016] although, there are some cases where what inversion does isn't quite what you want to happen [Thu Mar 3 15:24:17 2016] so these custom inversion function can be very handy [Thu Mar 3 15:25:06 2016] wait, I can't want inversion, since I don't have it as a hypothesis [Thu Mar 3 15:25:13 2016] ah [Thu Mar 3 15:25:26 2016] yeah I just need to let simpl work [Thu Mar 3 15:25:28 2016] brb [Thu Mar 3 15:37:00 2016] hmm, I could try and simplify the definition of ClassTable_rect [Thu Mar 3 15:37:12 2016] but I'm not sure if that will actaully help [Thu Mar 3 15:37:52 2016] I don't really want to have to deal with the internals at all. [Thu Mar 3 15:42:03 2016] I'm going to try something simpler [Thu Mar 3 15:42:08 2016] just the number of ancestors [Thu Mar 3 15:42:17 2016] and see if I can prove anything about it [Thu Mar 3 15:50:06 2016] nah, can't [Thu Mar 3 15:50:16 2016] I'll try and remove that ok_type_ requirement [Thu Mar 3 15:50:21 2016] see if I can prove it without that [Thu Mar 3 15:53:08 2016] that really doesn't work [Thu Mar 3 15:53:24 2016] since I can't assume the class is one I know anything about [Thu Mar 3 15:53:52 2016] lets try that dependant type pair idea [Thu Mar 3 15:55:04 2016] aka sigma [Thu Mar 3 16:00:27 2016] is there a way to skip the assert and just define a term and add it to your hypotheses? I vaugely recall being able to do this but can't remember how [Thu Mar 3 16:02:45 2016] e.g. instead of assert nat as N. apply 0. is there a way to just say define N 0? [Thu Mar 3 16:07:36 2016] ah set (N:=0). [Thu Mar 3 16:13:59 2016] Definition Class_ (CT:ctable) := forall C : cname, {C : cname | ok_type_ CT C}. [Thu Mar 3 16:14:06 2016] is that reasonable? [Thu Mar 3 16:14:21 2016] if I want to have cnames where I know they are ok_type [Thu Mar 3 16:14:25 2016] you don't need the forall [Thu Mar 3 16:14:38 2016] how do I get the C in scope? [Thu Mar 3 16:14:47 2016] oh [Thu Mar 3 16:14:48 2016] { C : cname [Thu Mar 3 16:14:49 2016] it is [Thu Mar 3 16:14:51 2016] magic [Thu Mar 3 16:15:15 2016] forall C : cname and { C : cname even mean exactly opposite things :) [Thu Mar 3 16:15:25 2016] one is "defined for any C" and the other is "defined for some C" [Thu Mar 3 16:15:34 2016] sure, yes [Thu Mar 3 16:16:03 2016] now, I want to construct a value for Object [Thu Mar 3 16:16:15 2016] given proof of okayness (ok_obj CT) [Thu Mar 3 16:16:22 2016] Definition Object_ (CT:ctable) : Class_ CT := [Thu Mar 3 16:16:24 2016] exist Object (ok_obj CT). [Thu Mar 3 16:16:26 2016] doesn't work [Thu Mar 3 16:16:49 2016] exist _ Object (ok_obj CT) [Thu Mar 3 16:17:23 2016] what's the _? [Thu Mar 3 16:17:28 2016] oh [Thu Mar 3 16:17:30 2016] P [Thu Mar 3 16:17:33 2016] I see now [Thu Mar 3 16:26:01 2016] good morning, fellow proof assistant comrades [Thu Mar 3 16:26:07 2016] good morning, spacekitteh! [Thu Mar 3 16:26:12 2016] how is Australia today? [Thu Mar 3 16:26:19 2016] it's okay [Thu Mar 3 16:26:23 2016] kinda warm still [Thu Mar 3 16:26:30 2016] fuck global warming [Thu Mar 3 16:26:39 2016] how's the US [Thu Mar 3 16:26:42 2016] Good morning [Thu Mar 3 16:26:47 2016] pretty nice today [Thu Mar 3 16:26:52 2016] Canada's got snow everywhere [Thu Mar 3 16:26:56 2016] jelly [Thu Mar 3 16:27:24 2016] it's not actually nice outside [Thu Mar 3 16:27:35 2016] i love snow tho [Thu Mar 3 16:27:40 2016] though I do agree that too cold is more fixable than too warm [Thu Mar 3 16:27:46 2016] you can keep adding layers [Thu Mar 3 16:28:01 2016] i have had snowball fights with swedes where i was just in cargo pants and a tank top [Thu Mar 3 16:28:13 2016] and they were like "wtf why isn't she freezing" [Thu Mar 3 16:29:16 2016] i am not suited to australian weather :( [Thu Mar 3 16:33:06 2016] spacekitteh: where are you from, besides space? [Thu Mar 3 16:33:15 2016] straya [Thu Mar 3 16:33:23 2016] where is straya? [Thu Mar 3 16:33:24 2016] she sounds too tough for a queenslander :) [Thu Mar 3 16:33:31 2016] ah [Thu Mar 3 16:33:31 2016] i am indeed a queenslander [Thu Mar 3 16:33:34 2016] just moved to sydney though [Thu Mar 3 16:33:51 2016] still to hot for you down there? [Thu Mar 3 16:33:58 2016] yeah. [Thu Mar 3 16:34:03 2016] anything over 20c = GTFO [Thu Mar 3 16:34:16 2016] autism is a hell of a drug [Thu Mar 3 16:34:59 2016] yeah sounds like you are on the wrong continent [Thu Mar 3 16:35:22 2016] maybe we can trade [Thu Mar 3 16:35:25 2016] i love queensland [Thu Mar 3 16:35:29 2016] heh [Thu Mar 3 16:35:44 2016] gimme 1980s east berlin and you got yourself a deal [Thu Mar 3 16:35:59 2016] hah [Thu Mar 3 16:36:20 2016] high desert in SW USA close enough? [Thu Mar 3 16:36:51 2016] i guess [Thu Mar 3 17:18:26 2016] curious how everyone builds their coq projects [Thu Mar 3 17:18:51 2016] i ended up using shake and coqdep after not having much luck with coq_makefile [Thu Mar 3 17:19:11 2016] I use coq_makefile, with a Makefile around it [Thu Mar 3 17:19:23 2016] stelleg: I use coq_makefile with a _CoqProject file [Thu Mar 3 17:19:27 2016] yeah, and _CoqProject [Thu Mar 3 17:19:36 2016] stelleg: https://gist.github.com/851503119553cdcd2808 [Thu Mar 3 17:19:40 2016] that's my current project's Makefile [Thu Mar 3 17:20:53 2016] johnw: cool, thanks [Thu Mar 3 17:22:57 2016] fixcode.pl :) [Thu Mar 3 17:24:01 2016] so does anyone have any idea how to debug plugins? [Thu Mar 3 17:26:11 2016] * has yet to install a plugin [Thu Mar 3 17:28:32 2016] spacekitteh: no idea at all [Thu Mar 3 17:28:42 2016] =[ [Thu Mar 3 17:53:10 2016] jrw: thanks for _CoqProject tip [Thu Mar 3 17:53:49 2016] stelleg: https://gist.github.com/870023c358a27a2737a6 [Thu Mar 3 17:53:58 2016] that's my _CoqProject that goes with the Makefile [Thu Mar 3 17:54:08 2016] and works for both 8.4 and 8.5 [Thu Mar 3 17:56:15 2016] johnw: thanks [Thu Mar 3 18:00:11 2016] johnw: do you use proof general? [Thu Mar 3 18:00:43 2016] yes [Thu Mar 3 18:01:28 2016] did the move to 8.5 cause any issues? [Thu Mar 3 18:01:48 2016] no [Thu Mar 3 18:01:54 2016] not from the PG perspective [Thu Mar 3 18:02:03 2016] i still use 8.4 on this particular project [Thu Mar 3 18:02:06 2016] but 8.5 on others [Thu Mar 3 18:03:55 2016] ok thanks, I think I'll take a swing at moving coquille (a vim-coq plugin) work with 8.5 [Fri Mar 4 06:08:21 2016] asmanur: hi, remember that sigma vs pi type? can you recommend some material to help understand why they are both necessary and be "dual"? [Fri Mar 4 06:08:54 2016] they are not really dual [Fri Mar 4 06:09:27 2016] asmanur: hmm, I heard it's a concept in category theory, so I have to learn category to understand it? [Fri Mar 4 06:09:39 2016] but I don't know anything in particular in the literature [Fri Mar 4 06:09:43 2016] weellll [Fri Mar 4 06:09:57 2016] yeah, it's not dual it's adjoint [Fri Mar 4 06:10:47 2016] but yeah I find the categorical intepretation quite enlightening [Fri Mar 4 06:11:34 2016] OK I guess I have to learn some category theory. [Fri Mar 4 06:22:07 2016] but your question is a bit orthogonal to dependant types, the situation kind of already happens in the simply typed setting [Fri Mar 4 06:23:43 2016] huh? you mean A->B and A*B? [Fri Mar 4 08:52:49 2016] hello there [Fri Mar 4 09:04:24 2016] riaqn: yes [Fri Mar 4 13:58:17 2016] riaqn: in Coq they are not both necessary [Fri Mar 4 13:58:43 2016] riaqn: using pi types alone, you can express sigma types [Fri Mar 4 13:59:30 2016] for example, a sigma { n : nat | n < 10 } could be encoded as a function forall r, (forall n : nat, n < 10 -> r) -> r [Fri Mar 4 14:52:12 2016] jgross: ping [Fri Mar 4 17:50:40 2016] johnw: yeah, that's what I thought, and it has been haunted me for days. [Fri Mar 4 17:52:09 2016] johnw: but asmanur told me that it's impossible to derive some rules by this encoding. [Fri Mar 4 17:53:16 2016] johnw: but I still doesn't understand why. until yesterday I found this link: http://math.stackexchange.com/questions/661511/is-it-possible-to-express-sigma-type-in-martin-l%C3%B6f-type-theory-with-other-constr [Fri Mar 4 17:54:33 2016] or this: http://mathoverflow.net/questions/16442/can-dependent-sums-be-encoded-as-dependent-products [Fri Mar 4 18:14:15 2016] oh, sorry for the numerous grammar errors above. [Fri Mar 4 18:48:23 2016] is there some nice haskell or purescript implementation of the CoC or some similar consistent type theory [Fri Mar 4 18:48:29 2016] lambda-pi has type in type i think [Fri Mar 4 18:50:12 2016] what's lambda-pi? could you give me some links? [Fri Mar 4 18:50:21 2016] you mean forall-pi? [Fri Mar 4 18:52:12 2016] ok I guess (s)he means this: https://www.andres-loeh.de/LambdaPi/ [Fri Mar 4 19:00:00 2016] ah [Sat Mar 5 03:58:13 2016] riaqn: given pi types and inductive data types, we can represent sigma using the introduction rule for some "sig" data type, giving you an induction principle [Sat Mar 5 03:58:53 2016] but then we're using more than pi-types [Sat Mar 5 03:59:14 2016] however, Coq acquired inductive data types partly because of this shortcoming of the Church encoding, or recursors only, approach [Sat Mar 5 03:59:25 2016] which, btw, Lean is apparently trying, so I wonder how they'll resolve this [Sat Mar 5 04:06:46 2016] johnw, what do you mean exactly? [Sat Mar 5 04:19:42 2016] johnw: lean is trying what? using only pi types? [Sat Mar 5 04:21:04 2016] Lean implements its sigma in the standard lib using a single case inductive data type: structure sigma {A : Type} (B : A → Type) := mk :: (pr1 : A) (pr2 : B pr1) [Sat Mar 5 04:21:11 2016] if I'm not mistaken [Sat Mar 5 04:22:29 2016] rrika: my impression is that inductive type is a kind of superset to sigma type, so the fact that it can be encoded is not surprising. [Sat Mar 5 06:04:10 2016] hello, how can I prove this one? https://bpaste.net/show/089664465d6f [Sat Mar 5 06:09:51 2016] riaqn, if you use inversion instead of induction you get many more facts [Sat Mar 5 06:11:00 2016] rrika: but I feel needing to induction over H. [Sat Mar 5 06:26:49 2016] riaqn, if you figure it out tell me. [Sat Mar 5 06:26:56 2016] I've been trying to solve it until now. [Sat Mar 5 06:27:36 2016] one thing I noticed is that nothing prevents you from having values of both (multi X t_true) and (multi X t_false). [Sat Mar 5 06:27:46 2016] at least you can not easily derive False from two such values. [Sat Mar 5 06:28:16 2016] the definition of small and multi should be enough to show that it can only be either one or the other. [Sat Mar 5 06:35:57 2016] rrika let me know if you solve it,i [Sat Mar 5 06:36:05 2016] I have given up [Sat Mar 5 06:36:24 2016] where is this task from? [Sat Mar 5 06:37:32 2016] from tapl chapter 3, but not an exercise [Sat Mar 5 06:41:26 2016] rrika page 34, it's called small step operational semantics [Sat Mar 5 06:41:35 2016] I only read a part of SF [Sat Mar 5 06:49:37 2016] riaqn, is it intentional that small t_true t_true -> False? [Sat Mar 5 06:49:57 2016] 'small' has nothing indicating that literals evaluate to themselves [Sat Mar 5 06:57:16 2016] rrika where do you derive that t_true t_true -> False? [Sat Mar 5 06:57:30 2016] inversion [Sat Mar 5 06:58:07 2016] Theorem small_true_true : [Sat Mar 5 06:58:07 2016] small t_true t_true -> False. [Sat Mar 5 06:58:07 2016] Proof. [Sat Mar 5 06:58:07 2016] intros. [Sat Mar 5 06:58:07 2016] inversion H. [Sat Mar 5 06:58:08 2016] Qed. [Sat Mar 5 06:58:42 2016] yes, it's international [Sat Mar 5 06:58:54 2016] oh I mean intentional [Sat Mar 5 06:59:14 2016] So small makes sure its first argument is never true or false but always cond [Sat Mar 5 06:59:21 2016] And multi has two cases [Sat Mar 5 06:59:37 2016] the tautology X → X [Sat Mar 5 07:00:07 2016] and a multi transformation followed by a small transformation [Sat Mar 5 07:00:24 2016] which means that multi can only have X → X or (endless tree of conds with no leaves) → X [Sat Mar 5 07:00:45 2016] → not in the function signature sense, bad choice of symbol of me [Sat Mar 5 07:01:22 2016] Maybe there is an error in my reasoning. [Sat Mar 5 07:52:50 2016] riaqn, nevermind I was wrong [Sat Mar 5 07:52:53 2016] also I solved it [Sat Mar 5 08:18:36 2016] riaqn, https://bpaste.net/show/c38e0e25a139 [Sat Mar 5 08:36:34 2016] rrika huh, not as easy as it seems [Sat Mar 5 08:38:49 2016] my style is a bit roundabout. [Sat Mar 5 19:25:50 2016] so for the last week or so i've been getting this error while trying to compile coq trunk: [Sat Mar 5 19:25:54 2016] File "./theories/Init/Logic.v", line 541, characters 24-25: [Sat Mar 5 19:25:55 2016] Syntax error: [tactic:binder_tactic] or [tactic:tactic_expr] or [tactic_then_locality] expected after ";" (in [tactic:tactic_expr]). [Sat Mar 5 19:26:18 2016] since there's been like a dozen commits after it first started i'm wondering if it's on my end. [Sat Mar 5 19:50:27 2016] spacekitteh can you paste the context? [Sat Mar 5 19:50:50 2016] COQC -noinit theories/Init/Notations.v [Sat Mar 5 19:50:51 2016] COQC -noinit theories/Init/Logic.v [Sat Mar 5 19:50:51 2016] File "./theories/Init/Logic.v", line 541, characters 24-25: [Sat Mar 5 19:50:51 2016] Syntax error: [tactic:binder_tactic] or [tactic:tactic_expr] or [tactic_then_locality] expected after ";" (in [tactic:tactic_expr]). [Sat Mar 5 19:50:53 2016] Makefile.build:591: recipe for target 'theories/Init/Logic.vo' failed [Sat Mar 5 19:50:56 2016] make[1]: *** [theories/Init/Logic.vo] Error 1 [Sat Mar 5 19:51:42 2016] spacekitteh and the context? [Sat Mar 5 19:51:48 2016] what do you mean [Sat Mar 5 19:51:48 2016] please use lpaste [Sat Mar 5 19:51:51 2016] the code [Sat Mar 5 19:53:28 2016] https://github.com/coq/coq/blob/trunk/theories/Init/Logic.v#L541 [Sat Mar 5 19:56:46 2016] Looks like I can compile trunk just fine on my end :x [Sat Mar 5 19:57:00 2016] (not helping much though) [Sat Mar 5 19:57:11 2016] no that does help cypi [Sat Mar 5 19:57:24 2016] what's the result of your .configure? [Sat Mar 5 19:58:07 2016] (i ran ./configure -debug -local) [Sat Mar 5 19:59:24 2016] http://lpaste.net/154084 [Sat Mar 5 20:00:02 2016] Maybe a difference in the Camlp4/5 version used? (I have no idea how these work though) [Sat Mar 5 20:00:46 2016] hmm, i'm using camlp4. i'll try with p5 [Sat Mar 5 20:03:41 2016] ok it looks like it was camlp4 that was the problem. [Sat Mar 5 21:02:57 2016] sup nerds [Sat Mar 5 21:54:05 2016] riaqn: it's often convenient to use a different encoding of the transitive closure than the one your using. I think it will make this particular proof easier as well. [Sat Mar 5 21:59:35 2016] if you just change the type of m_S to be [small t1 t2 -> multi t2 t3 -> multi t1 t3] then the proof goes through with two inversions. [Sat Mar 5 21:59:56 2016] you can prove that the two definitions are equivalent, since sometimes one is more convenient than the other [Sun Mar 6 12:55:25 2016] hi! I need some help with the installation coq, ProofGeneral, emacs on NixOS, anyone could help? [Sun Mar 6 14:17:55 2016] rrika: someone had told me that Lean uses recursors, and not inductive data types, in its meta-theory [Sun Mar 6 14:22:43 2016] johnw, I'm very weak on the theory behind all this [Sun Mar 6 14:23:04 2016] what is meant by recursors anyway? [Sun Mar 6 14:23:21 2016] it would mean that a user-facing construction like "inductive list a := nil | cons a (list a)" [Sun Mar 6 14:23:36 2016] would construct terms of the form ∀ r. r -> (a -> r -> r) -> r [Sun Mar 6 14:23:49 2016] and that elimination would consist of calling this somehow [Sun Mar 6 14:24:01 2016] I *think* [Sun Mar 6 14:24:12 2016] well, coq offers both match and a function for that, doesn't it? [Sun Mar 6 14:24:22 2016] and lean gives you a recursor but also a match [Sun Mar 6 14:24:24 2016] yes, but the core meta-theory actually has inductive constructions [Sun Mar 6 14:24:36 2016] it doesn't try to reduce an inductive type further down to plain functions [Sun Mar 6 14:24:52 2016] I don't know if it's defined by its recursor, or just has a recursor [Sun Mar 6 14:24:54 2016] 2meta4me [Sun Mar 6 14:24:59 2016] haha [Sun Mar 6 14:25:07 2016] Does it make a difference for the definition of sigma though? [Sun Mar 6 14:25:21 2016] Whether it's based on a "true" inductive data type or a recursor [Sun Mar 6 14:25:58 2016] not a whole lot; I was just mentioning that we don't need anything but pi to encode it [Sun Mar 6 14:27:48 2016] because a recursor is a pi type? [Sun Mar 6 14:27:57 2016] *is of a [Sun Mar 6 14:28:01 2016] yes [Sun Mar 6 16:03:33 2016] good morning fellow workers [Sun Mar 6 16:17:56 2016] hello, kitten of the vast outer reaches [Sun Mar 6 16:20:01 2016] helo [Sun Mar 6 16:33:04 2016] so like [Sun Mar 6 16:33:06 2016] this is my first ever job [Sun Mar 6 16:33:11 2016] haven't even got a degree [Sun Mar 6 16:33:19 2016] mum said "don't get involved in office politics" [Sun Mar 6 16:33:25 2016] three months later i'm the union delegate [Sun Mar 6 16:33:25 2016] hah [Sun Mar 6 16:34:48 2016] what kind of job? [Sun Mar 6 16:37:31 2016] proof engineering [Sun Mar 6 16:39:19 2016] nice [Sun Mar 6 16:39:28 2016] indeed :) [Sun Mar 6 16:39:31 2016] close to home, or did you have to move? [Sun Mar 6 16:41:00 2016] had to move [Sun Mar 6 16:42:55 2016] i was on welfare prior to it [Sun Mar 6 16:43:02 2016] what with increased rent here and so on [Sun Mar 6 16:43:11 2016] how did you land the job? [Sun Mar 6 16:43:12 2016] i only make a profit of about $150/fortnight, lol [Sun Mar 6 16:43:28 2016] johnw: applied for it! [Sun Mar 6 16:43:41 2016] there was an open listing for it [Sun Mar 6 16:44:21 2016] spacekit1eh, what technologies do you get to work with? [Sun Mar 6 16:44:37 2016] (coq y/n?, others?) [Sun Mar 6 16:45:02 2016] isabelle :( [Sun Mar 6 16:45:05 2016] + haskell [Sun Mar 6 16:45:15 2016] but i'm working on coq stuff on my spare time [Sun Mar 6 16:45:18 2016] which is a LOT [Sun Mar 6 16:49:18 2016] spacekit1eh: good job finding that; proof engineering jobs are kind of rare [Sun Mar 6 16:49:30 2016] and so, hard to build up working experience in [Sun Mar 6 16:51:19 2016] yeah lol [Sun Mar 6 16:52:29 2016] I also moved for my first ever job without a degree. Trying to learn coq and other proving stuff on the side. [Sun Mar 6 21:15:30 2016] what has been written on the topic of equipping systems like the CoC with "native" types and functions [Sun Mar 6 21:15:57 2016] i.e. like how Int, (+), etc are in Haskell [Mon Mar 7 10:23:32 2016] benzrf: I don't think you ever need that to be in the meta-theory [Mon Mar 7 10:24:08 2016] benzrf: for Coq, "Int" is just an ordinary inductive data type, while constants like "12" reduce down to a series of constructor calls. But none of this occurs at the CiC layer. [Mon Mar 7 11:49:15 2016] johnw: I have some vague recollection of you mentioning that you maintain most of the coq nix packages [Mon Mar 7 11:50:44 2016] ah nevermind, i figured out the issue [Mon Mar 7 11:51:26 2016] nix seems pretty nice [Mon Mar 7 11:57:52 2016] is there a nice way to simplify the goal if it's a match? [Mon Mar 7 11:58:27 2016] in particular, is it possible to reduce match expressions with only one arm to their arm in a goal [Mon Mar 7 11:58:42 2016] or does that break dependant typing? [Mon Mar 7 11:59:11 2016] You will need to destruct on the variable being matched on in any case [Mon Mar 7 11:59:43 2016] Even with only one branch. In some cases it might not even be provable that you can just reduce it to its branch (as you said, dependent typing makes everything more complicated) [Mon Mar 7 11:59:45 2016] I'm trying to do: https://gist.github.com/aa17a372450bf1beb58e [Mon Mar 7 12:00:04 2016] I can't destruct on the variable, it lead to "ill typed term" [Mon Mar 7 12:01:58 2016] https://github.com/tbelaire/FJ-Formalization/blob/wip/FJ_Definitions.v#L586 [Mon Mar 7 12:04:03 2016] what was your destruct command? [Mon Mar 7 12:04:29 2016] destruct H_ok. [Mon Mar 7 12:04:46 2016] try "dependent destruction H_ok" [Mon Mar 7 12:04:51 2016] okay [Mon Mar 7 12:05:07 2016] there are non-axiomy ways around using that, but they are somewhat involved [Mon Mar 7 12:05:44 2016] Syntax error: 'generalize_eqs_vars' or 'generalize_eqs' or 'rewrite' or 'simple' 'inversion' expected after 'dependent' [Mon Mar 7 12:06:42 2016] you'll have to import something [Mon Mar 7 12:06:43 2016] Coq 8.4pl6, and I can't upgrade because they broke the vim plugin [Mon Mar 7 12:06:47 2016] ah, okay [Mon Mar 7 12:07:04 2016] Require Import Coq.Logic.JMeq. [Mon Mar 7 12:07:05 2016] [Mon Mar 7 12:07:29 2016] (Note that this would most probably introduce an axiom) [Mon Mar 7 12:07:36 2016] I'm okay with that [Mon Mar 7 12:08:15 2016] fixed [Mon Mar 7 12:08:21 2016] but it was Require Import Program. [Mon Mar 7 12:08:32 2016] but thanks, that's some progress [Mon Mar 7 12:09:35 2016] uh, how do you deal with 'match ! in ...' [Mon Mar 7 12:09:45 2016] or match False_Ind [Mon Mar 7 12:10:16 2016] I don't see "match !" anywhere in your paste [Mon Mar 7 12:11:14 2016] You don't have to tbelaire, your context should be inconsistent there [Mon Mar 7 12:11:30 2016] (I thought "dependent destruction" would actually see that) [Mon Mar 7 12:11:47 2016] oh, that was after the dependent destruction [Mon Mar 7 12:12:14 2016] note that I'm not actually doing this in Coq over here, so I don't see what you see after executing the tactic [Mon Mar 7 12:12:35 2016] ah, I did have an inconsistent context [Mon Mar 7 12:12:52 2016] thanks [Mon Mar 7 12:13:12 2016] The second branch of the induction looks funnier, have fun :o [Mon Mar 7 12:15:48 2016] It's done. Destruct (A == Object), then apply IHCT. [Mon Mar 7 12:15:53 2016] Ah, cool :) [Mon Mar 7 12:16:09 2016] I was very afraid that it wouldn't work [Mon Mar 7 12:16:25 2016] but that whole lemma is a base case [Mon Mar 7 12:16:31 2016] next is the inductive case [Mon Mar 7 12:16:58 2016] if you Print Assumptions on that proof now [Mon Mar 7 12:17:03 2016] you'll see that it depends on JMeq [Mon Mar 7 12:17:24 2016] yeah, I know about that. This post was informative https://homes.cs.washington.edu/~jrw12/dep-destruct.html [Mon Mar 7 12:17:26 2016] read https://homes.cs.washington.edu/~jrw12/dep-destruct.html to learn how to avoid that necessity, if such freedom is important [Mon Mar 7 12:17:30 2016] haha [Mon Mar 7 12:17:37 2016] yes [Mon Mar 7 12:17:42 2016] that page exactly [Mon Mar 7 12:17:55 2016] took me a day to read though [Mon Mar 7 12:18:01 2016] CPDT also discusses this in depth [Mon Mar 7 12:18:02 2016] I really like how the page is interactive [Mon Mar 7 12:18:44 2016] Maybe I should steal that tech, so my gists are easier to read [Mon Mar 7 12:19:07 2016] if you ever make it easy to paste interactive Coq pastes, please share :) [Mon Mar 7 12:19:18 2016] maybe next weekend :) [Mon Mar 7 12:20:00 2016] doesn't sound crazy hard if he already did all the hard work [Mon Mar 7 12:20:02 2016] i do intend to incorporate such technology into my Hakyll system [Mon Mar 7 12:20:09 2016] since I hadn't started blogging about Coq yet [Mon Mar 7 13:51:00 2016] Ahrg, that's going to be harder than I thought. [Mon Mar 7 13:51:13 2016] Is there documentation on the new Toplevel stuff anywhere? [Mon Mar 7 14:02:29 2016] Also, is there any way to find out why "fold" isn't firing? [Mon Mar 7 14:02:51 2016] I'm trying to unfold then refold a definition to expose only a little bit of work [Mon Mar 7 14:03:01 2016] but it's stuck as a 3000 line goal statement [Mon Mar 7 14:03:43 2016] Do I just have to write "abstract " in the intial proof more? [Mon Mar 7 14:08:04 2016] if it unfolded to an anonymous "fix", you can't re-fold [Mon Mar 7 14:08:10 2016] at least, I haven't figured out how to do that yet [Mon Mar 7 14:16:25 2016] It does not, it's unfolding to a list_rec [Mon Mar 7 14:16:40 2016] but one with a very large inductive case [Mon Mar 7 14:17:02 2016] hmm, mabye I can name that inductive case when writing the definition [Mon Mar 7 14:17:07 2016] as a lemma first [Mon Mar 7 14:17:09 2016] ... [Mon Mar 7 14:23:14 2016] johnw@14:52, 3/4: pong (I was away square dancing all weekend) [Mon Mar 7 15:16:35 2016] How do you debug Hint Extern rules not firing? [Mon Mar 7 15:20:42 2016] oh hey, it seems to work for eauto.... [Mon Mar 7 15:21:46 2016] jgross: have fun? [Mon Mar 7 15:24:13 2016] If I have 'Hint Extern 1 => ', auto fails to work, but if I leave off , it does [Mon Mar 7 15:24:26 2016] so I think that means my pattern is wrong, right? [Mon Mar 7 15:24:34 2016] but it's just [Mon Mar 7 15:24:36 2016] Cask 'coqide' definition is invalid: Bad header line: parse failed [Mon Mar 7 15:24:38 2016] no [Mon Mar 7 15:24:40 2016] Hint Extern 1 (extends_ _ _ _) => unfold_extends. [Mon Mar 7 15:24:51 2016] do you need ?s or something? [Mon Mar 7 15:25:45 2016] do you mean to have a space between extends and the first underscore? [Mon Mar 7 15:30:04 2016] no, I have two versions of that function, it's intentional [Mon Mar 7 15:30:08 2016] if you have a , the head must match [Mon Mar 7 15:30:13 2016] maybe it's not matching due to an existential? [Mon Mar 7 15:30:23 2016] what does that mean? [Mon Mar 7 15:30:31 2016] not sure without looking at your context and goal [Mon Mar 7 15:30:35 2016] Sure [Mon Mar 7 15:31:08 2016] H : extends_ nil C D [Mon Mar 7 15:31:10 2016] ======================== ( 1 / 1 ) [Mon Mar 7 15:31:12 2016] False [Mon Mar 7 15:31:34 2016] so, False != extends _ _ [Mon Mar 7 15:31:46 2016] or does the Hint Extern pattern match anything in the context too? [Mon Mar 7 15:32:00 2016] oh, I want it to match agaist the context in a hypothesis [Mon Mar 7 15:32:08 2016] you can do that with [Mon Mar 7 15:32:22 2016] Hint Extern => match goal with [ H : extends _ _ |- _ ] => . [Mon Mar 7 15:32:29 2016] just move the match into the hint [Mon Mar 7 15:32:39 2016] okay, I do have that too [Mon Mar 7 15:32:54 2016] I didn't realize the pattern for Hint Extern was only the goal [Mon Mar 7 15:33:03 2016] that solves it, thansk [Mon Mar 7 17:10:35 2016] Is there a way to duplicate a Hypothesis? [Mon Mar 7 17:11:10 2016] Ah, don't need it anymore [Mon Mar 7 18:11:32 2016] pose proof H. [Mon Mar 7 21:31:22 2016] johnw: I did! [Tue Mar 8 12:46:46 2016] lingxiao, you've surely done the subseq task from SF. [Tue Mar 8 12:46:52 2016] I'm stuck [Tue Mar 8 12:47:05 2016] hey yup which on are you talking about? [Tue Mar 8 12:47:11 2016] i dno aobut surely... but I'll try! [Tue Mar 8 12:47:20 2016] oh, wait, I don't need to ask you, you put everything on github anyway [Tue Mar 8 12:47:27 2016] in Prop.v [Tue Mar 8 12:47:57 2016] haha yeah here: https://github.com/lingxiao/CIS500 [Tue Mar 8 12:48:05 2016] but i stopped doing the advanced problem lately though [Tue Mar 8 12:48:23 2016] I think it's called IndProp.v for me [Tue Mar 8 12:48:25 2016] in hw5 [Tue Mar 8 12:49:00 2016] let me know if you have questions ! [Tue Mar 8 12:49:11 2016] I found it. Intesting, I didn't make proofs for head1 = head2 and head1 <> head2 arguments for the constructor. [Tue Mar 8 12:49:54 2016] im sorry which problem are you talking about? [Tue Mar 8 12:50:35 2016] https://github.com/lingxiao/CIS500/blob/master/hw5/IndProp.v#L1613 [Tue Mar 8 12:52:16 2016] oh how did you specify the inductive casese then? [Tue Mar 8 12:54:02 2016] https://gist.github.com/rrika/367bbbb95a3bed91101a [Tue Mar 8 12:55:19 2016] ahh that looks like it could work too! [Tue Mar 8 12:55:44 2016] induction on that type gives me stuff I can't proove [Tue Mar 8 12:55:49 2016] *prove [Tue Mar 8 12:55:59 2016] and i thnk in my x_eq _y case i couldve writen: forall l1 l2 x, subseq l1 l2 -> subseq (x::l1) (x::l2) [Tue Mar 8 12:56:28 2016] ohh you know what i think in your ct case you do need to decompose the p in subseq p (x::q) [Tue Mar 8 12:56:51 2016] otherwise you have the second list that is destructing as you step through the proof, and the first case that's not destructing [Tue Mar 8 12:57:15 2016] so [ ct :: forall x y p q, subseq p q -> x <> y -> subseq (y::p) (x::q) [Tue Mar 8 12:57:27 2016] the [x <> y] is needed in your proof [Tue Mar 8 12:57:33 2016] as an assumption in your proof * [Tue Mar 8 12:57:56 2016] well, your approach makes the matching unambiguous [Tue Mar 8 12:58:00 2016] first list that is not destructing * [Tue Mar 8 12:58:10 2016] that is there is only one way to show that [1 2 3] in [1 2 2 3] [Tue Mar 8 12:59:19 2016] hey sorry not clear on the question are you saying that adding x <> y makes the matching unambious [Tue Mar 8 12:59:19 2016] ? [Tue Mar 8 12:59:25 2016] yes [Tue Mar 8 12:59:38 2016] you can not skip the '2' [Tue Mar 8 12:59:44 2016] because you can't provide a proof that 2<>2 [Tue Mar 8 13:01:22 2016] yeah i think w/o specifiying x <> y it's actually possible that x = y [Tue Mar 8 13:08:28 2016] morning [Tue Mar 8 13:08:47 2016] lingxiao working on subseq? :) [Tue Mar 8 13:09:13 2016] hey yup i worked on it a bit ago, but i think i remmeber enough to answer questisons :) [Tue Mar 8 13:10:43 2016] I'll do it my way [Tue Mar 8 13:10:44 2016] without <> [Tue Mar 8 13:10:47 2016] it must work [Tue Mar 8 13:10:54 2016] which proof rrika_mobile ? [Tue Mar 8 13:11:15 2016] forall (a b: list nat) (x: nat), subseq (x::a) b -> subseq a b. [Tue Mar 8 13:11:29 2016] some helper theorem I want to prove [Tue Mar 8 13:12:13 2016] gotta go offline. I have 5% battery and way too many tabs open that I still need. [Tue Mar 8 13:12:17 2016] :P [Tue Mar 8 13:13:26 2016] rrika oke i got the same helper theorem [Tue Mar 8 13:13:36 2016] :) [Tue Mar 8 13:14:28 2016] hm im not using it though :P [Tue Mar 8 13:14:36 2016] well its not so hard to proof [Tue Mar 8 15:29:28 2016] > [19:10:36] well its not so hard to proof [Tue Mar 8 15:29:37 2016] ;_; [Tue Mar 8 15:30:15 2016] how do I use the decidable equality of nat? [Tue Mar 8 15:34:43 2016] kinda annoying though that I have to resort to that. [Tue Mar 8 15:38:01 2016] sup nerds [Tue Mar 8 15:38:42 2016] failing at SF [Tue Mar 8 15:39:25 2016] oh no [Tue Mar 8 15:39:41 2016] how do I show that (S b = b) can't be true. [Tue Mar 8 15:41:00 2016] uniqueness theorems for inductor constructors [Tue Mar 8 15:41:39 2016] yeah, how does that work in coq [Tue Mar 8 15:41:53 2016] dunno :V [Tue Mar 8 15:42:15 2016] "constructor" is a tactic apparently [Tue Mar 8 15:42:39 2016] not the one I need apparently. [Tue Mar 8 15:42:41 2016] constr_eq [Tue Mar 8 15:54:48 2016] rrika: I suppose using n_Sn from the prelude would be cheating [Tue Mar 8 15:55:13 2016] stelleg, i'm currently trying to do it myself, but knowing where do find it in the prelude is just as important. [Tue Mar 8 15:55:24 2016] oh [Tue Mar 8 15:55:31 2016] I figured it out btw [Tue Mar 8 15:55:38 2016] discriminate and congruence didn't work [Tue Mar 8 15:55:46 2016] because 'b' obviously has no indication what case it is [Tue Mar 8 15:55:55 2016] but if I do induction, it works. [Tue Mar 8 15:57:40 2016] btw, is there a tacic for turning reducing "A → B" to "B" in the context? [Tue Mar 8 15:58:08 2016] s/i.*ng/ing/ [Tue Mar 8 15:58:51 2016] "apply in" or specialize, if you have an A [Tue Mar 8 15:59:34 2016] specialize is exactly what I was looking for, thanks. [Tue Mar 8 16:00:39 2016] johnw, do you know something like inversion which clears the original item? [Tue Mar 8 16:00:54 2016] destruct is similar [Tue Mar 8 16:01:04 2016] there's always "clear" [Tue Mar 8 16:01:12 2016] yeah, but my code is cluttered with manual clears [Tue Mar 8 16:01:17 2016] I have S a = S b [Tue Mar 8 16:01:21 2016] inversion gives me an additional a = b [Tue Mar 8 16:01:25 2016] I just want to replace the original H. [Tue Mar 8 16:01:40 2016] destruct just clears without giving me a = b [Tue Mar 8 16:02:52 2016] >inversion_clear [Tue Mar 8 16:02:55 2016] well that was easy [Tue Mar 8 16:03:11 2016] where are two big savings in proof size to me [Tue Mar 8 16:03:12 2016] :) [Tue Mar 8 16:04:16 2016] a lot of us use: Ltac inv H := inversion H; clear H; subst. [Tue Mar 8 16:04:24 2016] I see that often [Tue Mar 8 16:04:42 2016] inversion_clear doesn't do what I want after all. [Tue Mar 8 16:04:45 2016] ah, never got to Ltac. [Tue Mar 8 16:04:49 2016] I will use this [Tue Mar 8 16:05:17 2016] what does plain subst do? [Tue Mar 8 16:07:34 2016] "apply all equalities that you can" [Tue Mar 8 16:17:38 2016] in which direction? [Tue Mar 8 16:17:47 2016] Also, order matters. [Tue Mar 8 16:17:56 2016] (I think) [Tue Mar 8 16:40:00 2016] just why did I name my variables p b and q. [Tue Mar 8 16:40:05 2016] too confusable [Tue Mar 8 16:48:21 2016] .ц 30 [Tue Mar 8 16:48:25 2016] oops, sorry [Tue Mar 8 18:44:21 2016] hi rrika [Tue Mar 8 18:44:25 2016] proofed it? [Tue Mar 8 19:02:03 2016] have a good night [Tue Mar 8 20:37:17 2016] Nik05, still on it [Tue Mar 8 20:37:26 2016] discovery of today: [Tue Mar 8 20:37:35 2016] refine (fix go … := _). [Tue Mar 8 20:38:03 2016] Disadvantage: I have to read Qed. before the system will tell me that my arguments aren't decreasing. [Tue Mar 8 20:38:07 2016] But it makes things so much easier [Tue Mar 8 20:38:38 2016] rrika: You might be interested in the [Guarded] vernacular. Also the [fix] tactic. [Tue Mar 8 20:40:52 2016] interesting [Tue Mar 8 20:41:37 2016] very nice [Tue Mar 8 20:41:44 2016] is it possible to have a function type like [Tue Mar 8 20:41:58 2016] A → (A → (A → …)) → B [Tue Mar 8 20:42:12 2016] that I call like f f g [Tue Mar 8 20:42:16 2016] probably not [Tue Mar 8 20:42:44 2016] was trying to create the type in tactic mode using [Tue Mar 8 20:42:48 2016] assert Type. [Tue Mar 8 20:42:52 2016] refine (A → _ → B). [Tue Mar 8 20:42:54 2016] apply X. [Tue Mar 8 20:43:05 2016] but it won't let me put a placeholder there. [Tue Mar 8 20:53:10 2016] rrika: what do your ellipses mean? [Tue Mar 8 20:56:02 2016] it's self referential [Tue Mar 8 20:56:17 2016] oh, it's lacking [Tue Mar 8 20:56:29 2016] A → (A → (A → … → B) →B) → B [Tue Mar 8 20:57:45 2016] rrika: I see. no I don't think that's possible. that looks like a full-on recursive type, which in general introduces non-termination. [Tue Mar 8 20:58:01 2016] makes sense [Tue Mar 8 20:58:13 2016] you can define a finite version of that by introducing a "depth" argument [Tue Mar 8 20:58:24 2016] and then abstracting over it if you want to work on arbitrary depth [Tue Mar 8 21:00:40 2016] I was just trying weird approaches. My recursion depth would've been one. [Tue Mar 8 21:01:14 2016] the tactic fix gives me a "Not enough abstractions in the definition." [Tue Mar 8 21:01:41 2016] I don't know, but it's already very abstract for me. [Tue Mar 8 22:05:17 2016] lol [Wed Mar 9 02:09:21 2016] evening [Wed Mar 9 06:29:53 2016] rrika just use induction? [Wed Mar 9 08:05:52 2016] do I need to know math to be able to use coq? [Wed Mar 9 08:06:53 2016] yes [Wed Mar 9 08:07:04 2016] how much math? [Wed Mar 9 08:07:21 2016] proof by induction [Wed Mar 9 08:07:34 2016] isn't that really simple? [Wed Mar 9 08:07:55 2016] yeah [Wed Mar 9 08:46:33 2016] is there a proof for Ukkonen's algorithm in Coq? [Wed Mar 9 15:31:18 2016] Slice^ where do you want to use Coq for? [Wed Mar 9 15:31:42 2016] systems and application programming [Wed Mar 9 15:32:00 2016] say, driver, web server or browser [Wed Mar 9 15:32:02 2016] Slice^: very nice [Wed Mar 9 15:32:08 2016] Slice^: that's more of what I'm using it for [Wed Mar 9 15:32:16 2016] Slice^ and you can program? [Wed Mar 9 15:32:30 2016] well, I've written a few [Wed Mar 9 15:32:37 2016] nothing big [Wed Mar 9 15:33:40 2016] mostly uni coursework [Wed Mar 9 15:34:04 2016] Don't you get math courses at uni? [Wed Mar 9 15:34:23 2016] we had like 2 theory courses [Wed Mar 9 15:34:33 2016] just basic propositional and predicate logic [Wed Mar 9 15:34:46 2016] intro computability and complexity theory [Wed Mar 9 15:47:16 2016] hello johnw :) [Wed Mar 9 15:48:51 2016] hi [Wed Mar 9 22:30:07 2016] How do I prove something by contrdiction? More specifically, how would I change the goal from A to ~A -> False (if possible)? [Wed Mar 9 22:32:44 2016] lambda-11235: Do you have the law of excluded middle or some other classical axiom? [Wed Mar 9 22:33:35 2016] lambda-11235: Doing that is not intuitionistically valid. If A is already negated though, you just unfold not. [Wed Mar 9 22:34:38 2016] ~A is defined as A -> False [Wed Mar 9 22:35:34 2016] Cale: No to the law question, and I'm trying to prove (~A -> B) -> (B -> A) -> A, so I can't unfold. [Wed Mar 9 22:37:21 2016] You can unfold not in the hypothesis, but it just means you have a function (A -> False) -> B [Wed Mar 9 22:38:16 2016] Cale: Don't see how that would help. [Wed Mar 9 22:38:23 2016] right, it doesn't [Wed Mar 9 22:39:42 2016] That statement doesn't seem provable. [Wed Mar 9 22:40:48 2016] Cale: I may have to include A = ~~A as an axiom then. [Wed Mar 9 22:40:54 2016] yeah [Wed Mar 9 22:41:03 2016] Is it already in the standard library? [Wed Mar 9 22:42:54 2016] http://lpaste.net/154396 [Wed Mar 9 22:44:04 2016] Coq.Logic.Classical seems to export relevant stuff [Wed Mar 9 22:44:18 2016] Specifically in Coq.Logic.Classical_Prop [Wed Mar 9 22:44:25 2016] Axiom classic : forall P:Prop, P \/ ~ P. [Wed Mar 9 22:44:25 2016] Lemma NNPP : forall p:Prop, ~ ~ p -> p. [Wed Mar 9 22:46:15 2016] * sheds a tear for Lemma proof_irrelevance : forall (P:Prop) (p1 p2:P), p1 = p2. [Wed Mar 9 22:46:32 2016] So much destruction of beautiful structure [Wed Mar 9 22:53:42 2016] Cale: Thanks, I think the classic axiom is what I was looking for. [Wed Mar 9 22:57:08 2016] Why is proof_irrelevance bad? [Wed Mar 9 22:59:58 2016] lambda-11235: It completely obliterates the interpretation of identity types as path spaces, i.e. homotopy type theory's interpretation of what's going on in the type system [Wed Mar 9 23:01:52 2016] lambda-11235: You can think of types A as being spaces (up to homotopy), and their term inhabitants x y : A as being points in those spaces, and then proofs of equality p: x = y as being paths from x to y [Wed Mar 9 23:01:56 2016] in the space [Wed Mar 9 23:02:20 2016] and proof_irrelevance identifies all those paths [Wed Mar 9 23:02:48 2016] So you can't have something like a circle any more, it collapses [Wed Mar 9 23:05:04 2016] (the loop which goes around the circle once from a point to itself is identified with the path which stays at that point and doesn't go anywhere) [Wed Mar 9 23:14:39 2016] what do you get out of seeing types as spaces? [Wed Mar 9 23:35:03 2016] sunnymilk: Confused. :) [Wed Mar 9 23:36:49 2016] Disclaimer: I don't actually know anything about HoTT, or much of type theory for that matter. [Wed Mar 9 23:56:38 2016] lol [Thu Mar 10 00:34:13 2016] So all propositions in Coq are singly inhabited? That is (A : Prop) only contains a single value? [Thu Mar 10 00:34:27 2016] Cale: Is that the problem? [Thu Mar 10 03:35:42 2016] sunnymilk: You get a whole other way of using type theory -- you can use it to study homotopy theory directly. Apart from that, homotopy theory can inform our understanding of type theory, by making it clearer what things are possible or not through that model, and suggesting interesting directions in which to take the language (for example, higher inductive types are like inductive types, but they allow additional new sor [Thu Mar 10 03:35:42 2016] ts of constructors for equalities (paths) between constructed terms, and then paths between paths and so on). It becomes very natural to handle groups and groupoids. [Thu Mar 10 06:22:34 2016] Cale wait what is proof_irrelevance? [Thu Mar 10 06:23:26 2016] oh i should scroll further :) [Thu Mar 10 06:28:10 2016] oh i read it wrong [Thu Mar 10 06:28:24 2016] so p1 and p2 are proofs of P, and they are the same? :S [Thu Mar 10 06:29:05 2016] oh no not proof [Thu Mar 10 06:29:08 2016] s [Thu Mar 10 06:46:33 2016] Yes, proofs [Thu Mar 10 06:46:57 2016] It basically amounts to saying that a proof of P has no other content than the fact that it is a proof of P [Thu Mar 10 07:24:16 2016] Nik05: 1) it doesn't matter how you proved some proposition 2) considering the relevant/irrelevant proofs, it may mean that it have/haven't to be represented in runtime [Thu Mar 10 17:07:08 2016] why is a → {b | P b}, Set and not Prop? [Thu Mar 10 17:10:16 2016] It depends on a and b. If they are both in Prop, then it will be Prop [Thu Mar 10 17:10:34 2016] (actually, if b is in Prop, then it's in Prop) [Thu Mar 10 17:11:05 2016] b is bool [Thu Mar 10 17:12:07 2016] Then it's natural that a function that returns something in Set is at least in Set [Thu Mar 10 17:12:09 2016] a -> exists b, P b is all in Prop [Thu Mar 10 17:12:27 2016] but your original function type returns a "b" in Set [Thu Mar 10 17:12:45 2016] hm, I could make pbool, which is in Prop. [Fri Mar 11 05:15:55 2016] how do I tell Coq to perform beta reduction on the goal? [Fri Mar 11 05:16:25 2016] If you literally only want beta, "cbv beta" [Fri Mar 11 05:16:34 2016] If you actually want to normalize your term, "compute" [Fri Mar 11 05:17:16 2016] "simpl" is a milder middle-ground [Fri Mar 11 05:17:30 2016] right [Fri Mar 11 05:17:33 2016] well [Fri Mar 11 05:17:38 2016] I have such goal: [Fri Mar 11 05:17:49 2016] S m = S (m + 0) [Fri Mar 11 05:17:57 2016] and inductove hypothesis: [Fri Mar 11 05:18:03 2016] 0 + m = m + 0 [Fri Mar 11 05:18:22 2016] I'd like to simplify IH and then tell Coq to ise it under S constructor [Fri Mar 11 05:18:55 2016] "simpl in H" will simplify the left-hand side of IH [Fri Mar 11 05:19:30 2016] and you can use the tactic "f_equal" to express what you said next [Fri Mar 11 05:19:43 2016] (or just rewrite with the hypothesis H) [Fri Mar 11 05:19:52 2016] Sorry, "simpl in IH"* [Fri Mar 11 05:21:10 2016] ah, f_equal. Thanks [Fri Mar 11 05:21:12 2016] that works [Fri Mar 11 05:30:50 2016] If I have a goal a = b and I have a lemma that proves b = a, how do I tekl Coq to use that lemma? [Fri Mar 11 05:31:18 2016] You can rewrite with your hypothesis, or you can use "symmetry" to swap the terms in your goal [Fri Mar 11 05:34:58 2016] oh, I wasn't aware that rewrite is aware of symmetry. [Fri Mar 11 05:35:27 2016] It's not really aware of symmetry, it's just that it will find a 'b' in the goal, and replace it with 'a' [Fri Mar 11 05:35:37 2016] So the goal would become "a = a", which is trivial [Fri Mar 11 05:37:45 2016] what if I want it the other way around [Fri Mar 11 05:37:56 2016] what if I want my goal to be rewritten to b = b ? [Fri Mar 11 05:38:02 2016] "rewrite <- lemma" [Fri Mar 11 05:38:39 2016] ah, that's what <- means [Fri Mar 11 05:39:16 2016] that works, thanks [Fri Mar 11 06:33:52 2016] rewrite errors if it generates subgoal identical to original goal. Is there a way to ignore that? [Fri Mar 11 06:35:50 2016] You can always "try rewrite ..." so that it just doesn't do anything if it fails [Fri Mar 11 06:37:01 2016] yeah, that works :-) [Fri Mar 11 06:37:05 2016] thanks [Fri Mar 11 09:14:01 2016] is there a proof of commutativity of multiplication somewhere in the standard library? [Fri Mar 11 09:21:03 2016] jstolarek : yes, it's called 'mult_comm' and is available in Arith [Fri Mar 11 09:22:23 2016] Cypi: where exactly in Arith? [Fri Mar 11 09:22:43 2016] I tried looking in Arith.PeanoNat but couldn't locate it :-/ [Fri Mar 11 09:22:50 2016] and I can;t find it in the lemma index [Fri Mar 11 09:24:59 2016] Nevermind, mult_comm is actually an alias for Nat.mul_comm [Fri Mar 11 09:25:06 2016] (notice the lack of 't' for some reason) [Fri Mar 11 09:25:26 2016] still, mul_comm is also not listed in Lemma list' [Fri Mar 11 09:25:37 2016] unless I don't know how to use Coq's online reference [Fri Mar 11 09:27:00 2016] jstolarek: did you try the Locate command ? [Fri Mar 11 09:28:29 2016] Anachros: I did [Fri Mar 11 09:28:52 2016] again, I get pointed to Arith.NPeano.Nat [Fri Mar 11 09:29:04 2016] So The actual definition seems to be buried in a ton of modules :/ [Fri Mar 11 09:29:08 2016] Looking for it... [Fri Mar 11 09:35:59 2016] https://coq.inria.fr/library/Coq.Numbers.NatInt.NZMul.html# [Fri Mar 11 09:36:01 2016] there... [Fri Mar 11 09:36:07 2016] not very useful to know the precise location though [Fri Mar 11 09:36:18 2016] But I must say it makes for a confusing online reference :/ [Fri Mar 11 09:39:17 2016] is there a way to actually look at the source? [Fri Mar 11 09:39:29 2016] I'm trying to figure out how to prove commutativity of multiplication [Fri Mar 11 09:40:47 2016] You can download the sources, yes, or just look at them on Github for instance: https://github.com/coq/coq/blob/trunk/theories/Numbers/NatInt/NZMul.v#L30 [Fri Mar 11 09:41:12 2016] but honestly, I don't think this would help you, since they try to express everything in a sort of modular way [Fri Mar 11 09:41:17 2016] it can make for strange proofs [Fri Mar 11 09:41:38 2016] right [Fri Mar 11 09:41:55 2016] (in this case it's actually ok) [Fri Mar 11 13:46:10 2016] I'm having trouble getting ltac sequencing to do what I want. I've defined: [Fri Mar 11 13:46:13 2016] Tactic Notation "strengthen" constr(H) "by" tactic(T) := (cut H; [ solve [T] | ]). [Fri Mar 11 13:47:45 2016] then I can prove something by 'strengthen H by firstorder. .'. But if I change the period to a semicolon, I get an error. [Fri Mar 11 13:49:12 2016] I want my 'strengthen' notation to solve the first subgoal produced by cut, and then hand off the second subgoal to the next thing in the sequence. [Fri Mar 11 13:49:44 2016] but that doesn't seem to be what's happening. I think ';' is trying to something further on the first subgoal even though it's already been solved. [Fri Mar 11 13:52:13 2016] If you write '(strengthen H by firstorder); ', does that work? [Fri Mar 11 13:52:23 2016] Just to understand the problem (which is probably in the parsing of the tactic T) [Fri Mar 11 13:52:38 2016] ah, yup! [Fri Mar 11 13:52:48 2016] so I guess I just have a precedence problem. [Fri Mar 11 13:55:56 2016] Looks like writing "tacticn(T)" for n <= 3 works, but I don't really know much about tactic levels [Fri Mar 11 13:56:04 2016] (so 'tactic3(T)' for instance) [Fri Mar 11 13:59:58 2016] i didn't know about tactic levels either [Fri Mar 11 14:00:07 2016] in some ways Coq is small, but in other ways it's not at all [Fri Mar 11 16:05:36 2016] Coq novice here - CoqIDE seems to have difficulty with "Require Export" statements. I've been working through Pierce's "software foundations" in CoqIDE, and for example, I can make each chapter with "make" or manually with "coqc", but when I go to work in CoqIDE, and ask it to run "Poly.v", it claims "Error: File …Lists.vo [Fri Mar 11 16:05:36 2016] has bad magic number. It is corrupted or was compiled with another version of [Fri Mar 11 16:05:36 2016] Coq." [Fri Mar 11 16:06:54 2016] Alternatively, I can compile each buffer itself in CoqIDE, but in, say Induction.v, I can interactively work through the whole file with no problem, but when I go to compile buffer, it declares "Compilation output: [Fri Mar 11 16:06:54 2016] File "…/Induction.v", line 378, characters 2-14: [Fri Mar 11 16:06:54 2016] Error: The reference Basics.evenb was not found in the current environment." (again, not a problem in interactive mode) [Fri Mar 11 16:06:59 2016] Any advice? [Fri Mar 11 16:07:43 2016] isheff: if you downloaded the tarball, it might contain pre-built .vo files that are confusing things? [Fri Mar 11 16:07:49 2016] you could try `make clean` [Fri Mar 11 16:08:14 2016] jrw: I made the ".vo" files myself with coqc [Fri Mar 11 16:08:29 2016] jrw: and also tried the given makefile - same results [Fri Mar 11 16:09:37 2016] isheff: so the bad magic number error fundamentally means somebody is passing you .vos from a different version of coq [Fri Mar 11 16:09:51 2016] do you have multiple versions of coq on your machine? [Fri Mar 11 16:10:05 2016] jrw: erm . . . not that I know of . . . [Fri Mar 11 16:11:15 2016] isheff: did you install coqide separately from coq itself? [Fri Mar 11 16:15:16 2016] jrw: well, this machine is running osx, so I went to https://coq.inria.fr/download , and downloaded the given osx file, which is a .dmg containing just coqide.app. Now that you mention it, this begs the question of where my command-line installation came from. "coqc —version" turns up that it's 8.4, whereas coqide is 8.5, and thus a different version (as you said). Now, I'm still working on where that 8.4 installation came from... [Fri Mar 11 16:15:48 2016] ah, well that explains the symptoms at least :) [Fri Mar 11 16:15:55 2016] possibly you tried to install coq a long time ago [Fri Mar 11 16:17:41 2016] jrw: Thanks! It's true that I had, which begs the question of how I did that back then. If the "given" osx installer is actually just coqide, where did I get those binaries? Perhaps I compiled them . . . [Fri Mar 11 16:19:23 2016] isheff: the dmg includes both coqide and the command line tools. it sounds like your PATH is set to point to the 8.4 command line tools. [Fri Mar 11 16:19:34 2016] you may have an 8.4 version of coqide hidden somewhere [Fri Mar 11 16:20:19 2016] apparently [Fri Mar 11 16:20:35 2016] thanks for your help, I'll take a look at what's haunting my PATH [Fri Mar 11 17:35:59 2016] good evening jrw [Fri Mar 11 17:36:21 2016] Nik05: hello [Sat Mar 12 20:12:22 2016] Can anyone suggest a good strategy for defining a greatest common divisor algorithm over nats? :) [Sat Mar 12 20:12:42 2016] how would you do it on paper? [Sat Mar 12 20:13:36 2016] I'm not sure anymore haha [Sat Mar 12 20:13:38 2016] sorry [Sat Mar 12 20:13:46 2016] forall x y, exists p q n, (x = p/n) /\ (y = q/n) [Sat Mar 12 20:14:03 2016] if you can demonstrate that, then 'n' is your GCD [Sat Mar 12 20:14:18 2016] An intersection of prime factors? [Sat Mar 12 20:14:25 2016] I don't know about that [Sat Mar 12 20:14:40 2016] my method is probably very dumb, I just read the English description on Wikipedia [Sat Mar 12 20:14:49 2016] sure, i feel like that would probably be the best implementation [Sat Mar 12 20:15:02 2016] a multiset of prime factors, then take the intersection of the two sets [Sat Mar 12 20:15:08 2016] (for the binary gcd operation) [Sat Mar 12 20:15:26 2016] then just to a mass-product on that, then bam, gcd [Sat Mar 12 20:17:54 2016] What's the matter with Euclidean algorithm? [Sat Mar 12 20:20:05 2016] Cypi: Ahh woah I forgot about that property... thank you :) [Sat Mar 12 20:20:48 2016] (there is also Nat.gcd which is defined in the stdlib, but I don't know if you wanted to redefine it yourself) [Sat Mar 12 20:23:54 2016] agh crud, sorry I'm still finding my way around. In this link, https://coq.inria.fr/library/ Numbers > Natural doesn't really show Nat [Sat Mar 12 20:24:07 2016] I'm a klutz sorry [Sat Mar 12 20:24:37 2016] Nah, it's actually complicated :/ . This defines some operations on a type that would verify some properties of the natural numbers [Sat Mar 12 20:24:54 2016] it is then instantiated to create the Nat module [Sat Mar 12 20:25:05 2016] (as well as a lot of other modules which are simlarly abstracted) [Sat Mar 12 20:25:21 2016] It makes for a confusing documentation sadly [Sat Mar 12 20:26:43 2016] hmm, that's very different to what I'm used to haha. So module-level metaprogramming? [Sat Mar 12 20:26:52 2016] I guess so [Sat Mar 12 20:27:07 2016] I come from a Haskell background, so seeing these `Module Type Foo` declarations are a bit intimidating [Sat Mar 12 20:27:21 2016] I really need to dig into software foundations more [Sat Mar 12 20:27:50 2016] Software Foundations won't talk about this [Sat Mar 12 20:28:25 2016] I would say this is not really essential to Coq [Sat Mar 12 20:29:01 2016] hmm, I think I understand why it makes sense [Sat Mar 12 20:29:11 2016] for different fast implementations I mean [Sat Mar 12 20:29:57 2016] I hate to ask arbitrary questions, but does coq have `let` statements? Or `where` statements? So we can build more local definitions. Right now my only idea is `match complicatedExpression with | x => ` haha [Sat Mar 12 20:30:32 2016] There is a "let x := t in u" construct, yes [Sat Mar 12 20:30:47 2016] 'where', I don't know, I don't come from Haskell :/ [Sat Mar 12 20:31:49 2016] there are no where statements [Sat Mar 12 20:32:34 2016] athan: you can go a *long* way without ever dealing with module functors (Module Type, and where the word "functor" means something different from its Haskell/CT meaning) [Sat Mar 12 20:41:21 2016] johnw: Sorry, my internet is a bit flakey. That's interesting though - I think I've heard functor used that way with ML, at least I think :s [Sat Mar 12 20:41:24 2016] or OCaml maybe [Sat Mar 12 20:41:48 2016] Indeed [Sat Mar 12 20:41:48 2016] Cypi: Thank you :) [Sat Mar 12 20:42:12 2016] How can I find this `Nat` module's documentation? [Sat Mar 12 20:42:16 2016] the instantiated one, I mean [Sat Mar 12 20:43:54 2016] The operations over nat are defined in https://coq.inria.fr/library/Coq.Init.Nat.html# and the module itself is instantiated in https://coq.inria.fr/library/Coq.Arith.PeanoNat.html [Sat Mar 12 20:45:26 2016] The problem is that all the lemmas that derive from these are hidden in a cascade of modules [Sat Mar 12 20:47:03 2016] o.O man... [Sat Mar 12 20:47:18 2016] Yeah, confusing, as I said :/ [Sat Mar 12 20:47:33 2016] hmm... How do I import Nat's utilities? `Require Import Nat.` seems to show that Nat isn't known of in the import path [Sat Mar 12 20:48:43 2016] Nat is already available by default. If you want to bring everything in Nat in the global namespace, you can use `Import Nat.` [Sat Mar 12 20:49:44 2016] ahhh crap, okay sorry. I'll read software foundations ._. [Sat Mar 12 20:50:10 2016] Hmm, apparently you still need to `Require Import Arith.` to have access to all the lemmas, otherwise you only have the axioms, basically [Sat Mar 12 20:50:59 2016] hmm, is a lemma similar to a definition? [Sat Mar 12 20:51:27 2016] hrm, `Import Nat.` => `Nat is not a module` :( [Sat Mar 12 20:51:41 2016] Are you using the 8.5 version? [Sat Mar 12 20:52:03 2016] And yes, lemmas and definitions are basically the same. It is just that usually, a lemma is an opaque proof of a statement, whereas a definition is a transparent definition of some object. But they are in essence the same. [Sat Mar 12 20:53:09 2016] Cypi: hmm, okay [Sat Mar 12 20:53:44 2016] Ahh, I'm using 8.4, blasted ubuntu [Sat Mar 12 20:53:58 2016] Ah well, then maybe everything I told you about Nat is wrong for 8.4, I don't know :D [Sat Mar 12 20:55:04 2016] D: [Sat Mar 12 20:55:22 2016] I'm going to build from source now, hopefully that will help [Sat Mar 12 22:20:30 2016] https://coq.inria.fr/cocorico/Configuration%20of%20CoqIDE I'm trying to follow the instructions here for changing the coq keybindings. Putting the keybindings file in the correct directory doesn't seem to effect CoqIDE. When CoqIDE closes it then overwrites the file. I'm running coq compiled from the V8.5 tag. [Sat Mar 12 22:25:46 2016] Change the binding from within coq worked fine. [Sun Mar 13 03:23:01 2016] how can i turn a plugin into something which is built into the toplevel? [Sun Mar 13 09:37:50 2016] Are there any papers or is there any documentation on how Coq implements Notation? [Sun Mar 13 09:41:05 2016] there's the reference manual: https://coq.inria.fr/refman/Reference-Manual014.html [Sun Mar 13 09:42:02 2016] rrika: Uhu, that's what I was checking out. But I was wondering if there was anything else around. [Sun Mar 13 09:44:23 2016] I don't know much about coq or its source code. The manual says: "Coq extensible parsing is performed by Camlp5 which is essentially a LL1 parser." [Sun Mar 13 12:39:12 2016] Does anyone have pointers to serious bugs in Coq extraction from the past? [Sun Mar 13 13:46:30 2016] Smerdyakov: Are you looking for something more interesting than http://tinyurl.com/jv4ae7o , the list of the 84 bugs on the bug tracker matching "extraction"? [Sun Mar 13 13:47:03 2016] jgross, not sure. Clement was thinking about sprucing up a paper with a list of scary bugs. [Sun Mar 13 13:47:34 2016] jgross: hey can i ask you some questions about denotational semantics? [Sun Mar 13 13:53:16 2016] Smerdyakov: I bet Maxime Denes and Pierre-Marie Pedrot (probably also Hugo) would have a good sense of what all the serious bugs have been. [Sun Mar 13 13:53:39 2016] benzrf: Sure, but I'm about to run off to teach two hours of classes for Spark, so you won't get any answers from me for a few hours ^.^ [Sun Mar 13 13:53:46 2016] D: [Sun Mar 13 13:53:55 2016] do you know if there's anybody else here i can talk to, then? [Mon Mar 14 09:24:28 2016] benzrf: what was your question? [Mon Mar 14 09:26:11 2016] johnw: does denotational semantics for the untyped lambda calculus generally just look like "the denotation of a halting term is the normal form; the denotation of a non halting term is bottom" [Mon Mar 14 09:27:01 2016] although that sounds right, I guess you do need to ask Jason :) [Mon Mar 14 09:27:39 2016] he kicked me out of his HoTT class at splash because it was actually introductory to type theory as a whole ;-; [Mon Mar 14 09:27:58 2016] huh, he "kicked you out"? [Mon Mar 14 09:28:05 2016] not entirely literally [Mon Mar 14 09:28:14 2016] but he told me that there was nothing for me here [Mon Mar 14 12:21:12 2016] benzrf: re: your question about denotation semantics, it can completely depend on a model. There is a trivial model, where everything is just bottom. Then there is the Scott model which is kinda weird, in which terms are interpreted as certain functions from natural numbers. Then there is a model on P(N) -- powerset of natural numbers with a special topology [Mon Mar 14 15:21:39 2016] * going to bed [Mon Mar 14 16:05:35 2016] Am having problems loading a library, does someone want to help me with that? [Mon Mar 14 16:24:09 2016] Is there a way to install user contributions via coq/ocaml? [Mon Mar 14 16:25:39 2016] notdan: interesting [Mon Mar 14 16:26:39 2016] is there some kind of api for coq [Mon Mar 14 16:26:51 2016] can i import it as a package in another program & call into it [Mon Mar 14 16:27:00 2016] if i wanted to, say, make another interface for it [Mon Mar 14 17:27:03 2016] hi, i need a motivational short example for an intro talk on formal methods. my idea is to solve the same problem in python, haskell, and coq. of course, i want haskell to beat python and coq to beat haskell. any ideas? [Mon Mar 14 17:27:16 2016] How to fix the error: Eroor: The file *file* contains library path.lib and not library lib [Mon Mar 14 17:28:42 2016] i've been thinking of implementing an ordinary zip in python, then a number-parameterized version in haskell, but i don't know how to improve a haskell version in coq [Mon Mar 14 17:30:02 2016] nkaretnikov: hi [Mon Mar 14 17:30:14 2016] nkaretnikov: that should be a pretty easy example to construct [Mon Mar 14 17:30:57 2016] johnw: hi, i know it's easy. i don't know how i can improve a haskell version in coq [Mon Mar 14 17:31:06 2016] nkaretnikov: for example, a function that wants its input list in sorted order. With Python, and even Haskell, the only way to guarantee that that's always true is to perform a sort before calling. [Mon Mar 14 17:31:07 2016] what can coq bring to the table in this case? [Mon Mar 14 17:31:21 2016] but in Coq, if you can verify that the list is always sorted, you avoid the sort [Mon Mar 14 17:31:31 2016] but i want the same example in three langs :) [Mon Mar 14 17:31:42 2016] the audience is not very familiar with programming [Mon Mar 14 17:31:45 2016] sure, write a function that uses a sorted list [Mon Mar 14 17:31:55 2016] in Python, you're not even sure that it *is* a list [Mon Mar 14 17:32:08 2016] in Haskell you know it's a list, but you can't guarantee that it's sorted, without always sorting it [Mon Mar 14 17:32:10 2016] hm! [Mon Mar 14 17:32:23 2016] in Coq, the typechecker ensures that all code paths leading to your function pass in a sorted list [Mon Mar 14 17:32:24 2016] i think it's a great example [Mon Mar 14 17:32:32 2016] thank you :) [Mon Mar 14 17:32:36 2016] sure thing! [Mon Mar 14 18:26:01 2016] I'm trying to prove the pidgeonhole principle. [Mon Mar 14 18:26:15 2016] I'm stuck but I want to solve it myself :[ [Mon Mar 14 18:28:54 2016] it's a tough one [Mon Mar 14 18:31:14 2016] really, I think I got through the few tasks about it just by luck [Mon Mar 14 18:31:19 2016] *above it [Mon Mar 14 18:31:37 2016] subseq was near impossible for me [Mon Mar 14 18:31:43 2016] subseq_trans that is [Mon Mar 14 21:48:27 2016] good evning [Mon Mar 14 21:48:37 2016] rrika its though [Mon Mar 14 21:48:56 2016] im back again, got new gpu and had kernel errors [Mon Mar 14 21:49:04 2016] nice [Mon Mar 14 21:49:06 2016] what will you do [Mon Mar 14 21:49:08 2016] using the latest kernel it boots :) [Mon Mar 14 21:49:25 2016] encode videos, do trendy machine learning, just play games at 2000x1000 pixels? [Mon Mar 14 21:49:39 2016] oh uh [Mon Mar 14 21:49:59 2016] all [Mon Mar 14 21:50:24 2016] nice, I want to do machine learning but I never get around to getting the hardware for it [Mon Mar 14 21:50:36 2016] and games, of course. [Mon Mar 14 21:50:47 2016] well, who doesn't want a super computer [Mon Mar 14 21:50:55 2016] good luck with the pidgeonhole principle :P [Mon Mar 14 21:51:45 2016] I've given up for day. [Mon Mar 14 21:52:05 2016] Tomorrow with fresh mind. [Mon Mar 14 21:57:52 2016] :) [Mon Mar 14 22:02:28 2016] have a good night [Mon Mar 14 22:04:00 2016] same [Mon Mar 14 23:58:10 2016] what's HdRel in Coq.Sorting.Sorted? what does Hd stand for? [Tue Mar 15 00:42:06 2016] ah, it's probably head [Tue Mar 15 01:37:27 2016] johnw: https://gist.github.com/nkaretnikov/ad9dba77a9eafcc2d752 [Tue Mar 15 07:36:32 2016] http://lpaste.net/6947765245217603584 [Tue Mar 15 07:36:52 2016] how do I prove this goal given the inudctive hypothesis? [Tue Mar 15 07:37:17 2016] if IH was quantified I'd say "rewrite (IHn' (S n''))" [Tue Mar 15 07:37:38 2016] but it's not quantified and so I don;t know how to substitute n'' into it [Tue Mar 15 08:10:45 2016] jstolarek : since you need an induction hypothesis on (n-2) and not on (n-1), you might need to do a stronger induction. [Tue Mar 15 08:12:53 2016] what do you mean by stronger? [Tue Mar 15 08:13:32 2016] Cypi: ^^^ [Tue Mar 15 08:13:54 2016] For instance, instead of stating "forall n, P n" (where 'P' is the proposition you want to prove), you could say "forall m n, n < m -> P m", and then do an induction on m. [Tue Mar 15 08:14:06 2016] What is sometimes called "strong" induction on natural numbers [Tue Mar 15 08:16:10 2016] but the first claim seems to be more general then the second one [Tue Mar 15 08:16:28 2016] I don't see how they are equivalent [Tue Mar 15 08:18:22 2016] sorry, for the second one I meant n < m -> P n [Tue Mar 15 08:18:37 2016] Let's say I have a proof of "forall m n, n < m -> P n" and I want to prove "forall n, P n". I can instantiate the first one with (m := S n) and (n := n) to get "n < S n -> P n", which gets you "P n" [Tue Mar 15 08:19:43 2016] In Coq terms: http://lpaste.net/154728 [Tue Mar 15 08:22:47 2016] Cypi: hm... that sounds smart :-) but TBH I'm not sure how to use this info to make progress :( [Tue Mar 15 08:25:32 2016] oh, got it [Tue Mar 15 08:25:42 2016] I just realized I have an extra lemma that I can use :-) [Tue Mar 15 12:01:59 2016] so I've noticed that induction does pretty poorly with a constructor applied to its arguments, e.g. doing induction on inductive_prop (constructor a b) fails to generate a useful induction predicate, while doing induction on inductive_prop c /\ c_a = a generates the desired induction predicate [Tue Mar 15 12:02:53 2016] but that can make lemmas pretty clunky looking [Tue Mar 15 12:04:05 2016] anyone else have this issue and have a nicer solution? [Tue Mar 15 18:22:29 2016] stelleg: your question is lacking enough context for me to understand it [Tue Mar 15 18:22:36 2016] what in the heck is c_a, etc. [Tue Mar 15 18:23:48 2016] johnw: sorry, I'll try and come up with a simple example and paste it [Tue Mar 15 19:02:20 2016] example: http://lpaste.net/154757 [Tue Mar 15 19:02:22 2016] not that short :( [Tue Mar 15 19:03:29 2016] there's the two different attempts at the bottom [Tue Mar 15 19:05:36 2016] worth noting I haven't tried it in 8.5 [Tue Mar 15 19:14:37 2016] stelleg, does inversion help here? [Tue Mar 15 19:16:29 2016] also, you can't all quantify both your program and the result of the program [Tue Mar 15 19:16:49 2016] else, you'll end up having to prove that (2 2 +) can result in stack [5] [Tue Mar 15 19:16:55 2016] (at least I think so) [Tue Mar 15 19:18:09 2016] rrika: I don't think so, because you're just showing that if the transitive closure of the step relation holds for some result, then the evaluator will evaluate to that result [Tue Mar 15 19:18:26 2016] oh right [Tue Mar 15 19:18:36 2016] you're proving a proof that it already has evaluated to that value [Tue Mar 15 19:18:37 2016] as for inversion, I think you need induction here [Tue Mar 15 19:18:45 2016] right [Tue Mar 15 19:18:58 2016] I think you need induction because `multi` is recursive [Tue Mar 15 19:19:07 2016] and you will need that induction hypothesis [Tue Mar 15 19:20:08 2016] (but I'll check quickly) [Tue Mar 15 19:22:39 2016] is that a task from some book? [Tue Mar 15 19:24:02 2016] its very close to what's described in the Imp and Smallstep chapters of SF [Tue Mar 15 19:24:17 2016] I haven't gotten that far yet [Tue Mar 15 19:24:48 2016] it's pretty great [Tue Mar 15 19:29:00 2016] have you tried induction on a term that's not a single variable? [Tue Mar 15 19:30:57 2016] not sure I follow [Tue Mar 15 19:31:20 2016] I'm trying induction (compile e) right now [Tue Mar 15 19:32:28 2016] stelleg: this is a known and very common problem with the induction tactic. usually I use the [remember] tactic to transform the goal before doing induction [Tue Mar 15 19:32:37 2016] that way you can keep the clean statement of the lemma, and still get the right IH [Tue Mar 15 19:32:46 2016] jrw: cool, thanks! [Tue Mar 15 19:32:58 2016] it is also possible to automate the remembering [Tue Mar 15 19:33:02 2016] jrw, what kind of transformation exactly? [Tue Mar 15 19:33:09 2016] because I've been running into this issue too [Tue Mar 15 19:33:16 2016] let me post an example [Tue Mar 15 19:33:54 2016] rrika, jrw: thanks, will check back a bit later [Tue Mar 15 19:34:07 2016] cya [Tue Mar 15 19:34:21 2016] btw, I'm not convinced this is going to be provable, but I can help fix the surface issue of induction misbehaving [Tue Mar 15 19:34:38 2016] there is also a deeper issue of the statement not being general enough to be proved by induction [Tue Mar 15 19:35:49 2016] http://lpaste.net/154757 [Tue Mar 15 19:35:56 2016] I guess it let me just edit the paste? [Tue Mar 15 19:36:07 2016] sorry :\ [Tue Mar 15 19:36:18 2016] oops [Tue Mar 15 19:37:01 2016] remember will replace the term in other hypothesis? [Tue Mar 15 19:37:18 2016] oh wow this looks clean [Tue Mar 15 19:37:44 2016] [remember complexExpression] finds all occurrences of the expression replaces them with a fresh variable [Tue Mar 15 19:37:49 2016] which is constrained with an equality [Tue Mar 15 23:51:02 2016] jrw: perfect, this is exactly what I was looking for [Tue Mar 15 23:51:05 2016] thanks! [Tue Mar 15 23:51:17 2016] np [Tue Mar 15 23:51:27 2016] and yeah I'm not sure its provable, just threw it together in a few minutes [Tue Mar 15 23:53:22 2016] I find it somewhat amusing that "lambda pastebin" is mutable :) [Tue Mar 15 23:55:07 2016] haha, yeah [Tue Mar 15 23:55:23 2016] I clicked "edit" figuring it really meant "make a copy" [Wed Mar 16 03:37:29 2016] I'm defining a function using proof scripting, where I "pose" the definition and then perform multiple unfoldings and simplifications; however, these operations are not being retained in the final definition. Is there a trick for making them stick? [Wed Mar 16 04:20:41 2016] turns out I need to use Eval compute [terms...] in foo. [Wed Mar 16 04:20:50 2016] in order to ensure that the terms are unfolded in the definition [Wed Mar 16 08:06:23 2016] http://lpaste.net/154800 [Wed Mar 16 08:06:55 2016] based on the definition of normalize the RHS of my goal can be reduced to "twice (normalize (twice b'))" [Wed Mar 16 08:07:07 2016] which tactics do I use to do that? [Wed Mar 16 08:07:37 2016] I tried beta reduction with "cbv beta" but that does nothing :( [Wed Mar 16 09:17:28 2016] jgross: you about? [Wed Mar 16 12:53:32 2016] benzrf: What's up? [Wed Mar 16 13:44:17 2016] jstolarek: you can always just assert (twice (normalize (twice b')) = normalize (twice (twice b'))). reflexivity. [Wed Mar 16 13:44:21 2016] not sure about a quicker way [Wed Mar 16 13:45:52 2016] jgross: do you know anything about endowing implementations of the CoC with functions and types implemented in the host language without breaking the system's properties in unexpected ways? [Wed Mar 16 14:05:53 2016] jstolarek: you can say "replace (twice (normalize (twice b'))) with (normalize (twice (twice b'))) by reflexivity", which is sort of an ad-hoc rewrite [Wed Mar 16 14:25:01 2016] as usual johnw's answer is better [Wed Mar 16 14:36:45 2016] stelleg: how is your compile_correct proof going? [Wed Mar 16 14:40:25 2016] rrika_mobile: well the one I'm actually working on is going painfully slowly. bigstep -> smallstep wasn't too bad, but smallstep -> bigstep is proving quite difficult [Wed Mar 16 14:40:52 2016] rrika_mobile: may go back and try and prove that toy one i posted yesterday as practice [Wed Mar 16 14:43:17 2016] I began by proving lots of properties about multistep/step but haven't really gotten closer to showing anything about compile: https://gist.github.com/rrika/ce36a9098586fd1ce1ed [Wed Mar 16 14:43:39 2016] I wonder which of these are useful for later and which not. [Wed Mar 16 14:44:26 2016] rrika_mobile: very nice, you've convinced me to go back and play with that :) [Wed Mar 16 14:44:34 2016] haha [Wed Mar 16 14:44:50 2016] especially the first proofs are very nice [Wed Mar 16 14:44:53 2016] using ; constructor. just covers all instructions [Wed Mar 16 14:45:11 2016] (I don't even understand why, lol) [Wed Mar 16 14:47:43 2016] what are you dealing with now? [Wed Mar 16 14:47:43 2016] if this is a toy one [Wed Mar 16 14:47:54 2016] what are you dealing with now? [Wed Mar 16 14:48:27 2016] proving that a small-step and big step implementation of call by need are equivalent [Wed Mar 16 14:48:43 2016] for a particular abstract machine I've come up with [Wed Mar 16 14:49:51 2016] I see. [Wed Mar 16 14:50:00 2016] I'd rather not share the code here yet, its quite hideous :) [Wed Mar 16 14:50:05 2016] haha [Wed Mar 16 14:51:24 2016] well, if I get over the pidgeon hold principle in SF I can finally move on to the Imp chapter [Wed Mar 16 14:53:17 2016] you're more dedicated than I am apparently [Wed Mar 16 14:53:32 2016] I skipped large chunks to get to the parts I was interested in [Wed Mar 16 14:54:02 2016] I try to have every single task solved [Wed Mar 16 14:54:13 2016] (it's the reason why it's taking me months) [Wed Mar 16 14:54:22 2016] (hard tasks making me stop for weeks) [Wed Mar 16 15:30:56 2016] rrika: if you leave the hard ones until later, they become easier due to the new insights you gain from later exercises [Wed Mar 16 15:31:21 2016] I don't think there's much didactic benefit from forcing linearity [Wed Mar 16 15:42:16 2016] johnw, I can't resist the challenge. [Wed Mar 16 15:42:30 2016] I know, some are marked as optional [Wed Mar 16 15:51:59 2016] with Coq, most everything gets easier with time and more experience [Wed Mar 16 15:52:24 2016] the other day I found myself doing a proof, and just as I was finishing I realized that I was proving the exact same thing (fairly easily) that it had taken me 40 hours to do two years ago [Wed Mar 16 15:53:03 2016] haha [Wed Mar 16 15:53:08 2016] I had the same the other way round too [Wed Mar 16 15:53:15 2016] I tried to solve something the second time [Wed Mar 16 15:53:20 2016] and it took me three screen pages [Wed Mar 16 15:53:25 2016] johnw: that is very good to hear [Wed Mar 16 15:53:26 2016] when my first attempt was ~8 lines [Wed Mar 16 15:53:58 2016] rrika: that's been my experience a few times [Wed Mar 16 15:54:01 2016] deeply depressing [Wed Mar 16 15:54:17 2016] I think the trend is still towards shorter and better proofs [Wed Mar 16 15:54:33 2016] true [Wed Mar 16 15:54:39 2016] it just shows that the new information I've received hasn't quite found its place in my brain yet [Wed Mar 16 15:56:26 2016] it took me a while to get fully past the "whack-a-mole" phase [Wed Mar 16 15:56:35 2016] where you keep trying different tactics to see what makes progress [Wed Mar 16 15:56:56 2016] "Oh, not induction? maybe inversion? maybe destruct?" [Wed Mar 16 15:57:51 2016] I think that it requires an understanding of how tactics relate to terms, and what the proof terms mean; I mean, we're really just writing programs within a different domain (Prop), and so all the tactics we use have an analog to things we're mostly familiar with in programming [Wed Mar 16 16:11:23 2016] I'm definitely still in whack-a-mole phase [Wed Mar 16 16:23:36 2016] just getting better at hitting the moles [Wed Mar 16 16:26:38 2016] ^ [Wed Mar 16 17:18:42 2016] okay, can someone give me a hint for the pidgeon hole principle? [Wed Mar 16 17:19:53 2016] rrika: which version are you doing and what have you tried? [Wed Mar 16 17:20:23 2016] 8.4 [Wed Mar 16 17:20:42 2016] rrika: no I mean what statement of the pigeonhole principle are you trying to prove? [Wed Mar 16 17:20:45 2016] the one from SF? [Wed Mar 16 17:20:51 2016] yes [Wed Mar 16 17:21:01 2016] I don't even know what my IH should be [Wed Mar 16 17:21:10 2016] SF suggests I do induction over l1 [Wed Mar 16 17:22:48 2016] rrika: you're planning on assuming excluded middle or decidable equality right? [Wed Mar 16 17:25:45 2016] Well, I want to do without, but by now I'm ready to include that too [Wed Mar 16 17:29:32 2016] rrika: the proof without is fundamentally different from the one with, and you need to restructure the theorem statements. so I recommend doing it with decidable equality first [Wed Mar 16 17:29:41 2016] so what have you tried? where are you stuck? [Thu Mar 17 04:18:59 2016] I have a goal that is clearly false and I have a premise that is also false. How do I proceed in such a case? exfalse replaces the goal with False but I'm not sure what the next steps should be :-/ [Thu Mar 17 04:19:23 2016] It depends how you can deduce False from your premise [Thu Mar 17 04:19:49 2016] "inversion H" on your premise might work if it's an impossible case in an inductive type for instance [Thu Mar 17 04:20:21 2016] TBH I am not yet sure how to deduce false from the premise [Thu Mar 17 04:20:51 2016] the goal is obviously false: [] = n :: l [Thu Mar 17 04:21:11 2016] but the premise is: [] = snoc (rev l2) n [Thu Mar 17 04:25:04 2016] hm... if I have a premise that says "a = b" can I apply a function to both sides so that the premise says "f a = f b" ? [Thu Mar 17 04:25:24 2016] that would allow me to use an earlier lemma and make progress [Thu Mar 17 04:25:30 2016] "apply f_equal f in H" [Thu Mar 17 04:25:30 2016] you could do induction on l2 I think [Thu Mar 17 04:25:40 2016] (regarding [] = snoc (rev l2) n) [Thu Mar 17 04:25:53 2016] there may be a simpler way [Thu Mar 17 04:26:07 2016] I guess you want to use length. That looks like a simple idea :) [Thu Mar 17 04:27:00 2016] Cypi: I was thinking about using rev and then applying rev (rev l) = l [Thu Mar 17 04:27:14 2016] hm.. getting syntax error from apply f_equal [Thu Mar 17 04:27:27 2016] rrika: I tried that, but I get stuck later on :( [Thu Mar 17 04:27:32 2016] "apply (f_equal f) in H" probably [Thu Mar 17 04:28:15 2016] oh, silly me [Thu Mar 17 04:28:31 2016] "apply (f_equal _ _ f) in H" [Thu Mar 17 04:33:19 2016] jstolarek, you can do it both via length and destruct [Thu Mar 17 04:38:41 2016] rrika: you mean "destruct H" ? [Thu Mar 17 04:38:48 2016] where H is a false premise [Thu Mar 17 04:38:50 2016] ? [Thu Mar 17 04:39:13 2016] ah, no [Thu Mar 17 04:39:22 2016] destruct the list into its nil and cons case [Thu Mar 17 04:39:31 2016] the question is just which list [Thu Mar 17 04:39:34 2016] ah, that [Thu Mar 17 04:39:43 2016] basically, snoc will always return some kind of cons [Thu Mar 17 04:39:55 2016] yes, I destructed the second list [Thu Mar 17 04:40:04 2016] now I'm struggling with this: [Thu Mar 17 04:40:04 2016] which second list? [Thu Mar 17 04:40:16 2016] my theorem is about two lists :-) [Thu Mar 17 04:40:21 2016] oh, okay [Thu Mar 17 04:40:22 2016] now I have a premise H : length (snoc (rev l1) n) = 0 [Thu Mar 17 04:40:33 2016] and I just proved blt_nat 0 (length (snoc l n)) = true. [Thu Mar 17 04:40:34 2016] Oh yes, you could actually just "destruct (rev l2)" [Thu Mar 17 04:40:39 2016] ^ [Thu Mar 17 04:40:48 2016] not even using length or anything [Thu Mar 17 04:40:50 2016] is what I was thinking of [Thu Mar 17 04:40:54 2016] ah [Thu Mar 17 04:41:04 2016] I haven't thought about doing that [Thu Mar 17 04:41:12 2016] I'll try that in a moment [Thu Mar 17 04:41:43 2016] but now, given my false premise H and my lemma that "blt_nat 0 (length (snoc l n)) = true" how can I use that lemma to show contradiction [Thu Mar 17 04:41:46 2016] ? [Thu Mar 17 04:42:10 2016] it looks pretty obvious to me as a human being that these two are contradictory but I don't know how to convince Coq about it :-) [Thu Mar 17 04:47:32 2016] well, there are tactics that can use a contradiction in the premises to prove any current goal [Thu Mar 17 04:47:48 2016] inversion H. or congruence. [Thu Mar 17 04:48:05 2016] ah, you're doing the length approach [Thu Mar 17 04:50:18 2016] ah [Thu Mar 17 04:50:45 2016] you make sure that "blt_nat 0 (…) = true" turns into "blt_nat 0 (S (…))" [Thu Mar 17 04:51:10 2016] so if you can somehow turn "length (snoc l n)" into "S (length l)" [Thu Mar 17 04:51:54 2016] "blt_nat 0 (S …)" will turn into true when you do "simpl." on it I think [Thu Mar 17 04:51:57 2016] rrika: I managed to do that, although I feel there must be a better approach than the one I used [Thu Mar 17 04:52:07 2016] show your whole thing [Thu Mar 17 04:52:15 2016] sure [Thu Mar 17 04:53:00 2016] jstolarek pasted “No title” at http://lpaste.net/154839 [Thu Mar 17 04:53:21 2016] working on the last case [Thu Mar 17 04:53:46 2016] but I don't like where this is going - it feels like there's a better way [Thu Mar 17 04:56:06 2016] jstolarek, rev_injective can be done without any induction [Thu Mar 17 04:56:20 2016] avoiding induction will make it much cleaner too [Thu Mar 17 04:56:30 2016] (basically you already did the induction it needs in rev_involutive) [Thu Mar 17 04:57:40 2016] ah, got it. [Thu Mar 17 04:58:09 2016] jstolarek, I see you try to turn "rev []" into "[]" in your premises [Thu Mar 17 04:58:19 2016] you can just use "simpl." for that [Thu Mar 17 04:58:23 2016] "simpl in H." [Thu Mar 17 04:58:54 2016] oh, that also affects the other side [Thu Mar 17 04:58:55 2016] nvm [Thu Mar 17 04:59:12 2016] jstolarek, how does the new one look like? [Thu Mar 17 04:59:49 2016] jstolarek annotated “No title” with “No title (annotation)” at http://lpaste.net/154839#a154840 [Thu Mar 17 04:59:59 2016] rrika: ^^^ [Thu Mar 17 05:02:05 2016] jstolarek, cool [Thu Mar 17 05:02:28 2016] did you notice how your "apply (f_equal rev) in H. repeat (rewrite rev_involutive in H)." does exactly what you want to show? [Thu Mar 17 05:02:57 2016] turning a "H : rev (n :: l1) = rev l2" into "H : rev (n :: l1) = rev l2" [Thu Mar 17 05:03:11 2016] oops, copied wrong text [Thu Mar 17 05:03:22 2016] turning a "H : rev (n :: l1) = rev l2" into "H : n :: l1 = l2" [Thu Mar 17 05:03:29 2016] yes :-) [Thu Mar 17 05:03:41 2016] I'm now trying to figure out a way to avoid the repetition [Thu Mar 17 05:03:56 2016] last two goals are solve with the same chain of tactics [Thu Mar 17 05:04:00 2016] try without destruction. [Thu Mar 17 05:05:39 2016] yup, that works :-) [Thu Mar 17 05:07:00 2016] wow, that was enlightening [Thu Mar 17 05:07:13 2016] got to go to work now, have fun [Thu Mar 17 06:32:32 2016] is there a way to avoid matching on parameters of an inductive data type? [Thu Mar 17 06:32:58 2016] eg. if I have inductive definition of a list and would like to match on "nil" instead of "nil _" [Thu Mar 17 06:33:55 2016] Software Foundations says this should simply work, ut it does not work for me under Coq 8.5 - I have to include an underscore to match the parameter of list data type [Thu Mar 17 06:34:37 2016] "Set Asymmetric Patterns" [Thu Mar 17 06:34:47 2016] Write that for instance at the top of your file [Thu Mar 17 06:39:53 2016] Cypi: thanks. Now I see that I am prohibited from matching on paremeters [Thu Mar 17 06:40:19 2016] Yes indeed :) [Thu Mar 17 06:43:37 2016] I wonder if there are situations where this becomes a problem [Thu Mar 17 06:44:09 2016] meaning, if there might be a single place where for some reason I'd like to match on a parameter [Thu Mar 17 06:44:13 2016] Parameters cannot be refined by knowing which constructors you actually have [Thu Mar 17 06:44:15 2016] so no [Thu Mar 17 06:44:22 2016] You can always deduce the actual parameter from the type [Thu Mar 17 06:44:37 2016] that is what distinguish parameters from indices [Thu Mar 17 06:51:43 2016] right [Thu Mar 17 06:51:49 2016] that makes sense [Thu Mar 17 07:11:23 2016] jstolarek pasted “No title” at http://lpaste.net/154850 [Thu Mar 17 07:11:39 2016] The term "combine X Y l1' l2'" has type "list (X * Y)" while it is expected to have type "list (X * Y)". [Thu Mar 17 07:11:53 2016] Am I missing something or is that error message bogus? [Thu Mar 17 07:12:54 2016] Hmm, it just works here :o [Thu Mar 17 07:14:03 2016] It could be a problem of universes in your case (which would explain the sort of bogus error message). But still, it's strange that there is even an error [Thu Mar 17 07:14:47 2016] ok, this means something else must be wrong in my source file... [Thu Mar 17 07:28:49 2016] Cypi: which Coq version do you have? [Thu Mar 17 07:29:05 2016] 8.5 [Thu Mar 17 07:31:04 2016] same here... strange [Thu Mar 17 07:34:49 2016] jstolarek pasted “No title” at http://lpaste.net/154852 [Thu Mar 17 07:35:09 2016] smae problem with split [Thu Mar 17 07:35:16 2016] well, almost the same [Thu Mar 17 07:35:28 2016] Again, it just works here :/ [Thu Mar 17 07:35:53 2016] * is puzzled [Thu Mar 17 07:36:04 2016] Hmm, have you defined the notation "_ * _" for types yourself, for instance? [Thu Mar 17 07:36:10 2016] yes [Thu Mar 17 07:36:26 2016] Notation "( X * Y )" := (prod X Y) : type_scope. [Thu Mar 17 07:36:56 2016] Still works [Thu Mar 17 07:36:59 2016] I have also defined this: [Thu Mar 17 07:37:00 2016] Notation "( x , y )" := (pair x y). [Thu Mar 17 08:15:02 2016] Sorry, I don't know what could be wrong, it just works here :( [Thu Mar 17 09:18:25 2016] jstolarek pasted “No title” at http://lpaste.net/154858 [Thu Mar 17 09:19:23 2016] Cypi: does the above work for you? [Thu Mar 17 09:21:04 2016] it's a minimal working example (or rather: non-working example) [Thu Mar 17 09:21:08 2016] No, it does not. Ok, I see, I don't know why Coq is confused with its notations [Thu Mar 17 09:21:20 2016] If you just disable the notations, you'll see: The term "combine X Y l1' l2'" has type "list (Datatypes.prod X Y)" while it is expected to have type "list (prod X Y)" [Thu Mar 17 09:22:05 2016] Either not specifiying the return type and letting Coq infer it, or specifying explicitely "list (prod X Y)" will work [Thu Mar 17 09:22:14 2016] But it's not ideal... [Thu Mar 17 09:22:43 2016] Ah [Thu Mar 17 09:22:50 2016] Notation "X * Y" := (prod X Y) : type_scope. [Thu Mar 17 09:22:52 2016] this works better [Thu Mar 17 09:23:03 2016] ah [Thu Mar 17 09:23:08 2016] that was tricky [Thu Mar 17 09:23:13 2016] Notations are :/ [Thu Mar 17 09:23:43 2016] * thinks many things in Coq are :/ [Thu Mar 17 09:24:10 2016] I once spend 30 minute strying to figure out why the code from CPDT does not work when I type it in [Thu Mar 17 09:24:32 2016] and the reason was I imported two modules in different order [Thu Mar 17 09:24:34 2016] I mean [Thu Mar 17 09:24:46 2016] Require Import A B instead of Require Import B A [Thu Mar 17 14:53:46 2016] Cypi: or: Infix "*" := prod : type_scope. [Thu Mar 17 16:14:40 2016] rrika: i managed to prove that toy example compiler correct if you want unreadable spoilers [Fri Mar 18 02:45:14 2016] Hello, after I prove a theorem T, how can I get the proof of that T? [Fri Mar 18 02:45:29 2016] i.e., I want to get the such t that t : T. [Fri Mar 18 02:45:38 2016] theorems are just terms [Fri Mar 18 02:45:55 2016] Definition and Theorem mean the same thing [Fri Mar 18 02:46:03 2016] well, I just want to get the proof of that theorem. [Fri Mar 18 02:46:20 2016] so when you do Theorem t : , t IS the proof [Fri Mar 18 02:46:30 2016] you can even print it [Fri Mar 18 02:46:34 2016] with Print t. [Fri Mar 18 02:46:41 2016] Oh right! I forgot it, sorry. [Fri Mar 18 02:47:20 2016] its actually very interesting to look at proof terms [Fri Mar 18 02:47:41 2016] yeah, constructive proof is very amusing to look at. [Fri Mar 18 02:47:58 2016] whenever you use induction for example youll see the induction hypothesis of the type you did the induction on there as a function call [Fri Mar 18 02:48:05 2016] and etc [Fri Mar 18 02:58:39 2016] OK, another question: when I 'Check t', how to print a simplified version? [Fri Mar 18 06:21:17 2016] riaqn make a simpler proof... [Fri Mar 18 08:02:10 2016] I have a premise (a = b), where a and b are nats, and a goal S a = S b. [Fri Mar 18 08:02:20 2016] what would be the best way of dealing with this? [Fri Mar 18 08:02:27 2016] rewrite and then reflexivity? [Fri Mar 18 08:02:58 2016] I'm interested if there is a common convention for dealing with such goals [Fri Mar 18 08:48:02 2016] i do exactly that [Fri Mar 18 08:52:49 2016] jstolarek: you can use congruence, it seems [Fri Mar 18 08:53:20 2016] Lemma nat_inj { n m : nat } : n = m -> S n = S m. Proof with (intros; congruence). [Fri Mar 18 08:53:44 2016] actually, intros is not needed [Fri Mar 18 09:00:48 2016] I would [f_equal; assumption], but really, any choice is good [Fri Mar 18 12:55:42 2016] I have a lemma that says: a = n -> b = n. Based on that lemma I want to prove a = b. I feel there is an easy way of doing this but I just can't see it :-/ [Fri Mar 18 14:16:09 2016] symmetry, transitivity? [Fri Mar 18 15:59:59 2016] Hi everyone. Is there a `rational` data type in the standard library? I was thinking of defining my own - just a signed pair of naturals, representing the numerator and denomonator (where the denom. is actually `S d`, to ensure there's no division by zero) [Fri Mar 18 16:03:50 2016] athan: there is a type called "Q" in the stdlib that implements rational numbers. I haven't used it much, but you could get started by doing [Require Import QArith.] [Fri Mar 18 16:04:35 2016] i think you want Coq.QArith.QArith_base [Fri Mar 18 16:04:49 2016] https://coq.inria.fr/library/Coq.QArith.QArith_base.html [Fri Mar 18 16:06:56 2016] Oh shoot, I haven't learned positive yet. What is `xH` exactly? `1` or something? [Fri Mar 18 16:07:16 2016] dredozubov: QArith imports QArith_base and other helpful things [Fri Mar 18 16:07:16 2016] you canalso make rationals out of two integers [Fri Mar 18 16:07:18 2016] with no sign [Fri Mar 18 16:07:24 2016] since the integers carry the sign [Fri Mar 18 16:07:34 2016] sunnymilk: But it's still allows 0 as the denom. [Fri Mar 18 16:07:45 2016] oh thats true [Fri Mar 18 16:07:50 2016] I don't think that's the rational I'm looking for :\ [Fri Mar 18 16:08:12 2016] hm... so they say that `x0 (xI xH)` represnts 6... how? :s [Fri Mar 18 16:08:41 2016] oh crap, it says in the docs that xH is 1 >< sorry all, I'll keep reading [Fri Mar 18 16:09:02 2016] positive is strictly positive [Fri Mar 18 16:09:07 2016] as name implies [Fri Mar 18 16:09:47 2016] Oh crap, positive is strictly in base 2, now I understand [Fri Mar 18 16:10:06 2016] man, that seems like it would be a pain to prove over :\ [Fri Mar 18 16:22:29 2016] I've asked here before if there's a `gcd` implementation for nats, and I guess there is... but I have no idea how to import it :\ [Fri Mar 18 16:24:17 2016] athan: I don't think you need to import anything. "Nat.gcd" should just be available [Fri Mar 18 16:24:59 2016] oh wait, this is only available for Coq >= 8.5, I forgot >< [Fri Mar 18 17:29:49 2016] Is there a way to set multiple `let` statements in one? So that way I don't need to do `let ... in let ... in let ... in`? [Fri Mar 18 17:40:21 2016] In software foundations, there's advocation of equality definitions to be named in the form (for naturals) `beq_nat`, however I can't seem to find that definition. After a bit of exploring, I found some usage where the type is a paramter to `eq` - something like `eq bool b1 b2` works fine. However, `eq nat n1 n2` doesn't seem to work.. there's some term names being generated by coq that I can't really inspect ( [Fri Mar 18 17:40:27 2016] skolemized variables, maybe?) [Fri Mar 18 17:40:34 2016] Really, my question is: "How do I test equality over naturals?" :) [Fri Mar 18 17:40:56 2016] I've seen some usage of `eq-refl`, maybe I should be using that for naturals because they're such a simple structure? [Fri Mar 18 17:41:30 2016] I can show you some (really terrible) code if you'd like :) [Fri Mar 18 17:42:13 2016] http://lpaste.net/155033 [Fri Mar 18 17:47:05 2016] athan, they SF later uses a different style of equalities [Fri Mar 18 17:47:21 2016] first it's a function that takes to values and returns a boolean [Fri Mar 18 17:47:58 2016] later they formulate it using inductive propositions for which you can only get proof, if they're actually equal [Fri Mar 18 17:48:00 2016] plus an additional thing that shows that it's decidable [Fri Mar 18 17:48:15 2016] which in the end will be quite similar to the bool returning one [Fri Mar 18 17:48:19 2016] :P [Fri Mar 18 17:48:44 2016] rrika: but... but... why read when you can be impatient? :D [Fri Mar 18 17:48:52 2016] sorry, thanks rrika. [Fri Mar 18 17:49:01 2016] oops, spoiler [Fri Mar 18 17:49:01 2016] :P [Fri Mar 18 17:49:01 2016] nothing to be sorry about [Fri Mar 18 17:52:14 2016] athan, if you're at this point in SF how do you know about {| |}? [Fri Mar 18 17:54:28 2016] rrika: I'm just clawing at whatever I can grab right now [Fri Mar 18 17:54:38 2016] I'm familiar with Haskell, with all the record sytnax stuff [Fri Mar 18 17:55:24 2016] oh, I knew neither haskell nor ocaml [Fri Mar 18 17:55:27 2016] (beyond a tutorial) [Fri Mar 18 17:56:15 2016] athan, just out of curiosity, whtat do you want to use coq for? [Fri Mar 18 17:58:37 2016] rrika: Proving that robert bland's finite pivoting method for his simplex algorithm is terminating (which will be hard), and actually optimizes [Fri Mar 18 17:59:05 2016] It will also help me expand his alg. a bit, while being confident that I don't bork it's meaning [Fri Mar 18 17:59:24 2016] see this is what confuses me: https://coq.inria.fr/library/Coq.Arith.EqNat.html [Fri Mar 18 17:59:25 2016] * understood nothing really [Fri Mar 18 17:59:32 2016] eq_nat is nowhere in scope :( [Fri Mar 18 18:00:15 2016] rrika: Simplex algorithms are used for linear optimization - like a bunch of linear constraints (over Rationals) and an objective function that needs to get optimized in the feasible rejion [Fri Mar 18 18:00:19 2016] region* [Fri Mar 18 18:00:34 2016] i see [Fri Mar 18 18:00:44 2016] his algorithm "walks the corners" of the feasible region / simplex, or something like that, based on a wonky-ass method that I'm trying to prove as correct :\ [Fri Mar 18 18:01:24 2016] If I do "Import Coq.Arith.EqNat", eq_nat is in my scope. [Fri Mar 18 18:01:24 2016] uh "Require Import", not "Import" [Fri Mar 18 18:03:05 2016] aie karumba, sorry >< [Fri Mar 18 18:04:26 2016] crap, so `bool` is junk, and I should really be testing for inhabitance. Got it :) [Fri Mar 18 18:04:55 2016] it's really easy to convert though [Fri Mar 18 18:05:07 2016] (beq x y = true) [Fri Mar 18 18:05:44 2016] ^ this expression as a type [Fri Mar 18 18:06:26 2016] oh!! = is a data constructor! Awesome [Fri Mar 18 18:06:49 2016] PAJAMAS! It's working! Thank you rrika! [Fri Mar 18 18:24:48 2016] heh [Fri Mar 18 19:56:01 2016] Hi everyone. Anybody here know how to abbreviate excessive `let ... in let ... in let ... in` statements? [Fri Mar 18 19:56:38 2016] you could use functions [Fri Mar 18 19:56:44 2016] (fun a b c => ...) a b c [Fri Mar 18 19:56:54 2016] that's what let desugars into, pretty much [Fri Mar 18 19:59:59 2016] johnw: Hmm, okay! Thank you! [Fri Mar 18 20:01:30 2016] "no local fields allowed in a record construction" - what does this mean, exactly? What makes a field... local? [Fri Mar 18 20:01:43 2016] can you show me the record? [Fri Mar 18 20:02:38 2016] johnw: sure! http://lpaste.net/155046 [Fri Mar 18 20:03:00 2016] I'm getting the error on lines 19-22 :\ [Fri Mar 18 20:03:01 2016] I don't think you mean to use := in your record [Fri Mar 18 20:03:07 2016] just : [Fri Mar 18 20:03:12 2016] ? I thought that was the correct syntax [Fri Mar 18 20:03:21 2016] it is correct, but for a different purpose [Fri Mar 18 20:03:24 2016] https://coq.inria.fr/refman/Reference-Manual004.html#Record [Fri Mar 18 20:03:27 2016] it sets a "local field" [Fri Mar 18 20:03:40 2016] just s/:=/: three times and you'll be fine [Fri Mar 18 20:03:45 2016] ohhh man I'm silly, okay [Fri Mar 18 20:04:12 2016] man that's different [Fri Mar 18 20:04:34 2016] perfect! Thank you!! [Sat Mar 19 06:23:33 2016] >The term "H" has type "x <> x'" while it is expected to have type "x <> x'". [Sat Mar 19 11:53:22 2016] rrika: whoops. can you show the context which gave that error? [Sat Mar 19 11:56:23 2016] stelleg, SF redefined False and <> [Sat Mar 19 11:56:46 2016] exfalso. uses the build in false, while <> gave me SF's false [Sat Mar 19 11:58:08 2016] You can use "elimtype False" with SF's False if you want to do exactly what "exfalso" does [Sat Mar 19 11:58:45 2016] thanks for the tip [Sat Mar 19 12:00:54 2016] notations are weird [Sun Mar 20 00:31:46 2016] Does `True = True`? [Sun Mar 20 00:33:43 2016] O_O `/\` is not reflexive? [Sun Mar 20 00:34:46 2016] athan: [Check eq_refl : True = True.] [Sun Mar 20 00:35:21 2016] athan: If `/\` were reflexive, that would mean that `forall x, x /\ x`, which is certainly not the case. Perhaps you're thinking of "symmetric"? [Sun Mar 20 00:35:32 2016] How do I "augment" /\ to be reflexive from the Setoid library? [Sun Mar 20 00:35:51 2016] oh shoot you're right, sorry [Sun Mar 20 00:36:12 2016] I must be abusing fixityu [Sun Mar 20 00:37:46 2016] no I guess I'm not. How is `foo = foo /\ bar = bar` not `= True`? [Sun Mar 20 00:39:13 2016] hmm, `(True = True) = True` does not unify [Sun Mar 20 00:39:48 2016] something something intensional... [Sun Mar 20 02:28:41 2016] Anyone around that has worked through Software Foundations? I'm stuck on the very last exercise in Poly (https://www.cis.upenn.edu/~bcpierce/sf/current/Poly.html#lab141); how to define 'exp'. [Sun Mar 20 02:29:53 2016] Intuitively I understand that the algorithm must be similar to the additional algorithm, except we want to do a multiplication in the loop. [Sun Mar 20 02:30:23 2016] But it seems like the value being passed through the loop must be type X and I don't see how to multiply that with a nat. [Sun Mar 20 03:52:19 2016] Does = have a type signature? [Sun Mar 20 09:21:40 2016] Can someone help with this problem: Running make on the Makefile generated by coq does not generate .vo files [Sun Mar 20 09:23:48 2016] I want to build the following coq contributions: Algebra, Topology, ZornsLemma [Sun Mar 20 09:24:12 2016] For algebra the standard makefile suffices, but for the other two there are no .vo files generated [Sun Mar 20 12:18:11 2016] exit [Sun Mar 20 15:38:29 2016] comrades, is there any plan to overhaul the coqide to something like what Isabelle has with jEdit? [Sun Mar 20 16:01:42 2016] Hi everyone. How would you try to reduce an idempotency sub goal? I've got something like `reduce x = reduce (reduce x)` [Sun Mar 20 16:02:07 2016] I'm trying the `compute` tactic, but it's just exploding my subgoal. simpl doesn't do anything either :\ [Sun Mar 20 16:05:24 2016] Hmm... is there a way to name decomposed records? Like `destruct x as ...`? [Sun Mar 20 16:06:02 2016] apply f_equal. [Sun Mar 20 16:06:31 2016] rrika: O_O that is awesome [Sun Mar 20 16:06:32 2016] thank you! [Sun Mar 20 16:06:38 2016] [05:34:54] hmm, `(True = True) = True` does not unify [Sun Mar 20 16:06:49 2016] left side is of type "prop" right is of type "bool" [Sun Mar 20 16:07:00 2016] (a = b) is the same as (eq a b) [Sun Mar 20 16:07:04 2016] you can find out with: [Sun Mar 20 16:07:06 2016] Locate = [Sun Mar 20 16:07:08 2016] or [Sun Mar 20 16:07:11 2016] Locate "=". [Sun Mar 20 16:07:11 2016] not sure [Sun Mar 20 16:07:17 2016] thank you :) [Sun Mar 20 16:07:33 2016] the type signature of eq can be found out with "Check eq." [Sun Mar 20 16:07:40 2016] or more specifically @eq [Sun Mar 20 16:07:46 2016] (which also shows you implicit arguments) [Sun Mar 20 16:07:54 2016] rrika: And this does not work with infix operators, does it [Sun Mar 20 16:07:59 2016] hmm!! [Sun Mar 20 16:08:09 2016] are you using emacs? [Sun Mar 20 16:08:12 2016] and proof general? [Sun Mar 20 16:08:31 2016] I'm using coqide right now, just to get my head around the language [Sun Mar 20 16:08:39 2016] I don't quite want to integrate into emacs yet [Sun Mar 20 16:09:01 2016] I like emacs more than coqide [Sun Mar 20 16:09:07 2016] I was new to both [Sun Mar 20 16:09:44 2016] hmm, I don't think `apply f_equal` is sound in this case [Sun Mar 20 16:09:53 2016] I doesn't matter much, I just know the shortcut for checking notations (such as =) is ctrl+c cltr+a ctrl+n [Sun Mar 20 16:09:53 2016] because then it would just assume `x = reduce x` [Sun Mar 20 16:10:32 2016] well, do you have a proof or want to create a proof of reduce's idemoptency [Sun Mar 20 16:10:54 2016] I want to create a proof :\ [Sun Mar 20 16:11:10 2016] what is reduce exactly? [Sun Mar 20 16:11:25 2016] Is there a tactic to evaluate `f ... = f ...` in parallel? [Sun Mar 20 16:11:39 2016] rrika: It's for my own rational number, to simplify fractions [Sun Mar 20 16:12:02 2016] but specifically _only_ `f` on each side [Sun Mar 20 16:12:16 2016] f ... = f ... is your goal? [Sun Mar 20 16:12:19 2016] or in your premises? [Sun Mar 20 16:12:21 2016] hey rrika [Sun Mar 20 16:12:24 2016] hi Nik [Sun Mar 20 16:12:28 2016] rrika: It's my goal [Sun Mar 20 16:12:46 2016] actually I think I want something like `f x = f (g x)`, where I want to evaluate `g` [Sun Mar 20 16:12:48 2016] well there's "simpl" [Sun Mar 20 16:12:56 2016] "unfold g." too maybe [Sun Mar 20 16:12:56 2016] rrika: simpl does nothing :\ [Sun Mar 20 16:13:10 2016] it would if 'x' was more specific [Sun Mar 20 16:13:11 2016] hmm... the issue is that `f` and `g` are actually using the same name haha [Sun Mar 20 16:13:29 2016] so I would need to destruct `x`? [Sun Mar 20 16:13:43 2016] if that is sufficient for your proof [Sun Mar 20 16:13:55 2016] oh reduce does the fraction simplification… [Sun Mar 20 16:13:58 2016] right? [Sun Mar 20 16:14:09 2016] yes :) [Sun Mar 20 16:14:45 2016] maybe you can prove a idempotency property for gcd or whatever property you use [Sun Mar 20 16:14:47 2016] and then work from there [Sun Mar 20 16:14:57 2016] hmm... [Sun Mar 20 16:15:06 2016] rrika: Would you be willing to take a peek at my code? http://lpaste.net/155547 [Sun Mar 20 16:15:16 2016] in 45min [Sun Mar 20 16:15:43 2016] :) [Sun Mar 20 16:16:00 2016] * is watching the matrix reloaded for the first time. priorities, you see. [Sun Mar 20 16:16:12 2016] I still haven't :o [Sun Mar 20 16:39:17 2016] the matrix series is obviously a metaphor for being transgender [Sun Mar 20 16:39:36 2016] it was obvious even before both of the wachowskis came out [Sun Mar 20 16:39:37 2016] :D [Sun Mar 20 16:53:53 2016] spacekitteh, the people I watched it wanted to play "spot the indicators" [Sun Mar 20 16:53:57 2016] >* athan has quit [Sun Mar 20 16:53:59 2016] noooo [Sun Mar 20 16:54:19 2016] but I'm just too oblivious for these games [Sun Mar 20 16:58:59 2016] *the people I watched it with [Sun Mar 20 17:08:38 2016] heh [Sun Mar 20 17:09:08 2016] * laughs her ass off at the thoguht of /r/theredpill reacting to the metaphor [Sun Mar 20 17:10:18 2016] Do I want to read that reddit? [Sun Mar 20 17:10:20 2016] *subreddit [Sun Mar 20 17:11:17 2016] not unless you're into super intense misogyny and rape advice [Sun Mar 20 17:18:54 2016] rrika: Yes. [Sun Mar 20 17:45:05 2016] Help rrika, you're my only hope D: [Sun Mar 20 17:47:47 2016] Hmm, so f_equal is like a transpose over application or something [Sun Mar 20 17:54:22 2016] athan: f_equal the lemma is [x = y -> f x = f y] [Sun Mar 20 17:54:42 2016] to put it in english I would say something like "a function applied to equal arguments yields equal results" [Sun Mar 20 17:54:56 2016] or maybe "equality is a congruence for function application" [Sun Mar 20 17:55:44 2016] f_equal is also the name of a tactic which will work for functions of any number of arguments. [Sun Mar 20 17:56:21 2016] jrw: Ahh wow that makes complete sense [Sun Mar 20 17:56:57 2016] so that would also imply that if `f x = f y` and `f_equal f`, then `x = y`, correct? [Sun Mar 20 17:57:23 2016] er, I'm not really sure what you mean, but I think the answer is "no" [Sun Mar 20 17:57:40 2016] [f x = f y -> x = y] means that f is injective [Sun Mar 20 17:57:49 2016] >< sorry haha [Sun Mar 20 18:11:31 2016] is there a quick way to do multiple ex_intro? nothing's jumping out at me, and it's a bit tedious to write out apply ex_intro with (x:=...) for each one [Sun Mar 20 18:16:16 2016] stelleg: if your goal is [exists x y z, ...] you can say [exists foo, bar, baz.] to give the witnesses [Sun Mar 20 18:16:29 2016] so, "exists" is also a tactic name that does exactly what you want [Sun Mar 20 18:18:04 2016] athan [Sun Mar 20 18:18:23 2016] I guess it's helpful to show that the gcd will be one after you do reduction [Sun Mar 20 18:18:53 2016] two steps: first show that the result of reduction has a gcd of one between numerator and denominator [Sun Mar 20 18:19:06 2016] second show that reduction leaves numbers untouched if the gcd is one [Sun Mar 20 18:20:30 2016] jrw: thanks! [Sun Mar 20 18:20:45 2016] np! [Sun Mar 20 18:22:46 2016] athan, you there? [Sun Mar 20 18:26:42 2016] rrika: Yes! How was the flick? Should I have high hopes? [Sun Mar 20 18:26:54 2016] sorry, knee deep in tactics :| [Sun Mar 20 18:27:47 2016] It was about as good as the first part I guess. [Sun Mar 20 18:27:53 2016] athan, what approach are you taking? [Sun Mar 20 18:28:10 2016] also where does gcd come from, (what kinds of imports) [Sun Mar 20 18:29:16 2016] gcd comes from... Nat :| [Sun Mar 20 18:29:32 2016] I'm not exactly sure. This syntax only worked in coq >= 8.5 if that helps :s [Sun Mar 20 18:29:35 2016] oh [Sun Mar 20 18:29:40 2016] there's my problem :P [Sun Mar 20 18:29:50 2016] shoot [Sun Mar 20 18:34:08 2016] So I'm a newcomer to Coq, and I'm a bit miffed because of how it separates Type from Prop. Can someone explain the rationale to me? [Sun Mar 20 18:35:43 2016] Is it because you use tactics to instantiate members of propositions but you need to explicitly construct members of types? [Sun Mar 20 18:36:09 2016] the idea is that all values of a prop type are equal [Sun Mar 20 18:36:29 2016] rrika: but only if you accept UIP [Sun Mar 20 18:36:47 2016] rrika: no way to use Coq without UIP? [Sun Mar 20 18:38:10 2016] you can absolutely use it without UIP [Sun Mar 20 18:39:14 2016] Then I'm confused. Do you know a good read on the topic? [Sun Mar 20 18:39:29 2016] Prop in coq is used/useful for several things: 1) the extraction mechanism erases props when generating code 2) it makes it easy to add axioms in Prop and then not having to realize them. 3) Prop is impredicative. [Sun Mar 20 18:40:21 2016] so that different proofs for the same prop can exchangable [Sun Mar 20 18:40:24 2016] Isn't UIP just a consequence of proof irrelevance? [Sun Mar 20 18:40:27 2016] I had my introduction to prop/type etc. through the manual for LEAN [Sun Mar 20 18:40:48 2016] Alright. Do you know if there's a successful Coq-style proof assistant/programming language without that distinction? I heard NuPRL did [Sun Mar 20 18:41:04 2016] NuPRL is quite different from Coq for other reasons [Sun Mar 20 18:41:06 2016] Oh right LEAN [Sun Mar 20 18:41:19 2016] I'll refresh myself on that, thanks [Sun Mar 20 18:41:35 2016] I'm not super familiar with Lean, but Agda is similar and does not have this distinction [Sun Mar 20 18:42:23 2016] Thanks, I'll do some Agda then! [Sun Mar 20 18:43:28 2016] Lean has two modes, one in which there are numbered type universes and the lowest one (type_0) is also known as prop and has proof-irrelevance. [Sun Mar 20 18:43:32 2016] And one based on HoTT which I don't quite understand yet. [Sun Mar 20 18:43:57 2016] they idea is that they want to remove the special-casing of type_0 [Sun Mar 20 18:44:07 2016] *the idea [Sun Mar 20 18:44:20 2016] as far as I understand anyway [Mon Mar 21 06:06:50 2016] I have (a,b,c,d)=(f,g,h,i) as my goal and I have premises H1:a=f, H2:b=g, H3:c=h and H4:d=i. Now I can prove the goal by "rewrite H1. rewrite H2. rewrite H3. rewrite H4." but that's redious. Is there a tactic that would do it automatically? [Mon Mar 21 06:11:23 2016] jstolarek: try "subst" [Mon Mar 21 07:56:28 2016] dogui: subst does all the substitutions. It does not solve the goal, but it's much better than doing the rewrote manually [Mon Mar 21 07:56:31 2016] thanks [Mon Mar 21 07:59:36 2016] jstolarek : [congruence] will solve it automatically [Mon Mar 21 07:59:39 2016] (probably) [Mon Mar 21 08:15:09 2016] Cypi: yup, congurence works :-) [Mon Mar 21 08:15:32 2016] what if I have some premises and I want to apply somethingt to all of them [Mon Mar 21 08:15:41 2016] how do I iterate over them? [Mon Mar 21 08:16:40 2016] with simpl I can for example do "simpl in * |- *". [Mon Mar 21 08:16:46 2016] this does not seem to work for apply [Mon Mar 21 08:20:02 2016] You might have to do some Ltac scripting to achieve this. See for instance http://lpaste.net/155662 [Mon Mar 21 08:20:40 2016] Note that this is quite brutal, you have to take care yourself of problems such as termination of Ltac and so on [Mon Mar 21 08:26:48 2016] Cypi: right. I though there is a way of doing this without Ltac. [Mon Mar 21 10:54:33 2016] blargh [Mon Mar 21 10:54:41 2016] does anyone know anything about endowing implementations of the CoC with functions and types implemented in the host language without breaking the system's properties in unexpected ways? [Mon Mar 21 10:55:34 2016] i want to write a coc-driven math tool that has a 'native' numerical type so that you can do calculations and simplifications with it [Mon Mar 21 11:40:57 2016] benzrf: word you want is probably primitive, cf. https://coq.inria.fr/files/coq5_submission_2.pdf [Mon Mar 21 11:41:19 2016] benzrf: http://www.maximedenes.fr/download/coq_primitives.pdf [Mon Mar 21 11:41:55 2016] thanks! [Mon Mar 21 11:42:33 2016] np [Mon Mar 21 13:38:04 2016] (x :: fst (split (combine l1 l2)), x0 :: snd (split (combine l1 l2))) = (x :: l1, x0 :: l2) [Mon Mar 21 13:38:11 2016] this is my goal [Mon Mar 21 13:38:19 2016] and I'd like to split it into two goals: [Mon Mar 21 13:38:27 2016] fst (split (combine l1 l2)) = l1 [Mon Mar 21 13:38:33 2016] snd (split (combine l1 l2)) = l2 [Mon Mar 21 13:38:37 2016] how do I do that? [Mon Mar 21 13:39:21 2016] With some luck "f_equal" will give you that immediately [Mon Mar 21 13:39:29 2016] if not, then "f_equal; f_equal" will I guess [Mon Mar 21 13:40:53 2016] ah [Mon Mar 21 13:40:57 2016] silly me [Mon Mar 21 13:41:13 2016] I tried "apply f_equal" [Mon Mar 21 14:09:54 2016] I have a premise that says "beq_nat a a = false" [Mon Mar 21 14:09:59 2016] obviously, that is False [Mon Mar 21 14:10:12 2016] but I don't know how to convince Coq :-/ [Mon Mar 21 14:10:32 2016] I was hoping that I can somehow use beq_nat_true to rewrite to true = false and then use inversion [Mon Mar 21 14:10:39 2016] but that rewrite fails :( [Mon Mar 21 14:11:50 2016] jstolarek: maybe beq_nat_refl instead of beq_nat_true? [Mon Mar 21 14:12:13 2016] ^ [Mon Mar 21 14:13:08 2016] ah [Mon Mar 21 14:13:13 2016] >_< [Mon Mar 21 14:13:48 2016] :) [Mon Mar 21 14:13:49 2016] obviously, yes [Mon Mar 21 17:40:53 2016] so I'm in a state where I have 0 subgoals, but when I try and Qed, I get: Error: Attempt to save a proof with existential variables still non-instantiated [Mon Mar 21 17:41:18 2016] stelleg: you can do [Grab Existential Variables.] to see what's left [Mon Mar 21 17:41:36 2016] once you figure it out, I recommend going back to where that evar was introduced and solving it there [Mon Mar 21 17:41:51 2016] leaving Grab Existential Variables commands in finished proofs is bad style IMO [Mon Mar 21 17:42:11 2016] jrw: thanks, I'll try and figure out where it was introduced [Mon Mar 21 17:42:52 2016] I think I may have introduced it in a proof equality [Mon Mar 21 17:44:36 2016] maybe you or someone else has a better solution to the problem than what I came up with, which requires proof irrelevance [Mon Mar 21 17:44:45 2016] stelleg: post some code? [Mon Mar 21 17:44:59 2016] jrw: on its way [Mon Mar 21 17:47:27 2016] actually, looking back at it now I think I should just switch from using eq_nat_dec to beq_nat [Mon Mar 21 17:48:10 2016] basically have a lemma that uses proof irrelevance to show that x <> y -> eq_nat_dec x y = right p [Mon Mar 21 17:49:19 2016] but it uses proof irrelevance [Mon Mar 21 17:51:02 2016] not actually sure where the evar is being introduced [Mon Mar 21 17:51:38 2016] don't have any eapplys in my code [Mon Mar 21 17:51:58 2016] yeah, it's tempting to want that lemma, but usually it means you're doing something wrong, in my experience [Mon Mar 21 17:52:09 2016] if you show me the code I can try to point out the evar [Mon Mar 21 18:01:45 2016] http://lpaste.net/155833 [Mon Mar 21 18:01:57 2016] apologies for the paragraph-style proofs [Mon Mar 21 18:06:14 2016] stelleg: what version of coq are you using? [Mon Mar 21 18:06:29 2016] 8.4pl6 [Mon Mar 21 18:07:09 2016] okay, well I'm on 8.5 and no evar is introduced [Mon Mar 21 18:07:16 2016] let me see if I have 8.4 somewhere... [Mon Mar 21 18:08:05 2016] yeah I'd make the switch, but I'm pretty stuck in my vim ways [Mon Mar 21 18:08:12 2016] and no coquille support for 8.5 [Mon Mar 21 18:08:29 2016] :\ yeah the vim situation is quite bad [Mon Mar 21 18:08:39 2016] I have a labmate who hacked his own vim mode [Mon Mar 21 18:08:47 2016] it's pretty primitive though from what I've heard [Mon Mar 21 18:09:17 2016] okay I found an installation of 8.4 and it does produce an evar [Mon Mar 21 18:09:53 2016] stelleg: it's the [rewrite eq_nat_dec_neq] [Mon Mar 21 18:10:11 2016] jrw: yeah that's what I suspected [Mon Mar 21 18:10:39 2016] I think I'll just make the switch to beq_nat [Mon Mar 21 18:10:42 2016] should solve the issue [Mon Mar 21 18:11:00 2016] I'll let you know though [Mon Mar 21 18:11:08 2016] that sounds reasonable [Mon Mar 21 18:11:10 2016] good luck! [Mon Mar 21 18:11:22 2016] thanks for the help! [Mon Mar 21 18:14:29 2016] yep that fixed it [Mon Mar 21 18:14:53 2016] thanks again though, now I know about those hidden evars, wasn't even aware of that possiblity [Mon Mar 21 18:15:05 2016] usually they aren't that hidden :) [Mon Mar 21 18:15:15 2016] but yeah, it's annoying [Mon Mar 21 18:15:39 2016] are they just unification variables? [Mon Mar 21 18:16:49 2016] not exactly. evars are an internal detail of the coq implementation. I'm not super familiar with the specifics, but I usually think about them as just a hole to be filled in later. [Mon Mar 21 18:22:04 2016] cool thanks [Tue Mar 22 00:22:28 2016] evars are pretty useful [Tue Mar 22 00:22:34 2016] took me a while to become friendly with them though [Tue Mar 22 06:36:21 2016] invoking coqc on a source file gives me "Error: There are pending proofs" [Tue Mar 22 06:36:27 2016] I believe this is bogus [Tue Mar 22 06:36:43 2016] is there a way of asking coqc which proofs it considers still pending? [Tue Mar 22 06:54:26 2016] the simplest way that comes to mind is going through them interactively [Tue Mar 22 06:55:53 2016] but all the proofs are finished [Tue Mar 22 06:56:06 2016] that's why I said that I think the error is bogus [Tue Mar 22 06:56:51 2016] jstolarek : try "Show." [Tue Mar 22 06:56:59 2016] It should print any pending goal [Tue Mar 22 06:57:38 2016] ah, got it [Tue Mar 22 06:57:39 2016] thanks [Tue Mar 22 06:57:47 2016] indeed, I have an unfisnished proof [Tue Mar 22 06:58:25 2016] coq supports nested theorems [Tue Mar 22 06:58:28 2016] i guess it's the reason [Tue Mar 22 06:58:48 2016] you can go to the end of buffer/file interactively and still have an unfinished proof [Tue Mar 22 14:20:31 2016] I'm looking for help with ZModulo. How to write, say, the number 2 in the field Z/7 ? [Tue Mar 22 14:56:38 2016] vorgang: I've never used that file, but it looks to me like it's for reasoning modulo a power of 2 [Tue Mar 22 14:56:48 2016] see https://coq.inria.fr/distrib/current/stdlib/Coq.Numbers.Cyclic.Abstract.CyclicAxioms.html [Tue Mar 22 14:58:30 2016] I see. Well I'm looking for Z/n where n is prime [Tue Mar 22 14:59:07 2016] maybe something in theories folder? [Tue Mar 22 14:59:27 2016] otherwise I'd go with 3rd party lib [Tue Mar 22 15:00:25 2016] or write it myself, but it's probably beyond my knowledge [Tue Mar 22 16:17:54 2016] ok I guess a Record can be used for that [Tue Mar 22 17:40:40 2016] can I "apply" an hypothesis to the goal, but leave the goal is the converted form rather than solving it? [Tue Mar 22 17:40:47 2016] I guess that's what change does? [Tue Mar 22 17:42:18 2016] ah, etransitivity does what I need [Tue Mar 22 18:49:26 2016] Could Coq's Notation be (ab)used to create custom definition keywords such as Inductive, Definition, Keyword...? Or can it only transform terms? [Tue Mar 22 18:49:47 2016] Oops, Keyword had to be Fixpoint in the list of examples. [Tue Mar 22 18:51:03 2016] I don't think you can introduce new vernacular without writing OCaml [Tue Mar 22 18:52:53 2016] johnw: You sir, have just saved my master's thesis. :P [Tue Mar 22 18:53:06 2016] how did I do that?? [Tue Mar 22 18:53:38 2016] I implemented a minimal calculus of inductive constructions (Giménez style, recursive schemes) in order to build DSLs on top of it for theorem proving in specific domains. [Tue Mar 22 18:53:54 2016] miniCoq! [Tue Mar 22 18:53:57 2016] But a guy at my lab argued that I could have done it on top of Coq. [Tue Mar 22 18:54:05 2016] So that my efforts were useless. [Tue Mar 22 18:54:30 2016] so, you can't introduce new vernacular [Tue Mar 22 18:54:36 2016] But you'd need fully-blown macros for that, Notation isn't that. [Tue Mar 22 18:54:36 2016] but that doesn't mean you can't use a deep embedding [Tue Mar 22 18:54:46 2016] Well, you could have written a plugin on top of Coq, as johnw said :p [Tue Mar 22 18:54:52 2016] i.e., instead of creating a new Inductive command, using type-indexed lists to construct a representation of an inductive type [Tue Mar 22 18:55:30 2016] then you can reflect on your representation and use it for your DSL as a declared inductive type; notations make it easy to write things down in this form [Tue Mar 22 18:55:35 2016] Cypi: I can motivate my own implementation by arguing that 1) it allowed me to quickly understand the CoIC; 2) it prevented me from having to dig through Coq's implementation and understand it. [Tue Mar 22 18:55:45 2016] well, there is that [Tue Mar 22 18:55:58 2016] 2) is a strong argument :-° [Tue Mar 22 18:56:23 2016] Also: my OCaml is rusty, my Haskell (in which I implemented my language) isn't. [Tue Mar 22 18:58:10 2016] I wonder if OCaml and Haskell are easy to interoperate? [Tue Mar 22 18:58:30 2016] Cypi: Through Haskell's C FFI I guess? :P [Tue Mar 22 18:58:43 2016] Precisely, I have no idea x) [Tue Mar 22 18:59:50 2016] Maybe there would be people interested in a Haskell API to develop Coq plugins. [Tue Mar 22 19:00:08 2016] man, I sure would be [Tue Mar 22 19:00:18 2016] Well, there should be a clear OCaml API first for this to be even conceivable [Tue Mar 22 19:00:23 2016] If they haven't flocked to Agda or *gasp* Idris. [Tue Mar 22 19:00:27 2016] and this is a work-in-progress [Tue Mar 22 19:00:59 2016] we may need to write an Ocaml plugin at work, and I'm not looking forward to that [Tue Mar 22 19:01:16 2016] It takes a little getting used to, but it's not so bad after some time [Tue Mar 22 19:01:23 2016] yeah, "after some timE" [Tue Mar 22 19:01:33 2016] i've never written a line of OCaml [Tue Mar 22 19:01:37 2016] The code base is kind of a mess though, I cannot deny that :/ [Tue Mar 22 19:01:42 2016] Ah x) [Wed Mar 23 01:36:51 2016] When trying to step through Znumtheory.v in emacs proofgeneral (using C-c C-n), I get the following error on the first line (Require Import ZArith.base): [Wed Mar 23 01:36:54 2016] Error: The file coq/theories/ZArith/ZArith_base.vo contains library Coq.ZArith.ZArith_base and not library ZArith_base [Wed Mar 23 02:01:09 2016] ok got it solved, I copy the file to a diffent place (outside of coq source tree) and then it works [Wed Mar 23 02:01:21 2016] there's probably a more elegant way [Wed Mar 23 06:25:18 2016] I have premises H1 : P -> Q and H2 : Q -> R. How do I prove P -> R ? This must be trivial but I just can figure it out :-/ [Wed Mar 23 06:26:51 2016] ah, got it [Wed Mar 23 06:27:07 2016] ok, I have a more ambitious question [Wed Mar 23 06:28:02 2016] say a tactic t generates several goals, each of which can be solved (completely or up to some point) by application of tactics a, b and c. [Wed Mar 23 06:28:26 2016] in such a situation I can say: t; a; b; c. to apply tactics a, b and c to each subgoal generated by t [Wed Mar 23 06:29:19 2016] now, say that t generates several subgoals and each of these goals needs a different treatment up to a point, but then every goal can be finished by applying a, b and c. [Wed Mar 23 06:29:31 2016] I figured out I can do it using: [Wed Mar 23 06:29:47 2016] t; [ t1 | t2 | ... ]; a; b; c. [Wed Mar 23 06:29:57 2016] is that idiomatic way of doing this?> [Wed Mar 23 06:31:51 2016] If you know exactly which treatment each subgoal needs and it's not too much of a bother to write each t1, t2, ..., then yes it's fine [Wed Mar 23 06:33:03 2016] If the treatment will fail on the subgoal that are not concerned, you can do something like: t; (t1 || t2 ...); a; b; c [Wed Mar 23 06:33:43 2016] If the treatment will make the goal unsolvable on the subgoals that are not concerned, then you can do (even though it will be less efficient): t; (t1 + t2 + ...); solve [a; b; c] [Wed Mar 23 06:34:29 2016] I'm not familiar with taht last notation [Wed Mar 23 06:34:39 2016] can you poingt me to relevant section of coq's manual? [Wed Mar 23 06:35:12 2016] https://coq.inria.fr/refman/Reference-Manual011.html#hevea_tactic204 [Wed Mar 23 06:37:40 2016] thanks [Wed Mar 23 06:40:00 2016] * finds tacticals to be very subtle [Wed Mar 23 06:43:36 2016] I am reading Software Foundations and I see that whenever there is a premise H that directly proves the goal they use "apply H". [Wed Mar 23 06:43:42 2016] I wonder why not use "assumption" [Wed Mar 23 06:44:11 2016] isn't it better? It does not reuquire to explicitly name which of the premises we want to use. [Wed Mar 23 07:17:17 2016] It's a matter of style I believe, that's all [Wed Mar 23 07:17:28 2016] you could even use "easy" or "auto" to be even more abstract [Wed Mar 23 08:22:45 2016] * wonder why easy is not listed at online tactics reference [Wed Mar 23 08:22:52 2016] s/wonder/wonders/ [Wed Mar 23 08:23:57 2016] https://coq.inria.fr/library/Coq.Init.Tactics.html They say it's "experimental" apparently, so it may for this reason [Wed Mar 23 08:24:00 2016] or just an oversight [Wed Mar 23 08:24:10 2016] (there is also "now t" which is a notation for "t; easy") [Wed Mar 23 10:01:11 2016] jstolarek: even better in that case is "exact H", so that the proof breaks if it no longer solves the goal at that point [Wed Mar 23 10:51:55 2016] johnw: right. I forgot about exact [Wed Mar 23 10:52:49 2016] jstolarek: what I really like is the "by" tactical from ssreflect [Wed Mar 23 10:53:03 2016] where "by foo" is effectively solve [ foo ] [Wed Mar 23 10:53:28 2016] by closing off every goal using either exact or by, you know immediately when a proof needs updating, and more precisely where [Wed Mar 23 10:53:50 2016] and proofgeneral can even helpfully highlight the words "exact" and "by" in red, to show this role [Wed Mar 23 10:54:38 2016] and then there is Adam's approach, which I'm slowly warming to more and more [Wed Mar 23 10:55:18 2016] I'm not yet at the "single-line proof" stage that he advocates, but I include more and more automation in my proofs now, to make them adaptable [Wed Mar 23 10:55:57 2016] I'm still learning the basics [Wed Mar 23 10:56:03 2016] working my way through SF [Wed Mar 23 10:56:14 2016] sure, that's still the best beginning out there [Wed Mar 23 10:56:37 2016] but looking at how unreadable proof scripts are once they are finished I really see merit in Adam's approach [Wed Mar 23 10:56:52 2016] BTW I'm hitting more and more silliness in Coq [Wed Mar 23 10:56:58 2016] what kind of silliness? [Wed Mar 23 10:57:09 2016] I kept getting "Syntax Error: Lexer: Unterminated string" error from coqc [Wed Mar 23 10:57:19 2016] reported at the end of file [Wed Mar 23 10:57:27 2016] do you have an unclosed "? [Wed Mar 23 10:57:43 2016] after carefully scanning my file it turned out that I did [Wed Mar 23 10:57:53 2016] which would be a good enough reason to report an error [Wed Mar 23 10:58:00 2016] if the string were not in a comment! [Wed Mar 23 10:58:24 2016] but it was in a comment so everything worked with ProofGeneral but not with Coqc [Wed Mar 23 10:58:43 2016] error reporting is not Coq's strong suit [Wed Mar 23 10:58:43 2016] I have many gripes there [Wed Mar 23 10:58:43 2016] best thing to do is to report a bug: Please let me know the line/character of the unclosed terminator when reporting this error. [Wed Mar 23 10:59:03 2016] there are lots of errors in Coq that give you absolutely no clue as what to do next [Wed Mar 23 10:59:09 2016] "Cannot instantiate evar" [Wed Mar 23 10:59:13 2016] "Universe inconsistency" [Wed Mar 23 10:59:18 2016] yeah [Wed Mar 23 10:59:31 2016] "Wrong type for instantiation" [Wed Mar 23 10:59:35 2016] I guess that with some experience these are a tad bit easier to figure out [Wed Mar 23 10:59:37 2016] all without any indication of even the context of the error [Wed Mar 23 10:59:46 2016] but for a beginner these are really horrible [Wed Mar 23 10:59:57 2016] even for an expert it is like being in the 1950s [Wed Mar 23 11:00:06 2016] but I've resolved to start reporting these as bugs [Wed Mar 23 11:00:15 2016] because the compiler knows more than it's telling us [Wed Mar 23 11:00:18 2016] * is going for a lunch and than back to SF [Wed Mar 23 11:00:22 2016] does that help? [Wed Mar 23 11:00:25 2016] enjoy jstolarek [Wed Mar 23 11:00:29 2016] meaning do the bugs get fixed? [Wed Mar 23 11:00:35 2016] yes, it does help [Wed Mar 23 11:00:44 2016] the Coq crew is interested in attracted more industrial users [Wed Mar 23 11:00:45 2016] then perhaps I should start doing the same [Wed Mar 23 11:01:07 2016] some of us (Adam included) have different goals than the mathematical crowd [Wed Mar 23 11:01:17 2016] and our only voice is to raise the issues we care about loudly [Wed Mar 23 11:01:25 2016] right [Wed Mar 23 11:01:34 2016] we want performance, good debugging tools, better error reporting, etc. [Wed Mar 23 11:01:48 2016] * now really goes afk for a while [Wed Mar 23 11:55:17 2016] k [Wed Mar 23 16:56:26 2016] what's an easy way to prove that some small number, say 5 or 7, is prime? thanks [Wed Mar 23 16:57:38 2016] you can compute its prime factorization, or maybe try solve 6k +/- 1 = p for p your prime number if you know its greater than 3 [Wed Mar 23 16:57:39 2016] vorgang: like, an existing tactic or something? [Wed Mar 23 16:57:51 2016] there's prime_2 and prime_3 in Znumtheory.v but I don't fully understand the proofs and can't extend them to other numbers [Wed Mar 23 16:58:19 2016] sunnymilk: hmm what is 6k +/- 1 = p a prime thing? [Wed Mar 23 16:58:36 2016] well all primes are of that form [Wed Mar 23 16:59:33 2016] anyway I don't really care, it's just something I need for some other project. I'd be happy to just grab the code from somewhere [Wed Mar 23 16:59:55 2016] I can't believe I'm stuck on this for a day now [Wed Mar 23 17:00:11 2016] coq just won't believe me when I say 7 is prime [Wed Mar 23 17:01:06 2016] maybe its not [Wed Mar 23 17:01:20 2016] last time I checked, it was [Wed Mar 23 17:02:35 2016] "everything changes and nothing stands still" - heraclitus [Wed Mar 23 17:02:39 2016] sorry im just being silly :p [Wed Mar 23 17:02:44 2016] i think number theory is quite hard in coq [Wed Mar 23 17:03:06 2016] but this is basic stuff and someone must have done it already [Wed Mar 23 17:04:09 2016] vorgang: what if... [Wed Mar 23 17:04:12 2016] it's a bit frustrating, coming from java where you can find anything on stackoverflow instantly [Wed Mar 23 17:04:14 2016] hm shouldn't you be able to solve something like this with omega? [Wed Mar 23 17:04:29 2016] well, you could define some things like euclid's totient function, and then define prime-ness in terms of that [Wed Mar 23 17:04:31 2016] could you write a naive function that (slowly) computes the nth prime, and prove that its outputs are always prime? [Wed Mar 23 17:04:36 2016] sunnymilk: *euler? [Wed Mar 23 17:04:49 2016] the keys are right next to each other ;-; [Wed Mar 23 17:05:01 2016] but yeah then youll have a ince decidable way of telling if a specific number is prime [Wed Mar 23 17:05:07 2016] without having to worry about prime factorization or something [Wed Mar 23 17:05:11 2016] then you can just use the fact that [nth_prime 4] is prime, and just simpl out [Wed Mar 23 17:05:28 2016] benzrf youd have to prove that theres no gaps [Wed Mar 23 17:05:43 2016] why [Wed Mar 23 17:05:45 2016] eg, that it comptues only primes, and there are no primes it doesnt compute, and its in order [Wed Mar 23 17:06:03 2016] if you need [prime 7], you just do, like [Wed Mar 23 17:06:19 2016] ohh wait i dont tihnk you need that [Wed Mar 23 17:06:21 2016] uh, i dont recall the tactic, but [Wed Mar 23 17:06:37 2016] you make an assumption of [prime (nth_prime 4)] [Wed Mar 23 17:06:41 2016] and then simpl in that assumption [Wed Mar 23 17:06:59 2016] it doesn't matter if there are gaps, you just want to get [prime 7] and *you* know that nth_prime 4 is 7 [Wed Mar 23 17:07:13 2016] yeah youre rght [Wed Mar 23 17:07:47 2016] :) [Wed Mar 23 17:13:26 2016] I mean there is coqprime, if all else fails, but pocklinton certificates seem a bit overkill for this [Wed Mar 23 17:13:44 2016] coqprime? [Wed Mar 23 17:14:25 2016] http://coqprime.gforge.inria.fr/ [Wed Mar 23 17:19:19 2016] coqprime doesn't compile. woohoo [Thu Mar 24 11:13:43 2016] I have a goal that seems like it should be reducible, but neither simpl nor compute will apply the function to its arguments: http://lpaste.net/156583 [Thu Mar 24 11:15:02 2016] I would like to be doing case analysis on beq_nat ne f [Thu Mar 24 11:15:38 2016] but for some reason it won't do that application [Thu Mar 24 11:15:56 2016] compute will unfold beq_nat, and simpl will do nothing [Thu Mar 24 11:16:57 2016] any thoughts? [Thu Mar 24 11:20:47 2016] to clarify, I would like it to beta apply (fix clu ...) x ne (f..) [Thu Mar 24 11:28:15 2016] You cannot reduce an application of a fixpoint to something that is not a constructor [Thu Mar 24 11:28:25 2016] otherwise you would lose strong normalization quite easily [Thu Mar 24 11:28:35 2016] (since, you would be able to unfold a fixpoint indefinitely) [Thu Mar 24 11:29:29 2016] Cypi: thanks [Thu Mar 24 11:31:02 2016] I thought you could manually unfold when you needed to [Thu Mar 24 11:33:01 2016] but that solves my problem, thanks [Thu Mar 24 16:13:27 2016] I'm thinking of replacing my class-name parameters with a dependant pair of class-name and proof that the class exists in the class table (or is Object). [Thu Mar 24 16:13:35 2016] This has some downsides though [Thu Mar 24 16:14:39 2016] I haven't used dependant pairs much (ever) and was wondering if anyone had tried working with them extensively [Thu Mar 24 16:14:50 2016] and if there is anything I should look out for [Thu Mar 24 16:15:23 2016] I'm mostly concerned that it's going to be a pain to keep boxing and unboxing these [Thu Mar 24 16:16:22 2016] is there a way to do something to automatically project out the first part when needed? [Thu Mar 24 17:02:34 2016] yes, you can define a coercion [Thu Mar 24 17:03:29 2016] Coercion proj_sig1 : forall A P, sig A P >-> A. [Thu Mar 24 18:02:16 2016] is there a way to see what "simpl" is doing, when it takes a huge amountof time to run? [Thu Mar 24 18:06:03 2016] what's a coercion? [Thu Mar 24 18:06:29 2016] see object of type X, invisibly apply accessor to get object of type Y [Thu Mar 24 18:08:36 2016] oooh niiiice [Thu Mar 24 18:15:23 2016] boxing, however, will always require evidence [Thu Mar 24 19:00:57 2016] what do you guys think of this idea? when you type a function name the agda-mode automatically inserts holes for each of the arguments [Thu Mar 24 19:01:40 2016] how does that help Coq users? [Thu Mar 24 19:01:53 2016] oh sorry wrong channel [Thu Mar 24 19:09:00 2016] I should make a mobile game out of coq. [Thu Mar 24 19:09:02 2016] tap to apply tactics [Thu Mar 24 19:09:03 2016] $0.50 for ";" [Thu Mar 24 19:09:43 2016] sell it as "puzzle" [Thu Mar 24 19:49:00 2016] ive thought of something similar :> [Sat Mar 26 17:50:40 2016] Hello #coq! I am a cognitive/computer scientist in an abstract reasoning modeling lab, and I think my model could be used to drive Coq's interactive theorem proving capabilities to accomplish fully automated theorem proving. Is there an already existing tool for getting the proof state from Coq during the proving process? Like when it's waiting in Emacs for you to tell it "trivial"or "intros" etc [Sat Mar 26 17:52:29 2016] I figure there should already exist an API but I'm not finding it with a cursory look-over of the repo or inria site [Sat Mar 26 18:17:49 2016] im not exactly sure how it does that - look into the proof general code maybe? [Sat Mar 26 18:18:09 2016] i dont thin ktheres an "api" for it though, i think it just gets it as text output [Sat Mar 26 18:18:39 2016] eg, emacs/proof general might not know about the strucutre of a proof state any deeper than "its a blob of text" [Sat Mar 26 18:18:51 2016] but i may be completely wrong on that [Sat Mar 26 18:39:02 2016] it would be extremely nice to have an api [Sat Mar 26 19:13:22 2016] twryst: I would think you could develop something in OCaml, since it has access to the current proof tree [Sat Mar 26 19:31:43 2016] @johnw In what context? as a branch off the coq git repo? or a new plugin to coq? [Sat Mar 26 19:31:50 2016] plugin to coq [Sat Mar 26 19:32:00 2016] OCaml tactics can reflect on the current proof state [Sat Mar 26 19:32:12 2016] http://gallium.inria.fr/blog/your-first-coq-plugin/ [Sat Mar 26 19:46:46 2016] @johnw hm, so that lets me get the proof state, and I can hand it off to my model using ocaml's open_process, but what my model will be outputting is the tactic that we want coq to use [Sat Mar 26 19:47:00 2016] btw, on IRC we use "johnw: " [Sat Mar 26 19:47:06 2016] if you say @johnw, it makes me think I have my op-flag on [Sat Mar 26 19:47:24 2016] twryst: your model would need to output the replacement proof state [Sat Mar 26 19:47:43 2016] i'm not sure if you'd be able to recursively make use of tactics within such a plugin, but maybe it's possible; the coq-club mailing list would know [Sat Mar 26 19:49:49 2016] johnw: interesting, thank you. Maybe I can look at the first step of implementation of the various tactics to see if I can hand off immediately after where Coq would do string-matching? I'll ask on the mailing list, thank you for the help [Sat Mar 26 19:50:03 2016] sure, good luck! [Sat Mar 26 19:50:08 2016] I'm always interested in better automation :) [Sat Mar 26 21:23:04 2016] twryst: If you grep the Coq source code for tclTHEN (the internal equivalent of ";", the Ltac sequencing operation), you'll see how internal code calls various tactics. [Sat Mar 26 22:48:40 2016] jgross: excellent, thank you [Sun Mar 27 14:31:04 2016] hello; I'm a beginner with coq (I worked through the first chapters of "Software Foundations"), could someone point me into a direction how one uses simple sets with coq? [Sun Mar 27 14:31:32 2016] akira42: not me, sorry [Sun Mar 27 14:31:36 2016] the listings in the standard library rather confuse me [Sun Mar 27 14:32:30 2016] benzrf: well, I just want to formalize simple proofs involving set theory (I'm a beginner with general proofs, too) [Sun Mar 27 14:33:24 2016] akira42, do you have an example of something you want to prove? [Sun Mar 27 14:35:01 2016] rrika: I'm using the book "How To Prove It", so all proofs in it - for example, suppose A B C are sets, the intersection of A and C is included in B, a is a element of C, prove that a is not an element of A minus B. [Sun Mar 27 14:35:46 2016] I tried using some modules of the library found that rather confusing [Sun Mar 27 14:37:18 2016] I don't know the "proper" way, but I guess you could get there with axioms. [Sun Mar 27 14:37:46 2016] Define "intersection" and "minus" by specifying how what is included in the results of these operations [Sun Mar 27 14:38:10 2016] akira42, have you learned about inductive propositions? [Sun Mar 27 14:38:26 2016] they'll appear later in SF but will probably help you with that [Sun Mar 27 14:38:30 2016] rrika: yes, but I would rather try to avoid 'rolling my own' [Sun Mar 27 14:38:50 2016] idk, you can always turn these into aliases for some library you find later [Sun Mar 27 14:40:24 2016] mh, true [Sun Mar 27 14:40:40 2016] gonna try that - thanks [Sun Mar 27 14:40:49 2016] I mean, you'll have some kind of type, "IsIn element set" [Sun Mar 27 14:40:55 2016] oh good bye then [Sun Mar 27 15:06:47 2016] I'm trying to get into Coq lately, I hope you won't mind a few beginner questions [Sun Mar 27 15:06:52 2016] Can the apply tactic be used in an hypothesis the same way as it is used in a goal? ie if H:B->C is an hypothesis and a lemma states that A->B there a direct way to obtain A->C as an hypothesis? [Sun Mar 27 15:07:25 2016] (oh and sorry, I meant to say hello first but i forgot) [Sun Mar 27 15:07:57 2016] Hi Aelita_ [Sun Mar 27 15:07:59 2016] you could use [Sun Mar 27 15:08:13 2016] assert (A->C). [Sun Mar 27 15:08:22 2016] apply H. [Sun Mar 27 15:08:26 2016] apply a. [Sun Mar 27 15:08:32 2016] I'm wondering if there's something shorter [Sun Mar 27 15:08:44 2016] pose proof (fun a => H a). [Sun Mar 27 15:09:16 2016] Thanks! The first version is good enough for me :) [Sun Mar 27 15:09:25 2016] np, enjoy [Sun Mar 27 15:43:40 2016] Hello, I'm trying to define a finite field type Z/p where p is prime. And then also operations add, sub mult. Here's a start: http://pastebin.com/wsQmQG16 [Sun Mar 27 15:44:14 2016] sorry I don't know how to do proper sytax highlighting coq code on pastebin [Sun Mar 27 15:46:13 2016] However I'm not happy with that approach: The second argument to pf_add "comp" is a necessary compatibility condition, and this will creep into all subsequent lemmas and proofs and cause lots of work [Sun Mar 27 15:48:44 2016] I have an idea how to do it better, by defining prime_field not as a plain record but a "parameterized type". However I can't figure out the right syntax. Can someone give a hint? Thanks [Sun Mar 27 15:50:54 2016] vorgang, you don't even use comp in pf_add [Sun Mar 27 15:51:23 2016] right [Sun Mar 27 15:51:52 2016] but I use (f x) and it just wouldn't make sense if (f x) != (f y) [Sun Mar 27 15:52:03 2016] hm [Sun Mar 27 15:55:10 2016] I wanted to do something similar to Vector and define prime_field not as one Record, but a family of types, parameterized by, say, Z. [Sun Mar 27 15:55:53 2016] if you put 'f' between prime_field and ':' [Sun Mar 27 15:55:54 2016] does that work? [Sun Mar 27 15:56:11 2016] uh, let's see [Sun Mar 27 15:58:14 2016] >Definition prime := {f | prime f}. [Sun Mar 27 15:58:14 2016] >Record prime_field (f: prime) : Set := pf_make {n: Z}. [Sun Mar 27 15:58:28 2016] wait, I'm redefining the name here [Sun Mar 27 16:02:11 2016] vorgang, if you wait a bit more I can send you a snippet [Sun Mar 27 16:03:07 2016] cool, looks good to me. Now for the definition of pf_add... [Sun Mar 27 16:03:59 2016] Definition pf_add {p: prime_z} (x y : prime_field p) := [Sun Mar 27 16:04:00 2016] pf_make p ((n p x) + (n p y)). [Sun Mar 27 16:04:34 2016] you can even do [Sun Mar 27 16:04:34 2016] Definition pf_add {p: prime_z} (x y : prime_field p) := [Sun Mar 27 16:04:35 2016] pf_make p ((n _ x) + (n _ y)). [Sun Mar 27 16:06:16 2016] Neat! What kind of syntax is (n p x), or (n _ x)? [Sun Mar 27 16:07:11 2016] So far I've only used (n x) "field access" [Sun Mar 27 16:07:22 2016] it's not really any different from a function call [Sun Mar 27 16:07:32 2016] defining that record added a function n to your scope [Sun Mar 27 16:07:47 2016] that can extract that field from a value of that record-type [Sun Mar 27 16:07:54 2016] yes, but now it's taking one more argument [Sun Mar 27 16:08:05 2016] yes, that one comes from the type [Sun Mar 27 16:08:21 2016] the (f: prime) of "Record prime_field (f: prime) :" [Sun Mar 27 16:08:31 2016] not really sure why [Sun Mar 27 16:08:43 2016] tricky stuff. Thanks! [Sun Mar 27 16:08:44 2016] but since it can be inferred from the later argument you pass (namely x) you can leave a placeholder [Sun Mar 27 16:09:07 2016] Glad I asked. I would have been stuck. [Sun Mar 27 16:09:12 2016] :) [Sun Mar 27 16:10:22 2016] you could try replacing "(f: prime)" by "{f: prime}" [Sun Mar 27 16:10:31 2016] so it will be implicit where possible [Mon Mar 28 03:43:50 2016] Say I have a hypothesis H represented by an inductive data type [Mon Mar 28 03:44:05 2016] what is the difference between "induction H" and "inversion H"? [Mon Mar 28 04:55:59 2016] say I have a hypothesis "H : and b c = true" and I need to learn that this implies "b = true" and "c = true" [Mon Mar 28 04:56:26 2016] I can "apply andb_true_elim1" to get "b = true" but that also deletes the original hypothesis [Mon Mar 28 04:56:50 2016] so I no longer have "andb b c = true" on which I could apply andb_true_elim2 [Mon Mar 28 04:57:10 2016] can I make apply not remove the original goal? [Mon Mar 28 05:01:48 2016] you can make a copy with "pose proof H." [Mon Mar 28 05:01:58 2016] but even better [Mon Mar 28 05:02:03 2016] "apply andb_true_iff" [Mon Mar 28 05:02:10 2016] if I remember correctly this will give you [Mon Mar 28 05:02:14 2016] b = true /\ c = true [Mon Mar 28 05:02:45 2016] which you can split into two using destruct [Mon Mar 28 05:02:51 2016] jstolarek, ^ [Mon Mar 28 05:05:41 2016] rrika : andb_prop :-) [Mon Mar 28 05:06:13 2016] so if I want to maintain the original hypothesis then I am forced to copy it explicitly? [Mon Mar 28 05:06:43 2016] I think you can tell apply to make a copy too. [Mon Mar 28 05:08:06 2016] but how? I looked at the manual but didn't find anyting :( [Mon Mar 28 05:10:17 2016] I can't find anything either now. [Mon Mar 28 05:10:37 2016] something else you could do is [Mon Mar 28 05:10:40 2016] assert (b=true). [Mon Mar 28 05:10:50 2016] apply (andb_true_elim1 H). [Mon Mar 28 05:10:52 2016] assert (c=true). [Mon Mar 28 05:10:56 2016] apply (andb_true_elim2 H). [Mon Mar 28 05:12:08 2016] actually, just pose "proof (andb_true_elim1 H). pose proof (andb_true_elim2 H)." [Mon Mar 28 05:16:37 2016] ok [Mon Mar 28 07:58:09 2016] is there a way to do an apply and leave particular arguments as a goal? [Mon Mar 28 07:58:56 2016] for example, apply (f _ x) is telling coq to try to infer the first parameter of f, but what if I'd like to leave that as a goal? [Mon Mar 28 08:03:16 2016] refine (f _ x) if "f _ x" is the complete term [Mon Mar 28 08:04:20 2016] Cypi: oh right, thanks [Mon Mar 28 09:10:59 2016] I have a hypothesis that says "H : forall x0 : X, ..." and I have a particular x in the context. How can I apply x to H0? I want to do this to show contradiction (x is a counter-example for claim made by H0) [Mon Mar 28 09:13:41 2016] "specialize (H x)" is a way [Mon Mar 28 09:13:54 2016] If he contradiction is immediate, "inversion (H x)" could work [Mon Mar 28 09:13:56 2016] the* [Mon Mar 28 09:22:23 2016] thanks :-) [Mon Mar 28 10:22:37 2016] Hi! Could someone please tell me how to do the obvious simplification here? http://pastebin.com/SgmQ3mu2 [Mon Mar 28 10:23:09 2016] "rewrite H; simpl" [Mon Mar 28 10:23:39 2016] Thanks! [Mon Mar 28 12:24:48 2016] I'm working on a formalisation of posets, implemented as a record PO. I have a notion of lower sub poset (LowerSubPo), (i.e., a lower-closed subset) and want to show that its complement is also a poset. The catch is that the way I implemented "p is a subposet of q" is by means of there is an isomorphic image of p in q. So the natural way to implement the complement of p is via a sig where the inhabitants [Mon Mar 28 12:24:54 2016] are all of those q' in q that are not in the image of p, and q1 <= q2 iff proj1_sig q1 <= proj1_sig q2. The difficulty is anti-symmetry. Antisymmetry in q gives me that the first projections are equal, but I also need to show that the proofs are equal, which doesn't strike me as true in general. [Mon Mar 28 12:25:43 2016] I've looked at Coq.Logic.EqdepFacts, but can't seem to make much sense of it. Here's what I have so far: http://www.cs.cmu.edu/~rkavanag/pomset.v . The relevant definitions are PO, LowerSubPo, and SubPoComplement. [Mon Mar 28 12:29:33 2016] Any thoughts on how to get around this snag? I'm starting to think that I should have stuck with Coq.Sets.Partial_Order and Ensembles as carriers, instead of Types, though I'm not sure how one would encode a map of Ensembles? A map from P -> Q, where P : Ensemble U and Q : Ensemble V would be an f : U -> V s.th. forall u : U, In P u -> In Q (f u) ? [Mon Mar 28 12:41:42 2016] hi [Mon Mar 28 12:42:12 2016] what is the snag exactly? [Mon Mar 28 12:43:34 2016] does "inversion e" not give you x = y? [Mon Mar 28 13:12:44 2016] johnw: No, it just gives me a new hypothesis "H : proj1_sig x = proj1_sig y". [Mon Mar 28 13:13:55 2016] johnw: Because, I assume, forall x : { x : T | P x }, x = y <-> (proj1_sig x = proj1_sig y /\ proj2_sig x = proj2_sig y). [Mon Mar 28 13:16:14 2016] I have that the first projections are equal, but there's no reason for the second projections to be equal. I think EqdepFacts is supposed to help with this by introducing proof irrelevance. [Mon Mar 28 14:00:51 2016] try this: [Mon Mar 28 14:00:54 2016] dependent rewrite H [Mon Mar 28 14:01:01 2016] i don't think that will work, never mind [Mon Mar 28 14:01:21 2016] ah, of course, this isn't true [Mon Mar 28 14:01:32 2016] it's only true under propositional extensionality [Mon Mar 28 14:02:06 2016] that is, if the 1st parts of two sigs are the same, their related proofs are only inferrably equal by propositional extensionality [Mon Mar 28 16:45:56 2016] Hi. I've just done an induction and for a hypothesis of the form D0 := D : typ [Mon Mar 28 16:45:59 2016] what's up with that? [Mon Mar 28 16:46:07 2016] haven't seen that before and it really hard to google := [Mon Mar 28 16:51:53 2016] Hi guys [Mon Mar 28 16:52:18 2016] hi tbelaire [Mon Mar 28 16:52:22 2016] I am almost through the Software foundations coursework and was thinking about doing a small proof apart from the exercises in there [Mon Mar 28 16:52:31 2016] tbelaire: I didn't really understand your question; can you show me some code? [Mon Mar 28 16:52:36 2016] titanium17: nice [Mon Mar 28 16:52:46 2016] Is there a good starting point for something easy? Just to get my feet wet? [Mon Mar 28 16:52:56 2016] oh, you just want a general problem to solve? [Mon Mar 28 16:53:10 2016] yeah, something not too complex, and that can be proved by coq [Mon Mar 28 16:53:24 2016] are you interested in heading toward mathematics, or engineering? [Mon Mar 28 16:53:45 2016] titanium17: my favorite problem at roughly that level of difficulty is "write a compiler from a simple arithmetic expression language to a simple stack machine and prove it correct" [Mon Mar 28 16:53:47 2016] err.. engineering interests me more than pure math [Mon Mar 28 16:53:54 2016] I might offend some people with that statement [Mon Mar 28 16:53:57 2016] :E [Mon Mar 28 16:54:00 2016] then I suggest getting started with software modeling [Mon Mar 28 16:54:02 2016] for example [Mon Mar 28 16:54:12 2016] pick some language, any language, like simple math or lambda calculus [Mon Mar 28 16:54:20 2016] and build the data representation for terms of that language [Mon Mar 28 16:54:42 2016] then provide a denotation for your language into Gallina, to state what various terms mean [Mon Mar 28 16:54:56 2016] johnw: I can, but I don't have a minimal example [Mon Mar 28 16:54:58 2016] finally, write proves about things implied by your denotation, or the correctness of certain transformations [Mon Mar 28 16:55:08 2016] tbelaire: I'm not sure what you're inducting on, or what the question is... [Mon Mar 28 16:55:40 2016] So if I were to venture into something along the lines of proving that inheritance in java preserves type safety... [Mon Mar 28 16:55:51 2016] yeah. Question is, what does A := B : C mean when it shows up as a hypothesis [Mon Mar 28 16:55:52 2016] Would I be able to find some specification of Java in coq online? [Mon Mar 28 16:55:57 2016] Java? [Mon Mar 28 16:55:58 2016] titanium17: well, sure, although that's biting off a LOT [Mon Mar 28 16:55:59 2016] ooh [Mon Mar 28 16:56:00 2016] or would I have to start from scratch? [Mon Mar 28 16:56:11 2016] I've been working on Featherweight java all term [Mon Mar 28 16:56:12 2016] uh [Mon Mar 28 16:56:16 2016] not a small project [Mon Mar 28 16:56:20 2016] but [Mon Mar 28 16:56:21 2016] I started trying to model Emacs Lisp, for example [Mon Mar 28 16:56:33 2016] haha ok, I am just throwing ideas around. Sorry!! [Mon Mar 28 16:56:46 2016] github.com/tbelaire/FJ-Formalization/ [Mon Mar 28 16:56:55 2016] started from someone elses project [Mon Mar 28 16:57:01 2016] titanium17: here's what the start of it looks like: https://github.com/jwiegley/notes/blob/master/EmacsLisp.v [Mon Mar 28 16:57:33 2016] I'm having an issue right now evaluations that should result yet again in s-expressions [Mon Mar 28 16:57:36 2016] but the basic idea is similar [Mon Mar 28 16:58:08 2016] titanium17: see also this material: https://frap.csail.mit.edu/main [Mon Mar 28 16:58:15 2016] it uses SQL as the "example language" [Mon Mar 28 16:58:19 2016] but the concept is exactly the same [Mon Mar 28 16:58:33 2016] [Mon Mar 28 16:58:55 2016] if you want to do engineering in Coq, becoming familiar with Adam and his approach is a good idea anyway [Mon Mar 28 16:59:28 2016] The E-lisp looks surprisingly "comprehendable" for lack of a better word [Mon Mar 28 16:59:40 2016] comprehensible? :) [Mon Mar 28 16:59:46 2016] yeah, that :P [Mon Mar 28 17:00:29 2016] thanks peeps, I shall look at more of such stuff. Both your links are very interesting! [Mon Mar 28 17:00:58 2016] Also, would proving correctness of certain algorithms be good starting point? [Mon Mar 28 17:01:11 2016] Although I am afraid that it might involve more mathy stuff [Mon Mar 28 17:01:30 2016] sure [Mon Mar 28 17:01:36 2016] proving the correctness of a sorting algorithm is interesting [Mon Mar 28 17:01:43 2016] it involves reasoning about permutations and orders [Mon Mar 28 17:02:07 2016] Hmm, that might work. Something not too mathematical to put me off completely... [Mon Mar 28 18:42:56 2016] what happened to nat_iter? [Mon Mar 28 18:43:15 2016] hmm? [Mon Mar 28 18:46:32 2016] i have some old code that wont compile anymore since i updated [Mon Mar 28 18:46:39 2016] it complains of the nonexistence of nat_iter [Mon Mar 28 18:47:00 2016] "updated"? [Mon Mar 28 18:47:08 2016] assume I don't know what you're thinking :) [Mon Mar 28 18:47:08 2016] updated coq [Mon Mar 28 18:47:15 2016] from 8.4 to 8.5? [Mon Mar 28 18:47:18 2016] probably [Mon Mar 28 18:50:06 2016] There is a commit that says "nat_iter n f x -> nat_rect _ x (fun _ => f) n" [Mon Mar 28 18:50:28 2016] great... [Mon Mar 28 18:50:39 2016] so then where do i get nat_iter_plus [Mon Mar 28 18:51:24 2016] and there is the notation "iter_nat" [Mon Mar 28 18:51:38 2016] where? [Mon Mar 28 18:51:46 2016] also, there seems to be an "iter" function [Mon Mar 28 18:51:48 2016] In Arith.Wf_nat [Mon Mar 28 18:51:50 2016] but no iter_plus or anything :I [Mon Mar 28 18:51:55 2016] (just Arith will import it) [Mon Mar 28 18:52:20 2016] Error: The reference nat_iter was not found in the current environment. [Mon Mar 28 18:52:21 2016] There is a nat_rect_plus [Mon Mar 28 18:52:26 2016] oh! [Mon Mar 28 18:52:28 2016] ty! [Mon Mar 28 18:52:30 2016] iter_nat I said, not nat_iter :p [Mon Mar 28 18:52:36 2016] oh derp x_x [Mon Mar 28 18:52:51 2016] ok, this looks like it'll work :) [Mon Mar 28 19:45:50 2016] i have False as a goal [Mon Mar 28 19:45:56 2016] how do i move backward to 'true = false' as a goal? [Mon Mar 28 19:46:04 2016] i could do an assert, but is there something more compact? [Mon Mar 28 19:47:50 2016] yeah, one sec [Mon Mar 28 19:49:15 2016] you could: cut (true = false); [intros;discriminate|]. [Mon Mar 28 19:49:26 2016] tad long :v [Mon Mar 28 19:49:48 2016] write a helper lemma true = false -> False, and apply it [Mon Mar 28 19:49:48 2016] what does discriminate do [Mon Mar 28 19:49:52 2016] ha [Mon Mar 28 19:49:57 2016] discriminate says true = false is obviously False [Mon Mar 28 19:50:16 2016] so like a special case of inversion? [Mon Mar 28 19:50:26 2016] automatically on relevant hypothesis? [Mon Mar 28 19:50:34 2016] it uses the obvious inequality of injective constructor (functions) [Mon Mar 28 19:54:12 2016] johnw: in an ltac expression, can i use . [Tue Mar 29 00:19:04 2016] is transfinite induction not computationally sound [Tue Mar 29 10:46:36 2016] hello [Tue Mar 29 10:47:51 2016] why i can't rewrite -> "H : 0 * p = 0" in "n' * 0 = n' * 0 * p" ? [Tue Mar 29 10:55:49 2016] Ainieco: probably because '*' associates to the left? [Tue Mar 29 10:55:57 2016] So you don't actually have (0 * p) anywhere [Tue Mar 29 11:05:18 2016] dogui: doh! [Tue Mar 29 11:05:41 2016] dogui: thank you! [Tue Mar 29 11:07:22 2016] Ainieco: you're welcome! [Tue Mar 29 15:43:29 2016] is there a way to rewrite let bound variables, e.g. I have goal (reflexive_predicate t t') and hypothesis t:=t', and would like to get reflexive_predicate t' t' [Tue Mar 29 15:46:00 2016] unfold t [Tue Mar 29 15:46:44 2016] thanks! [Tue Mar 29 16:27:17 2016] isn't there some tactic that clears an equality and erases the variable on one side [Tue Mar 29 16:27:19 2016] or something [Tue Mar 29 18:50:27 2016] gah [Tue Mar 29 18:50:42 2016] why do intros, induction, and inversion all start with 'in' [Tue Mar 29 18:52:00 2016] haha [Tue Mar 29 18:52:17 2016] maybe i should just learn ssreflect already >w> [Tue Mar 29 19:48:15 2016] can the descending argument of a fixpoint have a type that's dependent on a previous argument. [Tue Mar 29 19:59:08 2016] how would that be possible? [Tue Mar 29 19:59:17 2016] your argument would need to refer to the function you're defining [Tue Mar 29 20:03:20 2016] johnw: huh? [Tue Mar 29 20:04:18 2016] show me the type you'd want to write [Tue Mar 29 20:04:41 2016] actually let me just try writing something :v [Tue Mar 29 20:08:40 2016] johnw: it works [Tue Mar 29 20:08:44 2016] kk [Tue Mar 29 20:08:51 2016] isn't that more satisfying than asking here? :) [Tue Mar 29 20:08:56 2016] it took longer :( [Tue Mar 29 20:08:58 2016] Fixpoint last (n : nat) (v : natvec n) : nat := [Tue Mar 29 20:09:03 2016] but more rewarding [Tue Mar 29 20:09:04 2016] ahh [Tue Mar 29 20:09:07 2016] *that's* what you meant [Tue Mar 29 20:20:08 2016] johnw: so can i do induction over, say, the 3rd parameter, while keeping the 1st and 2nd arguments generalized? [Tue Mar 29 20:32:55 2016] try it :) [Tue Mar 29 20:44:41 2016] i dont know how [Tue Mar 29 20:44:48 2016] induction introduces automatically i think [Tue Mar 29 21:26:19 2016] you have to intros, then generalize dependent on each of the others [Tue Mar 29 21:31:30 2016] johnw: that de-assumption-ifies the thing i want to induct over tho [Tue Mar 29 21:31:34 2016] since it dpeends [Tue Mar 29 21:31:36 2016] *depends [Tue Mar 29 21:36:27 2016] well, of course [Tue Mar 29 21:36:29 2016] there is no way around that [Tue Mar 29 21:36:34 2016] other than to reorder your arguments [Wed Mar 30 05:12:25 2016] for some reason havin trouble poving multiplication assoc, sigh [Wed Mar 30 06:01:30 2016] i did, wow [Wed Mar 30 06:01:31 2016] i did it( [Wed Mar 30 06:01:36 2016] i did it* [Wed Mar 30 06:02:37 2016] gj [Wed Mar 30 06:04:02 2016] rrika: thanks [Wed Mar 30 06:50:36 2016] how do you make foralls/arrows/etc unicode in proof general? [Wed Mar 30 06:54:36 2016] Ainieco, Menu "Proof-General" → "Quick Options" → "Display" → "Unicode Tokens" [Wed Mar 30 06:55:51 2016] rrika: thank you, for some reason it displays weird char on the end of each line, is this a known thing? [Wed Mar 30 06:56:09 2016] I don't see that [Wed Mar 30 06:56:26 2016] only when you turn it on, or always? [Wed Mar 30 06:56:33 2016] Can you make a screenshot? [Wed Mar 30 06:57:03 2016] rrika: only when i turn it on(proof-unicode-tokens-toggle) [Wed Mar 30 06:57:11 2016] rrika: sure, one sec [Wed Mar 30 07:00:08 2016] rrika: https://i.imgur.com/89cuTzG.png [Wed Mar 30 07:01:11 2016] I've never seen this symbol before [Wed Mar 30 07:01:34 2016] yeah, me too [Wed Mar 30 11:40:02 2016] so I'm starting to have some issues with switching between Prop and Type/Set contexts, generally getting errors about not being able to do case analysis on sort Type (or Set) for inductive propositions, any general suggestions for how to avoid these? [Wed Mar 30 11:41:56 2016] I've already invested fairly heavily in a few inductive propositions, and would rather not have to rewrite all of them to be of type Type, as some of them, e.g. `In` are in the prelude [Wed Mar 30 11:47:09 2016] hi stelleg [Wed Mar 30 11:47:45 2016] it's fairly easy to avoid Prop/Set collision, it's often a matter of separation at the right places [Wed Mar 30 11:48:08 2016] where exactly are you experiencing these issues? While defining functions, or while defining types? [Wed Mar 30 11:50:00 2016] johnw: for example, something like In a (domain xs) -> exists x, lookup a xs = x [Wed Mar 30 11:50:19 2016] thats fine [Wed Mar 30 11:50:22 2016] defining that type, or that function? [Wed Mar 30 11:50:59 2016] so I can write that as a lemma just fine, but if I want to use that lemma to define a total lookup function I'm not sure how to [Wed Mar 30 11:51:11 2016] sorry that should be exists x, lookup a xs = Some x [Wed Mar 30 11:51:35 2016] right, you can only use a lemma of that type within another propositional context, where you are discharging a proof burden [Wed Mar 30 11:51:46 2016] right [Wed Mar 30 11:51:48 2016] you cannot use it to determine what the "x" actually is in a computable context [Wed Mar 30 11:52:01 2016] however, you *could* do that by stating: [Wed Mar 30 11:52:12 2016] In a (domain xs) -> { x | lookup a xs = x } [Wed Mar 30 11:52:17 2016] such a function is usable in Set [Wed Mar 30 11:52:37 2016] true, but I struggled to write that function for the same reason [Wed Mar 30 11:53:07 2016] that mean that while writing such a function, you attempt to derive your answer from a propositional value [Wed Mar 30 11:53:37 2016] I'll take another swing at it [Wed Mar 30 11:53:47 2016] if you can show me that function, I can tell you why it failed exactly [Wed Mar 30 11:54:18 2016] thanks, I'll take another look at it and post it shortly [Wed Mar 30 12:02:43 2016] here's the basic issue: http://lpaste.net/157662 [Wed Mar 30 12:03:17 2016] you write all your proofs on one line? :) [Wed Mar 30 12:03:23 2016] sorry :( [Wed Mar 30 12:03:36 2016] hey, more power to you [Wed Mar 30 12:03:38 2016] i'd get lost [Wed Mar 30 12:03:47 2016] ah, right [Wed Mar 30 12:04:05 2016] yeah I don [Wed Mar 30 12:04:23 2016] 't get much from reading nicely indented proofs [Wed Mar 30 12:04:38 2016] I think I'm not clever enough, I get much more stepping through the steps [Wed Mar 30 12:04:50 2016] seeing how the goals change [Wed Mar 30 12:06:36 2016] so that fails on destruct H, because In is a fixpoint proposition, which in the case of a cons simplifies to an Or, which we can't destruct in sort Type [Wed Mar 30 12:06:47 2016] and I'm not sure how to get around that [Wed Mar 30 12:06:53 2016] trying no [Wed Mar 30 12:06:53 2016] w [Wed Mar 30 12:13:57 2016] stelleg: https://gist.github.com/8b8a705280a80dbcc6aadd845e0b6e6e [Wed Mar 30 12:14:21 2016] the idea here is to move the propositional work out into its own helper lemma [Wed Mar 30 12:14:26 2016] but maybe I can do it within still [Wed Mar 30 12:15:04 2016] johnw: cool, thanks! [Wed Mar 30 12:15:16 2016] i've updated the gist [Wed Mar 30 12:15:21 2016] so [Wed Mar 30 12:15:29 2016] lines 13-17 are in a propositional context [Wed Mar 30 12:15:38 2016] line 4-12 are in a non-propositional context [Wed Mar 30 12:16:02 2016] "intuition" is destructing the \/ and automatically solving the right branch [Wed Mar 30 12:16:11 2016] but you should be able to destruct H there too [Wed Mar 30 12:16:18 2016] yes, indeed you can [Wed Mar 30 12:16:34 2016] so your only problem is that you were trying to destruct it *before* applying the induction hypothesis [Wed Mar 30 12:16:46 2016] when you can only destruct it *after*, to satisfy the hypothesis' antecedents [Wed Mar 30 12:16:54 2016] ahhh [Wed Mar 30 12:16:57 2016] that makes sense [Wed Mar 30 12:17:13 2016] because then you're not in sort Type anymore [Wed Mar 30 12:17:16 2016] exactly [Wed Mar 30 12:17:24 2016] great, thanks a lot johnw [Wed Mar 30 12:17:27 2016] when put in a position that you need to provide *evidence*, you're in Prop [Wed Mar 30 12:17:41 2016] when you're in a position that you need to provide *implementation* of a procedure, you're in Set/Type [Wed Mar 30 12:18:04 2016] gotcha [Wed Mar 30 12:18:13 2016] very helpful, thanks [Wed Mar 30 12:18:26 2016] as another example: if you ever find yourself caring what the proof term looks like (as in, how did it implement foo : option a?, by picking None?), you're clearly thinking in Set [Wed Mar 30 12:18:39 2016] but if you really don't care at all, and might even "abstract" it away to save memory, that's clearly in Prop [Wed Mar 30 12:19:36 2016] stelleg: since I use Coq for engineering, and not math, I deal with Prop vs. Set continually :) [Wed Mar 30 12:19:44 2016] it has a huge impact on the performance of extracted code [Wed Mar 30 12:25:00 2016] johnw: yeah I bet [Wed Mar 30 12:25:19 2016] also I didn't know about that destruct _ eqn:Heqe, that's really great [Wed Mar 30 12:25:24 2016] just the other day I had to change several uses of {P}+{~P} to just "bool", because it was extracting more information than I needed [Wed Mar 30 12:25:48 2016] johnw: I actually did the exact same [Wed Mar 30 12:25:52 2016] yes, eqn:Heqe is useful when the value you're destructing yields no evidence of its own [Wed Mar 30 12:26:19 2016] destruct (b : bool) eqn:Heqe is the same as destruct (p : {b = true} + {b = false})) [Wed Mar 30 12:27:25 2016] right, I've been going in a roundabout way by using destruct (eq_nat_dec n m), then beq_refl etc [Wed Mar 30 12:27:32 2016] which is much slower [Wed Mar 30 12:27:54 2016] where eq_nat_dec : {n = m} + {n <> m} [Wed Mar 30 12:28:08 2016] so thanks agian [Wed Mar 30 12:29:29 2016] ahh, right [Wed Mar 30 12:29:46 2016] without eqn: you'd need to always use decidability lemmas that present you with the evidence [Wed Mar 30 12:29:53 2016] which is probably how it's implemented [Wed Mar 30 13:12:00 2016] learned a new tactic form today: [Wed Mar 30 13:12:02 2016] remember (origRep _) as L in * at 1. [Wed Mar 30 13:12:13 2016] the "in * at 1" is called a "goal occurrence" [Wed Mar 30 16:29:10 2016] if I have a term which satisfies the goal, how do I apply that term without "yet" satisfying the goal, because I want to rewrite the shape of the term before finally allowing it through [Wed Mar 30 16:30:06 2016] I have the term already defined, but I want to massage it before accepting it as the answer to my definition [Wed Mar 30 16:30:44 2016] I've tried pose, pose proof, set, evar, but none of them give me the exact control I'm looking for (or at least, I'm using them incorrectly if they should be) [Wed Mar 30 16:33:22 2016] refine is the most control youn can have [Wed Mar 30 16:33:36 2016] Would it be easy to give a more precise example? [Wed Mar 30 16:33:48 2016] actually, I found my answer! [Wed Mar 30 16:33:53 2016] Ah, nice :) [Wed Mar 30 16:33:54 2016] funny how asking does that [Wed Mar 30 16:33:57 2016] here's the solution: [Wed Mar 30 16:34:05 2016] let term := OLD_TERM in [Wed Mar 30 16:34:21 2016] assert { term' : & term = term' }. [Wed Mar 30 16:34:35 2016] exact (projT1 H). [Wed Mar 30 16:34:43 2016] I'm hoping it retains my rewrites because I'm in Set. [Wed Mar 30 16:36:22 2016] yay, indeed it did [Wed Mar 30 16:36:38 2016] I'll just Ltac this now [Wed Mar 30 16:39:56 2016] Ltac adjust term := [Wed Mar 30 16:39:57 2016] let T := constr:term in [Wed Mar 30 16:39:57 2016] assert { T' : _ & T = T'} as T'; [eexists| apply (projT1 T')]. [Wed Mar 30 16:40:01 2016] that works nicely, should anyone else need to do this [Wed Mar 30 16:40:36 2016] the new goal becomes an equality of term with an existential, which you finish after rewriting with just "reflexivity" [Wed Mar 30 16:57:33 2016] is "" coq syntax or did you literally type the type? [Wed Mar 30 16:57:47 2016] 8.5 has a way to determine the type, but I just literally typed the type [Wed Mar 30 16:57:52 2016] however, _ is sufficient [Wed Mar 30 19:33:37 2016] is there a way to prevent the extraction of certain terms, when recursively extracting? [Thu Mar 31 12:05:02 2016] is there a way to generalize everything execept a term and what it's dependent on? [Thu Mar 31 12:05:18 2016] like the opposite of generalize dependent [Thu Mar 31 12:05:32 2016] would be useful for some induction cases [Thu Mar 31 12:30:01 2016] stelleg: something like this maybe? https://github.com/wilcoxjay/tactics/blob/master/JRWTactics.v#L316-L327 [Thu Mar 31 12:30:09 2016] see also [prep_induction] below it [Thu Mar 31 12:32:21 2016] jrw: awesome, I'll try that out. Thanks! [Thu Mar 31 14:21:04 2016] the dimension of force is ML/TT [Thu Mar 31 14:21:16 2016] more proof that type theory is what unites all things [Thu Mar 31 14:21:18 2016] :] [Fri Apr 1 05:18:39 2016] I have a theorem in Nat namespace. When I want to apply it I say "apply Nat." and at that moment ProofGeneral complains that Nat is not a visible reference (because I typed in a dot). [Fri Apr 1 05:18:46 2016] is there a workaround? [Fri Apr 1 12:31:24 2016] jrw: thanks for the pointer to your tactics, the prep_induction tactic has been great [Fri Apr 1 12:33:52 2016] * feels increasing pressure to give in and learn Ltac [Fri Apr 1 14:41:52 2016] dash_: the way I would do that is to actually implement the function, and then prove the relation equivalent to the function. [Fri Apr 1 14:42:05 2016] is there some reason you can't implement it and need to appeal to an axiom? [Fri Apr 1 15:44:29 2016] oh boy, this is a weird one: The term "H3" has type "In n (map (fst (B:=expr.tm)) x)" while it is expected to have type "In n (map (fst (B:=expr.tm)) x)". [Fri Apr 1 15:44:50 2016] don't think there's even any Notation's in use there [Fri Apr 1 15:46:47 2016] I think I recall there's a way to print types without any pretty printing, anyone recall that? [Fri Apr 1 15:56:32 2016] jrw: yeah the relation asserts the existence of something (shortest path to be precise) which would be too complicated to implement [Fri Apr 1 15:56:54 2016] stelleg: you want [Set Printing All.] [Fri Apr 1 15:57:00 2016] jrw: thanks! [Fri Apr 1 15:58:32 2016] dash_: ah, makes sense. what did you mean above about not being able to instantiate the axiom? [Fri Apr 1 16:00:32 2016] jrw: i want to have a function delta : nat -> nat that allows me to formulate lemmas.. For example forall v, delta v <= some_approx v. [Fri Apr 1 16:01:19 2016] right [Fri Apr 1 16:01:32 2016] and the axiom gives you such a function, no? [Fri Apr 1 16:02:23 2016] right, it does, but with an existential quantification... [Fri Apr 1 16:03:01 2016] ah, okay. I guess I would just directly axiomitize the function itself then. [Fri Apr 1 16:04:42 2016] That's what i did (at least i guess...) [Fri Apr 1 16:04:55 2016] something like 'Variable delta_ok : forall v, delta_prop g v (delta v).' [Fri Apr 1 16:06:05 2016] but the downside is, that it is difficult to keep track what this all assumes... [Sun Apr 3 16:15:02 2016] How can I reason about about Equivalence over dependent types? In particular, suppose I have a "P : Type -> Type" and an "Equiv {U V} (A : P U) (B : P V) : Prop". Then I can have a proposition of type "forall U, Reflexive (P U) Equiv". However, I'm not sure how to get an analog for Symmetric: "forall U, Symmetric (P U) Equiv" limits me to a single U, while it's possible for x : P U and y : P V to be [Sun Apr 3 16:15:08 2016] equivalent under Equiv. [Sun Apr 3 16:29:02 2016] ryanakca: have you seen https://coq.inria.fr/library/Coq.Logic.EqdepFacts.html#? [Sun Apr 3 16:31:25 2016] johnw: Yes, I was trying to get that work last week for proof irrelevance with sigT and decided to abandon it and tweak some initial defitions to circumvent the issue. I don't quite understand it, but it seems to deal more with equality than equivalence. [Sun Apr 3 16:33:18 2016] that's true, it does [Sun Apr 3 16:33:34 2016] you'd need a different version of eq_dep [Sun Apr 3 16:33:39 2016] say, equiv_dep [Sun Apr 3 16:33:43 2016] to build it up on top of Equivalence [Sun Apr 3 16:37:13 2016] johnw: I see, so I'd build a theory similar to Equivalence, but using my analog of eq_dep instead? [Sun Apr 3 16:37:41 2016] I believe so [Sun Apr 3 16:37:54 2016] not everywhere in the coq stdlib do they offer both facilities [Sun Apr 3 16:38:00 2016] but sometimes they do, like f_equal and f_equiv [Sun Apr 3 17:09:04 2016] johnw: Thanks [Mon Apr 4 03:29:16 2016] I'm trying to write an Ltac procedure and I see that it is not possible to combine tactics using a dot. This makes me think that what I'm trying to do should not be done using Ltac [Mon Apr 4 03:30:20 2016] so I wonder if I should use Tactic Notation [Mon Apr 4 03:30:24 2016] jstolarek: Try using a semicolon. [Mon Apr 4 03:31:05 2016] jstolarek pasted “No title” at http://lpaste.net/158352 [Mon Apr 4 03:31:23 2016] jgross: yes, but semicolon is not always what I want or need [Mon Apr 4 03:31:30 2016] the above is my use case [Mon Apr 4 03:33:07 2016] jstolarek: try using "foo; [ bar | .. ]" [Mon Apr 4 03:35:42 2016] How about repeat "do 30 try first [ reflexivity | progress simpl | rewrite plus_0_r | progress trivial | edestruct a_optimizer | match goal with | [ n : nat |- _ ] => destruct n end ]"? [Mon Apr 4 03:37:02 2016] * needs to think about it for a longer time [Mon Apr 4 03:37:17 2016] what does "do 30 try ..." mean? [Mon Apr 4 03:47:27 2016] I am calling "destruct (a_optimizer aexpr) as [ n | a1' a2' | a1' a2' | a1' a2']" in an Ltac procedure [Mon Apr 4 03:47:42 2016] how do I ensure that the names generated by destruct are fresh? [Mon Apr 4 03:48:02 2016] I think I could use "fresh" for that but putting it in front of every variable name seems tedious [Mon Apr 4 05:09:32 2016] hello, is there a way to pattern match a type argument in coq. (match T with Type -> Type => t | Type => f end.) ? [Mon Apr 4 05:11:01 2016] hm I don't think you can do that directly [Mon Apr 4 05:11:09 2016] maybe you can use reflection? [Mon Apr 4 05:14:40 2016] * googling [Mon Apr 4 05:21:42 2016] I'm calling "destruct h" and that generates several goals for different forms of h [Mon Apr 4 05:21:55 2016] Say one form is "Foo a b" and another is "Bar c d" [Mon Apr 4 05:22:17 2016] I want to call an Ltac procedure on each such subexpression, ie: [Mon Apr 4 05:22:32 2016] my_ltac (Foo a b). my_ltac (Bar c d). [Mon Apr 4 05:22:53 2016] how can I do that without writing all subcases manually? [Mon Apr 4 05:23:35 2016] <`rks> "destruct h; my_ltac." ? [Mon Apr 4 05:30:08 2016] `rks: nope, that does not seem to work [Mon Apr 4 05:30:17 2016] hm... [Mon Apr 4 05:30:33 2016] destruct generates for cases [Mon Apr 4 05:30:35 2016] I am looking for some documentation on how the arrow (->) works on different contexts in coq, can someone help? [Mon Apr 4 05:30:55 2016] first one is a special case, which I do with a proof script, the remaining three are identical and dealt with by an Ltac procedure [Mon Apr 4 05:31:27 2016] <`rks> jstolarek: yes, "; foo" works only if "foo" applies to each subgoal [Mon Apr 4 05:31:46 2016] <`rks> have a look at the "solve" tactic jstolarek [Mon Apr 4 05:32:57 2016] ok [Mon Apr 4 05:33:09 2016] well, to be price [Mon Apr 4 05:33:18 2016] I do "destruct h; try my_ltac". [Mon Apr 4 05:33:21 2016] so that should works [Mon Apr 4 05:33:26 2016] s/works/work/ [Mon Apr 4 05:33:42 2016] <`rks> sure [Mon Apr 4 05:33:49 2016] oh, got it - I placed "try my_ltac" after incorrect destruct [Mon Apr 4 05:36:24 2016] no, for some reason doing "destruct h; my_ltac" does not work :-/ [Mon Apr 4 05:38:24 2016] drninjabatman, do you want to match your own functions or existing ones? [Mon Apr 4 05:39:30 2016] rrika: I want to make a function that given a type will find it's arity [Mon Apr 4 05:39:45 2016] rrika: eg. arity (Type -> Type) = 2 [Mon Apr 4 05:39:55 2016] rrika: eg. arity (Type) = 1 [Mon Apr 4 05:40:14 2016] `rks: perhaps an important piece of information is that in my case "Foo a b" and "Bar c d" are not the goals to be proved, but *part* of the goals (meaning, they are somewhere in a branch of a match) [Mon Apr 4 05:41:27 2016] <`rks> best of luck :) [Mon Apr 4 05:41:48 2016] drninjabatman, I think it's not possible, but I'm not sure. [Mon Apr 4 05:42:12 2016] you can only match on inductive types afaik. (where you can handle every case) [Mon Apr 4 05:42:18 2016] <`rks> jstolarek: "destruct h; my_ltac (Foo a b) || my_ltac (Bar c d)." perhaps? [Mon Apr 4 05:42:35 2016] but new types can always be created. [Mon Apr 4 05:42:43 2016] making your match not handle one case [Mon Apr 4 05:42:58 2016] rrika: can I at least prove that a function has equal arity to another function? [Mon Apr 4 05:44:56 2016] you can specify something has at least 1,2,3,… arguments [Mon Apr 4 05:45:03 2016] {A B C} (f: A→B→C) [Mon Apr 4 05:45:35 2016] ^ saying you know nothing about the argument types but 'f' takes at least two arguments [Mon Apr 4 05:46:19 2016] drninjabatman, in what context do you need it? [Mon Apr 4 05:47:29 2016] rrika: I am trying to prove that ((.).(.) ... n times ... (.).(.)) f g = \a1, .. ,aN -> f( g a1 ... aN) [Mon Apr 4 05:47:57 2016] Another problem might be that Type_i and Type_i -> Type_i could be in different universes. [Mon Apr 4 05:48:01 2016] but again, i am not sure [Mon Apr 4 05:48:37 2016] I should probably redefine (A -> B) [Mon Apr 4 05:54:30 2016] how would one go about defining a list of types? The end goal would be to define a type that would represent function signatures as lists of types so I can reason about the arity [Mon Apr 4 05:57:02 2016] I don't know if it helps, but you could define "Fixpoint arity (n : nat) : Type := match n with O => Type | S n => Type -> arity n end." so that elements of the types "arity n" are functions of arity (at least) n [Mon Apr 4 05:57:30 2016] (you will probably have some universes problems if "arity" is not defined as being universe-polymorphic) [Mon Apr 4 06:00:22 2016] Cypi: that was my initial approach. Indeed I couldn't make it work due to universe problems... [Mon Apr 4 06:01:05 2016] Cypi: I don't know what universe-polymorphic means and how to take advantage of it [Mon Apr 4 06:01:29 2016] (found a paper about it) [Mon Apr 4 07:07:04 2016] jstolarek pasted “No title” at http://lpaste.net/158424 [Mon Apr 4 07:07:09 2016] halp! [Mon Apr 4 07:07:23 2016] I'm doing some silly mistake [Mon Apr 4 07:07:42 2016] prove_aminus is my Ltac procedure [Mon Apr 4 07:08:08 2016] I can't see why the secnd version fails :-/ [Mon Apr 4 07:21:23 2016] jstolarek : maybe "prove_aminus" does some work that is not being reverted because the tactic succeeds, even though it does not solve the goal? [Mon Apr 4 07:21:42 2016] You could try with "try solve [prove_aminus a2]" instead of just "try ..." [Mon Apr 4 07:26:48 2016] ok [Mon Apr 4 17:51:45 2016] Would anyone have good resources for an intro to formal methods (model checking in particular)? [Mon Apr 4 18:08:08 2016] GLM: part of Software Foundations covers that [Tue Apr 5 03:46:50 2016] jstolarek pasted “No title” at http://lpaste.net/158600 [Tue Apr 5 03:47:55 2016] can someone tell me why this ^^^ code does not work ? [Tue Apr 5 08:14:22 2016] hello, how would existentially quantify a list on n elements? [Tue Apr 5 08:15:38 2016] is that a valid Ltac construct: match goal with | [ N : nat |- _ ] => destruct N; .... [Tue Apr 5 08:16:25 2016] meaning: is it possible to match on a nat type and will N bind hypothesis name even if the actual name is different in the environment? [Tue Apr 5 08:39:07 2016] thanks jstolarek [Tue Apr 5 09:00:28 2016] jstolarek: yes [Tue Apr 5 09:01:04 2016] but it's probably not solid [Tue Apr 5 09:03:31 2016] you may be interested in http://adam.chlipala.net/cpdt/html/Match.html [Tue Apr 5 09:05:44 2016] jun: yup, I've read CPDT :-) Ltac looks simple on paper but practice turns out to be surprisingly difficult [Wed Apr 6 07:46:18 2016] is there a way to see output of idtac inside ProofGeneral? [Wed Apr 6 09:15:43 2016] how do I gain access to Integers? [Wed Apr 6 09:16:06 2016] Coq'Art mentions Z_scope and %Z suffix but that does not seem to work [Wed Apr 6 09:21:00 2016] to be more specific [Wed Apr 6 09:21:24 2016] I want to run do tactical a numbver of times specified by the argument to an Ltac procedure [Wed Apr 6 09:21:28 2016] so for example [Wed Apr 6 09:21:44 2016] Ltac foo n := do n idtac [Wed Apr 6 09:22:00 2016] and then use "foo 2" [Wed Apr 6 09:22:17 2016] but that does not work and produces following error message: [Wed Apr 6 09:22:32 2016] Ltac variable n is bound to a term which cannot be coerced to an integer [Wed Apr 6 14:31:06 2016] Hello! [Wed Apr 6 14:31:25 2016] I have a short question about Reals from Coq standard library. [Wed Apr 6 14:31:31 2016] There is an axiom [Wed Apr 6 14:31:34 2016] Axiom total_order_T : forall r1 r2:R, {r1 < r2} + {r1 = r2} + {r1 > r2}. [Wed Apr 6 14:32:12 2016] Why is it a sumbool? Simple disjunctions are enough for all possible needs, in my opinion. [Wed Apr 6 14:32:49 2016] hi za [Wed Apr 6 14:33:06 2016] za: by simple disjunction you mean \/? [Wed Apr 6 14:33:16 2016] That is, Axiom total_order: ∀ r1 r2, r1 < r2 ∨ r1 = r2 ∨ r2 < r1. [Wed Apr 6 14:33:19 2016] Yes. [Wed Apr 6 14:33:26 2016] that would only be usable in proofs [Wed Apr 6 14:33:31 2016] not Set computations [Wed Apr 6 14:33:50 2016] Hmm... How can I compute with reals? [Wed Apr 6 14:33:58 2016] you can extract them to a similar type [Wed Apr 6 14:34:17 2016] you could, for example, state that reals are Double in Haskell, and that < maps to <, etc. [Wed Apr 6 14:34:23 2016] Ah... Now I got it. [Wed Apr 6 14:34:29 2016] of course, it would be wrong in the edge cases, but it would work for most code [Wed Apr 6 14:34:58 2016] I did this just recently, but then I switched to rationals [Wed Apr 6 14:35:14 2016] Still feels a bit wrong but I can get a motivation now. :) [Wed Apr 6 14:35:22 2016] yeah, it IS a bit wrong :) [Wed Apr 6 14:35:22 2016] Thank you! [Wed Apr 6 14:35:26 2016] sure thing [Wed Apr 6 16:55:16 2016] Le français est ok ? [Wed Apr 6 17:27:19 2016] it's OK, but many of us do not speak it [Wed Apr 6 17:27:32 2016] (but I know that several do) [Wed Apr 6 17:28:01 2016] c'est bien... mais je ne parle pas Français [Thu Apr 7 12:10:06 2016] johnw: so... coq or agda [Thu Apr 7 12:10:13 2016] EvanR: hi! [Thu Apr 7 12:10:42 2016] I would say that agda is better at just writing dependently-typed programs, and that Coq is better at working on proofs [Thu Apr 7 12:10:50 2016] however, either can do both [Thu Apr 7 12:10:58 2016] and if you develop the skill, you can get just as good in either one [Thu Apr 7 12:11:06 2016] so partly it's a matter of preference [Thu Apr 7 12:11:20 2016] in Agda, you build proof terms manually. You _can_ do that in Coq too, but the tactics are usually easier. [Thu Apr 7 12:11:32 2016] so agda doesn't have the tactics workflow [Thu Apr 7 12:11:46 2016] not yet, although I've heard it's gaining a bit of it [Thu Apr 7 12:11:57 2016] also, Agda has the equational reasoning module [Thu Apr 7 12:12:05 2016] which Coq also does, in the form of a plugin :) [Thu Apr 7 12:12:11 2016] lots of cross-pollination [Thu Apr 7 12:12:19 2016] equational reasoning module? [Thu Apr 7 12:12:21 2016] Agda seems to be more focused on type theoretical research [Thu Apr 7 12:12:30 2016] and Coq on proof and the soundness of its meta-theory [Thu Apr 7 12:13:16 2016] EvanR: foswiki.cs.uu.nl/foswiki/pub/DTP/PresentationSlides/eqreasoning.pdf [Thu Apr 7 12:14:30 2016] i don't seem to know a lot of these symbols [Thu Apr 7 12:14:37 2016] ≡ [Thu Apr 7 12:14:54 2016] usually that means "definitionally equal" [Thu Apr 7 12:15:08 2016] "i don't seem to know a lot of these symbols" <-- my experience learning Agda ;) [Thu Apr 7 12:15:28 2016] is that different from propositional equality [Thu Apr 7 12:15:56 2016] yes [Thu Apr 7 12:16:07 2016] propositionally equal terms just have to have the same type [Thu Apr 7 12:16:13 2016] they needn't have the same definition at all [Thu Apr 7 12:16:24 2016] at least, that's in Coq [Thu Apr 7 12:16:34 2016] n + 0 ≡ n [Thu Apr 7 12:16:51 2016] ah, I see [Thu Apr 7 12:16:58 2016] and there is a proof [Thu Apr 7 12:17:01 2016] you may want to ask this in #agda [Thu Apr 7 12:17:12 2016] * bouncing around like pinball [Thu Apr 7 12:18:19 2016] n + 0 and n are provably equal. but I'm not sure that means you can't recover information from the difference between ((n + 0) + 0) + 0 and n + 0 [Thu Apr 7 12:18:37 2016] although, that may not relate to propositional equality [Thu Apr 7 12:18:43 2016] when I hear that type, I think "equal in Prop" [Thu Apr 7 12:19:23 2016] what does equal in equal in Prop mean [Thu Apr 7 12:19:59 2016] actually, without additional axioms, I guess it means the same thing, now that I think about it [Thu Apr 7 12:20:26 2016] creating new "definitional equalities" out of actual definitions seems weird [Thu Apr 7 12:20:43 2016] wouldnt that lead to everything that is ever equal being definitionally equal [Thu Apr 7 12:21:09 2016] I know that 0 + n = n is a definitional equality, by the definition of plus [Thu Apr 7 12:21:15 2016] right [Thu Apr 7 12:21:19 2016] essentially, if "just unfolding" brings you to an equality [Thu Apr 7 12:21:26 2016] but n + 0 = n requires induction to prove [Thu Apr 7 12:21:34 2016] so I don't think it is a definitional equality [Thu Apr 7 12:21:51 2016] so maybe theres some slop going on ;) [Thu Apr 7 12:22:01 2016] slop in terminology? [Thu Apr 7 12:22:11 2016] i guess choosing the symbols [Thu Apr 7 12:22:39 2016] ah [Thu Apr 7 12:23:01 2016] this is a huge side track... so I guess I start on the software foundations book [Thu Apr 7 12:23:07 2016] it's quite fun [Thu Apr 7 12:23:15 2016] and the knowledge/techniques are transferrable to Agda [Thu Apr 7 12:23:19 2016] do I need emacs or an IDE [Thu Apr 7 12:23:38 2016] there is coqide, and there is using Proof General in Emacs [Thu Apr 7 12:23:42 2016] you'll need one of them [Thu Apr 7 12:52:07 2016] Dropping this proof here. [Thu Apr 7 12:52:19 2016] test [Thu Apr 7 12:53:06 2016] first row second row [Thu Apr 7 12:53:15 2016] okay, no newlines [Thu Apr 7 12:53:41 2016] zb if you want to paste longer text use a service like gist.github.com [Thu Apr 7 12:55:01 2016] https://gist.github.com/anonymous/cf7699c80474645b69823a31e67a9dc8 [Thu Apr 7 12:55:18 2016] Thank you [Thu Apr 7 13:33:40 2016] How do you fix: Not the right number of induction arguments. when defining your own induction schemes? [Thu Apr 7 13:34:55 2016] I'm not sure how to poke it to fix that. [Thu Apr 7 13:38:25 2016] I did read: http://adam.chlipala.net/cpdt/html/InductiveTypes.html [Thu Apr 7 13:39:19 2016] which is the only place I've even *seen* "induction _ using _" at all [Thu Apr 7 13:39:38 2016] but I have a slightly different thing and it's not working [Thu Apr 7 13:39:57 2016] and I'm not sure if it just need an extra argument or if it's fundamentally doomed [Thu Apr 7 13:42:26 2016] hi [Thu Apr 7 13:42:31 2016] tbelaire: can you show me your induction scheme? [Thu Apr 7 13:44:15 2016] https://gist.github.com/d4818e22da5dd0139d89ed479c73872a [Thu Apr 7 13:44:37 2016] What's going on is that there was two separate types [Thu Apr 7 13:45:04 2016] but they could be unified by passing an "envmode" parameter [Thu Apr 7 13:45:43 2016] Before, wf_stack and wf_store were two separate inductive types [Thu Apr 7 13:45:54 2016] and the type of wf_stack_ind is unchanged [Thu Apr 7 13:46:14 2016] from when wf_stack was inductively defined vs a specialization of wf [Thu Apr 7 13:46:47 2016] and if I have a proof that does "induction Wf" for some wf_stack term, I would like to be able to say [Thu Apr 7 13:46:56 2016] induction Wf using wf_stack_ind. [Thu Apr 7 13:47:05 2016] and not need to change the proof much [Thu Apr 7 13:47:16 2016] since it's actually the same theorem as before being applied [Thu Apr 7 13:47:38 2016] (if I was using `apply` instead of `induction`, there would be no change at all) [Thu Apr 7 14:03:42 2016] back [Thu Apr 7 14:03:57 2016] and how are you trying to use it? [Thu Apr 7 14:04:31 2016] also, maybe try making some of those arguments implicit [Thu Apr 7 14:38:01 2016] I updated the gist [Thu Apr 7 14:38:26 2016] before the unifications, the `refine` was just `induction` [Thu Apr 7 14:38:36 2016] Sorry I don't have a minimal example [Thu Apr 7 14:38:43 2016] so, in this line: forall (c : ctx) (s : sigma) (s0 : stack), wf env_stack c s s0 -> P c s s0. [Thu Apr 7 14:38:48 2016] what if you had: [Thu Apr 7 14:38:49 2016] How would making the arguments implicit help? [Thu Apr 7 14:38:56 2016] forall {c : ctx} {s : sigma} {s0 : stack}, wf env_stack c s s0 -> P c s s0. [Thu Apr 7 14:39:03 2016] well, I think the induction tactic is expected you to give those arguments [Thu Apr 7 14:39:08 2016] as in: induction x using (foo a b c) [Thu Apr 7 14:39:13 2016] expecting* [Thu Apr 7 14:39:17 2016] okay [Thu Apr 7 14:39:23 2016] just a guess [Thu Apr 7 14:58:50 2016] What does Error: in _: Cannot recognize an induction scheme. mean [Thu Apr 7 14:59:09 2016] Do I have to register my theorem using Scheme somehow [Thu Apr 7 14:59:11 2016] ? [Thu Apr 7 15:13:12 2016] I wouldn't have thought so [Thu Apr 7 15:13:16 2016] but at this point, you may want to ask Coq-club [Thu Apr 7 15:14:20 2016] ? [Thu Apr 7 15:14:26 2016] I don't know the answer [Thu Apr 7 15:14:27 2016] What's that? [Thu Apr 7 15:14:32 2016] the Coq mailing list [Thu Apr 7 15:14:35 2016] Ah, okay [Fri Apr 8 14:03:04 2016] What's the story with Hints inside modules? [Fri Apr 8 14:03:13 2016] Do they go away afterwards like in sections? [Fri Apr 8 14:13:39 2016] not sure, you might just need to test that [Fri Apr 8 14:16:24 2016] ah, good idea [Sat Apr 9 16:27:30 2016] Hello! [Sat Apr 9 16:27:45 2016] hello! [Sat Apr 9 16:28:07 2016] If I have proof, for example: apply xyz; [auto [Sat Apr 9 16:28:11 2016] sorry [Sat Apr 9 16:29:45 2016] So, I have joined many proof steps into one proof step. Like this: apply xyz; [auto | apply mult_comm; auto]. [Sat Apr 9 16:30:07 2016] ok [Sat Apr 9 16:30:26 2016] Btw, that is equivalent to: apply xyz; [| apply mult_comm]; auto. [Sat Apr 9 16:30:26 2016] But, for example, I want to show all steps one by one, ... is it possible without rewriting the proof. [Sat Apr 9 16:30:27 2016] ? [Sat Apr 9 16:30:40 2016] no, you cannot step through proofs once you start using ";" [Sat Apr 9 16:31:03 2016] Oh, okay. [Sat Apr 9 16:33:26 2016] Thank you! [Sat Apr 9 16:39:47 2016] just rewrite the proof. it'll cost you nothing and help everyone. [Sat Apr 9 16:40:04 2016] well, it'll cost you that code-golfing satisfaction. [Sat Apr 9 16:44:59 2016] another way to write it is this: [Sat Apr 9 16:45:02 2016] apply xyz; auto. [Sat Apr 9 16:45:05 2016] apply mult_comm; auto. [Sat Apr 9 16:45:11 2016] that gives you both simplicitly, and steppability [Sat Apr 9 16:45:21 2016] and I'm guessing you only need "trivial", not full "auto" [Sun Apr 10 20:04:27 2016] Hi guys. In Coq, how do I define an equality type? For example, if I have a type Bool with constructors true and false, and I want to define bool_equal, I want to say bool_equal b b. How do I write this down in coq? [Sun Apr 10 20:04:32 2016] Im sorry if this is really basic [Sun Apr 10 20:11:20 2016] titanium17: do you want to write it yourself or have coq generate it for you? [Sun Apr 10 20:12:05 2016] I want to write it myself [Sun Apr 10 20:12:50 2016] something like Inductive bool_equals : Type := | eq : (forall b : bool), bool_equals b b. [Sun Apr 10 20:13:08 2016] I want to know the proper syntax for this [Sun Apr 10 20:29:10 2016] anyone here? [Sun Apr 10 20:56:32 2016] Inductive bool_equals : bool -> bool -> Type := ... should work [Sun Apr 10 20:56:54 2016] jun, thanks, just figured that out! [Mon Apr 11 07:55:56 2016] starting out with the tutorial, the very first thing actually fails for me. https://coq.inria.fr/tutorial/1-basic-predicate-calculus [Mon Apr 11 07:56:23 2016] oh. no it doesn't. it actually says O no 0. so yeah. OK... [Mon Apr 11 07:56:55 2016] maybe put the warning pre-use. and maybe use a font in the warning that distinguishes 0 from O, heh. [Mon Apr 11 11:19:16 2016] Is there a way to sort my givens? [Mon Apr 11 11:19:34 2016] Even alphabetically would work [Mon Apr 11 11:19:49 2016] or by outermost constructor name [Mon Apr 11 13:16:46 2016] Whoa, I'm getting something weird [Mon Apr 11 13:16:48 2016] https://github.com/tbelaire/FJ-Formalization/blob/wip/FJ_Definitions.v#L1326 [Mon Apr 11 13:16:57 2016] When I do an induction [Mon Apr 11 13:17:25 2016] some instances of C are replaced with t1, and some are replaced with C0, and C0 := C is added to my givens [Mon Apr 11 13:17:43 2016] but I don't get that t1 = C0, or t1 = C anywhere [Mon Apr 11 13:17:49 2016] and it breaks my proof [Mon Apr 11 13:17:56 2016] anyone know what can cause that? [Mon Apr 11 13:18:28 2016] I am sorry I can't make a minimal example, but it goes away with less complex proofs for some reason [Mon Apr 11 13:29:41 2016] I have a workaround by manually applying the induction principle with refine, but that's *ugly* [Mon Apr 11 13:40:33 2016] ok, I think I know why [Mon Apr 11 13:41:26 2016] ssub__ind takes in a CT, but in this case, that is (C, (F, fs2, ms2)) :: CT, and that means that C isn't entirely eliminated from scope inside the induction [Mon Apr 11 13:41:30 2016] gah [Mon Apr 11 13:42:21 2016] tbelaire, where is your CpdtTactics from? [Mon Apr 11 13:42:43 2016] oh, you found your answer [Mon Apr 11 13:42:46 2016] well [Mon Apr 11 13:42:52 2016] I found the problem [Mon Apr 11 13:42:58 2016] I haven't found an answer [Mon Apr 11 13:43:11 2016] other than maybe trying to prove a more general induction principle??? [Mon Apr 11 13:43:19 2016] this file is longer than anything I've read before [Mon Apr 11 13:44:00 2016] pushed the ctptTactics [Mon Apr 11 13:44:08 2016] yeah, it keeps growing [Mon Apr 11 13:44:26 2016] as I have to prove obvious but not trivial things [Mon Apr 11 13:45:03 2016] like if A is a subclass of B with classtable CT, then if I add some C to the classtable that isn't A or B, then A is still a subclass of B [Mon Apr 11 13:45:12 2016] which is what I'm working on now [Mon Apr 11 13:45:37 2016] intuitively it's quite obvious [Mon Apr 11 13:45:43 2016] but it's so hard to proooooooove [Mon Apr 11 13:46:57 2016] what fs and ms? [Mon Apr 11 13:47:03 2016] fields and methods [Mon Apr 11 13:47:08 2016] oh [Mon Apr 11 13:47:09 2016] don't care about them at all right now [Mon Apr 11 13:47:19 2016] can treat them as opaque [Mon Apr 11 13:47:53 2016] So if you check sub__ind [Mon Apr 11 13:47:55 2016] ssub__ind [Mon Apr 11 13:47:57 2016] : forall (CT : ctable) (P : typ -> typ -> Prop), [Mon Apr 11 13:47:59 2016] (forall t1 t2 t3 : typ, [Mon Apr 11 13:48:01 2016] ssub_ CT t1 t2 -> P t1 t2 -> ssub_ CT t2 t3 -> P t2 t3 -> P t1 t3) -> [Mon Apr 11 13:48:03 2016] (forall t1 t2 : cname, extends_ CT t1 t2 -> P t1 t2) -> [Mon Apr 11 13:48:05 2016] forall t t0 : typ, ssub_ CT t t0 -> P t t0 [Mon Apr 11 13:48:40 2016] The problem is when t is part of CT [Mon Apr 11 13:49:07 2016] which is scoped outside of the t [Mon Apr 11 13:52:28 2016] aaaah [Mon Apr 11 13:52:33 2016] so [Mon Apr 11 13:52:37 2016] ahhh [Mon Apr 11 13:53:30 2016] I guess I need to push around the order of arguments in the definition of ssub_ [Mon Apr 11 13:54:23 2016] does that ruin everything? [Mon Apr 11 13:54:55 2016] I have no clue, I have to read more, later. [Mon Apr 11 13:55:06 2016] cya [Mon Apr 11 13:59:33 2016] yes [Mon Apr 11 13:59:43 2016] everything does break a little [Mon Apr 11 13:59:59 2016] induction generalizes over the CT expression now [Mon Apr 11 14:00:04 2016] eating my information away [Mon Apr 11 14:03:30 2016] pacman induction [Mon Apr 11 17:10:28 2016] hello, got some time again to check out coq [Mon Apr 11 17:13:16 2016] cool [Mon Apr 11 17:14:19 2016] hello benzrf [Mon Apr 11 17:18:58 2016] Nik05: nice, welcome back [Mon Apr 11 17:19:08 2016] hey johnw :) [Tue Apr 12 06:05:12 2016] Hello! [Tue Apr 12 06:05:50 2016] Why is it so difficult (for beginner) to prove, for example, that two proofs of le x y are equal? [Tue Apr 12 06:09:00 2016] because it probably is not provable in general [Tue Apr 12 06:10:26 2016] Yes, that I know. But in this case and similar ones there is only one way how to construct a proof, as I understand. [Tue Apr 12 06:14:49 2016] Anyway, looking now at the existing proof of proof irrelevance for le with hopes to learn general way of proving such things. [Tue Apr 12 12:08:53 2016] does anyone now how to install Coq documentation so that company-coq mode for Emacs sees it? [Tue Apr 12 12:49:24 2016] is there a way to specify a Scheme directly instead of having coq generate it? [Tue Apr 12 12:49:59 2016] You mean like nat_ind and such? [Tue Apr 12 12:51:19 2016] you generate a scheme from a function [Tue Apr 12 12:51:23 2016] you can write the scheme directly [Tue Apr 12 12:52:23 2016] yeah [Tue Apr 12 12:52:30 2016] so I've created a schemem using Lemma [Tue Apr 12 12:52:34 2016] rather than function [Tue Apr 12 12:52:39 2016] is that a problem? [Tue Apr 12 12:52:42 2016] no [Tue Apr 12 12:52:57 2016] okay, let me try something [Tue Apr 12 12:56:01 2016] wait, how [Tue Apr 12 12:56:12 2016] The Functional Scheme command is a high-level experimental tool for generating automatically induction principles corresponding to (possibly mutually recursive) functions. Its syntax follows the schema: [Tue Apr 12 12:56:25 2016] I don't want to generate induction principles [Tue Apr 12 12:56:29 2016] I have an induction princible [Tue Apr 12 12:56:45 2016] if you have function of the correct type, it can serve as an induction principle [Tue Apr 12 12:56:53 2016] I just want to have it registered so `induction foo using bar` [Tue Apr 12 12:56:57 2016] right [Tue Apr 12 12:57:03 2016] that only requires "bar" to have the right type [Tue Apr 12 12:58:04 2016] for example, see http://www.cs.cornell.edu/~clarkson/courses/sjtu/2014su/terse/MoreInd.html [Tue Apr 12 12:58:15 2016] okay [Tue Apr 12 12:59:14 2016] huh [Tue Apr 12 12:59:45 2016] it does work in this case [Tue Apr 12 12:59:53 2016] could have sworn it was failing [Tue Apr 12 13:00:38 2016] I have seen a bunch of: cannot identify induction scheme errors before [Tue Apr 12 13:00:42 2016] with my other one [Tue Apr 12 13:02:48 2016] what is the way "correct type" is defined? [Tue Apr 12 13:10:02 2016] https://github.com/coq/coq/blob/trunk/tactics/tactics.ml#L3162 [Tue Apr 12 13:10:08 2016] I'm assuming that this is the definition [Tue Apr 12 13:19:13 2016] cool [Tue Apr 12 13:22:39 2016] AH [Tue Apr 12 13:22:45 2016] I wish I saw that a month ago [Tue Apr 12 13:22:56 2016] I think I can get everything working if I re-order parameters [Tue Apr 12 13:23:02 2016] Is it that enlightening? [Tue Apr 12 13:23:04 2016] Ah, good :) [Tue Apr 12 13:23:13 2016] This should be in the main documentation [Tue Apr 12 13:23:15 2016] aaaahhhh [Tue Apr 12 13:23:33 2016] so much time spend with `refine (foo_ind ...).` [Tue Apr 12 13:27:48 2016] hmm [Tue Apr 12 13:28:11 2016] lets see how I need to put things for my ClassTable_ind to work... [Tue Apr 12 13:30:33 2016] I wish there was more examples for what I'm trying to do [Tue Apr 12 13:31:29 2016] which is hide the actual representation of my datastructure away, and expose a more convenient induction scheme that can do everything [Tue Apr 12 14:03:15 2016] (on phone, will be back) [Tue Apr 12 14:41:20 2016] tbelaire: hi, I'm back [Tue Apr 12 14:41:42 2016] tbelaire: so, *actual* hiding is currently impossible, unless you use module functors [Tue Apr 12 14:41:52 2016] the hiding isn't super important [Tue Apr 12 14:41:59 2016] I just want a nicer interface [Tue Apr 12 14:42:08 2016] so you're just wanting to create recursors as an alternative to pattern matching? [Tue Apr 12 14:42:10 2016] ah, I'm just trying to add in some extra error information to be printed and recompiling coq [Tue Apr 12 14:42:50 2016] oh wow, that's gangster [Tue Apr 12 14:42:54 2016] not even that, since the ClassTable I'm wrapping is just a list, I just want to induct on chains of subclassing [Tue Apr 12 14:43:05 2016] instead of the number of classes defined [Tue Apr 12 14:43:08 2016] tbelaire: and what problem are you facing now? [Tue Apr 12 14:43:11 2016] uh [Tue Apr 12 14:43:15 2016] findlib is missing [Tue Apr 12 14:43:20 2016] compiling that now [Tue Apr 12 14:43:27 2016] I use Nix to build Coq [Tue Apr 12 14:43:31 2016] hmm [Tue Apr 12 14:43:49 2016] I've been using homebrew [Tue Apr 12 14:44:01 2016] but also have a git clone locally [Tue Apr 12 14:44:04 2016] probably good enough [Tue Apr 12 14:44:09 2016] actually, can I tell homebrew to build from source [Tue Apr 12 14:44:13 2016] I have done this before [Tue Apr 12 14:44:21 2016] so I dunno why its failing now anyways [Tue Apr 12 14:46:58 2016] show me the failure? [Tue Apr 12 14:47:06 2016] or are you talking about findlib [Tue Apr 12 14:47:10 2016] about which I know nothing [Tue Apr 12 14:49:07 2016] oh [Tue Apr 12 14:49:14 2016] Error: Not the right number of induction arguments (expected 1 parameter and [Tue Apr 12 14:49:16 2016] 4 arguments). [Tue Apr 12 14:49:25 2016] ok, can you reduce it something I can evaluate here? [Tue Apr 12 14:49:27 2016] i'd like to figure this out too [Tue Apr 12 14:49:34 2016] I had to separately install coq-8.5 [Tue Apr 12 14:49:41 2016] but the vim plugin for that is brokwn [Tue Apr 12 14:49:59 2016] otherwise it doesn't even say how many parameters and arguments it expects [Tue Apr 12 14:50:23 2016] ah [Tue Apr 12 14:50:35 2016] that would be a nice patch to submit to the bug tracker [Tue Apr 12 14:50:40 2016] I really want to see improved error reporting [Tue Apr 12 14:51:06 2016] so it is a little better for coq 8.5 [Tue Apr 12 14:51:10 2016] compared to 8.4 [Tue Apr 12 14:51:23 2016] yes [Tue Apr 12 14:51:24 2016] but I would like to see more [Tue Apr 12 14:51:28 2016] but some errors are still *terrible* [Tue Apr 12 14:51:28 2016] so that's what I'm doing now [Tue Apr 12 14:51:34 2016] but I can't compile [Tue Apr 12 14:51:36 2016] ahg [Tue Apr 12 14:51:39 2016] are you at MIT? [Tue Apr 12 14:52:33 2016] UWaterloo [Tue Apr 12 14:53:54 2016] I'm an undergrad working for Ondrej https://plg.uwaterloo.ca/~olhotak/ [Tue Apr 12 14:54:15 2016] ends in a few weeks [Tue Apr 12 14:54:26 2016] what will you do after? [Tue Apr 12 14:54:51 2016] tbelaire: do you go to conferences like ICFP? [Tue Apr 12 14:55:01 2016] I have not [Tue Apr 12 14:55:09 2016] if you ever do, say hi :) [Tue Apr 12 14:55:16 2016] I won't be in Japan this year, but I try to attend every year [Tue Apr 12 14:55:35 2016] Yeah, it'd be col [Tue Apr 12 14:55:37 2016] cool [Tue Apr 12 14:55:47 2016] I might actually go to linuxcon http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp [Tue Apr 12 14:55:56 2016] as it's close and my dad's going [Tue Apr 12 14:56:05 2016] I've never gone to a Linux conf [Tue Apr 12 14:56:07 2016] I've also been working on a linux driver in Rust [Tue Apr 12 14:56:07 2016] I'm a Mac user [Tue Apr 12 14:56:26 2016] me too, [Tue Apr 12 14:56:39 2016] well, I've got the 3 OSes running [Tue Apr 12 14:56:54 2016] lappy is OSX, desktop is Linux/Windows (for games) [Tue Apr 12 14:57:16 2016] hmm? why does it seem like brew install coq --build-from-source works [Tue Apr 12 14:57:22 2016] but I can't build it myself [Tue Apr 12 14:57:31 2016] gah [Tue Apr 12 14:57:59 2016] they might be applying patches [Tue Apr 12 14:58:01 2016] or doing other funny thing [Tue Apr 12 14:58:44 2016] `brew edit coq` doesn't show anything too fancy [Tue Apr 12 14:59:22 2016] maybe the camlp5_lib dir thing [Tue Apr 12 14:59:25 2016] :q [Tue Apr 12 14:59:30 2016] oops [Tue Apr 12 15:01:30 2016] :( [Tue Apr 12 15:01:33 2016] nope [Tue Apr 12 15:14:20 2016] okay, build ocamlfind [Tue Apr 12 15:14:26 2016] and building coq now :) [Tue Apr 12 15:15:12 2016] I was considering gradschool, but this term hasn't been that much fun. [Tue Apr 12 15:15:29 2016] working with coq all day seems better in theory than in practice [Tue Apr 12 15:15:35 2016] also I miss code review [Tue Apr 12 15:16:09 2016] haha [Tue Apr 12 15:16:19 2016] I guess we all have different preferences [Tue Apr 12 15:16:40 2016] I work all day in Coq too, but I'm loving it so far; this is the type of stuff I used to spend my free time on [Tue Apr 12 15:16:57 2016] but it's definitely at a certain remove from reality [Tue Apr 12 15:17:03 2016] I'm still happy I spend a term on it [Tue Apr 12 15:17:23 2016] do you have your induction theorem in a form that I can evaluate here? [Tue Apr 12 15:18:27 2016] I didn't quite get that [Tue Apr 12 15:18:34 2016] uh [Tue Apr 12 15:18:36 2016] your induction theorem that you can't apply [Tue Apr 12 15:18:45 2016] is it in a file that I can evaluate here, to see why it doesn't work? [Tue Apr 12 15:19:04 2016] It's not very self contained [Tue Apr 12 15:19:11 2016] but one sec, I'll push to github [Tue Apr 12 15:19:57 2016] btw, https://github.com/JasonGross/coq-tools [Tue Apr 12 15:20:07 2016] can be used to reduce Coq file to a minimum reproducing example [Tue Apr 12 15:20:20 2016] by our very own jgross [Tue Apr 12 15:21:22 2016] https://github.com/tbelaire/FJ-Formalization/blob/wip/FJ_Definitions.v#L696 [Tue Apr 12 15:21:28 2016] ooh [Tue Apr 12 15:21:43 2016] johnw, that's cool [Tue Apr 12 15:21:53 2016] does it try random stuff or do dependency tracking? [Tue Apr 12 15:22:28 2016] rrika: I'm not sure exactly how it works [Tue Apr 12 15:22:37 2016] tbelaire: ok, that reproduces here, with 8.4 no less [Tue Apr 12 15:22:52 2016] yeah, I'm working on 8.4 normally [Tue Apr 12 15:23:01 2016] breaking out 8.5 because slightly more information [Tue Apr 12 15:23:48 2016] I'm just trying to re-order how the arguments are to get that to apply nicely [Tue Apr 12 15:23:51 2016] it's weird [Tue Apr 12 15:24:13 2016] should it be parametrized on both CT and C? [Tue Apr 12 15:24:28 2016] I'm not quite sure what would make `induction` happy [Tue Apr 12 15:24:42 2016] but the theorem itself is useful for a number of proofs [Tue Apr 12 15:24:42 2016] one sec [Tue Apr 12 15:29:44 2016] well, of course this cannot work! [Tue Apr 12 15:29:49 2016] you're induction over a list with a predicate on cnames [Tue Apr 12 15:29:52 2016] inducting* [Tue Apr 12 15:30:00 2016] forall C : cname, P C [Tue Apr 12 15:30:09 2016] that needs to be: [Tue Apr 12 15:30:18 2016] forall (L : list (atom * (cname * flds * mths))), P L [Tue Apr 12 15:30:20 2016] at the very least [Tue Apr 12 15:30:33 2016] tbelaire: ^ [Tue Apr 12 15:30:44 2016] ah [Tue Apr 12 15:30:52 2016] true [Tue Apr 12 15:31:29 2016] hmm [Tue Apr 12 15:32:12 2016] but I do actually want to fix a particular classtable [Tue Apr 12 15:32:30 2016] you mean, the induction only applies if X? [Tue Apr 12 15:32:31 2016] since nothing is true over all the classtables [Tue Apr 12 15:32:39 2016] hmm [Tue Apr 12 15:32:47 2016] okay, true I think [Tue Apr 12 15:32:53 2016] then maybe something of the form forall L, Q L -> P L [Tue Apr 12 15:32:54 2016] lets see how that goes [Tue Apr 12 15:33:01 2016] then you can only induct if you supply the evidence [Tue Apr 12 15:34:38 2016] what do I want this to say... [Tue Apr 12 15:37:50 2016] oh cool, my patch worked [Tue Apr 12 15:37:59 2016] coq finished compiling and it *worked* [Tue Apr 12 15:38:01 2016] nice [Tue Apr 12 15:38:25 2016] lets see if I can make it nicer [Tue Apr 12 15:38:29 2016] nice enough to upstream [Tue Apr 12 15:46:08 2016] alright, fixing that gives me [Tue Apr 12 15:46:14 2016] expeted 5 arguments got 1 [Tue Apr 12 15:46:18 2016] expected [Tue Apr 12 15:46:31 2016] (The got 1 part is the code I added [Tue Apr 12 15:46:33 2016] ) [Tue Apr 12 15:46:52 2016] lets see if I can drop the types of the arguments too [Tue Apr 12 15:46:54 2016] that would help [Tue Apr 12 15:48:08 2016] Do you know how to print types? [Tue Apr 12 15:50:55 2016] tbelaire: here's an example of your 'bug' minified: https://gist.github.com/3b1626b90beeeb1689ff942164178336 [Tue Apr 12 15:51:00 2016] tbelaire: Print . [Tue Apr 12 15:51:12 2016] from ocaml code :P [Tue Apr 12 15:51:20 2016] I know absolutely 0 about OCaml [Tue Apr 12 15:51:31 2016] aww nice [Tue Apr 12 15:51:35 2016] I like the minifier [Tue Apr 12 15:51:56 2016] okay, I'm just trying to expand the error until a normal human can read it [Tue Apr 12 15:51:58 2016] then read it [Tue Apr 12 16:04:43 2016] gah, implicit typing is dumb, I can't just search up the types [Tue Apr 12 16:15:03 2016] anyone know why there are not .annot files generated? [Tue Apr 12 16:15:13 2016] when coq is build from source? [Tue Apr 12 16:36:30 2016] alright, got ",t" to print out ocaml types! [Tue Apr 12 16:36:32 2016] nice [Tue Apr 12 16:37:55 2016] only to realize that the variable I'm looking for is called the same name in both places [Tue Apr 12 16:38:04 2016] and I don't really need to play type tetris at alll [Tue Apr 12 16:46:08 2016] rrika: The bug-minimizer (https://github.com/JasonGross/coq-tools) takes a file that produces the error, uses the .glob file that coqc outputs to get the file's dependencies, and then tries ~brute-force removal of lines, together with inlining dependencies by wrapping them in nested modules, running coqc after each change to make sure the error message hasn't changed. [Tue Apr 12 16:48:32 2016] nice [Wed Apr 13 03:57:25 2016] goodmorning [Wed Apr 13 05:55:01 2016] Do you know of a way to replace the type of a variable in the environment by something that is convertible to it? [Wed Apr 13 05:55:26 2016] Say, I know that t and u are convertible, and I have "foo : t" in my environment. I'd like to have "foo : u" instead, without modifying the proof term [Wed Apr 13 12:11:24 2016] Are there any examples using functional induction? [Wed Apr 13 12:12:13 2016] I'm just trying to use the example on [Wed Apr 13 12:12:14 2016] one [Wed Apr 13 12:12:16 2016] https://gist.github.com/f2ca462d304a2f907030f0000a996645 [Wed Apr 13 12:12:29 2016] https://coq.inria.fr/refman/Reference-Manual015.html#sec573 [Wed Apr 13 12:12:43 2016] They give an example using Scheme to define schemes [Wed Apr 13 12:12:48 2016] but not on using said scheme [Wed Apr 13 12:39:10 2016] Cypi: you want something akin to "coercion"? [Wed Apr 13 12:39:29 2016] I would imagine you just need a function t -> u, no? [Wed Apr 13 12:40:46 2016] No. I just want to do it once, and this should not have any impact on the proof-term [Wed Apr 13 12:41:18 2016] For instance, let's say I have "x : nat", and for some reason I want to have "x : (fun T => T) nat" instead [Wed Apr 13 12:42:45 2016] you can rewrite within the type [Wed Apr 13 12:43:03 2016] given a left_id law of id x = x, then rewrite <- left_id in x; unfold id in x should do that [Wed Apr 13 12:43:10 2016] If I rewrite, then it will add this rewrite to the proof-term [Wed Apr 13 12:43:25 2016] (and also, in my case, I actually have "x := t : nat", so you can't rewrite without losing 't' [Wed Apr 13 12:43:26 2016] i don't see any way around that [Wed Apr 13 12:44:00 2016] the type can't change spontaneously, as far as I know [Wed Apr 13 12:44:24 2016] The type does not change, as far as the type system is concerned, since my two types are convertible [Wed Apr 13 12:44:26 2016] you'll end up involving eq_rect [Wed Apr 13 12:44:35 2016] I have a way actually, it's just very tedious. [Wed Apr 13 12:44:43 2016] well, but they aren't the same type, are they? [Wed Apr 13 12:44:48 2016] Syntaxically, no [Wed Apr 13 12:45:05 2016] in HoTT I'd think what you're saying is directly expressible [Wed Apr 13 12:45:17 2016] It's just like using the tactic change: you change the goal, but it won't do anything to the proof-term [Wed Apr 13 12:45:43 2016] you are basically just picking another representant of the class of types beta-equivalent to your goal [Wed Apr 13 12:45:58 2016] what is your tedious solution? [Wed Apr 13 12:46:54 2016] If I want to keep 't': substituting t for x everywhere, then do "set (x := t : T) in *" where T is my new type. And then "cbv zeta in x" to remove the coercion [Wed Apr 13 12:47:08 2016] (I use 'zeta' juste because in my case, it's the least likely to reduce anything else) [Wed Apr 13 12:47:14 2016] (I haven't found "just the coercions") [Wed Apr 13 12:47:16 2016] so, "equal up to zeta equivalence"? [Wed Apr 13 12:47:36 2016] I could use "cbv iota" or whatever, it's just to reduce the coercion and nothing else [Wed Apr 13 12:48:36 2016] Hmm. Actually I guess that substituting and then using set will modify the proof term, so it doesn't answer exactly what I wanted [Wed Apr 13 12:49:34 2016] even if I use "apply (fun x : nat => x : id nat) in t", the proof term has a call to "id" in it [Wed Apr 13 12:50:23 2016] Cypi: but if I do this... https://gist.github.com/4a55b0a1dbd47eec4d84d6c4f5c113fe [Wed Apr 13 12:50:32 2016] then while Cypi has the extra id in it, Cypi' does not [Wed Apr 13 12:50:53 2016] (I don't think the cbv there is actually doing anything) [Wed Apr 13 12:51:26 2016] Alright, see this: http://lpaste.net/159701 [Wed Apr 13 12:51:46 2016] In the first lemma, using change will change what type is displayed for n, without adding anything to the proof term [Wed Apr 13 12:51:55 2016] In the second one, I can't even use change, but I would like too. [Wed Apr 13 12:53:09 2016] the apply way of doing it works in that case also [Wed Apr 13 12:53:44 2016] Except that it will lose the term t, and modify the proof term [Wed Apr 13 12:54:01 2016] (in that case, I will lose the fact that n is actually 0) [Wed Apr 13 12:54:22 2016] I don't see that being lost in the proof term [Wed Apr 13 12:54:30 2016] bar = let n := 0 in (fun _ : id nat => I) n : let n := 0 in True [Wed Apr 13 12:54:55 2016] I do lose it after Eval compute [bar], because n is never used [Wed Apr 13 12:55:23 2016] in what context is this significant for you? [Wed Apr 13 12:55:25 2016] Then let's change the goal to "n = 0" instead of "True" I guess [Wed Apr 13 12:55:58 2016] In the context of trying to understand clearer what happens in a proof involving equalities and terms with types that are way too big for me, and that I would like to reduce part by part [Wed Apr 13 12:57:02 2016] Oh wait... "change nat with (id nat)" works exactly as I'd like it [Wed Apr 13 12:57:09 2016] ah, nice [Wed Apr 13 12:57:14 2016] I guess I just need to specify the original type, which can be made easy with some Ltac. [Wed Apr 13 12:57:25 2016] Ok, I hadn't even tried this. Thanks [Wed Apr 13 12:57:36 2016] glad to have .... helped? :) you answered yourself [Wed Apr 13 12:58:01 2016] Discussing helps [Wed Apr 13 12:58:04 2016] true [Wed Apr 13 12:58:16 2016] I'm trying to build a library right now for reasoning with units in coq [Wed Apr 13 12:58:21 2016] and am a bit surprised it hasn't been done already [Wed Apr 13 12:58:40 2016] units? As in physical units? [Wed Apr 13 12:58:46 2016] I want unitized values that may only be combined in type-safe ways, where dividing meters by seconds synthesizes a new unit "meters / seconds" [Wed Apr 13 12:59:39 2016] That sounds cool. I guess there aren't many physicists that have an interest in Coq yet. [Wed Apr 13 13:00:10 2016] I'm not using it for physics, just program metrics where I want to build a DSL for specifying constraint boundaries on program behaviors [Wed Apr 13 13:00:38 2016] like "this function is unhealthy if it produces fewer than X results per second" [Wed Apr 13 13:00:59 2016] and then I'd export the DSL term to something that can be used to construct an external process that will do the measuring [Wed Apr 13 13:01:08 2016] Coq is just giving me the type-safe language to talk about these terms [Wed Apr 13 13:02:02 2016] I see [Wed Apr 13 16:33:20 2016] Where can one get a copy of coq'art? [Wed Apr 13 16:39:37 2016] <_y> reuben364, here http://www.labri.fr/perso/casteran/CoqArt/ ? [Wed Apr 13 16:39:56 2016] <_y> (found from https://coq.inria.fr/documentation) [Wed Apr 13 16:47:15 2016] thanks [Wed Apr 13 19:20:18 2016] Hi. How is one supposed to use Set Automatic Coercions Import if Require commands are supposed to be at the beginning of the file? [Wed Apr 13 19:34:37 2016] Murad: presumably you should Set the option above the Require commands [Wed Apr 13 19:37:01 2016] jrw: Yes, that's the only way it works. However, is that not at odds with the the fact that Require commands are, themselves, supposed to be above all other commands? [Wed Apr 13 19:38:13 2016] In particular, I thought the Require commands at the top were parsed in a special manner for something I don't remember. [Wed Apr 13 19:38:29 2016] Dependency discovery or something. [Wed Apr 13 19:40:36 2016] I've never had a problem with Requires not being at the very top for coqdep, but maybe you're right, you'll just have to test [Wed Apr 13 19:41:48 2016] jrw: Thanks. [Thu Apr 14 05:26:16 2016] which theorem says: forall a b, a /\ b -> a ? [Thu Apr 14 05:27:13 2016] proj1 [Thu Apr 14 05:28:59 2016] how could I figure it out if I know the theorem? [Thu Apr 14 05:29:23 2016] I don't understand the question [Thu Apr 14 05:30:06 2016] If I know what the theorem states, how can I find it's name? [Thu Apr 14 05:36:56 2016] I don't, sorry :/ [Thu Apr 14 05:59:52 2016] I have premises A and B and a constructor C of type I that takes A and B as parameters. How do I apply C to both A and B to produce a value of type I as my premise? [Thu Apr 14 06:02:19 2016] exact (C A B) [Thu Apr 14 06:02:48 2016] Ah, sorry, I is not your goal [Thu Apr 14 06:02:57 2016] then "pose proof (C A B)" [Thu Apr 14 06:03:21 2016] I think I can also do "apply (C A) in H", where H : B [Thu Apr 14 07:45:13 2016] <_y> hello! might be a newbie question: http://paste.awesom.eu/0e2K&ln [Thu Apr 14 07:46:51 2016] <_y> how do i tell coq that its automatic variable n0 is in fact what i called m? [Thu Apr 14 07:48:33 2016] <_y> actually in this example i can make the problem simply disappear by moving the parameter n out of the constructor, but i’m still interested in understanding how it works [Thu Apr 14 07:49:00 2016] <_y> i guess there are cases where you can’t do this [Thu Apr 14 07:50:16 2016] Welcome to the world of dependent types. So, n0 comes from the underscore in your pattern. Outside the match, it's obvious that n0 and m should be the same, because m is the index of 'value'. But inside the match, n0 and m are completly unrelated. [Thu Apr 14 07:54:10 2016] A way to solve this is to "convey" proof_m_lt_n inside the pattern-matching, so that it's obvious that the types are, in fact, correct. See: http://lpaste.net/159982 [Thu Apr 14 07:55:01 2016] (you actually don't need the annotations on the match, but it's just to make it clearer) [Thu Apr 14 08:37:22 2016] HelloIs there a some very easy recipe for Coq developments in one folder with subfolders? [Thu Apr 14 08:37:32 2016] * Hello! [Thu Apr 14 08:37:40 2016] * Is there a some very easy recipe for Coq developments in one folder with subfolders? [Thu Apr 14 09:18:55 2016] _y : "unifying" is complicated in general. In this case, m is just an index, so it's easy. But it could be a constructor, an application of a function to another variable, anything basically. [Thu Apr 14 09:19:56 2016] Agda has a stronger pattern-matching which allows for such unification in more cases, but it comes with its own problems (for a while, it allowed to prove the axiom K, which is not something that we want by default) [Thu Apr 14 09:22:57 2016] <_y> constructors are easy to unify through [Thu Apr 14 09:23:23 2016] <_y> but indeed, if you can have any term as an index… [Thu Apr 14 11:44:08 2016] jstolarek: I don't think SearchPattern is bound to a key [Thu Apr 14 11:45:09 2016] jstolarek: Ah, PG calls it coq-SearchIsos, and it's bound to C-c C-a C-o [Thu Apr 14 13:45:21 2016] if I have two types, X Y : Type, is there any way to tell if the types are the same Inductive type? [Thu Apr 14 13:52:00 2016] johnw : with Ltac you mean? [Thu Apr 14 13:55:33 2016] I mean generically [Thu Apr 14 13:55:42 2016] so, I have a function foo (U T : Type) := .... [Thu Apr 14 13:55:50 2016] where I need to do one thing if U = T, but something else if not [Thu Apr 14 13:56:10 2016] so I need decidable equality on types, which I think doesn't (and can't) exist [Thu Apr 14 13:56:20 2016] Ah. Then no, I don't think that you can get anything close [Thu Apr 14 13:56:20 2016] since the decision would happen at runtime, but the types don't exist then [Thu Apr 14 13:57:16 2016] yeah, I'd be relying on information across a boundary [Thu Apr 14 13:57:18 2016] hmm [Thu Apr 14 13:57:21 2016] so, here's my problem [Thu Apr 14 13:57:41 2016] I have a system of Units devised now, so that an inhabitant of Units (Distance / Time) can only be something like Meters / Seconds. [Thu Apr 14 13:57:56 2016] what I need to write is multiplication between units [Thu Apr 14 13:58:11 2016] such that Units Time * Units (Distance / Time) would have type Units Distance [Thu Apr 14 13:58:27 2016] with the appropriate conversions happening if the first value is in Hours, and the second value is in Meters / Seconds [Thu Apr 14 13:58:51 2016] well, that logic depends very much on exactly which units are being multipled [Thu Apr 14 13:59:03 2016] Units Time * Units Distance is very different from Units Time * Units Time [Thu Apr 14 14:00:38 2016] I'm finding that function very hard to write... [Thu Apr 14 14:03:32 2016] hmm [Thu Apr 14 14:05:35 2016] How does your model work? You have some inductive type for the basic SI quantities like Distance, Time, Mass and so on. And then, another inductive type called Units, parametrized by a quantity, which instantiates units such as Meters, Seconds, ... ? [Thu Apr 14 14:07:28 2016] actually, a friend had a solution: use a generic type, since all of these are just sums in the end [Thu Apr 14 14:51:25 2016] Cypi: I don't have a single inductive type for SI quantities, since the ultimate use of this is not for physics. It's an open units system, where you can introduce new types of quantities. [Fri Apr 15 14:11:45 2016] can I create Ltac scripts that accept a pattern as an argument? [Fri Apr 15 17:08:40 2016] I don't think so, [Fri Apr 15 17:08:45 2016] but what does that mean exactly? [Fri Apr 15 17:09:29 2016] A pattern usually binds some variables, but if the pattern were outside your Ltac function, you would not know which variables are bound. [Fri Apr 15 17:09:59 2016] and if you just want to bind against a particular constructor, that is possible by taking the constructor as an argument [Fri Apr 15 17:10:31 2016] though if you wanted to take a whole expression I think you are out of luck. [Sat Apr 16 07:48:46 2016] mornign [Sat Apr 16 07:49:16 2016] hi hi [Sat Apr 16 08:42:43 2016] im studying some game theory, just beginning [Sat Apr 16 08:43:01 2016] hopefully something comes up to investigate a little with coq [Sat Apr 16 13:08:12 2016] tbelaire: hi [Sat Apr 16 13:08:20 2016] hi [Sat Apr 16 13:08:34 2016] so, I want to rewrite on a term under a binder [Sat Apr 16 13:08:41 2016] (fun n => 1 + (n + 2)) [Sat Apr 16 13:08:48 2016] which I can do, with the right setoids [Sat Apr 16 13:08:57 2016] so my macro wants to look like this: zoom [_ + 2]. [Sat Apr 16 13:09:07 2016] which would make a new goal, n + 2 = ?1 [Sat Apr 16 13:09:13 2016] which, when completed, replaces the term under the binder [Sat Apr 16 13:09:19 2016] so far, the best I can do is this: [Sat Apr 16 13:09:21 2016] pardon, what's a setoid? [Sat Apr 16 13:09:23 2016] zoom (fun n => n + 2) [Sat Apr 16 13:09:34 2016] a setoid is any set equipped with a notion of equivalence [Sat Apr 16 13:09:43 2016] ah, okay [Sat Apr 16 13:09:43 2016] (S,==,equivalence laws for ==) [Sat Apr 16 13:10:01 2016] once you establish a setoid in Coq, it can be used for rewriting with the "rewrite" tactic [Sat Apr 16 13:10:14 2016] in this case, I'm saying that functions are equivalent under functional extensionality [Sat Apr 16 13:10:16 2016] Alright [Sat Apr 16 13:10:23 2016] and zoom? [Sat Apr 16 13:10:23 2016] which will make rewriting under binders suddenly OK (given that axiom) [Sat Apr 16 13:10:29 2016] zoom is a tactic I've written [Sat Apr 16 13:10:33 2016] okay [Sat Apr 16 13:10:40 2016] https://gist.github.com/91d4c2f497e841bcc88be7499a649a0c [Sat Apr 16 13:10:45 2016] it actually works fairly well so far [Sat Apr 16 13:10:58 2016] example: https://gist.github.com/fa3eb4cad428c721e3c357c2250b85ce [Sat Apr 16 13:12:25 2016] I'm getting an error... [Sat Apr 16 13:12:31 2016] Tactic failure:setoid rewrite failed: Unable to satisfy the rewriting constraints. [Sat Apr 16 13:12:34 2016] yes, you don't have the setoids defined [Sat Apr 16 13:12:54 2016] err, after that [Sat Apr 16 13:13:10 2016] the rewriting constraints are things that need to be defined for it to work [Sat Apr 16 13:13:11 2016] Do I also need to do something with function extensionality [Sat Apr 16 13:13:13 2016] okay [Sat Apr 16 13:13:19 2016] I wouldn't try too hard to get the example working [Sat Apr 16 13:13:23 2016] it was just to show what I want [Sat Apr 16 13:13:42 2016] sure [Sat Apr 16 13:14:38 2016] So after you run zoom (1 + 2). you get what goal exactly? [Sat Apr 16 13:14:44 2016] 1 + 2 = ?1 [Sat Apr 16 13:14:54 2016] allow you to redefine the equality by rewriting [Sat Apr 16 13:15:02 2016] okay [Sat Apr 16 13:15:12 2016] then you use 'reflexivity' to end the goal at any time [Sat Apr 16 13:15:20 2016] and it rewrites with the new form on the left hand side [Sat Apr 16 13:15:40 2016] where zoom can "reach to" depends on what setoids are in scope [Sat Apr 16 13:15:58 2016] otherwise, it's just like any rewrite, except that it gives you some focus [Sat Apr 16 13:16:09 2016] (so that maybe you don't need to use occurence selectors so often, such as "at 1") [Sat Apr 16 13:16:19 2016] okay [Sat Apr 16 13:17:03 2016] and you want to use zoom (n + 2) instead of zoom (1 + 2) [Sat Apr 16 13:17:15 2016] well, zoom (_ + 2), yeah [Sat Apr 16 13:18:05 2016] is it possible to create a new evar and use that? [Sat Apr 16 13:18:12 2016] it won't match up :( [Sat Apr 16 13:18:23 2016] how would you do that anyways? [Sat Apr 16 13:18:32 2016] evar (n : nat). zoom (n + 2). [Sat Apr 16 13:18:45 2016] it's an existential, though [Sat Apr 16 13:18:56 2016] so it doesn't unify with "anything at all" [Sat Apr 16 13:20:43 2016] how about 'exists m, m + 2' or something [Sat Apr 16 13:20:50 2016] well [Sat Apr 16 13:21:02 2016] likely generated in the ltac somehow [Sat Apr 16 13:21:33 2016] because you can unify those, once [Sat Apr 16 13:23:31 2016] maybe something like [Sat Apr 16 13:23:33 2016] instantiate (1:=1) in (Value of n). [Sat Apr 16 13:23:44 2016] after creating it with evar [Sat Apr 16 13:24:06 2016] so, you mean the zoom statement would be: zoom (exists n, n + 2)? [Sat Apr 16 13:24:12 2016] I'm not sure yet [Sat Apr 16 13:24:41 2016] the variables behind `exists` are rather different from those created by `evar` [Sat Apr 16 13:24:59 2016] are they completely different? [Sat Apr 16 13:25:05 2016] I've never been clear on that [Sat Apr 16 13:25:17 2016] or are they just the same thing, presented differently? [Sat Apr 16 13:25:59 2016] well, the one behind "exists" is an existential within the ex_intro constructor [Sat Apr 16 13:26:18 2016] ah, so they are fundementally the same [Sat Apr 16 13:26:20 2016] cool [Sat Apr 16 13:27:50 2016] I wasn't sure if it was a meta-level vs a term level distinction [Sat Apr 16 13:29:10 2016] we want to talk about n, but it's not in scope, and we can't simply intros it into scope [Sat Apr 16 13:29:39 2016] we actually want to talk about "any n", not just some n [Sat Apr 16 13:29:49 2016] because the term we're rewriting in is a lambda [Sat Apr 16 13:29:54 2016] what if you did zoom (fun n, stuff + (n + 2)). intros n. zoom (n+2). [Sat Apr 16 13:29:57 2016] ? [Sat Apr 16 13:30:02 2016] would that work? [Sat Apr 16 13:30:08 2016] zoom (fun n => n + 2) does work [Sat Apr 16 13:30:12 2016] so that's my solution for now [Sat Apr 16 13:30:17 2016] ah, okay [Sat Apr 16 13:30:21 2016] what would have been cool is if [_ + 2] just expanded to that [Sat Apr 16 13:30:27 2016] the way it does in some places in ssreflect [Sat Apr 16 13:30:40 2016] set f := _ + 2 in ssreflect is equivalent to set f := forall x, x + 2. [Sat Apr 16 13:30:47 2016] write the tactic as a ML extension? :P [Sat Apr 16 13:30:52 2016] yeah, I'd have to I think [Sat Apr 16 13:31:03 2016] and use their machinery [Sat Apr 16 13:36:34 2016] if the ML to do this was straightforward, would you want to use it? [Sat Apr 16 13:36:40 2016] or do you want to say in pure ltac? [Sat Apr 16 13:36:54 2016] I'd be fine either way, if the ML was easy to write [Sat Apr 16 13:36:57 2016] and not need to do any compiling of things [Sat Apr 16 13:37:08 2016] okay, I might poke my nose into it [Sat Apr 16 13:37:27 2016] don't feel that you should, tbelaire, the fun _ => _ syntax is fine for now [Sat Apr 16 13:37:32 2016] but I think I'm going to read more of Scott Aaronson's book first [Sat Apr 16 13:37:40 2016] yeah, but I'm curious [Sat Apr 16 13:38:02 2016] I might not get around to it, I do have actual things I need to work on [Sat Apr 16 13:53:14 2016] it would be nice to see your ML plugin as a template for future such work, though :) [Sat Apr 16 13:53:22 2016] yeah [Sat Apr 16 13:53:35 2016] but in order to construct one, I'll first scour the web for examples :P [Sat Apr 16 13:53:49 2016] at which point, I could just point you there [Sat Apr 16 13:54:02 2016] actually doing original work is, well, work [Sat Apr 16 13:54:04 2016] :P [Sun Apr 17 12:39:49 2016] <_y> i have trouble with matching and “unification” again [Sun Apr 17 12:41:00 2016] <_y> http://paste.awesom.eu/pvt2&ln [Sun Apr 17 12:42:17 2016] <_y> here, you have to write the return value ‘eq_refl x’, ‘eq_refl y’ leads to this error message [Sun Apr 17 12:42:59 2016] <_y> and i don’t see why [Sun Apr 17 12:45:22 2016] <_y> the way i understand it is: when i destruct ‘H : eq x y’ into ‘eq_refl x0 : eq x0 x0’ (x0 being the placeholder _ in my code), Coq sees x is actually x0, and y is actually x0 [Sun Apr 17 12:47:51 2016] <_y> moreover, since in the definition of eq, the parameter x is outside the constructor eq_refl, x0 must remain implicit and is automatically inferred to be x [Sun Apr 17 12:49:26 2016] <_y> (as opposed to ‘Definition test : nat -> nat -> Prop := | test_refl : forall x, test x x.’, for which i have to write ‘match H with | test_refl x0 -> test_refl x0’ and nothing else) [Sun Apr 17 13:06:09 2016] <_y> sorry, did i miss a message? [Sun Apr 17 13:06:31 2016] <_y> i do not even know if all my messages where sent [Sun Apr 17 16:27:29 2016] _y: hi [Sun Apr 17 16:33:39 2016] _y: try @eq_refl nat x, instead of eq_refl y [Sun Apr 17 23:37:13 2016] what in fuck [Sun Apr 17 23:39:39 2016] how can eq eliminate to Type [Sun Apr 17 23:39:39 2016] is this the 1-ctor trick thing? [Sun Apr 17 23:51:44 2016] johnw: ping? [Sun Apr 17 23:57:08 2016] augh i need some hepl [Mon Apr 18 00:33:17 2016] benzrf: hm? [Mon Apr 18 00:35:08 2016] hey Cale! [Mon Apr 18 00:35:19 2016] benzrf: What was your question about? [Mon Apr 18 00:35:32 2016] how can i eliminate an impossible Prop to get an inhabitant of a Type [Mon Apr 18 00:37:04 2016] Can that be done? [Mon Apr 18 00:37:19 2016] oh, figured it out [Mon Apr 18 00:37:55 2016] assert False as foo. inversion H. inversion foo. [Mon Apr 18 00:38:49 2016] ah, look at the type of False_rect [Mon Apr 18 00:39:28 2016] found it :] [Mon Apr 18 04:31:02 2016] <_y> johnw, yes, i knew it works with ‘eq_refl x’ instead, my question was: [Mon Apr 18 04:31:28 2016] <_y> > the way i understand it is: when i destruct ‘H : eq x y’ into ‘eq_refl x0 : eq x0 x0’ (x0 being the placeholder _ in my code), Coq sees x is actually x0, and y is actually x0 [Mon Apr 18 04:31:36 2016] <_y> why is this sort of “asymetric” unification x0 ← x and x0 ← y, where x0 can be written where x or y is expected, but not the converse? [Mon Apr 18 04:34:21 2016] _y : this kind of unification can only unify an index with something else, never a parameter [Mon Apr 18 04:34:46 2016] In this case, the type of H is (x = y), where 'x' is a parameter and 'y' is an index [Mon Apr 18 08:43:56 2016] Hello! [Mon Apr 18 08:44:20 2016] I have integer division function defined using wf_nat_rec. [Mon Apr 18 08:44:33 2016] * lt_wf_rec [Mon Apr 18 08:44:59 2016] The problem is I don't know how to prove any of it properties. :( [Mon Apr 18 08:47:14 2016] There is a gist: https://gist.github.com/anonymous/b955c883fbf2da7a69fd3139abe7573e [Mon Apr 18 08:47:58 2016] For example, I can't even prove that for a < b a/b = 0. [Mon Apr 18 08:49:01 2016] Theorem div_lt (a b: nat) (H: 0 < b) (H0: a < b): div a H = 0. .... [Mon Apr 18 09:39:25 2016] you can unfold down to the real induction principle : https://gist.github.com/JoeDralliam/581e2164aa67e991e547cd3c5d42b669 [Mon Apr 18 09:51:53 2016] Big thank you! [Mon Apr 18 12:22:18 2016] benzrf: hi [Mon Apr 18 14:13:03 2016] Hello again. [Mon Apr 18 14:14:34 2016] Question about the same integer division function (https://gist.github.com/anonymous/b955c883fbf2da7a69fd3139abe7573e#file-div-v) [Mon Apr 18 14:15:31 2016] I tried to prove in the same way (unfold div and induction principle until well_founded_induction_type) but without success this theorem: [Mon Apr 18 14:15:38 2016] Definition fin_step (a b: nat) (H: 0 < b) (H0: b ≤ a): div a H = S (div (a - b) H). [Mon Apr 18 14:16:35 2016] Any ideas about what I am missing? [Mon Apr 18 14:19:22 2016] * until Acc_rect. [Mon Apr 18 17:22:06 2016] Is it possible to see history of this chat a few hours ago? [Mon Apr 18 17:30:18 2016] no [Mon Apr 18 17:30:25 2016] get a bouncer [Mon Apr 18 17:38:07 2016] Thanks, will check it [Tue Apr 19 10:13:29 2016] Are there papers around on the implementation of Coq? So not just about the calculus of inductive constructions, but rather from a software engineering standpoint. [Tue Apr 19 21:53:58 2016] are logs kept for this channel anywhere? [Tue Apr 19 21:58:22 2016] im here almost 24/7 on my bouncer & i log [Tue Apr 19 21:58:24 2016] why? [Tue Apr 19 21:59:37 2016] wondering if they were publicly available anywhere, someone asked earlier if there were any publications about the "software engineering" of coq, and I missed if anyone ever answered [Tue Apr 19 22:00:38 2016] Nobody answered [Tue Apr 19 22:00:55 2016] alright thanks [Tue Apr 19 22:00:57 2016] But as far as I know, there are no really precise documents about this [Tue Apr 19 22:01:38 2016] There was one start of a "tutorial" about it (I'm trying to find it again). There are some documents in the /dev/ folder, and that's about it :/ [Tue Apr 19 22:02:32 2016] i'll check out the folder [Tue Apr 19 22:03:14 2016] (/dev/doc/ to be precise) [Tue Apr 19 22:04:19 2016] https://github.com/wjzz/Coq-Developers-Manual >> alright, it was this one. It's very incomplete though, and quite visibly not up-to-date [Wed Apr 20 07:28:05 2016] I have a hypothesis H : forall n, ... [Wed Apr 20 07:28:19 2016] can I call intro on that hypothesis? [Wed Apr 20 07:28:50 2016] I means I want Coq to assume some particular n1 and specialize hypothesis for n1 [Wed Apr 20 07:52:47 2016] jstolarek : "intros H; specialize (H n1)" [Wed Apr 20 12:59:14 2016] I'm curious, do people still use the induction tactic for all their proofs, or are you forced to use refine (foo_ind ...) for larger ones? [Wed Apr 20 12:59:34 2016] because I've run into a number of problems where I was forced to use refine [Wed Apr 20 12:59:44 2016] and it's not very pretty [Wed Apr 20 12:59:59 2016] and I was wondering if that was normal [Wed Apr 20 13:04:28 2016] Is there a way to clear a term and all the hypothesis it's used in? [Wed Apr 20 13:06:23 2016] clear dependent foo. [Thu Apr 21 00:30:20 2016] jstolarek: I think you want: evar (n : nat); specialize (H n)? [Thu Apr 21 09:26:23 2016] ls [Thu Apr 21 09:26:27 2016] ...disregard that. [Thu Apr 21 11:04:22 2016] hey, I tried to write up my experience from the other day with index types [Thu Apr 21 11:04:24 2016] http://csclub.uwaterloo.ca/~tbelaire/blog/posts/coq-index-vs-parameter.html [Thu Apr 21 11:05:02 2016] and I would appreciate feedback, especially corrections [Thu Apr 21 11:05:15 2016] wait, I should get comments working on the blog [Thu Apr 21 14:59:16 2016] Good evening [Thu Apr 21 15:00:06 2016] Can someone help with such proof: https://gist.github.com/zaarcis/421b60757979bdb12308f640f25119ca [Thu Apr 21 15:22:11 2016] Random question: I'm working on a proof where I have a goal of the form `f x`, and I've proved the lemma 'f_dec', `forall x, {f x} + {~ f x}.` [Thu Apr 21 15:22:29 2016] How do I actually apply this lemma to finish the proof? [Thu Apr 21 15:22:59 2016] destruct (f_dec x) [Thu Apr 21 15:23:15 2016] but you'll have a case where the decision procedure determines ~ f x [Thu Apr 21 15:25:08 2016] hmm so if I have concrete arguments [Thu Apr 21 15:25:15 2016] like a goal of the form `f 1234` [Thu Apr 21 15:25:24 2016] Is there a way to get it to just compute? [Thu Apr 21 15:27:14 2016] f_dec 1234 will return either a value of f 1234 or ~f 1234 [Thu Apr 21 15:28:51 2016] so f_dec just says that either f x or ~ f x, but it can't be applied by coq to concrete arguments to actually run the decision procedure? [Thu Apr 21 15:29:47 2016] Right now, I've implemented a parallel thing that returns a bool, and so I convert to that, and then `simpl; reflexivity` [Thu Apr 21 15:30:02 2016] if it's not too difficult can you paste your code somewhere? [Thu Apr 21 15:32:01 2016] okay, so I have this: https://gist.github.com/4ae377582b69561e52f4653a3a1addf5 (id is basically a wrapper around Z) [Thu Apr 21 15:32:11 2016] and I want to prove `ring_between 1 2 3` [Thu Apr 21 15:32:38 2016] I've written some ltac which needs to convert from exists x, ... to x := ?1 |- ... with evar [Thu Apr 21 15:32:43 2016] but I want to convert back at the end [Thu Apr 21 15:32:54 2016] I guess I can do it with `unfold ring_between; simpl; omega.` [Thu Apr 21 15:32:59 2016] is there a nice way to undo "evar (x: ty); exists x" [Thu Apr 21 15:36:23 2016] anishath_, you have "f : nat -> bool" and "f_dec : forall x, {f x}+{~f x}" and nothing more? [Thu Apr 21 15:36:43 2016] um well the specific example is what I wrote above [Thu Apr 21 15:36:47 2016] > okay, so I have this: https://gist.github.com/4ae377582b69561e52f4653a3a1addf5 (id is basically a wrapper around Z) [Thu Apr 21 15:36:51 2016] > and I want to prove `ring_between 1 2 3` [Thu Apr 21 15:36:55 2016] > I guess I can do it with `unfold ring_between; simpl; omega.` [Thu Apr 21 15:36:58 2016] what are you deciding in the specific example though? [Thu Apr 21 15:37:20 2016] Lemma easy : ring_between 1 2 3. [Thu Apr 21 15:39:46 2016] About the gist previously. I did it. [Thu Apr 21 15:40:08 2016] kxiw: does it use syntax in coq 8.5? (couldn't get it to run in 8.4p5) [Thu Apr 21 15:40:11 2016] just curious [Thu Apr 21 15:40:28 2016] The gist? Yes, it does. [Thu Apr 21 15:42:37 2016] Theorem first_and_tail has such "body" between Proof and Qed: refine (match L with cons a t => _ | nil _ => _ end); compute; auto. [Thu Apr 21 15:45:02 2016] Somehow usual destruct didn't work. [Thu Apr 21 15:45:47 2016] But this try with refine (and IDProp) did. [Thu Apr 21 16:10:32 2016] How do you solve "Instance is not well-typed in the environment of ?...." arising from evars [Thu Apr 21 16:11:03 2016] tbelaire: hi [Thu Apr 21 16:11:07 2016] Coq 8.4? [Thu Apr 21 16:11:08 2016] I'm trying to go from exists x, .. to x := ?.. |- .. and then back [Thu Apr 21 16:11:09 2016] yeah [Thu Apr 21 16:11:15 2016] ok [Thu Apr 21 16:11:23 2016] so what this means is that early in your proof, you created a "hole" [Thu Apr 21 16:11:30 2016] then you introduced some new terms [Thu Apr 21 16:11:38 2016] and now you're trying to reference these terms in your instantiation [Thu Apr 21 16:11:43 2016] yup [Thu Apr 21 16:11:50 2016] but since they didn't exist when the hole was created, you're not allowed to [Thu Apr 21 16:11:53 2016] yup [Thu Apr 21 16:12:02 2016] Coq 8.5 has some fixes to this logic, that make more instantiations possible [Thu Apr 21 16:12:16 2016] but until then, you have to delay creating your evar, or you have to introduce those terms earlier [Thu Apr 21 16:12:50 2016] The reason I created the evar was to keep working under a exists in Ltac [Thu Apr 21 16:13:05 2016] but you're creating information the evar is unaware of [Thu Apr 21 16:13:05 2016] there's a rewrite rule we want to apply [Thu Apr 21 16:13:59 2016] so, we have exists S, P. we want exists S, P' [Thu Apr 21 16:14:19 2016] is the proof small? can I see it? [Thu Apr 21 16:14:48 2016] but we can't do match goal with | context ctx[foo ?S ] end. [Thu Apr 21 16:14:54 2016] as you can't match open terms [Thu Apr 21 16:15:25 2016] but converting the exists with evars lets us create S:=?123 |= P' [Thu Apr 21 16:15:27 2016] and we are stuck [Thu Apr 21 16:17:53 2016] it's not that small [Thu Apr 21 16:18:16 2016] I've been doing a lot of work with evars lately [Thu Apr 21 16:18:19 2016] I wanted to try out some tricks [Thu Apr 21 16:18:33 2016] ok, I'll show it to you [Thu Apr 21 16:19:29 2016] https://gist.github.com/tbelaire/cdb9f164a7b4d06d37aadb09062e8b64#file-dot_top_bot_mut-v-L766 [Thu Apr 21 16:19:53 2016] do I need the LibLN source? [Thu Apr 21 16:20:17 2016] uh [Thu Apr 21 16:20:37 2016] yeah, that's libtlc [Thu Apr 21 16:20:39 2016] oh [Thu Apr 21 16:21:02 2016] https://github.com/amaurremi/dot-calculus [Thu Apr 21 16:21:29 2016] is the rest of the files, with this being in dev/lf/dot_top_bot_mut.v [Thu Apr 21 16:21:49 2016] ok [Thu Apr 21 16:22:20 2016] trying to just make a minimal counter example with numbers, one sec [Thu Apr 21 16:22:20 2016] it's evaluating [Thu Apr 21 16:22:29 2016] ah, yes [Thu Apr 21 16:22:36 2016] I get "impossible to unify" on line 924 [Thu Apr 21 16:23:11 2016] error should be on this line [Thu Apr 21 16:23:12 2016] https://gist.github.com/tbelaire/cdb9f164a7b4d06d37aadb09062e8b64#file-dot_top_bot_mut-v-L779 [Thu Apr 21 16:23:18 2016] how are you below that? [Thu Apr 21 16:23:32 2016] which branch are you on? [Thu Apr 21 16:23:36 2016] i don't have that code at that line [Thu Apr 21 16:24:54 2016] pushed the breaking version to github [Thu Apr 21 16:24:56 2016] pull? [Thu Apr 21 16:25:08 2016] sorry bout that [Thu Apr 21 16:25:17 2016] ok, have it now [Thu Apr 21 16:26:14 2016] the idea with the assert was to then apply it right away [Thu Apr 21 16:26:22 2016] to get the goal in the right shape [Thu Apr 21 16:26:28 2016] and maybe work this into the ltac [Thu Apr 21 16:26:38 2016] ah [Thu Apr 21 16:26:42 2016] yes, this cannot ever work [Thu Apr 21 16:26:48 2016] dang [Thu Apr 21 16:26:51 2016] you're trying to identify one existential with another [Thu Apr 21 16:27:01 2016] but that's the whole purpose of existentials [Thu Apr 21 16:27:06 2016] you only know that they exist, not what they are [Thu Apr 21 16:27:14 2016] if H1 accepted "forall", then you could do this [Thu Apr 21 16:27:23 2016] yeah [Thu Apr 21 16:27:40 2016] effectively you're saying: I have some number, and this hypothesis is proven in terms of some number; how do I state that these two numbers are the same number? [Thu Apr 21 16:27:55 2016] with decidable equality you can test for that [Thu Apr 21 16:28:04 2016] but you can't say it for all numbers you might have, and that H1 might have [Thu Apr 21 16:28:31 2016] do you have a better idea than using evar in the ltac to get around not being able to for match to grab them? [Thu Apr 21 16:28:39 2016] let me see [Thu Apr 21 16:38:23 2016] how do you know that S = S1 & l ~ T & S2 for some S1 and S2? [Thu Apr 21 16:39:37 2016] Hello [Thu Apr 21 16:40:01 2016] & is concat and ~ creates a binding [Thu Apr 21 16:40:05 2016] A question about opacity of theorems from standard library... [Thu Apr 21 16:40:18 2016] but how do you know that's true for any S, l and T? [Thu Apr 21 16:40:25 2016] skuesx: sure [Thu Apr 21 16:40:50 2016] I would want to make them transparent but that is impossible, as far as I know. [Thu Apr 21 16:40:56 2016] you can [Thu Apr 21 16:41:01 2016] Local Transparent "name of theorem" [Thu Apr 21 16:41:18 2016] I dunno, it's not my file :P [Thu Apr 21 16:41:31 2016] it was proven with a different proof [Thu Apr 21 16:41:32 2016] Error: Cannot make Nat.add_comm transparent because it was declared opaque. [Thu Apr 21 16:41:38 2016] :( [Thu Apr 21 16:41:44 2016] tbelaire: so, if you can prove that, then you have the first part of the conjunction [Thu Apr 21 16:42:52 2016] I wanted to use, for example, this theorem in eq_rect, where I need its 'computational content'. [Thu Apr 21 16:43:21 2016] give me a minute, and I'll put up an example with integers [Thu Apr 21 16:43:43 2016] k [Thu Apr 21 16:43:52 2016] oh, I see [Thu Apr 21 16:50:20 2016] Ltac foo := match goal with [Thu Apr 21 16:50:21 2016] | |- context ctx [S ?n] => idtac n [Thu Apr 21 16:50:23 2016] end. [Thu Apr 21 16:50:25 2016] Lemma bar : 2 = 1 + 1. [Thu Apr 21 16:50:27 2016] Proof. [Thu Apr 21 16:50:29 2016] foo. [Thu Apr 21 16:50:31 2016] reflexivity. [Thu Apr 21 16:50:33 2016] Qed. [Thu Apr 21 16:50:35 2016] Lemma baz : exists n:nat, S n = S n. [Thu Apr 21 16:50:37 2016] Proof. [Thu Apr 21 16:50:39 2016] foo. (* fails to match *) [Thu Apr 21 16:50:41 2016] Qed. [Thu Apr 21 16:50:43 2016] no, I copied the gist [Thu Apr 21 16:50:45 2016] https://gist.github.com/2ab40b3b2a76a0a7ce6a8f9117096638 [Thu Apr 21 16:50:47 2016] oops [Thu Apr 21 16:50:49 2016] that's really the problem we wanted to solve [Thu Apr 21 16:51:49 2016] where we want to have a more complicated tactic than idtac :P [Thu Apr 21 16:52:06 2016] eexists; foo [Thu Apr 21 16:52:26 2016] yeah [Thu Apr 21 16:52:37 2016] and then turn it back [Thu Apr 21 16:52:44 2016] into a goal with exists n, ... [Thu Apr 21 16:52:54 2016] set_evars [Thu Apr 21 16:52:59 2016] set_evars? [Thu Apr 21 16:53:01 2016] (does that exist in Coq?) [Thu Apr 21 16:53:02 2016] what magic is this [Thu Apr 21 16:53:03 2016] one sec [Thu Apr 21 16:53:17 2016] Ltac set_evars := [Thu Apr 21 16:53:17 2016] repeat match goal with [Thu Apr 21 16:53:17 2016] | [ |- appcontext[?E] ] => is_evar E; let H := fresh in set (H := E) [Thu Apr 21 16:53:19 2016] end. [Thu Apr 21 16:53:21 2016] [Thu Apr 21 16:53:29 2016] For now my "solution" for problem of opaque theorems from standard library is to ignore them and re-derive them again, this time with Defined. [Thu Apr 21 16:54:02 2016] Also using Local Definition to hide them from outside, probably. [Thu Apr 21 16:55:09 2016] yeah [Thu Apr 21 16:55:15 2016] does that help? [Thu Apr 21 16:55:25 2016] checking [Thu Apr 21 16:56:48 2016] Still... rederiving parts of existing library just because I need them to be transparent is bad code smell [Thu Apr 21 16:57:11 2016] we have a theorem we want to apply on the transformed version that outputs a exists S, ... type goal [Thu Apr 21 16:59:38 2016] so, you want to rewrite "under the exists"? [Thu Apr 21 17:00:02 2016] i.e., you have exists n, f n = f' n, and you just want to apply transformations to the equality? [Thu Apr 21 17:00:19 2016] exactly [Thu Apr 21 17:00:32 2016] ok, one second [Thu Apr 21 17:02:16 2016] Local Lemma aux0 n: n + 1 = S n. Proof. induction n; simpl; auto. Defined. [Thu Apr 21 17:02:35 2016] Definition add_to_end A n (L: list A n) (x: A): list A (S n) := eq_rect (L ++ x :: nil) (aux0 n). [Thu Apr 21 17:03:43 2016] Eval compute in (add_to_end (1 :: 2 :: 3 :: nil) 4). [Thu Apr 21 17:03:56 2016] = 1 :: 2 :: 3 :: 4 :: nil : list nat 4 [Thu Apr 21 17:04:06 2016] This time it works. [Thu Apr 21 17:13:30 2016] tbelaire: ok [Thu Apr 21 17:13:34 2016] cool [Thu Apr 21 17:13:51 2016] https://gist.github.com/ff0e1404c0b608ef03cceb357345507d [Thu Apr 21 17:13:56 2016] that will let you rewrite under exists [Thu Apr 21 17:14:13 2016] Add Parametric Morphism [Thu Apr 21 17:14:16 2016] what is this? [Thu Apr 21 17:14:20 2016] setoid rewriting machinery [Thu Apr 21 17:14:39 2016] it says that exists is an equivalence for a setoid, and that we can rewrite using that equivalence [Thu Apr 21 17:14:51 2016] or rather, exists *respects* the equivalence of a setoid [Thu Apr 21 17:14:57 2016] the setoid where iff is the equivalence [Thu Apr 21 17:14:57 2016] okay neat [Thu Apr 21 17:15:12 2016] I guess I should read a little about set setoids [Thu Apr 21 17:15:23 2016] for this to work, there needs to also be a Parametric Relation, defining the equivalence [Thu Apr 21 17:15:27 2016] but this already exists for both eq and iff [Thu Apr 21 17:17:18 2016] yes, they are quite useful for building smarter rewriting tactics [Thu Apr 21 17:17:30 2016] I'm using a setoid library right now for "refinement" relations [Thu Apr 21 17:17:47 2016] do you know of any good introductions to setoid things? [Thu Apr 21 17:17:56 2016] sadly, no [Thu Apr 21 17:18:02 2016] there is a chapter in the manual about them [Thu Apr 21 17:18:07 2016] okay [Thu Apr 21 17:18:08 2016] and I recommend reading it and rereading it [Thu Apr 21 17:18:16 2016] I do have a nice working example for you [Thu Apr 21 17:18:20 2016] which is what I used to get familiar with them [Thu Apr 21 17:18:28 2016] oh cool [Thu Apr 21 17:18:32 2016] https://github.com/jwiegley/coq-haskell/blob/master/src/Control/Iso.v [Thu Apr 21 17:18:42 2016] this creates a type relation called "isomorphic" [Thu Apr 21 17:18:47 2016] defines it as an equivalence relation [Thu Apr 21 17:19:02 2016] and then state that certain terms respect this relation [Thu Apr 21 17:19:16 2016] so that as you go further down the file, I can start proving type isomorphisms using plain rewriting [Thu Apr 21 17:19:28 2016] hey, just out of curiosity, do you have any examples that use functional induction. The manual defines one, but doesn't use it [Thu Apr 21 17:19:37 2016] okay I'll read it [Thu Apr 21 17:19:38 2016] not yet, I've never used it myself [Thu Apr 21 17:19:44 2016] ok [Thu Apr 21 17:19:56 2016] I feel like it might be a solution to a problem I have [Thu Apr 21 17:20:04 2016] but I'm out of time to explore [Thu Apr 21 17:20:25 2016] they stop paying me tomorrow to work on coq and I'm back to being a student [Thu Apr 21 17:20:31 2016] oh :( [Thu Apr 21 17:20:55 2016] will we lose your cheerful presence here? [Thu Apr 21 17:21:17 2016] I'll stick around in the channel [Thu Apr 21 17:21:26 2016] but likely you'll see me less [Thu Apr 21 17:21:45 2016] I'm going to try and write up another blog post tomorrow about what I was working on [Thu Apr 21 17:21:46 2016] I just simplified Iso.v [Thu Apr 21 17:21:57 2016] tbelaire: cool! please let me know [Thu Apr 21 17:22:15 2016] I did write up : http://csclub.uwaterloo.ca/~tbelaire/blog/posts/coq-index-vs-parameter.html [Thu Apr 21 17:22:25 2016] that index vs parameter for subsets [Thu Apr 21 17:22:45 2016] is it true that indexed types are just more general? [Thu Apr 21 17:22:47 2016] it hath been queued for reading [Thu Apr 21 17:22:52 2016] nice :D [Thu Apr 21 17:23:08 2016] i don't know enough to say yes or no to that statement [Thu Apr 21 17:23:11 2016] okay [Thu Apr 21 17:23:20 2016] inversion yields better information about parameters [Thu Apr 21 17:23:37 2016] I could prove the induction statement for the parameterized version from the indexed version [Thu Apr 21 17:23:43 2016] but I failed to do it the other way around [Thu Apr 21 17:23:45 2016] ah [Thu Apr 21 17:23:53 2016] which is different from a proof that it can't be done of course [Thu Apr 21 17:23:53 2016] they should be in bijection, no? [Thu Apr 21 17:23:59 2016] I don't think so [Thu Apr 21 17:24:10 2016] the set of inhabitants is different? [Thu Apr 21 17:24:15 2016] yeah [Thu Apr 21 17:24:59 2016] on some edge cases like sub_ ((C, (D, fs, ms)) :: CT) C D [Thu Apr 21 17:25:12 2016] where the CT really did depend on the choice of C and D [Thu Apr 21 17:25:23 2016] and the induction for the parameterized version wasn't working [Thu Apr 21 17:25:25 2016] I thin [Thu Apr 21 17:25:46 2016] I'm away for a bit... [Thu Apr 21 17:25:49 2016] I could take another attempt at proving it only using parameterized tyeps [Thu Apr 21 17:25:53 2016] alrigh ttyl [Thu Apr 21 17:54:46 2016] Apologies for asking again. How can I get transparent versions of theorems from standard library. [Thu Apr 21 17:55:20 2016] If it's possible without proving them again with Defined [Thu Apr 21 18:03:27 2016] skuesx: I'm not sure that you can :( [Thu Apr 21 18:06:11 2016] johnw: Okay, thanks. [Thu Apr 21 18:06:21 2016] you could always ask on the Coq-club mailing list [Thu Apr 21 18:53:56 2016] k [Fri Apr 22 03:52:25 2016] I have a module Foo in source file Bar. Inside Foo I declare inductive data type Baz. In another source file I say "Require Export Bar". How do I refer to Baz without qualifying it with Foo. module prefix ? [Fri Apr 22 03:54:45 2016] Does "Import Foo." work? [Fri Apr 22 03:58:41 2016] Cypi: yes, that seems to work [Fri Apr 22 03:59:29 2016] is there a good resource that would explain how this works? [Fri Apr 22 03:59:53 2016] eg. what are difference between "Import" and "Require Import" or "Require Export" ? [Fri Apr 22 04:00:20 2016] I only found tutorials on advanced features of module system (functors and so on) [Fri Apr 22 04:01:42 2016] Probably the reference manual. [Fri Apr 22 04:01:50 2016] https://coq.inria.fr/distrib/current/refman/Reference-Manual008.html#compiled and https://coq.inria.fr/distrib/current/refman/Reference-Manual004.html#hevea_command54 [Fri Apr 22 04:03:58 2016] oh, that looks good. I only found the chapter on typing modules [Fri Apr 22 10:58:07 2016] Hello! Is there a way to write a notation that takes a pattern as an argument ? [Fri Apr 22 19:46:47 2016] huh, alafont asked my same question, almost word-for-word [Sun Apr 24 14:01:39 2016] does transfinite induction have a computational interpretation? [Sun Apr 24 14:02:06 2016] oh hmm i think [Sun Apr 24 15:14:46 2016] is it possible to reopen a section in coq [Sun Apr 24 15:15:26 2016] hey hey [Sun Apr 24 15:39:01 2016] what the fuck does "Error: Type not allowed in recursive notation." mean :( [Sun Apr 24 17:26:43 2016] im going to try to implement the Extensive and Normal model of Game Theory... [Sun Apr 24 17:26:48 2016] lets hope something works [Sun Apr 24 17:27:46 2016] well lets first do the Normal form [Sun Apr 24 17:56:27 2016] maybe i should wait with this... [Sun Apr 24 18:37:49 2016] Good day [Sun Apr 24 18:38:03 2016] I compiled last version of Coq. [Sun Apr 24 18:38:20 2016] "coqc -v" gives back normal answer [Sun Apr 24 18:38:29 2016] The Coq Proof Assistant, version 8.5pl1 (April 2016) compiled on Apr 25 2016 0:17:7 with OCaml 4.02.3 [Sun Apr 24 18:39:03 2016] But "coqide &" results in "Error: host:port or stdfds expected after option -control-channel gdk_window_set_icon_list: icons too large Fatal error: exception Failure("The spawned process did not connect back in 2.0s")" [Sun Apr 24 18:40:22 2016] What did I wrong? [Sun Apr 24 18:41:34 2016] * What did I do wrong? [Sun Apr 24 18:53:08 2016] Oh well. [Sun Apr 24 18:53:38 2016] guess its a little late here ;) [Sun Apr 24 18:54:22 2016] Yes, probably. :) [Sun Apr 24 20:53:46 2016] Any coquille users here? [Sun Apr 24 20:56:45 2016] Any idea how much work it would be to patch it to work with Coq 8.5? [Sun Apr 24 22:57:48 2016] hi [Sun Apr 24 22:58:10 2016] I want to do this very much, and might actually be working on this soon [Sun Apr 24 22:58:19 2016] but I'm afraid I don't know how to patch it [Sun Apr 24 22:58:33 2016] and would need to reverse engineer the changes made to figure it out [Mon Apr 25 09:57:48 2016] so here's a question [Mon Apr 25 09:58:19 2016] if i write up the zfc axioms in coq and import LEM, will i get something consistent with classical first-order logic + zfc? [Mon Apr 25 09:58:32 2016] or would i need to manually define FOL within coq? [Mon Apr 25 10:06:06 2016] unrelated question: [Mon Apr 25 10:08:31 2016] i have an inductive type representing untyped lambda terms, whose "variable" constructor contains a nat (de bruijn index). sometimes i want to be able to define recursive functions on terms which additionally recurse on the index of a variable. unfortunately, this means that i have to factor out the var case, since [var n] is not a subterm of [var (S n)] and i can't recurse on it. this tends to complicate [Mon Apr 25 10:08:33 2016] everything, because proving stuff about the functions now requires a whole separate subsection for the separate function. is there a nice approach to this? [Mon Apr 25 10:09:04 2016] one thing i previously tried is having a constructor for [var O] and then having a 'shift' constructor which represents increasing all free variables in the subterm, but that complicates reduction a loooot [Mon Apr 25 11:15:51 2016] yet another question: if i make a section w/ axioms & so on, is there a way to open it back up later in coqtop [Mon Apr 25 11:15:54 2016] or in another file [Mon Apr 25 11:16:39 2016] e.g. i define zfc in a section using [Variable set : Type.]; now i want to be able to reason with [set] in scope from the repl or another file [Mon Apr 25 11:18:48 2016] firstorder is cool :) [Mon Apr 25 14:49:23 2016] I don't think it's possible to reopen a section [Mon Apr 25 14:49:38 2016] modules work I think [Mon Apr 25 14:49:54 2016] but you'd structure it differently [Mon Apr 25 14:50:03 2016] with an "assumptions_sig" module [Mon Apr 25 14:50:11 2016] which both would be parameterized on [Mon Apr 25 14:50:30 2016] But I'm no expert on modules [Mon Apr 25 14:54:44 2016] :( [Mon Apr 25 17:33:14 2016] Hi guys [Mon Apr 25 17:33:36 2016] I'm trying to define an evaluation context. I have this so far, but the fixpoint is not going through [Mon Apr 25 17:33:37 2016] http://pastebin.com/id2t42b5 [Mon Apr 25 17:34:04 2016] Coq complains : [Mon Apr 25 17:34:04 2016] Syntax error: '|' or '=>' expected (in [eqn]). [Mon Apr 25 17:34:20 2016] where am I going wrong? [Mon Apr 25 17:35:02 2016] no comma after evalContext in line 7 [Mon Apr 25 17:35:11 2016] oh, you don't need one, silly me [Mon Apr 25 17:35:47 2016] the evalContext goes through [Mon Apr 25 17:36:00 2016] its the "plug" im trying to define that is broken [Mon Apr 25 17:39:02 2016] titanium17, when I try to run it I get "Error: The constructor Ev_App2 expects 3 arguments." for line 17 [Mon Apr 25 17:39:04 2016] which makes sense [Mon Apr 25 17:39:05 2016] Is that really your current version? It looks like the order of some arguments are reversed between evalContext and plug. Also, could you add the definition of "exp"? [Mon Apr 25 17:39:28 2016] I used this btw: Variable exp: Type. Variable isValue: exp -> Prop. Variable E_App: exp -> exp -> exp. [Mon Apr 25 17:39:36 2016] (I assumed something like "Inductive exp : Type := E_App : exp -> exp -> exp | E_Merge : exp -> exp -> exp.") [Mon Apr 25 17:40:21 2016] Cypi, rrika thanks guys. My exp is quite straightforward --> http://pastebin.com/HvNadMJq [Mon Apr 25 17:41:04 2016] What I mean to do with Ev_App2 is get 2 arguments, and ensure that the first is a value [Mon Apr 25 17:41:11 2016] Maybe my definition is wrong? [Mon Apr 25 17:41:40 2016] your match has "Ev_App2 E' v " [Mon Apr 25 17:42:04 2016] but the signature of Ev_App2 is "forall e, isValue e -> evalContext ->evalContext" [Mon Apr 25 17:42:12 2016] e→E' [Mon Apr 25 17:42:18 2016] isValue e → v [Mon Apr 25 17:42:23 2016] ???? → evalContext [Mon Apr 25 17:42:29 2016] it's complaining that the third binding is missing [Mon Apr 25 17:42:45 2016] http://lpaste.net/161430 >> this goes through, but I have no idea if that's what you want :p (the recursive are missing I guess) [Mon Apr 25 17:43:09 2016] what Cypi said [Mon Apr 25 17:43:43 2016] Err.. I'm not sure about my evalContext definition anymore [Mon Apr 25 17:43:57 2016] Nah, it looks ok [Mon Apr 25 17:44:00 2016] Like I said, I only want Ev_App2 to have 2 arguments, similar to Ev_App1 [Mon Apr 25 17:44:06 2016] but I want the exp to be a value [Mon Apr 25 17:44:21 2016] The proof that it is a value is an argument in itself, you cannot avoid that [Mon Apr 25 17:44:30 2016] you _can_ pack it in a {e : exp | isValue e} [Mon Apr 25 17:45:01 2016] Oh, Cypi so is Ev_App2 now a 3 argument constructor of (exp, proof of value, evalContext)? [Mon Apr 25 17:45:25 2016] or do I lose the exp itself by having that 'isValue e' there? [Mon Apr 25 17:45:55 2016] No, what you said: it takes arguments of type (e : exp), then (isValue e), then (evalContext) [Mon Apr 25 17:46:38 2016] If you want only 2 arguments at all cost, there is the {e : exp | isValue e} solution. [Mon Apr 25 17:46:51 2016] well 3 arguments wont hurt [Mon Apr 25 17:47:00 2016] but I just want to be sure it is actually what I want [Mon Apr 25 17:47:43 2016] I guess 3 arguments makes sense now, If I were to make a Ev_App2 evalContext, I'd have to prove that what I'm giving it is a value in the first place [Mon Apr 25 17:47:50 2016] Thanks Cypi rrika [Mon Apr 25 17:47:57 2016] I shall try something else now! :D [Mon Apr 25 17:51:31 2016] Welp! The error persists.. [Mon Apr 25 17:51:55 2016] Its Strange, even if I have only the Ev_EmptyHole, Coq complains! [Mon Apr 25 17:52:08 2016] Are you sure there is no insecable space or something in there? ^^' [Mon Apr 25 17:52:18 2016] (I don't know...) [Mon Apr 25 17:52:28 2016] Ill retype it and check [Mon Apr 25 17:52:31 2016] non-breaking space* I mean [Mon Apr 25 17:52:34 2016] thanks for your help Cypi [Mon Apr 25 22:05:03 2016] so because im a masochist ive decided to try doing set theory in coq [Mon Apr 25 22:05:23 2016] but coq's logic is not the same as the logic assumed in typical set theory [Mon Apr 25 22:05:28 2016] right?? [Tue Apr 26 04:47:26 2016] i guess that usually the ZFC set theory is stated in the context of classical logic, where you have the law of excluded middle [Tue Apr 26 04:47:39 2016] which you do not have in Coq by default [Tue Apr 26 08:32:13 2016] Hi guys [Tue Apr 26 08:32:36 2016] In coq, I need to talk about finite decreasing sequences [Tue Apr 26 08:32:48 2016] I thought about using functions from nat->option A [Tue Apr 26 08:33:24 2016] And say, that, from a given n, there are only Nones, and that forall m < n, (f m) > (f (S m)) [Tue Apr 26 08:33:55 2016] But it's a bit heavy for my demonstrations [Tue Apr 26 08:34:33 2016] I also thought about using lists, but I don't know how to express that the list is decreasing [Tue Apr 26 08:34:55 2016] Do you have any idea ? (I guess it's easy, but I'm new to coq) [Tue Apr 26 09:32:46 2016] jstolarek pasted “No title” at http://lpaste.net/161598 [Tue Apr 26 09:33:38 2016] I'm trying to write an Ltac procedure to automate the shown proof [Tue Apr 26 09:34:30 2016] for some reason the last step in the match branch - exists (C t') - fails [Tue Apr 26 09:34:35 2016] I have no idea why. Help? [Tue Apr 26 09:40:31 2016] the precise error I get is: "Not an inductive goal with 1 constructor" [Tue Apr 26 09:43:29 2016] oh, got it [Tue Apr 26 09:43:58 2016] arcatan: there's some other things though [Tue Apr 26 09:44:55 2016] arcatan: i'm nowhere near certain, but i think, iirc, you can prove choice from ZF if you use ordinary coq logic [Tue Apr 26 09:45:03 2016] er, wait... hmmm... [Tue Apr 26 09:45:26 2016] ah, i mightve been conflating coq functions with theory-internal functions [Tue Apr 26 09:45:30 2016] now i'm entirely unsure :v [Tue Apr 26 10:12:40 2016] i'd be very surprised if that was the case [Tue Apr 26 10:17:15 2016] Is there any literature (or informal reading) around on implementing guarded-by-destructors/structurally smaller calls for inductive types? I've tried to do so myself based on (Giménez, 1994), but translating the predicate directly to a functional language leads to messy and buggy code. [Tue Apr 26 18:01:56 2016] Is anyone familiar with tools filling the same need as Liquid Haskell but for the Java ecosystem? [Tue Apr 26 18:11:36 2016] GLM: no :( closest thing I can think of would be esc/java [Tue Apr 26 18:18:54 2016] jrw: Do you know if there are any development interests in a project like that? Could be a good side project for me [Tue Apr 26 18:20:10 2016] sounds cool to me! not sure about, like, industry interest or anything. [Tue Apr 26 18:20:47 2016] I would hope there would be enough Java projects to use it on [Tue Apr 26 18:30:59 2016] arcatan: i figured it out, you're right [Tue Apr 26 18:31:24 2016] arcatan: i confused myself b/c i forgot that the axiom schema of specification only gives you comprehension for formulas *in the language of the model* [Tue Apr 26 18:31:41 2016] *of the theory, i guess [Tue Apr 26 18:34:57 2016] Onemorenickname_, are you still there? [Tue Apr 26 18:35:15 2016] rrika, yep [Tue Apr 26 18:35:30 2016] if you have a solution, i could never thank you enough [Tue Apr 26 18:35:46 2016] let me upload it [Tue Apr 26 18:37:32 2016] Onemorenickname_, https://gist.github.com/rrika/2422439491bf7f9a0c22670d87321b17 [Tue Apr 26 18:37:47 2016] if you want an explanation ask ahead [Tue Apr 26 18:38:37 2016] so [Tue Apr 26 18:39:01 2016] when you write forall a [Tue Apr 26 18:39:04 2016] how is a quantified ? [Tue Apr 26 18:39:09 2016] over what ? [Tue Apr 26 18:39:20 2016] oh, I left out the types because they can be inferred [Tue Apr 26 18:39:23 2016] but it'S [Tue Apr 26 18:39:42 2016] forall (a: nat) (b: nat) (c: list nat) (d: decreasing (cons b c)) [Tue Apr 26 18:41:14 2016] Onemorenickname_, should I go over it from top to bottom? [Tue Apr 26 18:41:47 2016] I'm back [Tue Apr 26 18:41:51 2016] so, it's only for nat [Tue Apr 26 18:42:02 2016] well, you can replace the relation ">" by something else [Tue Apr 26 18:42:24 2016] so i give it a set, a relation, and then i can quantify elements over this set, and use this relation [Tue Apr 26 18:42:35 2016] (i'm really new to coq D: ) [Tue Apr 26 18:42:36 2016] Onemorenickname_: yeah :) [Tue Apr 26 18:42:39 2016] yes [Tue Apr 26 18:43:01 2016] then, d0 says that every list of one element is a decreasing [Tue Apr 26 18:43:10 2016] yes [Tue Apr 26 18:43:19 2016] fyi, the set and relation should be parameters rather than indices [Tue Apr 26 18:43:34 2016] benzrf, i only know parameters, what are indices ? [Tue Apr 26 18:43:44 2016] Inductive decreasing : list nat -> Prop [Tue Apr 26 18:43:45 2016] vs [Tue Apr 26 18:43:54 2016] Inductive decreasing (foo: list nat) : Prop [Tue Apr 26 18:44:10 2016] believe it or not, those are semantically different [Tue Apr 26 18:44:14 2016] then, it says that if we have a decreasing list, and a bigger than the first element, then we have an other decreasing list [Tue Apr 26 18:44:23 2016] yes [Tue Apr 26 18:44:28 2016] it's so logic [Tue Apr 26 18:44:34 2016] i feel bad for not having found it ha ha [Tue Apr 26 18:45:13 2016] Onemorenickname_, if you put the "list nat" before the ":" in the first line you'd be talking about a proposition for all lists [Tue Apr 26 18:45:20 2016] but not all lists are decreasing [Tue Apr 26 18:45:23 2016] so you put it after the ":" [Tue Apr 26 18:45:32 2016] that's the difference between parameters and indices [Tue Apr 26 18:45:44 2016] Onemorenickname_: basically, a parameter is a special kind of argument in an Inductive definition, with the property that the type of each constructor must allow you to instantiate the parameter to anything [Tue Apr 26 18:46:37 2016] Onemorenickname_: so you couldn't make your [list nat] a parameter, because your constructors' types specify information about the structure of that argument to their return type, [Tue Apr 26 18:46:58 2016] that's why i couldnt do it [Tue Apr 26 18:47:09 2016] for example, you can't specialize dO to return "decreasing (cons 1 (cons 2 nil))" [Tue Apr 26 18:47:50 2016] if you declare one of your arguments as a parameter, you're forced to let it be instantiatable to anything, in the types of your constructors, but it also changes how the induction principle works [Tue Apr 26 18:47:53 2016] in a way that can be helpful [Tue Apr 26 18:48:27 2016] you can also just leave everything as indices (arguments after the colon), but you may get less helpful induction principles [Tue Apr 26 18:49:24 2016] I see [Tue Apr 26 18:49:34 2016] So, when I can, I put it as a parameter [Tue Apr 26 18:49:58 2016] i'm not experienced enough to tell you if that's *always* a good idea, but i think so [Tue Apr 26 18:50:29 2016] I'll take it with a grain of salt then ^^ [Tue Apr 26 18:50:32 2016] so, consider the type list [Tue Apr 26 18:50:43 2016] er, type constructor, i guess [Tue Apr 26 18:50:51 2016] its constructors are nil and cons [Tue Apr 26 18:51:09 2016] [nil : forall A : Type, list A] and [cons : forall A : Type, A -> list A -> list A] [Tue Apr 26 18:51:49 2016] notice that in both cases, in the final return type of both constructors, it's possible to fill in the first argument to the type as anything you, the user, want [Tue Apr 26 18:52:14 2016] if i have some type X, i can specialize either nil or cons to have a return type of [list X] [Tue Apr 26 18:52:27 2016] although that doesn't mean that i can actually use them [Tue Apr 26 18:52:57 2016] i can specialize cons to have a return type of [list False], but my type is still going to be [False -> list False -> list False], which is unusable [Tue Apr 26 18:53:37 2016] I see [Tue Apr 26 18:53:41 2016] but the point is that since the argument to list is specializable to anything in the return types of its constructors, it can be declared using as a parameter [Tue Apr 26 18:53:48 2016] (of course it can also be declared as an index) [Tue Apr 26 18:54:23 2016] since [dO : forall a, decreasing (cons a nil)], it's impossible to specialize dO to have a return type of [decreasing (cons 1 (cons 2 nil))] [Tue Apr 26 18:54:40 2016] indeed [Tue Apr 26 18:54:40 2016] so that means i can't declare that argument to decreasing using a parameter [Tue Apr 26 18:54:49 2016] we want it to be a certain way [Tue Apr 26 18:54:53 2016] right [Tue Apr 26 18:55:18 2016] btw, i have a question about the sample [Tue Apr 26 18:55:35 2016] when we write (d: decreasing (cons b c) [Tue Apr 26 18:55:48 2016] its syntactic sugar for "decreasing (cons b c)" ? [Tue Apr 26 18:55:59 2016] to declare an argument as a parameter, you put it *before* the colon and give it a name, like in a function definition [Tue Apr 26 18:56:28 2016] then that name is in scope through the whole Inductive declaration, and you *must* use that name as the appropriate argument in the return type [Tue Apr 26 18:56:33 2016] example https://coq.inria.fr/library/Coq.Init.Datatypes.html#list [Tue Apr 26 18:56:50 2016] Onemorenickname_, I use 'd' later in the same line [Tue Apr 26 18:56:52 2016] Onemorenickname_: no, that lets you bind d as the name of the argument [Tue Apr 26 18:56:56 2016] I need to name it [Tue Apr 26 18:57:06 2016] Onemorenickname_: like [forall (n : nat), ...] vs [nat -> ...] [Tue Apr 26 18:57:09 2016] ^ [Tue Apr 26 18:57:56 2016] rrika, i don't see wherei t is used [Tue Apr 26 18:58:18 2016] ah, right, my bad [Tue Apr 26 18:58:24 2016] I could've left it out then [Tue Apr 26 18:58:37 2016] giving it a name that is [Tue Apr 26 18:58:44 2016] forall a b c (d: decreasing (cons b c)), a > b -> decreasing (cons a (cons b c)). [Tue Apr 26 18:58:51 2016] forall a b c, decreasing (cons b c) -> a > b -> decreasing (cons a (cons b c)). [Tue Apr 26 18:59:28 2016] i see [Tue Apr 26 18:59:40 2016] well, thank you for your thorough help [Tue Apr 26 18:59:42 2016] Onemorenickname_: if anything, [foo -> bar] is syntactic sugar for [forall _ : foo, bar] [Tue Apr 26 18:59:45 2016] no problem :) [Tue Apr 26 18:59:59 2016] I'm always happy when random strangers help fellow random strangers [Tue Apr 26 19:01:37 2016] Gives me faith, hope, things like this, or at least joy [Tue Apr 26 19:01:40 2016] :D [Tue Apr 26 19:01:57 2016] the world needs to know about coq [Tue Apr 26 19:02:11 2016] ofc it does [Tue Apr 26 19:02:19 2016] it's like i can truly tell my computer what I think [Tue Apr 26 19:07:39 2016] well [Tue Apr 26 19:07:43 2016] its not like coq is the only proof assistant [Tue Apr 26 19:08:01 2016] the language coq is written in is a descendent of a language created to write tactics for some other ancient proof assistant :D [Tue Apr 26 19:08:13 2016] s/written in/implemented in/ [Tue Apr 26 19:09:39 2016] <_y> so the circle is complete :-) [Tue Apr 26 19:11:34 2016] I feel there is a bit of a gap between the currently available tools and the applications at the moment [Tue Apr 26 19:11:34 2016] maybe I just haven't done enough research yet [Tue Apr 26 19:12:45 2016] before coq, i only knew programming language [Tue Apr 26 19:12:50 2016] or sat [Tue Apr 26 19:16:04 2016] sat? [Tue Apr 26 19:17:02 2016] you put in some boolean equation system, and it solves it [Tue Apr 26 19:19:23 2016] o [Tue Apr 26 19:26:09 2016] (i dont know how its called) [Tue Apr 26 19:26:34 2016] It works ! [Tue Apr 26 19:26:37 2016] Thanks ! [Tue Apr 26 19:28:17 2016] yea! [Tue Apr 26 19:30:49 2016] Basic question [Tue Apr 26 19:30:50 2016] But [Tue Apr 26 19:31:10 2016] Why "hd" is not defined in the current environment ? [Tue Apr 26 19:32:07 2016] found [Tue Apr 26 19:32:13 2016] i opened the wrong thing [Tue Apr 26 19:32:47 2016] If you do "Require Import List." you'll have "hd" [Tue Apr 26 19:35:06 2016] rrika, yep ! [Tue Apr 26 19:35:17 2016] but i get an error i dont understand [Tue Apr 26 19:35:30 2016] there return type of hd (x: list A) is not A ? [Tue Apr 26 19:36:41 2016] Yes it is. But it is also expecting something to return if the list is empty [Tue Apr 26 19:38:49 2016] the 'hd' in 'List' will take a default value before taking the list, so it can return an 'A' in any case [Tue Apr 26 19:38:53 2016] hd 3 [] = 3 [Tue Apr 26 19:38:57 2016] hd 3 [99] = 99 [Tue Apr 26 19:39:23 2016] Onemorenickname_, can you show us the result of "Check hd."? [Tue Apr 26 19:40:03 2016] A -> list A -> A [Tue Apr 26 19:40:16 2016] I thought I had to pass it A, in fact it was a proof of A [Tue Apr 26 19:40:42 2016] indeed [Tue Apr 26 19:41:07 2016] However, I dont understand Check hd(0,cons(2,cons(False, nil))). [Tue Apr 26 19:41:47 2016] no () [Tue Apr 26 19:41:54 2016] or rather no "," [Tue Apr 26 19:42:57 2016] oh [Tue Apr 26 19:42:59 2016] .-. [Tue Apr 26 19:44:24 2016] That's the trouble coming from more imperative programming languages: you're used to parentheses for function calls. In Coq you would write this "hd 0 (cons 2 (cons False nil))" [Tue Apr 26 19:44:38 2016] Function application is just the space between two terms, no need for parentheses [Tue Apr 26 19:44:49 2016] In fact, I'm used to Ocaml [Tue Apr 26 19:44:52 2016] Oh x) [Tue Apr 26 19:44:54 2016] It's because of the forall , , [Tue Apr 26 19:45:24 2016] well, because of forall, exists, forall etc. [Tue Apr 26 19:45:41 2016] so i got mixed up (i'm easily confused, if you didnt notice :D) [Tue Apr 26 19:46:12 2016] strange Coq's tutorial says "We shall now prove a well-known fact from first-order logic: a universal pred- [Tue Apr 26 19:46:15 2016] icate is non-empty, or in other terms existential quantification follows from univer- [Tue Apr 26 19:46:19 2016] sal quantification." [Tue Apr 26 19:46:20 2016] sorry [Tue Apr 26 19:46:44 2016] and then they define a element in the Set and proof it :P [Tue Apr 26 19:48:27 2016] x) [Tue Apr 26 19:48:34 2016] oh because that is needed in Coq [Tue Apr 26 19:48:53 2016] But in classic logic a universal predicate is non-empty? [Tue Apr 26 19:53:14 2016] link? [Tue Apr 26 19:53:49 2016] https://coq.inria.fr/distrib/V8.5pl1/files/Tutorial.pdf [Tue Apr 26 19:55:43 2016] I never met a predicate that I didn't either like or dislike. [Tue Apr 26 19:59:03 2016] hm i think im under standing the Drinker "paradox" [Tue Apr 26 20:00:35 2016] Theorem johnw_pref_dec (p: Predicate) : {likes p} + {¬likes p}. [Tue Apr 26 20:01:38 2016] More like the double-negation of this [Tue Apr 26 20:02:01 2016] quadruple negation of it [Tue Apr 26 20:02:37 2016] That's the same thing :p [Tue Apr 26 20:02:45 2016] ;p [Tue Apr 26 20:02:49 2016] really? [Tue Apr 26 20:03:04 2016] Yes [Tue Apr 26 20:03:16 2016] [forall P, ~~~P -> ~P] is provable [Tue Apr 26 20:03:27 2016] oke [Tue Apr 26 20:03:43 2016] btw, I do not understand "universal predicate is non-empty" [Tue Apr 26 20:03:43 2016] ~~P -> P? [Tue Apr 26 20:03:53 2016] Nik05 : this is classical [Tue Apr 26 20:04:08 2016] if we pick an empty set, then, forall x : P x is true, but exists x : P x is false [Tue Apr 26 20:04:09 2016] (so not provable in Coq without axioms) [Tue Apr 26 20:06:40 2016] ah right [Tue Apr 26 20:10:18 2016] rrika: ;) [Tue Apr 26 20:17:59 2016] rrika, you're doing induction, and not the math kind [Tue Apr 26 20:18:07 2016] surely you can't generalize to that from his statement [Tue Apr 26 20:19:02 2016] hey all [Tue Apr 26 20:19:11 2016] I have a question that may need a clever and as yet unknown to me tactic [Tue Apr 26 20:21:51 2016] there are people online lingxiao ;) [Tue Apr 26 20:22:25 2016] oh wow awesome ok i'll send the link [Tue Apr 26 20:22:53 2016] https://github.com/lingxiao/CIS500/blob/master/hw12/Sub.v#L1147 [Tue Apr 26 20:23:18 2016] there are a bunch of cases that are clearly false but i could not prove them so [Tue Apr 26 20:24:05 2016] some help would be really helpful :D [Tue Apr 26 20:26:22 2016] hm you are way a head from me now :P [Tue Apr 26 20:27:51 2016] lingxiao: 你的名字的意思是什么？ [Tue Apr 26 20:28:27 2016] means I can't do coq that's what it means :( [Tue Apr 26 20:30:14 2016] i tried to find 'ling xiao' but nothing [Tue Apr 26 20:31:10 2016] have a good night everyone [Tue Apr 26 20:31:18 2016] night [Tue Apr 26 20:32:16 2016] lingxiao: would mind pasting the context for one of the cases that you want to prove is false? [Tue Apr 26 20:33:10 2016] jrw here: http://lpaste.net/161635 [Tue Apr 26 20:33:47 2016] how does S = TProd T1 T2 relate to S <: TProd T1 T2? [Tue Apr 26 20:33:56 2016] if you can establish identity between them, it is trivially proven [Tue Apr 26 20:34:12 2016] otherwise, maybe your induction hypothesis is too general [Tue Apr 26 20:34:17 2016] it means TProd T1 T2 <: S [Tue Apr 26 20:34:22 2016] but how does that help me? [Tue Apr 26 20:35:24 2016] well, from your context you need to show that S = TProd T1 T2 [Tue Apr 26 20:35:32 2016] because you have all the other pieces of evidence that you need [Tue Apr 26 20:35:52 2016] either that, or redo your induction so that it's not generalized over that equality (if that's even possible) [Tue Apr 26 20:36:21 2016] well i thought the rpoblem is that i need to show tabs x T0 t0 = tpair t1 t2 [Tue Apr 26 20:36:24 2016] which is clearly false [Tue Apr 26 20:36:34 2016] so i need a way to prove that [Tue Apr 26 20:36:43 2016] that's easy though [Tue Apr 26 20:36:46 2016] I have Gamma |- tabs x T0 t0 \in S <: S <: TProd T1 T2 [Tue Apr 26 20:36:46 2016] lingxiao: well the conclusion of your IH is also a contradiction [Tue Apr 26 20:36:48 2016] it's in your induction hypothesis [Tue Apr 26 20:36:57 2016] yeah so I apply induction hypothesis and get : [Tue Apr 26 20:36:58 2016] exact (IHHt ? Hv). [Tue Apr 26 20:37:07 2016] the ? is what we can't provide [Tue Apr 26 20:37:08 2016] lingxiao: have you tried using the lemma [sub_inversion_prod]? [Tue Apr 26 20:37:10 2016] http://lpaste.net/161636 [Tue Apr 26 20:37:16 2016] exactly [Tue Apr 26 20:37:28 2016] lingxiao: this is what I've been saying [Tue Apr 26 20:37:52 2016] let me see if I can build this here [Tue Apr 26 20:38:16 2016] not a small repo [Tue Apr 26 20:38:28 2016] jrw I need canonical forms of pair in sub inversion prod [Tue Apr 26 20:38:38 2016] yeah .. haha :( thanks for trying to buidl it [Tue Apr 26 20:38:56 2016] yeah so im not sure how to to show that S :> TProd t1 t2 [Tue Apr 26 20:39:23 2016] imean theres not reason why that should even be true [Tue Apr 26 20:39:26 2016] isn't it the other way around? [Tue Apr 26 20:39:44 2016] ok, I'm at that goal lingxiao [Tue Apr 26 20:39:51 2016] awesome thanks johnw! [Tue Apr 26 20:40:16 2016] lingxiao: before your induction, do "clear HeqT" [Tue Apr 26 20:40:23 2016] then that goal will be trivial [Tue Apr 26 20:40:59 2016] well but that will make other cases impossible [Tue Apr 26 20:41:04 2016] true [Tue Apr 26 20:41:11 2016] but I hadn't been asked about those yet :) [Tue Apr 26 20:41:34 2016] lingxiao: I can't get to a point that shows exactly the goal you're looking at [Tue Apr 26 20:41:41 2016] do you have a different version of this proof now? [Tue Apr 26 20:41:57 2016] oh, I see [Tue Apr 26 20:42:03 2016] never, just doing the clear is not enough [Tue Apr 26 20:42:04 2016] johnw ok i did clear HeqT. [Tue Apr 26 20:42:07 2016] what about starting from the top and doing inversion on the [value s] hypothesis [Tue Apr 26 20:42:51 2016] trying [Tue Apr 26 20:43:03 2016] ok looking at this: http://lpaste.net/161637 [Tue Apr 26 20:43:09 2016] oh boy ok i can try that [Tue Apr 26 20:45:29 2016] oh, yeah sub_inversion_prod [Tue Apr 26 20:45:48 2016] ok hmm intersting .. [Tue Apr 26 20:45:48 2016] http://lpaste.net/161638 [Tue Apr 26 20:46:00 2016] but inversion on Ht does me no good [Tue Apr 26 20:46:16 2016] it should be false so gets rid of case for me [Tue Apr 26 20:50:12 2016] johnw any progress? what did you mean by sub_inversion_prod [Tue Apr 26 20:51:05 2016] n/m me [Tue Apr 26 20:51:09 2016] i don't understand this code well enough [Tue Apr 26 20:52:48 2016] yeah boy this one is tough [Tue Apr 26 20:53:26 2016] lingxiao: what about this: https://gist.github.com/9c1b12df2bc1afceb0a22ca16cd19383 [Tue Apr 26 20:53:29 2016] does that look solvable to you? [Tue Apr 26 20:54:42 2016] no the problem is this: Ht : Gamma |- tabs x T t \in TProd T1 T2 [Tue Apr 26 20:55:07 2016] inversion on this does not falsify [exists t1 t2 : tm, tabs x T t = tpair t1 t2] [Tue Apr 26 20:55:12 2016] as it should without subtyping [Tue Apr 26 20:55:19 2016] but subtyping complictest things [Tue Apr 26 21:00:14 2016] does that make sense johnw? [Tue Apr 26 21:00:25 2016] yeah, so I'm afraid I'm not much help here [Tue Apr 26 21:01:29 2016] Wow so many Chinese speaker here? another here. [Tue Apr 26 21:01:32 2016] yeah :( thanks though! [Tue Apr 26 21:01:52 2016] benzrf: I guess lingxiao is just the pinyin of his/her name. [Tue Apr 26 21:02:12 2016] yeah it is [Tue Apr 26 21:02:15 2016] i was really creative here [Tue Apr 26 21:02:50 2016] o [Tue Apr 26 21:03:17 2016] yup [Tue Apr 26 21:05:00 2016] lingxiao: is this solvable: https://gist.github.com/23f0225fe0c6c0e1f3c47d56832c6cf7 [Tue Apr 26 21:46:52 2016] johnw i beleive it is?! [Tue Apr 26 21:46:59 2016] coudl i ask how you got there? [Tue Apr 26 22:47:05 2016] Hi everyone. I’m trying to port Agda code to Coq and ran into a problem. I’ve implented the `thin` function here https://github.com/pepijnkokke/FirstOrderUnificationInAgda/blob/master/Unification.agda#L97 like this: http://lpaste.net/161648 but it doesn’t typecheck for some reason. [Tue Apr 26 22:47:12 2016] What am I doing wrong? [Tue Apr 26 23:47:08 2016] tosun: er, [Tue Apr 26 23:47:12 2016] shouldnt you be matching on n? [Tue Apr 26 23:47:22 2016] oh, wait [Tue Apr 26 23:49:58 2016] tosun: i really, really, really doubt this will do anything, but just out of curiosity, could you try flipping x and y in the match? [Tue Apr 26 23:50:09 2016] so you match on y, x and then flip the patterns accordingly [Tue Apr 26 23:57:30 2016] benzrf: I did, now getting this: http://lpaste.net/161652 [Tue Apr 26 23:58:02 2016] benzrf: that wasn’t supposed to change anything though [Tue Apr 26 23:58:14 2016] yeah :X [Tue Apr 26 23:58:28 2016] (i'm pretty amateur at coq fyi) [Wed Apr 27 00:01:05 2016] benzrf: maybe I’m getting the behavior of `match x,y with` wrong since that did change something. [Wed Apr 27 00:03:01 2016] mhm [Wed Apr 27 00:03:18 2016] uh [Wed Apr 27 00:03:20 2016] what does thin do exactly [Wed Apr 27 00:03:25 2016] im kind of tired and having trouble thinking it through [Wed Apr 27 00:57:42 2016] benzrf: it’s kind of complicated [Wed Apr 27 00:57:58 2016] benzrf: it “collects the other n elements of Fin sn as the image of an embedding, thin x from Fin n, “diluting” Fin n with x” [Wed Apr 27 00:58:29 2016] benzrf: explained in McBride’s paper “first-order unification by structural recursion” [Wed Apr 27 13:33:56 2016] do they read their own tutorial? on page 40 below "Oops!", that part is obsolete [Wed Apr 27 13:35:38 2016] Ahah, indeed [Wed Apr 27 13:36:25 2016] Well, either something about typing or Check got changed, and they didn't think of looking at that part in the tutorial [Wed Apr 27 13:49:30 2016] will make a bugreport later :P [Wed Apr 27 14:29:00 2016] Onemorenickname_: Inductive foo : value -> Prop | bar : forall v, is_good v -> foo v [Wed Apr 27 14:29:04 2016] I think that works [Wed Apr 27 14:29:31 2016] I'm not sure if it should be in Prop or Set [Wed Apr 27 17:34:47 2016] do we have a coqbot like geordi or the haskell bot? [Wed Apr 27 17:36:26 2016] What would that bot do? [Wed Apr 27 17:36:55 2016] today i tried to show coq to one of the math teachers at my school [Wed Apr 27 17:37:06 2016] i mean i *did* show him it, but, [Wed Apr 27 17:37:18 2016] i somehow decided that a good thing to go with was proving uniqueness of inverses in a group [Wed Apr 27 17:37:33 2016] and i ended up confusing myself about the algebra >.> [Wed Apr 27 17:37:50 2016] not to mention that equality is one of the subtler aspects of coq [Wed Apr 27 17:38:30 2016] How did you go? Have you axiomatized group theory? Or something else? [Wed Apr 27 17:39:05 2016] defined a module type containing a type and operation and axioms, then parameterized another module over it [Wed Apr 27 17:40:19 2016] oooooh i figured out how i tripped up [Wed Apr 27 17:40:51 2016] when i wrote down the algebra with conventional reasoning i did some standard habitual elisions [Wed Apr 27 17:41:06 2016] then i confused myself b/c i forgot that i couldn't apply an axiom or tactic to jump immediately to the next stage [Wed Apr 27 18:21:56 2016] Cypi dont know really :P guess it can only show basic stuff [Wed Apr 27 18:22:44 2016] I mean, what do geordi or the haskell bot do? ^^' [Wed Apr 27 18:38:17 2016] is there a coq api at all? [Wed Apr 27 18:38:33 2016] weeeell... [Wed Apr 27 18:38:37 2016] is it embeddable [Wed Apr 27 18:38:44 2016] can i use only some parts of it [Wed Apr 27 19:54:08 2016] Nik05 : in case you do plan to make a bug report, you can mention that https://github.com/coq/coq/commit/cfff8f introduced this discrepancy. (For some reason, since then, Check performs beta-iota reduction on the type of the term.) [Wed Apr 27 19:54:19 2016] [yay git-bisect] [Thu Apr 28 07:51:32 2016] thank you Cypi :) [Thu Apr 28 07:52:30 2016] i think i red another obsolete text somewhere [Thu Apr 28 07:54:27 2016] huh i think i already filed a bug before... dont know my adres :( [Thu Apr 28 07:54:44 2016] or maybe it was anonymous [Thu Apr 28 07:54:51 2016] oh no its not [Thu Apr 28 08:07:30 2016] Cypi found another one [Thu Apr 28 08:34:39 2016] hi guys, can anyone recommend some materials on Ltac? as in tutorials? [Thu Apr 28 09:14:52 2016] lorozic: chapters 14 and 15 (IIRC) of CPDT ? [Thu Apr 28 09:20:44 2016] jstolarek pasted “No title” at http://lpaste.net/161716 [Thu Apr 28 09:21:17 2016] I am struggling with this silly error. I have absolutely no idea why this gives me a syntax error, especially that the code is copied from Software Foundations [Thu Apr 28 09:25:32 2016] oh, got it. Notations again :-/ [Thu Apr 28 09:44:59 2016] jstolarek: already seen that one but didn't sit well for some reason. I'll give it another chance. [Fri Apr 29 04:42:23 2016] Hi, is there a way to add hints to make Coq work better with conjunction? For example I want it to prove A /\ B -> B /\ A with just auto.. [Fri Apr 29 04:42:54 2016] "Hint Constructors and" does a bit in this sense, I don't need to do split. However can I add a hint to destruct conjunctions? [Fri Apr 29 07:25:24 2016] Maybe add proj1/proj2 as hints? [Fri Apr 29 08:07:28 2016] Is there any knowledgeable person about writing a plugin for Coq in OCaml? Specifically, my question is: I have a [constr] with some evars, and I know that one of these evars could be determined uniquely from the type (just what "refine" would do if it was a hole). How can I get the inference mechanism to resolve the content of this evar for me? [Fri Apr 29 17:14:36 2016] Is there some centralized repository of theories formalized in Coq? :-O [Fri Apr 29 17:16:24 2016] no [Fri Apr 29 17:16:41 2016] lots of repositories of theories, but opam is the closest you'll get, and I doubt it aggregates even the majority of them [Fri Apr 29 17:16:49 2016] Ah... [Fri Apr 29 17:23:52 2016] I want an existing formalization of System Fω, to see if I can extend it as proposed here: http://cstheory.stackexchange.com/questions/34567/ (incomplete sketch) [Fri Apr 29 17:24:12 2016] system fc has been formalized [Fri Apr 29 17:30:38 2016] System FC seems to have a feature that I don't really want or need (first-class type equality witnesses), and I have no idea how this would interact with subtyping. :-| [Fri Apr 29 20:00:04 2016] in A tutorial on [co-]inductive types in coq [Fri Apr 29 20:00:33 2016] what are they doing on page 16 (3.2.1 example) [Fri Apr 29 20:00:58 2016] they define pred_spec with set notation, and then define `predecessor`, what is happening there? [Fri Apr 29 20:04:34 2016] It seems like they first define the spec of the `predecessor` function, so what should be the relationship between its input and its output [Fri Apr 29 20:04:57 2016] and then they define the `predecessor` function itself, while proving that it conforms to this spec. [Fri Apr 29 20:06:29 2016] oh pred_spec is not a function? [Fri Apr 29 20:08:16 2016] Well, it is a function, that takes an argument (n : nat), and returns the expect return type of the `predecessor` function. [Fri Apr 29 20:08:58 2016] They could have written directly "Definition predecessor : forall (n : nat), {m : nat | n = 0 /\ m = 0 \/ n = S m}." [Fri Apr 29 20:09:39 2016] To be clearer: pred_spec is a function, but it is certainly not a function that computes the predecessor of an integer. It's just a function that returns a type. [Fri Apr 29 20:10:05 2016] returns just a type oh [Fri Apr 29 20:10:52 2016] what type does it return? [Fri Apr 29 20:11:05 2016] It returns the type {m : nat | n = 0 /\ m = 0 \/ n = S m} [Fri Apr 29 20:11:13 2016] This is its definition. [Fri Apr 29 20:22:16 2016] I'm defining a theory with multiple sorts (variances, kinds, types with kind K), and I want each sort to have an associated partial order relation. However, calling these types “v_inclusion”, “k_inclusion” and “t_inclusion” quickly gets annoying. Is there some way I can reuse the name “inclusion” for all three relations? [Fri Apr 29 20:25:00 2016] Could you help me read this line? [Fri Apr 29 20:25:02 2016] match A as X return int_type2 X -> term X with ... end. [Fri Apr 29 20:25:35 2016] I’m not sure what “return” does there [Fri Apr 29 20:26:15 2016] mietek: It's the return type of the whole “match” expression. [Fri Apr 29 20:26:38 2016] Line 136 of https://www.lri.fr/~keller/Documents-etudes/Categories/godel.v [Fri Apr 29 20:27:13 2016] (which is a formalisation of Coquand-Dybjer 1993) [Fri Apr 29 20:27:33 2016] 1997* [Fri Apr 29 20:27:50 2016] (https://www.dropbox.com/s/aam7zd1b2is3qe2/CoquandDybjer1997.pdf if anyone is curious) [Fri Apr 29 20:28:46 2016] pyon: doesn’t this basically restate the line above? [Fri Apr 29 20:28:58 2016] Fixpoint quote (A: type) : int_type2 A -> term A := [Fri Apr 29 20:28:58 2016] match A as X return int_type2 X -> term X with [Fri Apr 29 20:29:39 2016] If so, why is it significant to write it this way? [Fri Apr 29 20:30:06 2016] (I speak Agda reasonably fluently) [Fri Apr 29 20:31:31 2016] mietek: I don't really know either Coq or Agda terribly well, but IIUC, Coq's type inference is “less smart” than Agda's. [Fri Apr 29 20:31:44 2016] Ah. [Fri Apr 29 20:31:52 2016] mietek: Consider what would happen if instead of “match A”, you had “match complicated_expression”. [Fri Apr 29 20:32:15 2016] Guiding type inference makes sense, I suppose. [Fri Apr 29 20:32:19 2016] Thanks. [Fri Apr 29 20:32:20 2016] Yep. [Fri Apr 29 22:11:12 2016] Is there some way to tell Coq not to use the standard library, except for a few primitives (Set, Prop, function types)? [Fri Apr 29 22:17:55 2016] Also, is there some way to define an Inductive type and a notation for it simultaneously? [Fri Apr 29 23:08:59 2016] Is there some command for checking which notations are in scope? [Fri Apr 29 23:09:16 2016] Or for expanding an expression containing notations into an expression not containing them. [Sat Apr 30 01:13:03 2016] Why can't I do “fun (x, y) => ...” to define an anonymous function of a tuple? [Sat Apr 30 01:14:09 2016] I want to do the equivalent of the following OCaml code: “List.map (fun (k, v) -> k, v_inv v)”. [Sat Apr 30 04:40:54 2016] hello, what 's the relation between the underlying theories of NuPRL and Coq? I 'm really confused. [Sat Apr 30 04:41:42 2016] One is "Computational type theory" and the other "Calculus of construction", both of which seems related to MLTT. [Sat Apr 30 06:49:26 2016] thank you cypi [Sat Apr 30 06:51:32 2016] still dont get it [Sat Apr 30 06:51:36 2016] haha [Sat Apr 30 11:03:03 2016] Cypi so the type of pred_spec is nat -> { m : nat | n = 0 /\ m = 0 \/ n = S m } [Sat Apr 30 11:03:30 2016] and the type of predecessor is forall n : nat, pred_spec n [Sat Apr 30 11:03:47 2016] i dont see what the purpose is of predecessor [Sat Apr 30 11:08:10 2016] Ah non x) [Sat Apr 30 11:08:16 2016] The type of pred_spec is nat -> Set [Sat Apr 30 11:08:37 2016] Its definition is "pred_spec n := { m : nat | n = 0 /\ m = 0 \/ n = S m } [Sat Apr 30 11:09:01 2016] yes? [Sat Apr 30 11:09:43 2016] but none of these give you the answer like pred 10 = 9 or somethign [Sat Apr 30 11:09:51 2016] predecessor does! [Sat Apr 30 11:10:11 2016] = exist [Sat Apr 30 11:10:11 2016] (fun m : nat => 10 = 0 /\ m = 0 \/ 10 = S m) [Sat Apr 30 11:10:11 2016] 9 (or_intror eq_refl) [Sat Apr 30 11:10:13 2016] : pred_spec 10 [Sat Apr 30 11:10:22 2016] well there is a 9 in there but :P [Sat Apr 30 11:10:28 2016] More precisely, "predecessor 10" would evaluate to the pair formed by 9 and a proof that 9 is the predecessor of 10 [Sat Apr 30 11:10:39 2016] oh oke [Sat Apr 30 11:11:07 2016] so 9 is the predecessor and (or_intror eq_refl) is the proof? [Sat Apr 30 11:11:15 2016] You can see it in the term you quoted. There is a 9, and "or_intror eq_refl" has the type "10 = 0 /\ 9 = 0 \/ 10 = S 9" [Sat Apr 30 11:11:19 2016] yes! [Sat Apr 30 11:11:22 2016] ah oke [Sat Apr 30 11:11:56 2016] oh maybe im getting it [Sat Apr 30 11:12:01 2016] needs to sink in :P [Sat Apr 30 11:14:13 2016] thank you Cypi :) [Sat Apr 30 12:32:01 2016] when is this helpful? [Sat Apr 30 13:35:35 2016] oh i hadnt noticed but only predecessors type is defined [Sat Apr 30 14:19:09 2016] oh wow my brain [Sat Apr 30 14:19:18 2016] same for the le_lt_dec, mind is blown [Sat Apr 30 19:20:33 2016] Is there some way to “overload notations”? [Sat Apr 30 19:40:06 2016] sure [Sat Apr 30 19:40:12 2016] they can each be in a different scope [Sat Apr 30 19:40:18 2016] and scopes can be triggered on the type context [Sat Apr 30 19:54:06 2016] Scopes are associated to individual types, right? [Sat Apr 30 19:54:38 2016] I'd like to select notations based on the expected type of an expression. [Sat Apr 30 19:57:55 2016] they can be [Sat Apr 30 19:58:01 2016] yeah, that's right [Sat Apr 30 19:58:07 2016] you "delimit" the scope based on a type [Sat Apr 30 19:58:12 2016] and if the expression has that type, it'll use that scope [Sat Apr 30 19:58:31 2016] plus, you can switch scopes manually anywhere [Sat Apr 30 19:58:33 2016] (foo)%scope [Sat Apr 30 19:58:39 2016] or: Open Scope foo_scope. [Sat Apr 30 19:58:49 2016] Ah, nice. [Sat Apr 30 20:06:08 2016] Okay, so this is what I have so far: https://gist.github.com/eduardoleon/2d2c93892b70cbebb6823f567f5d8225 . Coq's complaining that the scope “var” doesn't exist. :-| [Sat Apr 30 20:06:33 2016] right, you haven't declared that scope [Sat Apr 30 20:06:58 2016] Delimit Scope var_scope with var. [Sat Apr 30 20:07:16 2016] Oh. [Sat Apr 30 20:07:18 2016] Bind Scope var_scope with var. [Sat Apr 30 20:07:26 2016] Delimit gives you %var [Sat Apr 30 20:07:31 2016] And Bind? [Sat Apr 30 20:07:34 2016] Bind associates var_scope with expressions of type var [Sat Apr 30 20:07:44 2016] i.e., implicit delimiting [Sat Apr 30 20:07:51 2016] Ah, makes sense! [Sun May 1 13:43:51 2016] To the people familiar with the calculus of inductive constructions: is there informal reading on implementing guarded-by-destructors (Giménez, 1994) out there? I've tried to translate the predicate from the paper to Haskell, but as I don't fully understand it yet, failed. 😝 [Mon May 2 04:19:42 2016] hi! I am sort of stuck with a proof in coq and was hoping someone could help me: http://pastie.org/private/syosbfctgnvt5jlkjjt5zg [Mon May 2 04:20:14 2016] natlist is a list of nat and I am trying to rewrite the goal so that "n ::" is outside of the two "rev" invocations [Mon May 2 04:20:35 2016] I spent hours on this already and just get stuck all the time [Mon May 2 04:20:52 2016] (rev reverses a list) [Mon May 2 04:24:24 2016] have you looked at Lists/List.v in the coq distribution? [Mon May 2 04:26:22 2016] no I haven't [Mon May 2 04:27:26 2016] I shall take a look [Mon May 2 04:30:02 2016] thanks! I think rev_unit looks very much like what I was missing [Mon May 2 05:37:00 2016] hello phdoerfler has quit [Mon May 2 06:42:18 2016] oh wow i just found out that the syntax for a proof is "Theorem Name : What to proof" ... -_- [Mon May 2 06:42:26 2016] as in Name has type what to proof [Mon May 2 09:42:06 2016] i have a mutual inductive declaration [Mon May 2 09:42:36 2016] i'm trying to define something which destructs on type A, getting out a B, then destructs on the B, getting out an A, which I recurse on [Mon May 2 09:42:41 2016] how do i do that? [Mon May 2 09:46:30 2016] oh - i tried actually googling >w> [Mon May 2 10:01:44 2016] Anyone familliar with Hott? Do I have to learn a lot about Algebraic topology before I read the Hott book? [Mon May 2 10:02:10 2016] riaqn: i don't know as much about hott as i would like to [Mon May 2 10:02:29 2016] i think you'd get more out of hott if you knew AT, kind of like how you get more out of category theory if you know a few fields of math already [Mon May 2 10:02:48 2016] but that's not based on much, so trust probably literally anybody else ove rme [Mon May 2 10:03:20 2016] benzrf: Yeah, but I get lost even before chapter 2. I don't understand the path induction. [Mon May 2 10:03:50 2016] algebraic topology often tends to be extremely algebraic [Mon May 2 10:03:57 2016] namely, it's stated that not all terms in eq is refl. [Mon May 2 10:04:09 2016] i think (again, trust probably literally anybody else over me) hott is kind of, like [Mon May 2 10:04:36 2016] benzrf: well I 'm not math genius and I 'm still learning point set topology. I guess I have to learn algebraic after that. [Mon May 2 10:04:37 2016] *only* algebraic, but the algebra involved is stuff that's mostly inspired by or useful-in-the-context-of algebraic topology that does involve some topology [Mon May 2 10:04:55 2016] riaqn: if you're interested in math i'd really recommend branching out more and doing less of the kind of [Mon May 2 10:05:21 2016] "i have a Driving Goal which is extremely advanced and i'm taking the shortest path thru the topic graph to that goal" [Mon May 2 10:06:25 2016] huh, that was I think.(and still thinking). Although I don't have such a roadmap for Hott. So I'm learning from the very begining all the things. [Mon May 2 10:06:28 2016] i was kind of doing that a while back and then i realized that it's better in a number of ways to reorient yourself with math in general as what you're working at, and then follow a broader & more convnentional path, while maybe being guided a little bit by HoTT or whatever [Mon May 2 10:06:59 2016] and now ive learned that manifolds are fun even when they have nothing at all to do with types :-) [Mon May 2 10:07:40 2016] just learn math, and maybe add a specific topic every so often if it happens to be within reach and happens to lead toward whatever you originally were interested in [Mon May 2 10:07:50 2016] yeah now I think learning more math(any kind) is always good for every STEM students. [Mon May 2 10:08:02 2016] hmmmm, i dunno [Mon May 2 10:08:09 2016] i think its more complex than that [Mon May 2 10:08:20 2016] huh, at least for theoretical CS. [Mon May 2 10:08:23 2016] pure math isnt so directly applicable to any other STE field [Mon May 2 10:11:40 2016] so hows point-set going [Mon May 2 10:12:01 2016] i cant say im a huge fan of topology that isnt somehow tied to the reals [Mon May 2 10:12:08 2016] (that i've seen, anyway) [Mon May 2 10:12:36 2016] Well I 'm just begining and I 'm using munkres 2nd. Just learnd the metric topology. [Mon May 2 10:12:51 2016] to be honest I don't see the connection to the type theory. [Mon May 2 10:14:10 2016] I think the person who related these two things must have some imagination. [Mon May 2 10:14:52 2016] well, it's kind of like you're learning arithmetic because algebra makes the most sense when you start off of arithmetic and you want to know algebra because you're working up to understanding finite fields so you can talk about crypto [Mon May 2 10:14:55 2016] :) [Mon May 2 10:15:12 2016] there's entire branches of math that stem off from where you are, and one of them has some parts that are connected [Mon May 2 10:17:44 2016] benzrf: let's see if I can relates these things finally. :) [Mon May 2 10:18:27 2016] riaqn: have you been fully absorbing what you're reading or have you been "skimming to get to the point" [Mon May 2 10:19:23 2016] benzrf: I read all theorems, proofs, and did ever exercise. [Mon May 2 10:20:19 2016] of course there were some exercise too hard, in which case I search it on the web, understand it and paraphase it myself. [Mon May 2 10:20:49 2016] nice! [Mon May 2 10:21:30 2016] yeah otherwise I may just "float" on the text and get lost halfway. I had such experience. [Mon May 2 10:21:42 2016] exercise is vital. [Mon May 2 10:21:46 2016] would i be correct in guessing that the definition of topological spaces is maybe a little seemingly pointless, or? [Mon May 2 10:23:21 2016] yes in the begining. But after seeing the real analysis as a special case of topology, I thought it's really cool. [Mon May 2 10:31:37 2016] neat [Mon May 2 10:31:48 2016] i was just gonna mention an alternative formulation of topologies that i like [Mon May 2 17:31:05 2016] why do matches sometimes fail to release a definitional equality [Mon May 2 17:33:55 2016] have you read CPDT? [Mon May 2 17:35:01 2016] if I understand your meaning of "release" correctly [Mon May 2 17:35:23 2016] i have not :> [Mon May 2 17:35:37 2016] I'll start answering questions again after you have :) [Mon May 2 17:35:55 2016] but i keep wanting to write things as expressions rather than with tactics, and I'm unable to because things wont unify [Mon May 2 17:35:56 2016] :( [Mon May 2 17:36:10 2016] hello benzrf and johnw [Mon May 2 17:36:11 2016] now you know where the answer is :) [Mon May 2 17:36:20 2016] man [Mon May 2 17:36:28 2016] i just wanna do some set theory in coq [Mon May 2 17:36:30 2016] not all this [Mon May 2 17:36:33 2016] "dependent types" shit [Mon May 2 17:37:50 2016] smdh [Mon May 2 17:37:51 2016] fwiw, what you're asking about is answered by the "convey pattern" [Mon May 2 17:37:57 2016] which CPDT covers in like 6 places [Mon May 2 17:38:03 2016] convoy pattern [Mon May 2 17:38:11 2016] maybe i should check out agda one of these days [Mon May 2 17:38:15 2016] hi Nik05! [Mon May 2 17:38:26 2016] i hear it's possible to write functions in it the normal way without ripping your hair out [Mon May 2 17:38:28 2016] agda is good at straight up dependently typed programming [Mon May 2 17:38:38 2016] their dot patterns especially are cool [Mon May 2 17:39:00 2016] i'll probably *have* to check it out anyway if im gonna be using it as an embedded thingy [Mon May 2 17:39:04 2016] which i vaguely plan to [Mon May 2 17:40:17 2016] coinductive types are defined as the terminal type-equipped-with-a-destructor for the destructor implied by the constructors you list, yeah? [Mon May 2 17:40:42 2016] i really don't know what you just said [Mon May 2 17:40:47 2016] uh [Mon May 2 17:40:48 2016] wel [Mon May 2 17:40:50 2016] *well [Mon May 2 17:41:20 2016] arent inductive types characterized as initial objects in a category of diagrams of their constructors [Mon May 2 17:42:24 2016] e.g. (nat, O, S) is the initial object in the category of diagrams w/ an endomorphism and a morphism from unit [Mon May 2 17:42:58 2016] i haven't read up on that, so I can't say [Mon May 2 17:43:06 2016] o [Mon May 2 17:43:29 2016] well i'm 90% sure that the last line was correct [Mon May 2 17:44:38 2016] i should come down to boston haskell again sometime soon :] [Mon May 2 17:44:57 2016] maybe i will finally be able to bicker w/ edwardk and know what the hell im talking about [Mon May 2 17:45:17 2016] where are you now? [Mon May 2 17:45:26 2016] maine, same as usual [Mon May 2 17:45:49 2016] convoy pattern looks ugly as all hell [Mon May 2 17:47:42 2016] good lobster? [Mon May 2 17:48:02 2016] never eaten it [Mon May 2 17:48:06 2016] WHAT? [Mon May 2 17:48:18 2016] C: [Mon May 2 17:48:20 2016] that's like living in a place called Chocolopolis and never eating chocolate [Mon May 2 17:48:30 2016] i dunno, never bothered [Mon May 2 17:48:35 2016] well, do [Mon May 2 17:56:30 2016] hey [Mon May 2 17:56:35 2016] hi sanooj [Mon May 2 17:56:52 2016] I'm getting back into my project after a long hiatus [Mon May 2 17:57:20 2016] I wasn't following the 8.5 stuff nor math-comp/ssreflect-1.6 [Mon May 2 17:57:44 2016] still getting headaches. :) [Mon May 2 18:00:57 2016] i'm dealing with upgrade headaches too [Mon May 2 18:01:28 2016] is there any reason not to upgrade to 8.5pl1? [Mon May 2 18:01:39 2016] i can't think of one [Mon May 2 18:01:41 2016] or ssr/mathcomp-1.6? [Mon May 2 18:01:50 2016] 1.6 is a nice upgrade, and is backward compatible [Mon May 2 18:01:57 2016] I like the new organization in the source repo for 1.6 [Mon May 2 18:04:05 2016] although now that they've merged the code again and shuffled bits around, it turns out I'm still reading ssreflect and haven't clawed myself into mathcomp proper yet. :) [Mon May 2 18:04:18 2016] I finished binomial.v the other day. [Mon May 2 18:07:56 2016] how can i "reopen" a module [Mon May 2 18:08:10 2016] i.e. go back and continue to develop in its scope, from the REPL or another module [Mon May 2 18:08:12 2016] er, another file [Mon May 2 18:12:01 2016] can't you juse Open Scope again? [Mon May 2 18:12:33 2016] you can't re-open a module [Mon May 2 18:12:38 2016] you can just make a new module that extends it [Mon May 2 18:12:46 2016] by Include'ing the original module [Mon May 2 18:12:54 2016] poo [Mon May 2 18:30:08 2016] mh. mathcomp doesn't seem to actually support parallel makes like make -j4 even though the README says to use it [Mon May 2 18:30:44 2016] there's just one coqtop process running at a time. [Mon May 2 19:22:01 2016] johnw: so youve never seen the characterization of the naturals as the initial (S, S -> S, 1 -> S) structure? [Mon May 2 20:00:41 2016] whete can i find what the "in" in "match .. in .. return .. with" does? [Mon May 2 21:00:15 2016] Nik05: cpdt is the best resource I know of. did you have any specific questions? [Mon May 2 22:02:00 2016] is there any type in vanilla coq + extensionality which is a model of ZFC [Mon May 2 22:02:12 2016] ± choice [Mon May 2 22:40:52 2016] anybody here uses (or understands) F*? :) [Tue May 3 01:53:25 2016] https://team.inria.fr/marelle/en/advanced-coq-winter-school-2016/ woot [Tue May 3 03:41:19 2016] sanooj: this already happened? [Tue May 3 03:46:03 2016] yes in january. the lecture notes and exercises are online though [Tue May 3 04:00:43 2016] thank you jrw [Tue May 3 04:07:44 2016] not really soecific [Tue May 3 04:07:56 2016] specific [Tue May 3 07:26:20 2016] Hi guys [Tue May 3 07:26:32 2016] I was wondering how I could define a set by specification in coq [Tue May 3 07:27:11 2016] (as, I have a A:Set, and I want to define B:Set as the elements of A such as P a (for a given P:A->Prop)) [Tue May 3 07:32:10 2016] Maybe {x : A | P x} is what you want [Tue May 3 07:32:17 2016] (the name of this type is "sig") [Tue May 3 07:37:46 2016] Cypi : Can I cast a sig to set ? [Tue May 3 07:38:13 2016] If you mean the "Set" of Coq, then you already have "{x : A | P x} : Set" whenever "A : Set" [Tue May 3 07:38:36 2016] Cypi : Oh, I didnt know [Tue May 3 07:40:41 2016] Cypi : Thanks ! [Tue May 3 07:40:44 2016] hm [Tue May 3 07:41:09 2016] Let's say I have B = {x:A|P x}, if I have X:A->Prop, I cant use it on y:B [Tue May 3 07:47:26 2016] B is indeed a different type. You have to go through "proj1_sig" to get back an A that you can apply X on. If you still want the convenience of writing "X y" directly, you can also do this: http://lpaste.net/162345 [Tue May 3 07:51:37 2016] Oh, nice. [Tue May 3 07:51:49 2016] I did not know you could do that kind of convenience things [Tue May 3 07:52:15 2016] Thank you [Tue May 3 07:53:01 2016] What does mean "@" ? [Tue May 3 07:53:13 2016] @ is to make every argument explicit [Tue May 3 07:53:57 2016] i see [Tue May 3 07:54:05 2016] otherwise, the arguments 'A' and 'P' of "proj1_sig" are implicit, but you cannot really write directly "Definition BtoA : B -> A := proj1_sig." [Tue May 3 07:54:21 2016] You could also eta-expand this, that would work: "Definition BtoA : B -> A := fun y => proj1_sig y." [Tue May 3 07:54:47 2016] I understand [Tue May 3 07:54:48 2016] (in this case, Coq knows that the implicit arguments of "proj1_sig" should be inferred, and it manages to do so thanks to the type of 'y') [Tue May 3 07:55:20 2016] I dont know how "Parameter" works [Tue May 3 07:55:27 2016] It does for all A:Set ? [Tue May 3 07:55:37 2016] Or it's just an example ? [Tue May 3 07:55:43 2016] (So we have a given A) [Tue May 3 07:55:47 2016] It's essentially the same as "Axiom" in this case. [Tue May 3 07:55:57 2016] So yes, just a given A that we know nothing about, except its type [Tue May 3 07:56:17 2016] Ok, I see [Tue May 3 07:56:25 2016] Can I do a coercion in a middle of a demonstration ? [Tue May 3 07:57:01 2016] in fact, I have the goal "exists F:nat->A", but I can only prove "exists F:nat->B", where B is a subset of A. [Tue May 3 07:57:08 2016] And I'd like the coercion to be done automatically [Tue May 3 07:57:25 2016] Maybe it requires a tactic, if so, I'll do it by hand [Tue May 3 08:00:40 2016] Hmm. Wherever you have to give a "nat -> A", giving a "nat -> B" is enough, and the coercion will be introduced automatically [Tue May 3 08:00:58 2016] so it depends exactly what you mean by "I can only prove "exists F:nat->B"". [Tue May 3 08:02:22 2016] This works, for instance: http://lpaste.net/162346 [Tue May 3 08:03:22 2016] I see [Tue May 3 08:03:50 2016] So, in fact, I will have to put the coercion in the middle of the demonstration, and then, i'll be able to do so [Tue May 3 08:06:16 2016] When I do a definition in a middle of my demonstration (as Definition wtvr (a:A)) and I have A in my hypothesis, I get "The reference A was not found" [Tue May 3 08:06:31 2016] I think I'll do the demonstration by hand, I'm too new to coq [Tue May 3 08:07:05 2016] Ah, I misunderstood what you meant. Putting a Definition inside a proof should be considered bad practice, for quick testing [Tue May 3 08:07:27 2016] and yes, if you do write a Definition in your proof, then it should be closed, as if it was written outside of the proof [Tue May 3 08:08:06 2016] Cypi : I didnt know it was bad practice [Tue May 3 08:08:09 2016] Thank you ^^ [Tue May 3 08:14:44 2016] Cypi, given a:A, and P a, how can I get the element of (sig A P), I cant find on https://coq.inria.fr/library/Coq.Init.Specif.html [Tue May 3 08:23:40 2016] "exist"exist : forall x:A, P x -> sig P. [Tue May 3 08:23:43 2016] oops. "exist : forall x:A, P x -> sig P. [Tue May 3 08:24:04 2016] Sorry, wrong manipulation. You're looking for "exist : forall x:A, P x -> sig P" [Tue May 3 08:27:23 2016] Cypi : That's what I thought [Tue May 3 08:27:37 2016] I define my set by "Definition nonAcceSet (A:Set) (R:A->A->Prop) : Set := {a : A|~(Acce A R a)}." [Tue May 3 08:28:08 2016] But when I do "exist (~ Acce A R b)" [Tue May 3 08:28:15 2016] I get a type error [Tue May 3 08:29:10 2016] "exist (fun a => ~ (Acce A R a)) a H" where (a : A) and (H : ~ (Acce A R a)) [Tue May 3 08:31:08 2016] oh [Tue May 3 08:31:16 2016] But, I don't understand why we have to pass that function too [Tue May 3 08:32:08 2016] You could probably ask Coq to infer it actuall: "exist _ a H" [Tue May 3 08:32:17 2016] In most cases it will work [Tue May 3 08:32:26 2016] in some cases, you'll still have to help it [Tue May 3 08:32:32 2016] I see [Tue May 3 08:34:04 2016] Thank you for everything ^^ [Tue May 3 08:34:26 2016] In fact, I don't know how I can learn coq .-. [Tue May 3 08:34:48 2016] I found Software Foundations to be a good introduction [Tue May 3 08:40:01 2016] Hello. I'm struggling to prove this basic lemma: [Tue May 3 08:40:23 2016] Theorem bounded_nat_dec : forall (P : nat -> Prop) (p : nat), (forall q, q < p -> {P q} + {~ P q}) -> {forall q, q < p -> P q} + {~ forall q, q < p -> P q}. [Tue May 3 08:40:23 2016] [Tue May 3 08:41:18 2016] plain induction doesn't work. [Tue May 3 08:42:04 2016] at least on p. [Tue May 3 08:45:35 2016] or perhaps it does and I'm a noob. [Tue May 3 08:47:41 2016] Trying it at the moment, I think it should work [Tue May 3 08:48:44 2016] Yup, it does. Where were you stuck? [Tue May 3 08:50:43 2016] I guess it is just a logistic thing of getting {(forall q : nat, q < p -> P q)} + {~ (forall q : nat, q < p -> P q)} as assumption from the hypothesis. [Tue May 3 08:52:05 2016] I just did an "assert (forall q : nat, q < p -> {P q} + {~ P q})." [Tue May 3 08:52:19 2016] and then "specialize (IHp H0)" (with the correct names for your case) [Tue May 3 08:52:53 2016] Ah. Thanks [Tue May 3 08:53:08 2016] I am not familiar with all the tactics. [Tue May 3 15:57:55 2016] sanooj: sounds like a notational misinterpretation to me [Tue May 3 15:58:12 2016] try using explicit scopes: (p ==> ...)%type [Tue May 3 16:03:07 2016] coq's CHANGES file says ==> is now right associative at level 55 in signature_scope. lemme check what it is in mathcomp [Tue May 3 16:06:05 2016] same. [Tue May 3 16:06:56 2016] except it's in bool_scope. [Tue May 3 16:09:07 2016] mh, and the CHANGES entry is under 8.1 -> 8.2 :| [Tue May 3 16:19:53 2016] right, ==> only comes in if you import the right module though, I thought [Tue May 3 16:20:01 2016] I use it for defining setoid morphism signatures [Tue May 3 16:54:25 2016] it's in ssrbool, so it's not exactly an obscure module. [Tue May 3 17:06:05 2016] oh, I see [Tue May 3 17:06:10 2016] it's a notation from ssreflect [Tue May 3 17:06:21 2016] do this: Locate Notation "==>". [Tue May 3 17:06:31 2016] see which one you're actually using in that lemma [Tue May 3 17:10:09 2016] Locate Notation doesn't work for me, but Locate "==>" give me this: http://pastebin.ca/3590051 [Tue May 3 17:10:18 2016] I think that says ==> should be from ssrbool. [Tue May 3 17:10:24 2016] hmm [Tue May 3 17:10:47 2016] why then is it inferring the type of p to be Type? [Tue May 3 17:10:57 2016] try an explicit type annotation (p : bool) [Tue May 3 17:12:16 2016] if you have math-comp installed you can try it yourself: http://pastebin.ca/3590053 [Tue May 3 17:12:31 2016] yeah, adding (p:bool) works fine, but I don't think that's what ought to be happening. [Tue May 3 17:13:16 2016] what do you think should be happening? [Tue May 3 17:13:39 2016] I think the ==> notation should be read as implb and that should trigger p to be inferred as bool. [Tue May 3 17:14:48 2016] try replacing the notation with implb [Tue May 3 17:14:51 2016] and see if that actually happens [Tue May 3 17:15:39 2016] oh, it doesn't... [Tue May 3 17:16:13 2016] it again says the same error: The term "p" has type "Type" while it is expected to have type "bool". [Tue May 3 17:17:35 2016] do a Print implb [Tue May 3 17:17:44 2016] make sure there isn't a parameter there that should be implicit [Tue May 3 17:18:37 2016] doesn't look like it. it says "implb = fun b1 b2 : bool => if b1 then b2 else true : bool -> bool -> bool" [Tue May 3 17:19:22 2016] the "p -> ..." part is likely intended to be read as "(is_true p) -> ..." [Tue May 3 17:19:42 2016] if I actually replace the p -> with (is_true p) -> then coq is happy. [Tue May 3 17:19:52 2016] hmm [Tue May 3 17:20:00 2016] so probably not a notations issue after all. [Tue May 3 17:20:38 2016] did you get 8.5 installed? [Tue May 3 17:22:39 2016] yeah, I have 8.5pl1 and mathcomp-1.6 [Tue May 3 17:22:51 2016] but I'm working on an issue with an 8.4 project right now [Tue May 3 17:22:57 2016] ok. [Tue May 3 17:52:03 2016] Cypi and Onemorenickname ah i missed the talk about Sets. Cypi any specific documentation on this? [Tue May 3 17:52:45 2016] Sofware Foundations is a good introduction to this? [Tue May 3 17:55:54 2016] not sure that SF goes into sets [Tue May 3 17:55:57 2016] Coq calls them Ensembles [Tue May 3 18:01:31 2016] thank you johnw [Tue May 3 18:02:12 2016] nice french name :P [Tue May 3 18:03:25 2016] and { a | P b } is not an ensemble? [Tue May 3 18:03:34 2016] no, that's a sigma type [Tue May 3 18:03:39 2016] type "sig" [Tue May 3 18:03:44 2016] just "P" would be the ensemble [Tue May 3 18:03:49 2016] an esemble is also a predicate [Tue May 3 18:03:55 2016] since it predicates the members of the set [Tue May 3 18:04:01 2016] oke [Tue May 3 18:04:30 2016] so, Ensembles.In _ x xs is identical to "xs x" [Tue May 3 18:04:34 2016] it takes some getting used to :) [Tue May 3 18:04:37 2016] How does this correlate with mathematical sets? [Tue May 3 18:04:48 2016] the only thing you can know about a mathematical set is its membership [Tue May 3 18:04:54 2016] so, that's the only information an Ensemble can give you [Tue May 3 18:05:05 2016] however, you can't enumerate an Ensemble [Tue May 3 18:05:22 2016] oke, and coq's Sets are? [Tue May 3 18:05:33 2016] Set is a "sort", a universe of type [Tue May 3 18:05:35 2016] s [Tue May 3 18:06:25 2016] it's also related to mathematical sets [Tue May 3 18:06:38 2016] Oké :P [Tue May 3 18:06:47 2016] think of an Ensemble as a reified set, though, something you can treat as a value [Tue May 3 18:07:17 2016] well, in a way [Tue May 3 18:07:23 2016] Ensembles have no computational meaning [Tue May 3 18:08:12 2016] oh sig, stands for signature [Tue May 3 18:08:29 2016] Im reading some wikipedia [Tue May 3 18:08:46 2016] does it? [Tue May 3 18:08:52 2016] I think it does [Tue May 3 18:08:57 2016] I thought it stood for sigma [Tue May 3 18:08:58 2016] It does not? [Tue May 3 18:09:00 2016] oh [Tue May 3 18:09:28 2016] Oh it does [Tue May 3 18:11:10 2016] the two basic dependent types are Pi and Sigma [Tue May 3 18:11:26 2016] although, in Coq's type theory, Sigma can be expressed in terms of Pi, because it has inductive types [Tue May 3 18:11:39 2016] What is Pi? [Tue May 3 18:11:44 2016] "forall" [Tue May 3 18:11:48 2016] universal quantification [Tue May 3 18:12:03 2016] also written Π a b, a → b [Tue May 3 18:12:05 2016] in some texts [Tue May 3 18:12:25 2016] if you read the HoTT book, you'll see Π and Σ everywhere, meaning "forall" and "exists" [Tue May 3 18:13:31 2016] oh oke, thank you [Tue May 3 18:17:27 2016] Why do they use set notation for sigma types and are sets called ensembles? :P [Tue May 3 18:18:07 2016] well, it's not really set notation [Tue May 3 18:18:19 2016] { x | x < 10 } doesn't mean all numbers less than ten [Tue May 3 18:18:28 2016] it means just one number less than 10 [Tue May 3 18:18:34 2016] I agree it _looks_ like set notation [Tue May 3 18:18:54 2016] and in a sense it's similar, because as an existential you don't know which number it is, so in a way it refers to all of them [Tue May 3 18:18:54 2016] so ∃ x, x < 10 ? [Tue May 3 18:18:57 2016] maybe that's the connection [Tue May 3 18:18:58 2016] yeah [Tue May 3 18:19:05 2016] there are three sigmas in Coq [Tue May 3 18:19:06 2016] its the same? [Tue May 3 18:19:07 2016] exists x, x < 10 [Tue May 3 18:19:10 2016] {x | x < 10} [Tue May 3 18:19:13 2016] {x & x < 10} [Tue May 3 18:19:23 2016] they are all different in their relationship to Type and Prop [Tue May 3 18:19:32 2016] but they all effectively just mean "exists" [Tue May 3 18:19:44 2016] strange [Tue May 3 18:20:27 2016] or is the a { x : x < 10 }, oh wait cant use : for this :P [Tue May 3 18:20:32 2016] to say "every number less than 10" as an Ensemble, you'd just write this: [Tue May 3 18:20:43 2016] Definition less_than (n : nat) : Prop := n < 10. [Tue May 3 18:20:55 2016] ah right [Tue May 3 18:21:10 2016] because that uses "forall", not "exists" [Tue May 3 18:22:11 2016] But in mathematics this is noted as { n ε N : n < 10 } right? [Tue May 3 18:22:17 2016] sorry cant find the right epsilon [Tue May 3 18:22:31 2016] ∈ [Tue May 3 18:22:46 2016] its somewhere in my compose key list :) [Tue May 3 18:23:01 2016] I type "\in" [Tue May 3 18:24:23 2016] ϵ [Tue May 3 18:24:27 2016] looks different [Tue May 3 18:24:29 2016] yeah [Tue May 3 18:25:01 2016] ah for me its WIN -> i -> n [Tue May 3 18:25:03 2016] in :P [Tue May 3 18:25:06 2016] ∈ [Tue May 3 18:25:19 2016] ah [Tue May 3 18:25:29 2016] ∉ [Tue May 3 18:25:33 2016] lol [Tue May 3 18:26:09 2016] ∋ win -> n -> i [Tue May 3 18:26:48 2016] what that is how they note it, right? [Tue May 3 18:26:50 2016] that's cute, \ni works too [Tue May 3 18:26:54 2016] :P [Tue May 3 18:27:09 2016] { x | x ∈ ℕ, x < 10 } [Tue May 3 18:27:22 2016] oh right [Tue May 3 18:27:49 2016] oke I have to remove this from my head, { x | P x} is not set notation in qoq [Tue May 3 18:28:31 2016] well thank you johnw [Tue May 3 18:28:38 2016] sure [Tue May 3 21:20:25 2016] hi, any clever ppl willing to explain to me how natural induction follows from initiality as an algebra [Tue May 3 21:25:36 2016] benzrf: isn't induction in that sense just a catamorphism? [Tue May 3 21:25:47 2016] whats a catamorphism [Tue May 3 21:25:53 2016] more reading for you! [Tue May 3 21:25:57 2016] in the category sense i mean [Tue May 3 21:26:05 2016] im vaguely aware that its a term related to structural induction [Tue May 3 21:26:09 2016] it's a morphism in the category of F-Algebras [Tue May 3 21:26:17 2016] just any one? [Tue May 3 21:26:19 2016] from the initial object [Tue May 3 21:26:34 2016] so, for lists, it's foldr [Tue May 3 21:26:47 2016] and if your result type is Prop, then foldr is induction [Tue May 3 21:26:53 2016] hm [Tue May 3 21:27:02 2016] induction is nothing special [Tue May 3 21:27:12 2016] yeah [Tue May 3 21:27:17 2016] which is kind of awesome [Tue May 3 21:27:24 2016] hold on tho [Tue May 3 21:28:59 2016] how does that play with dependent product in a way that gets you induction and not just a boring non dependent fold [Tue May 3 21:29:31 2016] by being a dependent fold [Tue May 3 21:29:35 2016] look at the type of "nat_ind", for example [Tue May 3 21:29:47 2016] i know [Tue May 3 21:29:51 2016] im asking how does this work categorically [Tue May 3 21:30:03 2016] then I don't understand the question [Tue May 3 21:30:33 2016] hmm, maybe im really asking "how do you do dependent stuff from a categorical perspective" [Tue May 3 21:30:53 2016] you pick a category that has dependent products [Tue May 3 21:31:41 2016] https://ncatlab.org/nlab/show/categorical+model+of+dependent+types [Tue May 3 21:31:50 2016] * clicks with trepidation [Tue May 3 21:33:57 2016] johnw: recently I reads about topology/algebra/category/type theory on web, and it gave me the feeling that they 're all inter connected... [Tue May 3 21:34:08 2016] they most certainly are [Tue May 3 21:34:35 2016] "topology/algebra" is like an appreciable portion of "math" [Tue May 3 21:36:03 2016] so I feel overwhelmed that I have to learn so many things, to know type theory. [Tue May 3 21:36:21 2016] or rather, think that life has many interesting evenings ahead of you [Tue May 3 21:36:34 2016] whatever you think you don't know now, will seem like nothing soon [Tue May 3 21:37:47 2016] I believe so. :-) [Tue May 3 21:41:40 2016] fortunately, as it all starts connecting together, it starts becoming true that learning one thing is actually learning 10 things at once [Tue May 3 21:50:04 2016] >That is, if a type A corresponds to an object in some category, then a dependent type (x:A)⊢(B(x)type) (x:A) \;\vdash\; (B(x) \;type) corresponds to a morphism B→A in that category. [Tue May 3 21:50:06 2016] ?????? [Tue May 3 21:51:09 2016] why is that a problem? [Tue May 3 21:52:04 2016] i dont understand at all what this means [Tue May 3 21:54:13 2016] ok this is all way over my head [Tue May 3 21:54:16 2016] bear in mind that morphisms can have as much structure as you like [Tue May 3 21:54:29 2016] so long as they honor the composition and identity laws [Tue May 3 21:56:44 2016] i kno [Tue May 3 21:56:53 2016] its not that i couldnt unwind the definitions if i absolutely had to [Tue May 3 21:57:09 2016] its just that theres entire towers of abstraction here that i havent wrapped my head around [Tue May 3 21:57:18 2016] so even if i did work out the actual definitions, theyd be meaningless to me [Tue May 3 21:58:01 2016] well, if that's the case, I can't unwind them for you in a few lines on IRC [Tue May 3 21:58:04 2016] you'll have to work these out [Tue May 3 21:58:41 2016] well, i wasnt asking you to :P [Tue May 3 22:02:43 2016] well, in that case, m'k :) [Wed May 4 00:34:35 2016] b.org [Wed May 4 07:40:03 2016] I have a hypothesis H : forall x, ... and I want to do "induction (H e)" where e is a unification variable [Wed May 4 07:40:09 2016] how can I achieve that? [Wed May 4 07:42:32 2016] Maybe "einduction H" ? [Wed May 4 07:43:43 2016] Ha! I should have thought about it ... [Wed May 4 21:15:54 2016] Hi. [Wed May 4 21:16:41 2016] I haven't used Coq in over ten years, and want to use it to prove some trivial theorems about operational semantics. [Wed May 4 21:17:02 2016] I'd like to model my operational semantics as categories. [Wed May 4 21:17:18 2016] What is the correct place to start from? [Wed May 4 21:17:43 2016] I see that the HoTT variant of Coq seems to have much more theories for Categories. [Wed May 4 21:19:02 2016] Fare: well, then you'll have to learn HoTT :) [Thu May 5 16:43:15 2016] Where in the coq libraries could forall a b : nat, {a < b} + {b <= a} be found? I could only find lt_ge_cases in Prop. [Thu May 5 16:45:10 2016] reuben364: you can try [SearchAbout le.] to get a massive scrollback-filling list of definitions whose type uses le [Thu May 5 16:45:18 2016] and then ctrl+f for 'dec' (decidable) [Thu May 5 16:45:22 2016] reuben364: le_lt_dec https://coq.inria.fr/library/Coq.Arith.Compare_dec.html [Thu May 5 16:45:37 2016] there's probably a better way to search but i'm not the most knowledgable :> [Thu May 5 16:46:01 2016] Ah. Thanks arcatan and benzrf. [Thu May 5 16:46:44 2016] the problem with the search commands is that you have to have imported the module you're looking for [Thu May 5 16:47:33 2016] i don't know a good solution for searching all the modules [Thu May 5 16:48:13 2016] (btw, i wrote this short tutorial about coq search commands: http://quanttype.net/posts/2016-04-19-finding-that-lemma.html) [Thu May 5 16:48:33 2016] actually! you only need to have the module loaded somewhere [Thu May 5 16:48:39 2016] you don't need to import it yourself [Thu May 5 16:48:44 2016] right, loaded, not imported [Thu May 5 16:48:59 2016] that's important, cause [Thu May 5 16:49:15 2016] if you import, say, Nat, it'll require a bunch of other modules while it's at it [Thu May 5 16:49:33 2016] and then if you SearchAbout, you'll probably find what you're looking for (if it's mostly about nats) [Thu May 5 16:50:38 2016] yea [Thu May 5 16:57:40 2016] Also, is there a shorter way of auto solving a trival goal when specializing an assumption instead of: assert a : A. auto. specialize (H a). clear a. [Thu May 5 16:58:57 2016] reuben364: you could try [specialize (H ltac:(auto)).] [Thu May 5 16:59:12 2016] (requires coq 8.5) [Thu May 5 16:59:18 2016] ohh!! [Thu May 5 16:59:26 2016] So you can embed tactics in gallina terms. Exactly what I was hoping for. [Thu May 5 16:59:31 2016] i was actually thinking the other day about if it was possibe to embed tactics [Thu May 5 16:59:32 2016] nice [Thu May 5 16:59:38 2016] yeah, new in 8.5 [Thu May 5 17:00:23 2016] reuben364: could you do specialize (@H A _) [Thu May 5 17:00:55 2016] Wouldn't that have to be solved with unification? [Thu May 5 17:02:48 2016] what do you mean [Thu May 5 17:05:51 2016] Underscores in gallina terms mean that argument can be resolved using type inference, so it won't try a proof-search or introduce a new subgoal. [Thu May 5 17:08:07 2016] i think it's actually more powreful than that... one sec, let me try something [Thu May 5 17:09:04 2016] ok nvm looks like you're right >.< [Thu May 5 17:09:06 2016] kk [Thu May 5 17:13:21 2016] reuben364: there's also: evar (a : A). specialize (H a). [Thu May 5 17:14:01 2016] johnw: awesome [Thu May 5 18:12:42 2016] ls [Thu May 5 18:12:47 2016] whoops [Fri May 6 03:37:21 2016] Reserved Notation "Gamma '|-' t '\in' T" (at level 40). [Fri May 6 03:37:34 2016] Software Foundations introduces notation above [Fri May 6 03:38:14 2016] unfortunatelly, use of '|-' collides with Ltac's match goal [ H : ... |- _ ] => ... [Fri May 6 03:38:32 2016] Is there a ways to resolve this ambiguity without changing the notation? [Fri May 6 04:42:29 2016] * also needs help with this : http://stackoverflow.com/questions/37067923/matching-on-unary-data-constructors-in-ltac [Fri May 6 04:45:56 2016] jstolarek : in your third branch, would it work to add "match ?C with _ _ => fail end; ..." ? [Fri May 6 04:46:21 2016] (for the notation, I have no idea, I already had this problem :/ ) [Fri May 6 04:47:43 2016] * tries [Fri May 6 04:48:21 2016] I meant "match C with", no '?' [Fri May 6 04:49:23 2016] Cypi: no, that does not seem to work [Fri May 6 04:49:32 2016] unless I've made some mistake [Fri May 6 04:49:52 2016] Hmm. Let me try to put together some code so that I can actually test it ^^ [Fri May 6 04:49:56 2016] jstolarek pasted “No title” at http://lpaste.net/162548 [Fri May 6 04:50:06 2016] is that what you meant? [Fri May 6 04:50:15 2016] that's what I meant, yes [Fri May 6 04:50:36 2016] Ah wait, of course that cannot work. Now the third branch is never taken I guess, right? [Fri May 6 04:51:31 2016] yes [Fri May 6 04:52:01 2016] So, maybe: match C with _ _ => fail 1 | _ => idtac end [Fri May 6 04:52:13 2016] (yup, that does seem convoluted, maybe there is a batter way, but I don't know it...) [Fri May 6 04:53:05 2016] yes, that works [Fri May 6 04:53:11 2016] but that makes me think [Fri May 6 04:53:24 2016] what is the semantics of pattern matching in Ltac? :-/ [Fri May 6 04:54:06 2016] I couldn't do a detailed explanation, but if you have a precise question (regarding this example in particular), maybe I can answer it [Fri May 6 04:54:49 2016] well, why does ?C ?t match a binary constructor? [Fri May 6 04:55:30 2016] another question is why does your solution work, ie. what is the meaning of _ _ in the pattern match ? [Fri May 6 04:56:11 2016] If your term is "C1 a b" (with C1 a binary constructor), then ?C ?t will bind C to "C1 a" and t to "b", because it sees the term as ((C1 a) b) [Fri May 6 04:56:34 2016] A function applied to two arguments, is the same as a function applied to one argument, which is then applied to another argument [Fri May 6 04:56:42 2016] ok, I understand, but this is horrible... [Fri May 6 04:57:00 2016] The meaning of "_ _" is basically the same as "?C ?t": it's trying to destruct C further into an application [Fri May 6 04:57:13 2016] but [Fri May 6 04:57:18 2016] if we can do it, then it means that we were having at least two applied arguments originally [Fri May 6 04:57:22 2016] ah, I see [Fri May 6 04:57:27 2016] makes sense [Fri May 6 04:57:37 2016] but again, this is just horrible... [Fri May 6 04:57:38 2016] I don't think it's horrible, this is basically currying [Fri May 6 04:57:54 2016] I wouldn't expect that from pattern matching [Fri May 6 04:57:57 2016] Functions with two arguments are just a special case of functions with one argument [Fri May 6 04:58:03 2016] perhaps I've spent too much time with Haskell [Fri May 6 04:58:35 2016] Hmm, I get your meaning. But still, I think doing the opposite would be just as bad or even worse [Fri May 6 04:59:10 2016] Sometimes I want to match on a function applied to some arguments, but I don't know if it will be applied to more arguments or not (and I don't care) [Fri May 6 05:00:00 2016] I guess the best solution would be to have some control over that [Fri May 6 05:01:07 2016] On the other hand, I don't think it would be difficult to implement some "exact number of arguments" match [Fri May 6 05:01:53 2016] meaning as an Ltac tactic? [Fri May 6 05:02:26 2016] I was thinking more of something in OCaml to add a syntax for that to Ltac [Fri May 6 05:02:50 2016] that's above my paygrade [Fri May 6 05:02:59 2016] Ahah, I wasn't suggesting you should do it :p [Fri May 6 05:03:04 2016] :-) [Fri May 6 05:03:23 2016] Anyway, I extracted your solution as an "assert_unary" Ltac procedure [Fri May 6 05:03:32 2016] should make my life easier [Fri May 6 05:06:51 2016] You could actually write a tactic in Ltac that succeeds only if you have the correct number of arguments: http://lpaste.net/162550 [Fri May 6 05:07:01 2016] (this is just a more general version of this match) [Fri May 6 05:07:14 2016] of course it won't do any bindings, it just acts as a check [Fri May 6 05:10:12 2016] done :-) [Fri May 6 06:09:57 2016] can I somehow inspect contents of Hint databases? [Fri May 6 06:11:05 2016] maybe Print Hint * or Print HintDb name [Fri May 6 06:17:07 2016] I was thinking about inspecting hints in an Ltac procedure [Fri May 6 06:17:17 2016] but perhaps that's not the best idea [Fri May 6 06:17:23 2016] anyway [Fri May 6 06:17:46 2016] I have formulated a theorem that says something leads to False [Fri May 6 06:18:07 2016] now I would like Coq to automatically spot situations where that something appears as a premise [Fri May 6 06:18:26 2016] and apply my theorem to introduce False as a premise and then do inversion on False [Fri May 6 06:18:30 2016] how can I do that? [Fri May 6 06:18:36 2016] morgen [Fri May 6 06:25:26 2016] jstolarek : maybe this works for you? http://lpaste.net/162554 [Fri May 6 06:26:35 2016] Well, at this point I guess even this would work: [Fri May 6 06:26:36 2016] solve [repeat (intro; try now elim foo_False)]. [Fri May 6 06:28:58 2016] Cypi: yes, that would work [Fri May 6 06:29:20 2016] but what I am looking for is a way to use my theorem with auto/eauto [Fri May 6 06:29:31 2016] oh x) [Fri May 6 06:29:35 2016] I mean [Fri May 6 06:30:31 2016] I was thinking of some way where I would not have to explicitly insert my lemma into a proof [Fri May 6 06:30:48 2016] hoping that it gets picked up from the hint database by auto [Fri May 6 06:32:22 2016] So, the dirty solution "Hint Extern 1 => solve [repeat (intro; try now elim foo_False)]." would work. [Fri May 6 06:32:29 2016] It means that auto will try this anytime you call it [Fri May 6 06:33:21 2016] you can wrap the solve in a "match goal with |- context [foo] => ... end" to make it more efficient (it will only try it if "foo" appears somewhere in the goal) [Fri May 6 06:33:37 2016] yes, I guess that would work :-) [Fri May 6 06:33:53 2016] It's not perfect, it will attempt this even if "foo" is in a positive position, but well... [Fri May 6 06:34:48 2016] btw [Fri May 6 06:34:54 2016] what is "now" ? [Fri May 6 06:34:59 2016] in "try now" [Fri May 6 06:36:20 2016] "now t" is a tactic notation for "t; easy", and easy is a simpler version of auto to finish trivial proofs [Fri May 6 06:36:31 2016] now will fail if it cannot finish the proof [Fri May 6 06:37:04 2016] It's actually implemented with Ltac, so it's readable ^^' https://github.com/coq/coq/blob/trunk/theories/Init/Tactics.v#L169 [Fri May 6 06:37:26 2016] thanks :-) [Fri May 6 06:37:31 2016] is auto also implemented in Ltac? [Fri May 6 06:37:37 2016] no [Fri May 6 06:38:46 2016] :< [Fri May 6 06:39:29 2016] I don't think you can do things as complicated as going through Hint databases and such in Ltac [Fri May 6 06:40:43 2016] too bad [Fri May 6 06:40:50 2016] that would be a way to write a custom auto [Fri May 6 06:41:18 2016] Some people think and work towards having an actual programming language instead of Ltac, but it's still a complicated and open-ended matter [Fri May 6 06:41:48 2016] (I mean, transforming Ltac into an actual programming language, not embedding another programming language) [Fri May 6 06:42:38 2016] what do you mean by embedding? [Fri May 6 06:42:55 2016] (I am unfamiliar with internal implementation of Coq but I'm curious) [Fri May 6 06:43:31 2016] I mean you could say "Well, let's take something like Ruby, put together an API for manipulating the current goal and state of the proof, and there you go, the user can write some Ruby instead of tactics." It would one possible solution, but I don't think those people want that [Fri May 6 13:28:47 2016] per default, coq does not have functional extensionality, right? [Fri May 6 13:29:07 2016] (except probably for the HOTT-patches) [Fri May 6 13:45:06 2016] schoppenhauer: it does not [Fri May 6 13:45:21 2016] i think it's in the stdlib though [Fri May 6 13:45:29 2016] (as an importable axiom, i mean) [Fri May 6 13:58:39 2016] ok. [Fri May 6 13:58:40 2016] thx. [Fri May 6 14:02:07 2016] np [Sat May 7 01:48:41 2016] hi again [Sat May 7 15:05:06 2016] Is total induction defined anywhere as a tactic? [Sat May 7 15:05:38 2016] Or perhaps as a theorem. [Sat May 7 15:07:29 2016] As in, “Theorem total_ind p : (forall n, (forall m, m < n -> p m) -> p n) -> (forall n, p n).”, with a corresponding proof, of course. [Sat May 7 15:37:23 2016] pyon: not sure if it's in the stdlib, but you can prove it like this http://lpaste.net/162627 [Sun May 8 13:20:07 2016] the [Function] command is so neat [Sun May 8 16:08:14 2016] https://www.ps.uni-saarland.de/autosubst/ [Sun May 8 16:08:16 2016] This seems nice [Mon May 9 05:38:26 2016] I have a hypothesis H : true = true -> A \/ B [Mon May 9 05:38:31 2016] and my goal is A [Mon May 9 05:38:42 2016] how do I prove my goal? [Mon May 9 05:39:00 2016] I feel this is trivial but I don't see a way to use H :-/ [Mon May 9 05:42:22 2016] If you just have this, you cannot prove your goal, since you cannot know if you actually have A or B [Mon May 9 05:42:42 2016] hm... good point [Mon May 9 05:42:55 2016] but still [Mon May 9 05:43:07 2016] To use H, you could do "destruct (H eq_refl)" [Mon May 9 05:43:23 2016] is there a way to somehow simplify H to get rid of the trivialy true premise (true=true)? [Mon May 9 05:43:31 2016] ah, eq_refl [Mon May 9 05:43:39 2016] If you just want to remove the premise, "specialize (H eq_refl)" for instance [Mon May 9 05:46:01 2016] ok, thanks [Tue May 10 07:42:34 2016] jstolarek pasted “No title” at http://lpaste.net/162789 [Tue May 10 07:43:03 2016] Coq just gave me this result as a list of goals produced be a tactic [Tue May 10 07:43:13 2016] this looks like some sort of bug... [Tue May 10 07:44:59 2016] and if I type Focus 2 I get "No such goal error" [Tue May 10 16:39:41 2016] jstolarek: what tactic produced that? [Tue May 10 21:22:36 2016] sanity check: should this be provable? ~ (forall x, P x) <-> exists x, ~ P x [Tue May 10 21:23:25 2016] heh: http://pldev.blogspot.com/2012/03/coq-proving-duality-between-forall-and.html [Tue May 10 21:26:07 2016] I can confirm that this should not be provable (only the <- part) [Tue May 10 21:26:22 2016] Ah well, everything is detailed in this blogpost, ok :D [Tue May 10 21:26:22 2016] I can do it easily with Classical.Peirce, but not otherwise [Tue May 10 21:29:36 2016] you mean, only the -> part is not provable [Tue May 10 21:29:40 2016] the <- part is just "firstorder" [Tue May 10 21:51:03 2016] uwverdi [Tue May 10 21:51:07 2016] oops. [Wed May 11 10:01:53 2016] jrw: my custom Ltac procedure. This was some sort of error - I restarted Coq and the proof went through without problems. [Wed May 11 11:53:17 2016] jstolarek pasted “No title” at http://lpaste.net/163019 [Wed May 11 11:53:31 2016] I need some help woith the above [Wed May 11 11:53:50 2016] I feel the answer is simple but it eludes me :-/ [Wed May 11 11:54:08 2016] I have a piece of Ltac code that automates the first proof [Wed May 11 11:54:37 2016] and then I have a slightly more complicated proof which I want to automate [Wed May 11 11:55:30 2016] one of the problems in the second case is that the order of `destruct (...)` matters [Wed May 11 13:25:36 2016] jstolarek: hi [Wed May 11 13:40:39 2016] Hi, can someone help me? Coq is complaning that omega was not found in the current environment when I try to compile a file. [Wed May 11 13:50:24 2016] hi cswords_ [Wed May 11 13:50:28 2016] did you upgrade to 8.5? [Wed May 11 13:55:10 2016] if you did, just "Require Omega" [Wed May 11 13:55:16 2016] in 8.4, it was visible by default [Wed May 11 14:21:45 2016] Thanks! [Thu May 12 13:25:42 2016] hey all, I am going through software foundations and I'm confused by a universe inconsistency errors I'm getting with the `plus'` function defined here: http://lpaste.net/163065 [Thu May 12 13:26:38 2016] I've defined addition on church encoded nats in two different ways which I think should both work, but only the first alternative `plus` seems to do the trick [Thu May 12 13:39:28 2016] hi aupiff! [Thu May 12 13:40:06 2016] aupiff: you can avoid this by lifting the X out of your definition of nat, making it a parameter [Thu May 12 13:40:08 2016] for example: [Thu May 12 13:40:29 2016] https://gist.github.com/9b771ab8d309cbc4d4970573fbeae5b3 [Thu May 12 13:41:08 2016] now, the next question is why you're getting the inconsistency [Thu May 12 13:41:21 2016] it's because you've created a scenario where X could be "nat" itself [Thu May 12 13:41:27 2016] I don't think this work though, since you cannot instantiate X by nat then, if you lift it outside of the definition. [Thu May 12 13:41:47 2016] and the first use of "nat" (the outer use) fixed the universe level of your Type [Thu May 12 13:41:52 2016] Cypi: ah, maybe, I didn't try to use it [Thu May 12 13:42:07 2016] if you have 8.5, you could "Set Universe Polymorphism" [Thu May 12 13:42:21 2016] so that there are dynamically infinitely many versions of "nat", one for each universe level needed [Thu May 12 13:42:39 2016] then nat2 can include nat1, etc. [Thu May 12 13:42:40 2016] Or just "Polymorphic Definition nat := ... " is enough [Thu May 12 13:42:50 2016] Cypi: is that a new thing in 8.5? [Thu May 12 13:42:58 2016] is that how you set UP for just one definition? [Thu May 12 13:43:01 2016] Just like universe polymorphism, yes [Thu May 12 13:43:03 2016] Indeed [Thu May 12 13:43:13 2016] sweet!! [Thu May 12 13:43:13 2016] TIL [Thu May 12 13:43:14 2016] thanks [Thu May 12 13:43:18 2016] The other way is to make use of the impredicativity of Prop, and making all these definitions in Prop instead of Type [Thu May 12 13:43:29 2016] sure [Thu May 12 13:44:31 2016] hi johnw! long time no see. thanks for the explanation. [Thu May 12 13:45:35 2016] hi aupiff! yes, ltns [Thu May 12 14:50:40 2016] hi, i'm checking out some code in the FCF library and have found a line "eauto with typeclass_instances". It doesn't seem typeclass_instances is part of the library, however I can't seem to find anything in the coq docs. Anyone have any ideas what it means? [Thu May 12 15:21:02 2016] Hey I’m trying to prove that some datatype is finite but I am getting a weird error http://lpaste.net/163072 [Thu May 12 15:22:08 2016] ah I forgot the name … [Fri May 13 06:12:03 2016] johnw: blah, missed your ping yesterday :-) [Fri May 13 11:13:49 2016] Hi there ! [Fri May 13 11:15:00 2016] does someone know if there is a way to control the directory in which coq extract ml files from a _CoqProject file ? [Fri May 13 12:07:25 2016] jstolarek: hi [Fri May 13 16:38:15 2016] does [Function] generate a theorem to the effect of [Fri May 13 16:38:38 2016] [your_function x y z = your_function_F your_function x y z] [Sat May 14 13:12:50 2016] Is there coq for android? [Sat May 14 13:16:24 2016] i don't know if you mean "as an android app", but in case your question rather is "can i run coq on an android device" the answer is "yes" (i do) [Sat May 14 13:17:26 2016] egdfffghff: ^ [Sat May 14 13:17:35 2016] How? [Sat May 14 13:17:53 2016] using a linux distribution in a chroot environment ... [Sat May 14 13:18:05 2016] (i need root access, though) [Sat May 14 13:18:05 2016] I know people installing Debian on their smart phones [Sat May 14 13:18:12 2016] yes, for example [Sat May 14 13:18:18 2016] Ah, as I thought, sigh. [Sat May 14 13:18:28 2016] Thanks for sharing anyway. [Sat May 14 13:18:40 2016] i sense that's not what you were looking for? [Sat May 14 13:19:11 2016] Yup, android app would much more appealing. :) [Sat May 14 13:19:30 2016] anyway, i don't think there is an actual android coq app (but i'm just guessing) [Sat May 14 13:20:48 2016] Would be great to sit on train and work through SF. :) [Sat May 14 13:20:59 2016] Laptops are cumbersome. [Sat May 14 13:22:04 2016] Then print it ... :D [Sat May 14 15:57:43 2016] what approach is generally taken in proof assistants based on undecidable systems? [Sat May 14 15:57:51 2016] e.g. PRLs [Sat May 14 15:58:06 2016] rejection of some valid inputs? or failure to halt on some? something else? [Sun May 15 21:53:54 2016] Hello, [Sun May 15 21:54:14 2016] I have an hypothesis "forall P0 Q : Prop, ((P0 -> Q) -> P0) -> P0" [Sun May 15 21:54:26 2016] (it it called pe) [Sun May 15 21:54:59 2016] and I would like to replace the "forall P0" with P (there is an hypothesis P:Prop) [Sun May 15 21:55:02 2016] How could I do that ? [Sun May 15 23:29:44 2016] use tactic "specialize" [Mon May 16 03:37:50 2016] jun__: Great thank you ! [Mon May 16 03:38:13 2016] However I don't manage to replace the second variable : [Mon May 16 03:38:19 2016] If I do " specialize (pe P). [Mon May 16 03:38:22 2016] " [Mon May 16 03:38:32 2016] it does it for the first variable, [Mon May 16 03:40:19 2016] If I do : [Mon May 16 03:40:22 2016] specialize pe with (Q := P). [Mon May 16 03:40:43 2016] It doesn't do anything [Mon May 16 03:40:53 2016] (no error but no replace) [Mon May 16 03:42:12 2016] i think you have to create a new hypothesis [Mon May 16 03:42:43 2016] something like "pose (pe' := fun P0 => pe P0 P)" [Mon May 16 03:44:34 2016] Hum the result is pretty strange : pose (pe' := fun P0 => pe P0 P) [Mon May 16 03:45:24 2016] ? [Mon May 16 03:47:28 2016] jun__: sorry, this is the result : [Mon May 16 03:47:30 2016] pe' := fun P0 : Prop => pe P0 P : forall P0 : Prop, ((P0 -> P) -> P0) -> P0 [Mon May 16 03:47:49 2016] it is what you expected [Mon May 16 03:48:39 2016] to parse it more easily you can ignore it's value (the part between := and the first colon) [Mon May 16 03:48:47 2016] *its [Mon May 16 03:50:01 2016] maybe I didn't understand your problem [Mon May 16 03:50:07 2016] Hum... It's right that it's the more general case... [Mon May 16 03:51:04 2016] jun__: The thing is that since forall commute, I expected a "forall P0 : ((P0 -> P) -> P0) -> P0 [Mon May 16 03:51:25 2016] it does not really "commute" [Mon May 16 03:51:42 2016] Is it possible to force the commute ? [Mon May 16 03:51:57 2016] Why doesn't it commute ? [Mon May 16 03:52:14 2016] a proof of type "forall (a : A) (b : B), C" cannot be of type "forall (b : B) (a: A), C" [Mon May 16 03:52:27 2016] forall x y, x > y isn't the same as forall y x, x > y ? [Mon May 16 03:52:41 2016] there are equivalent [Mon May 16 03:53:04 2016] ie there is an implication in both direction [Mon May 16 03:53:32 2016] but basically forall proofs are functions [Mon May 16 03:53:47 2016] And can I do the traduction with "apply XXX in H" ? [Mon May 16 03:54:08 2016] and you cannot freely swap the argument order in a function [Mon May 16 03:55:31 2016] you can do "apply XXX with Q:=P in pe" [Mon May 16 03:56:43 2016] jun__: Ok, thank you. [Mon May 16 03:57:18 2016] By apply, I mean, does a lemma/tactic/... already exists to produce pe'' from pe such that forall are exchanged ? [Mon May 16 03:57:48 2016] Or should I write the proof by myself ? [Mon May 16 04:00:45 2016] I'm not sur if there is [Mon May 16 04:01:02 2016] I need to go, but I will come back earlier so that I can read your answer (if any), so don't worry if I don't answer right now. Anyway, that you so much for your help, it was really usefull ! [Mon May 16 04:01:08 2016] jun__: Ok thank you ! [Mon May 16 06:47:14 2016] hello. I'm looking for smallest lambda term for "pred_pf n : { n' : nat | n = S n'} + {n = O}". My version is http://pastebin.com/PWqG5iVB , it uses convoy pattern. Is it possible to avoid convoy here? (why smallest? -- I need to evaluate these terms in coq, small -> low memory usage.) [Mon May 16 06:56:21 2016] Yes gdsfh, you can avoid it in this case. Just remove the "n = n' -> " and the "fun eq =>" [Mon May 16 06:56:36 2016] as you can see, you haven't used at all "eq" in the two branches [Mon May 16 07:01:43 2016] Cypi: thank you! (really. feeling dumb.) [Mon May 16 07:16:04 2016] johnw: :-) I guess the best way of reaching me is via email, not IRC ;-) [Mon May 16 13:46:13 2016] Hum... Really coq doesn't like me ! [Mon May 16 13:46:55 2016] I would like to proove that (not (P -> Q)) -> P /\ not Q. [Mon May 16 13:47:42 2016] * is thinking [Mon May 16 13:47:52 2016] You can't :) [Mon May 16 13:49:44 2016] This statement is classical, and by default, Coq is only intuitionnistic [Mon May 16 13:58:13 2016] Cypi: Well, I'm trying to use "Definition classic := forall P:Prop, ~~ P -> P." in addition... But I'm a bit confused... [Mon May 16 13:58:24 2016] you can't Axiom that in [Mon May 16 13:58:27 2016] but you can't prove it [Mon May 16 13:58:35 2016] just defining "classic" won't help you [Mon May 16 13:59:03 2016] johnw: I can't try to prove this : [Mon May 16 13:59:04 2016] Lemma not_imply : classic -> forall (P Q:Prop), not (P -> Q) -> P /\ not Q. [Mon May 16 13:59:06 2016] ? [Mon May 16 13:59:12 2016] oh, you could prove that, sure [Mon May 16 13:59:18 2016] Ok [Mon May 16 13:59:20 2016] it's tricky, but not hard [Mon May 16 13:59:37 2016] Well I tried to use absurd (P -> Q) to do so [Mon May 16 13:59:48 2016] remember: you get to choose P and Q to be whatever you want [Mon May 16 13:59:52 2016] but I don't understand why absurd doesn't put in goal "False" [Mon May 16 14:00:10 2016] use contradiction [Mon May 16 14:01:14 2016] johnw: What should it do ? [Mon May 16 14:01:35 2016] contradiction H assumes that H is something -> False, and then makes something your goal [Mon May 16 14:01:46 2016] where ~ H is the same as H -> False [Mon May 16 14:01:50 2016] Oh... [Mon May 16 14:02:03 2016] I understand a bit better [Mon May 16 14:02:21 2016] And what is the difference between contradiction and absurd ? [Mon May 16 14:02:26 2016] i've never used absurd, actually [Mon May 16 14:02:49 2016] Hum ok. [Mon May 16 14:03:32 2016] * thinks again [Mon May 16 14:04:30 2016] I have to say I don't see that 'forall P Q, (not (P -> Q)) -> P /\ not Q' holds even with double negation as an axiom [Mon May 16 14:05:06 2016] stelleg: Double negation isn't equivalent to classical logic ? [Mon May 16 14:05:59 2016] tobiasBora: no idea, I am referring to your definition of "classic" though [Mon May 16 14:06:18 2016] but if johnw says it's provable it probably is :) [Mon May 16 14:06:25 2016] let me check actualy [Mon May 16 14:06:34 2016] I don't know about ~ (P -> Q) -> P /\ ~ Q [Mon May 16 14:07:09 2016] yeah [Mon May 16 14:07:38 2016] I don't think that classic -> ~ (P -> Q) -> P /\ ~ Q. [Mon May 16 14:07:50 2016] do case analysis on P and Q, treating connectives as boolean operators - does it hold? [Mon May 16 14:10:03 2016] yeah, I can't prove it [Mon May 16 14:11:05 2016] Really ? [Mon May 16 14:11:16 2016] So there is something I don't understand : [Mon May 16 14:11:21 2016] https://gist.github.com/ac4d1ab496bcfe976ffb99ba15b82530 [Mon May 16 14:11:32 2016] given classic, here's what I can prove: [Mon May 16 14:11:33 2016] Definition peirce := forall P Q: Prop, ((P->Q)->P)->P. [Mon May 16 14:11:35 2016] Definition excluded_middle := forall P : Prop, P \/ ~P. [Mon May 16 14:11:37 2016] Definition de_morgan_not_and_not := forall P Q: Prop, ~(~P /\ ~Q) -> P\/Q. [Mon May 16 14:11:38 2016] Definition implies_to_or := forall P Q: Prop, (P->Q) -> (~P\/Q). [Mon May 16 14:12:07 2016] but not ~ (P -> Q) -> P /\ ~Q. Is that supposed to be an inverted form of implies_to_or? [Mon May 16 14:12:08 2016] no, it's true [Mon May 16 14:12:20 2016] from a boolean standpoint [Mon May 16 14:13:08 2016] oh, duh! [Mon May 16 14:13:11 2016] it's provable [Mon May 16 14:13:11 2016] =) [Mon May 16 14:13:14 2016] told you~ [Mon May 16 14:13:16 2016] contradiction H0. [Mon May 16 14:13:16 2016] apply H1. [Mon May 16 14:13:17 2016] Abort. [Mon May 16 14:13:18 2016] [Mon May 16 14:13:21 2016] sorry, [Mon May 16 14:13:23 2016] https://gist.github.com/99bb58cce5dd08b1140f88cb84e1ef1d [Mon May 16 14:13:25 2016] thanks, benzrf, for keeping me sane [Mon May 16 14:13:28 2016] no problem :D [Mon May 16 14:13:57 2016] * is studing the proof [Mon May 16 14:16:20 2016] johnw: Where is imply_to_and defined ? [Mon May 16 14:16:26 2016] sorry [Mon May 16 14:16:48 2016] Coq.Logic.Classical [Mon May 16 14:17:59 2016] johnw: In fact I'm trying to show that all definitions are equivalents, that's why I wanted to proof that ^^ [Mon May 16 14:20:10 2016] * is re-re-thinking [Mon May 16 17:43:19 2016] I have prooved the property : [Mon May 16 17:43:21 2016] forall P:Prop, (~ (~ ~ P -> P)) /\ (~ P) -> False. [Mon May 16 17:43:35 2016] And in my hypothesis I have : [Mon May 16 17:44:12 2016] H : ~ (~ ~ P -> P) [Mon May 16 17:44:14 2016] H0 : ~ P [Mon May 16 17:44:41 2016] How could I use the above lemma to show that there is a contradiction in my hypothesis [Mon May 16 17:44:58 2016] You can start with "exfalso; apply " [Mon May 16 17:45:07 2016] (or, more directly, "elim ") [Mon May 16 17:49:33 2016] Cypi: I tried but it doesn't work... (or I think I did the wrong thing) You can find my proof here : http://pastebin.com/V2TEg9E6 [Mon May 16 17:50:12 2016] And "elim neg_abs" fail with the error : "Error: Unable to find an instance for the variable P." [Mon May 16 17:50:39 2016] and same thing with exfalso; apply neg_abs. [Mon May 16 17:51:01 2016] Ah, yes, that's because doesn't know what to put for the variable P here. So, two ways of dealing with it [Mon May 16 17:51:29 2016] 1) Just specify yourself which one you want: "elim (neg_abs P)" or "exfalse; apply (neg_abs P)" [Mon May 16 17:52:13 2016] 2) Let Coq put an existential here, which is a way of saying "You don't know yet what to put in here, but some time later in the proof, it will become obvious", by using eelim or eapply [Mon May 16 17:54:44 2016] Cypi: Yeeeeahhhh it works !!! I'm working on this proof for several hours... Thank you :D [Mon May 16 17:55:10 2016] :) [Mon May 16 18:01:16 2016] Cypi: Elim works with theorems that looks like "prop -> False" ? [Mon May 16 18:01:55 2016] Yes. Just like apply, it will try to do some clever things when the shape of your theorem isn't directly what is expected [Mon May 16 18:02:17 2016] like asking you to prove some premises [Mon May 16 18:04:07 2016] Ok ! And when the theorem isn't like "prop -> False" I can't do anything with it using elim or it's more general ? [Mon May 16 18:05:04 2016] It's more general. Actually, elim is some more basic variant of destruct I believe [Mon May 16 18:05:21 2016] in your case, "edestruct neg_abs" would have worked just the same [Mon May 16 18:07:22 2016] (I don't know why I picked up the habit of using "elim H" specifically when H ends with False) [Mon May 16 18:07:50 2016] what does this "e..." means ? [Mon May 16 18:07:57 2016] I see it very often [Mon May 16 18:08:26 2016] e means existential [Mon May 16 18:16:35 2016] Ok great thank you ! [Mon May 16 19:14:12 2016] Is it possible to have info from "tauto" ? [Mon May 16 19:14:33 2016] I tried "info_tauto" and "info tauto". [Mon May 16 19:17:29 2016] You can try "Info 1 tauto", but I'm not sure you will get much :) [Mon May 16 19:17:52 2016] The info_* stuff is supposed to be deprecated in 8.5, to be replaced with "Info ." [Mon May 16 19:23:26 2016] Cypi: Info 1 tauto. ==> "Error: The reference Info was not found in the current environment." [Mon May 16 19:23:49 2016] Hum [Mon May 16 19:23:57 2016] I'm running 8.4 [Mon May 16 19:26:27 2016] Ah, then you probably cannot. (But then again, don't worry, even in 8.5 I don't know if it gives much ^^ ) [Mon May 16 19:29:35 2016] (Ah well, I stand corrected, it can give some information: http://lpaste.net/163550 [Mon May 16 19:29:55 2016] but it's not very readable nor very reusable [Tue May 17 07:40:36 2016] Ok thank you ! [Tue May 17 10:14:40 2016] hello! given two variables x and y, how can I split my goal into two, where the first one considers the case when x = y, and the second one considers x <> y? [Tue May 17 10:15:13 2016] amaurremi: you can't in general unless you have a decision procedure for equality on values of their type [Tue May 17 10:15:25 2016] the law of excluded middle doesn't hold by default in coq. [Tue May 17 10:15:41 2016] crap i gotta go - but somebody else will probably help oyu :) [Tue May 17 10:15:43 2016] *you [Tue May 17 10:15:50 2016] right, okay, that makes sense, thanks [Tue May 17 10:16:32 2016] np [Tue May 17 10:19:14 2016] given the goal: (exists x, P1 /\ P2), is it possible to split it up into two goals, (exists x, P1) and (exists x, P2)? [Tue May 17 10:20:31 2016] sorry, I guess not, because it has to be the same x. never mind [Tue May 17 13:54:50 2016] A little question : I defined a recursive object, lets call it myobject. When I run "Check myobject_ind", I have the definition that appears, but when I run "Search my_object" I do not have the my_object_ind function [Tue May 17 13:55:19 2016] Is there a way to display this kind of function during searching ? [Tue May 17 13:59:56 2016] tobiasBora: Perhaps SearchAbout myobject. ? [Tue May 17 17:19:12 2016] Cale: I tried but same resul... [Tue May 17 17:20:40 2016] And I have another problem : I have an expression which returns a Prop, like : [Tue May 17 17:20:46 2016] 2 <= 1 \/ ((2 <= 1 -> False) /\ (2 <= 1 -> False)) /\ 5 <= 5 [Tue May 17 17:21:34 2016] And I would like to evaluate it to get a bool (false or true) [Tue May 17 17:22:09 2016] I tried Eval compute in, but it doesn't work. Is there anything else I could try ? [Tue May 17 17:27:41 2016] tobiasBora: Props are not bools [Tue May 17 17:28:13 2016] coq doesn't run on truth values [Tue May 17 17:28:54 2016] that expression is already in normal form [Wed May 18 13:51:30 2016] if I say: [Wed May 18 13:51:35 2016] remember A as B [Wed May 18 13:51:57 2016] Coq creates B and extra equality hypithesis H : A = B [Wed May 18 13:52:07 2016] can I somehow stop it from creating H ? [Wed May 18 13:52:54 2016] You can just do "pose proof A as B" [Wed May 18 13:53:07 2016] or "assert (B := A)" [Wed May 18 13:57:38 2016] how does pose proof exactly work? [Wed May 18 13:58:00 2016] I'm unable to comprehend the description in the user manual :-/ [Wed May 18 13:58:26 2016] "pose proof t" will really just creates a new hypothesis of the same type as t [Wed May 18 13:58:35 2016] This is basically an opaque set [Wed May 18 13:58:59 2016] ("set" as in the tactic) [Wed May 18 14:01:26 2016] I really liked ssreflect's set tactic [Wed May 18 14:01:29 2016] it was beatiful [Wed May 18 14:01:39 2016] ok, that makes much more sense than what the user manual says [Wed May 18 14:07:38 2016] "Anomaly: variable H unbound. Please report." [Wed May 18 14:07:49 2016] sounds like something that shouldn't happen [Wed May 18 14:08:18 2016] Indeed [Wed May 18 14:08:24 2016] How did you do that? ^^' [Wed May 18 14:08:36 2016] Also, are you using 8.5? (I don't remember) [Wed May 18 14:09:00 2016] 8.5, yes [Wed May 18 14:09:04 2016] you want to see the code? [Wed May 18 14:09:31 2016] Why not. Anomalies are not supposed to happen :) [Wed May 18 14:10:00 2016] give me a moment then. But first let me try an old trick of restaring Coq [Wed May 18 14:10:03 2016] sometimes that helps [Wed May 18 14:11:44 2016] Cypi: code is here: [Wed May 18 14:11:46 2016] https://github.com/jstolarek/sandbox/blob/master/coq/sf/MoreStlc.v [Wed May 18 14:11:55 2016] now, three interesting places in that code [Wed May 18 14:12:06 2016] Line 446: here's where the error is reported [Wed May 18 14:12:52 2016] line 402: here's that tactic that causes the error [Wed May 18 14:13:23 2016] previous version of that tactic that used to work began with "subtype_cases ..." and what is now H was passed as an argument [Wed May 18 14:13:55 2016] Let me clone that and see if I can reproduce it [Wed May 18 14:13:58 2016] lines 452-455 show how the previous version of solve_inversion_lemma_binary was used [Wed May 18 14:15:15 2016] my goal was to include intro and generalize dependent stuff in the tactic itself, as they are repeated in every proof [Wed May 18 14:17:29 2016] Well, at this point in your proof, H doesn't exist anymore, so it's kind of normal that it doesn't work [Wed May 18 14:17:36 2016] (H has been generalized back in the goal) [Wed May 18 14:18:12 2016] hm... [Wed May 18 14:18:25 2016] need to think about it for a moment [Wed May 18 14:18:29 2016] Although it shouldn't raise an anomaly anyway [Wed May 18 14:19:20 2016] ok, I see what happens [Wed May 18 14:19:40 2016] that was not a very useful error message but thanks for pointing out my mistake :-) [Wed May 18 14:50:39 2016] please actively report bad diagnostics problems; that's my current crusade [Wed May 18 14:50:51 2016] not to fix them, just to make sure enough reports get generated :) [Wed May 18 14:55:09 2016] is there an easy way to generate fresh names in Ltac? [Wed May 18 14:55:12 2016] for example [Wed May 18 14:55:13 2016] I say [Wed May 18 14:55:20 2016] remember A as B [Wed May 18 14:55:32 2016] "let B := fresh "B" in ..." [Wed May 18 14:55:45 2016] (or just "let B := fresh in ..." iirc) [Wed May 18 14:55:46 2016] ah [Wed May 18 14:55:57 2016] (if you don't care about the prefix) [Thu May 19 03:32:05 2016] I just learned that Hint Immediate and Hint Resolve will use simple apply rather than apply [Thu May 19 03:32:16 2016] this forces me to use Hint Extern [Thu May 19 03:32:35 2016] is there a way to force Hint Immediate and Hint Resolve to use apply and not simple apply? [Thu May 19 13:46:38 2016] jstolarek: I can't find the answer by simple search; maybe ask the ML? [Thu May 19 16:07:39 2016] jstolarek: I couldn't find the answer for this researching online; the best way might be to send a message to the Coq mailing list [Fri May 20 14:59:13 2016] dependently typed programming in Coq without tactics can feel very strange [Sun May 22 14:00:51 2016] So, I'm working through Software Foundations, and I'm trying to state the following theorem: Theorem bag_theorem : forall (v : nat) (s1 : bag) (s2 : bag), member v s1 /\ subset s1 s2 -> member v s2. [Sun May 22 14:01:00 2016] And I'm getting the error: The term "member v s1" has type "bool" while it is expected to have type "Prop". [Sun May 22 14:01:09 2016] What am I doing wrong? [Sun May 22 14:04:54 2016] Hm, I've just realised I can solve it by adding `= true' three times. [Sun May 22 14:05:05 2016] Still, is there a better way? [Sun May 22 14:10:51 2016] And now I've no idea how to prove this theorem. :-D [Sun May 22 14:24:07 2016] fds: i think there might be a function bool -> Prop in the stdlib [Sun May 22 14:24:13 2016] which basically just does = true [Sun May 22 14:25:12 2016] I see. [Sun May 22 14:25:42 2016] I suppose I'll just leave it like this then. [Sun May 22 14:25:51 2016] Now I'm practising with unfold. :-) [Mon May 23 13:02:46 2016] it's called "is_true" [Tue May 24 12:38:04 2016] Is there a version of the code in sofware fundation that works with coq 8.5 or should I downgrade back to 8.4 ? [Tue May 24 12:38:15 2016] I'm not aware of the 8.5 port having been announced yet [Tue May 24 12:38:20 2016] but it is being worked on [Tue May 24 12:39:24 2016] ok, downgrading it is, then [Tue May 24 12:39:36 2016] 8.4.6 is ok ? [Tue May 24 12:39:54 2016] sure [Tue May 24 18:25:48 2016] Drup: there's a 4.0 beta version of SF that works with 8.5 http://www.cis.upenn.edu/%7Ebcpierce/sf/sf-4.0/ [Tue May 24 18:59:17 2016] Has anyone recreated the results from Chapman's Levitation paper in Coq? [Tue May 24 19:00:59 2016] I've been experimenting with different ways of encoding inductive types so I can replicate Godelian results, and the Levitation paper seems like the simplest way to do it [Tue May 24 19:15:20 2016] gallabytes: never heard of it :) [Tue May 24 19:19:12 2016] benzrf: https://jmchapman.github.io/papers/levitation.pdf [Tue May 24 19:19:31 2016] Its a schema for inductive definitions that's strong enough to encode itself [Tue May 24 19:20:16 2016] Most of the definitions go through in Coq, but the fixpoint definition fails the positivity checker [Tue May 24 19:20:23 2016] (it passes the one in Agda though) [Wed May 25 11:33:03 2016] https://github.com/FormalTheology/GoedelGod [Wed May 25 11:35:53 2016] lol [Wed May 25 14:10:56 2016] any good channels for the discussion of formal verification? [Wed May 25 14:20:47 2016] this is a good one, I'd think [Wed May 25 14:21:47 2016] Also ##typetheory [Fri May 27 22:30:42 2016] Hello, is there some comparison between CoC(as in coq) and CTT(as in nuprl)? [Sat May 28 00:18:11 2016] riaqn: you might try asking over at ##typetheory [Sat May 28 00:19:30 2016] pretty sure that jonsterling's your man [Sat May 28 01:05:22 2016] steshaw: thx [Sat May 28 11:44:39 2016] is there any typical approach in coq to finite multisets [Sat May 28 11:44:53 2016] i'm thinking about prime factorization in particular [Tue May 31 18:50:14 2016] hello [Tue May 31 18:52:12 2016] Say I'm working with strings, and I want to prove this: forall a b c : string, (a ++ b)%string <> (a ++ c)%string -> b <> c [Tue May 31 18:52:49 2016] Induction on a. The empty case is easy. [Tue May 31 18:53:22 2016] But then I get: String a (...) <> String a (...) -> b <> c [Tue May 31 18:53:48 2016] Which seems obvious from structural equality. But I don't know how to eliminate the "String a" part. [Tue May 31 18:56:33 2016] eraserhd: I don't think you need induction for this at all. [Tue May 31 18:56:47 2016] jrw: not surprised, actually :) [Tue May 31 18:57:08 2016] it suffices to prove [b = c -> a ++ b = a ++ c], which could be done with [intros; subst; reflexivity] [Tue May 31 19:10:01 2016] ok, neat [Tue May 31 21:38:33 2016] I would love a way where, instead of case analysis on a match variable, I can make each match case a subgoal. [Tue May 31 21:39:14 2016] (because there are fewer match cases than constructors). [Tue May 31 21:55:42 2016] eraserhd: Can you give an example of the situation you're in? I'm not sure I clearly understand from that description what you want, but I believe you can do that. [Tue May 31 22:00:09 2016] eraserhd: You can do something like refine (match foo with | pat1 => _ | pat2 => _ | ... end). [Tue May 31 22:00:30 2016] eraserhd: and you'll get subgoals for each blank [Tue May 31 22:02:30 2016] Cale: https://gist.github.com/eraserhd/f86f86bb58c71765881529c16b05556f [Tue May 31 22:02:57 2016] case a makes eight booleans, each of which makes 256 cases. [Tue May 31 22:04:45 2016] ugh, that's not a very pretty looking type... [Tue May 31 22:05:02 2016] heh. [Tue May 31 22:05:04 2016] But you should be able to write a match return... [Tue May 31 22:05:08 2016] hm [Tue May 31 22:05:41 2016] Is there some simpler way to write that goal? [Tue May 31 22:06:59 2016] That's the result of 'compute'. It was this: https://gist.github.com/eraserhd/d348ac42dd450088cca705fd36a34f7a [Tue May 31 22:07:12 2016] ah, okay [Tue May 31 22:07:41 2016] I'm trying to prove that pipe_escape is injective. Also, I'm a noob. [Tue May 31 22:08:57 2016] I have it working with induction a; induction b0; induction b1; induction b2; ...; discriminate. But ick. [Tue May 31 22:09:30 2016] haha [Tue May 31 22:10:10 2016] Well, do you want to handle each of these cases individually? [Tue May 31 22:11:30 2016] er... no? If it's possible to not handle them individually, I'd prefer not to. [Tue May 31 22:13:01 2016] http://lpaste.net/164952 -- does this command actually work? :) [Tue May 31 22:15:06 2016] eraserhd: (I'm just curious) [Tue May 31 22:15:58 2016] it runs :) [Tue May 31 22:16:03 2016] But you can probably write something which does those inductions... can I have enough of your file to be able to play around with it? [Tue May 31 22:16:36 2016] So yeah, you should get a whole bunch of goals then, one for each of the right hand sides of that match [Tue May 31 22:16:43 2016] But that seems... not so fun. [Tue May 31 22:17:03 2016] Yeah. But it works if I add "; discriminate" to the end. [Tue May 31 22:17:16 2016] ah, cool [Tue May 31 22:17:49 2016] wait a minute... [Tue May 31 22:18:00 2016] Does discriminate work on its own? :) [Tue May 31 22:18:55 2016] oh, I guess you might not have a hypothesis in scope which is discriminable [Tue May 31 22:19:30 2016] I wonder what ediscriminate a. would get you [Tue May 31 22:21:21 2016] I actually forgot to recurse in pipe_escape. So it looks worse now :) [Tue May 31 22:21:48 2016] Welp. Time for bed. [Tue May 31 22:21:56 2016] Cale: g'night and thanks. [Tue May 31 22:22:00 2016] g'night [Wed Jun 1 00:41:07 2016] Hello [Wed Jun 1 00:41:21 2016] I have a syntax question [Wed Jun 1 00:41:39 2016] Is this a good place to ask? [Wed Jun 1 00:46:04 2016] ah! sorry, I think I have figured out my problem [Wed Jun 1 01:22:01 2016] penlu: for future reference, this is a good place to ask :) [Wed Jun 1 05:05:07 2016] Is there a way to Print a term without using notations? [Wed Jun 1 05:07:13 2016] ah, "Eval compute in x" worked for me [Wed Jun 1 05:44:55 2016] steshaw : you can also use "Unset Printing Notations." before printing, or the corresponding option in the "View" menu if you're using CoqIDE [Wed Jun 1 05:45:25 2016] Cypi: thanks [Wed Jun 1 05:47:19 2016] "Eval compute in x" wasn't working for all the cases I had [Wed Jun 1 05:51:29 2016] It will actually reduce the term to its normal form, but if the normal form matches some notations it will use them to print it [Wed Jun 1 05:56:06 2016] I didn't have an calculations to perform AFAICT. However, there were definitions to substitute. That's why I thought it was working. [Wed Jun 1 05:56:37 2016] None of the notations were actually expanded using Eval only. [Wed Jun 1 05:56:42 2016] Thanks for you help. [Wed Jun 1 16:43:12 2016] How would I "split" a hypothesis (a conjunction), such that I have two hypotheses. [Wed Jun 1 16:43:14 2016] ? [Wed Jun 1 16:43:49 2016] eraserhd: "destruct H." where H is the hypothesis name should do it. [Wed Jun 1 16:44:18 2016] jrw: I swear I did this! But it works. [Wed Jun 1 18:21:15 2016] How would you proceed with this?: https://gist.github.com/eraserhd/40e25f309cb1d2bc81b943af734630cb [Wed Jun 1 18:21:34 2016] Also, any sort of feedback is welcome. I'm certain it's overcomplicated so far. [Wed Jun 1 19:01:48 2016] eraserhd: well, you can intro more at that point. I'm not an expert, but I might also try to avoid expand pipe_escape unless it's necessary (your inductive hypotheses are in terms of pipe_escape and it's easier to read) [Wed Jun 1 19:04:22 2016] * just found `functional induction`. Yay. [Wed Jun 1 19:08:09 2016] huh, never knew about that one [Thu Jun 2 00:20:48 2016] Hello [Thu Jun 2 00:21:03 2016] I am wondering if coq has any facilities for modules as in the mathematical object [Thu Jun 2 00:21:55 2016] I've found rings and fields in the standard library but they were a little obscure and module is a bad keyword when it comes to coq so I was wondering if I missed anything [Thu Jun 2 01:58:20 2016] penlu: I would suggest taking a look at the mathematical components library/extension to coq at https://github.com/math-comp/math-comp [Thu Jun 2 02:00:10 2016] Thanks! [Thu Jun 2 02:02:51 2016] in particular I believe the algebra/ssralg.v file defines modules over a ring [Thu Jun 2 09:34:02 2016] Does anyone knows an example of a formalization of a staged calculus in Coq/Locally nameless ? [Thu Jun 2 14:27:27 2016] Hrmm. I have [ H : a0 <> b0 |- a0 = b0 ], but "contradiction" doesn't do anything. What am I doing wrong? [Thu Jun 2 14:32:24 2016] Ooh, "injection" is what I was looking for yesterday. [Thu Jun 2 15:32:08 2016] Hello all. Is this an appropriate place to ask for short form pointers on Coq issues I'm stuck on (and have already researched as best I know how)? [Thu Jun 2 15:52:12 2016] ampere: ask away! [Thu Jun 2 19:19:57 2016] Does Z -> string exist anywhere? If not, how might I go about doing that (taking an integer and getting its string representation)? [Fri Jun 3 09:01:42 2016] jstolarek pasted “No title” at http://lpaste.net/165168 [Fri Jun 3 09:02:16 2016] it seems that the last part in the match branch - `unfold extend in E [Fri Jun 3 09:02:21 2016] does not work [Fri Jun 3 09:02:44 2016] I know that hypothesis generated by inversion contains "extend" [Fri Jun 3 09:03:18 2016] but after the "match goal..." `extend` is still folded [Fri Jun 3 09:03:45 2016] Is it possible to have slightly more code, to be able to try it myself? [Fri Jun 3 09:06:15 2016] just a sec [Fri Jun 3 09:07:45 2016] Cypi: https://github.com/jstolarek/sandbox/blob/master/coq/sf/MoreStlc.v#L896 [Fri Jun 3 09:11:21 2016] this fragment of code is in a flux - I'm trying to make it work, so subsequent lines of code might require some minor editing [Fri Jun 3 09:12:44 2016] I don't see a problem. E is H0, so there is nothing to unfold [Fri Jun 3 09:13:23 2016] I guess you should do something like "inversion H0 as [? E]" [Fri Jun 3 09:13:33 2016] since apparently there is a first variable before the one you're interested in [Fri Jun 3 09:15:02 2016] (quick tip: I just added "idtac E" at the end of the tactic to check what was the name bound to E) [Fri Jun 3 09:16:26 2016] oh [Fri Jun 3 09:16:33 2016] you are of course right [Fri Jun 3 09:16:35 2016] thanks! [Fri Jun 3 09:16:46 2016] I knew it must be some silly mistake [Fri Jun 3 15:17:07 2016] Yay, back to hacking on Coq. [Fri Jun 3 15:17:19 2016] I mean a Coq proof. I can't actually hack on Coq. [Fri Jun 3 15:22:55 2016] how to eliminate a <-> in a goal? [Fri Jun 3 15:23:27 2016] why, `unfold iff` of course. [Fri Jun 3 15:31:38 2016] you can also just [split] directly :) [Fri Jun 3 15:42:12 2016] benzrf: Cool. [Fri Jun 3 15:42:52 2016] I can't remember how to search for things or run a command-line (like Check) with Proof General. Anyone know off the top of their head? [Fri Jun 3 15:48:23 2016] C-c C-a C-c [Fri Jun 3 15:48:33 2016] and C-c C-a C-p for print [Fri Jun 3 15:49:08 2016] Drup: Ah, thanks! [Fri Jun 3 15:50:12 2016] actually, what is the emacs command for mode help? I basically only use emacs for Coq. [Fri Jun 3 15:50:24 2016] (and can't remember a lot of it :) [Fri Jun 3 15:52:15 2016] Oh, I just found a vim plugin. Makes me wonder why i'm using emacs. :/ [Fri Jun 3 16:06:12 2016] and... it needs me to downgrade Coq. Nevermind. [Fri Jun 3 16:21:02 2016] Is it possible to run `injection` in a hypothesis? [Sat Jun 4 16:10:43 2016] @pl \s -> fmap (first f) (runParser a s) [Sat Jun 4 16:10:47 2016] whoops [Sun Jun 5 15:06:29 2016] this is unprovable, right? [forall P P' : nat -> Type, (forall x, P x) = (forall x', P' x') -> P O = P' O] [Sun Jun 5 15:55:08 2016] looks like it benzrf [Sun Jun 5 15:55:17 2016] Kk [Sun Jun 5 22:35:36 2016] relrod pasted “Why does this fail with a stack overflow?” at http://lpaste.net/165528 [Sun Jun 5 22:35:47 2016] That's the smallest repro I could come up with I think [Sun Jun 5 22:36:32 2016] Am I just doing something silly? [Sun Jun 5 22:43:08 2016] relrod: It's the extra parameter to BlahInstance [Sun Jun 5 22:43:51 2016] relrod: It results in an infinite loop, looking for an instance of Blah to fill the C parameter, and then attempting to use the very same instance, resulting in another C parameter which needs to be filled... [Sun Jun 5 22:44:27 2016] Usually Haskell would complain at you for writing this, but Coq's type class mechanism is a bit less picky. [Sun Jun 5 22:45:28 2016] Well, it would be weird writing this in Haskell in the first place, because the class has no parameters. [Sun Jun 5 22:46:17 2016] but it's like writing instance Blah => Blah where ... [Sun Jun 5 22:49:14 2016] Cale: What if I want to refer to something from C in the instance though? (I'm just kind of playing around and I'm really new to this and probably getting it all wrong, but...) [Sun Jun 5 22:49:47 2016] Probably first of all your class should have a parameter. [Sun Jun 5 22:50:10 2016] https://bitbucket.org/amintimany/categories/src/bd56bc28cc67507707453794efbdf4a78f632d0a/Category/Opposite.v?at=master&fileviewer=file-view-default -- Taking this for inspiration; they do something similar [Sun Jun 5 22:50:59 2016] It's kind of funny that Coq has all this machinery to ensure that things terminate, and then doesn't do even a little bit of it when checking type classes / instances. :) [Sun Jun 5 22:52:19 2016] Yeah, I'm still getting used to all the semantics. [Sun Jun 5 22:53:02 2016] Cale: In that file I linked, they do something similar, implementing an instance of their Category class, which also takes no parameters. That's why I did it this way (ultimately I'm trying to implement a tiny CT lib just for learning. I was referring to theirs as needed.) [Sun Jun 5 22:53:23 2016] yeah, that's interesting [Sun Jun 5 22:55:13 2016] Perhaps they're taking advantage of the order in which type class instances are attempted [Sun Jun 5 22:56:16 2016] yeah, if you insert another instance, like Instance BaseBlah : Blah := { ob := bool }. [Sun Jun 5 22:56:25 2016] then it no longer loops [Sun Jun 5 22:59:08 2016] I just found https://github.com/amintimany/Categories/blob/master/Category/Opposite.v which is apparently more recent, and they use Definition instead of Instance.... which makes more sense to me I think. [Sun Jun 5 22:59:41 2016] But what do I know :) [Sun Jun 5 22:59:53 2016] Not much. Yet. :) [Sun Jun 5 23:00:26 2016] yes, that makes much more sense [Sun Jun 5 23:00:57 2016] You would want it to try to automatically use the opposite category when it needed a category [Sun Jun 5 23:04:41 2016] Cale: thanks for your help :) [Sun Jun 5 23:34:48 2016] er, I just realised I automatically said the opposite of what I meant [Sun Jun 5 23:35:01 2016] wouldn't* :) [Sun Jun 5 23:35:10 2016] Yeah I knew what you meant :) [Fri Oct 7 16:30:20 2016] Can coqdoc and coq-tex be used together? [Fri Oct 7 16:41:37 2016] Is there any way to get results like coq-tex in coqdoc output? [Fri Oct 7 17:48:42 2016] It seems coq-tex does not like bullets [Sat Oct 8 10:29:28 2016] Is there a way to make the rewrite tactic only apply to a specific subterm? What is the general rule that the rewrite tactic uses if there are multiple matching subterms? [Sat Oct 8 10:31:20 2016] one thing you can do is use replace tactic, or assert the specific rewrite you want [Sat Oct 8 10:32:53 2016] Thank you, modulus. I will look into the replace tactic and asserting rewrites. [Sat Oct 8 10:33:19 2016] replace is like replace (x) with (y), and it sets that as a proof obligation, and replaces it on the goal. [Sat Oct 8 10:33:44 2016] assert (H:x = y) will set that as a new proof obligation, and once proven presents as a hypothesis H which you can do rewrite H with. [Sat Oct 8 10:34:36 2016] Great, I understand now. Thanks again. [Sat Oct 8 10:34:50 2016] yw [Sat Oct 8 12:34:43 2016] If one of the hypotheses in the context is identical to the goal is there a tactic for asserting the goal being just a hypothesis/axiom. [Sat Oct 8 12:35:02 2016] For example, if A -> B is a goal and A -> B is a hypothesis in the context. [Sat Oct 8 12:38:02 2016] Sorry, I just figured out the answer to my question. Do you use exact? [Sat Oct 8 12:44:38 2016] vramesh : "assumption" [Sat Oct 8 12:44:56 2016] It will do just that: look in the context for a hypothesis which is exactly the goal [Sat Oct 8 12:45:13 2016] you can also use "exact H" if you want to specify which hypothesis you use, indeed [Sat Oct 8 12:50:02 2016] Cypi: Thank you very much - did not know about "assumption". [Sat Oct 8 13:21:26 2016] on the sofwtrae ofudnaitosn logic chapter ,i' mtyrin gto do the tr_erv exerciess, whic hinovvles: [Sat Oct 8 13:21:26 2016] Lemma tr_rev_correct : forall X, @tr_rev X = @rev X. [Sat Oct 8 13:22:03 2016] i'm introing X, then applying functional extensionality. then induction on x. and there i get stuck. i can't get anything useful out of rev_append, which unfolds from tr_rev. any clues? [Sat Oct 8 13:22:39 2016] also apologies, my keybaord is doin gsoemhting weird. [Sun Oct 9 20:28:49 2016] benzrf: wondering which channel you meant originally. [Sun Oct 9 20:29:58 2016] just one i talk to friends in [Sun Oct 9 22:35:16 2016] does the term "inhabitant" generally refer to expressions, or to specifically semantic objects [Sun Oct 9 22:37:48 2016] benzrf: an inhabitant is a member of a type [Sun Oct 9 22:38:33 2016] johnw: so - an expression? [Sun Oct 9 22:42:08 2016] every expression must evaluate to an inhabitant [Sun Oct 9 22:42:50 2016] in my sense, "be an inhabitant of" is literally a synonym for "have type", so the former. Maybe other people give a more specific sense to it [Sun Oct 9 22:42:51 2016] and since "1 + 1" and 2 denote the same thing [Sun Oct 9 22:43:20 2016] yeah, "have a type" is a pretty good rule of thumb [Sun Oct 9 22:43:37 2016] given some x and T such that x : T, then x is an inhabitant of T [Sun Oct 9 22:44:31 2016] it's less interesting to ask what form it takes, expression or naked constructor, etc. [Sun Oct 9 22:56:51 2016] johnw: well - is False inhabited in haskell? [Sun Oct 9 23:02:33 2016] False in Haskell is really False⊥ [Sun Oct 9 23:02:48 2016] so yes, it's inhabited there, by ⊥ [Sun Oct 9 23:03:14 2016] so then inhabitants are semantical objects, not expressions [Sun Oct 9 23:03:22 2016] and not this: 10:43:37 johnw │ given some x and T such that x : T, then x is an inhabitant of T [Sun Oct 9 23:03:37 2016] ? [Sun Oct 9 23:03:43 2016] what is a "semantical object" and what is an "expression"? [Sun Oct 9 23:04:06 2016] i mean - you can define a language and a type system without giving it semantics... [Sun Oct 9 23:04:15 2016] "⊥" is not a haskell expression [Sun Oct 9 23:04:24 2016] but ":" is a relation between expressions and types [Sun Oct 9 23:04:32 2016] do you mean, a language that is purely syntax? [Sun Oct 9 23:05:02 2016] well, this isnt a terribly important question [Sun Oct 9 23:05:04 2016] its ok [Sun Oct 9 23:05:07 2016] ok [Sun Oct 9 23:05:18 2016] you sound like you need a precise answer, but I don't understand the question well enough [Mon Oct 10 13:06:03 2016] benzrf: I would also say the latter [Mon Oct 10 13:06:42 2016] but then I'd use it loosely with expressions [Mon Oct 10 13:08:08 2016] but I'd say the inhabitants are the canonical values of the type [Mon Oct 10 17:40:51 2016] Can proof general work on a coq-tex input file? [Tue Oct 11 12:09:00 2016] does anyone use coq-tex? [Tue Oct 11 12:40:44 2016] Is coq-tex the best way to show intermediate goals of a proof in a document? [Tue Oct 11 13:00:14 2016] so far i've found coq-tex to be fairly unsatisfying; I'd be interested to see what you come up with [Tue Oct 11 13:05:30 2016] wrengr_away: congruence is the one ive been looking for :) [Tue Oct 11 13:08:42 2016] So far I've just been looking for some way to step through only the code of a coq-tex input file with coq-mode in emacs, rather than replacing coq-tex itself [Tue Oct 11 13:09:16 2016] I did notice that coq-tex itself is a self-contained and fairly small ocaml program, so it might not be so bad [Tue Oct 11 16:58:01 2016] johnw: I at least got ProofGeneral working on coq-tex files by extending it's comment regex to count the \begin{coq_...} makers as ending comments, and \end{coq...} as starting a comment [Tue Oct 11 17:38:38 2016] is there a tactic to prove a goal by contradiction when there's a hypothesis like S n = n [Tue Oct 11 17:39:02 2016] inversion [Tue Oct 11 17:39:12 2016] no, you need to do an induction for this [Tue Oct 11 17:39:15 2016] just gives you another hypothesis [Tue Oct 11 17:39:22 2016] (or use something like omega probably) [Tue Oct 11 17:39:29 2016] omega is prob the easy way [Tue Oct 11 17:39:32 2016] there is nothing built-in for acyclicity [Tue Oct 11 17:39:34 2016] hmm [Tue Oct 11 17:39:37 2016] or intuition [Tue Oct 11 17:39:55 2016] I don't think intuition works. omega might do it? [Tue Oct 11 17:40:02 2016] yeah intuition doesn't work [Tue Oct 11 17:40:10 2016] omega works [Tue Oct 11 17:40:10 2016] omega owrks [Tue Oct 11 17:40:16 2016] yeah S n = 0 would but not = n i guess, silly me. [Tue Oct 11 17:40:17 2016] I think there is a theorem like that already [Tue Oct 11 17:40:38 2016] Nat.neq_succ_diag_l: forall n : nat, S n <> n [Tue Oct 11 17:41:03 2016] Conor McBride's "A Few Constructions on Constructors" describes a general approach for proving acyclicity theorems [Wed Oct 12 08:40:42 2016] Hi, I am trying to write a function, which returns a proof of n Please look at my code here : http://pastebin.com/1nJW5hjY [Wed Oct 12 08:41:03 2016] Can you suggest the last entry? [Wed Oct 12 08:44:52 2016] ankitk: what should happen if you feed n = 1, m = 0 in your function? [Wed Oct 12 08:45:21 2016] my fixpoint function needs to return proof of 1 < 0 [Wed Oct 12 08:45:29 2016] but that is not possible! [Wed Oct 12 08:45:34 2016] yeah [Wed Oct 12 08:45:40 2016] so you cannot write such a function [Wed Oct 12 08:45:46 2016] oh [Wed Oct 12 08:46:12 2016] but the Vector library expects proofs, such as p < m [Wed Oct 12 08:46:33 2016] when we want to get pth term from a vector of length m [Wed Oct 12 08:46:40 2016] how to provide that? [Wed Oct 12 08:46:41 2016] But you cannot really provide such a proof if p is not less than m [Wed Oct 12 08:46:49 2016] right [Wed Oct 12 08:47:08 2016] What you can write is a function with the type forall (n m: nat) : (n < m) + (n >= m) [Wed Oct 12 08:47:35 2016] in fact, such a function/theorem is probably somewhere in the standard library [Wed Oct 12 08:48:15 2016] so if you have specific n and m for which you know that n > m, you can use the decidability of > to provide a proof [n > m] [Wed Oct 12 08:48:54 2016] that is there, but then then the functions replace_order and nth_order expect only (H : p < n) [Wed Oct 12 08:49:17 2016] do i need to hand construct the proof before calling such functions? [Wed Oct 12 08:51:58 2016] hm there should be a better way [Wed Oct 12 08:52:11 2016] unfortuntely, i am not very familiar with dependent type programming myself [Wed Oct 12 08:52:20 2016] okk [Wed Oct 12 08:52:44 2016] Thanks @notdan [Wed Oct 12 08:53:41 2016] maybe you can put a placeholder _ where the proof (p < n) is expected. albeit i doubt that it can figure out the proof automatically. [Wed Oct 12 09:01:18 2016] i will try yhat [Wed Oct 12 09:01:21 2016] that [Wed Oct 12 09:02:31 2016] it works :) [Wed Oct 12 09:02:38 2016] Thanks [Wed Oct 12 09:02:52 2016] so coq handles it on its own [Wed Oct 12 09:03:02 2016] cool :) [Wed Oct 12 09:18:55 2016] hi all. I wrote thousands of lines of Coq in the past but it's been a while and apparently I forgot all the cool commands (for searching in library etc.) and even the syntax. what's a good quick tutorial these days as a refresher? [Wed Oct 12 09:27:06 2016] https://cel.archives-ouvertes.fr/file/index/docid/459139/filename/coq-hurry.pdf [Wed Oct 12 09:27:18 2016] osal this paper is a good refresher [Wed Oct 12 09:29:46 2016] ankitk: thanks, will take a look [Wed Oct 12 13:14:52 2016] KaneTW: afaict, there's no general tactic that'll turn cyclic equality proofs into falsum. But you can do it yourself by reimplementing structural induction with wf-induction [Wed Oct 12 13:16:29 2016] notdan: glad I could help [Wed Oct 12 14:30:24 2016] hi anyone up for stepping through a small proof. i face a problem regarding use of unfold/fold? [Wed Oct 12 14:53:12 2016] sure [Thu Oct 13 06:40:22 2016] Hi, I am trying to write the TAL-0 language in coq (assembly with types) [Thu Oct 13 06:40:42 2016] code is here : https://github.com/ankitku/awotap/blob/master/TAL.v [Thu Oct 13 06:41:26 2016] I am having trouble using the apply tactic with R_IJmp_Succ [Thu Oct 13 06:42:14 2016] on using with in this apply in ieval_example1 , I am getting error "Not the right number of missing arguments (expected 0)." [Thu Oct 13 06:42:49 2016] Please help, note to compile this , you will need to compile (coqc Maps.v) first [Thu Oct 13 12:19:12 2016] ankitku: which argument are you trying to fill? [Thu Oct 13 12:19:44 2016] you should say "with (name := ...)", otherwise it will think you're trying to fill some remaining arguments after having inferred the ones you cared for [Thu Oct 13 12:20:30 2016] ok, I am trying to give intermediate step for R_IJmp_Succ [Thu Oct 13 12:20:50 2016] but you're trying to give a state [Thu Oct 13 12:21:12 2016] because in R_IJmp_Succ st1 st2, st2 will not match the final state I am trying to prove [Thu Oct 13 12:21:18 2016] but R_IJmp_Succ doesn't take a state as input [Thu Oct 13 12:21:21 2016] yes, a state [Thu Oct 13 12:21:40 2016] so, I am giving st2' [Thu Oct 13 12:22:03 2016] what will the name in (name := ) be? [Thu Oct 13 12:22:19 2016] well it won't be anything because there is no state to fill [Thu Oct 13 12:23:12 2016] you might have made your semantics too specific to be practical to use [Thu Oct 13 12:23:52 2016] here your R_IJmp_Succ rule won't apply unless you can first show [Thu Oct 13 12:24:06 2016] (t_update init_regs (Id 3) 0 = final_regs [Thu Oct 13 12:24:10 2016] t_update init_regs (Id 3) 0 = final_regs [Thu Oct 13 12:24:26 2016] yes, but that won't happen now [Thu Oct 13 12:24:37 2016] final regs will be after running of the loop [Thu Oct 13 12:24:52 2016] so, i need to give an intermediate step [Thu Oct 13 12:25:37 2016] well then your semantics are wrong [Thu Oct 13 12:25:43 2016] in the code, I have given the intermediate state after keyword "with" [Thu Oct 13 12:25:54 2016] ieval (IJmp (ANum v)) (St H R (IJmp (ANum v))) (St H R I') [Thu Oct 13 12:26:04 2016] you have the same R before and after the step it seems [Thu Oct 13 12:26:42 2016] or your theorem is wrong [Thu Oct 13 12:28:08 2016] well R will be same, registers won't change after the jump [Thu Oct 13 12:28:37 2016] In the theorem I have given the final state, i.e. after the whole loop for calculating product has run [Thu Oct 13 12:28:53 2016] program finds product of 1 and 2 [Thu Oct 13 12:30:11 2016] R_ISeq case works perfectly, but i am getting stuck in R_IJmp case [Thu Oct 13 12:30:20 2016] well, I believe that you made a mistake somewhere, maybe in your very first proof step [Thu Oct 13 12:32:07 2016] hm, but it works as expected [Thu Oct 13 12:33:58 2016] if you copy the state after "with" in R_IJmp_Succ and paste it in the theorem,instead of the final state, the proof completes [Thu Oct 13 13:13:39 2016] yeah, because that theorem is correct [Thu Oct 13 13:13:45 2016] but the one you wrote isn't necessarily [Thu Oct 13 13:14:47 2016] ieval (IJmp (ANum 2)) [Thu Oct 13 13:14:47 2016] (St init_heap (t_update (t_update (t_update empty_regs (Id 1) 1) (Id 2) 2) (Id 3) 0) [Thu Oct 13 13:14:51 2016] (IJmp (ANum 2))) [Thu Oct 13 13:14:53 2016] (St init_heap (t_update (t_update (t_update empty_regs (Id 1) 0) (Id 2) 2) (Id 3) 2) [Thu Oct 13 13:14:56 2016] (IJmp (ANum 4))) [Thu Oct 13 13:14:59 2016] does this look right? [Thu Oct 13 13:15:18 2016] it seems like the register contents are different to me [Thu Oct 13 16:02:51 2016] hello [Thu Oct 13 16:03:09 2016] what book on Coq you like and recommend? [Thu Oct 13 16:05:14 2016] depends on what you want to do with coq. [Thu Oct 13 16:08:30 2016] RegEchse: I want to fully understand the underlying theory and have maximum ability to use it practically [Thu Oct 13 16:16:04 2016] antonv: start with Software Foundations, then Certified Programming with Dependent Types [Thu Oct 13 16:16:27 2016] also, what are you going to use Coq for? [Thu Oct 13 16:16:30 2016] math? program semantics? [Thu Oct 13 16:17:45 2016] johnw: thanks for recommendations. My primary desire is to understand it fully. [Thu Oct 13 16:19:15 2016] if you're interested in the type theory behind it, and the Calculus of Constructions, there are other resources, mostly academic articles [Thu Oct 13 16:29:07 2016] johnw: ideally I'd like a book fully self-contained, not requiring prior expertise [Thu Oct 13 16:29:16 2016] academic articles might use specific [Thu Oct 13 16:29:29 2016] might assume substantial knowledge. [Thu Oct 13 16:29:52 2016] I'm not aware of any such book [Thu Oct 13 16:32:50 2016] software foundations starts more or less from zero but probably doesn't cover all of coq [Thu Oct 13 16:33:13 2016] how's coq.art? [Thu Oct 13 16:55:22 2016] ok, maybe not fully self-contained, but let's assume a reader has some basic understanting of logic (logical entailment, resolution, induction). [Thu Oct 13 16:56:26 2016] Are there books which explain the remaining parts of type theories and coq? [Thu Oct 13 17:55:08 2016] the "Certified Programming with Dependent Types" seems close to that... [Thu Oct 13 17:55:13 2016] thanks for the reference [Thu Oct 13 17:55:26 2016] CPDT is an excellent text for the working Coq user [Thu Oct 13 17:55:44 2016] if your intention is to use it practically, that's a good one [Thu Oct 13 17:56:07 2016] the main thing is that there are several ways of approaching problems in Coq, and choosing the way appropriate to your problem is a huge part of finding success [Thu Oct 13 17:57:23 2016] johnw: how do you use Coq? (for what purpose?) [Thu Oct 13 17:57:47 2016] I use it at work for formalizing software semantics [Thu Oct 13 17:58:03 2016] I'm also using it for provably correct program synthesis, from those semantics [Thu Oct 13 17:59:32 2016] when one mastered coq, how long / expencise it is to formalize some software module? Say some scheduler which distributes work from a queue to workers. [Thu Oct 13 17:59:50 2016] Is it a project for a month, for 6 month, a year, 3 years? [Thu Oct 13 18:00:34 2016] depends on what properties you want to prove. [Thu Oct 13 18:01:15 2016] well, theat the tasks is always handled, that the queue doesn't become too long, that the task is given to a less loaded worker, etc, etc. [Thu Oct 13 18:01:52 2016] well, maybe my question is too vague... [Thu Oct 13 18:02:25 2016] I'm just thinking how realistic it is to hope to use Coq for the existing java system I'm working on now. [Thu Oct 13 18:03:41 2016] Can I hope to have benefits from Coq in that usual java project, or in the current state of certified programming thechnology it's only practical for very specific projects, which can afford huge investments. [Thu Oct 13 18:04:48 2016] if it's a first time, and the project would have taken you a month in your language of choice, assume a year for Coq [Thu Oct 13 18:05:01 2016] I doubt it will help you in the usual java project anytime soon [Thu Oct 13 18:05:09 2016] unless you have one core component that it's important to verify [Thu Oct 13 18:05:51 2016] Coq is a fantastic for modeling, and models can be made applicable to literally anything, given the effort. Use Coq as a programming language is not so fantastic, but still doable. Integrating Coq as a programming langauge with other modern systems in currently a herculean exercise. [Thu Oct 13 18:06:24 2016] part of the problem is that the behaviour is spread over several modules (programs) [Thu Oct 13 18:06:38 2016] you can model the network of modules [Thu Oct 13 18:06:51 2016] it's all about defining which semantics you care about, and how closely you need your model to approach real behavior [Thu Oct 13 18:07:17 2016] yes, but how to apply the model? I mean, how to ensure my java implementation corresponds to the model? [Thu Oct 13 18:07:33 2016] for example, you can model information flow control for security, by just stating "we assume that this module does not leak information". You don't need to prove it then, you simply increase your trusted code base. [Thu Oct 13 18:07:39 2016] "ensure" here is the key word [Thu Oct 13 18:07:57 2016] the weakest statement is "provided I followed practices X, Y and Z, my code must be correct" [Thu Oct 13 18:08:24 2016] the strongest statement is "Here I have a trusted version of the JVM in Coq, and I've shown that no possible execution path in my program can violate the necessary properties." [Thu Oct 13 18:09:24 2016] it's all about time investment proportional to reward [Thu Oct 13 18:09:44 2016] if you're building control software for a space probe that must run for 50 years unattended, then you spend years perfecting your model [Thu Oct 13 18:10:05 2016] if you're building Web server software that may disappear in 6 months, maybe you only want to verify things about behavior allowed by your server protocol [Thu Oct 13 18:11:28 2016] my case is closer to the second (it's not going to dissappear in 6 months, but it's being changed all the time and we often have bugs). [Thu Oct 13 18:12:26 2016] then identify which exactly it is about the system that you want to prove properties about [Thu Oct 13 18:12:48 2016] "general correctness" is a chimera, since pratically no model will include the execution semantics of the processor you run on [Thu Oct 13 18:12:54 2016] so everything is a decision in terms of how far you go [Thu Oct 13 18:13:16 2016] if the goal is to eliminate bugs, pick which kinds of bugs to eliminate [Thu Oct 13 18:13:17 2016] etc. [Thu Oct 13 18:13:30 2016] So we could specify properties the system should guarantee, and then certify that if we use this algorithm, then the properties will hold. [Thu Oct 13 18:13:48 2016] And then implement this algoritm manually in java, right? [Thu Oct 13 18:14:30 2016] that's way one; draft the algorithm in Coq, then transcode it to Java [Thu Oct 13 18:15:17 2016] or program the important parts of your Java program in a simplified subset of Java that can be read into Coq as an AST [Thu Oct 13 18:15:43 2016] if it fits within the space of Featherweight Java, then you'd have existing tools for stating properties about that AST [Thu Oct 13 18:16:02 2016] I'm really interested, btw, in using Coq to prove properties of real world programs in languages like Java [Thu Oct 13 18:16:21 2016] I just haven't attempted to tackle that problem yet because it's so hard for the benefit gained [Thu Oct 13 18:16:33 2016] If there's haskell for the jvm, that could be another approach [Thu Oct 13 18:16:45 2016] Extraction then translation [Thu Oct 13 18:16:49 2016] It's much easier to start from a clean slate, and build software that only needs to _interoperate_ with Java [Thu Oct 13 18:16:55 2016] right [Thu Oct 13 18:17:01 2016] (there seems to be ocaml for jvm too) [Thu Oct 13 18:17:09 2016] (in alpha stage) [Thu Oct 13 18:18:02 2016] yes, in alpha - I checked this option before [Thu Oct 13 18:18:22 2016] thinking about your previous suggestions... [Thu Oct 13 18:18:36 2016] there's this: bentnib.org/coqjvm.pdf [Thu Oct 13 18:20:02 2016] see also things like research.microsoft.com/en-us/um/people/nick/coqasm.pdf [Thu Oct 13 18:20:12 2016] which formalizes a subset of the Intel x86 execution architecture [Thu Oct 13 18:20:31 2016] there are tradeoffs, though: formalizing the low-level is simpler, but loses important high-level structure [Thu Oct 13 18:21:12 2016] and formalizing at a high-level often includes insane amounts of functionality, since modern languages enjoy adding new semantics through custom syntax, where the true underlying semantics is only completely defined by the compiler implementation [Thu Oct 13 18:21:30 2016] hm [Thu Oct 13 18:22:22 2016] I know a PhD student at UCSD doing his thesis research on this very question :) [Thu Oct 13 18:22:28 2016] so, there's no simple answer today [Thu Oct 13 18:22:29 2016] I'm trying to understand how the low-level models (jvm, x86) can be useful. Do you mean to verify the compiled code? [Thu Oct 13 18:22:40 2016] yes [Thu Oct 13 18:22:43 2016] Not the java sources, but compiled java bytecode? [Thu Oct 13 18:22:49 2016] for example, I could verify a Haskell program by verifying the resulting GHC Core [Thu Oct 13 18:22:50 2016] that's interesting [Thu Oct 13 18:22:59 2016] or a C program by verifying LLVM output [Thu Oct 13 18:23:35 2016] I lose the notion of "structs" and "enums", but I keep the notion of pointers and address regions [Thu Oct 13 18:23:52 2016] cool [Thu Oct 13 18:24:18 2016] ok [Thu Oct 13 18:24:30 2016] now I'm reading your previous suggestions... [Thu Oct 13 18:27:33 2016] so, extraction is already implemented not only for ocaml, but also for haskell? [Thu Oct 13 18:27:37 2016] and scheme, yes [Thu Oct 13 18:27:42 2016] And I see here https://coq.inria.fr/refman/Reference-Manual026.html [Thu Oct 13 18:27:46 2016] and writing new extractors is not terribly difficult either [Thu Oct 13 18:27:47 2016] yes, for scheme! [Thu Oct 13 18:27:57 2016] I started to write one for Emacs Lisp, but then woke up [Thu Oct 13 18:28:06 2016] scheme for JVM exists for sure. [Thu Oct 13 18:29:25 2016] now trying to comprehend what you said about AST andFeatherweight Java [Thu Oct 13 18:30:04 2016] it's all about scoping; code in a subset, and proofs get easier [Thu Oct 13 18:30:42 2016] see also projects like http://why3.lri.fr/ [Thu Oct 13 18:31:48 2016] there was some caveat with scheme extraction [Thu Oct 13 18:35:36 2016] you need some extra definitions for the extracted code to work (https://www.irif.fr/~letouzey/scheme/) I'm suprised this is not included in the coq repo [Thu Oct 13 18:37:14 2016] rrika: thanks [Thu Oct 13 18:37:34 2016] antonv, for the scheme case that is [Thu Oct 13 18:37:46 2016] ah, it's visible in the url anyway, nevermind [Thu Oct 13 18:37:50 2016] johnw: yes. I was just trying to understan, how practical it is to use arbitrary AST (java subset) [Thu Oct 13 18:38:14 2016] what Coq tools exists for Featherweight Java? [Thu Oct 13 18:38:57 2016] google: featherweight java coq [Thu Oct 13 18:39:01 2016] there's a few papers on it [Thu Oct 13 18:39:37 2016] doing that now [Thu Oct 13 18:41:22 2016] I found some [Thu Oct 13 18:41:47 2016] Ok, thanks for the chat. [Thu Oct 13 18:41:54 2016] good luck! [Thu Oct 13 18:41:54 2016] A lot of interesting informatio for me. [Thu Oct 13 19:52:25 2016] anyone know a simple way to transform the following in my premises [Thu Oct 13 19:52:53 2016] x := match … with | … y … => constructor (… y …) end [Thu Oct 13 19:52:54 2016] into [Thu Oct 13 19:53:01 2016] x := constructor (match … with | … y … => (… y …) end) [Thu Oct 13 20:00:42 2016] i do it with helper lemmas [Thu Oct 13 20:04:15 2016] my expressions are big though [Thu Oct 13 20:04:36 2016] (I'm playing with why3/frama-c and it gave me a Map.get (Map.set (Map.set t_1 a_1 x) a x_1) a_1 [Thu Oct 13 20:04:43 2016] where Map.set unfolds into something big [Thu Oct 13 20:05:10 2016] Map set always puts its first argument in "match ↓ with" position [Thu Oct 13 20:05:24 2016] so as soon as one of them is not transformed to move the constructor outside it blocks all further simplification [Thu Oct 13 20:05:41 2016] I have a helper lemma now but I feel this should be easier. [Thu Oct 13 20:06:26 2016] rrika: can I see your code? [Thu Oct 13 20:07:57 2016] johnw, https://gist.github.com/rrika/4b8562a3e259f27571b7f6e535f09177 [Thu Oct 13 20:08:06 2016] you won't be able to run it though, it seems to depend on a lot of stuff [Thu Oct 13 20:08:11 2016] my code is at the bottom [Thu Oct 13 20:20:32 2016] oh god this is so tedious, all I'm trying to prove is that "temp = *a; *a = *b; *b = temp" conforms to the spec of "swap" [Thu Oct 13 20:20:41 2016] well, it's for learning [Thu Oct 13 20:30:15 2016] whoo, I did it [Thu Oct 13 20:30:28 2016] without helper theorems [Thu Oct 13 20:54:30 2016] johnw, do you know http://krakatoa.lri.fr/ ? [Thu Oct 13 21:11:44 2016] i didn't until a minute ago :) [Thu Oct 13 21:12:37 2016] I guess antonv would've been interested in this [Thu Oct 13 21:12:43 2016] though the workflow looks a bit painful [Thu Oct 13 21:12:43 2016] yes [Thu Oct 13 21:12:47 2016] and yes :) [Thu Oct 13 21:12:49 2016] importing it into an old version of why [Thu Oct 13 21:12:55 2016] then transforming it to a new version, etc. [Fri Oct 14 15:35:14 2016] does anyone here have experience with showing that some assembly corresponds to some C code? [Fri Oct 14 15:35:24 2016] (doesn't have to be using coq) [Fri Oct 14 15:35:53 2016] I'm mostly wondering about the issue that sideeffects from the C perspective do not include stack manipulation like spilling reigsters. [Fri Oct 14 15:45:30 2016] hi antonv [Fri Oct 14 15:45:48 2016] I found http://krakatoa.lri.fr/ yesterday. Might be relevant to you. [Fri Oct 14 15:51:37 2016] rrika: thanks a lot, let me check it [Fri Oct 14 16:04:24 2016] rrika: if you look into CompCert, you can propably devise a way to simulate an execution from the CompCert C subset of the C language to x86/PowerPC asm [Fri Oct 14 16:04:43 2016] I have no choice over the compiler [Fri Oct 14 16:04:53 2016] I want to confirm that a decompilation is correct [Fri Oct 14 16:05:13 2016] the stacklayout choices have already been made [Fri Oct 14 16:05:42 2016] I'm currently flipping through a slidedeck called "Translation Validation for a Verified OS Kernel" [Fri Oct 14 16:05:48 2016] (it's about sel4) [Fri Oct 14 16:06:30 2016] (http://www.nicta.com.au/publications/research-publications/?pid=6449) [Fri Oct 14 16:09:59 2016] rrika: your link is a whole new stratum of information for me, thanks again [Fri Oct 14 16:11:18 2016] :3 [Fri Oct 14 16:22:04 2016] rrika: I did not mean to use the compiler part, just the semantics [Fri Oct 14 16:22:13 2016] but indeed seL4 might have something better :) [Fri Oct 14 16:22:39 2016] Ptival, ah, tbh, both are huge projects and "using a part of it" is probably non-trivial [Fri Oct 14 16:23:54 2016] yeah :\ [Fri Oct 14 16:24:12 2016] I'm familiar with CompCert's codebase [Fri Oct 14 16:24:16 2016] can't help with seL4's [Fri Oct 14 16:24:38 2016] https://github.com/SEL4PROJ/graph-refine [Fri Oct 14 16:24:49 2016] Ptival, how come you know compcert? [Fri Oct 14 16:24:58 2016] I mean, know it more in depth [Fri Oct 14 16:25:01 2016] I've worked on it and with it [Fri Oct 14 16:25:04 2016] oh, cool [Fri Oct 14 16:27:15 2016] oh, actually, graph-refine looks very applicable to what I'm trying to do [Fri Oct 14 16:55:04 2016] neat [Fri Oct 14 17:43:27 2016] ugh, the repo is incomplete [Fri Oct 14 17:43:38 2016] lacks some programs [Sun Oct 16 04:03:56 2016] Hi [Sun Oct 16 04:04:05 2016] I need a universally unifiable term [Sun Oct 16 04:04:08 2016] in Coq [Sun Oct 16 04:05:07 2016] such that I can state that : universally_unifiable t -> t = f (t) [Sun Oct 16 04:05:54 2016] how can I create one? [Sun Oct 16 13:58:09 2016] I just had a look at http://www.rntz.net/files/icfp2016-datafun-presentation.pdf [Sun Oct 16 13:58:45 2016] I was wondering if that type system could be embedded in coq and a "fix" operator that automatically derives the well foundedness relation could be provided [Sun Oct 16 13:58:52 2016] need to understand it more first though [Mon Oct 17 16:29:15 2016] Anyone can give me some hints on reg_exp_of_list_spec lemma, from software foundations? [Mon Oct 17 16:29:58 2016] I'm trying induction on the lists but i get to something like [] = X s1 and the hypotheses don't seem useful. [Mon Oct 17 16:58:19 2016] modulus: for the -> direction, you should probably be able to do an induction directly on the "... ~= ..." hypothesis [Mon Oct 17 16:58:31 2016] for the <- direction, I don't think you have a choice: induction on the lists it is [Mon Oct 17 16:58:48 2016] make sure that the second list is generalized when do the induction on the first one though, it's probably safer [Mon Oct 17 17:00:08 2016] hmm [Mon Oct 17 17:02:13 2016] ok, i think what i was doing wrong is i was starting to induct on s2 and s2 after doing the split. but you can induct on H right from the split. [Mon Oct 17 17:02:25 2016] but now it remains to be seen if this way round works :-) [Mon Oct 17 17:03:49 2016] hmm no... [Mon Oct 17 17:04:36 2016] when i do generalize dependent s1 or s2 it gets out the H from the hypotheses too so it won't let me generalize on those and induce on H. [Mon Oct 17 17:18:09 2016] ok, i found a solution online. [Mon Oct 17 17:18:35 2016] seems i was failing to see possibilities of inversion for one of the hypotheses. [Tue Oct 18 00:27:48 2016] Hi every one [Tue Oct 18 00:27:56 2016] Could some one please have a look https://gist.github.com/mukeshtiwari/06c1c80df64fcd68b51c08b1a0831391 [Tue Oct 18 00:28:14 2016] "congruence" [Tue Oct 18 00:28:30 2016] johnw: I was about to write [Tue Oct 18 00:28:35 2016] congruence is not working [Tue Oct 18 00:28:37 2016] haha [Tue Oct 18 00:28:45 2016] what does this say: rewrite H in Hk [Tue Oct 18 00:29:12 2016] Found no subterm matching "Fixpoints.iter (O k) (length v) (fun _ : cand * cand => false) (c, d)" in Hk. [Tue Oct 18 00:29:29 2016] I tried all this before coming here :) [Tue Oct 18 00:29:44 2016] now check with Set Printing All [Tue Oct 18 00:29:48 2016] they won't be identical then [Tue Oct 18 00:30:13 2016] and I wonder if "simpl in *" makes them identical [Tue Oct 18 00:32:54 2016] johnw: Thanks [Tue Oct 18 06:38:31 2016] hi [Tue Oct 18 11:04:06 2016] dg pasted “ 【美国文凭】密歇根大学-安娜堡分校毕业证,成绩单/Q/微320865551制作UMich毕业证成绩单真实可查的教育部认证回国人员证明文凭University of Michigan Ann Arbor” at http://lpaste.net/4716211765631778816 [Tue Oct 18 11:06:20 2016] dg pasted “【美国文凭】莱斯大学毕业证,成绩单/Q/微320865551制作毕业证成绩单真实可查的教育部认证回国人员证明文凭Rice University” at http://lpaste.net/3476341452731056128 [Tue Oct 18 11:07:36 2016] dg pasted “ 【美国文凭】乔治城大学毕业证,成绩单/Q/微320865551制作毕业证成绩单真实可查的教育部认证回国人员证明文凭Georgetown University” at http://lpaste.net/8955378438500253696 [Tue Oct 18 11:07:50 2016] dg pasted “【美国文凭】塔夫斯大学毕业证,成绩单/Q/微320865551制作毕业证成绩单真实可查的教育部认证回国人员证明文凭Tufts University” at http://lpaste.net/4481412771212165120 [Tue Oct 18 12:03:55 2016] whom do I ask to get #ops in this channel? [Tue Oct 18 13:49:12 2016] hints? https://paste.debian.net/883392/ [Tue Oct 18 17:35:48 2016] Hi, I'm getting a test failure with the 8.5pl2 release, on `success/Nsatz.v` - full build log: http://ix.io/1xnR [Tue Oct 18 17:36:04 2016] (Currently working on packaging Coq for Exherbo) [Tue Oct 18 17:36:40 2016] Any thoughts as to the cause, or how I could resolve it? [Tue Oct 18 17:37:33 2016] (Or any further information I can provide - I have the build dir preserved) [Wed Oct 19 11:34:40 2016] Hi all! I have CoqIDE FAQ #1 and can’t find an answer through googling [Wed Oct 19 11:35:19 2016] namely, I have some Coq projects that work under ProofGeneral’s “Compile before Require” behavior [Wed Oct 19 11:35:30 2016] how do I get them to work with CoqIDE? [Wed Oct 19 11:35:59 2016] in particular, I’d like “Require Import Foo.” to work once Foo.v exists in the same folder. [Wed Oct 19 11:36:31 2016] I can’t find an answer in either of https://coq.inria.fr/faq#htoc172 http://stackoverflow.com/questions/16202666/coqide-cant-load-modules-from-same-folder http://blog.zhenzhang.me/2016/09/19/coq-dev.html [Wed Oct 19 13:39:15 2016] AFAIU, you need to compile Foo.v with something like `coqc Foo.v` [Wed Oct 19 13:57:23 2016] and for the current folder I don’t need any `-I .` option by default? [Wed Oct 19 13:58:25 2016] also, is it right that there’s no way to have CoqIDE compile dependencies automatically? I need to do that externally, by hand or through Makefiles? [Wed Oct 19 13:59:18 2016] i've never tried using it [Wed Oct 19 14:01:27 2016] pgiarusso: Looking at the CoqIDE UI, it seems to have "Make Makefile" under "Compiling", which I suspect runs "coq_makefile" - that may automate the process of specifying dependencies by using coqdep. [Wed Oct 19 14:04:32 2016] *pgiarrusso ^^ [Wed Oct 19 14:07:27 2016] eternaleye: interesting, but that uses `-R "." Top -I “.”` which breaks things [Wed Oct 19 14:09:00 2016] ah wait, it works if I clean the project first [Wed Oct 19 14:10:48 2016] eternaleye: OK, this workflow seems reasonable, if only one discovers it :-) [Wed Oct 19 14:11:41 2016] I retract, since CoqIDE doesn’t know about this default and complains the compiled code uses Top.Foo instead of Foo :-| [Wed Oct 19 14:11:53 2016] Mm [Wed Oct 19 14:12:22 2016] I can make it work via make COQLIBS=‘’ and then loading a file [Wed Oct 19 14:12:25 2016] * just installed Coq yesterday, but spent the past week getting it packaged, and so has a better idea of the build process than any of the actual features at this point :P [Wed Oct 19 14:16:38 2016] You might be able to do something via creating a _CoqProject file at the top level [Wed Oct 19 14:17:53 2016] pgiarrusso: https://coq.inria.fr/refman/Reference-Manual017.html#Makefile [Wed Oct 19 14:18:13 2016] According to the docs, CoqIDE respects that when generating makefiles [Wed Oct 19 14:21:32 2016] So now I have to maintain the list of source files by hand? [Wed Oct 19 14:22:17 2016] I don’t mean to complain against anybody [Wed Oct 19 14:22:42 2016] but I’m trying to figure out whether CoqIDE can be configured to “just work” like ProofGeneral [Wed Oct 19 14:23:25 2016] And I’m fine with “don’t expect it to really work well without integration” — I’m fine with using Proof General myself [Wed Oct 19 14:24:09 2016] but today I tried installing Coq for a fellow PhD student and directed him to CoqIDE, and I’m fine with concluding “that was a mistake” [Wed Oct 19 14:24:22 2016] or “everybody uses ProofGeneral” [Wed Oct 19 14:28:10 2016] eternaleye roconnor: to be sure, thanks both of you for your help :-) [Wed Oct 19 21:20:39 2016] 02:12:25 * │ eternaleye just installed Coq yesterday, but spent the past week getting it packaged, and so has a better idea of the [Wed Oct 19 21:20:52 2016] eternaleye: what OS do you use that you had to do that? [Wed Oct 19 21:21:36 2016] benzrf: Well, it took me about 20min to write the package, and a week to discover that -datadir /usr/share is not a good thing to pass to configure [Wed Oct 19 21:21:53 2016] Which was a bit of a surprise, coming from Autotools [Wed Oct 19 21:21:57 2016] but... what OS do you use that you had to do that? [Wed Oct 19 21:22:04 2016] Exherbo [Wed Oct 19 21:22:19 2016] Small source-based distro, somewhat cousin-like relation to Gentoo [Wed Oct 19 21:22:22 2016] I'm a dev [Wed Oct 19 21:22:47 2016] Coq was already packaged, but it was 8.4, and was a bit crufty [Wed Oct 19 21:23:49 2016] So I revamped the package definition, bumped it to 8.5pl2, and added -scm packages for 8.5 HEAD and trunk HEAD for impatient people [Wed Oct 19 21:24:23 2016] (it being a source distro, on each build it would fetch up-to-date source from git for those) [Wed Oct 19 21:26:13 2016] o: [Wed Oct 19 21:26:20 2016] u should just use nix :} [Wed Oct 19 21:26:25 2016] nix is fun & good [Wed Oct 19 21:31:10 2016] I use Nix for everything Coq-related too; very nice to use, once you get it all working [Wed Oct 19 22:55:39 2016] I've looked at Nix; I agree there are some things it does very well, but I also feel there are things it could stand to do better that Exherbo does well. [Wed Oct 19 22:56:02 2016] Also, I'm familiar with Exherbo, Coq is a hobby right now, and I don't have enough leisure time to experiment with distros _and_ Coq. [Wed Oct 19 22:56:36 2016] (And as I said, I'm a _dev_ on Exherbo. If I don't like something there, I have push access) [Wed Oct 19 23:37:53 2016] well [Wed Oct 19 23:37:59 2016] you can use nix on any OS [Wed Oct 19 23:38:03 2016] i run arch myself [Wed Oct 19 23:39:08 2016] what does exherbo do that nix doesnt do well? [Thu Oct 20 00:02:33 2016] Well, one is that cross-compilation is natively supported to the point that it's used for 32-bit compat on 64-bit systems, with full coinstall capability. Another is that it's considerably closer to FHS in layout, and thus software (especally binary software) needs far, far less massaging to fit. A third is that it has a trivial command (cave import) to take manually-built code (DESTDIR-like) and create an ephemeral package [Thu Oct 20 00:02:34 2016] from it, such that its dependencies and files can be tracked natively, without needing to write a single line of code. A fourth is that Exherbo _doesn't_ try to make the package manager responsible for all configuration of the installed packages, which I consider to be a futile/sisyphean task which reduces generality. A fifth is that while nix-env blocks collisions, it (at least defaults to) permitting multiple versions of [Thu Oct 20 00:02:35 2016] the same package to be installed. This is unsafe in the general case, due to data structure and symbol isolation problems that are insoluble in the C model of compilation where one dependency can link to foo.so.1 and another can link to foo.so.2. Exherbo defaults to a package _not_ being mutually installable with other versions, unless explicitly permitted via the "slots" mechanism. [Thu Oct 20 00:03:33 2016] Also, my repeated experience with Nix has been being told I should switch to it and that it's better than X, _after_ I've said I'm a developer for a distribution. This tends to come across as rude. [Thu Oct 20 00:04:40 2016] I do think Nix does many things right - pure package specifications generating build instructions in particular, as well as the immutable store - but I'd much rather examine it for lessons than switch to it. [Thu Oct 20 12:08:42 2016] Hello, all. Is it possible to prove that forall x: T, ~P x -> ~exists x: T, P x? [Thu Oct 20 12:08:51 2016] I managed to prove the opposite [Thu Oct 20 12:09:43 2016] well, you'd have to prove that there exists at least one x: T [Thu Oct 20 12:10:19 2016] hm.; nevermind, I'm tired [Thu Oct 20 12:10:54 2016] You need more parentheses, but yes, it's provable [Thu Oct 20 12:11:10 2016] By that I mean: you probably want (forall x: T, ~P x) -> ~exists x: T, P x [Thu Oct 20 12:12:07 2016] Yeah, that [Thu Oct 20 12:12:19 2016] Thx [Thu Oct 20 12:18:01 2016] Is it possible to use exists for a generic type? [Thu Oct 20 12:18:27 2016] What do you mean? [Thu Oct 20 12:19:59 2016] Nvm, the docs answered me: https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic20 [Thu Oct 20 12:20:13 2016] "This applies only if I has a single constructor." [Thu Oct 20 12:20:32 2016] oooh, you meant the tactic [Thu Oct 20 17:10:29 2016] I have a hypothesis H1: P and H2: P -> Q. If I apply H2 in H1, I get H1: Q and lose P. The problem is that I need P further down the proof. Is there a way I can apply H2 in H1 without losing my original proposition? Or am I thinking of this the wrong way? [Thu Oct 20 17:10:41 2016] (Sorry, my connection went down) [Thu Oct 20 17:11:07 2016] If you don't mind losing H2, you can do "specialize (H2 H1)" [Thu Oct 20 17:11:29 2016] more generally, you could do "pose proof (H2 H1)" which would create a whole new hypothesis [Thu Oct 20 17:21:37 2016] Cypi: can I give the new hypothesis a custom name? [Thu Oct 20 17:22:12 2016] "pose proof (H2 H1) as your_name" [Thu Oct 20 17:22:33 2016] i've also been using set (Hnew := H2 H1) sometimes [Thu Oct 20 17:22:36 2016] Thanks [Thu Oct 20 17:23:23 2016] set keeps the body of the hypothesis though, which might or might not like [Thu Oct 20 20:00:30 2016] Hello everyone [Thu Oct 20 20:00:34 2016] I am stuck with https://gist.github.com/mukeshtiwari/86d63bf2efb5db89cb7fceeddcedd772 [Thu Oct 20 20:00:59 2016] A hint would be great [Thu Oct 20 20:04:53 2016] hi keep_learning [Thu Oct 20 20:05:01 2016] Hi johnw [Thu Oct 20 20:05:25 2016] You need to make your statement more general to be able to prove it [Thu Oct 20 20:05:40 2016] specifically, the second argument to s_execute [Thu Oct 20 20:05:48 2016] a general rule of thumb is to avoid constants in theorems statements as much as possible [Thu Oct 20 20:06:02 2016] so, instead of [], use xs with some statement about its properties if necessary [Thu Oct 20 20:06:30 2016] probably the right-hand side will need to be different as well [Thu Oct 20 20:09:55 2016] Cypi: specifically, the second argument to s_execute. You mean change empty list ([]) in s_execute st [] (s_compile e) = [ aeval st e ] to more general one ? [Thu Oct 20 20:10:04 2016] yes [Thu Oct 20 20:10:11 2016] the specificity of [] is hampering you [Thu Oct 20 20:10:19 2016] this is a general rule of thumb [Thu Oct 20 20:10:44 2016] notice that as johnw said, there is also an empty list constant hidden in the right-hand side that you will need to change for it to be correct [Thu Oct 20 20:11:00 2016] in fact, there's a section in CPDT about this [Thu Oct 20 20:11:19 2016] Thank you Cypi johnw [Thu Oct 20 20:11:32 2016] Theorem s_compile_correct : forall (st : state) (e : aexp) (l : list nat), s_execute st l (s_compile e) = [ aeval st e ] ++ l. [Thu Oct 20 20:12:05 2016] see section 2.1.4 of CPDT, where Chlipala says: Though a pencil-and-paper proof might clock out at this point, writing “by a routine induction on e,” it turns out not to make sense to attack this proof directly. We need to use the standard trick of strengthening the induction hypothesis. [Thu Oct 20 20:12:24 2016] it's that trick which you need here [Thu Oct 20 20:13:24 2016] johnw: Yes, it the particular instance of empty list [] is making the situation impossible to prove this [Thu Oct 20 20:13:51 2016] keep_learning: I've run into this so many times, that I now instinctively look for non-variables in my theorems :) [Thu Oct 20 20:14:18 2016] in fact, it hit me again two days ago [Thu Oct 20 20:14:43 2016] johnw: I tried CPDT in past, but it was very to grasp every thing and too much for me. [Thu Oct 20 20:14:57 2016] Time to read it again [Thu Oct 20 20:15:45 2016] it was very *hard to grasp every thing. [Thu Oct 20 20:15:53 2016] yes, it deserves multiple reads [Thu Oct 20 20:16:06 2016] and its usefulness relates to how much you intend to really use Coq [Thu Oct 20 21:21:24 2016] hmm [Thu Oct 20 21:21:35 2016] i wonder if i could do a tutorial request and work through CPDT for credits 8D [Thu Oct 20 21:23:54 2016] How can I pass an implicit parameter explicitly to a constructor? [Thu Oct 20 21:24:02 2016] two ways [Thu Oct 20 21:24:05 2016] @ctor param [Thu Oct 20 21:24:12 2016] or: ctor (name:=param) [Thu Oct 20 21:24:29 2016] the latter is often better than @ctor _ _ _ _ _ _ _ param :) [Thu Oct 20 21:24:40 2016] actor! [Thu Oct 20 21:24:56 2016] ? [Thu Oct 20 21:25:29 2016] I'll try that, thanks [Thu Oct 20 21:27:37 2016] I really don't know what I was doing wrong. Thanks [Thu Oct 20 21:30:00 2016] johnw: @ctor [Thu Oct 20 21:39:05 2016] Hey, you folks are very supportive and very quick to answer. Thanks a lot :) [Thu Oct 20 21:48:38 2016] we're here to help :) [Thu Oct 20 22:08:12 2016] quick to answer??? [Thu Oct 20 22:08:14 2016] #coq ??? [Thu Oct 20 22:08:18 2016] impossible [Thu Oct 20 22:55:36 2016] Definition coq_channel(quick_to_answer: True) -> False. Proof. trivial. Qed. [Thu Oct 20 22:55:39 2016] :P [Thu Oct 20 23:08:00 2016] do you mean ": False" o: [Thu Oct 20 23:11:42 2016] Well, I did just install Coq two days ago :P [Thu Oct 20 23:11:57 2016] Still getting the hang of it [Thu Oct 20 23:22:49 2016] 00:03 Also, my repeated experience with Nix has been being told I should switch to it and that it's better than X, _after_ I've said I'm a developer for a distribution. This tends to come across as rude. [Thu Oct 20 23:22:52 2016] hehe [Thu Oct 20 23:22:54 2016] sorry [Fri Oct 21 00:03:41 2016] It's fine [Fri Oct 21 00:11:13 2016] #gcc [Fri Oct 21 00:11:18 2016] Whoops [Fri Oct 21 00:12:46 2016] How do I use the "reverse" of an iff? I mean, I just proved A <-> B, but I can only manage to apply A -> B, not the other way around [Fri Oct 21 00:15:22 2016] It's a hidden conjunction. One way is to split it. [Fri Oct 21 00:16:23 2016] How, exactly? split theorem_name? [Fri Oct 21 00:16:35 2016] you can also: proj1 theorem_name or proj2 theorem_name [Fri Oct 21 00:17:41 2016] Do I need to import something? [Fri Oct 21 00:18:02 2016] no [Fri Oct 21 00:20:33 2016] >= 8.5? [Fri Oct 21 00:20:41 2016] I'm still in 8.4 [Fri Oct 21 00:21:07 2016] proj1 is in Coq.Init.Logic [Fri Oct 21 00:21:13 2016] so it should be available by default [Fri Oct 21 00:21:25 2016] maybe that changed in 8.4, I don't know [Fri Oct 21 00:21:53 2016] johnw means `apply (proj2 theorem_name)` [Fri Oct 21 00:21:57 2016] yes [Fri Oct 21 00:22:40 2016] Ah [Fri Oct 21 00:25:32 2016] The term "andb_ab" has type "forall a b : bool, a && b = true <-> a = true /\ b = true" while it is expected to have type "?2206 /\ ?2207". [Fri Oct 21 00:36:43 2016] not sure what you're doing but may it be you wante rewrite <- theorem? [Fri Oct 21 02:33:10 2016] Could some one please have a look at https://gist.github.com/mukeshtiwari/e4a19f08114658c21ea703ad11f3bc41 [Fri Oct 21 02:33:38 2016] I am trying to prove while_break_true [Fri Oct 21 02:33:45 2016] but stuck with last goal [Fri Oct 21 03:14:37 2016] Please leave you answer as a comment. [Fri Oct 21 08:56:15 2016] what typeclass do I have to implement to apply the omega tactic to some structure I define? [Sat Oct 22 07:58:29 2016] I found a source file in an odd language: https://github.com/hbr/albatross/blob/master/example/list_sort.al [Sat Oct 22 07:58:36 2016] Anyone know this? [Sat Oct 22 08:57:54 2016] rrika: it's literally right there [Sat Oct 22 08:58:03 2016] "The Albatross Programming Language" [Sat Oct 22 08:58:26 2016] I can see the name. I mean more the context of the language. [Sat Oct 22 08:58:42 2016] I'm assuming the language designer already knew existing languages in that area. [Sat Oct 22 08:59:07 2016] But it chose to be different from them in some regards. [Sat Oct 22 08:59:13 2016] I just wanted to know the reasons behind those decisions [Sat Oct 22 08:59:36 2016] i've never heard of it before [Sat Oct 22 08:59:52 2016] for example, in some other files in the repo you can see properties about relations [Sat Oct 22 08:59:57 2016] (like is_reflexive) [Sat Oct 22 09:00:20 2016] but they're written to return bool instead of {p}+{¬p} which I know from coq [Sat Oct 22 09:01:43 2016] Hi, I have to disprove that : AReg r = ANum 0 [Sat Oct 22 09:01:48 2016] given the definition [Sat Oct 22 09:02:00 2016] Inductive aexp : Type := [Sat Oct 22 09:02:00 2016] | ANum : nat -> aexp [Sat Oct 22 09:02:00 2016] | AReg : nat -> aexp [Sat Oct 22 09:02:14 2016] inversion? [Sat Oct 22 09:02:28 2016] But inversion works only on Hypothesis [Sat Oct 22 09:02:42 2016] AReg r = ANum 0 is in my goal [Sat Oct 22 09:02:49 2016] then it's unprovable [Sat Oct 22 09:02:50 2016] you can't prove it [Sat Oct 22 09:03:00 2016] you have to show that something else in your premises is contradictory [Sat Oct 22 09:03:08 2016] ohk [Sat Oct 22 09:03:15 2016] thanks :) [Sat Oct 22 09:06:48 2016] ankitku, you can run "apply False_rect" to remind yourself to not worry about the goal [Sat Oct 22 09:06:53 2016] it will replace the goal by false [Sat Oct 22 09:07:12 2016] ok, thanks rrika [Sat Oct 22 12:11:59 2016] exfalso is a shorthand for elimtype False [Sat Oct 22 12:16:29 2016] (and elimtype False does the same thing as apply False_rect) [Sat Oct 22 12:53:16 2016] KaneTW, I vaguely remembered something like that and tried "ex_falso", saw that it didn't work and doubted my memory [Sat Oct 22 15:42:16 2016] Hi [Sat Oct 22 15:42:23 2016] CVL : exists (i : instr) (l : nat), [Sat Oct 22 15:42:24 2016] ihas_type Psi Gamma i (code Gamma) -> v = l -> Some i = H (Id l) [Sat Oct 22 15:42:24 2016] ============================ [Sat Oct 22 15:42:25 2016] Some I2 = H (Id v) [Sat Oct 22 15:42:56 2016] i need to apply CVL to the goal, with appropriate bindings, but I am not able to [Sat Oct 22 15:43:03 2016] pls help [Sat Oct 22 15:57:38 2016] ankitku: CVL proves that there exists an i such that [Sat Oct 22 15:57:56 2016] blah, but you need to know that it holds for I2 [Sat Oct 22 15:58:21 2016] yes, so can i instantiate it with I2? [Sat Oct 22 16:00:35 2016] ankitku: no, that's not what "there exists" means. you don't get to instantiate it, you just have to deal with whatever is in there. [Sat Oct 22 16:00:49 2016] okk [Sat Oct 22 16:01:00 2016] thanks :) [Sat Oct 22 23:25:57 2016] so it looks as though agda's coinductive types fully take the approach of the user providing destructors [Sat Oct 22 23:26:02 2016] why did coq do it the way it did? [Sun Oct 23 09:11:45 2016] I forgot how to move a subexpression to the assumptions [Sun Oct 23 09:11:47 2016] like [Sun Oct 23 09:12:03 2016] |- P (x+3) [Sun Oct 23 09:12:03 2016] into [Sun Oct 23 09:12:14 2016] temp := x+3 : nat |- P temp [Sun Oct 23 09:12:21 2016] set (temp := x+3) [Sun Oct 23 09:12:48 2016] ah, thank you very much Cypi [Sun Oct 23 09:45:51 2016] Okay, I ran into a very weird situation. [Sun Oct 23 09:46:01 2016] Inductive clos_refl (A : Type) (R : relation A) (x : A) : A -> Prop := [Sun Oct 23 09:46:01 2016] r_step : forall y : A, R x y -> clos_refl A R x y [Sun Oct 23 09:46:01 2016] | r_refl : clos_refl A R x x [Sun Oct 23 09:46:09 2016] this is from Coq.Relations.Relations. [Sun Oct 23 09:47:11 2016] oh nevermind, I had a mistake in my reasoning [Sun Oct 23 09:48:38 2016] rubber duck debugging but with roosters [Sun Oct 23 12:44:44 2016] I have a question. I have a hypothesis like this: H0 : (P -> False) /\ ((P -> False) -> False) [Sun Oct 23 12:44:54 2016] and a goal of False. [Sun Oct 23 12:45:19 2016] if I apply H0, the goal becomes p -> False. and if I apply it again it tells me no goals left. this is puzzling me a little. [Sun Oct 23 12:46:59 2016] I understand solving this by destructing H0 and applying one goal on the other, then I get a false hypothesis and it's done, but this double application thing, I don't get why it works. [Sun Oct 23 12:47:25 2016] modulus, I guess apply destructs internally and tries applying each of the sides of the /\ [Sun Oct 23 12:47:39 2016] during the first part it doesn't apply the whole H but the right part [Sun Oct 23 12:47:45 2016] *during the first step [Sun Oct 23 12:48:00 2016] so the first apply works on the right side of the conj and the next apply on the left? [Sun Oct 23 12:48:07 2016] apparently [Sun Oct 23 12:48:18 2016] that seems a bit magic to me tbh. [Sun Oct 23 12:48:26 2016] there's a lot of magic in coq [Sun Oct 23 12:48:26 2016] like it's great that it works, but it is a bit odd. [Sun Oct 23 12:48:38 2016] many tactics do "intro" for example [Sun Oct 23 12:48:54 2016] true, like unduction, destruct. [Sun Oct 23 12:50:24 2016] tbh what i would have expected is, it sees that both sides of the conj have a false on the right, and it would produce p /\ p -> false. [Sun Oct 23 12:52:51 2016] but now i think about it this seems sensible, since H0 is asserting both sides are true so it shouldn't require you to prove them both. [Sun Oct 23 12:54:33 2016] what *is* surprising is that given the choice to use either it picks the right one [Sun Oct 23 12:54:54 2016] i think because only the right one has the right type on the conclusion. [Sun Oct 23 12:55:09 2016] wait no, both do. [Sun Oct 23 12:55:58 2016] yeah, if it went with the left one you'd be stuck with P on the goal and couldn't go on. [Sun Oct 23 12:57:23 2016] modulus, if you swap the sides of /\ it fails [Sun Oct 23 12:57:35 2016] I think it prefers the right side [Sun Oct 23 12:57:47 2016] Heh, how fortuitous. [Sun Oct 23 12:58:20 2016] Might be something on how conj is constructed, idk. [Sun Oct 23 12:59:11 2016] even in the simple case apply tries multiple times and goes with the first match [Sun Oct 23 12:59:15 2016] Anyway, I guess it's just a funny coincidence. I'll remember that when applying a conjunctive hypothesis it will try the right side first. [Sun Oct 23 12:59:20 2016] H: a → b → c [Sun Oct 23 12:59:36 2016] it will try to match the goal with (a→b→c), (b→c), (c) [Sun Oct 23 13:00:08 2016] odd. [Sun Oct 23 13:00:36 2016] so I guess while recursing down the ast whatever gets found first sticks [Tue Oct 25 04:45:04 2016] how can I proof something like (i ?= 0) = Lt where i : Z? [Tue Oct 25 18:54:13 2016] hi, i'm trying to learn coq, does anyone know how one might solve the following lemma in a simple manner? [Tue Oct 25 18:54:16 2016] Lemma unique_succ : forall a : positive, exists! b : nat, S b = Pos.to_nat a. [Tue Oct 25 18:54:47 2016] stupified: what's the definition of positive [Tue Oct 25 18:54:49 2016] by hand, i proved this using induction on b... but doing so in coq leads to a bunch of cases with terms I am unable to eliminate [Tue Oct 25 18:55:10 2016] positive - set Z+ of integers {1, 2, ...} [Tue Oct 25 18:55:19 2016] nat = {0, 1, 2, ...} [Tue Oct 25 18:55:37 2016] stupified: No, I know what positive numbers are; what I need to know, is what the inductive encoding of the concept you are using is ;) [Tue Oct 25 18:57:05 2016] ah, I believe I am using the definition in binNums - https://coq.inria.fr/distrib/8.5pl2/stdlib/Coq.Numbers.BinNums.html [Tue Oct 25 18:58:11 2016] I am importing Coq.PArith.PArith, at least [Tue Oct 25 18:58:59 2016] stupified: I don't understand how you can proceed by induction on b for this lemma. b is existentially quantified in the conclusion. [Tue Oct 25 18:59:27 2016] Do induction on positive [Tue Oct 25 18:59:28 2016] the straightforward thing to try is induction on a [Tue Oct 25 18:59:30 2016] yeah [Tue Oct 25 18:59:49 2016] it might be a bit finicky in the xO case but eh [Tue Oct 25 19:02:00 2016] you're right. I probably mistranslated my proposition into logic. I started with the sentence "Let a be a positive number. Then there exists exactly one natural number b such that S(b) = a". [Tue Oct 25 19:02:42 2016] sounds right to me [Tue Oct 25 19:09:05 2016] so, that decomposes the proof into three cases. the first of which is exists ! b : nat, S b = Pos.to_nat a~1 [Tue Oct 25 19:09:21 2016] am i right in saying that reads as there is a unique nat b such that S(b) = a, a not equal to 1? [Tue Oct 25 19:12:13 2016] I am not sure where the ! came from [Tue Oct 25 19:15:36 2016] part of the original statement was that there is exactly one natural number b. So I wrote that using exists!, which I think is notation for "there exists a unique..." [Tue Oct 25 19:15:40 2016] stupified: no, a~1 is notation for the xI constructor [Tue Oct 25 19:15:53 2016] ! is defined in the stdlib as a notation for "unique" [Tue Oct 25 19:16:31 2016] unique P x := P x /\ (forall x', P x' -> x = x') [Tue Oct 25 19:16:45 2016] so exists! x, P x does the right thing [Tue Oct 25 19:17:59 2016] stupified: (spoilers!) here's one way to do it https://gist.github.com/wilcoxjay/e913b5f8533831ad963da0383f401a89 [Tue Oct 25 19:21:26 2016] thanks jrw. i'll take a close look at it. spoilers are fine, haha, i'm trying to learn coq, not reprove my real analysis notes from years ago ;p [Tue Oct 25 19:22:02 2016] note that I used the omega tactic, but not really in any interesting way. it should be possible to replace it in all cases with simpler tactics if you want. [Tue Oct 25 19:22:42 2016] yes, i will probably try to do that once i understand the proof. omega is very mysterious to me [Tue Oct 25 19:39:46 2016] is there a concise way to say propositions p1...p5 are equivalent, or do i need to do p1<->p2/\p2<->p3 etc? [Tue Oct 25 19:44:07 2016] modulus, you could make a helper proposition that says that all props in a list are equivalent [Tue Oct 25 19:44:19 2016] ah, that sounds reasonable. [Tue Oct 25 19:52:49 2016] modulus, you can also do this [Tue Oct 25 19:52:49 2016] Definition allEquivTo (A: Prop) (l: list Prop) := [Tue Oct 25 19:52:49 2016] fold_left and (map (fun Z => A<->Z) l) True. [Tue Oct 25 19:52:57 2016] take a list of Z1 Z2 Z3 Z4 [Tue Oct 25 19:53:01 2016] use map to turn them into [Tue Oct 25 19:53:06 2016] A<->Z1 A<->Z2 A<->Z3 [Tue Oct 25 19:53:12 2016] then link them all with "and" [Tue Oct 25 19:53:56 2016] though I guess this exposes the internals a lot [Tue Oct 25 19:54:02 2016] so having a helper proposition is probably nicer [Tue Oct 25 21:35:33 2016] Hi. I'm working on the formalization of this Language (https://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf). But I'm stuck in a step which he does not prove that the typing context remains consistent when applying , is it common a paper [Tue Oct 25 21:37:09 2016] remains consistent when applying a context weakening lemma. is it common a paper skip this part of the proof and let the reader work the details? [Tue Oct 25 21:38:02 2016] I mean, I'm not even sure that the step is correct. [Tue Oct 25 21:39:03 2016] Well, if anyone is interesting in taking a look, it is at the page 33 of the pdf 2nd line, applying Lemma A.1.3 [Wed Oct 26 00:03:59 2016] Hey, is there any syntax to define a fixpoint as a member of a typeclass instance, without having a Fixpoint vernacular command at the top level defining the function which the Instance simply aliases? [Wed Oct 26 00:05:00 2016] This is my current code: http://ix.io/1zy4 [Wed Oct 26 00:05:26 2016] I'd prefer to write the body of `splitter` directly as the body of `splits`, eliding `splitter` entirely [Wed Oct 26 00:10:52 2016] You can always use the actual Gallina construct which corresponds to Fixpoint: fix [Wed Oct 26 00:11:44 2016] it would go something like: splits := fix splitter I (inputi: Input I) (s: nat) (i: I) {struct s} := match s with ... end [Wed Oct 26 00:26:28 2016] Thanks! [Wed Oct 26 00:27:00 2016] I'm just starting out with Coq, so I haven't learned many of the vernacular <-> gallina correspondences yet. [Wed Oct 26 00:27:34 2016] Figured I'd start with a real project I actually want to use for something, so I'm working towards a range concatenation grammar implementation [Wed Oct 26 00:29:52 2016] Ah, and there we go! http://ix.io/1zyg [Wed Oct 26 00:30:03 2016] Cypi: Thank you, that worked like a charm [Wed Oct 26 00:30:26 2016] good :) [Wed Oct 26 04:47:10 2016] oops, wrong channel. Sorry. :-) [Thu Oct 27 21:10:55 2016] Hello everyone [Thu Oct 27 21:11:11 2016] Could some one please have a look https://gist.github.com/mukeshtiwari/5d524ad4a49abeb40573c629e5e392e1 [Thu Oct 27 21:11:31 2016] I am stuck with goal NoDup a [Thu Oct 27 21:13:13 2016] I am just looking for hint. [Thu Oct 27 21:51:57 2016] does omega not know about distributivity [Thu Oct 27 22:03:37 2016] is there a way to see the ast of coq functions from within coq? [Thu Oct 27 22:03:50 2016] I guess you could rebuild the ast with a custom tactic [Thu Oct 27 22:12:04 2016] oh, that's literally what http://adam.chlipala.net/cpdt/html/Reflection.html does [Thu Oct 27 22:12:10 2016] should finally read that [Thu Oct 27 23:41:28 2016] heh [Thu Oct 27 23:56:16 2016] aw i was thinking about exactly this sort of thing the other day as a potential interesting thing to do [Fri Oct 28 00:02:42 2016] rrika: Chlipala and others go into that technique in much greater depth here: http://adam.chlipala.net/papers/MirrorShardITP14/ [Fri Oct 28 00:02:57 2016] also, Adam's Facade project at MIT also reifies most of Coq syntax, except via plugin [Fri Oct 28 03:01:49 2016] Does anyone know if the various theorems for list have been replicated for string anywhere? I'm finding it irritatingly difficult to do things like prove that `forall s: string, forall: n: nat, forall H: (n < =length string), length (substr 0 n) = n` [Fri Oct 28 03:02:05 2016] When that's absolutely trivial to do using list's firstn and skipn [Fri Oct 28 04:33:59 2016] eternaleye: whenever I want to do nontrivial string manipulation, I usually convert to a list of ascii representation and use list functions [Fri Oct 28 04:34:04 2016] maybe not the answer your were hoping for thought :\ [Fri Oct 28 04:38:56 2016] Eh, it's about what I suspected; just wondered if anyone had anything better. [Fri Oct 28 04:39:15 2016] * might take a stab at porting over the theorems [Fri Oct 28 07:05:02 2016] Does anyone know of a paper or other resource which describes the algorithm to derive recursive schemes from inductive types as in Coq? Codifying Guarded Definitions with Recursive Schemes by Eduardo Giménez only informally describes it for a simple example. [Fri Oct 28 07:10:40 2016] johnw, I was thinking about this in the context of hardware description. If you have a model that includes a computation like (x+y)*(a+b), and you want to associate this with hardware blocks they are run on. [Fri Oct 28 07:10:49 2016] (and in this case you want to do the two additions on the same block in sequence) [Fri Oct 28 07:11:11 2016] then tactics could be used to match a certain subexpression and insert something like a call to "id" but with metadata [Fri Oct 28 07:15:17 2016] johnw, thanks for the link [Fri Oct 28 08:35:04 2016] Hey. I have heard htat coq is the last big user of camlp5. How is it going? Does camlp5 have know long-living issues that poison your life? [Fri Oct 28 09:07:06 2016] rrika: how funny you should say that, since I'm working on something right now based on reflection that may end up doing just that [Fri Oct 28 09:24:11 2016] johnw, oh, tell more [Fri Oct 28 09:27:01 2016] rrika: later today, after my early meetings, but I'd love to talk about it moer [Fri Oct 28 09:40:49 2016] in short, I'm using Fiat to refine specifications into programs, and one of the types of "programs" are encodings of operational semantics by way of a DSL, for example a circuit description [Fri Oct 28 11:23:28 2016] johnw, by refining specifications you mean finding a value for "forall a:A, exists b:B, solution_ok a b"? [Fri Oct 28 11:23:31 2016] or something more general? [Fri Oct 28 11:24:03 2016] ah, exists is in prop isn't it? then the non-prop version of it. [Fri Oct 28 14:16:22 2016] rrika: yes, just that [Fri Oct 28 14:16:37 2016] rrika: { f : A -> B & forall a : A, exists b : B, R a b } [Fri Oct 28 14:16:50 2016] where R is now the "specification", and f is the implementation [Fri Oct 28 14:17:18 2016] between these two can be infinite partial specifications, going from some R to R', given that: forall (a : A) (b : B), R' a b -> R a b [Sun Oct 30 19:35:31 2016] Hi, I'm struggling to understand the following: https://gist.github.com/anonymous/d81add97a0928eb756b8a7290ae1ae8f [Sun Oct 30 19:36:24 2016] I would expect the two definitions of type T in the Gist to be strictly equivalent, but that doesn't seem to be the case [Sun Oct 30 19:36:41 2016] For the record, I'm using Coq 8.5pl2 [Sun Oct 30 19:36:55 2016] Am I missing something obvious ? [Sun Oct 30 19:56:23 2016] gargawel: I get an error when trying the alternate definition because the first argument to sig is implicit. if I fix that (by saying "@sig" instead of "sig") then the whole file goes through without error for me. [Sun Oct 30 19:57:01 2016] jrw: Hum :/ I don't have the same experience. [Sun Oct 30 19:57:51 2016] Are you also using 8.5pl2 ? [Sun Oct 30 19:58:03 2016] yes [Sun Oct 30 19:58:14 2016] are you importing any other files not shown in the gist? [Sun Oct 30 19:59:15 2016] No [Sun Oct 30 20:00:46 2016] Ok, now that's strange ; I indeed have some code before that one that is completely irrelevant to the gist and does not import anything [Sun Oct 30 20:00:57 2016] if I comment it I get the same results as you [Sun Oct 30 20:01:01 2016] let me check again... [Sun Oct 30 20:01:34 2016] Ok, forget it :D I was in fact redefining sig, just to check how things work... [Sun Oct 30 20:01:42 2016] I guess I should go to sleep [Sun Oct 30 20:02:46 2016] Thanks for your help ! [Sun Oct 30 20:18:03 2016] np [Mon Oct 31 09:32:01 2016] Software foundations Imp chapter says "repeat simpl" will loop forever. This doesn't seem to hold for coq 8.5pl2. any good way to let authors know? [Mon Oct 31 10:47:42 2016] email? [Tue Nov 1 00:12:01 2016] Are there any definitions for injective/surjective/etc functions in the standard library? [Tue Nov 1 00:14:27 2016] There are some here https://coq.inria.fr/library/Coq.Logic.FinFun.html [Tue Nov 1 00:14:45 2016] but I don't know if they are really that standard, or just used in that file [Tue Nov 1 00:15:45 2016] Cypi: I saw that, but it looks like they are only good for AxA functions, where A is finite? [Tue Nov 1 00:16:31 2016] Well, the first definitions are general. The properties that are proved afterwards, less so, indeed [Tue Nov 1 00:16:58 2016] ah, okay - not sure how I missed that. I guess I'll try that for now, thanks! [Tue Nov 1 00:17:14 2016] As a hobby I am trying to formalize some of the definitions from an undergraduate level discrete math class in Coq and Isabelle [Tue Nov 1 00:18:17 2016] By the way, is there a general opinion on the mathematical proof syntax (what used to be called Czar)? [Tue Nov 1 00:18:27 2016] I know a few years ago, new users were warned to stay away from it... [Tue Nov 1 01:19:33 2016] do you have any suggestions for how to navigate the standard library? [Tue Nov 1 01:21:18 2016] Starting out, it is difficult to figure out stuff like - should I use Coq.ZArith.ZArith, or Coq.Numbers.Something? [Tue Nov 1 01:21:38 2016] Why do I need to say 'Z.mul_comm', but 'div' by itself is okay? [Tue Nov 1 01:22:01 2016] Where wound I find the need to do stuff like 'Open Scope Z_scope' in the package documentation for ZArith? [Tue Nov 1 06:34:45 2016] someone should change the topic to add 8.5pl3, no? [Tue Nov 1 11:00:10 2016] can anyone help me findint Coq 8.4 sources? https://coq.inria.fr/download <- seems to be removed from there [Tue Nov 1 12:53:43 2016] osa1: https://github.com/coq/coq/releases [Tue Nov 1 12:53:54 2016] Oh, he already left. [Tue Nov 1 13:13:04 2016] How do you prove a trivial inequality in coq? Like 3<>0? [Tue Nov 1 13:15:24 2016] convert to 3 = 0 -> False, introduce it as a hypothesis and do inversion on it. [Tue Nov 1 13:16:41 2016] in other words: "inversion 1" will do it [Tue Nov 1 13:17:30 2016] nice, i didn't know you could do that. i'd have done unfold not. intros. inversion H. [Tue Nov 1 13:45:44 2016] Cypi, modulus: sorry for the delay, thanks greatly! [Tue Nov 1 13:46:28 2016] Relatedly, 'rewrite Z_div_mult_full in H0. rewrite Z_div_mult_full in H0' works for me, but 'repeat (rewrite Z_div_mult_full in H0)' never terminates - any suggestions? [Tue Nov 1 13:47:10 2016] What's the question? [Tue Nov 1 13:47:25 2016] Just - why doesn't the repeat work & is there a similarly succinct way to write it? [Tue Nov 1 13:47:51 2016] if rewrite finds something to rewrite at each step, it's normal it never terminates: it will just rewrite indefinitely [Tue Nov 1 13:48:22 2016] if you already know how many times you want to rewrite, you can do: do 2 rewrite Z_div_mult_full in H0 [Tue Nov 1 13:49:10 2016] hmm, interesting - that works, but it makes 3 "3 <> 0" subgoals, instead of 2 [Tue Nov 1 13:50:09 2016] Ah, right [Tue Nov 1 13:50:10 2016] basically, I have http://lpaste.net/322211 - and I would really appreciate suggestions on ways to make it more idiomatic of a proof [Tue Nov 1 13:50:27 2016] that's because it's equivalent to rewrite Z_div_mult_full in H0; rewrite Z_div_mult_full in H0, which is not the same [Tue Nov 1 13:50:48 2016] ah, I see. [Tue Nov 1 13:51:06 2016] why does 'rewrite Z_div_mult_full in H0; inversion 1' not solve the generated subgoal? [Tue Nov 1 13:52:05 2016] because it can only solve the "3 <> 0" subgoal, not the other one [Tue Nov 1 13:52:43 2016] If you really want something more compact, you can write: do 2 (rewrite Z_div_mult_full in H0; try inversion 1). [Tue Nov 1 13:53:01 2016] that makes sense. Do you think that that would be more or less idiomatic? [Tue Nov 1 13:53:07 2016] or slightly better I guess: do 2 (rewrite Z_div_mult_full in H0; [|inversion 1]). [Tue Nov 1 13:53:49 2016] I think my personal preference would be to write twice "rewrite Z_div_mult_full in H0; [|inversion 1]." (not with the "do 2") [Tue Nov 1 13:54:08 2016] but honestly, I don't know how valuable my opinion is, I'm not such an expert ^^ [Tue Nov 1 13:54:20 2016] okay, that makes sense - thanks for the disclaimer! [Tue Nov 1 13:54:50 2016] Do you have any other suggestions for the other part(s) of that proof? I feel like all of my coq ends up looking more verbose than the stuff that I see "in the wild", although I'm not totally sure... [Tue Nov 1 13:55:00 2016] in the end so long as the proof is reasonably readable it's fine. the generated terms are the same anyway. [Tue Nov 1 13:55:22 2016] that's true... [Tue Nov 1 13:55:31 2016] modulus: what do you think of the mathematical proof language for making proofs more readable? [Tue Nov 1 13:55:37 2016] well, some people (ab?)use tacticals to the point that their proofs are a bit dense to read, to me anyway. [Tue Nov 1 13:55:42 2016] I come from an Isabelle/HOL background... [Tue Nov 1 13:55:57 2016] Well, people like more or less automatization, that's the main difference [Tue Nov 1 13:56:10 2016] andromeda-galaxy - there are a couple of attempts on this line. there is the other notation for proofs, which does look more meaningful than tactics. [Tue Nov 1 13:56:10 2016] for instance, after the "unfold f", you could just do "omega" [Tue Nov 1 13:56:15 2016] it would solve the goal [Tue Nov 1 13:56:16 2016] there's also Mtac [Tue Nov 1 13:56:45 2016] It seems like even a readable coq proof you kind of have to step through and think about the way that the proof state changes, whereas you can (maybe) hopefully get an idea of the high-level thinking just on reading without even worrying about the state [Tue Nov 1 13:56:57 2016] right, the difference is if you want to convey that something is true, or also how/why it is true. [Tue Nov 1 13:57:05 2016] modulus: I think that is what I meant by the "mathematical proof language"? - used to be called Czar? [Tue Nov 1 13:57:07 2016] omega is basically saying "by presburger arithmetic" [Tue Nov 1 13:57:33 2016] Ah, that makes sense. [Tue Nov 1 13:58:27 2016] yes, but the alternative mathematical notation thing is not well documented (ime) and it is not as well developed and hard to automate. [Tue Nov 1 13:58:53 2016] it might be useful to use on some particular branches of a proof where you want to show the work perhaps, but i wouldn't use it often. [Tue Nov 1 13:59:15 2016] ah, okay. thanks, I'd been wondering about the state of that [Tue Nov 1 13:59:46 2016] in Isabelle lots of proofs are written that way, so I was rather curious [Tue Nov 1 13:59:46 2016] state is not very good, it's easy to get yourself to a position where you screw yourself out of the capacity to finish the proof. [Tue Nov 1 13:59:48 2016] and it can only work on focused goals etc. [Tue Nov 1 14:00:31 2016] are we agreeing that that makes a declarative style nice? [Tue Nov 1 14:00:45 2016] yeah, i never used isabelle so i can't really compare, but the advantage with the tactical approach is you can write new tactics and automate to quite an amazing extent, with things like omega or crush that are really semi-automatic solvers for at least some domains. [Tue Nov 1 14:01:26 2016] i like declarative style for reading proofs, that's for sure. unfold meh. apply foo. rewrite bar. reflexivity. doesn't make for very meaningful scripts. [Tue Nov 1 14:01:51 2016] yeah, exactly. In the sort of proofs that I was writing with Isabelle, at least, tactics are still used to go between each step in the declarative reasoning [Tue Nov 1 14:02:16 2016] so you could write down each major equation that you would have written in a paper-and-pen proof and then go between them with tactics like "by presburger" "by metis" "by smt", that sort of thing [Tue Nov 1 14:02:29 2016] so you could get a fair bit of automation with (hopefully) more readable proofs [Tue Nov 1 14:02:36 2016] (and then of course, there is the infamous sledgehammer) [Tue Nov 1 14:02:53 2016] aha, that does sound like it would make for more readability. my understanding is isabelle has other disadvatanges but that sounds like a pro. [Tue Nov 1 14:03:52 2016] yeah - the logics are mostly classical and non-dependent, which is a big reason that I am now learning Coq. [Tue Nov 1 14:03:55 2016] that said, as one learns coq it's my experience that one gets better at simulating the tactics. [Tue Nov 1 14:04:42 2016] hmm, that indeed makes sense [Tue Nov 1 14:04:59 2016] oh well, maybe some day we'll finish Czar and have the best of both worlds [Tue Nov 1 14:05:08 2016] we can hope :-) [Tue Nov 1 14:06:03 2016] indeed :-) [Tue Nov 1 14:10:50 2016] hmm, now I am trying to prove ~ (Surjective f). - any tips for how to approach the negation of a quantified statement? [Tue Nov 1 14:11:48 2016] put it on a hypothesis, and assert something false that you can prove with it. [Tue Nov 1 14:11:55 2016] then invert on the assertion. [Tue Nov 1 14:13:14 2016] okay, I think that that vaguely makes sense. Like in this case I would 'intros. assert (2 mod 3 = 0) { proof }.' or something like that [Tue Nov 1 14:13:22 2016] and then somehow derive void from false assertion [Tue Nov 1 14:13:31 2016] right. [Tue Nov 1 14:14:02 2016] hmm, do De Morgan's Laws for quantifiers hold in CiC? why not have a tactic for that? [Tue Nov 1 14:14:13 2016] well, then the assert goes into the context, say as assert (C: 2 mod 3 = 0), once you prove it you can inversion C. [Tue Nov 1 14:14:37 2016] de morgan's laws are non-constructive, theyr'e equivalent to excluded middle. [Tue Nov 1 14:16:02 2016] oh right, of course - how embarassing to forget that. Too much time in Isabelle recently, I guess. [Tue Nov 1 14:16:09 2016] np :-) [Tue Nov 1 14:16:09 2016] maybe ClassicalFacts should include something [Tue Nov 1 14:16:31 2016] okay, thanks for all the help/suggestions/etc.! I think I have a better handle on this now [Tue Nov 1 14:16:37 2016] yeah, i am a noob and i don't know the theory library much, but on classical logic module you may have something, idk. [Tue Nov 1 14:16:48 2016] yw, hth, gl. [Tue Nov 1 14:20:51 2016] thanks! [Tue Nov 1 14:30:13 2016] hmm, I am still having trouble understanding the right way to prove stuff like '0 <= 0 < 3', for example... [Tue Nov 1 14:30:57 2016] "repeat constructor" might do it? [Tue Nov 1 14:31:04 2016] otherwise, stuff like "omega" [Tue Nov 1 14:32:06 2016] aha, thanks - looks like "repeat constructor; inversion 1' works [Tue Nov 1 14:32:59 2016] repeat constructor alone works for me on 0 <= 0 < 3. [Tue Nov 1 14:33:55 2016] hmm, weird - I got an extra '0 <= 0' subgoal when I tried it [Tue Nov 1 14:34:34 2016] that's odd, constructor solves that one. [Tue Nov 1 14:35:01 2016] so I had to use 'elim H.' to change an existential quantifier in a hypothesis but I didn't really understand what that did - do you have any suggestions for where to look into better ways to do that? [Tue Nov 1 14:35:33 2016] hmm, I get "The type has no constructors" [Tue Nov 1 14:35:40 2016] oh, I am using Zarith - are you using nat? [Tue Nov 1 14:36:20 2016] ah, yes, sorry, i was using nat. [Tue Nov 1 14:36:42 2016] that must be it, I guess [Tue Nov 1 14:51:42 2016] agh, why is there no (a*b)/a = b in Coq.NArith.BinNat? [Tue Nov 1 14:53:37 2016] or in fact (a*b/b) = a, is what I need, I guess [Tue Nov 1 14:54:10 2016] can't you use associativity? [Tue Nov 1 14:54:34 2016] for a*(b/b), probably - but there's no (a*b)/b = a in the first place! [Tue Nov 1 14:55:24 2016] it seems to me if you can rewrite into (a*(b/b)) should be possible to get a out of it easily. [Tue Nov 1 14:56:34 2016] hmm, maybe - I can't find a lemma for b/b = 1, though [Tue Nov 1 15:00:04 2016] <__monty__> May be a stupid question but what about 0? [Tue Nov 1 15:03:59 2016] good point, i guess it'd be undefined for 0. [Tue Nov 1 15:46:10 2016] andromeda-galaxy: Lemma div_same : forall a, 0 a/a == 1. [Tue Nov 1 15:46:33 2016] Lemma div_mul : forall a b, 0<=a -> 0 (a*b)/b == a. [Tue Nov 1 15:46:47 2016] oh [Tue Nov 1 15:46:48 2016] binnat [Tue Nov 1 15:46:50 2016] reading is hard [Tue Nov 1 15:46:52 2016] sorry [Tue Nov 1 15:47:23 2016] that'll work anyways though i think [Tue Nov 1 15:49:08 2016] Coq < Check N.div_mul. [Tue Nov 1 15:49:10 2016] N.div_mul [Tue Nov 1 15:49:12 2016] : forall a b : N, b <> 0%N -> (a * b / b)%N = a [Tue Nov 1 16:05:24 2016] modulus, __monty__: good point, that's an easy obligation to discharge in this case [Tue Nov 1 16:06:26 2016] KaneTW: hmm, thanks - not sure how I missed those.. [Tue Nov 1 16:06:40 2016] KaneTW: where is N.div_mul defined? [Tue Nov 1 16:08:06 2016] Coq < Locate N.div_mul. [Tue Nov 1 16:08:07 2016] Constant Coq.NArith.BinNat.N.div_mul [Tue Nov 1 16:08:14 2016] oh cool! thanks! [Tue Nov 1 16:08:24 2016] I can't seem to get the hang of rewriting in subterms.. [Tue Nov 1 16:09:02 2016] if rewrite is misbehaving remember you can use replace (x) with (y) and then discharge x = y. [Tue Nov 1 16:10:01 2016] hmm.. okay, I think that makes sense.. [Tue Nov 1 16:10:08 2016] my goal is y * 2 / 2 = y [Tue Nov 1 16:10:26 2016] rewrite N.div_same and N.div_mul both don't work on that [Tue Nov 1 16:10:32 2016] whichever the associativity is it doesn't work [Tue Nov 1 16:11:00 2016] hmm i'm not familiar with BinNat in particular but you should have associativity rewrites to change it. [Tue Nov 1 16:11:24 2016] I mean, if it is associated as (y*2)/2 then shouldn't div_mul work? [Tue Nov 1 16:11:34 2016] and if it's y * (2/2), then shouldn't div_same work? [Tue Nov 1 16:13:17 2016] have you tried apply N.div_mul ? [Tue Nov 1 16:13:41 2016] yes: Unable to unify "(?M1792 * ?M1793 / ?M1793)%N = ?M1792" with [Tue Nov 1 16:13:41 2016] "y * 2 / 2 = y". [Tue Nov 1 16:14:12 2016] this is inside a "Open Scope nat_Scope" and after "Close Scope Z_Scope" [Tue Nov 1 16:14:23 2016] although I don't really understand scopes... [Tue Nov 1 16:14:31 2016] then no idea what is happening, sorry. [Tue Nov 1 16:14:59 2016] presumably those terms are of type N? [Tue Nov 1 16:16:05 2016] oh, oops. that's it - they are nats [Tue Nov 1 16:16:34 2016] like I mentioned yesterday, I don't really understand all the kinds of numbers, so I'm probably using the wrong ones [Tue Nov 1 16:17:42 2016] I just have a function that in math notation is \mathbb{N} -> \mathbb{N} so I wrote it as nat to nat [Tue Nov 1 16:21:51 2016] modulus: any suggestions for better numbers and/or whether that lemma works with nat? [Tue Nov 1 16:34:36 2016] What are the differences between Modules and Sections? [Tue Nov 1 16:46:40 2016] sections are just bits where you can declare variables and things, use them in lemmas, and when you close the section the lemmas will generalize on those variables. [Tue Nov 1 16:47:09 2016] modules i don't understand them fully. i use them for namespace issues but i am aware they do more things, but i don't know what they are. [Tue Nov 1 16:47:44 2016] ah, okay - do sections provide any namespacing isolation? [Tue Nov 1 16:48:03 2016] I am just trying to figure out how to structure a file with nested scopes so that I can define "f" a few times in different contexts [Tue Nov 1 16:48:11 2016] also you can put a section in a module but not a module i a section. [Tue Nov 1 16:48:27 2016] and am not sure if I should use 'Section Thing1' or 'Module Thing1' inside my file [Tue Nov 1 16:48:29 2016] hmm, interesting [Tue Nov 1 16:48:44 2016] i'd go for modules [Tue Nov 1 16:48:46 2016] they nest well. [Tue Nov 1 16:49:08 2016] Sections don't provide namespacing anyway, you are right [Tue Nov 1 16:49:13 2016] cool, I'll do that then - thanks [Tue Nov 1 16:49:42 2016] section is like, say you're going to prove a few theorems about n m o: nat and p q r s:Prop, you can declare those propositions so you don't need to do the forall p q r s :Prop thing every time. [Tue Nov 1 16:51:47 2016] ahh, okay [Tue Nov 1 16:52:22 2016] I got confused by having heard that Chapter is like Section, so I assumed that they would be good for like writing a book where I might want to use the same names in different chapters [Tue Nov 1 16:56:10 2016] way i've seen it described in the tutorial is section is to define a universe of discourse where you're going to prove things on. just to save you the trouble of reintroducing it in every lemma. then when you do End Whatever, the lemmas get generalized to the variables you declared in the section. [Tue Nov 1 16:57:21 2016] okay, right, that makes more sense, thanks [Tue Nov 1 17:06:51 2016] is Couple somehow used for the cartesian product of Ensembles? [Tue Nov 1 17:09:04 2016] how to Ensemble unions not double count the intersection? [Tue Nov 1 17:22:57 2016] hmm. I want to write a function which,given two sets, is a funciton from the powerset of their union to the product of their powersets [Tue Nov 1 17:24:01 2016] but I can't use Ensembles and say, e.g. 'Definition f (x : Power_set U (Union U A B))' because Power_set U (Union U A B) has type Ensemble not type Set [Tue Nov 1 17:26:23 2016] you sure that's how you want to declare the type of x? [Tue Nov 1 17:26:57 2016] well it definitely isn't since it gives (x : (y : Ensemble U)) which doesn't work - but I'm not sure what the correct way to model the function is [Tue Nov 1 17:50:48 2016] modulus: How would I model a function whose domain is the powerset of another set? [Tue Nov 1 17:54:18 2016] well, a powerset is a set, no? [Tue Nov 1 17:54:57 2016] indeed, but this function is intended to take only sets that are powersets of another one - not any Ensemble (Ensemble U) [Tue Nov 1 17:55:49 2016] f : P(A union B) -> something [Tue Nov 1 17:56:03 2016] I mean, not any Ensemble U [Tue Nov 1 17:56:06 2016] i don't know, not sure how one would represent that as a type. my instinct is that may be easier to represent as a relation. [Tue Nov 1 17:56:28 2016] represent as a relation?esent as a relation [Tue Nov 1 17:56:42 2016] (sorry about the doubling there, I have bad network connectivity) [Tue Nov 1 17:57:10 2016] instead of a funciton i mean. [Tue Nov 1 17:57:33 2016] hmm. it is just that it is a function, and I want to show whichever injectivity/surjectivity properties it might have [Tue Nov 1 17:59:07 2016] it also produces output that is restricted like that - the cartesian product of powersets [Tue Nov 1 17:59:29 2016] f : {x : U | In x P(A union B)} -> something [Tue Nov 1 17:59:35 2016] wouldn't that be the correct type for such a function? [Tue Nov 1 17:59:43 2016] Cypi: how does that bar work? [Tue Nov 1 17:59:53 2016] (I meant "In P(A union B) x") [Tue Nov 1 18:00:00 2016] probably it would [Tue Nov 1 18:00:22 2016] if the result type can also be like that [Tue Nov 1 18:00:27 2016] sure [Tue Nov 1 18:00:46 2016] Cypi: those look like refinement types to me? [Tue Nov 1 18:00:52 2016] I didn't know coq had that syntax [Tue Nov 1 18:01:01 2016] It's just a notation for sig [Tue Nov 1 18:01:07 2016] not really refinement types, these are dependent pairs [Tue Nov 1 18:01:31 2016] ohhh dependent pair of some value x and a proof that it is an element... I see [Tue Nov 1 18:01:53 2016] I don't know much about Ensembles, but I would guess this is a way of speaking of the elements of an Ensemble [Tue Nov 1 18:01:59 2016] hmm, I will try that [Tue Nov 1 18:02:08 2016] but maybe what you actually want is to represent your functions are actual Ensemble, I don't know [Tue Nov 1 18:02:12 2016] s/are/as [Tue Nov 1 18:14:04 2016] Cypi: sorry for the big delay. That is probably what I really want, actually... [Tue Nov 1 18:14:38 2016] It all depends if you want to talk about Coq functions, or functions in the realm of Ensembles [Tue Nov 1 18:14:43 2016] (I mean, the version that you provided) [Tue Nov 1 18:14:49 2016] ok, good then :) [Tue Nov 1 18:15:01 2016] I should try to figure out the distinction better, though [Tue Nov 1 18:15:10 2016] basically I am just translating some old exercises that I did in Isabelle into Coq [Tue Nov 1 18:15:40 2016] (exercises from some old book) - doing them in Isabellle is really nasty, and I was hoping that Coq would be better [Tue Nov 1 18:15:55 2016] how is it going so far? [Tue Nov 1 18:16:06 2016] so all that really matters is that it is a function from elements of that powerset to elements of the other powerset, and that I can show wthat it is injective, whatever [Tue Nov 1 18:16:34 2016] okay, I think - I haven't had too much time since Cypi suggested it since I had to suddenly walk between buildings and then reboot my machine when its network died [Tue Nov 1 18:19:27 2016] hmm, { x : U | In x (Power_set U (Union U A B)) gives The texm "x" has type "U" while it is expected to have type "Type" [Tue Nov 1 18:19:32 2016] i meant generally rewriting isabelle exercises in coq. [Tue Nov 1 18:19:49 2016] oh wait, I understand why, I made a type [Tue Nov 1 18:20:09 2016] (also, In probably needs U as an argument) [Tue Nov 1 18:20:11 2016] modulus: hmm, pretty okay so far - some are better, some are worse, some are just different. The declarative vs. tactic proof styles are very different [Tue Nov 1 18:20:26 2016] Cypi: what is the syntax for using that construction in an argument of a Definition? [Tue Nov 1 18:21:37 2016] What do you mean? [Tue Nov 1 18:22:13 2016] it should just be like "Definition f (n : { x : U | In ...})" right? [Tue Nov 1 18:22:16 2016] {x : U | In U (Power_Set U (Union U A B)) x} is just a type (it has literally type Type), you can use it wherever you can use a type [Tue Nov 1 18:22:20 2016] Yes, for instance [Tue Nov 1 18:22:58 2016] there, this is it I think: (n : { x : Ensemble U | In (Ensemble U) (Power_set U (Union U A B)) x }) [Tue Nov 1 18:23:50 2016] hmm, what is the type for generally the cross product? [Tue Nov 1 18:24:47 2016] Do you just mean "prod"? [Tue Nov 1 18:26:41 2016] Maybe! but I think it needs to be product of ensembles, because I want to say roughly { x : ??? | In x (??? (Power_set A) (Power_set B)) [Tue Nov 1 18:28:03 2016] what exactly does Couple do? [Tue Nov 1 18:28:28 2016] but basically I need to fill in the two blanks to say that it is in the cross product of the two powersets, which are ensembles, right? [Tue Nov 1 18:35:09 2016] actually maybe I need some way of doing this without Ensembles - like to prove this one in full generality, I don't need to restrict A and B to having the same universe [Tue Nov 1 18:35:43 2016] Meh, this stdlib seems to be lacking basic stuff like products, functions, etc... Not sure what its intended scope is [Tue Nov 1 18:35:58 2016] certainly not set theory [Tue Nov 1 18:37:13 2016] indeed... [Tue Nov 1 18:37:45 2016] any suggestions for a better library/modules to use? [Tue Nov 1 18:41:28 2016] Maybe this one is more usable? https://github.com/coq-contribs/zfc (I don't really know better than you, just looking up stuff) [Tue Nov 1 18:57:04 2016] Cypi: looks promising, I'll try it [Tue Nov 1 18:57:20 2016] I may take a break and do some less set-theoretic stuff when I find out [Tue Nov 1 18:57:28 2016] *before I look at that [Tue Nov 1 22:08:42 2016] Hello everyone [Tue Nov 1 22:09:30 2016] I am trying to prove ceval_deterministic https://gist.github.com/mukeshtiwari/047b46f9ded7aa1e0cd1f27d1f090370 [Tue Nov 1 22:09:41 2016] But stuck with goal [Tue Nov 1 22:09:50 2016] Could some one please have a look [Tue Nov 1 22:11:20 2016] I can prove only when we have st' = st'0 [Tue Nov 1 22:11:36 2016] But I don't see any relation to connect these two states [Tue Nov 1 22:43:11 2016] Now I am stuck with while loop https://gist.github.com/mukeshtiwari/13e5210a7d590a021a84b3a1e70063ea [Tue Nov 1 22:43:21 2016] Any idea how to solve this goal [Wed Nov 2 00:27:58 2016] #hacks [Wed Nov 2 00:34:20 2016] hmm, so I have proof right now that looks like 'assume foo. { ... } rewrite SomeLemma. assumption. apply foo.' [Wed Nov 2 00:34:48 2016] is there some way to combine those things together more idiomatically [Wed Nov 2 00:35:58 2016] (apart from just replacing the apply foo with the assume foo)? [Wed Nov 2 00:36:32 2016] specifically, this feels like it is in kind of the wrong order to me [Wed Nov 2 00:36:51 2016] I would like to read the proof as 'rewrite SomeLemma, which works because { proof block }. Then it's just an assumption [Wed Nov 2 00:36:54 2016] ' [Wed Nov 2 00:37:58 2016] (or, if there is a more idiomatic way to read/write that, I'd like to do that...) [Wed Nov 2 11:42:54 2016] How do you write tactics taking a constr_list in Ltac? [Thu Nov 3 05:25:19 2016] doing the Imp chapter of software foundations, sometimes it requires manually formulating fairly long terms for apply S_Eq with (_) [Thu Nov 3 05:25:31 2016] is there any way to avoid having to write these terms by hand? [Thu Nov 3 05:53:11 2016] modulus: it's possible that "eapply S_Eq" will generate goals to build those terms. I don't know for your specific example. [Thu Nov 3 05:54:22 2016] thanks, i'll give it a shot. [Thu Nov 3 16:41:00 2016] is anyone aware of a library of c-zar proofs? I'd like to start learning how to use that style but there are precious few examples to learn from [Thu Nov 3 16:42:32 2016] http://math.stackexchange.com/questions/1037997/status-of-declarative-proof-languages-in-proof-assistants has no answer :/ [Thu Nov 3 18:09:30 2016] qwerty2016: lean has such a syntax too. and ssreflect for coq can be readable if you are used to it [Thu Nov 3 18:27:43 2016] lean looks cool, but i am wary of learning a new language. I am not sure how it is better than Coq or Isobelle [Thu Nov 3 18:27:52 2016] i will take a long look at ssreflect though [Thu Nov 3 18:32:19 2016] qwerty2016, I learned lean before learning coq, it's not too much to learn, especially if you know a similar language already [Thu Nov 3 18:32:54 2016] same keywords even [Thu Nov 3 18:33:36 2016] the lean tutorial places a much bigger focus on constructing the proof terms manually, instead of letting tactics do it (but they do have tactics) [Thu Nov 3 18:34:02 2016] and the interaction style is a bit different [Thu Nov 3 18:34:09 2016] real tactics are only coming in lean3 now [Thu Nov 3 18:34:17 2016] or, composable tactics that is [Thu Nov 3 18:34:20 2016] instead of being displayed your assumptions and your goal you place a "_" and hover over it [Thu Nov 3 18:34:44 2016] and to find your assumption you just look left of your cursor and find all your (fun x => …) [Thu Nov 3 18:35:05 2016] o/ chris2 [Thu Nov 3 18:35:11 2016] hey [Thu Nov 3 18:35:31 2016] #leanprover is a subset of #coq :D [Thu Nov 3 18:35:49 2016] indeed [Thu Nov 3 18:42:43 2016] so... lean is basically coq, but with nicer syntax and quality of life improvements? but fewer libraries? [Thu Nov 3 18:43:45 2016] qwerty2016, the stdlib of lean feels more cleaned up to me [Thu Nov 3 18:44:05 2016] in coq, I never know which of le_n_S, le_S, etc. I Need [Thu Nov 3 18:44:29 2016] but it's smaller I guess [Thu Nov 3 18:45:50 2016] There are some "ethical" differences in the treatment of inductive types also, I guess: in Lean you only have eliminators, in Coq you derive the eliminators from pattern-matching [Thu Nov 3 18:47:03 2016] Cypi, what are the consequences of this? [Thu Nov 3 18:47:08 2016] I have no clue :D [Thu Nov 3 18:47:10 2016] haha [Thu Nov 3 18:47:30 2016] Hmm, actually I can mention one consequence [Thu Nov 3 18:47:43 2016] that means that by default, with only eliminators, you are forced to recurse on the very next subterm [Thu Nov 3 18:48:05 2016] You need to put a little more work to recurse on a deeper subterm [Thu Nov 3 18:48:21 2016] you mean you can't do match x with S (S x) => …? [Thu Nov 3 18:48:25 2016] without "match"ing twice [Thu Nov 3 18:48:36 2016] You cannot do that and then a recursive call on that x [Thu Nov 3 18:48:52 2016] oops, I used x twice here [Thu Nov 3 18:48:59 2016] on the inner x [Thu Nov 3 18:49:13 2016] eh, why not? [Thu Nov 3 18:49:36 2016] Because you wouldn't write a match with an eliminator, you would write something using the equivalent of nat_rect [Thu Nov 3 18:49:53 2016] forall P : nat -> Type, P 0 -> (forall n : nat, P n -> P (S n)) -> forall n : nat, P n [Thu Nov 3 18:49:54 2016] eliminators are not something like "rect"? [Thu Nov 3 18:49:58 2016] They are [Thu Nov 3 18:50:15 2016] and in the successor branch, you have to prove P (S n) only knowing P n [Thu Nov 3 18:50:41 2016] ("P n" would be the recursive call) [Thu Nov 3 18:51:10 2016] Cypi, the coq equivalent also has the non S (S x) arm, that can return something of the same type as the S (S x) arm [Thu Nov 3 18:51:23 2016] so you could return that in the O case of the inner match [Thu Nov 3 18:51:29 2016] "match" [Thu Nov 3 18:51:32 2016] eliminator [Thu Nov 3 18:52:09 2016] Hmm. I'd have to try to do it precisely, but I think you need a little bit of work to formulate correctly the "P" for the inner eliminator [Thu Nov 3 18:52:18 2016] if what you are suggesting is nesting two eliminators [Thu Nov 3 18:52:27 2016] yeah [Thu Nov 3 18:52:33 2016] maybe I didn't think this through [Thu Nov 3 18:52:40 2016] iirc lean has match anyway [Thu Nov 3 18:52:41 2016] as syntactic sugar [Thu Nov 3 18:54:04 2016] Oh you're right, it looks like that actually have full-fledged dependent pattern-matching, structural recursion and so on [Thu Nov 3 18:54:14 2016] I don't know if it's compiled away and in what manner though [Thu Nov 3 18:54:26 2016] yeah, I think with 8.5 they are on par but 8.4 was actually a bit more tedious [Thu Nov 3 18:54:35 2016] Cypi, it's turned into eliminators I thinik [Thu Nov 3 18:54:51 2016] qwerty2016, another thing about lean is that the author apparently cares about supporting hott stuff [Thu Nov 3 18:54:55 2016] if you're into that [Thu Nov 3 18:55:48 2016] (which is another thing I don't quite get) [Thu Nov 3 18:56:15 2016] lean elaborates dependent pattern matching really well ime [Thu Nov 3 18:56:32 2016] you dont need to do it yourself [Thu Nov 3 19:02:05 2016] well, i guess i can read over the tutorial. at first glance it seemed to be the not-invented-here child of coq and mizar [Thu Nov 3 19:02:47 2016] qwerty2016, even if it added nothing to coq other than prefixing the cases of an inductive type, I'd take it [Thu Nov 3 19:02:50 2016] this namespace clutter is terrible [Thu Nov 3 19:03:36 2016] (I thought about patching that into coq for fun, but I'd have to learn french first :P) [Thu Nov 3 19:03:47 2016] Why French? [Thu Nov 3 19:04:01 2016] Well ok, _some_ part of the codes still have French in them :p [Thu Nov 3 19:04:07 2016] parts* code* [Thu Nov 3 19:04:29 2016] But really, you shouldn't need any French to contribute :) [Thu Nov 3 19:04:44 2016] Cypi, it's more the usual problems of finding your way in a huge code base but I also did stumble upon french parts without looking for them. [Thu Nov 3 19:05:26 2016] Also, I wonder how the devteam would feel about such a change. It would break probably every single script out there [Thu Nov 3 19:05:39 2016] Cypi, it's a "python with braces" kind of idea [Thu Nov 3 19:05:59 2016] only realistic way is a per file opt-in [Thu Nov 3 19:06:02 2016] but I do agree that I always have to come up with terrible names for constructors :p [Thu Nov 3 19:06:56 2016] On the other hand, this is a problem that shouldn't exist too much with nice use of modules [Thu Nov 3 19:07:12 2016] (and just having several files, not using "Require Import" but just "Require") [Thu Nov 3 19:07:56 2016] Would be nice to have a cheatsheet/faq for the module system because I always put everything in a single file to avoid having to think about it too much [Thu Nov 3 19:08:07 2016] then again, I don't work on any serious project with coq [Thu Nov 3 19:30:32 2016] rrika: very much agreed [Thu Nov 3 19:30:48 2016] rrika: every time I want to do something serious with modules, I find myself reading the 3 scant resources that exist over and over [Thu Nov 3 19:32:47 2016] haha [Thu Nov 3 19:33:45 2016] Just read the source code, and then write an explanation of it for everyone else :> [Thu Nov 3 19:34:02 2016] (there is a myth that nobody quite understands the code managing modules) [Fri Nov 4 19:40:26 2016] anyone here coming to the presentation at Santa Clara University this evening? [Sun Nov 6 02:24:52 2016] johnw: apparently not [Sun Nov 6 11:44:57 2016] https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried [Wed Nov 9 04:12:53 2016] when including a module type, I can override a single definition using "Include M with Definition Foo := 42.". Is there a way to do this with multiple definitions? [Thu Nov 10 09:37:35 2016] I was thinking about doing a proof that an algorithm that cuts polygons with axis-aligned edges into rectangles works correctly. [Thu Nov 10 09:37:48 2016] Was wondering what kind of field deals with such questions. [Thu Nov 10 09:38:44 2016] Because I could take some ad-hoc approach but the task seems simple enough that someone else must've thought about it already. [Fri Nov 11 06:06:18 2016] Hello all. How do I specialize a forall hypothesis to some specific value? [Fri Nov 11 06:07:24 2016] For example, I have H: forall x, P x and want to create an H0: P n for a specific n: nat [Fri Nov 11 06:11:35 2016] To stack up the questions.. can Coq be used as a theorem prover? [Fri Nov 11 06:17:27 2016] r_rios: iirc, (H n) should be a proof of H0 [Fri Nov 11 06:21:16 2016] You can use "specialize (H n)" if you want to replace H with the new hypothesis, or "pose proof (H n)" to create a new hypothesis [Fri Nov 11 06:21:53 2016] dmiles: what do you mean? An automatic theorem prover? [Fri Nov 11 06:22:04 2016] If yes, in some extent, with the right tactics [Fri Nov 11 06:22:24 2016] to* some extent [Fri Nov 11 06:22:27 2016] it's not really thought out as an entirely automatic solver. [Fri Nov 11 06:22:35 2016] it can do some of it but it's not what it is good at. [Fri Nov 11 06:23:13 2016] ok, well that is a start :P [Fri Nov 11 06:23:31 2016] this is realitively new in the last 4 years? [Fri Nov 11 06:24:11 2016] (the tactic managment being usefull for doing small bits of inferenceing) [Fri Nov 11 06:25:28 2016] well sorry i am probably mixing a few things up it coudls sound like: inferncing and automated solving [Fri Nov 11 06:25:42 2016] dmiles: for the record there exists some automated theorem provers which can output coq proofs (for instance, Zenon) [Fri Nov 11 06:26:05 2016] It's not really new. Coq "always" had some (basic) automated tactics like auto, intuition, omega and so on, and some people always tried to have more complicated tactics [Fri Nov 11 06:26:48 2016] since such provers exist that produce Coq output i suppose a nomral step is to let provers be embeded in some ways [Fri Nov 11 06:27:11 2016] (or at least an interface to runing them?) [Fri Nov 11 06:28:43 2016] right, but I d'ont remember if such a fonctionnality has already been implemented in Coq (btw, that's what the sledgehammer tool does in isabelle) [Fri Nov 11 06:29:57 2016] zozozo: specialize is what I was looking for [Fri Nov 11 06:30:18 2016] Thanks, Cypi and zozozo [Fri Nov 11 06:30:53 2016] What i am evetually really after is to find out if deductive FOPL data files if i convert to a format someone likes can bbe used to forward anf backchain to deduce new states and facts.. this might be done using OWL files or perhaps KIF files like https://github.com/ontologyportal/sumo/blob/master/Merge.kif [Fri Nov 11 06:31:40 2016] wondering what sort of tools exists in Coq's orbit for such things [Fri Nov 11 06:34:18 2016] normally tools i use are LarKC, CYC and Ontolingua [Fri Nov 11 06:34:52 2016] but there seems to be this whole other world in which Coq plays a big role in [Fri Nov 11 06:36:13 2016] in whaty way is Coq differnt than Isabelle? [Fri Nov 11 06:36:22 2016] from* [Fri Nov 11 06:37:34 2016] the logic is different. isabelle is classical high order logic. [Fri Nov 11 06:37:51 2016] coq is (by default) intuitionistic/constructive. [Fri Nov 11 06:38:43 2016] i think the logic of KIF might be called sequent logic.. I thought somehow it is constructive logic in that it builds up sentences [Fri Nov 11 06:39:18 2016] but constructive logic is ot about constructing new sentences right? [Fri Nov 11 06:40:18 2016] but constructive logic is about constructing new sentences without trying to make up T/F deductions right? [Fri Nov 11 06:40:33 2016] constructive logic is that if you have something saying there exists x, such that bla bla, if the logic is constructive you can get the x. [Fri Nov 11 06:40:40 2016] well, (an) x. [Fri Nov 11 06:43:01 2016] i like that constructive logic does not cowtow to the ideas of excluding middle [Fri Nov 11 06:43:30 2016] in that this is term rewriting without some notion of truth values? [Fri Nov 11 06:43:39 2016] (sort of like prolog?) [Fri Nov 11 06:45:22 2016] dmiles, if you have a proof for "a=b" you can turn "x : … a …" into "x : … b …" [Fri Nov 11 06:46:02 2016] nice, " double negation can be introduced, but it cannot be eliminated " I always thought double negation elimination was a bad idea [Fri Nov 11 06:47:09 2016] since normally the two negations are in separated domains .. for exmaple ~ ~ P migh tmean never is it ture that P is false.. yet that doesnt say ever that P is true [Fri Nov 11 06:47:45 2016] ~ ~ P might mean never is it true that P is disproven .. yet that doesnt say ever that P is true [Fri Nov 11 06:48:04 2016] and for your own data types you can define the constructors in a way that restricts which types are inhabited [Fri Nov 11 06:49:45 2016] so Coq is very good at disproving types are compatible when they are not? [Fri Nov 11 06:49:59 2016] what do you mean by "are compatible"? [Fri Nov 11 06:51:03 2016] you can derive an contradiction if you have a proof of equality between values which you can tell apart [Fri Nov 11 06:51:20 2016] For exampe i have type: PortableObject and various Types like : BigHouse and SMallCupcake.. BitgHouse is not Cpatable with ProtableObject [Fri Nov 11 06:51:35 2016] what kinds of things are these [Fri Nov 11 06:52:10 2016] IF X is type BigHouse is not X is not comaptible with PortableObject [Fri Nov 11 06:52:23 2016] I guess it's hard to disprove such things. You can always introduce an axiom later that says they *are* the same. [Fri Nov 11 06:52:23 2016] they are datatypes in a MUD i am writing [Fri Nov 11 06:53:06 2016] they MUD rejects a user trying to pick up a box containing a BigHouse [Fri Nov 11 06:53:13 2016] oh I see [Fri Nov 11 06:53:42 2016] so i use deduction to descide what is possible for players and NPCs [Fri Nov 11 06:53:58 2016] all the checks in coq I can think of are done ahead of time [Fri Nov 11 06:54:07 2016] using "pick" on a house is a dynamic error [Fri Nov 11 06:54:15 2016] so I guess you'll have to do the check yourself [Fri Nov 11 06:55:03 2016] i am fine with these checks runing at runtime [Fri Nov 11 06:55:22 2016] or i mean requesting these checks be done that is [Fri Nov 11 06:55:52 2016] but even then you want to specify a behavior what to do if they don't match [Fri Nov 11 06:56:04 2016] at that point why not just do the check yourself [Fri Nov 11 06:58:00 2016] what i was thinking Coq was good at detecting disjointedness of sets of composite types [Fri Nov 11 06:58:29 2016] I don't know enough to answer that [Fri Nov 11 06:58:31 2016] some sort of set theory ++ :P [Fri Nov 11 07:01:51 2016] i create composite types like here: https://github.com/TeamSPoon/PrologMUD/blob/master/pack/prologmud/games/src_game_nani/objs_misc_household.pfc.pl#L133-L160 [Fri Nov 11 07:02:15 2016] genls meaning? [Fri Nov 11 07:02:22 2016] genls means if X is arg1 then X is Arg2 [Fri Nov 11 07:02:32 2016] oh [Fri Nov 11 07:03:03 2016] does genls form a tree or a graph? [Fri Nov 11 07:03:15 2016] the *Able types are what NPCs can nomrally do with things [Fri Nov 11 07:03:29 2016] someehat if a graph [Fri Nov 11 07:03:41 2016] someehat of a graph .. hoping to tree-ify it [Fri Nov 11 07:04:17 2016] (assuming tree-ify means i resolve the world into non circular terms) [Fri Nov 11 07:04:20 2016] things you do have in coq: [Fri Nov 11 07:04:22 2016] logic programming to generate terms [Fri Nov 11 07:04:30 2016] records that can hold functions (like vtables) [Fri Nov 11 07:04:46 2016] automatic "casts" [Fri Nov 11 07:05:49 2016] ^ if you have a record B that contains (base: A, health: nat) then the function "base" which takes a B and returns an A, when declared as "coercion" will allow the use of objects of type B where A is expected [Fri Nov 11 07:06:46 2016] ahah good. coercian for me is very important.. I describe quite a bit in it [Fri Nov 11 07:07:19 2016] you have no way to get back from A to B though [Fri Nov 11 07:07:44 2016] I coerce (pathFn kitchen north) to a lookAble that rturns (a path leads normth_ [Fri Nov 11 07:08:25 2016] I coerce (PathFn kitchen north) to a 'lookAble' (was a path) that returns and object that can be seen [Fri Nov 11 07:09:06 2016] mainly i am sort of reassigning the expected uses the code has with a datatype.. that it can start to be used with code that used differnt types [Fri Nov 11 07:10:51 2016] typeProps(tBroccoli,[mudColor(vGreen),mudSize(vSmall),mudShape(isLikeFn(mudShape,tTree))]). so an isntance of broccoli normally only good for energy can be coerced to tArt that looks like a tree [Fri Nov 11 07:11:09 2016] prolog seems to be a nice language to prototype stuff like that [Fri Nov 11 07:11:18 2016] and somone miight paint snow on it (based on the tree-ness) [Fri Nov 11 07:11:28 2016] (green tree-nees) [Fri Nov 11 07:12:28 2016] prolog allows so many decrees of freedom .. you almost need a theorem prover to manage all of your code and data :P [Fri Nov 11 07:12:42 2016] not almost .. you do [Fri Nov 11 07:12:52 2016] okay, here's a problem I see [Fri Nov 11 07:12:59 2016] coq only allows complete functions [Fri Nov 11 07:13:08 2016] (whyy i am seeking tools outside prolog) [Fri Nov 11 07:13:11 2016] so if you define a function: AnyType -> option Carryable [Fri Nov 11 07:13:23 2016] at that point you already need to deal with all possible inputs [Fri Nov 11 07:13:36 2016] if your "type" hierarchy is extendable you could break that [Fri Nov 11 07:14:07 2016] ahah. atp-haskell is all AnyType [Fri Nov 11 07:14:32 2016] so you'll need an enum/inductivedatatype to list all possible types you have [Fri Nov 11 07:14:52 2016] *"types" [Fri Nov 11 07:15:00 2016] they're only types from the gamers perspective [Fri Nov 11 07:15:17 2016] dmiles, if you want to check out another language but not wander too far way from prolog check out mercury [Fri Nov 11 07:15:26 2016] so eventualyl we get some support from the language? [Fri Nov 11 07:15:58 2016] (i mena eventually we stop being the "gamers types" and finnaly get to use outr types) [Fri Nov 11 07:17:24 2016] eventually we stop being the "gamers types" and finnaly get to use our types such as dynamicGamerType systemEnumeablePErcent , actionBackedByCode types [Fri Nov 11 07:18:19 2016] (sort of like if you implement edenbouroh prolog in mercury .. you will have a type called compound, databaseTerm, etc) [Fri Nov 11 07:19:01 2016] (even though the runner of your prolog will have their own system they are thinking in) [Fri Nov 11 07:20:18 2016] secretly i hoping that somehow if their is finnally a ontology of types the systenm discovers that the gamer doesnt have to [Fri Nov 11 07:20:23 2016] there* [Fri Nov 11 07:20:34 2016] I gotta go. Hope you find what you need. [Fri Nov 11 07:20:54 2016] thx.. i should get to work to.. [Fri Nov 11 07:23:20 2016] "so you'll need an enum/inductivedatatype" percisly the type of deduction system... perhaps i am looking for the Quine that produces typetheory and coding it in typethoery [Fri Nov 11 07:23:37 2016] or ATP encoded in ATP [Fri Nov 11 07:25:02 2016] for exmaple.. my TimeSices are never going to be typecompable with the type system (that is a good thing) [Fri Nov 11 07:25:33 2016] time-intervals will stay disjoint form npcs and disjoint from actions [Sat Nov 12 08:58:06 2016] In case anyone's interested: I've created an unofficial discussion channel for fiat at ##fiat [Sat Nov 12 09:03:17 2016] sorry shlevy i dont drive a fiat [Sat Nov 12 09:03:57 2016] I read into category theory and I understand Coq a lot more now. [Sat Nov 12 11:30:14 2016] In 8.5 constructor patterns must now mention parameters of their type? [Mon Nov 14 14:53:06 2016] napping: only if they are not declared as implicit. [Mon Nov 14 14:53:22 2016] Just like in expressions. [Tue Nov 15 21:31:33 2016] Hello everyone [Tue Nov 15 21:31:40 2016] I am trying to prove this https://gist.github.com/mukeshtiwari/6eb4267771c444efff6a0321159e353f [Tue Nov 15 21:32:19 2016] But my problem is I don't have instance of cand variable in context [Tue Nov 15 21:32:32 2016] Any idea if it provable or not ? [Tue Nov 15 21:37:01 2016] keep_learning, I think it's provable [Tue Nov 15 21:37:45 2016] rrika: Any point on how to proceed [Tue Nov 15 21:38:10 2016] ha, I was going to say I felt like it wasn't [Tue Nov 15 21:38:17 2016] I'm trying to do it by induction on cand_all, somehow [Tue Nov 15 21:38:19 2016] if you can recurse down cand_all and show that you can't reach the end without having found a matching candidate (because you have cand_fin) you can show that "forall c: cand, p c > 0" is convertable to a chain of ands and conversely [Tue Nov 15 21:38:23 2016] maybe I haven't thought this throuhg [Tue Nov 15 21:38:28 2016] * starts emacs to prototype [Tue Nov 15 21:38:40 2016] but I'm not convinced yet that this is provable either :) [Tue Nov 15 21:39:02 2016] (note that cand_fin is in Prop by the way, which doesn't help) [Tue Nov 15 21:39:12 2016] why is cand_all relevant? [Tue Nov 15 21:39:13 2016] okay, okay, consider it unprovable until I know more [Tue Nov 15 21:39:34 2016] Ptival, it is finite [Tue Nov 15 21:39:35 2016] Ptival: it is supposed to contain every cand there is [Tue Nov 15 21:39:37 2016] it seems to me this just says "for any function from an arbitrary type to nat, I can decide whether that function always return strictly positive" [Tue Nov 15 21:39:50 2016] from an arbitrary finite type to nat [Tue Nov 15 21:40:06 2016] oh, didn't see that [Tue Nov 15 21:40:14 2016] ok that seems provable then :) [Tue Nov 15 21:54:43 2016] Ok, can confirm [Tue Nov 15 21:55:00 2016] Hint: I first proved the following lemma: [Tue Nov 15 21:55:13 2016] forall (b : ballot) (l : list cand), {forall c : cand, In c l -> b c > 0} + {~ forall c : cand, In c l -> b c > 0} [Tue Nov 15 21:57:14 2016] Cypi: Thank you. [Tue Nov 15 21:57:53 2016] and instantiating l with cand_all in this lemma ? [Tue Nov 15 21:58:01 2016] yes [Tue Nov 15 21:58:28 2016] Cypi: Thanks again [Tue Nov 15 22:03:50 2016] ugh, I'm twenty lines of helper theorems in and not near yet [Tue Nov 15 22:10:08 2016] rrika: and I have proved forall b : ballot, {ballot_valid b} + {~ballot_valid b}. assuming forall b : ballot, {ballot_valid b} + {~ballot_valid b}. [Tue Nov 15 22:10:39 2016] did you just paste the same thing twice? [Tue Nov 15 22:10:48 2016] rrika: Yeah [Tue Nov 15 22:11:01 2016] Now just apply any fixpoint combinator! [Tue Nov 15 22:11:11 2016] proved forall b : ballot, {ballot_valid b} + {~ballot_valid b}. assuming forall (b : ballot) (l : list cand), {forall c : cand, In c l -> b c > 0} + {~ forall c : cand, In c l -> b c > 0}. [Tue Nov 15 22:16:31 2016] Cypi: https://gist.github.com/mukeshtiwari/8aa739f48bd993b573c2ec6898ba8423 [Tue Nov 15 22:17:32 2016] Cypi: Any hint for this goal [Tue Nov 15 22:47:40 2016] rrika: Did you finish the proof. I am stuck with c = a case [Tue Nov 15 22:48:00 2016] I got as far as you did, using Cypi's hint, now back to fixing my own proof [Tue Nov 15 22:48:17 2016] I used a slightly modified version of Cypi's lemma. [Tue Nov 15 22:48:24 2016] forall (b : ballot) (l := cand_all), {forall c : cand, In c l -> b c > 0} + {~ forall c : cand, In c l -> b c > 0} [Tue Nov 15 22:48:34 2016] maybe that's a bad idea, idk [Tue Nov 15 22:51:43 2016] Now only Cypi can tell us about the proof. [Tue Nov 15 23:24:06 2016] rrika: I guess I am only stuck with c = a https://gist.github.com/mukeshtiwari/e4f958dff0b8609404f740f51abb1d7c [Tue Nov 15 23:30:01 2016] hi guys [Tue Nov 15 23:30:58 2016] I'll need more definitions to try this here [Tue Nov 15 23:31:06 2016] johnw, challenge of the day: I am trying to prove this https://gist.github.com/mukeshtiwari/6eb4267771c444efff6a0321159e353f [Tue Nov 15 23:35:00 2016] johnw: We have proof of valid_or_invalid_ballot : forall b : ballot, {ballot_valid b} + {~ballot_valid b}. assuming forall (b : ballot) (l : list cand), {forall c : cand, In c l -> b c > 0} + {~(forall c : cand, In c l -> b c > 0)}. [Tue Nov 15 23:35:24 2016] but stuck with forall (b : ballot) (l : list cand), {forall c : cand, In c l -> b c > 0} + {~(forall c : cand, In c l -> b c > 0)}. :) [Tue Nov 15 23:38:30 2016] I don't think this is provable [Tue Nov 15 23:38:51 2016] i've been trying to prove the ceval_deterministic theorem from Imp.BreakImp on Software Foundations for a couple of weeks now. [Tue Nov 15 23:39:22 2016] can anyone give me hints on it? i can post details but it depends on quite a few definitions. [Tue Nov 15 23:39:52 2016] I can take a look at where you're stuck [Tue Nov 15 23:39:56 2016] sure, sec [Tue Nov 15 23:40:02 2016] keep_learning: there isn't enough information to prove this, from what I can see [Tue Nov 15 23:41:28 2016] Thanks johnw, but could you please elaborate bit more. [Tue Nov 15 23:41:28 2016] it's saying that either every candidate had at least one vote, or no candidates had any votes? Is that what ballot means? [Tue Nov 15 23:41:54 2016] ballot is a function from finite type to natural number [Tue Nov 15 23:42:04 2016] This is my current script so far. [Tue Nov 15 23:42:05 2016] https://paste.debian.net/896080/ [Tue Nov 15 23:42:20 2016] ah [Tue Nov 15 23:42:48 2016] i'm stuck on the induction, when it takes place over WHILE b DO c END. [Tue Nov 15 23:43:27 2016] i don't know if I can evaluate SF up to this point... [Tue Nov 15 23:43:30 2016] i'll try [Tue Nov 15 23:43:46 2016] I can paste the judgement. [Tue Nov 15 23:44:12 2016] oh, I got there [Tue Nov 15 23:44:46 2016] we must have differences, though, your proof script breaks for me about 12 lines in [Tue Nov 15 23:44:51 2016] i'm not sure induction on that is the way to do it but it's the one that came to mind. [Tue Nov 15 23:45:06 2016] hmm odd [Tue Nov 15 23:45:12 2016] I'm using Coq 8.5pl3 [Tue Nov 15 23:45:23 2016] ah, i'm on pl2 [Tue Nov 15 23:45:41 2016] can a single patch level break things much? [Tue Nov 15 23:45:52 2016] so... [Tue Nov 15 23:45:57 2016] i just solved it in one-line [Tue Nov 15 23:46:03 2016] loool [Tue Nov 15 23:46:15 2016] presumably other than Admitted ;-) [Tue Nov 15 23:46:18 2016] yeah [Tue Nov 15 23:46:31 2016] so, maybe you're overthinking it [Tue Nov 15 23:46:34 2016] hmm so any hints? [Tue Nov 15 23:46:50 2016] sure, the same tactic can several every sub goal after inducting and splitting [Tue Nov 15 23:46:55 2016] well, same set of tactics [Tue Nov 15 23:47:03 2016] total script is 52 characters [Tue Nov 15 23:47:11 2016] lol i can't believe that. [Tue Nov 15 23:47:12 2016] and I don't think I'm using anything fancy, aside from "auto" [Tue Nov 15 23:47:32 2016] oh, 59 chars, I forget one thing [Tue Nov 15 23:47:34 2016] * still very noobish, clearly. [Tue Nov 15 23:47:44 2016] keep at it [Tue Nov 15 23:47:53 2016] my first real proof took me literally 40 man hours [Tue Nov 15 23:48:11 2016] then, 2 years later I ended up doing the same proof in just a few minutes, and it occurred to me, "Hey, what a minute, this is that same proof!!!" [Tue Nov 15 23:48:18 2016] heh [Tue Nov 15 23:48:29 2016] i noticed that with some of teh miniproofs like plus_comm [Tue Nov 15 23:49:56 2016] one key to all of this is that everything boils down to pretty much three operations: introducing data through constructors, eliminating data through destructors, and function calls. The real trick, of course, is know how to formulate types to say what you really want them to say, and which functions to call. :) [Tue Nov 15 23:50:37 2016] every tactic is just a shorthand for those things [Tue Nov 15 23:50:51 2016] so when you say in one line you mean from the start of the proof or from where my script left of? [Tue Nov 15 23:51:03 2016] or in other words should i try to continue banging on my script or start from zero? [Tue Nov 15 23:51:08 2016] i mean, from "Proof. <59 chars>. Qed." [Tue Nov 15 23:51:27 2016] damn [Tue Nov 15 23:51:40 2016] you had started out right [Tue Nov 15 23:52:03 2016] I think some of your induction hypothesis applications might not have the right arguments [Tue Nov 15 23:52:27 2016] and usually all rewriting by equalities can be replaced with "subst" [Tue Nov 15 23:52:41 2016] we've now said in this channel every tactic that is needed :) [Tue Nov 15 23:52:47 2016] and even some that aren't [Tue Nov 15 23:56:51 2016] johnw: https://gist.github.com/mukeshtiwari/6eb4267771c444efff6a0321159e353f. I have added the the proof so far I have completed [Tue Nov 15 23:57:37 2016] I am just stuck at one point where a = c in context [Tue Nov 15 23:57:58 2016] Going out and will be back in 1 hour [Tue Nov 15 23:58:54 2016] i've tried induction c; inversion H; inversion H0; auto. but that's not quite it. [Tue Nov 15 23:59:37 2016] maybe need to induce on on of the hypotheses. [Wed Nov 16 00:01:20 2016] you're just missing one tactic there [Wed Nov 16 00:01:29 2016] no, two [Wed Nov 16 00:01:37 2016] the 4 you have are right, and in the right order [Wed Nov 16 00:01:40 2016] just insert 2 more and you're done [Wed Nov 16 00:01:50 2016] now, to understand WHY and where, that is the thing :) [Wed Nov 16 00:04:12 2016] lol [Wed Nov 16 00:06:20 2016] ok, i do need split before auto. [Wed Nov 16 00:06:26 2016] but other than that... [Wed Nov 16 00:16:23 2016] hint: subst [Wed Nov 16 00:16:54 2016] alternatively (and SF may not have covered this yet), just "congruence" [Wed Nov 16 00:17:07 2016] congruence says "solve this equation using knowledge of all equalities in the context" [Wed Nov 16 00:19:57 2016] hmm subst. [Wed Nov 16 00:20:44 2016] nah, i can't do this.... urgh. [Wed Nov 16 00:21:02 2016] yeah, congruence hasn't been shown yet. [Wed Nov 16 00:25:40 2016] induction c; split; inversion H; inversion H0; subst; auto. [Wed Nov 16 00:25:50 2016] the split could move anywhere [Wed Nov 16 00:26:18 2016] no, 23 sugoals left. [Wed Nov 16 00:26:25 2016] interesting [Wed Nov 16 00:26:31 2016] I wonder why it solves it here? [Wed Nov 16 00:26:54 2016] I just have: Proof. induction c; split; inversion H; inversion H0; congruence. Qed. [Wed Nov 16 00:27:07 2016] for the theorem on line 1674, [ceval_deterministic] [Wed Nov 16 00:27:25 2016] i'll try congruence. [Wed Nov 16 00:28:32 2016] is this the goal of the theorem? forall (c : com) (st st1 st2 : state) (s1 s2 : status), c / st \\ s1 / st1 -> c / st \\ s2 / st2 -> st1 = st2 /\ s1 = s2 [Wed Nov 16 00:30:29 2016] https://gist.github.com/jwiegley/80b39aefca77e7d28da14e389f0f9958 [Wed Nov 16 00:31:27 2016] keep_learning, I did it, I think [Wed Nov 16 00:31:36 2016] wtf that is weird. [Wed Nov 16 00:32:30 2016] i gues the terms mustn't have the same definitions somehow. [Wed Nov 16 00:32:37 2016] * sighs [Wed Nov 16 00:33:22 2016] keep_learning, https://gist.github.com/rrika/c0b49bc88bfc1ffbc293492f0aa43514 [Wed Nov 16 00:33:41 2016] with congruence it tells me tried to save incomplete proof. [Wed Nov 16 00:39:22 2016] keep_learning, where you do "destruct IHz. left." instead of left I do "destruct (le_gt_dec (b a) 0)." and go into right and the left depending on that. [Wed Nov 16 01:17:50 2016] rrika: Thank you. [Wed Nov 16 01:18:35 2016] johnw: I was tried this proof twice https://github.com/mukeshtiwari/Coq/blob/master/software-foundation-8.5/Imp.v#L737 [Wed Nov 16 01:19:04 2016] still not able to finish it, and your proof is just a line :) [Wed Nov 16 01:19:22 2016] keep_learning, I tried shortening my proof a bit. [Wed Nov 16 01:20:15 2016] randomly added "firstorder." and "auto." and looked at how much it helped :P [Wed Nov 16 01:21:52 2016] rrika: I do that very often :) [Wed Nov 16 01:22:05 2016] Use it and see if it is working or not [Wed Nov 16 01:46:14 2016] rrika: nicely done [Wed Nov 16 01:46:41 2016] ^_^ thanks [Wed Nov 16 01:53:29 2016] rrika: https://gist.github.com/jwiegley/cf02c7380be2ee45bf9fbdcfded79a8e [Wed Nov 16 01:53:47 2016] it never occurred to me to drop the In down into the two sides; I'll remember that trick [Wed Nov 16 01:53:56 2016] of course you'd golf it [Wed Nov 16 01:54:04 2016] it's all I can do at this point :) [Wed Nov 16 01:54:43 2016] consider it an offer of admiration :) [Wed Nov 16 01:54:45 2016] johnw, the funny thing is Cypi, looked at it for five minutes came up with that, left a cryptic hint and left. I and keep_learning failed to reproduce it so I tried all kinds of approaches, only to see that it ended up being what Cypi described [Wed Nov 16 01:57:11 2016] what does "cut" do? [Wed Nov 16 01:57:17 2016] johnw - a bit at end of tethre with this ceval_deterministic thing, could i show you my definition of ceval to see if it's the same you have? [Wed Nov 16 01:57:29 2016] it says: prove that you can solve the goal assuming X, then prove X [Wed Nov 16 01:57:55 2016] it's the reverse order of using assert [Wed Nov 16 01:58:22 2016] ooh, nice [Wed Nov 16 01:58:26 2016] modulus: sure [Wed Nov 16 01:59:07 2016] firstorder sure takes long [Wed Nov 16 01:59:17 2016] on my slow cpu I can see the difference clearly [Wed Nov 16 02:02:40 2016] https://paste.debian.net/896102/ [Wed Nov 16 02:02:47 2016] ok, do your defs look like this? [Wed Nov 16 02:02:53 2016] yeah, firstorder is always my last choice [Wed Nov 16 02:02:58 2016] anyway, your version is very nice to read. [Wed Nov 16 02:03:10 2016] bedtime [Wed Nov 16 02:03:36 2016] I have a fast version now [Wed Nov 16 02:03:48 2016] https://gist.github.com/jwiegley/cf02c7380be2ee45bf9fbdcfded79a8e [Wed Nov 16 02:04:41 2016] is auto or intuition faster? [Wed Nov 16 02:04:51 2016] than firstorder? always [Wed Nov 16 02:05:20 2016] modulus: ah, that was it! [Wed Nov 16 02:05:26 2016] modulus: forget everything I told you; trying now [Wed Nov 16 02:05:46 2016] hah [Wed Nov 16 02:05:46 2016] I have 27 goals now too [Wed Nov 16 02:05:55 2016] lol that starts to make sense :-) [Wed Nov 16 02:06:04 2016] well, 15 if I try congruence [Wed Nov 16 02:06:43 2016] still a good bunch left. [Wed Nov 16 02:10:25 2016] is there anything that explains coq's assortment of tactics like auto, omega, congruence, firstorder, nsatz for mere mortals like me? [Wed Nov 16 02:37:13 2016] modulus: I don't know what to do with these WHILE_DO_END blocks either [Wed Nov 16 02:37:26 2016] reuben364: I don't know of any really good resource, unfortunately [Wed Nov 16 02:38:05 2016] yeah, i suspect the general strategy is wrong, of inducti on c. [Wed Nov 16 02:38:15 2016] unfortunately i haven't come up with anything better. [Wed Nov 16 02:38:29 2016] johnw: okay, thanks. [Wed Nov 16 02:57:41 2016] modulus: well, I'm kind of close [Wed Nov 16 02:57:56 2016] modulus: maybe you know what to do now [Wed Nov 16 02:58:17 2016] modulus: https://gist.github.com/jwiegley/07352c4e464f5bbd78650fa9ccf0ede9 [Wed Nov 16 03:37:38 2016] johnw - thanks! [Wed Nov 16 03:38:55 2016] lol, no; i don't know most of those tactics. i've no idea how to continue it :-) [Wed Nov 16 03:39:22 2016] the goal at that admit is pretty simple [Wed Nov 16 03:39:33 2016] I feel like we need to know something more about WHILE [Wed Nov 16 03:40:00 2016] that if WHILE X / st \\ SContinue / st1 and WHILE X / st \\ SContinue / st2, then st1 = st2 [Wed Nov 16 03:40:15 2016] that's all that's left, but even as a separate theorem I couldn't find the way to break it apart [Wed Nov 16 03:40:49 2016] yeah, to be quite honest i'm not sure it is true [Wed Nov 16 03:41:48 2016] at least i get feeling that it could be different number of rounds of the while [Wed Nov 16 03:42:03 2016] it's the same predicate, and the same body [Wed Nov 16 03:43:01 2016] hmm yes, it ought to be true. [Wed Nov 16 03:45:08 2016] SF imo has some exercises that are not really well balanced. [Wed Nov 16 03:45:24 2016] the previous 2-3 exercises on ceval i did trivially, and this one is basically impossible for me. [Wed Nov 16 03:56:06 2016] yeah, there's some trick here we're missing [Wed Nov 16 03:56:22 2016] anyway, that's it for me; good night! [Wed Nov 16 06:31:47 2016] johnw: if you want to do the exact reverse of assert, there is "enough" [Wed Nov 16 06:31:59 2016] (this will introduce the new hypothesis in the goal, whereas cut doesn't) [Wed Nov 16 08:37:40 2016] Are goals like "False_rect … = …" usually provable? [Wed Nov 16 08:54:52 2016] If False_rect is fully applied, then sure: the second argument to False_rect has type False [Wed Nov 16 09:00:22 2016] Cypi, what kind of tactic would help me with this [Wed Nov 16 09:01:30 2016] If you have "False_rect P t = …", then "elim t" should do it [Wed Nov 16 09:01:37 2016] thank you [Wed Nov 16 09:01:40 2016] (or "destruct" if you prefer) [Wed Nov 16 09:18:56 2016] so if there's any term inside the goal which I know can't have a value I can use destruct to dismiss the goal? [Wed Nov 16 09:19:01 2016] (or elim) [Wed Nov 16 09:19:57 2016] goal: f (is_odd 2) (…) = g … [Wed Nov 16 09:20:03 2016] elim (is_odd 2) [Wed Nov 16 09:20:05 2016] ? [Wed Nov 16 09:21:01 2016] yes [Wed Nov 16 09:21:14 2016] well, if Coq can determine that it's empty indeed [Wed Nov 16 09:23:28 2016] if it can't can I have it give me "supposedly_emtpy |- False" as goal? [Wed Nov 16 09:27:45 2016] You can always do something like "pose proof (supposedly_empty); exfalso" [Wed Nov 16 09:31:02 2016] oh, right, I don't even need to interact with the goal [Wed Nov 16 10:14:39 2016] To implement coq in set theory, do we really need inaccessible cardinals, or would something like feferman's set theory ZFC/S which has some reflection principle but is conservative over ZFC suffice? [Wed Nov 16 10:55:46 2016] GoGi: I think there hasn't been much investigation into this sort of things since: http://www.lix.polytechnique.fr/~werner/publis/tacs97.pdf . None that I'm aware of at least. [Wed Nov 16 10:56:20 2016] Mmm… there's Bruno Barras's work. [Wed Nov 16 10:57:08 2016] http://www.lix.polytechnique.fr/~barras/proofs/sets/index.html [Wed Nov 16 10:57:20 2016] It uses IZF but probably inaccessible cardinals as well. [Wed Nov 16 11:02:59 2016] Also, http://www.lix.polytechnique.fr/~barras/habilitation/ for the inductive types [Wed Nov 16 11:27:08 2016] Cypi: nice! Never even heard of 'enough' [Wed Nov 16 12:42:03 2016] in 5.4.2, the habilitation you refered to says [Wed Nov 16 12:42:06 2016] We have chosen to model the universes of ECC as Grothendieck universes, which [Wed Nov 16 12:42:06 2016] are the intuitionistic counterparts of inaccessible cardinals. It is known that it is not [Wed Nov 16 12:42:06 2016] necessary to resort to such powerful axioms, since Luo’s proof of strong normalization [Wed Nov 16 12:42:06 2016] proof of ECC [35], based on quasi-normalization, is expressed within ZF. [Wed Nov 16 12:42:17 2016] what does this mean? [Wed Nov 16 13:04:33 2016] GoGi: basically that proving the consistency/termination of calculus of construction + universes (ECC) doesn't require inaccessible cardinals. That being said, Coq has inductive types with strong elimination, this may require more (though Barras seems to believe it). I wouldn't be surpris in Luo's model is not very natural. But it would be best to read his proof. [Wed Nov 16 19:21:54 2016] so, what's the general approach to solving something where dependent types prevent you from doing a destruct/induction? [Wed Nov 16 19:22:13 2016] w/o using Program [Wed Nov 16 19:34:26 2016] Ptival: https://homes.cs.washington.edu/~jrw12/dep-destruct.html [Wed Nov 16 19:35:54 2016] Ptival, like what? [Wed Nov 16 19:37:25 2016] rrika: I am trying to prove a bunch of properties about some encoding of extensible records, and most proofs end up in a place where I'm stuck because of dependent types [Wed Nov 16 19:38:13 2016] Ptival: I don't know if there is a fully general strategy. I have memorized a few tricks and I just blindly apply them until I get it or get frustrated or convince myself it's not provable [Wed Nov 16 19:38:33 2016] if you can share code I'd be happy to try my tricks on it :) [Wed Nov 16 19:40:02 2016] jrw: are most of your tricks writing a dependent pattern match using refine? [Wed Nov 16 19:40:28 2016] there's that [Wed Nov 16 19:40:32 2016] there's generalizing stuff that seems like it can be generalized [Wed Nov 16 19:40:40 2016] yeah :) [Wed Nov 16 19:40:46 2016] ok I think I have the same tricks haha [Wed Nov 16 19:40:48 2016] there's pulling out a subterm and working on it independently from the big term [Wed Nov 16 19:40:59 2016] but it always feels like I'm doing something specific and not seeing the pattern :) [Wed Nov 16 19:41:04 2016] yeah [Wed Nov 16 19:41:44 2016] basically massaging things to remove the constraint on the type index [Wed Nov 16 19:41:55 2016] yeah [Wed Nov 16 19:42:07 2016] "oh you have this dependent problem. what if you made it... less dependent?" [Wed Nov 16 19:43:23 2016] jrw: trying to prove http://paste.awesom.eu/7mRl where Records is coq-extensible-records [Wed Nov 16 19:44:40 2016] cool, I'll take a look. are these records what you guys are using to model states in the TLA implementation as well? [Wed Nov 16 19:47:32 2016] we're trying to switch to those yes, in the current implementation we use "state: string -> R", but it doesn't give us nice composability [Wed Nov 16 19:48:46 2016] right, makes sense. [Wed Nov 16 19:50:11 2016] https://github.com/UCSD-PL/kraken/commit/7601bc <- back when I had to write crazy refines, I would factor them out and name them "ridiculous_lemma_n" [Wed Nov 16 19:50:42 2016] hahahaha [Wed Nov 16 19:50:59 2016] ll 1836+ have an insane refine [Wed Nov 16 19:51:10 2016] that's how I learned the hard way to not bite more than I could chew :( [Wed Nov 16 19:51:23 2016] best refine [Wed Nov 16 19:58:41 2016] sigh I'm getting a bunch of weird errors that make me think I'm hitting coq bugs. [Wed Nov 16 19:58:56 2016] Ptival: what version of coq should I use with this? (or should it not matter?) [Wed Nov 16 20:17:24 2016] Ptival: so I tried proving it using `dependent destruct` just to get some intuition for how it should go, and I finished it, but can't get it to Qed because of a "block" artifact from the internals of Program. I've never seen this before, but I wonder if this is a bad sign for making the proof go through event without Program. ("too much dependency" or something...) [Wed Nov 16 21:18:17 2016] I import a library which defines a notation (without putting it in any scope). Is there any way I can get rid of it? [Wed Nov 16 21:19:29 2016] Well, I guess I can define a new one which overrides it, that’s probably good enough… [Wed Nov 16 22:18:21 2016] jrw: :s [Wed Nov 16 22:18:36 2016] let me give it a try too :3 [Wed Nov 16 22:19:00 2016] maybe the pmr <> pmw hypothesis can be expressed in a different way [Wed Nov 16 22:19:24 2016] I just want to know that the updated field is not the field being read [Wed Nov 16 23:14:21 2016] Ptival: can you get decidable equality on `member` and then have a general lemma that uses an `if` expression to describe write-over-read? [Thu Nov 17 01:02:18 2016] does AC_fun here https://coq.inria.fr/library/Coq.Logic.ChoiceFacts.html#FunctionalChoice_on hold for finite A? [Thu Nov 17 01:05:13 2016] jrw: according to gmalecha, I should not use equality and instead write a discriminating function [Thu Nov 17 02:03:58 2016] ok, I am thinking AC probably does hold for finite sets, but trying to derive it has been difficult for me (Coq newbie): http://lpaste.net/1637040481521106944 [Thu Nov 17 02:04:16 2016] I admitted computation rules for fin_case from https://homes.cs.washington.edu/~jrw12/dep-destruct.html :( [Thu Nov 17 02:23:26 2016] jrw: if there is a "block" remaining and the Qed doesn't go through, I believe it's a bug. If you wouldn't mind reporting it, that would be nice :) [Thu Nov 17 02:24:19 2016] (I mean, if a "block" appears in the context at some point it's a bug, or if the Qed doesn't go through it's a bug too) [Thu Nov 17 02:28:53 2016] tomjack: the first step is to replace the two previous "Qed" by "Defined" [Thu Nov 17 02:29:16 2016] then you'll discover the joy of working with equalities [Thu Nov 17 02:29:53 2016] at some point you'll need to prove stuff like Eqdep_dec.eq_rect_eq_dec PeanoNat.Nat.eq_dec Fin F0 eq_refl = eq_refl, which is provable [Thu Nov 17 02:30:04 2016] sadly I don't have time right now to give a hint or something :s [Thu Nov 17 02:33:08 2016] thanks! no problem :) [Thu Nov 17 02:34:00 2016] I had hoped that fin_case could be avoided but didn't know it would cause this much ..joy [Thu Nov 17 03:17:58 2016] it seems much easier with Fin defined as a Fixpoint with sum unit [Thu Nov 17 12:16:16 2016] tomjack : alright, see http://lpaste.net/8088061667688054784 for an axiom-less proof [Thu Nov 17 12:16:30 2016] it's not veeery pretty I would say, though [Thu Nov 17 12:23:32 2016] (It's still sort of in beta, but there is a plugin called Equations that actually perform this kind of stuff way better in most cases. In this case, the proof could be this: http://lpaste.net/1501733622829285376 (notice the "depelim x", which is similar to "dependent destruct x", but can be configured not to use heterogeneous equality)) [Thu Nov 17 12:29:08 2016] ah, wow, thank you! I will try to understand that :). I ended up abandoning the Inductive Fin: http://lpaste.net/3292157475368730624 [Thu Nov 17 17:17:41 2016] when working with tactics how do I introduce a stream like `Let inf_str := Cons x inf_str` ? [Thu Nov 17 17:22:40 2016] nvm, I used a CoFixpoint definition [Thu Nov 17 17:22:50 2016] and then `pose proof mk_inf_str x as inf_str.` [Thu Nov 17 17:25:26 2016] "let inf_str := constr:(cofix str : Stream A := Cons A x str) in idtac inf_str." to do it inline [Thu Nov 17 17:25:34 2016] (the point is the cofix construction) [Fri Nov 18 00:10:10 2016] Hello everyone [Fri Nov 18 00:10:21 2016] https://gist.github.com/mukeshtiwari/191e94a9f4b4a8ff800341df3c99acb6 [Fri Nov 18 00:10:32 2016] Why omega is not able to solve this goal [Sat Nov 19 06:03:39 2016] Hi, does coq support "parametric types", and if so: how do i use it? Eg. how do i define "map", "fold" and other common operators to work on lists? [Sat Nov 19 06:23:18 2016] pete_8: Fixpoint map (A B : Type) (f : A -> B) (l : list A) : list B := match l with | nil => nil | cons x l' => cons (f x) (map A B f l') end [Sat Nov 19 06:23:26 2016] this kind of things [Sat Nov 19 06:23:56 2016] See the https://www.cis.upenn.edu/~bcpierce/sf/current/Poly.html chapter of Software Foundations for more [Sat Nov 19 06:26:48 2016] Aha, thanks a bunch! [Sat Nov 19 12:12:58 2016] I've got "H : ~ ~ ((a -> b) \/ a) /\ ~ ((b -> a) \/ b)" as an assumption. How can I reduce the double negation? [Sat Nov 19 12:13:37 2016] I tried "assert (((a -> b) \/ a) /\ ~ ((b -> a) \/ b)) as C; apply NNPP; exact H", but that gives me an error saying that their types are not equal. The latter one has more parentheses. [Sat Nov 19 12:13:44 2016] Shouldn't they be ignored anyway? [Sat Nov 19 12:15:48 2016] what's NNPP? [Sat Nov 19 12:16:08 2016] maybe stupid comment but you can't generally eliminate double negation, but if it is decidable you can. [Sat Nov 19 12:16:37 2016] That's the elimination of negation. [Sat Nov 19 12:16:51 2016] I use classical logic, so A or ~A. [Sat Nov 19 12:16:57 2016] ahh. [Sat Nov 19 12:17:52 2016] I thought using "Require Import Classical_Prop." is sufficient for this property to appear. [Sat Nov 19 12:18:22 2016] i've not done uch with classical logic in coq so can't say. [Sat Nov 19 12:18:30 2016] zfm, use "unfold not in *." to see the problem better [Sat Nov 19 12:19:09 2016] the double neg is in the left branch of /\ but you're applying it to the whole thing [Sat Nov 19 12:19:30 2016] Where exactly should I put unfold not in *.? [Sat Nov 19 12:19:39 2016] "unfold not in *." after the Require above gives me a syntax error [Sat Nov 19 12:19:45 2016] apply NNPP. [Sat Nov 19 12:19:52 2016] ah never mind in the proof section [Sat Nov 19 12:20:03 2016] I split up your assert/apply/exact into three tactics with "." [Sat Nov 19 12:23:08 2016] Ah thanks [Sat Nov 19 12:23:25 2016] I was going to try "replace (~ ~ ((a -> b) \/ a)) with ((a -> b) \/ a) in H." [Sat Nov 19 12:23:31 2016] but that requires a slightly different axiom [Sat Nov 19 12:23:38 2016] not ~~P→P but ~~P=P [Sat Nov 19 12:23:42 2016] so probably not a good way [Sat Nov 19 12:23:56 2016] But now I've got a related problem. "H0 : ~ ~ ((a -> b) \/ a). assert ((a->b) \/ a) as C. exact H0." also gives me a type error [Sat Nov 19 12:24:00 2016] where H0 is now another assumption [Sat Nov 19 12:25:05 2016] Actually I am supposed to hand in a Fitch proof, which I try to check in Coq. [Sat Nov 19 12:25:14 2016] you need to do "apply NNPP" before doing exact H0. [Sat Nov 19 12:26:07 2016] Ah works! Thanks [Sat Nov 19 19:18:01 2016] is there a notion of, like [Sat Nov 19 19:19:03 2016] if there's a theorem, and you can write a program that fulfills the theorem, but you can only prove classically that the program will definitely halt [Sat Nov 19 19:19:17 2016] so it's not actually "constructively provable" [Sat Nov 19 19:23:06 2016] I read that as "is there a notation of like" so I thought: [Sat Nov 19 19:23:07 2016] Notation "A ♥ B" := (like A B) (at level 36, left associativity). [Sat Nov 19 19:23:32 2016] hah [Sat Nov 19 19:23:41 2016] why 36 :) [Sat Nov 19 19:23:54 2016] between unary minus and multiplication [Sat Nov 19 19:24:01 2016] because love binds even stronger than multiplication [Sat Nov 19 19:24:03 2016] obv [Sat Nov 19 19:24:43 2016] as for the constructively provable thing [Sat Nov 19 19:24:49 2016] there's "Print Assumptions x." to list axioms IIRC [Sat Nov 19 19:25:02 2016] so you can manually check if something used classical logic [Sat Nov 19 19:26:38 2016] But a proof that something can't be proven without a certain axiom… I don't know if you can do it within coq. [Sat Nov 19 19:29:42 2016] That is, without reasoning over coq asts instead of using the native objects. [Sat Nov 19 19:29:53 2016] Someone more knowledgeable than me answer this. [Sat Nov 19 19:31:16 2016] benzrf, though, if you have a program, aren't you dealing with types with decidable equality most of the time anyway? [Sat Nov 19 19:31:33 2016] i dont see how thats relevant.? [Sat Nov 19 19:31:54 2016] maybe I misunderstand [Sat Nov 19 19:32:54 2016] I'm curious about the specific thing that is only classically provable. [Sat Nov 19 19:40:01 2016] the fact that the algo in question halts [Sat Nov 19 19:40:29 2016] like - in an inconsistent version of CoC with unbounded recursion - [Sat Nov 19 19:40:47 2016] i can prove proposition X, but in particular, i can classically prove that my proof always does halt [Sat Nov 19 19:40:57 2016] then maybe i can't take that proof and bring it back to normal CoC, even though it always halts [Sat Nov 19 19:41:05 2016] because i can't intuitionistically prove that it will halt [Sat Nov 19 19:44:45 2016] maybe you have some relation on which you'd like to do well-founded induction, but you cannot constructively prove that the relation is well-founded? so you can postulate or hypothesize its well-foundedness or enough classical axioms to prove its well-foundedness [Sat Nov 19 19:49:29 2016] Axiom eq_wf : well_founded (@eq nat). [Sat Nov 19 19:49:29 2016] Definition this_hangs_coq := @Fix nat eq eq_wf (fun a => nat) (fun (x:nat) (rec : forall (y:nat), R y x -> nat) => (S (rec x (CR x x))) 0. [Sat Nov 19 19:54:33 2016] hmm, yes, the program will not run even if the relation really is well-founded? [Sat Nov 19 23:09:49 2016] fwiw, i ask because i read about bar induction [Sat Nov 19 23:10:33 2016] i tried writing down the types in Idris and implementing them, and figured out that i can write something which will necessarily terminate but which im not sure i can prove termiantes [Sat Nov 19 23:10:38 2016] without proof by contradiction [Sun Nov 20 07:59:43 2016] Notation "x |> f" := (apply f x) (at level 50, left associativity). [Sun Nov 20 07:59:49 2016] Definition a := s1 |> f |> map g |> h. [Sun Nov 20 07:59:56 2016] This works, but why? [Sun Nov 20 08:00:06 2016] For example, naively starting to place parenthesis I could end up with: [Sun Nov 20 08:00:13 2016] ((s1 |> f) |> map) g |> h [Sun Nov 20 08:00:37 2016] Which is wrong. What am I not getting? [Sun Nov 20 08:00:54 2016] Why is it wrong? [Sun Nov 20 08:01:19 2016] g is the first argument to map, the thing coming from the pipe is the second [Sun Nov 20 08:01:22 2016] oh, nevermind, I missed the "map g" thing [Sun Nov 20 08:01:35 2016] Probably that simple application has a higer priority [Sun Nov 20 08:01:55 2016] So you get (map g) first and then it's easy [Sun Nov 20 08:03:56 2016] Aha, seems plausible. [Sun Nov 20 08:08:32 2016] Is there some way to find out for sure? I did not manage to make Google answer this... Perhaps you have some keywords or document name that could help? :) [Sun Nov 20 08:09:38 2016] not especially, sorry :/ [Sun Nov 20 08:10:10 2016] np, just found a list :) [Mon Nov 21 00:50:20 2016] how to prove "(if Z_lt_dec i 0 then Vundef else y) = y" with the assumption "H : i >= 0"? [Mon Nov 21 00:50:47 2016] I tried using elim H, but it doesn't seem to be the correct way of doing it [Mon Nov 21 00:52:08 2016] with "unfold Z_le_dec. elim H.", I get a new goal "(i ?= 0) = Lt" [Mon Nov 21 00:53:41 2016] hmm...shouldn't use elim [Mon Nov 21 00:54:28 2016] any ideas on this? [Mon Nov 21 00:55:42 2016] petercommand: "destruct (Z_lt_dec i 0)", and then you'll get one branch which is trivial, and the other which contains a contradiction [Mon Nov 21 00:58:00 2016] Cypi: oh..I see [Mon Nov 21 00:59:52 2016] How do I apply the absurd pattern? [Mon Nov 21 01:01:35 2016] you could do "absurd (i < 0)%Z" [Mon Nov 21 01:02:00 2016] what does the %Z mean? [Mon Nov 21 01:02:18 2016] "parse this expression in the Z scope", you may not need it in your case [Mon Nov 21 01:02:26 2016] so juste "absurd (i < 0)" [Mon Nov 21 01:02:29 2016] ok [Mon Nov 21 01:03:11 2016] not that you have in your context two hypotheses H1 and H2 such that "H1 : P" and "H2 : ~ P", literally. So you can just use the tactic "contradiction", it will figure out what the contradiction is. [Mon Nov 21 01:03:15 2016] note* [Mon Nov 21 01:04:50 2016] hoew does it know that ~ (i >= 0) is (i < 0) ? [Mon Nov 21 01:05:26 2016] I assume it is some sort of search database? [Mon Nov 21 01:05:44 2016] This is just the definitions Z.ge and Z.lt [Mon Nov 21 01:06:18 2016] "Z.ge x y" is "(x ?= y) <> Lt", while "Z.lt x y" is "(x ?= y) = Lt" [Mon Nov 21 01:07:04 2016] oh, I see [Mon Nov 21 01:08:52 2016] thanks! [Mon Nov 21 03:42:15 2016] roconnor__: isn't the Feit-Thompson link wrong? [Mon Nov 21 07:19:27 2016] hi. is there a possibility to define algorithms that have "undefined behavior" if something occurs, and then proving afterwards that these cases will never occur? [Mon Nov 21 07:20:17 2016] for example, if I have formalized arrays and do not want to do a bounds check because I can prove that my access is in-bounds, but I do want to prove this afterwards rather than directly in the function definition, how can I do that? [Mon Nov 21 07:21:46 2016] you could use a function that returns undefined for out of bounds and show that it won't happen. [Mon Nov 21 07:21:56 2016] or an option etc. [Mon Nov 21 07:22:14 2016] modulus: but then that function would have to check whether it is in-bounds [Mon Nov 21 07:22:32 2016] and the function calling it could check whether it returns "undefined" [Mon Nov 21 07:25:11 2016] I guess it depends how you formalized your arrays, and so on your specific example [Mon Nov 21 07:25:33 2016] sometimes it just does not make sense to have an "undefined behavior" easily [Mon Nov 21 07:26:10 2016] Cypi: normally I just have some "n < size a" argument. is it possible to define a function with a placeholder at this point, saying "I will prove that later"? I know refine can do something similar, but refine is part of the function definition. [Mon Nov 21 07:27:07 2016] "prove that later": do you mean that in a proof-writing sense, or an algorithmic sense? For the latter, you could hoist the "n < size a" argument further up [Mon Nov 21 07:27:25 2016] hoist? [Mon Nov 21 07:27:48 2016] I mean, if you need to provide a "n < size a" proof, you can place here some hypothesis H that your function being defined also takes as an argument [Mon Nov 21 07:28:21 2016] but if you meant in a proof-writing sense, you could use Program for instance: it will generate an obligation that you will have to prove later [Mon Nov 21 07:28:37 2016] (but you do need to prove it to be able to define the function fully, still) [Mon Nov 21 07:28:43 2016] (I don't think there is a way around that) [Mon Nov 21 07:30:07 2016] ok [Mon Nov 21 09:35:19 2016] hm. somehow my definition makes coq compute a lot. I defined a Program Fixpoint with a nontrivial measure. I am pretty sure it will not automatically find a proof. Is it possible to tell it not to search for it (I guess this is what it tries to do) but just drop an obligation? [Mon Nov 21 09:40:27 2016] Local Obligation Tactic := idtac. [Mon Nov 21 09:40:30 2016] worked [Mon Nov 21 09:51:48 2016] hm. [Mon Nov 21 09:51:56 2016] why do I have to prove that lt is well_founded? [Mon Nov 21 09:52:55 2016] The usual way of defining a recursive functions based on a measure is to say 1) The measure decreases at each recursive call and 2) It is well-founded [Mon Nov 21 09:53:13 2016] if you do not have 2), you might have infinite decreasing chains in your measure [Mon Nov 21 09:53:40 2016] (but if it is indeed a measure, so going in nat, this should not be a problem) [Mon Nov 21 10:02:00 2016] Cypi: it is a funktion list → nat [Mon Nov 21 10:02:20 2016] Cypi: and for some reason, coq wants me to prove that lt with my function applied is well-founded [Mon Nov 21 10:03:40 2016] not sure why this does not follow from wf_lt [Mon Nov 21 10:03:46 2016] but apparently it doesn't. [Mon Nov 21 10:03:48 2016] or so [Mon Nov 21 10:03:57 2016] It does. If you used MR to apply your function, there is the lemma measure_wf that proves it [Mon Nov 21 10:05:19 2016] (it's in Program.Wf) [Mon Nov 21 10:06:39 2016] ok, seems to work. [Mon Nov 21 10:06:52 2016] but somehow the thing I defined really makes coq crunch. [Mon Nov 21 10:12:16 2016] "Defined." hangs [Mon Nov 21 10:12:35 2016] hmm, strange... Any way to provide some code, or is it too involved? [Mon Nov 21 10:13:15 2016] I'll try [Mon Nov 21 10:17:16 2016] Cypi: http://lpaste.net/7461210550886727680 [Mon Nov 21 10:17:48 2016] Oh, I see [Mon Nov 21 10:18:18 2016] what do you see? [Mon Nov 21 10:18:21 2016] I'm pretty sure omega generates huge terms every time, and since everything is transparent [Mon Nov 21 10:18:35 2016] the final term is possibly quite huge [Mon Nov 21 10:18:46 2016] I used Qed. [Mon Nov 21 10:18:48 2016] it was the same. [Mon Nov 21 10:19:22 2016] the last one warns me that "Error: Obligation should be transparent but was declared opaque." [Mon Nov 21 10:19:27 2016] you're right. (also, just writing "abstract omega" generates a universe inconsistency error, not sure if it's related...) [Mon Nov 21 10:20:11 2016] it doesnt generate one for me … [Mon Nov 21 10:20:14 2016] but defined still hangs [Mon Nov 21 10:20:42 2016] I don't *need* omega at this point, the inequalities are trivial [Mon Nov 21 10:20:46 2016] but it is handy [Mon Nov 21 10:21:44 2016] It's probably not related anyway since it hangs even with Qed [Mon Nov 21 10:21:50 2016] yes [Mon Nov 21 10:22:20 2016] hm. any suggestions? [Mon Nov 21 10:22:26 2016] or should I ask the mailinglist maybe? [Mon Nov 21 10:22:31 2016] ah, I'll try the git version of coq first [Mon Nov 21 10:23:35 2016] I'm trying to tweak it to see if I can make go through a slightly different definition [Mon Nov 21 10:23:51 2016] (but if you want to fetch some more help, don't hesitate, there is no guarantee I'll be able to do it :) ) [Mon Nov 21 10:25:09 2016] I'll wait for you first [Mon Nov 21 10:33:14 2016] I would blame Program... [Mon Nov 21 10:33:42 2016] http://lpaste.net/1981498748445917184 here is a Program-free version [Mon Nov 21 10:33:48 2016] using instead refine and Fix [Mon Nov 21 10:34:13 2016] (and MR to define a relation on SequenceWIthBackRefs) [Mon Nov 21 10:35:09 2016] It may be still worth posting the version with Program somewhere, since it looks like a bug [Mon Nov 21 10:37:36 2016] hm. yes, especially my definition looks more readable. but I first try it in the current git version [Mon Nov 21 10:37:53 2016] (which currently compiles) [Mon Nov 21 10:40:09 2016] Oh, strange. Just doing "simpl" right at the start of the last obligation seems to hang [Mon Nov 21 10:40:35 2016] yes. [Mon Nov 21 10:40:44 2016] even "unfold MR" takes ages. [Mon Nov 21 10:40:48 2016] but terminates. [Mon Nov 21 10:42:05 2016] Looks like the goal is just huge because of the sheer number of arguments it puts in this nested telescope [Mon Nov 21 10:42:12 2016] (even though it only needs one) [Mon Nov 21 10:42:37 2016] [you can display implicit arguments and even disable notations to see how big this type is] [Mon Nov 21 10:43:49 2016] but why does it? [Mon Nov 21 10:44:32 2016] l does not depend on them [Mon Nov 21 10:45:04 2016] neither do the other variables there [Mon Nov 21 10:46:35 2016] I agree... [Mon Nov 21 10:47:06 2016] I'll ask the mailinglist. [Mon Nov 21 10:51:13 2016] Reading the code, looks like there was no effort made to select a subset of the arguments, indeed :o [Mon Nov 21 10:51:18 2016] (or I misunderstand the code) [Mon Nov 21 10:57:19 2016] what is smurf naming? [Mon Nov 21 10:59:17 2016] instead of using some namespace (or even though), prefixing every name with smurf_ and the like [Mon Nov 21 10:59:36 2016] it's a common antipattern [Mon Nov 21 10:59:47 2016] ahhh [Tue Nov 22 02:22:42 2016] im an undergraduate student studying mathematics, and i want to learn about automated theorem proving and proof assistants [Tue Nov 22 02:22:50 2016] basically i read this article: https://en.wikipedia.org/wiki/QED_manifesto [Tue Nov 22 02:22:53 2016] and it looked cool [Tue Nov 22 02:23:01 2016] but i have no experience at all in cs [Tue Nov 22 02:23:17 2016] where do i start? [Tue Nov 22 02:25:27 2016] nathann: I've been very slowly working my way through https://www.cis.upenn.edu/~bcpierce/sf/current/index.html and it seems quite interesting [Tue Nov 22 02:26:24 2016] looking over it i think i should probably go back and read a book on mathematical logic [Tue Nov 22 02:27:06 2016] thx i bookmarked it [Tue Nov 22 02:28:29 2016] I personally wouldn't think you have to know too much. I'm absolute shit at math and I haven't yet gotten into too bad of a corner. [Tue Nov 22 02:30:57 2016] alright [Tue Nov 22 05:34:14 2016] hm. I have two versions of coq. one insists on an argument to Vector.nil (a type argument), the other one does not accept this argument. what can I do? [Tue Nov 22 05:34:21 2016] I use a notation "Vnil" for Vector.nil [Tue Nov 22 05:34:30 2016] can I somehow overload this notation depending on the version? [Tue Nov 22 05:37:38 2016] schoppenhauer: if the problem shows up in patterns, you have three choices: either fiddle with the `Asymetric Patterns` option, make sure that the first argument of `Vector.nil` is implicit (using the `Argument` command), or define `Notation Vnil := (@Vector.nil _)`. If it shows up in expressions as well, only the latter two choices are available. [Tue Nov 22 05:40:19 2016] aspiwack[m]: Hm. I tried Notation Vnil A := (@Vector.nil A), is this correct too? [Tue Nov 22 05:40:22 2016] ah, apparently not [Tue Nov 22 05:40:50 2016] That would be `Notation Vnil := (@Vector.nil)`. [Tue Nov 22 05:41:26 2016] ah ok [Tue Nov 22 05:41:27 2016] Or you could define Vnil as a token, and do `Notation "'Vnil' A" := (@Vector.nil A)`, but I would not advise it. [Tue Nov 22 05:41:34 2016] yes [Tue Nov 22 09:08:59 2016] Hi [Tue Nov 22 09:09:12 2016] Is there a way to print currently available/visible instances? [Tue Nov 22 16:34:42 2016] im thinkin maybe next year ill work thru cpdt for credit~ [Tue Nov 22 16:38:16 2016] benzrf: good idea [Tue Nov 22 16:39:39 2016] but i never got that far in software foundations >w> [Tue Nov 22 16:39:46 2016] does sf work with latest coq [Tue Nov 22 16:40:09 2016] mostly yes [Tue Nov 22 16:40:29 2016] cool [Tue Nov 22 16:40:48 2016] only issue i have noticed is some modules may conflict with coq theories, like lists and basics. [Tue Nov 22 16:40:59 2016] personally i renamed them just in case. [Tue Nov 22 17:17:17 2016] is there a way to start using a notation within a section, but also have it survive the end of the section? [Tue Nov 22 17:18:45 2016] Ptival: not that I know of. I always repeat myself when I want to do that. [Tue Nov 22 17:20:10 2016] jrw: so do you rather (close section, define notation, open similar section) or (define notation, finish section, define similar global notation)? [Tue Nov 22 17:20:48 2016] well honestly what I usually do is decide I don't *really* need the notation inside the section, so I just go without it and define it after ending the section. [Tue Nov 22 17:20:59 2016] if I do feel like I really need it, then I just define it twice [Tue Nov 22 17:21:14 2016] hehe [Tue Nov 22 17:21:17 2016] thought about it [Tue Nov 22 17:21:29 2016] but all those theorems will look so sad without the notation :( [Tue Nov 22 17:21:51 2016] well they'll only look sad in the source, they'll look nice in the output of search about if you have the notation in scope [Tue Nov 22 17:22:40 2016] btw did you figure out that extensible records thing you were working on a while back? [Tue Nov 22 17:23:27 2016] I stopped working on it after I realized there was a bug in coq... (I subitted it and it turned out to be universe related; matthieu fixed it) [Tue Nov 22 17:55:09 2016] cool, yeah I fixed it, but using Program [Tue Nov 22 17:55:54 2016] jrw: https://github.com/dricketts/dL/blob/ext-records/theories/RecordsFacts.v#L42-L56 I think it was this one? [Tue Nov 22 17:59:17 2016] nice [Tue Nov 22 17:59:27 2016] is the member_to_pos thing essential? [Tue Nov 22 17:59:46 2016] or does the same proof work without it? [Tue Nov 22 18:03:58 2016] Hi all, does anybody know if it is possible to automate proofs of decidable equality? The proof length (as I'm writing it right now) of eqb x y = true <-> x = y is basically quadratic in the number of constructors of the inductive type. [Tue Nov 22 18:06:22 2016] gancherj: does "decide equality" work? [Tue Nov 22 18:06:31 2016] (how's that for automation, if it does!) [Tue Nov 22 18:08:07 2016] ..it did! :) [Tue Nov 22 18:08:39 2016] thanks, I knew it would be obvious [Tue Nov 22 18:16:38 2016] jrw: the member_to_pos helps get rid of some dependent type constraints, not sure if necessary but it definitely simplifies things [Tue Nov 22 18:17:18 2016] as opposed to writing (diff: pmr <> pmw) and then have a weird heterogeneous equality when you start destructing either pmr or pmw [Tue Nov 22 18:17:36 2016] it might be necessary actually [Tue Nov 22 18:18:05 2016] you need some sort of hypothesis like pmr <> pmw, but that will allow their type to change [Tue Nov 22 18:18:32 2016] unless you can dependent destruct the equality? [Tue Nov 22 18:19:03 2016] nah nvm [Tue Nov 22 18:22:35 2016] iirc I got the proof to work with `pmr <> pmw` modulo coq universe bugs [Thu Nov 24 13:06:22 2016] What is a good way to do this: [Thu Nov 24 13:06:28 2016] match (p, s) with [Thu Nov 24 13:06:36 2016] | (String h p', String h s') [Thu Nov 24 13:07:28 2016] I get "Error: The variable h is bound several times in pattern." [Thu Nov 24 13:10:29 2016] do you need the value of h? [Thu Nov 24 13:10:51 2016] yes [Thu Nov 24 13:12:11 2016] seems a bit annoying but maybe you could match on p first, then on s. [Thu Nov 24 13:13:01 2016] yes, I can do that. [Thu Nov 24 13:13:16 2016] but was hoping for a "nicer" solution :) [Thu Nov 24 13:13:55 2016] is it a constraint that h for p and h for s are the same, or do you know already that they will be same? [Thu Nov 24 13:14:08 2016] if you know that they will be same you could use _ on the second slot [Thu Nov 24 13:14:13 2016] otherwise no idea [Thu Nov 24 13:16:06 2016] yes, it is a constraint [Thu Nov 24 13:19:04 2016] Hmm, it seems I can't match one one and then the other either ... [Thu Nov 24 13:19:43 2016] If I do "match p with | String h pt => match s with | EmptyString => ... | String h st => ... | _ => ..." [Thu Nov 24 13:19:58 2016] I get the error "Error: This clause is redundant." [Thu Nov 24 13:20:08 2016] So it appears the "second h" is considered a fresh variable? [Thu Nov 24 13:20:25 2016] You need some kind of decidable equality on h, and then do something like: match (p, s) with (String h1 p', h2 s') -> if eq_dec h1 h2 then ... else ... end [Thu Nov 24 13:21:15 2016] yeah it shadows [Thu Nov 24 13:21:27 2016] aha, ok [Thu Nov 24 13:21:32 2016] right, the issue is you're hiding an equality comparison in there [Thu Nov 24 13:22:07 2016] thanks both of you! [Sat Nov 26 18:17:08 2016] is it possible to (locally) deactivate all/some coercions? [Tue Nov 29 19:00:25 2016] are there any nonstandard models of peano arith that you can constructively define, e.g. in vanilla coq [Thu Dec 1 18:46:16 2016] Is there a coq bot? [Fri Dec 2 17:32:27 2016] I guess it hasn't been proven to exist? [Fri Dec 2 17:40:59 2016] johnw: *slow clap* [Fri Dec 2 18:08:53 2016] hodapp: now when I see your name, I wonder if it means "hold the app" [Fri Dec 2 18:12:50 2016] don't remind me of one of the sorrier deaths in 2016 :( [Sun Dec 4 22:22:58 2016] johnw: Hi John [Sun Dec 4 22:23:14 2016] Which version of Coq you are using [Sun Dec 4 22:23:16 2016] https://gist.github.com/jwiegley/80b39aefca77e7d28da14e389f0f9958 [Sun Dec 4 22:24:12 2016] I am using Welcome to Coq 8.5pl2 (July 2016), and when trying your solution [Sun Dec 4 22:24:18 2016] it is not accepted [Sun Dec 4 22:49:42 2016] Hmm, it works here, with a Coq8.5pl2 from October 2016 [Sun Dec 4 22:49:51 2016] (so basically pl2 with a few added patches which shouldn't matter) [Sun Dec 4 22:50:28 2016] Could you detail a little bit more what fails? Replace the "congruence" with "try congruence" and see what goals are left [Sun Dec 4 23:09:07 2016] Cypi: https://gist.github.com/mukeshtiwari/b063970860df57673aec1e366d27461b [Sun Dec 4 23:10:42 2016] This is strange. Are you sure that you're doing "induction c; split; inversion H; inversion H0" right at the start, when the goal is "forall (c : com) (st st1 st2 : state) (s1 s2 : status), c / st || s1 / st1 -> c / st || s2 / st2 -> st1 = st2 /\ s1 = s2" ? [Sun Dec 4 23:12:16 2016] Oh wait. Ahah, I see [Sun Dec 4 23:12:25 2016] Theorem ceval_deterministic: forall (c:com) st st1 st2 s1 s2, c / st \\ s1 / st1 -> c / st \\ s2 / st2 -> st1 = st2 /\ s1 = s2. [Sun Dec 4 23:12:32 2016] Could you provide your definition of ceval? If we are not even working on the same definitions, that won't work :) [Sun Dec 4 23:13:46 2016] Cypi: https://gist.github.com/mukeshtiwari/b063970860df57673aec1e366d27461b [Sun Dec 4 23:16:06 2016] Cypi: I wrote it months back, so I don't remeber all the details. [Sun Dec 4 23:16:44 2016] But now I think that my definition of ceval is not correct [Sun Dec 4 23:18:29 2016] What I'm trying currently: "induction c; split; try solve [inversion H; inversion H0; congruence]." and then dealing with the remaining goals [Sun Dec 4 23:18:42 2016] I'll see if I encounter a problem that seems to be related to the definition :) [Sun Dec 4 23:32:46 2016] ah right, I very vaguely remember this one...I actually had some problems with the WHILE case [Sun Dec 4 23:34:55 2016] Cypi: Yes [Sun Dec 4 23:35:13 2016] The WHILE case looks scary :) [Sun Dec 4 23:35:43 2016] I remember finding a trick that made it natural, but I forgot the trick -.- [Sun Dec 4 23:36:53 2016] Cypi: May I see your code ? [Sun Dec 4 23:37:24 2016] if only I still had it :D [Sun Dec 4 23:38:13 2016] Cypi: :) [Mon Dec 5 00:03:59 2016] Ok, I somehow managed to prove it, but it's ugly... [Mon Dec 5 00:04:38 2016] Cypi: Something is better than nothing [Mon Dec 5 00:04:52 2016] Let me rephrase it a tiny bit and I'll paste that. [Mon Dec 5 00:17:06 2016] keep_learning : https://gist.github.com/cmangin/5fadf6e2754f767021cfbfb55a8d7276 [Mon Dec 5 00:17:12 2016] have fun with that... [Mon Dec 5 00:20:26 2016] Cypi: Thank you [Mon Dec 5 01:04:51 2016] Cypi: We need some kind of induction, because we don't know how many E_WhileLoopNormal steps were taken. [Mon Dec 5 01:05:00 2016] I think this is what I was missing [Mon Dec 5 01:05:06 2016] Thanks again [Mon Dec 5 07:19:09 2016] Is there a way to associate a proof requirement with a typeclass? As a trivial example, let's say I have `Class BinaryOp (F: Type) (T: Type) := { apply (f: F) (x: T) (y: T): T; }.` and I want to define a `Class AssociativeBinaryOp (F: Type) (T: Type) {BinaryOp F T} := { ... }.`, such that in order to implement `AssociativeBinaryOp F T`, you must prove that `forall f: F, forall x: T, forall y: T, apply f x y = apply f y x` [Mon Dec 5 07:21:02 2016] (If anyone's curious as to motivation, I'm wanting to play around with the idea of a generic CRDT combinators framework) [Mon Dec 5 07:22:16 2016] But of course, CRDTs require a merge function that is associative, commutative, and idempotent [Mon Dec 5 08:24:57 2016] eternaleye: you can write basically exactly what you wanted. For instance: Class AssociativeBinaryOp (F: Type) (T: Type) `{BinaryOp F T} := { associative_ax (f : F) (x : T) (y : T) : apply f x y = apply f y x }. [Mon Dec 5 08:25:21 2016] (notice the backtick in front of {BinaryOp F T}, it's just a way to say this is an implicit argument whose name we don't care about) [Mon Dec 5 08:25:30 2016] (it's often use for typeclasses, precisely) [Mon Dec 5 08:25:51 2016] Cypi: Huh, in my experience, curly braces do that on their own? [Mon Dec 5 08:27:00 2016] curly braces alone will treat the identifiants inside the braces as single variables [Mon Dec 5 08:27:05 2016] which are deemed implicit [Mon Dec 5 08:27:25 2016] so {BinaryOp F T} will actually declare 3 additionnal parameters [Mon Dec 5 08:27:27 2016] Also, the problem with framing it that way is that when I try to instantiate the typeclass (for a trivial instantiation where T = unit), and I bind associative_ax f x y := apply f x y = apply f y x, it complains that it expected something of type apply f x y = apply f y x, but got something of type Prop [Mon Dec 5 08:27:40 2016] Mm [Mon Dec 5 08:27:43 2016] (it will fail somewhere along the road, but well, in this case, the error messages are not very useful) [Mon Dec 5 08:28:46 2016] if you want to build an instance of this class, then you need to provide a proof of "apply f x y = apply f y x" [Mon Dec 5 08:29:21 2016] I suppose my problem is I've not yet worked with constructing proofs without the Theorem vernacular helping me [Mon Dec 5 08:29:54 2016] If I just close out the class, would it drop me into proof-editing mode for that? [Mon Dec 5 08:30:08 2016] It can still help you, Instance can work just the same as Theorem [Mon Dec 5 08:30:20 2016] just end the statement with a dot instead of the := to declare a term [Mon Dec 5 08:30:36 2016] Mm, cool. [Mon Dec 5 08:30:57 2016] What if the class has both function-like members and proof-like members? Can I specify only the former? [Mon Dec 5 08:31:45 2016] Hmm, using Program, probably. Something like "Program Instance", then you go on and define the instance entirely, but whenever there are proof-like members, just write an underscore _ [Mon Dec 5 08:32:15 2016] Mm, that sounds like a plan [Mon Dec 5 08:32:15 2016] it will then generate obligations that you can prove one by one with "Next Obligation. (* your proof *) Qed." and so on [Mon Dec 5 08:32:33 2016] * might use that anyway, since I like the look of that syntax better [Mon Dec 5 08:32:46 2016] Makes it more explicit exactly what's being left out [Mon Dec 5 08:33:41 2016] What is "BinaryOp F T" supposed to mean? I'm not sure I quite understand :o [Mon Dec 5 08:36:18 2016] Cypi: You'd use it like "apply Add 1 2" or "apply Sub 4 1" [Mon Dec 5 08:36:33 2016] Cypi: F is just to disambiguate multiple instances for the same T [Mon Dec 5 08:36:57 2016] I just use newtypes of unit [Mon Dec 5 08:37:40 2016] There's probably a more clever way, due to instances being named, but I'm not aware of it [Mon Dec 5 08:38:01 2016] Ok, so it means that for any (f : F), there exists a function T -> T -> T basically, I see. You wanted to index your functions by some type. Ok :) [Mon Dec 5 08:38:39 2016] AssociateBinaryOp would then mean that _all_ these functions are symmetric, right? [Mon Dec 5 08:39:30 2016] No, it'd mean that any BinaryOp F T that also implements AssociateBinaryOp F T is symmetric [Mon Dec 5 08:40:15 2016] If you want a function to only accept symmetric binary ops, for example, you'd specify a parameter of type "AssociateBinaryOp F T" [Mon Dec 5 08:41:03 2016] Yeah, but to provide a "AssociateBinaryOp F T", wouldn't you have to prove that all the "apply f" functions are symmetric? For any (f : F) ? [Mon Dec 5 08:41:41 2016] I don't think so? Since F and T are already bound - you're instantiating AssociateBinaryOp for _concrete_ F and T [Mon Dec 5 08:41:50 2016] You just have to prove for all f, x, and y [Mon Dec 5 08:42:30 2016] Yes, that's what I was meaning to say. So if you have "Add" and "Sub" in your F, as you were saying, you would have trouble [Mon Dec 5 08:42:34 2016] So I'd instantiate AssociateBinaryOp Add nat [Mon Dec 5 08:42:46 2016] Oh, yes [Mon Dec 5 08:42:55 2016] Ah well no. You wrote "apply Add 1 2", so Add is of type F for some (F : Type) [Mon Dec 5 08:43:00 2016] Which is why I use distinct newtypes of unit for each [Mon Dec 5 08:43:25 2016] As I said, I'm sure there's a more elegant way, but... [Mon Dec 5 08:43:42 2016] For my uses, F is always a newtype of unit [Mon Dec 5 08:44:04 2016] Oh well, ok, as long as it works [Mon Dec 5 08:44:42 2016] I'd love to know if there's a better way to 1.) define multiple instances with the same parameters and 2.) select which one to call functions from [Mon Dec 5 08:45:05 2016] As I'm currently just hacking it so that they have different parameters :P [Mon Dec 5 08:46:13 2016] Maybe I could do something with modules [Mon Dec 5 09:52:53 2016] Cypi: Aha! This works much better: http://ix.io/1KhS [Wed Dec 7 10:59:21 2016] what are the limits of self-interpreters in consistent languages? [Wed Dec 7 10:59:33 2016] consistent meaning, having a type system that acts as a consistent logic [Wed Dec 7 10:59:59 2016] thinking of dependently typed languages in particular, where it makes sense to, e.g., have a function like "TypeRep -> Type" (obv not surjective) [Fri Dec 9 11:34:07 2016] i have a more general question about type theory; i hope it's fine to ask here [Fri Dec 9 11:34:26 2016] if i understood correctly, dependent sum types are generalizations of product types and dependent product types are generalizations of function types [Fri Dec 9 11:34:32 2016] this seems unintuitive - i would have expected dependent product types to be generalizations of product types [Fri Dec 9 11:34:35 2016] what am i missing? [Fri Dec 9 12:41:45 2016] mjacob: you're not missing anything. The name of "product type" is rather unintuitive, as it is a special case of a dependent sigma (or sum) type [Fri Dec 9 12:44:21 2016] mjacob: it's because it's a "dependent" product [Fri Dec 9 12:44:56 2016] mjacob: like this: https://wikimedia.org/api/rest_v1/media/math/render/svg/cd6a5719f5cda293cd79836a3c90f59e7447557e [Fri Dec 9 12:45:39 2016] a normal product is the same as an indexed sum where the terms are always the same no matter the index [Fri Dec 9 12:45:51 2016] a normal exponent is the same as an indexed product where the terms are always the same no matter the index [Fri Dec 9 12:46:10 2016] a dependent product is not a "product of the domain and codomain" - it's a product of all of the possible codomains together [Fri Dec 9 12:50:52 2016] Cypi: so which name do you think is unintuitive - "product type" or "depedent product type"? [Fri Dec 9 12:52:05 2016] benzrf: so you mean it's like "2 * 3 = Σ i from 1 to 2, 3"? (sorry for the bad notation, i hope you understand what i mean) [Fri Dec 9 12:53:26 2016] well, that's basically exactly what you said ;) [Fri Dec 9 12:53:31 2016] yup! [Fri Dec 9 12:54:31 2016] "exists n : nat, int" <- this is "Σ_{n in nat}, int" [Fri Dec 9 12:54:34 2016] a.k.a. nat * int [Fri Dec 9 12:54:43 2016] thank you, that makes sense; and now i also understand why people use exponentials to express function types [Fri Dec 9 12:54:47 2016] yup :) [Fri Dec 9 13:11:47 2016] mjacob: "product type", but benzrf's explanation makes sense :) [Tue Dec 13 04:22:46 2016] I've formalized and proven something about F-Algebras for a functor F encoded as a record (basically equvialent to using nested sigT, dependent functions and vectors). Now I wonder how to present this correctly in "normal" pen and paper math. I can write down the Functor pretty easily as sums and products, but I'm not sure which category to put on it [Tue Dec 13 04:24:29 2016] I just care that sums and products are there and behave like coq types. Is it ok to just write everything happens in Set? [Tue Dec 13 04:33:00 2016] I know there is "Coq in Sets, Sets in Coq" and a follow up talk (http://www.lix.polytechnique.fr/Labo/Bruno.Barras/talks/model-cic-2011.pdf) from the author, Bruo Barras, explaining some ideas how to do CIC [Tue Dec 13 04:33:15 2016] *Bruno [Tue Dec 13 04:45:02 2016] Or can I even write something along the line of "fix some locally cartesian closed category C"? My proofs live in a module taking a carrier in Type as parameter. [Tue Dec 13 06:33:07 2016] "but I'm not sure which category to put on it" not sure what you mean; wouldn't it be the category induced by F-algebra homomorphisms? [Tue Dec 13 06:34:02 2016] @ JanBessai [Tue Dec 13 06:42:22 2016] @stoopkid: for the F-Algebra morphism "F" needs to be an endofunctor in some category C [Tue Dec 13 06:42:31 2016] and I'm wondering, what to say about C [Tue Dec 13 06:45:10 2016] hrm, what else do you need to say about it besides for that it's a category? [Tue Dec 13 06:46:33 2016] I also need sums and products to define F [Tue Dec 13 06:49:13 2016] ah is this for polynomial functors? [Tue Dec 13 06:49:52 2016] exactly [Tue Dec 13 06:50:41 2016] my problem is sort of similar to the issues with haskell. people just use "Hask" without ever saying what it is: http://math.andrej.com/2016/08/06/hask-is-not-a-category/ [Tue Dec 13 06:52:33 2016] i've been working on the same thing in agda actually. i started by formalizing F-algebras for arbitrary functors and categories and now i'm aiming to handle polynomial functors as a special case [Tue Dec 13 06:53:38 2016] my stuff is just one special polynomial functor for term signatures with some bells and whistles [Tue Dec 13 06:57:32 2016] @stoopkid: how do you deal for example with extensionality? [Tue Dec 13 06:57:45 2016] are you using hot, setoids or something like that? [Tue Dec 13 06:58:20 2016] i hadn't run into it as an issue yet [Tue Dec 13 06:58:28 2016] where's it coming up? [Tue Dec 13 06:59:25 2016] to be a category, one needs (f compose g) compose h = f compose (g compose h), which usually requires functional extensionality [Tue Dec 13 07:00:05 2016] or f compose id = f [Tue Dec 13 07:00:26 2016] ah [Tue Dec 13 07:01:58 2016] i don't think function extensionality is necessary for this, but i've been running into the issue of possibly needing the K rule to prove that F-algebra homomorphisms satisfy the associativity and identity laws [Tue Dec 13 07:02:30 2016] because F-algebra homomorphisms keep track of a commuting diagram [Tue Dec 13 07:03:58 2016] i imagine it would be a similar situation in other cases too, so i've been thinking about how to weaken the definitions [Tue Dec 13 07:08:16 2016] but, for example, i was able to prove that each set-level in agda forms a category: http://pastebin.com/h7NkXabL [Tue Dec 13 07:17:12 2016] a couple ways i can think to approach the situation where the homomorphisms carry extra information like the commuting diagrams in F-algebra homomorphisms without adding either K-rule or univalence: a) use squash types to eliminate the proof information for the commuting diagrams, or b) weaken the definitions of associativity and identity to those described [Tue Dec 13 07:17:12 2016] here: https://ncatlab.org/nlab/show/monoidal+category [Tue Dec 13 07:18:05 2016] squash types seem like the intuitively correct choice [Tue Dec 13 07:19:02 2016] we don't care about the structure of our proof that the diagram commutes, we only care *that* the diagram commutes [Tue Dec 13 15:39:43 2016] Hi, everyone! [Tue Dec 13 15:41:09 2016] I'm getting an error: Error: Compiled library Foo.Bar.vo makes inconsistent assumptions over library Coq.Init.Logic. [Tue Dec 13 15:41:47 2016] Where Foo.Bar is a project I've installed with `make install`, from a Makefile produced by `coq_makefile`. [Tue Dec 13 15:42:32 2016] I would like to understand if `coqc` will print out the exact file path of Foo.Bar.vo so that I can understand from where it is trying to load the module from. [Tue Dec 13 15:43:43 2016] Or to put it in another way, how can I know which paths does `coqc` is using to look for modules? [Tue Dec 13 15:44:34 2016] My module `Foo.Bar` is being installed in `.opam/system/lib/coq/user-contrib`, but apparantly `coqc` is not picking it up. [Tue Dec 13 16:13:55 2016] tcog: it seems like Foo.Bar.vo was compiled with a different version of Coq than what you are using now. Would you have a way to recompile it? [Tue Dec 13 16:14:23 2016] (as for your precise question, sorry, I don't really know how to have Coq to print this exact file :/ ) [Tue Dec 13 16:14:59 2016] Thanks, Cypi. I figured out that the culprit file was located in ~/.local/share/coq [Tue Dec 13 16:16:39 2016] Which means that, for future reference, `coqc` uses `~/.local/share/coq first` and then `~/.opam/system/lib/coq/user-contrib`. [Tue Dec 13 16:26:18 2016] This is more of a general question (not troubleshooting). I am wondering what is the rule of thumb when writing Coq libraries. To me it appears very difficult to maintain a Coq library because any change in any lemma will break the public interface and therefore not be backwards compatible. Are there any tricks or good practices you guys use to ameliorate this problem? [Tue Dec 13 16:28:19 2016] One technque I follow is to use Let to hide lemmas from the public API, the caveat is that adding many lets in a section will slow compilation down and make some of the proofs implicit (if using auto). [Tue Dec 13 18:06:14 2016] [Local Definition] is also a thing, and makes a name not be unqualified on [Import]. [Tue Dec 13 18:17:40 2016] hi jgross! [Fri Dec 16 06:37:46 2016] @stoopkid: perhaps you already know all this, but continuing our discussion from two days ago: I find the original paper on locally cartesian closed categories (LCCCs) by Seely (http://www.math.mcgill.ca/rags/LCCC/LCCC.pdf) and the follow ups by hofmann (https://www.irif.fr/~mellies/mpri/mpri-ens/articles/hofmann-syntax-and-semantics-of-dependent-types.pdf) and Curien, Garner and Hofmann [Fri Dec 16 06:37:52 2016] (https://www.tcs.ifi.lmu.de/mitarbeiter/martin-hofmann/publikationen-pdfs/j36-RevisitingCategoricalInterpretation.pdf) helpful. While I'm still not sure how to present it in my context, it seems ok to give set based examples and refer to LCCCs as the general case for which the proofs in coq/agda hold [Fri Dec 16 06:40:16 2016] if one is to be extremely nit-picky, there is some care to be taken to adress the differences between variations of dependent type theory, but for something using it just as a tool, LCCCs with sums and products ought to be fine [Fri Dec 16 06:40:38 2016] (I at least hope so) [Fri Dec 16 08:53:23 2016] JanBessai: idk if you'd need LCCCs unless you're trying to do dependent polynomial functors [Fri Dec 16 08:54:02 2016] regular polynomial functors should work for any category with sums & products, afaict [Fri Dec 16 08:56:48 2016] i haven't really studied dependent polynomial functors yet though, so i'm not sure if the category itself has to be an LCCC or if you just need the dependencies to exist in the type theory where the functor is being described [Fri Dec 16 09:11:17 2016] stoopkid: I think I need LCCCs, because I'm using dependencies all over the place - a simplified version of the functor I use would be F(C)(s) = Sigma_{op | range(op) = s} Pi_{i=1}^{arity(op)} C(pi_i(domain(op))) [Fri Dec 16 09:11:46 2016] with Sigma and Pi being dependent sums and products [Fri Dec 16 09:15:18 2016] basically I just want to say "Pi_x P(x)" is "forall x, P x" in coq or a family of sets on paper and "Sum_x P(x)" is "{ x: _ & P(x) }" in coq or a disjoint tagged set union on paper [Fri Dec 16 09:15:59 2016] and if I understand Seely correctly, one can get away with that without worry [Fri Dec 16 09:17:28 2016] (at least if only the direction coq -> paper is used; just using arbitrary non constructive set stuff and claiming paper -> coq is a bad idea, of course) [Fri Dec 16 09:18:16 2016] i see [Fri Dec 16 09:19:31 2016] yea i'll have to think about that. i can try working out some stuff in Agda a bit later, i'll need to review seely's paper and test some things out [Fri Dec 16 09:26:01 2016] what currently escapes me, is the part about second projections of coproducts/sums (pi' in SigmaE). Seely writes they are "essentially" the identity map, turning "projT2: forall (s: { x: _ & P (x) }), P (projT1 s)" into a morphism "Sig_{x}P(x) -> Sig_{x}P(x)" [Fri Dec 16 09:28:55 2016] while I get the rational of not being able to have dependently typed morphisms, I don't quite get, why the identiy map is a way out of the dilemma [Fri Dec 16 09:38:45 2016] (on a side note: it is incredible, to imagine all of this being done completely without computer interaction in '83 - even before nuprl ) [Fri Dec 16 17:32:41 2016] is there a coq tactic that inserts fst and snd [Fri Dec 16 21:35:13 2016] Does anyone know where the best place to find the formal verification community is? [Fri Dec 16 21:41:42 2016] Big_G: what are you going to do to them when you find them? [Fri Dec 16 21:43:37 2016] Mainly ask what the best way to get into the field is. I haven't seen a ton of resources (beyond some textbooks) for getting into the field as well as where to find work in it. [Fri Dec 16 21:47:38 2016] Big_G: oh okay :) well, what kind of formal verification stuff are you interested in? [Fri Dec 16 21:48:52 2016] I'm at the stage where I don't know what I don't know so I can only guess. Proof assistants seem interesting, I like the idea behind dependent types, and I like the concept of having some form of model that can "guarantee" properties. [Fri Dec 16 21:53:25 2016] Big_G: sounds good. if you want to learn proof assistants, in my opinion the best resource is still "software foundations". [Fri Dec 16 21:55:36 2016] a lot of formal verification work is being done in the PL community, so you could have a look at conferences like POPL, PLDI, ICFP, and OOPSLA. [Fri Dec 16 21:55:59 2016] if you want somewhere to start with research papers, I'd recommend looking at the compcert papers. [Fri Dec 16 21:56:07 2016] I can be more specific if you want. [Fri Dec 16 21:56:45 2016] I'm sure I'll need that at some point but only after some more research [Fri Dec 16 21:59:54 2016] Big_G: if you do decide to learn coq, I'd recommend coming back here and asking questions! [Fri Dec 16 22:00:59 2016] I've been meaning to for quite some while. I just have difficulty spending time on stuff after work without a clear purpose. [Fri Dec 16 22:01:40 2016] Not to say that Coq isn't cool, just that I won't be able to use it in my life as a Java coder [Fri Dec 16 22:02:26 2016] that's understandable. if you can find an hour or so to get started, you might find that the exercises in software foundations are sufficiently addicting to keep you coming back [Fri Dec 16 22:03:59 2016] That's how they get you. The first proof is always free. [Fri Dec 16 22:04:14 2016] haha :) [Sat Dec 17 03:54:08 2016] is the code / "upcoming publication" mentioned in "Buisse, A., & Dybjer, P. (2008). The Interpretation of Intuitionistic Type Theory in Locally Cartesian Closed Categories–an Intuitionistic Perspective. Electronic Notes in Theoretical Computer Science, 218, 21-32." (http://www.cse.chalmers.se/~peterd/papers/Philadelphia2008.pdf) available somewhere? [Wed Dec 21 21:30:21 2016] Hello everyone [Wed Dec 21 21:30:56 2016] I am trying to use constructive_indefinite_ground_description from https://coq.inria.fr/library/Coq.Logic.ConstructiveEpsilon.html [Wed Dec 21 21:31:11 2016] The type A is Z in my case [Wed Dec 21 21:32:07 2016] and I have to give two function f : Z -> nat and g : nat -> Z with proof that Hypothesis gof_eq_id : forall x : A, g (f x) = x. [Wed Dec 21 21:32:33 2016] Could some one please give a idea about writing these two functions [Wed Dec 21 22:02:17 2016] johnw, stoopkid: one reason nuprl is relatively unpopular just might be the fact that the most standard way to run it is to download a VM image [Thu Dec 22 03:04:19 2016] how to do inequality case splits in coq? i want to split into two cases: i < j or i >= j [Thu Dec 22 03:05:15 2016] i, j : Z [Thu Dec 22 03:18:05 2016] hmm.. seems that I should use <=? [Thu Dec 22 03:18:23 2016] "<=?" [Thu Dec 22 03:28:46 2016] petercommand: it depends on whether you have "(i < j) \/ (i >= j)" or "{i < j} + {i >= j}". You can just pattern match on them, or in tactics use destruct, case or inversion. [Thu Dec 22 03:33:56 2016] JanBessai: thx, i'll try that [Thu Dec 22 03:34:49 2016] there is also "if ... then ... else ..." as described in https://coq.inria.fr/refman/Reference-Manual004.html#Extensions-of-match [Thu Dec 22 13:00:03 2016] is there a tactic to specialize a hypothesis with underscores and prove them as subgoals? [Thu Dec 22 13:56:39 2016] you mean, you have an hypothesis of the form "forall x, f x" [Thu Dec 22 13:56:52 2016] and you want it to become "f ?x" with a new subgoal to prove ?x [Thu Dec 22 13:56:54 2016] ? [Thu Dec 22 14:07:29 2016] is anyone else seeing "Unbound module Gramext" when building mathcomp-1.6.1 using Coq 8.6? [Thu Dec 22 16:37:55 2016] johnw: yes [Thu Dec 22 16:37:59 2016] often it's [Thu Dec 22 16:38:16 2016] H: forall x, P x -> Q x [Thu Dec 22 16:38:23 2016] and I have the x but not the (P x) [Thu Dec 22 16:38:57 2016] and I want the Q x for something else [Thu Dec 22 16:53:30 2016] Ptival: you can do this: [Thu Dec 22 16:53:38 2016] cut (x : T). [Thu Dec 22 16:53:42 2016] specialize (H x). [Thu Dec 22 16:53:44 2016] ... [Thu Dec 22 16:53:50 2016] [Thu Dec 22 16:54:09 2016] or use assert, if you prefer that ordering [Thu Dec 22 19:07:57 2016] Hello everyone [Thu Dec 22 19:08:01 2016] https://gist.github.com/mukeshtiwari/74de0dcb50f4160870714707e6ee7db1 [Thu Dec 22 19:09:43 2016] I am trying to prove that f_nat_Z and f_Z_nat are inverse of each other [Thu Dec 22 19:10:18 2016] but lost in symbol manipulation of library https://coq.inria.fr/library/Coq.ZArith.Znat.html [Thu Dec 22 19:11:00 2016] Could some one please have a look and give some hints [Thu Dec 22 19:12:34 2016] I am trying to prove that integers are countable infinite https://proofwiki.org/wiki/Integers_are_Countably_Infinite [Fri Dec 23 02:46:48 2016] johnw: I guess the last constraint would have been "without having to type P" because it's long [Fri Dec 23 02:46:58 2016] I think I had made a tactic for this now that I think about it [Fri Dec 23 05:53:10 2016] hi. can types with one element have computational content? [Fri Dec 23 05:53:24 2016] I think they can, but then, under what conditions? [Fri Dec 23 05:54:30 2016] the examples I can think of where they have computational content employ proof irrelevance. in absence of proof irrelevance, can they have computational content? [Fri Dec 23 06:25:03 2016] schoppenhauer: can you say what you mean by computational content? [Fri Dec 23 06:25:57 2016] JanBessai: it cannot be erased when extracting. like, for example, Prop will be. [Fri Dec 23 06:26:32 2016] JanBessai: and branches with the empty type and the unit type [Fri Dec 23 06:29:01 2016] well type is one element are isomorphic to unit right? [Fri Dec 23 06:29:33 2016] not sure. [Fri Dec 23 06:30:38 2016] yeah no, it's a fact [Fri Dec 23 06:30:51 2016] for example, { x : nat | "x is the smallest prime larger than m" } would contain one element (in presence of proof irrelevance) [Fri Dec 23 06:31:22 2016] yes, but you prove it has one element by proving it is isomorphic to unit [Fri Dec 23 06:31:37 2016] still, it has computational content [Fri Dec 23 06:33:03 2016] I'm not sure.. perhaps it is the projection into nat, which has computational content [Fri Dec 23 06:35:43 2016] hm. ok. yes. [Fri Dec 23 06:35:54 2016] it would be a function that depends on m. [Fri Dec 23 06:36:09 2016] ok, interesting. [Fri Dec 23 06:37:51 2016] but yes, this makes sense … it is a pair (nat, _), and to get the nat, one has to use the recursion operator on pairs. [Fri Dec 23 06:38:02 2016] i still find this counter-intuitive somehow … [Fri Dec 23 06:38:30 2016] perhaps I'm wrong (I don't have any formal proof or reference for that) [Fri Dec 23 06:38:53 2016] maybe I'll ask math.stackexchange or something. [Fri Dec 23 06:40:45 2016] but it makes sense in the sense that the result of the recursion operator only depends on m. [Fri Dec 23 06:41:36 2016] on the other hand … this should probably be undecidable in general. so this is not really a "practical" notion of computational content. [Fri Dec 23 06:42:21 2016] maybe it boils down to the questions: given (S : Type) (singleton: Singleton S) (A: S -> Type), Lemma erase: JMEq (forall (s: S), A s) (forall (u: unit), A (unit_isomorphism u)). [Fri Dec 23 06:42:51 2016] with JMeq being john major equality, because the functions have different types [Fri Dec 23 06:43:42 2016] and unit_isomorphism being unit <-> S from the singleton proof [Fri Dec 23 06:45:40 2016] (or similar non dependent versions, if that is easier and enough) [Fri Dec 23 06:45:59 2016] i.e. JMeq (S -> A) (unit -> A) [Fri Dec 23 06:47:46 2016] is there a JMeq analogon of functional extensionality? forall A B C (f: A -> C) (g: B -> C), JMeq A B -> JMeq f g. [Fri Dec 23 06:48:09 2016] ohh one moment.. wrong definition [Fri Dec 23 06:49:02 2016] forall A B C D (f: A -> C) (g: B -> D), (forall (x: A) (y: B), JMeq x y -> JMeq (f x) (g y)) -> JMeq f g. [Fri Dec 23 06:50:29 2016] hmmm on the other hand not even sure that would be enough: unit and singleton types have different inhabitant terms [Fri Dec 23 06:53:19 2016] I recently encountered a similar question for False. you can have Inductive False1 : Type :=. Inductive False2 : Type :=. and it is not the case that False1 = False2 (even though that would be true in Set theory). [Fri Dec 23 07:59:36 2016] JanBessai: shouldn't False1 = False2 at least hold in HoTT? because they are clearly isomorphic? [Fri Dec 23 07:59:45 2016] ah ok no [Fri Dec 23 07:59:49 2016] not clearly [Fri Dec 23 08:00:22 2016] only with function extensionality [Fri Dec 23 10:52:21 2016] Hello gentlemen! I have a question regarding Ltrac matching mechanism. It fails for my case but I cant figure why. Is it alright to ask such a question here? [Fri Dec 23 10:52:29 2016] *Ltac [Fri Dec 23 10:54:36 2016] No one complained, so I guess it means ok :-) [Fri Dec 23 10:55:42 2016] Lets say I have the following code: [Fri Dec 23 11:09:11 2016] Ok, I found a solution -) Thanks anyway. [Fri Dec 23 11:10:43 2016] I was waiting for the code :( [Fri Dec 23 12:15:09 2016] I am relatively new to Coq! I am stuck proving http://pastebin.com/fKAguHvg. What is some advice on how to prove Sorted_cdr? [Fri Dec 23 12:21:02 2016] do you know how you'd do it on paper? [Fri Dec 23 12:28:30 2016] If t::L is sorted and if L is a::b::L' (if L is empty or a single item then it is trivial) then you have to prove R a b and b::L' is sorted, which you have to somehow 'extract' from the proof of Sorted t::L. This is my intuition. (I am not a trained mathematician/computer scientist). [Fri Dec 23 12:34:43 2016] "'extract' from the proof of Sorted t::L" >> that's the right idea. You have a proof of t::L, and there are just a few ways you could have that (by singleton_sorted or by cons_sorted). The way to explain that in Coq is "inversion H" [Fri Dec 23 12:36:59 2016] Thanks for the help Cypi. Will give that a go. [Fri Dec 23 12:38:48 2016] It worked! (Probably no surprise to you!) Thanks! Now to go and read the documentation for the "inversion" tactic. [Fri Dec 23 23:00:21 2016] schoppenhauer: function extensionality is a theorem in hott [Fri Dec 23 23:00:51 2016] benzrf: I know [Fri Dec 23 23:01:16 2016] i didn't, cool to know. i thought it had to be an axiom. [Fri Dec 23 23:01:34 2016] benzrf: but it is not "clear" how to use this here. that was what I meant [Fri Dec 23 23:01:50 2016] oh [Fri Dec 23 23:03:41 2016] modulus: you need univalence. and I dont know how it is proved. [Fri Dec 23 23:03:49 2016] but probably benzrf knows [Sat Dec 24 15:42:43 2016] i kind of do [Sat Dec 24 15:42:51 2016] i know how to prove funext in cubical type theory [Sat Dec 24 15:42:56 2016] im not sure how to do it just from univalence [Sun Dec 25 11:12:32 2016] Hey, everyone. I'm trying to understand how to handle warnings of this kind: Warning: Cannot build inversion information [funind-cannot-build-inversion,funind] [Sun Dec 25 11:13:08 2016] Why isn't Coq able to build inversion info. Is there anything I can do to help it? [Sun Dec 25 18:29:02 2016] supose I have an Inductive for lambda terms (https://gist.github.com/pedrotst/6a5af9f6fc162f31af59902b274b66f0). How do I state the lemma "all terms that does not contain application satisfies blah"? [Sun Dec 25 18:29:27 2016] that does not contain application as subterm* actually [Sun Dec 25 18:30:52 2016] You need a predicate to express "that does not contain application" [Sun Dec 25 18:31:36 2016] two approaches I can see: 1) The simple but more redundant one: having another inductive predicate which expresses directly this property (you will basically have one constructor for each constructor of tm except app [Sun Dec 25 18:32:01 2016] 2) Rewrite your inductive definition of tm so that it's indexed by a boolean which indicates if the term contains an app somewhere or not [Sun Dec 25 18:32:33 2016] (2) is less redundant, but the type is more dependent, and also, maybe this boolean is not relevant for other theorems) [Sun Dec 25 18:37:40 2016] those are nice ideas, thanks [Sun Dec 25 18:37:52 2016] unfortunately I don't think they fit my need [Sun Dec 25 18:38:33 2016] I pretty much need to check if a term contains some sort of subterm, and if thats the case, state a property about it [Sun Dec 25 18:39:02 2016] Ah, youm [Sun Dec 25 18:39:03 2016] maybe the example I used isn't the best, let me think [Sun Dec 25 18:39:10 2016] Ah, you mean that it's not "an application" in general [Sun Dec 25 18:39:31 2016] let's change "its not an application" to it's actually an aplication [Sun Dec 25 18:39:38 2016] that that aplication must satisfy such and such [Sun Dec 25 18:40:19 2016] So... "every application node in the term satisfies such property"? [Sun Dec 25 18:40:25 2016] yes [Sun Dec 25 18:40:40 2016] Then I would write it as a Fixpoint, probably [Sun Dec 25 18:41:07 2016] you mean a lemma as a fixpoint? [Sun Dec 25 18:41:21 2016] Not the lemma, the type of the lemma :) [Sun Dec 25 18:41:33 2016] oh yeah haha, awesome [Sun Dec 25 18:42:42 2016] gees, thats beyond my knowledge right now. Do you think if I finish Certified Programming with Dependent Types I`ll be able to come up with that naturally? [Sun Dec 25 18:43:12 2016] As a more simple example, let's just take a list, and say we want to prove the property P for every element of the list. You could start by defining: "Fixpoint All {A : Type} (P : A -> Prop) (l : list A) : Prop := match l with nil => True | cons x l' => P x /\ All P l' end." [Sun Dec 25 18:43:40 2016] and then have the type of your lemma be "All P l" for the right P and l [Sun Dec 25 18:43:47 2016] CPDT is quite advanced, sure [Sun Dec 25 18:44:19 2016] In the case of your terms, this is essentially the same kind of Fixpoint, just slightly more complicated because it's a tree [Sun Dec 25 18:46:29 2016] I'll give it a go. Thanks a lot! [Wed Dec 28 00:44:10 2016] Turns out god exists: http://page.mi.fu-berlin.de/cbenzmueller/compmeta/htdocs/poster2.pdf :-) [Wed Dec 28 09:37:28 2016] rrika: is there a technique to go past through goals like the final one here? http://paste.awesom.eu/5N42 [Wed Dec 28 09:37:32 2016] this is so convoluted :( [Thu Dec 29 16:47:13 2016] Cale, jesus dude.. You're in every single channel I'd ever think to join. [Thu Dec 29 16:48:58 2016] If I wanted to learn more about System U, which channel would be most helpful? I'd think #Coq, possibly #haskell, even #hott, but I'm a little flustered at the moment. [Thu Dec 29 18:15:25 2016] what is System U? [Thu Dec 29 21:41:13 2016] Ptival, is this based on your earlier code? [Thu Dec 29 21:41:38 2016] oh, you managed to do without my "match goal with |- context [ Fix_sub ?A_ ?R_ ?Rwf_ ?P_ ?f_ ?x_ ] =>" [Thu Dec 29 21:41:48 2016] interesting will have to look at that… [Thu Dec 29 21:50:43 2016] Ptival, when I try to load your file I get an error. [Thu Dec 29 21:50:59 2016] >Cannot infer the type of I in pmconcat [Thu Dec 29 21:53:38 2016] okay I used (I: {i: nat & i > 0}) [Thu Dec 29 22:10:47 2016] … I don't quite get the idea behind pmconcat. Also coq uses 20% of my RAM now. [Fri Dec 30 04:19:41 2016] rrika: yeah like this it looks dumb, it's actually a stand-in for a version that would be parallelized in practice [Fri Dec 30 04:20:10 2016] and you match goal was just to make things more readable/short no? [Fri Dec 30 16:47:41 2016] Does someone know some literature about logic and curry-howard correspondence? [Fri Dec 30 16:47:52 2016] Topic should als be updated, 8.6 is out [Sun Jan 1 10:00:26 2017] are people familiar with https://x80.org/collacoq/ here? [Sun Jan 1 10:00:38 2017] it's doing weird things on my chrome, and i'm not sure whether they are bugs [Sun Jan 1 10:00:55 2017] like, trying to automatically compile all the time, thus messing up my edits [Sun Jan 1 10:01:08 2017] or capturing the Ctrl+V key binding for "paste" [Sun Jan 1 14:38:46 2017] 明けましておめでとうございます [Mon Jan 2 08:37:43 2017] does anyone know how to prove a goal of the form " 0 < p <= m" in mathcomp? [Mon Jan 2 08:37:56 2017] i think it's an /\, but i'm not sure how to deconstruct it [Mon Jan 2 09:56:01 2017] arvisrend: it's (0 < p) && (p <= m) I think [Mon Jan 2 09:56:15 2017] so you have to use "apply/andP." to turn it into a /\ before you can use "split" [Mon Jan 2 09:56:50 2017] well I'm a bit late so maybe you already found lol [Mon Jan 2 10:01:26 2017] thanks [Mon Jan 2 10:01:31 2017] yeah i did find it [Mon Jan 2 10:01:49 2017] just getting confused by the fact that tutorials always lag behind the libs [Mon Jan 2 10:36:37 2017] is it common that you say "rewrite X" instead of saying "rewrite the goal using X"? [Mon Jan 2 10:36:45 2017] i'm finding it quite confusing [Mon Jan 2 10:36:51 2017] i mean in text, not in code [Mon Jan 2 10:37:21 2017] that's probably SSR users writing "rewrite theorem." so often it becomes natural language :D [Mon Jan 2 10:37:41 2017] also, about that "0 < p <= m", you could've found using: Locate "_ < _ <= _". [Mon Jan 2 10:38:18 2017] ah, locate! [Mon Jan 2 10:38:19 2017] thanks [Mon Jan 2 10:38:42 2017] so far it's been mostly a game of chance if i got the Check/Locate/Search right [Mon Jan 2 15:40:06 2017] Hi, I have a very basic question. I have "Notation "~ x" := (not x) : type_scope." (from the software foundations book), and in the proofs they use "unfold not", but is it possible to use something like "unfold ~" instead? "unfold ~" does not work so I guess some kind of escaping or something like that is needed? Or maybe it's not the correct "scope"? [Mon Jan 2 15:40:32 2017] unfold "~" [Mon Jan 2 15:41:52 2017] johnw: That worked, haha, thank you. [Mon Jan 2 15:41:56 2017] I only tried ( [Mon Jan 2 15:41:58 2017] ops [Mon Jan 2 15:42:04 2017] (~) [Mon Jan 2 18:19:49 2017] Hello everyone [Mon Jan 2 18:20:06 2017] Wish you all a very happy new year [Mon Jan 2 18:20:32 2017] May your year be filled with Qed :) [Mon Jan 2 19:41:38 2017] Hello everyone [Mon Jan 2 19:42:00 2017] I am trying to prove that integer in countble infinite https://gist.github.com/mukeshtiwari/bb7e2ea056e9229cc8ad630457ee872c [Mon Jan 2 19:42:22 2017] *countably infinite [Mon Jan 2 19:43:19 2017] But stuck with goal. [Mon Jan 2 19:45:06 2017] I have proof sketch also. For any v = Pos.to_nat p, 2 * v - 1 > 0 and we can write it S (2 * (v - 1)) [Mon Jan 2 19:46:01 2017] After simplification, it will go second branch of f_nat_Z | _ => if even n then -1 * Z.of_nat (div n 2) else Z.of_nat ((div (S n) 2)) [Mon Jan 2 19:47:03 2017] and clearly S (2 * (v - 1)) is odd so we go to else branch [Mon Jan 2 19:48:41 2017] My only problem is I am not able to convice Coq accroding to my thinking because of my lack of inexperience with ZArith. [Mon Jan 2 19:49:51 2017] I would be more than happy to read Coq code if there is any such proof on github (I tried to search but could not locate any) [Mon Jan 2 19:57:48 2017] keep_learning: looks "just" like some annoying manipulations to prove simple arithmetic facts. I'm trying to do it at the moment... (not very used to ZArith either) [Mon Jan 2 19:58:37 2017] Cypi: Yeah. I am also trying but not able to see the directon of proof. [Mon Jan 2 20:00:27 2017] Well, for instance, the steps I took after where you left at: "destruct v", then prove that v = O is absurd, and so on... [Mon Jan 2 20:11:16 2017] keep_learning: there you go http://lpaste.net/350789 [Mon Jan 2 20:11:20 2017] it's probably very ugly though [Mon Jan 2 20:14:17 2017] Cypi: Thank you. [Mon Jan 2 20:15:59 2017] I am trying different route https://gist.github.com/mukeshtiwari/bb7e2ea056e9229cc8ad630457ee872c [Mon Jan 2 21:54:10 2017] Cypi: Thanks again. Finally I completed my own version of proof by using your tactics. https://gist.github.com/mukeshtiwari/bb7e2ea056e9229cc8ad630457ee872c [Tue Jan 3 13:11:48 2017] what's the state of the art for using mathcomp on windows? [Tue Jan 3 16:00:49 2017] hm, is there some way of showing the level and associativity of an operator (in proof general in emacs)? i tried print, check, locate notation etc. but nothing shows the things i want to know, :(. [Tue Jan 3 16:19:24 2017] I also wish there were [Wed Jan 4 07:03:54 2017] In first order logic I'd like to prove "(exists x:D, phi \/ psi) -> ((exists x: D, phi) \/ (exists x: D, psi))". How can I tell Coq that phi and psi might well be dependent on x? Currently, I have declared them as a simple Prop. [Wed Jan 4 07:07:11 2017] phi_: I don't think that you can express that in first-order logic because you'd have to quantify over phi and psi (which would then need to be of type D -> Prop) [Wed Jan 4 07:07:53 2017] though you can probably prove it for any instance of phi and psi [Wed Jan 4 07:13:51 2017] It seems that our lecture notes tried to prove ∃ elimination by means of expressing ∃ through ~(forall: ~phi). But isn't this inherently the same - a quantification over phi? [Wed Jan 4 07:14:01 2017] How could I proove it for any instance? [Wed Jan 4 07:16:47 2017] well, quantify over phi and psi ? but then it's not really first-order anymore [Wed Jan 4 07:22:45 2017] It worked! Thanks! [Wed Jan 4 07:38:48 2017] There is really strange bug: you can never save your _scratch_ files in any subdirectory on your OneDrive folder. However, once you open an already saved file there, you can arbitrarily save it again under the same name. [Wed Jan 4 15:08:54 2017] Hm, regarding my previous question about escaping operators. unfold "~" works, but unfold "<>" does not work. Coq says that it's unable to interpret "<>" as a reference. Is there some extra escaping needed here? [Wed Jan 4 15:18:09 2017] maybe unfold "_ <> _"? [Wed Jan 4 15:18:11 2017] dunno [Wed Jan 4 15:18:13 2017] cic^ [Wed Jan 4 15:22:36 2017] benzrf: same error :( [Wed Jan 4 15:23:28 2017] shrug [Wed Jan 4 15:23:30 2017] sorry [Wed Jan 4 15:25:18 2017] cic: I'm not sure you can do anything, because 'Locate "_ <> _".' gives that "x <> y" is a notation for "not (eq x y)" [Wed Jan 4 15:25:49 2017] and AFAIK "unfold" is for unfolding definitions (in that case, "not") and not detailing notations [Wed Jan 4 15:26:48 2017] you can use "Unset Printing Notations." but that will hide all the notations [Wed Jan 4 15:27:11 2017] You'll notice that [unfold "~"] will actually also "unfold" anything involving <>, since it seems to be just the same as [unfold not] [Wed Jan 4 15:35:12 2017] The strange this is that "~" is also a notation, but unfold "~" works. :/ [Wed Jan 4 15:36:21 2017] The tactic mechanism probably recognized "~" as being a literal synonym for "not", whereas "_ <> _" is a more complicated expression [Wed Jan 4 15:36:27 2017] Maybe the problem is that we have this: [Wed Jan 4 15:36:29 2017] Notation "x <> y :> T" := (~ x = y :>T) : type_scope. [Wed Jan 4 15:36:32 2017] Notation "x <> y" := (x <> y :>_) : type_scope. [Wed Jan 4 15:36:53 2017] "<>" is a notation for another notation ... [Wed Jan 4 15:38:02 2017] but, yeah, as you say, "unfold not" works. i was only wondering because unfold is easier when you do not know the definition of some notation thing. [Wed Jan 4 15:39:04 2017] cic: https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic145 [Wed Jan 4 15:39:07 2017] "unfold string: If string denotes the discriminating symbol of a notation (e.g. "+") or an expression defining a notation (e.g. "_ + _"), and this notation refers to an unfoldable constant, then the tactic unfolds it." [Wed Jan 4 15:39:30 2017] notations are just a display thing, whereas "unfold" actually replaces a constant by its definition [Wed Jan 4 15:39:49 2017] here, <> is not an unfoldable *constant* [Wed Jan 4 15:40:18 2017] are there ABT-like tools for coq [Wed Jan 4 15:40:28 2017] and what is the definition of unfoldable? :p [Wed Jan 4 15:40:36 2017] i wanna try messing around with formalizing some logic stuff, but im not super interested in the details of substitution atm [Wed Jan 4 15:41:32 2017] a constant can be unfoldable or not. For instance, a lemma proved with a "Qed." at the end is opaque/non unfoldable. [Wed Jan 4 15:41:46 2017] (but if you finish the prove with "Defined.", then it's transparent/unfoldable) [Wed Jan 4 15:45:18 2017] hm, the error message didn't say anything about <> being non-unfoldable, it said something about being unable to interpret <> as a reference [Wed Jan 4 15:45:41 2017] artart78 did insist on the word *constant* [Wed Jan 4 15:46:04 2017] in this case, the problem is not the unfoldability of a constant; it is that the notation "_ <> _" does not refer to any constant [Wed Jan 4 15:48:08 2017] sorry but why isn't it a constant, it refers to another notation that is simply a notation for "not (x = y)" and some bird smiley (:>)? [Wed Jan 4 15:48:31 2017] I guess the bird thing is from the definition of eq/=. [Wed Jan 4 15:48:47 2017] what we call a constant is a name, basically [Wed Jan 4 15:48:55 2017] oh, where "x = y :> A" := (@eq A x y) : type_scope. [Wed Jan 4 15:49:19 2017] There is not a single name that is tied to the notation "_ <> _", but a more complex expression [Wed Jan 4 15:49:37 2017] To show the difference, you could do this: [Wed Jan 4 15:50:04 2017] Definition neq {A : Type} (x y : A) := ~ x = y. Notation "x <=> y" := (neq x y) (at level 20). [Wed Jan 4 15:50:17 2017] Now "<=>" is a notation referring to the constant "neq" [Wed Jan 4 15:50:35 2017] so [unfold "<=>"] will work [Wed Jan 4 15:56:31 2017] hm, ok, and "x <> y" is not a constant because the _ part in the definition? [Wed Jan 4 15:57:20 2017] No, simply because the expression that "x <> y" refers to is "not (x = y)", which is a compound expression, not just the application of a constant to the arguments [Wed Jan 4 15:57:39 2017] What constant would be "x <> y" referring to? (remember, "constant" means one single name) [Wed Jan 4 16:00:47 2017] hm, this seems like a fairly arbitrary limitation to me, other parts of the system can understand this notation ... but thanks for the explanations. [Wed Jan 4 16:01:32 2017] It's more like an expansion of what "unfold" is capable to handle. In its most simple form, it just takes a constant as an argument and nothing else (so no notation). [Wed Jan 4 16:02:02 2017] It happens that they extented it so that it can also take notations that are synonymous to a constant as an argument [Fri Jan 6 13:05:12 2017] 15:40 are there ABT-like tools for coq [Fri Jan 6 13:05:14 2017] 15:40 i wanna try messing around with formalizing some logic stuff, but im not super interested in the details of substitution atm [Fri Jan 6 13:05:48 2017] oh, this looks relevant https://www.ps.uni-saarland.de/autosubst/ [Fri Jan 6 13:05:50 2017] :| [Fri Jan 6 15:34:26 2017] I always thought the parameters to inductive types (and bound for constructors) defined through the Vernacular "Inductive" were syntactic sugar for functions wrapping the constructors, e. g.: "Inductive list : (A : Set) := | nil : list A | cons : A -> list A -> A." = "Inductive list : Set -> Set := | nil : (fun A : Set => list A) | cons : (fun A : Set => A -> list A -> list A)." But apparently this is not the case, as Coq does not [Fri Jan 6 15:34:26 2017] accept the second definition. Unless it is implicitly doing some binding itself? [Fri Jan 6 15:36:33 2017] It could of course be a single function wrapping the inductive type as in Eduardo Giménez's 1994 paper. [Fri Jan 6 16:23:07 2017] Never mind, I was being silly, a function is of a function type, which is not a valid kind. [Fri Jan 6 16:50:19 2017] mettekou: hmm, whta? [Fri Jan 6 16:50:26 2017] coq doesn't have kinds that are separate from types [Fri Jan 6 16:50:28 2017] there are just types, the end [Fri Jan 6 16:52:53 2017] benzrf: Not separate from types, but they are there. By "not a valid kind", I meant to say "not a proper kind". The types of every constructor for an inductive type need to be in Set (Giménez, 1994), which is why I was concerned about the implementation of inductively defined types with parameters. [Fri Jan 6 16:53:56 2017] oh wait, i see what you meant [Fri Jan 6 16:54:00 2017] oops just misread [Fri Jan 6 16:54:17 2017] thought you meant that something of an ordinary function type couldnt be a "type constructor" because function types arent constructor kinds [Fri Jan 6 16:54:20 2017] which would be wrong [Fri Jan 6 16:55:33 2017] benzrf: Constructors don't need to be in Set (or Prop or Type, I only mentioned Set because Giménez does not concern himself with computational relevance and universe hierarchies in his paper) then? [Fri Jan 6 16:56:05 2017] er... i don't think so [Fri Jan 6 16:56:10 2017] i don't know a ton about the universe hierarchy ,sorry [Fri Jan 6 16:56:13 2017] benzrf: Do you have an example of a constructor of which the type is not in Set (or Prop or Type), modulo the parameters of the inductive type? [Fri Jan 6 16:56:33 2017] i don't know, sorry :P [Fri Jan 6 16:56:41 2017] it's not an important thing, nvm [Fri Jan 6 16:57:04 2017] It is when you're implementing the calculus of inductive constructions yourself, as I am. [Fri Jan 6 16:57:36 2017] i meant that my complaint and note weren't important :) [Fri Jan 6 16:58:46 2017] Well they were valid, I misspoke, I meant to say "proper kind" instead of "valid kind". [Fri Jan 6 23:30:38 2017] benzrf: for the record, Coq does have a concept of kinds/sorts, which are Prop/Set/Type [Sun Jan 8 11:53:40 2017] is anyone knowledgeable about proving things about programs written using dependent destruction? In particular, my proof starts looking like (solution_left ...) from Program.Equality and I'm not quite sure how to proceed from here... [Sun Jan 8 11:55:24 2017] Usually, the lemmas like solution_left and such will simplify if they are given eq_refl. So you might want to eliminate the equality that solution_left uses. However it might not be easy to do, so really, it might depend on your case... [Sun Jan 8 11:56:05 2017] Also some lemmas are more complicated to eliminate: it won't necessarily compute (for instance if it uses K as an axiom), but you might still be able to prove propositionally what you want [Sun Jan 8 11:57:28 2017] (solution_left/right are really just eq_rect by the way) [Sun Jan 8 12:12:09 2017] Cypi: if you'd like to see my current problem (self-contained, skip to (*** PROBLEM ***) for the important context): http://paste.awesom.eu/1mqb [Sun Jan 8 12:15:45 2017] Weeell, just "reflexivity" does the job actually [Sun Jan 8 12:15:57 2017] you're in a case where everything computes just fine [Sun Jan 8 12:16:51 2017] more step-by-step: unfold solution_left, eq_rect_r, eq_rect., you can see a match on "eq_sym eq_refl", so this should simplify (and it does, "simpl" works at this point) [Sun Jan 8 12:56:35 2017] thanks, didn't realize that... [Sun Jan 8 13:01:04 2017] other question: how do I get access to the commutative without having to unpack the class? http://paste.awesom.eu/IyN4 do I need some sort of Coercion? or some different way of defining the hierarchy? [Sun Jan 8 17:56:31 2017] how do i use a tactic in an expression, again? [Sun Jan 8 18:48:19 2017] ltac:(tactic) [Sun Jan 8 18:48:26 2017] if you have Coq 8.5 [Sun Jan 8 18:55:16 2017] (3 + ((fun a => ltac:(apply a)) 10)) [Sun Jan 8 18:55:17 2017] this is fun [Sun Jan 8 20:25:18 2017] thx johnw [Sun Jan 8 20:25:28 2017] hey, anyone know about modules? [Sun Jan 8 20:25:34 2017] i am having a confusion [Sun Jan 8 20:25:37 2017] better to just ask your question :) [Sun Jan 8 20:25:54 2017] ok well [Sun Jan 8 20:25:59 2017] i am doing this: [Sun Jan 8 20:26:02 2017] Module Type Theory (Sig : Signature). [Sun Jan 8 20:26:04 2017] Module Lang := FOLLang Sig. [Sun Jan 8 20:26:06 2017] Import Lang. [Sun Jan 8 20:26:23 2017] but then when i try to do a module later to instantiate this type, it complains that i am not defining the Lang field! [Sun Jan 8 20:26:38 2017] so apparently this creates a field 'Lang' that it wants me to fill [Sun Jan 8 20:26:40 2017] huh?? [Sun Jan 8 20:26:53 2017] interesting [Sun Jan 8 20:36:09 2017] johnw: plz help :( [Sun Jan 8 20:36:37 2017] it doesn't ring any bells here [Sun Jan 8 20:36:55 2017] don't do that? [Sun Jan 8 20:37:18 2017] why are you importing a module into a module type anyway, rather than into a regular functor? [Sun Jan 8 20:37:38 2017] because theories are parameterized over signatures [Sun Jan 8 20:37:57 2017] i cant define the theory of peano arithmetic except as a theory over the relevant signature [Sun Jan 8 20:37:58 2017] but do theories usually import modules? [Sun Jan 8 20:38:14 2017] i know functors do, but theories? [Sun Jan 8 20:38:26 2017] huh? [Sun Jan 8 20:38:50 2017] can you ask a question to clarify what didn't make sense? [Sun Jan 8 20:39:04 2017] i dont have to import it, but i dont think i can avoid defining it if i want to reference Lang.formula [Sun Jan 8 20:39:15 2017] why are you using Module Type Theory (Sig : Signature). instead of Module Theory (Sig : Signature). [Sun Jan 8 20:39:41 2017] because i have [Sun Jan 8 20:39:49 2017] Module Deduction (Thy : Theory). [Sun Jan 8 20:40:46 2017] that's not a reason [Sun Jan 8 20:40:49 2017] you can do: [Sun Jan 8 20:40:52 2017] Module Deduction. [Sun Jan 8 20:40:57 2017] Module Import Thy := Theory. [Sun Jan 8 20:41:34 2017] I need to know why you need it to be a module type, not just beacuse you're trying to use it as one [Sun Jan 8 20:41:50 2017] i dont know what Module Import does [Sun Jan 8 20:41:59 2017] module types usually just contain a bunch of parameters and axioms [Sun Jan 8 20:42:03 2017] yes [Sun Jan 8 20:42:10 2017] Module Import is the same as Module followed by Import [Sun Jan 8 20:42:11 2017] that's what Theory contains [Sun Jan 8 20:42:22 2017] it contains more than that, because you're importing a module into it! [Sun Jan 8 20:42:34 2017] Module Type Theory (Sig : Signature). [Sun Jan 8 20:42:37 2017] Module Lang := FOLLang Sig. [Sun Jan 8 20:42:39 2017] Parameter axiom : Type. [Sun Jan 8 20:42:41 2017] Parameter ax_inj : axiom -> Lang.formula. [Sun Jan 8 20:42:43 2017] End Theory. [Sun Jan 8 20:43:01 2017] that's a lot more than just parameters [Sun Jan 8 20:43:09 2017] that two parameters plus the whatever Lang contains [Sun Jan 8 20:43:28 2017] anyway, try doing this without use a module type [Sun Jan 8 20:43:32 2017] just use module functors [Sun Jan 8 20:43:34 2017] i [Sun Jan 8 20:43:37 2017] what? [Sun Jan 8 20:43:56 2017] then how do i do Module Deduction (Thy : Theory) [Sun Jan 8 20:44:04 2017] you wouldn't [Sun Jan 8 20:44:25 2017] here's another way [Sun Jan 8 20:44:29 2017] Module Type Theory (Sig : Signature). [Sun Jan 8 20:44:38 2017] Parameter formula : Type. [Sun Jan 8 20:44:43 2017] Parameter axiom : Type. [Sun Jan 8 20:44:50 2017] Parameter ax_inj : axiom -> formula. [Sun Jan 8 20:44:51 2017] End Theory. [Sun Jan 8 20:44:55 2017] but then i don't get to assume that formula is as i defined it [Sun Jan 8 20:45:34 2017] you can instantiate the module signature by plugging in Lang.formula for formula [Sun Jan 8 20:46:29 2017] i've got to go, good luck [Sun Jan 8 20:46:38 2017] i dont understand [Sun Jan 8 20:46:59 2017] augh [Mon Jan 9 08:44:00 2017] so it seems a new behavior when using e-tactics is to shelve the dependent premises, and I find it annoying, is there a way around this? [Mon Jan 9 08:44:32 2017] for instance if need to construct a record { plus: T -> T -> T; prop: SomethingAbout plus; } [Mon Jan 9 08:44:46 2017] where building the plus would be easier done in tactic mode [Mon Jan 9 08:45:31 2017] and Unshelve does not bring the goal forward :( [Mon Jan 9 10:06:01 2017] Ptival: you can use "unshelve tac" to immediately unshelve anything that the tactic generated and shelved [Mon Jan 9 10:23:14 2017] Is there a good resource out there on the implementation of Ltac? There's a paper describing the operational semantics and properties of Mtac, but I can't seem to find such a paper (or even a less formal resource) on Ltac's semantics or implementation. [Mon Jan 9 15:25:32 2017] are there any experts on modules here [Mon Jan 9 15:26:07 2017] i am extremely confused as to the mechanics of unification of stuff defined in various modules [Mon Jan 9 15:26:17 2017] which should absolutely be definitionally equal [Mon Jan 9 15:46:28 2017] unrelated, but i also have a question about binding levels and stuff, if anyone can answer [Mon Jan 9 15:55:03 2017] :I [Mon Jan 9 16:07:53 2017] [G |- forall1, b -> P] should be parsed as [(G |- (forall1, b)) -> P], but it seems to be parsed as [G |- ((forall1, b) -> P)] [Mon Jan 9 16:08:21 2017] [Reserved Notation "G |- p" (at level 75)] and [Notation "'forall1' , p" := (uni p) (at level 80)] [Mon Jan 9 16:09:20 2017] (when i say 'should be', i mean that i want it to be parsed that way) [Mon Jan 9 16:14:53 2017] ...huh. i made "|-" at 85, and that seems to have fixed it [Mon Jan 9 16:14:58 2017] i don't understand why, though! [Mon Jan 9 22:04:13 2017] omg i hate this [Mon Jan 9 22:04:23 2017] wrote up a whole function but its not clear enough that the argument is decreasing [Mon Jan 9 22:04:26 2017] ahghgh [Tue Jan 10 00:48:50 2017] benzrf: You can use Program construct https://coq.inria.fr/refman/Reference-Manual027.html and see goals are solved automatically or not. [Tue Jan 10 00:49:10 2017] benzrf: I haven't experimented much with this [Tue Jan 10 01:03:45 2017] https://scontent-ord1-1.xx.fbcdn.net/v/t31.0-8/15391486_219157441863379_3019041884290281398_o.jpg?oh=1a0af7c83076ca5ac5b9e89853846057&oe=58DA761D [Tue Jan 10 09:01:06 2017] is there a known thing about type classes not resolving past depth 10? [Tue Jan 10 11:05:20 2017] Does anyone know why Coq accepts the first definition, but rejects the second? https://gist.github.com/mettekou/00a03d98eeb1037056fe7d543138a480 [Tue Jan 10 11:07:16 2017] http://adam.chlipala.net/cpdt/html/Universes.html look for your error message. You can also check another explanation at https://coq.inria.fr/refman/Reference-Manual006.html [Tue Jan 10 11:08:28 2017] The problem is that in the second case, "A : Set" is an actual argument for the constructors (and Set is in Type). In the first case, it is just a parameter for the whole inductive type [Tue Jan 10 11:09:43 2017] parameters are nicer to use, since you have the guarantee that they are uniform over all constructors. So defining an inductive type with a parameter is really the same as defining as many inductive types as there are possible values for this parameter [Tue Jan 10 11:10:31 2017] and you can consider each of these inductive types individually and it makes sense on its own. With indices (your second case), this is not necessarily the case: considering just one possible index does not make sense in general [Tue Jan 10 11:11:38 2017] For instance, if you take "Inductive vect : nat -> Set := nil : vect O | cons : forall n, nat -> vect n -> vect (S n).", it does not really make sense to consider only the elements of "vect 1" without talking about the elements of "vect O" [Tue Jan 10 11:31:20 2017] Cypi: My confusion wasn't from the standpoint of a user of Coq, but came from misreading part of Codifying Guarded Definitions with Recursive Schemes (Giménez, 1994). I didn't understand how a parameter to an inductive type, desugared as a lambda abstraction over that inductive type played nicely with top-level definitions of constructors. But I see which trick the parser and type checker use now. Thanks! [Tue Jan 10 18:38:31 2017] hi all, I'm trying to understand terms generated by omega (i have a real reason, i promise) -- but as part of these terms I get these periods, e.g. "(fun x : Z => (0 <= x + .)%Z -> False)" [Tue Jan 10 18:38:56 2017] does anyone know what these are? if i try to write it as a definition i can't get it to even lex, and type inference fails if i try placeholders [Tue Jan 10 18:39:27 2017] set printing all also doesn't expand them in any way [Tue Jan 10 18:39:46 2017] Do you have a (preferably small) example of this? I'm curious [Tue Jan 10 18:40:53 2017] The omega term isn't small but if you can reproduce it locally: [Tue Jan 10 18:41:32 2017] (this is a purposely dumb theorem and proof): Theorem OmegaBasic: forall (n m p : nat), n <= m -> m <= p -> n <= p + 17. Proof. intros. omega. Qed. [Tue Jan 10 18:41:39 2017] thanks [Tue Jan 10 18:42:00 2017] i am in coqide, so it could also be coqide, curious if you're in ProofGeneral if it actually expands it [Tue Jan 10 18:42:51 2017] hey, if i have a type like so: [Tue Jan 10 18:42:53 2017] I'm in CoqIDE, and I don't get anything strange [Tue Jan 10 18:43:08 2017] I can copy/paste what "Show Proof" gives me and give it to "exact" [Tue Jan 10 18:43:19 2017] Inductive tree := | leaf : nat -> tree | node : list tree -> tree. [Tue Jan 10 18:43:28 2017] can i somehow generate an induction principle that actually works? [Tue Jan 10 18:43:44 2017] benzrf: you can't easily generate it, but you can certainly write one yourself [Tue Jan 10 18:43:49 2017] :\ [Tue Jan 10 18:44:00 2017] man... that's irritating [Tue Jan 10 18:44:16 2017] It's not that easy to know automatically what's a relevant induction principle for nested inductive types [Tue Jan 10 18:44:30 2017] can't i nudge coq using some command? [Tue Jan 10 18:44:33 2017] Cypi really? can you send me your term? I have periods in there that break the lexer, even if I pass it to exact [Tue Jan 10 18:45:05 2017] http://lpaste.net/351088 here it is [Tue Jan 10 18:45:08 2017] thanks [Tue Jan 10 18:45:16 2017] (relatedly, it is also a huge pain to define recursive functions over this type) [Tue Jan 10 18:45:23 2017] benzrf: not currently I don't think [Tue Jan 10 18:45:32 2017] huh, your term is different from mine [Tue Jan 10 18:45:56 2017] I'm in 8.5 [Tue Jan 10 18:46:28 2017] 8.5pl3 to be precise (I think it's the .dev version, not exactly pl3, but close enough) [Tue Jan 10 18:46:31 2017] OK -- it looks actually like your periods are just expanded. maybe i'll need to upgrade coq. good to know. thanks! [Tue Jan 10 18:46:46 2017] So I'm curious: what are they expanded to? [Tue Jan 10 18:47:48 2017] i wish the answer to that were short, but pretty everything fast_Zred_factor6 is applied to [Tue Jan 10 18:48:11 2017] ok [Tue Jan 10 18:48:22 2017] strange [Tue Jan 10 18:48:25 2017] like, I have: [Tue Jan 10 18:49:16 2017] http://lpaste.net/351089 [Tue Jan 10 18:50:15 2017] I wonder if it might just be the printer, but that would be strange [Tue Jan 10 18:50:25 2017] I mean, in the sense that it doesn't want to printe something to deep or something [Tue Jan 10 18:50:27 2017] I don't know :) [Tue Jan 10 18:51:05 2017] it looks like they are different in more ways on close look actually, so i can't control for that vs. different versions of omega [Tue Jan 10 18:51:15 2017] mysterious [Tue Jan 10 18:52:24 2017] while i wait to install 8.5, would you be willing to send me the term you get when the conclusion is n <= p instead of n <= p + 17? [Tue Jan 10 18:53:05 2017] i know there's a lemma for it, just comparing omega terms as a learning experience [Tue Jan 10 18:53:59 2017] http://lpaste.net/351090 [Tue Jan 10 18:54:10 2017] thanks a ton [Tue Jan 10 18:54:20 2017] no problem [Tue Jan 10 18:55:41 2017] this sucks so much [Tue Jan 10 18:56:30 2017] It looks like it is the printer -- the term you sent works fine, but when I print it i get the same periods in my term [Tue Jan 10 18:57:34 2017] Cypi: if i write my own induction principle, will i be able to invoke it with [induction] or something, or will i need to use super verbose [apply] [Tue Jan 10 18:58:52 2017] benzrf: you can use "induction ... using ..." [Tue Jan 10 18:59:04 2017] it expects a certain shape for the induction principle, but I don't remember what it is x) [Tue Jan 10 18:59:28 2017] you sure there's nothing straightforward for nested types? :( [Tue Jan 10 18:59:34 2017] I'm not sure, no [Tue Jan 10 18:59:39 2017] heuh [Tue Jan 10 18:59:47 2017] but I'd be surprised [Tue Jan 10 19:02:18 2017] hmm... i see "inversion using" but not "induction using" [Tue Jan 10 19:03:00 2017] https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic79 in the variants of "induction", there is "induction term1 using term2" [Tue Jan 10 19:03:16 2017] ah! thanks [Wed Jan 11 00:15:25 2017] is there a Type version of Vector.Forall [Wed Jan 11 08:42:01 2017] hi [Wed Jan 11 15:10:21 2017] (Linux, ocaml 4.04, coq from git) When attempting to run ./configure or ocaml configure.ml I immediately get the following exception: https://ptpb.pw/8dof [Wed Jan 11 15:11:41 2017] i'd report a bug on the issue tracker [Wed Jan 11 15:11:43 2017] or ask teh ML [Wed Jan 11 15:12:24 2017] Hm, okay thanks [Wed Jan 11 15:22:01 2017] johnw: https://coq.inria.fr/bugs/show_bug.cgi?id=5307 [Wed Jan 11 15:40:40 2017] someone should see it fairly soon [Wed Jan 11 16:02:42 2017] Hopefully it's just a small oversight in the latest development code [Wed Jan 11 16:11:56 2017] i'm sure that's it [Thu Jan 12 03:07:12 2017] hi [Thu Jan 12 03:32:58 2017] I have been playing with Program and vector and I think I found some inconsistencies [Thu Jan 12 03:33:20 2017] some errors suggest coq generate mistyped code [Thu Jan 12 03:34:44 2017] As long as it generates mistyped code but recognizes afterwards that it's mistyped, it's "fine" (still a bug, but not a severe one) [Thu Jan 12 03:35:03 2017] I wouldn't be surprised if Program could generate wrong terms indeed. Do you have an example though? [Thu Jan 12 03:41:22 2017] yes [Thu Jan 12 03:43:01 2017] https://gist.github.com/lethom/8d76dddecb8b343a9e7592764d42fa87 [Thu Jan 12 03:43:19 2017] the (dummy) implementation of map2 (at the very end) [Thu Jan 12 03:45:40 2017] hmm, yes, looks like a straight bug in De Bruijn indices manipulation :/ [Thu Jan 12 03:46:32 2017] I imagined something like that (minus the De Bruijn clue :p) [Thu Jan 12 03:48:57 2017] What is the best way to report that? Github? [Thu Jan 12 03:49:15 2017] https://coq.inria.fr/bugs/ the official bug-tracker [Thu Jan 12 03:50:00 2017] it makes sense, thank you (I could have look [Thu Jan 12 03:50:04 2017] ed a little more) [Thu Jan 12 03:50:20 2017] no problem [Thu Jan 12 03:50:40 2017] Hmm, even what I believe would be a correct version of map2 does not go through, that's annoying :/ [Thu Jan 12 03:51:14 2017] I was able to implement something, using nested pattern matching [Thu Jan 12 03:51:32 2017] and by avoiding placeholders [Thu Jan 12 03:51:44 2017] good then :) [Thu Jan 12 03:52:03 2017] my issue was the extracted code was a bit disappointing [Thu Jan 12 03:53:24 2017] not close enough to what you would have written directly? [Thu Jan 12 03:53:54 2017] well there is two issues I found and I do not [Thu Jan 12 03:54:02 2017] know if it is possible to avoid them [Thu Jan 12 03:55:18 2017] but the main one is that it wraps the result in some Exist types [Thu Jan 12 03:55:30 2017] actually the same way the commented version of map2 does [Thu Jan 12 03:57:23 2017] (actually, not quite the same, sorry..( [Thu Jan 12 03:59:00 2017] If I extract the version you commented, I actually get something quite good enough [Thu Jan 12 03:59:11 2017] (after inlining a few other definitions...) [Thu Jan 12 04:02:01 2017] can you give me your extraction calls? [Thu Jan 12 04:02:49 2017] Unset Extraction SafeImplicits. Extraction Inline solution_left solution_right simplification_heq map2_obligation_1. Extraction map2. [Thu Jan 12 04:03:03 2017] I'm no expert on extraction, so I'm not even sure why I need the first command :) [Thu Jan 12 04:04:27 2017] It is my fault, actually (I tried to make the first argument of vcons implicit but it is not that simple) [Thu Jan 12 04:04:36 2017] thanks! [Thu Jan 12 04:04:45 2017] https://gist.github.com/lethom/11f938f54ba3462e44703f85cbca8409 what I ran into [Thu Jan 12 04:05:18 2017] I wonder, which version of Coq are you using? [Thu Jan 12 04:05:57 2017] the trunk version of January 2nd [Thu Jan 12 04:06:08 2017] ok :o [Thu Jan 12 04:07:21 2017] thanks for the inlining tip [Thu Jan 12 04:08:08 2017] oh, the Admitted seem to mess up with it though [Thu Jan 12 04:08:35 2017] Hopefully when you'll complete your definition, the extraction will be better [Thu Jan 12 04:08:53 2017] Oh, it is good to know [Thu Jan 12 04:10:57 2017] I had some trouble completing the obligation though, but I didn'try for a while [Thu Jan 12 04:11:10 2017] thanks four your help anyway [Thu Jan 12 09:42:37 2017] hi. is there a complete formal specification of coq's type system? [Thu Jan 12 10:20:32 2017] schoppenhauer: depends on "complete formal", but yes i think so! [Thu Jan 12 10:20:41 2017] benzrf: where? [Thu Jan 12 10:20:46 2017] 1 sec [Thu Jan 12 10:22:01 2017] schoppenhauer: chapter 4 https://coq.inria.fr/distrib/current/files/Reference-Manual.pdf [Thu Jan 12 10:23:08 2017] benzrf: thank you [Thu Jan 12 10:23:16 2017] np [Thu Jan 12 10:51:16 2017] ok, on https://coq.inria.fr/distrib/current/files/Reference-Manual.pdf page 122, there is some {\cal S} out of nowhere. what does it mean? (In the rule W-Local-Assum, for example) [Thu Jan 12 10:53:44 2017] schoppenhauer: defined on page 119 [Thu Jan 12 10:53:47 2017] right at the bottom [Thu Jan 12 10:56:00 2017] benzrf: ah thx. I overread this. [Thu Jan 12 10:57:39 2017] heh [Sat Jan 14 11:45:18 2017] Hello! [Sat Jan 14 11:47:17 2017] Does somebody read me? [Sat Jan 14 11:48:06 2017] yes [Sat Jan 14 11:48:54 2017] usually on IRC you don't expect people to answer to just "Hello!", just ask your question :P [Sat Jan 14 11:49:29 2017] Thanks. I am learning Coq, and was searching for like minded people. :) [Sat Jan 14 11:50:41 2017] Last time when I used irc was long time ago :), so I should be excused for my ignorance [Sat Jan 14 11:51:34 2017] no problem :) [Sat Jan 14 11:55:39 2017] Dinno: https://www.xkcd.com/1782/ [Sat Jan 14 11:56:10 2017] Does somebody use Coq for programming? I mean certifying of programs [Sun Jan 15 22:05:52 2017] is there something like non-generative modules/functors that i can use, that won't suck [Tue Jan 17 02:42:39 2017] hi [Tue Jan 17 07:49:06 2017] hi [Tue Jan 17 11:01:43 2017] hi. does anyone know an example where the usage of a tactic blows up an extracted algorithm? [Tue Jan 17 11:04:01 2017] You mean a "usual" tactic? [Tue Jan 17 11:04:13 2017] because you could certainly write one that makes your algorithm blows up [Tue Jan 17 11:06:41 2017] yes, I mean a usual one. one argument against program extraction is often that you can have blowups … but I never had one, but that is because I mainly use tactics on stuff that has no computational content. [Tue Jan 17 11:07:37 2017] I wasn't really aware of this argument. If you mean to extract your program, then it seems obvious to me that you should be somewhat careful of you write it [Tue Jan 17 11:07:51 2017] me too [Tue Jan 17 11:08:05 2017] I cannot be sure, but there may be cases where using inversion or intuition might make terms bigger than they should be [Tue Jan 17 11:08:26 2017] I mean, I'm pretty sure there are such cases, but I don't think I'd be able to build one right now :) [Tue Jan 17 11:08:54 2017] (but again, using intuition while building a proof whose term is of some importance seems bad) [Tue Jan 17 11:08:56 2017] probably, but bigger terms are not really a problem. I mean the argument that "the extracted algorithms are not readable" is stupid imho, because you can usually not read the assembly that haskell generates, too. for me, extraction is a form of compilation. [Tue Jan 17 11:10:12 2017] I think I'll try something with omega first [Tue Jan 17 11:10:23 2017] as long as bigger doesn't mean slower, then yes [Tue Jan 17 11:10:48 2017] omega only solves goal in Prop, doesn't it? [Tue Jan 17 11:11:00 2017] (since they are equality/comparisons and so on of integers) [Tue Jan 17 11:11:09 2017] not sure [Tue Jan 17 11:11:22 2017] i thought there can be existential quantifiers in some situations [Tue Jan 17 11:11:54 2017] omega does not even solve "exists n, n = 0" [Tue Jan 17 11:11:57 2017] so I doubt it [Tue Jan 17 11:12:40 2017] does not solve it even if you do "eexists" first, it will not trigger a unification of the existential variable and 0 [Tue Jan 17 11:12:52 2017] hm. [Tue Jan 17 11:12:54 2017] ok, you are right. [Tue Jan 17 11:14:52 2017] Well, I never liked this argument anyway, because being able to make inefficient programs look efficient is something you can always do with abstraction. [Tue Jan 17 11:18:45 2017] Sure, but having something readable, and not only readable, something which is what you would have written yourself, is a convincing argument for the efficiency of your program [Tue Jan 17 11:19:30 2017] When I wrote a fairly complicated substitution function whose type proved its correctness and termination, I was quite happy to see that it extracted to what I would have written directly in OCaml [Tue Jan 17 11:38:30 2017] ok, so here's the problem i'm having. [Tue Jan 17 11:38:42 2017] i'm defining a module functor which contains an inductive typedef [Tue Jan 17 11:39:01 2017] let's call it F [Tue Jan 17 11:39:13 2017] but then - suppose i want to define two other functors over the same type of argument, call them A and B [Tue Jan 17 11:39:43 2017] and it turns out that A depends on stuff in F, and B depends on stuff in A [Tue Jan 17 11:39:57 2017] er, B depends on F as well, oops [Tue Jan 17 11:40:21 2017] but this is unworkable, because in order to define stuff in A i have to apply F to an argument and then work over the result module [Tue Jan 17 11:40:38 2017] and then i need to do the same in B; apply both F and A to my argument [Tue Jan 17 11:41:47 2017] but then i can't use the stuff from F and from A together, because A also manually applies F, so it gets its own version of the inductive type which won't unify with the version from the F application in B [Tue Jan 17 11:41:53 2017] let me see about writing up a minimal example... [Tue Jan 17 11:42:31 2017] (i'm gonna rename these A, B, C) [Tue Jan 17 12:00:10 2017] https://gist.github.com/e933faa3b014123eb3c116c8129cf6a5 [Tue Jan 17 12:01:11 2017] johnw: there's an example of the issue i was struggling with, which i tried to ask about ^ [Tue Jan 17 12:02:10 2017] correct, this is expected behavior [Tue Jan 17 12:02:12 2017] modules are generative [Tue Jan 17 12:02:21 2017] there really are two definitions of A [Tue Jan 17 12:02:45 2017] I posted this same type of question to Coq-club last year [Tue Jan 17 12:04:08 2017] that's what i found out by googling :\ [Tue Jan 17 12:04:15 2017] so - what should i do instead, then? [Tue Jan 17 12:04:22 2017] how do i approach this pattern? [Tue Jan 17 12:05:03 2017] use sections and variables, instead of modules, if you need only one 'foo' [Tue Jan 17 12:06:08 2017] but if i have more than one section, i can't pleasantly use the stuff in the old one with variables in the new one... [Tue Jan 17 12:06:43 2017] you can if you redefine them in the new section [Tue Jan 17 12:07:07 2017] can you link an example or something? [Tue Jan 17 12:07:14 2017] I don't have anything handy [Tue Jan 17 12:07:25 2017] well, i just mean - [Tue Jan 17 12:07:44 2017] even if i redefine variables in the new section, the definitions in the old section will need to be explicitly passed the new variables [Tue Jan 17 12:07:47 2017] which is a pain [Tue Jan 17 12:20:05 2017] I mean, repeat the old definitions [Tue Jan 17 12:20:25 2017] Section foo. Variable x. Definition Blah. End Foo. Section new. Variable y. Definition Blah := Blah y. End new. [Tue Jan 17 12:20:47 2017] oh [Tue Jan 17 12:20:49 2017] ew :| [Tue Jan 17 12:20:52 2017] it works [Tue Jan 17 12:21:00 2017] yeah, but what if i have a whole lot of definitions? [Tue Jan 17 12:21:09 2017] find an editor that has macros [Tue Jan 17 12:21:18 2017] that's kind of a hack solution [Tue Jan 17 12:21:22 2017] well, you're not going to be able to change how modules behave [Tue Jan 17 12:22:58 2017] ;-; [Tue Jan 17 13:42:34 2017] i'm getting a type error but the two types seem to obviously reduce to the same thing [Tue Jan 17 13:42:41 2017] i think it might involve existentials [Tue Jan 17 13:43:09 2017] any suggestions? the two types are [Fin.t (S v)] and [Fin.t (term_free ?t@{t1:=& v})] [Tue Jan 17 13:43:22 2017] [term_free &v] immediately reduces to S v [Tue Jan 17 13:44:33 2017] i've found that when dependent types are involved, two types that are "equal up to simpl" are not necessarily found to be equal, except by JMeq [Tue Jan 17 13:44:39 2017] :( [Tue Jan 17 13:44:55 2017] but i literally don't see why this would be an issue [Tue Jan 17 13:45:05 2017] it previously typechecked when i was using modules - now i'm using sections and it breaks [Tue Jan 17 13:45:29 2017] so im squinting leerily a bit at implicits and existentiald [Tue Jan 17 13:45:32 2017] *existentials [Tue Jan 17 13:46:03 2017] the types are as equal as you think, there's a layer in between that simpl is able to get rid of, but type equality doesn't necessarily "run simpl" [Tue Jan 17 13:46:07 2017] aren't* [Tue Jan 17 13:46:57 2017] ehhhhhhh [Tue Jan 17 13:47:37 2017] I don't understand fully why, I've just noticed this before [Tue Jan 17 13:48:27 2017] my experience has usually been that when it seems like two things should unify but they don't, it's because there's a variable that isn't being "expanded" on the inside of a match [Tue Jan 17 13:48:53 2017] like [S x] won't unify with [y] even though the expression where it needs to unify is inside a clause where i've matched [y] with [S x] [Tue Jan 17 13:49:00 2017] but this isn't a case like that [Tue Jan 17 13:51:30 2017] i don't need *any* kind of external knowledge about what any of the variables are, to know that these reduce correctly, except for the definition of term_free, which is not opaque [Tue Jan 17 13:52:43 2017] wtf [Tue Jan 17 13:52:49 2017] if i add an annotation the problem vanishes [Tue Jan 17 13:52:53 2017] seriously w t f [Tue Jan 17 13:54:16 2017] "annotation"? [Tue Jan 17 13:54:22 2017] oh, and. [Tue Jan 17 13:54:31 2017] there was a type error in the other branch because i forgot to bind a variable [Tue Jan 17 13:54:36 2017] and once i fixed that i dont even need an annotation [Tue Jan 17 13:54:38 2017] ?!?!? [Tue Jan 17 13:54:49 2017] er, like (3 : nat) instead of 3 [Tue Jan 17 13:57:08 2017] are there multiple notational definitions for 3 in scope? Do you have N or Z or Q imported? [Tue Jan 17 13:57:42 2017] that was just an example [Tue Jan 17 13:57:47 2017] ah [Tue Jan 17 13:57:51 2017] wait, you can override nat notation? [Tue Jan 17 13:57:58 2017] oh, just by rebinding S? [Tue Jan 17 13:58:01 2017] huh? [Tue Jan 17 13:58:05 2017] "3" is not a nat [Tue Jan 17 13:58:12 2017] 3%Z is a Z [Tue Jan 17 13:58:15 2017] yeah but i mean [Tue Jan 17 13:58:23 2017] i didnt know you could override numeral notation [Tue Jan 17 13:58:30 2017] yeah, you can do it in OCaml [Tue Jan 17 13:58:33 2017] oh [Tue Jan 17 13:58:42 2017] there's no Vernacular way to do it, unfortunately [Tue Jan 17 13:59:03 2017] however, I think you could write a plugin if you need other numeral literal types [Tue Jan 17 14:00:26 2017] o [Tue Jan 17 14:00:42 2017] I guess it doesn't come up often enough :) [Tue Jan 17 14:42:09 2017] There should be soon a way to do it directly on the Coq-side though [Tue Jan 17 14:42:19 2017] * checks if it's not already in 8.6... [Tue Jan 17 14:43:09 2017] Hmm, ok, maybe it wasn't done yet :/ [Tue Jan 17 14:46:11 2017] Ah right: https://github.com/coq/coq/pull/156 [Tue Jan 17 14:46:24 2017] so according to the label, it should be planned for 8.7 [Tue Jan 17 15:06:25 2017] cool [Tue Jan 17 15:23:13 2017] A researcher is looking for examples where a small change broke all your proofs: https://twitter.com/TaliaRinger/status/821444419677130752 [Tue Jan 17 15:54:45 2017] benzrf, johnw: You can stick the parameterized inductive outside the module, and then use modulues and functors for the definitions. [Tue Jan 17 15:59:55 2017] has anyone here used coq for hardware description before? [Tue Jan 17 16:00:41 2017] (I know there's FeSi) [Tue Jan 17 16:05:56 2017] johnw, benzrf: Also, re unificaiton, higher order unification is undecidable (related bugs: 5264, 5199, 5198, 5107, 5049, 4931, 4821, 4644, 4631, 4490, 4484, 4415, 4413, 4384 (this one is fun), 4231, 4154, 3515, 3445, 3419, 3395, 3284, 3141). The unification strategy that says "first run simpl" is not complete, and can be slow. It's a hard problem. [Tue Jan 17 16:06:38 2017] Oh, and [Notation "'3'" := foo.] is totally valid. :P You just can't write notations for all the numerals without OCaml yet. [Tue Jan 17 18:31:42 2017] WHY ARE NESTED RECURSIVE FIELDS MADE OF PAIN [Tue Jan 17 18:31:51 2017] * rocks back and forth, sobbing [Tue Jan 17 18:37:23 2017] i'm hoping you aren't using Coq because someone promised you pleasure [Tue Jan 17 18:37:50 2017] what it does is make the rest of life seem easier [Tue Jan 17 18:46:22 2017] lmao [Tue Jan 17 20:27:22 2017] anyone here using VST? [Tue Jan 17 20:36:11 2017] anyone here using VST? -- repeating due to netsplit [Wed Jan 18 09:45:46 2017] hey! [Wed Jan 18 09:46:15 2017] suppose i have an inductive type with a fairly large number of constructors, and one of the leaf constructors contains, say, a nat [Wed Jan 18 09:47:22 2017] then i want to do induction over the type, but i particularly want to know in this leaf-constructor's case, that the nat is <= the max leaf nat [Wed Jan 18 09:48:10 2017] i could of course write a max-leaf-nat functoin manually, prove a custom induction principle manually, and then manually apply that custom induction principle, but there would be an awful lot of repeated logic since there's a lot of constructors [Wed Jan 18 09:48:18 2017] is there any nice way to handle this kind of situation? [Wed Jan 18 17:20:16 2017] is there a way to recover the old non-shelving behavior for evars? [Wed Jan 18 17:24:47 2017] also, is it possible to disable all automatic indentation for ProofGeneral? I'm so tired of the default indenting rules... [Wed Jan 18 18:17:45 2017] benzrf: it sounds like you're describing induction-recursion [Wed Jan 18 18:18:01 2017] which Coq doesn't support :( [Wed Jan 18 18:18:12 2017] Soon(-ish)! [Wed Jan 18 18:18:16 2017] ooh, nice! [Wed Jan 18 18:18:30 2017] Don't take my word for it. There is already an experimental branch that implements it [Wed Jan 18 18:18:40 2017] i've really wanted it exactly once [Wed Jan 18 18:19:48 2017] benzrf: can you break your data type up into two parts? [Wed Jan 18 18:20:00 2017] Ptival: I don't think so (about evars) :( . Locally, you can prefix the tactic by "unshelve ..." [Wed Jan 18 18:20:06 2017] the core datatype, and then a "constructor" data type, that inductively predicates how your core datatype may be lawfully constructed [Wed Jan 18 18:20:18 2017] that way, you can do recursion on the first data type from the constructors of the second [Wed Jan 18 18:20:50 2017] so, a Foo might have bad leaves, but a Good Foo cannot [Wed Jan 18 18:21:19 2017] If I understand their problem correctly, they don't have "correct" values, they are all correct, they just want a practical way to have a proof that the "nat" from a leaf is <= to the max of every leaves [Wed Jan 18 18:21:35 2017] (which will always be the case of course, it's just not immediate) [Wed Jan 18 18:21:48 2017] if it's inferrably always the case, then a separate proof should be sufficient, no? [Wed Jan 18 18:22:40 2017] that basically amounts to what they wrote next I think? ("i could of course write a max-leaf-nat function manually...") [Wed Jan 18 18:22:52 2017] but yes, that is what I would do [Wed Jan 18 18:34:03 2017] Cypi: I found out I could use "simple refine" [Wed Jan 18 18:34:52 2017] other question, is there a way to have "Definitions" whose names are local to a section? [Wed Jan 18 18:35:10 2017] Let [Wed Jan 18 18:35:16 2017] it's really annoying to prefix everything to avoid conflicts for stuff that I don't even intend to be visible outside [Wed Jan 18 18:35:19 2017] ah [Wed Jan 18 18:37:02 2017] benzrf: ah yeah, but with Let, the body gets immediately unfolded in proofs :\ [Wed Jan 18 18:37:31 2017] in the context [Wed Jan 18 18:38:14 2017] ah [Wed Jan 18 18:38:17 2017] then Local [Wed Jan 18 18:38:18 2017] i think [Wed Jan 18 18:38:32 2017] *Local Definition [Wed Jan 18 18:38:48 2017] oops that's for modules [Wed Jan 18 18:38:49 2017] no that does not work I think :( [Wed Jan 18 18:38:54 2017] ah yeah [Wed Jan 18 18:38:59 2017] I think for sections I'm doomed [Wed Jan 18 18:39:01 2017] huh [Wed Jan 18 18:39:23 2017] yeah I can't use Let, these functions are like 100 lines so my context becomes unreadable [Wed Jan 18 18:39:29 2017] haha [Wed Jan 18 18:39:43 2017] I'm really tired of the way context printing can't be hacked [Wed Jan 18 18:39:49 2017] should keep working on my frontend :( [Wed Jan 18 19:50:53 2017] is anyone familiar with the whole .class .class_of .Pack way of building canonical structures? [Wed Jan 18 19:51:32 2017] in particular, I want to use some operations that have been defined with Context {G : AbelianGroup} when I have in context something that contains an AbelianGroup.class_of somewhere [Wed Jan 18 19:51:36 2017] Ptival: I believe there's a paper about it [Wed Jan 18 19:51:55 2017] johnw: yeah I think I know which ones (the math-comp ones?) [Wed Jan 18 19:52:04 2017] yeah [Wed Jan 18 19:54:45 2017] I think my problem is that in definitions such as http://coquelicot.saclay.inria.fr/html/Coquelicot.Hierarchy.html#AbelianGroup1 [Wed Jan 18 19:55:33 2017] you can only mention zero when you have a concrete AbelianGroup, not when you have a hypothetical AbelianGroup.class_of T [Thu Jan 19 00:28:55 2017] Ptival: Context hacking: Definition hide {T} {x : T} := x. Arguments hide {_ _}, {_} _. Let foo := hide (foo_body). [Thu Jan 19 15:45:17 2017] jgross: clever :) [Thu Jan 19 19:33:27 2017] Ptival: Another useful trick is "Notation hide := (some_head_constant _)." [Mon Jan 23 19:16:33 2017] Hi, everyone. I was using an alternative set of keybindings, but since 8.6 these seem to get overwritten. Are these still supported? [Tue Jan 24 08:54:07 2017] Hello! I have a question regarding 'autorewrite' tactic & ltac [Tue Jan 24 08:55:10 2017] Ltac autorw base:= autorewrite with base. [Tue Jan 24 08:55:16 2017] autorw fsmrw. [Tue Jan 24 08:55:48 2017] Error: rewrite base base does not exist. [Tue Jan 24 08:56:30 2017] rewriting bases are not something that you can bind with Ltac [Tue Jan 24 08:56:37 2017] I understand that 'base' is identifier, not an expression, so substitution does not take place here. But how can I accomplish this? [Tue Jan 24 08:56:49 2017] I don't know much about autorewrite, but I don't think you can accomplish this actually [Tue Jan 24 08:57:03 2017] Are there any ways to construct Ltac at runtime ? [Tue Jan 24 08:59:04 2017] You can always do stuff like "let autorw := autorewrite with fsmrw in ....", but I guess it's still not enough for what you want [Tue Jan 24 09:00:49 2017] Let construct does not do substitution for 'base' , I've tried that [Tue Jan 24 09:01:03 2017] Yeah it's the same: you can't bind a rewrite base [Tue Jan 24 09:01:15 2017] Thats really dissappoiting. [Tue Jan 24 09:01:20 2017] (unless there is a trick I don't know of) [Tue Jan 24 09:08:56 2017] Well, thanks anyway. As for know it means a lot of boilerplate tactic soup to come in my development. [Tue Jan 24 09:09:55 2017] If someone have a solution to this problem please let me know: evgeniy.shishkin@gmail.com [Wed Jan 25 05:57:57 2017] re [Wed Jan 25 06:55:44 2017] I have a question about existential variables. What premise do you need to proof P ?x. Or is this impossible? [Wed Jan 25 06:56:21 2017] * Or is this impossible, and you need more in the goal to instantiate ?x ? [Wed Jan 25 13:43:16 2017] Nik05: well, if you have some proof of (H : P y) for any given y, you can try to "apply H" [Wed Jan 25 13:44:27 2017] it will succeed unless there is a hidden thing about ?x that the given y does not satisfy (for instance, if ?x is expected to be at a lower universe than y, or if there are implicit arguments to P that differ) [Wed Jan 25 14:03:20 2017] or if some stuff in y has been defined after the evar as been defined [Wed Jan 25 14:03:26 2017] has* [Wed Jan 25 14:14:01 2017] ok thank you Ptival [Wed Jan 25 14:17:12 2017] Ptival Cypi oke when I apply something like H : P x, it says [Wed Jan 25 14:17:25 2017] Unable to unify ?x with "x" [Wed Jan 25 14:18:13 2017] because "x" is not in its scope [Wed Jan 25 14:18:24 2017] that means this 'x' was introduced after the evar was created [Wed Jan 25 14:20:31 2017] Oké, thank you Cypi [Wed Jan 25 14:21:18 2017] I guess this cannot be proven with intuistic logic [Wed Jan 25 14:21:57 2017] it's about swapping forall and exists [Wed Jan 25 14:22:37 2017] or not sure which logic it is, the one which says that if you have a forall x, P x then there exists an x : P x [Wed Jan 25 14:22:55 2017] I'm pretty sure there is no logic that tells you that [Wed Jan 25 14:23:14 2017] example: forall x : False, P x [Wed Jan 25 14:23:17 2017] since you can easily prove "forall (x : False), P x" for any [Wed Jan 25 14:23:20 2017] hehe [Wed Jan 25 14:23:20 2017] eh [Wed Jan 25 14:23:23 2017] that's maybe predicativity? [Wed Jan 25 14:23:40 2017] i never quite sure what predicativity is/does though. [Wed Jan 25 14:24:46 2017] "A definition is said to be impredicative if it generalizes over a totality to which the entity being defined belongs. Otherwise the definition is said to be predicative." [Wed Jan 25 14:25:00 2017] sorry "exists an x : P x" -> "exists x, P x" [Wed Jan 25 14:28:08 2017] I'm sorry, didn't you write twice the same thing? Maybe I'm parsing this wrong [Wed Jan 25 14:28:43 2017] yeah this looks wrongly-written [Wed Jan 25 14:28:55 2017] "x : P x" in particular [Wed Jan 25 17:07:53 2017] Cypi with : i meant such that not is of type [Wed Jan 25 17:08:49 2017] So you mean "exists x, (P x -> exists x, P x)"? [Wed Jan 25 17:09:42 2017] I don't think so [Wed Jan 25 17:09:50 2017] If that's what you mean, then once again, there is no logic when that can hold in general [Wed Jan 25 17:09:58 2017] where* [Wed Jan 25 17:10:05 2017] (I mean, no consistent logic) [Wed Jan 25 17:10:12 2017] That can not hold? [Wed Jan 25 17:10:57 2017] Not for every type and predicate: consider any (P : False -> Type), and now you can prove False [Wed Jan 25 17:11:47 2017] becase there exists no x in False? [Wed Jan 25 17:12:05 2017] Hopefully [Wed Jan 25 17:12:45 2017] I mean, there _should_ exist no x in False, but if you admit "exists x, (P x -> exists x, P x)" for any P, then you can build a term of type False by considering any (P : False -> Type) [Wed Jan 25 17:13:16 2017] Oké that makes sense for me now [Wed Jan 25 17:14:50 2017] I haven't studied logic, but I thought there are two logics that are different in the existence of . Oh wait [Wed Jan 25 17:16:09 2017] Something like "all flying teapots around Mars have the colour blue", in one logic this is a perfect sentence, while it isnt in the other. [Wed Jan 25 17:16:43 2017] Not sure if this has anything to do with anything I said earlier [Wed Jan 25 17:17:33 2017] What you said is basically "forall (x : False), P x" (there are no flying teapots around Mars, and we can assume anything about them) [Wed Jan 25 17:17:44 2017] and that, specifically, is provable [Wed Jan 25 17:19:17 2017] Oké, but isnt there also a logic that says there has to be a x such that P x? [Wed Jan 25 17:19:43 2017] I don't know, sorry [Wed Jan 25 17:19:48 2017] Oké [Thu Jan 26 10:10:48 2017] hi, I'm trying to write a plugin for 8.6, and I get a weird linking error when the .cmxs is loaded: "no implementation available for Declarations" [Thu Jan 26 10:11:17 2017] I used coq-makefile to build, no idea what the makefile does exactly [Fri Jan 27 09:34:08 2017] no one has had issues with their plugins on 8.6? :/ [Fri Jan 27 12:45:18 2017] https://www.irif.fr/~letouzey/types2014/abstract-18.pdf ← is there any full version of this? [Fri Jan 27 23:37:59 2017] companion_cube: haven't tried yet, sorry :\ [Mon Jan 30 01:10:24 2017] Hello everyone [Mon Jan 30 01:11:11 2017] I have m, n of type Z and hypothesis H : m < n [Mon Jan 30 01:11:40 2017] I am looking for lemma which says Z.max m n = n [Mon Jan 30 01:12:21 2017] All the lemma https://coq.inria.fr/library/Coq.ZArith.BinInt.html [Mon Jan 30 01:13:22 2017] under specification of minimum and maximum asks for equality [Mon Jan 30 02:02:14 2017] Please leave your comment here. https://gist.github.com/mukeshtiwari/ae79fc3aacf6e694252b5ff176a04e93 [Mon Jan 30 02:37:06 2017] keep_learning: commented. [Mon Jan 30 18:51:12 2017] Cale: Thank you [Mon Jan 30 18:51:27 2017] Hello everyone. [Mon Jan 30 18:51:37 2017] I am trying to prove this lemma https://gist.github.com/mukeshtiwari/60f7628e1044874bb6a4cf1411675029 [Mon Jan 30 18:52:21 2017] I have finished maxlist (map f l) >= s -> exists (x:A), In x l /\ f x >= s except couple of admits. [Mon Jan 30 18:53:33 2017] When I am trying to simplify maxlist (f a :: map f l), I am getting something different than Z.max (f a) (maxlist (map f l)) [Mon Jan 30 18:54:07 2017] It is clear that l is not empty from context l = l1 + [x] [Mon Jan 30 18:54:43 2017] so simplification should go in 3rd branch of maxlist definition [Mon Jan 30 18:55:09 2017] Could some one please tell me what is wrong with my understanding and Coq simplification. [Mon Jan 30 18:55:37 2017] keep_learning: provable l is not empty != definitional equality [Mon Jan 30 18:55:49 2017] in this case if you case on l1 you should be able to get it to simplify [Mon Jan 30 18:56:18 2017] ezyang: You mean destruct l1 ? [Mon Jan 30 18:56:22 2017] yeah [Mon Jan 30 18:56:48 2017] ezyang: Thank you. [Tue Jan 31 02:21:52 2017] hi a simple question regarding coqdoc. How do I ensure that coqdoc passes what ever latex commands are present in the comments to the output tex file [Tue Jan 31 02:22:28 2017] currently if I write \myfunnycommand{foo} coq doc converts it to \symbol{92}myfunnycommand{foo} [Tue Jan 31 02:32:05 2017] sorry I got the answer my self %\myfunncycommand{foo}% [Tue Jan 31 10:34:54 2017] i remembered a little while back that in like 6th grade i had this frustrating, half-formed concept in my head of some kind of unified notation or programming language for expressing all math concepts, not just simple expressions but ones where you normally have to use auxiliary english explanations [Tue Jan 31 10:34:56 2017] and yknow, i think things like coq are almost exactly what i knew i wanted but couldnt quite understand [Tue Jan 31 10:35:01 2017] :} [Wed Feb 1 08:52:13 2017] what do I have to do to make my project usable with opam? I probably have to set up an opam repo for it (?) [Wed Feb 1 11:12:29 2017] is it possible to have a field of a record of type Set being computationally irrelevant? [Wed Feb 1 11:12:55 2017] in theory, having "exists x, Type" should be enough for that, but this seems horrible to handle with [Wed Feb 1 17:29:44 2017] is anybody here? [Wed Feb 1 17:29:59 2017] exists person. [Wed Feb 1 17:30:11 2017] Yup, but I don't really know the answers to your question :) [Wed Feb 1 17:30:19 2017] same [Wed Feb 1 17:30:47 2017] Well, I'll give it a try anyway: for the first one, my guess would be that you need to take a look at how https://github.com/coq/opam-coq-archive works, and probably send a PR there [Wed Feb 1 17:30:58 2017] (maybe) [Wed Feb 1 17:31:36 2017] ok, then new question: is there an emacs mode that can automatically change the depths of +, ++, ++++, *, ...? like M-x indent-region does for indentions, etc.? [Wed Feb 1 17:31:54 2017] For the second one...hmm. [Wed Feb 1 17:32:03 2017] looks like the inductive type inhabited could be the right way? [Wed Feb 1 17:32:21 2017] "Inductive inhabited (A : Type) : Prop := inhabits : A -> inhabited A" (it's present by default) [Wed Feb 1 17:33:08 2017] hm. [Wed Feb 1 17:33:21 2017] makes sense. [Wed Feb 1 17:38:26 2017] thx [Thu Feb 2 05:36:09 2017] should I open a bug report about coq eating all the RAM when compiled wiht flambda? [Thu Feb 2 06:08:02 2017] go xb [Thu Feb 2 06:08:20 2017] companion_cube: i noticed that too [Thu Feb 2 21:41:04 2017] Hi everyoen [Thu Feb 2 21:41:20 2017] *everyone [Thu Feb 2 21:41:40 2017] Could some one please tell me how to write this function using refine https://gist.github.com/mukeshtiwari/66555dd59ff886bfc6c51e580a5491ab [Thu Feb 2 21:44:36 2017] keep_learning, why is this a fixpoint if it isn't self-referential? [Thu Feb 2 21:44:43 2017] "MM" doesn't appear anywhere [Thu Feb 2 21:44:57 2017] ah, that should be "M" I guess [Thu Feb 2 21:46:50 2017] rrika: Yes [Thu Feb 2 21:46:56 2017] Updated [Thu Feb 2 21:48:21 2017] are you just asking for the syntax? [Thu Feb 2 21:48:22 2017] Theorem M : forall (n : nat) (c d : Evote.cand), n <> O -> Z. [Thu Feb 2 21:48:22 2017] refine (fix MM (n : nat) (c d : Evote.cand) => ... ). [Thu Feb 2 21:49:03 2017] where ... can be the body you used before, or _. [Thu Feb 2 21:49:53 2017] Yes, I am asking for syntax. Thank you [Thu Feb 2 21:49:58 2017] I was looking for fix [Thu Feb 2 21:56:01 2017] rrika: https://gist.github.com/mukeshtiwari/66555dd59ff886bfc6c51e580a5491ab [Thu Feb 2 21:56:12 2017] I am getting syntax error. [Thu Feb 2 21:56:25 2017] Could you please have a look. [Thu Feb 2 22:02:16 2017] oops it's ":=" not "=>" [Thu Feb 2 22:02:34 2017] keep_learning, ^ [Thu Feb 2 22:07:25 2017] rrika: Thank you [Thu Feb 2 22:30:15 2017] rrika: For me (newbie in coq) it looks impossible to write this definition https://github.com/mukeshtiwari/formalized-voting/blob/master/schulze-count.v#L222 using refine tactic https://gist.github.com/mukeshtiwari/66555dd59ff886bfc6c51e580a5491ab [Thu Feb 2 22:31:09 2017] I am trying to avoid n = 0 case and my base case should be n = 1 [Thu Feb 2 22:32:45 2017] but stuck with proof n' <> 0 [Thu Feb 2 22:34:03 2017] you're lacking the assumtion that S n' = n [Thu Feb 2 22:34:43 2017] keep_learning, you could try refining only the fix [Thu Feb 2 22:34:50 2017] refine (fix MM (n : nat) (c d : Evote.cand) := _). [Thu Feb 2 22:34:57 2017] then use destruct tactic on n. [Thu Feb 2 22:35:17 2017] that way you can outsource some of the more tedious tracking to coq, iirc. [Thu Feb 2 22:35:45 2017] rrika: Thank you [Thu Feb 2 22:37:01 2017] keep_learning, let me know if it works, and what context you end up with in the last case [Thu Feb 2 23:04:20 2017] rrika: Could you please have a look https://gist.github.com/mukeshtiwari/66555dd59ff886bfc6c51e580a5491ab [Thu Feb 2 23:04:43 2017] I am not sure if both N and M are same. [Thu Feb 2 23:05:20 2017] Because in N function I don't have base case [Thu Feb 2 23:15:05 2017] basically you want (N 5 a b (5<>0)) = (M 4 a b)? [Thu Feb 2 23:22:18 2017] rrika: Yes, because M the recursion goes upto depth of (n + 1) and terminates when n = 0, but I want it to be terminate at n = 1 [Thu Feb 2 23:22:35 2017] can't you just wrap M and call it with (n-1)? [Thu Feb 2 23:24:41 2017] rrika: That's what I have done in my proofs, but I was thinking to implement it using refine. [Thu Feb 2 23:25:00 2017] rrika: Thank you very much [Thu Feb 2 23:25:13 2017] keep_learning_, https://gist.github.com/rrika/42679641037b80b51aa79f65e4a94410 [Thu Feb 2 23:25:55 2017] it's dangerous though, because being in proof mode makes you think getting rid of all goals means that you did the right stuff. [Thu Feb 2 23:26:11 2017] but your return value is Z, so your goal is Z, so even "exact 42." will remove a Z goal [Thu Feb 2 23:26:41 2017] rrika: Thank you. [Thu Feb 2 23:27:08 2017] don't worry [Thu Feb 2 23:29:02 2017] I think I was missing this point destruct n as [|[|n'']] [Thu Feb 2 23:29:37 2017] yeah, you destructed on n before intro-ing the H: n<>0 [Thu Feb 2 23:30:03 2017] when you intro first, you can destruct n, do congruence on the first goal, and then destruct n again to distinguish S O and S n' [Thu Feb 2 23:30:09 2017] but destruct n as [|[|n'']] is shorter :P [Thu Feb 2 23:31:57 2017] destruct n as [|[|n'']] is elegant also [Thu Feb 2 23:35:02 2017] btw, if you want a third way to do it [Thu Feb 2 23:35:30 2017] https://gist.github.com/rrika/fe89b48887994fa1e56e1bfc3c6459b7 [Thu Feb 2 23:36:11 2017] (program fixpoint tends to generate very messy terms though) [Thu Feb 2 23:36:33 2017] ~magic~ [Thu Feb 2 23:40:13 2017] rrika: You call to (M (S n') x d)) in S (S n') branch is intended or it should be call back again N ? [Thu Feb 2 23:40:26 2017] oops [Thu Feb 2 23:40:39 2017] ooh, that's why it worked so easily [Thu Feb 2 23:42:45 2017] rrika: :) [Thu Feb 2 23:51:54 2017] rrika: https://gist.github.com/mukeshtiwari/8ea564b77d2bdf69d5f0d741a56f2b5d [Thu Feb 2 23:52:14 2017] yeah, that works [Fri Feb 3 00:08:54 2017] keep_learning_, if I understand correctly, this will be the real challenge: https://gist.github.com/rrika/7add43807be38ec35f6aa4e4ed80babe [Fri Feb 3 00:16:09 2017] rrika: Yes [Fri Feb 3 00:16:55 2017] I did not know that doing pattern matching on natural number is this hard :) [Fri Feb 3 11:54:51 2017] can I create records in coq more nicely than using mkRecordName ...? like, actually using the field names? [Fri Feb 3 16:23:44 2017] is a partial map such as the one found in “software foundations” somewhere in the standard library or do I need to define my own/copy the one from sf? [Fri Feb 3 16:30:13 2017] help! I'm trying to prove that `h ∘ g ∘ f = h ∘ (g ∘ f)` [Fri Feb 3 16:30:21 2017] and I can't figure out what to do :( [Fri Feb 3 16:30:27 2017] try reflexivity [Fri Feb 3 16:30:31 2017] (I'm going through HoTT and using coq as a theorem prover) [Fri Feb 3 16:30:44 2017] benzrf: ah, thanks! [Fri Feb 3 16:30:46 2017] lmao [Fri Feb 3 16:31:06 2017] benzrf: why does that work? [Fri Feb 3 16:31:10 2017] what does reflexivity do? [Fri Feb 3 16:31:27 2017] it attempts to use eq_refl as a proof of the goal [Fri Feb 3 16:32:25 2017] cool [Fri Feb 3 16:41:23 2017] benzrf: is there a way to like... apply a function? [Fri Feb 3 16:41:45 2017] I'm trying to check something out [Fri Feb 3 16:41:45 2017] f x [Fri Feb 3 16:41:55 2017] but like, unfold f [Fri Feb 3 16:41:57 2017] kind of thing [Fri Feb 3 16:42:00 2017] unfold [Fri Feb 3 16:42:01 2017] f [Fri Feb 3 16:42:09 2017] but it's not working... [Fri Feb 3 16:42:09 2017] wait, what do you mean [Fri Feb 3 16:42:26 2017] one sec, I'll show you [Fri Feb 3 16:43:00 2017] benzrf: https://gist.github.com/ubsan/bad1e66a48ee08ddbd4edf3d1374b6e6 [Fri Feb 3 16:43:20 2017] I'd like p1 to become fun x => h (g x) [Fri Feb 3 16:44:05 2017] oh [Fri Feb 3 16:44:13 2017] fold, perhaps [Fri Feb 3 16:44:27 2017] no :( [Fri Feb 3 16:44:31 2017] it just stays the same [Fri Feb 3 16:44:35 2017] fold p1? [Fri Feb 3 16:44:41 2017] yeah [Fri Feb 3 16:44:49 2017] > p1 := h ∘ g : B -> D [Fri Feb 3 16:44:55 2017] with unfold changed to fold [Fri Feb 3 16:45:04 2017] it folds it on my end [Fri Feb 3 16:45:08 2017] ============================ [Fri Feb 3 16:45:09 2017] h ∘ (g ∘ f) = p1 ∘ f [Fri Feb 3 16:45:23 2017] oh! [Fri Feb 3 16:45:25 2017] I see [Fri Feb 3 16:47:24 2017] benzrf: I'd like it to become fun x => g (f x) though [Fri Feb 3 16:47:40 2017] as opposed to the other way [Fri Feb 3 16:48:31 2017] compute in p1 [Fri Feb 3 16:48:37 2017] compute is the hardcore version of simpl [Fri Feb 3 16:49:15 2017] benzrf: ah! [Fri Feb 3 16:49:18 2017] thanks so much :D [Fri Feb 3 16:51:00 2017] np [Fri Feb 3 17:13:41 2017] how do I explicify implicit parameters? [Fri Feb 3 17:14:05 2017] like {a = foo} in idris [Fri Feb 3 17:18:45 2017] ah, (a:=foo) [Sat Feb 4 12:18:47 2017] When would I want to use a type class instead of module types and functors? Just to make the resolution implicit, or are there other differences? [Sat Feb 4 12:27:22 2017] hey folks [Sat Feb 4 12:27:50 2017] shlevy: i'd say logical programming [Sat Feb 4 12:28:03 2017] you sort of need automatic resolution there [Sat Feb 4 12:28:42 2017] E.g. for some type class C : Prop -> Prop, you can make an instance for C (P /\ Q), given you have instances for C P and C Q [Sat Feb 4 12:29:04 2017] also typeclasses are often used for overloading [Sat Feb 4 14:39:12 2017] Are there any good library types for representing bytes (or, really, arbitrary fixed-length binary numbers)? [Sat Feb 4 14:52:54 2017] Are there any good style guides/naming conventions? [Sat Feb 4 14:54:57 2017] Hey, I was trying to change the notation of my typing derivations to use "|--" instead of "|-" to avoid the collision with |- used in ltac. However I am getting an error about a missing parsing rule http://lpaste.net/352087 and I can’t figure out what I need to do about this [Sat Feb 4 14:57:42 2017] I'm guessing this just isn't possible, but I'm trying to use https://coq.inria.fr/library/Coq.Numbers.NaryFunctions.html#nfun to define an arbitrary-length bytes type: Inductive bytes (n : nat) : Type := mk_bytes : byte ^^ n --> bytes n. [Sat Feb 4 14:58:32 2017] This is failing because coq doesn't know that the type of mk_bytes ends in bytes n, but of course in this case it always should. [Sat Feb 4 14:58:47 2017] Is there any way to do this? variable-length constructors are probably verboten :D [Sat Feb 4 14:59:40 2017] If not, does coq have macros or anything similar? I don't need functions that abstract over the size of the byte buffer in my use [Sat Feb 4 15:07:00 2017] nvm, I had a reserved notation above that code [Sat Feb 4 15:07:04 2017] after changing that too everything works [Sat Feb 4 15:13:15 2017] Is there ever a reason to define an inductive type in Type if the definition is accepted in Set? [Sat Feb 4 15:27:12 2017] Why does sigT2 exist? [Sat Feb 4 16:01:44 2017] shlevy: my suggestion be to use vectors and have mk_bytes : vVec btyete n -> bytes n [Sat Feb 4 16:02:08 2017] the induction principle that you'll get will be useless but you should be able to roll your own i ugess [Sat Feb 4 16:06:33 2017] notdan: Yeah, that's what I've got :) [Sat Feb 4 16:15:20 2017] so I remember I read a paper on modelling assembly in Coq, and they used ssreflect's n-tuples of bools to model bytes, words, dwords etc [Sat Feb 4 16:17:04 2017] Yeah, I've got something isomorphic [Sat Feb 4 16:17:38 2017] bit := B0 | B1, byte := mk_byte : bit ^^ 8 --> byte. [Sat Feb 4 18:02:59 2017] shlevy: I worked on that Coq assembly project and your trouble rings a bell [Sat Feb 4 18:06:57 2017] huh I think the code is gone tho :( [Sat Feb 4 18:07:24 2017] but I guess the vector suggestion was good [Sat Feb 4 18:08:21 2017] what project was that Ptival, if you don't mind me asking? [Sat Feb 4 18:08:48 2017] notdan: oh the project from the paper, I worked a bit on it after the paper, but nothing that ended up published [Sat Feb 4 18:09:44 2017] pretty sure the project died soon after [Sun Feb 5 04:14:33 2017] how do I use exists? [Sun Feb 5 04:14:53 2017] specifically, I have `n0 : nat` [Sun Feb 5 04:15:07 2017] and a goal, `exists m : nat, S n0 = S m` [Sun Feb 5 04:15:17 2017] how would I say "m is n0, trivial" [Sun Feb 5 04:16:04 2017] oh, the exists tactic [Sun Feb 5 04:16:06 2017] woot! [Sun Feb 5 04:20:15 2017] okay, new question [Sun Feb 5 04:20:16 2017] https://gist.github.com/ubsan/6c1cbaefec3197cdaa6c7170317759ca [Sun Feb 5 04:20:22 2017] still going through HoTT [Sun Feb 5 04:23:17 2017] doing one of the exercises, which is "why can't you provide a function `f : Pi(x : A) Pi(p : x = x) p = eq_refl` using `f(x, refl[x]) := refl[refl[x]] [Sun Feb 5 04:23:32 2017] or translated to coq like you see in the link [Sun Feb 5 08:45:59 2017] ubsan: try to write it out explicitly using the J elimination rule for the identity [Sun Feb 5 08:46:32 2017] ubsan: the problem is that you can only use id-recursion if both "endpoints" of the equality p : x = y are free [Sun Feb 5 08:46:53 2017] in this example you have [p : x = x] , so the final endpoint should be the same as the initial endpoint [Sun Feb 5 08:47:53 2017] see also https://homotopytypetheory.org/2011/04/10/just-kidding-understanding-identity-elimination-in-homotopy-type-theory/ [Sun Feb 5 13:04:52 2017] Is there some clever tactic to destruct "exists x y, A /\ B /\ C" such that I have two new variables and A, B & C separately? [Sun Feb 5 13:07:26 2017] ah "do 4 destruct H as [? H]" does the job [Sun Feb 5 13:07:40 2017] I forgot that I can just name the resulting hypothesis to avoid this breaking [Sun Feb 5 19:18:01 2017] cocreature: usually I do "destruct H as [? [? [A [B C]]]]." [Sun Feb 5 19:18:05 2017] it's a little tedious [Mon Feb 6 00:56:35 2017] Ptival: ah that’s more readable than destruct 4 [Mon Feb 6 17:18:16 2017] Bit of an odd one but my coqide renders some of the menus in japanese on my mac. I assume it's because I have japanese input methods enabled. is there a config file or option somewhere to change this? [Mon Feb 6 20:42:08 2017] Is there a way to do Eval with proof general? [Mon Feb 6 20:56:55 2017] rgrinberg, you can type C-c C-a ? to list available shortcuts [Mon Feb 6 20:57:06 2017] (eval is not among them) [Mon Feb 6 20:59:20 2017] rrika: I see. thanks [Mon Feb 6 21:00:28 2017] but you can always just put a line in your buffer and run it with C-c C-n [Mon Feb 6 21:00:37 2017] but you were looking to avoid that, I guess [Mon Feb 6 21:03:21 2017] rrika: Yeah, exactly. [Mon Feb 6 22:12:05 2017] Can you generate arbitrary coq terms with ltac? e.g. could I "prove" an inhabitant of Set by defining an Inductive type in tactics? [Mon Feb 6 22:12:24 2017] (I'm trying to get a sense for the metaprogramming/macro facilities available) [Mon Feb 6 22:13:04 2017] Sadly not, inductive types could in theory be first-class inhabitant, but they are not at the moment [Mon Feb 6 22:13:33 2017] But I believe everything else (so no (co-)inductive type definitions) can be built using tactics [Mon Feb 6 22:14:20 2017] OK [Mon Feb 6 22:14:43 2017] Ah, right, Inductive declarations are treated as assumptions in the global environment right? [Mon Feb 6 22:15:35 2017] You can see it like that (they are not actual assumptions in the same sense that an axiom is, they are part of the logic in any case; but you still can only define them in the global environment) [Mon Feb 6 22:15:50 2017] (but as I said, it's a technical point, not a theoretical one) [Mon Feb 6 22:16:28 2017] Are alpha-equivalent inductive definitions equivalent? [Mon Feb 6 22:17:53 2017] They are not. But I don't know the answer to the question "Should they be?" [Mon Feb 6 22:18:19 2017] I mean, they are equivalent in a sense (you can prove an equivalence between them), but they are not equal or interchangeable [Mon Feb 6 22:18:37 2017] I mean in the reduction of theh calculus [Mon Feb 6 22:19:46 2017] Inductive foo : Prop := . Inductive bar : Prop := . Goal foo = bar. Fail reflexivity. [Mon Feb 6 22:19:50 2017] does that answer your question? [Mon Feb 6 22:19:54 2017] Yep [Mon Feb 6 22:20:26 2017] So that's a theoretical difference between (at least one possible impl) of first-class inductive terms [Mon Feb 6 22:20:45 2017] Indeed. Hence the "Should they be?" that I don't know the answer to [Tue Feb 7 11:32:30 2017] shlevy: It might be possible to make a generic Inductive type, which sort of lets you make first class inductive types from it. [Tue Feb 7 11:33:07 2017] That's called W-types [Tue Feb 7 11:34:00 2017] Ah, that's right. Ugh, and they have extensionality issues. I remember now. [Tue Feb 7 11:34:33 2017] "Inductive W (A : Type) (B : A -> Type) : Type := sup : forall (a : A), B a -> W A B." basically subsumes every inductive type. [Tue Feb 7 17:20:50 2017] roconnor: You can make a more complicated generic inductive type that has fewer extensionality issues than W-types. [Tue Feb 7 17:54:42 2017] oh really? [Tue Feb 7 17:55:19 2017] maybe by augmenting the B with a vector of types? [Fri Feb 10 04:05:36 2017] Is it hard to add a new language for program extraction to Coq? The language I have in mind is Elm, which is syntactically similar to Haskell, but being strict would benefit from the kind of optimisations that Coq does when extracting for OCaml [Sun Feb 12 12:27:08 2017] Suppose you have a predicate P on, say, natural numbers. Then proving P decidable takes two parts: A function [decide : nat -> bool], and a proof [decide_correct : forall n, P n <-> decide n = true] [Sun Feb 12 12:27:51 2017] Is there some P such that we can define [decide] in vanilla Coq, but we can't prove [decide_correct] without LEM? [Sun Feb 12 12:28:08 2017] i.e., we have a constructive decision procedure, but it's only classically provable that it's correct [Sun Feb 12 12:28:19 2017] so we can effectively decide, but we can't constructively prove that it's decidable [Sun Feb 12 13:33:20 2017] benzrf: Fix an encoding of Turing machines as [nat]s, and let [H n] be the proposition that the Turing machine represented by [n] halts. Set [P n := H n \/ ~H X], and let [decide n := true]. Then you can prove that [LEM -> decide_correct], but if [decide_correct] were provable, you could replace [Prop] with [Set] and pass -impredicative-set and extract to OCaml, and you'd get a solution to the Halting problem. [Sun Feb 12 13:34:10 2017] ahh, ok [Sun Feb 12 13:35:37 2017] If you hadn't said that [P] had to be on [nat], then you get a simpler solution: let [P p := p \/ ~p] and set [decide p := true]. Then [decide_correct] is equivalent to LEM. [Sun Feb 12 13:35:46 2017] yeah :P [Sun Feb 12 13:36:15 2017] Or, oh, here's an easy one: take [P n := forall X : Prop, X \/ ~X], and set [decide n := true]. Then [decide_correct] is equivalent to LEM :P [Sun Feb 12 13:36:42 2017] * swats jgross with a rolled up newspaper [Sun Feb 12 13:37:54 2017] hmmmmmm... so are there models of CoC which don't validate "all turing machines halt or dont halt"? [Sun Feb 12 13:37:56 2017] * redefines the tactic generating newspapers to be [idtac], and recompiles reality [Mon Feb 13 09:41:30 2017] exists (Some reason). ← how deep. [Mon Feb 13 20:12:57 2017] Hi everyone [Mon Feb 13 20:13:22 2017] How to instantiate ?n in goal with x ? https://gist.github.com/mukeshtiwari/9fee46749b77c835698159eaa2e6ecc8 [Mon Feb 13 20:22:30 2017] instantiate (1:=x). [Mon Feb 13 20:22:39 2017] or: apply H0 [Mon Feb 13 20:22:43 2017] or: eassumption [Mon Feb 13 20:22:45 2017] or: eauto [Mon Feb 13 20:32:14 2017] johnw: I am getting Error: Instance is not well-typed in the environment of ?X106 when using instantiate (1 := x) [Mon Feb 13 20:32:59 2017] Unable to unify "?n" with "x" (cannot instantiate "?n" because "x" is not in its scope: available arguments are "dec_cand" "cand_fin" "cand_not_nil" "wins" "loses" "is_marg" "k" "c" "d" "H"). when apply H0 [Mon Feb 13 20:33:54 2017] I am trying to convert Prop level path to Type level path using previous existing lemmas [Mon Feb 13 20:34:09 2017] https://github.com/mukeshtiwari/formalized-voting/blob/master/Schulze_Dirk_Z.v [Mon Feb 13 20:34:28 2017] so, you introduced x after the existential was created [Mon Feb 13 20:35:32 2017] imagine if you had match-analyzed a variable, and then tried to refer to the results of the match before it had happened [Mon Feb 13 20:36:53 2017] johnw: Thank you. I got your point. [Mon Feb 13 22:33:53 2017] is there a theorem somewhere that preorder closure preserves monotonicity? [Mon Feb 13 22:34:10 2017] in the sense that f monotonic for R -> f monotonic for R* [Mon Feb 13 22:34:44 2017] i guess it wouldnt be hard to prove but it seems like something that would be in the stdlib [Wed Feb 15 17:02:11 2017] is there any support for deriving decidable equality in a similar way to haskell? [Wed Feb 15 17:04:45 2017] yes [Wed Feb 15 17:05:51 2017] Set Decidable Equality Schemes. [Wed Feb 15 17:05:55 2017] before the type definition [Wed Feb 15 17:06:01 2017] johnw: you're my hero [Wed Feb 15 17:06:54 2017] there's also Set Boolean Equality Schemes. [Wed Feb 15 17:07:34 2017] johnw: awesome. I'm assuming it generates a standard name in a similar way to the inductive hypotheses? [Wed Feb 15 17:07:39 2017] yes [Wed Feb 15 17:17:37 2017] hm, seems like the decidable equality schemes only generated boolean equality (t -> t -> bool) with the ugly name internal_t_beq [Wed Feb 15 17:17:50 2017] at least according to SearchAbout [Wed Feb 15 17:18:25 2017] boolean equality schemes generated t_beq, which is fine for my purposes [Wed Feb 15 17:18:27 2017] thanks again [Wed Feb 15 17:31:40 2017] I've now spent a few hours on this and it's not going anywhere: http://tuplanolla.no-ip.org/tmp/Destutter.v [Wed Feb 15 17:31:48 2017] Any clues on how to finish the proof? [Wed Feb 15 17:58:11 2017] stelleg: that's the boolean one; there is also the Decidable one [Wed Feb 15 17:58:14 2017] maybe it couldn't generate it [Wed Feb 15 18:57:53 2017] Tuplanolla: a useful intermediate lemma could be "forall x y xs ys, destutter (x :: xs) = y :: ys -> x = y" [Wed Feb 15 18:58:34 2017] that would allow you to destruct "destutter (y :: ys)" while keeping the information that this term starts with y [Wed Feb 15 18:59:10 2017] That could work. [Wed Feb 15 19:05:02 2017] seems a little weird that it would succeed in generating boolean equality but not decidable [Wed Feb 15 19:06:09 2017] I don't know how to prove something like that either though. [Wed Feb 15 19:07:12 2017] by induction on xs. But I guess you did that, so where did you get stuck? [Wed Feb 15 19:08:47 2017] Manipulating hypotheses instead of goals, but I'll figure it out. [Wed Feb 15 19:34:44 2017] You can see my progress in the file. [Wed Feb 15 19:35:53 2017] You don't want to apply your induction hypothesis from the get-go [Wed Feb 15 19:36:07 2017] it will only be useful in the case x :: x :: zs [Wed Feb 15 19:36:30 2017] Should I start inside E? [Wed Feb 15 19:37:20 2017] you should start with the case on (eq_dec x z), and then rewrite in E accordingly [Wed Feb 15 19:37:39 2017] So yes. [Wed Feb 15 19:52:35 2017] Back to the theorem then. [Wed Feb 15 20:06:39 2017] The implication seems to be going in the wrong direction in the lemma. [Wed Feb 15 20:07:57 2017] I managed to prove the theorem using this lemma. [Wed Feb 15 20:08:25 2017] Right where you were stuck, the next step was to destruct (destutter (y :: ys)) (and keeping an equation between this and the result, to be used with the new lemma) [Wed Feb 15 20:08:39 2017] With the other direction I could just say "apply destutter_head_reverse; reflexivity" and it would be done. [Wed Feb 15 20:09:05 2017] The other direction is false though [Wed Feb 15 20:09:39 2017] It's because of the quantifiers. [Wed Feb 15 20:09:53 2017] I shall work with what I had then. [Wed Feb 15 20:15:26 2017] There we go. Thanks for the clues, Cypi. [Wed Feb 15 20:18:00 2017] Is there some kind of deeper structure in theorems that mandates how many times one needs to use the induction principle to prove them? [Wed Feb 15 20:18:29 2017] When I started this problem, I had the feeling that one use without lemmas ought to be enough. [Wed Feb 15 20:28:32 2017] usually you use induction to prove some core relational theorems, and from then on you can mostly use rewriting [Thu Feb 16 06:00:49 2017] how do I import a library from the standard library? I have found the documentation here: https://coq.inria.fr/library/Coq.Lists.List.html [Thu Feb 16 06:01:12 2017] using Import Coq.Lists.List. gives an error [Thu Feb 16 06:01:18 2017] Error: Coq.Lists.List is not a module [Thu Feb 16 06:04:40 2017] Require Coq.Lists.List. [Thu Feb 16 06:07:03 2017] great [Thu Feb 16 06:07:04 2017] thanks [Thu Feb 16 12:17:36 2017] Does the standard library have an inductive family for differences of integers? Something like: [Thu Feb 16 12:19:51 2017] Inductive diff : Z -> Z -> Type | diff0 : forall z : diff z z | diffNeg : forall z1 z2. z1 < z2 -> diff (Zsucc z1) z2 -> diff z1 z2 | diffPos : forall z1 z2. z1 > z2 -> diff z1 (Zsucc z2) -> diff z1 z2. [Thu Feb 16 12:25:55 2017] oh, I actually want it for Nat rather than Z. [Thu Feb 16 14:23:16 2017] roconnor: But integers are the differences between Nats. :P [Thu Feb 16 14:24:40 2017] yes, but integers are not parameterized by two nats. [Thu Feb 16 14:25:04 2017] What I'm imagining is isomorphic to the intergers when you forget the paramters. [Fri Feb 17 10:12:52 2017] I am having trouble with the module system... I want to use the `divide` definition in Coq.Arith.PeanoNat. I tried Require Coq.Arith.PeanoNat but I keep getting the error "The reference divide was not found in the current environment." [Fri Feb 17 10:13:12 2017] any ideas on how to import this correctly? [Fri Feb 17 10:14:37 2017] aochagavia : either use Nat.divide, or add "Import nat." [Fri Feb 17 10:14:55 2017] Notice in the first few lines of https://coq.inria.fr/library/Coq.Arith.PeanoNat.html, there is "Module Nat ..." which opens a module [Fri Feb 17 10:15:16 2017] so what is the difference between Require and Import? [Fri Feb 17 10:17:02 2017] (I added Import Nat, but I keep getting the error) [Fri Feb 17 10:17:35 2017] the code is here, in case you want to see it: https://gist.github.com/aochagavia/72f8088b0789261525c2cd429ea2b48a [Fri Feb 17 10:17:40 2017] Ah, yes. "Require Coq.Arith.PeanoNat" will just require the file and put everything it defines in a submodule [Fri Feb 17 10:17:44 2017] just 3 lines [Fri Feb 17 10:17:58 2017] "Require Import Coq.Arith.PeanoNat" will do that, and then import everything at top-level [Fri Feb 17 10:19:09 2017] You could do "Import PeanoNat.Nat." [Fri Feb 17 10:19:16 2017] to reference the module Nat which is defined inside PeanoNat [Fri Feb 17 10:19:30 2017] (apparently there is another module called Nat which is defined elsewhere...) [Fri Feb 17 10:23:09 2017] thanks [Fri Feb 17 19:03:34 2017] If I want to have a monad for manipulation of a graph data structure that has (among other things) an add and remove operation, how can I make sure that only operation sequences that remove existing nodes are expressible. [Fri Feb 17 19:08:58 2017] I can't locally know if a removal is valid, I have to know if a node creation will be prepended to it [Fri Feb 17 19:31:28 2017] you'll need to represents the structure in the type somehow, so that the constructor for Removal : forall (g : Graph), isNonEmpty g -> GraphOp g [Fri Feb 17 19:31:55 2017] probably end that with GraphOp (remove n g), and declare n too [Fri Feb 17 19:32:17 2017] in other words, "GraphOp g" is the type of correct operations on a graph, where g is the correctly operated on graph [Fri Feb 17 19:33:46 2017] johnw, what would the body of "remove" be? [Fri Feb 17 19:33:56 2017] your remove operation on the graph [Fri Feb 17 19:34:08 2017] which presumably would require a g, NonEmpty g [Fri Feb 17 19:35:00 2017] the idea here is to have two data types [Fri Feb 17 19:35:02 2017] is the type of graphs [Fri Feb 17 19:35:22 2017] the next is the type of a DSL representing all lawful operations on graphs [Fri Feb 17 19:35:41 2017] then you bake the requirements into the constructors of the DSL term, and it becomes a propositional predicate for a "correctly operated on graph" [Fri Feb 17 19:35:54 2017] another term for this might be "a good graph client" [Fri Feb 17 19:36:11 2017] hm, I'll try something like that. [Fri Feb 17 19:36:23 2017] I've used this trick many times, it generally works out well [Fri Feb 17 19:36:49 2017] because it allows you to still operate on plain graphs, so long as you can prove that those operations maintain correct construction [Fri Feb 17 19:36:56 2017] i.e., rather than having a dependent type that must *always* be correct [Fri Feb 17 19:37:10 2017] I want to avoid implementing the graph ops [Fri Feb 17 19:37:16 2017] hmm? [Fri Feb 17 19:37:26 2017] The idea is that I extract to something that can do graph mutation natively. [Fri Feb 17 19:37:40 2017] basically, not emulate a mutable graph with an immutable datastructure [Fri Feb 17 19:37:58 2017] I'd just state the important properties about add/remove: Everything but the element in question stays the same [Sat Feb 18 04:42:35 2017] hi [Sat Feb 18 04:46:28 2017] hi notdan [Sat Feb 18 16:09:01 2017] I vaguely recall reading a paper about why pattern-matching + recursion is much nicer to work with as the primitives than induction principles. Does anyone know what I might be talking about? :D [Sat Feb 18 18:11:37 2017] I was looking for "Codifying guarded definitions with recursive schemes" I think [Sun Feb 19 12:40:01 2017] hi shlevy [Sun Feb 19 12:40:30 2017] shlevy: I think I know, but I'm not sure of the context in which you ask [Sun Feb 19 12:41:13 2017] shlevy: are you talking about the difference in coding style between writing a recursive function that pattern matches on its list argument, rather than a function that just calls list_rect? [Sun Feb 19 17:08:12 2017] Looking at the definition of Well_founded.Acc (https://coq.inria.fr/distrib/current/stdlib/Coq.Init.Wf.html#Acc), why is 'x' allowed to be a parameter? It doesn't really seem to be uniform... [Sun Feb 19 17:09:05 2017] Is the uniformness only required for the final type of the constructor? [Sun Feb 19 17:15:11 2017] Acc x means that x is Accessible from every other value of the same type, under the relation R [Sun Feb 19 17:15:20 2017] for example, every number reduces to 0, every list reduces to [], etc. [Sun Feb 19 17:15:24 2017] Sure [Sun Feb 19 17:15:38 2017] so, in Acc x, x is the value representing the base case for the relation R [Sun Feb 19 17:15:43 2017] I'm asking about the difference between a parameter and an index [Sun Feb 19 17:15:46 2017] Acc was just an example [Sun Feb 19 17:15:48 2017] ahh [Sun Feb 19 17:15:59 2017] parameters can't vary [Sun Feb 19 17:16:02 2017] indices can [Sun Feb 19 17:16:29 2017] Right, but what does 'vary' mean specifically? In this case, it seems to me like 'x' varies [Sun Feb 19 17:16:42 2017] But it's there as a parameter [Sun Feb 19 17:16:46 2017] for the parameter Foo (x : A), it means every constructor's type will be Foo x [Sun Feb 19 17:16:59 2017] But the recursive arguments are allowed to be Foo y [Sun Feb 19 17:17:20 2017] that's an instance of the type, not the type of the constructor [Sun Feb 19 17:17:26 2017] Right [Sun Feb 19 17:17:26 2017] OK [Sun Feb 19 17:17:39 2017] So it's not *quite* as if the inductive definition existed behind a lambda [Sun Feb 19 17:17:51 2017] not quite sure what you mean by that... [Sun Feb 19 17:20:31 2017] I mean if coq had anonymous inductive definitions, you can implement list like: fun (A : Type) => ind l := [(nil : l) (cons : A -> l -> l)] or whatever [Sun Feb 19 17:21:00 2017] But you can't do something similar for Acc, you'd need the anonymous inductive type definition to have built-in support for parameters as well as indices [Sun Feb 19 17:21:45 2017] i'm not sure what your syntax is supposed to represent [Sun Feb 19 17:22:03 2017] ind l is taking... a type as a parameter within a lambda? [Sun Feb 19 17:22:07 2017] The type of that whole expression is Type -> Type [Sun Feb 19 17:22:31 2017] ind is some imagined syntax for defining an inductive type family [Sun Feb 19 17:22:36 2017] are you talking about a recursor, like the type of list_rec? [Sun Feb 19 17:22:40 2017] No [Sun Feb 19 17:22:44 2017] (l is just a name I believe) [Sun Feb 19 17:23:15 2017] yes, l is a name, like how with 'fix' you define a name that's usable in the body [Sun Feb 19 17:23:24 2017] really it should be something like ind (l : Type) := ... [Sun Feb 19 17:23:37 2017] But anyway, I think I understand the answer to my question even if I can't phrase it well :D [Sun Feb 19 17:32:57 2017] shlevy: uniformness is only required for the final type of the constructor. [Sun Feb 19 17:33:11 2017] OK, cool [Sun Feb 19 17:34:14 2017] there are actually three types of parameters: uniform parmameter, non-uniform parameters, and indices. [Sun Feb 19 17:34:42 2017] So list has a uniform parameter and Acc has anon-uniform parameter? [Sun Feb 19 17:34:46 2017] Or is that something different? [Sun Feb 19 17:34:49 2017] I think my complain a while back prompted the existance of non-uniform parameters. [Sun Feb 19 17:35:14 2017] I wonder if the type of paremeter of Acc has changed. [Sun Feb 19 17:35:37 2017] What's the formal difference? [Sun Feb 19 17:36:28 2017] between non-uniform and uniform parameters? [Sun Feb 19 17:36:36 2017] Yeah [Sun Feb 19 17:37:59 2017] There might be a paper on this topic. [Sun Feb 19 17:40:13 2017] do they generate different induction principles? [Sun Feb 19 17:40:34 2017] the unform parameters might fully abstract the parameter. [Sun Feb 19 17:40:41 2017] in the induction principle. [Sun Feb 19 17:40:44 2017] Not sure. [Sun Feb 19 17:40:55 2017] shlevy: why do you want this construction, btw? [Sun Feb 19 17:41:50 2017] There is a thread on coq-club about this: https://sympa.inria.fr/sympa/arc/coq-club/2011-11/msg00411.html (not pointing to a specific mail in the thread). The take-away seems to be that non-uniform parameters behave like indices w.r.t recursive schemes (what you said), and like parameters w.r.t dependent pattern-matching [Sun Feb 19 17:44:00 2017] Yes, the definition of Acc has changed since coq 8.0pl3 [Sun Feb 19 17:44:09 2017] Inductive Acc : A -> Prop := [Sun Feb 19 17:44:10 2017] Acc_intro : forall x:A, (forall y:A, R y x -> Acc y) -> Acc x. [Sun Feb 19 17:44:33 2017] I wonder where shlevy copied his definition from then... [Sun Feb 19 17:44:44 2017] johnw: I linked it :D [Sun Feb 19 17:44:49 2017] ah [Sun Feb 19 17:44:55 2017] current stdlib I think [Sun Feb 19 17:45:00 2017] indeed you did [Sun Feb 19 17:45:04 2017] No, it's the definition that roconnor copied which is the old one ^^ [Sun Feb 19 17:45:08 2017] aha [Sun Feb 19 17:45:13 2017] non-uniform inductive parameters were introduced in 8.1 [Sun Feb 19 17:45:20 2017] I pasted the definition from 8.0pl3 [Sun Feb 19 17:46:17 2017] OK [Sun Feb 19 17:47:10 2017] So non-uniform parameters are the same thing as indices in a calculus with recursion principles as the primitive instead of fixpoints/matches? [Sun Feb 19 17:47:13 2017] shlevy: why do you want this? [Sun Feb 19 17:47:44 2017] Trying out an idea for an alternative kernel [Sun Feb 19 17:47:51 2017] have you looked at lean? [Sun Feb 19 17:48:01 2017] Yeah [Sun Feb 19 17:48:05 2017] i know that it does inductive types differently [Sun Feb 19 17:49:07 2017] shlevy: the primary reason I wanted non-uniform parameters was to avoid raising the universe level. [Sun Feb 19 17:49:12 2017] Aaah [Sun Feb 19 17:49:14 2017] Interesting [Sun Feb 19 17:49:56 2017] roconnor: Can you give an example where it matters? [Sun Feb 19 17:51:06 2017] yes [Sun Feb 19 17:59:09 2017] maybe [Sun Feb 19 17:59:54 2017] So the section on Non-unform De Bruijn Indices in https://coq.inria.fr/cocorico/UntypedLambdaTerms was my motivation at the time [Sun Feb 19 18:01:35 2017] This is the thread that I believe prompted the existance of non-uniform indices: https://sympa.inria.fr/sympa/arc/coq-club/2005-03/msg00006.html [Sun Feb 19 18:01:54 2017] There could have been other motivations that I wasn't are of though. [Sun Feb 19 18:02:48 2017] shlevy: I think the above link clearly demonstrates the issue. [Sun Feb 19 18:06:35 2017] Thanks [Sun Feb 19 18:07:06 2017] also https://sympa.inria.fr/sympa/arc/coq-club/2005-03/msg00017.html [Sun Feb 19 18:07:46 2017] though perhaps that pitfall has been fixed. [Sun Feb 19 18:13:10 2017] roconnor set flags +o on johnw [Sun Feb 19 18:13:31 2017] roconnor set flags +ARefirstv on johnw [Sun Feb 19 18:50:37 2017] roconnor: Can you give an intuition why a non-recursive parmeter need not raise the universe level but an index must? [Sun Feb 19 18:50:41 2017] erm, non-uniform [Sun Feb 19 19:04:53 2017] hmm, Christine Paulin doesn't seem to have any publications on the topic [Sun Feb 19 19:05:06 2017] Christine Paulin-Mohring [Sun Feb 19 19:07:25 2017] maybe this message / thread can help: https://sympa.inria.fr/sympa/arc/coq-club/2011-11/msg00465.html [Sun Feb 19 19:08:01 2017] though it doesn't help md. :( [Sun Feb 19 19:08:04 2017] *me [Sun Feb 19 19:09:40 2017] https://sympa.inria.fr/sympa/arc/coq-club/2011-11/msg00323.html [Sun Feb 19 19:13:33 2017] but honestly I have little understanding of universe levels. [Mon Feb 20 10:55:44 2017] Hm, what is the best way to debug tactics? [Mon Feb 20 10:56:40 2017] I have a very silly problem: if I inline the definition of an ltac, then Coq eats it up and everything is fine. If I put the tactic in a separate ltac, then Coq complains [Mon Feb 20 10:56:59 2017] is there difference in backtracking w.r.t. inlined tactics and calls to tactics/tacticals? [Mon Feb 20 10:58:43 2017] Oh, actually if I move that ltac definition into a Section where the proof is located, then it works fine... [Mon Feb 20 10:58:43 2017] wtf [Mon Feb 20 13:03:09 2017] Ah I see, I had a problem with scopeing in Tactic Notation [Tue Feb 21 16:47:13 2017] what is a rudimentary way to do IO with Coq? [Tue Feb 21 16:47:46 2017] how rudimentary do you need? [Tue Feb 21 16:47:56 2017] my main method would be to generate code for any serious IO application [Tue Feb 21 16:48:03 2017] but I at least need to be able to output things [Tue Feb 21 16:48:18 2017] if you just want to "model effects", you can use a Free grammar, whose terms you would evaluate at runtime using some other language [Tue Feb 21 16:48:23 2017] and very likely read some things. Just file IO [Tue Feb 21 16:48:27 2017] if you want to "program with IO in Coq", try Ynot [Tue Feb 21 16:48:46 2017] or what this guy does: https://github.com/coq-concurrency/pluto [Tue Feb 21 16:49:05 2017] "whose terms you would evaluate at runtime using some other language" I don't understand [Tue Feb 21 16:49:21 2017] erisco: if my main = print 'Hello' [Tue Feb 21 16:49:30 2017] i'd compile that to a term like; Call (Print "Hello") [Tue Feb 21 16:49:38 2017] how? [Tue Feb 21 16:49:40 2017] then I'd produce that term in, say, Haskell (via extraction) [Tue Feb 21 16:49:48 2017] are you familiar with free grammars? [Tue Feb 21 16:50:06 2017] Inductive EffectsF r := Print : string -> r -> EffectsF r [Tue Feb 21 16:50:10 2017] no, but I am mainly curious about how you're getting something out of Coq and into something else [Tue Feb 21 16:50:18 2017] Definition Effects (A : Type) := Free EffectsF A. [Tue Feb 21 16:50:24 2017] main : Effects unit [Tue Feb 21 16:50:37 2017] main := liftF (Print "Hello" tt). [Tue Feb 21 16:50:50 2017] my knowledge of Coq is just about zero so this doesn't mean anything to me :P I just want to check that it is capable of my end goal before I get started [Tue Feb 21 16:51:00 2017] if you use the Haskell extraction from Coq, it will generate a Haskell definition for EffectsF and Effects [Tue Feb 21 16:51:10 2017] allowing you to construct the Effects term in Coq, and then hand it over to Haskell for evaluation [Tue Feb 21 16:51:21 2017] there are multiple ways to reach your end goal [Tue Feb 21 16:51:26 2017] but they will all require some work [Tue Feb 21 16:51:33 2017] this is not the 'natural mode' for Coq programmers [Tue Feb 21 16:51:36 2017] okay, so there is some Coq tool I can run on the Coq program to produce Haskell code? this is called "Haskell extraction"? [Tue Feb 21 16:51:45 2017] I am guessing it is just the data definitions, or something like that [Tue Feb 21 16:51:46 2017] It's built-in, erisco. [Tue Feb 21 16:51:46 2017] yes [Tue Feb 21 16:52:17 2017] if all you want to do is dependently-typed programming, though, you may prefer Agda [Tue Feb 21 16:52:19 2017] I suppose the data definitions plus the actual data constructions you make [Tue Feb 21 16:52:30 2017] Agda has IO, and more directly links to Haskell [Tue Feb 21 16:52:38 2017] no no… I've been unhappy with that [Tue Feb 21 16:52:53 2017] well, I'd hate to say, but you're likely to be more unhappy with Coq then [Tue Feb 21 16:53:00 2017] I had an easier time doing DT with Haskell and singletons =\ [Tue Feb 21 16:53:09 2017] hmm [Tue Feb 21 16:53:29 2017] when it came to type inference, type refinement particularly, it was just a nightmare [Tue Feb 21 16:53:45 2017] well I was using Idris, but apparently the way Idris is working in some areas comes from Agda [Tue Feb 21 16:53:49 2017] so I don't want to continue with either [Tue Feb 21 16:53:52 2017] that's often just "DT" [Tue Feb 21 16:54:15 2017] gotta run [Tue Feb 21 16:54:25 2017] well, when the Haskell version is easier then their version is just wrong for me [Tue Feb 21 16:54:41 2017] the only problem I ran into with Haskell was that DataKinds is unable to suitably promote some things [Tue Feb 21 16:55:12 2017] well, it cannot promote constraints, and then additionally you cannot use data families in type families [Tue Feb 21 16:55:22 2017] so there was too much friction and issue there as well [Tue Feb 21 16:55:28 2017] maybe in a few versions oO [Tue Feb 21 16:55:36 2017] so I've buckled into trying Coq again [Tue Feb 21 16:58:54 2017] johnw, well I'd have to guess that the "natural mode" does not involve IO at all [Tue Feb 21 16:59:33 2017] but I am a programmer, not a mathematician, so I want to prove things about programs [Tue Feb 21 16:59:54 2017] and, you know, run them :P [Tue Feb 21 17:02:19 2017] I tried the same thing a few years ago. [Tue Feb 21 17:03:27 2017] Tuplanolla, how did it go? [Tue Feb 21 17:03:39 2017] In addition to proving theorems and extracting them, you have add extraction rules to get quality code out. This of course means that you also have to ensure your extraction rules are correct. [Tue Feb 21 17:04:07 2017] It was enlightening, so I'm not saying it was useless. [Tue Feb 21 17:05:12 2017] I am expecting that part of things to be quite difficult, or at least to require a lot of time [Tue Feb 21 17:05:49 2017] not even looking forward to the build script to duct tape Coq and Haskell together [Tue Feb 21 17:06:15 2017] I have some lecture notes on basic proofs and program extraction here: http://users.jyu.fi/~sapekiis/ties350/ [Tue Feb 21 17:06:36 2017] Alas it was just a brief introduction. [Tue Feb 21 17:08:07 2017] it is a starting point. Thanks [Tue Feb 21 17:10:17 2017] reading through the intro… there are many things I have yet to understand, but this one in particular is most puzzling [Tue Feb 21 17:10:22 2017] ∀ x y : Z, x * y = 0 -> x = 0 \/ y = 0 what is the = 0 about? [Tue Feb 21 17:10:41 2017] that is the implementation of ∀ A B : Prop, A /\ B -> B \/ B [Tue Feb 21 17:12:15 2017] johnw, it was particular issues that really set me off. I'll know soon enough if Coq possesses those too [Tue Feb 21 17:12:44 2017] johnw, and if it does then, well, I guess I just have to learn the unfortunate idiosyncrasies [Tue Feb 21 17:12:57 2017] What's the issue with that proposition? [Tue Feb 21 17:13:15 2017] It says that if a product is zero, either operand must be zero. [Tue Feb 21 17:13:54 2017] oh, I must have grossly misunderstood [Tue Feb 21 17:14:23 2017] I thought ∀ A B : Prop, A /\ B -> B \/ B was like a type decl and ∀ x y : Z, x * y = 0 -> x = 0 \/ y = 0 was the definition/implementation [Tue Feb 21 17:14:29 2017] but they're separate examples, aren't they [Tue Feb 21 17:14:39 2017] They are. [Tue Feb 21 17:15:50 2017] so, ∀ A B is introducing variables A and B [Tue Feb 21 17:15:56 2017] what universe are these in? [Tue Feb 21 17:16:20 2017] is the whole thing ∀ A B : Prop which is saying A and B are Props? [Tue Feb 21 17:16:33 2017] They're of type `Prop`, which is of some other type. [Tue Feb 21 17:17:00 2017] okay, so ∀ x y : Z is saying x and y have type Z i.e. are integers [Tue Feb 21 17:17:24 2017] is this equivalent to ∀ x : Z ∀ y : Z ? [Tue Feb 21 17:17:33 2017] I suppose I should download Coq and find a way to try that [Tue Feb 21 17:17:44 2017] You forgot a comma, but yes. [Tue Feb 21 17:21:41 2017] lol, seems the installer cannot handle paths with spaces in it [Tue Feb 21 17:21:55 2017] get a proof on that [Tue Feb 21 17:26:39 2017] doesn't help that it boots in command prompt which doesn't support unicode [Tue Feb 21 17:27:16 2017] You'll want CoqIDE or Proof General. [Tue Feb 21 17:27:37 2017] seems I already have CoqIDE. Maybe that came with the install [Tue Feb 21 17:28:00 2017] man, an IDE? I really am spoiled [Tue Feb 21 17:29:56 2017] so lets say I want to check that ∀ A B : Prop, A /\ B -> B \/ B is syntactically valid. How do I do that with this IDE? [Tue Feb 21 17:30:14 2017] Slap it into the buffer, save it and advance the checker to that line. [Tue Feb 21 17:32:25 2017] I don't know… I have it saved, I click the "go to cursor" button when my cursor is at the start of the line [Tue Feb 21 17:32:43 2017] Move it to the end first. [Tue Feb 21 17:32:46 2017] I click "fully check the document" but despite the line containing garbage there is no error [Tue Feb 21 17:33:11 2017] It goes to the first full stop before the cursor. [Tue Feb 21 17:33:41 2017] hm, no dice [Tue Feb 21 17:34:44 2017] Does `Check 42.` produce anything? [Tue Feb 21 17:35:05 2017] yes [Tue Feb 21 17:35:49 2017] oh, I need a period I suppose [Tue Feb 21 17:36:08 2017] I guess I shouldn't call it a full stop then. [Tue Feb 21 17:36:10 2017] so it complains ∀ is an undefined token [Tue Feb 21 17:36:32 2017] I know what a full stop is but I thought it as a line return anyways :P [Tue Feb 21 17:36:46 2017] The top level is actually reserved for Vernacular, so you can't write Gallina there. [Tue Feb 21 17:37:54 2017] Try `Theorem whatever : forall A B : Prop, A /\ B -> B \/ B.`. [Tue Feb 21 17:38:15 2017] does Vernacular just introduce definitions? [Tue Feb 21 17:38:32 2017] It manages imports, definitions, extraction and all that. [Tue Feb 21 17:39:11 2017] alright, I got something with that [Tue Feb 21 17:39:17 2017] now why "forall" and not "∀"? [Tue Feb 21 17:39:23 2017] Because I'm lazy. [Tue Feb 21 17:39:27 2017] Now get proving! [Tue Feb 21 17:39:33 2017] ∀ does not work for me [Tue Feb 21 17:40:07 2017] I've gone through all this effort of setting up a compose key and I want to use it :P [Tue Feb 21 17:40:15 2017] (ノಠ益ಠ)ノ彡┻━┻ [Tue Feb 21 17:40:29 2017] How did you compose that one? [Tue Feb 21 17:40:45 2017] up up down down left right left right b a [Tue Feb 21 17:45:27 2017] I am guessing that I want this https://coq.inria.fr/library/Coq.Unicode.Utf8_core.html [Tue Feb 21 17:46:03 2017] I can copy it in and it works, but Import Coq.Unicode.Utf8_core. complains it is not a module [Tue Feb 21 17:46:06 2017] is there a package manager? [Tue Feb 21 17:46:14 2017] Say `Require Import`. [Tue Feb 21 17:47:50 2017] I love that Coq even ships with fonts that support the characters. Someone has put a lot of work into this [Tue Feb 21 17:54:28 2017] "or a form of subset types called Σ-types, e.g. the type of even natural numbers: {n : N | even n}" [Tue Feb 21 17:54:36 2017] is that read "sum types" or "sigma types" ? [Tue Feb 21 17:55:01 2017] and are these also called "refinement types" ? [Tue Feb 21 17:55:06 2017] Rather "dependent pair types". [Tue Feb 21 17:56:54 2017] can't say I've understood what that is [Tue Feb 21 18:04:53 2017] if we have {x:t} -> r as part of the language already then don't we already have dependent pairs? [Tue Feb 21 18:05:48 2017] because I can just write a constructor C : {x : t} -> F x -> Pair t F [Tue Feb 21 18:07:50 2017] is the {n : N | even n} feature just an ad hoc / convenient way to define these? [Tue Feb 21 18:08:29 2017] If you take a look at `exists`, it's not actually primitive either. [Tue Feb 21 18:08:53 2017] where? [Tue Feb 21 18:09:01 2017] In Coq. [Tue Feb 21 18:09:16 2017] I haven't seen it yet [Tue Feb 21 18:10:11 2017] by "either" do you mean to say that {n : N | even n} is not a primitive feature? [Tue Feb 21 18:10:33 2017] well, I presume it is syntactically, but you can achieve the same without [Tue Feb 21 18:14:13 2017] Indeed, {n : N | even n} is just another inductive type. Like you say, it has one constructor of type " forall x : A, P x -> {x : A | P x}" [Tue Feb 21 18:16:26 2017] no x argument? [Tue Feb 21 18:16:48 2017] In "forall x : A, P x -> {x : A | P x}", the first argument is x [Tue Feb 21 18:16:55 2017] (unless I misunderstood what you just meant) [Tue Feb 21 18:17:06 2017] okay, I wasn't aware [Tue Feb 21 18:17:13 2017] I do not fully understand the notation yet [Tue Feb 21 18:17:45 2017] Well, "forall (x : A), B" is the type of functions that take an argument x of type A, and return something of type B (which might mention x) [Tue Feb 21 18:17:48 2017] in Haskell the forall is apart [Tue Feb 21 18:18:03 2017] I think you wrote that {x : A} -> B earlier [Tue Feb 21 18:18:13 2017] well that'd be the Idris version [Tue Feb 21 18:35:13 2017] Cypi, it is strange to me why the introduction of variables is followed by a comma rather than → [Tue Feb 21 18:35:25 2017] if they are also parameters [Tue Feb 21 18:36:12 2017] Well, that's on the level of types. A term of type "forall x : A, B" could have the shape "fun x : A => t" [Tue Feb 21 18:37:05 2017] λ (A B : Prop) (H : A ∧ B), and_ind (λ (_ : A) (H1 : B), or_introl H1) H [Tue Feb 21 18:37:06 2017] : ∀ A B : Prop, A ∧ B → B ∨ B [Tue Feb 21 18:37:13 2017] so it seems the commas can be used in terms as well [Tue Feb 21 18:37:31 2017] It's just syntax anyway [Tue Feb 21 18:37:44 2017] yes but I am still trying to grapple with it [Tue Feb 21 18:37:46 2017] What you pasted use a notation though, "fun x : A => t" is the primitive way [Tue Feb 21 18:39:05 2017] By the way, you also have "A -> B" which is a notation for "forall _ : A, B", meaning that the return type does not depend on the input (so "A -> B" is just the type of normal functions from A to B) [Tue Feb 21 18:42:01 2017] can you interactively do a proof with CoqIDE? [Tue Feb 21 18:42:59 2017] Yes, that's the point. You can step through a proof using the arrows at the top (or rather the keyboard shortcuts in the "Navigation" menu). [Tue Feb 21 18:43:35 2017] So you can state some theorem, and then CoqIDE will show you the current goal, you can input some tactics, step through them, CoqIDE will show you the current goal(s) after execution of these tactics, and so on [Tue Feb 21 18:44:49 2017] okay, so if you could clear this up for me it would help a lot [Tue Feb 21 18:45:37 2017] I realise that fundamentally we're writing a proof like we would a program (the Curry-Howard correspondence) [Tue Feb 21 18:45:56 2017] but then to make this less tedious there are tactics [Tue Feb 21 18:46:14 2017] so say I have Theorem test : ∀ A B : Prop, A ∧ B → B ∨ B. [Tue Feb 21 18:46:40 2017] how does this compare to declaring a function "test" with type ∀ A B : Prop, A ∧ B → B ∨ B ? [Tue Feb 21 18:47:09 2017] You can pry the actual function out of the finished proof. [Tue Feb 21 18:47:18 2017] The end-result is basically the same: in both cases, you are writing a term (either directly or with tactics) whose type is "forall A B : Prop, A /\ B -> B \/ B"" [Tue Feb 21 18:47:30 2017] In CoqIDE it's behind one of F1 to F4. [Tue Feb 21 18:49:38 2017] can functions be defined or just theorems? [Tue Feb 21 18:50:14 2017] okay let me ask this a different way [Tue Feb 21 18:50:17 2017] I'm not sure I understand the question. Theorems are just terms like any others. [Tue Feb 21 18:50:25 2017] say I just wanted to do it as rudimentary as possible [Tue Feb 21 18:50:36 2017] (except that we usually only care for the type of a theorem, not the actual term) [Tue Feb 21 18:50:44 2017] so I just want to declare that "test" has a type, and then I want to write the proof term for it without tactics [Tue Feb 21 18:52:01 2017] Definition test : forall A B : Prop, A /\ B -> B \/ B := fun (A B : Prop) (H : A /\ B) => match H with conj _ H' => or_introl H' end. [Tue Feb 21 18:52:06 2017] You could write it like that [Tue Feb 21 18:55:27 2017] is there any interactive option with this approach? say I could leave one or more holes [Tue Feb 21 18:56:03 2017] Yup [Tue Feb 21 18:56:27 2017] Definition test : forall A B : Prop, A /\ B -> B \/ B. Proof. refine (fun (A B : Prop) (H : A /\ B) => _). ... [Tue Feb 21 18:56:35 2017] so using the tactic "refine" for instance [Tue Feb 21 18:56:49 2017] another way would to use the Program facility and writing stuff like: [Tue Feb 21 18:57:09 2017] Program Definition test : forall A B : Prop, A /\ B -> B \/ B := fun (A B : Prop) (H : A /\ B) => _ . [Tue Feb 21 18:57:14 2017] and it will generate subproofs for you [Tue Feb 21 18:57:29 2017] (but I wouldn't advise learning this first, Program is not primitive at all) [Tue Feb 21 18:58:23 2017] I appreciate avoiding any complications for now, thanks [Tue Feb 21 18:58:44 2017] refine, on the contrary, is very primitive: this is the basic building block of any tactic [Tue Feb 21 18:59:26 2017] what do I import to get that? [Tue Feb 21 18:59:32 2017] refine? Nothing [Tue Feb 21 18:59:41 2017] Error: The reference refine was not found in the current environment. [Tue Feb 21 19:00:14 2017] oh that is because I was still using := [Tue Feb 21 19:00:28 2017] Yes, refine is still a tactic, so you need to be in proof-mode [Tue Feb 21 19:02:51 2017] okay, so now what is the difference between "Theorem" and "Definition"? [Tue Feb 21 19:03:13 2017] Not much really. With Definition you can use :=, whereas with Theorem you can't. [Tue Feb 21 19:03:28 2017] But if you go in proof-mode, then I don't think there is any difference. [Tue Feb 21 19:05:30 2017] http://lpaste.net/352827 what is this error message about? [Tue Feb 21 19:05:39 2017] is it trying to synthesize the term? [Tue Feb 21 19:06:07 2017] Yes. You wrote an incomplete definition, and it needs to be complete (because not using the facilities of Program), so Coq is trying to infer it [Tue Feb 21 19:06:39 2017] In some cases it can (mainly if it's a type annotation which is missing), but there it won't be able to do it trivially, so it won't do it at all [Tue Feb 21 19:07:54 2017] Tuplanolla, F1 brings up the query pane [Tue Feb 21 19:08:27 2017] so I Print test. ? [Tue Feb 21 19:11:21 2017] Cypi, so this interactive proof with refine is still using the same imperative proof method [Tue Feb 21 19:11:24 2017] but that is alright I suppose [Tue Feb 21 19:11:58 2017] I find it to be alright. I mean, it basically does what you wanted: you provide a proof term with holes in it, and then you need to provide another proof term for each of these holes and so on [Tue Feb 21 19:14:23 2017] okay awesome, thanks [Tue Feb 21 19:14:35 2017] I'll have a hundred more questions but this should be enough to get me started [Tue Feb 21 19:14:57 2017] I'll have a peer through the available libraries to see what I won't have to define myself [Tue Feb 21 19:15:35 2017] but first a little test… [Tue Feb 21 19:32:13 2017] ah, so Coq doesn't do this either, hrm [Tue Feb 21 19:32:16 2017] it is really quite frustrating [Tue Feb 21 19:32:58 2017] do what? [Tue Feb 21 19:33:03 2017] this is a ported example so don't expect amazing Coq code, but this is what I'm talking about http://lpaste.net/352830 [Tue Feb 21 19:33:36 2017] in Haskell when you pattern match on "n" it refines the type of n [Tue Feb 21 19:34:10 2017] well, in Haskell we'd be pattern matching on a singleton but same idea [Tue Feb 21 19:34:24 2017] so it learns that n = 0 in the first case and n = S n' in the second [Tue Feb 21 19:34:31 2017] none of Coq, Agda, or Idris do this [Tue Feb 21 19:34:35 2017] Ah yes, so, this is slightly complicated... [Tue Feb 21 19:34:59 2017] but there is an insane example of it surprisingly working in Idris [Tue Feb 21 19:35:14 2017] based on some crazy rules [Tue Feb 21 19:35:21 2017] You can have the fact that "n = 0" in the first branch of your match, but you still cannot really unify n and 0: you only know that they are equal propositionally [Tue Feb 21 19:35:59 2017] So if you really want to write something like this, you will need some rewriting, and this is clearly cumbersome to write (and use) [Tue Feb 21 19:36:14 2017] (by "rewriting" I mean using a proof of equality to rewrite the type of something) [Tue Feb 21 19:37:03 2017] what does "propositionally equal" mean? [Tue Feb 21 19:37:55 2017] It means that you have a proof of the equality between n and 0 [Tue Feb 21 19:38:08 2017] So literally, you have in your context an hypothesis of type "n = 0" [Tue Feb 21 19:38:26 2017] well, then what is the problem with "only" having propositional equality? [Tue Feb 21 19:38:56 2017] The problem is that Coq won't be able to unify n and 0, which is why it complains in your example [Tue Feb 21 19:39:14 2017] why not? what does it require for that? [Tue Feb 21 19:39:39 2017] that is exactly what would happen in Haskell and so I've already got my mind set in a certain way [Tue Feb 21 19:39:53 2017] It would require for n and 0 to be _definitionally_ equal. For instance, "1 + 1" and "2" are definitionally equal [Tue Feb 21 19:40:10 2017] (to see what I meant about rewriting, this definition works: http://lpaste.net/352831 ) [Tue Feb 21 19:40:30 2017] (disclaimer: it's more complicated :p ) [Tue Feb 21 19:41:23 2017] look at this Idris example https://github.com/idris-lang/Idris-dev/issues/3659 [Tue Feb 21 19:41:34 2017] does that make any sense to you? I reported that as a possible bug and apparently it is not [Tue Feb 21 19:42:11 2017] Actually, it makes sense! Let me write something similar in Coq [Tue Feb 21 19:42:24 2017] (it won't be exactly the same, because Coq's pattern-matching is more primitive in a sense) [Tue Feb 21 19:42:28 2017] oh god -.- [Tue Feb 21 19:42:41 2017] * *sighs* [Tue Feb 21 19:42:47 2017] I don't know if I can take it! but I'll try [Tue Feb 21 19:42:58 2017] you have to understand that that violates such basic principles [Tue Feb 21 19:43:21 2017] let x = y in m if I cannot substitute x for y in m and have it be the same then something is horribly wrong [Tue Feb 21 19:43:59 2017] http://lpaste.net/352832 [Tue Feb 21 19:44:04 2017] I cannot even imagine any sane reasoning behind that not being the case… but I guess I am about to find out [Tue Feb 21 19:44:26 2017] So, in Coq it might be more obvious why it works [Tue Feb 21 19:44:52 2017] not in the slightest I am afraid [Tue Feb 21 19:45:04 2017] The trick is that on the outside, the term 'y' has the type "Sing n". But inside each branch, it has type "Sing 0" and "Sing (S n')" respectively [Tue Feb 21 19:45:13 2017] which is why you can write the "eqOnly ..." stuff [Tue Feb 21 19:46:27 2017] sure, but it doesn't make any sense to me why that works and the other doesn't [Tue Feb 21 19:46:33 2017] The same with more type annotations: http://lpaste.net/352833 [Tue Feb 21 19:47:10 2017] In your first example (the one that doesn't work), instead of 'y', you have directly "MkSing n", whose type is "Sing n" and stays "Sing n" all along [Tue Feb 21 19:47:28 2017] In the example that does work, the type of 'y' is changed through the pattern-matching [Tue Feb 21 19:47:41 2017] [to be faire, dependent pattern-matching is complicated] [Tue Feb 21 19:47:44 2017] [fair*] [Tue Feb 21 19:48:36 2017] "< erisco> let x = y in m if I cannot substitute x for y in m and have it be the same then something is horribly wrong" notice that in Coq, you are right, it doesn't work. If I don't add the trick of passing 'y' as an argument to the match, then it won't compile [Tue Feb 21 19:50:42 2017] I did not notice. So then the let/in part is unnecessary [Tue Feb 21 19:51:09 2017] you've done the equivalent of let x = y in m ≡ (\x -> m) y [Tue Feb 21 19:51:18 2017] though I guess this doesn't work in Coq [Tue Feb 21 19:51:30 2017] all the basic stuff I know doesn't work anymore and that bothers me [Tue Feb 21 19:52:31 2017] You are right, the let-in is unnecessary, you can do the substitution and it doesn't change anything: http://lpaste.net/352834 [Tue Feb 21 19:52:53 2017] it isn't a valid one in Coq [Tue Feb 21 19:52:56 2017] What is this singleton business about? [Tue Feb 21 19:52:58 2017] it doesn't work the other way at least [Tue Feb 21 19:53:01 2017] What I just pasted is valid [Tue Feb 21 19:53:11 2017] Tuplanolla, it is just a ported example I had from Idris [Tue Feb 21 19:53:13 2017] Notice that you cannot substitue the y inside the match, this is not the same [Tue Feb 21 19:53:17 2017] substitute* [Tue Feb 21 19:53:21 2017] where the Sing stuff is further ported from Haskell lol [Tue Feb 21 19:53:36 2017] I looked at Hackage and found automatically generated instance vomit. [Tue Feb 21 19:53:56 2017] yes it is awful in that way [Tue Feb 21 19:54:05 2017] I just rewrote the parts I cared about by hand so it wasn't so arcane [Tue Feb 21 19:54:43 2017] they have a feature where using TH you can promote regular Haskell code [Tue Feb 21 19:54:56 2017] and that is where the vomit comes from because they in turn define a bunch of things using their TH [Tue Feb 21 20:01:41 2017] Cypi, I wish I could understand why it makes sense… [Tue Feb 21 20:02:24 2017] let me try sticking holes in some places and maybe that reveals something [Tue Feb 21 20:02:29 2017] Why it makes sense that your first example does not work, you mean? [Tue Feb 21 20:02:40 2017] why the first doesn't work [Tue Feb 21 20:03:28 2017] The typing in Coq is actually quite easy to follow (sort of). So at some point it needs to typecheck the term "eqOnly n (MkSing 0) (MkSing n)" [Tue Feb 21 20:03:52 2017] due to the type of MkSing, you know that "(MkSing 0)" has type "Sing 0", and that "(MkSing n)" has type "Sing n" [Tue Feb 21 20:04:21 2017] but these types need to be exactly the same for this to typecheck. And they are not. End of story in this case. [Tue Feb 21 20:05:03 2017] The fact that you could, at this point in the program, have a proof of "n = 0", does not change anything to the fact that "Sing 0" and "Sing n" cannot be unified [Tue Feb 21 20:05:47 2017] which is mind-numbingly confusing [Tue Feb 21 20:05:53 2017] but okay, why does it work in the other case [Tue Feb 21 20:06:14 2017] So, let's take this one http://lpaste.net/352833 [Tue Feb 21 20:07:02 2017] At some point, it needs to typecheck the term "eqOnly 0 (MkSing 0) y". The type of (MkSing 0) is (Sing 0), and the type of y is (Sing 0), so they are the same, good, it typechecks! [Tue Feb 21 20:07:19 2017] Same for the other branch. So each branch can be typechecked [Tue Feb 21 20:07:29 2017] why is the type of y Sing 0 [Tue Feb 21 20:07:56 2017] Well, locally, very simply because I have written "fun (y : Sing 0) => eqOnly 0 (MkSing 0) y", so you are in a function and y is an argument of type (Sing 0) [Tue Feb 21 20:08:10 2017] Now the tricky part is: why does it make sense for these two branches to have different types? [Tue Feb 21 20:08:32 2017] The first one has the type "Sing 0 -> nat", while the second one has the type "Sing (S n') -> nat" [Tue Feb 21 20:09:02 2017] [now, as I said, what follows is tricky, especially since I probably don't explain it that well] [Tue Feb 21 20:09:22 2017] Now you need to take notice of the "return" annotation in the match [Tue Feb 21 20:09:51 2017] This is the expect type of the whole match, which in this case is "Sing n' -> nat", where you can see that n' is bound just before by the "as n'" clause [Tue Feb 21 20:09:56 2017] expected* [Tue Feb 21 20:10:07 2017] why is "n as n'" necessary [Tue Feb 21 20:10:14 2017] can you not just use n? [Tue Feb 21 20:10:21 2017] It is not actually, in this case you could just use case [Tue Feb 21 20:10:30 2017] just use n* [Tue Feb 21 20:10:44 2017] but in general, you might do the match on a more complicated term, and then you need a name to refer to the whole term [Tue Feb 21 20:10:59 2017] "as n'" introduces such a name [Tue Feb 21 20:11:09 2017] okay [Tue Feb 21 20:11:19 2017] So, we state that "Sing n' -> nat" is the expected type of the match, where n' stands for the term being matched on [Tue Feb 21 20:11:32 2017] so how does it accept that Sing 0 and Sing (S n') unifies with Sing n [Tue Feb 21 20:11:47 2017] For this to typecheck, Coq checks that each branch has this type, but where n' is replaced by 0 and (S n') respectively [Tue Feb 21 20:12:02 2017] (it is replaced by what is before the "=>" in each branch of the match, basically) [Tue Feb 21 20:12:24 2017] So the first branch needs to have the type "Sing 0 -> nat", and the second branch needs to have the type "Sing (S n') -> nat" [Tue Feb 21 20:12:37 2017] This is exactly what we have, so Coq is happy and can typecheck the whole match [Tue Feb 21 20:13:17 2017] well that's funny, because it seems to be using the fact that n = 0 to substitute n for 0 [Tue Feb 21 20:13:26 2017] and that n = S n' similarly [Tue Feb 21 20:13:35 2017] so I still fail to see the difference [Tue Feb 21 20:13:43 2017] other than they chose it to work in this one case and not the other [Tue Feb 21 20:14:26 2017] In the example that fails, this is more complicated: you are already inside the match, and suddenly you need to remember that this term of type "Sing n" can actually be seen as having type "Sing 0" [Tue Feb 21 20:14:51 2017] I believe this would easily be undecidable (what if there are several nested match and so on? I don't know) [Tue Feb 21 20:15:22 2017] someone said the same thing and I don't get that either [Tue Feb 21 20:15:25 2017] Whereas what I described is very mechanical: there is stuff that happens only at the match itself, and then we can just continue and forget that we are even in a match, it does not matter [Tue Feb 21 20:15:32 2017] if I saw an example where it is undecidable that would help [Tue Feb 21 20:15:40 2017] but it seems plain as day to me [Tue Feb 21 20:16:53 2017] I'm not quite sure, I'm no expert in this kind of stuff. But I believe that it would be like accumulating rewriting rules "n <-> 0" and so on for each match that you go through [Tue Feb 21 20:17:05 2017] and then try to tell if two terms are equal modulo these rewriting rules [Tue Feb 21 20:17:16 2017] I think that's undecidable? Not entirely sure as I said [Tue Feb 21 20:17:23 2017] but it certainly looks more complicated to me [Tue Feb 21 20:19:26 2017] okay, I am on the cusp of understanding this, but I need to mull it over [Tue Feb 21 20:25:12 2017] how do you focus on a subgoal? [Tue Feb 21 20:28:20 2017] You can use "Focus 2" to focus on the second subgoal [Tue Feb 21 20:28:24 2017] is that what you mean? [Tue Feb 21 20:29:38 2017] yes thanks [Tue Feb 21 20:33:10 2017] so it is actually an error for one of the branches to have type Sing n -> nat [Tue Feb 21 20:34:48 2017] Indeed [Tue Feb 21 20:35:12 2017] but valid if they both have that type [Tue Feb 21 20:35:43 2017] Well if they both have that type, and this is the expected type of the match, then yes [Tue Feb 21 20:36:00 2017] I don't get how that works [Tue Feb 21 20:36:29 2017] if you keep the explicit (Sing n' -> nat) as in my example, then having both branch with the type (Sing n -> nat) would be an error [Tue Feb 21 20:36:35 2017] I can see the match substituting n, in the type, everywhere [Tue Feb 21 20:37:02 2017] but that doesn't explain why both branches with type Sing n -> nat works [Tue Feb 21 20:37:07 2017] n shouldn't exist anymore [Tue Feb 21 20:37:21 2017] It works only if the return type of the match is (Sing n -> nat), and not (Sing n' -> nat) [Tue Feb 21 20:37:24 2017] n still exists [Tue Feb 21 20:37:27 2017] and if it does then I don't understand why just one of the branches can't have that type [Tue Feb 21 20:37:48 2017] because inside the match, there is no link anymore between n and 0 or n and (S n')) [Tue Feb 21 20:39:16 2017] why is that relevant [Tue Feb 21 20:40:21 2017] this is so confusing [Tue Feb 21 20:40:32 2017] let me paste another example [Tue Feb 21 20:42:02 2017] oh I think I had an issue with shadowing just then [Tue Feb 21 20:42:39 2017] It's possible. That's why I tried to introduce the "as n'" clause even though it's unnecessary for instance. (and actually, I should have called that m, since it's not the same n' as in the "S n' => ..." case) [Tue Feb 21 20:44:31 2017] lpaste isn't working again just a minute [Tue Feb 21 20:45:42 2017] you can choose between an ad-laden site or one which goes down every hour [Tue Feb 21 20:46:44 2017] know any good ones? [Tue Feb 21 20:47:19 2017] You can use this temporarily https://paste.isomorphis.me/ [Tue Feb 21 20:47:34 2017] https://paste.isomorphis.me/ufh [Tue Feb 21 20:47:40 2017] (I don't know how resillient it is though, since I think it's kind of a private server) [Tue Feb 21 20:48:05 2017] So, in order. [Tue Feb 21 20:48:28 2017] 1) The type of each branch needs to be the same as "Sing nn -> nat", where nn is replaced by 0 and (S n') respectively [Tue Feb 21 20:48:47 2017] The second branch is correct, but the type of the first branch needs to be "Sing 0 -> nat", which is not the case [Tue Feb 21 20:49:21 2017] 2) The type of each branch needs to be the same as "Sing n -> nat", where nn is replaced by 0 and (S n') respectively [Tue Feb 21 20:49:33 2017] (no typo in my sentence, I am just trying to be as mechanical as possible) [Tue Feb 21 20:50:10 2017] The first branch is correct, but the type of the second branch needs to be "Sing n -> nat", whereas it is "Sing (S n') -> nat" [Tue Feb 21 20:51:02 2017] okay, so I think I get this much of it [Tue Feb 21 20:51:05 2017] 3) Here, this is because the annotations are not explicit enough. This is actually the same case at the first one. The "n" in the return clause is not the same "n" which is defined elsewhere [Tue Feb 21 20:51:19 2017] when we use "x as y" we're introducing a name y which is explicitly rewritten in the return type [Tue Feb 21 20:51:42 2017] yup [Tue Feb 21 20:51:58 2017] okay, let me predict something that will work then [Tue Feb 21 20:53:12 2017] okay, so this alias is not in scope in the branch expressions [Tue Feb 21 20:53:43 2017] I predicted this to work https://paste.isomorphis.me/4uR [Tue Feb 21 20:54:24 2017] It wouldn't make much sense to have it in scope. This "alias" is part of the type annotations, you couldn't for instance return it [Tue Feb 21 20:55:26 2017] return it? [Tue Feb 21 20:55:59 2017] Writing something like "match n as m with 0 => m | S n' => m end" wouldn't make a lot of sense [Tue Feb 21 20:56:04 2017] (that's what I meant by "return it") [Tue Feb 21 20:56:20 2017] I don't see why not but I guess that's just Coq [Tue Feb 21 20:56:38 2017] Well, ultimately, what you are computing with are terms, not their types [Tue Feb 21 20:57:28 2017] so the type inference when we give none of these annotations is doing a lot [Tue Feb 21 20:57:30 2017] or so it seems [Tue Feb 21 20:58:02 2017] It is, and it has improved a lot in the last version of Coq. But sometimes it will just fail and you will have to prived these annotations [Tue Feb 21 20:58:12 2017] last versions* even [Tue Feb 21 20:58:24 2017] it has to take Sing 0 and Sing (S n') and figure out… I don't know what [Tue Feb 21 20:58:29 2017] and provide* (sorry, I can't write tonight) [Tue Feb 21 21:00:27 2017] Well, in this case, it knows that the whole match needs to have the type (Sing n -> nat), because it is applied to the term "y" which has type (Sing n) [Tue Feb 21 21:00:53 2017] ah yes, that is a help [Tue Feb 21 21:01:45 2017] So it is looking for some predicate (P m) ("match n as m return P m with ... end"), such that (P n) is exactly (Sing n -> nat), (P 0) is exactly (Sing 0 -> nat), and (P (S n')) is exactly (Sing (S n') -> nat) [Tue Feb 21 21:01:51 2017] in this case it's not too difficult [Tue Feb 21 21:04:40 2017] this is really obscured in Idris [Tue Feb 21 21:04:49 2017] like, invisible [Tue Feb 21 21:05:11 2017] The pattern-matching in Idrid (and Agda) is more powerful. It will actually rewrite some types in the context [Tue Feb 21 21:05:37 2017] So in this case, if there is something of type "Sing n" in the context, its type will be rewritten to "Sing 0" and "Sing (S n')" respectively [Tue Feb 21 21:05:43 2017] in Coq you need to make that explicit [Tue Feb 21 21:05:55 2017] (both have their pros and cons) [Tue Feb 21 21:11:08 2017] and it only ever rewrites in types [Tue Feb 21 21:13:11 2017] well that is a bit of a moot point seeing as how it works [Tue Feb 21 21:13:30 2017] (I need to go, sorry. Good luck for the rest!) [Tue Feb 21 21:13:30 2017] anyways, alright, I think I see what is going on [Tue Feb 21 21:13:37 2017] yes thank-you for the help and have a good night [Tue Feb 21 21:14:40 2017] now I am having a hard time recovering how I was confused [Wed Feb 22 12:29:06 2017] is Gregory Malecha here? [Wed Feb 22 13:18:08 2017] what is the difference between Inductive and Structure? Is the only difference that Structure is products where as Inductive is products and sums? [Wed Feb 22 13:18:21 2017] and maybe Structures cannot be recursive whereas Inductive can but I am not sure [Wed Feb 22 13:19:33 2017] Record/Structure is equivalent to a chain of sigmas, so it's a special case of what you *could* do with Inductive [Wed Feb 22 13:20:40 2017] what feature does it miss? [Wed Feb 22 13:21:05 2017] it's non-recursive [Wed Feb 22 13:21:08 2017] it doesn't do sums [Wed Feb 22 13:21:19 2017] you pretty much nailed it before [Wed Feb 22 13:21:22 2017] I thought sigma gave you sums [Wed Feb 22 13:21:41 2017] only if you already have a sum [Wed Feb 22 13:21:49 2017] { b : bool | if b then X else Y } [Wed Feb 22 13:22:16 2017] right, okay [Wed Feb 22 13:23:41 2017] are Record and Structure synonymous [Wed Feb 22 13:24:01 2017] yes [Wed Feb 22 13:27:27 2017] what is the naming convention? it seems to be snake case [Wed Feb 22 13:27:39 2017] whatever you prefer [Wed Feb 22 13:27:43 2017] I think the stdlib is mostly snake [Wed Feb 22 13:28:02 2017] but since there's no large community of library developers, there's not much collision [Wed Feb 22 13:28:40 2017] should anything start with a capital? [Wed Feb 22 13:28:53 2017] Coq doesn't care [Wed Feb 22 13:28:59 2017] I know [Wed Feb 22 13:29:04 2017] the only thing that must start with a capital is a Vernacular command [Wed Feb 22 13:29:43 2017] I haven't used snake in a long time so maybe I'll use that for fun [Wed Feb 22 13:30:05 2017] I use one style for a year and then I think the grass is greener on the other side [Wed Feb 22 13:36:22 2017] can Structure/Record not take parameters? [Wed Feb 22 13:37:29 2017] when I satisfy the grammar I then am told a sort was expected [Wed Feb 22 13:37:53 2017] it can [Wed Feb 22 13:38:06 2017] Record Foo (A : Type) : Type -> Type := { ... }. [Wed Feb 22 13:38:19 2017] hmm [Wed Feb 22 13:38:22 2017] maybe it can't take indices [Wed Feb 22 13:38:23 2017] let me try [Wed Feb 22 13:38:38 2017] yeah, no indices [Wed Feb 22 13:38:40 2017] just parameters [Wed Feb 22 13:38:46 2017] another restriction [Wed Feb 22 13:39:03 2017] what is an index? [Wed Feb 22 13:39:11 2017] in the above, "Type ->" [Wed Feb 22 13:39:40 2017] well what is (A : Type) ? [Wed Feb 22 13:39:44 2017] a parameter [Wed Feb 22 13:39:53 2017] I am confused [Wed Feb 22 13:39:58 2017] what is the confusion? [Wed Feb 22 13:40:09 2017] I actually don't know what (A : Type) is there [Wed Feb 22 13:40:17 2017] it's a parameter to Foo [Wed Feb 22 13:40:21 2017] I thought things were introduced with ∀/forall/λ [Wed Feb 22 13:40:23 2017] just like a parameter to a function [Wed Feb 22 13:40:36 2017] sometimes you can do either [Wed Feb 22 13:40:45 2017] either what? [Wed Feb 22 13:40:47 2017] Definition foo (A : Type) : Type [Wed Feb 22 13:40:55 2017] Definition foo : forall (A : Type), Type [Wed Feb 22 13:41:35 2017] but I thought that (A : Type) (B : Type), Type was the same as (A : Type) : Type -> Type [Wed Feb 22 13:41:43 2017] it almost is [Wed Feb 22 13:41:58 2017] depends on the context [Wed Feb 22 13:42:04 2017] for an Inductive type, it's very different [Wed Feb 22 13:42:16 2017] Inductive Foo (A : Type) : Type -> Type. [Wed Feb 22 13:42:19 2017] is quite different from [Wed Feb 22 13:42:24 2017] Inductive Foo (A : Type) (B : Type) : Type. [Wed Feb 22 13:42:30 2017] why? [Wed Feb 22 13:42:34 2017] it moves an index to a parameter [Wed Feb 22 13:42:49 2017] I don't know the difference between indices and parameters then [Wed Feb 22 13:43:17 2017] https://stackoverflow.com/questions/24600256/difference-between-type-parameters-and-indices [Wed Feb 22 13:44:19 2017] okay, well, I might ahve guessed that much, but I am still confused [Wed Feb 22 13:44:45 2017] (n : nat) (m : Fin n), Type isn't this indexed? [Wed Feb 22 13:44:47 2017] I don't really have time just now to repeat the material that exists on this, so I recommend to keep reading. [Wed Feb 22 13:45:53 2017] what you described as indices and parameters I thought was the other way around [Wed Feb 22 13:46:08 2017] that to the left are the indices (or potentially) and to the right are only parameters [Wed Feb 22 13:46:24 2017] parameters are left, and to the left of the colon [Wed Feb 22 13:46:35 2017] are fixed* [Wed Feb 22 13:46:39 2017] indices may vary by constructor, and are to the right of the colon [Wed Feb 22 13:47:10 2017] okay but we have to introduce the index before it is used, right [Wed Feb 22 13:47:19 2017] yes [Wed Feb 22 13:47:33 2017] we introduce something with the shape (x : t) and then later use this as p x (or something like this) [Wed Feb 22 13:47:45 2017] but we cannot put anything of the form (x : t) to the right [Wed Feb 22 13:47:50 2017] and so this has to be on the left [Wed Feb 22 13:47:55 2017] and so the indexes have to be on the left [Wed Feb 22 13:48:12 2017] meaning parameters are on the right [Wed Feb 22 13:49:36 2017] from Chlipala's book: " Parameters are those arguments declared with section variables or with entries to the left of the first colon in an inductive definition." [Wed Feb 22 13:51:30 2017] I'll have to remain confused on this for now then [Wed Feb 22 13:51:54 2017] I don't know what you meant by "we introduce something with the shape (x : t)" [Wed Feb 22 13:52:00 2017] or what it had to do with inductive parameters... [Wed Feb 22 13:52:27 2017] inductive parameters? oO [Wed Feb 22 13:52:50 2017] Inductive Foo (parameter : Type) : forall index : Type, Type. [Wed Feb 22 13:54:40 2017] ah, I think I am just misunderstanding the notation [Wed Feb 22 13:55:44 2017] I was thinking of what goes before and after the comma, not the colon [Wed Feb 22 13:55:54 2017] I wasn't seeing that the colon was a different thing altogether [Wed Feb 22 13:56:01 2017] I haven't a clue what the colon is about [Wed Feb 22 13:56:11 2017] it's the usual "type" colon [Wed Feb 22 13:56:11 2017] seems redundant for all I can tell [Wed Feb 22 13:56:44 2017] Structure colour : ∀ (n : nat) (m : Fin n), Set and Structure colour (n : nat) (m : Fin n) : Set both compile [Wed Feb 22 13:56:52 2017] are these any different? [Wed Feb 22 13:56:52 2017] the way I think about it, an inductive type with parameters is an inductive family. If you have Inductive Foo (n : nat) : Type , you have a family of types Foo 0, Foo 1, Foo 2.. etc. And the constctors for them are uniform in the sense that you can only write Inductive Foo (n : nat) := mkFoo : bla -> Foo n. If you were to write Inductive Foo : nat -> Type, then you could have a constructor bar : forall n, P n -> Foo n, or something like this. [Wed Feb 22 13:57:36 2017] or the List example at that stackoverflow link that johnw has posted [Wed Feb 22 13:58:24 2017] it actually explains why you want to define the type of vectors as Vec (T : Type) : nat -> Type [Wed Feb 22 13:58:44 2017] T (the paramter) stays the same but the natural number (the index) may vary [Wed Feb 22 13:59:45 2017] wait what… CoqIDE you're being weird on me again XD [Wed Feb 22 14:00:01 2017] Fin doesn't exist yet it gave me the green light more than once [Wed Feb 22 14:00:03 2017] now just to tell me it fails [Wed Feb 22 14:00:16 2017] why do they call it "t"? geez [Wed Feb 22 14:00:23 2017] how is that not going to collide all over the place [Wed Feb 22 14:00:31 2017] because you almost always refer to it as Fin.t [Wed Feb 22 14:00:34 2017] it's within a module [Wed Feb 22 14:00:49 2017] usually when a module defines an algebraic theory over a type, the type is just called 't' [Wed Feb 22 14:01:27 2017] okay, so the version with ∀ actually fails [Wed Feb 22 14:01:41 2017] I don't exactly see why that should be, but I suppose that is just the syntax they've chosen [Wed Feb 22 14:05:12 2017] Well, what sort of behaviour would you expect? [Wed Feb 22 14:05:32 2017] I'd just expect them to be equivalent [Wed Feb 22 14:05:33 2017] You are defining a new type that lives in T = forall n (m : Fin n), Set [Wed Feb 22 14:05:57 2017] but what you actually want to do is to define a family of colors for each n and (m : Fin n), I guess [Wed Feb 22 14:06:08 2017] so that you can use n and m in the fields of your structure [Wed Feb 22 14:06:10 2017] what is the :t of Coq? [Wed Feb 22 14:06:27 2017] Check? [Wed Feb 22 14:06:48 2017] As in [Check (1+1)] [Wed Feb 22 14:06:59 2017] colour [Wed Feb 22 14:06:59 2017] : ∀ n : nat, t n → Set [Wed Feb 22 14:07:19 2017] see? so they'd be the same, other than that isn't the syntax they prescribe [Wed Feb 22 14:07:24 2017] which is fine, it is just inconsistent [Wed Feb 22 14:07:40 2017] What is the full definition of colour tho? [Wed Feb 22 14:07:51 2017] Structure colour (n : nat) (m : Fin.t n) : Set := { [Wed Feb 22 14:07:51 2017] }. [Wed Feb 22 14:08:01 2017] yeah, it should be equivalent [Wed Feb 22 14:08:10 2017] Probably an artefact of the old times [Wed Feb 22 14:08:20 2017] s/old times/past/ [Wed Feb 22 14:08:39 2017] every project has it [Wed Feb 22 14:09:05 2017] so two things… how do I get "t" out of scope? is there a way to do qualified imports? import aliases? [Wed Feb 22 14:09:29 2017] I am not seeing anything in the docs for Require Import [Wed Feb 22 14:09:31 2017] ohh.. that is a touchy subject for me [Wed Feb 22 14:09:46 2017] there is no qualified import. in general module system in coq sucks [Wed Feb 22 14:10:12 2017] uh, hm [Wed Feb 22 14:10:47 2017] so we're a bit above C's #include but not so much [Wed Feb 22 14:10:57 2017] Maybe you can put your whole definition in the module and import Fin in that module only. Then, when you close the module, t should be out of scope [Wed Feb 22 14:11:24 2017] hehe that might be an apt comparison erisco [Wed Feb 22 14:15:53 2017] at least there is the option of incrementally qualifying the name, even though you cannot take the unqualified name out of scope [Wed Feb 22 14:16:20 2017] I worry about some accidental typos in the future [Wed Feb 22 14:16:28 2017] especially with things like "t" being in scope [Wed Feb 22 14:21:04 2017] "t" has never been a problem for me [Wed Feb 22 14:36:02 2017] I do not understand the type of get_colour here http://lpaste.net/352886 [Wed Feb 22 14:36:24 2017] or actually not that [Wed Feb 22 14:36:32 2017] just, what is the constructor of colour called? [Wed Feb 22 14:37:23 2017] there is "colour" which is the type constructor [Wed Feb 22 14:37:30 2017] and "get_colour" which is the projector [Wed Feb 22 14:40:31 2017] ah ha, Build_colour [Wed Feb 22 14:44:40 2017] I read the docs 5 times and missed the one sentence that said this every time :P [Wed Feb 22 15:46:51 2017] Require Import Coq.MSets.MSets. MSets.t is not in scope [Wed Feb 22 15:47:08 2017] then I try Require Import Coq.MSets.MSetAVL. and MSetAVL.t is not in scope [Wed Feb 22 15:47:20 2017] docs mention "t" but clicking on it doesn't take me to where it is defined [Wed Feb 22 15:47:20 2017] it's a module functor [Wed Feb 22 15:47:40 2017] you need to instantiate it with the module it requires [Wed Feb 22 15:47:57 2017] it wants to know something about the key type [Wed Feb 22 16:16:03 2017] okay, um, hm… so say I want an MSetList of Fin.t n [Wed Feb 22 16:16:31 2017] first, it seems like there is some interface to sets I am supposed to use? but I don't quite get how to [Wed Feb 22 16:17:14 2017] I can see Module XSet = Coq.MSets.MSetList Y where Y is the implemented of OrderedType for X [Wed Feb 22 16:23:02 2017] yes [Wed Feb 22 16:24:48 2017] but what is MSetInterface about? [Wed Feb 22 16:26:09 2017] if you write code in a module functor against MSetInterface, it will work for any MSet [Wed Feb 22 16:26:19 2017] so it's for library writers, not users [Wed Feb 22 16:26:28 2017] or anyone who wants to generalize their implementation [Wed Feb 22 16:29:59 2017] am I right that there is no OrderedType implementation here? https://coq.inria.fr/distrib/current/stdlib/Coq.Vectors.Fin.html [Wed Feb 22 16:30:42 2017] what did you want to be ordered? [Wed Feb 22 16:30:52 2017] Fin n [Wed Feb 22 16:30:52 2017] Fin.t? [Wed Feb 22 16:30:55 2017] yes [Wed Feb 22 16:31:13 2017] i don't think you can use Fin n as a key for an MSet [Wed Feb 22 16:31:21 2017] but why? :s [Wed Feb 22 16:31:25 2017] unless you package it in an existential [Wed Feb 22 16:31:28 2017] { n & Fin n } [Wed Feb 22 16:31:34 2017] otherwise, the types of the keys vary [Wed Feb 22 16:31:48 2017] or, if you fix n [Wed Feb 22 16:32:00 2017] for some n, MSet (Fin n) [Wed Feb 22 16:32:10 2017] so I don't know which your trying to use [Wed Feb 22 16:32:11 2017] a particular set will only have Fin n for some n [Wed Feb 22 16:32:14 2017] ah, ok [Wed Feb 22 16:32:21 2017] that should be easy to define an OrderedType for [Wed Feb 22 16:32:58 2017] here's all you need to write: [Wed Feb 22 16:32:58 2017] https://gist.github.com/b2f3f60ab30602cd41c4e95f9123acfb [Wed Feb 22 16:33:05 2017] of course, change all the definitions [Wed Feb 22 16:33:31 2017] uh, what? :s [Wed Feb 22 16:33:41 2017] defining an OrderedType for Fin n [Wed Feb 22 16:33:53 2017] it just says "morked I" [Wed Feb 22 16:33:59 2017] hmm [Wed Feb 22 16:34:16 2017] https://gist.github.com/df9650284e55044a5fe51fcc268e1e67 [Wed Feb 22 16:35:19 2017] thanks for the example [Wed Feb 22 20:03:13 2017] too bad there isn't newtype deriving :P [Wed Feb 22 20:04:06 2017] hahaha [Wed Feb 22 20:04:15 2017] if you think that's missing, just you wait [Wed Feb 22 20:04:29 2017] not sure which way to take that [Wed Feb 22 20:04:40 2017] programming in Coq is no easy thing, if you're used to Haskell [Wed Feb 22 20:04:46 2017] there's a TON of convenience features missing [Wed Feb 22 20:04:51 2017] stuff you may take for granted by now [Wed Feb 22 20:05:16 2017] usually you choose Coq because you need it, and because it's such an excellent tool for what it does well -- which is _not_ to act as a replacement for languages like Haskell [Wed Feb 22 20:05:18 2017] I may be persuaded to return to Idris but right now I don't know [Wed Feb 22 20:05:45 2017] well I cannot prove things in Haskell all that well, yet [Wed Feb 22 20:05:54 2017] have you actually tried Agda yet? [Wed Feb 22 20:06:01 2017] no [Wed Feb 22 20:06:11 2017] in some ways it's much more mature than Idris [Wed Feb 22 20:06:27 2017] I was quickly turned off because everything I tried to find on it seemed to be based on deprecated versions [Wed Feb 22 20:06:35 2017] so it seemed like a complete nightmare of an ecosystem [Wed Feb 22 20:06:46 2017] no worse than Coq [Wed Feb 22 20:07:14 2017] also, it's better at dependently-typed programming [Wed Feb 22 20:08:02 2017] how much is really missing? [Wed Feb 22 20:08:21 2017] the big thing: dependently-typed pattern matching [Wed Feb 22 20:08:23 2017] the tactics are a plus [Wed Feb 22 20:08:48 2017] the "with" stuff? [Wed Feb 22 20:09:00 2017] yeah [Wed Feb 22 20:09:13 2017] that was so insanely confusing I don't see how I can go back to that [Wed Feb 22 20:09:14 2017] when you match in Coq, you don't gain inferred equalities in the environment [Wed Feb 22 20:09:24 2017] if I had someone who could explain it to me in person, at length, then maybe [Wed Feb 22 20:09:33 2017] but to get there on my own I need to work with DT a lot more [Wed Feb 22 20:09:34 2017] you have provide those equalities for yourself manually, using something called the cargo pattern [Wed Feb 22 20:10:03 2017] well, whatever pain you experienced with 'with', doing dependently-typed programming in Coq is going to hurt more [Wed Feb 22 20:10:17 2017] really the only way to do it sanely is using tactics, but many times the resulting code kind of sucks [Wed Feb 22 20:10:24 2017] I couldn't even make sense of the scoping rules [Wed Feb 22 20:10:35 2017] though I was informed in the case of Idris that I encountered at least one bug [Wed Feb 22 20:10:56 2017] I hope Idris does well, it presents a nice possible future [Wed Feb 22 20:11:45 2017] right, well, by the time I figure out the redundant work in Coq I will better understand what these other languages are doing [Wed Feb 22 20:11:58 2017] well, maybe [Wed Feb 22 20:11:59 2017] I can use simplicity right now [Wed Feb 22 20:12:10 2017] the dot patterns in Agda are very cool [Wed Feb 22 20:12:17 2017] really nothing equivalent in Coq [Wed Feb 22 20:16:29 2017] dinner time now, good luck [Thu Feb 23 13:29:22 2017] Hi everyone, I have 27 subgoals that I think can all be solved with a "- intros. apply H.". I forget how to ask Coq to try to do that for each goal without typing it in 27 times. Does anyone know what I'm talking about? [Thu Feb 23 13:32:04 2017] you have to chain your tactic producing the 27 subgoals with "; intros; apply H." [Thu Feb 23 13:32:13 2017] ";" means "apply the rest to all the subgoals" [Thu Feb 23 13:34:07 2017] you can also use: all:(intros; apply H) after the fact [Thu Feb 23 13:34:18 2017] but it's more typical to say ;intros;apply H. [Thu Feb 23 13:36:51 2017] artart78: johnw: Thanks! worked like a charm :) [Thu Feb 23 13:38:46 2017] and often if it's as easy as that, you can just use "; auto" [Thu Feb 23 13:38:53 2017] which has the benefit of continuing to work, even if H changes its name [Thu Feb 23 13:42:26 2017] johnw: I'm not quite that lucky today, it seems :) [Thu Feb 23 13:50:02 2017] here's the scale of "figure it out for me!": assumption, trivial, auto, intuition, eauto, firstorder, crush (if you happen to have Adam's crash tactic available) [Thu Feb 23 13:50:55 2017] ADAM CRUSH [Thu Feb 23 13:51:10 2017] exactly [Thu Feb 23 13:51:21 2017] crush is nice in the way that it interacts with hint databases [Thu Feb 23 13:52:29 2017] adam chlipala had a job in a computer science department. then one day, there was an accident, and he was bombarded with beta[-reduction] rays [Thu Feb 23 13:53:08 2017] now, when he becomes - well, not enraged, but fed the fuck up with irritating repetition - he transforms [Thu Feb 23 13:55:13 2017] first he transforms, then the goal transforms [Thu Feb 23 13:55:27 2017] the harder it gets, the stronger he becomes. Hope that he never is asked to prove False. [Thu Feb 23 13:55:38 2017] lmbo [Thu Feb 23 13:58:06 2017] you either die a hero, or live long enough to write ltac [Thu Feb 23 14:00:51 2017] anyone who willingly writes ltac is a hero imo [Thu Feb 23 14:00:56 2017] by saving others from having to write it [Thu Feb 23 14:03:52 2017] Would anyone be willing look at this code and advise me on the approach i'm taking so far? I'm really just trying to relearn the basics of Coq after being out of it a while, and i'm stuck on proving if a simple relation is transitive :(. https://gist.github.com/jerry-james/5d912c639bf70f65a76730ae80279d43 [Thu Feb 23 14:05:08 2017] many of these definitions are already in the stdlib [Thu Feb 23 14:05:45 2017] oh good! [Thu Feb 23 14:05:47 2017] also, *is* it transitive? [Thu Feb 23 14:06:10 2017] hmm... [Thu Feb 23 14:06:47 2017] in my inductive type `r`, I intent the `r_t` constructor to make it transitive.. [Thu Feb 23 14:06:59 2017] but transitivity must take into account every constructor [Thu Feb 23 14:07:14 2017] because it's the type that has to be transitive, not just one class of values of that type [Thu Feb 23 14:07:53 2017] the subtype { x : r | match x with r_t => True | _ => False end } is most certainly transitive [Thu Feb 23 14:09:59 2017] hmm.. i think i understand what you mean, but i'm not sure how to validate my understanding. i'm not sure what to change to force the relation `r` to be transitive [Thu Feb 23 14:11:13 2017] for example, given two values (r_a : r B B) and (r_b :: r B B), what value do they give rise to? [Thu Feb 23 14:12:15 2017] hmm.. Some x : B [Thu Feb 23 14:12:24 2017] (should have said r_a : r x y and r_b : r y z [Thu Feb 23 14:12:29 2017] r_? : r x z [Thu Feb 23 14:12:44 2017] oh, I see [Thu Feb 23 14:12:47 2017] that's what you inted r_t to do [Thu Feb 23 14:13:27 2017] then just do this: [Thu Feb 23 14:13:30 2017] yeah, its kind of a mickey mouse file, i don't think i even need to to the theorems because that inductive `r` definition is basically trying to say "this is the way it is" [Thu Feb 23 14:13:30 2017] Proof. unfold transitive; intros; eapply r_t; eauto. Qed. [Thu Feb 23 14:13:43 2017] r_t is your reifed transitivity property, for all constructions [Thu Feb 23 14:13:54 2017] the same trick will work for r_s and r_r [Thu Feb 23 14:14:14 2017] Wow! [Thu Feb 23 14:14:28 2017] I need to read up on this magical `eapply` and `eauto` [Thu Feb 23 14:14:44 2017] eapply says "replace missing terms with evars (holes, essentially)" [Thu Feb 23 14:14:58 2017] eauto says "do what auto does, but try to invent/find terms to fill the holes" [Thu Feb 23 14:15:14 2017] aaah amazing! [Thu Feb 23 14:15:32 2017] now, if all you want to do is to reify the equivalence relation [Thu Feb 23 14:15:38 2017] you could do that with a separate, helper structure [Thu Feb 23 14:15:48 2017] called "requiv", parameterized over the relation [Thu Feb 23 14:16:11 2017] Inductive requiv {A : Type} (r : relation A) := r_r | r_s | r_t. [Thu Feb 23 14:16:30 2017] now "requiv r" is trivially an equivalence, because what you've done is define the "free equivalence" [Thu Feb 23 14:16:48 2017] the problem will come when you try to interpret values of type "requiv r" [Thu Feb 23 14:16:48 2017] ah that is the equivalence closure i need [Thu Feb 23 14:17:00 2017] because then you'll need to establish a meaning for r/s/t for r [Thu Feb 23 14:17:35 2017] is that a result of some poor choice i've already made? [Thu Feb 23 14:18:06 2017] no, you've just "deferred the laws" in a sense [Thu Feb 23 14:18:20 2017] i mean -- haven't i already defined a meaning for r/s/t over r? [Thu Feb 23 14:18:33 2017] you've simply encoded them [Thu Feb 23 14:18:46 2017] your evaluate, when it reaches an r_t value, will need to know what to do [Thu Feb 23 14:18:55 2017] evaluator* [Thu Feb 23 14:19:04 2017] ooh gotcha -- the semantics aren't present here, no [Thu Feb 23 14:19:07 2017] right [Thu Feb 23 14:19:12 2017] which is the whole beauty of free constructions [Thu Feb 23 14:19:27 2017] free constructions? i'm not familiar with that term [Thu Feb 23 14:19:53 2017] when you reify an algebra (like you're doing here for the equivalence algebra), you're create the free construction of that algebra [Thu Feb 23 14:20:07 2017] is that the constructors in r? [Thu Feb 23 14:20:11 2017] often, free construction give rise to recognizable data structures; the free monoid is what computer scientist call a "list" [Thu Feb 23 14:20:16 2017] yes, r_r/r_s/r_t [Thu Feb 23 14:21:05 2017] I haven't encountered the free equivalence before, but I think sure it represents a graph [Thu Feb 23 14:21:19 2017] ah okay -- so when i need to interpret `requiv r` i'll need some fixpoint function or something to do something with it? did i understand? [Thu Feb 23 14:21:22 2017] since it gives you identity, composition, and inversion [Thu Feb 23 14:21:31 2017] jerryj: yes, exactly [Thu Feb 23 14:21:44 2017] semantics are applied to a free construction by an evaluator, also called a fold [Thu Feb 23 14:22:20 2017] :) [Thu Feb 23 14:22:57 2017] the free equivalence is... let me guess... the equivalence closure over all free constructors? [Thu Feb 23 14:23:13 2017] i'm not that familiar with the term closure (I'm no mathematician) [Thu Feb 23 14:23:24 2017] or maybe i'm out in space now, i haven't heard of the free equivalence before, either [Thu Feb 23 14:23:35 2017] I believe the free equivalence here is basically a free groupoid [Thu Feb 23 14:23:39 2017] johnw: you aren't a mathematician!? i disagree... [Thu Feb 23 14:24:05 2017] I come at all of this from a CS perspective; if I can't code it, I don't really understand it [Thu Feb 23 14:24:50 2017] oh i learned one sense of the word "closure" from "semantics engineering with plt redex", i think it means the r/s/t that closes the group with an operator, in this case r [Thu Feb 23 14:25:13 2017] ah, ok [Thu Feb 23 14:25:15 2017] aaah gotcha -- i am the same way, but my math isn't where it needs to be yet. [Thu Feb 23 14:25:32 2017] for me, it just means a lambda that captures variables from the lexical scope, but I'd like to understand the math definition [Thu Feb 23 14:26:35 2017] johnw: thank you so much for your help -- i have to run, even though i'd like to stay longer and learn more :) [Thu Feb 23 14:26:45 2017] have a good day/night/evening! [Thu Feb 23 14:26:52 2017] you too, good luck! [Thu Feb 23 14:28:56 2017] https://ncatlab.org/nlab/show/groupoid mentions free equivalence relations, btw [Fri Feb 24 11:16:02 2017] In the first theorem of http://www.cs.cmu.edu/~rwh/papers/chitt/popl17.pdf, what does the notation bool [\cdot] mean? [Fri Feb 24 11:16:54 2017] Context: If M ∈ bool [·] then either M ⇓ true [Fri Feb 24 13:04:49 2017] johnw: I believe it means that there are no free dimension symbols in M [Fri Feb 24 13:08:55 2017] the [.] notation supposed to represent the empty dimension context. in general, the dimension context is represented by the metavariable \Psi in the rest of that paper [Fri Feb 24 14:18:46 2017] if anyone is interested I have the coq mode for vim mostly working on 8.6: github.com/stelleg/coquille [Fri Feb 24 14:39:07 2017] johnhw... no, not confusing at all :) [Fri Feb 24 16:46:01 2017] I think I remember seeing something along the lines of forall a b, (x:a) (a=b) : b in the standard library [Fri Feb 24 16:46:20 2017] anyone know off the top of their head if that's there and what its called [Fri Feb 24 16:46:37 2017] * continues to wish for coogle [Fri Feb 24 16:47:51 2017] stelleg, eq_rect? [Fri Feb 24 16:49:43 2017] rrika: ah thanks, that should work [Fri Feb 24 16:49:46 2017] eq_rect [Fri Feb 24 16:49:46 2017] : forall (A : Type) (x : A) (P : A -> Type), [Fri Feb 24 16:49:46 2017] P x -> forall y : A, x = y -> P y [Fri Feb 24 16:49:50 2017] where P is the identity [Fri Feb 24 16:49:52 2017] yeah [Fri Feb 24 18:07:52 2017] anyone know if there's anything relating nfuns to Vectors in the standard library? [Fri Feb 24 18:08:04 2017] been doing some of that myself for fun [Fri Feb 24 18:08:20 2017] but if it's there I should probably use it [Fri Feb 24 18:18:24 2017] ho boy [Fri Feb 24 18:18:35 2017] im regrestting trying to use eq_rect [Fri Feb 24 22:51:45 2017] stelleg: loooool [Fri Feb 24 22:52:02 2017] that's the coq user's slogan [Fri Feb 24 22:52:41 2017] HAS PLT GONE TOO FAR???? https://twitter.com/warrendhatton/status/835305173220151296 [Sat Feb 25 10:23:24 2017] Hi, Can I prove (nat = Z -> False) in Coq? [Sat Feb 25 10:46:59 2017] pretty sure you can [Sat Feb 25 10:52:49 2017] inversion doesn't works. Can you explain a bit more please? [Sat Feb 25 10:56:49 2017] http://stackoverflow.com/questions/12224318/how-to-solve-goals-with-invalid-type-equalities-in-coq [Sat Feb 25 10:56:52 2017] check the second answer [Sat Feb 25 10:56:57 2017] the first answer is in my view confusing [Sat Feb 25 10:57:37 2017] turns out it is harder than i thought [Sat Feb 25 11:45:25 2017] Thanks a lot!! I read it and understood. [Sat Feb 25 11:51:31 2017] Again, thanks for your help! I just removed my admit XD [Sat Feb 25 15:54:19 2017] benzrf: there is already a game written in Coq. [Sat Feb 25 15:54:24 2017] It's called Coqoban [Sat Feb 25 15:57:26 2017] does it come with a proof that you'll have fun playing it? [Sat Feb 25 15:57:55 2017] It is just a sokoban clone. [Sat Feb 25 15:58:11 2017] But proofs are involved. [Sat Feb 25 15:58:42 2017] Each level is a conjecture that the level is solvable, and each level you solve results in a proof that the level is solvable. [Sat Feb 25 16:03:34 2017] nice [Sat Feb 25 16:58:33 2017] fun fact: somewhere in the readme to the game roconnor mentioned, the author says he was interested in knowing whether someone has written an automatic solver/proof generator for the levels. As i had read this, i was inclined to give it a try ("just for fun" i thought) ... until i discovered how hard it is to write a good sokoban solver. Then i quickly let go of the idea ... ;D [Sat Feb 25 16:59:07 2017] anyway, good night. [Sat Feb 25 17:50:27 2017] roconnor: jesus [Sun Feb 26 11:54:25 2017] Is there any small yet semi-usable virtual machine with its small step semantics formalized in Coq? If possible a virtual machine that is itself the target of a simple verified functional language compiler? [Sun Feb 26 11:55:05 2017] if someone finds this out i'd like to know too. [Sun Feb 26 14:46:15 2017] anyone here to answer a quick question about Ltac "match goal with"? [Sun Feb 26 14:51:08 2017] Any idea how to make the application of ltac "cow" work in lemma "tail" (it works in lemma horns): http://pastebin.com/rJzr37bn [Sun Feb 26 15:17:03 2017] andrejbauer: as you correctly recognized, it won't unfold X without you telling Ltac to do so. If all you want is delta expansion (i.e. replacing transparent definitions with their bodies) you can stick a 'cbv delta' in somewhere ... [Sun Feb 26 15:18:11 2017] try something like |- ?X -> ?P => match eval cbv delta in X with True => [Sun Feb 26 15:18:29 2017] unfortunately, i have to leave now. So, good luck! ;) bye [Sun Feb 26 15:18:33 2017] Where exactly would I stick it? I don't actually want to cbv delta the goal itself, I just want the reduced goal to be used for matching [Sun Feb 26 15:18:45 2017] ok, I'll try that. [Sun Feb 26 15:18:48 2017] It's ugly. [Sun Feb 26 15:19:12 2017] tnx [Sun Feb 26 19:13:17 2017] I'm trying to compile Coq 8.6 with OCaml 4.04.0, and I'm getting "Error: Unbound module Toploop" on the command "COQMKTOP -o bin/coqtop.byte" from make. Anyone know what's going on? [Mon Feb 27 02:22:14 2017] what is the correct way to encode a theory in Coq? [Mon Feb 27 02:22:28 2017] do I create a typeclass, or is there some notion of "instantiation of a module"? [Mon Feb 27 02:22:32 2017] the stdlib uses both modules and typeclasses [Mon Feb 27 02:22:40 2017] I see [Mon Feb 27 02:22:44 2017] what are the pros and cons? [Mon Feb 27 02:23:08 2017] the fine points can get into a lot of subtleties, not all of which I'm fully cognizant of [Mon Feb 27 02:23:27 2017] personally, I'd try a module first, then move to a typeclass if it's not giving you the flexibility you want [Mon Feb 27 02:23:38 2017] but there are other ways too [Mon Feb 27 02:23:56 2017] canonical structures is another [Mon Feb 27 02:24:56 2017] modules may feel more natural, though, since the names you work with feel like they're at "global scope" [Mon Feb 27 02:25:08 2017] typeclasses need to be passed as implicit arguments (ala Constraints) [Mon Feb 27 02:25:09 2017] I see [Mon Feb 27 02:25:17 2017] and canonical structures I've never fully figured out [Mon Feb 27 02:25:19 2017] can you give me a link on using a module for this? [Mon Feb 27 02:25:26 2017] and, like, modules are parametrised too, right? [Mon Feb 27 02:25:35 2017] you have module types, which are like typeclasses [Mon Feb 27 02:25:36 2017] as in, I can define a theory in a module and instantiate it against multiple things? [Mon Feb 27 02:25:54 2017] you have module functors, which are like parameterized modules [Mon Feb 27 02:25:56 2017] and you have modules [Mon Feb 27 02:26:05 2017] usually your algebraic theory would go into a module type [Mon Feb 27 02:26:13 2017] and your generic code would go into a module functor that depends on that type [Mon Feb 27 02:26:26 2017] and your specific code would go into a module that instantiate the functor and type [Mon Feb 27 02:26:29 2017] I see, like the ML idea? (which I am vaguely familiar with) [Mon Feb 27 02:26:37 2017] I haven't used any of the ML family [Mon Feb 27 02:26:40 2017] OK [Mon Feb 27 02:26:43 2017] Coq modules are dumber though, I've heard [Mon Feb 27 02:26:50 2017] hm, so, is there a small example of this entire thing? [Mon Feb 27 02:26:54 2017] module + functor + instantiation [Mon Feb 27 02:27:03 2017] I was leaning towards typeclasses since I understand them better :) [Mon Feb 27 02:27:17 2017] https://coq.inria.fr/cocorico/ModuleSystemTutorial [Mon Feb 27 02:27:29 2017] thanks! [Mon Feb 27 02:27:36 2017] you can use them too, but they don't operate identically to Haskell [Mon Feb 27 02:27:54 2017] you'll run into weird cases of how instances are resolved, if you expect them to work out just like Haskell [Mon Feb 27 02:28:07 2017] I see [Mon Feb 27 02:28:11 2017] but, they can often be used in place of modules [Mon Feb 27 02:28:23 2017] so, just try things out, see what fits bets [Mon Feb 27 02:28:36 2017] cool, thanks :) [Mon Feb 27 02:28:39 2017] much appreciated [Mon Feb 27 02:29:19 2017] johnw: what is a "Parameter"? [Mon Feb 27 02:29:32 2017] oh, just the parameters of the module [Mon Feb 27 02:29:32 2017] OK [Mon Feb 27 02:32:57 2017] Infix "≤" := le : order_scope. what exactly is order_scope? [Mon Feb 27 02:33:06 2017] I notice that they do an Open Scope order_scope. [Mon Feb 27 02:33:08 2017] a syntactic scope [Mon Feb 27 02:34:04 2017] which means..? [Mon Feb 27 02:34:13 2017] how much have you used Coq? [Mon Feb 27 02:34:20 2017] nope :) [Mon Feb 27 02:34:25 2017] I have read through software foundations [Mon Feb 27 02:34:31 2017] not all of it [Mon Feb 27 02:34:34 2017] till ~chapter 5 [Mon Feb 27 02:34:41 2017] I'm just thinking we might have a long stream of questions here :) [Mon Feb 27 02:34:43 2017] xD [Mon Feb 27 02:34:44 2017] ah [Mon Feb 27 02:34:52 2017] sorry about that :) [Mon Feb 27 02:34:58 2017] I would be cool with going and reading about it [Mon Feb 27 02:35:07 2017] that's ok, but maybe there's a better resource than IRC right before I head to bed [Mon Feb 27 02:35:33 2017] heh, fair point [Mon Feb 27 02:35:45 2017] but I couldn't really find one [Mon Feb 27 02:35:58 2017] scopes are pretty well documented in the Coq reference manual [Mon Feb 27 02:36:04 2017] I wouldn't worry about them [Mon Feb 27 02:36:11 2017] just do it all at module scope for now [Mon Feb 27 02:36:21 2017] OK [Mon Feb 27 02:36:26 2017] so I don't bother with the scope stuff? [Mon Feb 27 02:36:34 2017] nope, ignore it [Mon Feb 27 02:36:38 2017] OK, thanks! [Mon Feb 27 02:36:56 2017] my problem with the reference manual is that they often document using type theory. Which is nice if you're a type theorist.. [Mon Feb 27 02:37:14 2017] https://coq.inria.fr/refman/Reference-Manual014.html [Mon Feb 27 02:44:17 2017] g'night [Mon Feb 27 02:45:55 2017] night :) [Mon Feb 27 03:01:47 2017] how do I instantiate reflexitivity of =? [Mon Feb 27 03:01:49 2017] given a : A [Mon Feb 27 03:01:52 2017] I want a term (a = a) [Mon Feb 27 03:02:31 2017] IIRC, `refl a' does the job [Mon Feb 27 03:02:35 2017] "eq_refl a" is such a term [Mon Feb 27 03:02:47 2017] thanks [Mon Feb 27 03:02:49 2017] :) [Mon Feb 27 03:03:04 2017] oh my memory is fading away :-( [Mon Feb 27 04:09:12 2017] proving in coq feels so strange [Mon Feb 27 04:09:14 2017] usually in math [Mon Feb 27 04:09:23 2017] I start from my assumptions and mutate them to reach the goal [Mon Feb 27 04:09:24 2017] i.e [Mon Feb 27 04:09:26 2017] if I have a -> b [Mon Feb 27 04:09:32 2017] I mutate a to reach b [Mon Feb 27 04:09:41 2017] in coq, I seem to be mutating b to unify with a [Mon Feb 27 04:10:10 2017] bollu pasted “coq-group-encoding” at http://lpaste.net/353019 [Mon Feb 27 04:10:37 2017] if someone could show me how to write this more idiomatically, it would help a lot :) It's an encoding of some simple group theory theorems in Coq [Mon Feb 27 04:37:46 2017] bollu: you can actually operate in both directions. you can apply things to your goal and you can apply them to assumptions [Mon Feb 27 04:38:08 2017] cocreature: I tried using "rewrite" on my assumptions, but it fails to unify correctly [Mon Feb 27 04:38:56 2017] bollu: rewrite is only for rewriting equalities, if you have something like "a -> b" and an assumption "a" you want to use "apply" [Mon Feb 27 04:39:02 2017] ah [Mon Feb 27 04:39:59 2017] cocreature: can you show me how to do this? g * h = g * k, then g^-1 * g * h = g^-1 * g * k => h = k [Mon Feb 27 04:40:06 2017] cocreature: I want the "proof flow" to be in that direction [Mon Feb 27 04:42:51 2017] sry I’m busy atm [Mon Feb 27 04:42:58 2017] ah, OK [Mon Feb 27 04:43:10 2017] cocreature: can you tell me where there are some examples of apply being used? other than the guide, that is [Mon Feb 27 04:43:28 2017] I’m pretty sure "apply" is used all over the place in sf [Mon Feb 27 04:45:36 2017] OK [Mon Feb 27 04:45:38 2017] I shall check [Mon Feb 27 04:45:40 2017] thanks [Mon Feb 27 05:37:25 2017] what is the difference between apply and apply_with [Mon Feb 27 05:39:23 2017] as in [Mon Feb 27 05:39:41 2017] what is the difference between apply (f x y z) versus apply f with x y z [Mon Feb 27 12:35:37 2017] does anyone know if someone has written a script to compile the Coq documentation for dash? [Mon Feb 27 13:06:47 2017] what's dash? [Mon Feb 27 13:08:37 2017] a documentation browser on macOS [Mon Feb 27 13:08:43 2017] Zeal is the free Linux clone [Tue Feb 28 03:08:09 2017] if I have something in the context with an exists, can I i eliminate the exists and get a useful instance? [Tue Feb 28 03:08:33 2017] you can "destruct" the something [Tue Feb 28 03:08:43 2017] (only if your goal is in Prop, not in Type) [Tue Feb 28 03:08:57 2017] it is not a goal, it's in the context [Tue Feb 28 03:09:55 2017] You can still destruct it [Tue Feb 28 03:10:02 2017] I still meant everything I said x) [Tue Feb 28 03:10:22 2017] http://lpaste.net/6834486449153245184 [Tue Feb 28 03:10:32 2017] Cypi: hm, that is interesting :) [Tue Feb 28 03:11:04 2017] yes, it works, thanks a ton! [Tue Feb 28 03:11:15 2017] also, is there some sort of quick reference for things like this? [Tue Feb 28 03:11:23 2017] I do not think the Coq manual counts ;) [Tue Feb 28 03:12:17 2017] the ttorial perhaps [Tue Feb 28 03:12:51 2017] I think destructing stuff comes with some amount of experience. "destruct" is one of the basic tactics that you can use all the time. In this case "exists ..." is an inductive type like any other, so you can destruct it. So, if you wanted a "reference", I would say any course about Coq, and then you'll never forget it :) [Tue Feb 28 03:12:55 2017] https://coq.inria.fr/tutorial-nahas [Tue Feb 28 03:14:28 2017] (Also, your goal will not be provable without some classical stuff. The -> direction is provable, but not the <- direction which is classical.) [Tue Feb 28 03:14:48 2017] (Well, unless you have other assumptions about R, F and W that I do not see of course) [Sat Mar 18 22:49:52 2017] Why can't I use the negation of a relation in its own definition? (example here https://gist.github.com/pedrotst/14296c346957f823ca2bced84bb90953) [Sat Mar 18 23:20:38 2017] a riff on a facebook meme https://i.imgur.com/atfWJua.png [Sat Mar 18 23:21:07 2017] pedroabreu: because it is non strictly positive [Sat Mar 18 23:21:13 2017] [~Foo] means [Foo -> False] [Sat Mar 18 23:21:16 2017] so it's in a domain position [Sat Mar 18 23:25:22 2017] well, the error message says non strictly positive, but I have no idea what that means :( [Sat Mar 18 23:25:34 2017] what do you mean by 'its in a domain position'? [Sat Mar 18 23:34:08 2017] pedroabreu: basically there are restrictions on where a type can appear in its own definition [Sat Mar 18 23:34:19 2017] in particular, it can't be the domain of a function which is an argument to a constructor [Sat Mar 18 23:34:49 2017] i think it can be the domain of the domain though, i.e. ((Type -> Something) -> Otherthing) as a constructor arg is OK [Sat Mar 18 23:35:17 2017] er never mind that's not ok [Sat Mar 18 23:35:39 2017] i guess it cant appear anywhere in a domain...? not clear on the details myself, sorry [Sat Mar 18 23:35:39 2017] hmm, got it [Sat Mar 18 23:35:42 2017] :) [Sat Mar 18 23:36:02 2017] allowing unrestricted reference here allows paradoxes i believe [Sat Mar 18 23:36:09 2017] for example, consider [Sat Mar 18 23:36:19 2017] Inductive foo := bar : ~foo -> foo. [Sat Mar 18 23:36:40 2017] i don't know that this is a problem in and of itself, but it definitely blows up if we have LEM [Sat Mar 18 23:38:18 2017] yeah, but axioms are always risky to be assumed [Sat Mar 18 23:38:32 2017] oh, I guess you mean the LEM for foo only [Sat Mar 18 23:38:34 2017] ok [Sat Mar 18 23:41:28 2017] well thank you :) [Mon Mar 20 09:56:37 2017] Hello. Are there any ways to calculate Coq's term size in some units? [Mon Mar 20 10:00:18 2017] In Coq directly? Not really, since it doesn't really make sense from a computational viewpoint [Mon Mar 20 10:00:40 2017] In OCaml, sure. In Ltac, probably. [Mon Mar 20 10:06:31 2017] Not in Gallina directly, but maybe using Coqs Vernacular. Ready-to-use ltac will do. [Tue Mar 21 21:55:47 2017] I have a question about the use of the field tactic [Tue Mar 21 21:56:26 2017] how might I pass it a list of hypotheses that I have constructed automatically? I am not sure how to cope with `field [H1 H2 H3 ...]` [Wed Mar 22 04:33:36 2017] Hi, I have "a := b" in my premise, and "a" in my goal. I want to replace "a" into "b" in my goal. I can use "unfold a" to do this. Can I do this without explicitly mentioning "a"? [Wed Mar 22 04:34:17 2017] I tried "context[?x := ?y]" in ltac match, but it gives Syntax error. [Wed Mar 22 12:13:31 2017] I'm trying to write the strongly specified assoc function forall (x:A) (l: assoc_list), {y | In (x,y) l} + {forall (y:B), ~In (x,y) l}. using tactics. [Wed Mar 22 12:13:40 2017] It's very easy to get the correct answer using induction on l. [Wed Mar 22 12:14:08 2017] However, the structure of the term itself does the recursive call prior to checking if the key is in the head of the list. [Wed Mar 22 12:14:40 2017] Trying to change the order of this has proved a little confusing for me in using the tactics language. Obviously I can just use refine and fix and get what I want. [Wed Mar 22 12:15:27 2017] But I wonder if there is a technique that could help me here. I imagine it has something to do with case_eq to remember the decomposition of the list, and then doing induction later and eliminating the nil case, but I keep getting an inductive hypothesis that is insufficiently abstract. [Fri Mar 24 10:23:12 2017] I have a goal with an equality [] = xs ++ ys, I need to get xs = [] and ys = [] from that, which is an inversion lemma when the order of the arguments of = are reversed (i.e. app_eq_nil). I even proved that x = y-> y = x, and tried to rewrite an assumption in that way, but according to Coq it wouldn't do anything, which is true in a certain sense. The problem, however remains. [Fri Mar 24 10:25:11 2017] "symmetry in H; apply app_eq_nil in H" [Fri Mar 24 10:26:01 2017] "x = y -> y = x" already exists, it's called "eq_sym", and symmetry will basically apply this in your hypothesis [Fri Mar 24 10:26:01 2017] Cypi: thanks. [Fri Mar 24 10:29:06 2017] Cypi: how do I convert H: a /\ b to H1:a, H:b? [Fri Mar 24 10:29:22 2017] "destruct H" [Fri Mar 24 10:31:40 2017] I also seem to get expressions like 0 + x a lot in my goals. If I want to get rid of those, the only way is basically to use Ltac like CPDT describes? [Fri Mar 24 10:32:47 2017] did you try with ring? [Fri Mar 24 10:35:03 2017] mortberg: Error: cannot find relation [Fri Mar 24 10:35:31 2017] I just want to rewrite x + 0 to x. [Fri Mar 24 10:35:42 2017] doesn't simpl do that? [Fri Mar 24 10:35:50 2017] oh, not x + 0 [Fri Mar 24 10:35:57 2017] but 0 + x as you said before [Fri Mar 24 10:36:28 2017] I tried rewrite plus_0_r. [Fri Mar 24 10:36:53 2017] cic: no. [Fri Mar 24 10:37:44 2017] Already got this to work. [Fri Mar 24 10:49:21 2017] I now have x = a :: xs -> . The premise is equivalent to false, but how do I explain that to Coq? It's some kind of discrimination, but what's a good way to only focus on the premise? [Fri Mar 24 10:49:39 2017] I meant xs = a :: xs [Fri Mar 24 10:51:52 2017] You can prove by induction on xs [Fri Mar 24 10:52:02 2017] (I'm surprised there isn't a lemma in the stdlib for this, maybe I missed it) [Fri Mar 24 10:52:25 2017] in any case: "intros H; exfalse; induction xs; inversion H; auto" or something along those lines should be enough [Fri Mar 24 10:52:27 2017] Cypi: can that be done without introducing an extra lemma? [Fri Mar 24 10:52:36 2017] sure [Fri Mar 24 10:52:54 2017] exfalso*, not exfalse [Fri Mar 24 10:55:30 2017] Cypi: exfalso is for the whole goal, I only have H: xs = a :: xs -> . [Fri Mar 24 10:55:53 2017] Oh. I'm sorry, I thought this was your goal, not a hypothesis [Fri Mar 24 10:55:56 2017] Cypi: so, the idea is that I want to conclude . [Fri Mar 24 10:56:08 2017] If that's a hypothesis, then you can't do anything with it [Fri Mar 24 10:56:09 2017] Since I believe that is close to the real goal. [Fri Mar 24 10:56:30 2017] it's the same as having "False -> ", which is useless [Fri Mar 24 10:56:40 2017] To use it, you'd have to prove False, which would solve the goal anyway [Fri Mar 24 10:56:53 2017] Cypi: ok [Sat Mar 25 10:05:23 2017] I tried to do https://homes.cs.washington.edu/~jrw12/InductionExercises.html, but I find even the first exercise hard. A natural way to think about the problem to me seems to be the observation that acc in ith iteration = sum_j=0^i xs[j]. This should imply that after n iterations, acc contains sum xs. However, a solution which I found somewhere online seems to require an inductive hypothesis that seems to come from nowhere (i.e., requires " [Sat Mar 25 10:06:35 2017] Now, in the code provided there is no variable "i" in scope, so it's already a slightly different problem, but I suppose there are ways to define the function such that it does and extract a version which doesn't mention "i". [Sat Mar 25 10:10:01 2017] The proposed solution reimplements 'sum' with an accumulator in one of the most unnatural ways possible (not the usual tail recusive accumulator). It seems completely artificially defined only to move the proof further. [Sat Mar 25 10:11:16 2017] It's quite "nice" that the author of this solution managed to solve the problem without any concept of "iteration", but it doesn't seem that this approach can possibly scale to any larger problems. [Sat Mar 25 10:26:15 2017] Or, perhaps more formally: forall k l acc, sum_tail' l acc = sum_tail' (drop k l) (sum (take k l)). seems like a useful lemma to prove. [Sat Mar 25 10:26:54 2017] This is, however completely not what the author of the exercise intended, AFAIK. [Sat Mar 25 15:39:37 2017] is there a way to define an inductive and simultaneously a definition over the type defined? [Sat Mar 25 15:39:40 2017] can't find the syntaax [Sat Mar 25 16:09:48 2017] Ptival: do you mean induction-recursion? in coq, no, I don't think so. agda has this, but I'm having trouble digging up documentation on it. [Sat Mar 25 16:23:51 2017] arjen really needs to get a bouncer. [Sat Mar 25 19:45:51 2017] jrw: no no, something much simpler [Sat Mar 25 19:46:14 2017] Inductive foo := Constructor : foolist -> foo with foolist := list foo. [Sat Mar 25 19:46:36 2017] ah, like SML's withtype. [Sat Mar 25 19:46:49 2017] can you use a notation for this? [Sat Mar 25 19:46:52 2017] harder question: is there a nice way of defining an indexed family such that indices easily specify allowed/disallowed constructors? [Sat Mar 25 19:47:07 2017] jrw: yeah a notation would work, I was trying to have a definition though [Sat Mar 25 19:48:04 2017] the only way I know how to do that is to inline the definition and then define it separately. this is not exactly the same, since the inductive contains the inlined definition, not the folded version. [Sat Mar 25 19:48:05 2017] http://paste.awesom.eu/74qp I tried this but it's very unwieldy [Sat Mar 25 19:48:57 2017] what's the intended meaning of the indices there? [Sat Mar 25 19:49:00 2017] (the idea being, type "rv" should be all constructors, "rvx" only the first four, "rx" only the first two) [Sat Mar 25 19:49:27 2017] they only serve to mark what constructors are allowed for particular types [Sat Mar 25 19:49:34 2017] hmm [Sat Mar 25 19:49:55 2017] each index describes a type-to-be [Sat Mar 25 19:50:16 2017] a quantified bool indicates the constructor is allowed [Sat Mar 25 19:50:21 2017] a "false" indicates it's disallowed [Sat Mar 25 19:50:33 2017] then types are defined by putting a "true" in their slot [Sat Mar 25 19:50:39 2017] it's hacky and impractical [Sat Mar 25 19:50:43 2017] would it be cleaner to define a separate "tag" type to use as the index? [Sat Mar 25 19:50:49 2017] or is that different somehow [Sat Mar 25 19:53:11 2017] that would be nicer-looking but idk about usability [Sat Mar 25 19:58:51 2017] I'm not sure how to express the overlaps [Sat Mar 25 19:59:41 2017] I want : T1 = {C1, C2, C3, C4, C5}, T2 = {C1, C2, C3, C4}, T3 = {C1, C2}, T4 = {C1} [Sat Mar 25 20:00:03 2017] (Ts are types, Cs are their allowed constructors) [Sat Mar 25 20:01:11 2017] here I guess it's easy because they are strictly ordered [Sat Mar 25 20:03:06 2017] so I could do the "Fin" trick to restrict constructors [Sun Mar 26 02:13:04 2017] Ptival: I stumbled across this francois pottier paper today that uses a similar trick, but with GADTs, to restrict the types: http://gallium.inria.fr/~fpottier/publis/fpottier-regis-gianas-typed-lr.pdf (see section 7) [Sun Mar 26 11:58:22 2017] When defining an inductive family "Foo", I automatically get a bunch of functions, such as Foo_ind and Foo_rect. Is there a specification of what exactly happens when you define an inductive family? Thanks [Sun Mar 26 20:12:03 2017] vorgang: what level of specification are you looking for? what coq does in particular, or the general idea of inductive families? [Sun Mar 26 23:12:52 2017] jrw: anything, really, but coq-specific would be nice [Mon Mar 27 06:18:49 2017] Good day! Please remind me by which means we replace propositions of the form: A /\ True -> B with a simplier ones A -> B ? [Mon Mar 27 06:24:04 2017] (Without proving an auxilary lemma) [Mon Mar 27 06:28:25 2017] I don't think I know anything simpler that proving it with assert (or providing directly a proof-term, but that's not really simpler) [Mon Mar 27 06:28:39 2017] do you mean replacing _all_ these propositions? Just one? In the context of an interactive proof? [Mon Mar 27 06:29:54 2017] Replace all such (obvious) propositions with simplier ones in call hypothesis in a context. [Mon Mar 27 06:30:05 2017] *in all hyp [Mon Mar 27 06:30:57 2017] I think Coq users would like to have some "rewrite" for this kind of props. [Mon Mar 27 06:31:02 2017] or "simpl" [Mon Mar 27 06:32:10 2017] Sorry, I don't know of an easy vanilla way of doing it (apart from a few lines of Ltac) [Mon Mar 27 06:32:26 2017] you can destruct the hypothesis. [Mon Mar 27 06:32:32 2017] and clear the true term. [Mon Mar 27 06:32:40 2017] Also, it might prove a little bit more complicated if some other hypotheses depend on these "A /\ True -> B" hypotheses [Mon Mar 27 06:42:07 2017] Are you sure that destruct is able to "destruct" implication? And why is it so, because implication is not encoded as inductive type or where am I missing? [Mon Mar 27 06:42:27 2017] I have tried to destruct "A /\ True -> B" and failed with error "Not an inductive type" [Mon Mar 27 06:43:39 2017] no, you can't destruct the impl [Mon Mar 27 06:43:52 2017] i meant you can intros the premise [Mon Mar 27 06:43:57 2017] It won't work, you don't need to destruct anything because the /\ is in the domain position. If you have "H : A /\ True -> B", then the term "fun (x : A) => H (conj x I)" has type "A -> B" [Mon Mar 27 06:43:58 2017] and then destruct that [Mon Mar 27 06:44:24 2017] Oh, well in my case I have (A /\ True -> B) as a hypothesis. [Mon Mar 27 06:45:25 2017] I had to mention this in the first place. Sorry. [Mon Mar 27 06:46:53 2017] Ok, thanks everyone. I would try to do something with it. [Mon Mar 27 06:48:12 2017] What you could do is this (warning: Ltac incoming): [Mon Mar 27 06:48:39 2017] repeat match goal with H : ?A /\ True -> ?B |- _ => let H' := fresh H in assert (A -> B) as H' by exact (fun x => H (conj x I)); clear H; rename H' into H end. [Mon Mar 27 06:49:09 2017] but of course, it works only very specifically for "A /\ True -> B", and nothing else which would be also trivial [Mon Mar 27 06:49:25 2017] ("True /\ A -> B" won't be simplified for instance) [Mon Mar 27 07:10:43 2017] Cypi: Thanks! [Mon Mar 27 09:31:03 2017] which of Coq commands can I use to search theorems by their conclusions? Eg. I want to locate a theorem that concludes "n = n + 0" and possibly has some premises [Mon Mar 27 09:31:55 2017] In this case, "Search (_ = _ + 0)." will work [Mon Mar 27 09:32:22 2017] you'll have to check the refman to know the actual behavior of "Search" and related commands, I don't know that precisely [Mon Mar 27 09:32:40 2017] (also, underscores are just wildcards, they don't check that it's the same term on both sides of the equality) [Mon Mar 27 09:32:58 2017] ah, parens [Mon Mar 27 09:33:06 2017] I was struggling trying to use quotes [Mon Mar 27 09:34:10 2017] thanks [Mon Mar 27 13:05:35 2017] vorgang: unfortunately, I don't know of any good coq-specific resources. however, I have found it helpful to understand inductive families in general, for example by reading the papers of peter dybjer. [Mon Mar 27 13:05:59 2017] while there are things that coq does differently, you can get pretty far by thinking of coq as "just" an implementation of these ideas. [Mon Mar 27 16:19:56 2017] jstolarek: you need quotes for finding notations with Locate [Mon Mar 27 16:20:06 2017] and parens to find terms with Search [Mon Mar 27 17:40:34 2017] peano arithmetic is just a theory! [Mon Mar 27 17:41:17 2017] a theory full of Suc! [Mon Mar 27 18:40:59 2017] damn, it's annoying that you can't use some Vernacular tokens... [Mon Mar 27 18:41:12 2017] like you can't have a file Variable.v of type called Variable [Tue Mar 28 18:12:44 2017] jrw: ugh, Peter Dybjer has published quite a few papers. Which one specifically would you recommend? [Tue Mar 28 18:19:54 2017] unfortunately, some of the links to papers on his chalmers.se home page are dead [Tue Mar 28 18:31:29 2017] vorgang: https://ncatlab.org/nlab/show/inductive+family#history [Tue Mar 28 19:19:18 2017] vorgang: I recommend starting by reading section 3 of this: http://www.cse.chalmers.se/~peterd/papers/Inductive_Families.pdf [Tue Mar 28 19:19:39 2017] the notation may take a bit of getting used to, but it should become clear if you work through the examples included there. [Tue Mar 28 19:50:13 2017] when I have an instance of a class, how do I fetch its name in an Ltac? I mean, you can't find it matching against the goal. [Tue Mar 28 20:02:44 2017] the instance value will either be in the local proof context, or the global context [Tue Mar 28 20:11:57 2017] let me send an example [Tue Mar 28 20:13:18 2017] https://gist.github.com/pedrotst/a1294868bbb89d6ac65ba13ce5e0f41d [Tue Mar 28 20:22:48 2017] interesting [Tue Mar 28 20:25:45 2017] why do you need to do that at all? [Tue Mar 28 20:25:51 2017] this works for me: Ltac find_dec_tac L i:= edestruct (find_dec L). [Tue Mar 28 20:25:58 2017] it finds the needed instance [Tue Mar 28 20:30:27 2017] I'm getting to the next level in my proofs Chlipala style and trying to get rid of the references to local variable names in my proofs [Tue Mar 28 20:30:58 2017] I'm in the beginning, lerning Ltac and all that [Tue Mar 28 20:31:14 2017] that seemed like a good automation [Tue Mar 28 20:31:27 2017] it's just not buying you anything [Tue Mar 28 20:31:54 2017] you're asking to see the chosen instance, and then turning around an explicitly trying to use that instance. Better automation would be to have no explicit reference at all. [Tue Mar 28 20:32:07 2017] let instance lookup work for you [Tue Mar 28 20:34:32 2017] yes, but I'd have to get that to the next level and make a through proof automation, since I might have several instances that match [Tue Mar 28 20:34:51 2017] wouldn't you be using the same intance either way? [Tue Mar 28 20:35:06 2017] I don't yet see how assigning a name to the instance helps... [Tue Mar 28 20:35:39 2017] yeah, I think I can drop that [Tue Mar 28 20:36:23 2017] Ltac find_dec_tac L i:= edestruct (find_dec L i). worked nicely thanks [Tue Mar 28 20:36:39 2017] I didn't know edestruct was smart like that [Tue Mar 28 20:37:31 2017] i'm not sure you even need it [Tue Mar 28 20:37:41 2017] maybe regular destruct will work here too [Tue Mar 28 20:38:21 2017] geez, it works! I've been wraping my head for nothing [Tue Mar 28 20:38:23 2017] haha [Wed Mar 29 01:05:51 2017] jrw: thanks [Thu Mar 30 14:05:36 2017] could someone explain why an nary inductive type doesn't seem to be allowed, e.g. Inductive rel_n : forall n, nary bool n Prop := ...? It fails with the error 'Not an arity' on the type of the relation. [Thu Mar 30 14:06:42 2017] works fine to do the equivalent rel_n_v : forall n, Vector.t bool n -> Prop, but I have an aesthetic preference for the nary version [Thu Mar 30 14:06:52 2017] i'd never heard of nary [Thu Mar 30 14:07:56 2017] ah, sorry: https://coq.inria.fr/library/Coq.Numbers.NaryFunctions.html [Thu Mar 30 14:08:19 2017] ah, cool [Thu Mar 30 14:08:32 2017] nprod is just what I'm using for vector [Thu Mar 30 14:11:27 2017] cool, hadn't seen that. I'm guessing nprod (S n) a := prod a (nprod n a)? [Thu Mar 30 14:11:34 2017] yep [Thu Mar 30 17:16:08 2017] is there a way to write a tactic like "t := match goal with [ H : ... ] => ... end" such that "t; u" can change the choice of H in t when u fails? [Thu Mar 30 17:18:04 2017] or do I need to pass `u` as a continuation to `t` so that its failure is understood by `t`? [Thu Mar 30 17:20:46 2017] hmmm, even using a continuation I can't seem to [Thu Mar 30 17:54:22 2017] nvm [Thu Mar 30 17:57:43 2017] Ptival: I'm not sure, but isn't multimatch what you're looking for, maybe? [Fri Mar 31 03:14:05 2017] Hi. How should I fix the verilog vs coq proof general issue? [Fri Mar 31 03:14:33 2017] (emacs thinks my .v files are verilog, rather then coq files) [Fri Mar 31 09:18:09 2017] Hello! [Fri Mar 31 09:18:35 2017] I have two hypotheses of the form H0: x <= y, H1: y < z. [Fri Mar 31 09:18:45 2017] sorry, not hypotheses but rather goals [Fri Mar 31 09:18:59 2017] how do I combine them into a singel x <= y < z? [Fri Mar 31 09:24:19 2017] FUZxxl, if you do 'Locate "_ <= _ < _".' you can see that it's only an alias for "and (le x y) (lt y z)" anyway [Fri Mar 31 09:24:37 2017] so if you link the two propositions with /\ you're done [Fri Mar 31 09:25:03 2017] rrika: how do I do that? [Fri Mar 31 09:25:16 2017] what exactly? [Fri Mar 31 09:25:33 2017] rrika: combine two goals into one with a logical and [Fri Mar 31 09:25:58 2017] hm, are you in the middle of a proof right now? [Fri Mar 31 09:26:03 2017] rrika: yes [Fri Mar 31 09:26:08 2017] what's your current goal? [Fri Mar 31 09:26:21 2017] just one half? [Fri Mar 31 09:26:23 2017] I have two goals: x <= y and y < z [Fri Mar 31 09:26:39 2017] and I want to apply a lema which proves (x <= y /\ y < z) [Fri Mar 31 09:26:45 2017] ah, okay [Fri Mar 31 09:27:06 2017] but coq won't let me, so want to combine the two goals and see if that works [Fri Mar 31 09:27:07 2017] okay, so before you get to the point where you split into these two cases, you do "enough (x <= y /\ y < z)" [Fri Mar 31 09:27:25 2017] that will give you that as hypothesis and you can continue with that, and later you have to prove it [Fri Mar 31 09:27:28 2017] but your goal will have both [Fri Mar 31 09:27:50 2017] ok [Fri Mar 31 09:27:54 2017] (assert (x <= y /\ y < z) does the same in reverse order, first you prove it's correct, then you can use it) [Fri Mar 31 09:28:03 2017] You can also just apply your lemma which proves (x <= y /\ y < z) [Fri Mar 31 09:28:19 2017] you won't be able to really reunite your two goals, but you can apply your lemma separately in each [Fri Mar 31 09:28:49 2017] apply is that clever? [Fri Mar 31 09:28:55 2017] Cypi: that's what I tried first but I get unification problems. [Fri Mar 31 09:29:10 2017] In most cases, apply is able to go through conjonctions, yes [Fri Mar 31 09:29:22 2017] another thing you could do is get the proof for (x <= y /\ y < z) and then destruct it and throw away one half with "clear" [Fri Mar 31 09:29:36 2017] (if it doesn't work automatically) [Fri Mar 31 09:29:54 2017] Basically, I start with an inequality of the form (x <= y < w) which I want to refine to (x <= y < z) using a hypothesis. [Fri Mar 31 09:30:16 2017] so I split that goal and applied transitivity [Fri Mar 31 09:30:22 2017] but then I can't combine it again! [Fri Mar 31 09:30:43 2017] somewhere in the documentation it is said that you never actually need assert [Fri Mar 31 09:30:52 2017] which is why I was wondering how to do that [Fri Mar 31 09:31:21 2017] I guess the full signature is (x <= y < w) → (w < z) → (x <= y < z) ? [Fri Mar 31 09:31:44 2017] rrika: of what? [Fri Mar 31 09:32:03 2017] ah yeah, you can assume that [Fri Mar 31 09:32:09 2017] (in ZArith) [Fri Mar 31 09:34:27 2017] ah, so you have something that when applied gives you (x <= y < w) but not (x <= y < w) itself? [Fri Mar 31 09:34:42 2017] no [Fri Mar 31 09:34:47 2017] I do have x <= y < w [Fri Mar 31 09:35:07 2017] but it won't let me apply Zlt_trans to it to reach x <= y < z [Fri Mar 31 09:36:52 2017] get unification errors [Fri Mar 31 09:36:57 2017] yeah, Zlt_trans expects single inequalites, not combined ones [Fri Mar 31 09:37:05 2017] (forall n m p : Z, (n < m)%Z -> (m < p)%Z -> (n < p)%Z) [Fri Mar 31 09:37:26 2017] so alternatively, how can I apply Zlt_trans to just part of the inequality? [Fri Mar 31 09:38:36 2017] destruct (x <= y < w) into (x <= y) and (y < w), then split your goal from (x <= y < z) to (x <= y) and (y < z) using "apply conj." the left one you can show with "assumption", the other one with "Zlt_trans" [Fri Mar 31 09:40:10 2017] sadly, this doesn't solve my full problem [Fri Mar 31 09:41:40 2017] sorry, I guess I misunderstood, what else is there? [Fri Mar 31 09:41:53 2017] my problem is: I have the goal (x <= y < z) and I want to use the hypothesis (w < z) to get the goal (x <= y z) so I can apply some lemma. Can this be done without using assert. etc.? I am interested in this because the manual claims that assert is never truly needed to prove things. [Fri Mar 31 09:42:10 2017] my problem is: I have the goal (x <= y < z) and I want to use the hypothesis (w < z) to get the goal (x <= y < w) so I can apply some lemma. Can this be done without using assert. etc.? I am interested in this because the manual claims that assert is never truly needed to prove things. [Fri Mar 31 09:42:42 2017] the last approach I described doesn't need assert [Fri Mar 31 09:42:59 2017] and it's true, you can rebuild parts of your proof in each branch of it when you need it [Fri Mar 31 09:43:14 2017] sometimes it's convenient to prove something earlier so you can reuse it in the different branches [Fri Mar 31 09:43:37 2017] true. However, I wasn't able to rebuild the part of the proof I needed as applying that lemma in each branch failed. [Fri Mar 31 09:43:52 2017] (unable to unify) [Fri Mar 31 09:44:35 2017] can you paste your whole proof state + error online somewhere, my imagination is failing [Fri Mar 31 09:45:02 2017] sorry [Fri Mar 31 09:45:07 2017] let's see. [Fri Mar 31 10:08:52 2017] I found my problem. There was a typo. Sorry for wasting your time, rrika. [Fri Mar 31 10:10:53 2017] haha, oh well, happens [Fri Mar 31 10:12:24 2017] (basically, I used lt_trans instead of le_lt_trans) [Fri Mar 31 10:12:59 2017] heh [Fri Mar 31 10:13:30 2017] I need to go to work (should've gone hours ago) byebye and good luck [Fri Mar 31 10:14:18 2017] see you [Sat Apr 1 15:19:15 2017] what does "by intros [|]." do? [Sat Apr 1 15:25:10 2017] oh, the reason I can't find it in the manual is because this source I have defines it itself, nevermind. [Sat Apr 1 16:56:58 2017] I have hypotheses `IHl : All P l -> forall x : T, In x l -> P x` and `All P l`. I expected `apply IHl in IHl.` to rewrite H2, but i'm getting `unable to unify` [Sat Apr 1 17:04:13 2017] oops, i meant `apply IHl in H2` [Sat Apr 1 17:04:31 2017] and it seems like in this case i'm getting Error: Unable to find an instance for the variable x. [Sat Apr 1 17:07:20 2017] you need a with clause to pass a value for x in there. [Sat Apr 1 17:12:27 2017] it works with `apply IHl with (x:=x0) in H2`, but i don't get why coq can't unify it [Sat Apr 1 17:16:24 2017] i expected it to rewrite H2 to `forall x : T, In x l -> P x` [Sat Apr 1 18:25:36 2017] dredozubov: that has somehow to do with how apply's "matching" works (but i can't explain any details). Note, however, that using apply here is somewhat bizarre anyway because you say like "find me a way to fit these two things together and then do it"; but in fact you know exactly what you want, namely just the term IHl H2. [Sat Apr 1 18:26:11 2017] you can do `assert (H2' := IHl H2).` to introduce that into the context (if you really want) [Sat Apr 1 18:31:13 2017] how can I elegantly show "c = d" from "a b = Some c" and "a b = Some d" [Sat Apr 1 18:33:51 2017] are you allowed functional extensionality? [Sat Apr 1 18:34:41 2017] no, some is a constructor though, not a function [Sat Apr 1 18:35:05 2017] ah... that was the direction of my thought :-( [Sat Apr 1 18:35:11 2017] I did it with "rewrite H1 in H2" and "inversion" on the resulting (Some c = Some d) and "reflexivity" after the goal turned into "d = d" [Sat Apr 1 18:35:18 2017] it's not very nice thouhg [Sat Apr 1 18:35:38 2017] I would have done that too [Sat Apr 1 18:35:43 2017] okay, that's reassuring [Sat Apr 1 18:36:06 2017] I'm poking around ch2o and am too lazy to install coq8.5 again (after I upgraded to 8.6) [Sat Apr 1 18:36:08 2017] so I'm porting it now [Sat Apr 1 18:36:21 2017] very weird in which ways proofs break [Sat Apr 1 18:36:57 2017] another weirdness was "tactic1; tactic2" going into an infinite loop, but if I copy paste tactic2 as many times as tactic1 gives goals, it works [Sun Apr 2 12:01:19 2017] can I make local definitions in an 'Inductive'? [Sun Apr 2 12:04:53 2017] I guess not. [Sun Apr 2 12:04:55 2017] https://coq.inria.fr/refman/Reference-Manual003.html [Sun Apr 2 12:05:07 2017] inductive ::= Inductive ind_body with … with ind_body, … [Sun Apr 2 12:32:19 2017] rrika: you can use a Section together with Let; after closing the section, the Let idents will be replaced by their definition. E.g. `Section TMP. Let t := (my long term that i don't want to repeat). Inductive Foo := X : t -> Foo | Y : t -> t -> Foo. End TMP.` [Sun Apr 2 12:32:53 2017] RegEchse, the long term can't depend on Foo though, right? [Sun Apr 2 12:33:17 2017] well, I can pass it in myself. [Sun Apr 2 12:33:18 2017] yes, that won't be possible. :/ [Sun Apr 2 12:33:27 2017] won't be as short, but acceptable [Sun Apr 2 19:21:08 2017] yeah, that's not possible, I was trying the other day I think :( [Sun Apr 2 19:21:14 2017] same with Records + Inductive [Mon Apr 3 04:39:36 2017] Hi [Mon Apr 3 04:40:11 2017] I want to destruct "match X as __ return", but destruct X gives me "Error: Abstracting over the term "o" leads to a term" this error. [Mon Apr 3 04:41:17 2017] Definition is made with "Program Definition". What I typed was normal pattern match, but it is changed into dependent pattern match (with variable name "anonymous") for the obligation proof. [Mon Apr 3 04:41:45 2017] I do not understand dependent pattern match in deep. How can I solve this problem? [Mon Apr 3 06:15:05 2017] Where can I find in the reference manual that "eval delta [H] in H." is a valid RHS of an Ltac definition? Specifically '[H]' is nowhere to be found as being valid, yet it does work. [Mon Apr 3 06:16:27 2017] What does it do? I wasn't aware of this syntax :o [Mon Apr 3 06:16:39 2017] Cypi: I have no clue. [Mon Apr 3 06:16:51 2017] augae: well, I can guess. [Mon Apr 3 06:17:18 2017] Cypi: but I don't like to guess, so let's not go there. [Mon Apr 3 06:17:39 2017] Even "delta" is not supposed to be valid, according to the documentation [Mon Apr 3 06:17:49 2017] "where redexpr is a reduction tactic among red, hnf, compute, simpl, cbv, lazy, unfold, fold, pattern." [Mon Apr 3 06:18:22 2017] Cypi: heh, I even overlooked that one. [Mon Apr 3 06:18:30 2017] Cypi: I just think this is super sloppy. [Mon Apr 3 06:18:57 2017] It makes Coq a language which can only be used by the magicians who made it with their secret incantations ;) [Mon Apr 3 06:19:25 2017] I mean, there are some secret incantations, but they are not necessary (or at least I hope so) [Mon Apr 3 06:21:13 2017] Cypi: I was hoping to find someone here who does know what it means. [Mon Apr 3 06:21:25 2017] I'm looking at the source code. What is your version of Coq? [Mon Apr 3 06:22:27 2017] 8.6 [Mon Apr 3 06:22:58 2017] I was also able to make CoqIDE crash by merely loading a previously saved file (few hundred lines). [Mon Apr 3 06:23:05 2017] Hmm. Do you have any plugin? It doesn't seem to be valid syntax on my end :o [Mon Apr 3 06:23:47 2017] Cypi: Ltac get_value H := eval cbv delta [H] in H. [Mon Apr 3 06:24:06 2017] ah, you did not mention the "cbv" part! [Mon Apr 3 06:24:19 2017] https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic145 [Mon Apr 3 06:24:23 2017] there you go, all specified :) [Mon Apr 3 06:24:43 2017] (I meant to link the "cbv" section) [Mon Apr 3 06:24:59 2017] (specifically, "The delta flag itself can be refined into delta [qualid1…qualidk] ...") [Mon Apr 3 06:26:06 2017] combined with this https://coq.inria.fr/refman/Reference-Manual011.html#sec481 which explains the "eval ... in ..." part [Mon Apr 3 06:26:10 2017] Cypi: thanks [Mon Apr 3 06:26:48 2017] Cypi: eval (cbv (delta [H])) in H. would have been simpler. [Mon Apr 3 06:27:05 2017] Cypi: can I print expressions with all parens somehow? [Mon Apr 3 06:27:24 2017] Cypi: I meant definitions. [Mon Apr 3 06:27:25 2017] I don't know that. I'm not even sure parens are allowed here actually [Mon Apr 3 06:28:43 2017] Cypi: they are not. [Mon Apr 3 06:29:49 2017] Cypi: perhaps they hate Lisp. [Mon Apr 3 07:34:52 2017] https://github.com/mukeshtiwari/Coq/blob/master/software-foundation-8.5/IndProp.v#L352 what does `induction 2` do here? [Mon Apr 3 07:35:38 2017] induction on the second non-dependent hypothesis [Mon Apr 3 07:35:49 2017] ("non-dependent" meaning that the rest of the goal does not depend on it) [Mon Apr 3 07:36:18 2017] can't wrap my head around "non-dependent" part still [Mon Apr 3 07:36:35 2017] is it induction on 'n <= o'? [Mon Apr 3 07:36:39 2017] yes [Mon Apr 3 07:36:57 2017] It basically means "the second non-named hypothesis", if you want to see it like that [Mon Apr 3 07:37:04 2017] can you show an example where it won't be non-dependent? [Mon Apr 3 07:37:29 2017] In your example, m n and o are hypotheses that would be "dependent" [Mon Apr 3 07:38:14 2017] is it fair to say that it becomes dependent when it's explicitly quantified? [Mon Apr 3 07:38:35 2017] Does "explicitly quantified" means that it has an apparent name? [Mon Apr 3 07:38:37 2017] mean* [Mon Apr 3 07:40:02 2017] i mean that there's quantifier with a name to the left [Mon Apr 3 07:40:53 2017] Then yes, I guess. If you can remove the name and still have a goal that makes sense, then it's non-dependent; otherwise, if you need a name, it's dependent [Mon Apr 3 07:41:20 2017] [the documentation talks about "non-dependent product", it's more correct than the term "non-dependent hypothesis" that I was using] [Mon Apr 3 07:43:19 2017] can i rewrite this proof by explicitly stating i want to apply induction tactic on `n <= o`? [Mon Apr 3 07:43:38 2017] i get an error: "Not an inductive product" when i try to do that [Mon Apr 3 07:44:02 2017] You could first intros everything manually and then do an induction: "intros m n o Hmn Hno. induction Hno." [Mon Apr 3 07:44:33 2017] you cannot write directly "induction (n <= o)" because you don't want to do an induction on the term "n <= o", you want to do an induction on a term _whose type is_ "n <= o" [Mon Apr 3 07:44:36 2017] hmm, i can do that if i "intro" that hypothesis, the do "induction Hnlto" [Mon Apr 3 14:58:11 2017] hey guys [Mon Apr 3 14:58:13 2017] allah is doing [Mon Apr 3 14:58:20 2017] sun is not doing allah is doing [Mon Apr 3 14:58:25 2017] to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [Mon Apr 3 15:06:13 2017] he's definitely reduced the volume of his contribution each time [Mon Apr 3 17:29:04 2017] :) [Mon Apr 3 20:52:45 2017] … [Mon Apr 3 21:32:14 2017] When you use the "exists" tactic, does the name passed to it have to be unique from any previous name? [Mon Apr 3 21:34:54 2017] significance: I'm not exactly sure what you mean. exists takes an argument that is the "witness" for the existential. the witness can be any term, not just a name. [Mon Apr 3 21:35:21 2017] and exists doesn't add any new things to your context, so you shouldn't need to worry about uniqueness of names or anything. [Mon Apr 3 21:35:50 2017] it is true that for some of the other tactics that do introduce new things into the context, you do need to provide fresh names or it will complain. [Mon Apr 3 21:36:05 2017] jrw: ahh, it makes a lot more sense now. thank you! [Mon Apr 3 21:39:43 2017] is there a difference between running .\n. and ; . ? [Mon Apr 3 21:43:53 2017] significance, yes, tactic 2 will be applied to each resulting goal of tactic 1. [Mon Apr 3 21:44:02 2017] rrika: thank you! [Mon Apr 3 21:45:04 2017] is there a way to Show in coqtop in between semicolon-ed tactics? [Mon Apr 3 21:45:36 2017] significance, I don't know how to do that. I'm asking myself that as well. [Mon Apr 3 21:45:51 2017] rrika: huh -- no worries! thank you :) [Mon Apr 3 21:59:55 2017] there's no way of doing that, unfortunately. [Mon Apr 3 22:12:04 2017] jrw: bummer -- thank you! [Mon Apr 3 22:20:12 2017] are there any tools to pinpoint sources of performance problems in coq? [Mon Apr 3 22:20:21 2017] proofs taking forever to check, or taking up 8GB while checking [Tue Apr 4 11:37:29 2017] cocreature pasted “No title” at http://lpaste.net/354277 [Tue Apr 4 11:38:00 2017] Hey, I’m trying to figure out how to make my adt so that it only allows constructing pairs if the arguments are values [Tue Apr 4 11:38:22 2017] however I fail to define the mutually recursive types because "Expr was not found in the current environment" [Tue Apr 4 11:38:26 2017] any ideas? [Tue Apr 4 11:43:35 2017] So, what you are trying to do is called induction-induction, and it's currently not supported by Coq [Tue Apr 4 11:44:07 2017] Cypi: oh ok, well I guess the good thing is that it’s at least not me being stupid [Tue Apr 4 11:44:22 2017] I’ll just add the value condition to my step relation instead of to the adt [Tue Apr 4 11:44:29 2017] thanks! [Wed Apr 5 07:46:56 2017] is there any way to automatically generate stronger induction hypothesis in particular for propositions with lists? I found https://stackoverflow.com/questions/39976451/induction-principle-for-propositions-with-lists-or-lnr-for-expressions-with-ne and I was able to adapt it to my own types but it seems kind of annoying to have to write and prove these lemmas for every type like this. [Wed Apr 5 07:50:06 2017] or maybe there is away to avoid these predicates altogether and replace them by equivalent predicates that don’t require custom induction principles? [Wed Apr 5 09:35:30 2017] how do I turn premise H: a < b into H0: b > a ? [Wed Apr 5 09:52:44 2017] jstolarek, you can do the reverse with "unfold gt in H0" [Wed Apr 5 09:53:10 2017] then maybe fold (gt b a) in H0 would work? [Wed Apr 5 09:53:35 2017] yep [Wed Apr 5 09:53:43 2017] didn't know about 'fold' [Wed Apr 5 09:53:50 2017] Is there any way to manipulate identifiers as strings in Ltac? Suppose I have a variable x and I want to create an identifier "Hyp_x" [Wed Apr 5 10:00:14 2017] thanks [Wed Apr 5 10:00:21 2017] I went with: [Wed Apr 5 10:00:32 2017] assert (H0: b > a) by omega [Wed Apr 5 10:05:42 2017] notdan, do you think this is related? https://stackoverflow.com/questions/22404394/how-to-automatically-generate-good-names-when-decomposing-existential-hypothes [Wed Apr 5 10:06:20 2017] though it seems they only pick an existing name, not build a completely new one [Wed Apr 5 10:07:28 2017] actually, "fresh" is exactly there to concat names, it seems [Wed Apr 5 10:07:31 2017] I need to test this [Wed Apr 5 10:10:24 2017] notdan, [Wed Apr 5 10:10:25 2017] Ltac add a b := let n := (fresh a b) in pose (n := a+b). [Wed Apr 5 10:10:25 2017] Goal nat -> nat -> nat. intros. add H H0. assumption. Qed. [Wed Apr 5 11:00:27 2017] is there a tactic that allows me to go from (x + 1) to ((fun y => y + 1) x) [Wed Apr 5 11:00:29 2017] ? [Wed Apr 5 11:01:09 2017] hm interesting rrika [Wed Apr 5 11:01:18 2017] I will test if it works in my case [Wed Apr 5 11:01:38 2017] jstolarek, something something generalize maybe? sorry, need to go [Wed Apr 5 11:02:22 2017] jstolarek: you can either do a [change] or use [eta_expansion] [Wed Apr 5 11:02:36 2017] (the later being a lemma, so you rewrite using it) [Wed Apr 5 11:05:04 2017] is that descriebed anywhere in the manual? [Wed Apr 5 11:35:59 2017] dunno [Wed Apr 5 11:51:34 2017] is there some induction principle for doing induction on two lists of the same length simultaneously in the standard library? [Wed Apr 5 12:26:34 2017] You can either use well-founded induction or write an inductive predicate expressing the fact that the lists have the same length [Wed Apr 5 12:26:47 2017] then you can use the induction principle for that inductive predicate [Wed Apr 5 12:27:57 2017] notdan: I was mostly being lazy and hoped that the right induction principle is already somewhere in the standard library :) [Thu Apr 6 00:44:56 2017] Hi Everyone [Thu Apr 6 00:45:19 2017] I am extracting Haskell code https://github.com/mukeshtiwari/formalized-voting/blob/master/paper-code/Extraction.v [Thu Apr 6 00:46:55 2017] In extracted code at line 441, type Cand = (), cand_all = Prelude.error "realize it" https://github.com/mukeshtiwari/formalized-voting/blob/master/paper-code/schulze-voting/src/Lib.hs#L441 [Thu Apr 6 00:47:58 2017] I have change it manually to data Cand = A | B | C | D | E and cand_all = Cons A (Cons B (Cons C (Cons D (Cons E NIl))))) [Thu Apr 6 00:48:58 2017] I am looking for way to do this while code extraction rather than doing it manually. [Thu Apr 6 00:49:11 2017] it is possible or any work around ? [Fri Apr 7 09:38:52 2017] question regarding modules [Fri Apr 7 09:50:51 2017] If I have a module type MT where I have used a Definition, i.e something like Module Type MT. Parameter foo : Type. Definition bar : foo -> fo. End MT. [Fri Apr 7 09:51:28 2017] Then when I define a module M of type MT, I always need to also write the Definition bar. Why is that the case? [Fri Apr 7 09:54:08 2017] Here is the code in gist https://gist.github.com/piyush-kurur/e4be87b4d86d90eb1296d1b1faeaefc5 [Sat Apr 8 07:22:13 2017] is it possible to instance the same type class twice? [Sun Apr 9 09:02:33 2017] i think i had to do manual rewriting in other occurences, don't understand why it work as it is: https://gist.github.com/dredozubov/a3ef6603d30998c44a97776106edb0ad [Sun Apr 9 10:21:39 2017] dredozubov: I would assume it works because [x] ++ y just simplifies to x :: y. you don’t need to prove and use some rewriting lemma here. but then again I don’t know much about how apply works internally so take that with a grain of salt :) [Mon Apr 10 10:13:09 2017] Hello! [Mon Apr 10 10:13:34 2017] After doing "compute." I am left with the goal "Lt = Gt -> False" [Mon Apr 10 10:13:37 2017] How do I prove that? [Mon Apr 10 10:14:10 2017] FUZxxl: "intros H. inversion H." should work I think [Mon Apr 10 10:14:33 2017] cocreature: thanks [Mon Apr 10 10:14:45 2017] I guess congruence works too [Mon Apr 10 10:14:54 2017] cocreature: is there a way to make coq evaluate numeric expressions in Zarith? [Mon Apr 10 10:15:12 2017] So, e.g. if I have (1 + 2 * 3 ^ 4) I want to evaluate that expression to its value [Mon Apr 10 10:15:18 2017] simpl? [Mon Apr 10 10:15:26 2017] or compute? [Mon Apr 10 10:15:28 2017] or compute [Mon Apr 10 10:15:35 2017] simpl doesn't help with pow [Mon Apr 10 10:15:38 2017] apparently [Mon Apr 10 10:16:19 2017] and compute creates very complex expressions when not the entire thing can be evaluated [Mon Apr 10 10:16:32 2017] I'm honestly not good at coq [Mon Apr 10 10:18:08 2017] simpl seems to work for me [Mon Apr 10 10:18:19 2017] at least for something like "Goal 1 + 2 + 3 ^ 4 = 84." [Mon Apr 10 10:18:34 2017] strange [Mon Apr 10 10:18:44 2017] FUZxxl: do you have that in the goal or in a hypothesis? [Mon Apr 10 10:18:49 2017] I have (0 <= 2 ^ 7)%Z in my goal [Mon Apr 10 10:18:59 2017] when I type simpl. I get (0 <= Z.pow_pos 2 7)%Z [Mon Apr 10 10:19:19 2017] cocreature: I am also interested in how to evaluate things in hypotheses if possible [Mon Apr 10 10:19:20 2017] oh I can reproduce that [Mon Apr 10 10:19:36 2017] FUZxxl: you can do "simpl in *" or "simpl in HypothesisName" [Mon Apr 10 10:19:44 2017] cocreature: let's see... [Mon Apr 10 10:20:06 2017] cocreature: that does something but doesn't get rid of Z.pow_pos [Mon Apr 10 10:20:13 2017] FUZxxl: "unfold Z.pow_pos." helps [Mon Apr 10 10:20:15 2017] is it because Z.pow_pos is recursive? [Mon Apr 10 10:23:09 2017] I’m not sure why it requires an explicit unfold. even "Hint Unfold Z.pow_pos" and "Transparent Z.pow_pos" don’t help [Mon Apr 10 10:24:51 2017] cbn works [Mon Apr 10 10:25:52 2017] FUZxxl: I suppose simpl probably considers 128 to be a more complex term than "Z.pow_pos 2 7" and thereby the heuristic for simplifying is not triggered. but I’ve never bothered to read the docs on simpl to figure out how exactly it decides when to simplify :) [Mon Apr 10 10:26:10 2017] cocreature: okay, I'll try cbn, too. Thanks. [Mon Apr 10 10:27:49 2017] shit [Mon Apr 10 10:27:57 2017] I accidentally deleted my last half hour of work [Tue Apr 11 11:58:09 2017] Hey, I have the following state http://lpaste.net/354517 and I’m trying to use "rewrite <- H6". However, that complains that there is no matching subterm in my goal. but it seems like there is one in the condition of the if clause? what am I missing here? [Tue Apr 11 12:05:31 2017] ah "Set Printing All." shows a difference. now I only need to figure out where that comes from :) [Tue Apr 11 16:00:18 2017] what are people's take on whether Coq file names should be like_this.v or LikeThis.v or something else? [Tue Apr 11 16:01:00 2017] I used to do the upper-case thing like the standard library, but it clashes with Vernacular a lot, so you can't name a file Variable.v because then you can't import it : >:( [Tue Apr 11 16:32:55 2017] hi [Tue Apr 11 16:33:13 2017] I use LikeThis names, and just avoid syntactic conflicts :) [Tue Apr 11 16:48:16 2017] yeah, I think I'll get back to this [Tue Apr 11 18:26:59 2017] It looks like `Import M` makes M’s names available unprefixed, while `Include M` actually copies all the bindings from M into the current module. Is that correct? [Tue Apr 11 19:52:34 2017] that sounds right [Tue Apr 11 19:52:48 2017] Module M := FooModule. [Tue Apr 11 19:52:52 2017] should make it available prefixed [Tue Apr 11 19:52:57 2017] bbaren: That is almost correct. However, [constr_eq] considers the "copied" bindings from [Include] to be syntactically equal to the original bindings. Including for inductive types. Despite the fact that they will print with different names, and [Compute] will not normalize one name to the other. [Tue Apr 11 19:52:58 2017] Module Import M := FooModule. [Tue Apr 11 19:53:03 2017] gives you both prefixed and unprefixed [Tue Apr 11 19:53:12 2017] hi jgross! [Tue Apr 11 19:53:23 2017] hi johnw! [Wed Apr 12 05:33:26 2017] Hello, where can I find the definition of the constructors O and S for natural numbers. [Wed Apr 12 05:33:58 2017] I mean something like O = 0 and S n = n + 1 [Wed Apr 12 05:34:08 2017] You can use [Locate] to find the definitions of various indentifiers. [Wed Apr 12 05:34:26 2017] In this particular case O and S do not really have a definition in the sense that you wrote [Wed Apr 12 05:34:47 2017] rather the type nat of natural numbers is defined by constructors O and S [Wed Apr 12 05:35:37 2017] I would assume there is somewhere in the code that coq converts O to a zero, is that not so? [Wed Apr 12 05:36:20 2017] sathi: no, because "zero" is precisely O [Wed Apr 12 05:36:59 2017] there are no built-in integers in Coq [Wed Apr 12 05:37:24 2017] rather the type [nat] defines the natural numbers [Wed Apr 12 05:38:37 2017] From Init/Datatypes.v: [Wed Apr 12 05:38:38 2017] Inductive nat : Set := [Wed Apr 12 05:38:38 2017] | O : nat [Wed Apr 12 05:38:39 2017] | S : nat -> nat. [Wed Apr 12 05:39:26 2017] But O could map to any integer (for example, 1) and S could be any function (maybe S n = n + 2) [Wed Apr 12 05:41:23 2017] So I would assume somewhere in the source code these are defined. [Wed Apr 12 05:42:33 2017] But I am not able to locate these in the source code. [Wed Apr 12 05:44:23 2017] not exactly how inductive types work [Wed Apr 12 05:44:28 2017] constructors are opaque [Wed Apr 12 05:44:43 2017] like, S O is just S O [Wed Apr 12 05:47:16 2017] If I define my own inductive type for even numbers like so: [Wed Apr 12 05:47:16 2017] sathi: what do you mean by O being mapped somewhere? [Wed Apr 12 05:47:17 2017] Inductive even_nat : Type := [Wed Apr 12 05:47:18 2017] | two : even_nat [Wed Apr 12 05:47:19 2017] | next_even : even_nat -> even_nat. [Wed Apr 12 05:47:25 2017] At which point do you expect it to be mapped and why? [Wed Apr 12 05:49:10 2017] I can see that the parser is treating the symbols O and S differently, i.e., resolving these to the numeric 0 and S such that S n = n + 1 [Wed Apr 12 05:50:53 2017] So I was expecting this to be defined somewhere in the source code, maybe kernel/constr.ml or kernel/inductive.ml [Wed Apr 12 05:51:06 2017] And I looked into the code, but could not find it. [Wed Apr 12 05:51:37 2017] it's just a printing thing afaik [Wed Apr 12 05:53:21 2017] Yes it is just a pretty-printing mechanism. [Wed Apr 12 05:54:31 2017] and it is defined here: https://github.com/coq/coq/blob/trunk/plugins/syntax/nat_syntax.ml [Wed Apr 12 06:03:48 2017] Can you tell me what I need to do to define an inductive type for even numbers [Wed Apr 12 06:03:59 2017] Inductive even_nat : Type := [Wed Apr 12 06:03:59 2017] | two : even_nat [Wed Apr 12 06:04:00 2017] | next_even : even_nat -> even_nat. [Wed Apr 12 06:16:49 2017] that could work, but I would suggest starting with zero [Wed Apr 12 06:17:00 2017] alternatively, you can define an inductive predicate on natural numbers: https://coq.inria.fr/library/Coq.Arith.Even.html#even [Wed Apr 12 06:18:09 2017] Thanks notdan for your help!! I will read up a bit on coq + ocaml and come back in a day or so. [Wed Apr 12 07:23:47 2017] is there some builtin tactic that, if the goal is A, searches for an assumption of the form B -> A and applies it automatically? [Wed Apr 12 07:25:27 2017] cocreature, yeah, it's called "auto" [Wed Apr 12 07:25:56 2017] rrika: that doesn’t seem to work if I don’t have a B assumption [Wed Apr 12 07:26:58 2017] oh [Wed Apr 12 07:31:02 2017] I guess reorganizing my proof to first get B is probably easier anyway [Wed Apr 12 07:33:28 2017] cocreature, I guess the issue is kinda that there are so many things of the form -> A and so it needs some kind of hint that you want B [Wed Apr 12 07:33:44 2017] but I guess you're trying to make a proof more terse here. [Wed Apr 12 07:34:12 2017] rrika: I’m fine if it only searches the local assumptions, in fact I want it to only search those and it doesn’t seem that uncommon that you only have one hypothesis that matches in that case [Wed Apr 12 07:45:16 2017] cocreature, idk about built-ins then but this works: Ltac apply_hyp := match goal with [ H: ?P->?X |- ?X ] => apply H end. [Wed Apr 12 07:45:40 2017] rrika: yeah that’s what I came up with myself, thanks :) [Wed Apr 12 07:50:17 2017] cocreature, I just realized an interesting thing btw, if you have (C->B->A) and (B->A) in your hypotheses, then no matter what order they are in, this ltac will always focus on the easier one [Wed Apr 12 07:50:31 2017] I wonder if this is some kind of heuristic based on number of generated goals [Wed Apr 12 07:54:14 2017] rrika: C -> B -> A simply doesn’t match ?P->?X [Wed Apr 12 07:54:30 2017] P can't be C->B? [Wed Apr 12 07:54:43 2017] no C -> B -> A is C -> (B -> A) [Wed Apr 12 07:54:50 2017] which is different from (C -> B) -> A [Wed Apr 12 07:55:13 2017] *facepalm* you're right [Wed Apr 12 07:55:37 2017] how does one match a function of any arity resulting in A in ltac then? [Wed Apr 12 07:55:43 2017] I have no idea :) [Wed Apr 12 07:55:48 2017] it's a mystery [Wed Apr 12 07:55:50 2017] let me know if you figure it out :) [Wed Apr 12 07:55:53 2017] sure [Wed Apr 12 07:57:50 2017] 1) You could blindly do "match goal with H : _ |- _ => apply H end." [Wed Apr 12 07:58:30 2017] 2) You could write another tactic that takes some term X and succeeds (with an "idtac") if and only if it is a product of any arity that results in A [Wed Apr 12 07:59:21 2017] Cypi, thank you [Wed Apr 12 07:59:42 2017] Both approaches have the problem that they don't look very efficient though, I'm not sure what would be best :/ [Wed Apr 12 08:00:20 2017] Cypi, i guess apply will already recursively traverse the H term, so using a second tactic means you traverse it twice? [Wed Apr 12 08:00:59 2017] The first one would certainly be preferable if you don't mind it to work for hypotheses where you need some unifying to make it work [Wed Apr 12 08:01:15 2017] something like "H : forall x, P x -> Q x" when the goal is "Q y" [Wed Apr 12 08:01:42 2017] (which would not work with the second approach, or what you seemed to be looking for initially) [Wed Apr 12 08:01:54 2017] oh, right [Wed Apr 12 08:10:53 2017] there is a variant of apply that never unifies iirc [Wed Apr 12 08:11:40 2017] *never instantiates [Wed Apr 12 08:11:50 2017] "simple apply H." [Wed Apr 12 12:02:41 2017] Am I correct in observing an isomorphism between Ensembles and Σ types? For example, I can define the set of naturals less than ten either with [Definition digits := {n | n < 10}.] or with [Inductive digits : Ensemble nat := digit : forall n, n < 10 -> In _ digits n.]. [Wed Apr 12 12:05:43 2017] I guess a Σ type actually has the condition for membership built into the type, whereas Ensembles build the condition into the constructor. [Wed Apr 12 19:26:53 2017] bbaren: umm, i'm not sure [Wed Apr 12 19:27:11 2017] what if you say something like [Wed Apr 12 19:27:24 2017] nonzero_ctor : forall n, nonzero (S n) [Wed Apr 12 19:46:23 2017] benzrf: I’m confused. What is nonzero_ctor for? [Wed Apr 12 19:54:31 2017] bbaren: maybe they meant, what if you consider the type [Inductive nonzeros : Ensemble nat := nonzero : forall n, In _ nonzeros (S n).], how does it translate into sigma-types? [Wed Apr 12 19:55:42 2017] also, what if you have several constructors? [Wed Apr 12 20:25:52 2017] Cypi: for future reference, im fine with "he" pronouns :) [Wed Apr 12 21:15:52 2017] benzrf, Cypi: Ah, cool! I knew I was missing something. Thanks. [Wed Apr 12 23:46:47 2017] bbaren: [digits] and [fun n => n < 10] both have type [nat -> Prop], and, under univalence or prop-extensionality+function-extensionality, are equal. Given an [Ensemble T], you can pass it to the partially-applied type constructor [@sig T], to make a type. So [sig] has type [forall T, Ensemble T -> Type]. However, it doesn't really make sense to talk about arrows the other way, I think? Certainly, you have a function [Type -> { T : Type & [Wed Apr 12 23:46:47 2017] Ensemble T }], namely, the identity on types and the always-true on ensembles, and it might be the case (though I'm not sure) that, under univalence, [{ T : Type & Ensemble T }] is isomorphic to [Type]. Does this give you more clarity? [Thu Apr 13 10:02:02 2017] jgross: Yep, that’s quite useful. Thanks. [Thu Apr 13 10:47:11 2017] hi guys! Anyone here attending OPLSS this year? [Thu Apr 13 11:59:56 2017] is there some way to make tactics local to the current proof? [Thu Apr 13 14:25:44 2017] cocreature: You can write [let my_tac := ... in ...]. [Thu Apr 13 14:26:12 2017] e.g., [Goal 3 = 3. let t := reflexivity in t. Qed.] [Thu Apr 13 15:39:53 2017] bbaren: ah nice, thanks! [Thu Apr 13 18:38:33 2017] can I ask Coq to simplify away transparent coercion function that I've marked as "Arguments /"? [Thu Apr 13 18:38:58 2017] in my case H = coerce F, but rewriting can't see through 'coerce', althugh simpl collapses this to H = H [Thu Apr 13 18:39:16 2017] I end up needed to pose my rewrite rules into the context, run simpl on all of them, and then they work [Fri Apr 14 06:28:33 2017] jstolarek pasted “No title” at http://lpaste.net/354578 [Fri Apr 14 06:28:51 2017] I'm struggling to prove this theorem. [Fri Apr 14 06:29:56 2017] It's an exercise from Verified Functional Algorithms, only 2-star difficulty so it should be simple and yet I am spending second day on this and just don't see a way forward [Fri Apr 14 06:30:24 2017] there's a hint in the exercise saying that it should require a single induction [Fri Apr 14 06:51:55 2017] jstolarek: make sure you're doing your induction on the right thing [Fri Apr 14 06:52:23 2017] the exercise is easy if you do the right induction, and (looks) very difficult otherwise [Fri Apr 14 06:53:13 2017] ah, got it! Indeed, I was doing induction on the wrong thing. [Fri Apr 14 06:53:32 2017] but I only realized that after finding a proof in Idris here: http://www.ben-sherman.net/posts/2014-09-20-quicksort-in-idris.html [Fri Apr 14 06:54:13 2017] I find that it's most of the time way better to do an induction on the inductive properties of the objects rather than the objects themselves [Fri Apr 14 06:54:27 2017] it gives more structure, and in this case, it even gives "for free" the relationships between your objects [Fri Apr 14 06:55:38 2017] Cypi: what do you mean by "inductive properties of the objects rather than objects themselves"? [Fri Apr 14 06:56:11 2017] as in: do induction on a property of a list rather than the list itself? [Fri Apr 14 06:56:15 2017] yes [Fri Apr 14 06:56:37 2017] It's not always better, but when what you want to prove relies on this property, it probably is [Fri Apr 14 07:01:13 2017] I have H : length (x :: y :: l) and I want to simplify it to H : S (length (y :: l)) [Fri Apr 14 07:01:19 2017] so just a single step of a reduction [Fri Apr 14 07:01:28 2017] how can I do that? [Fri Apr 14 07:01:44 2017] simpl in H. results in H : S (S (length l)) [Fri Apr 14 07:18:21 2017] jstolarek: you can do it very manually, using the "change" tactic :/ [Fri Apr 14 07:18:29 2017] but yeah, controlling reduction is difficult [Fri Apr 14 07:23:43 2017] Cypi: thanks. I realized I can also do it with "replace". Is there a difference between "change" and "replace"? [Fri Apr 14 07:39:38 2017] replace will do a rewriting (so it will change the proof term), whereas change asserts that your two terms are convertible [Fri Apr 14 07:41:40 2017] In other words, in my opinion, "change" is better (it's just another view of your current goal/context, and does not add anything to the proof term), but "replace" will work in more cases (sometimes you can prove that two terms are propositionally equal even if they are not definitionally equal) [Fri Apr 14 07:41:58 2017] if you don't care about the proof term, then it doesn't matter anyway :) [Sat Apr 15 14:12:26 2017] Hey everyone, apologies in advance if what I'm about to ask is something obvious. [Sat Apr 15 14:12:40 2017] I have the following in my stack: [Sat Apr 15 14:12:47 2017] P: nat -> Prop, Px: Px : forall x : nat, (forall y : nat, y < x -> P y) -> P x [Sat Apr 15 14:12:55 2017] and x: nat [Sat Apr 15 14:13:09 2017] And the goal left is P x. [Sat Apr 15 14:13:33 2017] A solution starts with this: move: {-2}x (leqnn x). [Sat Apr 15 14:14:09 2017] Can anyone explain how this works? I'm using the Mathematical Components library and I cannot figure out this pattern. [Sat Apr 15 14:37:17 2017] it's certainly not "obvious" ... ;) [Sat Apr 15 14:38:05 2017] but it's quite straight forward once you get familiar with the ssr tactic(al)s [Sat Apr 15 14:38:12 2017] so: [Sat Apr 15 14:39:11 2017] the : tactical discharges the rhs items right to left(!) and then calls the tactic to its left (i.e. "move" here, which basically does nothing). [Sat Apr 15 14:40:04 2017] thus, a more streamlined version of the above would be: move: (leqnn x). move: {-2}x. [Sat Apr 15 14:40:39 2017] the first move pushes the lemma 'leqnn' applied to 'x' onto the goal stack. [Sat Apr 15 14:41:32 2017] the second move generalizes the goal over the variable x, omitting the second occurrence (that's the work of the {-2}). [Sat Apr 15 14:41:36 2017] tyrokroketa: ^ [Sat Apr 15 14:44:10 2017] RegEchse: Ah, I was missing the right-to-left part, so I was going the wrong way "streamlining" it to understand it better [Sat Apr 15 14:44:15 2017] Thanks a lot! :) [Sat Apr 15 14:45:42 2017] you're welcome :) [Sun Apr 16 03:38:25 2017] can one prove that symmetry (symmetry f) = f? [Tue Apr 18 17:14:06 2017] yall are missing a huge xy problem [Tue Apr 18 17:14:12 2017] jeez [Tue Apr 18 17:14:21 2017] dont tell someone to use LEM when what they wanna prove is clearly constructively valid! [Tue Apr 18 18:15:39 2017] benzrf: if the proof is c/i and gets much shorter? [Tue Apr 18 18:43:36 2017] cocreature, are you trying to add H' to the context with that? [Tue Apr 18 18:43:41 2017] you could use pose/pose proof [Tue Apr 18 18:46:21 2017] cocreature, "assert (A := B)." = "pose proof (B) as A." [Tue Apr 18 19:16:41 2017] when I wanna do that I use lets from libtatics of software foundations. The full command becomes `lets ?H: H.` [Tue Apr 18 22:08:54 2017] When I use Coq via Spacemacs/company-coq/evil-mode and I exit insert mode, something is causing autocompletion to fire. For example if I type "intros s"ESC it replaces with "intros simpl" Any ideas how I might fix that or what I should be looking for? [Wed Apr 19 02:48:20 2017] rrika: thanks, pose is what I’m looking for. I was trying to duplicate a hypothesis that was already in my context because I wanted to apply two separate things to it (yes I know I can usually reorganize the proof to avoid that but it seemed like the simplest solution here) [Wed Apr 19 05:28:31 2017] jstolarek pasted “No title” at http://lpaste.net/354726 [Wed Apr 19 05:29:09 2017] how to use union_comm to rewrite (union (singleton y) (singleton x)) on the LHS? [Wed Apr 19 05:29:23 2017] I know I can use rewrite [Wed Apr 19 05:29:38 2017] sorry, replace, not rewrite [Wed Apr 19 05:30:22 2017] replace (union (singleton y) (singleton x)) with (union (singleton x) (singleton y)) by (apply union_comm). [Wed Apr 19 05:30:30 2017] but that is very verbose [Wed Apr 19 07:00:20 2017] jstolarek : "rewrite (union_comm (singleton y) (singleton x))" should work? [Wed Apr 19 07:00:52 2017] or "rewrite union_comm with (a := singleton y) (b := singleton x)" or anything similar (probably even just "rewrite (union_comm (singleton y))" [Wed Apr 19 10:34:53 2017] hey, has anyone here used Bedrock? [Wed Apr 19 10:35:07 2017] im trying to get it set up and i'm having a weird issue [Wed Apr 19 10:35:48 2017] i used the nixpkgs derivation - it built successfully, but when i try to do [Require Import Bedrock.], it says "Error: Cannot find library Bedrock.ILTac in loadpath" [Wed Apr 19 10:35:55 2017] and if i check the loadpath, it seems there's a .v but not a .vo [Wed Apr 19 18:37:13 2017] so what happens to known indices of a thing's type in a [return] clause of a [match] [Wed Apr 19 18:37:17 2017] that is to say [Wed Apr 19 18:37:28 2017] uh, let me make an example really quick [Wed Apr 19 18:37:50 2017] yeah, that would help :) [Wed Apr 19 18:38:43 2017] johnw: https://gist.github.com/a7ee7e8ac26bf9df2e5eb3c32963d808 [Wed Apr 19 18:39:43 2017] (im pretty sure the Goal isn't actually provable, but thats not my question exactly) [Wed Apr 19 18:40:21 2017] note that it says this: The term "e0" has type "a = a0" while it is expected to have type "a = a". [Wed Apr 19 18:40:34 2017] but the thing i'm matching on is known to have type [a = a] [Wed Apr 19 18:40:49 2017] it seems to have "generalized" the index (although not the parameter) [Wed Apr 19 18:41:30 2017] "e : a = a" has one two parameters (which are A and a) and an index (which is a). When you match on it, the return clause of the match is understood to be expressed under new binders for every index and one new binder for the term itself. So in this case, a fresh a0 is introduced, and a fresh e0 of type "@eq A a a0" [Wed Apr 19 18:41:40 2017] (that's two parameters, not "one two") [Wed Apr 19 18:43:01 2017] When you write some return clause "R", it actually requires that the term [fun (a0 : A) (e0 : @eq A a a0) => R] typechecks [Wed Apr 19 18:44:39 2017] (You can make all these fresh names appear by the way: refine (match e in _ = a0 as e0 return P e0 with eq_refl => _ end. ) [Wed Apr 19 18:44:54 2017] aww what [Wed Apr 19 18:45:00 2017] why does it work this way? [Wed Apr 19 18:45:25 2017] what does the [in] clause do btw [Wed Apr 19 18:45:42 2017] It does just that: binds the name of the indices so that you can use them in the return clause [Wed Apr 19 18:45:55 2017] o [Wed Apr 19 18:45:56 2017] I mean, it binds the indices to some names [Wed Apr 19 18:47:05 2017] btw, while i have ppl's attention [Wed Apr 19 18:47:14 2017] has anybody used bedrock? im having issues with its build [Wed Apr 19 18:47:16 2017] kinda [Wed Apr 19 18:48:21 2017] "why does it work this way?": well, if you wanted it to work otherwise, you would need e0 to have exactly the same type as e. So actually, e0 would be useless, you would just need e0. But then, what is e0 used for? When you want to automatically unify it with the constructors of the inductive types in the return type of the different branches of the match. [Wed Apr 19 18:49:20 2017] Then the follow-up question should be "why can't you do that directly with e?". The answer to this is that to do it, you need a theory that allows you to unify an arbitrary term ("e" in this case, but it could be more complicated) with some other arbitrary term (the constructor) [Wed Apr 19 18:49:50 2017] Coq doesn't have this. [Wed Apr 19 18:50:32 2017] um [Wed Apr 19 18:50:34 2017] hm [Wed Apr 19 18:50:59 2017] [it's a lot of "this" and "that", sorry for my poor English, hopefully I can explain anything that wasn't clear ^^' ] [Wed Apr 19 18:52:33 2017] is ^^ a french thing o= [Wed Apr 19 18:53:14 2017] It might be [Thu Apr 20 11:15:12 2017] is this provable? https://gist.github.com/d86ab6174fe0f4b3b91b710794f1edee [Thu Apr 20 17:39:15 2017] why on earth is this coq project taking an hour to compile a single file [Thu Apr 20 18:00:13 2017] I'm trying to use ltac to solve goals of this form (simplified example): `Last login: Sun Apr 9 11:07:10 on ttys004 [Thu Apr 20 18:00:31 2017] oh dear, that paste didn't go as expected [Thu Apr 20 18:01:10 2017] `Goal exists x : (nat * nat * nat), fst (fst x) = 1 /\ snd (fst x) = 2 /\ snd x = 3. [Thu Apr 20 18:02:29 2017] If I just `eexists; ...`, the automation machinery can't solve it, but if I `eexists ((_, _), _); intuition; auto`, then it can be simplified and solved [Thu Apr 20 18:02:46 2017] And so I'm trying to automate this -- the best I have currently is https://gist.github.com/anishathalye/5edecd0bb3cfef0f333d526e6d949672 [Thu Apr 20 18:03:07 2017] if this is totally insane and there's a better way of doing this, I'd appreciate some help/feedback [Thu Apr 20 18:04:53 2017] anishathalye: yeah, this is challenging to automate. I think what you've got is about as good as it gets. [Thu Apr 20 19:49:27 2017] anishathalye: for the record, another approach could be this one http://lpaste.net/354786 [Thu Apr 20 19:50:01 2017] not saying it's better, just different (also, I wish there was a better way of doing what I did in the [instantiate_pair] tactic, if anyone is aware of any trick...) [Thu Apr 20 20:09:50 2017] benzrf: isn't your [root_main] definition the wrong way around? Because currently it looks like your theorem is just false [Thu Apr 20 20:10:08 2017] for instance with [ [Thu Apr 20 20:10:10 2017] Definition my_p (c : conat) : bool := match c with cO => true | _ => false end.] [Thu Apr 20 20:10:36 2017] (but even with a fixed definition, I have no idea how to go about such a proof, I do not necessarily expect it to be provable) [Thu Apr 20 22:00:51 2017] Cypi: oh, that's pretty cool! In my actual use case (not the simple example), I can't match on e.g. `fst` [Thu Apr 20 22:01:39 2017] But I did take inspiration from your solution to make my ltac cleaner, so thanks for the help! [Thu Apr 20 22:48:47 2017] benzrf: about your conat stuff, you can try to take a look at http://lpaste.net/raw/354794 . I don't know how to use co-inductives really, so I don't know if it's any close to what someone else might have written. [Thu Apr 20 22:49:06 2017] There is one lemma which is Admitted because I'm tired, but it _should_ be provable. [Thu Apr 20 22:49:51 2017] And there are two axioms that I don't think you can prove (one of them looks quite classical, the other should hold only because your [p] is supposed to be constructive) [Thu Apr 20 22:51:20 2017] In any case, good luck. [Fri Apr 21 00:12:20 2017] Cypi: o heck i think i got it backawrds yeah [Fri Apr 21 23:32:07 2017] hey guys [Fri Apr 21 23:32:11 2017] allah is doing [Fri Apr 21 23:32:17 2017] sun is not doing allah is doing [Fri Apr 21 23:32:19 2017] to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [Fri Apr 21 23:55:38 2017] ????? [Fri Apr 21 23:59:09 2017] it keeps happening [Sat Apr 22 04:44:34 2017] is there a variant of Forall parametrized over (P : A -> Type) instead of (P : A -> Prop) somewhere in the standard library? [Sat Apr 22 11:17:13 2017] cocreature: for lists, you mean? [Sat Apr 22 11:17:37 2017] benzrf: yep [Sat Apr 22 11:18:05 2017] not personally sure, sorry [Sat Apr 22 11:19:06 2017] np, I just keep using my own version for now [Sat Apr 22 17:56:59 2017] cocreature: that construction is sometimes called an hlist, and it is not in the standard library, though many people have rolled their own. for example, see https://github.com/coq-ext-lib/coq-ext-lib/blob/v8.5/theories/Data/HList.v [Sat Apr 22 22:15:44 2017] cocreature: not everything has a constructive variant [Sat Apr 22 22:16:13 2017] some things do, though, like I just found out about crelations and how they fit into the rewriting system [Sun Apr 23 13:01:58 2017] Hello. I have a simple question about Coq. I have been searching Google for a while now, but I can't find the answer. [Sun Apr 23 13:02:31 2017] I have the goal a \/ b \/ c, and I have a lemma which of the form _ -> b \/ a [Sun Apr 23 13:02:41 2017] *which is of the form [Sun Apr 23 13:03:10 2017] I'm unable to get to this form by using just lefts and rights. [Sun Apr 23 13:03:51 2017] How can change my goal to b \/ a? [Sun Apr 23 13:07:06 2017] You could use the "or_assoc" and "or_comm" lemmas to get the form that you want (for instance, "apply or_assoc; left; apply or_comm") [Sun Apr 23 13:10:50 2017] Ah, thanks! [Sun Apr 23 18:02:32 2017] so, I'm trying to do this proof on a small-step operational semantics [Sun Apr 23 18:03:48 2017] Ptival: oh, haha, hi! I actually meant uwplse's slack channel #coq, but this works too :) [Sun Apr 23 18:03:58 2017] ah :p [Sun Apr 23 18:04:02 2017] didn't know about it [Sun Apr 23 18:04:38 2017] well, at some point I have some "Eval (Lam xs e) -> Eval (subst xs vs e)" [Sun Apr 23 18:05:00 2017] but my induction hypothesis only tells me something about "e", not about "subst ... e" [Sun Apr 23 18:05:21 2017] so I need an induction scheme that captures something about substitution [Sun Apr 23 18:06:00 2017] okay, that's what I figured. this is... kind of the whole ballgame in PL. [Sun Apr 23 18:06:14 2017] like, if this were easy, proving termination would be easy. [Sun Apr 23 18:07:06 2017] so is there a trick to deal with this? I seems to remember the problem being mentioned in some books but can't recall where and how to deal with it [Sun Apr 23 18:07:09 2017] :) [Sun Apr 23 18:07:17 2017] well it depends on your exact instance [Sun Apr 23 18:07:38 2017] in the general case, all the solutions I know of involve inducting on something else. eg, logical relations induct on types, or step-indexing methods induct on the index. [Sun Apr 23 18:07:59 2017] sometimes if you're only substituting things of known size, you can get around that. [Sun Apr 23 18:09:16 2017] ah yeah, well, my setting is untyped at the moment, and I don't think I can size the things I am substituting :( [Sun Apr 23 18:09:35 2017] Ptival: it might help to know a bit more about what exactly you're trying to do, if you can share. [Mon Apr 24 03:50:22 2017] Hi Everyone [Mon Apr 24 03:50:30 2017] https://gist.github.com/mukeshtiwari/884304d724fbc33d9f117b58b77092c9 [Mon Apr 24 03:51:22 2017] I have written partial_count_all_counted in proof mode, and now trying rewrite it using refine tactic. [Mon Apr 24 03:51:50 2017] When I am writing Fixpoint partial_count_all_counted : forall bs u inbs m, Count bs (partial (u, inbs) m) -> existsT i m, (Count bs (partial ([], i) m)). [Mon Apr 24 03:52:18 2017] It says It says Error: A fixpoint needs at least one parameter, so I changed it to [Mon Apr 24 03:52:32 2017] Fixpoint partial_count_all_counted bs : forall u inbs m, Count bs (partial (u, inbs) m) -> existsT i m, (Count bs (partial ([], i) m)). [Mon Apr 24 03:53:10 2017] According to my understanding, inside refine it should be [Mon Apr 24 03:53:58 2017] refine (fix u inbs m Hc := match u with match u with [Mon Apr 24 03:53:58 2017] | [] => existT _ inbs (existT _ m _) [Mon Apr 24 03:53:58 2017] | t :: ts => _ [Mon Apr 24 03:53:58 2017] end). [Mon Apr 24 03:57:27 2017] But this gives error [Mon Apr 24 03:58:16 2017] Sorry for complicated description of problem [Mon Apr 24 03:59:04 2017] I am just looking for one example to change proof mode program to change into refine mode. [Mon Apr 24 04:04:19 2017] keep_learning: you can print your lemma to see the proof term generated in proof mode and then plug that into refine [Mon Apr 24 04:07:16 2017] cocreature: https://gist.github.com/mukeshtiwari/884304d724fbc33d9f117b58b77092c9 [Mon Apr 24 04:07:51 2017] I have done that, but I am wondering about my what is wrong with my thinking [Mon Apr 24 04:09:07 2017] keep_learning: why did you change Lemma to Fixpoint? [Mon Apr 24 04:10:41 2017] cocreature: To get the induction principal like I am getting with list_rect, but it was just intuition and I am not sure if intuition is correct or not [Mon Apr 24 04:11:43 2017] I'm pretty sure that the parameter you are doing a recursion on should be in the parameters of the Fixpoint [Mon Apr 24 04:11:47 2017] (not 100% sure, but pretty sure) [Mon Apr 24 04:12:14 2017] ou can indicate the parameter you’re doing recursion on via the struct argument afaik [Mon Apr 24 04:12:18 2017] *you [Mon Apr 24 04:13:09 2017] keep_learning: it would be helpful if you could provide a self-contained example so I can load it into coq and play around with it [Mon Apr 24 04:14:32 2017] cocreature: https://github.com/mukeshtiwari/formalized-voting/tree/master/SchulzeCounting [Mon Apr 24 04:14:45 2017] all code is in this directory. [Mon Apr 24 04:15:13 2017] You can run coqc ListLemma.v [Mon Apr 24 04:16:35 2017] and partial_count_all_counted is in https://github.com/mukeshtiwari/formalized-voting/blob/master/SchulzeCounting/SchulzeSynthesis.v#L671 [Mon Apr 24 04:25:00 2017] keep_learning: I’m not sure I understand what exactly you are trying to do but maybe start like this? http://lpaste.net/354878 [Mon Apr 24 04:29:44 2017] cocreature: Thank you. I will think more to express the problem in more clear way. [Mon Apr 24 05:06:19 2017] cocreature: Thank you very much for your code. Now I understand and rewrote it https://github.com/mukeshtiwari/formalized-voting/blob/master/SchulzeCounting/SchulzeSynthesis.v#L690 [Tue Apr 25 10:29:19 2017] does anyone know how to print notation definitions in proof-general? [Tue Apr 25 10:31:33 2017] nevermind, found it [Tue Apr 25 12:58:19 2017] is there some tactic that generates subgoals for things that can’t be unified? e.g. I have the goal "tlist (a :: elements) = tlist (t :: elements1)" and I want the subgoals a = t and elements = elements1 [Tue Apr 25 14:08:46 2017] cocreature: may not be exactly what you're looking for but try the tactic "f_equal". [Tue Apr 25 14:56:09 2017] jrw: oh I didn’t know there was a tactic for that. I only knew about the lemma which only supports functions in one argument. thanks! [Tue Apr 25 15:24:13 2017] cocreature: Coq has lemmas `f_equal` up to `f_equal5` for functions from 1 to 5 arguments [Mon May 1 11:54:14 2017] _o/ [Mon May 1 11:55:02 2017] who can recommend me a library for working with binders? [Mon May 1 11:55:13 2017] extra points if you're not one of the authors [Mon May 1 11:55:25 2017] brownie points if you actually used it [Mon May 1 11:57:14 2017] noze: I’ve been quite happy with https://www.ps.uni-saarland.de/autosubst/ and I’m not the author :) [Mon May 1 12:22:27 2017] cheers, cocreature [Wed May 3 11:15:37 2017] is there anything much in the standard distribution for automating trivial steps in induction over inductive Props with a ton of constructors [Wed May 3 11:15:40 2017] to be precise - [Wed May 3 11:16:04 2017] i'm trying to work with a big inductive Prop for deduction in classical propositional logic [Wed May 3 11:16:19 2017] it has 12 constructors [Wed May 3 11:16:27 2017] when i do induction, theres usually only like 2 cases that are at all interesting [Wed May 3 11:17:03 2017] but just [constructor] is too stupid to figure out the right constructor, since technically the "assumption from the context" constructor can match almost anything [Wed May 3 11:47:22 2017] benzrf: here's a hacky trick I sometimes use: put the problematic constructor last. since the constructor tactic tries constructors in order, it will try everything else first. [Wed May 3 12:02:28 2017] benzrf: you could add the constructors to the hint database and then the `auto` machinery (or similar) might be able to easily dispatch your goals [Wed May 3 12:04:23 2017] e.g. https://pastebin.com/mnhvjgGA [Wed May 3 21:22:15 2017] Hi everyone. I am extracting a function m from proof https://github.com/mukeshtiwari/formalized-voting/blob/master/SchulzeCounting/SchulzeSynthesis.v#L792 [Wed May 3 21:22:49 2017] of type m : cand -> cand -> Z [Wed May 3 21:24:44 2017] This function is very computational intensive and I want to cache the result so that if this function is called at some other place with same parameter then it returns the cached value rather than computing again. [Wed May 3 21:26:10 2017] I think the exact word is functional memoization. [Wed May 3 21:26:11 2017] jrw: eek [Wed May 3 21:26:20 2017] anishathalye: intrestng thanks [Wed May 3 21:28:18 2017] I need some sort of F : (cand -> cand -> Z) -> (cand -> cand -> Z) such that F m is same type of function with cached behavior enabled. [Wed May 3 21:28:49 2017] Is it doable in Coq ? [Wed May 3 21:30:23 2017] keep_learning: wouldn't that necessarily involve either side effects or changes to the implementation? [Wed May 3 21:33:39 2017] benzrf: I can not change the implementation of m because it is handed to me by Coq https://github.com/mukeshtiwari/formalized-voting/blob/master/SchulzeCounting/SchulzeSynthesis.v#L645 [Wed May 3 21:33:53 2017] i mean changes to the implementation of the evaluator [Wed May 3 21:35:49 2017] benzrf: Yeah, I extracted OCaml code and tried with memoization but I am looking for a way to do this in Coq [Wed May 3 21:36:44 2017] so rather than changing code in OCaml, it should be extracted from Coq [Wed May 3 21:42:22 2017] benzrf: why not just write a wrapper function in OCaml that just implements memoization but calls the function extracted from Coq for evaluation? [Wed May 3 21:42:44 2017] or do you have other extracted code calling that function or something? [Wed May 3 21:43:31 2017] anishathalye: Second case. Extracted code calling m [Wed May 3 21:44:57 2017] All I have is ballots and I am extracting m after counting ballots. [Thu May 4 08:44:56 2017] Hi everyone, this is for people using mathcomp: [Thu May 4 08:45:21 2017] is there a way to show that, given a column vector b, (row i b) is equivalent to (b i 0) ? [Thu May 4 08:51:20 2017] tyrokroketa: many years since I did any mathcomp now, but maybe using colP could work? [Thu May 4 08:51:36 2017] or rowP [Thu May 4 12:22:36 2017] mortberg_: Thanks, I ended up casting to scalar matrices and using congr1 [Thu May 4 12:29:28 2017] Another question: I have a hypothesis stating that [forall i0: 'I_m, P i0], and my goal is P i. Is there a view for this? [Thu May 4 12:36:02 2017] forallP maybe? [Thu May 4 12:38:36 2017] mortberg_: Thanks! :) [Thu May 4 12:40:07 2017] they have very good naming conventions so you can usually guess that you need a view for "thing" the lemma is probably called "thingP" [Thu May 4 16:58:49 2017] is compactness of the cantor set computationally valid [Thu May 4 16:58:57 2017] or does that depend on your choices of definition [Thu May 4 17:00:36 2017] does anyone have experience writing code intended to be extracted to machine words in a safe-ish way? [Thu May 4 17:01:06 2017] in other words, I don't want to just extract nat -> machine int or whatever, since that's not even sound in principle. [Thu May 4 17:01:20 2017] but I don't want to work with big ints. what do I do at the coq level? [Thu May 4 17:01:32 2017] ...bedrock, maybe? :> [Thu May 4 17:02:05 2017] yeah, it would be fast :) seems like overkill though. I just want to generate some ocaml or haskell code that uses machine ints instead of big ints. [Thu May 4 17:02:52 2017] johnw: I feel like you might have some insight about this? [Thu May 4 18:22:39 2017] jrw: hi [Thu May 4 18:22:45 2017] hi! [Thu May 4 18:23:21 2017] I was looking through your coq-haskell repo and didn't see anything about machine ints. do you have a preferred approach to that? [Thu May 4 18:23:28 2017] at the coq level you can work with bounded binary-encoded integers [Thu May 4 18:23:42 2017] right, a la compcert ints [Thu May 4 18:23:45 2017] I use Fiat to refine my nat or N specified programs to 32-bit or 64-bit bounded words [Thu May 4 18:24:09 2017] or, I just extract to a bounded word and hope for the best sometimes [Thu May 4 18:24:12 2017] :D [Thu May 4 18:24:24 2017] I generally prefer N, or in some cases Z [Thu May 4 18:24:32 2017] it allows for efficient large constant [Thu May 4 18:24:41 2017] what does the fiat refinement step usually look like? [Thu May 4 18:25:32 2017] the abstraction relation would be: nat -> Word32 -> Prop, saying something like every Word32 chosen is representable in nat [Thu May 4 18:25:48 2017] then, in the refinement script, you have to decide what the answer becomes when the bounds are exceeded for any particular value [Thu May 4 18:26:13 2017] so, your specification may need to parameterize the return type, so that you can downgrade to "option Word32" [Thu May 4 18:26:18 2017] let me show an example [Thu May 4 18:26:24 2017] ok that'd be great, thanks [Thu May 4 18:32:26 2017] https://gist.github.com/1cbcd5c4582ad24888a49b6f4f10c6a0 [Thu May 4 18:32:38 2017] this uses module functors to abstract the target numerical type [Thu May 4 18:33:04 2017] how you specify to_nat and from_nat is the key [Thu May 4 18:33:15 2017] I give an example for bounded 31-bit integers [Thu May 4 18:33:47 2017] this example also shows the use of QuickChick to do QuickCheck-style testing, since I had trouble with the proofs and ran out of time :) [Thu May 4 18:34:14 2017] which is why from_to_nat is not a proof, just a QuickChick test [Thu May 4 18:34:22 2017] but it certainly should be provable [Thu May 4 18:35:13 2017] another way to specify the idea: [Thu May 4 18:35:14 2017] https://gist.github.com/ae333c61da1f3ed8926da5f5264a3a67 [Thu May 4 18:35:21 2017] this enriches the functor to talk about bounds explicitly [Thu May 4 18:35:26 2017] simplifies the refinement work [Thu May 4 18:35:34 2017] thanks! looking... [Thu May 4 18:39:55 2017] have you ever tried to extract from the Cyclic library directly? [Thu May 4 18:44:07 2017] no [Thu May 4 18:44:15 2017] but shouldn't be hard to make the mappings [Thu May 4 18:44:21 2017] I have lots of mapping from nat, Z and N to work with [Thu May 4 18:44:47 2017] e.g., https://github.com/jwiegley/bytestring-fiat/blob/master/extract/ByteStringExt.v#L99 [Thu May 4 18:45:30 2017] gotta run now [Thu May 4 18:46:12 2017] thanks! [Fri May 5 11:27:44 2017] Suppose I have a goal in the form a && b, but I need a to prove b [Fri May 5 11:28:15 2017] Is there a tactic/pattern to store it as a hypothesis after proving it? [Fri May 5 11:35:49 2017] assert (A := a), and then you can use it as many times you want. but there might be some prettier way of doing it. [Fri May 5 11:52:49 2017] cic: After I prove a, A dissapears [Fri May 5 12:00:05 2017] Ah, nevermind, I had to do it before the split. Thanks! [Sun May 7 16:53:47 2017] how can i express "pair of two numbers; second is smaller than first" in coq? [Sun May 7 16:56:04 2017] where number = natural number [Sun May 7 17:15:00 2017] mjacob: http://lpaste.net/355302 [Sun May 7 17:15:05 2017] Something like that perhaps? [Sun May 7 17:15:18 2017] oh, you wanted second smaller than first [Sun May 7 17:15:49 2017] Feel free to adjust the definition :) [Sun May 7 17:25:13 2017] Cale: it turns out that i need something more like "natural numbers from 0 to n (exclusive)" [Sun May 7 17:25:37 2017] Cale: the Fin type is almost what i need, except that it goes from 1 to n inclusive [Sun May 7 17:39:07 2017] mjacob: Well, that's little more than a relabelling of the constructors. [Sun May 7 17:43:37 2017] Cale: yes, i'll try that, hoping that i won't need to duplicate most of the rest of the module as well [Sun May 7 17:44:43 2017] thank you [Sun May 7 17:53:17 2017] mjacob: despite what they say at the top of the module, you'll notice that "to_nat F1" returns 0 (and some proof) [Sun May 7 17:53:37 2017] so it does not really represent 1 to n or 0 to n, it does not really matter what the constructors are labelled [Sun May 7 18:16:21 2017] Cypi: ah, good to know (although it is rather unintuitive) [Mon May 8 11:05:41 2017] Heelo, is anyone there to help with a quick question? [Mon May 8 11:06:07 2017] give it a shot [Mon May 8 11:06:25 2017] oops, sorry, house on fire must attend to that first [Mon May 8 11:06:26 2017] bye [Wed May 10 07:44:37 2017] is there any way to avoid having a large number of empty cases in the intro_pattern of inversion when I know that only one case is possible? [Wed May 10 17:55:26 2017] hi folks, I've been googling everywhere but I can't find an answer to this. From H:0 = 1, how can I conclude False? [Wed May 10 17:57:21 2017] found it - "discriminate" [Wed May 10 18:24:37 2017] yep :) [Wed May 10 19:25:18 2017] apparently Arguments support multiple argument specifications, but this doesn't seem to be documented anywhere? [Thu May 11 00:35:25 2017] what (if any) are the current upstream plans regarding the string library? [Thu May 11 01:17:27 2017] I haven't heard anything [Thu May 11 01:25:12 2017] I have been preparing a pile of StringFacts to send upstream :-) [Thu May 11 01:55:05 2017] :) [Thu May 11 01:55:08 2017] it's needed [Thu May 11 01:55:16 2017] get us really good extraction to Haskell while you're doing it [Thu May 11 01:55:25 2017] and better pattern matching on string constants if you can [Thu May 11 03:38:54 2017] haskell and I don't really get along any more [Thu May 11 03:39:27 2017] but having an equivalence between strings and lists of chars would probably help that [Thu May 11 03:51:50 2017] yes, right now they're lists of lists of booleans, which is painful in the extreme [Thu May 11 04:24:59 2017] I have a thing that makes them into pairs of pairs of pairs of booleans, which is a lot less painful [Thu May 11 04:25:13 2017] or rather, that makes such things and constructs some equivalences [Thu May 11 04:25:45 2017] but they aren't lists, they're their own inductive that's isomorphic to lists [Thu May 11 04:26:00 2017] so you can't use any of the list lemmas. [Thu May 11 10:24:36 2017] Hey, I have a set defined as S := [set i : T | P i], where T is a finType, but cannot find any lemma stating that S \subset T [Thu May 11 10:24:58 2017] I'm using mathcomp library, btw [Thu May 11 12:44:01 2017] nevermind, subset_predT did the trick [Thu May 11 20:11:32 2017] Hey there. [Thu May 11 20:12:31 2017] Just downloadin' Coq. Not sure what I'll end up doing with it. [Thu May 11 20:15:07 2017] hi [Thu May 11 20:21:39 2017] Hey there. [Thu May 11 20:21:52 2017] I could... try to implement the entirety of homotopy type theory in it? :D [Thu May 11 20:26:19 2017] banseljaj: oh hi! [Thu May 11 20:26:38 2017] Dang, I was so eager to get home and play with Coq, and now I don't even know what I want to do with it. [Thu May 11 20:28:30 2017] I guess I'll start by defining categories. That's always a good start. [Thu May 11 20:29:22 2017] Come to think of it, I'm gonna set a goal... let's go with proving the fundamental theorem of arithmetic. [Thu May 11 20:29:45 2017] Stated as... [Thu May 11 20:30:06 2017] "The multiplicative monoid of the positive integers is a free commutative monoid." [Thu May 11 21:04:35 2017] Warrigal: should be pretty achievable [Thu May 11 21:04:43 2017] i'm doing CT in Coq too [Fri May 12 00:45:17 2017] hi Warrigal [Sun May 14 11:27:11 2017] is there a standard mechanism for stating equivalence between data types? [Tue May 16 09:58:06 2017] hi, what does coq add that allows it to prove theorems? dependent types? [Tue May 16 10:00:12 2017] compared to other languages like haskell [Tue May 16 10:51:48 2017] BernhardPosselt: yes, dependent types and strong normalisation [Tue May 16 10:53:00 2017] notnotdan: ty :) [Tue May 16 11:55:54 2017] hey guys [Tue May 16 11:55:56 2017] allah is doing [Tue May 16 11:56:01 2017] sun is not doing allah is doing [Tue May 16 11:56:04 2017] to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [Tue May 16 11:57:12 2017] proof script or gtfo. [Tue May 16 11:59:13 2017] they're still going [Tue May 16 11:59:20 2017] amazing [Tue May 16 12:00:36 2017] i expect it's automated. [Tue May 16 15:41:12 2017] hey all, does anyone know of a general english language introduction to the coqide that comes with the installation on Unix? [Tue May 16 15:53:36 2017] .....bueller? [Tue May 16 16:24:18 2017] does anybody know how to use it and maybe answer a couple of questions? [Tue May 16 16:33:48 2017] modulus: hey, at least we have proof God exists with Coq! [Tue May 16 16:33:57 2017] okay not *reeeeaaalllly* [Tue May 16 16:34:05 2017] but it was still a pretty monumental undertaking [Tue May 16 21:47:59 2017] nobody seems to talk in here :( [Tue May 16 22:30:01 2017] dh`: lots of lurkers :) [Wed May 17 08:20:12 2017] Hello again everyone [Wed May 17 08:20:54 2017] Is it possible to create a coq toplevel with a set of automatic imports (from compiled Coq files containing theorems,defs etc.) using coqmktop? [Wed May 17 08:26:37 2017] I know you can build a wrapper script that invokes coqtop -load-vernac-source (or -require [path]), but I was just curious [Fri May 19 07:17:08 2017] Is there an equivalent (automated or some step-by-step process) to "cabal init" for starting a new coq project? [Fri May 19 09:44:22 2017] In emacs/PG, how do I make "Require ImportFoo" just indent Foo 2 spaces instead of 8? [Fri May 19 09:44:36 2017] I've searched through the mode customization and can't see where the 8 is coming from [Fri May 19 10:56:35 2017] Is there any way to check whether a goal (or some other term) has a certain variable free? [Fri May 19 10:56:40 2017] Using Ltac that is [Fri May 19 10:57:09 2017] I expect ordinary patterns would do that [Fri May 19 10:57:23 2017] well, making sure that it's free might be annoying [Fri May 19 11:01:26 2017] dh`: how one would do that with ordinary patterns? [Fri May 19 11:02:29 2017] Currently I am using a quite ugly semi-solution which does `generalize dependent x; match goal with | [ |- _ -> ?P ] => ... | [ |- forall x, P ] => ... end; intro x' [Fri May 19 11:02:33 2017] which only works with the goal [Fri May 19 20:59:29 2017] Hey folks. I've been struggling for a while with what seems to be really easy. My goal contains a subterm that is a fix, and I'd like to unrwap it by one step. [Fri May 19 20:59:33 2017] Here's a minimalish example: https://pastebin.com/ft07g0v3 [Fri May 19 20:59:59 2017] Oh, crap, sorry. [Fri May 19 21:00:10 2017] I'll correct it, then paste the correct one. [Fri May 19 21:02:19 2017] Well, okay, the theorem listed there is false, because I got the argument order wrong, but it doesn't really matter. The gist is the same -- I need to unwrap the term (fix f ...) so that it contains the (fix f ...) in place of f. [Mon May 22 21:51:28 2017] Is there a way to teach the coq flycheck checker to use the _CoqProject file? [Mon May 22 21:52:23 2017] johnw: ^ [Tue May 23 09:31:26 2017] Hi, I am total beginner and am completely lost in tutorials, but how would one prove in coq "forall i : Z. exists j : Z. i < j"? I thought I would unify j with i+1 and invoke lt_succ_r, but how, my assistant hates me and refuses to cooperate :) [Tue May 23 09:37:27 2017] jakub_: "intro. eexists. eapply lt_succ_r." might work [Tue May 23 09:38:49 2017] Saizan: thanks, coq: attempting to save an incomplete proof [Tue May 23 09:40:54 2017] I couldn't even spot these tactics among all the rest, at least now it makes a bit of sense, although I have no idea what is missing in that proof [Tue May 23 09:41:12 2017] jakub_: ok, sorry, maybe you have to be more specific, something like "intro i. exists (i+1). ..." [Tue May 23 09:42:09 2017] jakub_: another way might be "intro i. eexists. eapply (lt_succ_r i)." [Tue May 23 09:43:00 2017] is there a way to learn what exactly is missing? because none of the above worked [Tue May 23 09:43:11 2017] hah [Tue May 23 09:43:44 2017] i guess with Show Proof. you might get some info [Tue May 23 09:44:46 2017] the "e.." tactics make it so you can leave arguments unspecified until later [Tue May 23 09:46:22 2017] the coq reference-manual could use some examples [Tue May 23 09:47:05 2017] do I write "Show Proof." instead of "Proof." ? because if so, then it printed the veru useful line "?Goal" in blue and that's it :) [Tue May 23 09:47:14 2017] *very [Tue May 23 09:48:31 2017] no, your leave Proof. there [Tue May 23 09:48:45 2017] you can use Show Proof. in the middle of it to see the proof term generated so far [Tue May 23 09:49:31 2017] jakub_: well, the reference manual is not meant to be a tutorial i guess [Tue May 23 09:50:26 2017] http://covariant.me/stuff/coq/cheatsheet.pdf <- this is quite helpful though [Tue May 23 09:51:31 2017] thanks [Tue May 23 10:35:20 2017] http://lpaste.net/355769 What makes O the number 0? I really cannot wrap my head around this. [Tue May 23 10:36:51 2017] Please someone guide me in this [Tue May 23 10:44:21 2017] Nk_: what do you mean? [Tue May 23 10:44:52 2017] 0 is a notation for O, if that's what you mean. Or do you mean, in a more "philosophical" way, why is the constructor O the same as what we usually call 0? [Tue May 23 10:45:25 2017] Not in philosophical way [Tue May 23 10:46:24 2017] In the book Software foundations it says it does not matter whether we write O or tick or any variable. [Tue May 23 10:46:52 2017] I cannot understand if O represent natural number then how come it becomes only 0? [Tue May 23 10:48:47 2017] I don't understand "it becomes only 0". Do you mean, how come that when we speak about O, then Coq prints 0? [Tue May 23 10:49:07 2017] jakub_: if it helps, the following works in 8.6 http://lpaste.net/355770 [Tue May 23 10:49:37 2017] (the %Z are there to make sure the symbols < and + are interpreted properly (otherwise Coq expect them to talk about nat, not Z)) [Tue May 23 10:50:42 2017] Cypi: Yes exactly [Tue May 23 10:53:44 2017] Then it's just a matter of printing and notations. Somewhere in Coq, it knows that when it has to print O or (S (S ... (S O) ...)), it has to replace it with 0 or the natural number it correponds to [Tue May 23 10:55:15 2017] If you are using CoqIDE, you can uncheck "Display notations" in the "View" menu to see the actual terms. Without CoqIDE, you can use the "Unset Printing Notations." to get the same result. [Tue May 23 10:55:17 2017] oh ok [Tue May 23 10:55:46 2017] So 0 is not an actual term, it is just a notation, which might be translated to O (and vice-versa) [Tue May 23 10:56:45 2017] thank you [Tue May 23 11:04:14 2017] Cypi: thank you so much, it works with lt_succ_r too, the missing piece seems to have been reflexivity... I still don't quite see why [Tue May 23 11:08:33 2017] In my proof, what you need to prove at the end is (0 < 1)%Z [Tue May 23 11:09:20 2017] The way < is defined on Z is that "x < y" is the same as "(x ?= y) = Lt", where "x ?= y" is some function that compares x and y [Tue May 23 11:09:44 2017] so in the case where we compare 0 and 1, this function returns Lt, therefore what we have to prove is the same as proving "Lt = Lt" [Tue May 23 11:09:49 2017] which is done through reflexivity [Tue May 23 20:47:42 2017] So I'm thinking about theory here... [Tue May 23 20:48:11 2017] Coq has this thing called the "universe", I suppose. The axioms of the universe happen to be a conservative extension of the axioms of a category. [Tue May 23 20:48:51 2017] If I declare some types (representing objects) and functions (representing arrows), I will end up with all of the functions generated by the axioms of a category, but no additional functions. [Tue May 23 20:49:48 2017] Now, there are various axioms I can add that extend the universe in various interesting ways, like... [Tue May 23 20:50:08 2017] Axiom peirce : forall a b : Set, ((a -> b) -> a) -> a. [Tue May 23 20:50:51 2017] So my question is, then... [Tue May 23 20:51:02 2017] I don't suppose there's a way to have *multiple different* "universes" like this? [Tue May 23 20:51:35 2017] Maybe I want two different versions of Set, one where Peirce's law holds and one where it does not. [Tue May 23 20:56:46 2017] I'd like to be able to do something like... [Tue May 23 20:56:54 2017] Axiom MyUniverse : Universe. [Tue May 23 20:56:54 2017] Axiom peirce : forall a b : MyUniverse, ((a -> b) -> a) -> a. [Tue May 23 20:57:06 2017] Of course, there's no such type as "Universe". [Tue May 23 20:58:31 2017] I should probably stop using the word "universe", since Coq uses that word to mean something else. [Tue May 23 21:01:20 2017] Maybe I'll call it a "world". A "world" is a type which other types can be values of, and which supports all the usual primitives for constructing types. [Tue May 23 21:02:04 2017] Coq gives you three worlds: Set, Prop, and Type. It seems like Coq does not give you any way to create more worlds. [Tue May 23 21:02:06 2017] Right? [Tue May 23 21:04:26 2017] Looks like the correct word in Coq is actually "sort". [Tue May 23 21:38:17 2017] Then again... [Tue May 23 21:39:05 2017] Universe M. Definition MySort := Type@{M}. Opaque MySort. [Tue May 23 21:39:51 2017] Now MySort acts a lot like a sort like Set and Prop. [Wed May 24 03:26:02 2017] you can generate arbitrarily many more layers of Prop, but I don't think that's what you want [Wed May 24 03:47:24 2017] how could I state a forall-introduction rule in coq? (something that takes a formula phi over some term t and produces an equivalent formula (forall x. x = t -> phi') where phi' is phi[x/t] [Wed May 24 08:12:41 2017] I just started learning Coq. I want to know why do we need a programming language to prove Theorems? Is Coq only for mathematical people or does it have a use in software industry [Wed May 24 08:27:44 2017] Coqnoob: Well, while writing practical software in Coq still requires heroic levels of effort (it is possible though, see CompCert for an example of a nontrivial project), the idea of being able to prove theorems expressed by types should be of general interest to software developers [Wed May 24 08:28:04 2017] it's primarily for maths but it has use for software too, because programs and proofs are equivalent. it can be used to prove correctness of programs, extract programs that are correct by construction etc. [Wed May 24 08:28:12 2017] We like to know that our programs actually compute the things they're supposed to compute [Wed May 24 08:30:51 2017] Somewhat similar to Software testing? [Wed May 24 08:31:15 2017] Except better, because you can know that some property holds for all possible inputs. [Wed May 24 08:31:20 2017] a step up from testing. [Wed May 24 08:35:37 2017] ok got you. Also need to dive deeper in Coq to get the obscurity out of my mind. [Wed May 24 08:36:53 2017] Coqnoob: It's also more than just equational properties, for example, it's possible to have so-called "session types" which express a network protocol, and only programs which follow the protocol will typecheck. [Wed May 24 08:43:30 2017] hmm i see. I also started learning haskell and type theory intrigued me to learn Coq too but man I find Coq tough than Haskell. [Wed May 24 08:52:57 2017] Coqnoob: it is, dw [Wed May 24 09:03:49 2017] Hey everyone [Wed May 24 09:04:13 2017] is there some easy way to "prove" a forall over an empty set? [Wed May 24 09:04:45 2017] Prove that the set is empty [Wed May 24 09:04:46 2017] I am using mathcomp and have to prove something like "forall i: 'I_m, P i", but m = 0 in a certain case [Wed May 24 09:04:48 2017] tyrokroketa: what kind of empty set [Wed May 24 09:05:26 2017] tyrokroketa: the emptiness of the set is demonstrated by deriving a contradiction from having an element of it, so you're really asking a circular question :p [Wed May 24 09:05:30 2017] "forall (t : Empty_set), 0 = 1" would be proved by "intros H; inversion H" for instance, but it depends on your specific case [Wed May 24 09:05:40 2017] if you meant "empty" in the sense of "inductive type with 0 constructors", that would be inversion, but [Wed May 24 09:44:49 2017] In nat type definition I understand that S :nat ->nat take a number and return a number , but how does it returns a next number? [Wed May 24 09:45:25 2017] O is 0 how does S gives 1? [Wed May 24 09:55:28 2017] 'S' is short for 'successor'. So 'S O' means 'the successor of O', or 'the number after 0'. [Wed May 24 10:02:01 2017] Igloo: So S is not just a variable that can be replaced by anything if I want to implement nat type myself [Wed May 24 10:02:03 2017] tot: 1 is just notation [Wed May 24 10:02:29 2017] tot: when you write something like "3", coq expands it to "S (S (S O))" before almost anything else, as i understand it [Wed May 24 10:02:33 2017] it's just syntactic sugar [Wed May 24 10:02:46 2017] then it does the reverse when printing [Wed May 24 10:03:08 2017] but nats in coq ARE literally just the inductive type with S and O - digits are purely an interface thing [Wed May 24 10:03:27 2017] it's like how in haskell or ml, [1, 2, 3] is just short for 1:2:3:[] [Wed May 24 10:05:26 2017] ok so O means 0 in Coq and S O is 1 . This is how it was implemented internally in Coq? [Wed May 24 10:05:59 2017] no, it's the other way around [Wed May 24 10:05:59 2017] 0 means O [Wed May 24 10:06:36 2017] think how in C, you can write 'a' for 0x61 [Wed May 24 10:06:46 2017] but really, that's just syntax, it's still a byte either way [Wed May 24 10:07:02 2017] in coq, you can write 3 for S (S (S O)), but it's still the latter either way [Wed May 24 10:07:03 2017] oh ok [Wed May 24 10:07:20 2017] it's just a bit more confusing because coq prints out S (S (S O)) as "3" for convenience [Wed May 24 10:07:28 2017] but if you run "Unset Printing Notations." you can see what's really going on [Wed May 24 10:08:05 2017] ok thank you very much [Wed May 24 10:08:08 2017] np :) [Wed May 24 10:08:17 2017] tot: https://i.imgur.com/7uZiT7O.png [Wed May 24 10:49:46 2017] I want to make a function that checks if two numbers are equal or not . I thought if n-m =0 then they are equal so i wrote this http://lpaste.net/355816 but it give error "Cannot guess decreasing argument of fix." [Wed May 24 10:50:26 2017] Can I do something that use minus function to check equality? [Wed May 24 11:09:22 2017] Please someone take a look at my code. [Wed May 24 11:16:28 2017] are you using nat or z? [Wed May 24 11:18:49 2017] also, remember that in coq every function has to be guaranteed to terminate [Thu May 25 14:09:46 2017] I am very new to Coq and kinda just stumbled upon the language. I don't know exactly when and why to use this language but it seems interesting to me. So when do you guys think learning Coq is essential and benefit someone [Thu May 25 14:24:36 2017] anyone? [Thu May 25 14:30:49 2017] coq is an interactive theorem prover [Thu May 25 14:31:17 2017] mostly used for verifying computer programs, or formalizing mathematics [Thu May 25 14:31:55 2017] or writing certified programs [Thu May 25 16:55:19 2017] Is there some setting in my _CoqProject or coq_makefile to have docs built and installed with make? [Thu May 25 16:55:27 2017] Or add a "doc" make target at least? [Thu May 25 17:32:40 2017] hi shlevy! [Thu May 25 17:32:47 2017] you can use coq-doc [Thu May 25 18:06:00 2017] johnw: Hey! [Thu May 25 18:06:11 2017] johnw: I was trying to figure out the Right Way to incorporate it into my makefile [Thu May 25 18:11:20 2017] The One True Way [Thu May 25 18:17:13 2017] johnw: Is there a way in a Makefile that includes my _CoqProject Makefile to easily get all of the coq files and build the HTML or LaTeX for them and install them? [Thu May 25 18:18:02 2017] what are you expecting to see? [Thu May 25 18:18:04 2017] the source code? [Thu May 25 18:18:24 2017] The stuff generated with coqdoc [Thu May 25 18:18:33 2017] I'm adding coqdoc comments and all that [Thu May 25 18:19:00 2017] looks like coq-makefile creates an "html" target in the resulting makefile [Thu May 25 18:19:07 2017] Ah! [Thu May 25 18:19:10 2017] Awesome :D [Thu May 25 18:19:12 2017] Thank you [Thu May 25 21:07:58 2017] Hey, I'm wondering if I can write out a universe constraint explicitly. What I want to write is... [Thu May 25 21:08:28 2017] Definition Space := Type@{B}, where B is any universe greater than or equal to the global universe A. [Thu May 25 21:45:14 2017] Hmm. I wanted to write this record: [Thu May 25 21:46:02 2017] Record Unique (A : Space) := {unique_value :> A; unique_uniqueness : forall x : A, x = unique_value}. [Thu May 25 21:46:31 2017] But it looks like defining :> as a coercion is not allowed because A doesn't have a constant at the head. [Thu May 25 21:46:52 2017] Is that right? [Fri May 26 06:30:23 2017] tswe_tt: https://coq.inria.fr/refman/Reference-Manual032.html#hevea_default1067 Have you seen this? [Fri May 26 10:40:59 2017] tswe_tt: another trick that I use is "Space := (Type : Type)" [Fri May 26 10:41:07 2017] ensure you get a larger type than the "global Type" [Fri May 26 10:41:14 2017] or rather, smaller [Fri May 26 21:05:06 2017] shlevy: have I seen the Universe command? Yeah, that's how I got the global universe A in the first place. [Fri May 26 21:07:43 2017] Note that I'm using Set Universe Polymorphism. [Fri May 26 21:08:48 2017] Fwiw, I'm using a couple of "rules of thumb" in the stuff I'm writing... [Fri May 26 21:10:28 2017] Never use the tactic proof system; and make almost everything opaque. [Fri May 26 21:19:48 2017] By the way, is it possible to rearrange the panes in CoqIde? I'd like to have the editor take up the entire left half of the screen, while the Messages tab and the query pane are stacked vertically on the right half. [Fri May 26 21:42:47 2017] thats what it looks like for me :D [Fri May 26 21:52:53 2017] benzrf: whelp... how do I get it that way? [Fri May 26 21:53:19 2017] dunno [Fri May 26 21:53:23 2017] thats how it shipped for me i think [Fri May 26 21:53:25 2017] unsure [Fri May 26 22:16:16 2017] You know, it's a pretty remarkable coincidence that the capital letters pi and sigma, which can be used to denote dependent products and sums, resemble the letters A and E, for "all" and "exists". [Fri May 26 22:39:26 2017] I would like to have the following haskell typeclass in coq, but I can't figure out the syntax: [Fri May 26 22:39:27 2017] class Expr t where [Fri May 26 22:39:28 2017] step :: (Expr t' => t -> t') [Fri May 26 22:42:44 2017] dh`: I don't think that's supported by Coq, if I understand correctly. [Fri May 26 22:43:15 2017] That's an interesting one. [Fri May 26 22:43:24 2017] What I want to say is... [Fri May 26 22:43:54 2017] it's supposed to return a value of a potentially (but not necessarily) different type that's also an expression [Fri May 26 22:44:14 2017] (why do I have different types of expressions? because I'm doing something marginally crazy for other reasons) [Fri May 26 22:44:32 2017] Record Expr (t : Type) := { step : forall t' : Type, Expr t' -> t -> t' }. [Fri May 26 22:44:41 2017] Pretty sure Coq won't allow that because it's recursive. [Fri May 26 22:45:03 2017] yeah [Fri May 26 22:45:33 2017] dh`: so when I'm implementing Expr t, do I have to implement step for all possible t' or just one? [Fri May 26 22:45:43 2017] only one. [Fri May 26 22:46:01 2017] In that case, replace "forall" with "exists" in my record type. [Fri May 26 22:46:04 2017] It's still recursive, of course. [Fri May 26 22:46:09 2017] right [Fri May 26 22:46:52 2017] amusingly(?) if you try to write it as a Class it tells you "Records declared with the keywords Record or Structure cannot be recursive," and you have to know that classes are magic records [Fri May 26 22:47:11 2017] although that message points out that you can have recursive records with Inductive [Fri May 26 22:48:40 2017] Hmm, I feel like I know what here... [Fri May 26 22:48:42 2017] it gives "the term Expr t' -> t -> t'" has type Type while it is expected to have type Prop [Fri May 26 22:48:57 2017] er, wrong quotes, but anyway [Fri May 26 22:49:15 2017] I think I already tried that. :-/ [Fri May 26 22:50:13 2017] forall doesn't do that, but with forall and Inductive it complains about a non-strictly-positive occurrence of Expr [Fri May 26 22:51:16 2017] Inductive Expr : Type -> Type := step_to_Expr : forall (t t' : Type), Expr t' -> (t -> t') -> Expr t. [Fri May 26 22:51:18 2017] the conclusion I came to yesterday was that it wasn't going to work, but I was hoping just that I haven't tried all the possible syntaxes yet [Fri May 26 22:54:00 2017] So the good news is, I think that's exactly what you asked for (save for the fact that it's not a typeclass)? [Fri May 26 22:54:17 2017] The bad news is, there's no way to ever get an Expr. [Fri May 26 22:54:27 2017] heh [Fri May 26 22:55:32 2017] it's not really what I want because it allows any function to become a step [Fri May 26 23:02:25 2017] e.g. if I use nat as the type for constant expressions, then e.g. 2 steps to 3 using that and S [Fri May 26 23:02:31 2017] which is not really what one wants [Fri May 26 23:06:17 2017] one could stop that by introducing a class on t -> t' functions, I guess [Fri May 26 23:07:50 2017] but there's also the problem that which type an expression steps to isn't really static [Fri May 26 23:08:38 2017] e.g. an operator application steps to either itself (while it's stepping its contents) or to a constant [Fri May 26 23:10:00 2017] oh well [Fri May 26 23:10:03 2017] thanks for the suggestions. [Fri May 26 23:34:15 2017] (also it looks like without the class it's not polymorphic enough) [Sat May 27 19:46:49 2017] Is there a good preexisting lib for possibly terminating streams? e.g. Coq.List.Streams but with a 'nil' constructor? [Sat May 27 20:13:21 2017] hmm [Sat May 27 20:13:31 2017] don't know the answer to that one [Sat May 27 20:18:59 2017] OK. I know I can construct a coinductive predicate that such a pt-stream is non-terminating and I think I can use that to transport proofs about streams to the relevant pt-stream, and similarly an inductive predicate that such a pt-stream is terminating. Now to see if I can inhabit the sum of those two predicates from any given pt-stream [Sat May 27 20:19:55 2017] I don't know if the sum of an inductive and coinductive prop is something that you can even reasonably work with though :o [Sat May 27 20:37:58 2017] actually, there's a paper about mixing inductive and coinductive types [Sat May 27 20:55:38 2017] shlevy: https://github.com/jwiegley/fiat-rel :) [Sat May 27 20:57:50 2017] and you should join the Fiat mailing list [Sat May 27 21:40:41 2017] johnw: :o didn't know there was a mailing list@ [Sat May 27 21:40:50 2017] johnw: Link? [Sat May 27 21:43:49 2017] johnw: Oooh may have to wait for tomorrow to dig more intot his but it looks really interesting! I think RelatedTheory might fill a hole in some of my planning for the cat project :) [Sat May 27 22:01:16 2017] I think I may have asked this at one point, but is there a recommended style guide? [Sat May 27 22:45:31 2017] Is there a way to teach coqdoc to do hyperlinks to dependencies found in COQPATH? [Sat May 27 22:50:23 2017] johnw: And we're started https://github.com/shlevy/cat-fiat [Sat May 27 23:15:43 2017] shlevy: yes to the coqdoc and hyperlinks, it should be in the docs [Sat May 27 23:15:49 2017] yay to cat-fiat! [Sun May 28 03:38:54 2017] what’s the best way to apply a tactic to all assumptions that match some pattern? "match goal" only applies it once and "repeat match goal" is an infinite loop if I don’t remove those assumptions afterwards (which I don’t want to do) [Sun May 28 03:47:52 2017] ah in this case I could get it to work by checking if I had already operated on that assumption and "fail"ing in that case [Mon May 29 05:48:39 2017] This is annoying. I am using Emacs with evil and since a few days, Proof General wants to expand what is under my cursor when I hit Escap (and I do that quite often) [Mon May 29 05:48:56 2017] For instance it turns `(A: Type)` into `(AUTO: Type)` [Mon May 29 05:49:13 2017] Any advice on this matter? [Mon May 29 06:00:20 2017] found that: https://github.com/syl20bnr/spacemacs/issues/8853 [Mon May 29 23:44:21 2017] grr [Mon May 29 23:45:09 2017] I wish there were a way to stick "assert (x1 = x2)" into the middle of a function and prove it afterwards [Mon May 29 23:46:49 2017] or more accurately, "assert (t1 = t2)" where t1 t2: Type [Mon May 29 23:47:06 2017] this seems to come up a lot, or maybe it's just the way I write things [Mon May 29 23:55:26 2017] If you are using Program, you can stick an underscore somewhere and prove afterwards what is needed [Tue May 30 00:48:46 2017] that never seems to work, but maybe I'm doing it wrong [Tue May 30 00:48:51 2017] (also in this case I'm not using Program) [Tue May 30 00:49:03 2017] (not that this is necessarily important) [Tue May 30 04:24:25 2017] dh`: what about [enough (t1 = t2)]? [Tue May 30 10:31:13 2017] Hello everyone. Recently I became interested in homotopy type theory and would like to play around with it. Maybe this is the wrong place to ask, because you might be biased, but how can I decide between learning Agda vs learning Coq? [Tue May 30 10:41:31 2017] Or can anyone recommend a good way to learn coq? :-) [Tue May 30 10:42:41 2017] software foundations is one way [Tue May 30 10:42:56 2017] but that said that's thought out for learning coq for program verification and such [Tue May 30 10:43:25 2017] though of course much of it is applicable to other things, but if you are more interested in other bits, it may not be the shortest path. [Tue May 30 10:51:25 2017] modulus: Thank you very much, I will check that book out. [Tue May 30 10:51:43 2017] yw, hth. [Tue May 30 10:52:29 2017] also i'm not myself following HoTT but most I hear about developments in it are in coq so that may be a reason to choose it. [Tue May 30 10:56:53 2017] I see. And as a general question: I heard that you can extract code from coq, how well does that work? I mean in theory, since you can proof properties of your code the "compiler" can go completely crazy with optimizations. Is that actually happening? [Tue May 30 10:59:44 2017] nohTo: IIUC the extraction removes proofs but that's it. You can, of course, "go completely crazy" yourself with proofs all along the way verifying it [Tue May 30 11:00:18 2017] nohTo: And then only extract the optimized version [Tue May 30 11:01:38 2017] shlevy: Ah, you mean optimize yourself and prove correctness? [Tue May 30 11:02:11 2017] Yep, and you can automate or semi-automate that process. See e.g. http://plv.csail.mit.edu/fiat/ [Tue May 30 11:03:22 2017] To be clear, there is no built-in optimization done by the extractor. What it does is a very direct translation, with only some criterion to erase everything Prop-related [Tue May 30 11:09:26 2017] I guess it makes sense, because the extractor cannot guess what you want to optimize for [Tue May 30 16:13:56 2017] plus, the extractor is already untrusted; letting it do program transformations just makes that situation much, much worse [Tue May 30 16:14:20 2017] ideally it conveys my Coq terms as literally as possible in whatever the target language is [Tue May 30 16:14:33 2017] but even then, I have to hand-tune the translations, and even use Perl scripts to fix the result in places [Tue May 30 17:27:54 2017] This is a silly question, but I can't seem to find the answer anywhere obvious: what's the CoqIDE shortcut for compile buffer? [Tue May 30 17:28:28 2017] if you look up in the menus, it shows the keys for the shortcut [Tue May 30 17:28:37 2017] I can never remember what it is though [Tue May 30 17:28:51 2017] Yes, I know, but it doesn't show a key for compile buffer. [Tue May 30 17:28:59 2017] which is strange [Tue May 30 17:29:04 2017] huh [Tue May 30 17:29:38 2017] you can create a configuration file that will allow you to bind keys [Tue May 30 17:29:41 2017] for example https://github.com/yurug/coqepit/blob/master/installation/coqide-configuration/coqide.keys [Tue May 30 17:30:00 2017] I take it there's no canonical reference for shortcut keys. [Tue May 30 17:30:18 2017] F8? [Tue May 30 17:30:20 2017] https://coq.inria.fr/cocorico/Configuration%20of%20CoqIDE [Tue May 30 17:31:44 2017] ah ok. I'll try that alternative config file. [Tue May 30 17:36:53 2017] Huh, strange. I modified the bindings on ~/.config/coq/coqide.keys but my modifications are rolled back whenever I open up coqide. [Tue May 30 19:57:13 2017] Hey there. I wrote an expression with a placeholder (an underscore) in it, because I wasn't sure what to write there. [Tue May 30 19:57:38 2017] As I expected, I got a "cannot infer this placeholder" error, telling me the type needed for the placeholder and the environment. [Tue May 30 19:58:41 2017] Now I'm wondering if there's a way to set that as a goal so I can try some tactics. [Tue May 30 19:59:45 2017] If you wrote something like "Definition foo := some_term _ .", try "Program Definition foo := some_term _ ." [Tue May 30 20:00:14 2017] a more manual way of doing it would be to just take the expected type of the placeholder, and set that as a goal [Tue May 30 20:00:19 2017] (like, copy-paste it) [Tue May 30 20:02:08 2017] Warrigal: how did you write it? [Tue May 30 20:02:16 2017] often, refine or eapply can turn placeholders into goals [Tue May 30 20:02:44 2017] I wrote it inside a definition like Cypi wrote. [Tue May 30 20:03:13 2017] then either use Program [Tue May 30 20:03:21 2017] or say: Definition foo. refine (...). [Tue May 30 20:05:09 2017] Nice. I like that "Definition foo. refine" technique. [Tue May 30 20:05:10 2017] Thanks! [Tue May 30 20:05:46 2017] it's much-used in CPDT [Tue May 30 20:06:20 2017] as a way of writing most-Gallina definitions, but while still in a proof environment, in cases where Program isn't exactly what you need [Tue May 30 20:06:24 2017] I tend to use Program a lot, though [Tue May 30 20:06:38 2017] if I call a function and it can't guess the hole, I just do _ (func foo _ bar) [Tue May 30 20:06:45 2017] to see if it can make a goal for what I'd need to do further [Tue May 30 20:26:58 2017] Hmm. I see that Opaque doesn't do nearly what I thought it did. [Tue May 30 20:27:40 2017] I thought it would make a constant non-unfoldable. It doesn't do that. [Tue May 30 20:31:34 2017] Indeed, it looks like it's not possible to make a constant defined with "Definition" non-unfoldable. [Tue May 30 20:33:31 2017] The general thing I want to do is to define a constant, prove some things about it, and then make the constant non-unfoldable so that its implementation is no longer visible. [Tue May 30 20:34:49 2017] I'm trying to implement homotopy type theory, so an example would be that I define the path composition function, then prove that reflexivity is an identity for it, then make the function non-unfoldable. [Tue May 30 20:50:45 2017] Now I'm wondering what kinds of suites of opaque constants you'd need to match a transparent one. [Tue May 30 20:51:33 2017] Suppose you've got compose : (x = y) -> (y = z) -> (x = z) as an opaque constant. It's hard to prove stuff about that. [Tue May 30 20:52:14 2017] So let's introduce new opaque constants: compose_refl_left p : compose refl p = p and compose_refl_right p : compose p refl = p. [Tue May 30 20:52:45 2017] Great, but now we have no way to prove that compose_refl_left refl = compose_reft_right refl (they both assert that compose refl refl = refl). [Tue May 30 20:53:15 2017] So we introduce a *fourth* opaque constant: compose_refl_coherence : compose_refl_left refl = compose_refl_right refl. [Tue May 30 20:58:05 2017] I feel like we're done at that point; we have everything we need in order to prove "everything". [Wed May 31 00:25:43 2017] So the documentation says: "Notations do not survive the end of sections. They survive modules unless the command Local Notation is used instead of Notation." [Wed May 31 00:25:49 2017] I must be misunderstanding something... [Wed May 31 00:26:08 2017] I have a Module Type TPaths that defines a notation, and a Module Legacy (Paths : TPaths). [Wed May 31 00:26:23 2017] Inside of Legacy, I can't see the notations defined in TPaths. [Wed May 31 00:27:16 2017] If notations "survive modules", shouldn't I be able to see those notations? Maybe that's saying that they only survive actual modules, not module types? [Wed May 31 00:27:34 2017] Or maybe the notation is available inside Legacy somehow, but I need to "import" it or something? [Wed May 31 00:31:28 2017] Ah, here we go. "Import Paths" makes the notations visible. [Wed May 31 01:36:24 2017] speaking of notations, is there a paper on how they're set up? [Wed May 31 07:42:57 2017] hi all [Wed May 31 07:51:03 2017] I was wondering, do you all know if there is a way to deal with the “issue” describe into the following SO question: https://stackoverflow.com/questions/27322979/why-coq-doesnt-allow-inversion-destruct-etc-when-the-goal-is-a-type [Wed May 31 07:51:22 2017] that is, basically use `inverse` when the goal is something like `Prop` or a Type [Wed May 31 07:52:58 2017] I mean, everything seems to be in the question and the answer: you can't, unless it's supposed to discharge the goal because you're inverting an absurdity, in which case you can do "exfalso" first [Wed May 31 07:56:03 2017] well the question is from 2014 [Wed May 31 07:56:11 2017] I was hoping maybe it had changed [Wed May 31 07:56:42 2017] It won't change, it is not some limitation or something, it is a specific intention that you cannot eliminate something in Prop when building something in Set/Type [Wed May 31 07:57:23 2017] (It would probably make the logic inconsistent, even though I am no expert; at the very least, it would make it inconsistent with proof irrelevance) [Wed May 31 07:58:45 2017] I see [Wed May 31 07:59:07 2017] It does not work either when the goal is `Prop`, though [Wed May 31 07:59:23 2017] Prop has type Type [Wed May 31 07:59:24 2017] but I can guess why it is not allowed [Wed May 31 07:59:30 2017] You need a goal whose type is Prop [Wed May 31 07:59:36 2017] (for instance, "False" has type Prop) [Wed May 31 08:00:42 2017] Okay I see, thanks [Wed May 31 08:01:37 2017] I will try a different approach, then [Wed May 31 08:44:30 2017] I'm trying to define a key mapping for compile buffer on coqide. I modified ~/.config/coq/coqide.keys, but it rolls back every time I run coqide. Any idea as to what's going on? [Wed May 31 09:42:10 2017] ;o; [Thu Jun 1 04:50:38 2017] does anyone have a good recomendation for a tutorial about the coqide or proof general with coq? Googling has turned up things that are either too general (pun not intended) or not relevant [Thu Jun 1 17:08:42 2017] Anyone know if there's a way to ask Coq to apply only a single particular conversion rule (e.g. just β or just ι)? It would be nice to be able to illustrate the βιδζη rules separately. [Thu Jun 1 17:17:07 2017] cbv can take flags, see https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic132 [Thu Jun 1 17:30:30 2017] Cypi: ahh, thanks! [Thu Jun 1 23:03:12 2017] I'm attempting an implementation of difference lists just for practice/learning. Having trouble proving to_from_id here, can someone point me in the right direction? https://gist.github.com/relrod/078228e200e90c4e59a4733068843545 [Fri Jun 2 00:34:23 2017] hmm lemme see [Fri Jun 2 00:49:24 2017] I think the problem is that it's not true. [Fri Jun 2 00:50:27 2017] nothing says the xs that you passed to toList has to have been created with fromList, so it can have any function inside it. [Fri Jun 2 00:51:58 2017] you should be able to prove something like toList xs = toList (fromList (toList xs)) [Fri Jun 2 00:52:35 2017] he's already got toList (fromList xs) = xs [Fri Jun 2 00:52:50 2017] oh right [Fri Jun 2 00:56:11 2017] relrod: I commented on the gist with a proof that your theorem is false. [Fri Jun 2 00:57:52 2017] jrw, dh`, cocreature: Oops, thank you! That wouldn't certainly explain why I can't prove it. :) [Fri Jun 2 00:58:41 2017] try this: [Fri Jun 2 00:58:42 2017] Definition wonkyList {a: Set} (l: list a) : DList a := [Fri Jun 2 00:58:42 2017] DL a (fun k => l ++ k ++ l). [Fri Jun 2 00:58:44 2017] :-) [Fri Jun 2 00:59:03 2017] yeah. Hrm. [Fri Jun 2 01:01:56 2017] the other issue is, if I understand what difference lists are supposed to be [Fri Jun 2 01:02:09 2017] that even if you sort out this administrative problem, it still won't be true [Fri Jun 2 01:02:44 2017] inasmuch as the point of difference lists seems to be that they're a lazy representation of a list construction that you eventually evaluate [Fri Jun 2 01:03:09 2017] once you evaluate it, the thing that you get is structurally different and so not equal, even if it represents the same list. [Fri Jun 2 01:03:50 2017] and so fromList (toList xs) will not be the same as xs because it's done this step. [Fri Jun 2 01:04:40 2017] equality in coq is structural, so you'll need instead to define a concpt of equivalence for difference lists [Fri Jun 2 01:05:01 2017] and prove enough stuff about that to be useful [Fri Jun 2 01:05:24 2017] (symmetric, reflexive, and transitive is a good start) [Fri Jun 2 01:06:05 2017] dh`: Okay. There's a chance I'm getting ahead of myself and should go back to CPDT (or SF - I'd been bouncing between them a while back). Just wanted to try something different and experiment. [Fri Jun 2 01:06:19 2017] I really appreciate the explanation! [Fri Jun 2 01:06:28 2017] I dunno, you might or might not be. It seems like a tractable exercise, but perhaps larger than you expected... [Fri Jun 2 01:07:41 2017] well, assuming you can sort out the administrative problem. [Fri Jun 2 01:07:50 2017] I'm not absolutely sure how to do that. [Fri Jun 2 01:11:28 2017] * nods [Fri Jun 2 01:11:38 2017] Alright, I'll keep playing and see what I can do [Fri Jun 2 01:15:26 2017] hmm [Fri Jun 2 01:15:51 2017] you'll need to not have a function inside the DList, since it basically needs to always (implicitly) be ++ [Fri Jun 2 01:16:06 2017] and anything else will cause it to all go off the rails [Fri Jun 2 01:16:22 2017] since relrod has already imported FunctionalExtensionality, shouldn’t dlists be equal if you use extensional equality? [Fri Jun 2 01:16:53 2017] I wonder if equivalence of DLists is adequately stated by saying they toList to the same list [Fri Jun 2 01:18:02 2017] dh`: that's what they do in the Haskell one: http://hackage.haskell.org/package/dlist-0.8.0.2/docs/src/Data-DList.html#line-221 [Fri Jun 2 01:19:13 2017] Of course that doesn't mean much [Fri Jun 2 01:22:04 2017] relrod: I pushed an implementation here: https://github.com/wilcoxjay/notes/blob/master/DiffLists.v [Fri Jun 2 01:22:26 2017] the idea is that not just any function is allowed as a difference list, it has to be one that is a "prepender" [Fri Jun 2 01:22:35 2017] it means it worked for them... [Fri Jun 2 01:22:39 2017] anyway it seems to work [Fri Jun 2 01:22:41 2017] once you have that (and proof irrelevance), everything works. [Fri Jun 2 01:23:17 2017] I just did one based on this: [Fri Jun 2 01:23:18 2017] Inductive DList (a: Set) := [Fri Jun 2 01:23:18 2017] | DLnil: DList a [Fri Jun 2 01:23:18 2017] | DLprepend: list a -> DList a -> DList a [Fri Jun 2 01:23:18 2017] . [Fri Jun 2 01:23:37 2017] it is a direct corollary of to_from_id that DLists are equal just when their toLists are equal. [Fri Jun 2 01:23:52 2017] but that's not very general. [Fri Jun 2 01:25:57 2017] yours uses a lot of hammers though, I wonder if I can simplify that :-) [Fri Jun 2 01:26:26 2017] jrw: Thank you :) [Fri Jun 2 01:48:45 2017] Thanks again for all the help, folks! :) [Fri Jun 2 02:12:11 2017] yeah, provided you're willing to have a DListEq instead of using =, it works out decently [Fri Jun 2 02:15:42 2017] http://codepad.org/46q5VciT [Fri Jun 2 02:16:06 2017] it's fairly clear where functional extensionality and proof irrelevance come in if you want to use = [Fri Jun 2 02:19:02 2017] dh`: is one approach more commonly accepted in practice than the other? [Fri Jun 2 02:19:20 2017] well, maybe [Fri Jun 2 02:19:42 2017] functional extensionality is a big hammer [Fri Jun 2 02:20:11 2017] also it seems inelegant to many people. [Fri Jun 2 02:20:51 2017] there is absolutely nothing *wrong* with it, but people still like to not use it if they don't need to. [Fri Jun 2 02:20:59 2017] * nods [Fri Jun 2 02:22:15 2017] on the other hand, being able to state x = y has a lot of advantages, because you can use "rewrite" freely [Fri Jun 2 02:23:10 2017] you can use rewrite with your own equivalences, but it requires typeclass instances to show that what you've got is actually an equivalence, and, more annoyingly, an additional instance for every context in which the rewrite is admissible [Fri Jun 2 02:25:54 2017] dh`: I guess I'm trying to figure out which is nicer to people, if the goal is a general purpose library that people can use (and not just writing it as part of some bigger project or something) [Fri Jun 2 02:28:07 2017] But I guess there's no "one size fits all" answer - if people hate extensionality, I guess they'll avoid using a library that depends on it. And if they require heavy use of rewrite, the other solution is a nonstarter. [Fri Jun 2 02:33:31 2017] it's not clear [Fri Jun 2 02:33:48 2017] designing libraries is hard in general, and designing libraries for coq is harder still. [Fri Jun 2 02:40:50 2017] it's hard to know even what functions to put in (e.g. there should obviously be a Definition fromItem A (x: A) := DL A (cons x) (cons_prepender A x). [Fri Jun 2 02:40:55 2017] but what else? [Fri Jun 2 02:41:52 2017] and figuring out what lemmas to include is a lot worse. [Fri Jun 2 02:43:45 2017] in principle you'd probably want every lemma defined on lists, but many of them will be intractable. [Fri Jun 2 02:55:03 2017] Another thing is, functional extensionality is one of those things you can sometimes avoid by rephrasing things slightly [Fri Jun 2 02:58:47 2017] dh`: as far as functions, I was roughly thinking: Most of the functions that the Haskell one has. But a lot of those seem to piggyback off of List [Fri Jun 2 03:00:21 2017] my advice would be: don't try to design a library just yet; it's good to think about this but do some other stuff first and come back to it [Fri Jun 2 03:01:39 2017] Fair enough. I'll start bouncing off CPDT and SF again and try not to get ahead of myself. [Fri Jun 2 05:42:21 2017] is anyone awake here? [Fri Jun 2 05:43:57 2017] getting a weird msg in proof general that wasn't showing up yesterday, not sure whats happening. Its not recognizing coq files despite the files being from Software Foundations and are very much legit coq scripts [Fri Jun 2 05:46:25 2017] fwiw proof general is loading I get the splash screen, but when I try basic commands I get "Proof Process not started!" [Fri Jun 2 05:50:54 2017] nothing? [Fri Jun 2 12:47:17 2017] dtornabene: have you loaded at least one line from the file? that error message indicates that PG just hasn't been fully initialized yet. [Fri Jun 2 12:47:51 2017] jrw: hey! thanks for responding, yeah it was that exactly [Fri Jun 2 12:49:06 2017] jrw: i'm *just* getting into using proof general and still very much in the stumbling around phase. I didn't realize that despite the splash screen PG needs further initialization [Fri Jun 2 12:54:53 2017] glad you got it to work! [Fri Jun 2 13:00:03 2017] thanks, me too! [Mon Jun 5 20:20:59 2017] hmm :) [Mon Jun 5 20:21:09 2017] So I saw this question by zachk in #idris [Mon Jun 5 20:21:12 2017] in the algebraic expression: (n * (n + 1))/2 where n is a Nat, how would I prove the numerator is always even or divisible by 2, and how would I prove the division by 2 is total in idris [Mon Jun 5 20:21:30 2017] and I decided just for fun to do it in Coq, because I was bored [Mon Jun 5 20:22:09 2017] http://lpaste.net/356060 [Mon Jun 5 20:22:27 2017] The interesting thing is at the very end, when I try to compute using this [Mon Jun 5 20:22:37 2017] *some* triangular numbers will compute just fine [Mon Jun 5 20:22:46 2017] others result in an un-reduced mess :) [Mon Jun 5 20:24:10 2017] Oh, I can be more specific about that: for odd n, triangular n seems to compute okay [Mon Jun 5 20:24:56 2017] But even triangular 0 seems to get stuck. [Mon Jun 5 20:57:11 2017] Cale: in zachk it does case analysis on even_adjacency [Mon Jun 5 20:57:29 2017] essentially for odd numbers it does one branch and for even numbers it does another branch. [Mon Jun 5 20:57:42 2017] only one of the two branches calls mult_comm [Mon Jun 5 20:58:04 2017] mult_comm call a bunch of opaque lemmas such as mult_n_O and mult_n_Sm that do not reduce. [Mon Jun 5 20:58:27 2017] plus_comm has similar opaque lemmas. [Mon Jun 5 21:04:53 2017] ahh [Mon Jun 5 21:05:01 2017] They're opaque, right [Mon Jun 5 21:18:38 2017] Yeah, that fixed it :) [Mon Jun 5 21:18:58 2017] annoying that even very basic things in the library are opaque [Tue Jun 6 04:30:43 2017] Cale: I'd go so far as to say as extracting code from theorems isn't a great plan [Tue Jun 6 04:30:51 2017] even when it works [Tue Jun 6 04:33:25 2017] better to write an explicit half function and then prove what you want to know about it [Tue Jun 6 04:39:09 2017] because I'm a nerd: http://codepad.org/SD7RSU2o [Tue Jun 6 04:39:18 2017] (with four different versions of half) [Tue Jun 6 04:39:50 2017] the dependently-typed one that knows it can't be passed odd numbers is a pain and a half to work with, though. [Tue Jun 6 21:10:45 2017] stupid question: I'm trying to prove associativity of addition, and I have this [Tue Jun 6 21:10:51 2017] a : NatPos [Tue Jun 6 21:10:59 2017] IHa : forall b c : NatPos, plus (plus a b) c = plus a (plus b c) [Tue Jun 6 21:11:08 2017] want to show [Tue Jun 6 21:11:09 2017] forall b c : NatPos, S (plus (plus a b) c) = S (plus a (plus b c)) [Tue Jun 6 21:11:16 2017] you would just apply S to both sides of IHa [Tue Jun 6 21:11:19 2017] but I can't figure out how to do that [Tue Jun 6 21:11:42 2017] how should I prove this? [Tue Jun 6 21:22:01 2017] b7de: you can use the tactic f_equal to reduce your goal to your hypothesis. [Tue Jun 6 21:22:10 2017] thanks [Tue Jun 6 21:23:15 2017] that's a large hammer :-) there's a lemma about S x = S y -> x = y [Tue Jun 6 21:23:23 2017] try Search (S _ = S _). [Tue Jun 6 21:23:42 2017] (also one for x = y -> S x = S y) [Tue Jun 6 21:26:07 2017] it's my own custom S though [Tue Jun 6 21:30:25 2017] just use f_equal [Tue Jun 6 21:31:30 2017] ok [Tue Jun 6 21:33:01 2017] Uh... I don't think you should need f_equal. [Tue Jun 6 21:33:13 2017] What's your induction hypothesis say? [Tue Jun 6 21:33:49 2017] Well, I suppose it's fine to use f_equal, because it gets you to something which ought to be exactly your induction hypothesis [Tue Jun 6 21:34:04 2017] But you can probably also just rewrite by the induction hypothesis, and then use reflexivity. [Tue Jun 6 21:48:53 2017] .oO(Can we prove these two proofs of associativity are themselves equal, for each choice of a, b and c?) [Tue Jun 6 21:50:14 2017] Yes you can, because nat is an h-set (any two proofs of a = b are equal for any nat a and b) [Tue Jun 6 22:49:58 2017] right [Tue Jun 6 22:50:58 2017] At least, in principle we ought to be able to -- I'm not sure how to carry it out in plain Coq in detail. [Tue Jun 6 22:53:02 2017] One of the easy ways of proving this is to prove that equality is decidable (which it is for natural numbers) [Tue Jun 6 22:53:05 2017] See https://coq.inria.fr/library/Coq.Logic.Eqdep_dec.html [Tue Jun 6 23:08:54 2017] That is a facinating file to rewrite. If you want a bit of fun, start trying to do some of those proofs without looking at the solution; then once you give up copy out their solution to see what it is like. [Wed Jun 7 07:16:42 2017] I found the section on recursive Notation quite hard to follow in the reference manual. Is there any other source where I can read it from? [Thu Jun 8 13:26:29 2017] I would like to install coq 8.4 on a fedora machine. How do I do that? [Thu Jun 8 13:30:35 2017] Are there packages for the older versions of coq somewhere? Or, do I have to download the source code and build it myself? [Fri Jun 9 08:28:51 2017] how do you model relations in coq? [Fri Jun 9 08:29:03 2017] currently using a function A -> A -> bool. [Fri Jun 9 08:29:20 2017] is there some way to express it as a subset of A * A? [Fri Jun 9 08:29:57 2017] In the stdlib, relations are defined as A -> A -> Prop [Fri Jun 9 08:30:00 2017] as in https://coq.inria.fr/library/Coq.Relations.Relation_Definitions.html [Fri Jun 9 08:30:31 2017] yours would be decidable relations [Fri Jun 9 08:31:10 2017] yes, in my case I'd prefer decidable relations I think [Fri Jun 9 08:31:15 2017] trying to model finite graphs [Fri Jun 9 08:32:07 2017] Cypi: is there a better source (other than reference manual) for Notations involving recursion [Fri Jun 9 08:32:08 2017] mh. is there a shorter version of `== true` for booleans? [Fri Jun 9 08:32:26 2017] I found the section all most ununderstandable [Fri Jun 9 08:33:28 2017] heinrich5991: do you mean something like "is_true"? [Fri Jun 9 08:33:39 2017] (it's just the function "fun b => b = true") [Fri Jun 9 08:33:46 2017] yes [Fri Jun 9 08:33:53 2017] ok, thanks [Fri Jun 9 08:34:20 2017] piyush-kurur: I don't know, sorry. I'm using few notations in Coq, since I also find them to be complicated. [Fri Jun 9 14:39:26 2017] I have a file CpdtTactics.v. I'd like to include it [Fri Jun 9 14:39:40 2017] Require Import CpdtTactics. doesn't seem to work, even though I'm in the correct directory [Fri Jun 9 14:53:43 2017] . [Fri Jun 9 14:54:32 2017] unrelated: I have forall and existence quantors over finite types. [Fri Jun 9 14:54:40 2017] can I ask coq to just check all possible cases? [Fri Jun 9 14:55:07 2017] you could destruct perhaps? [Fri Jun 9 14:57:22 2017] I have something like forall x forall y forall z [Fri Jun 9 14:59:34 2017] when I destruct, only the first variable is split up [Fri Jun 9 15:01:09 2017] destruct x; destruct y; destruct z.? [Fri Jun 9 15:01:54 2017] ah great, thanks [Fri Jun 9 15:01:57 2017] didn't know about ; [Fri Jun 9 15:04:02 2017] yw, hth. it's auseful tactical for things that branch a lot. [Fri Jun 9 15:11:32 2017] can False -> (anything) be proven in coq? [Fri Jun 9 15:12:12 2017] False -> False can, i think, be proven. [Fri Jun 9 15:12:46 2017] actually False -> anything can be proven yeah. [Fri Jun 9 15:14:06 2017] use intro to get False as a hypothesis, then destruct the hypothesis and you get it. [Fri Jun 9 15:16:06 2017] mh. my situation is a tiny bit more complicated. I have true = false => (something) [Fri Jun 9 15:16:12 2017] (the booleans true and false) [Fri Jun 9 15:16:37 2017] you should be able to apply simpl on that to get true = false as False [Fri Jun 9 15:16:41 2017] I think. [Fri Jun 9 15:19:50 2017] how do I apply "simpl" to a hypothesis? [Fri Jun 9 15:20:17 2017] simpl in hypothesis, but i was wrong, simpl won't do it. [Fri Jun 9 15:20:21 2017] but inversion will. [Fri Jun 9 15:20:25 2017] so inversion in H or whatever [Fri Jun 9 15:24:45 2017] yea, works [Fri Jun 9 15:33:32 2017] so forall can be nicely destructed using `destruct` [Fri Jun 9 15:33:49 2017] do you know what could be done for `exists`? [Fri Jun 9 15:34:02 2017] I'd like coq to just try all the possible things. [Fri Jun 9 15:44:55 2017] what do you mean by "forall can be nicely destructed using `destruct`"? [Fri Jun 9 16:24:36 2017] johnw: I mean that I get a hypothesis for each possible x:(finiteset) [Fri Jun 9 16:24:45 2017] I'd like to get something similar for a `exists` clause [Fri Jun 9 16:26:47 2017] I still don't know what you mean, sorry [Fri Jun 9 16:27:08 2017] if you have H : exists x, ... in your context, then you can destruct H [Fri Jun 9 16:27:48 2017] suppose I have an exists x:bool, x=true. [Fri Jun 9 16:28:02 2017] I'd like coq to try x:=false and x:=true [Fri Jun 9 16:28:13 2017] you can then do: eexists; reflexivity [Fri Jun 9 16:28:17 2017] and it will pick "true" [Fri Jun 9 18:03:24 2017] mh. [Fri Jun 9 18:03:46 2017] my term is more complicated [Fri Jun 9 18:03:51 2017] like [Fri Jun 9 18:04:17 2017] Lemma a: exists b:bool, negb b = true. [Fri Jun 9 18:04:28 2017] eexists works there, but I'm not sure what to do next. [Fri Jun 9 18:43:02 2017] heinrich5991: maybe something like this will do what you want: unshelve eexists; [constructor|]; reflexivity. [Fri Jun 9 18:43:15 2017] it's pretty fragile though [Fri Jun 9 19:01:58 2017] heinrich5991: exists false. [Fri Jun 9 19:02:11 2017] (and then reflexivity will finish) [Fri Jun 9 19:23:53 2017] Cale: he wants coq to search over all values of a finite type and see which one works. [Sat Jun 10 04:01:52 2017] I'm not sure what you mean with [constructor|] [Sat Jun 10 04:02:05 2017] in Lemma a: exists b:bool, neg b = true. [Sat Jun 10 04:02:49 2017] I tried [constructor|], [true|], [bool|]. coq didn't like either of these, responding with a syntax error [Sat Jun 10 04:07:08 2017] does anyone know of a computational reflection tactic for finite FMaps whose structure is known? [Sat Jun 10 04:07:33 2017] i.e., a solver for statements of the form M.In x m, where m is a chain of M.add calls ending in M.empty [Sat Jun 10 04:23:40 2017] ah, figured it out, you mean the tactic "constructor" [Sat Jun 10 04:28:23 2017] Lemma ntrue : exists b:bool, negb b = true. [Sat Jun 10 04:28:29 2017] unshelve eexists. constructor. [Sat Jun 10 04:28:32 2017] 1 subgoal: [Sat Jun 10 04:28:35 2017] negb true = true [Sat Jun 10 04:29:33 2017] seems like coq decided to choose the wrong constructor [Sat Jun 10 04:44:12 2017] ah, but with ; instead of . it works [Sat Jun 10 04:44:19 2017] weird [Sat Jun 10 04:49:55 2017] is there no tactic that transforms [Sat Jun 10 04:50:24 2017] exists b:bool, notb b = true [Sat Jun 10 04:50:26 2017] into [Sat Jun 10 04:50:41 2017] (notb true = true) or (notb false = true) [Sat Jun 10 04:53:24 2017] heinrich5991: what do you expect that to do if instead of bool you have some recursive type and there is an infinite number of possibilities? [Sat Jun 10 04:56:08 2017] I only expect it to work for finite, non-recursive types [Sat Jun 10 04:57:51 2017] fair enough. I don’t think there is something builtin for that [Sat Jun 10 05:03:21 2017] how hard is it to build something like that? is it harder than easy? [Sat Jun 10 05:05:00 2017] it's not hard at all [Sat Jun 10 05:05:19 2017] now you're entering into Ltac territory [Sat Jun 10 05:05:32 2017] I don't know about "for any finite non-recursive type" [Sat Jun 10 05:05:40 2017] but for a known finite non-recursive type, certainly [Sat Jun 10 05:06:20 2017] Where do you paste code? lpaste seems to be down [Sat Jun 10 05:06:27 2017] I like gists [Sat Jun 10 05:07:15 2017] https://gist.github.com/cmangin/2ea76c4cac53606267502dbbd437c3a7 [Sat Jun 10 05:07:27 2017] this is basic, but this could work [Sat Jun 10 05:07:43 2017] (even for an infinite type, if it explores it in the correct order) [Sat Jun 10 05:08:12 2017] neat [Sat Jun 10 05:08:14 2017] "kont" is expected to fail if the instantiation is wrong (otherwise there is no way to tell if we chose the right argument for eexists) [Sat Jun 10 05:09:46 2017] hm. should I try to understand this or just copy-paste it? ^^ [Sat Jun 10 05:10:03 2017] this declares new tactics, I guess [Sat Jun 10 05:10:15 2017] what is generate_all supposed to do? [Sat Jun 10 05:10:53 2017] Just read it, it's not very complicated :) . The only thing to know is that Ltac has a backtracking semantics. So when you write "idtac + generate_all", it first tries to apply "idtac" (which does nothing), proceeds with the rest of the tactics, and if the following tactics fail, it will try with "generate_all" instead [Sat Jun 10 05:11:30 2017] To reformulate, if you write "(tac1 + tac2); tac", then Coq will try to do "tac1; tac", and if this fails it will do "tac2; tac" [Sat Jun 10 05:12:02 2017] So in this case, generate_all is supposed to try any combination of constructors [Sat Jun 10 05:13:02 2017] so this is something like constructor; (nothing; constructor; (nothing; constructor; ...))) [Sat Jun 10 05:13:11 2017] yup [Sat Jun 10 05:13:36 2017] so what does constructor; constructor do? use the second constructor? [Sat Jun 10 05:13:40 2017] constructor is also backtracking, so actually it will try every combination of constructors in a sort of breadth-first fashion [Sat Jun 10 05:13:46 2017] it applies one constructor, then another constructor [Sat Jun 10 05:13:59 2017] (well, not "another") [Sat Jun 10 05:14:09 2017] so it would be recursive, like the second constructor would try things like "S(S 0)"? [Sat Jun 10 05:15:04 2017] The second constructor would try either "S O" or "S (S ?)" [Sat Jun 10 05:15:57 2017] Just to be clear: generate_all is exactly equivalent to "constructor + (constructor; constructor) + (constructor; constructor; constructor) + ..." [Sat Jun 10 05:16:05 2017] yes [Sat Jun 10 05:16:27 2017] and constructor itself will try every constructor in order (again, with this backtracking semantics of Ltac) [Sat Jun 10 05:16:41 2017] so "constructor" will already try both? [Sat Jun 10 05:16:58 2017] both constructors, yes [Sat Jun 10 05:17:01 2017] ah, and check if the further applied tactics (after ;) are ok [Sat Jun 10 05:17:10 2017] in the case of your finite types this is probably enough, if they are not recursive [Sat Jun 10 05:17:15 2017] yes [Sat Jun 10 05:17:49 2017] can I nest try_all? [Sat Jun 10 05:17:53 2017] nest? [Sat Jun 10 05:18:04 2017] try_all (try_all reflexivity) and try_all try_all reflexivity don't seem to work [Sat Jun 10 05:18:20 2017] for two existentials [Sat Jun 10 05:18:56 2017] try_all ltac:(try_all reflexivity) [Sat Jun 10 05:19:10 2017] you need to indicate to Coq that is a Ltac term, not a Gallina term [Sat Jun 10 05:19:19 2017] (quotations are kind of messed up in Ltac currently) [Sat Jun 10 05:19:43 2017] The reference try_all was not found in the current environment. [Sat Jun 10 05:19:54 2017] nvm [Sat Jun 10 05:19:58 2017] missed the colon [Sat Jun 10 05:22:25 2017] If your types are not recursive, honestly you can be more simple: just write "unshelve eexists; [constructor|]; reflexivity" like it was suggested earlier [Sat Jun 10 05:22:49 2017] true [Sat Jun 10 05:22:56 2017] I'm still trying to figure out the final tactic [Sat Jun 10 05:23:12 2017] also, you don't need try_all to take a continuation, since it really only uses it at the end, you could write "Ltac try_all := unshelve eexists; [solve[generate_all]|]." and then do "try_all; try_all; reflexivity" [Sat Jun 10 05:23:35 2017] it's a term of the form fn1 a b = true /\ fn2 b a = true. [Sat Jun 10 05:23:51 2017] auto etc. don't fail if they can't reduce the term [Sat Jun 10 05:24:08 2017] but auto solves the goal if it can reduce it [Sat Jun 10 05:24:26 2017] so I'm currently trying to find a tactic that fails if it can't evaluate the term [Sat Jun 10 05:24:36 2017] wouldn't "split; reflexivity" work? [Sat Jun 10 05:25:16 2017] yes [Sat Jun 10 05:25:33 2017] (you see that I'm not very familiar with coq :/ ) [Sat Jun 10 05:27:14 2017] (it's alright, we all were there at some point :) ) [Sat Jun 10 05:30:37 2017] so.... I have a three proposition joined with conjunction, not two [Sat Jun 10 05:30:47 2017] I tried split; [split|]; reflexivity [Sat Jun 10 05:32:40 2017] you could even do "repeat split; reflexivity" to be a little bit more extensible [Sat Jun 10 05:33:03 2017] oh, I forgot the line: but it doesn't work [Sat Jun 10 05:33:14 2017] hmm [Sat Jun 10 05:33:14 2017] it says "no applicable tactic" [Sat Jun 10 05:33:27 2017] but yours does [Sat Jun 10 05:34:24 2017] ah right, it should have been [|split] instead of [split|] [Sat Jun 10 05:34:34 2017] because the split remains in the second subgoal, not the first one [Sat Jun 10 05:34:58 2017] [a|b] doesn't mean "try a and b"? [Sat Jun 10 05:35:12 2017] no, it means "do a on first subgoal, do b on second subgoal" [Sat Jun 10 05:35:17 2017] ah [Sat Jun 10 05:35:23 2017] "try a and if it fails b" is "a + b" [Sat Jun 10 05:35:50 2017] "a || b" is also "try a and if it fails b", but it is not backtracking [Sat Jun 10 05:40:15 2017] where do you learn these tactic combinators? [Sat Jun 10 05:40:29 2017] (also: I now found a error in my hypothesis :) ) [Sat Jun 10 05:40:59 2017] Well, some are taught about in various books (like Software Foundations). There is also this https://coq.inria.fr/refman/tactic-index.html which is a very useful index [Sat Jun 10 05:46:15 2017] hm [Sat Jun 10 05:47:08 2017] it works now [Sat Jun 10 05:47:46 2017] definitely thanks for your help, I wouldn't have made it this far :) [Wed Jun 14 08:59:23 2017] Hey, is there some tactic that can solve https://gist.github.com/cocreature/ee620862ecd8c4c3b6b7fe1bb59e6d27 automatically? [Wed Jun 14 08:59:34 2017] so some kind of auto that automatically deals with <->? [Wed Jun 14 09:03:07 2017] I guess I could just write my own that first destructs all equivalences and then calls eauto [Wed Jun 14 09:04:03 2017] not sure, would substs help? [Wed Jun 14 09:04:26 2017] hm I thought about 'congruence' but it might only handle equalities [Wed Jun 14 09:04:45 2017] artart78: yeah I tried that already and sadly it doesn’t work [Wed Jun 14 09:05:07 2017] modulus: "substs"? do you mean "subst"? if so that only handles equalities (afaik) and doesn’t work here (I tried it) [Wed Jun 14 09:05:33 2017] but how many such goals do you have cocreature? [Wed Jun 14 09:06:13 2017] artart78: not that many but it’s a pattern I’ve seen come up several times and it seems simple enough that there might be builtin automation for it (yes I’m lazy) [Wed Jun 14 09:06:16 2017] yes sorry, i did mean subst. [Wed Jun 14 09:08:31 2017] if you split the equivalence you should be able to do "apply (H H1)" which doesn't take much characters (or you could put it in the context when H1 is introduced) [Wed Jun 14 09:08:58 2017] artart78: if I split the equivalence I can also just use eauto :) [Wed Jun 14 09:09:18 2017] and even without splitting "apply H; eauto" works [Wed Jun 14 09:09:37 2017] did you try tauto, firstorder? [Wed Jun 14 09:09:42 2017] yep [Wed Jun 14 09:10:10 2017] ok, too bad :p [Wed Jun 14 09:10:26 2017] it’s no big deal, thanks for your help anyway :) [Wed Jun 14 15:05:53 2017] yay proofs in Coq seem much easier now that I am getting the hang of it, [Wed Jun 14 15:06:09 2017] though a google search for coq ring (tactic) showed some bad images :( [Thu Jun 15 04:48:21 2017] what exactly am I supposed to pass for the relation argument in "setoid_replace t with t' using relation rel"? [Thu Jun 15 04:49:09 2017] ah it’s the name of the actual relation that is an instance of Equivalence not the name declared in "Add Parametric Relation" [Fri Jun 16 01:21:24 2017] just finished a bunch of proofs that drained a TON of life away this past wee [Fri Jun 16 01:21:30 2017] that feeling is why we do it [Fri Jun 16 02:32:07 2017] does any know of code for computing the congruence closure of equivalences over list membership? [Fri Jun 16 09:27:28 2017] Anyone out there? [Fri Jun 16 10:49:02 2017] Require Import Coq.omega.Omega. works fine, but then on `assert (Hle': i1' <= i2') by omega.` I get `Error: The reference omega was not found in the current environment. ` [Fri Jun 16 10:49:42 2017] any ideas how to fix that? [Fri Jun 16 10:53:22 2017] retracting the whole module helped for some reason [Fri Jun 16 10:53:38 2017] i guess i've stumbled upon a PG bug or something [Fri Jun 16 11:02:27 2017] isn't it Omega? [Fri Jun 16 16:31:17 2017] when I use the Mathematical proof language (chaper 11 in the coq manual) and proof something simple like Lemma Bla (A : Prop): A -> A. [Fri Jun 16 16:31:20 2017] like this : [Fri Jun 16 16:31:35 2017] assume A. thus thesis. end proof. [Fri Jun 16 16:32:14 2017] coq tells me: No more subgoals, but there are non-instantiated existential variables [Fri Jun 16 16:32:39 2017] why is that so ? did I miss something ? Or is that normal ? [Fri Jun 16 16:48:58 2017] well and the message also contains : [Fri Jun 16 16:49:00 2017] ?Goal : [a : Prop _hyp : a |- a] [Fri Jun 16 16:49:10 2017] You can use Grab Existential Variables. [Fri Jun 16 22:00:09 2017] Is it possible to make output from coqc a bit more verbose? Currently it says "There are pending proofs" and that's not helpful at all. [Fri Jun 16 23:53:28 2017] hi I'm reading https://spin.atomicobject.com/2012/11/11/unifying-programming-and-math-the-dependent-type-revolution/ [Fri Jun 16 23:53:57 2017] it says that in dependent types you can use a constant 2 and % (remainder) operator to create a type of odd numbers [Fri Jun 16 23:54:11 2017] how is this possible in Coq? [Sat Jun 17 00:09:02 2017] is it just made up bollocks and this sort of thing isn't possible? [Sat Jun 17 01:00:40 2017] the closest thing I can find is like on here (second answer) https://stackoverflow.com/questions/10834168/how-to-define-a-limited-domain-in-coq [Sat Jun 17 01:01:13 2017] where you could have { x : nat | is_odd x } [Sat Jun 17 02:03:00 2017] you can probably write { x : nat | x % 2 = 1 } [Sat Jun 17 04:12:40 2017] How can I see the precedence of a notation? "Print Visibility", "Print Scopes", "Locate notation" all don’t seem to include that info [Sat Jun 17 19:49:59 2017] hi irc, just a quick question. if you define "eq" with one less parameter, i'm pretty sure you get an equivalent type (as in, if you were to do "Inductive eq (A:Type) : A -> A -> Prop := ..." it works out fine), but does it work if you do it with no parameters at all? or do you define a weaker equality if you do so? [Sat Jun 17 19:53:52 2017] You can prove they are equivalent: http://lpaste.net/356317 [Sat Jun 17 19:54:39 2017] oh hey, thanks! [Sat Jun 17 19:54:49 2017] i'm gonna take a better look at this. [Mon Jun 26 21:15:29 2017] How would I prove 0 <> 1 using tactics. [Mon Jun 26 21:21:36 2017] lambda-11235: you can't, it's false [Mon Jun 26 21:23:15 2017] oh wait im a moron [Mon Jun 26 21:24:00 2017] lambda-11235: intro, then inversion on the hypothesis [Mon Jun 26 21:24:07 2017] intros H, inversion H. [Mon Jun 26 21:25:10 2017] you can "unfold not." as the first step to make it less magical. [Mon Jun 26 21:27:02 2017] benzrf, pacak: Thanks. [Mon Jun 26 23:30:21 2017] for 0 <> 1, just "discriminate" is likely sufficient [Tue Jun 27 03:03:24 2017] Anyone think they can break my hashing function? (this is just a fun challenge I made): http://ideone.com/nSJa45 Goal: Determine the plaintext of the following hash: d0c0c93dcff308d1 [Tue Jun 27 03:03:32 2017] This is an attempt to solve it: https://pastebin.com/raw/5cWSdmxe and another attempt: https://gist.github.com/arisada/122658db10c0868bba00c6f87547896b [Tue Jun 27 03:03:47 2017] 100USD to anyone who manages to solve/break it! :) [Tue Jun 27 03:07:53 2017] this spammer again.... [Tue Jun 27 03:08:18 2017] I keep disconnecting [Tue Jun 27 13:10:50 2017] hey guys! i'm trying to train myself with frama-c + wp by implementing exercizes on hackerrank. it's quite difficult for a newbie like me. do you know any github repository that tries to do that ? [Wed Jun 28 00:59:39 2017] if I have some random theorem about a type foo, is there any way to write down something generic that matches the theorem's type? [Wed Jun 28 00:59:48 2017] something like foo -> Prop, except that doesn't work [Wed Jun 28 01:39:27 2017] Error: Not the right number of induction arguments (expected ). [Wed Jun 28 01:39:32 2017] lovely [Wed Jun 28 01:43:31 2017] Yea, error messages are terrible :( [Wed Jun 28 01:44:24 2017] is there something in the manual somewhere that documents how custom induction hypotheses need to be laid out and then how to use them? [Wed Jun 28 01:44:33 2017] I have been unable to find anything, but maybe I'm dumb [Wed Jun 28 01:44:48 2017] and it's really unrewarding to experiment by trial and error [Wed Jun 28 01:45:28 2017] Manuals are also bad :) [Wed Jun 28 01:45:59 2017] dh`: software foundations shows some nice examples for induction hypotheses [Wed Jun 28 01:46:11 2017] I have some examples :-/ [Wed Jun 28 01:46:36 2017] the first time I did it, I spent hours arguing with "cannot recognize the branches of an induction hypothesis" [Wed Jun 28 01:47:05 2017] With explanations. At least after reading those I was able to write some of my own. But it might be related to my experience with haskell and other stuff. [Wed Jun 28 01:47:10 2017] right now I'm trying to write something that uses two props [Wed Jun 28 01:48:01 2017] I wrote the thing and proved it, trying to use it gives various brokenness but the one that seems to go farthest gives "Unable to find an instance for the variable P" [Wed Jun 28 01:48:34 2017] oh well, I'll have a look [Wed Jun 28 01:54:26 2017] ...so I try using "my_ind (fun _ => Prop)" and now it tells me that it can't unify (fun _ => Prop) x with string [Wed Jun 28 02:46:03 2017] that was unfortunately not that helpful [Wed Jun 28 02:46:03 2017] oh well [Wed Jun 28 02:46:05 2017] time to sleep [Wed Jun 28 03:01:38 2017] although the stuff about applying induction hypotheses directly without the induction tactic was kinda interesting [Wed Jun 28 03:02:28 2017] but I don't understand something [Wed Jun 28 03:03:19 2017] if you can apply a theorem of the form forall (P: thing -> Prop), stuff -> forall x, P x [Wed Jun 28 03:03:37 2017] to a goal of the form e.g. forall x, x = thingy [Wed Jun 28 03:03:59 2017] and it instantiates P with x = thingy [Wed Jun 28 03:04:29 2017] why... waitasec [Wed Jun 28 03:25:29 2017] still have a question? [Wed Jun 28 10:09:20 2017] i'm getting started with coq (having a background in agda). what is the resource that you use for day-to-day referencing? e.g. what certain coq commands or tactics do? [Wed Jun 28 10:11:05 2017] the regular old coq documentation website is pretty decent [Wed Jun 28 10:11:34 2017] also, what does the postfix @{} mean in "Lemma MyLemma@{} : SomeTime."? [Wed Jun 28 10:11:42 2017] sometype* [Wed Jun 28 10:12:17 2017] benzrf: okay, so you'd have a browser in the background with the list of all tacics open or something? [Wed Jun 28 10:12:24 2017] or you just kinda know them by heart [Wed Jun 28 10:15:08 2017] re: @{}, im not sure, i havent seen that [Wed Jun 28 10:15:21 2017] i mostly pull up the tactic list when i need to check something [Wed Jun 28 10:15:24 2017] the basic ones stick with u [Wed Jun 28 10:44:07 2017] what are the exclamation marks i see in front of some types and terms? [Thu Jun 29 01:03:01 2017] johnw: not last night :-) [Thu Jun 29 01:03:30 2017] although I do now [Thu Jun 29 01:03:44 2017] hi [Thu Jun 29 01:03:53 2017] I'm here this time, ask away [Thu Jun 29 01:04:41 2017] I can write "remember (fun (l m n: list A) => l ++ m ++ n = (l ++ m) ++ n) as P [Thu Jun 29 01:04:52 2017] and instantiate it with app_assoc when needed [Thu Jun 29 01:05:45 2017] but I don't suppose there's any way to transform that construct [Thu Jun 29 01:06:07 2017] e.g. if I were writing stuff on paper I might say P[B/A] to make a different prop that's about lists of B [Thu Jun 29 01:06:32 2017] I'm not following you [Thu Jun 29 01:06:44 2017] well, I can write that and get P [Thu Jun 29 01:07:03 2017] what I'd like to do is generate a Q that's the same except with, actually, list ascii replaced by string [Thu Jun 29 01:07:21 2017] (I'm still trying to find a general way to use list lemmas to prove string lemmas) [Thu Jun 29 01:08:04 2017] I can write down fun (l m n: string) => (l ++ m ++ n)%string = ((l ++ m) ++ n)%string [Thu Jun 29 01:08:10 2017] but that doesn't actually help [Thu Jun 29 01:08:18 2017] ++ in those two cases are different functions [Thu Jun 29 01:08:21 2017] (by the time you do that, you might as well just go and prove it directly) [Thu Jun 29 01:08:47 2017] yeah, so it actually needs to substitute both the type and the function [Thu Jun 29 01:09:08 2017] but I could still write that on paper as P[string/list ascii][append/app] [Thu Jun 29 01:11:20 2017] are you asking for a way to automatically transport proofs into proofs on other types and functions? [Thu Jun 29 01:11:20 2017] I can't do it as tactics using rewrite because one has to do both substitutions at once. [Thu Jun 29 01:11:24 2017] yeah [Thu Jun 29 01:11:32 2017] wrong type theory :) [Thu Jun 29 01:11:38 2017] heh, figures [Thu Jun 29 01:12:12 2017] there's a thing called heterogenous relations that will do what you wan [Thu Jun 29 01:12:13 2017] t [Thu Jun 29 01:12:18 2017] but, you'll still have to prove all the correspondences [Thu Jun 29 01:23:42 2017] last night's questions were prompted by trying to do an induction scheme using two props [Thu Jun 29 01:23:49 2017] (couldn't get it to go) [Thu Jun 29 01:25:00 2017] what I was hoping to do there was to be able to change a string goal to a related one about lists (or vice versa) [Thu Jun 29 01:26:06 2017] but even after I stopped trying to make the induction tactic accept my crazy things and just started applying them directly, I couldn't find a useful way to relate the prop on strings to the corresponding propon lists. [Thu Jun 29 01:26:11 2017] that can be done with a soundness proof [Thu Jun 29 01:26:33 2017] the relating can be done with heterogeneous relatinos [Thu Jun 29 01:27:10 2017] if you construct one from the other by applying the function that converts strings to lists of char... then all you get out is the original goal [Thu Jun 29 01:27:13 2017] you relate two domains, type A and B, with a series of proofs A -> B -> Prop that show how operations relate to each other. And then show that a proof on B can be satisfied by a proof on A. [Thu Jun 29 01:27:36 2017] that's what I've been trying to do! but apparently I suck [Thu Jun 29 01:27:48 2017] so, you want to do it with list ascii and string, right? [Thu Jun 29 01:27:53 2017] yeah [Thu Jun 29 01:28:00 2017] one sec [Thu Jun 29 01:28:24 2017] oh, a string is bijective with a list of ascii [Thu Jun 29 01:28:28 2017] so this is easy [Thu Jun 29 01:30:55 2017] maybe if you have the right angle to look at it from :-/ [Thu Jun 29 01:33:13 2017] does this help get you started: https://gist.github.com/becb22998827cba09a94e379c24a9643 [Thu Jun 29 01:33:34 2017] you should be able to write an induction principle for strings that inducts them as lists of ascii, etc. [Thu Jun 29 01:34:50 2017] that soundness proof is needless complicated, btw [Thu Jun 29 01:35:04 2017] I did not think of that denote_sound, let me see if that helps [Thu Jun 29 01:35:06 2017] already have the rest [Thu Jun 29 01:36:04 2017] these same tricks work even if there's only an adjunction, so it's a useful trick to play with [Thu Jun 29 01:58:39 2017] this doesn't seem to lead anywhere better :( [Thu Jun 29 02:00:11 2017] I think the kind of automation you're hoping for isn't something you're going to find [Thu Jun 29 02:00:25 2017] without doing just as much work as you're hoping to avoid [Thu Jun 29 02:05:30 2017] it's not so much work I'm hoping to avoid (already done most of it) as trying to come up with a tidy library [Thu Jun 29 02:06:02 2017] even if I can get something to work though I don't think it's going to be clean enough to put in the standard string library [Thu Jun 29 02:12:22 2017] everything I've come up with so far requires giving a string -> Prop and a list ascii -> Prop and a proof that they're equivalent... which in general seems to subsume the proof of the string prop [Thu Jun 29 02:13:48 2017] which is where the question about substitutions comes in: if I can make the list ascii -> Prop out of the string -> Prop then I can do that and supply a proof of the list prop [Thu Jun 29 02:14:03 2017] and since they're structurally equivalent it seems like it *ought* to be possible... [Thu Jun 29 02:14:10 2017] but it doesn't seem to actually work. [Thu Jun 29 02:15:25 2017] you should be able to turn any string -> Prop into a list ascii -> Prop just using composition [Thu Jun 29 02:33:34 2017] you can, but it doesn't get you any traction on anything [Thu Jun 29 02:35:20 2017] e.g. if you do that and try to prove append_assoc, what it does is change the goal (a ++ b ++ c)%string = ((a ++ b) ++ c)%string to (denote xs ++ denote ys ++ denote zs)%string = ((denote xs ++ denote ys) ++ denote zs)%string [Thu Jun 29 02:35:36 2017] which accomplishes roughly less than O(nothing) [Thu Jun 29 02:54:28 2017] I guess I'd need a real example at this point [Thu Jun 29 03:05:49 2017] I have ~400 lines of crap but nothing worth sharing [Thu Jun 29 03:06:55 2017] basically the goal is to prove this by using app_assoc: [Thu Jun 29 03:06:56 2017] Lemma append_assoc: [Thu Jun 29 03:06:56 2017] forall s t u, [Thu Jun 29 03:06:56 2017] (s ++ (t ++ u)%string)%string = ((s ++ t)%string ++ u)%string. [Thu Jun 29 03:07:15 2017] although it's probably a bad choice since it has three strings in it [Thu Jun 29 03:07:16 2017] ah, I see [Thu Jun 29 03:07:33 2017] let me try [Thu Jun 29 03:07:59 2017] maybe app_comm_cons would be easier [Thu Jun 29 03:08:42 2017] or rather [Thu Jun 29 03:08:54 2017] prove that by using app_assoc by applying generic machinery of some kind [Thu Jun 29 03:08:58 2017] you can do it directly [Thu Jun 29 03:09:44 2017] given [Thu Jun 29 03:09:45 2017] Lemma append_is_app: [Thu Jun 29 03:09:46 2017] forall s t, [Thu Jun 29 03:09:46 2017] string_of_charlist (charlist_of_string s ++ charlist_of_string t) = [Thu Jun 29 03:09:47 2017] (s ++ t)%string. [Thu Jun 29 03:10:48 2017] you rewrite with that, then use charlist_of_string (string_of_charlist cs) = cs [Thu Jun 29 03:10:54 2017] and that gets you something you can use app_assoc on [Thu Jun 29 03:11:00 2017] https://gist.github.com/1c13db1b314bb743d7e41d54a2b1703d [Thu Jun 29 03:11:01 2017] but that isn't generic [Thu Jun 29 03:11:45 2017] reify_append is a heterogenous relation [Thu Jun 29 03:11:58 2017] relating a function string -> string -> string to ... [Thu Jun 29 03:12:03 2017] but like I said [Thu Jun 29 03:12:10 2017] you don't get this for free, without building up the theory [Thu Jun 29 03:12:35 2017] for example, this lib makes things a bit easier: https://github.com/CertiKOS/coqrel [Thu Jun 29 03:12:42 2017] but it doesn't give you the library of theory that you'll need [Thu Jun 29 03:12:50 2017] hrmm [Thu Jun 29 03:13:24 2017] so [Thu Jun 29 03:14:11 2017] why didn't I write down reify_append last night in place of the append_is_app thing I posted above? [Thu Jun 29 03:14:17 2017] because I'm an idiot, apparently [Thu Jun 29 03:14:31 2017] * blames it on lack of sleep and trying to do this stuff at 3am [Thu Jun 29 03:14:41 2017] well, i've been working on computational reflection procedures for the last two weeks, so this is how I think about things right now [Thu Jun 29 03:23:30 2017] that's not an excuse :-) I know how to write the definition of a homomorphism [Thu Jun 29 03:24:48 2017] although actually I think what you've got there and what I had yesterday before I started screwing around with induction schemes aren't actually that different [Thu Jun 29 03:26:22 2017] and neither is very generic in the sense that I'm chasing after [Thu Jun 29 03:26:28 2017] I think what I'm chasing after isn't possible [Thu Jun 29 03:26:43 2017] at least for now I think you're right, but I could be convinced [Thu Jun 29 03:27:43 2017] (what I'm after is a proof of that with something like "induction s using magic. apply app_assoc." [Thu Jun 29 03:27:49 2017] ) [Thu Jun 29 03:31:42 2017] or as close to that as possible [Thu Jun 29 03:31:56 2017] I was thinking that yours is more ltac'able than my version, but I'm not sure it actually is [Thu Jun 29 03:32:25 2017] it's pretty ltac'able [Thu Jun 29 03:32:37 2017] why is apply denote_sound twice a nop? [Thu Jun 29 03:32:38 2017] you just need to recurse over the terms and break down all the possible operations [Thu Jun 29 03:33:15 2017] istm that it ought to tack on another denote (reify _) on each application [Thu Jun 29 03:33:28 2017] it's a bi-implication at the moment [Thu Jun 29 03:34:07 2017] even so, shouldn't it always go forward by default? [Thu Jun 29 03:34:16 2017] dunno [Thu Jun 29 03:35:09 2017] you can't rewrite with it even though it's a <->, at least in that context, so there must be something about matching the prop that's not behaving the way I expect [Thu Jun 29 03:35:36 2017] anyway I think I'll stop chasing this particular windmill [Thu Jun 29 03:36:35 2017] thanks for your help :-) [Thu Jun 29 03:36:55 2017] if you can call it that :) [Thu Jun 29 12:37:14 2017] is there any documentation on coq's type inference? [Sun Jul 9 02:38:14 2017] is there a theorem in the library that basically rewrite stuff like this : S n = 1 + n (I can't seem to find it ...) [Sun Jul 9 02:42:48 2017] reflexivity will solve that goal. if you need to do a rewrite you could assert it by reflexivity. [Sun Jul 9 02:42:59 2017] "S n" is definitionally the same as "1 + n". But you do have "plus_n_Sm: forall n m : nat, S (n + m) = n + S m" and "plus_Sn_m: forall n m : nat, S n + m = S (n + m)". In particular, "plus_Sn_m 0 n : 1 + n = S n" [Sun Jul 9 02:44:33 2017] Nat.add_1_l: forall n : nat, 1 + n = S n [Sun Jul 9 02:44:33 2017] Nat.add_1_r: forall n : nat, n + 1 = S n [Sun Jul 9 02:44:37 2017] These two seem to exist, too [Sun Jul 9 02:45:09 2017] hmm i tried search about and didn't find those, nice. [Sun Jul 9 02:45:23 2017] ok thank you both :) [Sun Jul 9 05:59:15 2017] is there some way to check if a tactic has changed something? e.g. I have some match goal ltac and in one of the cases I do a "simpl in H". for various reasons that can’t be the last case but sometimes this is a noop which results in "repeat mytactic" repeatedly running into that case and doing nothing [Sun Jul 9 06:00:01 2017] so I’d like to call "fail 1" if it doesn’t simpl anything [Sun Jul 9 06:02:38 2017] ah I think I can use progress [Sun Jul 9 06:04:52 2017] yep that works [Sun Jul 9 11:20:09 2017] hi… could someone explain the differences between the various *Arith trees in the standard library? [Sun Jul 9 11:28:25 2017] ah, nevermind, figured it out [Sun Jul 9 15:44:58 2017] how can I get the term associated with a name in an ltac macro? If I define "Ltac mytac H := match H with …" and then pass the name of a hypothesis to mytac it doesn’t match on the hypothesis but on the name itself [Sun Jul 9 15:46:33 2017] let t := type of H in match t with ..." [Sun Jul 9 15:46:36 2017] " [Sun Jul 9 15:46:42 2017] Is that what you need? [Sun Jul 9 15:47:33 2017] Cypi: perfect, thanks! [Sun Jul 9 15:47:59 2017] makes sense now that I think about it [Mon Jul 10 03:05:40 2017] http://iris-project.org/ [Mon Jul 10 03:05:49 2017] what would be a simple explanation of what iris really is? [Mon Jul 10 03:05:58 2017] the documentation is a bit over my head [Mon Jul 10 03:07:09 2017] I guess it's a construction of a category with limits that lets you model computation, has fixed points and an = operator that looks past computing steps roughly..? [Mon Jul 10 12:13:20 2017] hi… is there a way to "open"/instantiate a whole Section? [Mon Jul 10 12:13:50 2017] like opening EqualityModulo for a specific N [Mon Jul 10 12:37:19 2017] ertes-w: no. sections get "erased" as soon as you close them, by adding all the Variables/Hypotheses to each definition. [Mon Jul 10 12:40:54 2017] jrw: is there a way to achieve that kind of abstraction? perhaps through the module system? [Mon Jul 10 12:41:09 2017] ertes-w: yes, you could use a functor for that. [Mon Jul 10 12:41:39 2017] jrw: what is the usual way to do this? or is it generally not done? [Mon Jul 10 12:41:55 2017] but you'd have to rewrite the library to be a functor instead of a section. [Mon Jul 10 12:43:09 2017] I'll cook up an example, one sec. [Mon Jul 10 12:48:31 2017] ertes-w: https://github.com/wilcoxjay/notes/blob/master/FunctorExample.v [Mon Jul 10 12:50:50 2017] jrw: thanks! [Mon Jul 10 12:51:48 2017] is Module Type necessary? agda lets one just parameterise modules the way you parameterise everything [Mon Jul 10 12:51:52 2017] which is really convenient [Mon Jul 10 12:52:03 2017] afaik, it is required. [Mon Jul 10 12:52:39 2017] ok, thanks a lot for your help [Mon Jul 10 14:01:07 2017] sounds like agda is smarter [Mon Jul 10 14:01:42 2017] coq modules are like ml modules; they're (gratuitously) different from other program elements, so functor application is gratuitously different from other application [Mon Jul 10 16:20:40 2017] hi, i want to probe the target: S (pn + pn * m + m) = S (pn + m + pn * m) I've a proof that plus is commutative but can't get it to apply to the second sum. [Mon Jul 10 16:20:49 2017] How can I do that? [Mon Jul 10 16:22:15 2017] I want: S (pn + m + pn * m) = S (pn + m + pn * m). But if I 'rewrite plus_comm', I get S (m + (pn + pn * m)) = S (pn + m + pn * m) [Mon Jul 10 16:26:09 2017] argent0: the issue is that + is left associative, so pn + pn * m + m means (pn + pn * m) + m. one option is to first rewrite by associativity, and then use commutativity. [Mon Jul 10 16:28:42 2017] jrw: ok, thanks for the heads up. [Mon Jul 10 17:04:02 2017] * finishes ½ hour later [Tue Jul 11 00:34:42 2017] is there a way to multiply an equation on both sides with a nat ?(I want to get rid of a fraction) [Tue Jul 11 00:41:47 2017] and is there an automation mechanism that can handle fractions with variables ? [Tue Jul 11 00:46:21 2017] f_equal? [Tue Jul 11 00:50:32 2017] pacak: yes , thank you :) [Tue Jul 11 06:39:15 2017] Hi, is there a way to create an Ordinal option from a nat in mathcomp? [Tue Jul 11 06:40:39 2017] I am trying to write a specification that takes a nat x and a range [0, ..., n-1], and if (x < n) outputs Some (Ordinal (x < n)), otherwise None [Wed Jul 12 04:23:42 2017] why does "clear - H" sometimes do nothing instead of clearing everything except for H? [Wed Jul 12 04:25:19 2017] ah I think it’s dependencies [Wed Jul 12 04:26:11 2017] so is there something like "clear -" that errors if clearing all hypothesis except for H is not possible instead of silently doing nothing? [Wed Jul 12 04:30:24 2017] nvm, that doesn’t help me either [Wed Jul 12 19:47:07 2017] what is the way to type annotate something that has parateterized type (like a list) ? [Wed Jul 12 19:48:18 2017] do you mean: [1; 2] : list nat? [Wed Jul 12 19:50:19 2017] ah ok , then I have a follow up question : what is the "%" used for (I thought this was used for type annotation)? [Wed Jul 12 19:57:10 2017] that's a notation scope [Wed Jul 12 19:57:18 2017] it indicates how syntax should be interpreted by the parser [Wed Jul 12 19:57:26 2017] [1%nat; 2%nat] : list nat [Wed Jul 12 19:57:37 2017] that would work even if the nat_scope was not open [Wed Jul 12 19:58:30 2017] ok thank you :) [Wed Jul 12 21:08:53 2017] Hi Everyone [Wed Jul 12 21:09:15 2017] I am trying to prove Lemma paul_alt : forall (a:R) (b:R) (eps:R), [Wed Jul 12 21:09:15 2017] (eps >= 0 -> a <= b + eps) -> a <= b. [Wed Jul 12 21:09:26 2017] http://lpaste.net/356902 [Wed Jul 12 21:09:57 2017] But I have feeling that it is not true statement, but not sure. [Wed Jul 12 21:31:13 2017] That's not true, indeed [Wed Jul 12 21:32:08 2017] This should be better: "Lemma paul_alt : forall (a:R) (b:R), (forall (eps:R), eps >= 0 -> a <= b + eps) -> a <= b." [Wed Jul 12 21:32:22 2017] but this is also not very interesting, since just taking "esp = 0" would prove easily the goal [Wed Jul 12 21:32:32 2017] now with "eps > 0", that would be more interesting x) [Wed Jul 12 21:33:18 2017] Cypi: Thank you. [Thu Jul 13 02:42:31 2017] bah [Thu Jul 13 02:42:45 2017] is there any way to put constructors in a typeclass? [Thu Jul 13 02:43:42 2017] (as in, the class is a class of types that have constructors of these forms...) [Thu Jul 13 02:43:55 2017] you can enter them as functions, but then you can't match. [Thu Jul 13 02:45:24 2017] I suppose it's problematic [Thu Jul 13 02:47:49 2017] dh`: you can go the universal algebra route [Thu Jul 13 02:47:56 2017] describe them using sorts and arities [Thu Jul 13 02:49:59 2017] an example, from Conor McBride: https://gist.github.com/a8d31300233746453f5f3b76c0834c48 [Thu Jul 13 02:58:50 2017] I think that makes my head hurt [Thu Jul 13 02:58:53 2017] :-) [Thu Jul 13 02:59:20 2017] (it doesn't look like it's actually all that complicated, but coq notation isn't being friendly to it) [Thu Jul 13 02:59:39 2017] it made my brain hurt a lot too [Thu Jul 13 02:59:50 2017] but mainly because I hadn't yet read any universal algebra when I first encountered it [Thu Jul 13 03:00:07 2017] think of it as "reifying interfaces", which avoids the function type matching problem you mentioned [Thu Jul 13 03:00:28 2017] you're turning a description of the type class constructors into a list of values [Thu Jul 13 03:00:44 2017] which you can denote back to function types [Thu Jul 13 03:08:17 2017] I'm trying something else, namely a member "matchme" whose type is t -> {t = ctor1 ...} + {t = ctor2 ...} [Thu Jul 13 03:08:29 2017] but it's not working [Thu Jul 13 03:09:18 2017] I can successfully match and get left P or right Q, but I don't see how to extract the constructor expression from P [Thu Jul 13 03:09:39 2017] (it's there in the typeclass, but the pattern match syntax won't do it) [Thu Jul 13 03:09:52 2017] or I'm doing it worng [Thu Jul 13 03:41:21 2017] all right, this doesn't work and I need to sleep [Thu Jul 13 03:41:41 2017] sleep helps, where Coq is concerned [Thu Jul 13 19:48:47 2017] hi, I have 'Fixpoint split ...' and in a proof I want to `unfold` it. And I get "Cannot coerce split to an evaluable reference." [Thu Jul 13 19:50:28 2017] I believe that it is a confusion with the split tactic (related to the constructor tactic). Is there a way to make explicity that I'm refering to the fixpoint? [Thu Jul 13 19:50:46 2017] other than renaming the fixpoint [Thu Jul 13 19:54:27 2017] it should not be the problem. It looks more like "split" is opaque in your case [Thu Jul 13 19:54:56 2017] Could you maybe provide more details? [Thu Jul 13 19:55:49 2017] See http://lpaste.net/356920 for instance [Thu Jul 13 19:55:57 2017] after calling "Opaque split.", I cannot unfold it anymore [Thu Jul 13 19:56:22 2017] Cypi: well, I'm following the software foundations book. And I had defined split in the wrong file. So it was something like: Fixpoint split ... Admitted. Sorry [Thu Jul 13 19:56:38 2017] Oh, alright [Thu Jul 13 19:56:46 2017] Thanks anyway [Fri Jul 14 03:08:11 2017] I’m trying to "fold to_tpair_list" in a goal but for some reason nothing happens. what could be causing this? you can see the goal and the definition here http://lpaste.net/356931 [Sat Jul 15 12:33:03 2017] opaque is really opaque, right? [Sat Jul 15 12:33:16 2017] as in, if I wrote [Sat Jul 15 12:33:18 2017] Definition ZZ := 0. [Sat Jul 15 12:33:18 2017] Definition SS x: nat := x. [Sat Jul 15 12:33:18 2017] Opaque ZZ. [Sat Jul 15 12:33:18 2017] Opaque SS. [Sat Jul 15 12:33:47 2017] and then wrote down a bunch of arithmetic stuff about SS and ZZ, such that unfolding SS and ZZ would easily let me prove False, it's still safe [Sat Jul 15 12:34:49 2017] (that would be a silly thing to do, but I'm thinking about modeling concurrency where life is a lot harder) [Sat Jul 15 12:36:37 2017] that seems like a bad idea to me... [Sat Jul 15 12:36:40 2017] i don't know the answer, though [Sat Jul 15 12:41:16 2017] nobody does :-) [Sat Jul 15 12:42:15 2017] basically if you want to model something concurrent as coq code (rather than as abstract syntax) you need to be able to destroy state at times [Sat Jul 15 12:42:57 2017] and so you need: Definition havoc: {T: Type} (x: T) := x. [Sat Jul 15 12:43:13 2017] but if it's not really and truly opaque it exposes that you haven't changed the value of x. [Sat Jul 15 12:43:36 2017] (the intent is to destroy existing knowledge about the value) [Sat Jul 15 13:27:20 2017] w-what [Sat Jul 15 13:27:26 2017] oh i see [Sat Jul 15 13:27:41 2017] well... don't model something concurrent as coq code rather than as abstract syntax [Sat Jul 15 13:27:43 2017] >:[ [Sat Jul 15 13:29:23 2017] or perhaps do something like [Sat Jul 15 13:29:39 2017] Axiom havoc : forall T, T -> T. [Sat Jul 15 14:00:54 2017] hmm, that's probably a better idea [Sat Jul 15 14:01:52 2017] and should ultimately be equivalent [Sun Jul 16 00:26:42 2017] meh: [Sun Jul 16 00:26:43 2017] Require Import OrderedType OrderedTypeEx. [Sun Jul 16 00:26:43 2017] Require MSetAVL. [Sun Jul 16 00:26:43 2017] Module NatSet := MSetAVL.Make Nat_as_OT. [Sun Jul 16 00:26:43 2017] Error: The field eq_equiv is missing in Coq.Structures.OrderedTypeEx.Nat_as_OT. [Sun Jul 16 00:27:17 2017] is that because it needs Orders and OrdersEx? [Sun Jul 16 00:27:44 2017] hmm, apparently so [Sun Jul 16 00:55:28 2017] ...why, if you have a system of Inductives on say expressions and statements and declarations and whatnot [Sun Jul 16 00:55:41 2017] (that are mutually recursive so they have to be one group) [Sun Jul 16 00:55:59 2017] does coq insist that the arguments to each inductive be the same? [Sun Jul 16 00:56:07 2017] or, I think, just the arity be the same? [Sun Jul 16 00:56:17 2017] this seems extremely stupid and it's extremely annoying [Sun Jul 16 00:56:31 2017] (since typically expressions are typed and statements aren't) [Sun Jul 16 13:56:39 2017] dh`: what do you mean? different inductive definitions within a mutual group can have different types/arities. [Tue Jul 18 12:19:43 2017] I have some goals (introduced by a parametricity tactic) in my context, which are named like _x_, _y_, etc. Can I somehow refer to them without Coq complaining about reserved identifiers? [Tue Jul 18 12:20:02 2017] Sorry, not goals, terms [Tue Jul 18 12:21:23 2017] probably at worst you can write an ltac that matches their names and renames them [Tue Jul 18 12:28:38 2017] dh`: Thanks! Any references/examples around? [Tue Jul 18 12:28:47 2017] dunno sorry :( [Tue Jul 18 12:28:59 2017] no problem [Wed Jul 19 15:45:06 2017] hi, I have a beginner's question, I don't know if this is the palce to ask... I'm trying to prove a theorem about an inductively defined proposition, but the statement of the theorem rules out the base case. However, induction asks me to prove it and gives me no assumptions to work with, any suggestions? [Wed Jul 19 15:58:26 2017] lfish: can you show us what you currently have? [Wed Jul 19 15:58:56 2017] I suspect that you need to use a combination of "remember" and "generalize dependent" or alternatively "dependent induction" but I’m not entirely sure I understand your problem [Wed Jul 19 16:00:50 2017] yes, the statement of the theorem is Theorem subseq_cons__subseq : forall (X : Type) (x : X) (xs l : list X), subseq (x :: xs) l -> subseq xs l. [Wed Jul 19 16:01:27 2017] and the case that's troubling me is from Inductive subseq {X : Type} : list X -> list X -> Prop := | empty_subseq : forall l, subseq [] l | cons_seq_subseq : forall (x : X) (s l : list X), subseq s l -> subseq s (x :: l) | cons_both_subseq : forall (x : X) (s l : list X), subseq s l -> subseq (x :: s) (x :: l). [Wed Jul 19 16:01:47 2017] can you add your Coq file to some pastebin service and give us the link? [Wed Jul 19 16:02:05 2017] reading things without linebreaks and indentation is hard :) [Wed Jul 19 16:02:14 2017] I'm sorry, I'm new at this [Wed Jul 19 16:02:47 2017] paste your code here http://lpaste.net/ and then give us the link [Wed Jul 19 16:05:05 2017] This seems to work. https://pastebin.com/Ks6f216X [Wed Jul 19 16:10:19 2017] http://lpaste.net/357049 that's in lpaste in case the other one didn't work [Wed Jul 19 16:10:29 2017] give me a minute [Wed Jul 19 16:11:57 2017] alright, so I guess you are trying to do induction on "subseq (x :: xs) l"? [Wed Jul 19 16:19:25 2017] time to go to bed for me so I can’t walk you through the solution but http://lpaste.net/357050 works [Fri Jul 21 11:23:04 2017] is there an induction lemma for lists somewhere in the standard library which gives me an "In x original_list" in the cons case? [Fri Jul 21 11:38:57 2017] hm actually I’d like something like http://lpaste.net/357089 but I’m too stupid to prove that :/ [Fri Jul 21 11:39:37 2017] I need to strengthen something somewhere :) [Fri Jul 21 12:34:22 2017] cocreature: how about this? https://github.com/wilcoxjay/notes/blob/master/ListInductionWithPrefix.v [Fri Jul 21 12:36:17 2017] jrw: perfect, thanks a ton! [Fri Jul 21 12:57:47 2017] cocreature: I was able to do it directly without thinking too hard, just applying whatever seemed like it would solve the goal http://lpaste.net/357092 [Fri Jul 21 13:06:34 2017] Cale: huh right, now I feel silly for not figuring out that myself. I guess I didn’t get enough sleep last night :) thanks! [Sat Jul 22 21:02:15 2017] <__marioxcc> Hello. [Sat Jul 22 21:03:03 2017] <__marioxcc> What is the benefit of a using constructive framework for the logic system of Coq? I am new to proof verifiers/assistants and I am honestly not very interested in constructive logic. "Should" I learn Coq or look for something else? [Sat Jul 22 22:03:31 2017] __marioxcc: Coq is a good one to learn. [Sat Jul 22 22:04:10 2017] <__marioxcc> Cale: How does it compare with other proof assistants/verifiers? [Sat Jul 22 22:04:14 2017] The reason is that we'd like for the logic to also be a programming language. There's a lot of benefit in general to regarding proofs of theorems as programs. [Sat Jul 22 22:04:46 2017] <__marioxcc> Does that have any practical use if one is not interested in program extraction? [Sat Jul 22 22:05:24 2017] <__marioxcc> I am interested in writing a formalization of chemical notation (since the current standard is full of nosense; I believe only a formal and computer-verified definition will be satisfactory). [Sat Jul 22 22:05:34 2017] Well, if you think about it, we actually do this all the time in mathematics [Sat Jul 22 22:05:41 2017] Though we think about it a little differently [Sat Jul 22 22:06:09 2017] Often you'll see someone refer to "the such and such thing which whose existence was guaranteed by Theorem 3.5" [Sat Jul 22 22:06:31 2017] So we sort of use theorems as if they were functions quite a bit [Sat Jul 22 22:07:04 2017] <__marioxcc> Ugh. I really have a hard time seeing it that way. [Sat Jul 22 22:07:12 2017] One interesting thing is that the underlying theory is a higher order logic instead of a first order logic. [Sat Jul 22 22:07:53 2017] <__marioxcc> but computerized higher order logic is basically obligued to use Henkin semantics, which make it more or less equivalent to first order logic. [Sat Jul 22 22:07:53 2017] __marioxcc: Maybe it'll help to explain the connection between logic and lambda calculus a bit :) [Sat Jul 22 22:08:07 2017] (Unless you're already familiar with it?) [Sat Jul 22 22:08:57 2017] <__marioxcc> Not familiar, but I know what the Howard-Curry correspondency is about. [Sat Jul 22 22:09:06 2017] okay [Sat Jul 22 22:09:13 2017] So in logic, if we want to prove A -> B, we start by assuming that A holds, and try to form a proof of B from there, and if we succeed, natural deduction says we can conclude A -> B [Sat Jul 22 22:10:04 2017] In lambda calculus, if we want to construct a function of type A -> B, we start by introducing a variable x : A, and try to form a term e : B, and if we succeed, then λ(x:A).B : A -> B [Sat Jul 22 22:10:06 2017] <__marioxcc> I think you mean Hedlund theorem. [Sat Jul 22 22:10:43 2017] <__marioxcc> Natural deduction is the style of deduction systems where assuming A and then proving B actually proves directly A -> B, AFAIK. [Sat Jul 22 22:10:54 2017] <__marioxcc> But I get the point. :) [Sat Jul 22 22:11:03 2017] Yeah, that's sort of what I'm talking about [Sat Jul 22 22:11:19 2017] Sometimes that's a metatheorem, sometimes it's just how we formulate the logical rule [Sat Jul 22 22:11:26 2017] <__marioxcc> Right. [Sat Jul 22 22:11:35 2017] In logic, if we have both that A -> B, and that A, we may conclude B (modus ponens) [Sat Jul 22 22:11:51 2017] In lambda calculus, if we have f: A -> B, and x: A, we can construct f x: B [Sat Jul 22 22:12:42 2017] <__marioxcc> Yes. [Sat Jul 22 22:12:49 2017] All the other logical connectives have similar connections: conjunction /\ corresponds to product types, and disjunction corresponds to sum types (discriminated unions) [Sat Jul 22 22:13:19 2017] <__marioxcc> What about "non-logical" axioms like ZF separation, choice, large cardinals and so on? [Sat Jul 22 22:14:09 2017] So, in MLTT and systems like the one Coq is based on, there's enough expressive power to do quite a lot of mathematics without any axioms at all -- you just need the logical rules which come in corresponding introduction/elimination pairs [Sat Jul 22 22:14:23 2017] But adding in axioms is something you can do [Sat Jul 22 22:15:45 2017] However, it spoils the computational nature of the logic, because the rules correspond nicely to things with universal mapping properties if you're thinking categorically, and that lets you "simplify" proofs which introduce and then eliminate them [Sat Jul 22 22:15:59 2017] <__marioxcc> Ugh, that is something I don't like. [Sat Jul 22 22:16:24 2017] <__marioxcc> I have the idea that logic should have weak consistency strenght, so it shouldn't be possible to do "interesting" things with it without further axioms. [Sat Jul 22 22:17:16 2017] <__marioxcc> Is there any sense in which "proofs are programs and programs are proofs" with "non-constructive" axioms like "there exist an unreachable cardinal from aleph_0"? [Sat Jul 22 22:17:18 2017] Well, mainly what gets you the additional strength is dependent types: Pi and Sigma [Sat Jul 22 22:17:28 2017] which in some sense correspond to forall and exists in logic [Sat Jul 22 22:17:39 2017] <__marioxcc> Ok. [Sat Jul 22 22:17:53 2017] But since types sort of keep track of *which* proofs exist, they also behave a lot like sets [Sat Jul 22 22:18:52 2017] Where when we're thinking in a purely "logical" way, we might ignore everything about that set apart from whether or not it's inhabited [Sat Jul 22 22:19:52 2017] It just turns out that once you start keeping track of the reasons for things everywhere, you get something which looks very similar to set theory (only a little different) [Sat Jul 22 22:21:04 2017] <__marioxcc> I guess I will understand that only after learning how to actually use it. [Sat Jul 22 22:21:10 2017] The main difference between saying that x has type A and x is an element of A being that x doesn't necessarily belong to any other type at all. [Sat Jul 22 22:21:52 2017] <__marioxcc> Yes, I know that in simple type theory variables can only belong to a single type. [Sat Jul 22 22:22:38 2017] So, if we want to express something like "The even natural numbers" as a type, we're more likely to use something like [Sat Jul 22 22:22:39 2017] <__marioxcc> Cale: What are the practical differences between Coq and other proof assistants? Since I am unfamiliar with all of them, I have only had time so far to glance at the tutorials of some of them (Coq, HOL-Light and HOL4) [Sat Jul 22 22:22:44 2017] Sigma (n:Nat), Even n [Sat Jul 22 22:22:55 2017] where Even n is the type of proofs that n is an even natural number [Sat Jul 22 22:23:37 2017] and Sigma (x:A), B(x) is the type of pairs (a,p) where a : A and p : B a, that is the type of the second part of the pair depends on the value of the first [Sat Jul 22 22:23:51 2017] <__marioxcc> Ok, that is completely new for me. [Sat Jul 22 22:24:09 2017] <__marioxcc> Cale: Have you used any of the HOL* family? [Sat Jul 22 22:24:12 2017] So, we'd have a type of natural numbers, paired up with proofs that they're even [Sat Jul 22 22:24:21 2017] I haven't yet actually [Sat Jul 22 22:24:27 2017] I've used Coq and Agda [Sat Jul 22 22:24:41 2017] and to some extent Idris (though it's more of a programming language than a proof assistant) [Sat Jul 22 22:24:53 2017] <__marioxcc> I see. [Sat Jul 22 22:24:59 2017] and I've looked at other things but I don't really have a lot of experience using them [Sat Jul 22 22:25:07 2017] <__marioxcc> *why* did you choose Coq and Agda instead of other proof assistant? [Sat Jul 22 22:25:29 2017] <__marioxcc> That's the main question for me. I'd like to know how they compare in practice. [Sat Jul 22 22:25:40 2017] Well, I just woke up one day after programming in Haskell for a decade or so, and just realised that I already knew how to use Coq. [Sat Jul 22 22:26:15 2017] Just through random exposure to bits and pieces [Sat Jul 22 22:27:01 2017] <__marioxcc> I see. I know the basics of Haskell but I have not written anything non-trivial with it. [Sat Jul 22 22:27:07 2017] Agda is also very similar in nature to Coq and Haskell -- it sort of looks like Haskell with a fancy type system and a standard library filled with unicode symbols [Sat Jul 22 22:27:44 2017] Coq tends to look different, in that you write proofs using "tactics", but the underlying type system is very similar [Sat Jul 22 22:28:14 2017] <__marioxcc> Is there no "tactics" automation in Agda? [Sat Jul 22 22:28:15 2017] Isn't HOL still based on type theory? [Sat Jul 22 22:28:27 2017] Not as far as I'm aware [Sat Jul 22 22:28:52 2017] It's something that would make sense adding to Agda, but culturally, Agda is sort of an experiment in where you can get just writing proof terms directly. [Sat Jul 22 22:29:07 2017] <__marioxcc> Ok. [Sat Jul 22 22:29:41 2017] <__marioxcc> lambda-11235: HOL4 describes the underlying logic as a specific type theory. [Sat Jul 22 22:29:57 2017] <__marioxcc> http://sourceforge.net/projects/hol/files/hol/kananaskis-11/kananaskis-11-logic.pdf/download [Sat Jul 22 22:35:50 2017] __marioxcc: One nice thing is that apart from having a model in sets, dependent type theories can also have a models in other locally Cartesian closed categories. Homotopy type theory explores the idea that type theory can be used to study homotopy types [Sat Jul 22 22:36:20 2017] <__marioxcc> I see, but I don't know any category theory. [Sat Jul 22 22:36:21 2017] So there, they tend to regard types not only as logical propositions, but more generally as something like topological spaces up to homotopy equivalence [Sat Jul 22 22:36:42 2017] <__marioxcc> Ok, that makes a bit more sense for me. :) [Sat Jul 22 22:37:03 2017] and then the identity type Id A x y, which we'd usually regard as the proposition that x = y in the type A, can be interpreted as the space of paths between x and y in A. [Sat Jul 22 22:37:53 2017] and anything which can be carried out in plain type theory automatically turns into the construction of points in a particular space [Sat Jul 22 22:38:15 2017] <__marioxcc> That sounds nice. [Sat Jul 22 22:38:20 2017] <__marioxcc> Where can I read more about it? [Sat Jul 22 22:38:26 2017] <__marioxcc> I am familiar with elementary topology. [Sat Jul 22 22:38:32 2017] https://homotopytypetheory.org/ [Sat Jul 22 22:38:35 2017] there's a book there [Sat Jul 22 22:38:40 2017] https://homotopytypetheory.org/book/ [Sat Jul 22 22:39:50 2017] <__marioxcc> Thanks you. [Sat Jul 22 22:40:31 2017] A really interesting little thing about it is that if you try to incorporate the law of excluded middle as an axiom (in its most general form), it kills this interpretation by making all your spaces discrete [Sat Jul 22 22:40:43 2017] But there are more restricted forms of LEM which still work [Sat Jul 22 22:41:37 2017] <__marioxcc> I see. [Sat Jul 22 22:42:07 2017] <__marioxcc> Too bad that this nice connection with topology trivializes under classical mathematics. [Sat Jul 22 22:42:40 2017] It's still expected that most or all of classical mathematics should be formalisable in here, with a little tweaking [Sat Jul 22 22:43:32 2017] Like, you might not get LEM for *all* types, but there's a class of types which are especially proposition-like (those types P which for any x and y of type P, we have x = y) [Sat Jul 22 22:43:58 2017] <__marioxcc> Ok. [Sat Jul 22 22:43:59 2017] and LEM will hold for those, and you can also have a classical-style Axiom of Choice for set-like types without spoiling things [Sat Jul 22 22:44:14 2017] Or rather LEM won't immediately hold for those, but you can add an axiom to make it hold [Sat Jul 22 22:44:34 2017] <__marioxcc> Cale: Why not add the ZF(C) axioms to Coq and then use the rest as the underlying logic? [Sat Jul 22 22:45:28 2017] Something like that is doable -- you can pose an element-of relation and the ZFC axioms for it [Sat Jul 22 22:45:37 2017] <__marioxcc> Ok. [Sat Jul 22 22:45:37 2017] It's just... ZFC isn't really terribly usable in reality [Sat Jul 22 22:46:17 2017] If you actually want to formalise a significant amount of stuff, first order set theory gets really tedious. [Sat Jul 22 22:46:41 2017] <__marioxcc> Well, metamath has formalized a non-trivial part of mathematics using only ZFC (with proper classes as an extension) http://us.metamath.org/mpeuni/mmset.html [Sat Jul 22 22:46:51 2017] We sort of pretend in mathematics that everything ought to be formalisable in ZFC, but rarely do we actually *do* it. [Sat Jul 22 22:47:22 2017] Yeah, metamath changes the underlying logic a bit from how ZFC is usually described, but it's pretty close [Sat Jul 22 22:47:24 2017] <__marioxcc> Could you point to something that can be formalized within ZF(C) in principle, but it is impractical? [Sat Jul 22 22:47:41 2017] However, I wouldn't hold it up as an argument against the idea that it's tedious :) [Sat Jul 22 22:47:49 2017] <__marioxcc> Metamath uses *exactly* ZFC as far as I can tell. [Sat Jul 22 22:47:53 2017] <__marioxcc> Yes, it is tedious indeed. [Sat Jul 22 22:48:59 2017] Like, most of the stuff they've already accomplished with metamath, I would consider extremely impractical as it is. [Sat Jul 22 22:49:09 2017] <__marioxcc> There is really no built-in underlying logic for Metamath, but the "set.mm" database uses an ordinary formalization of classical propositional and first order logic. [Sat Jul 22 22:50:01 2017] <__marioxcc> I agree that metamath is impractical, but is it because it uses ordinary first order logic (in set.mm) or is it because it has virtually no automation? [Sat Jul 22 22:50:22 2017] <__marioxcc> Basically the only automation is proving the well-formedness of the terms that appear in a proof. [Sat Jul 22 22:50:58 2017] <__marioxcc> So I'm not sure that Metamath is impractical because it uses ZFC with classical logic. [Sat Jul 22 22:51:40 2017] <__marioxcc> Bear in mind that Metamath is intended to be minimalistic, It has only substitution of variable as built-in logic, not even propositional logic is built-in. [Sat Jul 22 22:51:55 2017] It's a bit of both. Agda has very little automation as well, and accomplishing similar goals in that will generally be much easier just because it's got nice ways of structuring things. [Sat Jul 22 22:52:35 2017] (though the automation which is there in Agda you'll generally want to use too -- it can help you deal with splitting cases, and finding things in scope which have the right type and so on) [Sat Jul 22 22:52:57 2017] Come to think of it, those bits of automation are only possible because of the types [Sat Jul 22 22:53:12 2017] <__marioxcc> Ok. [Sat Jul 22 22:53:30 2017] <__marioxcc> Well, I have to go to sleep. It's 21:53 here and I have to wake early tomorrow. [Sat Jul 22 22:53:36 2017] All right, see you around! [Sat Jul 22 22:53:40 2017] <__marioxcc> Thanks for the information!. Good bye! [Sun Jul 23 18:43:31 2017] a few weeks ago i investigated the 'lean' proof assistant… it seemed to be much smarter about automating things, but was otherwise very similar to coq [Sun Jul 23 18:49:26 2017] i've also looked HOL light, but even though it seems to have a vast library of predefined stuff and i liked the way "tactics" are really just functions, it was really awkward to use [Sun Jul 23 18:49:35 2017] *looked into [Mon Jul 24 09:30:10 2017] is there a tactic to do ring *rewrites*? [Mon Jul 24 09:30:27 2017] like rewrite 8 to 3 + 1*5 [Mon Jul 24 09:31:15 2017] ertes-w: "replace 8 with (3 + 1*5) by omega"? [Mon Jul 24 09:32:31 2017] oh, nice [Mon Jul 24 09:32:43 2017] thanks [Mon Jul 24 09:32:45 2017] you need to import omega from somewhere [Mon Jul 24 09:33:10 2017] yeah, i just did… so is omega the "just do it" tactic? i have used 'ring' so far [Mon Jul 24 09:33:24 2017] I’ve actually never used ring :) [Mon Jul 24 09:33:29 2017] so not sure [Mon Jul 24 09:34:16 2017] looks like omega is only for presburger arithmetic [Mon Jul 24 09:34:52 2017] and only for nat and Z [Mon Jul 24 09:35:21 2017] although in your case since everything is constant "by reflexivity" should work too [Mon Jul 24 09:36:12 2017] ah, i think i'm starting to understand how "rewrite … by" works [Mon Jul 24 09:36:30 2017] so yeah, ring seems to be more powerful in fact [Mon Jul 24 09:38:17 2017] not sure about that. omega is a decision procedure so it should always work when it’s applicable. afaict ring is based on a bunch of simplifications followed by a syntactic equality check so I wouldn’t be surprised if there are things omega can solve that ring can’t solve [Mon Jul 24 09:53:17 2017] so far whenever i thought, "this should follow from the ring axioms", 'ring' worked [Mon Jul 24 09:54:30 2017] apparently it rewrites the expressions to a polynomial that is unique modulo the ring axioms, and if the results are syntactically equal, it uses reflexivity [Mon Jul 24 09:54:42 2017] which is exactly what i need most of the time [Mon Jul 24 11:04:22 2017] one example of a difference: omega understands less-than but ring doesn't. [Mon Jul 24 11:39:38 2017] ah [Mon Jul 24 19:45:43 2017] dot_assoc : forall {A B C D} (f : Hom C D) (g : Hom B C) (h : Hom A B), dot (dot f g) h = dot f (dot g h) [Mon Jul 24 19:46:13 2017] is there any way to shorten this? i thought something like: forall f g h, dot (dot f g) h = dot f (dot g h) [Mon Jul 24 19:46:31 2017] but coq doesn't seem to want to invent implicit arguments [Mon Jul 24 19:47:43 2017] also is the following good enough? Class Category (Ob : Type) (Hom : Ob → Ob → Type) … [Mon Jul 24 19:47:43 2017] [Mon Jul 24 19:47:51 2017] i feel like i'm running into a universe problem there [Mon Jul 24 19:48:12 2017] but i don't really know how coq deals with universes and universe polymorphism [Mon Jul 24 19:51:03 2017] ok, i can abbreviate (g : Hom B C) to just g [Mon Jul 24 19:51:12 2017] but that's not really the point [Mon Jul 24 20:11:30 2017] Hi, this link does not work :-( https://www.msr-inria.fr/news/feit-thomson-proved-in-coq/ [Wed Jul 26 21:21:39 2017] hi, I'm very new to Coq, so I apologize if my question is stupid. I was trying to prove something, and I needed to rewrite (foo x + 0) to foo x [Wed Jul 26 21:21:55 2017] i was looking for an appropriate lemma, and found https://coq.inria.fr/library/Coq.Arith.Plus.html [Wed Jul 26 21:22:00 2017] Notation plus_0_r := Nat.add_0_r (compat "8.4"). [Wed Jul 26 21:22:27 2017] but when I click on the Nat.add_0_r, there's no such thing in the documentation [Wed Jul 26 21:22:39 2017] can anyone explain to me what's going on? [Wed Jul 26 21:27:52 2017] You are right, this is very confusing, because of the way Nat is implemented. This is a module with a few basic definitions and axioms, the rest is derived through generic functors and stuff [Wed Jul 26 21:28:15 2017] The actual definition of add_0_r would be in https://coq.inria.fr/library/Coq.Numbers.NatInt.NZAdd.html I think [Wed Jul 26 21:28:20 2017] (but it doesn't really help to know that) [Wed Jul 26 21:37:06 2017] ah, i see. i mean, i don't see it, but looks like i cannot help it. [Wed Jul 26 21:39:10 2017] now i'm looking for a lemma saying that (S n) = (S m) -> n = m [Wed Jul 26 21:39:27 2017] in haskell one had a nice search engine that allowed you to search for functions matching given type signature [Wed Jul 26 21:39:36 2017] is there something like this for coq? [Wed Jul 26 21:40:22 2017] Search (S _ = S _ -> _ = _). [Wed Jul 26 21:42:11 2017] that's exactly what i was looking for! [Wed Jul 26 21:42:26 2017] thank you :) [Wed Jul 26 21:47:06 2017] actually, if i wanted to use the add_0_r, how do I import it? [Wed Jul 26 21:49:44 2017] If you do "Require Import Arith.", then "Nat.add_0_r" is available [Wed Jul 26 21:49:57 2017] if you want to just write "add_0_r", you can do "Import Nat." [Wed Jul 26 21:51:12 2017] hm, Require Import Arith. works fine, but then it cannot find Nat [Wed Jul 26 21:51:26 2017] What is your version of Coq? [Wed Jul 26 21:51:34 2017] 8.4 [Wed Jul 26 21:51:39 2017] ah [Wed Jul 26 21:51:44 2017] looks like it's pretty old [Wed Jul 26 21:51:57 2017] it came with my distribution though [Wed Jul 26 21:52:02 2017] should I update? [Wed Jul 26 21:52:11 2017] I don't know the corresponding lemma, but what you can is try to locate it, using Search [Wed Jul 26 21:52:29 2017] I would advise updating if it's easy enough for you, I guess, but it's up to you [Wed Jul 26 21:53:20 2017] I will probably update at some point then, but I can use plus_0_r from Plus module for now [Wed Jul 26 21:53:28 2017] good then :) [Wed Jul 26 21:53:31 2017] :) [Wed Jul 26 21:54:06 2017] this whole thing is really fun [Wed Jul 26 21:54:38 2017] I had fun proving logical tautologies using natural deduction years ago at university, and it's kinda like this [Thu Jul 27 09:18:48 2017] Dodek: proving something like (S n) = (S m) -> n m is possible just using the `congruence` tactic [Thu Jul 27 09:18:59 2017] you might find these slides helpful https://coq.inria.fr/files/coq-itp-2015/CoqSurvivalKit.pdf [Thu Jul 27 12:25:52 2017] hackedy_: thanks! i also learned other ways to prove it in the meantime [Thu Jul 27 12:26:09 2017] i have now something like 5 times as much experience as i had when asking that question [Thu Jul 27 15:15:19 2017] hm, so I have the following definition: [Thu Jul 27 15:15:22 2017] Definition fold_length {X : Type} (l : list X) : nat := fold (fun _ n => S n) l 0. [Thu Jul 27 15:15:40 2017] i want to prove that forall l, fold_length l = length l [Thu Jul 27 15:16:01 2017] so i do induction over l, and in the nontrivial case i need to prove [Thu Jul 27 15:16:15 2017] fold_length (h :: t) = S (length t) [Thu Jul 27 15:16:52 2017] i want to expand the fold_length definition, to use the second case from fold definition to obtain [Thu Jul 27 15:18:38 2017] (fun _ n => S n) h (fold (fun _ n => S n) t) = S (length t) [Thu Jul 27 15:18:50 2017] this would allow me to simplify and apply the induction hypothesis [Thu Jul 27 15:19:11 2017] but i am not able to reduce fold_length (h :: t), simpl. does nothing. why? [Thu Jul 27 15:22:56 2017] okay, i found unfold tactic [Thu Jul 27 17:42:23 2017] Currently looking for anyone who is experienced in CoQ or ACL2 that is looking to pick up an extra project on the side. First will be a few projects, but can lead to a full time remote job. Anyone interested? [Thu Jul 27 18:55:20 2017] Currently looking for anyone who is experienced in CoQ or ACL2 that is looking to pick up an extra project on the side. First will be a few projects, but can lead to a full time remote job. Anyone interested? [Fri Jul 28 07:33:23 2017] Hi. I have just started reading SF and learning Coq. [Fri Jul 28 07:33:51 2017] I am stuck with the following error message: [Fri Jul 28 07:33:53 2017] Error: Illegal application (Non-functional construction): The expression "bool" of type "Set" cannot be applied to the term "match b1 with | true => false | false => negb b2 end" : "bool" [Fri Jul 28 07:37:52 2017] negb and bool type are defined as in: https://softwarefoundations.cis.upenn.edu/current/Basics.html#lab17 [Fri Jul 28 07:40:08 2017] any hint would be appreciated [Fri Jul 28 07:51:08 2017] nimaai: what did you write [Fri Jul 28 08:13:21 2017] lyxia: I figured it out; missed ":=" in the function definition. Thanks [Sat Jul 29 15:08:46 2017] het [Sat Jul 29 15:09:02 2017] hey [Sat Jul 29 15:09:14 2017] (i'm working through software foundations book) [Sat Jul 29 15:09:20 2017] i have the following definition: [Sat Jul 29 15:09:22 2017] Inductive R : nat -> nat -> nat -> Prop := | c1 : R 0 0 0 | c2 : forall m n o, R m n o -> R (S m) n (S o) | c3 : forall m n o, R m n o -> R m (S n) (S o) | c4 : forall m n o, R (S m) (S n) (S (S o)) -> R m n o | c5 : forall m n o, R m n o -> R n m o. [Sat Jul 29 15:09:32 2017] oops, shouldn't have gone in a single line [Sat Jul 29 15:09:40 2017] Inductive R : nat -> nat -> nat -> Prop := [Sat Jul 29 15:09:44 2017] | c1 : R 0 0 0 [Sat Jul 29 15:09:48 2017] | c2 : forall m n o, R m n o -> R (S m) n (S o) [Sat Jul 29 15:09:52 2017] | c3 : forall m n o, R m n o -> R m (S n) (S o) [Sat Jul 29 15:09:56 2017] | c4 : forall m n o, R (S m) (S n) (S (S o)) -> R m n o [Sat Jul 29 15:09:59 2017] | c5 : forall m n o, R m n o -> R n m o. [Sat Jul 29 15:10:52 2017] it is clearly just a good old plus relation [Sat Jul 29 15:10:58 2017] and that's what i'm trying to prove [Sat Jul 29 15:11:38 2017] i'm having trouble though with doing any proofs whatsoever on this type -- the c4 constructor gives me a hard time. [Sat Jul 29 15:13:15 2017] e.g. suppose I want to prove that forall n, R 0 0 n -> n = 0. i intro the n and the assumption H: R 0 0 n, but when I do an inversion on H, i get a case of R 1 1 (S (S n)) -> R 0 0 n, and i have no idea how to deal with it. [Sat Jul 29 15:14:02 2017] the induction on n doesn't work for the same reason [Sat Jul 29 15:18:27 2017] here's a simpler case: [Sat Jul 29 15:18:41 2017] Inductive Q : nat -> Prop := [Sat Jul 29 15:18:44 2017] | q0 : Q 0 [Sat Jul 29 15:18:47 2017] | q2 : forall n, Q (S n) -> Q n. [Sat Jul 29 15:18:58 2017] how to prove the following theorem: [Sat Jul 29 15:19:18 2017] Theorem Q_triv : forall n, Q n <-> n = 0. [Sat Jul 29 15:22:06 2017] This kind of constructor definitely complicates things. In your simple case, you can do this: http://lpaste.net/357281 [Sat Jul 29 15:22:57 2017] ah, i just figured out simple case too [Sat Jul 29 15:23:34 2017] i also did induction on Q n [Sat Jul 29 15:23:56 2017] i wonder if it's gonna work on R too. [Sat Jul 29 15:23:57 2017] I do wonder: why not get rid of the constructors c4 and c5? They don't bring anything more in the relation, right? [Sat Jul 29 15:24:06 2017] yeah, they don't [Sat Jul 29 15:24:15 2017] the SF book even asks whether they bring anything [Sat Jul 29 15:24:24 2017] but i think that's the whole point. [Sat Jul 29 15:24:40 2017] ah right, I forgot about this exercise then :) [Sat Jul 29 15:27:35 2017] a funny thing is this [Sat Jul 29 15:28:03 2017] i don't see any way to prove that ~(Q 1) other than proving Q n <-> n = 0 [Sat Jul 29 15:28:12 2017] or am i missing anything? [Sat Jul 29 15:29:23 2017] Not missing anything, I think. There is no simple proof, because you have to explain that "Q 1" would be an infinite chain of applications of q2 [Sat Jul 29 15:42:35 2017] i'm now trying to prove that R 0 0 n -> n = 0 [Sat Jul 29 15:43:02 2017] but the induction on R 0 0 n introduces some unexpected cases to me, and i don't know how to deal with thosee [Sat Jul 29 15:43:48 2017] i am wondering if this is also the case like with ~(Q 1) above -- maybe i do really need to consider all of the variables at the same time. [Sat Jul 29 15:48:50 2017] e.g. I have assumption H: R 0 0 n, and I have goal n = 0. [Sat Jul 29 15:49:04 2017] I do induction H. [Sat Jul 29 15:49:15 2017] first case, c1, is trivial, so reflexivity deals with it. [Sat Jul 29 15:49:27 2017] but then c2 generates something weird: [Sat Jul 29 15:49:37 2017] n0 := 0 : nat [Sat Jul 29 15:49:37 2017] m : nat [Sat Jul 29 15:49:37 2017] n : nat [Sat Jul 29 15:49:37 2017] o : nat [Sat Jul 29 15:49:37 2017] H : R m n o [Sat Jul 29 15:49:39 2017] IHR : o = n [Sat Jul 29 15:49:42 2017] ============================ [Sat Jul 29 15:49:44 2017] S o = n [Sat Jul 29 15:50:29 2017] why is o = n? why did it introduce m n even though R 0 0 n is not of this form? [Sat Jul 29 15:50:54 2017] inversion would figure it out, but how can I do inversion when doing induction? [Sat Jul 29 15:51:19 2017] and why is the goal S o = n? the goal was n = 0 before, what happened? [Sat Jul 29 16:24:49 2017] Dodek: try "destruct" instead of "induction" [Sat Jul 29 16:25:03 2017] hmmm [Sat Jul 29 16:25:13 2017] actually how would you do the proof on paper? [Sat Jul 29 16:26:50 2017] nvm about the "destruct", didn't do Coq in a few months and I think I'm already rusty lol [Sat Jul 29 16:32:30 2017] Dodek: anyway IIRC the base 'induction' tactic will generalize everything [Sat Jul 29 16:35:03 2017] it works for example if you do "forall m p, m = 0 -> p = 0 -> R m p n -> n = 0" (but then you have a problem with c4) [Sat Jul 29 16:41:28 2017] I have no idea how to handle c4, but actually c5 can also be tricky as a simple induction cannot do it.. good luck heh [Sat Jul 29 18:31:21 2017] artart78: if i do induction on R m p n in your theorem, it wants me to prove that S o = 0 in the c2 case [Sat Jul 29 18:32:36 2017] hm but you have a contradicting hypothesis in your context, no? [Sat Jul 29 18:41:49 2017] doesn't look like it [Sat Jul 29 18:41:58 2017] consider my context above [Sat Jul 29 18:42:26 2017] where it asks me to prove that S o = n, with assumption that o = n [Sat Jul 29 18:42:36 2017] i mean, yes, it is a contradicting hypothesis [Sat Jul 29 18:42:52 2017] but it only means that i cannot derive the goal [Sat Jul 29 18:43:06 2017] unless there's a false assumption, but it doesn't look like it. [Sat Jul 29 18:45:16 2017] anyway [Sat Jul 29 18:45:29 2017] i just directly proved that R n m o <-> n + m = o [Sat Jul 29 18:45:34 2017] with a very simple proof [Sat Jul 29 18:45:49 2017] but I couldn't seem to prove any other thing about R. [Sat Jul 29 18:50:43 2017] hm sorry I don't remember what I did, I'm starting to feel asleep now lol [Sat Jul 29 18:51:03 2017] but to be honest I think it's not possible to do it using just an induction [Sat Jul 29 18:52:37 2017] so yeah you'll probably need to be more pedestrian (doesn't that n + m = o characterization solve what you want?) [Sat Jul 29 18:54:31 2017] sure, once I prove that R n m o <-> n + m = o, everything else follows from facts I proved about + [Sat Jul 29 18:54:54 2017] but I find it confusing that it's much easier to prove that equivalence than, say, to prove that R 0 0 n -> n = 0. [Sat Jul 29 18:55:23 2017] that often happens: for example, needing to generalize inductions in order to prove a simpler goal [Sat Jul 29 18:55:35 2017] but I guess it makes some sense -- to prove it using pen and paper, you have to consider also c constructor [Sat Jul 29 18:55:38 2017] c4 i mean [Sat Jul 29 18:55:50 2017] and then how could we have gotten an argument to c4 and so on [Sat Jul 29 18:57:09 2017] yeah you could probably prove the equivalence with R without c4 and c5 and then it would be easy [Sat Jul 29 19:01:37 2017] okay, I'm doing subsequent exercises in that book now [Sat Jul 29 19:01:40 2017] and they sem sooo easy [Sat Jul 29 19:01:44 2017] seem [Sat Jul 29 19:09:26 2017] maybe we missed something haha [Sat Jul 29 21:20:15 2017] so i can use -, +, and * to manage the focus of the proof [Sat Jul 29 21:20:35 2017] but what if i need more levels? obviously I could try to extract lemmas, but if there's nothing suitable to extract? [Sat Jul 29 21:20:38 2017] what are my other options? [Sat Jul 29 21:21:37 2017] you can use --, ++, ** and so on [Sat Jul 29 21:25:31 2017] oh. what's the order? [Sat Jul 29 21:25:57 2017] there is no set order, you can use them however you want [Sat Jul 29 21:27:22 2017] oh, i see [Sat Jul 29 21:27:24 2017] thanks! [Sat Jul 29 22:07:44 2017] what the hell is this omega tactic [Sat Jul 29 22:08:20 2017] The tactic omega, due to Pierre Crégut, is an automatic decision procedure for Presburger arithmetic. [Sat Jul 29 23:46:53 2017] Dodek: is that clarifying enough? [Sun Jul 30 00:41:19 2017] it is [Sun Jul 30 00:41:24 2017] actually i'm fucking pissed right now [Sun Jul 30 00:41:50 2017] i spent way too much time trying to prove that n + m + n + k = n + n + m + k yesterday [Sun Jul 30 00:42:13 2017] just kidding, it's a great tactic [Sun Jul 30 19:57:45 2017] according to something I saw somewhere, you should use bullets in the order - * + -- ** ++ etc. if you want proof general to do something-or-other optimally [Sun Jul 30 19:57:51 2017] (real specific, eh?) [Sun Jul 30 20:16:35 2017] hello [Sun Jul 30 20:16:53 2017] what would you recommend to use to write and prove correct a C program in coq? [Mon Jul 31 06:33:05 2017] are coq 8.4pl* compatible with the 8.4 release [Mon Jul 31 06:33:08 2017] ? [Mon Jul 31 06:33:28 2017] or are they not compatible [Mon Jul 31 10:33:03 2017] how do i configure coq loadpath or other variables to set it up? [Mon Jul 31 10:33:12 2017] i built and installed it locally ot a folder out/ [Mon Jul 31 10:33:20 2017] so i add out/bin to PATH but when I launch coqtop i get a lot of errors [Mon Jul 31 10:33:56 2017] warnings about things being remapped, and Error: Cannot load Coq.Init.Notations: no physical path bound to Coq.Init [Mon Jul 31 19:10:17 2017] when did the proof general logo turn into an anime girl [Mon Jul 31 19:10:29 2017] what weeb took over [Mon Jul 31 19:40:57 2017] http://zermelo.dcs.ed.ac.uk/releases/ProofGeneral-3.3/doc/ProofGeneral.jpg used to be this guy [Mon Jul 31 19:40:58 2017] haha [Mon Jul 31 19:42:52 2017] benzrf: http://mzp.hatenablog.com/entry/2012/09/26/232857 [Mon Jul 31 19:43:42 2017] oh no [Mon Jul 31 20:20:58 2017] no cigars [Mon Jul 31 20:21:01 2017] heresy. [Mon Jul 31 20:21:10 2017] love a good cigar [Tue Aug 1 07:10:57 2017] hello [Tue Aug 1 07:11:15 2017] any advice for running coq after building it into a local prefix? [Tue Aug 1 07:47:00 2017] I use proof general [Tue Aug 1 07:47:36 2017] I just append emacs exec-path with that particular prefix [Tue Aug 1 07:47:47 2017] You can just launch ./bin/coqide if you prefer CoqIDE to Proof General [Tue Aug 1 07:50:23 2017] my problem is coqtop wont work even in the terminal, let alone proof general [Tue Aug 1 07:50:38 2017] Oh. What does "wont work" mean? [Tue Aug 1 07:51:51 2017] https://bpaste.net/show/5a39e498a651 these are the errors i get [Tue Aug 1 07:53:30 2017] hmm, if you add "-coqlib " to the command line (where is whatever directory you are building in) [Tue Aug 1 07:54:45 2017] thanks! tried it, it didn't change anything [Tue Aug 1 07:55:42 2017] then I don't think I can help you, sorry :/ [Tue Aug 1 07:56:40 2017] how I built it was ./configure then it asks for the directories [Tue Aug 1 07:56:56 2017] and i just kep putting /my/path/out/coq /my/path/out/bin etc. [Tue Aug 1 07:57:15 2017] i can delete this whole thing and build it again, but does anyone know the right way to install it locally so i dont' have to use root? [Tue Aug 1 07:57:16 2017] If you just do "./configure -local", does it ask for anything? [Tue Aug 1 07:57:40 2017] Well, that's the way I usually do it: "./configure -local && make" [Tue Aug 1 07:57:52 2017] It gives me working binaries in the ./bin/ directory [Tue Aug 1 07:58:01 2017] nice let me try! [Tue Aug 1 07:58:07 2017] but it doesn't ask for any directory, the "./configure -local" just succeeds [Tue Aug 1 07:58:11 2017] it says [Tue Aug 1 07:58:16 2017] OCaml binaries in : /usr/bin/ [Tue Aug 1 07:58:16 2017] OCaml library in : /usr/lib/ocaml [Tue Aug 1 07:58:29 2017] hmm [Tue Aug 1 07:58:32 2017] oh nvm, thats not where it's going to put things [Tue Aug 1 07:58:41 2017] yeah, that looks fine [Tue Aug 1 08:07:21 2017] awesome now it works! cheers [Tue Aug 1 08:07:28 2017] good! [Tue Aug 1 08:59:54 2017] woo just compiled all of VST! [Tue Aug 1 09:00:01 2017] went without a hitch [Tue Aug 1 09:14:20 2017] is there something like “generalize … at …” which allows me to keep assumptions about the thing I’m generalizing? [Tue Aug 1 09:14:35 2017] I’m trying to generalize something so that two things which are currently the same can be different but I need the assumptions for both [Tue Aug 1 09:14:42 2017] looks like remember? [Tue Aug 1 09:15:05 2017] If they are currently the same, you might need to tweak it more manually though [Tue Aug 1 09:15:18 2017] (because Coq won't magically select the correct one for each variable) [Tue Aug 1 09:16:04 2017] is there something like the "at" for "remember" or do I need to do that manually? [Tue Aug 1 09:17:12 2017] ah looks like I can do that using the goal_occurences stuff [Tue Aug 1 09:17:55 2017] perfect that works, thanks Cypi! [Tue Aug 1 09:18:10 2017] really? You can select an occurrence position with this? [Tue Aug 1 09:18:26 2017] (I was about to suggest using "set", which supports "at", and then clear its body) [Tue Aug 1 09:18:30 2017] "remember xs' as xs'' in |- * at 1" seems to work [Tue Aug 1 09:18:38 2017] oh, nice [Tue Aug 1 09:18:47 2017] found it here https://coq.inria.fr/refman/Reference-Manual010.html#Occurrences_clauses [Tue Aug 1 09:19:51 2017] thanks, learned something too :) [Tue Aug 1 10:13:16 2017] in proof general, can i get electric terminator to produce a new line instead of just moving to the next one [Tue Aug 1 10:13:25 2017] when editing a proof in the middle of a file [Tue Aug 1 12:32:42 2017] what's the nicest way to prove this? https://i.imgur.com/FFzTh1u.png [Tue Aug 1 12:33:00 2017] i guess i could just do two destructs, but i feel like there's something more elegant [Tue Aug 1 13:30:27 2017] benzrf: You could write do 2 (destruct n; inversion G). if that's any better [Tue Aug 1 13:31:35 2017] eh [Tue Aug 1 13:32:27 2017] In my experience it's always kind of bleh turning equalities of bool values into something usable. [Tue Aug 1 13:35:59 2017] :[ [Tue Aug 1 21:12:13 2017] benzrf: the only ways I know are destructing and writing a lemma with that specific pattern and then applying it [Tue Aug 1 21:12:36 2017] both of which are messy [Tue Aug 1 21:12:37 2017] :\ [Tue Aug 1 21:13:13 2017] it seems to me that coq ought to either reduce those itself somehow or have a tactic specifically for it [Tue Aug 1 21:13:38 2017] out of curiosity, if you could write something like "destruct (st X) as [0 | 1 | S (S _)]", would that be satisfying? [Tue Aug 1 21:13:51 2017] or is it too much input? [Tue Aug 1 21:14:07 2017] not really [Tue Aug 1 21:14:23 2017] it would be an improvement, I guess [Tue Aug 1 21:15:00 2017] but it still generates the cases for the non-matching values [Tue Aug 1 21:15:08 2017] The non-matching values? [Tue Aug 1 21:15:21 2017] the ones that reduce to true = false [Tue Aug 1 21:15:24 2017] Ah, you meant for this specific pattern where you have an equality [Tue Aug 1 21:15:33 2017] which in this case can be retired with discriminate, but it isn't always that nice [Tue Aug 1 21:15:54 2017] I've been mucking with something that generates ~850 cases [Tue Aug 1 21:16:06 2017] and they don't all retire nicely up front [Tue Aug 1 21:16:17 2017] What can be expected from baseline Coq all depends on how you derive your absurdity [Tue Aug 1 21:16:24 2017] in this case it's easy, as you say [Tue Aug 1 21:17:12 2017] it begins like this: [Tue Aug 1 21:17:13 2017] intros. [Tue Aug 1 21:17:14 2017] inversion H; inversion H0; subst; simpl; auto. [Tue Aug 1 21:17:14 2017] 3,7,11,15,19,27,29-36,43: destruct r0. [Tue Aug 1 21:17:14 2017] 21-26,75-80: destruct r4. [Tue Aug 1 21:17:14 2017] 93-104: destruct r3. [Tue Aug 1 21:17:15 2017] (* whee 239 cases *) [Tue Aug 1 21:17:41 2017] glad the extendedd goal selectors are of use at least :p [Tue Aug 1 21:18:17 2017] they are, it would be impossible without [Tue Aug 1 21:18:41 2017] it goes on with [Tue Aug 1 21:18:42 2017] (* some instances of H1 have multiple alts in them *) [Tue Aug 1 21:18:42 2017] all: try (apply match_alt in H1; destruct H1); auto. [Tue Aug 1 21:18:42 2017] all: try (apply match_alt in H1; destruct H1); auto. [Tue Aug 1 21:18:42 2017] all: try (apply match_star_alternate in H1; destruct H1; subst); auto. [Tue Aug 1 21:18:42 2017] (* wheeeeee 839 cases *) [Tue Aug 1 21:19:16 2017] and then I have 28 versions of all: try (...). [Tue Aug 1 21:19:35 2017] and it goes through, but in addition to being a monumental pain it takes like five minutes to compile this lemma [Tue Aug 1 21:19:47 2017] yeah, I can understand :/ [Tue Aug 1 21:19:54 2017] the "all: try" are probably really bad [Tue Aug 1 21:20:49 2017] it's a lemma that shows that an optimization pass on a r1|r2 regexp preserves matching semantics [Tue Aug 1 21:20:52 2017] yeah, they are. [Tue Aug 1 21:21:25 2017] Is your code publicly available somewhere? [Tue Aug 1 21:21:34 2017] not yet [Tue Aug 1 21:21:36 2017] ok [Tue Aug 1 21:21:39 2017] and it's kinda half baked [Tue Aug 1 21:21:47 2017] but i can stick it somewhere temporarily if you're curious [Tue Aug 1 21:21:58 2017] I might be curious, but don't expect anything x) [Tue Aug 1 21:22:13 2017] (don't want to get your hopes up, I will probably not be able to do anything good) [Tue Aug 1 21:22:36 2017] don't waste your time on it [Tue Aug 1 21:23:04 2017] it remains to be seen if the logic that uses the pass is going to be any use [Tue Aug 1 21:23:37 2017] it is trying to match regexps without compiling them by peeling single matched characters off the front of the regexp [Tue Aug 1 21:23:54 2017] I see [Tue Aug 1 21:24:16 2017] and the basic problem is that the canonicalization pass needed to do that peeling requires 3-4 layer deep matching on the regexp [Tue Aug 1 21:24:33 2017] which means 3-4 layers of destruct, and regexps have lots of cases (six now and potentially more later) [Tue Aug 1 21:24:50 2017] yeah, I get the idea :/ [Tue Aug 1 21:25:08 2017] all the cases go through easily, there are just so damn many and just creating that many cases seems to be slow. [Tue Aug 1 21:25:54 2017] before I split the matching for sequences and alternates off into a separate definition it was far, far worse. [Tue Aug 1 21:26:05 2017] scary [Tue Aug 1 21:27:24 2017] then just compiling the Function that did the work took forever [Tue Aug 1 21:27:36 2017] not sure why [Tue Aug 1 21:27:56 2017] seems like something must be cubic or worse in the number of nested matches [Tue Aug 1 21:28:08 2017] You wrote "Function", are you actually using "Function"? [Tue Aug 1 21:28:14 2017] yeah [Tue Aug 1 21:28:15 2017] or was that just a random capitalization? [Tue Aug 1 21:28:16 2017] ok [Tue Aug 1 21:28:51 2017] Function seems to be strictly preferable to Fixpoint except when you have something ratty where it doesn't work [Tue Aug 1 21:30:14 2017] Well, Fixpoint is simple, it doesn't do anything fancy. Function is...more complicated [Tue Aug 1 21:31:00 2017] (and the one of those I've had since I learned enough to have any idea what I was doing... I never got to work) [Tue Aug 1 21:33:35 2017] being able to do functional induction is occasionally critical [Tue Aug 1 21:33:50 2017] also being able to do "rewrite foo_equation" is nice except that I have no idea why foo_equation only appears sometimes [Tue Aug 1 21:34:41 2017] good to know these features are useful x) [Tue Aug 1 21:36:32 2017] heh :-) [Tue Aug 1 21:38:03 2017] I wonder how feasible it would be to take that match expression and turn it into a big disjunction [Tue Aug 1 21:39:43 2017] something like ((st X = 0) /\ (false = true) \/ ((st X = 1) /\ (false = true)) \/ ((exists k, st X = S (S k)) /\ true = true)) [Tue Aug 1 21:40:03 2017] seems probably kinda beyond ltac [Tue Aug 1 21:40:25 2017] hmm [Tue Aug 1 21:40:49 2017] and not necessarily a big improvement, but then it's at least in a form you can do rewrites on [Tue Aug 1 21:40:50 2017] in Ltac it looks difficult, indeed [Tue Aug 1 21:41:56 2017] the problem is being general enough about patterns in the match, so that you can generate "exists k, ..." and so on, don't think you can do that [Tue Aug 1 21:42:10 2017] in OCaml it shouldn't be too hard though [Tue Aug 1 21:42:58 2017] oh, that reminds me, I had a bug report to file on congruence [Tue Aug 1 21:43:04 2017] I should actually file it. [Tue Aug 1 21:45:23 2017] oh actually that transform would help my cases a lot [Tue Aug 1 21:45:47 2017] I keep getting cases where there's a match on the six regexp constructors and five of the six cases are identical [Tue Aug 1 21:46:52 2017] well, except that the constructors will still end up the logic. pah [Tue Aug 1 21:47:59 2017] I wonder how hard it would be to specifically thread discriminate through that to eliminate all the false = true cases directly [Tue Aug 1 21:49:40 2017] it's a common enough pattern. :-/ [Tue Aug 1 21:50:17 2017] Sorry, I don't have any good suggestion :/ [Tue Aug 1 21:50:27 2017] also there's a problem; it won't work if the match cases aren't strictly disjoint [Tue Aug 1 21:51:26 2017] then again, coq doesn't allow that, does it? [Tue Aug 1 21:51:33 2017] anyway I need to make dinner [Tue Aug 1 21:51:42 2017] match cases that aren't strictly disjoint? It does allow it [Tue Aug 1 21:51:49 2017] the first case takes precedence [Tue Aug 1 21:52:06 2017] you can write "match x with O => foo | O => bar | S _ => blah end" [Tue Aug 1 21:52:11 2017] at least sometimes it complains about redundant cases, or is that only if one is entirely unreachable? [Tue Aug 1 21:52:27 2017] hmm. It may be a Function thing, too [Tue Aug 1 21:53:12 2017] oh nevermind [Tue Aug 1 21:53:19 2017] you're right, you actually cannot write what I just wrote [Tue Aug 1 21:53:37 2017] But still, don't think they need to be strictly disjoint... [Tue Aug 1 21:57:13 2017] I can write [Tue Aug 1 21:57:14 2017] Definition bar (x y: nat): nat := match x, y with [Tue Aug 1 21:57:14 2017] | S a, b => 1 + a * b [Tue Aug 1 21:57:14 2017] | a, S b => 2 + a * b [Tue Aug 1 21:57:14 2017] | 0, 0 => 0 [Tue Aug 1 21:57:17 2017] end. [Tue Aug 1 21:57:21 2017] but it expands it internally [Tue Aug 1 21:58:45 2017] yeah, the only pattern-matching the kernel is aware of is the very basic one: one variable, and an exhaustive list of cases [Tue Aug 1 21:58:50 2017] (and no deep patterns) [Tue Aug 1 21:58:57 2017] everything else is compiled down to something like this [Tue Aug 1 22:00:22 2017] in that case it should be ok by the time one tries to apply this hypothetical tactic to a proof [Tue Aug 1 22:03:48 2017] then again, the fragment that started this contains S (S _) and not "match k with | 0 => false | S k' => match k' with 0 => false | S k'' => true" [Tue Aug 1 22:05:08 2017] so it must be getting refolded at least for display [Tue Aug 1 22:05:26 2017] anyway, dinnertime [Tue Aug 1 22:06:05 2017] There are still some stuff in place so that it can be refolded, yes [Tue Aug 1 22:06:44 2017] is* [Tue Aug 1 22:41:37 2017] hrm, is ocaml hiding a unicode string module somewhere? the docs have Uchar but no strings for them [Tue Aug 1 22:42:57 2017] apparently not [Tue Aug 1 22:42:58 2017] sigh. [Wed Aug 2 00:42:41 2017] is there a tactic like discriminate that instead rewrites true = false (or whatever) to False? [Wed Aug 2 11:58:59 2017] are VST and guru related? what other tools are used to write and verify C programs? [Wed Aug 2 14:26:49 2017] how do i apply an implicit argument explicitly? [Wed Aug 2 14:38:22 2017] ertes-w: you can use the @ notation [Wed Aug 2 14:38:27 2017] ah, thanks [Wed Aug 2 14:38:30 2017] apply (@lem x1 x2 .. ). [Wed Aug 2 14:38:58 2017] also is there a way to have anonymous sections? i mostly use Section for Context and Variable [Wed Aug 2 14:39:52 2017] Not as far as I know. [Wed Aug 2 14:43:32 2017] hmm, too bad… thanks [Wed Aug 2 14:45:48 2017] what's the syntax to give a particular implicit argument by name? basically the equivalent to agda's "f {x = y}" [Wed Aug 2 14:49:39 2017] Sometimes when I do `apply (f (x:=y))` and it works [Wed Aug 2 14:49:57 2017] but sometimes I do something like that and it doesn't work :] [Wed Aug 2 14:50:13 2017] I think the order of argument is also important [Wed Aug 2 14:52:16 2017] hah, that worked =) [Wed Aug 2 14:52:17 2017] thanks [Wed Aug 2 14:53:49 2017] i'm probably doing this a lot more complicated than necessary [Wed Aug 2 14:54:40 2017] http://lpaste.net/8833383740748070912 [Wed Aug 2 14:57:37 2017] my Category class is basically parameterised over equivalence and composition, because everything else follows from those, at least in theory [Wed Aug 2 14:58:42 2017] (if a semigroupoid is a category, it's easy to prove that it's a *unique* category) [Wed Aug 2 14:59:53 2017] (and yes, my Semigroupoid class isn't complete yet… i'm missing one further axiom) [Wed Aug 2 21:25:07 2017] are there examples of using Coq as a service for another program? somewhat like Z3 in the sense you can throw stuff at it and it gives you answers [Wed Aug 2 21:25:30 2017] so for Coq I want to throw programs at it and have it tell me either the type errors or that it is good [Wed Aug 2 21:29:03 2017] probably this can be done with any sort of IDE support program, if Coq has one [Wed Aug 2 21:38:34 2017] yes, you could just invoke the Coq compiler, but the issue is having machine readable output, especially for errors [Thu Aug 3 04:12:33 2017] I’ve probably asked this before but I don’t think I’ve gotten an answer so I’ll try again: Is there a way to name the results of an inversion by providing only a list of names for the cases that I know can occur instead of a list for all cases? [Thu Aug 3 04:12:50 2017] it’s annoying to write a really long list if I know there will be only one case [Thu Aug 3 04:40:01 2017] not that I know of, but that doesn't prove much [Thu Aug 3 04:45:12 2017] I guess for the very common cases I could use separate lemmas that cover only that one case but that’s a bit annoying [Fri Aug 4 00:01:04 2017] New to coq and want to give a tern a name [Fri Aug 4 00:02:16 2017] I have a Hypothoses in the same form as my goal but theres a simple name in the Hyp, and a term (always the same) in all the same places of the goal [Fri Aug 4 00:02:59 2017] Anyone here? [Fri Aug 4 00:04:15 2017] "set (name := term)." can do the job [Fri Aug 4 00:04:20 2017] (if I got your question right) [Fri Aug 4 00:04:43 2017] like set m := n + 1. ?? [Fri Aug 4 00:05:11 2017] for You need the parentheses [Fri Aug 4 00:05:15 2017] -for [Fri Aug 4 00:05:23 2017] So "set (m := n + 1).", for instance [Fri Aug 4 00:05:37 2017] let me try that and see if I make progress. [Fri Aug 4 00:05:38 2017] thx [Fri Aug 4 00:05:50 2017] but to be able to apply yor hypothesis, you will still need to have a reason for the name in your hypothesis and this term to be equal [Fri Aug 4 00:07:49 2017] That did exactly what I intended but my thinking was wrong as it didn't seem to help. [Fri Aug 4 00:08:54 2017] I have a hypo, that has the same form as the goal, but the variables have differnt names -- though they match as a pattern. I though this would let me must do: assumption. but it doesn't work. [Fri Aug 4 00:09:31 2017] If your hypothesis is saying something about a specific variable, it has no reason to be true about any other variable/term [Fri Aug 4 00:09:56 2017] For instance you can't prove: "forall n m, n = 0 -> m = 0" [Fri Aug 4 00:10:09 2017] If in your context you have "H : n = 0", it doesn't say anything about m [Fri Aug 4 00:11:21 2017] I wanted to do something like "H: fun1 n = fun2 n and the goal is like: fun1 m = fun2 m. [Fri Aug 4 00:11:37 2017] I changed it some but that's the type of pattern match I have. [Fri Aug 4 00:11:51 2017] Same thing, H is talking about n, not m [Fri Aug 4 00:12:17 2017] If you want to be more specific about what you are trying to prove, don't hesitate. Maybe you can prove it differently (or maybe you can't, it happens) [Fri Aug 4 00:12:23 2017] well thx , that will at least keep me from driving myself nuts [Fri Aug 4 00:13:07 2017] I was being a bit vague because I didn't want the answer, hacking my way through Software Founddations CH.4 induction [Fri Aug 4 00:13:19 2017] Ah right :) [Fri Aug 4 00:13:34 2017] at least you know it's provable if it says so [Fri Aug 4 00:14:46 2017] I have IH: double n' = n' + n' Goal: double (S n') = S n' + S n' or double m = m + m (after that set you gave me) [Fri Aug 4 00:15:23 2017] I can see perfectly well it's true but can't figure out how to make progress on it. [Fri Aug 4 00:15:54 2017] what you can do is start by simplifying your goal [Fri Aug 4 00:16:05 2017] the term "double (S n')" can be evaluated to something better [Fri Aug 4 00:16:22 2017] ok, let me try -- I stopped that because simpl. made it look worse. [Fri Aug 4 00:24:14 2017] simpl. added S around left and combined the right. I don't have very good intuitions yet but looks a lot worse to me. [Fri Aug 4 00:24:42 2017] You should be at something like "S (S (double n')) = S (n' + S n')", right? [Fri Aug 4 00:24:50 2017] S (S (double n')) = S (n' + S n') is now the goal. [Fri Aug 4 00:24:57 2017] Yes [Fri Aug 4 00:25:05 2017] Now, the good thing is that you can use your induction hypothesis [Fri Aug 4 00:25:16 2017] since it talks precisely about "double n'" [Fri Aug 4 00:25:20 2017] Every time I reached here, I gave up. [Fri Aug 4 00:25:42 2017] ok, trying [Fri Aug 4 00:35:41 2017] First goal after the induction was trivial, but the 2nd looks like I am just going in a circle with different variable names [Fri Aug 4 00:37:00 2017] What did you do, from "S (S (double n')) = S (n' + S n')"? [Fri Aug 4 00:38:47 2017] induction n' as [|m IHm]. 1) trivial goal 2) looks worse [Fri Aug 4 00:39:32 2017] I meant, after the simpl, you have "S (S (double n')) = S (n' + S n')", and then I suggested you used your induction hypothesis [Fri Aug 4 00:39:36 2017] so what did you try? [Fri Aug 4 00:39:58 2017] that induction [Fri Aug 4 00:40:06 2017] induction n' as [|m IHm]. [Fri Aug 4 00:40:29 2017] Goal became: S (S (double (S m))) = S (S m + S (S m) [Fri Aug 4 00:40:35 2017] Well, that's not using your induction hypothesis. In this case, you don't need to do another induction, as you say you would just be going in circle [Fri Aug 4 00:41:02 2017] In your context you know that "IH: double n' = n' + n'". So what you can do is rewrite "double n'" to "n' + n'" in your goal [Fri Aug 4 00:41:06 2017] oh, I misunderstood and use the tactic -- [Fri Aug 4 00:42:26 2017] I may have it now, but I though this was something I tried a long time ago. [Fri Aug 4 00:44:44 2017] rewriting removed the double so now I just have a bunch of S terms.....working on it. [Fri Aug 4 00:45:01 2017] Ok, got it. thx. I had two lemmas already that simplified that out for me [Fri Aug 4 00:45:11 2017] thx. [Fri Aug 4 00:45:14 2017] Yup, I think this was intended by the book :) [Fri Aug 4 00:45:37 2017] One of them I built myself for remove outer S () = S () [Fri Aug 4 00:45:56 2017] Just in case, there is a tactic for that: f_equal [Fri Aug 4 00:45:57 2017] Not sure if I really needed it but it seemed simpler to me [Fri Aug 4 00:46:22 2017] whenever you need to prove "f x y z = f x' y' z'", the tactic f_equal will ask you to prove the goals "x = x'", "y = y'" and so on [Fri Aug 4 00:46:40 2017] cool, it did the same thing as what I built. [Fri Aug 4 00:47:10 2017] That sort of makes me feel better if I am building and using things that are standard without first knowing about them. [Fri Aug 4 00:47:25 2017] FYI: I am not in school, but I am trying to do this without cheating. [Fri Aug 4 00:49:05 2017] Ok, mine were exact, so f_equal just removed the wrap for me [Fri Aug 4 00:49:33 2017] but I see how it would do what you say if they weren't obviously equal in each variable [Fri Aug 4 00:50:15 2017] So, I didn't build exactly f_equal, just a very special case [Fri Aug 4 00:51:29 2017] thx Cypi -- must appreciated. Going to bed now, have a good one. [Fri Aug 4 00:51:46 2017] s/must/much/ appreciated. [Fri Aug 4 00:53:35 2017] No problem, good night [Fri Aug 4 01:02:06 2017] what part of the world are you in? [Fri Aug 4 09:58:04 2017] I prefer not to use auto. because I am learning, but I have been using it to check if there was likely an easy way forward. Reading last chapters in SF/Pierce indicates auto ONLY does reflexivity, assumption, and apply so it would seem if auto works then at least one of these (followed by others) much work, correct? [Fri Aug 4 10:06:04 2017] ringer1: i think it depends on some stuff, but im no expert on how auto works [Fri Aug 4 10:11:16 2017] assumption is just apply an hypothesis, and reflexivity is applying eq_refl, so you can subsume this by: auto uses apply with a number of terms, including hypotheses in context, and a bunch of other lemmas [Fri Aug 4 10:12:27 2017] If you want to know what auto did instead of guess, you can either use "info_auto", or take a look at the term that was produced with "Show Proof." [Fri Aug 4 10:21:04 2017] Cypi thx, I was looking for Show Proof but I don't seem to understand where/how to execute info_auto [Fri Aug 4 10:22:04 2017] Instead of auto [Fri Aug 4 10:22:14 2017] You just write info_auto where you would have written auto [Fri Aug 4 10:23:47 2017] Show Proof, I didn't fully understand hte output but it showed me a lamba: (fun (n m : nat) (H: S n = S m) => eq_add_S n am H) [Fri Aug 4 10:23:55 2017] Ok, instead of auto. [Fri Aug 4 10:24:21 2017] So, unless it's you, auto probably used eq_add_S [Fri Aug 4 10:24:34 2017] Ok, that made more sense. apply eq_add_S was the key [Fri Aug 4 10:25:01 2017] auto did that -- I didn't know eq_add_S or remember it if I did. [Fri Aug 4 10:25:38 2017] So lemmas are added by default to the set of lemmas that auto can use [Fri Aug 4 10:25:40 2017] Some* [Fri Aug 4 10:27:05 2017] I had used "auto" to prove something and wanted to remove it -- I did that now with your help to apply eq_add_S. Not sure where ea_add_S came from though. [Fri Aug 4 10:27:32 2017] wanted to remove auto, and have a proof I understood. [Fri Aug 4 11:26:23 2017] eq_add_S is from the standard library; you can find it with Search (S _ = S _). [Fri Aug 4 11:26:43 2017] also, as a general matter of convenience I wish auto also did "try discriminate; try contradiction" [Fri Aug 4 13:21:37 2017] dh` thanks to you also [Sat Aug 5 00:29:25 2017] Still hacking my way through SF/LF Chapter 4. Wonder how much I am really learning by hacking at these problem until I get them. Any thoughts? [Sat Aug 5 00:31:50 2017] ringer1: that's a good way to learn. reading without doing leads to faux learning [Sat Aug 5 00:36:53 2017] thx efm -- It's at least true that I'm learning MORE than if I were only reading [Sat Aug 5 00:37:23 2017] ringer1: you're learning if you're paying attention to why and how you're able to get through [Sat Aug 5 00:38:10 2017] johnw ok, I suppose it's going to be necessary to run through them all again from scratch [Sat Aug 5 00:38:23 2017] or find other, more interesting problems to tackle [Sat Aug 5 00:38:35 2017] I never finished SF because I find real things to hack on instead [Sat Aug 5 00:38:40 2017] but it's a great place to start [Sat Aug 5 00:38:54 2017] I was wondering about that -- or easier ones -- although these are probably pretty easy even if difficult for me [Sat Aug 5 00:39:59 2017] Our Haskell group started a Proofs/Type/CatTheory study group using SF first -- I'd been working on learning Categories for a few months so joined [Sat Aug 5 00:40:36 2017] I had no idea really WHY to do this, but in some ways it's fun -- would be more fun if I could see ahead a step or two more. [Sat Aug 5 00:41:57 2017] there's a pretty big world of verified software out there [Sat Aug 5 00:42:10 2017] Please don't tell answer: just tell me if this is progress -- it looks circular to me plus_comm [Sat Aug 5 00:42:11 2017] that's what the recent DeepSpec summer school was all about; and it's course videos are available online now [Sat Aug 5 00:42:26 2017] why is plus_comm circular? [Sat Aug 5 00:43:04 2017] Prove: n + m = m + n versus my current S n + S n' = S n' + Sn [Sat Aug 5 00:43:16 2017] (I hadn't finished question sorry) [Sat Aug 5 00:43:46 2017] To me that looks like I am just proving the same thing I started to prove (after a bunch of work) [Sat Aug 5 00:44:04 2017] looks like you inducted on both n and m [Sat Aug 5 00:44:24 2017] I did, is that generally? a mistake? [Sat Aug 5 00:44:46 2017] yeah, it's pretty rare to need double induction [Sat Aug 5 00:45:05 2017] the first induction gives you something you can rewrite with, if you just prepare the goal for it to work [Sat Aug 5 00:45:08 2017] Ok, I'll retry -- maybe that's the source of much of my trouble -- I did that in a lot of them. [Sat Aug 5 00:45:18 2017] retrying... [Sat Aug 5 00:45:24 2017] if you think of programming, induction is like a recursive call [Sat Aug 5 00:45:33 2017] usually you just recurse on one argument, not multiple [Sat Aug 5 00:54:47 2017] johnw thx. ok, makes sense. went back with single induction and only flailed a little proving plus_comm. Pretty straightfoward compared with earlier attempts. [Sat Aug 5 00:55:33 2017] Pierce said, "hacking is ok, about 5 minutes" :) so it took me 9 minutes -- probably 5 just hacking a bit. :) [Sat Aug 5 00:56:03 2017] you could also try doing it without tactics, though using the eq_ind function directly takes some getting used to [Sat Aug 5 00:58:16 2017] I have not idea how to do that (I could learn but it means nothing to me right now) [Sat Aug 5 00:58:21 2017] no idea [Sat Aug 5 00:58:47 2017] the only reason I say is that it's very helpful to know what tactics are actually doing [Sat Aug 5 00:58:55 2017] makes it easier to pick them, or intuit how they should be used [Sat Aug 5 00:59:15 2017] Makes sense -- are there any sources that teach that explicitly do you know? [Sat Aug 5 00:59:33 2017] not really, actually [Sat Aug 5 00:59:45 2017] this is something that would be valuable to write up [Sat Aug 5 01:03:04 2017] I found a couple of tutorials that said things like "If you have this, use this..." which is sort of that you are saying but WITH tactics [Sat Aug 5 01:03:10 2017] right [Sat Aug 5 01:03:16 2017] BTW, I walked through the next proof pretty easily [Sat Aug 5 01:03:27 2017] 4 minutes this time [Sat Aug 5 01:03:39 2017] plus_assoc [Sat Aug 5 01:03:58 2017] so the suggestion to stop doing multiple induction was probably much of my problem [Sat Aug 5 01:04:11 2017] It worked once and I just kept doing it. [Sat Aug 5 01:04:18 2017] thx [Sat Aug 5 01:06:35 2017] sure [Sat Aug 5 01:12:13 2017] here's the proof without tactics: https://gist.github.com/1ecdd0106959044a233a9e8a8223b31b [Sat Aug 5 01:12:26 2017] I included one use of eq_ind instead of the notation 'rew' just to show what 'rew' desugars into [Sat Aug 5 01:12:46 2017] that's what gets called when you use "rewrite" in a propositional context [Sat Aug 5 01:13:03 2017] but you can see the "induction hypothesis" being used here, it's just a recursive call [Sat Aug 5 01:14:54 2017] ok, reading it now [Sat Aug 5 01:17:15 2017] night time for me; enjoy! [Sat Aug 5 01:17:25 2017] the underscores on the right let coq fill in types (mostly?) [Sat Aug 5 01:17:43 2017] Me too, I only stayed to talk -- night, thx again [Sat Aug 5 02:00:55 2017] often if you think you need to induct on two things, it's sufficient to induct on one and destruct the other [Sat Aug 5 02:04:55 2017] also, if you're getting useless induction hypotheses (e.g. things like x :: xs = xs -> ...) [Sat Aug 5 02:05:43 2017] most of the time these can be rectified by manipulating which things are intro'd [Sat Aug 5 07:33:35 2017] thx dh` [Sat Aug 5 17:29:19 2017] In CoqIde, I wrote and assert with {curly braces} which turns YELLOW after the closing brace but the runs the next tactic just fine (green). What does this mean? I believe I made an error but haven't seen this before. [Sat Aug 5 17:29:58 2017] Something hilighted in yellow means that it was admitted. Have you used "admit" or something like this? [Sat Aug 5 17:30:16 2017] highlighted* [Sat Aug 5 17:30:24 2017] No. did not visibly or intentionally use admit. [Sat Aug 5 17:31:42 2017] Hmm. Then I am not sure [Sat Aug 5 17:31:46 2017] did only a rewrite with previously proven theorem in the curly braces: { rewrite mult_S_1. } closing brace and space to left turned yellow [Sat Aug 5 17:32:01 2017] might just be a bug of CoqIDE [Sat Aug 5 17:32:27 2017] It acts like it wants something in there, but the closing . period is present and it greens up otherwise. [Sat Aug 5 17:32:30 2017] somtimes the coloring and the text are out-of-sync, and it is fixed if you just change a bit the lines [Sat Aug 5 17:33:00 2017] Ok, already put it on separate line and all the spaces to the close brace went yellow also. [Sat Aug 5 17:33:30 2017] I might be stuck, and it looked like maybe i'd done something wrong to get there. [Sat Aug 5 17:34:01 2017] thx [Sat Aug 5 17:34:58 2017] try restarting coqide? [Sat Aug 5 17:35:10 2017] it's not 100% bug-free [Sat Aug 5 17:38:03 2017] ok [Sat Aug 5 17:40:02 2017] same thing, it also looks like I've ended up with an impossible to prove goal [Sat Aug 5 17:40:53 2017] I think m = S n would need to be true of all m n and that makes no sense to me [Sat Aug 5 17:53:33 2017] Is it possible to prove that BigQ.eq_bool x y -> Logic.eq x y ? [Sat Aug 5 17:54:20 2017] I'm trying to prove that BigQ is a MathComp eqType, but I haven't been able to find any related lemma [Sat Aug 5 17:58:39 2017] I've never really used BigQ, but it seems to be defined as "Inductive t_ : Type := Qz : bigZ -> BigQ.t_ | Qq : bigZ -> bigN -> BigQ.t_". So no, without an axiom it is not possible to prove [Sat Aug 5 17:59:04 2017] (because for instance 1/2 == 2/4, but 1/2 <> 2/4) [Sat Aug 5 18:00:07 2017] Ah, that's right [Sat Aug 5 18:03:36 2017] it would be nice if there were an intermediate concept of equality between the strict structural equality and what you can do with Equivalence [Sat Aug 5 18:03:50 2017] but I'm not sure what or how to frame it :-) [Sat Aug 5 18:06:46 2017] ideally, you could have a higher inductive type so that you can directly define the relevant equality for your type [Sat Aug 5 18:06:50 2017] but it's complicated :) [Sat Aug 5 18:09:14 2017] that sounds likely to make my head hurt :-) [Sat Aug 5 18:10:58 2017] the problem with Equivalence, or I guess more accurately Proper, is that you have to prove it separately for every context something appears in, and for anything general like a number implementation there are tons of those [Sat Aug 5 18:12:39 2017] offhand it seems like what one would want is some more specific way to seal an abstraction layer, and then define/prove an equality that can be used like = as long as you don't unseal [Sat Aug 5 18:43:07 2017] alternatively, I wonder if it would make sense to have abstract data types [Sat Aug 5 18:47:06 2017] The Coq version of HoTT already uses this kind of trick to simulate higher inductive types [Sat Aug 5 18:47:18 2017] private modules and whatnot, I don't know much about it [Sat Aug 5 18:47:59 2017] something like an abstract Q that has no structural representation and whose semantics are defined by a refinement to Qz [Sat Aug 5 18:48:06 2017] plus some kind of consistency proof [Sat Aug 5 18:50:43 2017] then you could say q1 = q2 and mean numeric equality, but I guess it would be a lot of thrashing. [Sat Aug 5 22:05:55 2017] what does "simple apply eq_sym" mean/do? I found this by using info_auto -- if I understood it then it would probably be Ok. [Sat Aug 5 22:07:02 2017] This is like "apply eq_sym", but performs less conversion to check if you can apply your lemma [Sat Aug 5 22:07:16 2017] so basically you can just write "apply eq_sym" [Sat Aug 5 22:17:39 2017] Ok. got simple twice and neither was needed. So I got mult_comm down to where: auto worked, then using that got it to: apply eq_sym. trivial. THEN info_trivial: got me the proof: apply eq_sym. apply mult_n_Sm. [Sat Aug 5 22:17:57 2017] But it feels like cheating. I fought this for a couple of hours probably though. [Sat Aug 5 22:19:03 2017] Not even sure if I should have used mult_n_Sm which is from core -- not something I built. [Sat Aug 5 23:10:22 2017] How is Coq applying the: assumption in this proof, it completes but I don't know how to read it. https://gist.github.com/HerbM/caaa7d36760162e000470f55b883de80 [Sat Aug 5 23:17:16 2017] "leb (S p + n) (S p + m)" -> "leb (S (p + n)) (S (p + m))" -> "leb (p + n) (p + m)" [Sat Aug 5 23:17:27 2017] so your goal and the type of IHp are convertible [Sat Aug 5 23:17:36 2017] if you do "simpl", you'll see it [Sat Aug 5 23:38:32 2017] ok [Sat Aug 5 23:39:57 2017] well I guess the lesson you just taught me is: If you try something easy and don't see it, then use simpl. [Sat Aug 5 23:42:39 2017] thx again. [Sun Aug 6 11:06:23 2017] i'm starting out with the software foundations book and browsing the chapters in Proof General... but how do i actually *use* this PG thing to run commands, check proofs, etc? [Sun Aug 6 11:07:05 2017] it behaves like no language mode i've ever seen before, can't see any kind of keybinding to send expression/region [Sun Aug 6 13:52:15 2017] .users [Sun Aug 6 13:53:40 2017] hello, I am a coq newbie, and would like to know if there is a way to rewrite or apply inside "fun" lambdas that are in goals ? [Sun Aug 6 14:13:36 2017] bartavelle: what does your goal and hypotheses look like? [Sun Aug 6 14:17:58 2017] bartavelle: rewriting under lambdas might need some axioms, so in general no [Sun Aug 6 14:36:37 2017] if rewrite won't go, then you have to explode the thing and rewrite the fragments [Sun Aug 6 14:55:19 2017] destructing the argument to the lambda tended to help me [Sun Aug 6 14:55:25 2017] as then lambda gets simplified [Sun Aug 6 14:55:37 2017] or at least allows you to prove stuff about the lambda [Sun Aug 6 17:06:25 2017] humm [Sun Aug 6 17:06:36 2017] not sure I understand most of that advice :) [Sun Aug 6 17:06:49 2017] I think I'll work throught software foundations a bit more [Sun Aug 6 17:13:33 2017] my goal looks like : (fun (r : R) (sw : S * W) => fmap idf (m r sw)) = m [Sun Aug 6 17:13:41 2017] where idf is the identity function [Sun Aug 6 17:14:29 2017] and m being a functor, I should be able to drop the "fmap idf" part, except I don't know how to apply the relevant theorem inside the fun [Sun Aug 6 17:46:13 2017] equality of functions is fairly deep water [Mon Aug 7 02:16:52 2017] yeah, it seems I chewed more than I could swallow here [Mon Aug 7 02:26:40 2017] oh well :-/ [Mon Aug 7 03:07:09 2017] perhaps more mundane, here http://lpaste.net/357476 , how to apply em in H ? [Mon Aug 7 03:09:43 2017] The easier way is to just use excluded middle on "P x" [Mon Aug 7 03:09:57 2017] (you first need to introduce x of course) [Mon Aug 7 03:10:50 2017] I just noticed I could destroy em, but will try that first [Mon Aug 7 03:10:57 2017] destruct [Mon Aug 7 03:15:03 2017] thanks, that worked [Mon Aug 7 03:16:46 2017] what does coq do with divides by zero? [Mon Aug 7 03:17:23 2017] it occurred to me to wonder this afternoon because generally code objects in coq don't have explicit preconditions [Mon Aug 7 03:17:47 2017] and mostly that works because the environment has been safe-ified (although it's occasionally annoying) [Mon Aug 7 03:18:24 2017] it happens to return 0 in the case of natural numbers, for instance [Mon Aug 7 03:18:41 2017] then most theorems will be prefixed with the adequate precondition [Mon Aug 7 03:18:50 2017] hmm [Mon Aug 7 03:18:53 2017] right [Mon Aug 7 03:18:59 2017] I suppose that shouldn't surprise me [Mon Aug 7 03:19:34 2017] given that it's consistent with the general model everything uses [Mon Aug 7 03:19:51 2017] but it seems kind of disconcerting, too. [Mon Aug 7 03:20:24 2017] It is no different than "pred 0" returning 0 too, for instance [Mon Aug 7 03:22:28 2017] true, or how List.nth insists on being given a value to return in case the list isn't long enough [Mon Aug 7 03:22:43 2017] that one is less disconcerting but more annoying in practice :-) [Mon Aug 7 03:24:19 2017] I got my regexp proofs mostly finished last night, btw [Mon Aug 7 03:24:32 2017] You can always use nth_error or write your own version that takes a proof of non-emptiness, but yes, there has to be a catch whatever way you choose [Mon Aug 7 03:28:53 2017] carrying around proofs is a lot more natural in some ways, but it also makes things a lot more painful [Mon Aug 7 03:29:09 2017] particularly in coq because it's not set up to cope, but in general too [Mon Aug 7 03:29:44 2017] Program can help a little. You can write functions which takes sigma types [Mon Aug 7 03:29:49 2017] and use them nearly normally [Mon Aug 7 03:29:57 2017] take* [Mon Aug 7 03:32:20 2017] I have been thinking about how one might set up a framework that handles concurrent programs directly [Mon Aug 7 03:32:28 2017] (because I'm a glutton for punishment, or something) [Mon Aug 7 03:35:26 2017] and it seems like everything goes to hell the moment the hoare logic comes out [Mon Aug 7 03:35:50 2017] even without concurrencly (comparatively speaking, anyway) [Mon Aug 7 03:36:40 2017] and I realized that coq avoids this not because it's functional but because it's supersafe :-) [Mon Aug 7 03:38:31 2017] but it's unlikely that I'm going to have time to do anything substantive along these lines. [Mon Aug 7 09:57:11 2017] hi, I started learning Coq just a few days ago and I'm wondering if it's easily provable that #{f | f : X -> Y} = #Y^#X . If it's easy, I think I'll give some thought to it. I don't want to waste time trying to solve a very difficult problem [Mon Aug 7 10:00:00 2017] I'm not an expert, but I would guess that it all depends on your reprensentation of sets. [Mon Aug 7 10:03:03 2017] (and functions and functional extensionality ? is this ssreflect ?) [Mon Aug 7 10:04:32 2017] what is a representation of sets? [Mon Aug 7 10:09:00 2017] { _ | _ } and #_ are not primitive constructs and we don't know how they are implemented if you do not give more details [Mon Aug 7 10:12:34 2017] Without knowing what they are, it's hard to guage how bureaucratic a formal proof would get. As for the high-level strategy for proving the statement itself, it's likely to be the same whatever the implementation details are and not too complicated, but I guess you don't want to be spoiled :) [Mon Aug 7 10:20:46 2017] I thought it was obvious but by "#{f | f : X -> Y} = #Y^#X", I meant that "for finite sets X and Y, the number of total functions from X to Y is the number of elements in Y to the power of the number of elements in X" [Mon Aug 7 10:21:40 2017] oh, you meant in general [Mon Aug 7 10:23:04 2017] My guess would be that it's not trivial from scratch: you need to formalize sets, ordinal numbers, cardinal numbers, and only then you can state what you want to prove. But there are formalizations of set theory which already exist and certainly contain this kind of proofs [Mon Aug 7 10:23:35 2017] (CoLoR probably has something like this, maybe ssreflect) [Mon Aug 7 10:26:55 2017] hmm ... i'd like to prove only with rudimentary tactics for the time being so i'll keep it untouched. good to know it's not trivial, thanks [Mon Aug 7 17:14:02 2017] numee I started Coq about 2 weeks ago, doing first 4 chapters of SF and Cypi dh` and some other kinds folks have helped me quite a bit [Mon Aug 7 21:05:09 2017] nothing is trivial without its accompanying framework (pretty much) [Tue Aug 8 19:10:17 2017] <[1]ringer1> Hacked through SF Ch. 4 except for part of the last one, it says the proof is difficult. [Tue Aug 8 21:52:09 2017] Does anyone know how to get the code from software foundations to compile? It uses unicode characters like → instead of ->. [Tue Aug 8 21:53:51 2017] If you click the Download button on https://softwarefoundations.cis.upenn.edu/current/index.html, you will get an archive which contains, among other things, one .v file per chapter [Tue Aug 8 21:53:57 2017] these .v files do not contain unicode characters [Tue Aug 8 21:54:12 2017] (and the html files are actually produced from these .v files) [Tue Aug 8 21:55:23 2017] Cypi: Thanks [Tue Aug 8 22:32:34 2017] <[1]ringer1> Whoo-ieeee got SF Chapter 4 done. [Wed Aug 9 00:07:51 2017] Is there a coq ide with a native gui for macOS? [Wed Aug 9 00:09:06 2017] Doesn't CoqIDE work? [Wed Aug 9 00:09:13 2017] (if it doesn't, sorry, I don't know) [Wed Aug 9 00:13:30 2017] Cypi: It works but it is obviously not built for macOS. [Wed Aug 9 00:15:07 2017] do you have any particular issue with it, or does it just not look right to you? [Wed Aug 9 00:16:36 2017] Dodek: It randomly crashes, the undo shortcut is command U (it should be command Z), and the menu bar is in the wrong spot. [Wed Aug 9 00:17:42 2017] <[1]ringer1> Much of the Windows interface is wrong also in CoqIDE and it crashes in low memory (for sure) [Wed Aug 9 00:18:07 2017] It also just looks off in the same way the java apps do [Wed Aug 9 00:18:21 2017] <[1]ringer1> I guess it is written in OCaml and maybe that is somewhere I could contribute sometime [Wed Aug 9 00:18:38 2017] <[1]ringer1> xcmw, on Windows also [Wed Aug 9 00:18:40 2017] The UI itself in just a basic Gtk UI :/ [Wed Aug 9 00:18:49 2017] s/in/is [Wed Aug 9 00:19:17 2017] <[1]ringer1> It's not terrible but much of the time I copied to my editor, fixed and re-pasted [Wed Aug 9 00:19:17 2017] Cypi: Is there one with a cocoa or web based ui? [Wed Aug 9 00:19:43 2017] This exists: https://x80.org/rhino-coq/ [Wed Aug 9 00:19:57 2017] <[1]ringer1> I do like the way it steps and reverses though [Wed Aug 9 00:20:05 2017] I never used it seriously, I don't know how stable it is, nor how usable it is. But I know it was made by someone who cares about UI :) [Wed Aug 9 00:21:31 2017] <[1]ringer1> It would be nice if coqc would say where the incomplete proof started :) but of course that was my fault :) [Wed Aug 9 00:22:04 2017] <[1]ringer1> good night (or day) all [Thu Aug 10 07:36:34 2017] I have a question regarding classes in Coq. Is the Class/Instance vernacular essentially building a class using the Cannonical Structure as described in the tutorial https://hal.inria.fr/hal-00816703v1/document [Thu Aug 10 07:36:48 2017] Or is it something differnt [Thu Aug 10 07:48:35 2017] I believe type classes and canonical structures are different mechanisms [Sat Aug 12 12:53:28 2017] I'm working through the Software Foundation book. Is there an issue tracker or something equivalent for it? I had a small issue with the list notation in IndProp.v in the version from this spring. [Sat Aug 12 20:02:43 2017] why won't omega retire a * b > 0 given a > 0 and b > 0? [Sat Aug 12 20:02:51 2017] (in nat) [Sat Aug 12 20:09:00 2017] also, while I'm at it, what's the point of Nat.mul_lt_mono_neg_l? [Sat Aug 12 20:09:11 2017] Nat.mul_lt_mono_neg_l [Sat Aug 12 20:09:11 2017] : forall p n m : nat, p < 0 -> n < m <-> p * m < p * n [Sat Aug 12 20:09:27 2017] it's not wrong, because the premise is False, but it seems questionable [Sat Aug 12 23:10:23 2017] <[1]ringer1> Does anyone have a reference for producing a PDF of Software Foundations (or generically if not) -- in Windows if it matters, but I'll take anything you know please [Sat Aug 12 23:30:08 2017] [1]ringer1: I got my copy from https://github.com/mietek/software-foundations. [Sun Aug 13 00:15:46 2017] dh` : omega only solves Presburger arithmetic, so no multiplication between variables [Sun Aug 13 00:15:58 2017] <[1]ringer1> Sorry, I wasn't careful in my question -- what I really am trying to do is product a Logical Foundations from the new sources where they split the book into 3 parts [Sun Aug 13 00:15:58 2017] (you can multiply by a constant but that's it) [Sun Aug 13 00:16:55 2017] <[1]ringer1> s/product/produce/ the LF book from the 2017 *.v and Makefile etc.0 [Sun Aug 13 00:30:38 2017] oh, right. [Sun Aug 13 02:04:57 2017] 'ring' can solve certain abstract problems involving multiplication [Sun Aug 13 05:44:35 2017] <[1]ringer1> ring automates commutative and associative structures for rings and semi-rings (field is similar for field structures) [Sun Aug 13 06:10:48 2017] <[1]ringer1> simplification and such [Sun Aug 13 08:29:39 2017] Is https://coq.inria.fr/ down or is it just me? Haven't been able to get there since sometime yesterday (from 2 separate networks) [Sun Aug 13 08:30:17 2017] It is down, yes. Server down for some reason, but since it's Sunday it probably won't be fixed until tomorrow :/ [Sun Aug 13 11:19:39 2017] With ltac "match goal" patterns, how do you match terms with bound variables? something like: match goal with H : forall (x : ?A), ?B |- _ => idtac end. [Sun Aug 13 11:21:34 2017] But with being able to subsitute x with something later. [Sun Aug 13 11:49:59 2017] Answered my own question: the solution is to use (@?P fv1 fv2 ...). [Sun Aug 13 12:48:34 2017] * [Sun Aug 13 15:49:27 2017] my question about Nat.mul_lt_mono_neg_l stands though :-) [Sun Aug 13 15:49:33 2017] what was that question? [Sun Aug 13 15:50:31 2017] why it exists, given that it's about negative nats, which don't [Sun Aug 13 15:51:26 2017] a "negative nat" is just zero [Sun Aug 13 15:51:44 2017] so I read this theorem as saying that multiplying by zero on both sides, or anything less than zero, has no effect on le [Sun Aug 13 15:52:35 2017] for example, you might have p - (p * 2). You won't know the value, but you'll know it's <= 0 [Sun Aug 13 15:53:01 2017] (that is to say, it's zero :) [Sun Aug 13 16:56:37 2017] well, the lemma's perfectly valid, given that it can be simplified to False -> irrelevant stuff [Sun Aug 13 16:57:08 2017] (it's "p < 0", not <=) [Sun Aug 13 16:57:22 2017] it just seems odd to have such stuff in the library [Sun Aug 13 16:57:39 2017] I guess they're there as parallel constructions with Z or something? that's about the only thing I can think of [Sun Aug 13 17:09:44 2017] dh` : yes, that's the reason [Sun Aug 13 17:10:09 2017] Nat is currently built as the result of the application of a functor to a module which specifies the basic operations and proves their most basic properties [Sun Aug 13 17:10:14 2017] and then derives a bunch of lemmas [Sun Aug 13 17:10:19 2017] ah [Sun Aug 13 17:10:21 2017] I was wondering about that [Sun Aug 13 17:10:24 2017] this functor is used for Nat, Z and so on, afaik [Sun Aug 13 17:10:38 2017] this is both kind of nice, and very annoying when looking for the definition of a lemma :) [Sun Aug 13 17:10:57 2017] how do you make a functor produce a toplevel module? [Sun Aug 13 17:11:02 2017] (and is there a way to do that in ocaml? [Sun Aug 13 17:11:04 2017] ) [Sun Aug 13 17:11:42 2017] oh wait, it isn't a toplevel module. derp [Sun Aug 13 17:11:44 2017] never mind, I'm stupid today [Sun Aug 13 17:15:58 2017] s/today// [Sun Aug 13 18:50:30 2017] ah, I didn't see just <; it seems in my browser it was an underlined < [Sun Aug 13 19:28:23 2017] heh, dangerous that :-) [Sun Aug 13 22:06:02 2017] is there a way to chain two Search patterns together? [Sun Aug 13 22:06:14 2017] the equivalent of unix "grep foo myfile | grep bar" [Sun Aug 13 22:54:25 2017] Search "foo" "bar"? [Mon Aug 14 04:01:40 2017] huh, didn't realize you could do that [Mon Aug 14 04:09:28 2017] What specifically does tauto DO? It doesn't have an info_tauto. I can complete the goal with it but want to know how. [Mon Aug 14 04:11:03 2017] I have in context: A, B:Prop ; H : A \/ B Goal is: (A -> False) /\ (B -> False) -> False -- it's obvious but how to complete it in Coq? [Mon Aug 14 04:12:46 2017] You can take a look at the proof from tauto with "Show Proof" (after calling tauto). [Mon Aug 14 04:13:52 2017] Now to prove it yourself, you can start by introducing this "~A /\ ~B" hypothesis in your context, and see if you can derive an absurdity by examining H [Mon Aug 14 04:25:39 2017] Ok, Cypi that should help -- didn't know Show Proof would show details, I did intros "~A /\ ~B" but was stuck again and tauto still worked. [Mon Aug 14 04:26:27 2017] Show Proof just show the proof term. It might be complicated to read, but it tells the truth. [Mon Aug 14 04:27:04 2017] Well, you can try to reason it before trying to prove it in Coq. You know that either A or B holds, and you also know that both A and B do not hold. [Mon Aug 14 04:27:44 2017] What you can do is say "If A holds, then I get a contradiction because A does not hold ; If B holds, then I get a contradiction because B does not hold" [Mon Aug 14 04:28:03 2017] So this just a disjunction on the fact that either A or B holds [Mon Aug 14 04:28:09 2017] Now, to convert that to Coq [Mon Aug 14 04:28:37 2017] Yes, Cypi, the conversion is where I was stuck [Mon Aug 14 04:28:51 2017] You know about "destruct", right? [Mon Aug 14 04:29:07 2017] I got to False by introducing -- yes, I know some about destruct [Mon Aug 14 04:29:30 2017] when I destruct 'd it seemed I was going in a circle -- let me retry [Mon Aug 14 04:51:02 2017] is there some way to write 'exists ... in H??' ? [Mon Aug 14 04:51:40 2017] (ie., how do I use hypothesis with an "exists" qualifier?) [Mon Aug 14 04:51:45 2017] You destruct it [Mon Aug 14 04:51:59 2017] You do not want to provide a witness to it, you want to extract a witness and a proof from it [Mon Aug 14 04:52:14 2017] I can't destruct it for some reason [Mon Aug 14 04:52:34 2017] Wild guess: your goal is not in Prop [Mon Aug 14 04:52:41 2017] ah, but I have an error message [Mon Aug 14 04:53:08 2017] destruct ... with did the trick, thanks [Mon Aug 14 09:14:11 2017] hmm..https://coq.inria.fr/ is still down.. [Mon Aug 14 09:39:52 2017] petercommand, I miss coq.infria.fr :( [Mon Aug 14 09:40:04 2017] petercommand: today is inria holiday and tomorrow is public holiday [Mon Aug 14 09:40:33 2017] I think it won't be fixed before wednesday [Mon Aug 14 09:43:09 2017] sgnb: that's..too bad :Q [Mon Aug 14 09:43:16 2017] ringer1: me too :( [Mon Aug 14 09:45:06 2017] https://sympa.inria.fr/sympa/arc/coqdev/2017-08/msg00012.html [Mon Aug 14 09:46:04 2017] coq.inria.fr being compromised... that's a milestone... [Mon Aug 14 11:24:45 2017] petercommand, I am a newbie and most of my google searches were taking me there -- it went down sometime (early?) Saturday for me [Mon Aug 14 11:27:36 2017] sgnb, thx, at least knowing they are working on it helps (and Tue is a holiday there argh!) [Mon Aug 14 11:39:40 2017] clearly the world needs a verified bug database :-) [Mon Aug 14 15:55:30 2017] Hi, I need a proof of (n:nat) -> n/1 = n, I can see there is such a lemma in NDiv, but I don't know how to instantiate to nat. [Mon Aug 14 15:56:55 2017] i.e., do Peano nats implement the modules in Numbers.Abstract.* ? [Mon Aug 14 15:58:11 2017] yup [Mon Aug 14 15:58:20 2017] Nat.div_1_r should be what you need? [Mon Aug 14 16:00:30 2017] ok, I did a Require Import NDiv, how do I access div_1_r for nat? [Mon Aug 14 16:01:02 2017] (I'm not very comfortable with using coq modules/functors) [Mon Aug 14 16:01:34 2017] You don't need to know anything about modules/functors. The easiest way is to just do "Require Import Arith.", then "Nat.div_1_r" is what you need [Mon Aug 14 16:02:20 2017] oh, that worked! [Mon Aug 14 16:02:35 2017] Does that mean the Nat module implements the NDiv module type? [Mon Aug 14 16:02:39 2017] alternatively, just "Require Import PeanoNot." is sufficient and imports less stuff; it's up to you [Mon Aug 14 16:02:52 2017] among other things, yes [Mon Aug 14 16:04:26 2017] https://github.com/coq/coq/blob/master/theories/Arith/PeanoNat.v the definition is here if you're interested (disclaimer: it's not very readable, and you need to dig through a lot of files to get a full picture) [Mon Aug 14 16:05:43 2017] thanks [Mon Aug 14 17:25:50 2017] oh yeah, I was meaning to ask [Mon Aug 14 17:25:59 2017] Require Import Arith gets the entire arith subtree? [Mon Aug 14 17:35:19 2017] only if it itself does a Require Export of those sub modules [Mon Aug 14 18:23:13 2017] so ls -ls prints 10 and ls -l says 4067 bytes? [Mon Aug 14 18:23:15 2017] gah [Mon Aug 14 18:23:25 2017] (wrong window) [Mon Aug 14 18:24:29 2017] johnw: the reason I was wondering is that the manual lists a lot of stuff under Arith and it's not clear what Require Import Arith. by itself does [Mon Aug 14 18:24:42 2017] that is, which of those it includes and which it doesn't, or if it's something else entirely [Mon Aug 14 18:24:55 2017] also the library index doesn't mention a number of other toplevel modules, like Omega [Mon Aug 14 18:25:12 2017] by index I mean https://coq.inria.fr/library/ [Tue Aug 15 00:41:19 2017] thx Cypi, it seems I needed to learn more about destruct (which I suspected) and managing the Context in general. This gave me focus for reading several of the books and a couple tutorials. [Wed Aug 16 13:45:22 2017] is there an option to disable positivity checking for inductives? googling shows an email that says "no", but it's from 2013 [Wed Aug 16 13:49:25 2017] So, there is https://github.com/coq/coq/pull/79, which was merged. [Wed Aug 16 13:49:33 2017] However I think there is no user-available syntax for now, sadly [Wed Aug 16 13:49:40 2017] So the answer would be no, unless I'm wrong [Wed Aug 16 14:00:26 2017] Cypi: thanks! seems it's not accessible indeed [Wed Aug 16 15:04:41 2017] dogui: what's your type? [Wed Aug 16 15:04:48 2017] there are existential tricks you can sometimes play [Wed Aug 16 15:05:01 2017] the resulting type is larger than the original type, but might suffice depending on your problem [Wed Aug 16 15:34:14 2017] coq.inria.fr is back up (at least partially -- didn't check everything) [Wed Aug 16 15:44:29 2017] ringer1: !! horay [Wed Aug 16 16:07:40 2017] btw, if there are any Mac users here, Dash is a great way to view/search the Coq documentation [Wed Aug 16 16:09:16 2017] the particular docsets must be downloaded and then installed (by double-clicking on them) from here: https://wiki.mq.edu.au/display/plrg/Resources [Wed Aug 16 16:09:32 2017] includes both the Coq docs, and the stdlib [Wed Aug 16 16:09:48 2017] I love it because not only is it very fast and works well, but it works *offline* [Wed Aug 16 20:22:29 2017] johnw: oh no I actually wanted to break consistency :) to show how to do recursion through one such type [Wed Aug 16 20:22:54 2017] johnw: I'm currently assuming a constructor/destructor to get the paradox, so no big deal also [Thu Aug 17 09:37:55 2017] Does anyone know if it is possible to make an argument for a tactic/tactic notation be parsed in a specific scope? [Thu Aug 17 09:39:09 2017] Like, for constants it's possible to do [Arguments f a1%E a2%E a3%V] [Thu Aug 17 09:47:43 2017] Hi, what is a good textbook for understanding theoretical foundations of Coq (Curry-Howard isomorphism or natural deduction or that kind of thing, I guess?)? Girard's Proofs and Types looked too succinct for me... [Thu Aug 17 09:49:59 2017] there's e.g. http://purelytheoretical.com/sywtltt.html, but maybe there's something more specific to coq [Thu Aug 17 09:52:08 2017] (also https://github.com/jozefg/learn-tt) [Thu Aug 17 09:54:09 2017] thanks! I'll take a look at the books referenced in these pages [Thu Aug 17 09:57:08 2017] there's also chapter 4 in the reference manual, and some links in the official faq, but i think those things make more sense if one knows about dt in general. [Thu Aug 17 10:01:10 2017] I'm trying to decide equality for mutually recursive/nested types, I'm not sure how to correctly refer to my example. https://gist.github.com/dredozubov/ca3d16c54f37b036612e24ce263e06e6 [Thu Aug 17 10:02:17 2017] I've discovered Fixpoint .. with .. , but I'm having problems proving the termination to totality checker. I'm getting an error, while trying to Qed the theorem. [Thu Aug 17 10:15:45 2017] Coq'Art might fit the bill -- it has more on CiC and CoC I believe. It's on archive.org so apparently it's legitimately free. https://archive.org/details/springer_10.1007-978-3-662-07964-5 [Thu Aug 17 10:16:59 2017] ringer1: i don't think there's much theory in coq'art? but i haven't looked very closely... [Thu Aug 17 10:18:16 2017] cic, I am still in the fairly early chapters of CoqArt, Pierce SF, and Chlipala CPDT -- I'm more interested in pragmatics myself. [Thu Aug 17 10:29:48 2017] IIRC Coq'Art doesn't describe how a type in Coq corresponds to a proposition in (intuitionistic?) logic, which I'd like to understand these days. [Thu Aug 17 10:31:01 2017] In order to understand foundations of Coq, I learned how to draw Gentzen-style natural deduction proof diagrams, but I have no idea how it translates to expressions in Coq (Gallina, to be precise?). [Thu Aug 17 10:31:30 2017] seen http://homepages.inf.ed.ac.uk/wadler/papers/propositions-as-types/propositions-as-types.pdf? [Thu Aug 17 10:34:16 2017] i haven't seen that paper. i'll read it [Thu Aug 17 10:34:49 2017] to some extent coq'art and SF talks about curry howard also, how to encode e.g. AND as an inductive type [Thu Aug 17 11:30:20 2017] IntroductionToTheCoqProof-AssistantForPracticalSoftwareVerification-Paulin-MohringCourse-notes.pdf has an intriguing table relating introduction and elimination rules to Coq tactics (which I wish I understood a bit better or had more of an explanation) [Thu Aug 17 11:30:44 2017] (That's my version of the title, the real title is very similar though) [Thu Aug 17 12:25:56 2017] you're referring to this? https://www.lri.fr/~paulin/LASER/course-notes.pdf it seems quite helpful, thanks! [Fri Aug 18 01:45:26 2017] numee, yes, there are several at about this size, ~60 pages, so far (I'm about half way through 3 or 4) they are all good in their own way. Paulin-Mohring course-notes, Huet TheTutorial, Bertot Coq-in-a-Hurry, Chlipala's intro (in addition to CPDT) [Fri Aug 18 01:46:02 2017] And of course Mike Nahas html tutorial on the Coq site [Fri Aug 18 01:46:41 2017] Best is to get the .v files for the ones you can find Nahas for certain.) [Fri Aug 18 02:59:18 2017] Cypi, dogui: No syntax, currently. You could add syntax with a plugin, though, I think. coq.inria.fr is currently down, but I plan to submit a enhancement report for this when it's back up. [Fri Aug 18 03:07:12 2017] ringer1: The table in that pdf is overly complicated, I think. There are two tactics for introduction rules: "intro", for the Pi/forall/arrow-style rules (which included negation), and "constructor" (or "constructor 1", "constructor 2", etc.) for inductives. ("split" = "constructor" for and, "left" = "constructor 1", "right" = "constructor 2", "reflexivity" = "constructor", "exists t" = "constructor with ...."). Similarly, there are two [Fri Aug 18 03:07:12 2017] tactics for elimination rules: "apply" for Pi/forall/arrow, and "destruct" for inductives. (You can simulate "rewrite" with "pattern" and "destruct". The "exfalso" rule is kind-of bogus; if you replace the ? up top with a name, say, h, then you can instead do "destruct h".) [Fri Aug 18 03:10:07 2017] jgross, it seems strange to me that among all the intro/tutorial resources and similar chapters in the longer books there doesn't seem to be SIMILAR and excellent summaries of when to use each tactic. [Fri Aug 18 03:10:26 2017] This implies it is either very hard or bad teaching/exposition. Maybe both. [Fri Aug 18 03:20:34 2017] what do you mean by "when to use each tactic"? e.g. when to use "left" rather than "constructor 1"? if so, i think it's difficult to say something more than "do the most readable thing" (in this case there can only be two constructors if you are going to use left, but that's just a detail for this tactic i would say)... [Fri Aug 18 03:20:45 2017] or maybe you mean something like http://matejkosik.github.io/www/doc/coq/notes/01__tactics.html? [Fri Aug 18 03:29:05 2017] ringer1: Have you seen http://adam.chlipala.net/itp/tactic-reference.html ? [Fri Aug 18 03:34:48 2017] But I think one issue is that the tactics are not well organized. For example, show me someone who can say what the different is between "eexact" and "exact" (I don't believe even any of the Coq devs can say what the difference, if any, is, and I certainly can't). The question of when to use "dependent destruction" vs "destruct" vs "case" vs "elim" vs "induction" is roughly "use induction if it's recursive, destruct if it's not, but if [Fri Aug 18 03:34:48 2017] destruct gives you dependent type errors, you can try elim or case (not sure what the difference is); if the type errors come from the type of the thing being eliminated rather than the goal, use inversion rather than case, and if you actually need destruct rather than inversion, but destruct gives you type errors, try dependent destruction; if you need to not depend on UIP, then implement your own version of dependent destruction". And if [Fri Aug 18 03:34:48 2017] you're using equality, use "rewrite", unless your equality shows up dependently, in which case, try "subst". If that fails, you'll probably need "generalize dependent" before you can "subst". Isn't that a lovely decision tree? [Fri Aug 18 03:46:50 2017] all, thx, cic, I'll take a look, jgross, I have the chlipala but review to see if I'm missing something, my claim is that proving stuff is either very hard or there should be a reasonable 80% explanation that's pretty simple (at least for beginner level+ problems) [Fri Aug 18 03:58:54 2017] cic, this does look it might have more of what I am seeking -- will have to try using it as I work ( http://matejkosik.github.io/www/doc/coq/notes/01__tactics.html? ) [Fri Aug 18 04:05:21 2017] It's the (good) examples that seem to make matejkosik's work -- to be fair, Nahas is good too -- it just starts off with different types of proofs than my exercises have contained, and I haven't finished working through the Nahas page yet. Summary at bottom seems good once yo work through it. Chlipala links are broken right now, either in the page or Coq.inria.fr is down again. [Fri Aug 18 04:08:40 2017] inria is down apparently [Fri Aug 18 16:49:19 2017] Any guidelines for deciding between modules and sections? [Fri Aug 18 16:52:53 2017] i avoid modules [Fri Aug 18 16:52:59 2017] they are almost always a pain [Fri Aug 18 16:57:32 2017] johnw: Thanks! [Sat Aug 19 16:02:16 2017] is there a way to use "replace" only in part of an expression ? [Sat Aug 19 16:07:42 2017] hum rewrite can do that [Sat Aug 19 16:16:33 2017] How do you instantiate an FMapAVL with binary natural numbers as keys? https://hastebin.com/ezikukuyar.erl [Sat Aug 19 16:34:57 2017] I got it - it looks like there were two different things called OrderedType [Mon Aug 21 12:37:00 2017] when coq gives me a (fun x: ...) where x had a product type, is there a tactic that can change it too (fun (x1,x2): ...) ? [Mon Aug 21 12:39:28 2017] (fun '(x1, x2) => ...) [Mon Aug 21 12:39:32 2017] (fun is in an inner expression, so i can't use functional_extensionality) [Mon Aug 21 12:39:38 2017] oh, you mean that's your goal [Mon Aug 21 12:39:41 2017] yes [Mon Aug 21 12:40:06 2017] and where does the (fun X: ...) occur? [Mon Aug 21 12:40:21 2017] what do you mean? [Mon Aug 21 12:40:29 2017] without more context, I can't answer [Mon Aug 21 12:40:32 2017] ok [Mon Aug 21 12:40:38 2017] can you show me what your goal looks like? [Mon Aug 21 12:40:47 2017] sure [Mon Aug 21 12:41:53 2017] http://lpaste.net/4656716817790664704 [Mon Aug 21 12:43:00 2017] have you tried "setoid_rewrite func_comp"? (or however you've named that law) [Mon Aug 21 12:44:50 2017] i'll look this tactic up thanks! [Mon Aug 21 12:45:17 2017] More manually, you could also just use functional_extensionality on the outer lambdas until the goal is more manageable, right? [Mon Aug 21 12:46:20 2017] I don't think I can here [Mon Aug 21 12:46:47 2017] that was my first try [Mon Aug 21 12:48:18 2017] I can't because I am on a monad transformer I think [Mon Aug 21 12:49:47 2017] actually I think there is a simpler way, BRB [Mon Aug 21 12:50:52 2017] I think that's because I don't understand typeclasses yet in coq, I'll work some more on that! [Mon Aug 21 12:52:50 2017] ah it was actually trivial :/ [Mon Aug 21 13:26:35 2017] is there an easy way to prove 65537 is prime without using fancy tools like ssreflect or customized tactics? [Mon Aug 21 13:40:17 2017] numee: there might be a theorem proving the correctness of some simple primality-checking algo, in which case you can just apply that [Mon Aug 21 13:58:25 2017] benzrf: All I managed to find was ZArith/Znumtheory.v and it doesn't seem to help me as it takes many steps just to prove 3 is prime: https://github.com/maximedenes/native-coq/blob/cb563ddaa6e46cd44390fbfc75fe3abf35041bde/theories/ZArith/Znumtheory.v#L661 [Mon Aug 21 14:01:33 2017] Why does discriminate fail to solve with an "m = S m" hypothesis? https://hastebin.com/yuwuwagavu.erl [Mon Aug 21 14:02:25 2017] MichaelBurge: because there aren't constructors on both sides [Mon Aug 21 14:02:41 2017] MichaelBurge: and what if it were co-inductive? discriminate needs to see Z = S _ [Mon Aug 21 14:03:14 2017] That makes sense - thanks! [Mon Aug 21 14:07:22 2017] Perhaps the motivating example in the documentation should be changed then, since it can't actually solve S (S 0) = S 0 directly: https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic78 [Mon Aug 21 14:08:08 2017] Nevermind, I tested that wrong. [Mon Aug 21 14:30:42 2017] numee: try writing a primality testing function and proving it correct :> [Mon Aug 21 14:36:44 2017] hmm, I'm curious to see how that would go actually... [Mon Aug 21 15:38:17 2017] Oh right. 65537 in unary is an immediate stack oeverflow :v [Mon Aug 21 15:38:19 2017] overflow* [Tue Aug 22 03:54:20 2017] I have something like "foo >>= (fun x => let (a,b) := x in pure (a,b))", how can I turn that goal into "foo >>= pure" ? [Tue Aug 22 03:59:44 2017] or really if there is any reference on the tactic names for working "inside" lambdas [Tue Aug 22 04:00:29 2017] johnw: told me about setoid which kind of look like what I want [Tue Aug 22 04:01:24 2017] but I am not sure that's it [Tue Aug 22 04:04:57 2017] ah I can with an assert! [Tue Aug 22 04:26:53 2017] well, if someone has pointers for working inside lambdas in goals, that would be appreciated [Tue Aug 22 05:51:29 2017] idk, maybe compute reduces inside lambdas? [Tue Aug 22 08:51:13 2017] I managed to massage the expressions [Wed Aug 23 10:08:39 2017] hello, I think I did something wrong with my usage of typeclasses here : http://lpaste.net/2601183531925241856 [Wed Aug 23 10:09:20 2017] at the end of this file, I have a goal with (let (..,pure0,...) := FRSST R S ... in pure0) [Wed Aug 23 10:09:37 2017] how can I switch that with the actuall implementation of pure for "FRSST R S ..."? [Wed Aug 23 10:09:51 2017] I suppose I did something wrong with my instance declaration [Wed Aug 23 12:36:20 2017] Hello, I'm very new to coq. I'm trying to prove that `forall a b : nat, S a = S b -> a = b.`. But I don't see how to do that. I've tried destruct, but I didn't get anywhere with it. [Wed Aug 23 12:38:57 2017] you need the inversion tactic for that one [Wed Aug 23 12:41:28 2017] oh, thanks, that worked - but i didn't get how inversion works [Wed Aug 23 12:42:17 2017] (induction ?) [Wed Aug 23 12:43:13 2017] so inversion just removes inductive costructors from both sides of an equality? [Wed Aug 23 12:47:12 2017] ski, but in induction i still get subgoals like forall a b : nat, S a = S b -> a = b. is there a way to deal with those other than inversion? [Wed Aug 23 12:47:28 2017] sorry, i meant 1 = S (S b') -> 0 = S b' [Wed Aug 23 13:08:58 2017] michbad: There's congruence: https://hastebin.com/exexiqapij.erl [Wed Aug 23 13:11:07 2017] I suspect it's probably equivalent, though [Wed Aug 23 13:13:00 2017] thanks, i'll have a look! i'm just starting with 'Software Foundations', so i'm not familiar with most of the tactics. [Wed Aug 23 13:20:36 2017] there's injection as well [Wed Aug 23 13:21:20 2017] michbad: there's a lemma for S a = S b -> a = b [Wed Aug 23 13:22:15 2017] eq_add_S [Wed Aug 23 13:22:30 2017] (found with "SearchAbout [ S eq ].") [Wed Aug 23 13:27:46 2017] You could also do f_equal pred H. [Wed Aug 23 14:06:50 2017] hmm [Wed Aug 23 14:07:07 2017] if I have: {x = foo} + {exists y, x = bar y} [Wed Aug 23 14:07:24 2017] how can I match or test this to extract y? [Wed Aug 23 14:09:21 2017] one can use if to test a {} + {}, but that doesn't have any way to bind y on the else side, and I can't figure out the match syntax [Wed Aug 23 14:27:51 2017] bah. [Wed Aug 23 14:27:52 2017] Elimination of an inductive object of sort Prop [Wed Aug 23 14:27:52 2017] is not allowed on a predicate in sort Set [Wed Aug 23 14:27:52 2017] because proofs can be eliminated only to build proofs. [Wed Aug 23 14:29:43 2017] I don't think this approach is going to work [Wed Aug 23 14:29:45 2017] * deletes [Wed Aug 23 14:30:44 2017] dh`: this is the syntax, but you do have to be going into Prop: http://lpaste.net/357917 [Wed Aug 23 14:47:32 2017] yeah, and unfortunately it doesn't work [Wed Aug 23 15:08:37 2017] (I figured out a workaround for the syntax, but it inevitably generates the same problem) [Wed Aug 23 15:08:45 2017] oh well [Wed Aug 23 16:40:06 2017] ok, further conclusion: trying to put together a common set of theorems for lists and strings and other sequence types isn't going to work, or at least not very well. [Wed Aug 23 16:41:07 2017] There are too many magic things implicit in the fact of an inductive type with two constructors. [Wed Aug 23 16:41:39 2017] Trying to make them all explicit makes a huge mess. [Wed Aug 23 16:41:53 2017] And there doesn't seem to be a way to abstract over constructors as constructors. [Wed Aug 23 16:42:44 2017] You can put "Inductive foo := ..." in a module type, but then you can't instantiate it with an existing type. [Wed Aug 23 16:42:59 2017] (AFAICT, anyway, but you can't in ML so it would surprise me if it worked) [Wed Aug 23 16:43:36 2017] But if you don't have that magic "Inductive" word there, the objects you have are no longer constructors. [Wed Aug 23 16:45:50 2017] And you lose the ability to e.g. match, and have coq believe in termination, and do inversions, and various other things. [Wed Aug 23 17:57:34 2017] ... why does "contradict H" sometimes add ~(goal) to your hypothesis bank and sometimes not? [Wed Aug 23 19:32:08 2017] when it does, it's very useful... otherwise not so much [Wed Aug 23 19:37:40 2017] dh` : https://coq.inria.fr/refman/Reference-Manual010.html#hevea_tactic71 for what "contradict" does. It does not always work in intuitionistic logic to add ~(goal) to your hypotheses. [Wed Aug 23 19:38:08 2017] (if you want to prove "A -> B", it is usually not enough to prove "~ B -> ~ A" [Wed Aug 23 19:38:10 2017] ) [Wed Aug 23 20:25:03 2017] right, that much I know, it just so far hasn't made sense which cases this does and doesn't work in [Wed Aug 23 20:25:11 2017] or rather, which cases contradict does and doesn't work in [Wed Aug 23 20:25:58 2017] Is there a version of cbv that does just one reduction step? [Wed Aug 23 20:27:12 2017] looking at that table, I think the issue is/has been that it's not always obvious what coq thinks has a ~ at the front of it. [Wed Aug 23 20:31:44 2017] You can "Print Ltac contradict." and read it :) [Wed Aug 23 20:40:24 2017] huh, neat :-) [Wed Aug 23 20:40:48 2017] something else I've never understood (that I just stepped on) is why rewrite sometimes rewrites all matching instances and sometimes only the first [Wed Aug 23 20:41:32 2017] about 98% of the time it does what one wants magically, so it's not bad [Wed Aug 23 21:25:14 2017] Hmm, it looks like Coq's Haskell extraction uses GHC.Prim.Any, which was removed in the latest version of ghc-prim [Thu Aug 24 19:17:43 2017] Is there a list of all the extraction-related modules? This one doesn't seem to be listed in the standard library: https://coq.inria.fr/library/Coq.extraction.ExtrHaskellString.html [Thu Aug 24 23:28:58 2017] It doesn't look like the Record macro creates record update functions. Is the only way to update a single field to create a new record repeating all the other fields? [Fri Aug 25 03:34:14 2017] is there any documentation on type classes other than https://coq.inria.fr/refman/Reference-Manual023.html ? For some reason their snippets don't work with my coq version, I don't even understand my error messages [Fri Aug 25 03:34:37 2017] (I mean I can make their snippets work, but when doing something more complex I am stuck) [Fri Aug 25 03:39:19 2017] not a great deal, afaicr. [Fri Aug 25 03:39:28 2017] experience with haskell type classes is probably the best asset [Fri Aug 25 03:39:46 2017] I do have that, but the errors make no sense to me anyway [Fri Aug 25 03:40:54 2017] that would be nice if there was an alternative though, I started with something like "Functor := exists (fmap : ...), functorlaw1 /\ functorlaw2" [Fri Aug 25 03:41:10 2017] the chief thing I've found that causes inexplicable weird problems is that (unlike haskell) you have to carry the instance around explicitly in a lot of places [Fri Aug 25 03:41:11 2017] but the problem is that I don't know how to reuse that "fmap" in the applicative laws [Fri Aug 25 03:41:35 2017] dh` do you mind taking a look at a snippet and tell me if there is anything obviously wrong ? [Fri Aug 25 03:41:40 2017] sure [Fri Aug 25 03:42:18 2017] http://lpaste.net/4490512325148672000 [Fri Aug 25 03:42:24 2017] the problem is the last line [Fri Aug 25 03:42:42 2017] The expression "Applicative" of type "Type" cannot be applied to the term "RSST R W S M" : "Type -> Type" [Fri Aug 25 03:43:15 2017] whereas it looks exatly the same as "Fucntor" to me [Fri Aug 25 03:44:34 2017] (also are there built in identity/first functions in the standard library?) [Fri Aug 25 03:45:01 2017] (first specialized to tuples would be alright to me) [Fri Aug 25 03:47:26 2017] I think it's getting confused with implicit arguments [Fri Aug 25 03:47:53 2017] TBH, I more or less randomly put them on either sides of the ":" [Fri Aug 25 03:48:11 2017] (re first and identity, I dunno. I'd assume an identity exists, but remembering its name is probably harder than typing it in again) [Fri Aug 25 03:48:18 2017] :) [Fri Aug 25 03:48:35 2017] there's some reason you usually see all implicit arguments first [Fri Aug 25 03:48:48 2017] I forget what it is, but I'd suggest doing that [Fri Aug 25 03:49:01 2017] also try making all the implicit arguments explicit until it works [Fri Aug 25 03:49:50 2017] what does that mean? Adding a @ before Applicative here and filling the slots ? [Fri Aug 25 03:51:06 2017] alright, it now seems I have to fill the functor instance [Fri Aug 25 03:51:28 2017] except I don't know how to use my "RSSTFunctor" instance, as it doesn't seem to know it (Error: Unbound and ungeneralizable variable RSSTFunctor) [Fri Aug 25 03:52:21 2017] aim gun at foot, pull trigger, blame microsoft [Fri Aug 25 03:52:22 2017] oops [Fri Aug 25 03:52:29 2017] :) [Fri Aug 25 03:52:43 2017] seems fitting to my problem, except the microsoft part [Fri Aug 25 03:52:54 2017] change the {}'s to ()'s in the declarations, fill in all the bits [Fri Aug 25 03:53:03 2017] once it works you can try backing them off again [Fri Aug 25 03:54:23 2017] alright, that seems better, it asks me to pass something that has type "Functor ?123", but I can't seem to be able to use my previosuly defined instance [Fri Aug 25 03:54:33 2017] Error: Unbound and ungeneralizable variable RSSTFunctor [Fri Aug 25 03:55:03 2017] I had some success previously with stating that there was some functor instance, but them I can't prove anything as I can't access the definition of fmap [Fri Aug 25 03:55:14 2017] (or bind) [Fri Aug 25 03:56:04 2017] I also had success with stating all the functions / laws in a single typeclass (StateReaderWriterMonad, with functor+applicative+monad+state+writer+reader) [Fri Aug 25 03:56:17 2017] but this is annoying to work with [Fri Aug 25 03:58:17 2017] I don't understand what it's doing [Fri Aug 25 03:58:42 2017] the way you've got it though, Check Applicative prints [Fri Aug 25 03:58:44 2017] channel [Fri Aug 25 03:58:46 2017] erm [Fri Aug 25 03:58:58 2017] Applicative [Fri Aug 25 03:58:58 2017] : Type [Fri Aug 25 03:58:58 2017] where [Fri Aug 25 03:58:58 2017] ?m : [ |- Type -> Type] [Fri Aug 25 03:58:58 2017] ?F : [ |- Functor ?m] [Fri Aug 25 03:59:05 2017] and that can't be right [Fri Aug 25 03:59:27 2017] I trust you on that :) [Fri Aug 25 03:59:36 2017] well [Fri Aug 25 03:59:38 2017] perhaps it's the "`" that I cargo culted from the docs [Fri Aug 25 03:59:41 2017] you don't want the m argument to be implicit [Fri Aug 25 03:59:55 2017] yeah I, um, don't know what that does [Fri Aug 25 04:01:56 2017] dropping the "`" breaks my Monad class declaration [Fri Aug 25 04:02:14 2017] I don't know what any of this is doing, I guess I'll just write all the proofs in one giant blob [Fri Aug 25 04:02:45 2017] dropping the ` causes your Monad to break with the same problem as the other thing, which is that the type of Applicative isn't what you want it to be [Fri Aug 25 04:06:43 2017] there's something else going on here that I don't understand [Fri Aug 25 04:07:47 2017] perhaps related to the fact the snippets in the documentation are not working ? [Fri Aug 25 04:07:56 2017] They seem to be able to write this: [Fri Aug 25 04:08:10 2017] Class Applicative `{F: Functor m} := ... [Fri Aug 25 04:08:13 2017] and I need to write: [Fri Aug 25 04:08:17 2017] Class Applicative m `{F: Functor m} := ... [Fri Aug 25 04:08:36 2017] it would really help to know what that ` is supposed to do [Fri Aug 25 04:08:38 2017] :-/ [Fri Aug 25 04:10:20 2017] https://stackoverflow.com/a/31862550/1755520 [Fri Aug 25 04:10:49 2017] https://coq.inria.fr/distrib/current/refman/Reference-Manual023.html#sec692 [Fri Aug 25 04:12:03 2017] for which version of coq are those docs valid anyway ? [Fri Aug 25 04:12:24 2017] ah I see [Fri Aug 25 04:12:27 2017] 8.6.1, whereas I use 8.4 ? [Fri Aug 25 04:12:41 2017] 8.4 is pretty old... [Fri Aug 25 04:12:49 2017] that's waht comes with ubuntu [Fri Aug 25 04:12:56 2017] I'll fetch a more recent version [Fri Aug 25 04:20:48 2017] I'm not sure exactly what's wrong but it's definitely the implicit args and the `s that's screwing it up [Fri Aug 25 04:21:07 2017] I'll update and try to do it exactly as they do it in the documentations [Fri Aug 25 04:21:23 2017] thanks a lot for spending some time with this! [Fri Aug 25 04:29:59 2017] same problem [Fri Aug 25 04:30:37 2017] I can't copy-paste the documentation snippets [Fri Aug 25 04:30:42 2017] in particular I think the problem is that the ` is filling in with the wrong stuff [Fri Aug 25 04:30:55 2017] even their samples with Eq => Ord doesn't work [Fri Aug 25 04:31:16 2017] probably you need 8.6 [Fri Aug 25 04:31:21 2017] I just installed it [Fri Aug 25 04:35:25 2017] http://lpaste.net/3394384117989638144 [Fri Aug 25 04:35:29 2017] that works for me [Fri Aug 25 04:35:36 2017] (or, more accurately, it did a couple months ago) [Fri Aug 25 04:36:08 2017] I think that would also work to me, as you don't ask it to also be an applicative [Fri Aug 25 04:36:27 2017] my problem is that I want to write proofs for a monad transformer [Fri Aug 25 04:36:35 2017] that has "Monad m => Applicative (Foo m)" [Fri Aug 25 04:36:51 2017] and I need to have the proper "bind" definition to write the proofs [Fri Aug 25 04:37:03 2017] http://lpaste.net/3394384117989638144 <- with an instance [Fri Aug 25 04:37:04 2017] sure [Fri Aug 25 04:37:11 2017] I managed to have something like "exists bind", but I could not uinfold it [Fri Aug 25 04:37:19 2017] but it works so you can probably then get at least the eq/ord stuff to work too [Fri Aug 25 04:38:11 2017] I got that working, I wrote a huge class that contained all the functions and laws for functor/applicative/monad/state [Fri Aug 25 04:38:29 2017] if I do that, I have no problem proving all my laws [Fri Aug 25 04:38:53 2017] but then I wanted to add laws for say, writer, and I needed to alter that big blob [Fri Aug 25 04:39:18 2017] (also I don't know what you mean by having eq/ord stuff working, I copy/pasted from the docs and it doesn't seem to work) [Fri Aug 25 04:39:20 2017] so what's specifically not working is class inheritance/derivation? [Fri Aug 25 04:39:29 2017] I *think* [Fri Aug 25 04:39:53 2017] I could get a monad constraint to prove the state laws [Fri Aug 25 04:39:59 2017] but then I couldn't unfold bind [Fri Aug 25 04:40:17 2017] it was some sort of generic bind that was in the environment, not the one I defined in another instance [Fri Aug 25 04:40:37 2017] where's the Eq => Ord example you're cribbing from? [Fri Aug 25 04:40:43 2017] the snippet I pasted is when I tried following the docs [Fri Aug 25 04:41:02 2017] https://coq.inria.fr/distrib/current/refman/Reference-Manual023.html [Fri Aug 25 04:41:26 2017] copy/paste the "Class EqDec (A : Type) := {" declaration [Fri Aug 25 04:41:39 2017] then the Ord from https://coq.inria.fr/distrib/current/refman/Reference-Manual023.html#sec695 [Fri Aug 25 04:41:48 2017] it whines about A being unknown [Fri Aug 25 04:42:08 2017] if you add an "A" before the "`", it works, but I suppose it doesn't do what it should [Fri Aug 25 04:50:43 2017] I'm not having any trouble writing down an Ord class that derives from an Eq class [Fri Aug 25 04:52:00 2017] http://lpaste.net/3969492664264425472 [Fri Aug 25 04:53:26 2017] I think the use of ` is what's causing your problems [Fri Aug 25 04:53:52 2017] hum, I'll try something like that [Fri Aug 25 04:56:18 2017] but how would you use eqq in your Instance ? [Fri Aug 25 04:57:41 2017] say you want Ord to also implent "lower than", and proove that "lee a b <-> eqq a b \/ ltt a b" [Fri Aug 25 04:57:46 2017] prove [Fri Aug 25 04:59:46 2017] (won't make much sense with bool) [Fri Aug 25 05:01:22 2017] this is where I got stuck : http://lpaste.net/8280026558127669248 [Fri Aug 25 05:05:46 2017] http://lpaste.net/3969492664264425472 [Fri Aug 25 05:07:49 2017] why are you stuck? [Fri Aug 25 05:08:05 2017] or, since that's kind of a useless question, what are you stuck on? [Fri Aug 25 05:10:06 2017] my goal is "(let (eqq0) := bool_eq in eqq0) a b = true \/ lt_bool a b = true" [Fri Aug 25 05:10:24 2017] in would like to have the definition of lt_bool [Fri Aug 25 05:10:30 2017] instead of that eqq0 [Fri Aug 25 05:10:48 2017] lemme look at your snippet [Fri Aug 25 05:12:41 2017] hummm [Fri Aug 25 05:12:46 2017] why does it work? :) [Fri Aug 25 05:12:47 2017] simpl will get rid of the useless let binding and leave you with eqb [Fri Aug 25 05:12:52 2017] I'll research that, thanks ! [Fri Aug 25 05:13:08 2017] what you want to unfold is not eqq but lt_bool and eq_bool [Fri Aug 25 05:13:55 2017] yeah it works for this proof [Fri Aug 25 05:14:08 2017] but to prove, say "get >>= put = pure ()", I need to unfold bind [Fri Aug 25 05:14:28 2017] you might not, depending [Fri Aug 25 05:14:37 2017] I think I really need in my case :) [Fri Aug 25 05:14:53 2017] but anyway simpl after unfold eqq makes the let rubbish go away [Fri Aug 25 05:15:26 2017] it does! [Fri Aug 25 05:16:45 2017] now I have to figure out why I can't reference my functor instance [Fri Aug 25 05:17:09 2017] I'm pretty sure that's from the implicit arguments and ` [Fri Aug 25 05:17:21 2017] yup [Fri Aug 25 05:17:24 2017] anyway i need to sleep, people will be hammering in 3h [Fri Aug 25 05:17:30 2017] thanks a lot ! [Fri Aug 25 05:17:35 2017] you're welcome :-) [Fri Aug 25 05:24:34 2017] ah, I think I get what my problem is! [Fri Aug 25 05:24:56 2017] I forget a damned Qed. !!!! [Fri Aug 25 05:25:16 2017] lol [Fri Aug 25 05:25:28 2017] just spent a few hours on that :) [Fri Aug 25 05:25:46 2017] well at least that's easy to solve. [Fri Aug 25 05:26:03 2017] sure! [Fri Aug 25 05:28:21 2017] is there a way to abort coq infinite loops in coqide? [Fri Aug 25 16:30:47 2017] bartavelle: this might be of interest: https://softwarefoundations.cis.upenn.edu/draft/qc-current/Typeclasses.html [Fri Aug 25 16:31:20 2017] (regarding your question on more documentation) [Fri Aug 25 23:59:57 2017] Does anyone have an idea as to how to prove f (if c then t else e) = (if c then f t else f e) ? [Sat Aug 26 00:02:53 2017] numee: destruct c; reflexivity. ? [Sat Aug 26 00:04:30 2017] Cale: thanks! [Sun Aug 27 23:32:09 2017] hrm [Sun Aug 27 23:32:26 2017] what would be a good simple program to do to muck with string code extraction? [Sun Aug 27 23:32:29 2017] not having any good ideas [Sun Aug 27 23:32:54 2017] (also, where should I look to get up to speed on doing extractions? haven't tried it before) [Mon Aug 28 00:20:38 2017] it's very easy to start [Mon Aug 28 00:20:54 2017] just Extraction Language . [Mon Aug 28 00:21:03 2017] then Extract "file.ext" func1 func2 func3. [Mon Aug 28 01:04:31 2017] neat [Mon Aug 28 02:49:21 2017] ugh why can't you use symmetry on <> ? [Mon Aug 28 03:35:26 2017] dh`: there's some information in VFA (e.g. https://www.cs.princeton.edu/~appel/vfa/Extraction.html), about extraction that is, but not much [Mon Aug 28 11:41:34 2017] hi. I use CpdtTactics in my project. It does not allow derivative works. Is using it without any changes a derivative Work? [Mon Aug 28 11:41:52 2017] that is, am I allowed to just place it into my project folder and load it? [Mon Aug 28 11:44:47 2017] or is this just a program library? [Mon Aug 28 11:45:58 2017] actually, I am only using the crush tactic. [Tue Aug 29 11:21:13 2017] Are there components of the C language like floats that are impossible to make proofs for? http://robbertkrebbers.nl/research/thesis.pdf This is "The C standard formalized in Coq", but it seems to not be capable of proofs for floating point arithmetic [Tue Aug 29 12:09:35 2017] justanotheruser: See CompCert -- I'm pretty sure it proves things about its implementation of floating point. [Tue Aug 29 12:10:05 2017] justanotheruser: It's not impossible, it's merely annoying to prove things about floats -- they don't have a whole lot of really nice properties. [Tue Aug 29 14:49:25 2017] It's possible that certain things about IEEE are too under-specified to prove certain things. [Tue Aug 29 14:50:13 2017] I'm not enough of an expert to say, though. [Tue Aug 29 17:01:50 2017] hi. I use CpdtTactics in my project. It does not allow derivative works. Is using it without any changes a derivative Work? that is, am I allowed to just place it into my project folder and load it? or is this just a program library? actually, I am only using the crush tactic. *push* [Thu Aug 31 07:48:16 2017] hi. I use CpdtTactics in my project. It does not allow derivative works. Is using it without any changes a derivative Work? that is, am I allowed to just place it into my project folder and load it? or is this just a program library? actually, I am only using the crush tactic. *push* [Thu Aug 31 07:59:49 2017] schoppenhauer: have you read the LICENSE file in the archive from the "Tarball of a few generally useful library modules from the book" link? [Thu Aug 31 08:51:38 2017] cpdtactics.v is licensed under bsd3 which allows for derivative works [Thu Aug 31 09:02:38 2017] yeah, its just really stupidly commented... [Sun Sep 3 08:14:35 2017] Hi, It seems that the "classical_right" tactic fails when there are no hypotheses in the context, is it known/expected ? for the moment my workaround is to "pose proof True", but is there a better way ? [Sun Sep 3 08:23:50 2017] Is adding the following axiom inconsistent? Inductive foo := foo_intro : foo -> foo. Axiom f : foo. [Sun Sep 3 08:24:50 2017] It's obviously ridiculous, as there's no way of inhabiting foo because no finite term can be an inhabitant of it, but I feel like this meta fact isn't accessible from inside of Coq in a way that yields inconsistency? [Sun Sep 3 08:37:43 2017] cq1: you can write foo -> False by recursion [Sun Sep 3 08:46:01 2017] Saizan: Awesome, thanks for the tip. I got it with that tip: https://pastebin.com/raw/m6W2hRx7 [Sun Sep 3 08:46:35 2017] Sorry, it was the blinding flash of the obvious once you said it. [Sun Sep 3 08:57:39 2017] cq1: cheers [Sun Sep 3 11:53:43 2017] zozozo: I have no idea, but that sounds like a bug and not desired behavior regardless of whether it's expected [Sun Sep 3 11:57:08 2017] dh`: I assumed as much, do you have any idea where I can open a bug report about it ? [Sun Sep 3 12:05:09 2017] I found the bugtracker and reported the problem [Sun Sep 3 13:59:22 2017] there, yeah [Sun Sep 3 13:59:41 2017] which reminds me, I still have a bug on to file on "congruence" [Sun Sep 3 14:09:02 2017] whatre yalls opinions on lean [Sun Sep 3 14:41:28 2017] dunno, haven't tried it [Sun Sep 3 15:33:24 2017] is there some reason that List.nth and List.nth_default are different? [Sun Sep 3 15:33:34 2017] and which form would be preferred for String.get? [Sun Sep 3 15:33:40 2017] (which I want to call get, not nth, to match ocaml) [Sun Sep 3 15:35:26 2017] also, should get_default or get_error be the default "get"? [Sun Sep 3 15:47:20 2017] and, does coq have a list function for what haskell calls "intersperse" or should that get added? so far I can't find one [Sun Sep 3 16:06:59 2017] also, is there a list t -> list (t * nat) that numbers a list? [Sun Sep 3 16:46:19 2017] I suppose the current String defines get a certain way that I'd better leave alone, though [Mon Sep 4 01:34:05 2017] I have been learning to use `inductive` to define predicates over natural numbers [Mon Sep 4 01:34:22 2017] I would like to be able to express that two such predicates are equivalent using induction [Mon Sep 4 01:34:52 2017] do I need coinductive predicates for this? [Mon Sep 4 01:43:34 2017] e.g. I'm trying to show that N and M are equivalent https://gist.github.com/anonymous/405c00d00d08b155c306ee9bcaba6476 [Mon Sep 4 01:58:32 2017] whenever I try pick through M_le_N or N_le_M using induction I get stuck at some point, and it feels like I'm not able to use the induction hypothesis in the same way I would on paper [Mon Sep 4 02:55:32 2017] cjh`: you probably need a stronger induction scheme that allows you to use the hypothesis for all n that are smaller and not just the one that is exactly 1 less. you can use well-founded induction on n for that. [Mon Sep 4 02:55:48 2017] specifically, import Wf_nat and then use "induction (lt_wf n)" [Mon Sep 4 03:16:30 2017] say I am trying to prove 'M n -> N n' and I have been able to get down to having an 'M n' [Mon Sep 4 03:16:43 2017] my proof is based on the assumption M n, but can't figure out how to apply that as the final step :/ [Mon Sep 4 03:18:07 2017] What exactly is in your context and in your goal? [Mon Sep 4 03:28:17 2017] notnotdan: https://gist.github.com/anonymous/f69e5c630811f0198c55accfcfcaa4ac#file-nat-mat-inductive-equal-two-v-L52 [Mon Sep 4 03:28:27 2017] I'm still quite early on in my learning of coq, and my general proofs are not great [Mon Sep 4 03:28:36 2017] I have been able to prove this by hand on paper, and it matches a proof I was given in class [Mon Sep 4 03:28:59 2017] but I'm trying to learn coq to check my proofs, and I seem to have trouble translating them into coq (which we don't cover in class) [Mon Sep 4 03:29:43 2017] cocreature: I can see how well founded induction would be useful, but on paper it seemed to be possible without it, but if I get stuck I will try that, thanks :) [Mon Sep 4 03:29:57 2017] cjh`: do you have your paper proof somewhere? [Mon Sep 4 03:30:19 2017] cocreature: not one me right now, but I can recreate / find it and share [Mon Sep 4 03:30:32 2017] the format we use in class (computer science) is very informal proof though [Mon Sep 4 03:30:46 2017] it’s easy to accidentally be sloppy when doing paper proofs [Mon Sep 4 03:30:59 2017] yeah, which is why I am trying to learn coq [Mon Sep 4 03:31:09 2017] I'm also uncomfortable with rule induction in general, especially for proofs of equality [Mon Sep 4 03:31:17 2017] so I want something to check me, and coq was recommended [Mon Sep 4 03:31:43 2017] I only think my paper proof is correct as it matched the proof in class, but appeal to authority isn't a great proof technique :p [Mon Sep 4 03:32:26 2017] even if your proof is correct you might accidentally be using well-founded induction [Mon Sep 4 03:33:15 2017] hmmm [Mon Sep 4 03:33:29 2017] I can see that, since there are times I take apart my values by more than one level [Mon Sep 4 03:41:15 2017] It is possible without well-founded induction if you do directlly a Fixpoint, as if you were writing a program that takes a "M n" and returns a "N n" [Mon Sep 4 03:48:57 2017] You could also write your own induction principle and use it, like this http://lpaste.net/358193 [Mon Sep 4 03:57:24 2017] okay I tried to typeset the easy half of the proof in latex and uploaded at http://segfault.net.nz/~chris/nat-mat-induction-proof-half.pdf [Mon Sep 4 03:57:38 2017] wasn't sure how else to share without taking a screenshot of my chicken scratch on paper [Mon Sep 4 03:57:51 2017] I hope that format of proof makes sense :/ [Mon Sep 4 03:59:31 2017] oops, has a mistake, fixing now ..> [Mon Sep 4 04:00:16 2017] fixed, M-2 induction rule was incorrect (had an N instead of M) [Mon Sep 4 04:00:29 2017] I don't want to waste anyone's time with this though, since I am so new it is likely just due to my misunderstanding [Mon Sep 4 04:00:55 2017] I have to run for a bit, thank you all for your time, I hope I didn't waste it. [Mon Sep 4 04:01:06 2017] cjh`: you are not doing induction on "n", you are doing induction on "M n" [Mon Sep 4 04:01:21 2017] cjh`: if you do that in Coq as well your hypotheses should work out as well [Mon Sep 4 04:01:31 2017] oohhhh [Mon Sep 4 04:01:45 2017] Cypi: thanks for that, I was trying Fixpoint initially but I got stuck and thought I was using the wrong tool [Mon Sep 4 04:01:55 2017] cocreature: thank you so much, I will try that after I've found food and report back [Mon Sep 4 04:02:04 2017] if you were doing induction on "n" you would have only two cases. [Mon Sep 4 04:02:10 2017] it felt like I wasn't "tying together" the two M and N in some way [Mon Sep 4 04:02:24 2017] I thought I had to relate them in an inductive sense, and coinduction sounded maybe right [Mon Sep 4 04:02:41 2017] some of my biggest problems have been around relating the informal proofs in class to formal proof techniques [Mon Sep 4 04:02:50 2017] I kept screwing up the inductive hypothesis [Mon Sep 4 04:04:28 2017] being precise can be surprisingly tricky :) [Mon Sep 4 04:04:44 2017] how do I express induction on M n in coq? [Mon Sep 4 04:05:14 2017] my undergraduate cs degree didn't feature this kind of structural / rule inductive proofs, so trying to learn while running [Mon Sep 4 04:05:15 2017] after "intros n H" you’ll have "H : M n". then you can just do "induction H" [Mon Sep 4 04:06:23 2017] omg yes! [Mon Sep 4 04:06:33 2017] there we are, the missing hypothesis \o/ [Mon Sep 4 04:07:28 2017] cocreature: thank you so much [Mon Sep 4 04:07:32 2017] and thank you everyone for your help [Mon Sep 4 04:07:32 2017] yw :) [Mon Sep 4 04:07:42 2017] I had never seen `intros H` [Mon Sep 4 04:07:54 2017] H is just an arbitrary name [Mon Sep 4 04:07:58 2017] 19:16 < cjh`> say I am trying to prove 'M n -> N n' and I have been able to get down to having an 'M n' [Mon Sep 4 04:08:01 2017] 19:16 < cjh`> my proof is based on the assumption M n, but can't figure out how to apply that as the final step :/ [Mon Sep 4 04:08:04 2017] that is roughly what I was trying to get at [Mon Sep 4 04:08:04 2017] okay [Mon Sep 4 04:08:09 2017] so I had learned intros for forall [Mon Sep 4 04:08:19 2017] but I couldn't figure out how to break up `M n -> N n` for example [Mon Sep 4 04:08:33 2017] I wanted to say 'use the assumption of that implication' [Mon Sep 4 04:08:44 2017] "M n -> N n" is basically "forall H : M n -> N n" [Mon Sep 4 04:09:11 2017] hmmm I sadly don't quite follow that [Mon Sep 4 04:09:17 2017] ohh actually [Mon Sep 4 04:09:31 2017] forall H (arbitrary name) of the type (M n -> N n) [Mon Sep 4 04:09:35 2017] I think I follow that [Mon Sep 4 04:09:35 2017] right [Mon Sep 4 04:09:52 2017] cocreature: thank you so much [Mon Sep 4 04:09:56 2017] this has honestly made my day [Mon Sep 4 04:10:09 2017] I will try write up the full coq proof tonight and report back [Mon Sep 4 04:10:13 2017] the feeling when your proof finally goes through can be quite satisfying :) [Mon Sep 4 04:10:29 2017] more generally I'm trying to understand curry-howard, and how proofs and types relate [Mon Sep 4 04:10:37 2017] and I keep hitting these kinds of walls which are due to my lack of understanding [Mon Sep 4 04:10:43 2017] I keep trying to use the wrong tool [Mon Sep 4 04:10:49 2017] have to run, thanks again :D [Mon Sep 4 05:24:26 2017] cocreature: omg it works perfectly, thank you so much [Mon Sep 4 05:24:52 2017] before coming in here I burned a bunch of time trying to use something like 'induction n on M' as I really wanted to say 'induction on M n' but didn't know how to express it [Mon Sep 4 05:28:26 2017] final proof: https://gist.github.com/mkfifo/774b4255278ca1305c9a68f872a48a7d [Mon Sep 4 05:28:31 2017] and now it matches what I was doing by hand EXACTLY [Mon Sep 4 05:28:33 2017] thanks all for your time :D [Mon Sep 4 05:31:06 2017] 1-1 correspondence with my hand proof is so lovely [Mon Sep 4 17:41:21 2017] Question [Mon Sep 4 17:41:46 2017] actually nvm my question would be better suited for ##typetheory [Mon Sep 4 20:44:49 2017] is there some version of [inversion] that doesn't automatically rewrite by the generated equalities [Mon Sep 4 20:54:58 2017] ah, [injection] [Mon Sep 4 20:57:00 2017] [firstorder] is an excellent tactic =D [Mon Sep 4 22:36:55 2017] inversion doesn't, does it? that's why you almost always want inversion foo; subst [Mon Sep 4 22:38:30 2017] er, it does /some/ rewritings [Mon Sep 4 22:38:34 2017] not every single possible one, i guess [Mon Sep 4 23:17:21 2017] Hi Everyone [Mon Sep 4 23:17:24 2017] https://gist.github.com/mukeshtiwari/40ce0915d55bf4b47ac4f56e5d63f845 [Mon Sep 4 23:18:10 2017] I am trying show to existence of function for decidable relation over finite types. [Mon Sep 4 23:19:05 2017] I have gone through https://coq.inria.fr/library/Coq.Logic.ChoiceFacts.html, but I am not able to put the piece of puzzles together. [Mon Sep 4 23:19:52 2017] I am just looking for minimum hint (direction to proceed) [Mon Sep 4 23:23:04 2017] I'm not sure what you're trying to accomplish exactly [Mon Sep 4 23:24:44 2017] and in the absence of any clear idea I'll just make a simple operational suggestion: prove the cases for P and ~P separately before writing that combined proof [Mon Sep 4 23:25:42 2017] dh`: Lets say for two elements, a and b, of type A and a is preferred over b so P a b holds and in this case I want to give low natural number to a and high natural number to b. [Mon Sep 4 23:25:42 2017] and without more context I question whether the ~P case you've formulated is actually true [Mon Sep 4 23:26:36 2017] also try instantiating it on a simple concrete type first, like say bool [Mon Sep 4 23:27:32 2017] Lets take a, b, c and a is preferred over b and b is preferred over c then P a b is true, P a c is true and P b c is true and everything else is false [Mon Sep 4 23:27:51 2017] so in this case f a = 0, f b = 1 and f c = 2 [Mon Sep 4 23:28:31 2017] your second case says "there exists no function into nat where f c < f d" and that's a very strong claim [Mon Sep 4 23:29:06 2017] Lets take directed graph and if node u is connected to node v then P u v holds [Mon Sep 4 23:29:36 2017] so the idea is that P is a total order on A? [Mon Sep 4 23:29:52 2017] let's take a simpler example, like bool, and suppose that false < true [Mon Sep 4 23:30:03 2017] dh`: Yes [Mon Sep 4 23:30:18 2017] so: P false true, ~P false false, ~P true true, and ~P true false [Mon Sep 4 23:30:24 2017] right? [Mon Sep 4 23:30:28 2017] Yes [Mon Sep 4 23:31:30 2017] so the second branch of your goal says: there exists no f: bool -> nat such that f true < f false [Mon Sep 4 23:31:56 2017] which is clearly not the case [Mon Sep 4 23:33:50 2017] which is I think because you've placed the exists somewhere other than where you wanted it [Mon Sep 4 23:34:47 2017] dh`: {(exists f : A -> nat, forall c d : A, P c d <-> (f c < f d)%nat)} + [Mon Sep 4 23:34:47 2017] {(exists f : A -> nat, forall c d : A, ~P c d <-> (f c >= f d)%nat)} [Mon Sep 4 23:35:59 2017] ok, I think I see what you're chasing after [Mon Sep 4 23:36:07 2017] so, since you said you wanted a hint, here's a hint: [Mon Sep 4 23:36:14 2017] how many functions do you want to show the existence of? [Mon Sep 4 23:36:55 2017] dh`: I think one would be great [Mon Sep 4 23:37:19 2017] right [Mon Sep 4 23:37:20 2017] so [Mon Sep 4 23:37:27 2017] how many do you get with the form you just pasted? [Mon Sep 4 23:38:48 2017] dh`: I am not able to prove the lemma so none [Mon Sep 4 23:41:05 2017] dh`: or you mean something else. Sorry I did not get you about "ow many do you get with the form you just pasted?" [Mon Sep 4 23:46:11 2017] dh`: Sorry, my browser crashed. [Mon Sep 4 23:50:14 2017] how many different functions are you trying to prove the existence of? [Mon Sep 4 23:50:55 2017] and how many are you going to get if you prove the lemma with the form you pasted a few minutes back? [Mon Sep 4 23:51:33 2017] {} + {} gives you two mutually exclusive cases [Mon Sep 4 23:51:48 2017] if you put an exists in each one, then... how many functions exist? [Mon Sep 4 23:52:45 2017] My initial thought was when P c d holds then go for left {(exists f : A -> nat, forall c d : A, P c d <-> (f c < f d)%nat)} and give one evidence of existence. [Mon Sep 4 23:53:01 2017] and when ~ P c d then go right [Mon Sep 4 23:53:10 2017] yes, that's what you've written [Mon Sep 4 23:53:24 2017] but that gives you a different exists each time, and thus a different function for each case [Mon Sep 4 23:53:34 2017] so there's potentially two different functions (though not at the same time) [Mon Sep 4 23:53:37 2017] and I don't think that's what you want [Mon Sep 4 23:55:14 2017] dh`: Yeah, Now I understand your point and probably confused also. [Mon Sep 4 23:55:47 2017] also I'm not sure you want a {} + {} in the goal at all [Mon Sep 4 23:56:41 2017] that's an either-or [Mon Sep 4 23:57:43 2017] skipping over the exists question, what you've got says EITHER p is equivalent to <, OR ~P is equivalent to >=, BUT not both at once [Mon Sep 4 23:58:20 2017] dh`: Yes [Tue Sep 5 00:00:29 2017] When P c d holds then c is ranked higher (low in number) than d ~ P c d is c is ranked equally or lower than d. [Tue Sep 5 00:02:35 2017] right, so you've said [Tue Sep 5 00:02:49 2017] P c d <-> f c < f d [Tue Sep 5 00:02:55 2017] ~P c d <-> f c >= f d [Tue Sep 5 00:03:06 2017] but what's the connective you want between them? [Tue Sep 5 00:05:59 2017] are they both always true together, both true sometimes but other times only one, or can only one be true at a time? [Tue Sep 5 00:06:40 2017] (or something else?) [Tue Sep 5 00:08:06 2017] dh`: No, both are not true together. Only one at a time either P c d or ~ P c d [Tue Sep 5 00:08:55 2017] Seems like my assumption is wrong (if I understood you correctly) forall c d, P c d \/ ~ P c d. [Tue Sep 5 00:12:33 2017] my question wasn't about P or ~P, it was about the equivalences. [Tue Sep 5 00:12:52 2017] P c d <-> f c < f d and ~P c d <-> f c >= f d [Tue Sep 5 00:17:29 2017] Only one at a time. [Tue Sep 5 00:18:59 2017] dh`: Let me think more clearly and will be back with more clear question. [Tue Sep 5 00:19:08 2017] Thank you very much [Tue Sep 5 00:34:25 2017] is this what its like to come face to face with one of the elder gods https://i.imgur.com/2WQFRRF.png [Tue Sep 5 02:52:20 2017] benzrf: oh wow... [Tue Sep 5 19:00:31 2017] in coq do all constant functions out of a sigma type factor thru the corresponding existential [Tue Sep 5 19:12:17 2017] This could be of interest to you https://homotopytypetheory.org/2015/06/11/not-every-weakly-constant-function-is-conditionally-constant/ [Wed Sep 6 18:08:36 2017] ty Cypi [Thu Sep 7 03:07:23 2017] hi… i have a problem with classes: https://gist.github.com/esoeylemez/9abba3e9a583ce8a89ed8938307a5a97 [Thu Sep 7 03:08:11 2017] it this point the goal should be (0 ≡ 0), but it's (0 ≡ id Z (eqm n) Z.add) instead… for some reason it doesn't take my Monoid instance into account, and all my attempts to rewrite it to 0 have failed [Thu Sep 7 03:08:19 2017] s/^it/at/ [Thu Sep 7 03:08:39 2017] any ideas? [Thu Sep 7 03:09:38 2017] note: coq doesn't want me to prove that the instance exists… apparently that particular class member is already satisfied [Thu Sep 7 03:10:22 2017] it's only asking for left_inv and right_inv [Thu Sep 7 03:22:24 2017] ertes-w: when you end your "plus_mod_monoid" definition with "Qed.", it makes everything inside opaque [Thu Sep 7 03:23:16 2017] so you should just replace your "Qed." with "Defined." [Thu Sep 7 03:23:30 2017] and that's it, "id Z (eqm n) Z.add" will then compute to 0 [Thu Sep 7 03:25:49 2017] Cypi: thanks… do i still need to reduce it explicitly? because so far it's still (id Z (eqm n) Z.add) [Thu Sep 7 03:26:00 2017] yeah, indeed [Thu Sep 7 03:26:03 2017] 'simpl' reduced it [Thu Sep 7 03:26:21 2017] you can also use "reflexivity" directly [Thu Sep 7 03:31:17 2017] Cypi: lovely… thanks a lot! [Thu Sep 7 03:31:33 2017] i always thought that Qed and Defined are synonymous [Thu Sep 7 03:32:30 2017] That's the only difference: whether the definition will be opaque or transparent. [Thu Sep 7 03:32:54 2017] Cypi: so basically it makes a difference for structures only? [Thu Sep 7 03:35:49 2017] now that the problem is solved, are there any ways to improve this code? still new to coq [Thu Sep 7 03:36:27 2017] Not only for structures, for any definitions [Thu Sep 7 03:37:19 2017] Your code looks fine to me. Only easy thing I would change: when you are proving different subgoals, use bullets to differentiate them. (It's a stylistic choice, but I find it makes proofs easier to read) [Thu Sep 7 03:38:18 2017] bullets? what's the syntax for them? [Thu Sep 7 03:38:43 2017] For instance in "plus_mod_monoid", you could have writtent the following: [Thu Sep 7 03:38:45 2017] - reflexivity. [Thu Sep 7 03:38:50 2017] ah [Thu Sep 7 03:38:54 2017] - intros. replace (x + 0) with ..... [Thu Sep 7 03:39:09 2017] you can use any symbol in -, +, *, --, ++, **, etc. [Thu Sep 7 03:39:11 2017] i see, yeah [Thu Sep 7 03:41:38 2017] is there a way to eliminate the redundancy in '- a. b. c. - a. b. c.'? [Thu Sep 7 03:42:32 2017] So, you could chain it with the previous tactic (if any). Or you could write something like "all: a; b; c." [Thu Sep 7 03:42:48 2017] (the ; chains several tactics) [Thu Sep 7 03:42:57 2017] (and "all:" is a goal selector) [Thu Sep 7 03:45:42 2017] now i have a case where i do this: - all: a. * b1. c. * b2. c. [Thu Sep 7 03:46:24 2017] is there a modifier 'f' such that i can do the following? all: a. b1. f: b2. all: c. [Thu Sep 7 03:48:41 2017] either "all: a; [b1 | b2]; c", or "all: a. b1. 2: b2. all: c." [Thu Sep 7 03:50:43 2017] great, now my proof for plus_mod_group looks like this: all: intros. 1: replace (-x + x) with 0 by ring. 2: replace (x + -x) with 0 by ring. all: reflexivity. [Thu Sep 7 03:50:58 2017] i know that the "1:" is redundant, but written vertically it just looks very nice [Thu Sep 7 03:51:33 2017] thanks a lot for your support! i'll be using coq to teach group theory in a cryptography workshop =) [Thu Sep 7 03:59:54 2017] Just another personal advice (also, I am by no mean an expert in writing Coq proofs), I wouldn't mind not trying to factorize everything as most as possible; readability should really be a priority in my opinion [Thu Sep 7 04:00:36 2017] So if your proof looks like "- intros. replace (-x + x) with 0 by ring. reflexivity. - intros. replace (x + -x) with 0 by ring. reflexivity.", it's very ok to me [Thu Sep 7 04:04:56 2017] Cypi: yes, that's what i'll be doing in the workshop anyway [Thu Sep 7 04:05:03 2017] i was just curious [Thu Sep 7 10:57:42 2017] in my paste from earlier, the resulting type of 'id' is: ∀ (A : Type) (eq : A → A → Prop) (dot : A → A → A), Monoid A eq dot → A [Thu Sep 7 10:57:57 2017] how do i make the first three arguments implicit? [Thu Sep 7 10:58:08 2017] without giving up the Section/Variable trick that is [Thu Sep 7 10:59:09 2017] ah, i figured it out: Context [Thu Sep 7 11:01:32 2017] err, no, that didn't quite work [Thu Sep 7 11:01:51 2017] now they are also implicit on the class itself, which is unfortunate [Thu Sep 7 11:10:20 2017] so the question is: how can i introduce a Context variable that is explicit on classes, but implicit on class members? [Thu Sep 7 11:37:02 2017] ah, now i finally get what the backtick means =) [Thu Sep 7 20:49:49 2017] is it possible in a Section to locally generalize a definition [Thu Sep 7 20:50:22 2017] that is, is it possible to say "this expression, but with a Variable discharged" [Thu Sep 7 20:56:25 2017] You can always write it explicitely (with a lambda or something), but I don't think there is anything more direct [Fri Sep 8 07:20:12 2017] my question from yesterday still stands, if anyone knows the answer: how can i introduce a Context variable that is explicit on classes, but implicit on class members? [Fri Sep 8 07:22:32 2017] example: Context {A : Type}. … Class Monoid := { …; id : A; … } [Fri Sep 8 07:22:40 2017] i would like A to be explicit on Monoid, but implicit on 'id' [Fri Sep 8 08:22:33 2017] i'm using 'Arguments' now to declare it explicitly [Fri Sep 8 08:24:13 2017] is there a way to use symbolic names and infix notation more naturally? right now i always have to introduce a regular prefix name first and then declare an infix notation for it using Notation/Infix… that's cumbersome [Fri Sep 8 08:25:02 2017] what i would like is to use something like Reserved Infix, and then just use that symbol directly as a variable name [Mon Sep 11 07:42:40 2017] I am looking for a reference of the proof term language [Mon Sep 11 07:43:50 2017] https://coq.inria.fr/distrib/current/refman/Reference-Manual003.html#term [Mon Sep 11 17:17:26 2017] i feel like ive read about function extensionality holding in cic in certain limited cases, like maybe when the domain has decidable equality or something—is there a thing like that, or am i just confusing myself? [Mon Sep 11 17:26:08 2017] benzrf: you can prove fun ext for functions out of finite domain if you have an explicit enumeration of the elements of the domain [Mon Sep 11 17:28:05 2017] this is used a lot in mathcomp (for instance a matrix is defined as a function from a finite set of indices, so you directly get that two matrices are equal if they are pointwise equal) [Mon Sep 11 18:16:10 2017] oh that's useful :D [Mon Sep 11 18:16:12 2017] mortberg: how do you prove that? [Mon Sep 11 18:16:25 2017] mortberg: don't you have to represent it as a vector though, instead of an actual function type? [Mon Sep 11 18:24:10 2017] ah right, my bad. Saizan_ is right, you represent the functions by their graph [Mon Sep 11 18:24:16 2017] aww wait what [Mon Sep 11 18:24:18 2017] lame D: [Mon Sep 11 18:25:06 2017] well, it's useful in practice. so it's not that lame, but having proper fun ext around is of course better [Mon Sep 11 18:25:28 2017] so i cant prove this then? [forall A (f : unit -> A), f = fun u => match u with tt => f tt end] [Mon Sep 11 18:27:18 2017] benzrf: Imagine that every function, in addition to the ordinary stuff, has a colour, which is information that is lost when the function is applied. [Mon Sep 11 18:27:59 2017] Cale: this is a model of mltt which invalidates that formula? [Mon Sep 11 18:28:12 2017] Yeah [Mon Sep 11 18:28:20 2017] heuh [Mon Sep 11 18:28:55 2017] ok, but you could just as easily make that claim for something like cubical tt, and it wouldnt necessarily be immediately obvious that it isnt a model [Mon Sep 11 18:29:09 2017] if this was an open question, i could say "but how do you know that this is a valid model for mltt" [Mon Sep 11 18:29:17 2017] which i guess is what my real question is! [Mon Sep 11 18:29:30 2017] look at this paper: https://www.pédrot.fr/articles/cpp2017.pdf [Mon Sep 11 18:30:38 2017] oh, neat [Mon Sep 11 18:30:53 2017] heh, a domain with an é [Tue Sep 12 15:52:19 2017] is there a "fold /\" function in the stdlib? (list Prop -> Prop) [Tue Sep 12 17:13:38 2017] like this? [Tue Sep 12 17:13:40 2017] Require Import List. [Tue Sep 12 17:13:40 2017] Import ListNotations. [Tue Sep 12 17:13:40 2017] Definition xs := fold_right and True [1 = 1; 2 = 2; 3 = 3]. [Tue Sep 12 17:13:40 2017] Goal xs. [Tue Sep 12 17:13:40 2017] Proof. [Tue Sep 12 17:13:41 2017] repeat split. [Tue Sep 12 17:13:43 2017] Qed. [Tue Sep 12 17:14:58 2017] Check fold_right and True : list Prop -> Prop. [Tue Sep 12 17:17:40 2017] hmm.. actually probably better use [Tue Sep 12 17:17:41 2017] Check Forall id : list Prop -> Prop. [Tue Sep 12 17:18:34 2017] although.. not sure which one is better, at the moment. [Tue Sep 12 17:27:00 2017] forall l : list Prop, Forall id l <-> fold_right and True l [Tue Sep 12 17:27:00 2017] is easy to prove anyways [Tue Sep 12 17:28:09 2017] staffehn, I ended up doing exactly that [Tue Sep 12 17:28:16 2017] I was just wondering whether an alias for that exitsed already [Tue Sep 12 17:28:50 2017] I combined it with a map for convenience. [Tue Sep 12 17:28:51 2017] Definition all_of {A: Type} l (f:A->_) := fold_left and (map f l) True. [Tue Sep 12 17:29:26 2017] eg. all_of [1; 2; 3] (fun n => n < 2) [Tue Sep 12 17:29:30 2017] that looks a lot like Forall though.. [Tue Sep 12 17:30:02 2017] Forall (fun n => n < 2) [1;2;3]. [Tue Sep 12 17:30:09 2017] you're right [Tue Sep 12 17:30:35 2017] I was a bit slow to parse. [Wed Sep 13 04:04:15 2017] how can I have a unicode character as an identifier? [Wed Sep 13 04:05:11 2017] I see the Notation declaration but this seems to be to define notations which can be desugared [Wed Sep 13 04:05:21 2017] Just enter it as an identifier in the text? [Wed Sep 13 04:06:03 2017] the compiler tells me "Syntax Error: Lexer: Undefined token" [Wed Sep 13 04:08:05 2017] Can you upload the full source file you are trying to compile? [Wed Sep 13 04:08:25 2017] what I would like is (→ : A -> A -> Prop) and then given x : A and y : A that I may write x → y [Wed Sep 13 04:08:41 2017] OK, for that you do need to have notations, most likely. [Wed Sep 13 04:08:55 2017] Because you want to have an infix notation, essentially [Wed Sep 13 04:10:26 2017] See for instance how it is defined here: https://gitlab.mpi-sws.org/robbertkrebbers/coq-stdpp/blob/master/theories/base.v#L355 [Wed Sep 13 04:12:45 2017] just trying to compile line 355 the compiler says Syntax Error: Lexer: Undefined token and in CoqIde it highlights → at col 28 [Wed Sep 13 04:13:56 2017] I am guessing it has some other Notation declaration somewhere [Wed Sep 13 04:14:28 2017] ah I bet it is using https://coq.inria.fr/library/Coq.Unicode.Utf8_core.html [Wed Sep 13 04:15:09 2017] Hm, wierd [Wed Sep 13 04:15:17 2017] I thought it should "just work". [Wed Sep 13 04:15:22 2017] What is your coqc version? [Wed Sep 13 04:15:38 2017] I just changed → for -> and λ for forall [Wed Sep 13 04:16:09 2017] it seems these just define section notations for → as an alias of -> [Wed Sep 13 04:16:16 2017] this is not what I want… I want → to be an identifier [Wed Sep 13 04:16:21 2017] a variable name [Wed Sep 13 04:17:27 2017] I want to have → be an arbitrary relation [Wed Sep 13 04:17:51 2017] in P(A*A) [Wed Sep 13 04:20:30 2017] the reference is a bit vague on which unicode characters are allowed in an identifier [Wed Sep 13 04:22:27 2017] and I guess that is just not one of the allowed ones… darn [Wed Sep 13 04:29:48 2017] I could, I dunno, rewrite x → y to R x y but I am not sure how to make a Notation declaration for this [Wed Sep 13 04:30:04 2017] because it complains R is not defined… not sure if I can refer to an R in context… [Wed Sep 13 04:31:39 2017] So what should be the meaning of (A \to B)? [Wed Sep 13 04:32:10 2017] is that a question for me? I do not understand it [Wed Sep 13 04:33:05 2017] Well, you want to define an identifier/unicode notation for something, right? [Wed Sep 13 04:33:27 2017] I don't exactly understand what do you want the meaning \to to be [Wed Sep 13 04:33:45 2017] Like, should (A \to B) be equal to (A -> B -> Prop) or to some element of that type? [Wed Sep 13 04:34:15 2017] as I said, I merely want it to be a variable name [Wed Sep 13 04:34:57 2017] seeing as that is not possible, maybe I can rewrite it to a fixed legal variable name, but I am not sure how to refer to the context in which x → y appears [Wed Sep 13 04:35:07 2017] OK, sorry, I misunderstood you then. [Wed Sep 13 04:35:11 2017] I am seeing ".." in notations and so maybe this is a way [Wed Sep 13 04:36:06 2017] something like this, but it does not compile yet http://lpaste.net/358397 [Wed Sep 13 04:37:17 2017] error occurs on the last .. [Wed Sep 13 04:38:52 2017] hm, I don't think .. is what I want it to be, at all [Wed Sep 13 04:39:25 2017] I wanted it to be "arbitrary expression" [Wed Sep 13 04:39:43 2017] In that case you might want to use typeclasses? Like this: https://gist.github.com/co-dan/0102e8608a05ed9f2d663c7cff139489 [Wed Sep 13 04:39:47 2017] not sure if that's the best solution tbh [Wed Sep 13 04:48:17 2017] maybe I'll try a section… I don't know what a section is yet [Wed Sep 13 04:51:46 2017] I have no idea what I am doing but this is working so far http://lpaste.net/358398 [Wed Sep 13 04:53:03 2017] having Variable A and Variable R seems really helpful to shorten my other definitions [Wed Sep 13 05:14:22 2017] how do I simplify notation in a proof? I know to use unfold to substitute for the definition [Wed Sep 13 05:16:28 2017] I am stuck with x ⇒ y which is just sugar for x -> y and intros is not seeing that [Wed Sep 13 05:17:23 2017] unfold ⇒. is a syntax error, simpl does nothing, compute does nothign [Wed Sep 13 05:21:40 2017] hm I think the precedence is wrong… I thought higher levels would bind tighter [Wed Sep 13 05:56:01 2017] if I have two hypotheses, how do I use them together in some way and add the result as a new hypothesis? [Wed Sep 13 05:57:08 2017] If you have "H1 : A ; H2 : A -> B", you can do "pose proof (H2 H1)." for instance [Wed Sep 13 05:57:30 2017] I have two hypotheses which can be arguments to a constructor [Wed Sep 13 05:57:38 2017] (pose proof accepts any well-typed term, and adds a new hypothesis with its type) [Wed Sep 13 05:57:48 2017] pose proof (C H1 H2) [Wed Sep 13 05:58:20 2017] normally I'd use the constructor tactic but it only works when it gives the consequent [Wed Sep 13 05:59:02 2017] okay, thanks [Wed Sep 13 06:08:52 2017] how would I find the constructors for "and"? [Wed Sep 13 06:09:19 2017] You can "Print and." to see the inductive definition [Wed Sep 13 06:09:38 2017] thanks! [Wed Sep 13 06:26:40 2017] here is a proof I have done… are there ways I can shorten or otherwise improve it? http://lpaste.net/358400 I am just getting to grips with the tactics [Wed Sep 13 06:30:59 2017] I fixed my levels for ⇒ and ∧ … lower levels bind tighter, okay [Wed Sep 13 07:37:25 2017] is there a shorter version of elim H. intros. ? [Wed Sep 13 07:37:38 2017] for ∧ [Wed Sep 13 08:23:45 2017] what is this error here? I do not understand it http://lpaste.net/358404 [Wed Sep 13 08:24:07 2017] if I use and (x →* y) (is_norm y) instead then it works fine [Wed Sep 13 08:24:22 2017] /\ for ∧ also fails [Wed Sep 13 08:30:31 2017] ah I think it may be because I have some overlapping notations [Wed Sep 13 08:31:46 2017] I have x → y as a notation and I also want x → y → z as a notation [Wed Sep 13 08:31:53 2017] not sure that is possible… seems to be screwing up [Wed Sep 13 08:50:48 2017] https://softwarefoundations.cis.upenn.edu/lf-current/Basics.html#lab16 [Wed Sep 13 08:50:55 2017] search for 'notations' [Wed Sep 13 08:51:09 2017] there they talk about associativity [Wed Sep 13 08:51:32 2017] is associativity relevant here? I thought it could be the ambiguity [Wed Sep 13 08:57:15 2017] bah I don't know… I'll use the noiser notation then [Wed Sep 13 09:03:40 2017] well if you write x → y → z as x → (y → z) or (x → y) → z then you only need one natation [Wed Sep 13 09:03:57 2017] no because they mean different things [Wed Sep 13 09:04:14 2017] it is like x < y and x < y < z [Wed Sep 13 09:04:26 2017] x < y < z means x < y ∧ y < z [Wed Sep 13 09:09:00 2017] is there a hotkey for "go to cursor"? [Wed Sep 13 09:10:29 2017] Ctrl+Right (in coqide) [Wed Sep 13 09:10:45 2017] awesome, thanks [Wed Sep 13 12:15:43 2017] I have c : forall x y, s x y -> t x y and would like to make x, y implicit [Wed Sep 13 12:15:59 2017] I tried c : forall {x y}, s x y -> t x y but this did not change anything, seemingly [Wed Sep 13 12:38:40 2017] would shorten a lot of code, hrm [Wed Sep 13 13:15:10 2017] I can make a Definition which wraps the constructor and has the implicit parameters [Wed Sep 13 13:15:23 2017] kind of clunky, but if that is what I have to do… are implicits only for Definitions? [Wed Sep 13 17:41:34 2017] huh, I think to prove a symmetric and transitive relation is reflexive, I need LEM [Wed Sep 13 17:45:07 2017] Isn't it false? [Wed Sep 13 17:45:22 2017] The empty relation is symmetric and transitive, but not reflexive, for instance. [Wed Sep 13 17:45:27 2017] I dunno, seems right, but I am tired enough to not see counter examples [Wed Sep 13 17:45:57 2017] yes, derp, I keep getting the wrong idea of reflexive in my mind [Wed Sep 13 17:46:34 2017] I end up thinking reflexivity means if xRy then xRx and yRy [Wed Sep 13 17:47:11 2017] Then it would be true, and you wouldn't need LEM :p [Wed Sep 13 17:48:00 2017] yes… so I was thinking this wrong way and then trying to prove it using the correct definition of reflexivity [Wed Sep 13 17:49:42 2017] another thing I might be stupid on… I think the symmetric closure of the transitive closure is a subset of the transitive closure of the symmetric closure [Wed Sep 13 17:50:03 2017] but the proof is going nowhere fast… not seeing obvious counter examples [Wed Sep 13 17:52:25 2017] Consider a set {x, y}, and your relation is {(x, y)} and that's it (so you have xRy and nothing else). The symmetric closure of the transitive closure is {(x, y), (y, x)}, while the transitive closure of the symmetric closure is {(x, x), (x, y), (y, x), (y, y)} [Wed Sep 13 17:52:39 2017] Ah wait, you said a subset, that's not a counter-example :D [Wed Sep 13 17:53:17 2017] and you'll notice why I keep getting the wrong idea of reflexivity in my head… because the difference seems to be reflexive pairs [Wed Sep 13 17:54:14 2017] I think you're right (about the symmetric closure etc.) [Wed Sep 13 18:01:56 2017] proved it, yay [Wed Sep 13 18:02:40 2017] realised a lemma that the transitive closure is a subset of the transitive closure of the symmetric closure [Wed Sep 13 18:17:38 2017] generalised to transitive closure preserves subset [Thu Sep 14 00:44:19 2017] How do I make my type ordered in coq? I'm looking at this answer https://stackoverflow.com/questions/44793027/example-uses-of-msets-in-coq for constructing a set and I think i need to write a corresponding module. [Thu Sep 14 00:44:32 2017] Not sure where to find an example of such a module and what functions it requires though [Thu Sep 14 01:21:44 2017] Orders, and there are some examples in OrdersEx [Thu Sep 14 01:22:21 2017] the examples aren't amazingly comprehensible because they're kind of overgeneralized for that (like much of the library) [Thu Sep 14 06:37:30 2017] An example for the natural numbers is here: https://coq.inria.fr/distrib/current/stdlib/Coq.Structures.OrderedTypeEx.html#Nat_as_OT [Thu Sep 14 11:27:50 2017] anton-trunov: thanks. [Thu Sep 14 11:31:33 2017] do i have to write boilerplate myself btw? [Thu Sep 14 11:31:42 2017] E.g. the lt function [Thu Sep 14 12:58:03 2017] hi. [Thu Sep 14 12:58:13 2017] hm. anyone here? [Thu Sep 14 12:58:32 2017] I am interested in compiling coq natively. [Thu Sep 14 12:59:33 2017] or more specifically, some OPAM packages for coq allow direct compilation I think. on the one hand: how is I/O handled? on the other hand: how can this be done? (I am still using extraction for most of my stuff) [Thu Sep 14 13:01:50 2017] What do you mean by compiling coq natively? [Thu Sep 14 13:02:11 2017] Most of the work one does in Coq tends not to be running things in Coq itself after all. [Thu Sep 14 13:05:07 2017] indeed [Thu Sep 14 13:05:11 2017] that is why I am wondering [Thu Sep 14 13:05:59 2017] ok. well, another question: how hard is it to write an own program extraction mechanism for coq? [Thu Sep 14 13:10:37 2017] I found https://github.com/pirapira/coq2rust/blob/rust/plugins/extraction/rust.ml [Thu Sep 14 13:11:14 2017] is there a central file where "proofs", that is, the structure of proofs themselves, are specified? [Thu Sep 14 13:14:02 2017] Writing extraction mechanisms is relatively straightforward from what I understand, but I've never written one. [Thu Sep 14 13:14:15 2017] I don't understand what you are asking about central files of proofs. [Thu Sep 14 13:15:14 2017] pmetzger: to write an extraction mechanism, I assume one has to get a proof object, and then generates program code. this proof object must have a structure that is defined somewhere in the coq source code. [Thu Sep 14 13:16:02 2017] I'd suggest reading one of the papers on extraction. They're old but they describe the mechanism. [Thu Sep 14 13:16:37 2017] Remember that you don't extract things that have type Prop. [Thu Sep 14 13:17:04 2017] When you extract something to OCaml, you're only extracting the stuff we generically think of as a program, not the proofs associated with it. [Thu Sep 14 13:24:16 2017] I know [Thu Sep 14 13:24:20 2017] hm. [Thu Sep 14 13:24:25 2017] pmetzger: can you suggest some paper? [Thu Sep 14 13:25:04 2017] I would only be googling for it just as you would. I last read the background on this years ago. [Thu Sep 14 13:31:47 2017] googling for "coq extraction paper" brings up immediate hits btw. [Thu Sep 14 13:34:20 2017] ok [Thu Sep 14 13:34:25 2017] yes [Thu Sep 14 13:34:34 2017] I currently read https://hal.archives-ouvertes.fr/hal-00150914/document [Thu Sep 14 13:36:03 2017] but this doesn't really help [Thu Sep 14 13:38:24 2017] I presume you've tried reading the Coq sources for a similar extraction already? [Thu Sep 14 13:42:50 2017] yes, I tried, but it is … rather complicated. [Thu Sep 14 13:43:01 2017] there is Pp [Thu Sep 14 13:43:04 2017] which does … something [Thu Sep 14 13:43:20 2017] but Pp is not really a name I understand. [Thu Sep 14 13:46:10 2017] If you don't feel comfortable reading an existing extraction, you might not be sufficiently versed to write a new one. [Thu Sep 14 14:00:00 2017] indeed [Thu Sep 14 14:00:16 2017] the point is: I want to *get* sufficiently versed ;) [Thu Sep 14 15:52:15 2017] I have a goal of the form "if somefun x then expr1 else expr2". I destruct'ed (somefun x), expecting each of the to-be-generated subgoals to have as a hypothesis somefun x = true and somefun x = false. but I just saw the goal having changed to expr1 with no additional hypothesis added. Any idea how to deal with this? [Thu Sep 14 15:52:52 2017] Use "destruct (somefun x) eqn:H" (where H is some name) [Thu Sep 14 15:53:08 2017] it will generate the equation you want [Thu Sep 14 15:53:48 2017] Cypi: thank you! you helped me again ... [Thu Sep 14 15:56:52 2017] oops, i was confused with another person whose name starts with C and is of 4 letters, never mind [Thu Sep 14 15:58:03 2017] ooh, didn't know you can do that, always figured you hand to "remember (somefun x) as foo; destruct foo" [Thu Sep 14 15:58:19 2017] also often "symmetry in Heqfoo" too [Thu Sep 14 15:58:40 2017] since remember ~always produces the equation backwards from what one ultimately wants. [Thu Sep 14 16:08:40 2017] http://coq-club.inria.narkive.com/kH5buUqe/a-tutorial-about-writing-coq-plugins does anyone know what has become of this tutorial? both links are dead now. [Sat Sep 16 06:34:43 2017] How can I prove with induction a proposition on positive numbers, which is of the form (forall n, 1<=n -> ...)? when I used `induction n`, I noticed a generated subgoal had as a hypothesis 1 <= S n, instead of 1 <= n [Sat Sep 16 06:37:13 2017] But the induction hypothesis requires the proof of 1 <= n and it's impossible to prove it from 1 <= S n [Sat Sep 16 06:37:49 2017] how is <= defined? [Sat Sep 16 06:39:53 2017] n is of type nat so it is defined in Coq.Init.Peano [Sat Sep 16 06:41:47 2017] numee, try intros. induction le. [Sat Sep 16 06:42:40 2017] wait, how is that true? [Sat Sep 16 06:42:51 2017] 1<=0 doesn't seem true to me [Sat Sep 16 06:43:36 2017] oh sorry, misread [Sat Sep 16 06:44:06 2017] numee, or since intros will put 1<=n as a hypothesis, I think it is induction H. or whatever the hypothesis is named [Sat Sep 16 06:45:34 2017] point being, you want to use induction on <= [Sat Sep 16 06:46:11 2017] erisco: thanks, i'll try that [Sat Sep 16 06:46:43 2017] and <= is notation for le… I am not sure how to determine this without looking up docs… would be happy to know [Sat Sep 16 06:57:57 2017] Locate "<=". [Sat Sep 16 06:59:16 2017] ooh... with induction H I managed to prove it. thank you again. [Sat Sep 16 07:00:06 2017] they might have called the language "Induction H" instead [Sat Sep 16 07:06:39 2017] rrika, thanks! [Sat Sep 16 10:24:04 2017] can I have notation overloaded based on types? [Sat Sep 16 10:24:31 2017] for example, is there some way to overload = for different equalities? [Sat Sep 16 10:39:24 2017] erisco, does this help? https://coq.inria.fr/refman/Reference-Manual022.html [Sat Sep 16 10:39:45 2017] probably, thanks [Sat Sep 16 12:00:30 2017] when I am trying to prove something like ∃x, p ⇒ x what is a tactic I can use to have p as a hypothesis to prove x? [Sat Sep 16 12:09:52 2017] ah ha, eexists! [Sat Sep 16 16:14:36 2017] saying the nonempty set contains an element seems to require LEM, interesting [Sat Sep 16 16:15:12 2017] define "nonempty set" [Sat Sep 16 16:15:27 2017] yes that is unclear [Sat Sep 16 16:15:44 2017] ¬(s = ∅) ⇒ ∃ x, x ∈ s [Sat Sep 16 16:15:53 2017] any set that is not the empty set? ;-) [Sat Sep 16 16:16:06 2017] yes, that is the version I am using here [Sat Sep 16 16:20:33 2017] well sure, this is just double negation elimination basically [Sat Sep 16 16:20:52 2017] think constructively [Sat Sep 16 16:21:08 2017] there is a double negation elimination and then LEM [Sat Sep 16 16:21:40 2017] if i agree to give you anything you like in return for a proof that this set is empty, you have no way of leveraging that to produce an element of the set [Sat Sep 16 16:21:58 2017] not unless you know something else about the set, which you don't if it's universally quantified [Sat Sep 16 16:22:13 2017] it is just interesting [Sat Sep 16 17:34:36 2017] Is it possible to prove that if f : A -> B is injective, that it has a left inverse in Coq? Typically the proof of this would just be constructing a function g where if f(x) = y, then g(y) = x, but I'm not really sure how to do that in general in Coq. [Sat Sep 16 17:38:55 2017] You can't. f : False -> unit is injective, but you can't build (hopefully) g : unit -> False [Sat Sep 16 17:40:36 2017] Cypi: what about f : A -> A? I.e., can it be proven if the domain and codomain are the same? [Sat Sep 16 17:41:27 2017] That's a good point, though. [Sat Sep 16 17:41:49 2017] and a good question, I need to think about it but I can't right now, I'll come back to it x) [Sat Sep 16 17:41:54 2017] (someone else might, though) [Sat Sep 16 17:46:19 2017] Thanks :). I suppose another question is if you keep f : A -> B, but then assert that there exists some a : A and b : B... [Sat Sep 16 17:47:39 2017] Which actually is helpful for a potential proof, because B might be "bigger" than A, meaning you can then have g : B -> A default to a. [Sat Sep 16 20:56:14 2017] Chobbes: an injective function is a monomorphism, so you can prove: ∀ f g h, injective f → (∀ x, g (f x) = h (f x)) -> ∀ x, g x = h x [Sat Sep 16 20:58:45 2017] it's not quite "has an inverse", but you can still reason about compositions with injections [Sat Sep 16 21:00:13 2017] similarly surjective functions are epimorphisms: ∀ f g h, surjective f → (∀ x, f (g x) = f (h x)) → ∀ x, g x = h x [Sat Sep 16 21:19:57 2017] hrm [Sat Sep 16 21:20:16 2017] it's straightforward to prove that if a list is not the empty list, there exists an element that's in it [Sat Sep 16 21:20:19 2017] why are sets different? [Sat Sep 16 21:21:02 2017] dh`: how do you express "non-empty set"? [Sat Sep 16 21:21:16 2017] s <> emptyset? [Sat Sep 16 21:21:27 2017] surely the empty set is allowed to be a thing [Sat Sep 16 21:21:38 2017] dh`: we're in the context of coq, right? so by "set" you really mean "type"? [Sat Sep 16 21:21:48 2017] are we? [Sat Sep 16 21:21:56 2017] I was replying to something in the scroll, that wasn't clear [Sat Sep 16 21:22:06 2017] ah, i see [Sat Sep 16 21:23:11 2017] the proposition in the scroll contains utf-8 that got mangled, but it seems to be writing s <> emptyset [Sat Sep 16 21:25:23 2017] again, are we talking about sets or types? [Sat Sep 16 21:25:55 2017] because the way you express "non-emptiness" for types is very different [Sat Sep 16 21:27:13 2017] right, you do it by saying there exists an x [Sat Sep 16 21:27:41 2017] in fact i would do the same for sets [Sat Sep 16 21:27:49 2017] and then the proposition about an element existing would be tautological [Sat Sep 16 21:28:19 2017] but this was probably about datatype sets or somebody's set theory development [Sat Sep 16 21:29:19 2017] if you assume LEM, then basically whenever you get a non-empty set you can pick an element from it [Sat Sep 16 21:29:44 2017] at least in ZF, and that's because LEM is actually equivalent to the axiom of choice [Sat Sep 16 21:30:18 2017] in constructive mathematics and type theory in particular you generally don't assume LEM [Sat Sep 16 21:30:35 2017] right [Sat Sep 16 21:30:49 2017] except I didn't realize it ended up being equivalent to the axiom of choice [Sat Sep 16 21:31:38 2017] in even simpler terms: if you assume LEM, then proving existence does not mean actually coming up with an element [Sat Sep 16 21:32:49 2017] with LEM you can prove existence by contradiction, which means: all you need to do is to show that non-existence doesn't make sense [Sat Sep 16 21:36:46 2017] "the set of even naturals is non-empty" = "there exists an even natural number"… (contrived) proof with LEM: assume that all naturals were odd… sums of natural numbers are natural numbers, so they must be odd as well, but the sum of two odd numbers is always even, thus there exist even natural numbers [Sat Sep 16 21:37:14 2017] the point is: in the proof i never came up with an actual even natural [Sat Sep 16 21:40:06 2017] right, I was thinking about coq objects, which are construcive and therefore decidable in various ways [Sat Sep 16 21:43:48 2017] constructive doesn't imply decidable, a.k.a. computable [Sat Sep 16 21:44:06 2017] well [Sat Sep 16 21:44:31 2017] any inductive type you can destruct [Sat Sep 16 21:45:15 2017] and that will give you one or more cases for empty, that are contradictions, and one or more cases where an element appears [Sat Sep 16 21:46:02 2017] so the proof for lists is easy, and I'd expect the proof for msets is too [Sat Sep 16 21:46:47 2017] what about functions? for example function injectivity is not decidable in general [Sat Sep 16 21:47:51 2017] I'm happy to concede your abstract point [Sat Sep 16 21:48:09 2017] I have been thinking specifically about containers of the programmatic kind [Sat Sep 16 21:48:53 2017] yeah, you need to be careful to make them decidable though, because properties are not decidable in general, not even for nice inductive data types [Sat Sep 16 22:15:55 2017] actually mucking with msets seems to be extremely painful, but maybe that's just because I don't understand the inner workings. [Sat Sep 16 22:21:18 2017] ah, there we go. yeah, the proof goes through [Sat Sep 16 22:27:12 2017] for some reason it's set up so you need to "compute", "simpl" doesn't do anything on anything [Sat Sep 16 22:28:06 2017] that and xs <> MyMSet.empty doesn't work without proof irrelevance (and maybe not then either, didn't try), because the mset is carrying around a proof in it [Sat Sep 16 22:28:25 2017] and so the <> doesn't provide the contradiction you need. [Sat Sep 16 22:28:28 2017] anyway, whatevs [Sat Sep 16 22:28:29 2017] thanks [Sat Sep 16 22:30:40 2017] (I tried, it does work) [Sat Sep 16 22:41:20 2017] hrm, but proof irrelevance seems to come from Classical [Sat Sep 16 22:41:25 2017] anyway, whatever really, need to make dinner [Sun Sep 17 05:00:57 2017] What is the minimal set of tactics which can prove anything that can be proven in Coq without directly specifying Gallina terms? [Sun Sep 17 06:14:46 2017] numee, where do you draw the border, what about "exact"? [Sun Sep 17 06:38:08 2017] else, I'd say [Sun Sep 17 06:38:08 2017] lambda → intro, function application → apply, variables → exact, constants → exact, Type → exact Type, forall → refine (forall x:_, _)., let → pose, match → destruct [Sun Sep 17 07:34:37 2017] rrika: by "without directly specifying Gallina terms" i tried to exclude exact (fun ...) [Sun Sep 17 07:35:41 2017] for example, is it possible to prove that (forall n, even (S (n + n)) -> False) from (even_contra': forall n', even n' -> forall n, (n' = S (n+n)) -> False) only with the tactics you listed? (the propositions are taken from CPDT p.84) [Sun Sep 17 07:36:20 2017] Even when you write "apply t" or "exact t", t is already a Gallina term [Sun Sep 17 07:36:25 2017] not sure where your line is [Sun Sep 17 07:53:52 2017] Cypi: would you accept if I said "without writing explicit lambda abstraction (fun ...)" ? [Sun Sep 17 07:53:53 2017] It is my impression that Ltac is meant to replace directly writing complex Gallina terms so every time I see a complex Gallina term in a proof I feel unconfortable. maybe this impression is just wrong [Sun Sep 17 07:59:06 2017] numee, "intro" will add a lambda abstraction to the proof. [Sun Sep 17 08:02:15 2017] rrika: can you achieve what eapply do with another tactic? I think refine (fun ...) would do but that makes me uncomfortable [Sun Sep 17 08:03:49 2017] hm, isn't that kind of the opposite? [Sun Sep 17 08:03:56 2017] apply/eapply add applications [Sun Sep 17 08:04:03 2017] refine (fun …) adds a lambda [Sun Sep 17 08:04:49 2017] "refine (fun a, _)." and "intro a." should do the same. [Sun Sep 17 08:05:25 2017] oh, you meant "fun" as placeholder, not the keyword [Sun Sep 17 17:13:30 2017] how can I pass an implicit argument explicitly? [Sun Sep 17 17:14:41 2017] Use @ in front of the constant name. Something like "@f x y z" [Sun Sep 17 17:26:43 2017] ah, and then I must give all arguments? hrm [Sun Sep 17 17:26:50 2017] yes [Sun Sep 17 17:27:24 2017] that's a bit painful… I should rethink this [Sun Sep 17 17:27:28 2017] also inside inductive declarations sometimes you seem to need to give all arguments anyway, not sure waht the deal with that is [Sun Sep 17 19:55:28 2017] what is an apply that I can use just on a hypothesis? the apply tactics I am finding target the goal [Sun Sep 17 19:55:41 2017] I just want a beta reduction [Sun Sep 17 19:58:48 2017] Okay, I think I'm missing something. https://coq.inria.fr/library/Coq.Vectors.Fin.html and https://coq.inria.fr/stdlib/Coq.Vectors.VectorDef.html both define an inductive type "t". Which seems crazy, because it's not exactly a great name and the overlap can only be a pain. Is there a reason for this? [Sun Sep 17 20:00:18 2017] Can I maybe rename them or something if I want to import both? [Sun Sep 17 20:11:11 2017] erisco: like "apply foo in H"? [Sun Sep 17 20:11:52 2017] apply H in H. seems to work, mkay, thanks [Sun Sep 17 20:12:08 2017] also rewrite foo in H, etc. [Sun Sep 17 20:12:13 2017] symmetry in H [Sun Sep 17 20:12:36 2017] you can use a lot of tactics in hypotheses [Sun Sep 17 20:13:42 2017] well I honestly don't know what apply H in H means, other than it targets H [Sun Sep 17 20:14:04 2017] chobbes: I'd have expected that to be inside a module, but apparently not [Sun Sep 17 20:14:14 2017] what you want to do is Require Fin but not Import, then refer to it as Fin.t [Sun Sep 17 20:14:31 2017] erisco: apply H in H per se won't go [Sun Sep 17 20:15:02 2017] but suppose you have s: string H: length s = 0 [Sun Sep 17 20:15:17 2017] and a lemma foo: length s = 0 -> s = EmptyString [Sun Sep 17 20:15:30 2017] then "apply foo in H" will convert H to: s = EmptyString [Sun Sep 17 20:15:31 2017] H has the form (fun x => m) a [Sun Sep 17 20:15:57 2017] and it won't simpl or otherwise reduce further? [Sun Sep 17 20:16:08 2017] (simpl in H) [Sun Sep 17 20:16:28 2017] dh`: thanks for the solution! [Sun Sep 17 20:16:30 2017] simpl in H also works, but so did apply H in H [Sun Sep 17 20:16:50 2017] it's weird that it would let you apply a hypotheses to itself [Sun Sep 17 20:16:57 2017] but *shrug* [Sun Sep 17 20:16:57 2017] * shrugs [Sun Sep 17 20:17:08 2017] simpl in H is definitely something to know about [Sun Sep 17 20:26:27 2017] hmm, it seems if you have H of the form t -> t, then you can apply H in H and produce H: t, and adds t as an additional goal [Sun Sep 17 20:27:21 2017] but this doesn't seem useful. [Sun Sep 17 20:27:28 2017] otherwise, or at least the things I've tried, it doesn't typecheck. [Sun Sep 17 20:52:17 2017] how can I fail loudly from within a match? it instead tries the next pattern, which I do not want [Sun Sep 17 20:52:28 2017] rather I want to see exactly why the tactic I am using fails [Sun Sep 17 20:54:24 2017] that I dunno, sorry [Sun Sep 17 20:54:37 2017] other than "try it by hand", which probably isn't helpful [Sun Sep 17 21:08:17 2017] thanks [Mon Sep 18 09:27:56 2017] how can I disable Init? [Mon Sep 18 09:28:35 2017] you can use the cli option -noinit [Mon Sep 18 09:30:28 2017] thanks… any idea for using CoqIDE? [Mon Sep 18 09:30:47 2017] sorry, I use ProofGeneral :( [Mon Sep 18 09:30:49 2017] "coqide -noinit" will work. [Mon Sep 18 09:31:00 2017] (I think you can also configure the coqtop arguments somewhere in the menu) [Mon Sep 18 09:33:03 2017] oh great, now CoqIDE won't start =\ [Mon Sep 18 09:33:08 2017] uhoh [Mon Sep 18 09:33:33 2017] any idea where the config file is stored? [Mon Sep 18 09:33:55 2017] apparently AUTO -noinit was not valid [Mon Sep 18 09:34:32 2017] for me, ~/.config/coq/coqiderc, but it probably depends on your system [Mon Sep 18 09:36:15 2017] well now my config is borked… can you do me a favour and tell me your cmd_coqtop line? [Mon Sep 18 09:36:35 2017] I tried setting it back to AUTO but CoqIDE keeps deleting the setting now [Mon Sep 18 09:36:47 2017] cmd_coqtop = [Mon Sep 18 09:36:49 2017] literally empty [Mon Sep 18 09:36:54 2017] oh, okay [Mon Sep 18 09:37:58 2017] I don't know what to do… I tried setting it to "coqtop -noinit" but when I close CoqIDE it just sets it to blank again [Mon Sep 18 09:40:01 2017] looks like this specific option does not support additional arguments, that's weird... [Mon Sep 18 09:41:09 2017] I tried making a batch script wrapper but it deletes that too [Mon Sep 18 09:41:44 2017] Can't you just alias coqide to "coqide -noinit" or something like this? Since CoqIDE seems to behave weirdly... [Mon Sep 18 09:45:21 2017] yeah I guess… will have to do some rigmarole… I want double-clicking on a Coq file to use -noinit [Mon Sep 18 09:45:36 2017] I don't really want this behaviour globally… but seems I have no option [Mon Sep 18 09:46:20 2017] If you don't want it globally, having it in the config file is certainly not a good idea, is it? [Mon Sep 18 09:46:50 2017] that is at least more convenient to change than updating shortcuts and file associations [Mon Sep 18 09:47:11 2017] what I want is to just have a pragma or import statement that gets rid of INit [Mon Sep 18 09:49:29 2017] bah whatever… guess I will have to start it with a shell [Mon Sep 18 09:52:41 2017] erisco: http://coq-club.inria.narkive.com/mBGy60m7/unload-prelude [Mon Sep 18 09:55:07 2017] what loads all the tactics? I don't want those either [Mon Sep 18 10:02:47 2017] even with -noinit -nois I have tactics such as intros [Mon Sep 18 11:02:52 2017] oh the horror, a shell :-p [Mon Sep 18 15:24:10 2017] I'm trying to define my own induction principle with Program Fixpoint but in the Obligation proof there is no references to the functin that is being defined in the list of hypotheses [Mon Sep 18 15:26:39 2017] So I tried to solve this by Program Definition foo ... := fix _foo ... so that I can use _foo in the Obligation proof [Mon Sep 18 15:27:03 2017] However, when the proof is completed, Coq crashes with Anomaly: [Mon Sep 18 15:27:03 2017] error with no safe_id attached [Mon Sep 18 15:28:00 2017] Am I doing something wrong or I found a bug in Coq? [Mon Sep 18 15:39:05 2017] Here is the minimal Coq code that exhibits the first problem I'm faced with: https://pastebin.com/dkLwTrCc [Mon Sep 18 17:57:25 2017] how do I get CoqIDE to let me import libraries in a local directory (same as opened file)? [Mon Sep 18 17:57:40 2017] I tried coqide -I with a bunch of things and none worked [Mon Sep 18 18:24:58 2017] now I am trying -R and no luck =\ [Mon Sep 18 18:33:02 2017] can I remap to the empty string? [Mon Sep 18 18:33:32 2017] I tried remapping the local directory to Local, but I still cannot load my libraries because it whines they are not called Local.Foo [Mon Sep 18 18:34:48 2017] okay, I use coqide -R . "" myfile.v and that works [Mon Sep 18 18:39:34 2017] I believe the proper way is to use Top instead of the empty string, but I'm not 100% sure [Tue Sep 19 08:23:00 2017] What options are available when Coq declines a Function definition saying "can not contain an applied match (See Limitation in Section 2.3 of refman)" ? [Tue Sep 19 08:23:37 2017] Program Fixpoint? [Tue Sep 19 08:27:42 2017] anton-trunov: I tried it but it didn't work because I cannot refer to the function that is being defined in the proof: https://pastebin.com/dkLwTrCc [Tue Sep 19 08:38:42 2017] You need to force Program to add it to your context, for instance with something like http://lpaste.net/358556 [Tue Sep 19 08:39:22 2017] the rationale for this is in the refman https://coq.inria.fr/refman/Reference-Manual027.html#sec758 [Tue Sep 19 08:42:16 2017] Cypi: thank you! I'll try to apply it to my case (the code I've shown was somewhat simplified) [Tue Sep 19 08:42:37 2017] Cypi: thank you for the link! [Tue Sep 19 09:55:11 2017] Cypi: thanks to the magic you told me I just completed the proof I've been working on for the past few days (a weird induction principle for list): https://pastebin.com/iDM8xhWu [Tue Sep 19 09:56:39 2017] numee: It looks similar to `rev_ind` [Tue Sep 19 09:58:12 2017] anton-trunov: yes it is. but not the same because it reduces a list from both left and right, rather than either of them [Tue Sep 19 10:02:33 2017] I mean, have a look at: (Pmore : (forall a b, forall xs, P xs -> P (a::xs++b::nil))). You can assume the proposition for the list with its head and last elements removed [Tue Sep 19 10:05:58 2017] I feel like the proof could be much simpler and shorter, but this is what I came up with. feedback is welcome [Tue Sep 19 11:36:41 2017] numee: I guess there is a more elegant version, but nevertheless: https://gist.github.com/anton-trunov/774fae6872df8d10a0350b73f326b1f4 [Tue Sep 19 12:48:53 2017] anton-trunov: that's already astonishingly simple and short. great work indeed [Tue Sep 19 12:50:04 2017] numee: thank you! [Tue Sep 19 13:22:14 2017] thinking about wlog reasoning again... [Tue Sep 19 13:30:49 2017] the [clear] tactic does nothing to the proof term, right? [Tue Sep 19 13:30:54 2017] it just affects the proving interface? [Tue Sep 19 13:32:51 2017] sort of. Technically it does create an intermediate existential variable, whose context is restricted. But if you normalize your proof term with respect to existential variables, you are right, it does nothing to the proof term. [Tue Sep 19 15:01:49 2017] Can anyone give me a hand to prove this simple lemma: Theorem perm_nil : forall {X: Type} (al: list X) (p: Permutation nil al), al = nil. [Tue Sep 19 15:02:55 2017] hmm, maybe by destructing al? [Tue Sep 19 15:03:21 2017] the nil case by symmetry and the h:t case by inversion? [Tue Sep 19 15:07:22 2017] modulus: that's what i tried. for nil, just reflexivity even worked [Tue Sep 19 15:07:31 2017] but i'm not sure how to proceed with inversion in the second case [Tue Sep 19 15:07:59 2017] my list of hypothesis just explodes with noise... [Tue Sep 19 15:09:21 2017] The easiest way I know is to prove that "Permutation l1 l2" implies that l1 and l2 have the same length. [Tue Sep 19 15:43:53 2017] Cypi: I'm actually trying to prove that and the permutation nil l1 thing is a lemma -_- [Tue Sep 19 15:56:51 2017] You shouldn't need any lemma for "Permutation l1 l2 -> length l1 = length l2" [Tue Sep 19 15:57:06 2017] make sure to do an induction on the right thing [Tue Sep 19 15:58:46 2017] Cypi: yeah, i probably messed up. Though I should be able to prove that permutation nil x anyway... that seems to be easier between those two [Tue Sep 19 16:00:09 2017] well, it's not easier [Tue Sep 19 16:01:01 2017] Btw, how do i enable the list notation? So that I can use things like [1;2;3;4] [Tue Sep 19 16:01:04 2017] Reading the four constructors of Permutation, it is quite obvious that it preserves length. On the other hand, the last constructor makes it difficult to say anything about "Permutation nil l" [Tue Sep 19 16:01:11 2017] Import ListNotations. [Tue Sep 19 16:04:17 2017] Cypi: thanks [Tue Sep 19 17:33:32 2017] new to ltac - is there a concept of, like, matching against what the new goal would be if i applied a tactic? [Tue Sep 19 17:33:44 2017] without actually applying the tactic to the main proof state? [Tue Sep 19 17:33:54 2017] You can always fail afterwards [Tue Sep 19 17:34:02 2017] sounds kinda hacky :( [Tue Sep 19 17:34:05 2017] It is [Tue Sep 19 17:34:14 2017] I'm not sure you can get back that information and use it after failing, too [Tue Sep 19 17:34:24 2017] (pretty sure jgross would know that kind of stuff) [Tue Sep 19 18:49:03 2017] haha i got an anomaly [Tue Sep 19 18:49:23 2017] (by trying to use a uconstr as a term context while fucking around randomly) [Tue Sep 19 19:01:41 2017] Is 'All' (proposition satisfied by ALL elements of a list) in the standard library somewhere? [Tue Sep 19 19:03:06 2017] Seems like it might just be a thing SF made up, but I'd rather not redefine it if it already exists. [Tue Sep 19 19:05:46 2017] im pretty sure it exists [Tue Sep 19 19:05:50 2017] There is Forall, defined in List. [Tue Sep 19 19:05:51 2017] it's called "Forall", i think (with a capital F) [Tue Sep 19 19:05:55 2017] jinx :) [Tue Sep 19 19:06:48 2017] benzrf: Cypi thanks! That's exactly what I wanted :). [Tue Sep 19 19:07:15 2017] I knew it *had* to be there somewhere. [Tue Sep 19 19:29:11 2017] is there a way to evaluate an ltac expression and see what it results in, when the result isnt a tactic? [Tue Sep 19 19:30:46 2017] hmm, this worked for now, but it doesnt seem terribly robust in general: let u := expr in pose (foo:=u). [Tue Sep 19 20:19:41 2017] ach, ltac is crap [Tue Sep 19 20:24:47 2017] benzrf, try idtac expr which should print expr [Tue Sep 19 20:34:33 2017] oh damn! [Tue Sep 19 20:34:36 2017] thanks! [Tue Sep 19 20:36:32 2017] when, i do something like destruct (x <=? y), i lose the hypothesis that x <= y in my subgoal. anyway to fix that? [Tue Sep 19 20:38:00 2017] rgrinberg: try [destruct (x <=? y) eqn:H] [Tue Sep 19 20:38:24 2017] benzrf: thanks. how come i need try? [Tue Sep 19 20:38:41 2017] oh lol, the try was an english word, the stuff in the braces is what you should use [Tue Sep 19 20:38:48 2017] er, s/braces/square brackets/ [Tue Sep 19 20:39:50 2017] oh haha [Tue Sep 19 20:40:08 2017] guhhh why cant i use match on a uconstr!!! [Tue Sep 19 21:12:49 2017] benzrf: btw, that gives me the proposition in the form x <= y = true. how can i turn that into x <= y? [Tue Sep 19 21:13:19 2017] there should be a lemma regarding that [Tue Sep 19 21:13:29 2017] but you could also just use a different lemma to start with [Tue Sep 19 21:13:45 2017] try this: [Tue Sep 19 21:13:55 2017] Search (forall x y, x <= y \/ y <= x). [Wed Sep 20 23:54:26 2017] I think the trick is you need to remember (rev l) as m, then revert Heqm; revert l. *then* induction m [Thu Sep 21 00:16:28 2017] intros. [Thu Sep 21 00:16:28 2017] remember (rev xs) as rxs. [Thu Sep 21 00:16:28 2017] revert Heqrxs. revert xs. [Thu Sep 21 00:16:28 2017] induction rxs; intros. [Thu Sep 21 00:16:31 2017] like that. [Thu Sep 21 00:16:35 2017] it works. [Thu Sep 21 00:17:22 2017] if you don't do the revert though the induction hypothesis isn't adequately generalized. [Thu Sep 21 00:30:51 2017] whee, now I have rev_ind for my string library :-) [Thu Sep 21 02:06:38 2017] benzrf: I did find a way to represent it that was more or less what you described :) [Thu Sep 21 02:11:18 2017] benzrf: in the above example, R = { : ... }, G = { : exist H := { x[0], x[1], x[2], ... , x[z] }, x[0] = a, x[z] = b, forall x[n] where 0 <= n < x, elementof H } [Thu Sep 21 02:17:41 2017] hi. hm. is somebody here who is familiar with the internals of the extraction mechanism? I have a weird bug where stuff is extracted twice under different names. But finding a minimal example is hard because I don't even know where to look at. On the other hand, I do not want to post all my code on a publicly visible place yet. [Thu Sep 21 02:18:20 2017] not I, I've been meaning to try to figure it out but nothing yet [Thu Sep 21 02:19:43 2017] dh`: what? [Thu Sep 21 02:20:48 2017] the problem does not yet occur in 8.4pl6 [Thu Sep 21 02:20:58 2017] but it does in 8.5 and 8.6, apparently [Thu Sep 21 02:24:30 2017] did anything significant change during these versions? [Thu Sep 21 02:42:48 2017] if somebody should come here who could help me, highlight plz. [Thu Sep 21 04:03:15 2017] hello! I just got started with Coq and following the Software Foundations book. In one of the exercises they ask to prove Theorem andb_true_elim2 : ∀ b c : bool, [Thu Sep 21 04:03:22 2017] andb b c = true → c = true. [Thu Sep 21 04:03:44 2017] shit, screwed up the formatting let me use a pastebin [Thu Sep 21 04:06:32 2017] So, they ask to prove [0], I wrote [1] which works but I got to it almost by chance and intuition. [1] gives [2] as subgoals and Im not sure how destruct gets to creating those subgoals. why does this work? http://lpaste.net/4151898009770131456 [Thu Sep 21 04:08:32 2017] I understand it when using `intros [] [].` with inductively defined datatypes, but I am a bit confused as to how destruct works with the hypothesis `andb b c` in the proof [1] [Thu Sep 21 04:11:19 2017] is it just applying andb to the values of b c in the current case? [Thu Sep 21 05:19:19 2017] what is the oldest coq version to support -, +, *, --, ++, **, etc., bullets? [Thu Sep 21 05:31:16 2017] 8.5 is the first tu support --, ++, **, etc.; 8.4 is the first to support -, + and * [Thu Sep 21 05:31:22 2017] to* [Thu Sep 21 05:33:59 2017] Cypi: thx [Thu Sep 21 05:47:30 2017] marcecoll: the 3rd `[]` is not destructing `andb b c`, it is destructing `andb b c = true` [Thu Sep 21 05:48:43 2017] destructing an equality will have the effect to rewrite the right-hand side to the left-hand side. So for instance, after `intros [] []`, the first goal is `true && true = true -> true = true`, which becomes `true && true = true && true` when you eliminate the equality at the head with one more `intros []` [Thu Sep 21 05:49:20 2017] a more explicit way to write it is `intros [] [] <-.` [Thu Sep 21 05:49:29 2017] (this way, it is obvious that you are rewriting) [Thu Sep 21 06:12:57 2017] Cypi: thanks, that really helped [Thu Sep 21 07:36:45 2017] could somebody please give me a clue on how to prove https://gist.github.com/dasuxullebt/226178ef1863bda02d94c542b63c1dd8 without dependent induction? (probably this function triggers a bug, and as dependent induction is fishy, I wondered whether this might be the problem) [Thu Sep 21 07:43:50 2017] I need to destructure the Vector.t a n and the Fin.t n simultaneously, and then also differentiate on the actual value of this Fin.t n [Thu Sep 21 07:54:15 2017] Do you mind axioms or not? [Thu Sep 21 08:01:52 2017] schoppenhauer : here is my take on it, using a Fixpoint and dependent destruction rather than dependent induction http://lpaste.net/358596 . It should be approximately the same though, and suffers from the same problem: dependent destruction uses the JMeq_eq axiom. [Thu Sep 21 08:02:28 2017] Removing JMeq_eq requires a bit more work, but it is very doable [Thu Sep 21 08:24:35 2017] Here is one possible way to do it axiom-less http://lpaste.net/358597 (this is what is implemented in Equations for instance; another way could be small inversion perhaps, if you are interested) [Thu Sep 21 08:38:47 2017] Cypi: what does "now" do? (not mentioned in https://coq.inria.fr/refman/tactic-index.html) [Thu Sep 21 08:39:33 2017] now = ; easy [Thu Sep 21 08:39:47 2017] Tactic Notation "now" tactic(t) := t; easy. [Thu Sep 21 08:39:52 2017] well ^ [Thu Sep 21 08:41:59 2017] ah ok. [Thu Sep 21 08:43:04 2017] It’s defined in https://coq.inria.fr/distrib/current/stdlib/Coq.Init.Tactics.html [Thu Sep 21 08:44:16 2017] ok thx [Thu Sep 21 08:44:51 2017] Cypi: does small inversion work without JMEq? (I read http://gallium.inria.fr/blog/a-new-Coq-tactic-for-inversion/ but it's not clear to me) [Thu Sep 21 08:46:45 2017] Cypi: also, invert appears not to be in 8.7-beta1. is it in the git version? [Thu Sep 21 08:47:08 2017] This should be the goal, yes. "Right now, we would rather not assume the K axiom" [Thu Sep 21 08:47:29 2017] I didn't say it was in Coq, it was just a pointer to the name of a technique to do proper dependent pattern-matching [Thu Sep 21 08:47:52 2017] Equations is not in Coq either for now, which is why the snippet I pasted contains the tactic depelim_fin [Thu Sep 21 08:48:10 2017] (which is just a well-behaved dependent elimination tactic specialized for fin) [Thu Sep 21 08:53:38 2017] ok, I guess I'd have to read the paper to fully understand what's going on. [Thu Sep 21 08:54:18 2017] Cypi: may I use your code? (How) should I attribute it? [Thu Sep 21 08:54:29 2017] Just use it as you wish, no attribution necessary [Thu Sep 21 08:54:34 2017] ok thx [Thu Sep 21 08:57:27 2017] anyway, I guess I should file a bug report. because I think (could not test it yet because internet is so slow here) this function somehow causes the extraction mechanism to extract the vector type twice [Thu Sep 21 08:58:04 2017] at least it is the function that uses extracted functions "t_rect" and "t_rect0", where t_rect0 is t_rect for a second definition of the vector type. [Thu Sep 21 09:01:13 2017] Hmm, if I just do "Recursive Extraction array_set." at the end of the snippet above, it seems to extract just as expected. [Thu Sep 21 09:05:23 2017] Cypi: not for me, actually. [Thu Sep 21 09:05:28 2017] Cypi: I extract to haskell. [Thu Sep 21 09:05:40 2017] Cypi: ok, you just found the minimal example of the bug \o/ [Thu Sep 21 09:05:43 2017] Cypi: thank you! [Thu Sep 21 09:06:05 2017] Cypi: it doesn't happen on 8.4pl6, but on 8.5pl3. [Thu Sep 21 09:11:16 2017] Cypi: and your code works \o/ [Thu Sep 21 09:11:22 2017] * hugs Cypi [Thu Sep 21 10:24:44 2017] anyone managed to solve the elements_relate theorem in the new vfa version ? [Thu Sep 21 10:25:39 2017] is there a link? [Thu Sep 21 10:25:50 2017] https://softwarefoundations.cis.upenn.edu/vfa-current/Redblack.html [Thu Sep 21 10:26:17 2017] it says that "Because elements does not pay attention to colors, and does not rebalance the tree, then its proof should be a simple copy-paste from SearchTree.v, with only minor edits." [Thu Sep 21 10:26:21 2017] but it is not true [Thu Sep 21 10:26:34 2017] because "int2Z x = int2Z y" isn't equivalent to "x = y" [Thu Sep 21 10:27:05 2017] that seems unsolvable to me, but I can't say I am an expert [Thu Sep 21 10:27:31 2017] (also the proof in the other exercise is only half of what is asked here) [Thu Sep 21 10:28:00 2017] or perhaps ... [Thu Sep 21 10:28:02 2017] I remember it was discussed here: https://sympa.inria.fr/sympa/arc/coq-club/2016-08/msg00196.html [Thu Sep 21 10:28:03 2017] humm [Thu Sep 21 10:28:45 2017] that is my exact problem [Thu Sep 21 10:28:47 2017] thanks a lot ! [Thu Sep 21 10:28:59 2017] you are welcome :) [Thu Sep 21 10:30:44 2017] oh, so this exercise is buggy, nice to know :) [Thu Sep 21 10:31:45 2017] ah damned, it is not buggy apparently [Thu Sep 21 10:31:59 2017] "Although this proof is only 4 stars of difficulty, it is plenty of work to do." [Thu Sep 21 10:32:04 2017] :) [Thu Sep 21 10:36:19 2017] well, if someone has a clue, I have none [Thu Sep 21 10:36:31 2017] I can copy/paste my solution that almost works [Thu Sep 21 10:36:59 2017] but I suspect there is something else that is smarter to do [Thu Sep 21 11:04:07 2017] Oh, I did not know about VFA. Guess I know what I'm doing this week-end :) [Thu Sep 21 11:34:18 2017] Cypi: please let me know if you manage to solve this particular problem [Thu Sep 21 11:34:32 2017] (elements_relate in Redlack.v) [Thu Sep 21 17:23:15 2017] hi , is it possible to prove this (and if so , how ?): Lemma test {A : Type} `{EqDec A} (x y : A) : (x ==b y) = true -> x = y. [Thu Sep 21 18:49:58 2017] qertyyyy: do you mean === at the end there? [Thu Sep 21 19:17:07 2017] benzrf: not exactly .. but if it helps: can I proof this lemma here : Lemma test2 {A : Type} `{EqDec A} (x y : A) : (x === y) -> (x = y). [Thu Sep 21 19:19:24 2017] qertyyyy, I don't think that's possible [Thu Sep 21 19:31:41 2017] ok , if thats so then I have another question. Is there somthing that I can use like equiv_dec for a "generiac equality check"? To be more specific I have this function : [Thu Sep 21 19:31:55 2017] Fixpoint del1 {A : Type} `{EqDec A} (val : A) (ls : list A) : list A := [Thu Sep 21 19:31:57 2017] match ls with [Thu Sep 21 19:31:59 2017] | [] => [] [Thu Sep 21 19:32:01 2017] | x::xs => if equiv_dec x val then xs else x :: del1 val xs [Thu Sep 21 19:32:03 2017] end.Y [Thu Sep 21 19:32:25 2017] this just deletes the first occurence of val in a list [Thu Sep 21 19:33:00 2017] the problem I have with equiv_dec is that I feels a bit awkward to use in a proof [Thu Sep 21 19:36:43 2017] qertyyyy, counterexample for 2===3 -> 2=3. https://gist.github.com/rrika/ffbb900730d84e66183076561eb70f8d [Thu Sep 21 19:38:13 2017] qertyyyy, what part of it do you feel is awkward? [Thu Sep 21 19:42:37 2017] rrika: thank you :). For example when I try to proof this : [Thu Sep 21 19:42:42 2017] Theorem del_4 {A : Type} `{EqDec A} (x y : A) (ls : list A) : [Thu Sep 21 19:42:44 2017] del1 x (del1 y ls) = del1 y (del1 x ls). [Thu Sep 21 19:43:19 2017] I have to use a lot of destructs (at least with my limited knowledge ... ) [Thu Sep 21 19:45:39 2017] I don't even know if it is provable in coq (since I haven't finised the proof) (but it should be provalbe ...) [Thu Sep 21 19:45:50 2017] it seems provable. [Thu Sep 21 19:45:56 2017] but I odn't know how to do it elegantly either. [Thu Sep 21 19:47:28 2017] ok. thank you very much for your time and effort :) [Thu Sep 21 20:03:57 2017] qertyyyy, here is an ugly proof for del_4: https://gist.github.com/rrika/d454d51a9f73217647d75c1626d57b5d [Thu Sep 21 20:09:23 2017] yes, I expected it to be like this (at least somewhat). (and thank you very very much again :) ) [Thu Sep 21 20:10:35 2017] ^_^ [Thu Sep 21 20:12:09 2017] rrika: and what about changing del1 itself ? can you (or anyone else) think of a different way to define it in this general way (the only other thing I can think of is to defnie a function for "every" type ... which is seems quite redundant) [Fri Sep 22 13:52:15 2017] how can I write a list of strign, such as ["foo";"bar";"baz"] : list string ? [Fri Sep 22 13:52:29 2017] I get Error: No interpretation for string "foo" [Fri Sep 22 13:52:41 2017] but I can write Definition foo : string := "foo". [Fri Sep 22 13:54:31 2017] ah ok, Local Open Scope string_scope. [Fri Sep 22 15:10:12 2017] Do you guys have any recommendations for resources to learn Coq with? [Fri Sep 22 15:12:14 2017] Software Foundations is a good one https://softwarefoundations.cis.upenn.edu/current/index.html [Fri Sep 22 15:16:08 2017] Cool. This looks promising. Thanks! [Fri Sep 22 15:23:32 2017] it's really the best place to start [Fri Sep 22 15:23:55 2017] Hello, [Fri Sep 22 15:24:22 2017] I can't find how to apply a the definition of a function to an assumption... [Fri Sep 22 15:24:40 2017] apply F in H? [Fri Sep 22 15:26:14 2017] johnw: something like that yes, I've Definition lower x l := match l with cons .... [Fri Sep 22 15:26:25 2017] and in my assumptions I've : [Fri Sep 22 15:26:34 2017] H : lower x (cons n l) [Fri Sep 22 15:28:12 2017] so I'd like to replace H by the definition of lower [Fri Sep 22 15:29:54 2017] unfold lower in H [Fri Sep 22 15:30:06 2017] (or just "simpl in H" if it is actually meant to reduce) [Fri Sep 22 15:36:25 2017] Cypi: great, thank you very much, I didn't know that it was possible to use simpl in assumptions. Thank you ! [Fri Sep 22 15:56:39 2017] And another question: how would you do a proof by case when it does *not* come out of an induction [Fri Sep 22 15:56:42 2017] like: [Fri Sep 22 15:56:54 2017] First case: x <= n [Fri Sep 22 15:57:01 2017] Second case: x > n [Fri Sep 22 15:58:40 2017] destruct (le_gt_dec x n) [Fri Sep 22 15:58:45 2017] (for this specific case) [Fri Sep 22 15:59:01 2017] A "proof by case" is mostly done through a destruct [Fri Sep 22 16:02:11 2017] Cypi: Great thank you very much, you're my god today! [Fri Sep 22 16:26:21 2017] I'm annoying, sorry, but another stupid question: I've a theorem that I'd like to use to add one more assumption, but I don't know how to do. I tried to play with apply, but it tries to applies it in the subgoal instead of creating a new assumption. [Fri Sep 22 16:27:27 2017] "pose proof t" (where t is any term) will add a new assumption with the type of t [Fri Sep 22 16:27:40 2017] hum sorry, I found the solution with pose proof. [Fri Sep 22 21:23:44 2017] bartavelle: you'll be happy to know that I am stuck at elements_relate, for now :p [Fri Sep 22 23:25:05 2017] bartavelle: alright, I'm confused. I think I have proved that the current statement of `elements_relate` is not provable... Where is the flaw? http://lpaste.net/358636 [Sat Sep 23 00:10:23 2017] cypi: where's the rest of this? [Sat Sep 23 00:12:33 2017] I need to make dinner but could use a nice puzzle unrelated to $work [Sat Sep 23 01:35:46 2017] also: is it considered better to use "reflexivity" and "assumption" when they apply, or just "auto"? [Sat Sep 23 06:24:31 2017] dh` : this is VFA https://softwarefoundations.cis.upenn.edu/vfa-current/ [Sat Sep 23 06:24:38 2017] specifically, RedBlack.v [Sat Sep 23 11:41:19 2017] when I do something like destruct (a <=? x), how can I get a <= x and x > a as assumptions for my subgoals? [Sat Sep 23 11:51:16 2017] rgrinberg: either "remember (a <=? x) as q; destruct q" or "destruct (a <=? x) eqn:H" [Sat Sep 23 11:51:39 2017] dh`: thank you! any difference between these two? [Sat Sep 23 11:51:45 2017] cypi: ah [Sat Sep 23 11:51:59 2017] rgrinberg: only in the names of what comes out [Sat Sep 23 11:52:53 2017] the remember form makes you pick a useless name q and then gives you a hypothesis Heqq; the other lets you just pick a hypothesis name H [Sat Sep 23 11:53:17 2017] the second form is obscure enough that I only found out about it when it was mentioned here a couple days ago [Sat Sep 23 11:55:43 2017] also, is there a way to simpl. a particular assumption? [Sat Sep 23 11:55:52 2017] rgrinberg: simpl in H [Sat Sep 23 11:56:10 2017] dh`: thanks again ^_^ [Sat Sep 23 11:56:48 2017] :-) [Sat Sep 23 12:02:48 2017] how do I do apply on a particular assumption to get a new assumption? [Sat Sep 23 12:28:59 2017] I don't understand why this isn't a match: https://i.imglnx.com/umzrGZ.png [Sat Sep 23 12:29:48 2017] Also, can someone explain to me why the "induction as [| n' IHn']" bit names the inductive hypothesis with IHn'? Why it names n' is clear to me, but how exactly is it telling Coq "oh yeah also name the inductive hypothesis IHn' because it's the second member of the list". [Sat Sep 23 12:35:51 2017] Oh, nevermind. Forgot to include "m" in intros. :) [Sat Sep 23 12:35:56 2017] But the second question still stands. [Sat Sep 23 19:04:40 2017] damn, the string library's almost 8000 lines already [Sat Sep 23 19:11:31 2017] which is getting to be enough that the color bar across the bottom of coqide doesn't have enough resolution [Sat Sep 23 19:11:52 2017] Just buy a bigger screen I guess [Sat Sep 23 19:17:06 2017] that's what 5K TVs were made for [Sat Sep 23 19:22:12 2017] Suppose I already have an assumption x <= y and I'd like to simplify an expression like if x <=? y in one of my goals. How would I do that? [Sat Sep 23 19:23:05 2017] Hmmm. Is there a way to define an inductive proposition on an indexed data type? E.g., NoDup but for Vectors? `Inductive NoDupVec {A : Type} {n : nat} : Vec A n -> Prop`. In this case you run into problems when defining NoDupVec_nil for the base case, since I don't know how to say n = 0 in this case. [Sat Sep 23 19:27:51 2017] rgrinberg: you could use a theorem like PeanoNat.Nat.leb_le: forall n m : nat, (n <=? m) = true <-> n <= m [Sat Sep 23 19:28:36 2017] Chobbes: the n should also be an index [Sat Sep 23 19:28:56 2017] Inductive NoDupVec {A : Type} : forall {n : nat}, Vec A n -> Prop [Sat Sep 23 19:30:03 2017] Cypi: ahhh, the forall was what I was missing when I tried that before, thanks :). [Sat Sep 23 20:44:42 2017] bartavelle: do you know what "makeblack_fiddle" is? (Still in RedBlack.v) [Sun Sep 24 00:11:51 2017] with a 5K TV I just wouldn't be able to see it :-) [Sun Sep 24 00:12:47 2017] (there's now almost 9000 lines) [Sun Sep 24 02:31:45 2017] cypi no, I didn't see this comment, but didn't need it either [Sun Sep 24 04:28:42 2017] bartavelle : thanks, you're right, it was way easier than what I though at first because of this comment :) [Sun Sep 24 09:13:03 2017] Cypi: so, did you manage to solve the problematic part ? [Sun Sep 24 09:13:37 2017] Well, as I wasy saying earlier, I think I proved that it is not provable. So I was asking for the flaw in my proof :p [Sun Sep 24 09:13:37 2017] (elements_relate) [Sun Sep 24 09:13:44 2017] ah [Sun Sep 24 09:13:47 2017] lemme see [Sun Sep 24 09:13:50 2017] bartavelle: alright, I'm confused. I think I have proved that the current statement of `elements_relate` is not provable... Where is the flaw? http://lpaste.net/358636 [Sun Sep 24 09:13:54 2017] there [Sun Sep 24 09:13:55 2017] ah yes! [Sun Sep 24 09:14:18 2017] did you look at the email exchange that was exhumed earlier in the week ? [Sun Sep 24 09:14:35 2017] not sure, I'll take a look [Sun Sep 24 09:14:54 2017] https://sympa.inria.fr/sympa/arc/coq-club/2016-08/msg00196.html [Sun Sep 24 09:14:59 2017] brb [Sun Sep 24 09:16:00 2017] Hmm. So it seems like Gaëtan suggested the same counterexample. And that Andrew fixed it, but...it is not consistent with what we see in the current version [Sun Sep 24 09:16:09 2017] maybe he forgot to update it at some point? [Sun Sep 24 09:31:04 2017] yeah :/ [Sun Sep 24 09:31:46 2017] well, from what I understand it was provable all along [Sun Sep 24 09:32:34 2017] but the comment is indeed not updated [Sun Sep 24 09:32:53 2017] that was more than a year ago, apprently for version 0.4, and it is now 1.1 [Sun Sep 24 09:39:26 2017] If it is supposed to be provable in the current version, I shouldn't be able to prove what I pasted, I think [Sun Sep 24 09:40:08 2017] duh, yeah, you are right! [Sun Sep 24 11:19:40 2017] thanks Cypi: i need to use this lemma with rewrite/apply right? [Sun Sep 24 11:20:17 2017] Somehow it's not working. I guess it's b/c my goal is (if x <=? y then .. else ..) rather than the direct <=? [Sun Sep 24 11:55:42 2017] i solved my issue by using destruct and proving the impossible case with congruence. I'm sure there are more elegant ways -_- [Sun Sep 24 19:12:36 2017] are there any examples of using functional extensionality in coq? [Sun Sep 24 19:24:58 2017] rgrinberg: what do you mean exactly [Sun Sep 24 19:26:30 2017] benzrf: nvm i figured it out. it's just the extensionality tactic that i need to use [Sun Sep 24 19:27:19 2017] heh [Sun Sep 24 19:27:46 2017] jsyk: in most contexts im pretty sure it's just called "function extensionality"; im not sure why coq calls it "function*al*" [Sun Sep 24 19:29:07 2017] speaking of which, is there a table in the docs somewhere of such things that are available but often avoided? [Sun Sep 24 19:29:22 2017] functional extensionality, for example, and classicalfacts [Sun Sep 24 19:41:26 2017] is there a way to make Search also search notations? [Sun Sep 24 21:18:38 2017] there's something else for notations but I can never remember what it is [Sun Sep 24 21:29:25 2017] rgrinberg: yeah, just put the notation in quotes [Sun Sep 24 21:29:43 2017] er, wait - what precisely do you mean by 'search notations' [Mon Sep 25 15:38:09 2017] hi. I'm a complete beginner, but why is >= on the natural numbers not a reflexive relation but <= is? [Mon Sep 25 15:38:36 2017] or to phrase it differently, why can the tactic "reflexivity" prove "a <= a" but not "a >= a"? [Mon Sep 25 15:38:48 2017] <= is defined in terms of <= [Mon Sep 25 15:38:56 2017] that is, >= [Mon Sep 25 15:39:27 2017] if you unfold ge, you should be able to [Mon Sep 25 15:39:38 2017] I don't know why the separate instance doesn't exist, though [Mon Sep 25 15:40:13 2017] yeah unfolding it works, thanks. [Mon Sep 25 18:51:46 2017] do any of the famous problem in mathematics (the millennium prize problems etc) have formulations in coq? [Mon Sep 25 18:51:58 2017] obviously not proofs but just the statements of what is to be proved [Mon Sep 25 18:52:54 2017] I'm curious how much machinery would be needed just to state the Riemann hypothesis, or P=NP, etc. [Mon Sep 25 18:54:03 2017] goldbach's conjecture is probably not too hard to express. [Mon Sep 25 22:44:58 2017] after many hours wrestling with coq I finally proved... that 2 is prime. [Mon Sep 25 22:45:04 2017] this was way harder than expected [Mon Sep 25 22:55:42 2017] Migi32: nice o/ [Mon Sep 25 22:56:20 2017] Migi32: you can almost certainly easily express the hailstone sequence problem in coq [Mon Sep 25 22:56:32 2017] and of course you can state fermat's last theorem [Tue Sep 26 03:59:58 2017] I suppose that using some else's library requires putting it in my program's path ? [Tue Sep 26 04:05:21 2017] in http://www.lix.polytechnique.fr/coq/V8.2pl1/contribs/GraphBasics.Graphs.html , why is there a G_eq case in the inductive graph type ? [Tue Sep 26 04:05:39 2017] isn't it obvious and equivalent to using replace or rewrite ? [Tue Sep 26 12:17:31 2017] hi. If you have a theorem that holds for all natural numbers except 0, do you formulate it as n <> 0 -> ... or something similar, or do you just use (S n) everywhere in the statement of the theorem? [Tue Sep 26 12:18:11 2017] I know both styles work, but what I'm asking is which one is more practical? [Tue Sep 26 12:18:15 2017] typically you start with n > 0 -> the rest [Tue Sep 26 12:19:00 2017] I like n <= 0 [Tue Sep 26 12:19:18 2017] but not S n [Tue Sep 26 12:19:36 2017] if you use S n, it's much harder to get your theorem to apply when you want to use it, since the constructors have to line up exactly [Tue Sep 26 12:19:44 2017] i.e., even though succ n and S n are the same, they are the same "enough" [Tue Sep 26 12:19:50 2017] aren't* [Tue Sep 26 12:19:57 2017] but is there any n <= 0? [Tue Sep 26 12:20:06 2017] but if you make n <= 0 a precondition, then the theorem will apply and you'll just generate another subgoal [Tue Sep 26 12:20:12 2017] other than 0 itself [Tue Sep 26 12:20:18 2017] oh, I meant n < 0 [Tue Sep 26 12:20:22 2017] if n : nat [Tue Sep 26 12:20:35 2017] grr, 0 < n [Tue Sep 26 12:20:38 2017] ah [Tue Sep 26 12:20:41 2017] sorry, just woken up [Tue Sep 26 12:20:45 2017] confused for a bit. [Tue Sep 26 12:20:49 2017] same [Tue Sep 26 12:21:07 2017] yeah, 0 < n -> bla bla bla works [Tue Sep 26 12:21:10 2017] n > 0 is just as good, but there are more theorems in terms of < than > in the stdlib [Tue Sep 26 12:21:30 2017] so these days I try to stick with < and <= as much as possible [Tue Sep 26 12:22:12 2017] and why not n <> 0? [Tue Sep 26 12:22:46 2017] it comes to the same in the end [Tue Sep 26 12:23:37 2017] n <> 0 is just a wee bit more annoynig [Tue Sep 26 12:24:00 2017] since now you're dealing with ~ (n = 0), rather than a direct inequality [Tue Sep 26 12:24:26 2017] omega probably doesn't care, though [Tue Sep 26 12:37:55 2017] I probably just don't understand dependent induction enough, but is there a way to prove "forall {A} (v : VectorDef.t A 0), v = VectorDef.nil A." in Coq? I was expecting to be able to use induction or dependent induction on the vector, but it leads to an error. [Tue Sep 26 12:38:19 2017] Wait. Import Program missing. [Tue Sep 26 12:39:37 2017] Problem solved :). [Tue Sep 26 12:40:20 2017] (just a disclaimer, "depdent induction" _will_ use an axiom named JMeq_eq; just in case you care about it) [Tue Sep 26 12:40:29 2017] "dependent induction"* [Tue Sep 26 12:40:54 2017] Cypi: I do know about that, but I also don't know enough to avoid it right now :). [Tue Sep 26 12:41:21 2017] not saying you should avoid it, in a lot of setting you don't have to care about it; it was just in case :) [Tue Sep 26 12:42:32 2017] there is an existing macro system, but there is some work in upgrading it i believe. [Tue Sep 26 12:42:36 2017] Cypi: I'm assuming I could prove this with refine and some fancy matches instead? [Tue Sep 26 12:42:39 2017] ups wrong chan [Tue Sep 26 12:43:15 2017] Probably, yes [Tue Sep 26 13:29:43 2017] Cypi: oh yeah. Works a charm :). [Tue Sep 26 13:30:21 2017] You did it with a match? It looks good when it works nicely :p [Tue Sep 26 13:32:01 2017] Cypi: yep! It's trivial with match, I just had only heard hushed whispers of this before, so I didn't attempt it. [Tue Sep 26 13:32:56 2017] why does "case n" not replace n in the hypotheses in the context? [Tue Sep 26 13:34:08 2017] Because "case" is low-level. Most of the time you want "destruct n" [Tue Sep 26 13:34:51 2017] (all "case" does is applying naively the eliminator for n on the current goal; it does not try to revert anything from the context back to the goal, and it does not do any intros after applying the eliminator) [Tue Sep 26 13:39:53 2017] Cypi: yeah, thanks. Which tactics to apply when is still a big struggling block. [Tue Sep 26 22:55:21 2017] hey all! any recommendations for a good first guide to coq? [Tue Sep 26 22:55:49 2017] significance: what's your background? [Tue Sep 26 22:56:12 2017] (btw, in the future don't expect sub-minute replies from this channel - i just happened to be looking at it :) ) [Tue Sep 26 22:56:48 2017] benzrf: undergraduate mathematics experience, plus a good amont of experience in some other languages [Tue Sep 26 22:57:04 2017] what languages? [Tue Sep 26 22:57:06 2017] benzrf: haha, I really appreciate it! no worries, I've been on a number of really slow channels before [Tue Sep 26 22:57:34 2017] benzrf: mostly imperative paradigms (Python, Java, etc.) but some beginning functional experience (Haskell) [Tue Sep 26 22:58:59 2017] what's driving your interest in coq? [Tue Sep 26 23:00:07 2017] benzrf: I recently read GEB and would love that kind of hands-on approach to working with the Curry-Howard isomorphism/theorem provers in general [Tue Sep 26 23:00:21 2017] It's more a general fascination for now. [Tue Sep 26 23:02:10 2017] though I'd love to dive more into the theory for sure [Tue Sep 26 23:03:15 2017] cool [Tue Sep 26 23:03:19 2017] sry was distracted [Tue Sep 26 23:03:55 2017] i kinda feel like you might be well served by focusing on haskell a bit and then taking a look at coq once youre a bit more familiar - depending on how much haskell youve already done [Tue Sep 26 23:05:06 2017] benzrf: that's probably a good call -- I'm just post-LYAH, so I'll probably try out RWH and circle back :) [Tue Sep 26 23:05:09 2017] thanks for your time!! [Tue Sep 26 23:05:22 2017] significance: oh, hold on [Tue Sep 26 23:05:26 2017] when you say post-lyah [Tue Sep 26 23:05:41 2017] (speaking of which, lyan is dispreferred these days >:O ) [Tue Sep 26 23:05:50 2017] benzrf: huh, really? what do people start with now? [Tue Sep 26 23:05:53 2017] how strong of a handle do you think you have on the content? [Tue Sep 26 23:06:13 2017] benzrf: pretty strong -- I also read up a bit on how the categorical underpinnings come in [Tue Sep 26 23:06:19 2017] uh, there's some variety in the resources, but cis194 is good - check this out https://github.com/bitemyapp/learnhaskell/ [Tue Sep 26 23:06:42 2017] sweet, I'll give cis194 a look -- heard it was good [Tue Sep 26 23:06:55 2017] well, if you feel comfortable with the stuff in lyah, there may be a lot of retreading [Tue Sep 26 23:07:07 2017] cis194 is just better about introducing a lot of that stuff, and how to use it - e.g. it has good exercises [Tue Sep 26 23:07:09 2017] anyway - [Tue Sep 26 23:07:15 2017] awesome -- thank you so so much [Tue Sep 26 23:07:18 2017] np :) [Tue Sep 26 23:07:20 2017] but - [Tue Sep 26 23:07:51 2017] so if youre comfortable with stuff like type constructors, function types, lambda expressions, algebraic data types, pattern matching -0 [Tue Sep 26 23:07:57 2017] s/0// [Tue Sep 26 23:08:00 2017] you may be ok to start with coq [Tue Sep 26 23:08:39 2017] the value of haskell knowledge in using coq is primarily in familiarity with typed lambda-calculus-based systems [Tue Sep 26 23:08:46 2017] not so much in the specifics of haskell itself [Tue Sep 26 23:09:31 2017] benzrf: awesome, I'm certainly familiar with those -- is there a canonical guide for ppl with just base experience w/ those concepts? [Tue Sep 26 23:09:55 2017] uhhh im not sure [Tue Sep 26 23:09:57 2017] thats a good question [Tue Sep 26 23:10:33 2017] personally i took a pretty rocky & gradual route in - so i dont have something i used which i would recommend, really [Tue Sep 26 23:11:50 2017] benzrf: sweet -- I'll search around a bit more and see if anything sticks out then :) [Tue Sep 26 23:12:06 2017] thank you for your time!! the cis194 thing looks like it'll be a huge help. [Tue Sep 26 23:12:18 2017] oh, cool [Tue Sep 26 23:12:49 2017] significance: for what it's worth - software foundations may be an OK introduction [Tue Sep 26 23:13:23 2017] benzrf: I'll check that out first -- thank you :) [Tue Sep 26 23:13:28 2017] but it's definitely more focused on talking about programming language stuff and coq is a vehicle for that, so it's only really incidentally an intro to coq [Tue Sep 26 23:13:42 2017] so it kind of elides some stuff which might be mentioned in something explicitly trying to explain coq to you [Tue Sep 26 23:13:45 2017] ¯\_(ツ)_/¯ [Tue Sep 26 23:13:52 2017] benzrf: gotcha -- honestly I could use a good formal programming text :) [Tue Sep 26 23:15:16 2017] ok then, that might be two birds with one stone! [Tue Sep 26 23:16:08 2017] yeah, this looks awesome -- thanks! [Tue Sep 26 23:16:18 2017] no problem! [Tue Sep 26 23:17:15 2017] have a good day/night :) [Tue Sep 26 23:17:20 2017] you too [Wed Sep 27 00:15:05 2017] I will carp slightly: while "imperative" is used in the functional programming world to mean "everything that isn't functional (or maybe logic/prolog)", properly speaking "imperative" means fortran [Wed Sep 27 00:15:39 2017] while the functional language community was curled up in a little ball by itself the outside world moved on to "structured" and then "object-oriented" and now other post-object ideas [Wed Sep 27 00:17:01 2017] there's a tendency in the functional world to lump all these together, but that's about as meaningful as grouping haskell with elisp. [Wed Sep 27 00:23:45 2017] suppose i have an asssumption that looks like this (fun x => ..) = (fun x => ...) [Wed Sep 27 00:24:06 2017] is there a way to apply a particular value to get to this equality between functions [Wed Sep 27 00:24:51 2017] hrm, that's an interesting one. [Wed Sep 27 00:25:21 2017] you can certainly do "remember ((fun x => ...) foo) as foo'" [Wed Sep 27 00:25:35 2017] but I'm not sure there's any good way to do it without retying all the ... [Wed Sep 27 00:25:38 2017] er, retyping. [Wed Sep 27 00:25:59 2017] and i mean apply a value, to get an equality between two values [Wed Sep 27 00:26:29 2017] hmm [Wed Sep 27 00:27:05 2017] maybe "assert (forall foo, (fun x => ..) foo = (fun x => ...) foo)"? [Wed Sep 27 00:27:14 2017] then use the original equality to rewrite, then reflexivity [Wed Sep 27 00:27:39 2017] then simpl in the resulting hypothesis to make the functions apply [Wed Sep 27 00:27:53 2017] do i have to copy the contents of the functions into my assertion? [Wed Sep 27 00:28:11 2017] probably :9 [Wed Sep 27 00:28:17 2017] er :( [Wed Sep 27 00:28:28 2017] like I was saying, I'm not sure there's any good way to do it without retyping the bodies [Wed Sep 27 00:29:07 2017] hmm. [Wed Sep 27 00:29:08 2017] i thought retyping referred to some type theory magic i've yet to understand :D [Wed Sep 27 00:29:14 2017] I am surprised there is no "forall {A B : Type} {f g : A -> B}, f = g -> forall x, f x = g x" lemma in the Stdlib? [Wed Sep 27 00:29:42 2017] maybe: assert (forall f g x, f = g -> f x = g x) by (intro Hfg; rewrite Hfg; auto) [Wed Sep 27 00:29:46 2017] You could just prove it above whatever you're doing, and then use it with your equality, it will certainly be less verbose [Wed Sep 27 00:30:12 2017] then apply that in your original equality [Wed Sep 27 00:30:38 2017] I wish there were a good way to search the whole library, rather than just the parts you've imported [Wed Sep 27 00:33:00 2017] actually you want the version cypi wrote with the inner forall, otherwise (IIRC) it'll demand you pick x when you apply it in your original equality [Wed Sep 27 00:34:17 2017] for my part, at the moment I'm wishing that either modules or typeclasses would let you say "let t be a type with two constructors with the following type signatures" [Wed Sep 27 00:34:56 2017] with modules, you can put such a type in a module signature but then you can only instantiate it with a type that has the same names for the constructors. [Wed Sep 27 00:34:59 2017] Yeah, I kind of have the same wish. I even want to be able to have convertibility constraints on module fields [Wed Sep 27 00:35:12 2017] and with typeclasses you can't do it at all. [Wed Sep 27 00:35:34 2017] if you make a typeclass that just has two functions that serve as the constructors, it really severely hampers proving things [Wed Sep 27 00:36:30 2017] how do prove's cypi's lemma? [Wed Sep 27 00:36:40 2017] how do i prove cypi's lemma? [Wed Sep 27 00:36:46 2017] With a rewrite [Wed Sep 27 00:37:01 2017] pretty much with what I said [Wed Sep 27 00:37:09 2017] ah yes [Wed Sep 27 00:37:44 2017] rewrite with the f = g, then you get forall x, f x = f x (or g x = g x, depending on the rewrite direction) [Wed Sep 27 00:38:06 2017] yup, thanks [Wed Sep 27 00:41:52 2017] at the moment my thinking is that the best approach for strings is to make a module signature whose type has constructors EmptyString and String, and then provide one instantiation for the current string type and then two more, one for utf-8 strings and one for unicode wide strings [Wed Sep 27 00:43:07 2017] except that I'm really not thrilled about those constructor names, either. [Wed Sep 27 00:43:58 2017] and I continue to wonder if maybe it wouldn't be better to just use lists of characters. [Wed Sep 27 00:44:28 2017] and some kind of magic extraction axioms when doing ocaml extractions to get ocaml strings instead of character lists [Wed Sep 27 00:44:48 2017] haskell extractions ought to produce character lists regardless, because that's how haskell works. [Wed Sep 27 00:45:28 2017] suppose I have an equality like 0 = 1 + some irrelevant stuff [Wed Sep 27 00:45:34 2017] hwo do i generate a contradiction from that? [Wed Sep 27 00:45:45 2017] the easiest way is the omega tactic [Wed Sep 27 00:46:07 2017] If it is literally "0 = 1 + ( ... )", inversion will work because it is convertible to "0 = S ..." [Wed Sep 27 00:46:41 2017] don't you need to rewrite the 1 + as S first? [Wed Sep 27 00:46:42 2017] but yeah, omega is more general when you have some contradictory arithmetic facts [Wed Sep 27 00:46:58 2017] No, the way addition is implemented, "1 + ..." and "S ..." are the same thing [Wed Sep 27 00:47:11 2017] I've noticed that it's funny about that in ways I don't always understand [Wed Sep 27 00:47:15 2017] but you do rely on the fact that implementation is implemented that way [Wed Sep 27 00:48:04 2017] Cypi: awesome. [Wed Sep 27 00:48:06 2017] that worked [Wed Sep 27 00:48:08 2017] also, is it expected that omega refuses to solve things like x * y = S (x * y) unless you do "remember (x * y) as foo"? [Wed Sep 27 00:49:07 2017] it works here [Wed Sep 27 00:49:11 2017] I know it doesn't understand multiplication, but I would have expected it to treat x * y as an irreducible blob [Wed Sep 27 00:49:19 2017] it is supposed to treat "x * y" as a variable indeed [Wed Sep 27 00:49:20 2017] it wasn't for some stuff I was doing [Wed Sep 27 00:50:02 2017] e.g. I needed the blef in: rewrite substring_append_second; try (remember (m * length s) as blef; omega) [Wed Sep 27 00:50:28 2017] if you want the full context I can get it [Wed Sep 27 00:50:58 2017] I probably won't be able to say anything else than "I think it is expected" or the contrary, but sure, if it is not much trouble [Wed Sep 27 00:51:02 2017] this was in the middle of proving something about repeat (k: nat) (s: string) which stamps down the string k times [Wed Sep 27 00:51:09 2017] ok moment [Wed Sep 27 00:53:19 2017] the lemma is: [Wed Sep 27 00:53:20 2017] Lemma repeat_substring: [Wed Sep 27 00:53:20 2017] forall m k s, [Wed Sep 27 00:53:20 2017] m < k -> [Wed Sep 27 00:53:20 2017] String.substring (m * String.length s) (String.length s) (repeat k s) = s. [Wed Sep 27 00:53:42 2017] proof is by induction on k [Wed Sep 27 00:54:56 2017] this is in the inductive case, and within that, the S m' case of "destruct m" [Wed Sep 27 00:55:36 2017] after simpl, the goal is: substring (length s + m * length s) (length s) (s ++ repeat k s) = s [Wed Sep 27 00:56:24 2017] substring_append_second is: [Wed Sep 27 00:56:25 2017] Lemma substring_append_second: [Wed Sep 27 00:56:26 2017] forall s1 s2 m n, [Wed Sep 27 00:56:26 2017] m >= String.length s1 -> [Wed Sep 27 00:56:26 2017] String.substring m n (s1 ++ s2)%string = String.substring (m - String.length s1) n s2. [Wed Sep 27 00:56:41 2017] that is, if you take a substring of s1 ++ s2 that's entirely in s2 [Wed Sep 27 00:58:04 2017] the extra bit produced by the rewrite that the try is supposed to retire is: [Wed Sep 27 00:58:05 2017] length s + m * length s >= length s [Wed Sep 27 00:58:30 2017] I guess it doesn't work because length s appears inside m * length s? [Wed Sep 27 00:59:32 2017] I never worked with string, give me a moment to catch up :p [Wed Sep 27 00:59:51 2017] very little of this is in the native string library :-) [Wed Sep 27 01:00:20 2017] (the reason I'm working on this thing is that the native string library has like 3-4 functions and a dozen lemmas) [Wed Sep 27 01:01:21 2017] Alright, I see [Wed Sep 27 01:01:29 2017] indeed, I would expect omega to solve this system [Wed Sep 27 01:01:31 2017] my stringfacts.v is currently at 8838 lines and it hasn't got to anything really complicated yet [Wed Sep 27 01:02:04 2017] ("auto with arith" does solve it, btw) [Wed Sep 27 01:02:42 2017] not sure I knew that existed :-/ [Wed Sep 27 01:03:11 2017] It is just "auto" complemented by a bunch of arithmetic lemmas in the "arith" hint database [Wed Sep 27 01:04:26 2017] I don't know enough about hints databases [Wed Sep 27 01:04:46 2017] Not much to know as long as you don't want to create one and populate it. [Wed Sep 27 01:07:05 2017] It is so strange... it can solve "x + x*y >= x*y", but not "x*y + x*y >= x*y" and not "x + x*y >= x" [Wed Sep 27 01:08:09 2017] that's weird, particularly x*y + x*y >= x*y [Wed Sep 27 01:11:53 2017] that reminds me, I really need to get around to filing a proper bug report on the problem I found with congruence [Wed Sep 27 01:14:00 2017] (last spring I stepped on a way to get it to generate a bad proof term) [Wed Sep 27 01:16:57 2017] anyway, thanks for looking at it, glad it wasn't just my imagination [Wed Sep 27 11:10:00 2017] not totally related to coq, but is it possible to have 2 proof general "contexts" running at the same time in emacs? one for each coq script that is [Wed Sep 27 11:24:27 2017] Also another question. Suppose I want to search for all things involving "In". How would I do that? I can do Search "In". but that returns a lot of irrelevant stuff [Wed Sep 27 11:25:24 2017] rgrinberg: Search In. [Wed Sep 27 11:26:16 2017] rgrinberg: in general you can do [Search foo] where foo is an expression, not just something in quotes [Wed Sep 27 11:26:28 2017] or SearchAbout if you want anything that mentions it, not just using it in the conclusion or whatever [Wed Sep 27 11:26:56 2017] thanks. so Search only searches for things in the last argument? [Wed Sep 27 11:27:10 2017] is that what you mean by "in the conclusion"? [Wed Sep 27 11:34:07 2017] rgrinberg: You can only have one proof general context going at a time. It is an unfortunate limitation. It's caused by the use of global variables for things that should be context specific. [Wed Sep 27 11:34:17 2017] Hopefully someone will fix that in the future. [Wed Sep 27 11:43:06 2017] pmetzger: i see... damn emacs [Wed Sep 27 11:44:55 2017] I believe Paul Steckler was talking about fixing this. He has a new version of Proof General that also handles the parallelism stuff that CoqIDE does now. [Wed Sep 27 11:47:28 2017] I don't quite get the difference between contradict and contradiction? any rule of thumb for how to decide which one to use? [Wed Sep 27 11:47:37 2017] I actually, i'm not even sure how to use contradiction effectively at all [Wed Sep 27 12:22:06 2017] is there a way to do a qualified import of a single symbol from a module in coq? [Wed Sep 27 12:28:32 2017] rgrinberg: i cant remember what the specific behavior of search vs searchabout is, but yes i believe its basically to do with the return type [Wed Sep 27 12:28:37 2017] not "final argument" :p [Wed Sep 27 12:29:34 2017] rgrinberg: You can make another module that only exports that one symbol, and then import that module. But there's no easy Haskell-like way to do it. [Wed Sep 27 12:29:42 2017] rgrinberg: btw, here's a fun fact regarding Search: https://i.imgur.com/XqEmu19.png [Wed Sep 27 12:30:08 2017] if you pass it something to search for, it really does search for that term, not just the exact string - those two types are convertible, since it's just a variable rename, so it finds it :) [Wed Sep 27 12:30:13 2017] johnw: i see, thanks. very ocaml-like [Wed Sep 27 12:30:45 2017] that said, it doesnt do, like, actual computation for the searches - [Search (1 + 1)] won't find stuff that [Search 2] does - but it's not that dumb either [Wed Sep 27 12:30:59 2017] benzrf: yeah searching is clever. though i'm not comfortable with it yet. for example, how do the ?p patterns works [Wed Sep 27 12:31:07 2017] oh shit can you use those with search? [Wed Sep 27 12:31:10 2017] i didn't know that :D [Wed Sep 27 12:31:34 2017] hmm, what have you seen that uses that? [Wed Sep 27 12:39:59 2017] i forgot but I'm somewhat able to make use of it with things like [Wed Sep 27 12:40:05 2017] Search In ?x []. for example [Wed Sep 27 12:41:05 2017] o.O [Wed Sep 27 13:05:14 2017] do coq scripts need to start with a capital letter to be importable? [Wed Sep 27 13:05:31 2017] You mean, the filename? No [Wed Sep 27 13:07:06 2017] okay. can the filename contain numbers? [Wed Sep 27 13:07:09 2017] digits rather [Wed Sep 27 13:07:29 2017] yes [Wed Sep 27 13:08:25 2017] (not in front, though) [Wed Sep 27 13:08:37 2017] (the whole thing needs to be a valid Module name, basically) [Wed Sep 27 13:17:06 2017] by default, I'm allows to import modules from my current dir, right? [Wed Sep 27 13:17:43 2017] If they have been compiled previously, yes, you should be able to. [Wed Sep 27 13:18:06 2017] and if they haven't? [Wed Sep 27 13:18:39 2017] Well, then no [Wed Sep 27 13:19:06 2017] If you have a directory with ./Foo.v and ./Bar.v, you need to do "coqc Foo.v" in this directory to be able to do "Require Import Foo." inside Bar.v [Wed Sep 27 13:19:42 2017] Require looks for compiled files, not source files [Wed Sep 27 13:21:10 2017] I see.. so I should probably start messing around with makefiles so that I can recompile things easily [Wed Sep 27 13:22:12 2017] You could look at coq_makefile. In its simplest form, you just need a file (usually called _CoqProject) which contains the list of .v files in your project (one file per line, I believe) [Wed Sep 27 13:22:29 2017] then you can call "coq_makefile -f _CoqProject -o Makefile" once to generate a Makefile [Wed Sep 27 13:22:58 2017] (of course you can also write your own, it's up to you) [Wed Sep 27 15:09:59 2017] Cypi: thanks. I'll look into that. [Wed Sep 27 15:10:27 2017] Suppose I have an expression like (fun x => ...) a in my goal, how do I simply apply this lambda to a? [Wed Sep 27 15:10:54 2017] Just "simpl" should work, it's just a beta-reduction [Wed Sep 27 15:10:58 2017] (unless I misunderstood) [Wed Sep 27 15:13:19 2017] yeah, i tried simpl. it didn't work... [Wed Sep 27 15:13:43 2017] Then I'd lire more details :) [Wed Sep 27 15:13:45 2017] like* [Wed Sep 27 15:14:06 2017] it's in your goal, right, not in your context? [Wed Sep 27 15:14:33 2017] yup. [Wed Sep 27 15:19:28 2017] Could you copy/paste your goal or something, if it's not too long? [Wed Sep 27 15:23:08 2017] or put it on pastebin [Wed Sep 27 15:42:47 2017] contents al v = multiset_delete (fun x0 : value => (if x0 =? v then 1 else 0) + contents al x0) v v [Wed Sep 27 15:42:50 2017] here it is Cypi [Wed Sep 27 15:44:18 2017] Ah, well, the lambda is not applied to anything in this case [Wed Sep 27 15:44:25 2017] since it is just an argument to "multiset_delete" [Wed Sep 27 15:44:50 2017] if you unfold multiset_delete, maybe at some point the lambda will be applied to something and you can unfold it [Wed Sep 27 15:57:25 2017] ah i see. oops [Wed Sep 27 15:58:54 2017] how do I simplify a clause like if v =? v then ...? [Wed Sep 27 15:58:58 2017] since it's clearly true [Wed Sep 27 15:59:53 2017] rgrinberg: it depends on what =? is [Wed Sep 27 16:00:03 2017] There is probably a lemma which says "forall v, v =? v = true" [Wed Sep 27 16:00:08 2017] you can rewrite with this lemma [Wed Sep 27 16:00:36 2017] Nat.eqb [Wed Sep 27 16:00:45 2017] rgrinberg: keep in mind that from coq's point of view, =? is just a function like any other - [v =? v = true] is no more obvious than, say, [n + n = 2 * n] [Wed Sep 27 16:01:02 2017] so you do need a specific proof of the reflexivity of the function [Wed Sep 27 16:01:29 2017] rewriting with Nat.eqb_refl seems to work [Wed Sep 27 20:02:32 2017] "No more subgoals." [Wed Sep 27 20:02:37 2017] isn't that the best feeling ever? :p [Wed Sep 27 20:04:31 2017] sorry, just finished a theorem with 18 cases, sub-cases and sub-sub-cases and I'm pretty happy that that's over now [Wed Sep 27 20:06:54 2017] it's a good feeling, at least when Qed doesn't fail ;-) [Wed Sep 27 20:07:28 2017] Qed can fail? [Wed Sep 27 20:13:16 2017] It can. The most normal case is when you used a fixpoint, and the recursive call was not correct [Wed Sep 27 20:13:30 2017] but sometimes tactics can produce ill-typed terms, which will then make Qed fail [Wed Sep 27 20:13:51 2017] (the whole term is type-checked again at Qed) [Wed Sep 27 20:15:52 2017] fortunately this doesn't happen often. [Wed Sep 27 21:03:42 2017] I'm a noob with coq and I manage to prove stuff but my proofs end up being very long and unreadable and writing them feels like playing tetris with tactics rather than reasoning through things :/ [Wed Sep 27 21:04:37 2017] Does this problem solve itself? Or do I need to start making more of an effort writing and understanding my proofs [Wed Sep 27 21:09:42 2017] there are ways to structure proofs, like tacticals. that said the tetris feeling probably doesn't ever go away entirely, but it is reasoning of a sort. [Wed Sep 27 21:14:26 2017] what do people do without tactics though? do they write proper, clear programs and understand their proofs entirely? [Wed Sep 27 21:14:34 2017] or is there still some tetris there? [Wed Sep 27 21:16:13 2017] well, tactics are not absolutely necessary for proofs but it's the reasonable way of doing it, but i was asking about tacticals, things like the ";" and such. [Wed Sep 27 21:16:29 2017] which can help give structure to the proof and automate repetitive bits. [Wed Sep 27 21:19:10 2017] modulus: i know how to use ";". not really any other tacticals [Thu Sep 28 00:22:52 2017] I was wondering if someone could help me along with this proof: http://paste.ubuntu.com/25631247/ [Thu Sep 28 00:23:13 2017] Obviously the claim is absurd, but I can't seem to figure out how to prove that the claim is absurd (i.e. lf = x :: lf). [Thu Sep 28 00:57:59 2017] This channel is so dead :( [Thu Sep 28 03:15:39 2017] rgrinberg: I just started with coq, but I usually reason to what should be inverted / inducted / destroyed, and then it is tactics tetris [Thu Sep 28 08:20:38 2017] hi. I'm getting stuck on something really basic. Say I have a hypothesis in the context that has an implication in it, say Hyp: A -> B, and I can prove my goal if I had a proof of B. What I can do is write assert (proof_of_A: A). Then I prove that new subgoal, then I pose (proof_of_B := Hyp proof_of_A). [Thu Sep 28 08:21:10 2017] that works, but isn't there a faster way? In particular, writing the "assert (proof_of_A: A)" can be pretty cumbersome if A is a big statement [Thu Sep 28 08:21:43 2017] I think apply [Thu Sep 28 08:22:07 2017] nm, ij ust woke and i'm not making sense. [Thu Sep 28 08:24:47 2017] I seem to remember using "destruct Hyp", but that's not working now, as it gives the error: Not an inductive product. [Thu Sep 28 08:29:39 2017] "apply Hyp" is what you want, indeed [Thu Sep 28 08:30:05 2017] Oh, sorry, you meant that you want a proof of B to then prove your goal, alright [Thu Sep 28 08:30:46 2017] a way to do it could be "refine ((fun H => _) (Hyp _))." [Thu Sep 28 08:31:02 2017] a bit manual, but it should do what you want (not repeating A and so on) [Thu Sep 28 08:41:28 2017] Cypi: yeah that works great, thanks. But I'm surprised that this is not a common enough occurrence to have its own shorthand tactic. You have to admit that "refine ((fun H => _) (Hyp _))." is pretty obscure [Thu Sep 28 08:44:50 2017] What you'd want is something like "especialize (Hyp _)", I am not sure why it doesn't exist [Thu Sep 28 09:30:34 2017] Cypi: I'm trying to write my own tactic to that effect using Ltac. It's going pretty well, but is there a way to switch the order of the subgoals generated by that "refine ((fun H => _) (Hyp _))."? [Thu Sep 28 09:31:10 2017] yup, "tac; swap 1 2" will swap the first and second subgoals generated by a tac [Thu Sep 28 09:33:43 2017] sweet. thanks. [Thu Sep 28 11:21:47 2017] jrw: are you the author of https://homes.cs.washington.edu/~jrw12/dep-destruct.html ? [Thu Sep 28 13:12:59 2017] rgrinberg: yes [Thu Sep 28 13:38:48 2017] jrw: i enjoyed it, thanks for writing it. I'm curious though, why do we need fin at all? can't we just work directly with nat to establish cardinalities [Thu Sep 28 13:41:13 2017] rgrinberg: you can replace fin n with {k : nat | k < n}, if that's what you mean [Thu Sep 28 13:41:34 2017] jrw: yeah [Thu Sep 28 13:42:27 2017] one way to think of that post is just as a tutorial on some aspects of dependent pattern matching. the applications to fin may or may not be interesting in their own right, but they are useful as a simple example of dependency. [Thu Sep 28 15:03:58 2017] jrw: yeah, I get it. Thanks :) [Thu Sep 28 15:04:41 2017] suppose I have a binding with 2 definitions. E.g. one : nat and one as a variable. is there a way to disambiguate them? [Thu Sep 28 15:07:32 2017] Actually, the other "one" in my case is a generalizable variable [Thu Sep 28 17:55:39 2017] that link was an interesting read, thanks [Thu Sep 28 18:35:26 2017] is it possible to remove imported identifiers in coq? [Thu Sep 28 18:35:31 2017] kinda like with Reset? [Fri Sep 29 10:41:26 2017] question regarding extraction to haskell. Is there a way to include a module import in the extracted file [Fri Sep 29 12:35:43 2017] if you have as goal "let (a,b) := something in something_else", is it possible to bring those a and b into the context, like what intro does with implication? [Fri Sep 29 13:15:38 2017] I think you need to destruct something. [Sat Sep 30 09:44:38 2017] Do we know that it is impossible to prove systemF/CC strong normalization without impredicativity? [Sat Sep 30 11:19:09 2017] what is eqn:? at the end of a destruct? e.g. destruct H ... eqn:?. [Sat Sep 30 11:26:10 2017] rgrinberg, usually when you destruct some expression, that expression will in each subgoal be replaced with the respective case of whatever type that expression was. [Sat Sep 30 11:26:59 2017] but sometimes you want to keep the original expression around, which you can indicate with eqn:somename [Sat Sep 30 11:27:53 2017] ah, i'm aware of that form. the way I've seen it is using something like eqn:HH. [Sat Sep 30 11:28:12 2017] oh wait, you mean a literal question mark? [Sat Sep 30 11:28:14 2017] But here I don't see the new assumption under the name "?" anywhere [Sat Sep 30 11:28:17 2017] yes [Sat Sep 30 11:28:20 2017] sorry [Sat Sep 30 11:28:52 2017] rrika: to convince you i haven't made this up, look for eqn:? here: https://softwarefoundations.cis.upenn.edu/current/vfa-current/Decide.html [Sat Sep 30 11:28:54 2017] :) [Sat Sep 30 11:29:02 2017] it just picks a random name [Sat Sep 30 11:29:20 2017] just induction generates "IH" [Sat Sep 30 11:29:21 2017] oh [Sat Sep 30 11:29:26 2017] ok I see. [Sat Sep 30 11:29:27 2017] *just like [Sat Sep 30 18:06:36 2017] if I have as goal "let (a,b) := something in something_else", is it possible to move these (a,b) into the context, like what "intros" does? [Sat Sep 30 18:06:44 2017] or how do you usually deal with these kinds of goals? [Sat Sep 30 18:06:59 2017] I asked this question yesterday as well but I had to go before anyone could answer [Sat Sep 30 18:07:15 2017] still stuck on it though [Sat Sep 30 18:07:46 2017] "Migi32: destruct something as (a,b)" ? [Sat Sep 30 18:08:45 2017] err "destruct something as [a b]" i mean [Sat Sep 30 18:10:51 2017] well that just deletes the whole "let (a,b) := something in " part, without putting the definition of (a,b) in the context [Sat Sep 30 18:29:50 2017] Migi32: oh, "destruct something as [a b] eqn: Hab" then? [Sat Sep 30 18:30:39 2017] aj: yes! Thanks you. [Sat Sep 30 18:30:41 2017] finally :p [Sat Sep 30 18:32:21 2017] Migi32: :) [Sat Sep 30 23:54:23 2017] Hey, hello! I'm new around here, could anyone give me a hand? (any Portuguese speaker, by the way?) [Sat Sep 30 23:55:32 2017] hop3: hi, probably! [Sat Sep 30 23:55:38 2017] personally though im pretty tired, its midnight where i am [Sat Sep 30 23:56:52 2017] Oh, it's 1 am here, haha [Sat Sep 30 23:58:57 2017] ok, so, i'm trying to complete a proof of the correctness of bubblesort, but I don't know if I've built things up the right way [Sun Oct 1 00:00:14 2017] https://codeshare.io/Gknqe3 [Sun Oct 1 00:02:28 2017] I know coq has a "Sorted" library, but as I'm new to it, I don't really understand how to construct a Lemma using LocallySorted, so I built my own [Sun Oct 1 01:18:29 2017] my browser doesn't like your pastebin, so maybe if you ask a more specific question... [Sun Oct 1 03:26:35 2017] hop3, your code actually describes insertion sort, not bubblesort [Sun Oct 1 03:28:46 2017] The "sorted" prop looks fine. [Sun Oct 1 10:36:06 2017] oh, thanks, rrika, I thought about that, but I searched for other implementations and they were all the same, haha... [Sun Oct 1 10:36:18 2017] lol [Sun Oct 1 10:43:33 2017] maybe the correct way to do it must considerate reducing the length of the list in the recursion function, because you don't need to compare until the end... but this is just an optimization, right? [Sun Oct 1 10:44:06 2017] you have two recursive functions, the inner one is good already [Sun Oct 1 10:45:05 2017] hmmm [Sun Oct 1 10:58:33 2017] by "recursion function" I meant the outer one, lol, sorry... so, what's the idea of the outer one? I'm out of ideas, lol [Sun Oct 1 11:01:12 2017] apply bubble to the entire list, in every iteration of bubblesort [Sun Oct 1 11:01:24 2017] while counting down from the length of the list to zero [Sun Oct 1 11:02:33 2017] Fixpoint bubblesort (n: nat) (l : list nat) : list nat := [Sun Oct 1 11:02:33 2017] match n with. [Sun Oct 1 11:02:33 2017] | 0 => l [Sun Oct 1 11:02:33 2017] | S n => bubblesort n (bubble l) [Sun Oct 1 11:02:34 2017] end. [Sun Oct 1 11:03:53 2017] I imagine the proof for that is going to be hard though [Sun Oct 1 11:07:09 2017] More and more elements in the back of the list will correspond to the sorted version [Sun Oct 1 11:27:00 2017] I see, awesome! thank, rrika! <3 [Sun Oct 1 11:28:58 2017] now I'm going to try proving this: Lemma bubble_preserves_order : forall n l, sorted l -> sorted (bubble n l). [Sun Oct 1 11:47:37 2017] good luck! [Sun Oct 1 15:28:25 2017] hey, can anyone give me another hand? [Sun Oct 1 16:47:41 2017] hop3: codeshare is over capacity, it doesn't let me see what you posted [Sun Oct 1 16:48:21 2017] nvm it works now [Sun Oct 1 16:48:27 2017] I'll give it a shot [Sun Oct 1 16:49:46 2017] thanks Migi32, but I changed it a little bit [Sun Oct 1 16:49:58 2017] just a sec [Sun Oct 1 16:54:21 2017] https://gist.github.com/anonymous/6b15c4640d9558791af3a8ba6283d44a [Sun Oct 1 16:56:13 2017] I'm getting stuck at some points in this last Lemma proof [Sun Oct 1 17:02:25 2017] hop3, do you do induction on H? [Sun Oct 1 17:07:25 2017] I actually do induction on l [Sun Oct 1 17:11:19 2017] your sorted inductive isn't good enough [Sun Oct 1 17:14:14 2017] hmmm, maybe I need the strong version of sorted? the one I use is the "locallysorted", just like in the Sorted library [Sun Oct 1 17:23:22 2017] hm [Sun Oct 1 17:23:24 2017] maybe I'm wrong [Sun Oct 1 17:23:48 2017] oh [Sun Oct 1 17:23:51 2017] yeah, I'm wrong. n/m [Sun Oct 1 17:26:34 2017] what a relief, haha... [Sun Oct 1 17:27:06 2017] what's the first argument of bubblesort for? [Sun Oct 1 17:28:46 2017] I think things will be a bit easier if bubble takes only one list and splits off the head itself. [Sun Oct 1 17:30:21 2017] oh, I see, it's recursive gas [Sun Oct 1 17:30:35 2017] you ought to be able to do this without recursive gas [Sun Oct 1 17:30:49 2017] dh`, it was me who suggested doing that ^^; [Sun Oct 1 17:31:19 2017] dh`, what would you use as decreasing argument then? [Sun Oct 1 17:31:38 2017] my original idea was to create an outer recursion like the insertion one [Sun Oct 1 17:41:57 2017] I tried to do it this way: https://gist.github.com/anonymous/ead887153716682ab78cf152b094fcfe [Sun Oct 1 17:42:42 2017] but he won't allow the bubble, "Recursive call to bubble has principal argument equal to "h' :: tl" instead of one of the following variables: "l0" "tl"." [Sun Oct 1 17:42:49 2017] the list itself should be sufficient [Sun Oct 1 17:42:50 2017] I think [Sun Oct 1 17:43:14 2017] oh [Sun Oct 1 17:43:16 2017] you're correct [Sun Oct 1 17:43:18 2017] lol [Sun Oct 1 17:43:39 2017] yeap, lol [Sun Oct 1 17:43:41 2017] my bad [Sun Oct 1 17:44:10 2017] oh, but there's a problem [Sun Oct 1 17:45:22 2017] I think this won't do, we lose information [Sun Oct 1 18:48:59 2017] hint: it's much easier to induct on sorted than on the list [Sun Oct 1 19:00:44 2017] although you can do it both ways. [Sun Oct 1 19:01:50 2017] although what I have is technically insertion sort [Sun Oct 1 19:02:16 2017] not sure offhand if there's a different notion of bubblesort for cons-lists [Sun Oct 1 19:08:51 2017] dh`: perhaps something with zippers [Sun Oct 1 19:19:30 2017] hop3: here's a proof of bubble_preserves_order: https://gist.github.com/Migi/924d400a7ffdb7c357f23b0a25f77e53 [Sun Oct 1 19:20:56 2017] the names are pretty bad and nondescriptive, and it's probably possible to do this all in a much shorter and cleaner proof, but I wrote it pretty quickly [Sun Oct 1 19:22:05 2017] oh and also the lemmas sorted_replace_front and bubble_head_is_ge2 aren't actually used, but I just left them in, maybe they can be useful [Sun Oct 1 19:29:14 2017] I was thinking maybe bubble should extract the smallest element out to the front, then recurse on the tail [Sun Oct 1 19:29:26 2017] but this becomes really regrettable really quickly, and I need to go [Sun Oct 1 19:30:59 2017] here's my full solution with insertion sort, which is relatively tidy: [Sun Oct 1 19:31:01 2017] http://codepad.org/PWFPZzY4 [Sun Oct 1 19:33:16 2017] yeah that's *much* cleaner than my solution [Sun Oct 1 19:34:36 2017] looks pretty [Sun Oct 1 20:20:45 2017] is there a way to make C-C C-n in proof general stop jumping lines? [Sun Oct 1 20:20:57 2017] I want to write a few tactics in 1 line and it's annoying to have to jump back [Sun Oct 1 21:05:06 2017] Suppose I have sorted (x :: y :: l), how can I prove sorted (x :: l)? [Sun Oct 1 21:13:02 2017] transitivity of <= [Sun Oct 1 21:13:33 2017] destruct l so you get x :: y :: a :: l', then you get x <= y, y <= a, so x <= a [Sun Oct 1 21:13:44 2017] (plus a trivial case) [Sun Oct 1 21:23:12 2017] Is there a command to print the proof of a theorem, given the theorem's name? [Sun Oct 1 21:44:22 2017] Print [Sun Oct 1 21:44:34 2017] well hmm, no, that prints the proof term [Sun Oct 1 21:44:45 2017] I think to get the tactic-language proof you need to UTSL [Sun Oct 1 21:45:16 2017] my question for the moment: is there a tactic that extracts everything congruence could prove and subst's it all? [Sun Oct 1 21:45:45 2017] this alternate bubble sort is full of really tedious a :: b :: c :: d = a' :: c' :: b' :: d' cases [Sun Oct 1 21:49:46 2017] UTSL? [Sun Oct 1 21:49:56 2017] use the source luke [Sun Oct 1 21:50:04 2017] Ah :P [Sun Oct 1 21:50:08 2017] Bummer [Sun Oct 1 21:50:19 2017] yeah [Sun Oct 1 21:51:10 2017] this may be mistaken, but - my impression is that trying to find out the tactic proof of a theorem is like trying to find out the expression that generated a number [Sun Oct 1 21:52:39 2017] Is that bad or something? [Sun Oct 1 21:53:27 2017] I'm also having a bit of trouble understanding iffs that also involve implications, like in this exercise: http://lpaste.net/358880 [Sun Oct 1 21:53:33 2017] no i just mean that it's not part of the resulting data [Sun Oct 1 21:53:48 2017] So in the lemma there's an implication prior to the iff and I find it difficult to even parse. [Sun Oct 1 21:53:59 2017] that's clearly true, after all a possible proof script would be exact [Sun Oct 1 21:54:04 2017] benzrf: Ah, right. I'd just like to look for didactic reasons. [Sun Oct 1 21:54:15 2017] right before you Qed though you can print the script if you want. [Sun Oct 1 21:54:21 2017] yeah i didnt mean to imply that wasnt legit :V [Sun Oct 1 21:54:24 2017] or in mid-proof. [Sun Oct 1 21:54:58 2017] Print the script? [Sun Oct 1 21:55:10 2017] the tactics. [Sun Oct 1 21:55:13 2017] buttbutter: "script" = "proof script" = "tactic code used to prove" [Sun Oct 1 21:55:14 2017] if you use Show Script. [Sun Oct 1 21:55:17 2017] in proof mode [Sun Oct 1 21:55:23 2017] Oh. Let me try. [Sun Oct 1 21:55:25 2017] buttbutter: what are u having trouble with in the example [Sun Oct 1 21:56:09 2017] I don't even understand the proposition. [Sun Oct 1 21:56:28 2017] " (∀ a1 a2, beq a1 a2 = true ↔ a1 = a2) → [Sun Oct 1 21:56:37 2017] That bit, prior to the iff, is confusing to me. [Sun Oct 1 21:56:50 2017] Sorry if I'm not being explicit. I don't understand it so it's difficult :) [Sun Oct 1 21:56:56 2017] its cool! [Sun Oct 1 21:57:03 2017] it's saying that this beq function correctly decides whether two things are equal [Sun Oct 1 21:57:14 2017] Oh, right. Of course. [Sun Oct 1 21:57:19 2017] :) [Sun Oct 1 21:57:22 2017] So it's just an assumption on the properties of beq. [Sun Oct 1 21:57:25 2017] right [Sun Oct 1 21:57:53 2017] And it's an implication because that beq is then being used in the subsequent term with beq_list beq l_1 l_2. [Sun Oct 1 21:58:43 2017] Thanks for the help. now i gotta prove it :D [Sun Oct 1 22:36:16 2017] oh, thank you guys, Migi32, dh` and rrika, I'll check it out [Sun Oct 1 22:45:03 2017] dh`: when i destruct on l, i don't get a <= equation in my assumptions, what gives? [Sun Oct 1 22:49:13 2017] rgrinberg: destructing l won't give you that [Sun Oct 1 22:50:09 2017] you have to destruct the leb comparison inside the function to get it [Sun Oct 1 22:52:27 2017] hop3: how do i destruct the leb comparison? [Sun Oct 1 22:53:27 2017] are you trying to do the same bubblesort proof I posted earlier? [Sun Oct 1 22:53:34 2017] you need something like "destruct (x <=? y) eqn:H" [Sun Oct 1 22:54:02 2017] exactly, do a "simpl", "simpl bubble" or "unfold bubble" to see it better [Sun Oct 1 22:54:13 2017] that will give you H: x <=? y = true, which you can then convert to x <= y via PeanoNat.Nat.leb_le [Sun Oct 1 22:54:48 2017] or, for the other case, PeanoNat.Nat.leb_gt [Sun Oct 1 22:54:51 2017] nope, i'm not trying to do anything with bubble sort or insert. [Sun Oct 1 22:55:04 2017] oh, sorry then [Sun Oct 1 22:55:27 2017] but it's just like what dh` said [Sun Oct 1 22:55:32 2017] what *are* you doing? :-) [Sun Oct 1 22:55:54 2017] * searches history for context, and fails [Sun Oct 1 22:56:05 2017] just what I said I think. prove that removing the second element in a sorted list maintains sortnedness [Sun Oct 1 22:56:08 2017] ll [Sun Oct 1 22:56:31 2017] oh, there we go [Sun Oct 1 22:56:40 2017] well [Sun Oct 1 22:56:57 2017] what I meant was: you start with sorted (x :: y :: l) [Sun Oct 1 22:57:06 2017] in order to reason about this you need the head of l [Sun Oct 1 22:57:11 2017] so the first step is to destruct l. [Sun Oct 1 22:57:19 2017] that gives you one case with (x :: y :: a :: l0) [Sun Oct 1 22:57:30 2017] and another case with (x :: y :: []) [Sun Oct 1 22:57:40 2017] the second case is easy [Sun Oct 1 22:57:50 2017] yup [Sun Oct 1 22:57:51 2017] since x :: [] is always sorted [Sun Oct 1 22:58:16 2017] for the first case you then need to mess with the definition of sorted to get x <= y, y <= a [Sun Oct 1 22:58:37 2017] inversion on the hypothesis that says it's sorted is the basic way to do that. [Sun Oct 1 22:58:57 2017] or if you're using the library's notion of sorted there are some lemmas [Sun Oct 1 23:00:25 2017] if you're using the sorted inductive that's been pasted tonight, then you might want to prove both "forall x xs: sorted (x :: xs) -> sorted xs" and "forall x y xs, sorted (x :: y :: xs) -> x <= y [Sun Oct 1 23:00:32 2017] " [Sun Oct 1 23:00:40 2017] (as separate lemmas) [Sun Oct 1 23:01:10 2017] you can almost always prove such bits inline, but it can get hairy and require bullets six deep and such [Sun Oct 1 23:01:27 2017] and occasionally it doesn't work. [Sun Oct 1 23:01:27 2017] Thanks. Yeah, I'm getting lost after doing the inversion. context is looking messy [Sun Oct 1 23:01:37 2017] always do subst after inversion [Sun Oct 1 23:01:42 2017] inversion makes a huge mess. [Sun Oct 1 23:02:09 2017] in many contexts it's also worth just robotically typing "inversion; subst; try discriminate; try contradiction" [Sun Oct 1 23:02:56 2017] anyway, I have the other bubble sort done [Sun Oct 1 23:04:39 2017] oh, cool! [Sun Oct 1 23:05:12 2017] did you go with induction on sorted? [Sun Oct 1 23:08:29 2017] this one requires functional induction [Sun Oct 1 23:16:19 2017] is there no Nat.le_le_trans? [Sun Oct 1 23:50:39 2017] dh`: functional induction? what's that [Mon Oct 2 02:09:30 2017] yay, I think I did it [Mon Oct 2 02:16:50 2017] I don't know too much about advanced tactics yet, so probably my proofs could be optimized [Mon Oct 2 02:16:56 2017] https://gist.github.com/anonymous/00548dbd3e719120888852c3ed83db29 [Mon Oct 2 02:17:37 2017] and I'm still not sure if it's bubblesort indeed, lol [Mon Oct 2 03:13:09 2017] rgrinberg: if you have Function foo ... := code (instead of Fixpoint) [Mon Oct 2 03:13:45 2017] it generates a bunch of additional doodads, one of which is the ability to do "functional induction (foo args)" and induct over the matching cases in the function. [Mon Oct 2 03:14:56 2017] this version of bubblesort is definitely from hell: [Mon Oct 2 03:14:58 2017] http://codepad.org/OBfRB7fy [Mon Oct 2 03:15:29 2017] I have been working the past six hours on it and I can't get it to go [Mon Oct 2 03:16:58 2017] What are you trying to prove on this? Correctness? [Mon Oct 2 03:19:22 2017] yeah [Mon Oct 2 03:19:47 2017] basically I nerdsniped myself by mumbling about whether insertion sort is really bubble sort [Mon Oct 2 03:19:58 2017] so I made a second version and then a third version [Mon Oct 2 03:20:14 2017] First of all, you should probably use "Defined" instead of "Qed" in the code you pasted, just so that you can compute with your definition [Mon Oct 2 03:20:26 2017] Then...I don't know yet, I'm looking at it! [Mon Oct 2 03:20:31 2017] which one? [Mon Oct 2 03:20:51 2017] oh, with the Function? oops [Mon Oct 2 03:21:10 2017] no wonder it was making me use rewrite twiddle_equation instead [Mon Oct 2 03:22:20 2017] I made a definition partlysorted: [Mon Oct 2 03:22:20 2017] Definition partlysorted (k: nat) (xs: list nat) := [Mon Oct 2 03:22:20 2017] sorted (chop k xs). [Mon Oct 2 03:22:25 2017] In some cases you'll still need to use the equation, but at least it'll compute on a closed term [Mon Oct 2 03:22:30 2017] where chop k xs removes the first k elements of xs [Mon Oct 2 03:22:55 2017] Yup, I have a similar definition, but I wrote it as an inductive one [Mon Oct 2 03:23:10 2017] so I tried to prove [Mon Oct 2 03:23:11 2017] Lemma twiddle_sorts: [Mon Oct 2 03:23:11 2017] forall k xs, [Mon Oct 2 03:23:11 2017] partlysorted (S k) xs -> [Mon Oct 2 03:23:13 2017] partlysorted k (twiddle xs). [Mon Oct 2 03:23:16 2017] and that just won't go [Mon Oct 2 03:23:23 2017] [I'm trying to adapt my code about the bubble sort that was pasted yesterday) [Mon Oct 2 03:23:41 2017] probably making partlysorted an inductive would help, I thought about that [Mon Oct 2 03:24:30 2017] I don't know, it just felt more natural [Mon Oct 2 03:26:28 2017] it didn't to me, but maybe I was not thinking of it in the most productive way [Mon Oct 2 03:26:38 2017] anyhow I need to stop this, it's 3:30am and I need to make dinner [Mon Oct 2 03:37:31 2017] dh` : alright, with minor modifications my proof still went through. [Mon Oct 2 03:37:49 2017] 1) In case you didn't, using twiddle_ind helps [Mon Oct 2 03:38:16 2017] 2) I don't know if it's necessary, but I used some easy lemmas about Permutation and Forall [Mon Oct 2 03:38:58 2017] (mainly, that the result of twiddle is a Permutation of its input, that the head of a sorted list is smaller than the rest of the list, and that a Permutation preserved a Forall) [Mon Oct 2 03:39:16 2017] each lemma has a proof of 4-5 lines, but it's still useful [Mon Oct 2 03:40:03 2017] my guess is that the inductive "partlysorted" helped: I just had to do some inversions on it to get all the essential information I needed from it [Mon Oct 2 04:07:07 2017] curious [Mon Oct 2 04:07:15 2017] mine was terrible in all respects [Mon Oct 2 04:07:50 2017] maybe I'll try making an inductive partlysorted [Mon Oct 2 04:10:23 2017] If it helps, I defined it as something like this: Inductive sorted_from : nat -> list nat -> Prop := | SF_O : forall l, sorted l -> sorted_from O l | SF_S : forall h l n, sorted_from n l -> sorted_from (S n) (h :: l). [Mon Oct 2 04:10:30 2017] (name is different, but it's the same idea) [Mon Oct 2 04:24:18 2017] that doesn't actually make it sorted...? [Mon Oct 2 04:24:58 2017] oh, I see [Mon Oct 2 04:25:03 2017] It makes it sorted starting from the n-th element. Same idea as your partlysorted [Mon Oct 2 04:28:00 2017] anyway I need to sleep [Mon Oct 2 12:06:11 2017] hi! [Mon Oct 2 12:06:25 2017] so i decided to have a go playing around with some basic smooth infinitesimal analysis in coq [Mon Oct 2 12:07:10 2017] i just got finished proving that equality on the real line cannot be decidable, and the proof was pretty long - would anyone be willing to have a look & see if i missed any nice ways of making it shorter? [Mon Oct 2 12:07:12 2017] https://gist.github.com/4a883cb5493e306ac391434b6fb246ad [Mon Oct 2 12:07:44 2017] im busy rn so i cant stick around to talk about it, but if you have any feedback please feel free to comment on the gist or post it in the channel - i'll read logs when i get back! [Mon Oct 2 12:27:39 2017] benzrf : fwiw, it looks good to me. [Mon Oct 2 12:31:10 2017] dh`: thanks [Mon Oct 2 13:42:40 2017] is there a way to to pattern match on a tuple in a lambda in coq? [Mon Oct 2 13:42:46 2017] E.g. something like fun (x, y) => [Mon Oct 2 13:50:35 2017] There is some sugar for it, yes: "fun '(x, y) => ..." [Mon Oct 2 13:51:12 2017] (only from 8.6 though) [Mon Oct 2 13:54:44 2017] Cypi: ok thanks :) [Mon Oct 2 13:55:03 2017] Also what's the difference between {| |} and { } when defining class instances. I see both forms being used. [Mon Oct 2 15:47:50 2017] Cypi: i managed to make it a bit nicer though :) https://gist.github.com/8198ed2e47b82727efafdcc99519d8dc [Mon Oct 2 15:50:13 2017] I mean, yeah, you've basically cut out a part of it in another lemma :p [Mon Oct 2 15:50:43 2017] (another lemma which has an interest in itself it seems, so that's good, of course) [Mon Oct 2 16:50:50 2017] hi [Mon Oct 2 16:51:05 2017] what is the difference between Set and Type, in Coq? is the answer supplied here correct? https://cs.stackexchange.com/a/80737 [Mon Oct 2 18:57:18 2017] mietek: not really. Type is a rammified hierarchy (like Set in Agda), and Set is exactly identical to the first universe in that hierarchy [Mon Oct 2 18:57:38 2017] wrengr: I see, thanks. [Mon Oct 2 18:58:32 2017] The textual token "Type" can refer to any (Type n). They use level inference to figure out what n should be. Whereas the textual token "Set" is always resolved to be (Type 0) [Mon Oct 2 18:58:43 2017] (or Type 1, if you prefer 1-based indexing) [Mon Oct 2 18:59:07 2017] can you read Type@{Set+1} ? [Mon Oct 2 18:59:23 2017] obtained with forall A : Set, A [Mon Oct 2 18:59:26 2017] also, re Prop: another difference about Prop vs Set/Type is that data types in Prop do not have discrimination [Mon Oct 2 19:01:08 2017] I haven't seen it written that way before... [Mon Oct 2 19:01:58 2017] I suppose it’s Type at the next level from whatever level Set is [Mon Oct 2 19:02:07 2017] but it’s slightly confusing if Set is definitely supposed to be Type 0 [Mon Oct 2 19:02:10 2017] "forall A:Set, A" can be considered syntactic sugar for "forall A:Type{0}, A" and we have the typing jusdement "|- (forall A:Type{0}, A) : Type{1}" [Mon Oct 2 19:02:28 2017] yes, that’s what I thought [Mon Oct 2 19:02:46 2017] yeah, they might use the textual token "Set" as a placeholder for where the hierarchy of Type starts [Mon Oct 2 19:03:25 2017] they prolly print it that way just to avoid the 0- vs 1-based indexing issue ;) [Mon Oct 2 19:03:29 2017] heh [Mon Oct 2 19:05:42 2017] what does the --parse-comments flag for coqdoc do? [Mon Oct 2 19:10:03 2017] iirc, it's the Coq-equivalent of Haddock; though of course the markup syntax is a bit different [Tue Oct 3 01:25:07 2017] What does it mean to use the destruct tactic on hypotheses? For example, if I have H : (exists x : X, P x -> False) -> False as an hypothesis (with P : X -> Prop) I can write "destruct H". But unlike, say, writing destruct y with y : bool, this doesn't have an obvious "case-by-case" interpretation to me. [Tue Oct 3 01:25:48 2017] buttbutter: a lot of tactics that operate on a type T will also operate on a function type that returns T [Tue Oct 3 01:26:00 2017] and generate goals for the arguments [Tue Oct 3 01:26:22 2017] so that will generate a goal for "exists x : X, P x -> False", feed that goal to H, and destruct the resulting False [Tue Oct 3 01:26:53 2017] similarly, you can do [rewrite H] where H is a function type that results in an equality [Tue Oct 3 01:27:10 2017] er... i _think_ thats correct anyway :) [Tue Oct 3 01:27:32 2017] some of this stuff might be specific to when it can infer what the arguments should be, like doing a rewrite using something of type [forall n, n + 0 = 0] [Tue Oct 3 01:28:32 2017] you can supply arguments to rewrite, e.g. "rewrite H with (a := a) (b := xyz)" [Tue Oct 3 01:28:36 2017] That sort of makes sense. I'm not sure I understand what it means to destruct False. [Tue Oct 3 01:28:44 2017] False is just an absurd propsition, right? [Tue Oct 3 01:28:45 2017] and I think you can do that with destruct too [Tue Oct 3 01:28:52 2017] proposition* [Tue Oct 3 01:29:12 2017] False is an inductive type with 0 constructors [Tue Oct 3 01:29:18 2017] so when you destruct it, you get 0 subgoals [Tue Oct 3 01:30:22 2017] speaking of which I came across something annoying last night; I had a lemma of the form "forall a b c, stuff1 -> stuff2 -> forall x, stuff3 [Tue Oct 3 01:30:58 2017] I tried to apply it in H: stuff2, and coq insisted on instantiating x instead of giving me H: forall x, stuff3 [Tue Oct 3 01:31:22 2017] I guess I'm still a bit confused why the destruct results in a new goal of just trying to figure out the arguments to the function H. [Tue Oct 3 01:31:24 2017] is there a way to make it not do that? [Tue Oct 3 01:32:46 2017] (besides "assert (forall x, stuff3) by (apply foo; auto)") [Tue Oct 3 01:33:56 2017] oh also [Tue Oct 3 01:34:16 2017] buttbutter: if you ask Coq to destruct "H : A -> False", then it will ask you to prove A, so that it can produce something of type False and destruct that something [Tue Oct 3 01:34:22 2017] cypi: I redid my 3rd bubblesort with your inductive and it worked (tsill kinda messy, six levels of bullets) [Tue Oct 3 01:34:36 2017] which is why destructing your H should result in exactly one goal asking you to prove (exists x, P x -> False) [Tue Oct 3 01:34:45 2017] Cypi: Oh. I see! that makes sense. [Tue Oct 3 01:34:54 2017] it didn't need any special properties of it being an inductive, but it did show what I was doing wrong last night [Tue Oct 3 01:35:15 2017] So the new goal is sort of an intermediate to the destruct in the sense that you first need to prove the argument before the destruct can even take place. [Tue Oct 3 01:35:26 2017] So the "destruction" hasn't happened yet. Until you prove the new goal. [Tue Oct 3 01:35:29 2017] namely: I was allowing lists to be more sorted than their length [Tue Oct 3 01:35:43 2017] Ah right, that might make things more annoying :) [Tue Oct 3 01:35:49 2017] this introduced enough imprecision to make things not go [Tue Oct 3 01:36:05 2017] and yes, being an inductive doesn't bring anything essential, you could just re-prove the injectivity stuff and so on [Tue Oct 3 01:36:12 2017] right [Tue Oct 3 01:36:16 2017] didn't use any of it directly anyway [Tue Oct 3 01:36:49 2017] buttbutter: depends on your definition of "hasn't happened yet", but if you were to destruct "A -> bool" for instance, then Coq would produce 3 subgoals [Tue Oct 3 01:36:52 2017] maybe I'll redo the non-inductive version analogously, it should not be substantively different. [Tue Oct 3 01:37:07 2017] so you could first prove the subgoals after the destruct if you wished so [Tue Oct 3 01:38:26 2017] Cypi: One subgoal to prove A, and then one for each of the two constructors of bool? [Tue Oct 3 01:38:33 2017] yes [Tue Oct 3 01:38:55 2017] And you can prove subgoals out of order? [Tue Oct 3 01:39:04 2017] sure [Tue Oct 3 01:39:08 2017] Oh. How? [Tue Oct 3 01:39:27 2017] You could use "Focus 3." to focus specifically on the third subgoal that you see [Tue Oct 3 01:39:41 2017] You could also do stuff like "3: apply foo." to use a tactic on the 3rd subgoal [Tue Oct 3 01:39:56 2017] You can also do "all: swap 1 3" to swap the first and the third subgoals [Tue Oct 3 01:39:59 2017] lot of choices :) [Tue Oct 3 01:40:05 2017] except that doing that moves goal 3 to the top [Tue Oct 3 01:40:08 2017] Cool :D Thanks. [Tue Oct 3 01:40:25 2017] a while back I had a mess where I ended up with like 850 goals [Tue Oct 3 01:40:47 2017] which came in patterns, so I was trying to do things like 1,6,12,18: destruct H [Tue Oct 3 01:40:58 2017] it didn't really work out very well [Tue Oct 3 01:41:31 2017] "3: apply foo." will not move goal 3 to the top [Tue Oct 3 01:41:51 2017] "3,6,9: idtac." will move goals 6 and 9 right after goal 3. [Tue Oct 3 01:42:19 2017] I know it's a problem with selectors on non-consecutive goals, but I couldn't figure out a heuristics that made sense. I'm open to reasonable suggestions x) [Tue Oct 3 01:43:10 2017] my suggestion would be to leave them alone, tbh [Tue Oct 3 01:43:21 2017] Except that it doesn't make sense from a technical standpoint [Tue Oct 3 01:43:24 2017] if the goals are patterned, breaking the patterns up doesn't help; if they aren't, nothing helps [Tue Oct 3 01:43:29 2017] oh [Tue Oct 3 01:43:31 2017] pity [Tue Oct 3 01:43:49 2017] One more question: say I have something like "H : forall P : Prop, P \/ ~ P" as a hypothesis, along with M : Prop. Is there a tactic to apply H to get the claim M \/ ~M? [Tue Oct 3 01:43:51 2017] The way tactics work, you have a bunch of goals under focus, you apply a tactic, you end up with another bunch of goals (which might be fewer or more goals, you don't know) [Tue Oct 3 01:44:10 2017] i.e. I don't know how to deal with the "forall" for hypothesis (for goals, it's easy). [Tue Oct 3 01:44:11 2017] if you have more goals, where do you put them? If less? You can't even really relate them to the goals you had initially :/ [Tue Oct 3 01:44:12 2017] buttbutter: specialize [Tue Oct 3 01:44:24 2017] e.g. specialize H with (P := M) [Tue Oct 3 01:44:35 2017] you can also write specialize (H M) [Tue Oct 3 01:44:49 2017] also, "pose proof (H M)." if you don't want to lose hypothesis H [Tue Oct 3 01:44:59 2017] Perfect! :D [Tue Oct 3 01:45:03 2017] Thanks. [Tue Oct 3 01:45:43 2017] What's the best way to learn about all these tactics, by the way? [Tue Oct 3 01:45:51 2017] ideally you'd put the new goals where the old ones were in the list [Tue Oct 3 01:46:04 2017] But you don't know from which goal they originated [Tue Oct 3 01:46:15 2017] imagine a tactic which starts with "all: cycle" and then does a bunch of stuff [Tue Oct 3 01:46:24 2017] buttbutter: there's a page in the manual, which is probably the best available, but it's not really suitable for beginners [Tue Oct 3 01:46:40 2017] there are a thousand cheatsheets and tutorials, but you tend to have to mine them for ideas [Tue Oct 3 01:46:49 2017] cypi: uugh [Tue Oct 3 01:46:50 2017] I dunno :( [Tue Oct 3 01:47:02 2017] basically, if there was a way to identify "single-goal" tactics, you could have a reasonable heuristics for them. But multi-goal tactics screw up everything :( [Tue Oct 3 01:47:04 2017] Yeah. I looked at the documentation and found it very difficult to understand. [Tue Oct 3 01:47:24 2017] I agree the situation isn't really satisfactory though, multiple-goals selectors are only good when you actually solve your goals [Tue Oct 3 01:47:48 2017] it would be great if someone who isn't a phd logician rewrote the whole manual :-/ [Tue Oct 3 01:48:01 2017] buttbutter: I'm pretty sure a book like Software Foundations covers the most useful tactics [Tue Oct 3 01:48:16 2017] There is also this page https://coq.inria.fr/refman/tactic-index.html which is worth to glance over, when you need something [Tue Oct 3 01:48:27 2017] sometimes tactics names make sense [Tue Oct 3 01:48:41 2017] Cypi: That's what I'm working through, actually. [Tue Oct 3 01:49:11 2017] But I found that a lot of the tactics aren't sufficiently explained. Or they are at first for simple cases, but then they--for example--start using destruct on functions without really explaining what's going on. [Tue Oct 3 01:49:27 2017] actually you know what might work better is a way to group goals [Tue Oct 3 01:49:43 2017] What do you mean? [Tue Oct 3 01:49:56 2017] something like "group 1 2 3 4 5 as XYZ" [Tue Oct 3 01:50:08 2017] then maybe "Focus XYZ" to see just those goals [Tue Oct 3 01:50:26 2017] or XYZ: foo to apply a tactic to all of them [Tue Oct 3 01:50:40 2017] it would probably be a fairly big deal to implement that [Tue Oct 3 01:51:19 2017] Basically, the tactics engine isn't made to focus on a non-consecutive list of goals, that's the main problem [Tue Oct 3 01:51:38 2017] for the same reason as before: you don't know what to do with the goals you get at the end [Tue Oct 3 01:52:29 2017] making the list into a tree so you can group related things is kind of a workaround for that, maybe [Tue Oct 3 01:52:32 2017] I dunno, I'm thinking out loud [Tue Oct 3 01:53:11 2017] I mean, I could imagine implementing what you meant, by literally putting aside these goals or something (removing them from the main focus, like a shelved evar) [Tue Oct 3 02:02:23 2017] you'd want to be able to name the groups, though [Tue Oct 3 02:03:32 2017] maybe make the goal list into a tree of groups, where you can move up and down by focusing, and only expose the current group at any one time [Tue Oct 3 02:03:36 2017] so things like cycle only affect it [Tue Oct 3 02:13:10 2017] relatedly, normally if you do something that produces additional goals, they end up after the original goal; is there a way or mode to cause them to appear first? [Tue Oct 3 02:13:52 2017] I'm guessing not, but often it seems more natural to dispatch them first and you can't always just do e.g. apply foo; try discriminate [Tue Oct 3 02:14:24 2017] and manipulating them explicitly by number if you don't have to feels fragile [Tue Oct 3 11:44:09 2017] On this page https://softwarefoundations.cis.upenn.edu/draft/qc-current/Typeclasses.html can someone help me out with exercise 4 (Dec_All). I'd like to see what the instance declaration would look like for "Dec for All P l, given that P a is decidable for every a." [Tue Oct 3 11:44:20 2017] I can write the instance myself. Just need the declaration. [Tue Oct 3 12:26:44 2017] it should be something like this: [Tue Oct 3 12:26:47 2017] Instance Dec_All `{P : A -> Prop} {H : forall a, Dec (P a)} (l : list A) : Dec (All P l). [Tue Oct 3 15:31:28 2017] it's not provable that theres a surjection from (nat -> bool) to nat, right? [Tue Oct 3 16:45:25 2017] hi. Is there a reason why "Qed." is used in the standard library instead of "Defined."? [Tue Oct 3 16:45:30 2017] I'm reading about well-founded recursion (http://adam.chlipala.net/cpdt/html/GeneralRec.html), which says that you have to use "Defined" in proofs of well-foundedness so that you can do recursion "on the structure of Acc proofs" [Tue Oct 3 16:45:35 2017] but doesn't that mean you can't use any theorems from the standard library in those well-foundedness proofs? They all end in Qed, not Defined. [Tue Oct 3 18:31:59 2017] quelqu'un est ici? [Tue Oct 3 18:34:38 2017] le canal est mort? [Tue Oct 3 18:35:09 2017] Migi32: u probably dont need to do that kind of recursion on most proofs [Tue Oct 3 18:36:40 2017] yeah you're probably right [Tue Oct 3 19:53:17 2017] say i have 2 assumptions a: A and forall x:A, P x, how do apply my 1st assumption to the 2nd? [Tue Oct 3 19:54:01 2017] rgrinberg: you can write the expression x a [Tue Oct 3 19:54:15 2017] or if you want to effect a change to the proof state, you have a couple of options depending on what you want the change to be [Tue Oct 3 20:03:23 2017] benzrf: what are those options? [Tue Oct 3 20:03:38 2017] suppose i just want to add the result as a new assumption for example [Tue Oct 3 20:04:25 2017] i think pose does that. [Tue Oct 3 20:04:29 2017] rgrinberg: one way to do that would be [pose (NewAssumption:=x a)] [Tue Oct 3 20:04:35 2017] im not sure if theres a specific way [Tue Oct 3 20:04:45 2017] pose in general lets you add a definition [Tue Oct 3 20:06:07 2017] benzrf: thanks [Tue Oct 3 20:06:14 2017] rgrinberg: you can also do [specialize (x a)] to move to [x : P a] [Tue Oct 3 20:06:25 2017] or [apply x in a] to move to [a : P a] [Tue Oct 3 20:06:29 2017] er, wait, that would fail i think [Tue Oct 3 20:06:33 2017] since youd be overwriting the thing it's referring to [Tue Oct 3 20:06:35 2017] np [Tue Oct 3 20:06:46 2017] specialize loses the thing though, doesn't it? [Tue Oct 3 20:08:46 2017] in my proof context, how come my NewAssumption is written with := rather than : like other ones? [Tue Oct 3 20:09:11 2017] rgrinberg: the context can have both "hypotheses" and "local definitions" [Tue Oct 3 20:09:21 2017] hypotheses correspond to function arguments; you only know their type [Tue Oct 3 20:09:43 2017] local definitions correspond to bindings created using things like let; you can always expand them [Tue Oct 3 20:11:00 2017] benzrf: i see. thanks again [Tue Oct 3 20:11:43 2017] np [Tue Oct 3 20:22:41 2017] Suppose, I have this notation {P} + {~ P}, how would I use proof general/company coq to look up what it means? [Tue Oct 3 20:22:57 2017] I actually know what it means in this coq, but i had to google it. Wondering how can I find this out inside emacs [Tue Oct 3 20:31:07 2017] rgrinberg: [Print "{ _ } + { _ }"] [Tue Oct 3 20:31:47 2017] benzrf: sweet :) [Tue Oct 3 20:31:53 2017] note that u need the extra spaces there [Tue Oct 3 20:32:05 2017] im not sure what the details are of what itll recognize and what it wont [Tue Oct 3 20:32:12 2017] it looks like [Print "exists _, _"] doesn't work [Tue Oct 3 20:32:14 2017] shrug [Tue Oct 3 20:32:25 2017] this also worked with Locate as well. awesome [Tue Oct 3 20:32:30 2017] :) [Tue Oct 3 20:32:46 2017] lol i hadnt even heard of locate [Tue Oct 3 20:33:17 2017] another quick one, suppose i have an assumption ~ P x and a goal P x. how do i make coq see the contradiction? [Tue Oct 3 20:33:32 2017] i tried congruence but it didn't work [Tue Oct 3 20:33:55 2017] contradiction [Tue Oct 3 20:35:14 2017] hmm, that doesn't work either. One thing to note is that my assumption is of the form ~ All p l, while the goal is of the form (fix All ... := ..) A p l) [Tue Oct 3 20:35:37 2017] coq expanded it like that because of a previous unfold, but it's still equivalent [Tue Oct 3 20:35:47 2017] rgrinberg: assumption ~P x and goal P x isnt solvable [Tue Oct 3 20:36:01 2017] consider: [Goal ~False -> False] [Tue Oct 3 20:36:27 2017] shouldn't this be enough to tell goal that this case is impossible? [Tue Oct 3 20:36:41 2017] im not sure what youre asking [Tue Oct 3 20:37:37 2017] here's my proof context [Tue Oct 3 20:37:37 2017] https://gist.github.com/rgrinberg/0a5931d1d28f2903a904c66e183495f9 [Tue Oct 3 20:39:14 2017] so you're trying to prove something false [Tue Oct 3 20:40:12 2017] yup [Tue Oct 3 20:40:20 2017] if we know that [~All P l] is the case, we certainly can't prove [All p l] [Tue Oct 3 20:40:25 2017] not unless we have a contradiction [Tue Oct 3 20:40:31 2017] where's the contradiction? [Tue Oct 3 20:41:14 2017] good point.. i thought what i had was already a contradiction [Tue Oct 3 20:41:24 2017] :p easy misatake to make if you get lost in the notation [Tue Oct 3 20:50:20 2017] ah fuck it... no idea how to proceed here. Here's what i got so far [Tue Oct 3 20:51:00 2017] https://gist.github.com/rgrinberg/ed9f821e4214427be323e72530bccb80 [Tue Oct 3 21:54:00 2017] looks like the tauto tactic is what i was looking for... [Tue Oct 3 22:03:01 2017] of course, that's not very satisfying as I have no idea how tauto works. So I'd like to understand that, and perhaps figure out how to do it the long way (without tauto). [Tue Oct 3 22:03:04 2017] here's my fool proof [Tue Oct 3 22:03:37 2017] https://gist.github.com/rgrinberg/85ece1635aec8312273008f9807346e9 [Tue Oct 3 23:32:19 2017] I asked this before but did not get an answer. Is there a way by which I can add an import Foo line in the extracted haskell code. [Tue Oct 3 23:32:30 2017] ? [Tue Oct 3 23:41:39 2017] dont personally know sorry :\ [Wed Oct 4 01:01:06 2017] jrw: in this post: https://homes.cs.washington.edu/~jrw12/InductionExercises.html what is this general helper lemma that you're referring to? is part of the exercise coming up with it? My first stab at it is something like n + sum l = sum_tail' l n but i'm not sure... [Wed Oct 4 01:02:00 2017] rgrinberg: to be clear, there will be a different "helper lemma" for each exercise. yours looks good to me. [Wed Oct 4 01:03:01 2017] jrw: thank you! [Wed Oct 4 01:25:38 2017] Is there a way to make unfold a little smarter? When I fold a recursive definition it will paste the entire definition and the arguments that it applies to it [Wed Oct 4 01:25:42 2017] but that's not really necessary... [Wed Oct 4 01:40:12 2017] Also, is there a rewrite rule for something like n + x = n + y => x = y [Wed Oct 4 01:42:18 2017] Think I found it.Plus.plus_reg_l [Wed Oct 4 05:35:49 2017] Is there a publicly available archive/log for this channel? [Mon Oct 9 07:42:45 2017] Hello. I need some help with this. http://lpaste.net/359064 . Thanks! [Mon Oct 9 08:02:32 2017] lfish : by using these two lemmas, it should be easier http://lpaste.net/359074 [Mon Oct 9 08:04:00 2017] (the first one is just to be able to destruct on the end side of a list; the second one generalizes properly emlist_of_list so that you get a useful induction hypothesis) [Mon Oct 9 08:07:18 2017] [actually, "Lemma dest_snoc : forall {X : Type} (l : list X) (x : X), exists x' l', x :: l = l' ++ [x']." could be even easier to use] [Mon Oct 9 08:08:45 2017] Cypi: while trying to build the evidence I run a couple of times into trying to define functions with no decreasing argument. Is the limitation in the length of the list in the second lemma related to that? [Mon Oct 9 08:09:35 2017] I am not sure I understand your first sentence. The "length l < n" is because it makes more sense in this case to do an induction on the length of the list [Mon Oct 9 08:10:30 2017] if you use the EMcons constructor, then you need an induction hypothesis that talks about the "middle" of your list. The "middle" of your list is not a subterm of your list, it is just some shorter list [Mon Oct 9 08:10:41 2017] hence the induction on the length of the list instead of doing it on the list itself [Mon Oct 9 08:13:15 2017] Oh, I understand now, thank you [Mon Oct 9 10:41:30 2017] how hesitant should I be to add more axioms, like the law of excluded middle? [Mon Oct 9 10:41:46 2017] so far I've avoided adding any axioms, but I'm wondering if I'm just wasting my time [Mon Oct 9 10:45:14 2017] I've read the FAQ which proposes a whole bunch of possible axioms to add, but if I understand correctly, the law of excluded middle seems to imply most of those other axioms [Mon Oct 9 10:45:22 2017] i would say if you're going to be hesitant that's one you should be hesitant about, since it is quite strong. negative sides of it are that you don't get constructive proofs. [Mon Oct 9 10:46:07 2017] if you're not going to compute with the proofs i guess it doesn't matter too much. [Mon Oct 9 10:51:04 2017] I'm not entirely sure what "computing with proofs" even means. Do you mean that if someone wrote a proof in coq of Goldbach's conjecture, without using any additional axioms, that no matter how that proof is written, you could ask coq to compute the 2 primes that add up to the given even integer? [Mon Oct 9 10:52:17 2017] yes [Mon Oct 9 10:56:20 2017] doesn't mean the computation will be fast or even feassible for very large nats though -) [Mon Oct 9 11:00:20 2017] I see. That's pretty cool actually. [Mon Oct 9 13:24:29 2017] Let's say I have an indexed type, like a vector, and I have a function which creates a vector `(Vec A (f n))`, but I know that `f n = n`, and I want to simplify this. Is there a good way to do that? [Mon Oct 9 13:26:36 2017] There is no magical way. From your function that creates a `Vec A (f n)` and a proof of `f n = n`, you can build a function which returns a `Vec a n` using some rewriting [Mon Oct 9 13:27:03 2017] but the rewriting can make using your function a bit more difficult [Mon Oct 9 13:27:31 2017] Cypi: yeah, so I have done this using tactics, which generates some expression using eq_rec. [Mon Oct 9 13:27:47 2017] But then proving properties about this new function is proving problematic. [Mon Oct 9 13:27:47 2017] yup, eq_rec is what I called rewriting [Mon Oct 9 13:28:46 2017] Cypi: do you know if there are any docs about eq_rec? [Mon Oct 9 13:29:11 2017] I can't seem to find it. eq_rect comes up a lot, but I'm pretty sure that's different. [Mon Oct 9 13:29:20 2017] I don't think there is specifically. It is just the induction principle for the equality type [Mon Oct 9 13:29:34 2017] and no, eq_rec is defined as eq_rect, it just goes to Set instead of Type [Mon Oct 9 13:29:39 2017] (you can "Print eq_rec.") [Mon Oct 9 13:30:03 2017] Oh I see. [Mon Oct 9 13:31:26 2017] What does "rect" even stand for? I know '_rect' functions are generated for each inductive type for the induction principle but I always read it as "rectangle" or something, and I think that's wrong. [Mon Oct 9 13:32:02 2017] I am pretty sure that "rec" stands for "recursion", and then "rect" stands for "recursion, but in Type" [Mon Oct 9 13:32:06 2017] might be wrong [Mon Oct 9 13:32:37 2017] Aha! That's what CPDT says as well :). Okay, thanks. [Mon Oct 9 13:45:59 2017] I feel like this might be the kind of scenario where `JMeq_eq : forall (A : Type) (x y : A), x ~= y -> x = y` may cause problems. Hmmmm. [Mon Oct 9 14:32:01 2017] cypi: I too am curious about that fib thing; did you see the solution I posted a couple days back? [Mon Oct 9 14:32:54 2017] I didn't see the solution, no. But I found my own which was easy enough that I was surprised [Mon Oct 9 14:32:59 2017] (it only takes a few lines) [Mon Oct 9 14:33:20 2017] huh, mine's not that simple [Mon Oct 9 14:33:22 2017] (and it's quite natural, just state the invariant) [Mon Oct 9 14:34:02 2017] it's here if you're curious: http://codepad.org/nsQpyeHY [Mon Oct 9 14:34:22 2017] thanks [Mon Oct 9 14:34:40 2017] ah yes, definitely simpler :) [Mon Oct 9 14:34:42 2017] it is not short, but it should at least be easy to follow [Mon Oct 9 14:34:44 2017] let me take that again [Mon Oct 9 14:36:54 2017] the reason it's hard is that the invariant is confusing [Mon Oct 9 14:37:23 2017] not really though :p http://lpaste.net/359084 [Mon Oct 9 14:38:24 2017] but that's nearly what you wrote as your first lemma [Mon Oct 9 14:39:11 2017] I dunno, it has one too many moving parts to be clear to me, or something [Mon Oct 9 14:39:39 2017] that first lemma of mine is actually a condensation of three steps when I started out [Mon Oct 9 14:39:54 2017] The way I understand "fib_tail' m a b" is that it advances the sequence by m steps [Mon Oct 9 14:40:10 2017] so if a is "fib (S n)" and b is "fib n", it returns the (n+m)-th term of the sequence [Mon Oct 9 14:40:14 2017] that's all you need [Mon Oct 9 14:40:34 2017] yes... once you figure that out [Mon Oct 9 14:40:57 2017] Ah right. Sorry, I thought he meant the proof itself was convoluted. Sure, it takes some time to get to that point [Mon Oct 9 14:41:07 2017] well, he might have :-) [Mon Oct 9 14:41:14 2017] now I definitely want to see his... [Mon Oct 9 14:42:30 2017] I should also do the expression continuations one, it is possibly comparable to something I spent ages beating my head against last spring [Mon Oct 9 16:25:03 2017] Hi, totally new to Coq and functional programming, so the syntax is new to me. I have a question that might not make sense, but that's most likely because I'm not understanding all of it 100%. I am doing Basics.v exercises from "Software Foundations", and I was wondering if the proofs for the theorems I do have many approaches? I have written 3 proofs for: 'Theorem andb_true_elim2 : forall b c : bool, andb b c = [Mon Oct 9 16:25:04 2017] true -> c= true' [Mon Oct 9 16:30:19 2017] It is often the case in SF that there are several obvious proof techniques. [Mon Oct 9 16:32:49 2017] (And in general it is often the case that there are many ways to prove a given theorem. This brings up the question of proof irrelevance. Don't worry about that yet.) [Mon Oct 9 16:33:03 2017] Aha [Mon Oct 9 16:34:02 2017] Can I PM you my 3 solutions? I want to get some feedback on my "style" of proofs [Mon Oct 9 17:11:35 2017] why yet another language? [Mon Oct 9 17:11:45 2017] cant you just make a c library? i dont get it [Mon Oct 9 17:13:45 2017] Eh? [Mon Oct 9 17:14:57 2017] the "convenience" of a DSL doesnt really trump the added cost of an entire new toolchain and effort of learning a language [Mon Oct 9 17:22:25 2017] Steverman: my own proofs usually look like mojibake. I wouldn't rely on me for style tips. :) [Mon Oct 9 17:22:37 2017] Alright :) [Mon Oct 9 17:22:54 2017] But if your proofs check, the computer has told you they're correct at least. [Mon Oct 9 17:23:04 2017] Then it's no problem? [Mon Oct 9 17:23:46 2017] I mean I used the shorthand intros [] [] H., then for each subgoal: -rewrite <- H. reflexivity. [Mon Oct 9 17:23:50 2017] Surprised that it worked [Mon Oct 9 17:25:38 2017] Me pretty much right now: https://i.pinimg.com/236x/4f/54/29/4f5429df5ea6361fa8d3f08dfcdccdf9--programmer-humor-computer-engineering.jpg [Mon Oct 9 17:39:02 2017] Steverman: So not understanding what's going on is a problem. You should try to understand if you can. [Mon Oct 9 17:39:22 2017] I suppose [Mon Oct 9 17:39:24 2017] BTW, 2/3 of the time I just do "intros" and let the thing name my variables and hypotheses whatever it wants to. :) [Mon Oct 9 17:39:42 2017] SF said it's bad practice :P [Mon Oct 9 17:39:45 2017] Have you tried watching any of the DSSS'17 videos btw? [Mon Oct 9 17:40:31 2017] SF is almost certainly right that it is bad practice when you are trying to understand a complicated proof. And it is probably correct that it is a bad habit to be in. None the less, I often just do "intros." [Mon Oct 9 17:40:36 2017] Laziness. [Mon Oct 9 17:43:54 2017] Anyway, if you don't understand why something worked or didn't work, try out more examples. Or ask people. [Mon Oct 9 18:18:03 2017] pmetzger: I tried [Mon Oct 9 18:18:38 2017] That was for the youtube vids [Mon Oct 9 18:18:38 2017] You tried what? :) [Mon Oct 9 18:19:08 2017] Anyway, if there's something you don't understand, pastebin it and ask people to look and explain as best as they can. [Mon Oct 9 18:19:08 2017] Yeah, maybe I shouldn't use shorthand notations [Mon Oct 9 18:20:54 2017] my take(s) on this the problem: https://pastebin.com/ernn9U45 [Mon Oct 9 18:21:20 2017] -this* [Mon Oct 9 18:24:57 2017] From what I've read, using 'intros []' (unnamed arguments?) will just generates subgoals from destructed arguments [Mon Oct 9 18:56:03 2017] what's your question? [Mon Oct 9 18:56:15 2017] you can do "intros.", no need for [] [Mon Oct 9 18:56:28 2017] if you're not going to name things. [Mon Oct 9 18:56:42 2017] I didn't know [Mon Oct 9 18:57:05 2017] I've only read what was on the basics chapter [Mon Oct 9 18:57:46 2017] But what's the question? what part of your proof don't you understand (taking the first version) [Mon Oct 9 18:59:03 2017] I suppose nothing then. if they all "check", then they're all valid? [Mon Oct 9 19:01:45 2017] well yes. but do you understand how they each work? [Mon Oct 9 19:02:31 2017] if "Qed." works, it means the checker says the proof is fine. It is possible, but very rare, that bugs in the tactic system could cause Qed to fail. You are unlikely to see this in the course of working through Software Foundations. [Mon Oct 9 19:03:11 2017] In mathematics there are sometimes hundreds of known proofs for a _complicated_ proposition. There are whole books of proofs of the pythagorean theorem for example. [Mon Oct 9 19:03:32 2017] though all these proofs you have are nearly the same, the differences are superficial. [Mon Oct 9 19:03:32 2017] Right [Mon Oct 9 19:03:56 2017] There is no preferred way? [Mon Oct 9 19:04:35 2017] What's the preferred proof of the pythagorean theorem? [Mon Oct 9 19:04:50 2017] I see your point :) [Mon Oct 9 19:05:52 2017] stylistically, a proof _script_ can be clean or incomprehensible. and if you continue with coq, you'll learn that there are styles of proof for complicated things that are more and less fragile in that they'll be more or less likely to break if definitions change a bit. [Mon Oct 9 19:06:01 2017] But at this stage, concentrate on learning fundamentals and not style. [Mon Oct 9 19:06:28 2017] I have a legit question though. The last question in exercise 3 (bottom page) https://softwarefoundations.cis.upenn.edu/lf-current/Basics.html [Mon Oct 9 19:07:21 2017] This exactly: 'Notice that incrementing a binary number and then converting it to unary should yield the same result as first converting it to unary and then incrementing.' I can't really wrap my head around what he's saying. Am I supposed to be able to convert to unary, then use 'incr' on a nat? [Mon Oct 9 19:07:50 2017] okay, so you get that there are many representations of numbers, yes? [Mon Oct 9 19:08:04 2017] Because I have defined it like this: (b : bin) : bin [Mon Oct 9 19:08:08 2017] Yes [Mon Oct 9 19:08:15 2017] you can represent the same number in base 10, base 8, base 2, balanced ternary notation, roman numerals, etc. [Mon Oct 9 19:08:29 2017] So if you do math in any of these representations you should come out with the same answers. [Mon Oct 9 19:08:55 2017] if you convert from base 2 to base 10, add 1, and convert back to base 2, that should be the same as staying in base 2 and incrementing, yes? [Mon Oct 9 19:09:09 2017] so: 'Notice that incrementing a binary number and then converting it to unary should yield the same result as first converting it to unary and then incrementing.' [Mon Oct 9 19:09:11 2017] that should be obvious. [Mon Oct 9 19:09:36 2017] you can convert before or after doing a mathematical operation and it should have no effect on the final answer. converting and incrementing should commute. [Mon Oct 9 19:09:45 2017] if they don't you have a bug. [Mon Oct 9 19:10:29 2017] Oh okay, so I just need to write a function that translates it back to bin [Mon Oct 9 19:10:47 2017] If I want to verify [Mon Oct 9 19:10:47 2017] that's not demanded here. [Mon Oct 9 19:11:07 2017] it is only demanding binary to unary [Mon Oct 9 19:12:27 2017] I see [Mon Oct 9 19:12:50 2017] but you get that incrementing and converting should commute, right? [Mon Oct 9 19:12:57 2017] the order of those operations should make no difference. [Mon Oct 9 19:13:23 2017] Yes [Mon Oct 9 19:14:02 2017] so doing things both ways should always yield an equal result. [Mon Oct 9 19:14:53 2017] you should even be able to prove that, that is, for all x : Binary, [fill in statement....] [Mon Oct 9 19:15:07 2017] though at this stage I don't remember if you have all the tools you need for an inductive proof of that. [Mon Oct 9 19:15:31 2017] Induction is in the next chapter I believe [Mon Oct 9 19:16:03 2017] You need proof by induction to prove things about infinite sets, at least usually. Well, "sets", they're really types given that this is type theory but YKWIM. [Mon Oct 9 19:18:37 2017] It has been a while since I've done one [Mon Oct 9 19:20:49 2017] I have 'Functional Programming' as a course, and got Lambda Calculus and Coq. [Mon Oct 9 19:21:27 2017] I suppose it makes sense on a Masters level CompSci [Tue Oct 10 03:09:42 2017] There are so many proof assistants, i dont know how to choose! [Tue Oct 10 03:10:04 2017] People say that Coq is too hard [Tue Oct 10 03:47:04 2017] hard for what? [Tue Oct 10 03:52:23 2017] for its intended purpose, to learn and use quickly to develop proofs [Tue Oct 10 04:25:46 2017] Let's say I've defined nat' identically to nat. I presume there's no way of proving forall P : Set -> Prop, (P nat) -> (P nat')? [Tue Oct 10 06:27:12 2017] hio: I’m learning from ‘Software Foundations’. I find the entry level very low. I tried to learn ATS earlier from some tutorial, and despite having experience with C (ATS is similar to C) I felt lost. It all depends on the learning materials you choose for yourself. [Tue Oct 10 06:29:31 2017] you mean this? http://adam.chlipala.net/cpdt/ [Tue Oct 10 06:30:19 2017] No. [Tue Oct 10 06:31:23 2017] https://softwarefoundations.cis.upenn.edu/ [Tue Oct 10 08:03:11 2017] cq1: you are right, without additional axioms you can't prove this (consider for instance "P := fun (S : Set) => S = nat") [Tue Oct 10 08:03:44 2017] if you think this would be natural to be able to prove this, then univalence is the axiom for you and you could take a look at Homotopy Type Theory [Tue Oct 10 09:01:11 2017] is it a good idea to create opam packages from my phd project? [Tue Oct 10 09:01:30 2017] and if so: is there a detailled documentation on how to create an opam-coq-package? [Tue Oct 10 09:01:58 2017] because opam seems to be rather for ocaml [Tue Oct 10 19:12:09 2017] Cypi: Thanks. I didn't consider such a proposition. Is there a name for the idea that two identical inductives should be equal, analogous to functional extensionality? [Tue Oct 10 19:12:36 2017] The idea that two equivalent types should be equal is univalence [Tue Oct 10 19:13:07 2017] this is a kind of functional extensionality but for types (it also implies functional extensionality) [Tue Oct 10 19:14:06 2017] What is "equivalent"? Does it have some definition inside of our logic, or is it a meta notion, like "these inductives differ only by reordering constructors, alpha-renaming, etc."? [Tue Oct 10 19:15:13 2017] It is a definition inside the logic. Basically, A et B are equivalent if there is a function f : A -> B such that there is a function g : B -> A which is inverse of f [Tue Oct 10 19:15:41 2017] (there are several notions of equivalence, but that's one of them) [Tue Oct 10 19:15:47 2017] So this is not specific to inductive types [Tue Oct 10 19:15:56 2017] I don't know of anything absolutely specific to inductive types [Tue Oct 10 19:25:31 2017] Cypi: Interesting, thanks. I'll look into HoTT and univalence. Is univalence pronounced /juː'nɪvələns/ or /juːnɪˈveɪləns/? [Tue Oct 10 19:26:23 2017] isnt it more common to say that 2 types are equivalent if there's an equivalence between them, where an equivalence is a map whose fibers are contractible [Tue Oct 10 19:26:25 2017] tsk tsk [Tue Oct 10 19:26:56 2017] cq1: I'm not a native English speaker, I don't know [Tue Oct 10 19:27:25 2017] benzrf: pretty sure it depends who you ask [Tue Oct 10 19:49:59 2017] Might not be the right way to say this, but can you only rewrite types? [Tue Oct 10 19:50:03 2017] http://lpaste.net/9127850804550565888 [Tue Oct 10 19:50:36 2017] Well, that's not right But I'm having problems rewriting the terms in eq_rect there. [Tue Oct 10 19:51:55 2017] And I'm not sure why it won't let me do that. [Tue Oct 10 19:55:02 2017] Maybe it just has to do with the final argument to eq_rect, the `x=y` argument, and then coq gets mad when you replace `x` in the previous arguments? [Tue Oct 10 22:17:22 2017] Super basic question that's leaving me feeling dumb: I have (cons a b = cons c d) -- how do I conclude a = c and b = d? [Tue Oct 10 22:18:11 2017] with "inversion H" (if H is the name of your hypothesis) [Tue Oct 10 22:19:04 2017] Cypi: Thanks. [Tue Oct 10 22:57:51 2017] I'm having a lot of trouble with the binary inverse problem in the induction chapter of the logical foundations book of software foundations. I get into an infinite regress (even using induction) where one case just keeps being intractable. I've looked at the existing solutions I can find online (this is not homework for me), and they don't work for me (and by inspection my data type/normalize seem identical ex [Tue Oct 10 22:57:52 2017] cept constructor names). [Tue Oct 10 22:59:01 2017] If anyone has some hints or meta-advice like to move on come back later, I'm happy to hear it. I can paste code or something if useful, though the book says you shouldn't do that, so I'm not sure how's best to avoid causing problems for classes using the book but still get help. [Tue Oct 10 22:59:49 2017] The one thing I noticed in the solution I looked at that was really interesting was they did a replace that *seemed not to modify any goals* yet later steps fail without it. https://github.com/blindFS/Software-Foundations-Solutions/blob/master/Induction.v#L686 [Wed Oct 11 00:52:31 2017] Basically, A et B are equivalent if there is a function f : A -> B such that there is a function g : B -> A which is inverse of f [Wed Oct 11 00:52:46 2017] careful, it also needs to be surjective to get a useful notion of equaivalence :-) [Wed Oct 11 00:54:43 2017] s/equaivalence/equivalence/ [Wed Oct 11 00:54:54 2017] equaivalence must be something involving deep learning [Wed Oct 11 00:58:01 2017] although I guess it's also sufficient to require that both f and g are mutual inverses. [Thu Oct 12 11:49:56 2017] alright, if anyone finished vfa, could he /msg me his definition of priqueue_elems ? it seems that there are many possibilities, but each one I tried got me stuck at abs_perm, which is only rated 2 stars [Thu Oct 12 11:50:10 2017] so I suppose I am missing something obvious [Thu Oct 12 11:52:28 2017] Could you /msg me your definition, so that I can try to hint at it? (Or if you really just want a solution, I'll give you mine directly, as you wish.) [Thu Oct 12 11:52:41 2017] sure [Fri Oct 13 13:04:40 2017] dh`: in virtue of f/g being functions (i.e., functional relations) and mutual inverses, injectivity and surjectivity follow for free (in the finite case; but then, in the infinite case "surjective" doesn't mean what one might want it to anyways) [Fri Oct 13 13:06:00 2017] dh`: of course, this is a peculiarity of sets. Other structures won't necessarily get isomorphism for free [Fri Oct 13 17:52:33 2017] has anybody put out, like [Fri Oct 13 17:53:21 2017] some kind of library intended to provide the baseline definitions and theorems of stuff like the untyped lambda calculus or whatever - [Fri Oct 13 17:53:50 2017] Something like http://iron.ouroborus.net/ ? [Fri Oct 13 17:53:52 2017] but optimized for ability to take some new thing you're learning about and try formalizing it without going thru the pain of having to redo the basic [Fri Oct 13 17:54:14 2017] Ah. No idea x) [Fri Oct 13 17:54:14 2017] oh that actually sounds kind of like what im looking for :D [Fri Oct 13 17:54:20 2017] oh mb not then [Fri Oct 13 17:54:55 2017] (to be precise - im reading about denotational semantics for haskell & i was thinking itd be nice to be able to try to write down formal definitions - except that i dont wanna go thru the pain of building the language id be giving semantics to) [Fri Oct 13 17:56:45 2017] benzrf: yeah, Ott [Fri Oct 13 17:57:03 2017] benzrf: it will generate a whole bunch of substitution theorems for you automatically from a core definition of lambda calculus [Fri Oct 13 17:57:08 2017] o: [Fri Oct 13 17:57:27 2017] Stephanie Weirich used it in her DeepSpec class this summer [Fri Oct 13 17:57:45 2017] along with a tool called lngen that generates even *more* theorems relating to the locally nameless representation [Fri Oct 13 17:58:02 2017] oh sick :D [Fri Oct 13 17:58:09 2017] it was pretty eant [Fri Oct 13 17:58:19 2017] basically, you don't have to do any of the "core theory", just your semantics on top [Fri Oct 13 17:58:20 2017] hmm this kind of reminds me of redex [Fri Oct 13 17:58:26 2017] from the tiny tiny amount of redex ive looked at [Fri Oct 13 17:58:45 2017] then there's the "bound" style monadic substitution [Fri Oct 13 17:58:52 2017] which, depending on what your doing, can be WAY simpler [Fri Oct 13 17:58:57 2017] god there's so many takes on lambda calc out there [Fri Oct 13 17:59:01 2017] but as with anything, it's all about tradeoffs [Fri Oct 13 17:59:03 2017] yep [Fri Oct 13 17:59:04 2017] i wanna learn all of them [Fri Oct 13 17:59:07 2017] what sohuld i read [Fri Oct 13 17:59:25 2017] has anybody written a proper textbook surveying this landscape [Fri Oct 13 17:59:29 2017] read up on de bruijn, locally nameless, HOAS, PHOAS, and "bound" style [Fri Oct 13 17:59:33 2017] good question [Fri Oct 13 17:59:39 2017] I wonder if TAPL covers any of it [Fri Oct 13 17:59:45 2017] o.o [Fri Oct 13 17:59:47 2017] I think the "bound" style is fairly unknown in the literate [Fri Oct 13 17:59:52 2017] I was only able to find one academic paper on it [Fri Oct 13 17:59:57 2017] what's that? [Fri Oct 13 18:00:01 2017] one sec [Fri Oct 13 18:00:22 2017] https://www.seas.upenn.edu/~plclub/poplmark/ covers a lot of styles, I think they have papers associated to each? [Fri Oct 13 18:00:35 2017] tangentially: i also want to do a survey of the trillions of kinds of semantics for propositional logic [Fri Oct 13 18:00:40 2017] it's all so delightful [Fri Oct 13 18:00:50 2017] benzrf: http://www.cs.uwyo.edu/~jlc/courses/5000_fall_08/debruijn_as_nested_datatype.pdf [Fri Oct 13 18:01:04 2017] Cypi: o= [Fri Oct 13 18:01:15 2017] johnw_: 403 [Fri Oct 13 18:01:20 2017] but "nested datatype" =- [Fri Oct 13 18:01:23 2017] i think i might know what you mean... [Fri Oct 13 18:01:36 2017] benzrf: are you a US citizen? if so, you should apply to intern with my company :) or someplace similar, like Galois [Fri Oct 13 18:01:49 2017] i actually tried applying to galois last year but they rejected me [Fri Oct 13 18:01:50 2017] oh, :( [Fri Oct 13 18:01:52 2017] >:o [Fri Oct 13 18:01:55 2017] what company are you at? [Fri Oct 13 18:02:02 2017] right, do you mean this https://hackage.haskell.org/package/bound [Fri Oct 13 18:02:05 2017] BAE Systems, in Boston [Fri Oct 13 18:02:09 2017] yeah, the bound library is based on this idea [Fri Oct 13 18:02:27 2017] oh yikes defense contracting [Fri Oct 13 18:02:35 2017] yeah, but it's public-facing DARPA work in formal methods [Fri Oct 13 18:02:49 2017] hm [Fri Oct 13 18:02:53 2017] what's your e-mail? I'll mail you the article [Fri Oct 13 18:03:00 2017] its ok [Fri Oct 13 18:03:09 2017] i never actually manage to get very far in pdfs ;-; [Fri Oct 13 18:03:14 2017] i mostly just wanted to know the basic idea [Fri Oct 13 18:03:35 2017] then watch these: https://www.slideshare.net/ekmett/bound-making-de-bruijn-succ-less [Fri Oct 13 18:04:12 2017] the basic idea is that you parameterize your variable type in the syntax, and make it into a monad; once you do that, >>= becomes substitution [Fri Oct 13 18:04:27 2017] yeah [Fri Oct 13 18:04:29 2017] i saw bound for the first time actually about a month ago [Fri Oct 13 18:04:49 2017] Joachim used it on a project recently in Coq, and it simplified SO many proofs [Fri Oct 13 18:04:58 2017] i guess the bound package itself is a slight twist on the idea youre talking about [Fri Oct 13 18:05:01 2017] optimizing substitution or something [Fri Oct 13 18:05:09 2017] but the idea itself i played aronud with a little bitonic [Fri Oct 13 18:05:10 2017] mainly because the way he was using lambda calc coincided with the sweet spot for this represetation [Fri Oct 13 18:05:12 2017] *bit [Fri Oct 13 18:05:16 2017] and i love it [Fri Oct 13 18:05:19 2017] bound is a Haskell implementation of the idea, as far as I understand it [Fri Oct 13 18:05:55 2017] >Logically you can think of this as if the shape were the traditional f (Var b a), but the extra f a inside permits us a cheaper lift. [Fri Oct 13 18:06:50 2017] but yeah if i understood what i was doing correctly it basically ends up making it so that being parametric guarantees hygiene??? [Fri Oct 13 18:06:52 2017] that's fucking sick [Fri Oct 13 18:07:09 2017] not even using dependent types or anything =D [Fri Oct 13 18:07:14 2017] yep [Fri Oct 13 18:07:17 2017] it's pretty damn sweet [Fri Oct 13 18:07:59 2017] i shd probably learn sml at some point [Fri Oct 13 18:08:06 2017] why? [Fri Oct 13 18:08:36 2017] i read a post or two by bob harper that ripped on haskell & it reminded me that im a bit myopic when it comes to functional programming as something broader than just haskell [Fri Oct 13 18:08:46 2017] also, moduels sound extremely good [Fri Oct 13 18:08:49 2017] i think the differences in syntax are pretty meaningless [Fri Oct 13 18:08:57 2017] im not just talking about syntax [Fri Oct 13 18:08:58 2017] master what's underneath, then translate [Fri Oct 13 18:09:14 2017] sml is strict and impure, among other things [Fri Oct 13 18:09:19 2017] that changes a LOT [Fri Oct 13 18:09:30 2017] I'd rather understand System FC better than learn another surface language [Fri Oct 13 18:09:47 2017] neither haskell nor sml is system fc [Fri Oct 13 18:10:02 2017] oh wait [Fri Oct 13 18:10:10 2017] i was thinking of system f - not sure what system fc is [Fri Oct 13 18:10:13 2017] lol [Fri Oct 13 18:10:20 2017] system f with polymorphic types, I thought [Fri Oct 13 18:10:27 2017] oh [Fri Oct 13 18:11:15 2017] well, even apart from that, /programming/ as an activity is qualitatively different from working with the formalisms that underlie language design [Fri Oct 13 18:11:32 2017] no doubt [Fri Oct 13 18:11:33 2017] hm i shd go eat dinner soon [Fri Oct 13 18:11:48 2017] better to understand digestion ;) [Fri Oct 13 18:32:37 2017] johnw: if youre still there: is this not equivalent to just "f(x) <= g(x)" https://i.imgur.com/uY55gJ8.png [Fri Oct 13 18:33:53 2017] ok nvm i thought it thru and its equivalent [Fri Oct 13 18:34:01 2017] i was avoiding hashing it out because im tired >.> [Fri Oct 13 22:48:10 2017] god i need to pick up some ett [Fri Oct 13 22:51:09 2017] im reading more posts on bob harper's blog and it's really reminding me how little i actually know :V [Fri Oct 13 22:53:19 2017] hmm https://i.imgur.com/rbiuZT4.png [Fri Oct 13 22:54:34 2017] i once downloaded and spun up a nuprl vm [Fri Oct 13 22:54:39 2017] and then i never really did anything with it [Fri Oct 13 22:55:15 2017] but whenever i look at stuff about nuprl, it feels like theres a gigantic universe there that i keep forgetting exists [Fri Oct 13 22:58:07 2017] someone smack me every day until i acquiesce to actually sitting down and reading some primary sources [Fri Oct 13 22:58:11 2017] like, martin-löf or something [Sat Oct 14 07:52:03 2017] benzrf: https://www.ps.uni-saarland.de/autosubst/ is nice btw, but i've only used it to prove the normalization stuff in SF for lambda calculus, and it's probably mentioned somewhere if you go through the poplmark stuff. [Sat Oct 14 07:52:17 2017] (regarding the binders discussion above.) [Sat Oct 14 09:19:16 2017] cic: yeah i actually tried using autosubst for formalizing FOL and it turned out it doesnt handle so well that kind of nested type thing [Sat Oct 14 09:19:27 2017] (prop type and expr type, vars bound in prop type and appear in expr type) [Sat Oct 14 11:40:50 2017] "prop type and expr type, vars bound in prop type and appear in expr type" interesting.. i been fighting with the acceptance (though i definately accepted by now) that i have to maintain the two typesystems [Sat Oct 14 11:42:48 2017] (for my homespun inference engine) [Sat Oct 14 12:22:05 2017] hm, do you have some instance of this problem to illustrate, because i don't follow. (it's not that i think i can solve it, i just want to know what's going on :p) [Sun Oct 15 10:17:23 2017] is there a way to do a "match goal" on a match expression without specifying the list of matches? [Sun Oct 15 10:17:57 2017] there is a "match foo" with with tons of coases, and I would just like to write something like [Sun Oct 15 10:18:15 2017] match goal with | _ |- match ?x with _ end => ... [Sun Oct 15 10:21:58 2017] ah, managed to google it [Sun Oct 15 10:25:57 2017] bartavelle, so what is the syntax? [Sun Oct 15 10:28:23 2017] found a SO answer, but can't make it work [Sun Oct 15 10:28:31 2017] https://stackoverflow.com/questions/28454977/how-to-match-a-match-expression [Sun Oct 15 10:30:31 2017] argh; found out why this didn't work [Sun Oct 15 10:30:45 2017] I appended a ;simpl. at the end of my match goal, so what I was seing could not be matched :) [Sun Oct 15 10:46:14 2017] cic: first-order logic syntax has separate grammars for propositions and expressions, with the latter appearing nested in the former [Sun Oct 15 10:46:28 2017] cic: forall and exists bind variables, but the variables get used in the expressions [Mon Oct 16 22:44:48 2017] i shd probably learn sml at some point [Mon Oct 16 22:44:54 2017] (yeah that's deep in the scroll) [Mon Oct 16 22:45:05 2017] sml is kinda crap, tbh [Mon Oct 16 22:49:47 2017] dh`: How so? [Mon Oct 16 22:52:11 2017] I mean, the infrastructure is bad, but the language seems alright (if a bit dated). [Mon Oct 16 22:58:05 2017] it's pretty dated [Mon Oct 16 22:58:13 2017] and most of the implementations are bitrotten [Mon Oct 16 22:58:23 2017] I haven't been able to get a reliably working smlnj build [Mon Oct 16 22:59:01 2017] same with mosml [Mon Oct 16 22:59:18 2017] and mlton isn't really being worked on any more either, afaict. [Mon Oct 16 23:00:52 2017] also, there was a change to the spec in the late 90s that outlawed certain kinds of sharing declarations, and the result of that is that you pretty much lose the ability to have any abstraction/encapsulation in sharing-heavy module families. [Mon Oct 16 23:01:52 2017] ocaml seems to be strictly superior from a point of view of actual code. [Mon Oct 16 23:11:23 2017] o [Mon Oct 16 23:50:31 2017] dh`: Indeed. I must admit one of my big problems with SML is the lack of any standard FFI. [Tue Oct 17 00:28:27 2017] oh, also, in sml "o" is an infix operator, which is just amazingly bizarre to look at. [Tue Oct 17 00:28:49 2017] someone should write a sml -> ocaml translator; there's just enough syntactic differences for doing it by hand to be really annoying. [Tue Oct 17 06:56:25 2017] dh`: yeah, OCaml more than caught up to SML in recent years. It used to be that sml had some small edges (like generative functors for example), but no longer... [Tue Oct 17 09:41:50 2017] has OCaml still the issues with multithreading/parallelism I'd heard people complain of? [Tue Oct 17 11:47:10 2017] hodapp: Yes. OCaml still has a single threaded GC. Though this is finally getting seriously addressed [Tue Oct 17 11:47:54 2017] See the multicore effort [Wed Oct 18 00:49:40 2017] is compcert's cpp verified? [Wed Oct 18 00:52:59 2017] I don't think parsing and preprocessing are verified [Wed Oct 18 00:53:06 2017] (if "cpp" meant preprocessing) [Wed Oct 18 00:53:58 2017] http://compcert.inria.fr/motivations.html explicitely states it I think [Wed Oct 18 00:54:05 2017] (search for "preprocessing") [Wed Oct 18 09:07:46 2017] are there any coq projects I could help with? I had some fun proving some basic number theory stuff, maybe there are a few projects where I could help out and actually prove something useful? [Wed Oct 18 17:30:42 2017] Is there a tactical that allows me to apply a tactic to all current subgoals? I'm aware of using ";" but that's sort of "apply this tactic to all subgoals generated by this other tactic". I just want to apply a tactic to all current subgoals, regardless of how they were generated. [Wed Oct 18 17:30:46 2017] I hope that makes sense. [Wed Oct 18 17:34:38 2017] buttbutt1r: I think there's a thing called "goal selectors" [Wed Oct 18 17:36:21 2017] https://coq.inria.fr/refman/ltac.html#hevea_tactic210 [Wed Oct 18 17:37:46 2017] So, `all: reflexivity.` for instance. [Wed Oct 18 18:13:51 2017] Chobbes: Oh, cool. That's precisely what I want. [Wed Oct 18 18:13:53 2017] Thanks! [Wed Oct 18 18:16:42 2017] buttbutt1r: no problem! I have to say, I'm curious, though. I find that `;` is sufficient for what I have done to date! Why the desire for `all`? Just structuring differently, and you found that after some simplification your goal became the same as other subgoals? [Wed Oct 18 18:20:12 2017] Is there a neat way for working with vectors? [Wed Oct 18 18:20:26 2017] xuanrui: what do you mean? [Wed Oct 18 18:21:01 2017] so that I don't have to do Vector.everything when I work with them [Wed Oct 18 18:21:15 2017] more of a notational efficiency concern [Wed Oct 18 18:22:11 2017] xuanrui: oh god, yeah. I think there is a way, but I haven't gotten annoyed enough yet. If you don't import lists I think you can avoid Vector.cons and so forth and just write cons. [Wed Oct 18 18:22:41 2017] Alas [Wed Oct 18 18:22:49 2017] I guess I have to live with it for a while, then [Wed Oct 18 18:22:59 2017] Can I avoid writing (Vector.nil A) then [Wed Oct 18 18:23:22 2017] so that I don't have to write the type argument all the time [Wed Oct 18 18:24:28 2017] You could define nil' with an implicit argument, maybe? [Wed Oct 18 18:24:33 2017] maybe [Wed Oct 18 18:24:49 2017] It's a little annoying to unfold sometimes, but that should work. [Wed Oct 18 18:27:04 2017] Chobbes: I'm kind a giant noob, so my approach is probably wrong. But when I use ";" often--say--3 subgoals are similar and then there are 2 outliers (that are similar to eachother). So the tactics you use with the ";" might work for the first 3, but not the last 2. So seems like a nice place to use a goal selector. [Wed Oct 18 18:27:34 2017] (i.e. after you've taken care of the first 3 subgoals, then use a goal selector to take care of the last 2) [Wed Oct 18 18:27:39 2017] But yeh, I dunno what I'm doing. [Wed Oct 18 18:27:55 2017] buttbutt1r: ah, I see! [Wed Oct 18 18:28:56 2017] buttbutt1r: you can handle this all with ";". Maybe it's not always better to do so, though. [Wed Oct 18 18:29:34 2017] Chobbes: I know you could. For example using try tactics, right? [Wed Oct 18 18:29:49 2017] But seems like it's more readable to not handle it all with ;. I dunno. [Wed Oct 18 18:30:00 2017] tacticals* not tactics. [Wed Oct 18 18:30:01 2017] buttbutt1r: yeah, but I think you're right. It could be a lot better to just use all. [Wed Oct 18 18:30:24 2017] :) [Wed Oct 18 18:36:04 2017] xuanrui: might be of interest: http://coq-club.inria.narkive.com/Nr2nabab/qualified-imports [Wed Oct 18 18:41:21 2017] Thanks! [Wed Oct 18 20:01:00 2017] where is the PG tutorial file!? i lost.. [Wed Oct 18 20:56:40 2017] I wonder how you'd phrase this in Coq: given a function any {A B} (P : A -> B) (xs : list A), how can I prove that every 'x : A' which is passed to P during the execution of 'any' came from xs? Parametricity implies this, but I'm wondering how I word the theorem. I want to derive evidence, within P, that the 'x' under consideration is in 'xs'. [Wed Oct 18 20:58:52 2017] What do you mean, "within P"? Would anything resembling "{A B} (xs : list A) (P : {x : A | In x xs} -> B)" be what you're asking for? [Wed Oct 18 20:59:00 2017] example: [Wed Oct 18 20:59:13 2017] any (P:=fun x => foo x) xs [Wed Oct 18 20:59:24 2017] but what if foo needs a witness List.In x xs [Wed Oct 18 20:59:45 2017] i mean, I know this parametrically; where else could the 'x' have come from [Wed Oct 18 20:59:55 2017] but I don't have the witness handy [Wed Oct 18 21:00:17 2017] and yes, the type you gave provides the evidence [Wed Oct 18 21:00:25 2017] but I'm not able to redefine 'any' in my context [Wed Oct 18 21:00:48 2017] Ok, I see what you mean now. [Wed Oct 18 21:02:55 2017] My instinct tells me it shouldn't be possible. For instance if you consider `@any nat nat`, then you certainly can't prove that anything given to P is in xs (basically, the same for any actual instantiation of A). So what you ask only makes sense if you don't have a specific A, which means you probably can't have what you want in general, right? [Wed Oct 18 21:03:33 2017] what about the parametricity argument? [Wed Oct 18 21:03:52 2017] since 'any' is parametric in A, it cannot fabricate any term of type A [Wed Oct 18 21:04:00 2017] it must have come from the list [Wed Oct 18 21:05:00 2017] alright, my sentence was probably wrong on second glance. What about a more compelling argument: wouldn't it contradict in some way excluded middle for instance? [Wed Oct 18 21:05:29 2017] any could be implemented as "match xs with [] => True | a :: _ => `something involving excluded middle to get an arbitrary (a : A)" [Wed Oct 18 21:05:48 2017] but you can't do that...? [Wed Oct 18 21:05:55 2017] why? [Wed Oct 18 21:06:01 2017] I don't have LEM [Wed Oct 18 21:06:46 2017] Well yes, but Coq is supposed to be consistent with excluded-middle. So I guess my point is that what you are asking for can only be a meta-theorem. [Wed Oct 18 21:07:02 2017] yes, I think you're right [Wed Oct 18 21:07:03 2017] (I may be wrong, but honestly I am not even sure how you would state this) [Wed Oct 18 21:07:11 2017] people have told me before that I can't have parametricity theorems except as axioms [Wed Oct 18 21:07:16 2017] or, in specific cases [Wed Oct 18 21:07:28 2017] such as Maxime's work on refinements for free [Wed Oct 18 21:08:02 2017] johnw: parametricity is an external fact [Wed Oct 18 21:08:37 2017] as Cypi pointed out, baseline coq is consistent with classical math (more or less), so it can't contradict classical math, and parametricity does not hold in classical math [Wed Oct 18 21:09:12 2017] how do you determine the last part of your statement? [Wed Oct 18 21:09:13 2017] proving parametricity relies on analyzing what kind of constructs exist in the language, and you can't introspect like that [Wed Oct 18 21:10:35 2017] well, it depends on the specifics, but broadly speaking i just mean that classical math lets you construct highly pathological functions with special-case-y behavior [Wed Oct 18 21:11:50 2017] e.g., you can write down "f does thing X when used with types that arent equal to nat, and thing Y when used with types that are equal to nat", and then you have a function which does that [Wed Oct 18 21:15:03 2017] https://gist.github.com/37d6cb4d88da54162cedc75ef8cced05 [Wed Oct 18 21:15:09 2017] here's a brief example of what I'm trying to do [Wed Oct 18 21:15:52 2017] it seems well-founded, if I know the relationship of subterm [n] to [xs'] [Wed Oct 18 21:30:57 2017] johnw: just in case it helps, you can define this as a nested recursion http://lpaste.net/359354 [Wed Oct 18 21:39:37 2017] Also it's a bit sad, but with a slightly different definition of any, it would work: http://lpaste.net/359355 [Wed Oct 18 21:40:08 2017] in the second definition you do the fixpoint a bit later, so you can actually reduce the application of `any'` to a predicate [Wed Oct 18 21:40:57 2017] in the first definition, if you just apply `any` to a predicate, well, you get a fixpoint applied to something (which is not its principal argument in constructor form), so you can't reduce it [Wed Oct 18 22:09:52 2017] ooh, this cofinite quantification thing is interesting https://www.cis.upenn.edu/~bcpierce/papers/binders.pdf [Wed Oct 18 22:10:13 2017] what exactly is the benefit of locally nameless over using only de bruijn indices? [Wed Oct 18 22:16:32 2017] looks like the point is to avoid too much complication with shifting lemmas [Wed Oct 18 22:16:40 2017] https://www.chargueraud.org/research/2009/ln/main.pdf looks like a good explanation [Wed Oct 18 22:21:22 2017] buhh [Wed Oct 18 22:21:31 2017] i shd try printing these papers out so i can read them without getting distracted [Wed Oct 18 22:21:36 2017] but the type would be so small... [Wed Oct 18 22:22:14 2017] I mean, you don't need to read everything, he gives enough motivation in the first few paragraphs x) [Wed Oct 18 23:37:37 2017] Mmmm. Has anybody encountered a problem with PG / company coq where sometimes when you open a new buffer after it has been opened for a while it 1) doesn't do any syntax highlighting, and 2) doesn't do any proof general stuff? It seems to be stuck in fundamental mod. [Thu Oct 19 00:07:30 2017] cypi: parsing is verified, there's a version of menhir (I think it went into menhir mainline, but not sure) that emits certified parsers in coq [Thu Oct 19 00:09:09 2017] so I was wondering about cpp, not really sure where to look other than wade into the source tree [Thu Oct 19 00:17:42 2017] which I can do obviously, but I was hoping someone already knew :-) [Thu Oct 19 00:28:17 2017] hmm, the posted manual notes the parser is verified and says the rest of the front bits aren't yet [Thu Oct 19 00:28:35 2017] wonder if anyone over there's working on it [Thu Oct 19 00:36:53 2017] Cypi: so I have to hand overfold 'any', even though the definition is the same? [Thu Oct 19 00:37:23 2017] Cypi: I see, any' is like doing pattern on the recursive argument [Thu Oct 19 01:28:55 2017] johnw: did you see the comments a few days ago about the fib exercise? [Thu Oct 19 01:29:34 2017] no [Thu Oct 19 01:57:56 2017] I made a fib, and then someone else (I think Cypi) made a better one [Thu Oct 19 01:58:14 2017] mine's here: http://codepad.org/nsQpyeHY [Thu Oct 19 01:59:29 2017] the other one's here: http://lpaste.net/359084 [Fri Oct 20 02:02:16 2017] do you guys know of companies investing in formal methods research? I can think of a few, but I was wondering which ones Google wasn't turning up... [Fri Oct 20 09:41:59 2017] what's the difference between ":" and ":>" in class definitions? [Fri Oct 20 09:42:05 2017] (for type signatures) [Fri Oct 20 09:42:44 2017] `:>` declares a coersion [Fri Oct 20 09:42:57 2017] ah, i see [Fri Oct 20 09:43:17 2017] so i can easily go to more general structures [Fri Oct 20 09:51:06 2017] can i query the definition of a Notation? [Fri Oct 20 09:51:23 2017] use case: what does "x = y" desugar to? [Fri Oct 20 09:52:16 2017] you can `Locate "=".` [Fri Oct 20 09:52:24 2017] or `Print "=".` [Fri Oct 20 09:52:50 2017] oh, indeed… thanks [Fri Oct 20 09:55:17 2017] one more question: is there a predefined extensional equality relation for functions with all the usual instances? [Fri Oct 20 09:57:06 2017] not that I'm aware off, but I vaguelt remember that stuff appeared on Coq-Club several years ago (IIRC Andrej Bauer was the OP) [Fri Oct 20 09:57:15 2017] *vaguely [Fri Oct 20 09:57:35 2017] * off = of [Fri Oct 20 10:02:45 2017] hmm, ok… kinda expected it to be in the standard library =) [Fri Oct 20 10:03:02 2017] i'll see what i can find (or just define it myself) [Fri Oct 20 10:04:13 2017] is there a best-practices guide? or perhaps a cheat sheet of convenience functions i should know about? especially with regard to implicits and notations [Fri Oct 20 10:05:32 2017] doing those by hand in the context of sections and classes is rather noisy =) [Fri Oct 20 10:07:56 2017] Probably this can be useful: https://sympa.inria.fr/sympa/arc/coq-club/2016-11/msg00113.html [Fri Oct 20 10:14:00 2017] hmm… not very satisfying =/ [Fri Oct 20 10:14:13 2017] I agree [Fri Oct 20 10:14:26 2017] i wish infix notation was just first class syntax in coq, like in agda [Fri Oct 20 10:14:59 2017] that would be awesome [Fri Oct 20 10:36:17 2017] what does "`" (backtick) mean? i found quite a few resources using it, but never explaining it [Fri Oct 20 10:37:58 2017] ah, apparently it says: "use generalisable variables" [Fri Oct 20 10:38:33 2017] it's a shorthand [Fri Oct 20 10:39:02 2017] it allows us not to write extra variables under forall [Fri Oct 20 10:45:22 2017] yeah, thanks [Sat Oct 21 03:47:46 2017] is there some reason that passing a recursive call to myself to fold_left isn't allowed for functions that have an explicit measure? [Sat Oct 21 03:48:26 2017] it's accepted if I let coq pick a decreasing argument itself (apparently) but that doesn't work for this function [Sat Oct 21 03:50:27 2017] or, more pertinently, is there a way around the issue? [Sat Oct 21 04:30:33 2017] I think there is an example in software foundations where the authors write a fixpoint and shows a way to manually prove the function terminates [Sat Oct 21 04:30:39 2017] can't find it though [Sat Oct 21 04:30:51 2017] and not sure that would be what you are looking for [Sat Oct 21 04:34:04 2017] yeah can't find it, must have dreamed it :/ [Sat Oct 21 04:43:21 2017] that's what I was doing [Sat Oct 21 04:43:55 2017] Function foo (arg: regexp * string) {measure: height arg} := ... [Sat Oct 21 04:44:06 2017] er, without the colon on the measure I think [Sat Oct 21 04:47:25 2017] the problem is that it won't let me call fold_left (fun ... => foo (r', s') ... [Sat Oct 21 04:48:39 2017] proving that (r', s') there is smaller than the original arg would be tedious, but it should certainly be possible. [Sat Oct 21 04:48:55 2017] given what the fold is. [Sat Oct 21 07:28:57 2017] hi, I'm currently going through Coq tutorial on https://softwarefoundations.cis.upenn.edu/lf-current/. there is a bunch of .v files to download; I'm using CoqIde, previously with Coq 7.3 (really), now upgraded to 8.6 [Sat Oct 21 07:29:30 2017] now there is Basics.v with definitions of some fixpoints like beq_nat [Sat Oct 21 07:29:47 2017] I've succesfully compiled Basics.v, .vo file has been created [Sat Oct 21 07:30:56 2017] another file, Induction.v, contains Require Export Basics, and uses beq_nat in some theorems [Sat Oct 21 07:32:17 2017] if I click Forward one command multiple times (or Go to end), everything works fine, the theorem that uses beq_nat gets defined, also Search "beq_nat" finds what I need [Sat Oct 21 07:32:35 2017] however, if I try to compile Induction.v, I get Error: The reference beq_nat was not found in the current environment. [Sat Oct 21 07:32:57 2017] this worked fine in 7.3 (even though I had to remove the bullets since they weren't supported) [Sat Oct 21 07:33:09 2017] any ideas what to do? [Sat Oct 21 08:17:03 2017] (okay, it has been 8.3 previously, not 7.3) [Sat Oct 21 08:27:29 2017] also, Print LoadPath. shows the folder with .v files in it [Sat Oct 21 08:36:54 2017] oh, it looks like I found the problem - if I run the program with the arrows, Print Libraries shows that Basics (from the current folder) has been loaded, but when I compile, it shows Coq.Program.Basics instead [Sat Oct 21 08:37:15 2017] still not sure how to fix this, but at least I'm closer [Sat Oct 21 08:46:33 2017] OK, looks like I partially fixed this with Add LoadPath "/path/to/v/files". It's a little bit annoying to add this to all files, so I'd still like to hear some suggestions for a better solution :-) [Sat Oct 21 10:59:18 2017] duri`: hmmm. You shouldn't have to change anything. [Sat Oct 21 11:50:21 2017] Chobbes: I've also thought so. We have a Coq seminar group and from about 10 people, one guy also had the same problem (and I observe this since today) [Sat Oct 21 11:59:51 2017] I've had similar problems, but it was from using an old version of ProofGeneral which didn't understand _CoqProject files. And the problem manifested itself in ProofGeneral, not on the command line. [Sat Oct 21 12:00:13 2017] (Also, to my knowledge, SF doesn't even use _CoqProject, so this is irrelevant) [Sat Oct 21 17:20:14 2017] there's a command-line option to add stuff to the include path; using that will be easier than adding stuff to evry file [Sat Oct 21 17:20:21 2017] s/evry/every/ [Sat Oct 21 19:46:16 2017] Hi guys. I installed CoqIDE on mac. It worked for a few hours. Now suddenly the keyboard shortcut cmd+ctrl+right arrow (which is "go to cursor") has stopped working. [Sat Oct 21 19:46:32 2017] Instead, it makes a beep sound as if the command is forbidden. However, it works if I select it from the menu or if I click on the toolbar. [Sat Oct 21 19:46:56 2017] Also, on the menu I see a different keyboard shortcut than before (maybe for windows?) it doesn't show the cmd icon as it was earlier. [Sat Oct 21 19:46:59 2017] I didn't change any settings. [Sat Oct 21 19:47:04 2017] I don't know what has caused it. [Sat Oct 21 19:47:06 2017] Any hints? [Sat Oct 21 20:20:03 2017] dionyziz: i dont know sorry [Sat Oct 21 20:20:08 2017] better keep waiting :I [Sat Oct 21 21:28:47 2017] benzrf: Thanks :) If anyone else knows, please ping me, I'm still here. [Sat Oct 21 21:30:57 2017] have you quit out and restarted it? [Sun Oct 22 06:22:28 2017] dh`: Yes, I tried restarting the program and my computer. [Sun Oct 22 06:23:32 2017] Quick question: If I have in my hypotheses a witness of type exists x, (p x)... is it possible to extract that x somehow? [Sun Oct 22 06:24:22 2017] yes, use `destruct` on that hypothesis [Sun Oct 22 06:25:10 2017] of course, you won't be able to extract the original witness that has been used to prove `exists` [Sun Oct 22 06:25:48 2017] ah, yes, I see. thanks! [Sun Oct 22 18:46:13 2017] Is it just me, or is proving r_star_trans impossible here? http://lpaste.net/8184976367771713536 [Sun Oct 22 18:46:37 2017] R_star is supposed to be the reflexive transitive closure of some relation R. [Sun Oct 22 18:46:45 2017] So I'm trying to show that R_star is transitive :) [Sun Oct 22 18:52:41 2017] buttbutter: I don't think this is a transitive closure, as this only allows one transitive step. [Sun Oct 22 18:53:40 2017] (if you know `R x y`, `R y z` and `R z t`, then you know `R x z` or `R y t`, but not `R x t`, for instance) [Sun Oct 22 18:54:41 2017] Ah, I knew something was wrong in my definition. [Sun Oct 22 18:55:17 2017] Sec, let me think about how to fix it. [Sun Oct 22 18:57:49 2017] Cypi: http://lpaste.net/57217760475742208 [Sun Oct 22 18:57:53 2017] I think that did it [Sun Oct 22 18:58:08 2017] Yup, now it's definitely transitive [Sun Oct 22 18:58:23 2017] Makes a lot more sense like this. Thanks for the help. [Sun Oct 22 19:04:06 2017] Cypi: I'm not sure if this is possible, but how can I generalize R_Star to any relation? Instead of just R? i.e., I want to prove a theorem involving a relation R and a relation T as well as their reflexive-transitive closures. [Sun Oct 22 19:07:12 2017] I guess I sort of want something like Inductive star : R -> X -> X -> Prop := ... where R is a relation with type X -> X -> Prop. But Coq complains. [Sun Oct 22 19:09:58 2017] You've nearly done it actually. X and R are declared with the Variables vernacular, so if you put everything in a Section, it will generalize over X and R [Sun Oct 22 19:10:10 2017] (put "Section some_name." before the declaration of X and R) [Sun Oct 22 19:10:20 2017] (and then you'll need to close the section with "End some_name.") [Sun Oct 22 19:11:03 2017] Another possibility is to write something like `Inductive star (X : Type) (R : Prop) : X -> X -> Prop := ...` [Sun Oct 22 19:11:23 2017] I mean, `Inductive star (X : Type) (R : X -> X -> Prop) : X -> X -> Prop := ...` [Sun Oct 22 19:13:00 2017] Ah. I guess that sort of brings up another thing for me: is doing something like Inductive star (X : Type) (R : X -> X -> Prop) := stuff the same as Inductive star := | rule1 : forall (X : Type) (R : X -> X -> Prop), ... (and then each rule has a similar forall statement)? [Sun Oct 22 19:13:29 2017] Sorry if these questions are sort of "lazy". I'll go read the documentation on my own if you don't want to bother. :) [Sun Oct 22 19:13:44 2017] Not exactly. In the first case, X and R are called parameters, and they need to be uniform in every constructor (that is, every constructor needs to end with `star X R ...` basically) [Sun Oct 22 19:13:56 2017] in the second case, they are called indices, and are not required to be the same in every constructor [Sun Oct 22 19:14:17 2017] Okay, but if I had the same indices in each cosntructor, then the two scenarios are identical, right? [Sun Oct 22 19:15:14 2017] Coq would still treat them differently. They would be a mix of parameters and indices (I don't remember the technical term) [Sun Oct 22 19:15:26 2017] (and I don't remember the precise differences :D ) [Sun Oct 22 19:16:24 2017] Ah, okay. Thanks for all the helpful information. I guess my last question is--is the Section treatment preferred or the "Inductive star (X : Type) (R : Prop) : " treatment preferred? [Sun Oct 22 19:17:02 2017] It depends, it's a stylistic choice. Note however that with a Section you won't need to recall X and R for every lemma that you are proving about R_star [Sun Oct 22 19:17:08 2017] (you can prove those lemmas in the section still) [Sun Oct 22 19:17:48 2017] Ah, true. That would be nicer. :) [Sun Oct 22 19:17:51 2017] Okay, great. Thanks! [Mon Oct 23 10:53:30 2017] I'm still not really sure what it means to use induction/inversion on hypotheses (instead of a variable, as I'm used to from math). Can anyone recommend a resource where I can read about this sort of induction? Software Foundations introduces it but doesn't really talk about what it means to my satisfaction, and I'd like to understand it better. [Mon Oct 23 11:09:36 2017] Could you clarify what you mean by that? Hypotheses and variables are pretty much the same thing. [Mon Oct 23 11:09:39 2017] Do you mean induction on derivation as opposed to let say induction on natural numbers? [Mon Oct 23 11:17:26 2017] I don't know what induction on derivation is. Traditionally, induction to me is sort of "okay, I have this base case and an inductive step". I.e. a single base case and a single inductive step. Generally, if I do induction on a hypothesis or on an inductive type that has multiple constructors, it's obviously not like that. [Mon Oct 23 11:17:31 2017] And it's just...foreign to me. [Mon Oct 23 11:17:41 2017] So I'm just looking for a resource that explains it. [Mon Oct 23 11:18:43 2017] What about course-of-values induction? You have only one step there... [Mon Oct 23 11:20:27 2017] I'm unfamiliar with course-of-values induction too. I only really know weak/basic induction. [Mon Oct 23 11:21:03 2017] https://en.wikipedia.org/wiki/Mathematical_induction#Complete_induction [Mon Oct 23 11:21:08 2017] So I guess I just want a clear resource that explains induction in Coq, aside from Software Foundations. Does that exist? [Mon Oct 23 11:22:51 2017] Winskel's book on semantics has some explanation of different types of induction [Mon Oct 23 11:24:12 2017] Perfect. This is for a semantics course anyway :) [Mon Oct 23 11:24:16 2017] Thanks. I'll take a look. [Mon Oct 23 11:24:18 2017] https://coq.inria.fr/distrib/current/files/RecTutorial.pdf [Mon Oct 23 11:24:37 2017] This tutorial might help [Mon Oct 23 11:25:05 2017] It explains induction more towards the end [Mon Oct 23 11:26:19 2017] Great. I guess what I'm confused about then is structural induction. [Mon Oct 23 11:26:36 2017] I think that's it at least. So I'll read about that :) [Mon Oct 23 11:26:45 2017] good luck! [Mon Oct 23 11:27:23 2017] Thanks for the help! [Mon Oct 23 11:27:38 2017] no prob :) [Tue Oct 24 08:35:34 2017] I have a premise that looks like this: [Tue Oct 24 08:35:39 2017] H : existT (fun ids : list id => stateP ids) ids b = existT (fun ids : list id => stateP ids) ids a [Tue Oct 24 08:35:59 2017] how to prove from it that a = b [Tue Oct 24 08:36:00 2017] ? [Tue Oct 24 08:45:45 2017] Ok, go it. inj_pair2_eq_dec from Coq.Logic.Eqdep_dec does the job [Tue Oct 24 09:05:50 2017] jstolarek: good thing it has a decidable equality, no axiom needed then [Tue Oct 24 10:14:32 2017] johnw: yes, had to prove decidable equality as a lemma, but that's better than an axiomn [Tue Oct 24 10:17:49 2017] jstolarek: yes, very much so :) [Tue Oct 24 10:18:06 2017] I find myself often written weird little side lemmas so that I can use Eqdep_dec whenever possible [Tue Oct 24 10:25:21 2017] jstolarek: good to see you here again, homework buddy :) [Tue Oct 24 10:25:36 2017] I'm going to be playing the recursion properties in Coq today [Tue Oct 24 10:26:19 2017] jonhw: nice to be back here. I on the other hand will be finishing for today [Tue Oct 24 10:26:35 2017] yes, I imagine so. Sleep well, and say hi to Poland for me [Tue Oct 24 10:26:36 2017] after spending yet another day on formalizing reasoning about program state [Tue Oct 24 10:26:46 2017] UK, not Poland ;-) [Tue Oct 24 10:27:03 2017] for the time being at least [Tue Oct 24 10:27:15 2017] oh right, why do I keep forgetting you're up there [Tue Oct 24 22:45:35 2017] I'm having some trouble defining the following function: https://pastebin.com/DnPcHqxr. Is my best shot going to be the Program libraries? [Tue Oct 24 22:46:51 2017] The third branch is the one I'm having trouble with. Otherwise, I could define it using Function. [Wed Oct 25 00:27:20 2017] When solving termination obligations using Program Fixpoint, how can I simplify goals containing the function being defined? The name appears in the goal, but Coq complains that it isn't an evaluable reference. [Wed Oct 25 08:29:35 2017] How can you unfold notation in a proof? [Wed Oct 25 08:30:03 2017] yes, `unfold "notation".` [Wed Oct 25 08:30:21 2017] I get an error that it's not a reference. [Wed Oct 25 08:30:39 2017] "Unable to interpret "<=2" as a reference", specifically. [Wed Oct 25 08:30:56 2017] can you show your proof? [Wed Oct 25 08:31:01 2017] Yeah, I'll paste it. Sec. [Wed Oct 25 08:32:25 2017] http://lpaste.net/1356292071543013376 [Wed Oct 25 08:43:39 2017] hmmm, this is interestion. I didn't encounter an error like this before. [Wed Oct 25 08:49:48 2017] I don't think you can unfold one specific notation, afaik [Wed Oct 25 08:50:16 2017] You might be able to when the Notation is really just replacing the name of a function (something like "Notation value := Some.") [Wed Oct 25 08:50:40 2017] in this case it will just unfold the underlying function [Wed Oct 25 08:50:45 2017] but in general, I don't think you can. [Wed Oct 25 08:51:14 2017] hmm can't you unfold not and such? [Wed Oct 25 08:51:47 2017] not is a function [Wed Oct 25 08:52:25 2017] and the notation for it would be treated as an alias for "not", I guess [Wed Oct 25 08:52:55 2017] "~ x" := not x : type_scope (default interpretation) [Wed Oct 25 08:56:41 2017] Apparently we can unfold "+", "~" a bunch of other notations involving parameters. [Wed Oct 25 08:57:57 2017] I don't see the reason not to be able to unfold this one, since Coq does that internally. [Wed Oct 25 08:58:22 2017] it's not the parameters the problem. ~ can be directly mapped to a constant called not. + can be directely mapped to a constant called plus, and so on [Wed Oct 25 08:58:40 2017] So when you ask to unfold "~", what is really unfolded is the constant "not" [Wed Oct 25 08:58:51 2017] the kernel doesn't know anything about notations, so "unfold a notations" would be a noop [Wed Oct 25 08:59:01 2017] -s [Wed Oct 25 09:25:35 2017] anton-trunov: Did you perchance answer my question about the unfolding? I had to leave that computer, so I wasn't able to see your reply. [Wed Oct 25 10:43:32 2017] buttbutter: If we take into account what Cypi told us about unfolding, then we can try to work around this issue by defining a wrapper like so: [Wed Oct 25 10:43:38 2017] Definition wrap_le2 {X : Type} (R S : X -> X -> Prop) := forall x y, R x y -> S x y. [Wed Oct 25 10:43:45 2017] Infix "<=2" := (wrap_le2) (at level 70). [Wed Oct 25 10:43:59 2017] Then you'll be able to unfold "<=2". [Wed Oct 25 10:44:25 2017] But you'll need change some of your proofs a bit [Wed Oct 25 10:44:31 2017] -to change [Wed Oct 25 14:10:23 2017] anton-trunov: I see. Thanks for the information. I asked about it in class as well and sort of got the blanket statement "Notations can't be unfolded". Which is why you're changing it to a definition right there, I'm guessing :) [Wed Oct 25 15:02:03 2017] Is there a library for doing proof on C programs [Wed Oct 25 15:06:46 2017] lyxia: VST [Wed Oct 25 15:07:18 2017] http://vst.cs.princeton.edu/ [Wed Oct 25 15:07:33 2017] Chobbes: perfect, thanks! [Wed Oct 25 15:08:01 2017] I haven't used it yet, but I'm pretty sure the gist is that you convert C files to coq programs using a tool, and then prove properties on that. [Wed Oct 25 15:08:24 2017] Uses CompCert stuff behind the scenes, which is also probably worth looking into. [Wed Oct 25 15:09:00 2017] At least, I think it does. I'm no expert :). [Thu Oct 26 09:48:56 2017] is there a tactical that succeeds when a given tactic does not produce new subgoals and fails if new subgoals are generated? [Thu Oct 26 10:27:49 2017] jstolarek: "tactic; fail" maybe? [Thu Oct 26 10:28:05 2017] if tactic solves the current subgoal then fail will never be reached [Thu Oct 26 10:28:33 2017] sometimes useful in combination with try: "tactic; try (tactic'; fail)" [Thu Oct 26 10:29:07 2017] maybe there's a more idiomatic way of doing the same thing, that i don't know [Thu Oct 26 10:29:34 2017] solve [ tac ] will succeed if and only fail there are no subgoals remaining after tac [Thu Oct 26 10:29:49 2017] s/fail/if/ [Thu Oct 26 10:30:18 2017] cic: I might have not been clear [Thu Oct 26 10:30:26 2017] I don't expect tactic to solve the goal [Thu Oct 26 10:30:34 2017] I just expect it not to produce more subgoals [Thu Oct 26 10:31:36 2017] so it's rather that it should fail if it produces more than one subgoal then, i.e. if it "splits" the current goal [Thu Oct 26 10:31:49 2017] yes, preciesly [Thu Oct 26 10:33:10 2017] you could look at the "General version of the invertn tactics [Thu Oct 26 10:33:12 2017] ah [Thu Oct 26 10:33:14 2017] new line [Thu Oct 26 10:33:25 2017] the thread with that title in the deepspec piazza [Thu Oct 26 10:33:47 2017] they count the number of subgoals there [Thu Oct 26 10:34:13 2017] "numgoals" [Thu Oct 26 10:34:14 2017] "tac; let n := numgoals in guard n < 2" would do it [Thu Oct 26 10:34:27 2017] ah, good point [Thu Oct 26 10:34:29 2017] See https://coq.inria.fr/refman/ltac.html#hevea_default867 and the following subsections [Thu Oct 26 10:34:34 2017] I even have that in my mailbox [Thu Oct 26 10:39:38 2017] it seems like a useful tactical to have, strange that it's not standard. but maybe it's cleaner in many cases to not use tactics that might split the goal rather than using "too heavy" tactics and then revert later. [Thu Oct 26 10:44:03 2017] I'm also surprised this is not standard. [Thu Oct 26 10:44:21 2017] Anyway, I just tested this and while my code is much more concise it is also three times slower :-. [Thu Oct 26 10:44:24 2017] :-/ [Thu Oct 26 10:45:55 2017] :( [Thu Oct 26 10:46:36 2017] does speed get to matter in very large proofs? [Thu Oct 26 10:49:26 2017] "sometimes"? i think adam chlipala said in some interview that people are often look confused when he says that he is "optimizing" proofs, or when talking about "proof performence" or similar [Thu Oct 26 10:49:51 2017] yeah i tink i heard that recently [Thu Oct 26 10:49:57 2017] on a functional programming podcast or something like that [Thu Oct 26 10:50:03 2017] functional geekery iirc [Thu Oct 26 10:50:14 2017] it def had functional in the name [Thu Oct 26 10:50:35 2017] my proofs are still tiny and more or less intantaeous. [Thu Oct 26 10:50:39 2017] *instantaneous. [Thu Oct 26 10:51:47 2017] but the proofs do not have to be "big" for speed to matter, e.g. consider the standard example of proving "even ", where even is given by the standard inductive definition, by using "repeat constructor". [Thu Oct 26 10:52:35 2017] yeah i guess that's a good point [Thu Oct 26 10:52:51 2017] using nat for any large arithmetic is not really very fast and sometimes blows up the stack [Thu Oct 26 10:54:24 2017] in this case it's worse than linear (what you have from nat alone), that proof size that is [Thu Oct 26 12:10:56 2017] (the topic is outdated btw, coq 8.7 is out now :p) [Thu Oct 26 12:10:58 2017] (https://coq.inria.fr/news/139.html) [Thu Oct 26 12:13:29 2017] thanks [Thu Oct 26 17:04:21 2017] i feel like using auto-generated names for variables isnt very robust [Thu Oct 26 17:04:35 2017] but when i do an induction on a big type, i dont wanna have a ginormous list of names all at the top [Thu Oct 26 17:04:41 2017] is there a nice way of dealing with this [Thu Oct 26 17:05:44 2017] name only the ones you have to [Thu Oct 26 17:05:50 2017] intros ??? _ x ?? _ _ ? [Thu Oct 26 17:06:47 2017] but i mean with induction you get the variables introduced for you [Thu Oct 26 17:06:57 2017] induction x as [??? _ x ?? _ _ ?] :) [Thu Oct 26 17:06:59 2017] unless you provide names all at the point of the induction tactic [Thu Oct 26 17:07:07 2017] yeah thats what im saying i dont wanna have a giant list up there :( [Thu Oct 26 17:07:18 2017] not sure what to tell you then... [Thu Oct 26 17:07:23 2017] imagine if you wrote a match expression where you list all of the names at the top and not at the branches [Thu Oct 26 17:52:19 2017] is there a tactic which can solve [M n = true <-> Some (M n) = Some true] [Thu Oct 26 18:07:09 2017] inversion solves one, f_equal solves the other [Thu Oct 26 18:07:19 2017] injection maybe? [Thu Oct 26 18:07:55 2017] no, not that [Thu Oct 26 18:08:13 2017] anyway: intuition; inversion H. [Thu Oct 26 18:50:10 2017] things im grumpy about, part 93994885 [Thu Oct 26 18:50:38 2017] we have: [seq_nth: forall len start n d : nat, n < len -> nth n (seq start len) d = start + n] [Thu Oct 26 18:51:14 2017] the corresponding statement for nth_err proves this very easily, but im pretty sure this doesnt help you at all if you wanna prove the converse [Thu Oct 26 18:51:26 2017] and this is the only one in the stdlib; the other isnt there [Thu Oct 26 19:12:31 2017] i ended up doing this which is ugly as fuck https://i.imgur.com/rH8vIM8.png [Thu Oct 26 19:12:56 2017] turned out it did help you a little but you have to do a dirty trick where you set the default to something you know the result can't be if it finds a real answer [Fri Oct 27 10:15:45 2017] I have a constructor: [Fri Oct 27 10:15:47 2017] APlus : aexp -> aexp -> aexp [Fri Oct 27 10:15:55 2017] and I can create Notation for it: [Fri Oct 27 10:16:12 2017] Notation "a1 '+' a2" := (APlus a1 a2) : aexp_scope. [Fri Oct 27 10:16:24 2017] I wonder if I can do the same for this constructor: [Fri Oct 27 10:16:41 2017] ANum : nat -> aexp [Fri Oct 27 10:17:01 2017] that is, can I overload parsing of natural numbers in a given scope so that they are wrapped in ANum constructor? [Sat Oct 28 14:10:22 2017] i ended up doing this which is ugly as fuck [Sat Oct 28 14:10:36 2017] after working on my string library for a while I absolutely detest the functions with default values. [Sat Oct 28 14:11:27 2017] you can generally set things up to make the proofs go through, but it requires creating a bunch of otherwise unnecessary machinery. [Sat Oct 28 14:12:41 2017] and then using them requires all the same crap. [Sat Oct 28 16:10:46 2017] Hi. Does anyone know, how can I rewrite [if PeanoNat.Nat.eq_dec n n then A else B] to [A]? [Sat Oct 28 16:11:07 2017] There aren't any lemmas about Nat.eq_dec, as far as SearchAbout goes [Sat Oct 28 16:13:25 2017] Right now I am doing a `replace` + case analysis and calling `congruence`, but that seems kinda annoying to me. [Sat Oct 28 16:18:05 2017] notnotdan: write a lemma stating 'PeanoNat.Nat.eq_dec n n = true' and just rewrite it? [Sat Oct 28 16:19:40 2017] notnotdan: wait what's the PeanoNat.Nat.eq_dec you're using? the eq_dec I found in https://coq.inria.fr/library/Coq.Arith.PeanoNat.html doesn't seem to be what you want to use [Sat Oct 28 16:24:09 2017] artart78: what do i want to use then? [Sat Oct 28 16:36:50 2017] notnotdan: I'd say eqb or =? (infix) [Sat Oct 28 16:42:55 2017] dh`: :( [Sun Oct 29 14:28:08 2017] there are times when I think it would be nice for coq to have some kind of builtin support for error monad refinement [Sun Oct 29 14:29:16 2017] something like Failing Function foo: x -> y := ... whose type is extended to be y option if referenced outside another failure context [Sun Oct 29 18:30:16 2017] Hmmm. I want to use real numbers for some basic calculus / real analysis stuff. Are the built in real numbers the best starting point? It seems like they have an odd amount of stuff. E.g., I don't see a log function, but it has limits defined on any metric space. As far as I'm aware, though, RLimit doesn't have any way to represent a divergent limit? Is there something better to use? C-CoRN seems to lag a bit [Sun Oct 29 18:30:18 2017] behind -- currently only available for 8.5.2. [Sun Oct 29 20:29:52 2017] argh [Sun Oct 29 20:30:30 2017] is there any way to tell coq that the map module I just created is the same as the one in the file I just imported? [Sun Oct 29 20:30:51 2017] Or do I need to build it exactly once and import it everywhere from there? [Sun Oct 29 20:50:57 2017] smh @ ppl who dont know the difference between recursion and corecursion https://i.imgur.com/KzLyGACh.jpg [Sun Oct 29 22:46:32 2017] Anomaly: Not an arity. Please report at http://coq.inria.fr/bugs/. [Sun Oct 29 22:46:35 2017] beautiful [Wed Nov 1 04:24:01 2017] grr... if I have H: P <-> a = b, is there any way to rewrite H to transform a to b without destructing the <-> first? [Wed Nov 1 09:23:01 2017] I m struggling with this seemingly trivial goal: [Wed Nov 1 09:23:05 2017] http://lpaste.net/359718 [Wed Nov 1 09:23:26 2017] I would expect that `inversion st` will figure out that st = StatePNil [Wed Nov 1 09:23:34 2017] but for some reason it does nothing [Wed Nov 1 09:23:36 2017] why? [Wed Nov 1 09:26:26 2017] jstolarek: what exactly is the notation in the goal [Wed Nov 1 09:26:40 2017] and what does happen when you do inversion? [Wed Nov 1 09:29:42 2017] jstolarek: ack, i gotta go, sorry - but for what it's worth, a tangential but relevant note is - [Wed Nov 1 09:30:02 2017] sometimes, people instead of doing: [Wed Nov 1 09:30:18 2017] Inductive foo : nat -> Prop := bar : foo 0. [Wed Nov 1 09:30:19 2017] peoiple do [Wed Nov 1 09:30:32 2017] Inductive foo (n : nat) : Prop := bar : n = 0 -> foo n. [Wed Nov 1 09:30:44 2017] i am not an expert and i dont know the details of precisely when you would want this instead of that [Wed Nov 1 09:30:48 2017] but i can tell you one thing: [Wed Nov 1 09:30:58 2017] defining your type like that allows you to destruct and get out equations [Wed Nov 1 09:31:18 2017] without worrying about ill-formed destruction due to type mismatches between constructors and input [Wed Nov 1 09:31:19 2017] ok later [Wed Nov 1 09:33:45 2017] benzrf: nothing happens - the goal remains unchanged [Wed Nov 1 09:34:23 2017] I annotated the paste with notation [Wed Nov 1 14:47:58 2017] st already is stateP nil, unless I'm reading wrong [Wed Nov 1 14:48:33 2017] oh wait, too many nils. [Wed Nov 1 14:59:31 2017] jstolarek: I think the problem is layers of typing; what happens if you assert (st = StatePNil), because using that to rewrite the goal will discharge it? [Wed Nov 1 15:01:54 2017] wait, no, maybe it'll work. both st and StatePNil have type "stateP nil"... [Wed Nov 1 15:02:20 2017] dh`: you may run into a problem [Wed Nov 1 15:02:37 2017] it will be trivially solvable with "dependent destruction st" to resolve that equality [Wed Nov 1 15:02:41 2017] but doing it axiom free might take work [Wed Nov 1 15:03:45 2017] true, but I was thinking the problem was that the types don't match up [Wed Nov 1 15:04:25 2017] (also this seems like a strange formulation so I wonder if there's a better way to structure it) [Fri Nov 3 10:47:06 2017] what was the command again to see the definition of an Infix/Notation? [Fri Nov 3 11:38:47 2017] Locate iirc [Sat Nov 4 11:10:21 2017] Hello, I have a question about a simple proof I'm trying to do involving booleans. I am trying to prove (forall a b : bool, andb a b = true -> b = true) where andb is just logical AND. This is obviouslly provable/true and I'm told that it should be done using case analysis. However, when I try to use the destruct tactic on either a or b, one of the subgoals that it generates leads to a contradiction. For example when I destruct b, it [Sat Nov 4 11:10:42 2017] anonlastname: you got cut off there [Sat Nov 4 11:11:22 2017] sorry, maybe my message was too long for your client because it showed up on mine [Sat Nov 4 11:11:25 2017] but I'm pretty sure the answer would be to look in your hypotheses for an absurdity [Sat Nov 4 11:11:59 2017] anonlastname: nah - irc servers dont send messages back to clients, so clients just display exactly what you typed, even if the server chops it off for everyone else [Sat Nov 4 11:12:11 2017] If at some point you have some hypothesis `H : false = true` in your context, then you can solve the current goal by using `inversion H`. [Sat Nov 4 11:12:20 2017] good clients generally break up long stuff into multiple messages so the server doesnt cut it - yours might have an option for that [Sat Nov 4 11:14:17 2017] Cypi: Ok I will try that [Sat Nov 4 11:14:20 2017] or `discriminate.` which uses disjointness of constructors [Sat Nov 4 11:16:30 2017] anonlastname: I saw your question on Stackoverflow. It looked like an exercise from SF. And it's frowned upon to give answers in public places indexed by search engines. [Sat Nov 4 11:17:24 2017] but feel free to ask here :) [Sat Nov 4 11:20:38 2017] ah yes using the inversion tactic worked thank you [Sat Nov 4 11:20:56 2017] iirc destruct H will also eliminate a goal with a contradictory hypothesis. [Sat Nov 4 11:21:04 2017] ora rather a goal with False in it. [Sat Nov 4 11:22:01 2017] anonlastname: you can also `rewrite` using your contradictory hypothesis. E.g. if you have H : false = true and you need to prove false = true, then rewrite H, turning your goal into true = true. [Sat Nov 4 11:22:38 2017] or you can just do "exact H" in that case, since it has the correct type x) [Sat Nov 4 11:22:49 2017] lots of possibilities! [Sat Nov 4 11:22:56 2017] +1 [Sat Nov 4 11:23:06 2017] how about contradiction? [Sat Nov 4 11:23:36 2017] anyway if one is going through SF it's probably best to use the tactics that already were introduced in the xercises. at least that's how i went about it. [Sat Nov 4 11:24:14 2017] modulus: I don't believe contradiction will work in this case [Sat Nov 4 11:24:33 2017] * tries it [Sat Nov 4 11:30:38 2017] anton-trunov: that's probably the way that it was meant to be done [Sat Nov 4 11:32:01 2017] Interesting, I was misremembering some of the mechanics, simpl doesn't go from false = true to false. [Sat Nov 4 11:32:50 2017] `_ = _` is an inductive type, `false = true` is as simplified as it can be [Sat Nov 4 11:33:21 2017] not to be mistaken for some computable equality like `eqb : bool -> bool -> bool` [Sat Nov 4 11:34:22 2017] yeah, it's easy to forget that equality works oddly in coq though. [Sat Nov 4 11:35:17 2017] The usual equality test that you see in more general programming languages is usually denote `_ =? _` in Coq, or something like this [Sat Nov 4 11:35:20 2017] (when it has a notation) [Sat Nov 4 11:35:28 2017] and of course it needs to be defined, you don't get it for free [Sat Nov 4 23:06:44 2017] are the exact rules for what is and isn't allowed making recursive calls in a Fix or Function documented somewhere? [Sun Nov 5 00:04:58 2017] pursuant to which I have a repeatable Anomaly... [Sun Nov 5 12:18:14 2017] Evening [Sun Nov 5 12:20:52 2017] I'm sorry, how do I define a datatype in Coq? [Sun Nov 5 12:21:01 2017] Inductive. [Sun Nov 5 12:21:06 2017] I'm trying to Google, but I don't know what to goo- [Sun Nov 5 12:22:09 2017] Ah [Sun Nov 5 12:22:10 2017] fantastic, thanks [Sun Nov 5 12:22:29 2017] yw [Sun Nov 5 12:35:27 2017] I have my Inductive Day : Set and Definition Next (day : Day) : Day. now proving after_monday_simple : ((Next Mon) = Tue) is simple enough. how can I prove the same, in terms of (forall A : Day, A = Mon -> Next A = Tue)? [Sun Nov 5 12:35:48 2017] I'm basically stuck after 2 intros [Sun Nov 5 12:36:38 2017] can you copy your thing on a pastebin? [Sun Nov 5 12:38:03 2017] https://paste.hosting/2YRdgX7n [Sun Nov 5 12:38:09 2017] right, sec [Sun Nov 5 12:38:14 2017] bor0: you can use rewriting to replace `A` by `Mon` in your goal. For instance with `rewrite H` (assuming you have `H : A = Mon` in your context) [Sun Nov 5 12:38:31 2017] ffs, javascript to use a pastebin? [Sun Nov 5 12:38:32 2017] * sighs [Sun Nov 5 12:38:44 2017] rewrite! that's new to me :) (I'm going through Mike Nahas's tutorial) [Sun Nov 5 12:39:29 2017] ahh neat. rewrite got me one step further [Sun Nov 5 12:40:22 2017] I ended up with: intros A. ; intros A_eq_Mon. ; rewrite A_eq_Mon. ; simpl. ; reflexivity. [Sun Nov 5 12:41:51 2017] intros. rewrite H. reflexivity. Qed. [Sun Nov 5 12:42:01 2017] thanks modulus, Cypi! one new tactic a try [Sun Nov 5 12:42:13 2017] ah, you don't need to simple.? [Sun Nov 5 12:42:37 2017] reflexivity does an implicit simpl beforehand. [Sun Nov 5 12:43:47 2017] neat! [Sun Nov 5 12:50:34 2017] fyi, if you want "reflexivity" without simpl, can you use "constructor" [Sun Nov 5 12:50:40 2017] s/can you use/you can use [Sun Nov 5 12:50:55 2017] how many tactic commands are there like in total? :D [Sun Nov 5 12:50:59 2017] one sec [Sun Nov 5 12:51:10 2017] 191 in Coq 8.5 [Sun Nov 5 12:51:22 2017] including variants [Sun Nov 5 12:51:35 2017] in Coq 8.7 there are quite a few more, since ssreflect was included [Sun Nov 5 12:52:00 2017] wow, that's a lot. and I've only got introduced to about 10 or so [Sun Nov 5 12:52:10 2017] you don't need to know all of them, by any means [Sun Nov 5 12:52:13 2017] s/got introduced/got myself introduced/ [Sun Nov 5 12:52:26 2017] some are the more basic tactics from which other tactics are built up [Sun Nov 5 12:52:38 2017] think of it like a standard tactic library [Sun Nov 5 12:52:50 2017] they aren't syntactic aspects of Ltac or anything like that [Sun Nov 5 12:53:11 2017] What do you mean about `constructor` johnw? Afaik, on any goal `x = y` where `reflexivity` would work, `constructor` should work too. [Sun Nov 5 12:53:39 2017] hmm, what does constructor do, apply the constructor of eq? [Sun Nov 5 12:53:45 2017] if so, then maybe "exact eq_refl" is the most basic tactic [Sun Nov 5 12:53:53 2017] Yes modulus [Sun Nov 5 12:53:56 2017] modulus: it finds a constructor of the type that matches the goal [Sun Nov 5 12:54:13 2017] is constructor an alias of exact eq_refl? [Sun Nov 5 12:54:16 2017] right, i used constructor with user-defined inductive types, but hadn't thought of using it with eq. [Sun Nov 5 12:54:31 2017] not an alias, `constructor` is more general [Sun Nov 5 12:54:43 2017] that's the beauty of all this: almost everything is just about types and finding inhabitants of types [Sun Nov 5 12:54:44 2017] bor0 - no, it tries the constructors of the types on goal and uses one that matches [Sun Nov 5 12:55:06 2017] Hi. I have a hypothesis of the form "exists v : Val, e1 = v". But I can't really figure out how I can "use" it, can you call an "exists" inside of a hypothesis to instantiate it or something? [Sun Nov 5 12:55:10 2017] Sorry, I know the question is unclear :C [Sun Nov 5 12:55:16 2017] sorry if I confused things, I was just trying to reveal a hierarchy of possibilities here [Sun Nov 5 12:55:35 2017] destruct it [Sun Nov 5 12:56:22 2017] johnw - i found it informative. [Sun Nov 5 12:56:26 2017] modulus: Oh, thank you! :) [Sun Nov 5 12:56:30 2017] yw [Sun Nov 5 12:57:25 2017] much as i try the fact that inductive types like = don't have computational content screws with my head a little still, so wouldn't have thought of using constructor to solve an equality. [Sun Nov 5 12:58:40 2017] modulus: have you use phantom types in Haskell? [Sun Nov 5 12:59:07 2017] not a haskeller [Sun Nov 5 12:59:12 2017] oh [Sun Nov 5 12:59:30 2017] the various inhabitants of eq differ only in their types, not their values [Sun Nov 5 12:59:39 2017] which is why they're all computationally equal, but logically distinct [Sun Nov 5 12:59:56 2017] yeah, as i said, screws with my head ;-) [Sun Nov 5 13:00:12 2017] in Haskell, we use "type-only variance" to good effect in many situations [Sun Nov 5 13:00:32 2017] it's the different between a null in java of object X, and a null of object Y [Sun Nov 5 13:00:35 2017] difference* [Sun Nov 5 13:01:19 2017] hmm [Sun Nov 5 13:01:24 2017] i suppose null is null [Sun Nov 5 13:01:38 2017] at runtime, yes [Sun Nov 5 13:01:41 2017] at compile-time, no [Sun Nov 5 13:01:45 2017] true [Sun Nov 5 13:02:13 2017] and likewise with the witnesses of eq [Sun Nov 5 13:03:32 2017] Coq's sophisticated type checking is making sure you're using everything correctly; but the actual use of those things at runtime is a MUCH simpler domain, since the purpose of all that knowledge is not needed then. It's like, once you know that you're driving on the right road, all you need to think about is staying between the lines. [Sun Nov 5 13:04:18 2017] as opposed to untyped languages that do lots of sanity checking at runtime [Sun Nov 5 13:04:37 2017] yeah, i guess it reduces the scope of unexpected things happening a lot. [Sun Nov 5 13:04:43 2017] ideally entirely. [Sun Nov 5 13:05:01 2017] it makes sure the executable you've compiled is a correct one; all the scaffolding of logic used to make that determination is therefore only relevant at compile-time [Sun Nov 5 13:05:16 2017] (or rather, the "extracted code", since Coq dosen't make executables) [Sun Nov 5 13:05:45 2017] hence, there is real value to compile-time only distinctions; they are more efficient at runtime [Sun Nov 5 13:06:12 2017] in a language like Coq, the majority of the work is at compile-time in fact! [Sun Nov 5 13:06:46 2017] I should take up Software Foundations again where I left it, but finding it harder to make room for fun learning now I hav ework. [Sun Nov 5 15:36:37 2017] I want to apply a theorem to a hypothesis, but I also want to keep that hypothesis. [Sun Nov 5 15:36:39 2017] How can I do that? [Sun Nov 5 15:41:33 2017] "pose proof" did it :) [Sun Nov 5 15:46:02 2017] my incantation for that is "remember H as H0; clear HeqH0; apply foo in H0" [Sun Nov 5 15:46:29 2017] this is the form I can apparently remember, regardless of it being a bit weird [Sun Nov 5 15:53:24 2017] yeah, the clear is unnecessary if you use pose proof [Sun Nov 5 16:28:03 2017] right, I can just never remember that [Sun Nov 5 17:06:03 2017] I'm trying to prove forall x : nat, x > 5 \/ x = 5 -> x > 4. I'm stuck on the first case (x > 5 -> x > 4). I guess I need to use `exact gt_trans` or something? [Sun Nov 5 17:11:20 2017] Goal forall x : nat, x > 5 \/ x = 5 -> x > 4. [Sun Nov 5 17:11:23 2017] oops [Sun Nov 5 17:12:57 2017] I guess I need to know how to end proving "5 > 4" :D [Sun Nov 5 17:17:31 2017] I suck at proofs with inequalities. [Sun Nov 5 17:18:16 2017] but really, how does one even something as simple as `Goal (5 > 4).` [Sun Nov 5 17:19:25 2017] I used to know this :-) [Sun Nov 5 17:19:30 2017] auto works *shrug* [Sun Nov 5 17:19:40 2017] you can use "constructor" [Sun Nov 5 17:19:46 2017] for (4<5) [Sun Nov 5 17:20:04 2017] ah, you need to apply le_n. [Sun Nov 5 17:20:05 2017] and PeanoNat.Nat.lt_succ_l for (x > 5 -> x > 4) [Sun Nov 5 17:20:45 2017] at least auto solves it with le_n [Sun Nov 5 17:21:00 2017] how do you see that modulus? [Sun Nov 5 17:21:07 2017] before Qed, do Show Proof. [Sun Nov 5 17:21:14 2017] ahh, neat! [Sun Nov 5 17:24:01 2017] rrika, I can't find PeanoNat.Nat.lt_succ_l :( [Sun Nov 5 17:24:15 2017] are you sure it's there? I'm using latest Coq(IDE) [Sun Nov 5 17:24:38 2017] I'm using coq version 8.7 [Sun Nov 5 17:24:45 2017] bor0, try "Require Import PeanoNat." [Sun Nov 5 17:25:26 2017] I did, it says it's "The reference lt_succ_l was not found in the current environment" [Sun Nov 5 17:26:51 2017] ok, if I use Nat.lt_succ_l instead now it says the types can't match: The term "Nat.lt_succ_l" has type "forall n m : nat, S n < m -> n < m" while it is expected to have type "5 > 4". [Sun Nov 5 17:29:03 2017] bor0, coq's ">" (gt) is defined in terms of "<" (lt) so you can convert it using "unfold gt" [Sun Nov 5 17:31:59 2017] neat, rrika! [Sun Nov 5 17:35:55 2017] what's that tactic to remove S from both sides of an equality? [Sun Nov 5 17:36:40 2017] like s(n) = S(n+ m) and then you get m = n`m [Sun Nov 5 17:36:59 2017] only without the mispellings :-) [Sun Nov 5 17:37:33 2017] this error tells me I'm so close, but it can't match x and m? The term "Nat.lt_succ_l 4" has type "forall m : nat, 5 < m -> 4 < m" while it is expected to have type "5 < x -> 4 < x" (cannot unify "5 < x" and "nat"). [Sun Nov 5 17:47:13 2017] modulus, f_equal [Sun Nov 5 17:48:00 2017] f_equal applies the obvious principle that if x = y -> f x = f y [Sun Nov 5 17:48:30 2017] equal_f, the opposite, depends on an axiom [Sun Nov 5 17:49:35 2017] functional extensionality? [Sun Nov 5 17:49:39 2017] exactly [Sun Nov 5 19:23:18 2017] no, wrong opposite [Sun Nov 5 19:23:29 2017] the converse is injectivity [Sun Nov 5 19:23:52 2017] function extensionality is when you swap the places you're talking about functions and arguments [Sun Nov 5 19:23:55 2017] but that's not what modulus asked about [Sun Nov 5 19:24:08 2017] modulus: you want injectivity, i think [Sun Nov 5 19:24:32 2017] oh wait thats not what the tactic is called hmmm [Sun Nov 5 19:24:42 2017] ah, right, equal_f is f = g -> forall x, f x = g x [Sun Nov 5 19:24:49 2017] thanks for the correction, benzrf [Sun Nov 5 19:25:01 2017] injection? [Sun Nov 5 19:25:04 2017] ah yeah [Sun Nov 5 19:25:12 2017] but thats for hypotheses and not goals, woops [Sun Nov 5 19:25:19 2017] oh wait no [Sun Nov 5 19:25:24 2017] f_equal was right in the first place [Sun Nov 5 19:25:25 2017] yeah, we all totally know what we're doing [Sun Nov 5 19:25:32 2017] because we're talking about the /goal/, not a /hypothesis/ [Sun Nov 5 19:25:39 2017] so we go from the conclusion to the hypothesis [Sun Nov 5 19:25:49 2017] so just [apply f_equal] is correct here [Sun Nov 5 19:25:52 2017] I was thinking of functional_extensionality when I said equal_f up above [Sun Nov 5 19:26:04 2017] which is indeed f x = f y -> x = y [Sun Nov 5 19:26:21 2017] no, that's injectivity of f :P [Sun Nov 5 19:26:33 2017] modulus: [apply f_equal] [Sun Nov 5 19:26:51 2017] Functional extensionality is "(forall x, f x = g x) -> f = g" [Sun Nov 5 19:27:15 2017] um, yeah, I meant that... [Sun Nov 5 19:27:18 2017] lmao [Sun Nov 5 19:27:26 2017] not batting 100 today [Sun Nov 5 19:27:41 2017] I guess in some sense, it is the injectivity of "fun {A B : Type} (x : A) (f : A -> B) => f x", so yeah x) [Sun Nov 5 19:27:55 2017] this is what I get for not waiting until Qed tells me it's OK to say something in #coq [Sun Nov 5 19:27:56 2017] hmm. No, nevermind. [Sun Nov 5 19:28:23 2017] which is actually why I love Coq so much; it's like having an genuine expert sitting behind you, to tell you when something is definitively correct [Sun Nov 5 19:42:26 2017] Okay, I have H1: Y >* Z and H2: X >* Y. >* is transitive and I have a theorem that says X >* Y -> Y * Z -> X >* Z. How can I apply that theorem to H1 and H2 to get H3: X >* Z? [Sun Nov 5 19:43:03 2017] If your theorem is called `thing_trans`, then you can do something like `pose proof (thing_trans H2 H1)` [Sun Nov 5 19:43:23 2017] you might have to write something like `pose proof (thing_trans _ _ _ H2 H1)` if the arguments X, Y and Z are not implicit arguments [Sun Nov 5 19:43:37 2017] (the underscore is just telling Coq to try to infer this term) [Sun Nov 5 19:44:14 2017] (equivalently you could fill them yourself: `pose proof (thing_trans X Y Z H2 H1)` ) [Sun Nov 5 19:44:51 2017] Okay, great. Thank you :) [Sun Nov 5 22:16:38 2017] if he makes his type an instance of Transitivity by that relation, then he can directly rewrite H1 in H2. [Sun Nov 5 22:17:07 2017] rather, the relation an instance [Mon Nov 6 05:13:07 2017] in Ltac, how can I check whether the goal contains a "match with" expression? I'm trying Ltac tactic := match goal with [ |- context[match someexpr(?X) with _ end] ] => ... [Mon Nov 6 05:23:00 2017] found it https://stackoverflow.com/questions/28454977/how-to-match-a-match-expression [Mon Nov 6 07:45:09 2017] Excuse my simple question, but how should I interpret this? "Inductive prod (X Y : Type) : Type := | pair : X -> Y -> prod X Y.". Should I just say "pair" takes 2 arguments, X and Y? [Mon Nov 6 07:45:31 2017] and returns a product of X and Y [Mon Nov 6 07:56:58 2017] Colloquially, "product" refers to a type (or set), whose inhabitants (or elements) are "pairs". [Mon Nov 6 07:57:56 2017] pair takes 2 arguments of types X and Y, to construct an inhabitant of prod X Y. [Mon Nov 6 08:24:28 2017] I see [Mon Nov 6 10:28:25 2017] How about "partition : forall X : Type, (X -> bool) -> list X -> list X * list X"? [Mon Nov 6 10:28:57 2017] I think I got it [Mon Nov 6 10:30:18 2017] Set X and a function of type X -> boolean should return a pair of lists [Mon Nov 6 13:05:11 2017] has anyone here tried the Coq-Equations plugin? [Mon Nov 6 13:05:46 2017] I'm running into a "Unbound module Sigma" from ocaml [Mon Nov 6 16:34:33 2017] can anyone help me finish my factorial greater than 0 proof? https://paste.hosting/mBje3DRx. my third day using Coq :D trying to tackle some induction [Mon Nov 6 16:35:26 2017] bor0: 'case' is not an induction, and you need an induction here ('induction n') [Mon Nov 6 16:35:43 2017] I was thinking I can handle the base case that way [Mon Nov 6 16:35:48 2017] and the inductive step, separately [Mon Nov 6 16:36:20 2017] is there a way not to use the induction tactics, and do it with few simple commands? I want to get a grasp of it before using magical commands :D [Mon Nov 6 16:36:33 2017] wut [Mon Nov 6 16:36:43 2017] you should learn what's induction first probably lol [Mon Nov 6 16:36:52 2017] I don't know, it just feels like using "auto" [Mon Nov 6 16:37:07 2017] no, I know induction well. I just am new with the tactic commands [Mon Nov 6 16:37:21 2017] 'induction' just does a proof by induction [Mon Nov 6 16:37:32 2017] there's no magic, except the magics of the type theory behind it if you want [Mon Nov 6 16:37:57 2017] so the only way to prove induction is through the induction tactic? [Mon Nov 6 16:38:42 2017] yeah, induction is a basic principle in Coq [Mon Nov 6 16:38:59 2017] ok, that makes sense in that case then :) [Mon Nov 6 16:39:03 2017] on paper you'd prove the induction principle by saying "take the smallest integer for which the property is false.." [Mon Nov 6 16:40:07 2017] which is way more technical in Coq, and will (probably?) rely on some inductions "in the hood" anyway [Mon Nov 6 16:40:12 2017] ahh, induction gives me 2 cases to prove (it's not doing it all by itself) [Mon Nov 6 16:40:29 2017] which looks pretty similar to what I had with case before, hm :| [Mon Nov 6 16:40:41 2017] well you have the induction hypothesis now :P [Mon Nov 6 16:40:43 2017] that's supposed to help [Mon Nov 6 16:42:11 2017] ahh, I see. neat! [Mon Nov 6 16:42:36 2017] yes, IHn magically appeared there :D [Mon Nov 6 16:42:45 2017] thank you. [Tue Nov 7 05:27:37 2017] hi. I'm stuck on the inductive step of my (still first, from yesterday) induction proof attempt: https://paste.hosting/KXW3OvWk [Tue Nov 7 05:27:53 2017] ignore L27 and L28, just something I've been trying [Tue Nov 7 06:43:19 2017] can't prove that one either, but i suck with inequalities. [Tue Nov 7 09:49:52 2017] a confused question: are evars (or whatever they are called) part of the kernel in any sense? they appear in the gallina ast iirc? so they are part of gallina's semantics, i.e. not just something part of the tactic language (ltac)? [Tue Nov 7 09:50:52 2017] They appear in the AST, but the kernel doesn't know what to do with them. [Tue Nov 7 09:52:13 2017] what do you mean by "doesn't know what to do with them"? you can't compare them or something like that? cannot compute with them? iirc you can do some computations at least, at least with some backends (not e.g. vm_compute in some cases iirc) [Tue Nov 7 09:55:22 2017] By that I mean that the kernel doesn't know how to type an evar [Tue Nov 7 09:55:52 2017] it won't try to reduce an evar, too. For the kernel, an evar is just some black box and won't do anything with it. [Tue Nov 7 09:56:10 2017] The only thing it knows is that an evar is convertible to itself and that's it. [Tue Nov 7 09:59:05 2017] but i think things like this will work for some backends: (\x y. y) ?evar --> y, where --> is "reduces to". so you can compute with them in that sense... not a very interesting sense maybe, but more than nothing :p [Tue Nov 7 09:59:28 2017] but i might be confused here, this is just something i vaguely remember [Tue Nov 7 09:59:52 2017] Yes, it's possible, since in this case you don't need to know anything about the evar. [Tue Nov 7 09:59:56 2017] whereas compute backends such as vm_compute will just complain that it doens't know what to do when the expression contains an evar [Tue Nov 7 10:00:01 2017] (If you ask the kernel to type the first term, it will fail though) [Tue Nov 7 10:00:51 2017] interesting, i didn't know that evars are "untypeable", that they don't have a type [Tue Nov 7 10:01:14 2017] To summarize, evars are in the AST (that is, there is some constructor `Evar : int -> constr`), but evar_maps are not in the kernel, and evar_maps are what contain all the information about an evar [Tue Nov 7 10:01:28 2017] They are typeable outside the kernel [Tue Nov 7 10:02:48 2017] oh, i've only spent maybe 15 minutes looking at kernel code, so i don't know much about it :p [Tue Nov 7 10:02:58 2017] maybe i should take another look at some point :p [Tue Nov 7 10:03:37 2017] evar_maps are defined in /engine/evd.mli (so, outside the kernel) [Tue Nov 7 10:04:30 2017] so evars are inside the kernel in the sense that the kernel must (at least) maintain the invariant that evars are black boxes [Tue Nov 7 10:04:49 2017] (whatever that means, but it's more than nothing at least) [Tue Nov 7 10:05:37 2017] It's not much work though, since evars only give an integer which is supposed to be a key to an evar_map, and that the kernel can't access any evar_map [Tue Nov 7 10:06:01 2017] https://github.com/coq/coq/blob/master/kernel/typeops.ml#L414 >> this is the main typing function in the kernel, it will just fail on evars, for instance [Tue Nov 7 10:06:54 2017] heh, comments in french, why did i expect something else ^_^ [Tue Nov 7 10:07:05 2017] Yeah, some of them still remain... [Tue Nov 7 12:06:15 2017] I have a hypothesis of the form P && Q. How can I get two hypotheses stating P and Q, respectively? [Tue Nov 7 12:08:35 2017] Umm, I probably asked a silly question, the hypothesis actually is P && Q = true, which is equal to (P && Q) = true, not P && (Q = true). Never mind. [Tue Nov 7 12:12:17 2017] And splitting H: P /\ Q can be done with destruct H. Great, solved. [Tue Nov 7 12:31:15 2017] there's a lemma in the stdlib for turning P && Q = true into P = true /\ Q = true [Tue Nov 7 12:31:38 2017] yes, already found it :) [Tue Nov 7 14:04:58 2017] is the ynot-library still maintained? [Tue Nov 7 14:05:39 2017] http://ynot.cs.harvard.edu/ doesn't look like it [Sun Nov 19 11:13:04 2017] I don't understand your question. [Sun Nov 19 11:13:26 2017] well the inductive data type i'm using is this: [Sun Nov 19 11:13:32 2017] Partial application means that you apply a function to a subset of the arguments, yielding a function that may be applied to the remaining arguments [Sun Nov 19 11:13:37 2017] Inductive Integer : Set := [Sun Nov 19 11:13:40 2017] | z : Integer (** Zero *) [Sun Nov 19 11:13:43 2017] | z : Integer (** Zero *) [Sun Nov 19 11:13:48 2017] | n : nat -> Integer. (** -(x+1) *) [Sun Nov 19 11:13:52 2017] | p : nat -> Integer (** x+1 *) [Sun Nov 19 11:14:02 2017] (with only one 'z' of course) [Sun Nov 19 11:14:33 2017] and if I wanted to write a definition for the sign on an integer, I can't figure out how to avoid defining it for the 'z' element [Sun Nov 19 11:14:41 2017] z, n and p are not functions you know, they're constructors. [Sun Nov 19 11:15:07 2017] and all functions in Coq are total, so if you define a function over Integer, it must be defined for _all_ possible values, and z is one. [Sun Nov 19 11:15:45 2017] In most languages, functions need not be total. In Coq, all functions must be total, and the system must be able to prove to itself that they're total. [Sun Nov 19 11:16:01 2017] If you don't know the term, a total function is one defined on all possible values of the type. [Sun Nov 19 11:16:37 2017] what do you mean by 'term'? [Sun Nov 19 11:17:01 2017] Are you a native english speaker? [Sun Nov 19 11:17:06 2017] Yes [Sun Nov 19 11:18:04 2017] Google says, accurately: "term: a word or phrase used to describe a thing or to express a concept, especially in a particular kind of language or branch of study." [Sun Nov 19 11:19:02 2017] "total function" is a phrase used to describe an idea in mathematics and computer science, i.e. a term. Not to be confused with the term "term" when discussing grammars and the like. [Sun Nov 19 11:19:22 2017] Perhaps a better way to state this question: Is there a way to write a function that only takes arguments of 'nat -> Integer' and then has a match structure that would return either p or n? [Sun Nov 19 11:19:55 2017] It seems that coq sees 'nat -> integer' as one of the types of the arguments and then it treats it like an integer since it returns an integer [Sun Nov 19 11:20:46 2017] "nat -> Integer" is not the type of an argument to n or p. the type of n and p is nat ->Integer. [Sun Nov 19 11:21:12 2017] they are constructors that take a "nat" and return an "Integer". You have defined that so with that inductive type definition. [Sun Nov 19 11:21:54 2017] There are three type constructors for your definition, "z", "n", and "p". These are the three ways to construct a thing of type Integer, and the only three ways. The first is a nullary constructor, the other two are unary. [Sun Nov 19 11:22:17 2017] I see [Sun Nov 19 11:24:59 2017] You're clearly starting out with this. Are you studying Coq on your own or in a class? [Sun Nov 19 11:25:56 2017] I'm just learning on my own- it's an interesting language [Sun Nov 19 11:26:43 2017] Do you have prior experience with a language like Standard ML, OCaml or Haskell? [Sun Nov 19 11:27:19 2017] Yes I have done some haskell but I'm not very good at it either [Sun Nov 19 11:27:56 2017] The syntax is somewhat different from Haskell but the idea of the algebraic data types you define is pretty similar. [Sun Nov 19 11:28:04 2017] Are you using Software Foundations as a teaching text? [Sun Nov 19 11:30:00 2017] No, but I did an excercise that I beilieve come from that book [Sun Nov 19 11:30:25 2017] I suggest going through the book from the start. It is the recommended way these days to learn Coq. [Sun Nov 19 11:30:49 2017] The normal documentation is not easy to follow, especially if you aren't already experienced with ML family languages with advanced type systems. [Sun Nov 19 11:31:26 2017] https://softwarefoundations.cis.upenn.edu/current/index.html [Sun Nov 19 11:31:42 2017] Start with Logical Foundations and work your way carefully forward. [Sun Nov 19 11:32:50 2017] i'll give that a try [Sun Nov 19 11:33:09 2017] Do you have a strong background in math or logic? [Sun Nov 19 11:34:06 2017] If not, I suggest being quite patient. The topic is not easy going even for graduate students in computer science. [Sun Nov 19 11:47:17 2017] I have no idea how to prove this theorem from Software Foundations.Theorem andb_true_elim2 : forall b c : bool, [Sun Nov 19 11:47:18 2017] andb b c = true -> c = true. [Sun Nov 19 11:47:51 2017] Can someone give me a hint please? [Sun Nov 19 11:49:55 2017] JamesGrayling: prove it by case analysis on b and c [Sun Nov 19 12:02:28 2017] JamesGrayling: lyxia has it, [Sun Nov 19 12:02:33 2017] that's the right approach. [Sun Nov 19 12:07:31 2017] cocreature: re Functional Scheme for fold_left, neat, thanks -- didn't know you could do that. [Sun Nov 19 12:07:34 2017] that's a ways back now... [Sun Nov 19 12:17:04 2017] What do I do in the cases where the condition is not met? [Sun Nov 19 12:17:50 2017] JamesGrayling: explain? You might want to use pastebin if there's more lines than you can comfortably copy here. [Sun Nov 19 12:18:27 2017] when b = true, c = false. H = true && false = true. [Sun Nov 19 12:18:51 2017] after `simpl.`, H : false = true. [Sun Nov 19 12:19:31 2017] so false = true is contradictory and you can dispose of that case easily because the hypothesis is false. [Sun Nov 19 12:19:45 2017] How do I dispose of the case? [Sun Nov 19 12:20:04 2017] I don't think it's been covered in the book [Sun Nov 19 12:21:03 2017] It has, I suspect. [Sun Nov 19 12:21:13 2017] you can use inversion H., but it hasn't been covered yet if you're going through Basics.v. [Sun Nov 19 12:21:17 2017] but there are several tactics that will get rid of an absurd goal. [Sun Nov 19 12:32:31 2017] "discriminate" is probably the most usual way to kill off false = true [Sun Nov 19 12:34:10 2017] JamesGrayling: you can also use the absurd H equality to rewrite [Sun Nov 19 12:41:48 2017] Oh yeah, rewrite works. I thought it wasn't working because I needed to repeat it 3 times. [Sun Nov 19 12:42:43 2017] Thanks! [Sun Nov 19 12:46:45 2017] oh btw, hi perry [Sun Nov 19 12:49:11 2017] Hello! [Sun Nov 19 12:49:34 2017] dh`: I didn't know you were a Coqer. [Sun Nov 19 12:52:39 2017] all things in their time :-) [Sun Nov 19 15:42:09 2017] It looks like CompCert/VST makes integer overflow wraparound; isn't that actually undefined behavior? [Sun Nov 19 15:46:50 2017] lyxia: it’s undefined behavior for signed integers, for unsigned integers wrap-around is required. [Sun Nov 19 15:48:14 2017] VST makes both wraparound [Sun Nov 19 15:49:02 2017] signed overflow is undefined in C, period. [Sun Nov 19 15:49:40 2017] https://github.com/PrincetonUniversity/VST/blob/master/doc/VC.pdf p16 "The C language specification says a C compiler *may* treat signed integer overflow by wrapping around mod 2^n". [Sun Nov 19 15:49:56 2017] No. [Sun Nov 19 15:50:07 2017] Read the C standard itself. [Sun Nov 19 15:50:15 2017] Sure [Sun Nov 19 15:50:16 2017] It does say this, since it says the compiler may do anything. [Sun Nov 19 15:50:22 2017] I'm asking about the discrepancy. [Sun Nov 19 15:50:55 2017] The compiler MAY choose to generate code to remove all the files on your file system, too. Undefined behavior means literally anything is okay. [Sun Nov 19 15:51:39 2017] Most C compilers presume that undefined behavior cannot happen, that is, if there's a possibility of an undefined behavior occurring, they can blithely presume it will never be triggered and pay attention only to what happens in other cases. [Sun Nov 19 15:52:16 2017] It is absolutely not acceptable to count on any particular behavior for signed overflow in C programs, full stop. Doing so is a way of producing code that isn't merely non-portable but actively dangerous. [Sun Nov 19 15:52:35 2017] pmetzger: well, tell that to the VST/Compcert developers [Sun Nov 19 15:52:38 2017] And yes, this stuff is part of my doctoral dissertation so I know far too much about it. [Sun Nov 19 15:53:07 2017] lyxia: I have met Andrew Appel, but I don't really know him, and I don't work on VST. :) [Sun Nov 19 15:54:05 2017] But my opinion is that any such claim is wrong. If you think you're going to wrap, that's poison. No verified C program should ever try to wrap a signed. [Sun Nov 19 15:56:40 2017] So if I verify code with VST, and forget whether I rely on overflow at some point, I can only expect CompCert to respect the resulting specification? [Sun Nov 19 15:57:01 2017] I hope compcert's semantics don't specify wrapping on signed ints. [Sun Nov 19 15:57:05 2017] pmetzger: If you don't mind, what was your dissertation topic? [Sun Nov 19 15:57:51 2017] Not was, is. I'm defending in a few months. Methods of remediating undefined behavior in C code is the general area. You don't want more detail, it won't fit in a couple of lines. [Sun Nov 19 15:58:40 2017] Okay, thanks :) [Sun Nov 19 16:01:54 2017] Anyway, if you get a copy of the ISO C standard (which is online even though it's not supposed to be), there's an appendix listing all 200 or so undefined behaviors in the language. [Sun Nov 19 16:02:23 2017] pmetzger: Yes I am looking at one, in fact addition is the first example of undefined behavior. [Sun Nov 19 16:08:31 2017] pmetzger: http://compcert.inria.fr/man/manual004.html [Sun Nov 19 16:08:58 2017] CompCert seems to just define a behaviour for signed integer overflow (section 4.4.2) [Sun Nov 19 16:10:05 2017] Which is probably fine, because it's reasonable for CompCert to have more rigorously defined behaviour, especially since the C code could "do anything" [Sun Nov 19 16:10:16 2017] Chobbes: Thanks [Sun Nov 19 16:11:27 2017] There's nothing wrong with CompCert deciding to define it. There's something wrong with VST deciding to define it, because code proven with VST can be compiled with other compilers. [Sun Nov 19 16:11:28 2017] But could lead to inconsistencies when using different compilers, which *shrug*. Probably one of the least causes of concern. I'm sure most compilers just treat it the same way. [Sun Nov 19 16:11:38 2017] No, THEY DO NOT. [Sun Nov 19 16:11:55 2017] C compilers frequently do horrible things when you try to do signed arithmetic that overflows. [Sun Nov 19 16:12:01 2017] HORRIBLE things. [Sun Nov 19 16:12:18 2017] Let me find the canonical example from my diss proposal, one second. [Sun Nov 19 16:12:20 2017] pmetzger: I guess optimization passes will probably look at it and decide "MEH! ALL 0" [Sun Nov 19 16:12:29 2017] oh, far, far worse. [Sun Nov 19 16:12:37 2017] Awesome:P [Sun Nov 19 16:13:08 2017] pmetzger: I think VST is only suppose to be "really" verified when using CompCert, though. [Sun Nov 19 16:13:21 2017] Using other compilers is regarded as "meh, it probably works?" [Sun Nov 19 16:13:22 2017] yah, but you still want the code to work on any compiler. [Sun Nov 19 16:13:44 2017] Yes undefined behavior for overflow is crucial for optimizations [Sun Nov 19 16:13:47 2017] pmetzger: a warning would probably be good. [Sun Nov 19 16:14:06 2017] If you know that x and y are positive, this allows compilers to assume that x+y is also positive. [Sun Nov 19 16:14:09 2017] not a warning. that should be undefined in the semantics to match the C standard. [Sun Nov 19 16:14:20 2017] lyxia: precisely. And they *do* assume that. [Sun Nov 19 16:15:03 2017] hell, I'm having trouble finding my diss proposal. [Sun Nov 19 16:16:07 2017] found it [Sun Nov 19 16:17:20 2017] okay, look at this, and WITHOUT compiling it or looking it up, tell me what it does if you do gcc -O3 to it: https://gist.github.com/pmetzger/d7429b4909eca180e01cd6a9368f4af7 [Sun Nov 19 16:17:55 2017] feel free to then compile it -O3 with llvm or gcc and see if you guessed right. [Sun Nov 19 16:19:39 2017] Now, CompCert is free to define such things, but if one is formally verifying C code, that behavior had better _not_ be defined by the semantics you are using for the C code you're defining. Indeed, it had better be an error to ever hit a state where you wrap a signed. [Sun Nov 19 16:19:44 2017] Wrapping unsigned is totally fine. [Sun Nov 19 16:20:17 2017] pmetzger: I assume VST just uses the CompCert semantics for everything. [Sun Nov 19 16:21:14 2017] That's bad if the CompCert semantics are not what the spec says, because it means people will verify code, assume that the only difference between gcc and CompCert is that the latter is verified, and end up with something totally broken. [Sun Nov 19 16:21:54 2017] Indeed, given the number of bad security holes caused by undefined behavior (like the famous Google NaCl bug caused by a shift by greater than wordlength leading to a test being removed by the compiler) I'd say that's very very bad. [Sun Nov 19 16:22:12 2017] pmetzger: oh totally :). I would be curious how common this is. I haven't used VST, but I'm planning on giving it a try soon. Maybe I'll try to see your example :P. [Sun Nov 19 16:22:14 2017] You want your formal semantics to accurately reflect the language spec, not one particular compiler that goes beyond the spec. [Sun Nov 19 16:22:19 2017] It's very very very common. [Sun Nov 19 16:22:26 2017] I bet it breaks all the same. [Sun Nov 19 16:23:04 2017] I can name a couple dozen bad security bugs caused by undefined behavior. If CompCert defines such behavior, that's fine for _compcert_ but not fine for _VST_. [Sun Nov 19 16:23:37 2017] It's fine for VST when used with CompCert, though. Which is the only "guaranteed path" anyway? [Sun Nov 19 16:23:39 2017] Now as it happens, Mozilla just advertised that some of the crypto code in FireFox is formally verified, and I know that was VST, and I also know they're compiling with the system compiler. [Sun Nov 19 16:23:44 2017] Can you say _terrible_? [Sun Nov 19 16:23:56 2017] pmetzger: okay, fair point. [Sun Nov 19 16:24:09 2017] That's actually a little concerning :|. [Sun Nov 19 16:24:24 2017] More than a little as wrapping behavior shows up in crypto code a lot. [Sun Nov 19 16:24:31 2017] pmetzger: are there tools that print out all the undefined behaviour in a C / C++ program? [Sun Nov 19 16:24:51 2017] Could be interesting to see (quickly) if anything would be invalid under VST. [Sun Nov 19 16:25:12 2017] There's an interpreter out there that sticks whenever it hits undefined behavior (and that's a pretty good one), and there's also the various "die if undefined" flags to gcc, llvm, etc. [Sun Nov 19 16:25:17 2017] pmetzger: I thought the crypto in FireFox was something under F*, though? [Sun Nov 19 16:25:46 2017] That could be the case, I may be mistaken about it being VST, but it's C code, not Rust or what have you. [Sun Nov 19 16:25:52 2017] I assumed it was done with VST. [Sun Nov 19 16:26:10 2017] the TIS interpreter: https://trust-in-soft.com/tis-interpreter/ [Sun Nov 19 16:26:40 2017] but remember, the TIS interpreter isn't formally verified. [Sun Nov 19 16:26:44 2017] https://github.com/mitls/hacl-star [Sun Nov 19 16:26:48 2017] ^ uses this thing. [Sun Nov 19 16:27:14 2017] I didn't think that was what was in firefox [Sun Nov 19 16:27:17 2017] let me check. [Sun Nov 19 16:27:42 2017] no, you're right and I'm totally wrong. [Sun Nov 19 16:27:54 2017] It's HACL* [Sun Nov 19 16:27:55 2017] pmetzger: of course, it goes through CompCerts Clight anyway :). [Sun Nov 19 16:28:14 2017] https://github.com/FStarLang/kremlin/ [Sun Nov 19 16:28:27 2017] So, you know. Same problem :). [Sun Nov 19 16:28:35 2017] Aw, that's bad. [Sun Nov 19 16:28:50 2017] Unless they're distributing object code. [Sun Nov 19 16:28:56 2017] I'm going to tweet and ask. [Sun Nov 19 16:29:11 2017] pmetzger: probably not, lol :P [Sun Nov 19 16:29:54 2017] pmetzger: so, then, if there's a tool that can parse a C file and spit out all instances of undefined behaviour... [Sun Nov 19 16:30:01 2017] I bet you could find a bug pretty fast :P [Sun Nov 19 16:30:35 2017] you literally cannot. [Sun Nov 19 16:30:38 2017] At least when compiled with -Obajillion. [Sun Nov 19 16:30:45 2017] You can't statically check for undefined behavior in C. it requires runtime checks. [Sun Nov 19 16:30:55 2017] I can trivially make the undefined behavior depend on an arbitrary computation. [Sun Nov 19 16:30:57 2017] pmetzger: fair point. [Sun Nov 19 16:31:46 2017] Using C for systems code is like juggling chainsaws while ice skating. It's a cool trick until something goes wrong. [Sun Nov 19 16:33:17 2017] After something goes wrong, cleaning up is, er, messy. [Sun Nov 19 16:37:10 2017] pmetzger: I'm tempted to compile the crypto library with the magical undefined flags now. Would be interesting to see. Not sure if Low* or whatever restricts to fully defined behavior in the spec -- probably just uses Clight semantics. [Sun Nov 19 16:39:54 2017] I would manually scan the code for "int". :) [Sun Nov 19 16:41:05 2017] pmetzger: that's probably easier :P. [Sun Nov 19 16:42:21 2017] Chobbes: wouldn't mind if you retweeted my tweet on this. Sadly people like Regehr aren't usually active on a Sunday evening. (He's probably hiking in some box canyon with his kids.) [Sun Nov 19 16:44:22 2017] pmetzger: I don't know if Mozilla would go along with the CompCert license. [Sun Nov 19 16:44:37 2017] They not only wouldn't but can't. [Sun Nov 19 16:45:04 2017] pmetzger: maybe for their binary releases they could? I'm not really sure. [Sun Nov 19 16:45:16 2017] In theory they could include binary blobs for x86 and ARM. But I doubt they're doing that. And their code runs on other platforms routinely like PPC/POWER. [Sun Nov 19 16:46:08 2017] I guess they do PPC though. [Sun Nov 19 16:46:22 2017] Not MIPS but I guess no one cares about MIPS now. [Sun Nov 19 16:46:48 2017] https://github.com/FStarLang/kremlin/blob/master/DESIGN.md [Sun Nov 19 16:59:17 2017] pmetzger: there are other possible concerns as well. As far as I can tell the Low* to C compiler isn't verified. I could be wrong, but it looks like it's just an OcaML program. [Sun Nov 19 16:59:51 2017] OCaml is the usual capitalization at the moment. It's officially not Objective Caml any more btw. [Sun Nov 19 17:00:29 2017] I think most extractors one can name aren't formally verified of course. I do remember there was one people were working on? [Sun Nov 19 17:00:33 2017] Dammit. So many weird capitalizations to keep track of. [Sun Nov 19 17:00:36 2017] https://arxiv.org/pdf/1703.00053.pdf [Sun Nov 19 17:00:49 2017] There's a quote on what the trusted computing base is in this paper. [Sun Nov 19 17:03:30 2017] Looks like a lot of their assertions involve informal proofs. [Sun Nov 19 17:04:54 2017] Informal = paper and pencil? [Sun Nov 19 17:04:59 2017] Yep. [Sun Nov 19 17:05:50 2017] At first glance it doesn't seem like it's end-to-end verified. Like, it sounds like the semantics of low* are only related to clight by paper and pencil? But I could be reading that wrong. [Sun Nov 19 17:29:04 2017] I know one of the guys on that paper (Catalin). He was a postdoc at Penn. I suppose I could ask him. [Sun Nov 19 17:31:25 2017] It does kind of bring up the interesting question of "what does formally-verified" actually mean. [Sun Nov 19 17:32:54 2017] Well, for CompCert a semantics that defines more than the standard does WRT undefined behavior breaks no conforming code. It's only dangerous to use that semantics in a different context. [Sun Nov 19 17:33:01 2017] I didn't even realize this was a thing. [Sun Nov 19 17:33:22 2017] But yah, formally verified is always "with respect to _what_".... [Sun Nov 19 17:37:59 2017] pmetzger: Oh. I'm also at Penn, partly thanks to him. [Tue Nov 21 15:58:02 2017] I have an inductive Predicate: MyType -> Prop; and I want to write a tactic that invert a hypothesis H: Predicate t only when t is not a variable [Tue Nov 21 15:58:54 2017] you can match goal on the hypothesis and use is_var on its parameter [Tue Nov 21 15:59:00 2017] I tried the follwoing: Ltac t := repeat match goal with | [ H: Predicate ?T |- _ ] => tryif (is_var T) then idtac else inversion H end. [Tue Nov 21 15:59:59 2017] johnw: I'm not sure my tactic is good, especially in the case where there are multiple hypotheses of type Predicate ?T [Tue Nov 21 16:00:53 2017] the match could match a hypothesis of type Predicate x, where x is indeed a variable, so it will just do idtac (or I could put fail instead) [Tue Nov 21 16:01:17 2017] maybe you want is_var T + inversion H [Tue Nov 21 16:04:22 2017] johnw: if I have two hypotheses, H1: Predicate X and H2: Predicate T, where X is a variable and T is not, then the match could just match H1 and then succeed on is_var X [Tue Nov 21 16:04:44 2017] What if you replace `idtac` by `fail` in your tactic? [Tue Nov 21 16:05:20 2017] Cypi: wouldn't that repeat the failure, and still match H1 on the next iteration of "repeat"? [Tue Nov 21 16:05:40 2017] `repeat` will stop when there is no progress anymore [Tue Nov 21 16:05:55 2017] Cypi: but I want it to match H2 after failing on H1 [Tue Nov 21 16:06:00 2017] the failure will make the `match` go to another candidate [Tue Nov 21 16:06:06 2017] hmm [Tue Nov 21 16:08:29 2017] I should probably clear H as well I guess [Tue Nov 21 16:08:36 2017] in case inversion H succeeds [Tue Nov 21 16:09:30 2017] I think it's working properly thanks [Tue Nov 21 16:14:41 2017] is there a tactic that tries to instantiate foralls that appear in the hypotheses with other hypotheses? e.g. if you have H: forall x, F1(x) -> F2(x), and you have some H2: F1(t), it will add a hypothesis F2(t) [Tue Nov 21 16:15:54 2017] (automatically) [Tue Nov 21 22:13:49 2017] should coq always generate a hypothesis every time you use the inductiion tactic? [Tue Nov 21 22:14:11 2017] if not what dictates whether it will or won't? [Tue Nov 21 22:16:12 2017] I've noticed that sometimes it will generate something with a name like IHn in the context when you use induction and sometimes it doesn't [Tue Nov 21 22:20:03 2017] anonlastname: the induction tactic applies an "induction principle" which dictates the subgoals. [Tue Nov 21 22:20:45 2017] https://softwarefoundations.cis.upenn.edu/lf-current/IndPrinciples.html [Tue Nov 21 22:26:46 2017] sud: how about something like match goal with [ H : (forall x : ?T, P x -> Q x), H' : P ?x |- _ ] => pose proof (H x H') end. [Wed Nov 22 05:20:53 2017] anishathalye: yes that would work; is there a way to generalize to more complicate patterns automatically (e.g. foralls with multiple variables, and multiple hypotheses P x -> Q x -> R x -> [...] -> conclusion), and have it do unification etc.? [Wed Nov 22 06:09:35 2017] is there a tactic that succeeds only is the argument is a constructor? [Wed Nov 22 06:13:43 2017] Not that I know of, but it should be possible to craft one. Just to make sure, you want some tactic `is_construct` such that `(is_construct t)` succeeds if and only if `t` is a constructor applied to any arguments? [Wed Nov 22 06:23:10 2017] sud_ : http://lpaste.net/360192 if you need it (note that it warrants some testing, since it looks kind of hack-ish :p ) [Wed Nov 22 06:26:23 2017] Uhoh, it also works on constructors which are not fully applied, because the `econstructor` tactic does not care... [Wed Nov 22 06:32:40 2017] Cypi: thanks! I ended up doing a pattern matching on the constructors I have [Wed Nov 22 06:33:12 2017] Oh right, if you just want it to work for one specific inductive type, it's simpler, of course [Wed Nov 22 06:38:31 2017] Cypi: but then I have to rewrite "is_construct" every time I change my type (and in every different project) [Wed Nov 22 06:39:01 2017] Sure. If you want more flexibility, you can try my version (no guarantee included) [Wed Nov 22 06:41:39 2017] thanks :) [Wed Nov 22 06:42:36 2017] Cypi: can you briefly explain how it works? [Wed Nov 22 06:43:21 2017] So, the goal is to use the `econstructor` tactic to instantiate some evar which is supposed to have the same type as the argument `t` [Wed Nov 22 06:43:39 2017] and then use `reflexivity` to try to unify the evar with `t`, which should succeed only if `t` is in constructor form [Wed Nov 22 06:44:06 2017] So what I do essentially is `assert (exists x, x = t)` [Wed Nov 22 06:44:27 2017] then use `eexists ?[x]` to create an evar named `x` [Wed Nov 22 06:44:40 2017] then `only [x]: econstructor` will instantiate `x` with a constructor [Wed Nov 22 06:44:56 2017] and finally, `reflexivity` will try to unify [Wed Nov 22 06:45:30 2017] The trick is that using `assert` would change the proof term, which I want to avoid. So instead I am creating a variable at the Ltac level, saying that its type must be `exists x, x = t` [Wed Nov 22 06:45:49 2017] and the term that I store in this variable is built by using a tactic, hence the `ltac:(...)` [Wed Nov 22 06:46:51 2017] If creating this whole term succeeded, it means that `t` was a constructor, so I can just succeed with `idtac`, otherwise I am failing with `fail` simply to avoid a weird error message [Wed Nov 22 06:47:03 2017] (you could fail with `fail "Not a constructor"` for instance, it would make more sense) [Wed Nov 22 06:47:31 2017] hope this makes some kind of sense [Wed Nov 22 07:24:18 2017] Cypi: I think so yes thanks [Wed Nov 22 07:26:44 2017] in Ltac, imagine I have H: forall _ _ _ _ _ _, ?P -> ?X, and I have H2: ?Q such that P unifies with Q; I want to write "pose H _ _ _ _ _ _ H2", though I don't know in general how many '_' the forall has [Wed Nov 22 10:52:36 2017] is there a tactic for arithmetic simplification? so something that removes +0, +x-x and so on? [Wed Nov 22 10:53:00 2017] I don’t need anything particularly fancy, a set of builtin rules that perform common simplifications is completely fine [Wed Nov 22 11:00:02 2017] omega? [Wed Nov 22 11:00:41 2017] lyxia: omega can’t solve my goal (and I don’t need it to), I just want to perform some simplifications before I continue [Wed Nov 22 11:04:09 2017] cocreature: I think ringsimpl might work with semirings, but I'm not sure it does what you want? [Wed Nov 22 11:05:28 2017] Chobbes: that looks useful, thanks! [Wed Nov 22 11:05:36 2017] cocreature: you could always write some Ltac to do those rewrites too! [Wed Nov 22 11:05:46 2017] Chobbes: sure, I’m just being lazy :) [Wed Nov 22 11:05:56 2017] ah ring_simplify helps, thanks again [Wed Nov 22 11:12:05 2017] :thumbsup: [Wed Nov 22 11:41:35 2017] how can I proof "r <> 0" from "1 <= r" where r : Real? [Wed Nov 22 11:42:36 2017] ah intro; fourier. does the job [Wed Nov 22 12:02:56 2017] cocreature: lra probably works too. [Wed Nov 22 12:16:56 2017] Chobbes: thanks, I’ll try that next time :) [Wed Nov 22 16:21:58 2017] is it possible to use the first element of an existential in the type signature? I mean, forall (x: (exists T: Prop, T)), fst x, or something like that [Wed Nov 22 16:23:13 2017] yes [Wed Nov 22 16:23:17 2017] but why do you want to :P [Wed Nov 22 16:23:58 2017] as I: I receive a tuple (T: Prop, T), and return the "T" from it (so type signature uses first item, function body uses the second) [Wed Nov 22 16:24:23 2017] I'm still learning, this doubt came up and I couldn't make it work [Wed Nov 22 16:24:39 2017] well, the problem is only that fst is the wrong type [Wed Nov 22 16:24:51 2017] im not sure if theres a name for the corresponding operation on exists [Wed Nov 22 16:27:41 2017] I tried writing an eliminator for exists but I keep getting Prop/Type problems [Wed Nov 22 21:06:26 2017] Is it possible to prove that [forall (a b : nat), beq_nat a b = true -> a = b]? [Wed Nov 22 21:08:43 2017] yes [Wed Nov 22 21:08:53 2017] induction a [Wed Nov 22 21:09:13 2017] ok thank you just wanted to make sure it wasn't a fools errand [Wed Nov 22 23:49:26 2017] I'm having an issue when installing coqide with a fresh opam switch, on OCaml 4.06.0 [Wed Nov 22 23:49:28 2017] # File "ide/ideutils.ml", line 376, characters 38-74:# Error: This expression has type string but an expression was expected of type bytes [Wed Nov 22 23:54:33 2017] I think this is because it might not be compatible (yet) with the safe strings from OCaml, which are made default by OCaml 4.06.0 [Wed Nov 22 23:55:52 2017] I don't know exactly when support for safe strings will be coming (for all I know it might already be implemented in the dev branch), but in the meantime, I think either 4.05.x or 4.06.0+default-unsafe-string should work. [Wed Nov 22 23:58:53 2017] Cypi: I did opam switch 4.05.0, and now I have to reinstall coq as well (even though coq compiled fine on 4.06.0), is that normal? [Wed Nov 22 23:59:18 2017] Sadly yes. Anything compiled with some version of OCaml will be unusable with another version of OCaml :( [Thu Nov 23 00:00:04 2017] Therefore, the opam switches are completely independent from one another, there is no sharing or anything [Thu Nov 23 00:00:37 2017] Cypi: alright, recompiling! do you know why the coq installation page suggests setting: export OPAMROOT=~/opam-coq.8.6; now everything I have (both switches) is in that folder [Thu Nov 23 00:01:22 2017] I don't know, sorry, I never did that [Thu Nov 23 00:03:18 2017] how will the system decide between which coqc to use, since there are one for each switch? [Thu Nov 23 00:04:50 2017] Normally both switches should have separate folders, so I'm a bit confused by the suggestion [Thu Nov 23 00:06:23 2017] I see, and I just have to "opam switch" to obtain the executables compiled with the other version [Thu Nov 23 00:07:05 2017] Yes. Among other things, `opam switch` will add to your PATH the correct folder containing binaries for the current switch [Thu Nov 23 05:00:05 2017] Hi, what does "intro" do or mean in the beginning of a Proof.? [Thu Nov 23 05:15:35 2017] Forlorn: can you step in the proof and see how it operates on your goal? basically, if your goal is to prove A -> B, intro will put A into your hypothesis, and you'll have to prove B [Thu Nov 23 05:25:16 2017] sud_, Thanks, I think I have got the hang of this now [Thu Nov 23 06:13:25 2017] hm, I find it a bit strange that coq looks very inspired by haskell, but is implemented in ocaml [Thu Nov 23 06:13:28 2017] anyone know why? [Thu Nov 23 06:13:41 2017] I mean, why haskell was not chosen [Thu Nov 23 06:14:29 2017] Haskell did not even exist at the time though [Thu Nov 23 07:16:13 2017] Any one using vim as editor for coq? [Thu Nov 23 07:16:21 2017] Any recommended plugins? [Thu Nov 23 09:12:47 2017] ggVGc: I think syntactically, it looks more like ml/ocaml than haskell [Thu Nov 23 09:16:35 2017] well, it seems I had my history wrong [Thu Nov 23 09:16:40 2017] I was sure coq was newer than haskell [Thu Nov 23 09:20:32 2017] According to "A History of Haskell", the decision of designing what became Haskell was taken in 1987, with the first version of Haskell being released in 1990 [Thu Nov 23 09:20:55 2017] https://coq.inria.fr/about-coq seems to say that Coq started in 1984 [Thu Nov 23 09:22:03 2017] https://caml.inria.fr/about/history.en.html says that Caml was also aimed at developping Coq at some early point [Thu Nov 23 10:18:03 2017] coq turns out to be a lot older than it seems like it ought to be [Thu Nov 23 10:18:10 2017] you aren't the first to have noticed this :-) [Fri Nov 24 02:29:33 2017] in coqdoc is there a way to emphasis/bold text ? [Fri Nov 24 02:30:06 2017] More generally what is the reference for the markup and text formating instructions that one can use in coqdoc [Fri Nov 24 02:33:42 2017] One of the documentation which I read says that it uses the Almost Free Text format but it looks like the '' notation for italics for example does not work in coqdoc [Fri Nov 24 06:33:05 2017] I'm trying to organize my files by separating theorems/proofs and tactic files. But then as soon as I have a dependencies tactic1 -> Lemma1 -> tactic2, I have to create a new tactic file to avoid cyclic dependencies in the source files. What is the recommended way of working with multiple sources? [Fri Nov 24 06:43:57 2017] sud_: how is your tactic2 depending on Lemma1 ? [Fri Nov 24 06:44:45 2017] piyush-kurur: yes [Fri Nov 24 06:46:49 2017] Depending on application I guess but I found the strategy of complete automation as recommended in the CPDT book to be the only feasible method to do large scale proofs [Fri Nov 24 06:47:48 2017] If you are following such strategy I would suggest that you have a generic "crush tactic" writen in a tactic file and then Supply your domain specific lemma (like Lemma1 etc) to crush using various kinds of hints [Fri Nov 24 06:48:39 2017] (need less to say that the crush tactics will have a default clause where it tries tactic like eauto etc where the hint database come into play) [Fri Nov 24 07:54:46 2017] piyush-kurur: did you see https://coq.inria.fr/refman/tools.html#coqdoc ? It looks like they have only one kind of emphasis (italics) but you can also inline latex or html. [Fri Nov 24 07:56:18 2017] lyxia: thanks great. [Fri Nov 24 10:42:22 2017] Depending on application I guess but I found the strategy of complete automation as recommended in the CPDT book to be the only feasible method to do large scale proofs [Fri Nov 24 10:42:51 2017] so far I have not found that and in fact it seems crazy to me (to go to the point of automating every last corner case) [Fri Nov 24 10:43:28 2017] is this because of what I've been working on, or does it more likely reflect some basic difference in approach? [Fri Nov 24 10:45:54 2017] (what I've been working on: a lot of it is the string library I occasionally talk about, but I've also done several rounds of type system soundness and i've been messing with some other things like concurrency models) [Fri Nov 24 10:55:09 2017] it seems to me that the critical thing for large proofs is a good decomposition into lemmas [Fri Nov 24 10:55:22 2017] (like dealing with large bodies of code) [Fri Nov 24 10:56:14 2017] I've gotten into a few things where I end up with 500 cases, but mostly they can be dismissed with things like "all: try (apply foo; discriminate)" [Fri Nov 24 10:56:38 2017] and sure that could be an ltac but I don't see anything much to be gained by making it one [Fri Nov 24 17:07:30 2017] is there any way to write a tactic which can do different things to each goal? [Fri Nov 24 17:08:03 2017] i.e. - so that i can write something like [destruct big_inductive_type_inhabitant; my_tactic] and have my_tactic operate differently on each case [Fri Nov 24 17:08:25 2017] or even [my_tactic (destruct big_inductive_type_inhabitant)] would be a fine calling convention [Fri Nov 24 17:09:09 2017] well, ok in that second case i could of course implement it as [Ltac my_tactic t := t; [case_a | case_b | case_c]] [Fri Nov 24 17:09:51 2017] but im thinking about something programmatic, like if i could dynamically address different goals [Fri Nov 24 17:10:28 2017] e.g., being able to pass in a uconstr list of lemmas and have them applied pointwise to the remaining goals [Fri Nov 24 17:31:42 2017] benzrf: if you have such a list, maybe you could try to deconstruct it and use the head lemma with something like `only 1: apply lemma`? [Fri Nov 24 17:31:54 2017] Ah wait, this would only work if it actually solve the goal [Fri Nov 24 17:32:25 2017] hmm. [Fri Nov 24 17:32:31 2017] I don't know x) [Fri Nov 24 17:32:49 2017] well the other thing is [Fri Nov 24 17:32:56 2017] are there any sequencing primitives besides ; [Fri Nov 24 17:33:08 2017] because if you solve, how can you work on the next goal? you certainly cant do it with ; [Fri Nov 24 17:33:51 2017] well yes you can [Fri Nov 24 17:34:03 2017] Goal True /\ True. split; only 1: exact I; only 1: exact I. Qed. [Fri Nov 24 17:34:06 2017] this works, for instance [Fri Nov 24 17:39:48 2017] woah wat [Fri Nov 24 17:40:28 2017] i thought if there were no more subgoals it didnt run the tactic [Fri Nov 24 17:41:18 2017] This is `split; (only 1: exact I); (only 1: exact I)`. So, after the splits, there are two goals under focus, it applies the tactic `only 1: exact I` on these two goals. This tactic focuses on the first goal and applies `exact I`, solving it. Then there are one goal remaining under focus, it applies `only 1: exact I` on this goal, solving it too. [Fri Nov 24 17:42:15 2017] well, this works: [split; (only 1: exact I; only 1: exact I)] [Fri Nov 24 17:43:48 2017] well yes [Fri Nov 24 17:44:07 2017] this is still `split; ((only 1: exact I); (only 1: exact I))` [Fri Nov 24 17:44:22 2017] however, this shouldn't work: `split; only 1: (exact I; only 1: exact I)` [Fri Nov 24 17:44:30 2017] (saying something about a goal that doesn't exist probably) [Fri Nov 24 17:48:58 2017] oh, what the fuck [Fri Nov 24 17:49:05 2017] why cant u match on uconstrs [Fri Nov 24 17:49:16 2017] ah right, match wants a typed term...... [Fri Nov 24 17:49:22 2017] (which is very annoying if you ask me) [Fri Nov 24 17:49:30 2017] (but there is probably some kind of reason somewhere) [Fri Nov 24 17:49:41 2017] well i literally cant do that because what im hauling around is intropatterns [Fri Nov 24 17:49:54 2017] You could have nested pairs instead of a list [Fri Nov 24 17:49:54 2017] mfw ltac doesnt have lists [Fri Nov 24 17:50:04 2017] still cant match [Fri Nov 24 17:50:07 2017] uconstr [Fri Nov 24 17:50:15 2017] In a constr I mean [Fri Nov 24 17:50:15 2017] oh wait does ltac have pairs [Fri Nov 24 17:50:23 2017] What does one element of your list looks like? [Fri Nov 24 17:50:26 2017] look* [Fri Nov 24 17:50:27 2017] an intropattern [Fri Nov 24 17:50:45 2017] So stuff like [[? _] | x] ? [Fri Nov 24 17:50:56 2017] well, to be precise, arguments to refine [Fri Nov 24 17:51:50 2017] i wanna cut down on this repetition https://i.imgur.com/K6mK0dy.png [Fri Nov 24 17:53:03 2017] Ah, so you would like stuff like `impl_I (impl_E _ (conj_E2 _))` in your list I guess :/ [Fri Nov 24 17:53:09 2017] i figured putting this stuff in a list would both get rid of all of the fcp_case and make me no longer need parens around each one [Fri Nov 24 17:53:12 2017] yup [Fri Nov 24 17:53:13 2017] isn't there anyway to compute these from the goal? [Fri Nov 24 17:53:32 2017] any way* [Fri Nov 24 17:53:37 2017] i mean, possibly, but writing sufficiently advanced ltac would be more work than just putting these in [Fri Nov 24 17:53:52 2017] probably, depends on your usecase [Fri Nov 24 17:54:36 2017] well, bbl :T [Fri Nov 24 17:55:36 2017] (the problem is that these are propositional logic proofs and the assumption rule, lem, and multiple elimination rules, all apply to any goal) [Fri Nov 24 17:55:44 2017] (well not lem. whatever) [Fri Nov 24 17:55:52 2017] (so i cant just exhaustively search constructors) [Fri Nov 24 18:25:10 2017] one of the things you can do if there are a lot of effectively duplicate cases is produce the hypotheses to solve them beforehand (before generating all the cases) and then auto will clean them up [Fri Nov 24 18:28:36 2017] that's the thing though, they arent really duplicate [Fri Nov 24 18:28:46 2017] this is the pared-down version, i already automated all the duplicate parts :) [Fri Nov 24 18:29:34 2017] the tactic essentially refines and then does some auto stuff - the terms im passing in are basically the important parts of the derivations, and the holes are where im appealing to assumptions or induction hypotheses [Fri Nov 24 19:22:55 2017] Hello, [Fri Nov 24 19:23:36 2017] I'm trying to use the autosubst library, and to "debug" my code, I'd like to be able to evaluate some code [Fri Nov 24 19:23:44 2017] I tried to do: [Fri Nov 24 19:23:52 2017] Eval simpl in (Var 1).[ren (+1)]. [Fri Nov 24 19:24:12 2017] it outputs ?Subst (ren (+1)) (Var 1) [Fri Nov 24 19:24:35 2017] : mytype [Fri Nov 24 19:24:49 2017] have you tried compute instead of simpl? [Fri Nov 24 19:25:24 2017] benzrf: yes, compute gives a stranger result: ?Subst (fun x : nat => ?H (S x)) (Var 1) [Fri Nov 24 19:26:04 2017] o= [Fri Nov 24 19:26:16 2017] do you have the appropriate instances? [Fri Nov 24 19:26:28 2017] should I ask what the notation (Var 1).[ren (+1)] means? [Fri Nov 24 19:26:41 2017] I loaded Ids, Rename, Subst, SubstLemmas [Fri Nov 24 19:27:03 2017] dh_work: it should be something like "add 1 to all the variables" [Fri Nov 24 19:27:30 2017] but in order to be sure, I'd like to display the result ;) [Fri Nov 24 19:29:46 2017] hmm [Fri Nov 24 19:29:55 2017] I don't have any idea what you're working with then, so I can't really help :-) [Fri Nov 24 19:29:56 2017] tobiasBora: did you use Qed anywhere? [Fri Nov 24 19:32:07 2017] benzrf: after the last Instance, I put SubstLemmas ... . derive. Qed. as explained in the doc [Fri Nov 24 19:32:17 2017] heuh [Fri Nov 24 19:32:35 2017] idk, i just thought maybe a failure to compute could be because of an opaque term somewhere [Fri Nov 24 19:32:42 2017] i dont know much about instances or about autosubst! [Fri Nov 24 19:35:57 2017] Hum, if I copy paste the example code it seems to give me a better result... Let me check the differences [Fri Nov 24 19:36:05 2017] If I have a class (Arbitrary : Type -> Type), with a method (arbitrary : forall A (Arbitrary A), A), and a single instance (Arbitrary unit), somehow that instance gets picked even if there are no constraints (e.g., just type (Check arbitrary)), is there a way to avoid that? [Fri Nov 24 19:37:13 2017] I don't really have a reason for it behaving one way or the other TBH, other than I'm used to how it works in Haskell [Fri Nov 24 19:48:00 2017] benzrf: dh_work I found the problem ! In fact, I got two types that uses the autosubst library, the first one with only "var", and the second one with the "{bind }" syntax. Because "var" was just another name for "int", I thought that I would not need to use the instance also on the first type... But I was wrong, when I create two sets of instances for both types, it seems to work better [Fri Nov 24 19:48:05 2017] Thank you for your help ! [Fri Nov 24 22:19:27 2017] tobiasBora: oh , good [Fri Nov 24 22:26:29 2017] How can I show that [max a b = n -> a = n \/ b = n]? Is it possible to use the fact that the only terminating brances in the fixpoint definition of max are either a or b? [Fri Nov 24 22:28:53 2017] what do you mean by "terminating branches"? [Fri Nov 24 22:29:50 2017] in the "match ... with" statement the only parts that don't call max return either a or b [Fri Nov 24 22:30:26 2017] just because they recurse doesn't mean they don't terminate [Fri Nov 24 22:30:45 2017] Yes but when they do terminate it's either a or b [Fri Nov 24 22:30:48 2017] which is what I want to prove [Fri Nov 24 22:30:52 2017] well, consider this [Fri Nov 24 22:30:56 2017] what if i evaluate [max 4 5] [Fri Nov 24 22:31:02 2017] then that has to recurse [Fri Nov 24 22:31:06 2017] it still terminates though! [Fri Nov 24 22:31:27 2017] And it will also satisfy my hypothesis [Fri Nov 24 22:31:45 2017] yes - im not claiming your proposition is false :) [Fri Nov 24 22:31:57 2017] The hypothesis I'm trying to prove is certainly true because every fixpoint will terminate and the only things it can terminate to are a or b [Fri Nov 24 22:31:58 2017] oh wait hold on i think i see what you mean [Fri Nov 24 22:32:04 2017] yeah, that makes sense [Fri Nov 24 22:32:56 2017] hmm, but hold on - that's not quite right [Fri Nov 24 22:33:23 2017] what you're saying would make sense if it were tail-recursive [Fri Nov 24 22:33:41 2017] but you can't just talk about what it results in when it terminates, because that result will be modified by the wrapping S [Fri Nov 24 22:35:18 2017] I see what you are saying [Fri Nov 24 22:35:42 2017] in any case, though - [Fri Nov 24 22:35:49 2017] the general principle tends to be like follows: [Fri Nov 24 22:36:30 2017] the "call graph", if you want to think of it that way, of a structurally recursive function, is isomorphic to its decreasing argument as a tree [Fri Nov 24 22:36:53 2017] well - at least, to some truncation of it. [Fri Nov 24 22:37:14 2017] insofar as a function recurses, it can only do so by filling out the shape of its decreasing argument [Fri Nov 24 22:37:40 2017] therefore, to prove a property by induction over the "call graph", you can equivalently prove it by induction over the decreasing argument [Fri Nov 24 22:38:34 2017] In this case both the arguments are decreasing [Fri Nov 24 22:39:17 2017] that's true, but that only gives you more opportunities [Fri Nov 24 22:39:34 2017] you can probably still work with the explicitly-marked-as-decreasing argument though [Fri Nov 24 22:39:45 2017] if you try [Print Nat.max] it should tell you that max is structural in n [Fri Nov 24 22:40:38 2017] well, maybe i should stop giving advice until i check whether it's actually applicable... :) [Fri Nov 24 22:47:20 2017] anonlastname: fyi, i think this would be better stated as [max a b = a \/ max a b = b] [Fri Nov 24 22:48:13 2017] Perhaps, but this came up in the context of another proof [Fri Nov 24 22:48:53 2017] ok, i just worked out a proof, and i can tell you that induction on the first argument indeed works [Fri Nov 24 22:49:04 2017] be careful with your choice of induction hypothesis, though [Fri Nov 24 22:49:34 2017] Alright thanks for the help [Fri Nov 24 22:50:48 2017] np [Fri Nov 24 23:46:02 2017] dh`: I have mostly been doing certain straight forward induction + some variation so it might be because of that I found the CPDT method working well (I should admit I am yet to do some really cutting edge proving) [Fri Nov 24 23:48:06 2017] dh` I think that strategy might not work for math theorems. But for applications like correctness of compilers I guess that is the only sane way as often your Inductive types change a lot in content but not in substance (You added a new syntactic sugar for example). [Fri Nov 24 23:50:23 2017] also when I say complete automation, there might still be some tiny little adjustments one needs to do (like one needs to intro the variable at the correct time for induction to work etc). So generally the fully automated proofs do tend to look like a bunch of intros and inductions and then crush. [Fri Nov 24 23:53:42 2017] nothing I've been doing is particularly cutting-edge really [Fri Nov 24 23:54:31 2017] in the string library, a lot of the proofs have the same general outline, but they're all slightly different in details and automation just seems hard and fairly pointless [Sat Nov 25 00:18:46 2017] dh_work: do you find your self repeating some same set of tactics ? [Sat Nov 25 00:20:05 2017] That is the first indication that there is some possibility of automation [Sat Nov 25 00:21:03 2017] Also there is one advantage of having a crush, you can use it to write not just proofs. YOu can use it to fill in your other functions. [Sat Nov 25 00:22:27 2017] Some times coq behaves in strange ways because it is not able to see that two things are of the same type. In such cases I have also found the strategy of writing an incomplete version of the match using refine and disposing of holes in the match using the crush [Sat Nov 25 00:23:55 2017] those programs look like refine(match _ => whatever); crush [Sat Nov 25 04:33:48 2017] hi, I'm going through IndProp.v from the Software Foundations book. I have proven that the given ternary relation encodes plus: https://pastebin.com/EsgqAdEy However, it took me a long time because in the second "-" bullet, I had to find out how to completely remove H after rewrite <- H. (If H is not removed, then the following induction hypotheses would be more complicated and not useful.) [Sat Nov 25 04:34:01 2017] Finally I did it using destruct H. [Sat Nov 25 04:37:02 2017] But I don't really understand the magic - why using destruct on H: m + n = o just removes it, why this influenced the induction hypotheses that followed, and how could I possibly remove any hypothesis I want. [Sat Nov 25 04:37:37 2017] To remove an hypothesis, you can just use `clear H` (as long as nothing depends on `H`) [Sat Nov 25 04:38:17 2017] Cypi: great, works fine :-) thanks [Sat Nov 25 04:38:48 2017] In general, destructing an hypothesis with `destruct` will remove it, and refine the goal depending on how this hypothesis could have been built. If you have `n : nat` and do `destruct n`, it will generate two subgoals where `n` is replaced by `O` and `S n'`. [Sat Nov 25 04:39:47 2017] If you have `H: m + n = o` and do `destruct H`, the only way to build a proof of equality is with its only constructor, `eq_refl`. So it will generate one subgoal where `H` is replaced by `eq_refl`, and also `o` is replaced by `m + n`. [Sat Nov 25 04:40:31 2017] wow, so I didn't even need to use rewrite <- H. [Sat Nov 25 04:41:20 2017] `rewrite <- H` and `destruct H` for such a proof of equality will basically do the same anyway. [Sat Nov 25 04:41:25 2017] (apart from clearing H or not) [Sat Nov 25 04:41:39 2017] If your intent was to rewrite, then using `rewrite` is perfectly fine :) [Sat Nov 25 04:41:40 2017] I think I got it, thank you very much [Sat Nov 25 07:58:12 2017] Hello, [Sat Nov 25 08:11:35 2017] I'm still trying to understand autosubst. And I need to define two types "typea" and "typeb". In "typea", I define a "Var (_ : var)", and in "type b" I define a "Forall (_ : {bind typea in typeb}) | Myeq (_ : typea) (_ : typeb)" [Sat Nov 25 08:11:57 2017] Then I load all the instances, for both types [Sat Nov 25 08:12:11 2017] And finally I try to do some tests: [Sat Nov 25 08:12:30 2017] Eval compute (Var 0).[ren (+1)] [Sat Nov 25 08:12:37 2017] ==> good result: Var1 [Sat Nov 25 08:12:47 2017] BUT the following code does nothing: [Sat Nov 25 08:13:16 2017] Eval compute (Myeq (Var 0) (Var 1)).[ren (+1)]. [Sat Nov 25 08:13:31 2017] It just gives me (Myeq (Var 0) (Var 1)). [Sat Nov 25 08:14:42 2017] (oh, I forgot, in type b, I also add a dummy instruction "dummy (_ : var)" because without it I can't load the instance. Maybe both problems are linked ?) [Sat Nov 25 08:18:23 2017] Any idea how I could let "talk together" the two types ? [Sat Nov 25 08:50:51 2017] I have definitions that I want automatically unrolled, but I don't want to change my tactics everytime I add a new definition; what's the proper way of doing that? [Sat Nov 25 09:21:56 2017] Hum, if you don't have the solution for autosubst, I may have a simpler question. I use "Eval compute ", and at the end I have something like "((((Var 0) =p (Var 0)) = ((Var 0) =p (Var 0))) -> False) -> False" [Sat Nov 25 09:22:28 2017] The center equality is obviously true, so it should remap to (true -> false) -> false [Sat Nov 25 09:23:38 2017] i.e. (False -> False), ie True. [Sat Nov 25 09:24:04 2017] Why does the computation stays into this big equation ? [Sat Nov 25 09:24:08 2017] *stay [Sat Nov 25 09:25:01 2017] I don't know if it's important, but all of the symbols Var and =p are defined using "Inductive" [Sat Nov 25 09:27:21 2017] (and =p is just an infix operation for Equalp) [Sat Nov 25 09:31:42 2017] tobiasBora: a simpler example is: Eval compute in (0 = 0). basically, "0 = 0" is a proposition (a Prop), and cannot be reduced anymore/computed [Sat Nov 25 09:32:55 2017] really ? [Sat Nov 25 09:33:22 2017] try it :) [Sat Nov 25 09:33:57 2017] So maybe I'm doing it in the wrong way. I'd like to debug some functions that returns Prop to be sure they do what I expect. [Sat Nov 25 09:34:06 2017] return* [Sat Nov 25 09:34:57 2017] tobiasBora: do you want to prove that the given Prop always "holds"? [Sat Nov 25 09:34:58 2017] so for now I run "Eval compute in myfunction()", and I get this (often) ugly output. [Sat Nov 25 09:35:16 2017] sud: Not really, I just want to run some tests on my function. Like [Sat Nov 25 09:35:34 2017] assert (f 42 45) False [Sat Nov 25 09:35:44 2017] assert (f 12 10) True [Sat Nov 25 09:35:46 2017] ... [Sat Nov 25 09:35:59 2017] Just for debuging [Sat Nov 25 09:36:04 2017] tobiasBora: perhaps what you really wanted was returning a boolean? [Sat Nov 25 09:36:50 2017] Well after I'll do real proof on it, so I guess that boolean would not be what I want. [Sat Nov 25 09:37:22 2017] tobiasBora: things that are in Prop do not reduce to True or False [Sat Nov 25 09:37:55 2017] tobiasBora: can you do: Example test1: f 42 45. Proof. [Sat Nov 25 09:38:38 2017] or f 42 45 -> False if you're expecting that the Prop "f 42 45" does not hold [Sat Nov 25 09:40:20 2017] sud: Hum it may be a good idea if there is a tactic that can do the proof easily. [Sat Nov 25 09:41:31 2017] the "simpl." tactics gives me the same output as Eval simpl... so it's a good point [Sat Nov 25 09:42:25 2017] tobiasBora: perhaps someone else can help you with that, but you can try simpl, intuition and congruence; can I have a look at the goal? [Sat Nov 25 09:43:15 2017] hum, in fact "auto" works great. What is intuition ? [Sat Nov 25 09:43:34 2017] (intuition also work great ^^) [Sat Nov 25 09:43:46 2017] (and also congruence, amazing) [Sat Nov 25 09:44:39 2017] thank you ! [Sat Nov 25 10:00:26 2017] tobiasBora: not sure exactly (see https://coq.inria.fr/refman/tactics.html#hevea_tactic175 for congruence) [Sat Nov 25 10:01:13 2017] you can have a tactic: Ltac easy := repeat (simpl || congruence || intuition || subst). or similar that tries a bunch of those [Sat Nov 25 10:09:46 2017] sud: good to know, thank you! [Sat Nov 25 10:28:04 2017] And by the way I solved my autosubst problem [Sat Nov 25 10:44:26 2017] tobiasBora: what was it? I joined after [Sat Nov 25 10:47:22 2017] sud: I got some troubles to define with autosubst two types, with typeb that depends on typea. When I was trying to update the typeb, nothing happened. And the solution was to define HSubst instance, and then use .| instead of . [Sat Nov 25 10:57:56 2017] By the way, in coq was is the convention in notation ? What should I write LikeThat, Like_that, like_that, or likeThat ? [Sat Nov 25 11:00:23 2017] 2nd to last is most common [Sat Nov 25 11:00:43 2017] i think UpperCamelCase is used for some things but unsure [Sat Nov 25 11:04:54 2017] tobiasBora: here's some results from the standard theories shipped in the main coq codebase https://gist.github.com/c8a90f86259ed5306457d82394d58e21 [Sat Nov 25 11:05:21 2017] snake_case seems to overwhelmingly dominate :) [Sat Nov 25 11:05:46 2017] (line 367 for the results from the other 2) [Sat Nov 25 11:06:38 2017] benzrf: ok thanks. So I should not differentiate types and constructors ? [Sat Nov 25 11:07:43 2017] i just realized i forgot one - it seems that Capital_snake_case is also very common (although not as common as lower_snake_case) [Sat Nov 25 11:07:57 2017] i think constructors often start with capital letters, but im not sure theres a hard and fast rule [Sat Nov 25 11:09:56 2017] tobiasBora: for what it's worth, the constructors of option begin with capitals but the constructors of le begin with lowercase [Sat Nov 25 11:10:50 2017] i think the idea is roughly that the constructors of a type like le are more like "axioms for le" and hence ordinary names, whereas the constructors of option are more like "data constructors" [Sat Nov 25 11:11:06 2017] but on the other hand, nil and cons are lower case... [Sat Nov 25 11:11:08 2017] so who knows :) [Sat Nov 25 11:21:52 2017] benzrf: ok thank you ;) [Sat Nov 25 11:22:34 2017] np [Sat Nov 25 11:51:06 2017] I've been wondering what naming conventions would be best for the string library given that I'd like to get it merged [Sat Nov 25 11:56:52 2017] piyush-kurur: there are some cases where things are repeated, but mostly it's only things like two branches within a single proof; one could write an ltac but it doesn't really help much in general [Sat Nov 25 11:59:10 2017] this is a fairly typical one: http://codepad.org/ooASZH4Q [Sat Nov 25 11:59:30 2017] two of the middle cases are the same, but they're not long and they're not really the same as anything else [Sat Nov 25 12:00:57 2017] Hi! [Sat Nov 25 12:01:46 2017] I’m looking for examples of proofs by well-founded induction about definitions done with “Program Fixpoint” [Sat Nov 25 12:01:56 2017] dh`: how does [simpl in H; firstorder using ascii_distinct] fare [Sat Nov 25 12:02:09 2017] firstorder is really nice [Sat Nov 25 12:02:31 2017] I’ve used Program Fixpoint to define a step-indexed logical relation, now I need to do a proof with the same termination order [Sat Nov 25 12:02:34 2017] good question [Sat Nov 25 12:02:37 2017] let's try [Sat Nov 25 12:04:12 2017] * twiddles while it compiles [Sat Nov 25 12:04:51 2017] pgiarrusso: Do you mean that you've already taken care of the obligations? [Sat Nov 25 12:05:48 2017] lyxia: yes [Sat Nov 25 12:05:56 2017] benzrf: nothing [Sat Nov 25 12:06:05 2017] dh`: ouch [Sat Nov 25 12:06:36 2017] the simpl'd H is forall def : ascii, def = a [Sat Nov 25 12:07:00 2017] and now that I look at it I recall ascii_distinct being a pain in the !#$@ [Sat Nov 25 12:07:30 2017] not so much proving it as having to prove three or four forms of it for different appearances of the same concept [Sat Nov 25 12:08:05 2017] although everything involving ascii is a hassle [Sat Nov 25 12:14:56 2017] Lemma ascii_distinct: [Sat Nov 25 12:14:56 2017] forall (a: ascii), [Sat Nov 25 12:14:56 2017] (forall b, a = b) -> False. [Sat Nov 25 12:16:34 2017] now I can't find the alternate forms of it; I think maybe I cleansed them all [Sat Nov 25 12:17:18 2017] hmm [Sat Nov 25 12:17:36 2017] is there a way to reason directly about the constructors a type has? [Sat Nov 25 12:17:49 2017] what do you mean [Sat Nov 25 12:17:54 2017] there's match [Sat Nov 25 12:19:32 2017] a generalization of that lemma of the form: forall (t: Type) (a: t) (c: t), constructors t = [c] -> forall b, a = b. [Sat Nov 25 12:19:55 2017] that is, a type with one nullary constructor is a singleton so all elements of that type are equal [Sat Nov 25 12:20:35 2017] or something like forall (t: Type) (a: t), length (constructors t) > 1 -> forall b, a = b -> False [Sat Nov 25 12:20:50 2017] I'm guessing this can't be done [Sat Nov 25 12:21:17 2017] since it's a form of reflection that I'm pretty sure we don't have [Sat Nov 25 12:23:44 2017] assert (forall a b : t, a = b) as H by (now destruct a, b). [Sat Nov 25 12:24:37 2017] you can do that for any singleton type, but not write it once for all singleton types [Sat Nov 25 12:25:26 2017] that's true, but why do you want that in particular [Sat Nov 25 12:26:08 2017] oh, some sort of contrapositive for proving ascii_distinct? [Sat Nov 25 12:26:19 2017] Isn't it a one-line tactic [Sat Nov 25 12:27:43 2017] a general way of dealing with problems like ascii_distinct [Sat Nov 25 12:28:27 2017] if the string library were parameterized over the character type (it's supposed to be, but isn't yet), ascii_distinct becomes a headache [Sat Nov 25 12:28:43 2017] s/becomes/would become/ [Sat Nov 25 12:28:45 2017] * can grammar [Sat Nov 25 12:38:13 2017] dh`: https://gist.github.com/a96fbc58717fae57928decfbc8b4fc6e [Sat Nov 25 12:39:39 2017] huh, curious that firstorder takes it if it's written as <> [Sat Nov 25 12:39:53 2017] oh wait, that's not the head proof. derp [Sat Nov 25 12:39:59 2017] huh? [Sat Nov 25 12:40:03 2017] head proof? [Sat Nov 25 12:40:05 2017] that's a nicer proof of ascii_distinct than I have though [Sat Nov 25 12:40:09 2017] :) [Sat Nov 25 12:40:14 2017] the lemma I pasted a few minutes back [Sat Nov 25 12:40:18 2017] may I steal it? [Sat Nov 25 12:40:22 2017] sure! [Sat Nov 25 12:40:26 2017] and how would you like it to be credited? [Sat Nov 25 12:40:39 2017] i cede copyright to you [Sat Nov 25 12:40:47 2017] i just did it in like 6 minutes :P [Sat Nov 25 12:41:11 2017] I'm an academic of sorts, I'd like it to say "from benzrf; used by permission" [Sat Nov 25 12:41:14 2017] lyxia: is the “one-line tactic” thing an answer to me by any chance? [Sat Nov 25 12:41:15 2017] well, ok [Sat Nov 25 12:41:19 2017] that's fine by me [Sat Nov 25 12:41:26 2017] if you don't want to expose your real name, that's fine [Sat Nov 25 12:41:53 2017] pgiarrusso: unfortunately not, I don't have any idea [Sat Nov 25 12:42:24 2017] quick note: i proved the exists first and the forall as a corollary because going from [exists b, a <> b] to [~forall b, a = b] is just distributing the negation outside of the exists and flipping the quantifier [Sat Nov 25 12:42:37 2017] - but you cant push a negation inside a forall to get an exists in intuitionistic logic [Sat Nov 25 12:44:06 2017] for reference, this was mine: http://codepad.org/HhKDkANk [Sat Nov 25 12:44:08 2017] that said, if you dont need both lemmas, it's pretty trivial to inline the distribution of negation into the first proof [Sat Nov 25 12:44:31 2017] u just specialize your hypothesis to the b instead of giving it as a witness [Sat Nov 25 12:44:41 2017] ah [Sat Nov 25 12:44:46 2017] I might need both; I suspect having both will improve the string proofs [Sat Nov 25 12:44:55 2017] :) [Sat Nov 25 12:45:01 2017] FWIW, looking into the Program libraries — it seems I might need to use Fix_sub_rect by hand somehow [Sat Nov 25 12:46:12 2017] dh`: fyi, you can do just [specialize (H a1)] [Sat Nov 25 12:46:44 2017] Hello. Is there a way to specify in a SearchAbout pattern that two terms (as usually specified by an underscore "_") should be equal? (As a simple example, SearchAbout (_ - _ = 0) to something like SearchAbout (a - a = 0).) [Sat Nov 25 12:46:54 2017] really all it does is apply a hypothesis to some argument [Sat Nov 25 12:47:31 2017] so you can even go from [H : P -> Q, J : P] to [H : Q] with [specialize (H J)] [Sat Nov 25 12:50:51 2017] speaking of which, is there an off-the-shelf tactic that simplifies hypotheses by making trivial mandatory specializations? [Sat Nov 25 12:51:10 2017] like that converts H: forall x, x = y -> ... to just ... [Sat Nov 25 12:51:45 2017] oh, interesting [Sat Nov 25 12:52:58 2017] "favorite" is a pretty loaded term [Sat Nov 25 12:53:01 2017] oops [Sat Nov 25 12:53:06 2017] (wrong window) [Sat Nov 25 12:53:11 2017] for that specific case, [specialize (H _ eq_refl)] works [Sat Nov 25 12:53:19 2017] i dont know that there's something more general though [Sat Nov 25 12:53:43 2017] right, but in cases where a lot of these appear (which seems to be always if one is ever doing induction in a complicated environment) [Sat Nov 25 12:53:49 2017] yeah :I [Sat Nov 25 12:53:53 2017] well - [Sat Nov 25 12:53:57 2017] it would be nice to have a single thing to invoke to fix the whole hypothesis bank [Sat Nov 25 12:54:36 2017] applying a hypothesis to something will attempt to unify as far to the right as necessary, which will automatically specialize if it can infer specialization from unification [Sat Nov 25 12:55:21 2017] yeah, but it doesn't always work plus you end up with lots of trivial goals to discharge [Sat Nov 25 12:55:24 2017] so if you can get far enough for the specializations you need to be easily recognizable as necessary intermediate steps, something like tauto or firstorder may finish for you [Sat Nov 25 12:55:32 2017] apply H; auto usually covers most of them, but it's still annoying [Sat Nov 25 12:57:44 2017] also when you get a lot of them it's difficult to read the hypothesis bank [Sat Nov 25 12:58:06 2017] and in particular, difficult to tell for sure if you reverted the right things before starting the induction [Sat Nov 25 13:00:24 2017] anyway, I guess this tactic doesn't exist (yet) [Sat Nov 25 13:01:56 2017] tbh if you have a lot of equalities involved it's pretty possible you're making the wrong statement [Sat Nov 25 13:02:10 2017] that's possible [Sat Nov 25 13:03:17 2017] if you have [forall x, x = y -> P x y], it seems to me that probably P shouldn't've mentioned x in the first place [Sat Nov 25 13:03:22 2017] do you have a particular example? [Sat Nov 25 13:03:31 2017] not offhand [Sat Nov 25 13:03:41 2017] it just seems to come up a lot, particularly with complex higher-level things [Sat Nov 25 13:04:11 2017] hmm [Sat Nov 25 13:04:43 2017] but you can get forall x, x = y -> P x y by doing induction on y when your goal is P x y [Sat Nov 25 13:05:03 2017] and x = y is a fact you acquired earlier [Sat Nov 25 13:05:09 2017] well... [Sat Nov 25 13:05:15 2017] substitute the equation before doing the induction :) [Sat Nov 25 13:05:17 2017] of course if so you should have subst'd to get rid of y [Sat Nov 25 13:05:24 2017] jinx [Sat Nov 25 13:05:40 2017] of course if you do, then you still get y = y -> P x y [Sat Nov 25 13:05:56 2017] subst should clear the equation [Sat Nov 25 13:06:03 2017] or you can manually remove it [Sat Nov 25 13:06:09 2017] it doesn't if it was there first [Sat Nov 25 13:06:17 2017] e.g. x = y is only true in this branch [Sat Nov 25 13:07:45 2017] (then how would you get it in H? I forget but it happens) [Sat Nov 25 13:07:49 2017] dh`: have you looked at match goal with? [Sat Nov 25 13:07:57 2017] anyway we need a real example to discuss this intelligently [Sat Nov 25 13:08:01 2017] yeah [Sat Nov 25 13:08:05 2017] also i shd really go soon ;v; [Sat Nov 25 13:08:20 2017] I should have gone an hour ago :-/ [Sat Nov 25 13:08:22 2017] ttyl [Sat Nov 25 13:08:43 2017] dh`: I’ll explain relevance for later [Sat Nov 25 13:09:39 2017] if you get often forall x, x = y -> P x, you should be able to match on it with match goal and apply some tactic [Sat Nov 25 13:09:42 2017] something like [Sat Nov 25 13:10:57 2017] I'd like to know, I'd like to define a type "theory", that has several "instances", like "Inductive th1 : theorie := A : th1 42 | B : th1 43", and "Inductive th2 : theorie := C : th1 142 | D : th1 242". Then, I define a parametrize "Inductive proof (myth:theorie) : int -> Prop := ... | Axth : forall (x:myth) (n:int), x n -> proof n.". The problem is that this is not accepted. How could I say that "x" should be [Sat Nov 25 13:11:00 2017] constructed by the constructors of th1 if myth is th1, and by the constructor of th2 if if myth is th2 ? [Sat Nov 25 13:11:05 2017] yes, but writing a custom ltac to just do that doesn't actually save any typing over "specialize (H _ eq_refl)" [Sat Nov 25 13:11:29 2017] but what you _can_ do is write one that scans all your hypotheses and does it to the right ones automatically [Sat Nov 25 13:11:46 2017] then you can do [induction whatever; scan_hyps] [Sat Nov 25 13:13:25 2017] right, I was asking if this tactic already existed [Sat Nov 25 13:13:38 2017] since it seems to me like a useful general-purpose tactic [Sat Nov 25 13:13:50 2017] since it doesn't, writing it is a second exercise [Sat Nov 25 13:13:57 2017] well that was pgiarrusso's point [Sat Nov 25 13:14:21 2017] right, but it needs to be broader than just that [Sat Nov 25 13:14:34 2017] because there's also forall y, P y -> x = y -> ... [Sat Nov 25 13:15:00 2017] dh`: maybe context might help here [Sat Nov 25 13:15:13 2017] anyway we need a real example to discuss this intelligently [Sat Nov 25 13:15:27 2017] I'll come back when I have one ready to hand :-/ [Sat Nov 25 13:15:31 2017] dh`: for this kind of [P y], this would just be something that can also be trivially proved, right? [Sat Nov 25 13:15:37 2017] you're not looking to generate new obligations? [Sat Nov 25 13:15:45 2017] depends [Sat Nov 25 13:15:55 2017] what I'd like it to do is leave behind P y -> ... [Sat Nov 25 13:16:03 2017] hmmmmmm [Sat Nov 25 13:16:08 2017] actually i have an idea... [Sat Nov 25 13:16:11 2017] let me see [Sat Nov 25 13:16:14 2017] tobiasBora: are you sure theorie isn’t just Set? That seems like a starting point [Sat Nov 25 13:16:21 2017] anyway bbl [Sat Nov 25 13:18:15 2017] benzrf: I’m thinking match goal with | H : forall x, context f [ x = ?y -> ?P ] => ... end [Sat Nov 25 13:18:25 2017] ooh [Sat Nov 25 13:18:30 2017] yeah i was thinking similar stuff [Sat Nov 25 13:18:42 2017] :) https://i.imgur.com/5iOw78Y.png [Sat Nov 25 13:18:50 2017] but I’m less sure how to then call H with the right number of argument, I’d need to inspect f somehow? [Sat Nov 25 13:19:33 2017] pgiarrusso: Hum, I'm not sure, how could I test it ? [Sat Nov 25 13:19:38 2017] benzrf: could you try dropping the `?` from `forall ?x,` [Sat Nov 25 13:19:42 2017] because when I run this code I've something like 'The term "myth" has type "theorie" which should be Set, Prop, or Type. [Sat Nov 25 13:19:44 2017] i did [Sat Nov 25 13:20:27 2017] tobiasBora: how did you define theorie? But maybe definitions aren’t expanded there [Sat Nov 25 13:20:42 2017] I’d just use Set [Sat Nov 25 13:21:02 2017] that should be enough for your example [Sat Nov 25 13:21:03 2017] pgiarrusso: Definition theorie: int -> Prop. [Sat Nov 25 13:21:27 2017] That’s := ? [Sat Nov 25 13:21:36 2017] yes sorry [Sat Nov 25 13:22:52 2017] but then, if (myth: theorie), myth is a type constructor not a type, so (x: myth) is wrong [Sat Nov 25 13:23:12 2017] there you’d want forall (n: int) (x: myth n) [Sat Nov 25 13:23:34 2017] yes it's wrong indeed, and I understand why, but I don't see how to correct it, because if I put (x: theorie), then I forget the fact that x should be a constructor of myth [Sat Nov 25 13:23:49 2017] * is thinking [Sat Nov 25 13:24:01 2017] again, forall (n: int) (x: myth n) [Sat Nov 25 13:24:16 2017] in the Axth [Sat Nov 25 13:24:42 2017] tobiasBora: ^^ [Sat Nov 25 13:26:14 2017] pgiarrusso: Hum... Interesting. So here x will be of type "int -> Prop" or it will be the evaluation of "myth n" ? [Sat Nov 25 13:27:31 2017] tobiasBora: myth will have type int -> Prop, and x will have type myth n (and therefore, also its result) [Sat Nov 25 13:28:02 2017] I guess you used evaluation for “result” or “value” [Sat Nov 25 13:28:09 2017] (not sure it’s wrong but it sounds strange) [Sat Nov 25 13:30:02 2017] benzrf: ah, you forgot the | before H [Sat Nov 25 13:30:59 2017] benzrf: Coq accepts Ltac foo := match goal with | H : forall x, ?P x |- _ => idtac end. [Sat Nov 25 13:31:56 2017] benzrf: Coq’s parser, like OCaml’s, doesn’t have great error messages [Sat Nov 25 13:32:01 2017] at least I can use Coq [Sat Nov 25 13:32:14 2017] with OCaml I managed but it was always a struggle [Sat Nov 25 13:32:52 2017] (in OCaml’s defense, I learned the theory of ML modules before doing any programming in it, that’s bound to be frustrating) [Sat Nov 25 13:42:17 2017] pgiarrusso: Hum, it kind of work, but too much, now it refuses to type when the property is wrong ^^ Here is the code: https://zb.phyks.me/?2cc8c6f382cfdb4c#GKke2NcxO7cHYjMS7nzqJGeXv2NYW4Eeq06+ujTmj2o= [Sat Nov 25 13:42:37 2017] All the lines behave as expected, except for the line "Check (Axth th2 Zero C)." [Sat Nov 25 13:43:02 2017] Because C is a constructor of th2, I would expect it to type, even if it reduces to "False" [Sat Nov 25 13:45:31 2017] tobiasBora: well, I fear then you have to take *two* different indexes m and n [Sat Nov 25 13:46:40 2017] also, wait [Sat Nov 25 13:47:06 2017] strictly speaking (as we should), there’s no definition there that reduces to False [Sat Nov 25 13:47:47 2017] I mean, Axth th2 Zero takes an argument of type th2 Zero [Sat Nov 25 13:48:07 2017] now th2 Zero does not reduce to false, but it is empty [Sat Nov 25 13:50:11 2017] you can try Axth: forall (n : int) (m : int) (x : myth m), proof myth n [Sat Nov 25 13:50:35 2017] and then later you can define an interpreter for proofs that says this proof is not valid unless m = n [Sat Nov 25 13:50:38 2017] pgiarrusso: does that mean that I need to manually enter the "m" when I call Axth, like "Check (Axth th2 Zero (S (S Zero)) C )." (so that means that I know a value where C is valid ?) (Sorry if I say nonsense, it's quite unclear in my mind) [Sat Nov 25 13:51:02 2017] tobiasBora: with that definition yes [Sat Nov 25 13:51:40 2017] this is quite correct [Sat Nov 25 13:51:41 2017] one can change things to make sure that m is inferred automatically from x, for convenience [Sat Nov 25 13:52:07 2017] the language feature for that is called “implicit arguments” [Sat Nov 25 13:52:45 2017] but I’m not sure exactly how it works, I use it and it does something sensible, but I’d rather not explain it [Sat Nov 25 13:53:20 2017] but I think if you give the command Set Implicit Arguments before that, probably you won’t have to write the m arguments when calling Axth [Sat Nov 25 13:54:20 2017] pgiarrusso: Hum... If I do that, it fails to type check [Sat Nov 25 13:54:44 2017] it thinks that the x is the dummy "m" value [Sat Nov 25 13:55:30 2017] Did you add Set Implicit Arguments *before* the definition? [Sat Nov 25 13:55:43 2017] (like, beginning of the file) [Sat Nov 25 13:55:58 2017] yes [Sat Nov 25 13:56:19 2017] OK, then ignore what I said on how to use implicit arguments [Sat Nov 25 13:56:43 2017] either don’t use them and pass m, ask somebody else, or google them [Sat Nov 25 13:57:03 2017] ok thanks [Sat Nov 25 13:57:20 2017] But maybe I'm trying to do the wrong thing. [Sat Nov 25 13:58:42 2017] “making m implicit” makes sense [Sat Nov 25 13:59:03 2017] but I’m less sure on “allowing m and n to be different” [Sat Nov 25 13:59:22 2017] I mean, you are defining a datatype of proofs [Sat Nov 25 13:59:30 2017] (that’s what the type is called) [Sat Nov 25 13:59:55 2017] if you don’t have both m and n, that type will only contain valid proofs, it seems [Sat Nov 25 14:00:05 2017] instead of having invalid ones that somehow “reduce to False” [Sat Nov 25 14:00:32 2017] and “have only valid proofs” is often an advantage of using dependent types [Sat Nov 25 14:01:57 2017] However, having *datatypes* indexed by numbers, as you do, can get tricky in Coq when you do proofs — I’m no expert, but lots of old tactics work less well on those types, you often need the “dependent” variants from Sozeau [Sat Nov 25 14:07:42 2017] dh`, pgiarrusso: repeat match goal with H : forall x : ?T, @?P x |- _ => let x := fresh in evar (x : T); specialize (H x); match type of H with context [x = ?y -> _] => instantiate (x:=y); subst x end end. [Sat Nov 25 14:07:52 2017] that should be half of the functionality :') [Sat Nov 25 14:08:35 2017] it will instantiate vars and turn the equations into trivial equations - [Sat Nov 25 14:08:42 2017] but it doesnt clear the trivial equations as hypotheses [Sat Nov 25 14:08:47 2017] but i seriously have to go so im leaving it there [Sat Nov 25 14:08:57 2017] benzrf: cool [Sat Nov 25 14:09:08 2017] hmm also the "@?P x" could probably be replaced with just _ [Sat Nov 25 14:09:19 2017] its left over from another pass [Sat Nov 25 14:10:39 2017] oh and it needs another clause for equalities w/ the variable on the right [Sat Nov 25 14:10:53 2017] ah, in the match type [Sat Nov 25 14:43:10 2017] pgiarrusso: Ok, maybe it would be enough even if it does not type when the properties are different... I also found another way to do what I want. Thank you very much for your help [Sat Nov 25 14:45:30 2017] what's a good strategy to do inversion on hypotheses in Ltac (so that it does not loop and only do inversion on "useful" things) [Sat Nov 25 14:46:45 2017] sud: +1, I had the same problem [Sat Nov 25 14:47:59 2017] I don’t have a good general solution [Sat Nov 25 14:48:03 2017] but in some project I ended up with [Sat Nov 25 14:49:00 2017] Ltac inversion_clear_some := simpl in *; match goal with | H : Some ?x = Some ?y |- _ => inversion_clear H; subst end. [Sat Nov 25 14:49:16 2017] I also had variants using tlc’s inverts tactic [Sat Nov 25 14:49:27 2017] but *nothing* was always robust [Sat Nov 25 14:50:00 2017] so sometimes I had to use inversion instead of inversion_clear, because otherwise I’d lose information [Sat Nov 25 14:50:33 2017] in the tactic above, using `repeat` before `match goal` won’t loop [Sat Nov 25 14:50:59 2017] but IIRC inversion_clear might still lose information [Sat Nov 25 14:51:41 2017] But I’m still a newbie, so I’m mostly joining your question [Sat Nov 25 14:56:20 2017] what about inversion H; [idtac]; clear H? [Sat Nov 25 14:56:27 2017] found in https://jozefg.bitbucket.io/posts/2014-07-09-dissecting-crush.html [Sat Nov 25 14:59:00 2017] sud: no clue, what should [idtac] do? looking up [Sat Nov 25 14:59:21 2017] pgiarrusso: idtac is a tactic that does nothing [Sat Nov 25 15:00:07 2017] I get that, but what’s the point there? [idtac] must do something I guess [Sat Nov 25 15:00:09 2017] from the web page: Remember that [t | t' | t''] is a tactic that runs t on the first subgoal, t’ on the second, and so on. If the number of goals don’t match, [] will fail. So [idtac] is just a clever way of saying “there’s only one new subgoal”. [Sat Nov 25 15:01:06 2017] so you only do inversion if it does not add more subgoals [Sat Nov 25 15:01:24 2017] right, makes sense [Sat Nov 25 15:04:18 2017] pgiarrusso: oh that fails if the inversion succeeds in solving the goal and has 0 subgoals [Sat Nov 25 15:05:05 2017] does it? really? shouldn’t Coq just stop the Ltac program then? [Sat Nov 25 15:05:18 2017] but then you can add a try solve [inversion H] before [Sat Nov 25 15:06:31 2017] or rather, follow the webpage more closely [Sat Nov 25 15:06:48 2017] see the `(inversion H; fail) ||` bit and its explanation [Sat Nov 25 15:07:17 2017] OK, so it sounds like I should just be using (pieces of) crush there [Sat Nov 25 15:10:55 2017] pgiarrusso: yes it fails [Sat Nov 25 15:11:10 2017] but I don't understand that part inList F invOne; [Sat Nov 25 15:11:36 2017] me neither — at least there’s text about it [Sat Nov 25 15:12:16 2017] anyway: I’m also a newbie, should probably study it some other time, gotta go now :-| [Sat Nov 25 15:13:31 2017] (also, even though I realize it’s hard, I keep being disappointed by how much work one needs to do on top of raw tactics to make them actually convenient to use. It... works, but it all feels so primitive) [Sat Nov 25 15:13:46 2017] which is why I guess “use crush” is probably decent advice [Sat Nov 25 15:14:30 2017] ah, invOne is a list of predicates on which we allow inversion [Sat Nov 25 15:26:01 2017] but I would have to explicitly pass that list everytime I add a new constructor [Sat Nov 25 15:27:32 2017] sud: well, crush has a builtin list [Sat Nov 25 15:27:59 2017] they use the empty list [Sat Nov 25 15:28:19 2017] (Ltac crush := crush' false fail.) [Sat Nov 25 15:29:51 2017] basically I am defining many inductive relations, and I don't want to have to redefine my tactics every time; I'd like to be able to easily change the list when defining a new relation [Sat Nov 25 15:30:20 2017] aah wait [Sat Nov 25 15:30:32 2017] invOne is a list of blacklisted things [Sat Nov 25 15:31:12 2017] > First we run the inList predicate, meaning that we don’t invert upon anything that we don’t want to [Sat Nov 25 15:31:20 2017] sud: ^^ [Sat Nov 25 15:31:47 2017] pgiarrusso: no I think it's a white list [Sat Nov 25 15:32:11 2017] the entire textbook using crush *never* uses crush’ [Sat Nov 25 15:32:34 2017] and the text pretty clearly says it’s a blacklist — it might be wrong of course [Sat Nov 25 15:32:38 2017] but that would be more confusing [Sat Nov 25 15:32:51 2017] but I don’t get how it works either [Sat Nov 25 15:34:18 2017] pgiarrusso: in the book it's described as a white list, also the definition inList definitely checks that the constructor is in the list [Sat Nov 25 15:34:40 2017] from the book "The second argument is a list of predicates on which inversion should be attempted automatically." [Sat Nov 25 15:35:08 2017] I think the website meant that "we don't want to invert on stuff outside the white list" [Sat Nov 25 15:35:27 2017] though I don't understand how crush works so well if it doesn't do inversion by default [Sat Nov 25 15:37:38 2017] sud: OK, sorry, you’re right [Sat Nov 25 15:38:37 2017] maybe it does inversion elsewhere — and it does handle a few special cases specially [Sat Nov 25 15:38:57 2017] (say, it uses injection on Some, below) [Sat Nov 25 15:39:24 2017] still: the core advice of the book is “write your own automation” [Sat Nov 25 15:39:47 2017] (IIUC) [Sat Nov 25 15:39:57 2017] yes trying to :) right now my tactic loops forever because it does inversion on equality [Sat Nov 25 15:40:00 2017] (haven’t read that part closely, only the intro, and bits and pieces) [Sat Nov 25 15:40:13 2017] and it things it's doing progress [Sat Nov 25 15:40:22 2017] thinks* [Sat Nov 25 15:40:59 2017] uh, maybe you want to blacklist equality then? only use injection there somehow? [Sat Nov 25 15:41:59 2017] i'll look up injection I didn't know that thanks [Sat Nov 25 15:45:57 2017] me neither honestly [Sat Nov 25 15:59:58 2017] trying to make sense of inList [Sat Nov 25 16:00:27 2017] given some definition f, inList f f fails [Sat Nov 25 16:02:22 2017] inList idtac idtac as well [Sat Nov 25 16:05:44 2017] the text suggests it takes lemmas, but I’m not sure it’s true [Sat Nov 25 16:06:19 2017] (I mean, that blog is cool but full of typos, so I’m not sure the details are necessarily extremely accurate — which is OK for a blog I guess) [Sat Nov 25 16:10:27 2017] inList f (f) worked in the end I think [Sat Nov 25 16:17:59 2017] anyone knows how to have local (non recursive) definitions automatically unfolded? [Sat Nov 25 17:56:18 2017] Hum... Is it possible in coq to generate a new variable to generate a Prop ? [Sat Nov 25 18:38:35 2017] How do I prove that [forall (n : nat), n = n \/ S n = n]? [Sat Nov 25 18:39:02 2017] intros; left; reflexivity. [Sat Nov 25 18:39:13 2017] or just "auto" or "intuition" should do it [Sat Nov 25 18:39:27 2017] Ah thank you I didn't know about that tactic [Sat Nov 25 18:39:35 2017] intuition is very handy, but it can be slow [Sat Nov 25 18:39:39 2017] if it is, try "intuition idtac" [Sat Nov 25 18:40:21 2017] I meant I didn't know about the left tactic but thanks anyways [Sat Nov 25 18:40:25 2017] ah, ok [Sat Nov 25 18:40:33 2017] left works with any 2 constructor type [Sat Nov 25 22:42:19 2017] what's the equivalent of Print for ltac bits? [Sun Nov 26 00:07:00 2017] dh` : `Print Ltac foo.` [Sun Nov 26 03:03:13 2017] sud_: Coq’s reference manual suggests to *not* use inversion so lightly, because it creates large proofs, and to save inversion lemmas instead [Sun Nov 26 03:04:32 2017] in programming languages you often see *books* state inversion lemmas Iaxh, even when [Sun Nov 26 03:04:35 2017] sorry [Sun Nov 26 03:05:02 2017] books state inversion lemmas, *say for typing relations* (say, TAPL) [Sun Nov 26 03:05:31 2017] sometimes even when they’re trivial [Sun Nov 26 03:06:51 2017] sud_: maybe *that* is why crush uses inversion carefully [Sun Nov 26 03:52:22 2017] sud_: comments on inversion_sigma here seem maybe interesting: https://coq.inria.fr/library/Coq.Init.Tactics.html [Sun Nov 26 06:29:07 2017] Hello, [Sun Nov 26 06:33:00 2017] I'd like to convert a formula into my own type into a Prop. Is it possible to generate fresh variables that I can pass in argument ? With something like "let meta_var = new metavar, let p = get_prop(A, m::meta_var), forall meta_var, p" ? [Sun Nov 26 06:33:22 2017] s/into my own type/from my own type [Sun Nov 26 06:33:55 2017] or to index variables by array [Sun Nov 26 06:34:47 2017] Like, I have a list of variable name, and I can do something like my_var_list[0] to refer to the first variable [Sun Nov 26 06:35:17 2017] and then write "forall my_var_list[0], my_var_list[0] \/ my_var_list[1]" [Sun Nov 26 06:36:58 2017] which would be equivalent to "forall a, a \/ b : Prop" [Sun Nov 26 07:01:17 2017] I provide here an example: https://stackoverflow.com/questions/47495923/coq-meta-programming-generate-fresh-variable [Sun Nov 26 08:19:36 2017] Ok problem solved [Sun Nov 26 08:32:31 2017] I have two mutually recursive functions define with Fixpoint ... with ..., but Coq cannot guess the decreasing argument. I have a (nat) measure on the arguments of the functions; can I specify this measure to Coq, without changing too much the syntax of my program? (and then I'll have to prove that the measure decreases on each recursive call) [Sun Nov 26 08:40:14 2017] sud: use Program Fixpoint [Sun Nov 26 08:42:31 2017] lyxia: I got "Well-founded fixpoints not allowed in mutually recursive blocks" [Sun Nov 26 09:01:29 2017] That's unfortunate. [Sun Nov 26 09:03:13 2017] Can you pick a single function to define with Program Fixpoint, and make the others parameterized by it? [Sun Nov 26 09:05:36 2017] sud: http://lpaste.net/360257 for example [Sun Nov 26 09:06:49 2017] yes that would work, thanks! [Sun Nov 26 09:14:03 2017] lyxia: uh, it’s surprising that typechecks! It must be Russell’s type rules? [Sun Nov 26 09:14:12 2017] I get why that definition makes sense [Sun Nov 26 09:14:37 2017] But it’s less obvious that you can use even at that type [Sun Nov 26 09:15:00 2017] Also, wished that Program’s documentation showed such an example [Sun Nov 26 09:22:17 2017] pgiarrusso: Well-founded fixpoints make the recursive occurence of even have that type [Sun Nov 26 09:24:00 2017] Yeah, but that’s usually hidden, so I wonder on the typing rules [Sun Nov 26 09:24:15 2017] I should look for them [Sun Nov 26 09:45:21 2017] can I use a lexicographic ordering for a measure? [Sun Nov 26 09:46:52 2017] (my function L1 L2 calls itself on L1' L2' where L1' is a subterm of L1, or (L1' = L1 and L2' is a subterm of L2) [Sun Nov 26 10:05:28 2017] I know that you can prove [a = b] from a proven hypothesis of [S a = S b], but how do you simplify a goal of [S a = S b] to [a = b]? [Sun Nov 26 10:05:53 2017] that is, you can prove it from a proven hypothesis using the injection tactic [Sun Nov 26 10:07:37 2017] You can use the tactic `f_equal` [Sun Nov 26 10:11:29 2017] thanks [Sun Nov 26 10:17:57 2017] sud: http://lpaste.net/360262 (Obligation 1 is the proof that the measure is WF) I don't know how to make this simpler though. [Sun Nov 26 10:29:06 2017] thanks! [Mon Nov 27 16:57:44 2017] I'm playing around with Coq and I have: Axiom test : Set. Axiom member : test. how can I start proving Theorem cardinality_set : (forall i : test, member = i). ? I was thinking intros/rewrite combination but seems it's not that simple? [Mon Nov 27 16:58:06 2017] (skip the theorem name, it was from something I experimented previously) [Mon Nov 27 17:09:02 2017] sud: such consistency bugs are fixed quickly, googling `coq proof false` leads to https://news.ycombinator.com/item?id=9259790 for the last instance [Mon Nov 27 17:09:56 2017] The last more serious bug was this one I think https://sympa.inria.fr/sympa/arc/coq-club/2013-12/msg00119.html [Mon Nov 27 17:10:21 2017] it didn't make Coq inconsistent by itself, but it made it inconsistent with propositional extensionality, which is wrong [Mon Nov 27 17:11:07 2017] thanks for the references! [Mon Nov 27 17:11:20 2017] bor0: I don't think you can prove this. [Mon Nov 27 17:11:34 2017] why? member is the only axiom of test [Mon Nov 27 17:12:15 2017] And yet you cannot prove that. I lack the experience to explain this properly, but I'm quite certain of it [Mon Nov 27 17:12:30 2017] basically, you asserted that `test` is a type, but you know absolutely nothing about it [Mon Nov 27 17:12:41 2017] so you don't know if it's empty or not or anything else [Mon Nov 27 17:13:03 2017] Then you assert that `member` has type `test`. Now you know one element in `test`, but still, that's all you know about `test`. [Mon Nov 27 17:13:10 2017] bor0: I think you want Inductive test: Set := | member: test [Mon Nov 27 17:14:02 2017] With what sud said, `test` is defined much more precisely: this is the inductive type with one constructor called `member`, so you can prove that this is the only value in that type. [Mon Nov 27 17:14:21 2017] (because an inductive type is defined as the least fixpoint of a monotonous operator blah blah) [Mon Nov 27 17:14:42 2017] (then you will need to use destruct i or induction i to prove your theorem) [Mon Nov 27 17:14:55 2017] (sorry I have to go) [Mon Nov 27 17:15:44 2017] ahh that works, thank you! [Mon Nov 27 17:25:42 2017] given IH: max (max a b) c = max a (max b c), what tactics can I use to prove max (max (S a) b) c = max (S a) (max b c)? I believe it's something around rewrite? [Mon Nov 27 17:26:05 2017] I'm experimenting with Coq, trying to prove (max (max a b) c) = (max a (max b c)) :D [Mon Nov 27 17:26:25 2017] `rewrite IH` should do it, right? [Mon Nov 27 17:26:37 2017] Found no subterm matching "Nat.max (Nat.max a b) c" in the current goal. *shrug* [Mon Nov 27 17:26:42 2017] Oh wait, nevermind x) [Mon Nov 27 17:26:47 2017] I've already tried that :D [Mon Nov 27 17:27:04 2017] I need to rewrite a to (S a) in my IH, and then use exact IH [Mon Nov 27 17:27:05 2017] So, IH speaks exactly of `a`, not `S a` [Mon Nov 27 17:27:24 2017] What you need to do is somehow extract the S in your goal [Mon Nov 27 17:27:28 2017] bet: you need to generalize more variables before doing induction [Mon Nov 27 17:27:33 2017] if you just `simpl`, what does it look like? [Mon Nov 27 17:27:55 2017] bor0: IH comes from induction I’m guessing? [Mon Nov 27 17:28:01 2017] a huge block of Nat.max match b with, looks scary [Mon Nov 27 17:28:07 2017] pgiarrusso, yea. I can show the full code I have if you want [Mon Nov 27 17:28:28 2017] I use double induction. I'm probably doing something wrong :) [Mon Nov 27 17:28:50 2017] I’m on a hurry, but I think you need to have a more general induction hypothesis, that’s a common problem [Mon Nov 27 17:28:55 2017] or, it depends on the goal [Mon Nov 27 17:29:12 2017] but if you have forall a b c and do intro [Mon Nov 27 17:29:26 2017] yeah I have that [Mon Nov 27 17:29:32 2017] you probably need to move back forall X in the goal, where X is anything you don’t do induction on [Mon Nov 27 17:29:47 2017] or, well, for that goal [Mon Nov 27 17:29:52 2017] you’d need to have forall a, ... [Mon Nov 27 17:30:10 2017] so that IH becomes general enough to be usable on S a [Mon Nov 27 17:30:33 2017] http://lpaste.net/360311 [Mon Nov 27 17:30:48 2017] caveat: I don’t know if this is your problem, but this is the recipe for 90% of similar cases [Mon Nov 27 17:31:41 2017] whoops, I forgot to paste 2 axioms I'm using. if you don't see them please refresh the paste [Mon Nov 27 17:32:03 2017] Since I'm guessing this is an induction on a, it won't be usable directly on `S a`. However pgiarrusso is right, it will be better if you generalize a bit. [Mon Nov 27 17:32:21 2017] So when you do your induction (on `a` for instance), make sure that `b` and `c` are still in the goal [Mon Nov 27 17:32:25 2017] I can probably prove the axioms to be theorems but I can do that later. focused on the main theorem for now [Mon Nov 27 17:32:44 2017] Cypi is right, if you do induction on a you can’t have “forall a” in your hypothesis [Mon Nov 27 17:33:22 2017] what should I have in my hypothesis instead? [Mon Nov 27 17:33:23 2017] Also, if `max` is the one defined in the stdlib, you won't need any axiom [Mon Nov 27 17:33:24 2017] in fact, during induction on a, you can’t have your hypothesis hold on S a [Mon Nov 27 17:33:38 2017] that would mean proving the thesis using itself [Mon Nov 27 17:33:45 2017] that would be circular [Mon Nov 27 17:33:53 2017] (I mean, you won't need to prove anything else, you can do the whole proof with intros/induction/destruct/rewrite/reflexivity) [Mon Nov 27 17:33:54 2017] ow. I see. [Mon Nov 27 17:34:17 2017] so if I were doing this by hand manually, I'd probably use cases for a > b, b > c, etc. can I approach it like that in Coq? [Mon Nov 27 17:34:24 2017] you need to modify your goal (by simplification) so that it turns into something else [Mon Nov 27 17:34:47 2017] I gotta go now, but others should be able to help you [Mon Nov 27 17:34:53 2017] thanks for the help! [Mon Nov 27 17:34:57 2017] but you’ll need to say which definition of max you are using ;-) [Mon Nov 27 17:35:17 2017] I believe it's Nat.max, the one built-in [Mon Nov 27 17:36:15 2017] Then you can do it without much trouble with a simple induction [Mon Nov 27 17:36:40 2017] If you want to use cases as you were saying, you can probably do it too. You will need to use something like `le_dec` to reason by cases [Mon Nov 27 17:36:52 2017] and you will need some lemmas about how `max` behaves with respect to inequalities [Mon Nov 27 17:37:14 2017] (these lemmas probably exist already in the stdlib I would guess, since it's basically the specification of the function max) [Mon Nov 27 17:37:22 2017] ok, so this doesn't seem to be as simple as I thought for a Coq beginner. I should probably move to simpler stuff :D [Mon Nov 27 17:37:35 2017] Doing it by induction is simple enough! [Mon Nov 27 17:37:47 2017] is it similar to what I already had approached? [Mon Nov 27 17:37:48 2017] It's nearly as simple as proving the associativity of addition, the proof is really quite similar [Mon Nov 27 17:38:16 2017] So, first of all, as we were saying, keep `b` and `c` in the goal before doing the induction on `a`. [Mon Nov 27 17:38:34 2017] Then, you will not need to do a second induction, you can just `destruct b` instead of `induction b` [Mon Nov 27 17:38:34 2017] ah! so intro them at a later stage [Mon Nov 27 17:39:07 2017] Finally, don't hesitate to simplify the goal to see what it looks like, and if there is a `match x with ... end`, you can try to `destruct x`, it will probably help [Mon Nov 27 17:42:38 2017] lol I proved it. by randomly trying combinations of simpl/reflexivity/destruct [Mon Nov 27 17:42:58 2017] can you explain to me what `match x with ... end` is, and why destruct "cures" it? [Mon Nov 27 17:44:10 2017] `match x with ... end` is a term that allows to destruct `x`. So, in your case where `x` is an integer, you would write something like `match x with O => term1 | S n => term2 end.`. This term will reduce to `term1` if x is O, and to `term2` if x is some `S n`. [Mon Nov 27 17:45:05 2017] Now, on the side of tactics, `destruct x` will do exactly this: since `x` is a `nat`, it can only be either O or some `S n`. Therefore it will generate two subgoals, one where `x` has been replaced by O, and one where `x` has been replaced by `S n` [Mon Nov 27 17:45:27 2017] This will simplify the `match x with ... end` because now `x` is a constructor [Mon Nov 27 17:47:49 2017] ow, I remember now. I used destruct in proving A /\ B -> A earlier. so it basically splits a goal in two subgoals [Mon Nov 27 17:48:12 2017] It depends on the number of constructors of what you destruct [Mon Nov 27 17:48:34 2017] yeah. that's the more general version, you are right. I kept thinking about A /\ B [Mon Nov 27 17:48:37 2017] If you destrct `H : A /\ B` you will only have one subgoal, because the `and` inductive type has only 1 constructor [Mon Nov 27 17:48:59 2017] On the other hand, if you destruct `H : A \/ B`, you will end up with two subgoals [Mon Nov 27 17:49:54 2017] e.g. Inductive test: Set := | member: test. in this case, a constructor is `member`, correct? [Mon Nov 27 17:50:03 2017] correct [Mon Nov 27 17:59:50 2017] thanks Cypi! is there another tutorial for starters you'd recommend, besides Mike Nahas' one? [Mon Nov 27 18:01:32 2017] I used Software Foundations to learn Coq [Mon Nov 27 18:01:52 2017] I had a bit of background in functional programming (like OCaml) which certainly helped [Mon Nov 27 18:02:58 2017] ah, yeah. I've seen that one [Mon Nov 27 19:22:07 2017] Hum, I'm using something like "induction x; try solve [... induction y. a. big b ....]. The problem is that in the solve I'm not allowed to use ".", only ";" seems to be allowed. How could I do, because here I really want to do a ".". I though I may use nested solve, but I'm not sure it's the best way to proceed since I know how to solve each single branch. [Mon Nov 27 19:23:21 2017] or maybe ( ... + ...) ? [Mon Nov 27 19:29:38 2017] And also the induction fails with an error "Error: The reference x was not found in the current environment.". If I run "intro x" before, then the intro also fail with the error Ltac call to "intro (ident)" failed. [Mon Nov 27 19:29:41 2017] Error: No product even after head-reduction. [Mon Nov 27 19:30:43 2017] (while if I replace the ";" with "." it works with no error) [Mon Nov 27 19:31:27 2017] tobiasBora: tac0; [tac1 | tac2 | ... | tacN] applies taci to the i-th goal generated by tac0 [Mon Nov 27 19:37:56 2017] tobiasBora: the main reason to use solve is in automated proofs, so that it fails when its argument tactic is not enough — but then, no reason for a dot in solve’s argument. [Mon Nov 27 19:38:37 2017] tobiasBora: also, `induction x; solve [t1. t2. t3]` would stop between `t1`, `t2`, `t3` in *each case arising from `induction` [Mon Nov 27 19:38:37 2017] Ok thank you! I think I understood why it failed, I need to check it [Mon Nov 27 19:39:14 2017] if you want to look at things carefully, it always works to replace `t1; t2` with `t1. ` [Mon Nov 27 19:39:47 2017] pgiarrusso: yes, that's why I wanted to avoid to use two solved. But for the first one, I want to do that because I've lot's of goals that are solved in the same way in my 20 goals. [Mon Nov 27 19:40:14 2017] the failures you’re seeing are probably because the different goals produced by `induction` have different shapes [Mon Nov 27 19:40:17 2017] `try` can help [Mon Nov 27 19:40:45 2017] if you have that many goals, and you already want to try automating the proof, *maybe* you want to use the Ltac debugging facilities [Mon Nov 27 19:40:55 2017] but I read they are not easy to use [Mon Nov 27 19:41:21 2017] also, if you’re getting started, maybe it’s easier at the beginning to just use copy-paste instead of automation [Mon Nov 27 19:41:40 2017] once you have a non-automated proof that works, you can try automating it [Mon Nov 27 19:41:56 2017] pgiarrusso: yes, that's what I did first [Mon Nov 27 19:42:01 2017] (in fact, I’ve seen that recommended also for experienced users) [Mon Nov 27 19:42:22 2017] now my "non automated proof" works (at least for 2 subgoals ^^) and I want to factor it [Mon Nov 27 19:43:06 2017] ah OK, sorry [Mon Nov 27 19:43:18 2017] no problem, I like advices [Mon Nov 27 19:43:54 2017] but maybe I should try to factor is using Lemma, I'm not sure if it's usual to have such a big proof. [Mon Nov 27 19:44:06 2017] (and I already use some lemma) [Mon Nov 27 19:44:22 2017] well, lemmas are at least readable :-) [Mon Nov 27 19:44:29 2017] you can read the statement [Mon Nov 27 19:44:50 2017] proof scripts... aren’t really readable [Mon Nov 27 19:53:04 2017] yes, I've always tought that reading the code of someone else was quite difficult. But in coq it's not even possible ;) [Mon Nov 27 19:54:48 2017] Hum the a ; [b | c] syntax is really nice, it makes the code much more readable. [Mon Nov 27 19:55:16 2017] Do you know if it's possible to naviguate in this syntax "line by line" instead of evaluating the whole structure at once? [Mon Nov 27 19:58:05 2017] I would also like to know. [Mon Nov 27 20:00:15 2017] I’ve never found such a thing, except for https://coq.inria.fr/refman/ltac.html#sec501 [Mon Nov 27 20:00:27 2017] (and I’ve never used it) [Mon Nov 27 20:01:04 2017] so Chlipala advices to not try reading proof scripts, and declare lemmas for interesting steps [Mon Nov 27 20:01:46 2017] meanwhile, if you want to split tactics by goals, using “bullets” can be useful [Mon Nov 27 20:02:03 2017] bullets ? [Mon Nov 27 20:04:51 2017] there’s an example at Sec. 7.2.7 of https://coq.inria.fr/refman/proof-handling.html#sec331 [Mon Nov 27 20:05:06 2017] but basically, you can write sort of nested bulleted lists [Mon Nov 27 20:05:12 2017] to group your tactics [Mon Nov 27 20:05:25 2017] you write - to focus on the first goal [Mon Nov 27 20:05:37 2017] and you can write `-` again only when that goal is done [Mon Nov 27 20:05:42 2017] And Set Ltac Debug is nice, it's just too bad that it's not possible to stay at the "user level", instead of going deep in the ltacs. [Mon Nov 27 20:07:37 2017] BTW, you can nest bullets, with +, then *, then — and so on [Mon Nov 27 20:07:43 2017] and there’s support for automatic indentation [Mon Nov 27 20:08:41 2017] woahh great, and it's even supported by emacs :D [Mon Nov 27 20:10:49 2017] Can it replace the [ ... | ... ] ? ^^' [Mon Nov 27 20:24:51 2017] Is it possible to replace " (rewrite .... a ....; rewrite ..... b .....) + (rewrite .... c ....; rewrite ..... d.....)" by a function . I tried "let myrewrite x := rewrite .... x .... in ((myrewrite a; myrewrite b) + (myrewrite c; myrewrite d)." [Mon Nov 27 20:24:55 2017] but it fails... [Mon Nov 27 20:26:48 2017] (if it can help: Syntax error: 'type' 'of' expected after '(' (in [hypident]).) [Mon Nov 27 20:29:26 2017] Ltac my_rewrite x := rewrite .... x .... . [Mon Nov 27 20:32:21 2017] The Ltac syntax also give me an error : Syntax error: ']' expected after [tactic_then_gen] (in [tactic:tactic_expr]). [Mon Nov 27 20:32:49 2017] (I use it inside a [ ... ] structure, maybe I cannot ?) [Mon Nov 27 20:33:56 2017] (and I don't really want to define it before, because else the variables inside myrewrite won't exist) [Mon Nov 27 20:44:54 2017] (and by the way, the bullets are so nice !) [Mon Nov 27 21:13:26 2017] Is it possible to ask to coq to check if a property seems to be true, by trying to evaluate for random values, and some importants values, like 0, and 1 ? For now I do that by hand, it's not really long but a function would be really nice to have ;)$ [Mon Nov 27 22:01:18 2017] tobiasBora: There's QuickChick. [Mon Nov 27 22:02:03 2017] Thank you ! [Mon Nov 27 23:58:13 2017] Hum... What is the name of the tactic that do nothing? [Tue Nov 28 00:01:23 2017] idtac? [Tue Nov 28 05:24:05 2017] is there a tactic that checks online for proofs in an existing global database? [Tue Nov 28 05:44:58 2017] sud: i had found a database of contribution packages, but a problem is that they might or might not work with recent Coq versions; as a rule. [Tue Nov 28 05:45:19 2017] Sorry: *as a rule, they won’t keep working without maintenance. [Tue Nov 28 05:51:30 2017] pgiarrusso: wouldn't it be useful to have a central database where people upload all of their proofs, and then a tactic can go fetch them? [Tue Nov 28 05:54:10 2017] I’m not saying no, but there’s no point if those proofs break [Tue Nov 28 05:54:47 2017] more importantly, there are multiple such databases for various theorem provers [Tue Nov 28 05:55:00 2017] well, mostly there are repositories of contributions [Tue Nov 28 05:55:23 2017] there’s also NuPRL, an alternative to Coq which IIUC uses such a database [Tue Nov 28 05:56:04 2017] but it seems its distributed system aspects make it harder to install [Tue Nov 28 06:34:08 2017] I have p_imp_q : p -> q and p_imp_not_q : p -> ~ q (trying to prove neg_intro). what tactic can I use to prove that ~ p? [Tue Nov 28 06:35:16 2017] the way I would solve it manually is to assume p, arrive at a contradiction from ~q and q and thus not p [Tue Nov 28 06:41:29 2017] bor0: "intuition" should do it [Tue Nov 28 06:42:20 2017] bor0: if you want more details, you have to remember that ~ p is a notation for p -> False [Tue Nov 28 06:44:01 2017] so first you can do "intro H", which will move (H: p) to your hypotheses; then you know that p_imp_not_q : p -> q -> False, so you write "apply p_imp_not_q"; and it will ask you to prove "p" and "q"; to prove p, you just use "H"; and to prove q, you "apply p_imp_q" and use "H" again [Tue Nov 28 07:10:11 2017] if I have a hypothesis of the form: "a := let b : False := {...} in 5 : nat", can I prove False? [Tue Nov 28 07:13:27 2017] sud_ what about "exact" with the value for b? [Tue Nov 28 07:14:18 2017] `exact (some Gallina term)` [Tue Nov 28 07:14:31 2017] pgiarrusso: yes that would work, but assume I have no access to the body of b, but only to its type [Tue Nov 28 07:14:48 2017] Yeah, not sure how to get it out of `a` [Tue Nov 28 07:25:23 2017] Why would you not have access to the body of b? [Tue Nov 28 07:26:50 2017] In any case, what you have is the same as having `a := 5 : nat`, so not a chance to prove False purely by using `a` [Tue Nov 28 07:32:59 2017] Cypi: I was wondering whether things that are proved in the inner scope of a let could be used outside of the let binding, without having to reprove them; but it makes sense that it is not the case [Tue Nov 28 08:16:40 2017] what is the recommended type for using integers (positive or negative) [Tue Nov 28 08:33:43 2017] I'm using Z, is there a lemma that allows me to write if (lemma_lt a b) then X else Y, and have the fact that a < b propagate in the X branch, and a >= b propagate in the Y branch? [Tue Nov 28 08:39:14 2017] Is lemma_lt a boolean function? [Tue Nov 28 08:42:23 2017] lyxia: I didn't define that lemma, but I'm looking for one (that says that either a < b or a >= b) [Tue Nov 28 08:43:08 2017] lyxia: I found the lemma Z.lt_ge_cases, but I cannot do if then else on it in computations apparently (I obtain an error regarding Prop and Set when doing so) [Tue Nov 28 08:45:45 2017] Nat.lt_decidable [Tue Nov 28 08:45:56 2017] ah... [Tue Nov 28 08:46:43 2017] there should be a {a < b} + {a >= b} somewhere [Tue Nov 28 08:48:06 2017] SearchAbout (forall a b: Z, _ + _). returns nothing :( [Tue Nov 28 08:48:55 2017] Z.lt_decidable exists [Tue Nov 28 08:49:11 2017] the `_ + _` is wrapped in a definition, that's why the search fails [Tue Nov 28 08:49:38 2017] Ah wait, except that this is in Prop, not Type... [Tue Nov 28 08:49:58 2017] yes [Tue Nov 28 08:50:22 2017] Alright, `Search Z.lt "dec".` should give you everything you need [Tue Nov 28 08:50:53 2017] unrelated question: is there a tactic that transform every hypothesis of the form "H := term: type" to "H: type"? [Tue Nov 28 08:51:24 2017] only result for that search is Z.lt_decidable [Tue Nov 28 08:51:47 2017] Really? Have you imported ZArith for instance? [Tue Nov 28 08:51:54 2017] (I'm not sure where these lemmas are found) [Tue Nov 28 08:52:17 2017] sud_: `clearbody H` does this, so you could wrap it in a `repeat match goal ...` [Tue Nov 28 08:52:34 2017] Z_ge_lt_dec: forall x y : Z, {(x >= y)%Z} + {(x < y)%Z} [Tue Nov 28 08:52:35 2017] I only imported Require Import Coq.Numbers.BinNums. Require Import Coq.ZArith.BinInt. [Tue Nov 28 08:52:46 2017] after Require Import ZArith. [Tue Nov 28 08:53:18 2017] There is ZArith.Zarith_dec which seems to exist, if you want to limit your number of imports [Tue Nov 28 08:53:32 2017] Sorry, ZArith.ZArith_dec [Tue Nov 28 08:53:59 2017] awesome thanks [Tue Nov 28 08:54:47 2017] and one last thing, searching (forall a b : Z, _ + _) should still fail, but searching (forall a b : Z, {_} + {_}) should work [Tue Nov 28 08:54:51 2017] (the curly braces are part of the notation) [Tue Nov 28 08:54:55 2017] ah I see [Tue Nov 28 08:59:12 2017] is there a tactic that will automatically destruct such expressions (omega didn't help here) when it sees them, or do I have to define it myself? [Tue Nov 28 09:00:17 2017] I think `intuition` will do that, but it will also do a lot more [Tue Nov 28 09:02:00 2017] Cypi: intuition does nothing on that goal: "(if x < x then false else if x < x then false else true) = true" [Tue Nov 28 09:02:08 2017] (where Notation "a < b" := (Z_lt_ge_dec a b).) [Tue Nov 28 09:03:20 2017] Ah right, I misunderstood what you meant (it would do something if you had `{x >= y} + {x < y}` in your hypotheses) [Tue Nov 28 09:03:35 2017] The no, no built-in tactic for this afaik [Tue Nov 28 09:03:39 2017] Then* [Tue Nov 28 09:07:44 2017] alright thanks [Tue Nov 28 09:09:01 2017] I'm trying to define a function (that proves a theorem) manually, as a fixpoint. So I write Fixpoint (n: nat) (H: P1): P2. (where P1 and P2: Prop) and then I want to write the proof manually. [Tue Nov 28 09:09:17 2017] But I get: "Cannot do a fixpoint on a non inductive type." is there a workaround? [Tue Nov 28 09:11:10 2017] Fixpoint (n : nat) (H : P1) {struct n} : P2. [Tue Nov 28 09:11:21 2017] Poor Coq doesn't know what the recursive argument should be [Tue Nov 28 09:12:51 2017] great! thanks [Tue Nov 28 09:13:20 2017] So I proved all the subgoals using some tactics and then got: "All the remaining goals are on the shelf: x <> y, x <> y" (P1 was x <> y) [Tue Nov 28 09:14:05 2017] You can do `Unshelve.` to get under focus the goals that you actually did not prove [Tue Nov 28 09:14:19 2017] these may come from some application of a lemma or different other cases, it depends on your proo [Tue Nov 28 09:14:22 2017] proof* [Tue Nov 28 09:15:07 2017] Cypi: yes indeed, I called the Fixpoint F recursively with F n' _ [Tue Nov 28 09:15:23 2017] (and wrapped than around "refine") [Tue Nov 28 09:15:59 2017] It looks like `refine` decided that this specific _ should be put on the shelf (I'm not sure what the heuristics is) [Tue Nov 28 09:16:09 2017] if you want to avoid that, you can do `unshelve refine (F n' _)` [Tue Nov 28 09:16:19 2017] it will immediately unshelve anything that was put on the shelf by refine [Tue Nov 28 09:16:30 2017] cool that worked! [Tue Nov 28 10:45:53 2017] Hi. Is it possible to prove for MSets that remove x empty = empty ? [Tue Nov 28 10:47:46 2017] Ok, I see that no. [Tue Nov 28 10:47:53 2017] This equality is too strong. [Tue Nov 28 12:45:10 2017] Hello. Are there any Coq tactics in mathcomp/ssreflect or corn or standard coq library that simplify dealing with systems of (in)equalities (over rationals or complex numbers)? [Tue Nov 28 13:10:18 2017] Vivi: "field" should work for equalities [Tue Nov 28 13:10:41 2017] oh I missed the “systems” part, sry [Tue Nov 28 13:13:14 2017] So field, ring, fourier... maybe auto with real is all I am stuck with? [Tue Nov 28 13:14:16 2017] at least that’s all I know about :) [Tue Nov 28 13:16:45 2017] Thank you! :) I've been looking through mathcomp and corn and haven't really found any advanced automation in this regard. [Tue Nov 28 13:17:15 2017] Sometimes even things like operating on both sides of an equation with an injective function is beyond automation. [Tue Nov 28 13:19:20 2017] automation always breaks down when you want it most :) [Tue Nov 28 13:21:41 2017] I'll conjure something myself then... yey Ltac... [Tue Nov 28 13:56:40 2017] Vivi: sadly, we know Peano arithmetic (unlike Presburger arithmetic) is undecidable — in fact, already addition + multiplication are :-| [Tue Nov 28 13:59:05 2017] Yes, however I am not seeking a decision procedure, heuristics would do. [Tue Nov 28 17:38:31 2017] Is there a platform where people submit Coq theorems and other people prove them, perhaps explaining their reasoning? [Tue Nov 28 17:51:00 2017] StackOverflow :)? [Tue Nov 28 20:54:30 2017] Is there a nice way to model equality of lists modulo transposition of elements in some finite set? [Tue Nov 28 22:47:51 2017] In ltac, I want to write a tactic that matches '_ \/ _' in the hypothesis given as an argument and then uses "generalize dependent" on both sides of the operator. [Tue Nov 28 22:48:41 2017] I can't figure out how to get some identifier for the underscores in the pattern so I can pass them as arguments to 'generalize dependent'. Is this something that you're supposed to use metavariables for? [Tue Nov 28 22:56:07 2017] yup [Tue Nov 28 22:56:37 2017] nate_: patterns in ltac are extremely powerful - in particular, you can match against any term [Tue Nov 28 22:57:33 2017] therefore, a variable occurring in an ltac pattern is treated not as a new binding but as a pattern which will match that variable [Tue Nov 28 22:57:59 2017] if you want to capture a subterm in a match, like how variables in normal patterns work, you indeed use a ?metavariable [Tue Nov 28 22:58:39 2017] (but this is just notation in the pattern - the bit after the question mark is the variable's name) [Tue Nov 28 22:59:08 2017] (so if you want to refer to the variable that was bound, you just say metavariable - no question mark) [Tue Nov 28 23:03:45 2017] OK I see [Tue Nov 28 23:03:52 2017] I was just getting syntax errors [Tue Nov 28 23:03:54 2017] thanks [Wed Nov 29 04:25:47 2017] Hello :). I'm trying to learn Coq with simple experiments. How can I go about proving that x^2 + 2x + 1 is equal to (x+1)^2? [Wed Nov 29 04:37:20 2017] Blerp: start by simplifying things using "cbn" and then use rewriting to eliminate things like + 0 or *1 and rewrite using associativity and distributivity [Wed Nov 29 04:38:23 2017] at least that’s the “manual” way which you should probably follow if you’re trying to learn Coq. there are mostly automatic solutions that require way less work :) [Wed Nov 29 04:41:52 2017] I agree, the manual way would be best right now haha [Wed Nov 29 04:42:16 2017] cocreature: Do you know any beginner-friendly sources that don't assume too much knowledge on the student's part? [Wed Nov 29 04:42:41 2017] Blerp: I’ve learned Coq from "software foundations" and found it quite approachable [Wed Nov 29 04:43:20 2017] I'll look into that, then. Thank you :) [Wed Nov 29 06:39:59 2017] Hello! I am constructing an Ltac script which by given proposition constructs some object term, it does not change goals or hypothesis. How do I debug such Ltac script? If I run it inside proof env, Coq gives "Tactic expected" or "Expression does not evaluate to a tactic". [Wed Nov 29 06:44:14 2017] Info 1 ... does not help either. [Wed Nov 29 11:05:19 2017] There's always this Coq Discord server https://discord.gg/JeJ4kxr [Wed Nov 29 11:55:30 2017] Hello, [Wed Nov 29 11:56:39 2017] When I have in the hypothesis: a, b, (a /\ b) -> c, how could I deduce c ? (I tried destruct and split) [Wed Nov 29 12:05:01 2017] (and because c is not in the goal, I cannot apply the Hyphothesis 3 [Wed Nov 29 12:15:58 2017] I think you have to supply (a /\ b) somehow. [Wed Nov 29 12:17:41 2017] tobiasBora: "specialize (H (conj a b))" would be one option [Wed Nov 29 12:18:16 2017] or "assert (Harg : a /\ b) by auto; apply H in Harg" [Wed Nov 29 12:18:25 2017] (assuming the last hypothesis is called H) [Wed Nov 29 12:22:58 2017] Hum interesting... And if a and b are not straight forward to show, it's also with assert? [Wed Nov 29 12:27:15 2017] yeah "assert" is pretty useful for proving some intermediate things [Wed Nov 29 12:27:45 2017] tobiasBora: in fact you could even do "assert c by auto" (or manually prove it using "apply" after you’ve used the assert) [Wed Nov 29 12:28:19 2017] Great, thank you! And the "assert ... by ...." is nice to have, thank you! [Wed Nov 29 12:28:37 2017] np [Wed Nov 29 12:31:45 2017] tobiasBora: you might also want to look at https://coq.inria.fr/refman/proof-handling.html#hevea_default505 which is great for structuring subproofs for assertions [Wed Nov 29 12:38:42 2017] cocreature: yes, someone showed me the bullets yesterday, it's just amazing [Wed Nov 29 12:39:46 2017] and the "by" is really practicle! [Wed Nov 29 17:10:15 2017] if I have a bunch of .v files, and many unproven goals, is there an interface that allows me to see all unproven goals at once, and chose from the goals? [Wed Nov 29 17:10:32 2017] (chose which one to prove, and enter an interactive mode) [Wed Nov 29 19:20:52 2017] I have a simple question: I am doing a proof and have come to a subgoal, which is very simple, but I can't really find the right tactic. It's this: [Wed Nov 29 19:21:03 2017] n + n + m + p = n + m + n + p [Wed Nov 29 19:23:18 2017] There's the omega tactic. If you want to prove it by hand, the low level properties to manipulate this kind of expressions are commutativity and associativity. [Wed Nov 29 20:08:29 2017] Is it possible to use Ltac to create a tactic that takes in a hypothesis of the form (A \/ B) where A and B are props and produces 2 subgoals for proving that it the goal holds when A is false and B is true and B is false and A is true [Wed Nov 29 20:08:58 2017] is there something that already does this? is that even possible? [Wed Nov 29 20:09:53 2017] If I understand what you mean, you want to have `forall A B P, (A -> ~B -> P) -> (~A -> B -> P) -> (A \/ B -> P)`, is that right? [Wed Nov 29 20:10:29 2017] Well [Wed Nov 29 20:10:34 2017] Let me see [Wed Nov 29 20:10:55 2017] Just in case, what I wrote is not provable. Take `A := True` and `B := True` for instance [Wed Nov 29 20:11:14 2017] lyxia: Okay, so no middle ground. I am proving by comm. and assoc. But it is so tedious [Wed Nov 29 20:12:24 2017] Cypi: I'm not completely sure [Wed Nov 29 20:12:58 2017] I don't think so because (A -> ~B) would mean that they both can't be true [Wed Nov 29 20:14:15 2017] Not exactly, I wrote (A -> ~B -> P), not (A -> ~B). I can equivalently rewrite this as `forall A B P, (A /\ ~B -> P) -> (~A /\ B -> P) -> (A \/ B -> P)` [Wed Nov 29 20:14:45 2017] But you are right that what you want initially doesn't seem to be doable, because (A \/ B) doesn't say that they can't both be true. [Wed Nov 29 20:15:50 2017] Is there a way to generate all 4 possibilities as subgoals? [Wed Nov 29 20:17:05 2017] Only if you have a decidability property on A and B, that is, you know `A \/ ~A` [Wed Nov 29 20:17:17 2017] (and `B \/ ~B`) [Wed Nov 29 20:18:18 2017] Couldn't you prove that forall (A : prop), A \/ ~A -> True? [Wed Nov 29 20:18:38 2017] You could prove what you wrote, but it doesn't say much, since anything implies True [Wed Nov 29 20:18:58 2017] On the other hand, you cannot prove `forall (A : Prop), A \/ ~A`, which is excluded middle [Wed Nov 29 20:19:25 2017] it's a classical property that a lot of people use, but you cannot prove it in an intuitionnistic setting such as Coq, you need to assert it as an axiom. [Wed Nov 29 20:23:30 2017] So if I'm willing to use an extra axiom for that, how can I exploit this to prove my goal through the possible values of A and B? [Wed Nov 29 20:25:32 2017] Assuming you have `classic : forall (P : Prop), P \/ ~P`, you could for instance do `destruct (classic A); destruct (classic B)` to have 4 subgoals [Wed Nov 29 20:25:53 2017] one of them will be easy to solve because you can't have both ~A and ~B (since you know A \/ B) [Wed Nov 29 20:26:17 2017] Two of them will be what you wanted initially, and finally you will also get a goal where both A and B are true [Thu Nov 30 03:25:35 2017] sudi: grep for Admitted? [Thu Nov 30 03:26:40 2017] sudi: to find unproven goals. Unless you’re using tactics such as tlc’s skip, which postulates False to let you finish with Qed. [Thu Nov 30 03:29:45 2017] pgiarrusso: basically I have a *.v file with many function definitions, and many calls to refine(...) with holes "_" inside the refine body; [Thu Nov 30 03:31:50 2017] pgiarrusso: I want an interface that lets the user run coq on the file, have coq generate all subgoals, and then let the user choose the subgoals that remain, to prove them manually [Thu Nov 30 03:32:55 2017] each unfinished proof will end with "Admitted" basically [Thu Nov 30 03:36:25 2017] Oh. You want to pick among the open subgoals of multiple proofs. Ok, good question. [Thu Nov 30 03:36:25 2017] I’m thinking of Program’s Obligations commands [Thu Nov 30 03:37:10 2017] But you cannot use a function until its obligations are either proven or admitted... [Thu Nov 30 03:42:07 2017] pgiarrusso: or at least do the basic command-line tools (coqc/coptop) allow to have all of these functions defined in the same file, let them be Admitted and refer to each other, and then let the user process the open subgoals in order? [Thu Nov 30 03:44:03 2017] no clue. Maybe that works if you make the functions mutually recursive. [Thu Nov 30 03:44:46 2017] I mean, I only use Proof General, but it seems a function is only in scope when it’s done [Thu Nov 30 03:46:17 2017] But also, it’s not clear why you want this so strongly. What’s bad about “go back to an earlier point and start proving”? [Thu Nov 30 03:46:28 2017] Proof General will automatically retract later proofs, I guess the same for CoqIDE if it works for you [Thu Nov 30 03:47:51 2017] pgiarrusso: this would be part of a project for automatically proving assertions written in another programming language; the program with assertions would be translated to Coq (with refine), and have Coq generate the subgoals [Thu Nov 30 03:49:22 2017] Don’t take my word for it, but sounds like you’d need to store this list externally [Thu Nov 30 09:12:01 2017] If I have a inductive proposition, and someone ask me to verify if a given proposition is provable, do I write 'Goal '? [Thu Nov 30 09:13:52 2017] That sounds fine. [Thu Nov 30 09:14:57 2017] Okay :) [Thu Nov 30 10:28:51 2017] I'd like to know, how could I specialize a forall inside an expression? Like in "a -> (forall x, b(x) -> c(x))" [Thu Nov 30 10:40:50 2017] tobiasBora: it's a function that takes x as its second argument, so you can apply it [Thu Nov 30 10:46:25 2017] lyxia: if the conclusion is in the goal yes, but what if I just want to specialize the argument, without using it now in the goal ? Do I need to use assert ? [Thu Nov 30 10:47:52 2017] If you have `H : a -> (forall x, b(x) -> c(x))`, you can do something like `pose proof (fun u => H u t)` if you want to specialize x with t [Thu Nov 30 10:49:43 2017] Cypi: great, thanks! [Thu Nov 30 14:16:07 2017] how can I prove this without using simpl? I believe I need to re-use the definition of "add", but how can I "rewrite" it? Theorem my_thm : forall n m : nat, S n + m = S(n + m). [Thu Nov 30 14:16:29 2017] also a follow-up question to that, can we prove stuff without even using simpl? just using rewrite based on axioms/definitions? [Thu Nov 30 14:16:39 2017] s/even/ever/ [Thu Nov 30 14:31:11 2017] ah, I just remembered unfold and it does exactly what I need (unfold add) [Thu Nov 30 15:40:28 2017] Okay, I have been trying to solve this problem for HOURS now, and I'm about to give up. I am trying to solve a problem from: https://softwarefoundations.cis.upenn.edu/lf-current/IndProp.html#lab216 (ctrl-f: Exercise: 4 stars (re_not_empty) [Thu Nov 30 15:40:31 2017] ) [Thu Nov 30 15:43:35 2017] I don't know if I defined 're_not_empty' correct. Especially Star: '| Star re => re_not_empty re', I think I can make it work by just returning true, but I think it's incorrect [Thu Nov 30 15:45:33 2017] If you return `re_not_empty re`, then it is incorrect [Thu Nov 30 15:46:14 2017] I think you've thought of it, but `Star re` will always match the empty string, therefore there is a string that it matches [Thu Nov 30 15:46:30 2017] So returning true should be the right thing to do. [Thu Nov 30 15:46:33 2017] So => true [Thu Nov 30 15:46:35 2017] Ah [Thu Nov 30 15:46:37 2017] :/ [Thu Nov 30 15:47:02 2017] So much pain [Thu Nov 30 15:47:34 2017] Honestly, I don't think I am learning much from these exercises [Thu Nov 30 15:48:01 2017] The harder ones is more of a guess game [Thu Nov 30 15:48:35 2017] guessing* [Thu Nov 30 15:52:25 2017] Hi [Thu Nov 30 15:52:59 2017] doing exercise of Software Foundations, and getting this error "Error: Cannot guess decreasing argument of fix" with https://pastebin.com/JrbkPBsq [Thu Nov 30 15:53:32 2017] equivalent function in haskell seems to work: let alternate [] y = y; alternate (x:xs) y = x : (alternate y xs) [Thu Nov 30 15:54:19 2017] I used double pattern matching for that problem [Thu Nov 30 15:54:22 2017] Haskell doesn't check for termination though, does it? [Thu Nov 30 15:54:28 2017] match l1, l2 [Thu Nov 30 15:54:30 2017] yes, it seems like it. [Thu Nov 30 15:54:34 2017] oh, okay [Thu Nov 30 15:54:46 2017] thanks Steverman [Thu Nov 30 16:08:39 2017] hrllo [Thu Nov 30 16:09:18 2017] are there any good strategies for provings things like f (x ++ y) = f x ++ f y [Thu Nov 30 16:09:34 2017] on lists for example [Thu Nov 30 16:16:04 2017] beaky: is 'f' a map over lists? [Thu Nov 30 16:16:08 2017] yes [Thu Nov 30 16:17:14 2017] beaky: you might want to look at map_app, then! [Thu Nov 30 16:17:17 2017] wow thanks [Thu Nov 30 16:18:41 2017] beaky: search can be very useful as it can take multiple functions: `Search List.map app.` [Thu Nov 30 16:18:51 2017] wow i didnt know search existed [Thu Nov 30 16:19:13 2017] beaky: are you using proof general? [Thu Nov 30 16:19:20 2017] yes [Thu Nov 30 16:19:48 2017] "C-a C-a" will let you do a search within it very easily :). [Thu Nov 30 16:20:10 2017] https://quanttype.net/posts/2016-04-19-finding-that-lemma.html [Thu Nov 30 16:21:28 2017] I have IHn : evenb (S n) = negb (evenb n) and as a goal evenb (S (S n)) = negb (evenb (S n)). how can I "rewrite" evenb (S (S n)) from its definition? should be evenb n by def [Thu Nov 30 16:22:07 2017] bor0: simpl? [Thu Nov 30 16:22:37 2017] I get "evenb n = negb match n with". should I destruct on n after that? [Thu Nov 30 16:25:23 2017] bor0: I would probably rewrite with IHn first. [Thu Nov 30 16:25:45 2017] Before calling simpl, that is. [Thu Nov 30 16:26:28 2017] And then you probably have a theorem about negb that can help you :). [Thu Nov 30 16:27:07 2017] negb_involutive [Thu Nov 30 16:27:09 2017] thanks! I made progress, will try to tackle it more :) [Thu Nov 30 16:28:32 2017] woot Steverman. thanks for that, Qed [Thu Nov 30 16:28:44 2017] :> [Thu Nov 30 16:28:45 2017] what's the easiest way to search Coq for theorems? [Thu Nov 30 16:29:00 2017] https://coq.inria.fr/library doesn't seem to be very user friendly :( [Thu Nov 30 16:29:00 2017] Search negb. [Thu Nov 30 16:29:16 2017] Hah, yeah I always end there when I google [Thu Nov 30 16:29:17 2017] https://quanttype.net/posts/2016-04-19-finding-that-lemma.html [Thu Nov 30 16:29:20 2017] there's `Search`! ahh. this will save me hours. thanks Chobbes! [Thu Nov 30 16:29:21 2017] I immedially close it [Thu Nov 30 16:29:30 2017] bor0: also that link. [Thu Nov 30 16:29:39 2017] Yeah, future coq exercises may use from previous chapters [Thu Nov 30 16:30:13 2017] oh wow, there's a whole blogpost on how painful searching can be. I thought it was only me :D thanks for all the help! [Thu Nov 30 16:31:01 2017] There is an effort to make the Coq reference manual a little more pleasant, hopefully by next release :). [Thu Nov 30 16:31:35 2017] bor0: searching is actually pretty nice in Coq :). [Thu Nov 30 16:31:45 2017] indeed ! [Thu Nov 30 16:31:55 2017] ^exclamation point localized for france [Thu Nov 30 16:32:28 2017] how does Search differ from SearchRewrite? I thought we can rewrite using any theorem? [Thu Nov 30 16:32:34 2017] Googling for Coq stuff... That's usually not pleasant. But searching for theorems within Coq is A+. [Thu Nov 30 16:32:50 2017] bor0: SearchRewrite is for looking for theorems that will do a specific rewrite. [Thu Nov 30 16:33:11 2017] ah, got it. [Thu Nov 30 16:33:32 2017] oic u only give one side of the equation [Thu Nov 30 16:33:47 2017] well cant u also just type [Search (foo = _)] instead of [SearchRewrite foo] [Thu Nov 30 16:33:58 2017] i suppose the latter does both lhs and rhs and no need for parens [Thu Nov 30 16:34:10 2017] benzrf: I think so. [Thu Nov 30 16:35:07 2017] so for the given goal evenb (S (S n)) = negb (negb (evenb n)) I use negb_involutive to rewrite. but when I try to SearchRewrite (evenb (S (S _))). or SearchRewrite (negb (negb (evenb _))). nothing is returned. am I mistakenly using it? [Thu Nov 30 16:35:29 2017] bor0: i believe the issue is that it doesnt do full unification [Thu Nov 30 16:35:39 2017] ow, I understand [Thu Nov 30 16:35:57 2017] but if you apply some rules of thumb it shuoldnt be too much of an issue [Thu Nov 30 16:36:21 2017] for example, in this case it would seem reasonable to have an involution theorem for double negb, but probably not a theorem specifically involving both negb and evenb [Thu Nov 30 16:36:45 2017] `Search (negb (negb _) = _).` ok I see the power of Search in Coq :) [Thu Nov 30 16:36:50 2017] ^^ [Thu Nov 30 16:37:15 2017] bor0: you can also use metavariables and stuff in search :). [Thu Nov 30 16:37:46 2017] do note you can search for fragments of names by using quotes, for notations using quotes, and that you can search for multiple things at once by separating with spaces [Thu Nov 30 16:38:08 2017] e.g.: [Search (_ + _) "comm"] [Thu Nov 30 16:38:54 2017] or even just, [Search "+" "comm"] [Thu Nov 30 16:39:00 2017] using apply with parenthesis is still black magic to me [Thu Nov 30 16:39:16 2017] Steverman: oh? [Thu Nov 30 16:39:21 2017] well, it is just like using apply normally, except that you are constructing a term that's not just a variable [Thu Nov 30 16:39:25 2017] apply (thm a)? [Thu Nov 30 16:39:29 2017] yeah [Thu Nov 30 16:39:35 2017] I don't know when to use it [Thu Nov 30 16:39:42 2017] what does `apply` do? I did write a bunch of proofs in Coq but never had the need (or knowledge) to use it? [Thu Nov 30 16:39:56 2017] defining H as f x and then apply H is the same as apply (f x) [Thu Nov 30 16:39:56 2017] Steverman: well you can think of it as partially applying the theorem. [Thu Nov 30 16:40:10 2017] Yeah. [Thu Nov 30 16:40:12 2017] bor0: it's a very general tactic for refining the goal into an application [Thu Nov 30 16:40:36 2017] what's an application? lambda application? [Thu Nov 30 16:40:39 2017] function application [Thu Nov 30 16:41:08 2017] Lemma re_not_empty_correct is too hard :/ [Thu Nov 30 16:41:08 2017] i.e. if you want to prove the current goal with a term of the form [f args args args], and you know what f should be, you can use [apply f] and get the args as subgoals [Thu Nov 30 16:41:12 2017] I (think I) know what function application is, but can you show a simple theorem where I can use apply? just so I get feeling of it [Thu Nov 30 16:41:43 2017] you can use apply anytime there's an implication or forall (same thing, actually) whose conclusion unifies with your current goal [Thu Nov 30 16:41:56 2017] bor0: if your goal is "X" and you have a theeorem "H : X" you can apply H to solve the goal. [Thu Nov 30 16:42:03 2017] well, that's a special case :P [Thu Nov 30 16:42:08 2017] isn't that just exact H? [Thu Nov 30 16:42:13 2017] If your theorem is H : A -> X then applying will leave A as the goal. [Thu Nov 30 16:42:14 2017] yes, apply generalizes exact [Thu Nov 30 16:42:42 2017] in some sense it's like exact is apply for a 0-arg function :-) [Thu Nov 30 16:42:43 2017] There is no way to find out if you're actually stuck a proof right? [Thu Nov 30 16:42:47 2017] (Because you need to have a proof of A in order to prove X with H :) ) [Thu Nov 30 16:42:48 2017] stuck with a* [Thu Nov 30 16:42:56 2017] Steverman: not as a general problem, but there are surely some heuristics [Thu Nov 30 16:43:07 2017] like, if the goal is obviously false, that's probably a bad sign :) [Thu Nov 30 16:43:10 2017] "exact is apply for a 0-arg function" that's really interesting! [Thu Nov 30 16:43:12 2017] Steverman: you can usually figure it out in SF if you take a step back. [Thu Nov 30 16:43:13 2017] (unless you have contradictory assumptions) [Thu Nov 30 16:43:24 2017] bor0: don't take that too literally, all functions have 1 arg ;) [Thu Nov 30 16:43:38 2017] Steverman: there's also tools like quickchick which can point out when you're trying to prove something that's obviously false. [Thu Nov 30 16:43:38 2017] ah, (un-)currying, right? :D [Thu Nov 30 16:43:42 2017] yeah [Thu Nov 30 16:43:49 2017] Chobbes: I have been up for 22 hours, I don't know :D [Thu Nov 30 16:43:54 2017] anyway, for an example of apply - [Thu Nov 30 16:44:03 2017] yes please! [Thu Nov 30 16:44:11 2017] Steverman: step 1 in knowing if you're stuck -- get some sleep :P. [Thu Nov 30 16:44:37 2017] Well... you seee... I was supposed to finish this chapter yesterday [Thu Nov 30 16:44:52 2017] consider this theorem: [Nat.lt_le_incl: forall n m : nat, n < m -> n <= m] [Thu Nov 30 16:44:52 2017] Steverman: it often helps to take a step back and look at it with a pencil and paper proof. [Thu Nov 30 16:45:17 2017] if your current goal is something like [p <= q], you can do [apply Nat.lt_le_incl] [Thu Nov 30 16:45:23 2017] Hmm [Thu Nov 30 16:45:49 2017] this generate an incomplete proof of [p <= q] of the form [Nat.lt_le_incl p q _] [Thu Nov 30 16:45:59 2017] then the missing proof of [p < q] will be a new obligation [Thu Nov 30 16:46:01 2017] Steverman: dead serious -- you'll be able to follow that proof more or less to convert it into Coq. It's fairly easy to get lost in tactics. [Thu Nov 30 16:46:15 2017] (the p and q appear there because apply infers that it needs to do that) [Thu Nov 30 16:46:30 2017] Regular Expressions subchapter is actually just all tactics guessing for me [Thu Nov 30 16:46:33 2017] I don't like that [Thu Nov 30 16:46:43 2017] Steverman: don't do that then :). [Thu Nov 30 16:47:19 2017] How would you do it with pen/paper? [Thu Nov 30 16:47:21 2017] Figure out how you would do the proofs manually, and use that to guide you. [Thu Nov 30 16:47:52 2017] Steverman: ah -- maybe this isn't helpful advice if you don't have a math background. [Thu Nov 30 16:47:52 2017] how can I search to see what I need to import to get Nat.lt_le_incl? [Thu Nov 30 16:48:01 2017] I did informal proofs before, but I don't think that's what you're fishing for [Thu Nov 30 16:48:13 2017] Chobbes: I am actually just a bad computer scientist [Thu Nov 30 16:48:16 2017] :D [Thu Nov 30 16:48:22 2017] Steverman: that's what I'm fishing for :) [Thu Nov 30 16:48:23 2017] bor0: im actually not personally all that sure >w> [Thu Nov 30 16:48:30 2017] :D [Thu Nov 30 16:48:33 2017] but i can tell you that [Require Import PeanoNat] will do it - that might not be the right thing though [Thu Nov 30 16:48:56 2017] ah, [Require Import Arith] is probably the intended top level [Thu Nov 30 16:49:11 2017] Steverman: if you can do an informal proof of the problem you'll be ahead of the game. [Thu Nov 30 16:49:30 2017] I suppose [Thu Nov 30 16:49:54 2017] I can't see why the application of le_incl : forall n m : nat, n < m -> n <= m on top of n <= m would generate n < m as a goal :( [Thu Nov 30 16:49:56 2017] in general, apply is used for modus ponens and for instantiating foralls (which are the same thing) [Thu Nov 30 16:50:04 2017] bor0: because your argument is [Thu Nov 30 16:50:32 2017] "ok, i'll prove p <= q. now by le_incl, it's enough to prove p < q. then ..." [Thu Nov 30 16:50:49 2017] remember, you're doing backward reasoning in the goal [Thu Nov 30 16:50:58 2017] if you go from goal A to goal B, that means B -> A [Thu Nov 30 16:51:21 2017] you start with the final result, then work backward to what will prove the final result, what will prove /that/, etc [Thu Nov 30 16:52:03 2017] ahh. I see. what you asked me to prove (Theorem asdf : forall n m : nat, n < m -> n <= m.) is actually exact Nat.lt_le_incl. but `apply` could turn out to be useful in case I have something more in the theorem e.g. Theorem asdf : forall n m : nat, n = 3 -> n < m -> n <= m. ? or I got it completely wrong [Thu Nov 30 16:52:28 2017] nooo, i mean [Thu Nov 30 16:53:13 2017] in any place where your current goal is of the form [n <= m] - no matter what your hypotheses are or how you got there - you can use [apply lt_le_incl] to move to [n < m] [Thu Nov 30 16:53:52 2017] saying [apply lt_le_incl] means "alright, the conclusion of lt_le_incl matches what i'm currently trying to show, so let me appeal to that and prove its premises instead" [Thu Nov 30 16:57:08 2017] ahhh. ok. it's [apply lt_le_incl] vs [exact (Nat.lt_le_incl n m)] in this case. I *think* I see what apply does [Thu Nov 30 16:57:42 2017] well, the latter wont work [Thu Nov 30 16:57:52 2017] sorry, after intros that is [Thu Nov 30 16:57:57 2017] (for the latter) [Thu Nov 30 16:57:59 2017] no i mean [Thu Nov 30 16:58:01 2017] the type of the latter is [n < m -> n <= m] [Thu Nov 30 16:58:12 2017] so you can only use exact if your goal is of that form [Thu Nov 30 16:58:19 2017] if your goal is just [n <= m], you need to use apply [Thu Nov 30 16:58:40 2017] oh but I didn't intro n < m yet, so my goal is still n < m -> n <= m [Thu Nov 30 16:58:48 2017] aaaaa [Thu Nov 30 16:58:57 2017] ok yeah, in that particular case you can just use exact :P [Thu Nov 30 16:59:29 2017] ok it doesn't work now when I intro n_lt_m [Thu Nov 30 16:59:31 2017] :D [Thu Nov 30 16:59:39 2017] but if your theorem is like [forall l l', is_proper_prefix l l' -> length l <= length l'] [Thu Nov 30 17:00:21 2017] (ok, well, you wouldnt state the theorem that way to begin with, and if you were trying to prove this there'd probably be simpler ways than moving to the stronger less-than statement) [Thu Nov 30 17:00:25 2017] (but hopefully you see what i mean) [Thu Nov 30 17:00:54 2017] I also have problems knowing when to intro and when not to [Thu Nov 30 17:00:59 2017] knowing when* [Thu Nov 30 17:01:12 2017] Sometimes you don't have to intro everything [Thu Nov 30 17:01:25 2017] so if I have thm1: A -> B and my goal is B, I use apply thm1 to just prove A? [Thu Nov 30 17:01:30 2017] yes, precisely :) [Thu Nov 30 17:01:51 2017] except that it also handles instantiating foralls, since that's the same thing in coq's theory [Thu Nov 30 17:02:00 2017] (i.e. both are function application) [Thu Nov 30 17:02:10 2017] I always use intro proof_A; exact B. I guess this is just a neat shortcut, or is there more to its generalization (of exact)? [Thu Nov 30 17:02:28 2017] i picked lt_le_incl because using it will both move from B to A *and* instantiate n and m [Thu Nov 30 17:02:32 2017] Steverman, I intro everything :D guess that's the beginner's way [Thu Nov 30 17:02:38 2017] It is [Thu Nov 30 17:02:39 2017] you usually intro everything [Thu Nov 30 17:02:42 2017] afaict [Thu Nov 30 17:02:50 2017] unless you need to have a forall for an induction hypothesis [Thu Nov 30 17:03:10 2017] bor0: i don't think this intro-exact does the same thing at all [Thu Nov 30 17:03:21 2017] if your goal is B, and B is not a function type, you cannot use intro [Thu Nov 30 17:03:42 2017] you're thinking of proving A -> B using B [Thu Nov 30 17:03:46 2017] this is proving B using A -> B [Thu Nov 30 17:03:54 2017] (and therefore generating an obligation to prove A) [Thu Nov 30 17:04:06 2017] I need to dig more into `apply`. while you are here, can I bug you about one more thing? so far I've been proving theorems involving forall, but I'm having troubles with forall,exists one, e.g. Theorem even_or_odd : forall n k : nat, exists k : nat, n = 2 * k \/ n = 2 * k + 1. [Thu Nov 30 17:04:13 2017] that said, i think apply actually does work in that case - [Thu Nov 30 17:04:20 2017] iirc it will automatically intros things for you if it needs to [Thu Nov 30 17:04:21 2017] Wait till you read about forward reasoning [Thu Nov 30 17:04:23 2017] it's pretty smart [Thu Nov 30 17:05:31 2017] I intro n and I don't know how I can "instantiate" k [Thu Nov 30 17:05:43 2017] or even use it in my premises [Thu Nov 30 17:05:56 2017] you use [exists ] [Thu Nov 30 17:06:37 2017] what's ? I have goal `exists k : nat, n = 2 * k \/ n = 2 * k + 1` and if I try [exists k.] I get "The reference k was not found in the current environment." [Thu Nov 30 17:07:11 2017] my theorem is actually forall n : nat, exists k : nat, n = 2 * k \/ n = 2 * k + 1, sorry [Thu Nov 30 17:07:17 2017] (no k in forall) [Thu Nov 30 17:10:04 2017] oh, is constant :D seems to be working [Thu Nov 30 17:11:47 2017] (at least for the base case :D) [Thu Nov 30 17:16:30 2017] bor0: try proving this [forall P Q R : Prop, (P -> Q) -> P /\ R -> Q.] [Thu Nov 30 17:16:44 2017] bor0: also, of course [exists k] doesnt work [Thu Nov 30 17:16:58 2017] if i say to you "give me some number k such that k is greater than 10", and you say "ok, the number is k" [Thu Nov 30 17:17:01 2017] that makes no sense :P [Thu Nov 30 17:33:54 2017] benzrf, is that theorem to demonstrate the usefulness of `apply`? :) [Thu Nov 30 17:35:27 2017] here's a newbie proof :D [intros P Q R ; intros P_imp_Q ; intros P_and_R ; destruct P_and_R as [proof_P proof_R] ; exact (P_imp_Q proof_P).] [Thu Nov 30 17:35:36 2017] yeah [Thu Nov 30 17:35:37 2017] I imagine the apply variant will look much simpler [Thu Nov 30 17:35:59 2017] [exact (P_imp_Q proof_P)] is precisely [apply P_imp_Q; exact proof_P] [Thu Nov 30 17:36:19 2017] [apply f] is basically like [exact (f _)] and then your goal is to prove the _ [Thu Nov 30 17:36:26 2017] except it's much smarter than that [Thu Nov 30 17:36:44 2017] ah! now it makes sense. it always does with examples I guess :D [Thu Nov 30 17:36:54 2017] i probably shouldve given one from the start :P [Thu Nov 30 17:39:22 2017] ok I just used my first apply. I assume it gets better and better the longer the implication is, because exact will be more complex to be used? [Thu Nov 30 17:41:26 2017] ah, neat. two subgoals for P_imp_Q_imp_R for (P -> R -> Q) -> P /\ R -> Q [Thu Nov 30 17:42:24 2017] instead of (exact P_imp_Q_imp_R proof_R proof_P) which can get trickier [Thu Nov 30 17:43:43 2017] :) [Thu Nov 30 17:43:55 2017] like i was talking about earlier, it also instantiates variables in foralls, since that's also application [Thu Nov 30 17:59:04 2017] bor0: a useful idiom is something along the lines of [apply H; auto] or a suitable sharpening [Thu Nov 30 18:17:57 2017] Oh man... the chapters keeps introducing tactics. I can't follow :( [Thu Nov 30 18:19:13 2017] what book is that? I'm going through Software Foundations (Vol. 1) but still at the beginning [Thu Nov 30 18:19:30 2017] (well chapter 3 almost) [Thu Nov 30 18:22:22 2017] There's a Tactics chapter, it's useful for reference [Thu Nov 30 18:23:20 2017] Coq's reference manual also serves as a helpful reminder once you know your way around it. [Thu Nov 30 18:26:24 2017] given p_imp_q : p -> q, p_imp_not_q : p -> ~ q. what tactics can I use to prove that not p? [Thu Nov 30 18:26:25 2017] I tried to use the manual [Thu Nov 30 18:31:48 2017] boro_: intro and apply [Thu Nov 30 18:33:11 2017] woot. thanks :D [Thu Nov 30 18:34:18 2017] When do I use 'generalize dependent'? [Thu Nov 30 18:34:52 2017] Most likely before induction [Thu Nov 30 18:35:13 2017] I used intro/apply, my proof pass and I don't understand what apply did there :( given [p_imp_q : p -> q] ; [p_imp_not_q : p -> ~ q] ; [assume_P : p] and a goal False, why did [apply p_imp_not_q] give me 2 goals of p and q? [Thu Nov 30 18:35:53 2017] That's not in chapter 2-3! [Thu Nov 30 18:54:37 2017] boro: ~q means q -> False [Thu Nov 30 18:55:04 2017] so apply p_impl_not_q proves False assuming both p and q [Thu Nov 30 18:55:30 2017] he's gone [Thu Nov 30 18:58:02 2017] Steverman: uh right [Thu Nov 30 19:57:52 2017] SF: Pumping lemma exercise [Thu Nov 30 19:57:54 2017] Oh man :/ [Thu Nov 30 20:00:03 2017] That's tough. [Thu Nov 30 20:18:04 2017] Who mentioned QuickChick? [Thu Nov 30 20:19:35 2017] I did. [Thu Nov 30 20:22:09 2017] Would you recommend it to someone "reading" SF? [Thu Nov 30 20:26:06 2017] Steverman: do you have experience with QuickCheck, or one of its counterparts in other languages? [Thu Nov 30 20:26:13 2017] None [Thu Nov 30 20:27:00 2017] So I wouldn't recommend it :) [Thu Nov 30 20:27:50 2017] Okay :< [Thu Nov 30 20:28:38 2017] Benjamin Pierce is actually looking at whether SF+QuickChick would make a good combination. [Thu Nov 30 20:29:46 2017] Ah well. By then the course will be over [Thu Nov 30 20:29:53 2017] But for now the project is still in a very early stage. [Thu Nov 30 21:55:43 2017] Okay, I give up on pumping lemma :D [Thu Nov 30 22:25:43 2017] Steverman: 4-star exercises can indeed be hard. But have you had a formal logic course? [Thu Nov 30 22:26:01 2017] It's actually 5 [Thu Nov 30 22:26:23 2017] Steverman: OK, you’re definitely trying too hard [Thu Nov 30 22:26:28 2017] my first theorem-proving experience sounded like yours [Thu Nov 30 22:26:55 2017] Studying formal logic and type systems helped [Thu Nov 30 22:26:57 2017] My last logic course was 3 years ago [Thu Nov 30 22:27:10 2017] (Also, programming in Agda did) [Thu Nov 30 22:27:25 2017] Ah, but you did have logic! That helps [Thu Nov 30 22:27:43 2017] Yeah [Thu Nov 30 22:27:50 2017] It's actually an assignment [Thu Nov 30 22:28:43 2017] oh. tough. [Thu Nov 30 22:28:56 2017] The whole chapter [Thu Nov 30 22:29:02 2017] I can maybe answer on “how much to intro” and induction though? [Thu Nov 30 22:29:15 2017] I did everything up to pumping lemma [Thu Nov 30 22:29:28 2017] cool! [Thu Nov 30 22:30:24 2017] All the way from Basics (with every optional exercise) [Thu Nov 30 22:30:33 2017] including informal proofs [Thu Nov 30 22:32:18 2017] I feel like I need to start over because I am not always doing it in a "structural" way [Thu Nov 30 22:34:26 2017] do you understand why your tactics work? [Thu Nov 30 22:35:00 2017] I know what they do. Advanced tactics usage.. not so much [Thu Nov 30 22:36:02 2017] well, once you can follow a proof script you completed, and get why a certain tactic works, you’re already pretty good [Thu Nov 30 22:36:22 2017] I may need to reread the theory again (from lambda calculus to CoC), but the material my lecturer uploaded isn't great [Thu Nov 30 22:36:52 2017] Sometimes they're just puzzles for me [Thu Nov 30 22:37:07 2017] did you do functional programming before? [Thu Nov 30 22:37:23 2017] Very little [Thu Nov 30 22:37:25 2017] Scheme [Thu Nov 30 22:37:58 2017] That helps a bit, but something with types would have helped more [Thu Nov 30 22:38:08 2017] Created a parser for a subset language [Thu Nov 30 22:38:14 2017] So lots of pattern matching [Thu Nov 30 22:38:19 2017] good [Thu Nov 30 22:38:44 2017] Oh yeah.. created a compiler from scratch with SML [Thu Nov 30 22:39:20 2017] This is the book: https://www.cs.princeton.edu/~appel/modern/ml/ [Thu Nov 30 22:39:26 2017] because it helps to see that a theorem is a function from its argument to a proof of the thesis [Thu Nov 30 22:39:46 2017] so if sum_comm : forall a b, a + b = b + a [Thu Nov 30 22:40:15 2017] then `sum_comm m (n+1)` is a function application [Thu Nov 30 22:40:29 2017] and a proof that `m + (n + 1) = (n + 1) + m` [Thu Nov 30 22:40:59 2017] Aha [Thu Nov 30 22:41:21 2017] you can use that with `exact` [Thu Nov 30 22:41:34 2017] (with the whole term) [Thu Nov 30 22:41:47 2017] or use `apply` to construct things bit-by-bit [Thu Nov 30 22:41:59 2017] I mostly use apply [Thu Nov 30 22:42:16 2017] yes, it’s usually easier [Thu Nov 30 22:42:58 2017] but for me things got easier once I could understand theorem proving in terms of functional programming [Thu Nov 30 22:43:05 2017] and types [Thu Nov 30 22:43:36 2017] anyway, talking too much — any questions I might help with? [Thu Nov 30 22:43:37 2017] type theory? [Thu Nov 30 22:44:12 2017] Oh, I don't know. I may need a coq cheatsheet or something [Thu Nov 30 22:44:16 2017] what about it? [Thu Nov 30 22:44:29 2017] yeah, the amount of tactics is overwhelming [Thu Nov 30 22:44:56 2017] the reference manual in PDFs starts having a usable table of contents [Thu Nov 30 22:44:57 2017] sometimes I don't know when to use inversion or destruct [Thu Nov 30 22:45:09 2017] ah, good question [Thu Nov 30 22:45:30 2017] destruct H does case analysis on all constructors of H [Thu Nov 30 22:45:42 2017] but inversion is smarter [Thu Nov 30 22:45:52 2017] I mean it was straight forward between induction and destruct [Thu Nov 30 22:46:09 2017] sometimes, some of those constructors aren’t plausible [Thu Nov 30 22:47:08 2017] I mostly use inversion [Thu Nov 30 22:48:32 2017] ah, found an example [Thu Nov 30 22:48:42 2017] take H : ev (S (S n)) [Thu Nov 30 22:48:59 2017] where ev is the inductive for “even” [Thu Nov 30 22:49:52 2017] now, destruct thinks that H can be ev_0 or ev_SS, since it’s a value of type ev something [Thu Nov 30 22:50:03 2017] Right [Thu Nov 30 22:50:17 2017] inversion is smarter, and realizes that an instance of ev (S (S n)) can’t be built from ev_0 [Thu Nov 30 22:50:35 2017] because it ev_0: ev 0 [Thu Nov 30 22:50:48 2017] and there is no solution to ev 0 = ev (S (S n)) [Thu Nov 30 22:51:04 2017] (this can be found by first-order unification, if you’ve seen the concept) [Thu Nov 30 22:51:20 2017] so inversion will only give you one case [Thu Nov 30 22:51:27 2017] Right [Thu Nov 30 22:51:37 2017] that’s the difference [Thu Nov 30 22:51:52 2017] destruct can be faster, but that’s it [Thu Nov 30 22:52:05 2017] I see [Thu Nov 30 22:52:37 2017] still, you can use `destruct` when you don’t need inversion for “cleanliness”, but that’s a secondary concern [Thu Nov 30 22:53:30 2017] now I could say that both tactics do pattern matching on the proofs [Thu Nov 30 22:54:11 2017] (not sure that helps, this pairs with the thing above on apply and exact) [Thu Nov 30 22:54:52 2017] and `inversion` is a smarter form of pattern matching (it is similar to pattern matching on GADTs, if that says anything, but maybe this isn’t helpful) [Thu Nov 30 22:55:39 2017] Gotta look that up :), [Thu Nov 30 22:57:44 2017] only if it helps [Thu Nov 30 22:58:14 2017] Yeah, I don't think it's relevant fo rme [Thu Nov 30 22:58:57 2017] anyway, I should probably sleep — hope this helped at least a bit! And good luck! [Thu Nov 30 22:59:31 2017] Yes thank you! [Fri Dec 1 00:50:58 2017] Is there a clean way to talk about equality of lists modulo transposition of elements (in some finite set)? This has been giving me some trouble - obviously for two elements you can enumerate the cases with an inductive definition. I am trying to getting bogged down with a specification in terms of positions (or functions). The context is that I need to prove an exchange lemma for a typing relation with a synthesized output context (an [Fri Dec 1 00:50:59 2017] d need to talk about equality modulo transposition). [Fri Dec 1 00:54:29 2017] minn: you want to argue about permutations of lists? [Fri Dec 1 00:54:59 2017] minn: usually you define an inductive proposition Permutation l1 l2. [Fri Dec 1 00:55:48 2017] minn: and then in order to make proofs easier you can drop into counting elements in each list. If the counts of the elements are the same, then they're permutations of each other. [Fri Dec 1 00:56:17 2017] https://github.com/DeepSpec/dsss17/blob/master/auto/ReflectivePermutation.v <-- minn this might be useful to you! [Fri Dec 1 00:57:10 2017] It would be much easier if I just needed permutations (or subsequences). I need to say that two lists xs and ys are equal, except that for the elements occurring in some list zs, those elements might not occur or might be transposed (but only elements in zs). [Fri Dec 1 00:57:57 2017] minn: oh, hmmmm. [Fri Dec 1 00:58:29 2017] The implementation of permutations in the standard library is nice to reason about - I'm having trouble coming up with a similarly nice inductive definition (or other specification). [Fri Dec 1 00:58:33 2017] minn: I would guess you could do something similar, but I'm not sure exactly what you mean. [Fri Dec 1 00:59:08 2017] xs = ys, except there might be some elements from zs mixed in there? [Fri Dec 1 00:59:26 2017] yeah, the elements in zs might not be present or could be swapped. [Fri Dec 1 00:59:48 2017] minn: but otherwise xs and ys are in the same order? [Fri Dec 1 01:00:02 2017] right, if you removed all elements in zs the lists would be identical [Fri Dec 1 01:01:30 2017] Ok something like "remove zs xs = remove zs ys" where remove is some function which removes elements from the first list from the second list. [Fri Dec 1 01:03:28 2017] huh, that might actually be a strong enough condition - i was banging my head against inductive definitions [Fri Dec 1 01:03:56 2017] minn: you can definitely make an inductive definition for this too. [Fri Dec 1 01:04:16 2017] Whether or not it's pretty at all is another question -- I'm starting to see if I can make one :P> [Fri Dec 1 01:06:02 2017] minn: what are you trying to do btw? [Fri Dec 1 01:09:30 2017] prove some basic structural properties of a (deterministic) typing relation for stlc + linear types that synthesizes an output context (to prove exchange lemmas, it isn't sufficient for the output contexts to be permutations). [Fri Dec 1 01:10:14 2017] i think something like what you suggested is probably the way to go [Fri Dec 1 01:14:46 2017] http://lpaste.net/360391 <-- minn something like that for the Inductive proposition, maybe? [Fri Dec 1 01:20:33 2017] i think that's pretty closed to the relation i'm looking for - it seems simple when put like that [Fri Dec 1 01:21:55 2017] They're usually suprisingly simple things! [Fri Dec 1 01:22:52 2017] But that's my understanding of what you want, anyway. You might want to think up better names or whatever, but I think it should do what you want? Let me know if it works out / how the proving goes :). [Fri Dec 1 01:29:13 2017] it's pretty close - i think a slightly stronger relation will work very well. thanks :( [Fri Dec 1 01:29:16 2017] err :) [Fri Dec 1 01:52:58 2017] how is bool defined in Coq and why can't I use induction on it? if I do [Inductive my_bool : Set := true : my_bool | false : my_bool.] I can use induction on my_bool which is fancy [Fri Dec 1 01:53:41 2017] Why do you think you can't do an induction on a boolean? bool is defined the same way as your in the stdlib. [Fri Dec 1 01:53:46 2017] (try `Print bool.`) [Fri Dec 1 01:53:53 2017] yours* [Fri Dec 1 01:54:08 2017] I'm having troubles proving [Theorem double_neg_elim : forall p : Prop, not (not p) -> p.] and I tried to approach using induction [Fri Dec 1 01:54:42 2017] Oh, Prop and bool are two different beasts [Fri Dec 1 01:55:03 2017] oh, I just noticed I have Prop there. wow. how are they different? [Fri Dec 1 01:55:06 2017] and you cannot prove what you want to prove in an intuitionnistic settings [Fri Dec 1 01:55:19 2017] The elimination of double negation is typically classical [Fri Dec 1 01:55:22 2017] yeah I have excluded middle as an axiom but I'm still stuck [Fri Dec 1 01:55:38 2017] Then you can use excluded middle on the proposition p. [Fri Dec 1 01:56:09 2017] If you have a proof of p then your goal is trivial, and if you have a proof of (not p), then you can use it together with the `not (not p)` to derive an absurdity [Fri Dec 1 01:56:49 2017] For the difference between Prop and bool: bool is a type of booleans, you can compute with it, you can check if a boolean is `true` or `false` and so on, because it just an inductive type. [Fri Dec 1 01:56:50 2017] is the difference between Prop and bool having to do with provability? [Fri Dec 1 01:56:54 2017] yes [Fri Dec 1 01:57:02 2017] ok that makes sense :) [Fri Dec 1 01:57:26 2017] Prop is a universe of propositions: when you have `P : Prop`, you don't know anything about the provability of P, unless you can build a term `p : P` [Fri Dec 1 01:57:49 2017] So in general you cannot "compute" a proposition [Fri Dec 1 01:58:15 2017] The ability to decide for any proposition if it's true or false is exactly the excluded middle [Fri Dec 1 01:59:26 2017] ok, this makes sense. and P \/ ~P doesn't make sense in the world of Prop, but it does in the world of bool because we have only 2 possible values, correct? [Fri Dec 1 01:59:55 2017] (just trying to figure out why we need excluded_middle as axiom for Prop) [Fri Dec 1 02:00:11 2017] `P \/ ~P` is a valid statement, but you cannot prove it in general [Fri Dec 1 02:00:18 2017] (you might be able to prove it for some specific propositions) [Fri Dec 1 02:00:34 2017] why can we not prove it? [Fri Dec 1 02:01:22 2017] because not every statement is decidable. As long as you don't add any axiom to Coq, if you have a proof of `P \/ ~P`, then you can actually know if P is true or false [Fri Dec 1 02:01:46 2017] But what if P is some fact that is know to be undecidable, such as the halting problem, or the continuum hypothesis, stuff like that? [Fri Dec 1 02:01:50 2017] known* [Fri Dec 1 02:02:06 2017] can you tell me which tactic I can use to "include" excluded_middle as hypothesis in my proof for double_neg_elim? [Fri Dec 1 02:02:46 2017] Just `apply` should be enough. You probably have some constant `excluded_middle : forall P, P \/ ~P` [Fri Dec 1 02:02:50 2017] oh, I see. so it has to do with computability [Fri Dec 1 02:02:50 2017] (it might have another name) [Fri Dec 1 02:05:11 2017] I have [Axiom excluded_middle : forall p : Prop, p \/ ~ p.], but when I try to `apply` it it says it's Unable to unify "p \/ ~ p" with "p". [Fri Dec 1 02:06:23 2017] Oh right, I don't know what I was saying. So, `excluded_middle p` has type `p \/ ~p`, which means that you can do `destruct (excluded_middle p)` [Fri Dec 1 02:06:42 2017] wow! I can use destruct in that way. awesome [Fri Dec 1 02:11:17 2017] thank you. :) [Fri Dec 1 04:39:25 2017] is there a way to cast a list to "cons_type", and have a proof obligation be generated automatically? Definition isCons {T} (l: list T) := match l with | nil => False | cons _ _ => True end. Definition cons_type {T} := {l: list T | isCons l}. Definition l: cons_type := (cons 5 (cons 7 nil): cons_type). [Fri Dec 1 05:07:46 2017] Hello, [Fri Dec 1 05:11:41 2017] If in my goal I've something like "T a b", can I somehow add a rule "assert (U b)" without copy/paste it? I tried "let b := match goal with T a b => b end. but I've a syntax error "Syntax error: ':' or ':=' expected after [Prim.name] (in [match_hyps])." [Fri Dec 1 05:13:29 2017] `match goal with |- T _ ?b => assert (U b) end` for instance [Fri Dec 1 05:13:59 2017] The ?b binds the name `b` to this subterm, the _ says that you don't care about this subterm [Fri Dec 1 05:17:10 2017] Great thank you! What "|-" is for? [Fri Dec 1 05:18:12 2017] |- separates the hypotheses from the goal [Fri Dec 1 05:18:23 2017] it just happens that I don't care about the hypotheses, so there is nothing to the left [Fri Dec 1 05:18:56 2017] you could do stuff like `match goal with H : ?ty |- ?ty => exact H` to re-implement the `assumption` tactic for instance [Fri Dec 1 05:23:25 2017] ok that's great, thank you very much! And I managed to do the same thing with let, and it works great, except if I want to return a tuple. let (a,b) = ... => (a,b) end. in ... is not correct ? [Fri Dec 1 05:23:32 2017] s/=/:= [Fri Dec 1 05:24:12 2017] So, I may be wrong here, but I don't think Ltac has actual tuples. You can only bind one name to a value and that's it [Fri Dec 1 05:24:25 2017] You _can_ bind a tuple to a name, but that would be a tuple from Gallina, not from Ltac [Fri Dec 1 05:24:46 2017] (hopefully this will change at some point in the future where Ltac will be an actual programming language, but for now it's not the case) [Fri Dec 1 05:32:54 2017] I'm trying out the "Program Definition" command, this is what I needed! So "Program Definition l := cons ((cons 5 (cons 7 nil))) nil: list (cons_type nat)." this works well, but this fails: "Program Definition l := cons ((cons 5 (cons 7 nil))) nil: cons_type (cons_type nat)." any reason why? [Fri Dec 1 06:12:45 2017] Cypi: Ok thank you! [Fri Dec 1 06:41:50 2017] In a tactic, can I create a fresh name, and remember it? Something like "let a := in assert( : ...) ... simpl in ." [Fri Dec 1 06:42:40 2017] Yup, the `fresh` tactic exists [Fri Dec 1 06:42:58 2017] `let a := fresh in ...` or `let a := fresh "a" in ...` if you want to give a "base" name [Fri Dec 1 06:43:14 2017] (it will generate a fresh name from this base, like a or a0, a1, ...) [Fri Dec 1 06:46:29 2017] Cypi: that's great, thank you very much! [Fri Dec 1 06:47:05 2017] (just there is a minor typo, it's "let tac a") [Fri Dec 1 06:48:20 2017] hum wait [Fri Dec 1 06:49:06 2017] I used: let tac hyp := fresh "MyH" in assert (hyp: ...). [Fri Dec 1 06:49:22 2017] and the name of the hypothèse is "hyp", not "MyH". [Fri Dec 1 06:49:39 2017] How could I say "I want to use the variable "hyp", not the name "hyp". [Fri Dec 1 06:52:17 2017] Oh, you're right, with `assert` it will probably go wrong... [Fri Dec 1 06:52:50 2017] Hmm, I can't think of something less manu than `refine (fun (hyp : ...) => _) _` right now :/ [Fri Dec 1 06:53:05 2017] manual* [Fri Dec 1 06:53:26 2017] (also note that it might swap the goal compared to what `assert` would give. If it's a problem, you can use `refine (...); swap 1 2`) [Fri Dec 1 06:57:10 2017] Wait, on my Coq it works. `let H := fresh "blih" in assert (H : True).` created a hypothesis named "blih" in the second subgoal [Fri Dec 1 06:57:21 2017] hmm... [Fri Dec 1 06:57:45 2017] (it also works in Coq 8.6) [Fri Dec 1 06:59:07 2017] 'let tac hyp := fresh "MyH"': why "let tac hyp" and not "let hyp"? [Fri Dec 1 06:59:14 2017] oh ok [Fri Dec 1 06:59:16 2017] tobiasBora: actually, why did you add the `tac`? This creates a Ltac function named `tac`, that's all [Fri Dec 1 06:59:27 2017] (I didn't notice at first, my bad) [Fri Dec 1 07:01:02 2017] that's the point, at the beginning I got an error, and I google it and I found "let tac ...". So I replace it, and I still got an error, and I just realized that the name for the hypothesis was already taken, so I changed the name, but I forgot to change back "let tac" into "let". Sorry for that ! [Fri Dec 1 07:01:25 2017] No problem, of course [Fri Dec 1 07:09:19 2017] Now I begin to like Coq ^^ [Fri Dec 1 07:11:15 2017] Just a question, Ltac cannot have type for the input? I tried "Ltac mytac (x : my_type)", but it does not work, and the documentation never mention any type for the argument of a tactic [Fri Dec 1 07:11:39 2017] ltac is an untyped language [Fri Dec 1 07:11:54 2017] or dynamically typed/unityped/whatever you want to call it [Fri Dec 1 07:20:00 2017] minn: for your type system, is there any chance to work with separate contexts rather than removing one from another? [Fri Dec 1 07:23:03 2017] cocreature: interesting ^^ Pretty rare in the ML world ! [Fri Dec 1 07:24:08 2017] tobiasBora: fwiw ltac2 or at least the plans that I saw for it will be typed. no idea what its current state is though [Fri Dec 1 07:24:47 2017] It's fairly advanced (and already used by some for testing purposes). I don't know if/when it will be shipped with Coq, but it's already possible to play with it [Fri Dec 1 07:25:19 2017] Cypi: nice! is https://github.com/ppedrot/ltac2 what one should be looking at? [Fri Dec 1 07:25:30 2017] yes [Fri Dec 1 07:26:14 2017] great, now I only need to find the time to play around with it :) [Fri Dec 1 07:27:14 2017] Does that mean that everything I'm currently learning with ltac will be useles in a few months ? [Fri Dec 1 07:27:31 2017] useless* [Fri Dec 1 07:27:33 2017] Nope [Fri Dec 1 07:28:26 2017] Firstly, I don't know if/when Ltac2 will completely replace Ltac, not sure what the plans are. Secondly, one of the goals of Ltac2 is to stay true to what Ltac looks like, so that it's easy to transition [Fri Dec 1 07:28:54 2017] (or even seamless for the basic stuff) [Fri Dec 1 07:30:29 2017] what a nice team! [Fri Dec 1 07:31:11 2017] retrocompatibility in general is always taken into account when changing stuff [Fri Dec 1 07:34:20 2017] except for python3 [Fri Dec 1 07:34:33 2017] I meant, in the case of the Coq devteam x) [Fri Dec 1 07:34:38 2017] I don't know about other projects [Fri Dec 1 07:38:09 2017] ahah sure. But sometimes when people rewrite a tool, it's because it was not though in the good way at the beginning, and it may be possible that, because everything is thought in a different manner, the initial code becomes a nonsense. But anyway, it's good to know that I continue to learn ltac ;) [Fri Dec 1 09:33:40 2017] tobiasBora: most of the Coq community uses Ltac, and different languages easily coexist, so don’t worry [Fri Dec 1 09:34:18 2017] all tactics languages generate terms in the same core language, so there’s no hurry to unsupport Ltac [Fri Dec 1 14:08:12 2017] Ok thank you! [Fri Dec 1 14:09:50 2017] Just, I'd like to create a function that will be used in the tactics that basically filter a list. Should I define this function using Ltac, let, or Define/Fixpoint ? [Fri Dec 1 14:35:19 2017] tobiasBora: sounds like you might want to study inList and nearby functions in https://jozefg.bitbucket.io/posts/2014-07-09-dissecting-crush.html [Fri Dec 1 14:36:03 2017] also, for your question, it seems you want Ltac — I don’t think Ltac can call Coq functions [Fri Dec 1 14:37:13 2017] I suspect you’d have a hard time picking a type for those Coq functions [Fri Dec 1 14:38:15 2017] on inList, somebody mentioned a singleton “faux-list” with `x` as element is produced with `(x)`, for use with `inList` [Fri Dec 1 14:39:03 2017] * wants to open a new thread, wonders how to do it on IRC [Fri Dec 1 14:39:33 2017] can anybody here compare Autosubst vs locally nameless and other approaches? [Fri Dec 1 14:40:02 2017] I can look at the Autosubst paper, and I’ve already learned they’re redesigning it [Fri Dec 1 14:40:15 2017] so the original version is only semi-maintained [Fri Dec 1 16:12:28 2017] pgiarrusso: no threads on IRC, just rooms. [Fri Dec 1 16:13:39 2017] Chobbes: Hi there! I know, it was a joke also serving as vertical whitespace [Fri Dec 1 16:14:09 2017] Chobbes: I'm Blaisorblade on Twitter, think we tweeted? [Fri Dec 1 16:17:37 2017] Chobbes: Oh yeah, you must be https://twitter.com/Chobbez [Fri Dec 1 16:23:38 2017] pgiarrusso: oh yeah! Hi :). [Fri Dec 1 16:24:41 2017] Thought you might have been new to IRC from slack or something. Where the best feature slack has added is threads :P. [Fri Dec 1 16:29:55 2017] pgiarrusso: are you doing lambda calculus things in Coq? If you want to know more about locally nameless I would check out Stephanie Weirich's lectures from DSSS17. [Fri Dec 1 16:30:46 2017] https://www.youtube.com/watch?v=MxFpplaMDXs [Fri Dec 1 16:32:09 2017] But I don't think there was any comparison with autosubst (which I haven't heard of until now). [Fri Dec 1 16:32:47 2017] Chobbes: Poe's law [Fri Dec 1 16:33:35 2017] I'm using some locally nameless mechanizations, but I'm slowly getting tired of the proof obligations [Fri Dec 1 16:35:39 2017] So I'm wondering if Autosubst is worth the switch; its papers seem interesting but it seems it's not as mature [Fri Dec 1 16:36:08 2017] But thanks for the pointer, might be worth checking out (not a talk guy but gotta try) [Fri Dec 1 16:39:05 2017] pgiarrusso: I think most of the automation in professor Weirich's lecture comes from Ott for generating useful lemmas and theorems. [Fri Dec 1 16:40:34 2017] I.e., I don't remember much automation when actually writing proofs about terms in the calculus, other than some automated finite set tactics. [Fri Dec 1 16:41:23 2017] https://github.com/plclub/lngen oh and this. [Fri Dec 1 16:42:23 2017] https://github.com/DeepSpec/dsss17 [Fri Dec 1 16:43:10 2017] Lecture material is in the Stlc directory. I dunno if any of this is helpful to you, but it's resources that I'm vaguelly aware of :) [Fri Dec 1 16:51:04 2017] Chobbes: probably useful to have up-to-date pointers [Fri Dec 1 16:52:13 2017] I spent six-month reviewing papers on a different topic, then 3 hours with an expert made a huge difference [Fri Dec 1 16:52:52 2017] Now, it did take those 6 months to be able to convey that much information in 3 hours [Fri Dec 1 16:54:08 2017] though this might boil down to “studying math helps talking about math” ;-) [Fri Dec 1 17:58:31 2017] is this axiom consistent with Coq? "Axiom classic : forall P:Prop, P + ~ P.". I want to use it to define a PropToBool function [Fri Dec 1 18:08:20 2017] sud: that's excluded middle? [Fri Dec 1 18:08:42 2017] Chobbes: the usual one is with \/ [Fri Dec 1 18:09:21 2017] This is strong excluded middle https://github.com/coq/coq/wiki/CoqAndAxioms [Fri Dec 1 18:09:25 2017] and should be consistent [Fri Dec 1 18:54:50 2017] hi! I am trying to prove a property in my program [(forall l : natlist, has_odd (evenmembers l) = false)]. I use induction and am stuck on the goal [has_odd (if Nat.even n then cons n (evenmembers l) else evenmembers l) = false]. I tried to use case (Nat.even n) but I don't have hypothesis to re-use for each case [Fri Dec 1 18:55:24 2017] evenmembers takes a list and returns only even numbers. has_odd returns a boolean whether list contains any odd numbers [Fri Dec 1 18:58:16 2017] You can use `destruct (Nat.even n) eqn:Hn` to keep an equality that will say `Nat.even n = true` or `Nat.even n = false` [Fri Dec 1 18:58:45 2017] that saves the day I think! thanks! :) [Fri Dec 1 19:00:08 2017] Qed. woot! my first "useful" proof on lists! [Fri Dec 1 19:01:20 2017] so now that you told me this new gem I can use in my proofs, I figured while going through "Logical Foundations" I have a wrong answer [Fri Dec 1 19:01:31 2017] Briefly explain the difference between the tactics destruct and induction: When we use destruct to analyze cases we don't have hypothesis to re-use, unlike induction. [Fri Dec 1 19:02:43 2017] we *can* have hypothesis with destruct as well, right? [Fri Dec 1 19:02:55 2017] You're not completely wrong. `destruct` will only give information about the thing you can destructing, and you can keep an equality about it if you want. The hypothesis that you can gain with `induction` is an induction hypothesis that tells something about the _subterms_ of the thing you are destructing [Fri Dec 1 19:03:02 2017] s/can/are/ [Fri Dec 1 19:03:59 2017] ah, correct. I am missing the keyword _subterms_ in my explanation [Fri Dec 1 19:05:18 2017] thank you again, Cypi! [Fri Dec 1 19:32:40 2017] Somebody update the Wiki page: it has moved to Github [Sat Dec 2 07:01:20 2017] is there a way to allow Coq to have redundant match clauses? [Sat Dec 2 08:07:45 2017] pgiarrusso: sorry, yesterday I ran out of battery. I wanted to use Ltac, but autosubst's syntax .| seems not to be usable, so I defined i using fixpoint. However, to use it I'd like to define a fonction (or Ltac ?), that returns a function like that: "match goal with |- deduc _ _ ?g => (fun x => x = g) end" (the out should be of type "type -> bool"). [Sat Dec 2 08:08:29 2017] on Fixpoint, it should not work because match goal is for ltac, however, it I use Ltac, it does not work... [Sat Dec 2 08:19:19 2017] and if I define everything using Ltac, the line "let r := b.|[ren(+curr_lift)] in" gives me the error "Syntax error: 'with' or 'in' expected (in [tactic:binder_tactic])." [Sat Dec 2 08:26:43 2017] Hum, I tried to replace .| with hsubst, and now the error is in the "if" on the next line "let r = ... in if (f r) then ..." [Sat Dec 2 08:26:50 2017] "Syntax error: [tactic:tactic_expr level 5] expected after 'in' (in" [Sat Dec 2 08:32:08 2017] I tried to change "if" with match ... with true => ... | _ => ... in", but now I've an error saying that the function "hsubst" does not exists (while it's supposed to be imported from autosubst). Can I somehow import a function from galinea into ltac. [Sat Dec 2 08:33:52 2017] tobiasBora: I'd try using Ltac, and fixing those syntax errors with more parens [Sat Dec 2 08:35:41 2017] pgiarrusso: yes, I fixed the syntax errors, but now the problem is that I'd like to do a pattern matching on the result of a function imported from autosubst, and this function seems to stay "in the coq world", and I can't use it the ltac... [Sat Dec 2 08:37:03 2017] What you wrote is that you didn't fix the syntax error, but you tried to do something else... [Sat Dec 2 08:37:21 2017] On the world separation: [Sat Dec 2 08:38:21 2017] Ltac can refer to Gallina functions, but it can't "run" them, it can paste together terms that will run them [Sat Dec 2 08:41:27 2017] tobiasBora: can you post a more complete example on a pastie? [Sat Dec 2 08:42:18 2017] pgiarrusso: sure: https://zb.phyks.me/ [Sat Dec 2 08:42:20 2017] oups [Sat Dec 2 08:42:26 2017] https://zb.phyks.me/?f4587b7c4f3f4b44#xN1BW11A4HckJ4pInK7u9K+wkru7xoOzb/rolK8K78E= [Sat Dec 2 08:43:41 2017] Ok, can you explain what you want to achieve? [Sat Dec 2 08:45:26 2017] sure, so basically, I've a goal like "|- A _ g _". So a tactic will first match the goal to extract g, and then call my function. [Sat Dec 2 08:45:35 2017] This g is a kind of list of expression [Sat Dec 2 08:45:50 2017] so that's why I first do a pattern matching on this g. [Sat Dec 2 08:45:51 2017] Is g a Coq or Ltac list? [Sat Dec 2 08:46:00 2017] the problem is on the "assume" case [Sat Dec 2 08:46:41 2017] basically, f would intuively be a filter a filter function, that would return a bool when applied on a given argument [Sat Dec 2 08:47:06 2017] this argument should be r, i.e. "hsubst (ren(+curr_lift)) b" [Sat Dec 2 08:47:11 2017] Really, what sort of list is g? [Sat Dec 2 08:47:33 2017] Because if it is a Coq list, it makes no sense to recurse on it in Ltac [Sat Dec 2 08:47:39 2017] yes it's a coq list [Sat Dec 2 08:47:55 2017] well a kind defined in coq. [Sat Dec 2 08:48:27 2017] OK, so from what you said the recursion on the list must in in Gallina [Sat Dec 2 08:48:38 2017] ok [Sat Dec 2 08:48:39 2017] But the match goal must be in Coq [Sat Dec 2 08:48:50 2017] Gallina and coq is not the same thing? [Sat Dec 2 08:48:56 2017] Sorry [Sat Dec 2 08:49:08 2017] Match goal must be in Ltac [Sat Dec 2 08:50:02 2017] Well, strictly speaking Coq has everything, though we use it usually (but sloppily) to mean Gallina [Sat Dec 2 08:50:09 2017] ok [Sat Dec 2 08:50:18 2017] I mean, Coq includes Ltac, Gallina doesn't [Sat Dec 2 08:50:35 2017] so in this model I've another problem: define the filter function "f" in my code [Sat Dec 2 08:51:57 2017] tobiasBora: also, are you sure you understand the stage distinction between Ltac and Gallina? [Sat Dec 2 08:52:25 2017] I think that I see the difference yes. Basically Ltac generate Gallina code that will handle the proof right? [Sat Dec 2 08:54:45 2017] tobiasBora: correct! Now, if I have in a proof context a variable g bound to one of your “list”, and I try to match it in Ltac, what does Ltac see? [Sat Dec 2 08:55:09 2017] I ask because that’s what the snippet tries to do [Sat Dec 2 08:55:43 2017] and overall, I ask because your task seems to require mixing Ltac and Gallina carefully, so I want to make sure before we proceed [Sat Dec 2 08:55:58 2017] sure no problem. Let me think... [Sat Dec 2 08:57:38 2017] Actually it's a good question, I would say that Ltac would have the ability to read g if g has already been generated before the call to the tactic. [Sat Dec 2 08:58:25 2017] well, but g is just a variable in context [Sat Dec 2 08:58:59 2017] and I mean a proof context — like, one of the assumptions in a goal [Sat Dec 2 08:59:16 2017] if I finish the proof and run it, g will have a value [Sat Dec 2 08:59:44 2017] but when I’m writing the proof g is just a Gallina variable [Sat Dec 2 09:00:25 2017] so it does *not* have a value [Sat Dec 2 09:00:27 2017] hum... You mean something like "g: Mytype |- ..." ? [Sat Dec 2 09:00:39 2017] something like that [Sat Dec 2 09:01:09 2017] ok, so here I agree. [Sat Dec 2 09:01:18 2017] it’s different if g is an Ltac variable bound to some Coq expression [Sat Dec 2 09:01:41 2017] like in "match goal with Mytype g => " ? [Sat Dec 2 09:01:47 2017] yes [Sat Dec 2 09:01:52 2017] *Mytype ?g [Sat Dec 2 09:02:11 2017] ok [Sat Dec 2 09:02:14 2017] so, if you have an Ltac match binding g to something *appearing in the goal*, you can do metaprogramming on the g — on what appeared in the goal [Sat Dec 2 09:02:34 2017] actually, I’m taking your “match goal with Mytype g => “ loosely [Sat Dec 2 09:04:06 2017] so when you say “I’ve got a goal of shape ‘|- A _ g _’”, which one do you mean? [Sat Dec 2 09:04:23 2017] I mean the "match goal" thing [Sat Dec 2 09:05:14 2017] to be sure: you mean your goal could be ‘|- A _ nilc _” or “|- A _ (intc _) _” etc? [Sat Dec 2 09:05:50 2017] and you want to run different tactics if you have literally `nilc` or `(intc _)` ? [Sat Dec 2 09:06:13 2017] kind of yes [Sat Dec 2 09:07:00 2017] well, if those can be different functions I’d stick to gallina, but if you need different *tactics* maybe you need Ltac [Sat Dec 2 09:07:28 2017] still, the pattern match in the snippet will fail if your goal is literally `|- A _ g _` [Sat Dec 2 09:07:40 2017] where `g` is a Gallina variable [Sat Dec 2 09:08:14 2017] if you’re familiar with the metalanguage/object language distinction, maybe it helps to use that language [Sat Dec 2 09:08:36 2017] Ltac is a metalanguage for manipulating expressions from Gallina, the object language [Sat Dec 2 09:09:11 2017] and in `filter_aux`, `g` is a metavariable standing for an object expression of type `mytype` [Sat Dec 2 09:10:53 2017] yes, this seems pretty natural, it's exactly what I want [Sat Dec 2 09:11:39 2017] well `filter_aux` looks like it’s written in the Gallina mindset, but maybe you’re right [Sat Dec 2 09:12:20 2017] still, I’m not sure what you overall are trying to achieve, at a higher level, so I’m not sure what you actually need to do, beyond writing out what lives at which stage [Sat Dec 2 09:12:25 2017] ok, so with your nice advices, now I've something that "types", but when I try to run it I've an error saying the "a = b" returns a Prop, while it should be a bool. How could I return a bool to test if two elements are syntaxiquely the same ? [Sat Dec 2 09:13:05 2017] pgiarrusso: hum, now I'm doubtful... Not sure anymore, and actually, if it works, it may seems pretty magical ^^{ [Sat Dec 2 09:13:07 2017] ^^'* [Sat Dec 2 09:13:47 2017] well, if it turns out my advice are bad, it’s because this conversation *might* be an instance of the XY problem: https://meta.stackexchange.com/a/66378/210646 [Sat Dec 2 09:13:55 2017] anyway on your next question: [Sat Dec 2 09:14:35 2017] so a and b are metavariables standing for terms, I imagine [Sat Dec 2 09:15:18 2017] it sounds like you want *not* to use decidable equality for their type (which would be what you want in Gallina) [Sat Dec 2 09:18:00 2017] OK, not sure — I usually just reuse a variable in a pattern match (`match goal with ?a + ?a > 5 => ...`) to ensure both positions have the same content... [Sat Dec 2 09:18:03 2017] googling ntime [Sat Dec 2 09:18:05 2017] *time [Sat Dec 2 09:21:54 2017] coq ltac comparing termshttps://stackoverflow.com/q/33049082/53974 and http://coq-club.inria.narkive.com/1I7oD4Vm/term-classification-in-ltac-has-var-is-constr-term-complexity-measure [Sat Dec 2 09:21:59 2017] sorry [Sat Dec 2 09:22:04 2017] I’ve googled `coq ltac comparing terms` [Sat Dec 2 09:22:19 2017] and those two links seem vaguely relevant (not sure) [Sat Dec 2 09:22:38 2017] but... I have no clue [Sat Dec 2 10:11:41 2017] is there a tactic that automatically sees contradictions such as: forall y ys, Cons x xs <> Cons y ys in the hypotheses? [Sat Dec 2 10:16:10 2017] I just wrote a Ltac magic = match goal with H : forall y ys, ?f ?x ?xs <> ?f y ys |- _ => solve [exfalso; eapply H; auto] end. [Sat Dec 2 10:22:37 2017] lyxia: eauto worked :) (after doing intuition to unroll the <> in -> False) [Sat Dec 2 10:35:24 2017] you don't need intuition for that, just "intro" works [Sat Dec 2 10:37:49 2017] which isn't the "right" way either of course, but intuition is fairly expensive to run [Sat Dec 2 11:16:40 2017] pgiarrusso: I think I found a case where I really shouldn't intros everything: "Lemma beq_list_true_iff" in the Logic chapter. [Sat Dec 2 11:17:11 2017] dh`: but the forall was in the hypotheses [Sat Dec 2 11:17:57 2017] ^ that's why [Sat Dec 2 11:18:05 2017] :D [Sat Dec 2 11:18:25 2017] can I have a tactic that unfolds definitions which is defined once and for all, and then add more and more definitions to be unfolded once I defined them? [Sat Dec 2 11:19:46 2017] sud: are you looking for autounfold? [Sat Dec 2 11:20:03 2017] and `Hint Unfold foo`? [Sat Dec 2 11:20:32 2017] though when I’m using Software Foundations and TLC, I often prefer `unfolds` [Sat Dec 2 11:20:48 2017] (which just unfolds the head definition, which seems more useful and safer) [Sat Dec 2 11:23:59 2017] pgiarrusso: nice! is unfolds a custom tactic? [Sat Dec 2 11:24:48 2017] sud: it's from the TLC library [Sat Dec 2 11:25:13 2017] There's IIRC a LibTactics chapter in software foundations [Sat Dec 2 11:27:49 2017] oh, I missed some of the context [Sat Dec 2 11:28:01 2017] for that case I'd probably just write "specialize (H x xs); contradiction" [Sat Dec 2 11:28:48 2017] looking for (or writing) a tactic takes a lot longer than typing one line [Sat Dec 2 11:29:05 2017] so unless you have a gazillion cases like this reappearing... [Sat Dec 2 11:29:30 2017] dh`: but how do you know your hypothesis is H? [Sat Dec 2 11:29:41 2017] You can, but you need to pay attention [Sat Dec 2 11:29:54 2017] Especially if you plan to maintain your proof [Sat Dec 2 11:30:18 2017] lyxia's automation is a bit more robust [Sat Dec 2 11:30:40 2017] (though here it's a bit specific indeed) [Sat Dec 2 11:33:13 2017] mostly you need to worry about that regardless [Sat Dec 2 11:34:02 2017] also, proofs rarely change wildly in a single go, at least IME [Sat Dec 2 11:34:25 2017] but I haven't done any real long-term maintenance on coq things yet [Sat Dec 2 13:08:37 2017] I do wish inversion produced more predictable hypothesis names, though... [Sat Dec 2 14:29:35 2017] If I get false = true, then I suppose I did something wrong earlier [Sat Dec 2 14:29:42 2017] In my goal that is.. [Sat Dec 2 14:32:09 2017] Either you have an absurdity in your hypotheses, or your initial goal is not provable, or you did something wrong [Sat Dec 2 14:32:18 2017] (but in the first case it's perfectly fine) [Sat Dec 2 14:36:30 2017] Because then I could use inversion? [Sat Dec 2 14:37:19 2017] For instance, depends on your hypotheses. [Sat Dec 2 14:39:13 2017] Regarding the 'Search' tactic.. I sometmes can't find e.g: 'andb_true_iff' [Sat Dec 2 14:39:25 2017] But searchin for 'andb' will find it [Sat Dec 2 14:39:36 2017] 'andb_true' will not work [Sat Dec 2 14:40:02 2017] The reference andb_true was not found in the current environment. [Sat Dec 2 14:40:16 2017] If you write `Search andb`, then it will look for any lemma that mentions the constant `andb` in its conclusion [Sat Dec 2 14:40:47 2017] if you want to look for part of the name of a lemma, then you need to write `Search "andb_true".` for instance. [Sat Dec 2 14:40:53 2017] Ah [Sat Dec 2 14:40:58 2017] So quote it [Sat Dec 2 14:41:14 2017] That works :) [Sat Dec 2 14:41:29 2017] in proving [length (reverse l) = length l], I'm stuck on [length l + 1 = S (length l)]. how can I prove something as simple as that? [Sat Dec 2 14:42:49 2017] There is a lemma called `Nat.add_1_r` which will prove exactly that [Sat Dec 2 14:43:07 2017] You can do `Search (_ + 1 = S _).` to search for it for instance [Sat Dec 2 14:43:21 2017] (I think I had to import Arith or something similar to get this lemma though) [Sat Dec 2 14:43:51 2017] Qed. thanks. I just imported PeanoNat [Sat Dec 2 14:44:04 2017] why can't Coq solve that by `simpl.`? (I guess I need to prove it myself to understand) [Sat Dec 2 14:44:54 2017] Addition is defined by induction on the first argument. So, `S n + m` can reduce to `S (n + m)` for instance. But `length l + 1` is simply stuck, because the first argument is `length l` and is not a constructor [Sat Dec 2 14:45:27 2017] So to prove `forall n, n + 1 = S n`, you actually need an induction [Sat Dec 2 14:46:21 2017] bor0: don't they explain it further down the chapter? [Sat Dec 2 14:46:26 2017] oh. I just realized that by proving it. thank you! :) [Sat Dec 2 14:46:35 2017] Steverman, they probably do, but I'm trying my own things on the way [Sat Dec 2 14:46:46 2017] Alright [Sat Dec 2 14:47:03 2017] I also try to just look at the Theorem header only and try to prove it myself before looking at the actual proof [Sat Dec 2 15:11:56 2017] Hmm, I don't quite understand this. So I have "IHl1 : forall l2 : list A, beq_list beq l1 l2 = true <-> l1 = l2", "l1 : list A", "l2 : list A". The IH will only work if the goal is: "beq_list beq l1 l1 = true" [Sat Dec 2 15:12:16 2017] "beq_list beq l2 l2 = true" won't [Sat Dec 2 15:12:48 2017] The induction hypothesis is quantified over l2, but not l1. So you can instantiate l2 with whatever you want, but not l1 [Sat Dec 2 15:13:05 2017] Right [Sat Dec 2 15:22:25 2017] when we say beq l1 l2 l3.. how are the arguments (l1, l2, l3) consumed? are they consumed by quantifiers (forall/exists)? [Sat Dec 2 15:22:43 2017] or is it by hypothesis also? [Sat Dec 2 15:29:01 2017] all of them [Sat Dec 2 15:29:37 2017] in the exact order as in the theorem, I assume? [Sat Dec 2 15:30:48 2017] yes [Sat Dec 2 15:32:00 2017] is it wrong to say that almost all Coq tactics are about rewriting rules? [Sat Dec 2 15:33:06 2017] or substitution rules, if that makes more sense [Sat Dec 2 15:34:18 2017] a follow-up to that, does it have a list of "basic" tactics that all other tactics can be represented by? like Lisp needing only 5 (7?) primitives [Sat Dec 2 15:37:01 2017] Above the line is called the context right? [Sat Dec 2 15:37:29 2017] I've heard state and hypothesis, but I guess context isn't that far off :) [Sat Dec 2 15:38:11 2017] Oh well [Sat Dec 2 15:38:15 2017] I have these: 'H : forall P : Prop, P \/ (P -> False)', 'P, Q : Prop' [Sat Dec 2 15:38:19 2017] I can't destruct H [Sat Dec 2 15:38:44 2017] destruct (H P)? [Sat Dec 2 15:39:13 2017] oh, isn't that an axiom? (excluded middle) [Sat Dec 2 15:39:17 2017] Yes [Sat Dec 2 15:39:35 2017] Proving: excluded_middle -> peirce. [Sat Dec 2 15:39:52 2017] I don't understand parenthesis with tactics [Sat Dec 2 15:40:08 2017] (H P) means feed P into H (for the quantifier). did it work? :D [Sat Dec 2 15:40:13 2017] Yeah [Sat Dec 2 15:40:30 2017] Thanks [Sat Dec 2 15:40:32 2017] a better way to think about it: (H P) passes P as the first argument of H [Sat Dec 2 15:42:37 2017] I guess it makes sense! I have used it like this: 'destruct (f b)' where f is a function and b is a boolean [Sat Dec 2 15:42:49 2017] Tactics chapter :) [Sat Dec 2 16:38:34 2017] Okay: I need a tip on this one: 'H : forall P Q : Prop, ((P -> Q) -> P) -> P', 'P : Prop', 'HP : (P -> False) -> False' | goal: P [Sat Dec 2 16:39:41 2017] Do I have to do something similar as like time like destruct but with another tactic? [Sat Dec 2 16:45:08 2017] Steverman: wow, are you dealing with the excluded middle exercises? [Sat Dec 2 16:45:14 2017] I am [Sat Dec 2 16:45:38 2017] does... intuition solve this? [Sat Dec 2 16:45:50 2017] (I suspect that’d be cheating though) [Sat Dec 2 16:46:07 2017] Uh [Sat Dec 2 16:46:18 2017] Is that a tactic? [Sat Dec 2 16:46:21 2017] Steverman: it's all about finding the correct Q to instantiate H. [Sat Dec 2 16:46:29 2017] FalsE? [Sat Dec 2 16:46:31 2017] False* [Sat Dec 2 16:46:33 2017] sorry, yes, `intuition` [Sat Dec 2 16:46:49 2017] False is probably a good idea, yes [Sat Dec 2 16:47:38 2017] pgiarrusso: I have never heard of it [Sat Dec 2 16:47:49 2017] But yeah. it solves it :D [Sat Dec 2 16:48:02 2017] OK, so I guess it is cheating [Sat Dec 2 16:48:17 2017] Steverman: I think the non-obvious step might be that you’ll need False -> P somewhere [Sat Dec 2 16:48:34 2017] Mmmh okay [Sat Dec 2 16:49:42 2017] It looks like starting with `apply H.` might work [Sat Dec 2 16:50:21 2017] It does [Sat Dec 2 16:52:12 2017] I also think this way might work till the end — you’ll need to use `HP`, but need `P -> False` somewhere [Sat Dec 2 16:52:35 2017] I will try :) [Sat Dec 2 16:55:57 2017] I *think* though, I haven’t fully tried it [Sat Dec 2 16:56:00 2017] I am not sure if this is the correct way to solve the whole exercise. I have to prove that the 5 propositions (classical logic) are equivalent. I could do A -> B, B -> C.... etc, but I doing it like this instead: 'A <-> B', 'A <-> C', and then just proved 'excluded_middle -> peirce' [Sat Dec 2 16:56:32 2017] when I was working SF I failed that miserably [Sat Dec 2 16:56:50 2017] I suppose you can do it now :) [Sat Dec 2 16:56:56 2017] both ways are valid Steverman, it's just that you probably end up doing more work by proving equivalences [Sat Dec 2 16:57:19 2017] Proving A -> B -> C -> D -> E -> A is 5 implications, while A <-> B <-> ... <-> E -> A is 9 implications [Sat Dec 2 16:57:43 2017] Oh great... my TA suggested the latter [Sat Dec 2 16:58:04 2017] I mean, maybe the point is to make you work on your proving skills, I don't know x) [Sat Dec 2 16:58:28 2017] Cypi: oh... it's not like that [Sat Dec 2 16:58:33 2017] It's from A only [Sat Dec 2 16:58:56 2017] Ah right, star-like. Well, it's still 8 implications, but you're right, it's noticeably different [Sat Dec 2 16:59:12 2017] Well here is his wording: You could either: [Sat Dec 2 16:59:14 2017] - Show that A -> B, B -> C and C -> A [Sat Dec 2 16:59:16 2017] - Show that A <-> B and A <-> C [Sat Dec 2 17:05:59 2017] Got it :) [Sat Dec 2 17:26:19 2017] pgiarrusso: I am intrigued by 'intuition'. Is it like auto, but better? I never used auto myself. [Sat Dec 2 17:28:58 2017] intuition is not like auto. it's closer to firstorder. [Sat Dec 2 17:46:30 2017] It turns 'H: (P -> False) /\ (Q -> False) -> False' into 'H0 : (P -> False) -> (Q -> False) -> False' [Sat Dec 2 18:28:19 2017] Steverman: the “Tactics” section of the reference manual can be rather readable for a reference: https://coq.inria.fr/refman/tactics.html#sec423 [Sat Dec 2 18:28:33 2017] but TL;DR. once you merge the descriptions of `intuition` and `tauto` [Sat Dec 2 18:28:46 2017] Oh okay [Sat Dec 2 18:28:56 2017] you learn that `intuition` is a decision procedure for intuitionistic propositional calculus [Sat Dec 2 18:29:11 2017] I also recommend the PDF version of the reference manual [Sat Dec 2 18:29:34 2017] Easier to search? [Sat Dec 2 18:29:50 2017] simply because the TOC of chapter 8 goes one level deeper and shows the actual tactics :-) [Sat Dec 2 18:30:00 2017] Yeah :D [Sat Dec 2 18:30:06 2017] peirce <-> de_morgan_not_and_not is hard for me [Sat Dec 2 18:30:38 2017] https://coq.inria.fr/refman/tactic-index.html if you need an index of tactics, pgiarrusso [Sat Dec 2 18:31:03 2017] Cypi: no, I need a *directory* of tactics sorted by goal :-) [Sat Dec 2 18:31:15 2017] by category, whatever [Sat Dec 2 18:31:22 2017] Steverman: wait, you’re showing that *pierce* is equivalent to the others? [Sat Dec 2 18:31:31 2017] isn’t pierce the weirdest? [Sat Dec 2 18:31:37 2017] at least, it is for me [Sat Dec 2 18:31:41 2017] I have no intuition about it [Sat Dec 2 18:31:45 2017] Uhm [Sat Dec 2 18:31:53 2017] Already did: peirce <-> double_negation_elimination. [Sat Dec 2 18:31:57 2017] No going back! [Sat Dec 2 18:32:37 2017] you can go back, just switch to double_negation_elimination as the first step for everything else :-) [Sat Dec 2 18:32:45 2017] *if* that one is easier for you [Sat Dec 2 18:32:56 2017] I could yeah :) [Sat Dec 2 18:33:08 2017] (it is for me, but it’s a personal choice) [Sat Dec 2 18:33:25 2017] Quick question... how do I remember the H I destruct? [Sat Dec 2 18:33:55 2017] Steverman: do either remember or pose (H1 := H) help? [Sat Dec 2 18:34:03 2017] (I forget the `remember` syntax) [Sat Dec 2 18:34:12 2017] Oh right.. remember to remember :D [Sat Dec 2 18:34:42 2017] But it's introduced in the next chapter [Sat Dec 2 18:34:51 2017] Not sure if I should use it then [Sat Dec 2 18:35:14 2017] I only use tacics I learnt from start to the chapter I am in. [Sat Dec 2 18:35:40 2017] Steverman: destruct term eqn:myEquation too perhaps? [Sat Dec 2 18:36:30 2017] Need a fully applied argument. [Sat Dec 2 18:37:22 2017] pgiarrusso: for the intuition about Peirce one, would it be easyer if it said `forall P, (~P -> P) -> P`? [Sat Dec 2 18:37:28 2017] easier* [Sat Dec 2 18:40:12 2017] I have no idea what that error is [Sat Dec 2 18:42:08 2017] Oh well, I shouldn't use it anyway [Sat Dec 2 18:42:57 2017] Steverman: `destruct (term) eqn:myEquation` probably [Sat Dec 2 18:43:42 2017] I think it’s an achievement of the ML world to confuse so many people on parsing issues with their grammars and error messages :-| [Sat Dec 2 18:46:10 2017] (but I’m biased because I’m among the confused people) [Sat Dec 2 18:46:27 2017] :D [Sat Dec 2 18:46:43 2017] Yeah, I will switch to double_negation [Sat Dec 2 18:47:54 2017] Did you find peirce -> double_negation easier, or double_negation -> peirce? [Sat Dec 2 18:48:55 2017] Cypi: uh, good point [Sat Dec 2 18:48:56 2017] I had to ask for the tip :P [Sat Dec 2 18:49:23 2017] apply (H P False) [Sat Dec 2 18:49:52 2017] Hmm, I don't know [Sat Dec 2 18:50:11 2017] Steverman: shoot-out if that was meant as a Memento quote :-) [Sat Dec 2 18:50:25 2017] The movie? [Sat Dec 2 18:50:34 2017] It wasn't :( [Sat Dec 2 18:50:45 2017] It's a great movie thoug [Sat Dec 2 18:50:47 2017] j [Sat Dec 2 18:50:49 2017] though* [Sat Dec 2 18:52:24 2017] It's a criteria like any other, but if `A -> B` felt easier to me than `B -> A`, then I would think that A is "stronger" (even though they are equivalent) than B [Sat Dec 2 18:52:31 2017] so it should make proofs easier by starting from A [Sat Dec 2 18:52:36 2017] but really, it's nothing precise [Sat Dec 2 18:52:59 2017] It was definitely shorter to write [Sat Dec 2 18:53:08 2017] By... 3 tactics [Sat Dec 2 18:53:32 2017] Actually much more [Sat Dec 2 18:53:59 2017] apply with parenthesis is still icky for me [Sat Dec 2 18:54:22 2017] It's like the statement I wrote above, `forall P, (~P -> P) -> P`. It's just Peirce instantiated with (Q := False), so clearly Peirce is at least as strong and any proof you can do with (Q := False), you can easily do with Peirce. [Sat Dec 2 18:54:45 2017] But you can prove that both statements are equivalent of course, so in the end it's a matter of taste [Sat Dec 2 18:55:06 2017] anyway, I'm just nitpicking x) [Sat Dec 2 18:56:56 2017] https://gist.githubusercontent.com/Steverman/a0e0ffe1efee9d6f501fefd84f8369e1/raw/433ea65873362a4d9909d87c71e6bc56c9224752/gistfile1.txt [Sat Dec 2 18:57:26 2017] Works if I use 'left' first [Sat Dec 2 18:58:43 2017] Steverman: since your hypotheses are in fact symmetric, it seems using `right` first should work as well (not sure the *tactics* would be as easy, but the proof is the same) [Sat Dec 2 18:59:32 2017] Steverman: but indeed, using an introduction form for the goal is often not a bad thing to try :-) [Sat Dec 2 19:03:28 2017] Steverman: are you saying that you managed to finish your proof after using `left`? [Sat Dec 2 19:04:20 2017] Nooo [Sat Dec 2 19:04:22 2017] :D [Sat Dec 2 19:04:31 2017] Alright x) [Sat Dec 2 19:04:32 2017] Nevermind [Sat Dec 2 19:04:50 2017] Just to explain why I was suspicious [Sat Dec 2 19:05:31 2017] The only thing you know in your hypothesis which tells you something about P and Q is `~(~P /\ ~Q)`. Nothing strange with this hypothesis, we know that it should be equivalent to `P \/ Q` in a classical context [Sat Dec 2 19:05:54 2017] If you were able to finish your proof after starting with `left`, it would mean that from this simple hypothesis, you could, _always_ prove P [Sat Dec 2 19:06:27 2017] and as pgiarrusso was saying, since everything is symmetric, basically you could also always prove Q [Sat Dec 2 19:06:43 2017] Oh okay [Sat Dec 2 19:06:56 2017] So, in the end, from your proof, you could prove `P \/ Q -> P /\ Q`, which is clearly suspicious, even with classical logic [Sat Dec 2 19:07:37 2017] This was a long way of saying: unless you've done something special to distinguish P and Q, there is no reason you should be able to choose between them [Sat Dec 2 19:07:48 2017] so starting with `left` or `right` probably should not work [Sat Dec 2 19:07:49 2017] Right [Sat Dec 2 19:07:58 2017] Steverman: ah, this is the second time you write “works” and I read it as “I can get to Qed.” [Sat Dec 2 19:08:20 2017] (while Cypi just wrote “work” as “you can finish the proof”) [Sat Dec 2 19:08:48 2017] Right, it just means I can apply the tactic [Sat Dec 2 19:10:34 2017] Also, I'm sorry, despite my "rant" about peirce vs double_negation, for this proof it's probably easier to go through double_negation :p . Now I'm going to shut up, sorry x) [Sat Dec 2 19:11:00 2017] Yeah.. why make it harder [Sat Dec 2 19:13:54 2017] Cypi: I haven’t seen a rant [Sat Dec 2 19:14:30 2017] in fact, you taught us that to use Pierce, we should often think of taking Q := False before going on :-) [Sat Dec 2 19:14:38 2017] so thanks ;-) [Sat Dec 2 19:15:13 2017] Even with this proof? [Sat Dec 2 19:16:09 2017] Ohhh.. I have to lookup apply [Sat Dec 2 19:18:09 2017] apply () is the same as apply with? [Sat Dec 2 19:19:00 2017] hmm, `with` is just a way to specify which value should be bound to some binders in the term you are applying [Sat Dec 2 19:19:07 2017] Steverman: you mean `apply ($something)`? [Sat Dec 2 19:19:09 2017] Steverman: similar yeah, in that it allows you to specify the arguments to the theorem you're applynig. [Sat Dec 2 19:19:18 2017] pgiarrusso: yes [Sat Dec 2 19:19:31 2017] So in the case of `peirce : forall (P Q : Prop), ((P -> Q) -> P) -> P`, doing `apply (H P False)` and `apply H with (P := P) (Q := False)` would be the same [Sat Dec 2 19:19:48 2017] +1 to Cypi, good example [Sat Dec 2 19:19:48 2017] Steverman: but apply () is really just apply without the with! You just construct a new theorem to apply by partially applying it. [Sat Dec 2 19:20:11 2017] Oh okay [Sat Dec 2 19:20:12 2017] You should be able to use apply (blah x y) with (z:=something) [Sat Dec 2 19:20:14 2017] The advantage of "with" can be that you don't have to specify the position of the binder you are referring to. You can refer to it by its name [Sat Dec 2 19:20:21 2017] ^^^ [Sat Dec 2 19:20:35 2017] so `apply f with ...` is just a syntax for “named function arguments” when calling `f` [Sat Dec 2 19:20:49 2017] So if you know that Coq will be able to infer the first argument of H, you can write `apply (H _ False)`, but you can also write `apply H with (Q := False)` and it should be enough [Sat Dec 2 19:20:56 2017] Cypi: although, you can use holes if you only want to supply the third argument of- [Sat Dec 2 19:21:04 2017] Yep :) [Sat Dec 2 19:21:05 2017] Yeah, I tried that [Sat Dec 2 19:21:09 2017] Got the same [Sat Dec 2 19:21:15 2017] Yup, but then when you add an argument to your lemma, you need add underscores everywhere :p [Sat Dec 2 19:21:30 2017] Cypi: very good point :). [Sat Dec 2 19:21:38 2017] and of course if you change the name of your argument, you need to change the name in every "with", both ways have pros and cons, as often [Sat Dec 2 19:21:39 2017] I was actually more explicit [Sat Dec 2 19:21:47 2017] instead of underscore [Sat Dec 2 19:21:53 2017] But I can see it can get tedious [Sat Dec 2 19:22:15 2017] for now being explicit is good [Sat Dec 2 19:22:31 2017] Cypi: mmmm. You might be able to use with (1:=blah) or something for the first argument? Seems like a very Coq thing, but I'm not sure that actually works. [Sat Dec 2 19:22:50 2017] (1:=...) should refer to the first "non-dependent" hypothesis [Sat Dec 2 19:23:02 2017] oh my gosh, numbers [Sat Dec 2 19:23:02 2017] (which is usually the first unnamed one (usually, not always)) [Sat Dec 2 19:23:18 2017] who thought they’re a good idea? [Sat Dec 2 19:23:19 2017] So in this case you can't refer to Q by a number [Sat Dec 2 19:24:06 2017] also, where do you learn what they mean, I couldn’t make heads or tails of the reference manual there... hm, should ask that when I have a problem in front of me... [Sat Dec 2 19:24:36 2017] pgiarrusso: there's some info in CPDT on them. [Sat Dec 2 19:25:59 2017] It makes heavy use of them with all of the tactics like induction. [Sat Dec 2 19:33:41 2017] OK, now I remember my question: how does `rewrite $term at $occurrences` work? [Sat Dec 2 19:34:09 2017] the manual (https://coq.inria.fr/refman/tactics.html#sec423) points to `pattern` [Sat Dec 2 19:34:22 2017] weirdly. That's the best I can do on this question, sorry, I never quite understood myself x) [Sat Dec 2 19:34:49 2017] thanks [Sat Dec 2 19:35:08 2017] moral support is already great [Sat Dec 2 19:35:28 2017] I often have `rewrite term at 1` work but `rewrite term at 2` not work [Sat Dec 2 19:35:38 2017] even when there *are* two occurrences [Sat Dec 2 19:36:26 2017] in a wonderful touch, the manual says “Occurrences are located from left to right.”, but it does NOT say if the numbering starts at 0 or 1 [Sat Dec 2 19:36:43 2017] I think this is due to a weird thing where rewrite will find the first occurrence, instantiate your $term accordingly (if your $term starts with `forall ..., ...`), and then with this instantiation it won't match your second occurrence [Sat Dec 2 19:36:44 2017] or even something else, dunno, like -2 [Sat Dec 2 19:36:52 2017] but sometimes experience contradicts this, so really, I don't kno [Sat Dec 2 19:36:53 2017] w [Sat Dec 2 19:37:09 2017] wait. a. second. [Sat Dec 2 19:37:20 2017] Don't take my word for it on this one [Sat Dec 2 19:37:25 2017] why would rewrite do that if I only want to rewrite the 2nd instance? [Sat Dec 2 19:37:28 2017] no problem [Sat Dec 2 19:37:40 2017] To find the 2nd instance, it needs to find the first one, first [Sat Dec 2 19:38:00 2017] sure, but not to do instantiation, one would hope [Sat Dec 2 19:38:11 2017] one would hope. I don't know :) [Sat Dec 2 19:38:44 2017] ohhhh wait, maybe it needs to do unification, and unification uses unification variables, and the sensible implementation for them is imperative, and but this thing might be using backtracking... [Sat Dec 2 19:38:59 2017] OK, I refuse to believe this might be a bug, but I would not be surprised [Sat Dec 2 19:39:05 2017] why, $deity, why [Sat Dec 2 19:39:10 2017] [Sat Dec 2 19:40:13 2017] (and then people ask why somebody would use Agda instead of dealing with tactics) [Sat Dec 2 19:40:25 2017] OK, I promise this is for real [Sat Dec 2 19:40:50 2017] You can always ignore tactics and just write terms, or use only refine x) [Sat Dec 2 19:44:21 2017] Cypi: but I can’t do that without holes [Sat Dec 2 19:44:28 2017] hence refine [Sat Dec 2 19:44:33 2017] uh [Sat Dec 2 19:44:43 2017] (or I misunderstood what you just meant) [Sat Dec 2 19:44:44 2017] and without dependent pattern matching (though Sozeau might have me covered) [Sat Dec 2 19:44:55 2017] you’re right, refine *is* relevant [Sat Dec 2 19:45:07 2017] Equations will be coming for the general public consumption at some point x) [Sat Dec 2 19:45:27 2017] Cypi: you’re confirming it’s not really ready yet? [Sat Dec 2 19:46:04 2017] I'm not confirming anything. You can already use it, it will do what's written on the box. But there might still be some quirks and bugs, and there is still work we want to do on it. [Sat Dec 2 19:46:42 2017] Cypi: “we”? It’s good to know people working on Coq are in the same boat [Sat Dec 2 19:47:35 2017] anyway, the truth is that I might be more productive in Coq than in Agda right now [Sat Dec 2 19:47:39 2017] I'm a PhD student of Sozeau, hence the "we". He's still the main developer but I've been working on some parts of Equations. [Sat Dec 2 19:48:01 2017] well, good luck! [Sat Dec 2 19:48:06 2017] thanks :) [Sat Dec 2 20:29:01 2017] Oh well.... I went with peirce anyway [Sat Dec 2 20:29:11 2017] I only need: peirce <-> implies_to_or [Sat Dec 2 21:24:43 2017] 'H : forall P Q : Prop, (P -> Q) -> (P -> False) \/ Q', 'P, Q : Prop', 'HPQP : (P -> Q) -> P' | Goal: P [Sat Dec 2 21:25:34 2017] I stuck on this [Sat Dec 2 21:26:25 2017] I'm* [Sat Dec 2 21:32:54 2017] Hmm, I think there are two keys uses of H in this proof [Sat Dec 2 21:33:06 2017] one of them is to translate the implication given by HPQP to a disjunction [Sat Dec 2 21:33:17 2017] the other one is to decide whether P is true or false [Sat Dec 2 21:34:52 2017] Uff [Sat Dec 2 21:36:04 2017] I'm wrong actually, you only need one. So scratch what I just said: you can use H to have the exact same goal, but with an extra hypothesis that has type ` ~ P ` [Sat Dec 2 21:36:09 2017] from this it should be easy [Sat Dec 2 21:36:31 2017] Thanks for the tip :) [Sat Dec 2 21:36:36 2017] I'll try it [Sat Dec 2 21:58:02 2017] Huh, not sure what you really meant [Sat Dec 2 21:59:33 2017] I used 'intros. destruct (H P P)' it works (to QED :D) [Sat Dec 2 22:00:25 2017] When you do `destruct (H P P)`, in one branch you get `P` (which you can use trivially to prove the goal), and in the other branch you get `~P`, which is what I meant [Sat Dec 2 22:01:32 2017] https://gist.github.com/Steverman/3e8c7249f7524a133472bf71404354ef [Sat Dec 2 22:02:11 2017] I see it onw [Sat Dec 2 22:02:13 2017] now* [Sun Dec 3 09:31:50 2017] This is more of a Company Coq question, but I'd love to somehow annotate my .v file with something that tells Company Coq to render some given text with some particular symbols. [Sun Dec 3 09:32:19 2017] In particular, I want my inductive constructor Iota to render as a nice little iota. I was hoping that Company Coq had a feature for adding custom prettifications. [Sun Dec 3 09:32:22 2017] Does anyone know? [Sun Dec 3 10:44:32 2017] I suspect you want to do that by writing it as an iota, not by telling the ide to translate [Sun Dec 3 10:58:30 2017] dh`: You mean using the Unicode iota character as an identifier? [Sun Dec 3 11:00:00 2017] yeah. [Sun Dec 3 11:00:13 2017] you can definitely do that. [Sun Dec 3 11:00:19 2017] Hmm. :/ [Sun Dec 3 11:00:32 2017] (although I've had problems with coqide converting all unicode characters to '?') [Sun Dec 3 11:01:29 2017] Not the worst idea, but seems maybe problematic for other users who might have a hard time typing ι. [Sun Dec 3 11:02:27 2017] I'm using Company Coq (thus emacs) not coqide, so containing a unicode character isn't the worst, but still seems like a potentially problematic solution. [Sun Dec 3 11:03:07 2017] coqide is supposed to support it, it's just the usual problems with unicode on unix [Sun Dec 3 11:03:51 2017] (that is, typically everything works until programs try to start supporting unicode explicitly) [Sun Dec 3 11:03:59 2017] dh`: aren’t we all on UTF-8 now? Input methods, on the other hand... [Sun Dec 3 11:04:30 2017] I suspect installing Agda-mode in emacs just for this might be worth it... [Sun Dec 3 11:04:43 2017] you'd think [Sun Dec 3 11:04:59 2017] Still, I think cq1’s idea can be done [Sun Dec 3 11:05:12 2017] Spacemacs definitely shows exists as \exists [Sun Dec 3 11:05:21 2017] oh, another way, try using a Notation? [Sun Dec 3 11:05:26 2017] I think the emacs lingo for this might be font lock [Sun Dec 3 11:05:56 2017] pgiarrusso: Does Spacemacs do that *without* Company Coq? [Sun Dec 3 11:06:27 2017] font lock is about displaying multiple fonts and font styles and colors [Sun Dec 3 11:06:31 2017] less about characters [Sun Dec 3 11:06:32 2017] afaicr [Sun Dec 3 11:07:15 2017] Or is it fortification? Anyway, you’ll need the right name for this sort of thing to google for the solution [Sun Dec 3 11:07:41 2017] A custom prettification really seems like the lowest burden solution. I can keep my file as 7-bit ASCII (with all the entailed benefits of making it easier to edit for most people), and still have it render nicely. [Sun Dec 3 11:07:55 2017] cq1 it’s with the Coq layer on the devel branch, that includes company-Coq + proof-general + not sure what stuff [Sun Dec 3 11:08:24 2017] cq1: I agree that’s a valid concern, especially in the Coq world [Sun Dec 3 11:09:10 2017] (In contrast to Agda, but Agda tools give better support for math Unicode input) [Sun Dec 3 11:11:55 2017] cq1 https://emacs.stackexchange.com/a/36156/2087 with proof general [Sun Dec 3 11:12:39 2017] Where can I get info about how Coq decides if an argument is decreasing or not? [Sun Dec 3 11:16:05 2017] 1. Unfold stuff. 2. See whether arguments of recursive calls come from pattern matching parameters of inductive types at the same position...? [Sun Dec 3 11:16:34 2017] pgiarrusso: Cool, seems useful. I wonder if this is compatible with Company Coq... [Sun Dec 3 11:17:50 2017] cq1: either of us could check the Spacemacs layer, though probably we have the same valid reasons for not doing it [Sun Dec 3 11:19:15 2017] cq1 but I mean, isn’t company-Coq required to work with proof general? I’d just try and/or ask there; linking to a stackexchange was also a hint ;-) [Sun Dec 3 11:34:11 2017] pgiarrusso: Yeah, that seems to work fine for me. Thanks for the link. [Sun Dec 3 11:42:39 2017] :-) [Sun Dec 3 12:49:49 2017] How fast growing a function nat -> nat can one actually define in Coq? [Sun Dec 3 12:53:55 2017] You can define the Ackermann function in Coq, cq1. Does that help answering your question? [Sun Dec 3 12:54:01 2017] (I don't know much about computability) [Sun Dec 3 12:56:37 2017] Cypi: That puts a nice lower bound on it, thanks. [Sun Dec 3 13:04:22 2017] cq1: that's actually a pretty hard question; you can certainly define *much worse* [Sun Dec 3 13:05:26 2017] Ackerman is system-T definable, so it is actually kind of easy, as in Peano Arithmetic-easy to be precise [Sun Dec 3 13:07:28 2017] and Coq is strong enough to show normalization of system F, so you should have everything that is definable in second-order arithmetic, which should include all sorts of length of hydra battle or length of Goodstein sequences [Sun Dec 3 13:09:28 2017] then I'm not an expert either, but these issues are also linked to consistency strength, which I think are not so well-known for Coq, beyond the (Coq + EM) at type n+1 ⟹ Cons of ZF + n inaccessible cardinals by bruno barras' work [Sun Dec 3 13:11:09 2017] so my guess is that a quick answer to your question is mostly "horribly big" and depends whether or not you assume further axioms [Sun Dec 3 13:11:30 2017] darktenaibre: Thanks, this is very helpful. [Sun Dec 3 13:12:34 2017] This is also the sort of answer I was looking for. [Sun Dec 3 13:13:07 2017] Do you have a citation on the Bruno Barras work? [Sun Dec 3 13:16:55 2017] Can anyone point me to a formalization of indexed set families? [Sun Dec 3 13:20:07 2017] cq1: not sure how relevant it is for the specifics of your question as I'm not an expert on definability of fast-growing recursive functions tho; and I do not have a specific citation in mind actually, I am mostly aware of his big formalization efforts, there are probably more details on his webpage http://www.lix.polytechnique.fr/~barras/ [Sun Dec 3 13:21:12 2017] I suppose this would be the most relevant paper https://jfr.unibo.it/article/view/1695, I haven't read it recently, maybe skimmed through it a couple years ago [Sun Dec 3 13:23:37 2017] (and also, as with all things regarding metatheory of coq as implemented, I think no one would dare make a definite claim for an upper bound; another question of interested that was probably studied more thoroughly in the past is the same question restricted to various predicative fragments (MLTT)) [Sun Dec 3 13:25:00 2017] (in such a case, ackermann would still be one of these obvious system T-definable lower bounds, but maybe you can get upper bounds such as "definable in full second order arithmetic" or smth) [Sun Dec 3 13:43:02 2017] darktenaibre: Thanks, I'm reading this paper now. [Sun Dec 3 16:03:04 2017] Does the admit tactic work differently now in 8.6? I used to be able to do Theorem bad : False. Proof. admit. Qed. but now that's not working. [Sun Dec 3 16:05:19 2017] Now it forces you to end your proof with `Admitted.`. You can import Compat.AdmitAxiom to get the old behaviour back [Sun Dec 3 16:05:44 2017] Cypi: Hmm, that seems like a good change. Thanks. [Sun Dec 3 16:31:30 2017] I have an inductive that is basically just a trivial tree. What's the best idiom to get an equality decider on it? Optimally I'd like something very automatic. [Sun Dec 3 16:32:27 2017] hello [Sun Dec 3 16:45:07 2017] lapinot: <3 [Sun Dec 3 16:58:20 2017] i'm quite excited to be able to do a pull request on coq/coq: there is a stupid bug in coqide on 4.06.0 since now lablgtk2 has upgrade to using safe strings [Sun Dec 3 16:58:33 2017] s/upgrade/upgraded/ [Sun Dec 3 17:00:03 2017] cq1: just write it down, unless your tree has a lot of cases it's pretty easy [Sun Dec 3 17:02:23 2017] e.g. http://codepad.org/8GXPeSCH [Sun Dec 3 17:04:01 2017] lapinot: Can upgrading to safe string cause bugs? [Sun Dec 3 17:04:42 2017] dh`: I don't want propositional equality, I want boolean equality. I could do as you say, and additionally define the obvious Fixpoint, then prove correctness, but I was really hoping there was some built in mechanism to do all of this for me. [Sun Dec 3 17:05:47 2017] I don't want to just write the obvious boolean equality Fixpoint, because I could have made a dumb mistake. I can prevent this by proving it equivalent to what you wrote, but now I'm looking at 15+ lines for something that is should be totally rote. [Sun Dec 3 17:06:03 2017] oh [Sun Dec 3 17:06:05 2017] lyxia: i guess so (now strings are safe by default so unsafe behavior will crash).. [Sun Dec 3 17:06:05 2017] "There is no such builtin mechanism" is an acceptable answer. [Sun Dec 3 17:06:15 2017] you can use Tree_dec to build the boolean function for you [Sun Dec 3 17:06:31 2017] yuo'll get pretty crap code from this, but that probably doesn't matter [Sun Dec 3 17:07:04 2017] now the question is whether I can remember how [Sun Dec 3 17:07:51 2017] lapinot: I assumed it just made programs not compile [Sun Dec 3 17:08:39 2017] dh`: I guess that's not the worst. [Sun Dec 3 17:08:45 2017] lyxia: ha! yeah, i was being unprecise but that's what i meant! [Sun Dec 3 17:10:23 2017] dh`: That's actually a pretty okay solution, especially because I "Definition beq_tree a b := if Tree_dec a b then true else false." seems pretty trivially bug-free. [Sun Dec 3 17:10:31 2017] I guess I could accidentally swap the positions of true and false. [Sun Dec 3 17:10:45 2017] yeah but you didn't :-) [Sun Dec 3 17:11:43 2017] lapinot: ah, okay :) I guess for some value of "bug", "not compiling" counts as one. [Sun Dec 3 17:12:01 2017] dh`: I'm picturing that I've got a bunch of such inductives, and maybe I accidentally mess up for one of them. I'd really like a "MagicalVernacularThatMakesABooleanDecider my_inductive" that eliminates all such issues. [Sun Dec 3 17:12:18 2017] But I guess your solution is sufficiently non-horrific. It's still mildly horrific. [Sun Dec 3 17:13:58 2017] cq1: on your “fast growth”, would definability in System F/2nd order Peano arithmetic be relevant? [Sun Dec 3 17:14:06 2017] cq1: Coq is more powerful of course [Sun Dec 3 17:14:17 2017] it seems to me that there ought to be a nice way to get foo_dec for an arbitrary inductive [Sun Dec 3 17:14:27 2017] (at least where it's true) [Sun Dec 3 17:15:25 2017] hmm, Definition Tree_eq (a b: Tree) : bool := [Sun Dec 3 17:15:25 2017] if Tree_dec a b then true else false. [Sun Dec 3 17:15:30 2017] acts kinda weird [Sun Dec 3 17:15:38 2017] cq1: Girard’s “Proofs and Types” shows that System F can define exactly the functions that you can prove total in 2nd order Peano/Heyting arithmetic [Sun Dec 3 17:15:43 2017] oh but now i'm really sad, it has already been reported and fixed: https://github.com/coq/coq/issues/6140 .. it's just that no release happened in the meantime [Sun Dec 3 17:17:04 2017] cq1: and I suspect that should extend to bigger systems — the proof is based on a realizability model, and we know how to build those for many languages [Sun Dec 3 17:37:38 2017] given n <= m, how can I apply this hypothesis to the min/max for the goal min n m <= max n m? [Sun Dec 3 17:39:57 2017] Why do you need n <= m for min n m <= max n m? [Sun Dec 3 17:40:30 2017] I'm trying to prove forall n m : nat, min n m <= max n m for fun :D [Sun Dec 3 17:40:44 2017] right, you don't need that assumption [Sun Dec 3 17:41:08 2017] I don't need n <= m? I'm using [case (Nat.leb n m) eqn:Hn.] [Sun Dec 3 17:41:53 2017] my attempt was to use the fact that [n <= m \/ n > m] and prove by cases, by rewriting min/max defs with the current hypothesis [Sun Dec 3 17:42:10 2017] bor0: you should end up with two cases in your proof. One where n <= m and one where m <= n. Is that what you're refering to? [Sun Dec 3 17:42:20 2017] Errr. m < n [Sun Dec 3 17:42:28 2017] You know what I mean :) [Sun Dec 3 17:42:33 2017] n <= m and m > n you mean? :D [Sun Dec 3 17:42:44 2017] m > n <-> n < m :) [Sun Dec 3 17:43:11 2017] bor0: no, because that would be n <= m and n < m [Sun Dec 3 17:43:26 2017] bor0: Are you looking for something like this? https://pastebin.com/raw/ifcNfYEw [Sun Dec 3 17:44:25 2017] oh, right :D sorry [Sun Dec 3 17:44:35 2017] n <= m and m < n [Sun Dec 3 17:44:54 2017] bor0: Min n m <= max n m if n <= m or if m <= n. So you shouldn't need that as an assumption. [Sun Dec 3 17:45:15 2017] cq1, wow. I'm speechless. what does the "try" tactic do? [Sun Dec 3 17:45:41 2017] my proof attempt already has 3 lemmas and 4 LoC theorem :D [Sun Dec 3 17:45:44 2017] bor0: attempts the tactic, and doesn't complain if it fails. [Sun Dec 3 17:45:56 2017] bor0: it's useful in conjunction with ';' [Sun Dec 3 17:46:09 2017] sorry to re-ask this, but is there a formalization of indexed set families handy someplace? [Sun Dec 3 17:46:17 2017] ahhh, min_l and max_r is the magic here [Sun Dec 3 17:46:31 2017] *runs Coq Check on them* [Sun Dec 3 17:46:35 2017] pgiarrusso: This seems like the sort of thing I'm looking for, but I'll have to look up these various terms more. [Sun Dec 3 17:47:26 2017] haha, those are exactly what I had as axioms for my theorem: [Axiom a1 : forall n m : nat, n <= m -> min n m = n.] [Axiom a2 : forall n m : nat, n <= m -> max n m = m.]. cute [Sun Dec 3 17:48:00 2017] bor0: Are you trying to prove things yourself with minimal library theorems? [Sun Dec 3 17:48:25 2017] cq1 yeah it is not immediate [Sun Dec 3 17:48:29 2017] cq1, I'm doing random stuff to be honest. I just thought of this simple theorem and trying to prove it myself to increase my Coq knowledge. I'm at chapter 4 of Software Foundations Vol. 1 [Sun Dec 3 17:49:03 2017] so "assumption" is the same as "exact "? [Sun Dec 3 17:49:28 2017] bor0: yep! [Sun Dec 3 17:49:43 2017] It just finds the hypothesis automatically. [Sun Dec 3 17:49:55 2017] Sometimes it can't do it if the types are really complicated, though. [Sun Dec 3 17:51:40 2017] in proving [forall n m : nat, n <= m -> min n m = n.], is my original approach (considering [n <= m \/ n > m]) a good way to attack it? [Sun Dec 3 17:52:16 2017] Should be! [Sun Dec 3 17:53:51 2017] If you know n <= n, considering [n <= m \/ n > m] is [|exfalso] tho. [Sun Dec 3 17:54:01 2017] n <= m* [Sun Dec 3 17:54:39 2017] what's the difference between <= and <=? (I know the latter is nat -> nat -> bool) [Sun Dec 3 17:55:02 2017] ah, I have leb_le to re-use for my case (but still wondering how they differ) [Sun Dec 3 17:55:33 2017] bor0: It may be that you don't want spoilers, but you can prove (forall n m, min n m <= max n m) pretty readily with library theorems: https://pastebin.com/raw/Z1H5ENm5 [Sun Dec 3 17:56:01 2017] I will look at the pastebin, but I think doing it from "scratch" will probably increase my skills (at least a bit) :D [Sun Dec 3 17:57:22 2017] for example, I already tried to do [Axiom a1 : forall n m : nat, n <= m -> min n m = n.] before seeing your pastebin, which makes me proud I was on the right path :D [Sun Dec 3 17:58:05 2017] bor0: Why do you have that as an axiom? Are you intending to replace that with a proof? If so, maybe you should have it as a lemma and admit it until you're ready to go back and prove it. [Sun Dec 3 17:58:30 2017] ahhh! forgot about Admitted. it was discussed in the book. good catch! yeah my plan was to prove it later [Sun Dec 3 17:59:27 2017] cq1: the only difference is a little bit of syntax, though? [Sun Dec 3 18:00:03 2017] I think "Admitted" marks my green (status?) bar with yellow points while Axiom doesn't (might be wrong) [Sun Dec 3 18:00:26 2017] Status bar? CoqIDE? [Sun Dec 3 18:00:37 2017] yeah [Sun Dec 3 18:00:49 2017] Ah okay, I'm a PG person. [Sun Dec 3 18:00:55 2017] Chobbes: It's true. I was mostly asking to make sure bor0 wasn't thinking they had to axiomatically define min and max, or something, and intended to prove those. [Sun Dec 3 18:01:05 2017] Though, yeah, I think Admitted shows up red in PG. [Sun Dec 3 18:01:26 2017] is there a vim PG? or vim anything-Coq-related? I'm kind of struggling with CoqIDE because the key bindings are weird on OS X [Sun Dec 3 18:01:44 2017] bor0: use Evil with PG. [Sun Dec 3 18:01:45 2017] but it's good that I can go step by step, that's why I avoid the command line compiler [Sun Dec 3 18:02:03 2017] https://www.emacswiki.org/emacs/Evil [Sun Dec 3 18:02:33 2017] that's emacs right? yeah. I tried emacs a bunch of times in the past :D guess I have to give it another try [Sun Dec 3 18:02:34 2017] I know of lots of people who do this. Though, I am not one of them :). [Sun Dec 3 18:02:50 2017] bor0: PG is just an emacs plugin. [Sun Dec 3 18:03:02 2017] But you can make emacs have vim keys if you would like :). [Sun Dec 3 18:03:07 2017] ah, Evil is "vi" on emacs. guess I can try that combo :D [Sun Dec 3 18:03:29 2017] lol E"vi"l, nice [Sun Dec 3 18:04:41 2017] bor0: I'd recommend getting familiar with emacs if you're interested in stuff like Coq. A lot of modes for "esoteric" programming languages start with Emacs. [Sun Dec 3 18:05:42 2017] yeah, I noticed that. I tried Agda, Lean and a couple of others, but Coq seems best for me. I only have some Haskell experience so most of the things click but I still get stuck on some things [Sun Dec 3 18:06:15 2017] "brew install emacs" then :D [Sun Dec 3 18:06:24 2017] I'm thinking about going back to basics. Starting with SKI, then Simply Typed Lambda Calculus.... System F, and eventually Calculus of Constructions. Just to know the inner workings (and for my course). I just don't have any material for it [Sun Dec 3 18:06:37 2017] bor0: brew install emacs --with-cocoa=y probably, if I recall correctly. [Sun Dec 3 18:06:51 2017] bor0: also a lot of people like Spacemacs. [Sun Dec 3 18:07:06 2017] My lecture notes are not good neough for me, so I need to look somewhere else [Sun Dec 3 18:07:09 2017] how is it different from Emacs? (w.r.t. Coq, or in general) [Sun Dec 3 18:07:10 2017] Which is like a front end to emacs? I don't use it, but it includes some easy setup stuff, I think. [Sun Dec 3 18:07:39 2017] bor0: by default I think brew only installs the command line version. [Sun Dec 3 18:07:59 2017] Though it has been a while since I have used a mac, so I might be remembering wrong :). [Sun Dec 3 18:08:19 2017] It might also recommend adding a cask(?) or something for emacs for mac or whatever it is. [Sun Dec 3 18:08:27 2017] I'd probably listen to brew. [Sun Dec 3 18:09:04 2017] bor0: oh! Also if you do try proof general I would *strongly* recommed installing company-coq as well. [Sun Dec 3 18:09:30 2017] https://github.com/cpitclaudel/company-coq [Sun Dec 3 18:11:05 2017] thanks! I will check those out [Sun Dec 3 18:11:18 2017] Steverman, are you following a college/university course? or just self-learning? [Sun Dec 3 18:11:51 2017] university [Sun Dec 3 18:12:24 2017] ah, ok. I guess it's trickier, given time constraints etc [Sun Dec 3 18:13:24 2017] I have a coq assignment, but I have no idea how to start on it [Sun Dec 3 18:13:33 2017] Steverman: honestly if you want a teensy peek behind the curtains I would recommend going through this: http://oxij.org/note/BrutalDepTypes/ [Sun Dec 3 18:13:53 2017] Steverman, are you allowed to share the assignment? I'm just curious [Sun Dec 3 18:14:00 2017] Chobbes: Sure [Sun Dec 3 18:14:05 2017] bor0* [Sun Dec 3 18:14:06 2017] :D [Sun Dec 3 18:14:13 2017] Steverman: I've found that doing a bit of Agda (where you write out raw proof terms instead of using tactcs in Coq) enlightening. [Sun Dec 3 18:14:49 2017] Chobbes, why is that? what is "raw proof terms"? is it like _the_ lambda calculus or? [Sun Dec 3 18:14:54 2017] I can't do that with my time constraint [Sun Dec 3 18:15:27 2017] I get lost in tactics pretty fast, but that's because I am poor at formal logic [Sun Dec 3 18:15:42 2017] bor0: more or less, yeah. I mean there's still a bunch of syntactic sugar in Agda, but you get a much better sense of what a proof actually looks like in a curry-howard sense. [Sun Dec 3 18:15:56 2017] Especially with the last chapter I did [Sun Dec 3 18:16:03 2017] Chobbes, is there not a way to do that with Coq? I liked Lean because of that but I thought I'd get to that point in Coq, eventually [Sun Dec 3 18:16:21 2017] bor0: you can do this in Coq too! [Sun Dec 3 18:16:25 2017] Or, Gallina, rather. [Sun Dec 3 18:16:46 2017] But Agda is a bit cleaner and includes an axiom that makes dependent pattern matching much nicer. [Sun Dec 3 18:16:48 2017] Chobbes: I will look at it :). I need a crash course on everything [Sun Dec 3 18:17:02 2017] Programming with dependent types in Coq is... More painful. [Sun Dec 3 18:17:46 2017] Steverman, are you good with mathematical proofs (on paper)? [Sun Dec 3 18:17:58 2017] Not really [Sun Dec 3 18:18:25 2017] bor0: https://www.dropbox.com/s/xfv0gdysfygth7l/projects.pdf?dl=0 [Sun Dec 3 18:18:35 2017] Steverman: depending on what you mean by "lost in tactics" it's possible that proof tree could be a little helpful for you? [Sun Dec 3 18:18:42 2017] ignoring your time constraint https://www.amazon.com/How-Prove-Structured-Approach-2nd/dp/0521675995 this really helped me with that part. another good one (free) alternative is http://people.uleth.ca/~dave.morris/books/proofs+concepts.html [Sun Dec 3 18:19:35 2017] Chobbes: if it's the ones with lines, then the part I am struggling with is mostly the symbols and definitions [Sun Dec 3 18:19:56 2017] Is it bad form to recommend Software Foundations for learning proofs? :P [Sun Dec 3 18:20:16 2017] Steverman: yeah, it sort of shows you where you are in the tree structure of the proof. [Sun Dec 3 18:20:32 2017] SKI was easy to understand [Sun Dec 3 18:20:38 2017] Which can be a little helpful for keeping track of where you were. [Sun Dec 3 18:21:16 2017] as far as I see it does assume knowing proofs a bit (at least Vol. 1). it doesn't have kind of the "total newbie" exercises like HTPI (prove A, A -> B .:. B, show why it holds with tables), etc [Sun Dec 3 18:21:31 2017] Steverman: for definitions and symbols -- don't know what would be most helpful. Probably unfolding things / searching / printing in Coq? [Sun Dec 3 18:21:47 2017] Lambda calculus got tricky, and may need more reading. Got totally lost then types can have kinds... like types for types? [Sun Dec 3 18:22:01 2017] This is outside of coq :) [Sun Dec 3 18:22:32 2017] We pretty much got handed 2 lecture notes and that's it [Sun Dec 3 18:22:47 2017] Weekly coq assignments. Usually whole chapters from SF [Sun Dec 3 18:22:56 2017] including optional [Sun Dec 3 18:23:29 2017] Steverman: oooh, Aarhus? [Sun Dec 3 18:23:34 2017] Yes [Sun Dec 3 18:24:03 2017] Stop gooling my lecturer :D [Sun Dec 3 18:24:05 2017] googling* [Sun Dec 3 18:24:13 2017] types do have types in Coq too I think. e.g. Inductive bool : Set. [Sun Dec 3 18:24:14 2017] Cool :). I met a bunch of people from there at the DeepSpec Summer School (coq thing). [Sun Dec 3 18:24:27 2017] bor0: yep! [Sun Dec 3 18:24:50 2017] I don't know too much about it but there's this type hierarchy. [Sun Dec 3 18:24:51 2017] I actually took this course because of a lecturer. But he left! [Sun Dec 3 18:25:07 2017] The best lecturer I had [Sun Dec 3 18:25:12 2017] Steverman: :C [Sun Dec 3 18:25:17 2017] yeah, I think type hierarchy is for Russel's paradox (I remember reading this somewhere, and it also might have been Software Foundations Vol 1. too, or maybe Mike Nahas tutorial) [Sun Dec 3 18:25:43 2017] Russell's* [Sun Dec 3 18:25:54 2017] bor0: yeah. It's to prevent paradoxes and whatnot. [Sun Dec 3 18:25:59 2017] Then we got a new guy. Every lecture is just him and coq. I don't get much out of it [Sun Dec 3 18:26:19 2017] But it's this guy: https://www.nature.com/articles/432790b [Sun Dec 3 18:27:08 2017] Steverman: are you a grad / undergrad? [Sun Dec 3 18:27:11 2017] grad [Sun Dec 3 18:27:15 2017] I'd say pre-requisites for Coq is knowledge with at *least* one FP language (pref. Haskell) and math proofs on paper. this is from personal experience, and doesn't mean it has to be done that way but I _think_ I get what's going on [Sun Dec 3 18:27:17 2017] well.. [Sun Dec 3 18:27:23 2017] Studying masters.. so not yet grad? [Sun Dec 3 18:28:56 2017] I am not familiar with undergraduate/graduate as it's a North American thing [Sun Dec 3 18:29:01 2017] Steverman: ah, okay. I was wondering if you would know a couple PhD students -- Lau and Marit. Maybe you wouldn't then? [Sun Dec 3 18:29:05 2017] + few others [Sun Dec 3 18:29:22 2017] Lau [Sun Dec 3 18:29:27 2017] My old TA [Sun Dec 3 18:29:41 2017] The bearded guy? [Sun Dec 3 18:29:46 2017] Steverman: yeah! :) [Sun Dec 3 18:30:17 2017] He was TA for my "regularity" and automata course [Sun Dec 3 18:30:37 2017] intro to formal language I guess? [Sun Dec 3 18:30:39 2017] Steverman: Lau is clairvoyant. They predicted that I would end up in a wheel chair at DSSS17... And I broke my ankle a few days later. [Sun Dec 3 18:30:56 2017] :D [Sun Dec 3 18:31:12 2017] Marit.. hmmmm hmm [Sun Dec 3 18:31:15 2017] bor0: Haskell + proofs definitely help! Though, I would say that Coq can also help you learn Haskell ;) [Sun Dec 3 18:31:19 2017] Oh her [Sun Dec 3 18:31:33 2017] We started at the same time [Sun Dec 3 18:32:01 2017] Chobbes, yep :D I don't negate that. my road was starting with Haskell first (I heard the hype from some friends) but then I learned about Coq (which is much more powerful than Haskell) so decided to give it a go :) [Sun Dec 3 18:32:18 2017] bor0: one thing is that Coq tends to be a lot more... Tame than Haskell. [Sun Dec 3 18:32:42 2017] I guess she started on her PhD on top of her masters degree [Sun Dec 3 18:32:49 2017] Seems to be a trend here [Sun Dec 3 18:33:12 2017] Chobbes, so math proofs being the only pre-requisite? or do you think SF handles that well? [Sun Dec 3 18:33:33 2017] Like you can get into some pretty complicated types and magical category theory when diving into Haskell right away. You usually don't have that problem in Coq, I find. [Sun Dec 3 18:34:00 2017] yeah, especially the monads stuff. I guess it's because Haskell is more about IO than Coq? [Sun Dec 3 18:34:07 2017] (I might be wrong, as I still haven't done any Coq IO) [Sun Dec 3 18:34:43 2017] I am still worried about this course, and may have to drop it [Sun Dec 3 18:34:46 2017] bor0: I keep wanting to teach people math with Coq, so I dunno. It is one of the goals of SF to handle that relatively well, and I think it does a decent job? But I dunno. Different things work for different people. [Sun Dec 3 18:36:21 2017] bor0: I think that's definitely part of it, but another part might just be that the community is smaller so you have fewer libraries that you might want to use that force you to learn ever more type wizardry fast. Plus Coq has had really good beginner resources like SF for a while. Haskell was lacking for a time. [Sun Dec 3 18:37:30 2017] Steverman: hopefully not :(. I do find that it takes a couple passes for Coq to make sense sometimes. Also if a proof isn't coming along it's very good to take a break, maybe try to solve the thing on paper. [Sun Dec 3 18:37:31 2017] To be honest. If you don't know anything about the inner workings, proofs (or poor at it), then Coq is just a puzzle solving game. That is what I heard from most students here [Sun Dec 3 18:37:34 2017] yeah, agree. LYAH was really good tho for beginners [Sun Dec 3 18:38:39 2017] I want to do it on paper, but I lack the proper foundation to be able to :) [Sun Dec 3 18:39:01 2017] bor0: LYAH is good for encouraging people to learn Haskell, but I think overall it's not the best due to a lack of exercises, some shaky monad / applicative / functor chapters, and out of date sections. [Sun Dec 3 18:40:07 2017] Steverman: :(. Well, if you have particular questions maybe I or somebody else in here can help you! [Sun Dec 3 18:40:34 2017] This was supposed to be an introduction course, but oh boy he skipped the earlier parts so quick [Sun Dec 3 18:40:49 2017] Steverman: that's how it always goes :P. [Sun Dec 3 18:41:33 2017] Uni life :( [Sun Dec 3 18:42:15 2017] Yep! But it's usually a lot better when you sit down and get a chance to go through it. Though, obviously that's not without challenges. [Sun Dec 3 18:42:42 2017] Steverman, I think the fastest way to get to it is to read up on two-column proofs, and read some of the rewrite (inference) rules https://en.wikipedia.org/wiki/List_of_rules_of_inference#Table:_Rules_of_Inference [Sun Dec 3 18:42:42 2017] Yeah, that's why I asked for materials :D [Sun Dec 3 18:42:53 2017] I have to start with basics [Sun Dec 3 18:43:17 2017] I remember these from my logic course [Sun Dec 3 18:43:23 2017] two-column proofs is basically when you try to prove something and on the left column you do the actual rewrite and on the right you explain by which rule it is [Sun Dec 3 18:43:47 2017] when doing proofs I think it all boils down to rewriting. both in Coq and manually [Sun Dec 3 18:44:09 2017] rewriting/substitution [Sun Dec 3 18:44:12 2017] I used natural deduction [Sun Dec 3 18:44:36 2017] But I remember them as boxes [Sun Dec 3 18:44:55 2017] boxes? or do you mean tables? [Sun Dec 3 18:45:02 2017] Thinking about proofs in terms of rewriting is a bad idea. [Sun Dec 3 18:45:13 2017] whoops. why's that, Vivi_? [Sun Dec 3 18:46:04 2017] It is how it works in proof assistants, but "natural" proofs rarely if ever are expressed in terms of steps that "compose" a proof. [Sun Dec 3 18:46:05 2017] No, actual boxes: https://www.researchgate.net/profile/Bernard_Sufrin/publication/2650380/figure/fig1/AS:341829011689481@1458509795515/Figure-6-a-small-proof-in-the-above-encoding-of-natural-deduction.png [Sun Dec 3 18:46:12 2017] When I did natural deduction [Sun Dec 3 18:46:21 2017] For the same reason why two column proofs are a bad idea. [Sun Dec 3 18:46:24 2017] Vivi_, by "natural" you mean "informal"? [Sun Dec 3 18:46:30 2017] yes [Sun Dec 3 18:47:04 2017] I definitely agree. I read this somewhere also in some book "now that you learned how to apply two-column proofs, forget it and never use it" :D but I think it's a good thing to explain what's going on under the hood [Sun Dec 3 18:50:23 2017] In Coq, the closest to "natural" [Sun Dec 3 18:50:37 2017] proving one can get is to adopt Adam Chlipala's style [Sun Dec 3 18:51:49 2017] (although I wouldn't recommend any of his books before you finish SF) [Sun Dec 3 18:52:28 2017] Regarding my upcoming project. There are 3 coq projects I can choose. And knowing that I am poor at this. I don't know which project I should avoid to stop myself from shooting myself in the foot [Sun Dec 3 18:54:21 2017] I suggest you go with the group approach (as far as I checked the pdf). probably easier than solo :) [Sun Dec 3 18:54:49 2017] (disclaimer: I'm (still) a Coq noob) [Sun Dec 3 18:55:31 2017] That was not the question :D. [Sun Dec 3 18:55:46 2017] Section 2 has the projects [Sun Dec 3 18:58:03 2017] I think 2-3 Trees looking doable [Sun Dec 3 18:58:05 2017] looks* [Sun Dec 3 19:09:02 2017] why is the definition of max recursive and not using comparison definitions? makes stuff a bit harder to prove? [Sun Dec 3 19:09:28 2017] well, there is probably a lemma somewhere [Sun Dec 3 19:09:46 2017] there is, but I'm trying to prove it :D Lemma my_min_l : forall n m : nat, n <= m -> min n m = n. [Sun Dec 3 19:09:51 2017] hah [Sun Dec 3 19:19:14 2017] bor0: Those comparisons are, themselves, recursive. The overall term for min/max is smaller as written as two simple nested matches. [Sun Dec 3 19:19:33 2017] ah. that makes complete sense. thank you! [Sun Dec 3 19:24:24 2017] if I have [Hn : (n =? v) = true], how can I replace n with v in the goal? [Sun Dec 3 19:29:47 2017] bor0: if you use search you should be able to find a lemma! [Sun Dec 3 19:30:02 2017] There is a n =? v = true -> n = v lemma. [Sun Dec 3 19:30:02 2017] why do I keep thinking in terms of tactics? :D [Sun Dec 3 19:30:11 2017] bor0: I don't know what structure you have equality on here, but SearchAbout ((_ =? _) = true) to find an appropriate lemma to get (n = v) then rewrite with it or subst it in. [Sun Dec 3 19:30:19 2017] Then you can rewrite as usual. [Sun Dec 3 19:30:42 2017] thank you both! [Sun Dec 3 19:52:33 2017] is it impossible to prove eta-contraction without axiom of extensionality? [Sun Dec 3 20:05:13 2017] mniip: Hmm, good question. I think so? The proof is very straight forward given functional extensionality. But without FE, I'm not sure what handles one has on a goal like ((fun x => f x) = f). [Sun Dec 3 20:05:26 2017] *the proof of eta-contraction's validity given FE [Sun Dec 3 20:06:23 2017] You can prove this trivially in Coq by eq_refl [Sun Dec 3 20:07:22 2017] eta-expansion is in the convertibility rules for Coq (but not reduction) [Sun Dec 3 20:08:20 2017] Cypi: Oh, yeah, derp. [Sun Dec 3 22:19:10 2017] Regarding Vivi_’s earlier comment on “natural” informal proofs: the “informal” proofs used in graduate math miss too many steps to be formalized in Coq, but they’re also not meant to be actual proofs [Sun Dec 3 22:19:25 2017] They’re meant to allow you to reconstruct the full argument [Sun Dec 3 22:19:51 2017] And you *have* to reconstruct it before formalizing it, early on [Sun Dec 3 22:20:08 2017] you can still formalize them, you just need more steps [Sun Dec 3 22:20:24 2017] Sure [Sun Dec 3 22:20:31 2017] and it may not be easy :-) [Sun Dec 3 22:20:58 2017] My opinion was about *learning* Coq [Sun Dec 3 22:21:31 2017] you can’t *expect* a similar level of detail :-) [Sun Dec 3 22:21:45 2017] yeah, that's not a good way to learn, unless it's math you're very familiar with [Sun Dec 3 22:22:19 2017] if you know the math too well it might be worse [Sun Dec 3 22:22:56 2017] I mean, you’ll need to decompose many more “obvious” steps [Sun Dec 3 22:24:24 2017] I utterly failed to prove the pigeonhole principle in SF—it’s so obvious to me (and I’ve used it lots) I had no clue how to approach its formal proof [Sun Dec 3 22:35:06 2017] hahaha [Mon Dec 4 00:13:47 2017] haha im also stuck in those exact places in the SF book (im new to math too :<) [Mon Dec 4 00:14:39 2017] (that whole chapter is badass though makes me not regret trying to learn coq) [Mon Dec 4 00:45:04 2017] wow we've had a lot of scroll today [Mon Dec 4 01:43:39 2017] I've got some ltac that'd doing (let x' := fresh "x" in remember x as x') but I want to follow it up with some manipulation of the new Heqx hypothesis. Is there some way to get what remember named it? [Mon Dec 4 01:45:51 2017] You can name it yourself `remember x as x' eqn:Heqx` [Mon Dec 4 01:51:47 2017] Cypi: What's the behavior if Heqx isn't fresh? [Mon Dec 4 01:52:07 2017] Also, what purpose does "as x'" serve in this case? [Mon Dec 4 01:52:35 2017] I guess I can test the former... [Mon Dec 4 01:53:25 2017] Oh, I see, sorry, I answered the purpose of "as x'" by testing. [Mon Dec 4 01:53:56 2017] Okay, and now I answered the former -- sorry I should have experimented more before asking. [Mon Dec 4 01:56:17 2017] Cypi: Thanks, that's just what I wanted. [Mon Dec 4 02:15:54 2017] why is it we can [case (Nat.eqb n v)] but not [case n = v]? [Mon Dec 4 02:17:31 2017] bor0: Because "n = v" is a Prop. [Mon Dec 4 02:17:48 2017] case works only on inductive types? [Mon Dec 4 02:18:43 2017] bor0: Think about what case is building into the current hole. It builds a match, letting you do case analysis on the constructors of a given dependent product. [Mon Dec 4 02:19:27 2017] thank you! that clears it up for me [Mon Dec 4 02:21:56 2017] bor0: This may be more basic than you're thinking. (n = v) : Prop, while (Nat.eqb n v) : bool : Set. They're different distances from a sort. [Mon Dec 4 02:21:56 2017] bor0: It's not just that (n = v) was disqualified for "not being an inductive", recall that (n = v) is notation for (eq x y), which is an inductive. [Mon Dec 4 02:22:27 2017] ow, ow [Mon Dec 4 02:23:49 2017] To put it in somewhat simplistic (crappy) terms (n = v) is a "type", while (Nat.eqb n v) is an actual value that can be destructed, and not a type (it's two down from a sort). [Mon Dec 4 02:24:56 2017] n = v being a "type", does that mean it's only useful in terms of Gallina? e.g. stuff like rev l1 = rev l2 -> l1 = l2 [Mon Dec 4 02:27:12 2017] I just printed Nat.eqb and saw it doesn't rely on eq at all. was just wondering in which cases will eq be useful, and in which other cases will eqb be useful [Mon Dec 4 02:27:53 2017] bor0: (n = v) is useful whenever you need propositional equality, which occurs all over the place. Gallina refers to the term language of Coq. [Mon Dec 4 02:31:20 2017] ok I think I was being confused by the fact that Prop is not true/false, rather provable/unprovable. I need to keep reminding myself of this. so eq is a check for provable/unprovable, while eqb is a true/false check? [Mon Dec 4 02:31:55 2017] bor0: eqb is a true/false check [Mon Dec 4 02:32:14 2017] To say that eq is a "provable/unprovable check" is drawing a false parallel to the computation that eqb performs. [Mon Dec 4 02:33:05 2017] right. ok I see. it doesn't check the value, rather the type. so it will be correct to say it's a Prop check? [Mon Dec 4 02:33:35 2017] I don't like the word "check" here -- it's not checking anything and returning something based on that check. [Mon Dec 4 02:33:47 2017] :( [Mon Dec 4 02:33:48 2017] match? [Mon Dec 4 02:33:49 2017] (x = y) simply is the proposition that x equals y. You can think of it as the type of proofs that x equals y. [Mon Dec 4 02:34:25 2017] A term t whose type is (t : (x = y)) is a proof that x = y. [Mon Dec 4 02:34:39 2017] in my happy and untyped math world, x = y was always either true/false. this is why this (as simple as it sounds) is a bit weird to me now [Mon Dec 4 02:35:25 2017] bor0: You must understand that inhabitants of Prop are types whose inhabitants are proofs of logical statements. This is key to the whole enterprise. [Mon Dec 4 02:36:08 2017] Compare what I wrote above to the eqb case. (eqb x y) is NOT a type, and thus there can be no term (t : (eqb x y)), while there can be terms (t : (eq x y)) because (eq x y) is a type. [Mon Dec 4 02:36:17 2017] They're structurally extremely different. [Mon Dec 4 02:37:10 2017] I'd like to read up on this more. I'll save your statements and re-read them. do you know if Software Foundations covers this later? or prefer a short intro/tutorial to type theory? [Mon Dec 4 02:40:13 2017] bor0: I'm not sure, I haven't read SF. This is close to the corner stones of Howard-Curry and the BHK interpretation. That (x : p : Prop) means that p is a logical proposition and x is its proof is a key part of the paradigm (perhaps *the* key part). [Mon Dec 4 02:42:56 2017] I definitely "see" how isomorphic they are (Prop and bool). was computability the only reasoning behind this? [Mon Dec 4 02:43:22 2017] s/the only/a/ [Mon Dec 4 02:46:01 2017] bor0: Prop and bool are completely different beasts that have no meaningful isomorphism. Prop is a Sort, and thus there exist pairs x y with (x : y : Prop). bool can only live in the middle of such triples (x : bool : Set). [Mon Dec 4 02:46:42 2017] bor0: bool has two inhabitants: true and false. It is an inductive. Contrast to Prop which has infinitely many inhabitants, with the various inhabitants being types corresponding to logical propositions. [Mon Dec 4 02:47:35 2017] and https://en.wikipedia.org/wiki/Brouwer%E2%80%93Heyting%E2%80%93Kolmogorov_interpretation#The_interpretation are these logical propositions? [Mon Dec 4 02:48:11 2017] bor0: Don't be confused into thinking bool is particularly profound. It just happens to be the name we give to the inductive in Set that has two constructors. The inductive in Set with one constructor is called "unit". [Mon Dec 4 02:49:01 2017] bor0: In that Coq manifests the BHK interpretation, those expressions from that article should be thought of as Props. [Mon Dec 4 02:50:27 2017] bor0: Here's the translation. When the Wikipedia BHK article says "A proof of x is an object y such that..." you should translate that to Coq world as there being some proposition (x : Prop) with some proof (y : x). [Mon Dec 4 02:50:37 2017] ok, this kind of makes sense. your explanation is very precise and thank you for that! but I think I need to read up on some type theory. I thought I "knew" types but it's probably more than just to say "x : A, x has a type of A" [Mon Dec 4 02:52:12 2017] ok, so for a given x : Prop, it's proof is an inhabited type of Prop, i.e. x? [Mon Dec 4 02:52:19 2017] s/it's/its/ [Mon Dec 4 02:52:55 2017] bor0: An inhabitant of a type is just a term of that type. I'm not saying anything special. When (x : T), x is an inhabitant of the type T. [Mon Dec 4 02:53:47 2017] how come it's satisfying that for x : Prop, y : x is a valid proof? is the only requirement types to flow correctly? [Mon Dec 4 02:54:16 2017] I mean if y : x is a valid proof, then probably y' : x is as well? [Mon Dec 4 02:54:28 2017] bor0: Absolutely. [Mon Dec 4 02:54:45 2017] x has potentially infinitely many proofs. [Mon Dec 4 02:54:54 2017] Every term y : x is a valid proof of x. [Mon Dec 4 02:55:00 2017] which ones are satisfying? the ones that have the types flow/match? [Mon Dec 4 02:55:11 2017] ok, cool [Mon Dec 4 02:56:03 2017] I'm not sure what you mean by "types flow/match". Any term (y : x) is definitionally a term whose type "matches x". [Mon Dec 4 02:56:14 2017] yeah, that :) [Mon Dec 4 02:56:19 2017] bor0: Think of a proposition (x : Prop) as being the "type of all proofs of the logical statement x". [Mon Dec 4 02:56:41 2017] Also, note that above whenever I wrote (a : b : c) that was short-hand for (a : b) and (b : c). [Mon Dec 4 02:57:35 2017] so all of /\ \/ -> that I've been using all this time are BHK? and not boolean expressions? [Mon Dec 4 02:58:37 2017] bor0: Correct, they form propositions that can be interpreted roughly via that Wikipedia BHK article. They do not manipulate booleans. [Mon Dec 4 02:59:10 2017] bor0: It may be instructive to try things like: Variable p1 p2 : Prop. Check (p1 /\ p2). [Mon Dec 4 02:59:13 2017] You [Mon Dec 4 02:59:14 2017] one side question, do you know why [Check (\/).] doesn't work, and it doesn't work generally for operators? if I were able to Check \/ I wouldn't have asked you that question (to confirm it's a Prop) [Mon Dec 4 02:59:42 2017] ah. I need to specify variables for it [Mon Dec 4 03:00:12 2017] bor0: That's because \/ is notation. You can first do Locate "\/" to see that it's shorthand for or. You can do Check or. to see that or : Prop -> Prop -> Prop. [Mon Dec 4 03:01:06 2017] ah, Locate! that is handy [Mon Dec 4 03:01:41 2017] bor0: Coq's structure is much simpler than you may believe. There is a lot of notation. It may be instructive to "Unset Printing Notations." and complete a proof. [Mon Dec 4 03:04:54 2017] what should be different when I do that? I just proved [Theorem cool : forall a b : Prop, a /\ b -> a.] but didn't notice anything new [Mon Dec 4 03:06:13 2017] bor0: Step through the proof and see what the output is. You should see that the goal starts as "forall a b : Prop, (_ : and a b), a". [Mon Dec 4 03:06:51 2017] it still says [forall a b : Prop, a /\ b -> a]. I have "Unset Printing Notations." right above my theorem [Mon Dec 4 03:07:35 2017] What environment are you using? [Mon Dec 4 03:07:44 2017] CoqIDE 8.7.0 [Mon Dec 4 03:09:21 2017] bor0: Oh, I see. I use PG. Click "view" in and uncheck "Display notations" instead then. [Mon Dec 4 03:09:42 2017] ahh! weird why that "Unset" statement didn't override that setting. it works now! [Mon Dec 4 03:12:02 2017] this is helpful. do you think it will be useful for my understanding if I re-do my deduction system with this thing turned on (https://github.com/bor0/tutorials/blob/master/2017/deduction_system.v)? [Mon Dec 4 03:14:31 2017] bor0: I don't know, probably not really. I think it's just instructive to realize that things like "/\" "\/" "->" aren't super fundamental, but are just notations for some inductives in Prop. [Mon Dec 4 03:14:51 2017] You should Print or. and Print and. and see if the inductives make sense to you. [Mon Dec 4 03:15:56 2017] ahh!! [Mon Dec 4 03:16:13 2017] product and sum inductive types, I see [Mon Dec 4 03:16:46 2017] and the proofs for them are satisfied when the types flow correctly (or types match) [Mon Dec 4 03:17:59 2017] how can I print ->? Locate doesn't give a meaningful name: Notation "A -> B" := forall _ : A, B : type_scope (default interpretation) [Mon Dec 4 03:18:21 2017] sorry, never mind. the notation itself makes sense to me [Mon Dec 4 03:18:41 2017] bor0: Yes, -> is not an inductive. It's notation for a non-dependent product. [Mon Dec 4 03:19:06 2017] :D I think the more answers you give to me, the more questions I have. what are non-dependent products? [Mon Dec 4 03:19:29 2017] bor0: Contrast to the case of (forall x : A, B) where x is a sub-term of B. [Mon Dec 4 03:20:45 2017] bor0: It may be instructive to Google "dependent product". [Mon Dec 4 03:21:32 2017] ahhh, Pi-type. damn, I went through this when I was checking out Lean [Mon Dec 4 03:24:14 2017] thank you again for Type Theory 101! as awesome as this is, I gotta get back to my regular work. will continue later :) [Mon Dec 4 03:25:58 2017] bor0: You write at one point "(* performs case analysis without recursion, unlike induction *)" [Mon Dec 4 03:27:07 2017] :D I think I have something similar here? https://github.com/bor0/coqlf/blob/master/ch2/1_exercises.v#L108-L109 [Mon Dec 4 03:27:41 2017] I guess now I need to go through all exercises that I did with what I learned today on top of my mind [Mon Dec 4 03:28:27 2017] This is incorrect. What is going on is that ~p is simply p -> False, so it adds p as an obligation, then destructs on the constructors of False. False is the inductive in Prop with no constructors, so it immediately discharges the goal. [Mon Dec 4 03:28:36 2017] Then you're left with the obligation p. That's why the goal changed from q to p. [Mon Dec 4 03:29:19 2017] if I said "case" instead of destruct in that statement, would it made sense? [Mon Dec 4 03:29:32 2017] I just figured out today with one exercise how case and destruct are different [Mon Dec 4 03:29:35 2017] In general you *cannot* do case analysis on an arbitrary proposition, as you correctly note in your long comment block, whose prose is pretty correct. [Mon Dec 4 03:29:54 2017] bor0: No, there is no case analysis to be done on ~p. What is going on is subtle. [Mon Dec 4 03:30:46 2017] It has to do with the fact that destruct is looking at the head of the hypothesis, which in this case is the inductive False. [Mon Dec 4 03:30:54 2017] yeah I need to re-read that comment block. it's copy-paste from a discussion I had in this channel earlier [Mon Dec 4 03:31:11 2017] This "destruct" IS doing case analysis, but across all zero cases that are the constructors of False. [Mon Dec 4 03:31:38 2017] Here's how you should think of what happened: [Mon Dec 4 03:31:56 2017] Recall that ~p is simply p -> False. [Mon Dec 4 03:32:10 2017] destruct makes one case for the current goal for each constructor of False. [Mon Dec 4 03:32:23 2017] There are no constructors of False, so it makes zero cases. This effectively discharges the current goal of "q". [Mon Dec 4 03:32:51 2017] HOWEVER, destruct used the assumption p in order to build that term of type False that it did case analysis on. So it emits a goal corresponding to that obligation. [Mon Dec 4 03:33:02 2017] So it looks like your goal changed from "q" to "p". [Mon Dec 4 03:34:38 2017] There is no general way of doing case analysis on a proposition. Had your hypothesis instead been "p -> q" or something like that then destruct would give you "Error: Not an inductive product." [Mon Dec 4 03:35:10 2017] I've seen that error a lot [Mon Dec 4 03:36:27 2017] The destruct you're using is certainly compact, but it may be conceptually easier to realize that not_p : p -> False is a term that will give you a False if you give it a p. [Mon Dec 4 03:36:35 2017] With a term of type False you're golden, and can discharge any goal. [Mon Dec 4 03:37:04 2017] So what you've written is a way of passing p into not_p, getting the False out, and then using that False to discharge the goal "q". [Mon Dec 4 03:37:16 2017] ow, I see. we proved the current goal q to be False, and are left with proving p (by not_p)? [Mon Dec 4 03:37:57 2017] what tactics can I use to make this more explicit? I feel destruct did quite some magic there [Mon Dec 4 03:38:10 2017] You could also write it in more of a contradiction style: apply not_p in proof_p. contradiction. [Mon Dec 4 03:38:25 2017] Or something like this: exfalso. exact (not_p proof_p). [Mon Dec 4 03:39:13 2017] exfalso, is it like [assert False], but replaces current goal instead of adding a new one? [Mon Dec 4 03:39:14 2017] Your current way of doing it is totally fine. Just don't think that "destruct" is doing case analysis on not_p. It's doing case analysis on the head of not_p, which is a False -- it's doing case analysis across all zero cases of False. [Mon Dec 4 03:40:00 2017] I guess in terms of the effects that's right. [Mon Dec 4 03:41:14 2017] "exfalso. { ... }" is basically the same as "assert False as bad. { ... } destruct bad." [Mon Dec 4 03:41:34 2017] can I "unfold not" a hypothesis? [Mon Dec 4 03:41:43 2017] bor0: unfold not in not_p. [Mon Dec 4 03:41:48 2017] ah, `in` [Mon Dec 4 03:44:20 2017] bor0: contradiction is basically the same as just searching for a hypothesis of type False and destructing it. It's basically just Ltac contradiction' := match goal with [ H : False |- _ ] => destruct H end. [Mon Dec 4 03:44:54 2017] so if I have a given of False, contradiction will end the proof for me? [Mon Dec 4 03:45:00 2017] s/end/finish/ [Mon Dec 4 03:46:00 2017] bor0: Yes, or destructing that False, or whatnot. It's slightly fancier, and will actually complete the proof right after your three intros because it sees that not_p and proof_p together fit the pattern [ H1 : ?x, H2 : ?x -> False ] [Mon Dec 4 03:48:37 2017] bor0: The gist here is that neg_elim is true because ~p -> p -> q is simply stating that a contradiction proves anything. This proof script can be simplified to the single command: Proof. contradiction. Qed. [Mon Dec 4 03:49:01 2017] is this correct? destruct not_p. (* discharge current goal q by p -> False, p .:. False *) [Mon Dec 4 03:51:10 2017] bor0: You're discharging the current goal with the False, and get p as an obligation to use the False. [Mon Dec 4 03:51:12 2017] I guess that's okay. [Mon Dec 4 05:14:24 2017] I have a relation R defined as: Inductive rel: A -> A -> Prop := | Base: forall a1 a2, base a1 a2 -> rel a1 a2 | Trans: forall a1 a2 a3, rel a1 a2 -> rel a2 a3 -> rel a1 a3. When I use "constructor" on a goal of the form "rel (f x1) (f x2)" it asks me to prove "base (f x1) (f x2)", but instead it should go to the transitivity case. Is there a safe version of "constructor" that doesn't make unsafe choices? [Mon Dec 4 05:19:17 2017] sud: What behavior do you want? [Mon Dec 4 05:20:41 2017] cq1: if there are multiple choices, I'd rather have the tactic fail [Mon Dec 4 05:20:57 2017] (because this is in an Ltac script) [Mon Dec 4 06:29:07 2017] sud: ++ [Mon Dec 4 06:31:04 2017] sud: this is experimental, but you can try to use `exactly_once constructor` [Mon Dec 4 06:31:09 2017] see https://coq.inria.fr/refman/ltac.html#hevea_tactic223 for details [Mon Dec 4 06:40:01 2017] pgiarrusso: ? [Mon Dec 4 06:40:21 2017] Cypi: nice thanks [Mon Dec 4 06:40:26 2017] Cool [Mon Dec 4 06:40:42 2017] sud: Sorry, I meant to upvote your question :-) [Mon Dec 4 06:41:05 2017] ah, I thought that was a secret Ltac operator :) [Mon Dec 4 06:41:14 2017] Lol [Mon Dec 4 06:41:48 2017] Excellent answer sir, you win the internet today (or at least the channel) [Mon Dec 4 06:42:22 2017] And scratch the sir. Sorry. [Mon Dec 4 06:42:26 2017] Bad idiom [Mon Dec 4 06:42:44 2017] haha :) [Mon Dec 4 08:36:53 2017] pgiarrusso: Thank you for your help, I finally managed to make my tactic working, by simulating the "=" function I needed by a tactic that fails if the goal cannot be matched with my input. And it's much clearer, simpler... and it works :D Thank you for your help! [Mon Dec 4 10:12:31 2017] any general advice on how to better automate this? https://pastebin.com/RZcVZapN it seems that I need to inspect the context and goal manually to "guess" what should be these intermediary steps (that I pose with the Transitivity constructor) [Mon Dec 4 10:21:15 2017] eapply Transitivity [Mon Dec 4 10:22:04 2017] lyxia: it seems that sometimes gets stuck when it picks the wrong "intermediary" [Mon Dec 4 10:23:20 2017] Yes you might need to be careful to instantiate the existential variables the way you want [Mon Dec 4 10:26:00 2017] lyxia: so I will still have to manually choose the existiential, unless I make an algorithm that chooses right? [Mon Dec 4 10:26:35 2017] lyxia: what about automating this part? "apply IHyp1; myTactic."; should I try to just apply all hypotheses in my context automatically? [Mon Dec 4 10:29:35 2017] sud: in the worst case where you choose the existential explicitly you might as well use apply in the current way [Mon Dec 4 10:30:31 2017] sud: I'm not sure how to automate that part either in general [Mon Dec 4 10:30:55 2017] sud: what do the types of IHyp1 and IHyp2 look like? [Mon Dec 4 10:31:16 2017] I did something that tried to apply eveyr hypothesis in the context and solve the goal in one step; so now I have that: https://pastebin.com/Ppv5bH7e [Mon Dec 4 10:31:30 2017] And maybe I could see the type of Transitivity too for context. [Mon Dec 4 10:32:29 2017] lyxia: they're an inductive hypothesis of the form: forall x, _ -> Result, where the Result unifies with the goal I'm trying to prove [Mon Dec 4 10:32:50 2017] lyxia: it's a constructor for an inductively defined relation: | Transitivity: forall R1 R2 R3, betaConvRef R1 R2 -> betaConvRef R2 R3 -> betaConvRef R1 R3 [Mon Dec 4 10:34:53 2017] okay so if we eapply Transitivity on the goal betaConvRef R1 R3, we get betaConvRef R1 ?R2 and betaConvRef ?R2 R3 as subgoals... [Mon Dec 4 10:35:35 2017] and applying IHyp1 for example in one of the cases should instantiate ?R2 [Mon Dec 4 10:35:41 2017] does it not? [Mon Dec 4 10:36:21 2017] ah, unless the conclusion of IHyp1 also quantifies over R2. [Mon Dec 4 10:37:06 2017] So I guess I would need to look at the whole context to get more ideas. [Mon Dec 4 10:37:21 2017] lyxia: well IHyp could deduces other things as well that the R2 we want indeed [Mon Dec 4 10:38:41 2017] sud: but then it sounds surprising that having R2 properly instantiated before applying IHyp makes it work [Mon Dec 4 10:39:58 2017] Is it not myTactic trying something too eagerly, that fails with a concrete R2, but succeeds if it is existential? [Mon Dec 4 10:44:29 2017] lyxia: right now my code looks like that: https://pastebin.com/Ppv5bH7e (so myTactic succeeds when the R2 is concrete). Also sometimes note that I have to introduce 2 different intermediary steps for the same goal [Mon Dec 4 10:47:10 2017] (sorry I have to go I'll reconnect later. I probably need a minimal example to show :-) [Mon Dec 4 13:14:41 2017] Hum... Sometimes I've in the assumptions something like "T1 a b = T2". And because T1 and T2 are two different constructors, it's obvious that this is not possible. How could I reduce this to bottom? [Mon Dec 4 13:15:18 2017] (it appears after a "inversion H" operation) [Mon Dec 4 13:24:47 2017] Hum I found the solution with discriminate [Mon Dec 4 13:25:06 2017] (and actually now I rememember that one of you already pointed me to this solution) [Mon Dec 4 15:03:13 2017] tobiasBora: you could probably just inversion the T1 a b = T2 thing? Although, I would have thought that inversion would see the contradiction if it generated it. [Mon Dec 4 15:15:38 2017] that depends on whether it arises from the target of the inversion, I think [Mon Dec 4 15:15:43 2017] anyway "try discriminate" is often helpful [Sat Dec 23 23:02:05 2017] beaky: it seems you’d want to define splitWith directly by recursion, your solution calls the predicate twice per element, even after extraction [Sat Dec 23 23:02:19 2017] o right [Sat Dec 23 23:03:23 2017] beaky: on your actual question, it’s hard to be sure without seeing the output, but https://gmalecha.github.io/reflections/2017/qed-considered-harmful might be relevant [Sat Dec 23 23:03:51 2017] OTOH, my first instinct was to use Qed for the obligations [Sat Dec 23 23:03:59 2017] nice thanks [Sat Dec 23 23:04:27 2017] In fact, my 0th instinct would be to ask if you really should be using vectors here [Sat Dec 23 23:05:12 2017] haha that is the painful realization i am facing [Sat Dec 23 23:05:53 2017] In Coq you can just prove facts about the length of the list if you want [Sat Dec 23 23:08:38 2017] yes i had a splitWith with ordinary lists (accompanied by length proofs) and wanted to see how it would go with vectors (was hoping it would cut down on the proofs :D) [Sat Dec 23 23:09:37 2017] Well sometimes it does [Sat Dec 23 23:09:56 2017] But `filter` and friends seem more problematic [Sat Dec 23 23:10:47 2017] I’ve used heterogeneous length-indexed vectors in Agda with great success, but there I never had something like filter [Sat Dec 23 23:11:27 2017] *also*, Coq tends to be less friendly to dependently-typed data structure, that blog post is just one issue with the “ecosystem” [Sat Dec 23 23:11:56 2017] nice i hope i can get into agda (and idris too) after coq [Sat Dec 23 23:12:39 2017] That `destruct` and `induction` don’t work well on vectors and friends is another [Sat Dec 23 23:12:51 2017] I think Agda is instructive [Sat Dec 23 23:13:21 2017] as oppsosed to destructive? [Sat Dec 23 23:13:22 2017] :] [Sat Dec 23 23:13:49 2017] pgiarrusso: isnt agda's friendliness b/c it has a rly powerful elimination construct but which actually causes a stronger theory than coc [Sat Dec 23 23:13:51 2017] But I have painted myself into a corner with dependently-typed data multiple types [Sat Dec 23 23:14:32 2017] benzrf: weeell.... sort-of-somewhat [Sat Dec 23 23:15:01 2017] benzrf: in terms of that blog post, agda defaults to `Defined` over `Qed` for the reasons argued there [Sat Dec 23 23:15:56 2017] benzrf: it is true that Agda has dependent pattern matching (unlike Coq, but like Coq + Equations) and that dependent pattern matching is easier to do using “axiom K” which Coq doesn’t use [Sat Dec 23 23:16:33 2017] but axiom K (or UIP, for uniqueness of identity proofs) can be often avoided (see Jesper Cockx’s “Pattern matching without K”) [Sat Dec 23 23:16:56 2017] wots coq + equations [Sat Dec 23 23:17:23 2017] google sozeau equations [Sat Dec 23 23:18:00 2017] a PhD student of Sozeau working on equations hangs in this channel and wrote so, afraid I forget who it is :-( [Sat Dec 23 23:18:24 2017] anyway yeah i was wondering how u use equalities in agda when they're hell to do directly in coq and i googled and it seemed u just eliminate them and it ~works~ [Sat Dec 23 23:18:24 2017] but sorry, tl;dr.: equations gives Agda-style pattern matching in Coq [Sat Dec 23 23:18:28 2017] ah [Sat Dec 23 23:19:14 2017] what *is* missing though in Coq is *interactive* support for `refine` *when writing programs*, which is often nice [Sat Dec 23 23:19:57 2017] the problem, though, can be that it seems to take a PhD to write dependently-typed programs in just the right way so that dependent types work nicely [Sat Dec 23 23:20:09 2017] heh heh [Sat Dec 23 23:22:46 2017] https://people.mpi-sws.org/~gil/publications/typedsyntaxfull.pdf is one of my favorite examples — people working out just the right way to represent a certain tricky data structure (simply-typed lambda calculus terms) so that dependent types are less painful [Sat Dec 23 23:22:50 2017] and actually helpful [Sat Dec 23 23:24:11 2017] benzrf: “just eliminate equalities” by pattern matching is indeed very nice in Agda — it’s much more concise and readable than doing `dependent destruction` on them :-) (never tried it, does it work?) [Sat Dec 23 23:31:36 2017] i dont know [Sun Dec 24 09:41:17 2017] is inversion the only tactic I can use to prove [x] = [y] -> x = y? [Sun Dec 24 09:46:36 2017] What is [x]? A list with one element? You should be able to use `injection` too, which is a bit more precise and low-level. [Sun Dec 24 09:47:54 2017] neat [Sun Dec 24 19:32:09 2017] How does this work? It seems like this should fail... "S m" should not unify with "m". https://pastebin.com/e4ZP5jng [Sun Dec 24 19:32:46 2017] n can freely unify with "S n'" because it's universally quantified, but m should be fixed and fail to unify with "S m", yes? [Sun Dec 24 19:33:59 2017] (I mean obviously not, but that's what I would think) [Sun Dec 24 19:36:34 2017] My guess is that Coq is doing something smarter than just "apply the function", but I'm not sure what. [Sun Dec 24 20:31:08 2017] arguments wrong way around smh https://scontent-ort2-1.xx.fbcdn.net/v/t1.0-9/23472080_1503337823096298_1032036901787370844_n.png?oh=6522030821783b56a64f604424a56a5b&oe=5ACB0584 [Sun Dec 24 20:32:04 2017] I accidentally got disconnected a few minutes ago; did anyone respond to my question [Sun Dec 24 20:32:08 2017] *? [Sun Dec 24 20:32:23 2017] williamyager: not yet, but got an idea [Sun Dec 24 20:32:48 2017] williamyager: I suspect `simpl in *.` before the `apply` could clarify things [Sun Dec 24 20:33:03 2017] I think `eq_nat (S a) (S b)` simplifies to `eq_nat a b` [Sun Dec 24 20:33:32 2017] williamyager: ^^ [Sun Dec 24 20:33:36 2017] Ah, you are correct. [Sun Dec 24 20:33:38 2017] Thank you! [Sun Dec 24 20:33:57 2017] :-) [Sun Dec 24 20:34:02 2017] this was indeed confusing [Sun Dec 24 20:34:18 2017] I could have sworn I tried doing simpl before and it didn't work, but I may have forgotten "in eq". [Sun Dec 24 20:34:55 2017] took me a while to realize that `eq_nat` is not a “constructor” for unification [Sun Dec 24 20:35:55 2017] (that is, `eq_nat a b = eq_nat c d` does not necessarily mean that `a = c` and `b = d` — one has at least to simplify first) [Mon Dec 25 00:09:54 2017] How can I destruct on a boolean expression like "pred x" such that I get a witness that the expression evaluates to true or false in each branch? [Mon Dec 25 00:10:47 2017] I can destruct on the expression, and it replaces any already-present instances of "pred x" with "true" and simplifies, but I can't subsequently replace any instances of "pred x" I come up with with "true". [Mon Dec 25 00:11:11 2017] I would like it to add "H0 : pred x = true" to scope or something [Mon Dec 25 00:13:39 2017] It looks like I can use "compare (pred x) true" but that seems a bit indirect [Mon Dec 25 02:29:05 2017] And... the answer was ‘destruct (pred x) eqn:H’ (see also reference manual for destruct), but williamyager js out [Mon Dec 25 05:58:36 2017] Merry christmas ladies, gentlemen, bots. [Mon Dec 25 05:58:48 2017] I sort of doubt anybody is around today, but [Mon Dec 25 05:59:03 2017] I think I have just "proved" that 0 != 0 [Mon Dec 25 05:59:19 2017] Can somebody help me understand what I'm doing wrong? [Mon Dec 25 05:59:19 2017] https://pastebin.com/e1Yh20bQ [Mon Dec 25 09:19:10 2017] t0by: That seems to be something different from Inductive Empty := . [Mon Dec 25 09:19:25 2017] Yes, that is it [Mon Dec 25 09:19:32 2017] Sorry, found out on my own a while ago [Mon Dec 25 09:19:37 2017] thanks and merry christmas! [Mon Dec 25 09:20:29 2017] lyxia, while we are at it: I'm trying to figure out how to _build_ a proof term (by hand) of NonZero (succ O) [Mon Dec 25 09:20:30 2017] Merry Christmas to you too [Mon Dec 25 09:20:42 2017] Using tactics intro; inversion H suffices [Mon Dec 25 09:20:56 2017] but the resulting proof term is a behemoth I can't make heads or tails of [Mon Dec 25 09:21:09 2017] Any hint? [Mon Dec 25 09:21:37 2017] (Using as little of coq's theory and lemmas as possible, since I'm working through a textbook) [Mon Dec 25 09:27:22 2017] Maybe I can explain what's going on because that may be as simple as it gets [Mon Dec 25 09:27:32 2017] the key part is eq_ind [Mon Dec 25 09:27:47 2017] If P x is true, then forall y, x = y -> P y [Mon Dec 25 09:28:02 2017] It's the induction principle for eq [Mon Dec 25 09:28:44 2017] Oh, sure. [Mon Dec 25 09:30:22 2017] What is the P in question, though? [Mon Dec 25 09:32:26 2017] (fun n : nat => match n with O => False | S _ => True end) or the other way around (True/False) depending on whether you wrote (0 = 1) or (1 = 0) [Mon Dec 25 09:33:25 2017] and then essentially it's ex falso? [Mon Dec 25 09:33:38 2017] A different way to put it is if (x = x) -> P x is true then forall y, (x = y) -> P y is true [Mon Dec 25 09:33:52 2017] If I squint I can now sort of see it in this monster of a pt. [Mon Dec 25 09:34:44 2017] P is a function that can match on y, so that P y = False whenever y is not x [Mon Dec 25 09:36:22 2017] And to implement that principle you use dependent pattern matching. When you pattern match on refl : x = x you can just assume the two sides are the same. [Mon Dec 25 09:42:54 2017] Hrrr [Mon Dec 25 09:42:57 2017] let me digest this [Mon Dec 25 09:42:59 2017] but thanks [Wed Dec 27 23:06:48 2017] plenty of fans of untyped languages are big proponents of runtime distinction between "types" [Wed Dec 27 23:06:58 2017] and many aren't, too. [Wed Dec 27 23:07:09 2017] yes, but they're the ones who dislike python [Wed Dec 27 23:07:31 2017] basically it seems out of character for python to think True == 1 [Wed Dec 27 23:08:11 2017] in awk, 1 == "1" but 1.0 != "1.0" [Wed Dec 27 23:08:45 2017] true [Wed Dec 27 23:09:35 2017] anyway, syntactically, if you don't make assignment an expression, you end up needing two classes of statements [Wed Dec 27 23:09:40 2017] and I'm not sure that's really preferable [Wed Dec 27 23:09:49 2017] well, that's true [Wed Dec 27 23:09:57 2017] it's easy to reject assignments that were supposed to be comparisons; gcc's been doing it for 20 years [Wed Dec 27 23:10:10 2017] no, more than that. [Wed Dec 27 23:11:10 2017] matching with if is a more interesting syntactic problem [Wed Dec 27 23:11:32 2017] i think rust has a handle on it [Wed Dec 27 23:11:37 2017] the key is to not do donkey sentences [Wed Dec 27 23:12:59 2017] if (exists x, foo == Foo x) then x else 0 is fine from a logic point of view [Wed Dec 27 23:13:13 2017] it just requires a restriction on where x can appear [Wed Dec 27 23:14:09 2017] in particular it has to be constrained by equality [Wed Dec 27 23:14:44 2017] the x is escaping the binder [Wed Dec 27 23:14:57 2017] that depends on how you think of the binder [Wed Dec 27 23:15:24 2017] or rather, you could write it some other way [Wed Dec 27 23:15:26 2017] or both [Wed Dec 27 23:15:30 2017] well, i assumed that the thing inside of the if was supposed to be an expression [Wed Dec 27 23:16:02 2017] so unless you're doing crazy special-casing that would imply that you have some bizarre scoping rules [Wed Dec 27 23:16:06 2017] it's not unprecedented for the scope of binders in the head of a statement to cover the body [Wed Dec 27 23:16:26 2017] that's generally special-cased [Wed Dec 27 23:16:32 2017] er, i mean [Wed Dec 27 23:16:45 2017] that's generally a case where that sort of binder is a distinct syntactic form [Wed Dec 27 23:16:47 2017] actually I guess it's the distinction between assignment and let-binding [Wed Dec 27 23:17:01 2017] and we expect "exists x," to be a let-binding [Wed Dec 27 23:17:09 2017] not a let binding [Wed Dec 27 23:17:11 2017] just a binding [Wed Dec 27 23:17:13 2017] o.O [Wed Dec 27 23:17:57 2017] syntactically it's "let x = (some type) in foo == Foo x" [Wed Dec 27 23:18:13 2017] and we expect the binding to be limited to the in-clause [Wed Dec 27 23:18:19 2017] that's not a let thing [Wed Dec 27 23:18:21 2017] that's just called "binding" [Wed Dec 27 23:18:34 2017] no? [Wed Dec 27 23:18:50 2017] what's "int x; x = 0; ...... return x;" [Wed Dec 27 23:18:56 2017] declaration and assignment [Wed Dec 27 23:19:04 2017] it's still a binding of x [Wed Dec 27 23:19:12 2017] or at least, I'd say so [Wed Dec 27 23:19:49 2017] if someone wrote "int x; x = 0; ...... return boundp(x)" and it returned false, that would be weird. [Wed Dec 27 23:20:17 2017] i was about to start typing up a counterpoint but then i realized i dont think i have an actual point i'm arguing [Wed Dec 27 23:20:29 2017] anyway that's a detail [Wed Dec 27 23:21:05 2017] let me back up: what i meant to say is that in the context of talking about expression-based syntaxes, the concept of a term in which a subterm has a bound variable is just "binding", not "let-binding" [Wed Dec 27 23:22:04 2017] yes, but whether the binding escapes the term or not... the latter is the defining characteristic of let-binding [Wed Dec 27 23:22:39 2017] no it's not, that's true of pretty much every binder in most logics and type theories [Wed Dec 27 23:22:43 2017] forall, exists, lambda [Wed Dec 27 23:23:45 2017] I suppose that's true [Wed Dec 27 23:24:22 2017] anyway this is still a side issue [Wed Dec 27 23:24:37 2017] in fact, "int x;" isn't a case of a binding escaping a binder [Wed Dec 27 23:25:30 2017] because either we want to see "int x;" as not a term with subterms, in which case it's not a coherent question, or else we should regard "int x; ..." as a term with the ... as a subterm which int x binds over [Wed Dec 27 23:26:04 2017] well, it does have two subterms: int and x [Wed Dec 27 23:26:13 2017] but I take your point [Wed Dec 27 23:26:20 2017] i wouldn't call those subterms [Wed Dec 27 23:26:24 2017] they're different parts of the grammar [Wed Dec 27 23:26:34 2017] x is, int isn't really [Wed Dec 27 23:26:39 2017] but i guess this is a silly argument anyway since by definition a variable can't escape a binder [Wed Dec 27 23:26:46 2017] in C types are different, but at a fundamental level they aren't [Wed Dec 27 23:27:12 2017] anyway [Wed Dec 27 23:27:43 2017] either a variable is bound by a given binder, or not, and "escaping" is a description of human interaction, like how "bugs" arent features of programs themselves [Wed Dec 27 23:29:12 2017] actually I think the way to do it is an operator that takes a statement and converts its success or failure to a boolean [Wed Dec 27 23:29:43 2017] uhhh [Wed Dec 27 23:29:50 2017] booleans are bad, mkay [Wed Dec 27 23:30:02 2017] booleans are reality :-) [Wed Dec 27 23:30:12 2017] so is failure, for that matter... [Wed Dec 27 23:30:13 2017] so is assembly language [Wed Dec 27 23:34:37 2017] Foo (var x) = foo ?? x :: 0; [Wed Dec 27 23:34:41 2017] for = meaning assignment [Wed Dec 27 23:35:04 2017] I don't think that syntax violates any standard assumptions [Wed Dec 27 23:35:17 2017] given that ?? would mean "test for failure" [Wed Dec 27 23:35:45 2017] although maybe it should be written { Foo (var x) = foo } ?? x :: 0; to make the grouping clear [Wed Dec 27 23:35:55 2017] except that does violate standard notions of scoping [Wed Dec 27 23:36:16 2017] meh. [Wed Dec 27 23:36:21 2017] I'm not actually designing a language tonight [Wed Dec 27 23:38:05 2017] https://play.rust-lang.org/?gist=973e5ffaadecf566a33e24e954d90664&version=stable [Wed Dec 27 23:38:37 2017] j/k, if let is a specific construct [Wed Dec 27 23:55:10 2017] does rust really use "let" for all assignments? [Wed Dec 27 23:56:21 2017] i dont think so [Wed Dec 27 23:56:24 2017] it uses let for declarations [Wed Dec 27 23:56:58 2017] if you have a mutable variable then assigning to it is just like in c [Wed Dec 27 23:57:29 2017] ah [Wed Dec 27 23:57:39 2017] you say let mut for mutable variables [Wed Dec 27 23:57:53 2017] well - actually mut is a modifier on the variable binding, and it's still let [Wed Dec 27 23:58:49 2017] e.g. https://play.rust-lang.org/?gist=86793e081b9b42f2eb4dfbb957e9d62d&version=stable [Wed Dec 27 23:59:50 2017] ah [Thu Dec 28 00:03:45 2017] seems a lot like the role of "var" in pascal, not that this is necessarily bad [Thu Dec 28 00:04:30 2017] i read my dads old pascal book once like 10 years ago. thats what i know about pascal [Thu Dec 28 00:05:04 2017] but I admit, "let x = 3;" annoys me both because it doesn't have a body and because it is a throwback to early BASIC dialects [Thu Dec 28 00:05:11 2017] which you probably aren't old enough to remember :-) [Thu Dec 28 00:05:30 2017] actually "True BASIC" is the first programming language i learned, bizarrely [Thu Dec 28 00:06:05 2017] what do you mean about not having a body, though [Thu Dec 28 00:06:07 2017] * waits for the RESF to come strike him down [Thu Dec 28 00:06:18 2017] "let" should have the form "let x in y" [Thu Dec 28 00:06:25 2017] oh [Thu Dec 28 00:06:36 2017] if that's not what it is, use a different keyword [Thu Dec 28 00:07:26 2017] but you just pointed out that not having a body is the earlier form 🤔 [Thu Dec 28 00:07:55 2017] I don't think it is [Thu Dec 28 00:07:58 2017] BASIC dates to the 70s [Thu Dec 28 00:08:04 2017] "let" comes from lisp and probably dates to the 60s [Thu Dec 28 00:08:13 2017] well [Thu Dec 28 00:08:16 2017] okay [Thu Dec 28 00:08:31 2017] though I don't know much about the history of lisp (and don't really care very much) [Thu Dec 28 00:08:42 2017] gonna hold you to taking prompting from lisp when it comes to syntax (: [Thu Dec 28 00:09:09 2017] hadnt heard of the resf but wow https://pbs.twimg.com/media/DL7ggZWWkAAHL9y.jpg:large [Thu Dec 28 00:10:41 2017] good night [Thu Dec 28 00:12:29 2017] heh [Thu Dec 28 00:13:22 2017] night [Thu Dec 28 00:13:54 2017] everybody we've been drowning out, please resume talking about coq :-) [Thu Dec 28 02:07:03 2017] pgiarrusso: it looks like cpdt is not doing anything special for type setting, may be the style file he is using makes the difference. Also the output of the coq interpreter, is being included by hand. So I think that is the best that can be done. [Thu Dec 28 02:07:12 2017] pgiarrusso: thanks for the help in any case [Thu Dec 28 02:13:29 2017] pgiarrusso: I found two latex macros that control the typesetting of keywords and ids [Thu Dec 28 02:13:47 2017] I guess I can tweak that for better styling [Thu Dec 28 02:47:31 2017] pgiarrusso: it seems the coqdoc package takes a color option so now I am happy. [Thu Dec 28 02:47:48 2017] * should always try the obvious thing before asking [Thu Dec 28 03:32:14 2017] is there a way to automate this kind of proof involving 'exists'? (i.e. solvable by just trying out constructors and hoping one sticks) https://bpaste.net/show/3d20ce88d5b1 [Thu Dec 28 03:36:20 2017] eexists perhaps? [Thu Dec 28 03:37:55 2017] You can probably also write a loop but I don't know how. [Thu Dec 28 03:38:29 2017] intros []; eexists; eauto. [Thu Dec 28 05:05:40 2017] exists + whatever automation is good, but warning: you often want to delay eexists. doing substitution on existential variables is a pain [Thu Dec 28 05:06:52 2017] ah sorry, I agree this isn't relevant here [Thu Dec 28 05:51:50 2017] beaky : to do what you describe, you can try `repeat econstructor; eauto` [Thu Dec 28 05:51:56 2017] this will even do the `eexists` for you [Thu Dec 28 06:56:15 2017] Cypi: I thought you’d need a backtracking loop and errors though... closer to `repeat solve [econstructor; eauto]` (or maybe you need a dummy `match goal` to get the needed backtracking?) [Thu Dec 28 06:58:31 2017] But I’m not sure what `intros []` means... checking it out [Thu Dec 28 07:00:56 2017] I was wondering that [Thu Dec 28 07:04:00 2017] OK, `intros []` *is* a case split on the first argument [Thu Dec 28 07:05:19 2017] though https://coq.inria.fr/refman/tactics.html#hevea_tactic38 appears to forbid it in the documentation of disjunctive patterns [Thu Dec 28 07:17:04 2017] FWIW, the alternative I had in mind was `match goal with _ |- _ => solve [econstructor; eauto] end.`, or something like that — where the dummy `match goal` gives backtracking. But I’m still pretty confused here on the exact semantics. [Thu Dec 28 07:17:43 2017] also, `repeat solve ...` is redundant for `solve ...` [Thu Dec 28 08:11:14 2017] pgiarrusso: the ; from Ltac is backtracking. [Thu Dec 28 08:13:09 2017] Consider this simple example http://lpaste.net/361162 [Thu Dec 28 08:13:26 2017] `constructor` will pick the first constructor, so in the first case you end up with having to prove `False` [Thu Dec 28 08:14:04 2017] but this is actually a tactic with multiple successes, so if a further tactic would fail (like the second `constructor` in the latter example), it will backtrack and try the next constructor [Thu Dec 28 08:14:58 2017] So if you do `repeat econstructor; solve[ tac ].`, it will actually try every combination of constructors applications until `tac` can succeed [Thu Dec 28 10:17:00 2017] Cypi: first of all, I’m taking the original script to never nest calls to constructor, making repeat econstructor undesirable [Thu Dec 28 10:17:48 2017] Cypi: but your explanation suggests that econstructor; solve [eauto]. might be the desired tactic [Thu Dec 28 10:21:13 2017] Looking at the reference manual, this might be explained under heading “Backtracking branching” of https://coq.inria.fr/refman/ltac.html#sec468, while discussing the semantics of +; the equation with + and ; are especially suggestive. [Thu Dec 28 10:22:41 2017] But if that’s the case, the earlier explanation of ; is very bad, and even the later one js bad... this might be appropriate for a bad tutorial, not for a reference manual [Thu Dec 28 10:23:45 2017] Of course I might miss something, but now I have one more reason to ask for a formal semantics of Ltac (crazy, I know) [Thu Dec 28 10:25:38 2017] Though... I gotta look closer at your example [Thu Dec 28 10:28:41 2017] Cypi: OK, indeed got your example, and `econstructor; solve [eauto]` solves it too :-). [Thu Dec 28 10:34:15 2017] beaky: `econstructor; solve [eauto]` seems the closest automation of your solution [Thu Dec 28 11:08:03 2017] Cypi: also, THANKS, I’m wondering how I missed this earlier [Fri Dec 29 09:13:05 2017] hello [Fri Dec 29 09:13:10 2017] https://streaming.media.ccc.de/34c3/relive/9105 [Fri Dec 29 09:13:14 2017] adam gave a talk at CCC [Fri Dec 29 09:31:43 2017] pgiarrusso: is there a way to include (* *) comments in the doc ? [Fri Dec 29 09:33:12 2017] piyush-kurur: I'm unqualified to answer, but those books I cited last time seem to do it by default? or maybe they only include some comments? [Fri Dec 29 11:09:41 2017] dh`: do you want to see the end result of the 2-3 tree project? [Fri Dec 29 12:29:15 2017] sure [Fri Dec 29 12:29:18 2017] :-) [Fri Dec 29 21:16:39 2017] ugh... if I have H: P (ctor arg) for some inductive P, is there any working way to do induction H? [Fri Dec 29 21:17:11 2017] it seems that if you don't remember and hide away (ctor arg) the induction forgets it isn't the general case of its type [Fri Dec 29 21:18:09 2017] but if you do, the Heq* from remembering it gives you a false premise in the induction hypothesis. [Fri Dec 29 21:20:31 2017] I suppose it's reasonable that it works out this way, but it's annoying and it's making it impossible to prove something otherwise simple... [Fri Dec 29 21:33:53 2017] dh_work: isn’t this what dependent induction is for? [Fri Dec 29 21:34:40 2017] This is the same problem that various “dependent foo” tactics solve [Fri Dec 29 21:43:32 2017] hmm that's an idea [Fri Dec 29 21:45:00 2017] yes that worked! woo [Fri Dec 29 21:45:36 2017] back on regexps, was trying to prove that RxStar (RxEpsilon) can't match x :: xs [Fri Dec 29 21:50:18 2017] and that's surprisingly hard. [Fri Dec 29 21:59:45 2017] wait, that regexp is \epsilon *? [Fri Dec 29 22:00:04 2017] an arbitrary sequence of empty strings? [Fri Dec 29 22:00:38 2017] which matches... the empty string, hence a prefix of x :: xs... so I hope you mean it doesn’t do a “full” match [Fri Dec 29 22:01:09 2017] have you tried reasoning on the length of x :: xs (>= 1) and of strings matching \epsilon * (0)? those lengths are disjoint [Fri Dec 29 22:01:32 2017] so the thesis should follow [Fri Dec 29 22:01:56 2017] once you prove enough facts about “length of matches” [Fri Dec 29 22:03:10 2017] dh_work: ^^ [Fri Dec 29 22:05:51 2017] I mean, reasoning on \epsilon * by direct induction (on matches of *) would fail because \epsilon * = [Fri Dec 29 22:06:03 2017] \epsilon \epsilon* [Fri Dec 29 22:06:19 2017] so a match of \epsilon* is a match against \epsilon and a match against \epsilon* [Fri Dec 29 22:06:48 2017] so we’re back to where we started without having made progress [Fri Dec 29 22:06:58 2017] having consumed characters, and so on [Fri Dec 29 22:08:50 2017] dh_work: or, can you prove that a match against r* is a match against `r^n` for some n (where `r^n` means `n` times `r`)? If so, you can at least reason by induction on `n` [Fri Dec 29 22:09:29 2017] and prove by induction on `n` that for all `n`, `\epsilon^n` does not match `x :: xs` [Fri Dec 29 22:15:39 2017] I'm not convinced lengths will help [Fri Dec 29 22:15:42 2017] the latter probably will [Fri Dec 29 22:15:57 2017] at the moment I'm trying to work it by adding more inductives [Fri Dec 29 22:19:58 2017] also, is the latter even true? the basic problem here is that r* matches "" ++ s, and after simplifying you get right back to r* matches s [Fri Dec 29 22:24:26 2017] bah [Fri Dec 29 22:24:51 2017] dependent induction works for RxStar RxEpsilon, but not for RxStar r [Fri Dec 29 22:25:13 2017] In nested Ltac calls to "dependent induction (ident)", "do_depind", [Fri Dec 29 22:25:13 2017] "tac" (bound to fun hyp => do_ind hyp), "do_ind", "elim_ind", [Fri Dec 29 22:25:13 2017] "elim_tac" and "p", last term evaluation failed. [Fri Dec 29 22:25:13 2017] Variable p should be bound to a term but is bound to a ident. [Fri Dec 29 22:25:38 2017] can't really interpret that message :( [Fri Dec 29 22:27:25 2017] people working on Coq warned me against `dependent induction` because it’s more experimental, this might be what they meant :-| [Fri Dec 29 22:28:15 2017] > 4:19 AM also, is the latter even true? the basic problem here is that r* matches "" ++ s, and after simplifying you get right back to r* matches s [Fri Dec 29 22:28:36 2017] I agree that is the problem, and making `n` explicit fixes that [Fri Dec 29 22:29:01 2017] (I tried to hint at this but explained that badly) [Fri Dec 29 22:29:33 2017] `n` explicit fixes that because at least you go to `r^(n - 1) matches s` and the inductive hypothesis tells you that’s impossible [Fri Dec 29 22:29:54 2017] and this, BTW, is just strengthening of the induction hypothesis [Fri Dec 29 22:30:19 2017] well, scratch “just”... it’s yet another instance of it [Fri Dec 29 22:32:23 2017] on lengths, I’ll agree it’d be more work, and a few steps might be hard [Fri Dec 29 22:36:41 2017] dh_work: on your original question re `dependent induction H`, you should not remember just `H`, but you should also “generalize” its indexes [Fri Dec 29 22:36:54 2017] > 3:16 AM ugh... if I have H: P (ctor arg) for some inductive P, is there any working way to do induction H? [Fri Dec 29 22:38:36 2017] you need to bind a fresh variable `x` and remember that `x = ctor arg`, turn `H` into `H : P x`, *then* do `induction H` [Fri Dec 29 22:40:06 2017] that’s a (bad) summary of https://coq.inria.fr/refman/tactic-examples.html#dependent-induction-example [Fri Dec 29 22:40:14 2017] which explains how the tactic is implemented [Fri Dec 29 22:41:00 2017] this way, beyond the absurd premise in the induction hypothesis, you should get an absurd premise to the goal as well [Fri Dec 29 22:41:26 2017] dh_work: ^^ [Fri Dec 29 22:43:49 2017] hmm [Fri Dec 29 23:09:33 2017] hmm [Fri Dec 29 23:10:00 2017] the cases in which dependent induction doesn't work are the ones where the regexp has a subregexp in it [Fri Dec 29 23:11:32 2017] or rather, it seems, dependent induction H chokes as above if H contains a subterm that's a general case of a regexp [Fri Dec 29 23:11:48 2017] which will always be the case for some instances, because regexps are inductive. [Fri Dec 29 23:13:35 2017] aha [Fri Dec 29 23:14:27 2017] it seems to be critical to define matching for * just so [Fri Dec 29 23:15:08 2017] I had been using: [Fri Dec 29 23:15:09 2017] | StarMatches: forall ctx r xs, [Fri Dec 29 23:15:09 2017] RxMatches ctx (RxAlt RxEpsilon (RxSeq r (RxStar r))) xs -> [Fri Dec 29 23:15:09 2017] RxMatches ctx (RxStar r) xs [Fri Dec 29 23:16:22 2017] in which case inducting on RxMatches after remembering (RxStar r) gives a single IH that wants RxAlt RxEpsilon (RxSeq r (RxStar r)) = RxStar r [Fri Dec 29 23:16:24 2017] and it fails [Fri Dec 29 23:16:29 2017] however, changing that to: [Fri Dec 29 23:16:41 2017] | StarMatchesEmpty: forall ctx r, [Fri Dec 29 23:16:41 2017] RxMatches ctx (RxStar r) [] [Fri Dec 29 23:16:41 2017] | StarMatchesMore: forall ctx r xs0 xs1, [Fri Dec 29 23:16:41 2017] RxMatches ctx r xs0 -> [Fri Dec 29 23:16:41 2017] RxMatches ctx (RxStar r) xs1 -> [Fri Dec 29 23:16:42 2017] RxMatches ctx (RxStar r) (xs0 ++ xs1) [Fri Dec 29 23:17:30 2017] makes it a lot better: the empty case works out easily and the other case gives me two induction hypotheses, where the equality premise of the second one is RxStar r0 = RxStar r, and that works [Fri Dec 29 23:17:41 2017] that is not something I would have expected. [Fri Dec 29 23:17:59 2017] I'd been using the second form earlier, but changed for this branch of things because it looks tidier to unfold the other way [Fri Dec 29 23:24:22 2017] I have a term t that appears in many places in my context and I want to declare a name X for it (pose t as X for instance), and I want to substitute every occurrence of t with X (assert (H: t = x). { auto. } rewrite H in *. [Fri Dec 29 23:24:50 2017] this part is ok, but I also want that subst and other tactics to not simplify X away [Fri Dec 29 23:43:26 2017] you can do that more easily with "remember t as X"; but I don't know any way to make subst ignore it [Fri Dec 29 23:49:13 2017] dh_work: perhaps by "hiding" the equality inside a constructor? Inductive W: Prop -> Prop := Wrap: forall P: Prop, P -> W P. [Sat Dec 30 01:43:05 2017] oh, that should do it. [Sat Dec 30 01:43:51 2017] don't even bother with that, just assert (Some t = Some x) by (apply f_equal; auto). [Sat Dec 30 01:45:34 2017] i believe even just f_equal is a tactic [Sat Dec 30 01:45:44 2017] (so [by f_equal]) [Sat Dec 30 01:45:52 2017] then clear the direct equation [Sat Dec 30 01:46:32 2017] oh wait no yeah the auto is still necessary nvm [Sat Dec 30 23:38:59 2017] if anyone's about and bored, and has opinions about how my string librrary should think about character classes, this would be a good time to speak up [Sun Dec 31 02:49:12 2017] Also, does the Coq library have anything comparable to struct timespec or time_t? [Sun Dec 31 03:01:46 2017] dh`: not that I know of [Sun Dec 31 03:16:42 2017] figures [Sun Dec 31 03:17:15 2017] the string library ought to have strftime(), was hoping there's already some time infrastructure [Sun Dec 31 03:17:41 2017] but given coq's general detachment from that level of reality I'm not actually surprised :-) [Sun Dec 31 03:21:43 2017] while I maybe have your attention: do you see any value in python's foo[x:y:z] stride array slicing for strings? [Sun Dec 31 03:21:47 2017] I'm thinking not [Sun Dec 31 06:36:17 2017] https://gist.github.com/bollu/bb2bfdeccfc86a173319576a15f62c7a <- I'm not able to convert a Zneq_bool into a type-level witness [Sun Dec 31 06:36:24 2017] I get a cryptic error that I don't know how to debug [Sun Dec 31 06:40:22 2017] bollu1: did you not mean "apply Zeq_bool_neq" [Sun Dec 31 08:18:15 2017] lyxia: yes, I did [Mon Jan 1 00:06:02 2018] heh, coqide gets really slow on 10000-line files [Mon Jan 1 00:49:18 2018] It looks to me that a Class constraint in Coq becomes a formal argument in the extracted haskell code. Is there a way to make it a class constraint. [Mon Jan 1 00:49:55 2018] Or is this inherently going to be difficult [Mon Jan 1 00:56:10 2018] haskell typeclasses are different enough that it probably will be difficult [Mon Jan 1 01:15:50 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A DISCUSSION IS GOING ON ABOUT TO TO RE-ENSLAVE NIGGERS IN #/JOIN IF THIS GETS YOUR DICK HARD JOIN IN (MESSAGE VAP0R FOR HELP) jwotpmr: mpickering tomjack xeno ▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 01:15:56 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A DISCUSSION IS GOING ON ABOUT TO TO RE-ENSLAVE NIGGERS IN #/JOIN IF THIS GETS YOUR DICK HARD JOIN IN (MESSAGE VAP0R FOR HELP) mjwcqjadpu: justan0theruser bitonic mankyKitty ▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:31 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)tbtnyj: augur tomjack butterthebuddha ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:36 2018] ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zagytvq: ynyounuo contrapumpkin sbp ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:41 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)jamqm: rgrinberg hackedy_ terrorjack ▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:46 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ackjhprdup: jgross bitonic cjh` ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:51 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)nqefkrdj: petercommand wedify Intensity ▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:51:56 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zeegmaa: bitonic ertes justan0theruser ▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:01 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)wfzspj: augur ynyounuo mbrcknl_ ▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:06 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)uxfgg: lynn jmagnusj aj ▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:11 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)gdzyz: bitonic sbp jmagnusj ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:16 2018] ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ajccxywd: terrorjack bitonic Intensity ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:21 2018] ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)gjrjtc: ynyounuo zgrepc dmiles ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:27 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)rspdzj: jgross ggherdov terrorjack ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:31 2018] ▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zlohihq: schoppenhauer ynyounuo augur ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:36 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)hezwhb: rgrinberg piyush-kurur lynn ▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 10:52:42 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)nytuamhusz: butterthebuddha sbp jmagnusj ▄▄▄▄▄▄▄▄▄▄▄▄▄ [Mon Jan 1 18:49:46 2018] Hi folks! Does the Coq standard library provide a definition for Nat type? [Mon Jan 1 18:51:08 2018] pnull: yes, it's just nat [Mon Jan 1 18:51:18 2018] a lot of type names in coq are lowercase [Mon Jan 1 18:52:50 2018] Oh, God. Sorry, I mistyped that. I would like to find a Fin type. [Mon Jan 1 18:56:47 2018] https://coq.inria.fr/library/Coq.Vectors.Fin.html this one? [Mon Jan 1 19:00:40 2018] Cypi: It looks like something I want, but doing `Require Coq.Vectors.Fin. Check fin.` gives me an error. How do I properly "import" this package? [Mon Jan 1 19:01:31 2018] `Check Fin.t.` [Mon Jan 1 19:01:48 2018] it doesn't define anything named `fin`, despite what the comments would suggest, just a type `t` [Mon Jan 1 19:02:08 2018] (I guess this is a habit coming from OCaml, where the internal type defined by a Module is often called `t`) [Mon Jan 1 19:02:15 2018] Great, it works. Thank you! [Mon Jan 1 19:02:49 2018] Also, could you please explain me one more thing. [Mon Jan 1 19:03:43 2018] I haven't learned yet what `Set` is, is it ok if I ignore it and pretend it's just `Type`? [Mon Jan 1 19:04:09 2018] It is actually. `Set` could be considered as the lowest `Type` [Mon Jan 1 19:04:29 2018] Thank you once again. [Mon Jan 1 19:15:54 2018] does Set promote to Type? I wouldn't expect it but I'd expect a lot more things to fail than actually do if you use Sets [Mon Jan 1 19:17:19 2018] I'm not sure I understand the question. Just in case, if you have some function that applies on a Type, and you use it on `nat : Set`, then `Set` is not promoted to `Type`. It would be the other way around, the function is instantiated with `Set`. [Mon Jan 1 19:25:37 2018] hrm [Mon Jan 1 19:25:52 2018] well, for example you can do Inductive foo: Set := ... [Mon Jan 1 19:26:06 2018] and then have lists of foo, but list is allegedly Set -> Set [Mon Jan 1 19:26:12 2018] erm [Mon Jan 1 19:26:16 2018] list is allegedly Type -> Type [Mon Jan 1 19:26:16 2018] sorry [Mon Jan 1 19:26:37 2018] there's some extra polymorphism going on in there [Mon Jan 1 19:29:33 2018] Ah. Well, anything typed as a Set can be typed as Type. Now there is still some extra stuff going on to make `list nat` a Set, and not a Type [Mon Jan 1 19:30:20 2018] if it came out as a Type what happens would be indistiguishable from promotion in the traditional sense :-) [Mon Jan 1 19:30:36 2018] Alright, sorry then, I misunderstood what you meant x) [Mon Jan 1 19:32:12 2018] as I recall maps *don't* work this way [Mon Jan 1 19:32:46 2018] anyway, I was just curious. [Mon Jan 1 19:34:21 2018] anytime implicit type conversions get used successfully to avoid user-facing administrative hassles is at least marginally interesting, especially when coexisting with a strong type system. [Tue Jan 2 05:22:17 2018] how do I make Coq believe that n + 0 = n in here? https://gist.github.com/takanuva/c645d2a46e3c9bcb10a0293683da3423 [Tue Jan 2 05:40:14 2018] Theorem vec_c_n: forall {n}, forall v1: Vector n, eq_rect_r Vector (concat v1 Nil) (plus_n_O n) = v1. My best approximation so far [Tue Jan 2 05:50:01 2018] lyxia: that helps, thanks! but it raised a lot more questions now, though... :( [Tue Jan 2 06:07:05 2018] https://gist.github.com/bollu/84a241bcce247b1cfa98c4ad284589a9 <- can I please have some help proving propositions about ListMap? [Tue Jan 2 06:17:05 2018] isn't every nat >= 0 [Tue Jan 2 06:18:02 2018] ignoring that, you need to strengthen your lemma [Tue Jan 2 06:19:33 2018] in the intermediate step, in_proof simplifies to ... (insertNats n somethingNotEmpty) [Tue Jan 2 06:20:41 2018] lyxia, indeed, I was going to make the example harder next, but I couldn't even get this to prove [Tue Jan 2 06:21:55 2018] lyxia what do you mean by "intermediate step"? [Tue Jan 2 06:23:31 2018] bollu_alternate: I mean whatever you get after "simpl in in_proof." once more after tauto. [Tue Jan 2 06:24:05 2018] We get this, right? in_proof : List.In k (keys (insertNats n (add (S n) (S n) NatToNatEmpty))) [Tue Jan 2 06:24:28 2018] Yeah [Tue Jan 2 06:24:37 2018] yes, but, well [Tue Jan 2 06:24:43 2018] How do I use this? :) [Tue Jan 2 06:25:14 2018] the induction hypothesis should quantify on the map [Tue Jan 2 06:26:48 2018] I am not sure what you mean by that. You mean that I should state my theorem for all possible maps? [Tue Jan 2 06:27:06 2018] forall n mm, (forall k, List.In k (keys mm) -> k >= 0) -> (forall k, List.In k (keys (insertNats n mm)) -> k >= 0) [Tue Jan 2 06:27:48 2018] don't introduce mm before doing the induction. [Tue Jan 2 06:28:21 2018] So I have the universal quantifier available, I assume? [Tue Jan 2 06:29:23 2018] I am confused, are you saying that I should try and prove this? forall n mm, (forall k, List.In k (keys mm) -> k >= 0) -> (forall k, List.In k (keys (insertNats n mm)) -> k >= 0) [Tue Jan 2 06:30:57 2018] yes [Tue Jan 2 06:31:46 2018] I am trying that, that makes sense [Tue Jan 2 06:31:51 2018] Also, what does "simpl" do, really [Tue Jan 2 06:31:59 2018] I use it as a black box that knows stuff [Tue Jan 2 06:32:02 2018] but, how does it work [Tue Jan 2 06:32:11 2018] bollu_alternate: by "intermediate step" I was referring to insertNats, which works by successively adding elements to the map [Tue Jan 2 06:32:40 2018] but in your theorem, when you do induction, the induction step assumes something about insertNats on an empty map [Tue Jan 2 06:33:58 2018] bollu_alternate: think of it as beta-reduction [Tue Jan 2 06:34:17 2018] bollu_alternate: about simpl ^ [Tue Jan 2 06:34:33 2018] hm, I see [Tue Jan 2 06:35:15 2018] there are some more rules about opaqueness, but that's the basic idea otherwise. [Tue Jan 2 06:39:51 2018] lyxia: got farther, but I'm stuck again :) https://gist.github.com/bollu/84a241bcce247b1cfa98c4ad284589a9#file-farther-need-right-tactic-v-L47. How do I find the theorem / tactic I need? [Tue Jan 2 06:40:10 2018] I need some "learning how to learn" coq. I know of Search and SearchAbout, but I do not think they are strong enough here [Tue Jan 2 06:44:35 2018] bollu_alternate: you can split on these cases using decidable equality, something like forall n m, {n = m} + {n <> m} [Tue Jan 2 06:44:55 2018] It's somewhere in the stdlib [Tue Jan 2 06:47:05 2018] PeanoNat.Nat.eq_dec [Tue Jan 2 06:48:06 2018] Then with "Search MNat.add" there are some relevant lemmas [Tue Jan 2 06:48:44 2018] I drr [Tue Jan 2 06:48:46 2018] see* [Tue Jan 2 06:48:52 2018] I believe the theorem I need is this: [Tue Jan 2 06:48:54 2018] Theorem key_add_presence: forall (k: nat) (v: nat) (mm : NatToNat) (curk : nat), List.In curk (keys (add k v mm)) -> curk = k \/ List.In curk (keys mm). [Tue Jan 2 06:49:11 2018] you will need to relate the MapsTo predicate to whatever you are doing with List.In and keys [Tue Jan 2 06:49:33 2018] lyxia why do I need to relate MapsTo? [Tue Jan 2 06:49:48 2018] because that's the predicate that's used by the lemmas about MNat.add [Tue Jan 2 06:49:52 2018] I see [Tue Jan 2 06:50:29 2018] OK, I'll check this out :) [Tue Jan 2 06:50:30 2018] ty [Tue Jan 2 06:51:08 2018] yw [Wed Jan 3 12:08:10 2018] What does functionalInduction do, actually? as a tactic [Wed Jan 3 12:08:12 2018] I asked a question here [Wed Jan 3 12:08:13 2018] https://stackoverflow.com/questions/48076202/what-does-the-functional-induction-tactic-do-in-coq [Wed Jan 3 12:08:18 2018] I have some vague intuition about it [Wed Jan 3 12:08:21 2018] but no real insight [Wed Jan 3 12:08:28 2018] could someone please help? :) [Wed Jan 3 12:08:35 2018] lyxia: ping, if you are around! [Wed Jan 3 13:43:10 2018] bollu1: an induction principle is an actual lemma that you can `Print` [Wed Jan 3 13:43:58 2018] I forget the name generation scheme, it’s easier to see with Induction Scheme IIRC [Wed Jan 3 13:44:43 2018] But before reading those, you probably want to understand simpler principles, like dunno, nat_ind [Wed Jan 3 13:45:25 2018] Eventually you should see they’re basically fancier and more dependently typed folds [Wed Jan 3 13:46:04 2018] But on your actual question, I’m not sure what Function’s principles do [Wed Jan 3 13:49:53 2018] Uh, sorry, he went... [Wed Jan 3 14:45:02 2018] anyone answering on SO? [Wed Jan 3 14:50:29 2018] deeglaze: good point [Wed Jan 3 14:59:05 2018] I'm writing an answer. [Wed Jan 3 14:59:50 2018] I haven't dived into the inner workings of what Coq actually does, but I do have experience with induction schemes and what I'm pretty sure Coq does... [Wed Jan 3 15:05:31 2018] deeglaze: I’ve added a comment (I’m Blaisorblade there), but it’s not a full answer [Wed Jan 3 15:06:11 2018] also, I am not sure where bollu1 is stuck on the docs, since quite a few of their questions are answered there [Wed Jan 3 15:50:24 2018] given that he's a beginner, that's likely not the kind of answer he's looking for. [Wed Jan 3 15:51:54 2018] what he wants is most likely "it does induction over the recursive calls in a function" even though that's not a very well-formed statement [Wed Jan 3 15:53:32 2018] (well, "he") [Wed Jan 3 19:17:07 2018] dh`: You might well be right, it’s sad we didn’t catch them on IRC to answer more interactively [Wed Jan 3 20:12:51 2018] oh well [Wed Jan 3 20:12:51 2018] when people ask questions and don't stick around for answers, it's their problem. [Fri Jan 5 05:58:08 2018] how do I split a class definition in a proof? I have only one goal (Monad Foo), I'd like to split it to prove its components [Fri Jan 5 05:58:20 2018] (still learning, studying by myself) [Fri Jan 5 06:13:14 2018] Try "constructor" [Fri Jan 5 06:13:20 2018] or "split" [Fri Jan 5 06:56:50 2018] lyxia: "constructor" gives me "No applicable tactic", and "split" gives me "unable to find an instance for variables Return, Bind" (the class is Monad) [Fri Jan 5 07:01:35 2018] takanuva: Can I see the definition of Monad [Fri Jan 5 07:04:00 2018] lyxia: https://i.imgur.com/2Q8UgSZ.png [Fri Jan 5 07:05:02 2018] takanuva: can you show me how you tried to use those tactics [Fri Jan 5 07:06:17 2018] "constructor." and "split.", since what I'm trying to break is my goal... isn't that right? (sorry, I'm studying by myself!) [Fri Jan 5 07:07:03 2018] if I add the := {} on the Instance, it already breaks the five goals I want... I assume there's a tactic to do that as well [Fri Jan 5 07:08:34 2018] if I write "constructor." I get to prove the five goals. [Fri Jan 5 07:09:01 2018] odd... [Fri Jan 5 07:11:15 2018] oh wait no I simplified too much [Fri Jan 5 07:13:00 2018] oh, I thought it maybe could be the Coq version... I'm running 8.6 here [Fri Jan 5 07:14:15 2018] ah I see it can't split because the laws depend on the definition of Return and Bind [Fri Jan 5 07:15:07 2018] oh [Fri Jan 5 07:16:32 2018] I mean, not with constructor/split. there may be another tactic [Fri Jan 5 07:17:49 2018] at least I already learned something new :D [Fri Jan 5 07:18:43 2018] I noticed that "eexists" does something, but it only gives me the laws instead (and I don't know what to do then) [Fri Jan 5 07:19:13 2018] yeah the "existential" variants of the tactics seem relevant [Fri Jan 5 07:19:20 2018] econstructor. Unshelve. [Fri Jan 5 07:20:06 2018] eexists seems to do the same as econstructor here. [Fri Jan 5 07:20:55 2018] I'm not sure how to avoid shelving and get the same order of goals as with := {} [Fri Jan 5 07:21:21 2018] you might want to look at this https://stackoverflow.com/q/35937980/2747511 [Fri Jan 5 07:21:49 2018] You can use Focus 2. to pick the right goal. [Fri Jan 5 07:22:00 2018] yeah, this is where I took the code from, but I noticed I can use Proof instead of {| ... |}, I took it as an exercise [Fri Jan 5 07:23:25 2018] why "Focus" and "Unshelve" start with a capital letter? [Fri Jan 5 07:25:02 2018] they are commands. [Fri Jan 5 07:27:02 2018] this solves the issue, I can probably write an LTac that splits, unshelves and reorders by myself now [Fri Jan 5 07:27:05 2018] thank you very much :) [Fri Jan 5 07:28:43 2018] takanuva: There is also a Build_Monad function (that is used by those tactics), so if you manage to define Return and Bind you can write apply Build_Monad with (Return := MyReturn) (Bind := MyBind). [Fri Jan 5 07:29:15 2018] lyxia: I'll take note of that, thanks! :D [Fri Jan 5 07:29:38 2018] yw. That's about all I could think of so far. [Fri Jan 5 07:34:08 2018] econstructor also supports binding lists: econstructor 1 with (Return := ...) (Bind := ...) [Fri Jan 5 07:52:42 2018] ohhh [Sat Jan 6 10:42:22 2018] hello. besides embedding or extraction, are there any other methods for obtaining verified programs from coq in an automated fashion? [Sat Jan 6 10:52:59 2018] Sorry if this is a double post, new here... [07:50] To join a channel type: Hello. I am working through Pierce's Logical Foundations and I am stuck trying to prove a trivial theorem about lists. Would you please help me? The details are here: http://lpaste.net/360556 Thank you! [Sat Jan 6 10:59:24 2018] robwebbjr: basically, you need to pattern match on `x` using `destruct x.` [Sat Jan 6 10:59:57 2018] because `beq_id` is defined via pattern matching on its parameters [Sat Jan 6 11:00:21 2018] Hi. thank you so much! [Sat Jan 6 11:00:25 2018] in many cases your proofs reflect the structure of your function [Sat Jan 6 11:00:45 2018] you sort of symbolically execute your function in your proofs [Sat Jan 6 11:01:54 2018] The techniques used up to this point did not seem to work here. Someone mentioned "apply"; what is this command? [Sat Jan 6 11:03:28 2018] it's called a "tactic" (commands are different beasts in Coq, their names start with capital letters) [Sat Jan 6 11:03:47 2018] if your goal matches some lemma you can `apply` the lemma [Sat Jan 6 11:03:56 2018] I'm simplifying a lot [Sat Jan 6 11:04:10 2018] so my description is not really precise [Sat Jan 6 11:04:20 2018] but should get you started [Sat Jan 6 11:06:11 2018] OK, I get it though. [Sat Jan 6 11:06:21 2018] That's what I was missing. [Sat Jan 6 11:07:01 2018] I started with Agda, and stumbled onto Coq, looking for answers from being stuck. [Sat Jan 6 11:07:39 2018] And this is like rewriting using the theorem that you are currently proving. [Sat Jan 6 11:08:04 2018] Which was just presented as an ordinary rewrite in Agda. [Sat Jan 6 11:08:26 2018] Thank you so much. The book hasn't covered tactics yet. [Sat Jan 6 11:09:19 2018] really? As far as I remember the book does that. Is it possible that you have started from the wrong chapter? [Sat Jan 6 11:10:20 2018] Well, I started at chapter 1 of logical foundations. this is chapter 3 and I don't recall any mention of tactics... [Sat Jan 6 11:11:31 2018] the 1st chapter mentiones tactics in Proof by Simplification section [Sat Jan 6 11:15:48 2018] OK, well I'm satisfied with your great help. Thanks again! [Sat Jan 6 11:16:03 2018] No problem! Good luck [Sat Jan 6 11:49:40 2018] hum, I can't figure out how to switch by goal from [Sat Jan 6 11:49:44 2018] (a,b) = (c,d) [Sat Jan 6 11:49:45 2018] to [Sat Jan 6 11:49:52 2018] a = c /\ b = d [Sat Jan 6 11:55:24 2018] enough (a = c /\ b = d) as [-> ->] by trivial. [Sat Jan 6 12:00:01 2018] what does (-> ->] mean [Sat Jan 6 12:00:04 2018] err [Sat Jan 6 12:00:14 2018] alright, I expected smething like using f_equal [Sat Jan 6 12:00:24 2018] * looks up "enough" [Sat Jan 6 12:01:05 2018] it destructs the conjunction and uses both equalities to rewrite in the goal [Sat Jan 6 12:01:55 2018] it's called "intro-pattern" (you can look them up in the manual, they are quite fun to use) [Sat Jan 6 12:02:39 2018] bartavelle: f_equal will do what you want, unless you really want your obligations in a conjunction [Sat Jan 6 12:03:31 2018] anton-trunov: is this intro pattern more common with ssreflect? [Sat Jan 6 12:04:23 2018] I'm no expert but I've only seen it in those proofs [Sat Jan 6 12:04:35 2018] (until now) [Sat Jan 6 12:04:54 2018] yeah, ssreflect proofs use them a lot, but intro-patterns are part of standard Coq for quite a long time [Sat Jan 6 12:05:03 2018] pgiarrusso: I can't seem to be able to use f_equal [Sat Jan 6 12:05:03 2018] well ssreflect is now too [Sat Jan 6 12:05:17 2018] and the "enough" trick gives me Error: Tactic generated a subgoal identical to the original goal. [Sat Jan 6 12:05:31 2018] bartavelle: what Coq version are you on? [Sat Jan 6 12:05:48 2018] 8.6.1 [Sat Jan 6 12:05:50 2018] I tested with Coq 8.7.1 [Sat Jan 6 12:06:07 2018] anton-trunov: ssreflect is merged since 8.7 [Sat Jan 6 12:06:07 2018] argh :( [Sat Jan 6 12:06:14 2018] bartavelle: any dependent types in your goal? [Sat Jan 6 12:06:22 2018] that is my exact goal : http://lpaste.net/3424182772887977984 [Sat Jan 6 12:06:29 2018] in the types of a, b, c, d? [Sat Jan 6 12:07:35 2018] uh [Sat Jan 6 12:07:51 2018] ah but it runs f_equal on the inner pair [Sat Jan 6 12:07:57 2018] (looks like) [Sat Jan 6 12:08:01 2018] wat [Sat Jan 6 12:08:05 2018] not surprised [Sat Jan 6 12:09:05 2018] maybe something like enough a = b as [ -> ] by trivial would be safer [Sat Jan 6 12:09:18 2018] but you need your actual a and b (the functions) [Sat Jan 6 12:09:24 2018] is there a trick to help it figure out this problem? Or an already existing theorem like " (a,c) = (b,c) <-> a = b " [Sat Jan 6 12:09:58 2018] you could just prove that lemma yourself and use it with apply [Sat Jan 6 12:10:05 2018] oh well [Sat Jan 6 12:10:08 2018] I'll just do that [Sat Jan 6 12:10:10 2018] thanks! [Sat Jan 6 12:10:32 2018] (or search for it, but I doubt people would bother adding it to the library) [Sat Jan 6 12:11:36 2018] you might need to specify c to apply to help inference [Sat Jan 6 12:26:18 2018] bartavelle: if you use the `f_equal` tactic, what error message Coq gives you back? [Sat Jan 6 12:31:15 2018] Unable to unify "pair (fun s0 : S => (fun t : S => a (mappend s (mappend s0 t)), snd (a (mappend s s0))))" with [Sat Jan 6 12:31:16 2018] "pair (fun t : S => (fun t0 : S => a (mappend (mappend s t) t0), snd (a (mappend s t))))". [Sat Jan 6 12:34:11 2018] can you try `f_equal.`? (not `apply f_equal.`) [Sat Jan 6 14:52:17 2018] f_equal2 [Sat Jan 6 14:54:08 2018] ah, f_equal the tactic may apply f_equal or f_equal2 (or ...) the lemmas [Sat Jan 6 17:12:01 2018] f_equal on its own worked! [Sat Jan 6 23:19:50 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 kcgnleidge: bacam edwardk dmiles ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Sat Jan 6 23:19:50 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 nnytnao: bacam dmiles schoppenhauer ▄▄▄▄▄▄▄▄▄▄▄ [Sat Jan 6 23:35:52 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 jenticsxd: bitonic ertes leah2 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Sat Jan 6 23:35:52 2018] ▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 wcplpowol: anton-trunov zgrepc otto_s ▄▄▄▄▄▄▄▄▄▄▄▄▄ [Sat Jan 6 23:35:52 2018] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 xpjxcmqjv: dolio otto_s lynn ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ [Sun Jan 7 02:44:49 2018] jgross: ping [Sun Jan 7 09:51:56 2018] huh, I just found http://web.mit.edu/cpitcla/www/coq-rst/tactics.html [Sun Jan 7 09:52:01 2018] created by https://www.csail.mit.edu/person/clement-pit-claudel apparently [Sun Jan 7 09:52:22 2018] (in Chlipala's research group at MIT) [Sun Jan 7 12:09:01 2018] how can I change the keybindings of proof general in emacs? [Sun Jan 7 13:33:09 2018] I am trying to understand Calculus of Constructions, but I have forgotten the basic formalities. Can someone point me to learning materials? [Sun Jan 7 13:37:08 2018] I want to be able to create proof trees through rules of inference (Am I right on this?) [Sun Jan 7 15:48:34 2018] Hi, when extracting to ocaml is it possible to map string to ocaml's string type? I see there is this issue: https://github.com/coq/coq/issues/2747 [Sun Jan 7 15:55:49 2018] it will be at best hard [Sun Jan 7 15:55:56 2018] also strings in coq kinda suck [Sun Jan 7 15:56:00 2018] (at least for now) [Sun Jan 7 15:57:08 2018] ocaml's string type is opaque; coq's is inductive [Sun Jan 7 15:57:19 2018] you'll have to e.g. never match on strings, which means you can't prove anything at all [Sun Jan 7 15:57:26 2018] or write much of anything at all [Sun Jan 7 16:05:20 2018] and there's next to no existing string library to fall back on, either [Sun Jan 7 16:05:27 2018] (I've been working on that) [Sun Jan 7 16:13:06 2018] errr, what's wrong with extraction directive ? sure the extracted code might not be stellar in terms of efficiency if you do the minimal amount of work, but I don't see why it shouldn't work as easily as nat in principle ? https://coq.inria.fr/distrib/current/refman/extraction.html#sec818 [Sun Jan 7 16:16:13 2018] it runs, it gives output that is not ocaml strings [Sun Jan 7 16:16:22 2018] (or ocaml characters either, afaik) [Sun Jan 7 16:22:00 2018] I don't see why the "Extract Inductive" directive on both ascii and string to get ocaml strings as output [Sun Jan 7 16:22:42 2018] I mean as per the example beneath the line " [Sun Jan 7 16:22:43 2018] As an example of translation to a non-inductive datatype, let’s turn nat into Ocaml’s int (see caveat above): [Sun Jan 7 16:22:46 2018] " [Sun Jan 7 16:22:52 2018] in the refman page I quoted [Sun Jan 7 16:23:42 2018] (sorry I am unable to run coq right now to double-check this; I do remember having used those directive in the past for similar purposes though) [Sun Jan 7 16:28:29 2018] Perhaps it would be possible to use functors and provide the implementation in ocaml? [Sun Jan 7 16:29:00 2018] I don't konw. I have yet to look into this part of things [Sun Jan 7 16:29:13 2018] started to a while back, but then got distracted by RL [Sun Jan 7 16:30:08 2018] darktenaibre: examples I've seen go as far as mapping ascii to char, but not as far as mapping list of char to string [Sun Jan 7 16:31:10 2018] dh: to write a better string library? [Sun Jan 7 16:36:00 2018] Extract Inductive string => "string" [ "\"\"" (fun a b -> (string_of_char a) ^ b)"] "(fun e c s -> if s = "" then e else c s.[0] (String.sub s 1 (String.length s - 1)))" [Sun Jan 7 16:37:17 2018] (untested ass-pull, supposing you did ascii -> char) [Sun Jan 7 16:38:35 2018] jmagnusj: I have been working on a string library ever since I discovered coq doesn't come with a String_as_OT [Sun Jan 7 16:38:45 2018] so you can't have maps from string to t without writing your own [Sun Jan 7 16:39:20 2018] I have mostly been working on the code itself (as in, what string operations to have, what to call them, etc.) and its proofs, and thinking about how to present it as a library [Sun Jan 7 16:40:00 2018] extraction is on my list of things to worry about but real life stuff intervened shortly after I started looking into it [Sun Jan 7 16:44:45 2018] darktenaibre: Extract Inductive string => "string" [ """""" "(fun a b -> (string_of_char a) ^ b)"] "(fun e c s -> if s = "" then e else c s.[0] (String.sub s 1 (String.length s - 1)))". [Sun Jan 7 16:45:05 2018] w [Sun Jan 7 16:45:05 2018] darktenaibre: that seems to work except literals aren't translated to literals [Sun Jan 7 16:45:39 2018] darktenaibre: "+" maps to ((fun a b -> (string_of_char a) ^ b) ('+', "")) [Sun Jan 7 16:46:36 2018] dh: cool, that seems like a worthwhile project. This is probably something everyone who wants to do program extraction runs into [Sun Jan 7 16:47:17 2018] and while it's not a blocker it certainly is a bit offputting [Sun Jan 7 16:48:30 2018] having to do all your own string stuff is a barrier that presumably anyone who tries to do anything text-oriented runs into, extraction or not [Sun Jan 7 16:48:50 2018] I already have about 10,000 lines of material and it's not remotely finished [Sun Jan 7 16:51:52 2018] standar library's ExtrOcamlString has this: Extract Inductive string => "char list" [ "[]" "(::)" ]. [Sun Jan 7 16:53:20 2018] dh: wow, that's a lot. Perhaps there's a smaller kernel of the most basic functionality that can be published? [Sun Jan 7 16:55:28 2018] darktenaibre: One can hope that the ocaml compiler is smart enough to evaluate the string at compile time. In worst case you can give the strings names and evaluate them once so this goes pretty far. [Sun Jan 7 16:58:19 2018] dh: is your effort related to this? https://github.com/mit-plv/fiat/blob/master/src/Common/String_as_OT.v [Sun Jan 7 17:01:09 2018] no [Sun Jan 7 17:01:20 2018] I'm sure there are a bunch of String_as_OT implementations [Sun Jan 7 17:01:40 2018] jmagnusj: the goal is to have a real string library (comparable to, say, python) [Sun Jan 7 17:04:47 2018] dh: gotcha. cool [Sun Jan 7 17:14:42 2018] the size isn't that surprising; basically you end up with O(n^2) lemmas when you apply any one string op to any other [Sun Jan 7 17:15:06 2018] and so far I haven't tried to shorten the proofs by writing ltac (and I'm not convinced anything would actually end up shorter) [Sun Jan 7 17:16:31 2018] oh, since that bug report was on github: is github or the inria bugzilla I have a link for somewhere the proper place to file bugs? [Sun Jan 7 17:30:20 2018] dh`: the Coq team uses Github pretty much for everything nowadays, so you should file your issues on gihub [Sun Jan 7 17:31:58 2018] noted [Sun Jan 7 17:55:10 2018] jmagnusj: yeah, efficient translation of litterals is something I wouldn't know how to deal with automatically; I guess that if you only have very few of them in your program, you may pack them in a Definition and use "Extract Constant" as a crutch (and my gut feeling is that the ocaml compiler might not be too stellar in optimizing this kind of code, but I don't know really) [Sun Jan 7 17:55:37 2018] hmm [Sun Jan 7 17:55:54 2018] looking at the extraction manual again, I don't see any reason why it shouldn't be possible to do it the same way as it shows for nat [Sun Jan 7 17:56:02 2018] (and it may already, haven't tried) [Sun Jan 7 17:56:07 2018] but it'll still be pretty crap code [Sun Jan 7 17:57:34 2018] yes; but if you're going to do this, you might as well use Extract Constant for any function defined in the OCaml stdlib to achieve similar efficiency [Sun Jan 7 17:59:09 2018] (you may both shadow term with this directive, or just use it on axioms and axiomatize the stdlib iirc) [Sun Jan 7 17:59:35 2018] the ocaml string library doesn't have a whole lot in it, and it's not proven correct either ;-) [Sun Jan 7 18:00:29 2018] I think the right way to do it is to provide equivalences from normal coq code to coq code written in the style of ocaml strings (which doesn't require mutation but does typically require e.g. for-loops) [Sun Jan 7 18:01:35 2018] and then have the extraction specifically use the ocaml-style ones when doing ocaml extraction, so what you get out (for the string library code anyway) is decent ocaml code that the ocaml compiler can do something useful with. [Sun Jan 7 18:01:54 2018] but you don't want this for haskell extraction since haskell has a quite different model of strings. [Sun Jan 7 18:04:26 2018] this only helps your own string code if you avoid ever doing matching or consing of strings yourself, though. [Sun Jan 7 18:17:09 2018] of course, this assumes it works. Is it possible to tell the extraction system to extract foo' when asked for foo? [Sun Jan 7 18:39:26 2018] yes, this is what "Extract Constant" does [Sun Jan 7 19:34:50 2018] ah, it doesn't have to be a string on the RHS, but can be something else to be extracted recursively? [Sun Jan 7 19:40:01 2018] bah [Sun Jan 7 19:40:17 2018] is there a way to state assumptions that coqide doesn't label yellow? [Sun Jan 7 19:41:03 2018] I would like it (temporarily at least) to mark only missing obligations (e.g. admits) yellow, and not axioms [Sun Jan 7 20:19:33 2018] ok, I think I'm a good way towards making this extract decently [Sun Jan 7 20:21:09 2018] next question is how to concoct something for coq that can extract to an ocaml for-loop [Sun Jan 7 20:21:24 2018] maybe just fold_left will work... [Sun Jan 7 20:22:09 2018] but I kinda want to prove equivalence somehow [Sun Jan 7 20:38:33 2018] dh`: sorry to ask, but do you plan to open-source this eventually? If so, why not OS IT [Sun Jan 7 20:38:46 2018] *OS it now? [Sun Jan 7 20:59:59 2018] dh, that's unfortunate if you need O(n^2) proofs [Sun Jan 7 21:00:29 2018] dh`, I'm sure you've thought about whether there's a better approach [Sun Jan 7 23:29:52 2018] you want the O(n^2) proofs, and not very many of the lemmas are hard [Sun Jan 7 23:29:56 2018] erm [Sun Jan 7 23:30:04 2018] you want the O(n^2) lemmas, and not very many of the proofs are hard (or long) [Sun Jan 7 23:31:10 2018] pgiarrusso: of course it will be, since the goal is to get it merged upstream (in the coq standard library) [Sun Jan 7 23:31:39 2018] but it's not done and posting not-done stuff in public has rarely proved beneficial in the past [Sun Jan 7 23:32:53 2018] ...however, that was an interesting proof I just did so maybe I should post it somewhere anyway [Sun Jan 7 23:33:20 2018] needed to generalize before inducting, but then weaken the generalization [Mon Jan 8 03:46:58 2018] dh`: most open-source projects are indeed ignored, but you want this merged upstream and used [Mon Jan 8 03:47:19 2018] dh`: which means that you want other people to approve of the design [Mon Jan 8 03:48:08 2018] dh`: so, either you come up with the perfect design alone, or you get others involved early [Mon Jan 8 03:49:05 2018] dh`: to avoid the O(n^2) lemmas, can’t you follow the same trick as shortcut or stream fusion? prove that all the functions can be expressed using some primitive, then devise some fusion/swap lemmas? [Mon Jan 8 03:51:13 2018] in Haskell you can *write* the functions using some primitive and get the compiler to optimize them together (mostly); that doesn’t work in OCaml, but the equivalences should keep holding (at least when the function arguments of the primitives are total) [Mon Jan 8 03:58:59 2018] or let me rephrase: that doesn’t “just work”, but it suggests you might not have to prove O(n^2) lemmas, or at least not fully independently [Mon Jan 8 03:59:22 2018] (but I’m not an expert of fusion and fusion rules) [Mon Jan 8 04:02:01 2018] but even if you don’t like such feedback, you’ll get it sooner or later if you want it merged... so trying to develop this alone sounds a bit like hybris ;-) [Mon Jan 8 04:51:20 2018] well, maybe. let me put it another way: it's not ready for anyone else to look at until it's gotten quite a bit further. [Mon Jan 8 04:51:54 2018] as for fusion, I'm not sure what you mean. [Mon Jan 8 04:53:40 2018] as a random example, though, consider forall x xs, String.In x xs -> exists m, String.find x (String.concat xs) = Some m. [Mon Jan 8 04:53:51 2018] actually that should be List.In [Mon Jan 8 04:54:26 2018] where find looks for the offset of a substring (like strstr in C) and String.concat concats a list of strings into one string [Mon Jan 8 04:55:05 2018] the proof for this is neither long nor difficult (although I don't think it's one I've done yet) [Mon Jan 8 04:55:56 2018] basically it goes by induction xs, and either x is the first in xs and the offset is 0, or you go by the induction hypothesis. [Mon Jan 8 04:56:42 2018] but so far I haven't seen any useful way to automate the proofs, let alone automate writing the lemmas somehow. [Mon Jan 8 04:57:23 2018] or for another one, forall c x xs, List.In x xs -> String.In c x -> String.In c (String.concat xs) [Mon Jan 8 05:07:48 2018] or, say, forall f k n, k < n -> String.In (f k) (String.init f n). (where init is like in ocaml) [Mon Jan 8 05:09:42 2018] or forall xs, String.length (String.concat xs) = nat_sum (map String.length xs) [Mon Jan 8 05:10:07 2018] there's just a lot of these if one's trying to be complete, and I am [Mon Jan 8 08:23:17 2018] hey. I created a simple inductive type "Truebox : bool -> Set := | truebox : Truebox true". now I want to prove that "Truebox false -> False", i.e. there's no way to construct Truebox false, which is obvious because the truebox constructor discards its bool argument and always uses constant true instead. the term for this is simple, and with refine the proof is "refine (fun F : Truebox false => match F with end)." [Mon Jan 8 08:24:42 2018] my question is: can the same term be generated using case or some other tactic that doesn't involve just using the term language? in other words, is there a more tactical way to prove this? I've tried looking through the manual for different ways to invoke "case" but I couldn't find one that works. case itself generates "match F with | truebox => ?Goal end" [Mon Jan 8 08:25:09 2018] `inversion` will do that. `intros H; inversion H.` or just `inversion 1.` completes your goal. [Mon Jan 8 08:26:10 2018] (the proof term will be uglier though) [Mon Jan 8 08:26:24 2018] Cypi: ah beautiful, thanks! yeah, that's fine though since that's pretty much expected with tactics [Mon Jan 8 08:29:38 2018] ironically I had already looked at the proof term that inversion generated, but I didn't think to check to see if it actually completed the proof. heh [Mon Jan 8 08:30:12 2018] it didn't look like the short term I wanted so I just ignored it [Mon Jan 8 08:52:31 2018] sbp: haven’t checked, but `intros H; dependent destruction H.` might also do that proof, and with a smaller proof term [Mon Jan 8 08:58:51 2018] dh`: “not ready to look at until it’s gotten further” is often a fallacy, I’m not sure this is an exception (unless people will pile on you with negative criticism, which seems unexpected) [Mon Jan 8 09:01:01 2018] dh`: “fusion” refers to either loop fusion (in imperative languages) or shortcut fusion/stream fusion (in functional languages, often Haskell) [Mon Jan 8 09:01:54 2018] fusion tries to remove intermediate data structures from string-processing pipelines (not relevant here), which would naively need O(n^2) rules [Mon Jan 8 09:02:23 2018] to avoid that, all operators are expressed into some primitive, then some rewrite rules are used for optimization [Mon Jan 8 09:02:35 2018] that general strategy seems potentially helpful here [Mon Jan 8 09:03:14 2018] for instance, your length/concat lemma (11:09 AM or forall xs, String.length (String.concat xs) = nat_sum (map String.length xs)) seems to involve swapping folds [Mon Jan 8 09:04:05 2018] I’m not an expert of the right research area, but it should be possible to derive such theorems from more general principles [Mon Jan 8 09:05:59 2018] dh`: one well-known paper on the topic is https://www.dropbox.com/s/7chntgnevsoc3fl/A%20tutorial%20on%20the%20universality%20and%20expressiveness%20of%20fold%20-%20fold.pdf?dl=0 [Mon Jan 8 09:06:17 2018] but there are people who are far more qualified than me to comment [Mon Jan 8 09:06:46 2018] (this is the whole Squiggol research tradition, which merged into Haskell more than ML) [Mon Jan 8 12:02:28 2018] pgiarrusso: gives me a syntax error in Coq 8.7.1. strange though, the manual indicates it should be okay. (error: "'induction' or 'generalize_eqs_vars' or 'generalize_eqs' or 'rewrite' or 'simple' 'inversion' expected after 'dependent' (in [tactic:simple_tactic])") [Mon Jan 8 12:05:08 2018] sbp: missing some import, or using a different manual version? [Mon Jan 8 12:05:31 2018] (needed imports are somewhere in the manual) [Mon Jan 8 12:09:34 2018] oh yes, sorry. needed Coq.Program.Equality. thanks! [Mon Jan 8 13:29:15 2018] pgiarrusso: there's a level of doneness before which posting work in progress isn't helpful [Mon Jan 8 13:29:31 2018] especially when further progress is slow [Mon Jan 8 13:30:02 2018] it is time I posted on coq-club about the general layout of the thing [Mon Jan 8 13:30:21 2018] but that's about it for the time being. [Mon Jan 8 13:31:00 2018] as for fold fusion, now I see what you mean. yes, many string ops can be written as folds and fusing compound folds is a nice way to do certain things [Mon Jan 8 13:31:00 2018] but [Mon Jan 8 13:31:23 2018] reasoning about folds in coq is a gigantic pain (I have already complained about this a number of times ;-) ) [Mon Jan 8 13:31:44 2018] and so none of the functions are written as folds natively so proofs go through. [Mon Jan 8 13:32:16 2018] this might be a good way to automate string proofs, and I will definitely think on that [Mon Jan 8 13:32:38 2018] but I don't see any way to derive an automated way to *write down* the O(n^2) lemmas [Mon Jan 8 13:32:44 2018] if you know of one, please share [Mon Jan 8 13:46:11 2018] for the proofs, seems like one can write down a fold version of each function (these are maybe wanted anyway for ocaml extraction), prove each equivalent, then use a private hint database to apply the equivalences, then write some automation on the resulting folds [Mon Jan 8 13:46:22 2018] might work, worth a try. [Mon Jan 8 14:21:32 2018] dh`: yep — once you rewrite as much as possible to folds, some theorems should be reducible to general theorems on folds [Mon Jan 8 14:22:06 2018] one annoyance is that running those folds sometimes works better with *lazy* folds — that doesn’t matter in Coq, but it might affect extraction [Mon Jan 8 14:23:20 2018] for instance, you can search for the first element satisfying `p` with a `fold_right`, but an eager `fold_right` will IIRC always scan the entire list [Mon Jan 8 14:25:10 2018] also, GHC’s optimizer is aggressive enough it can be convinced to fuse compound folds often, while OCaml’s optimizer is much more predictable but also conservative [Mon Jan 8 14:25:37 2018] but all these questions about optimizations affect only extraction to OCaml, not the proofs [Mon Jan 8 15:49:37 2018] the reason to write in terms of folds for extraction to ocaml is that what I was doing last night was writing and proving an embedding of string.foldi_left in an ocaml for-loop [Mon Jan 8 15:50:52 2018] even if extracting a composition of these generates terrible code (as it probably will) it'll still beat faking pattern-matching on ocaml strings. [Mon Jan 8 16:16:21 2018] I’m sure you know more OCaml than me :-) [Mon Jan 8 16:16:44 2018] however: I’d guess fold_left *will* throw a wrench into proofs [Mon Jan 8 16:17:04 2018] using just fold_right works nicely for proofs [Mon Jan 8 16:18:20 2018] though `fold_left` might help in an eager language? (not sure?) maybe `fold_right` with thunks will do better though [Mon Jan 8 16:19:15 2018] simply encoding call-by-name with `Unit -> T` should be “lazy enough” to write a search using `fold_right` — and it’s a search finding the *first* match [Mon Jan 8 18:57:43 2018] easier to write a custom thing that extracts to a loop that stops early [Mon Jan 8 18:57:53 2018] at least, assuming ocaml allows that, which on reflection I'm not sure about [Mon Jan 8 19:02:57 2018] what tactic can I use to turn "|- {x : nat & P x}" into "|- P ?x" [Mon Jan 8 19:03:37 2018] `eexists` or `econstructor` should work I think [Mon Jan 8 19:04:04 2018] ooh, thanks [Mon Jan 8 19:32:38 2018] pgiarrusso: I don't know that much about ocaml really, only really used it for one real project so far [Mon Jan 8 19:32:53 2018] the important thing though is that its string type isn't an inductive type. [Mon Jan 8 19:49:55 2018] and, internally, strings aren't cons-lists, so manipulating them like they are is expensive [Tue Jan 9 10:47:39 2018] I am trying to rewrite a Fixpoint to Inductive, but I am not sure if I have written my Inductive correct: https://gist.github.com/Steverman/05421617bcca1774dfec6b1594fbfe1e [Tue Jan 9 10:50:03 2018] This looks correct to me. However, I would not use equalities for e_n2_eq and so on, but directly `e_n2_eq : forall n t1 t2, Elem' n (Node2 t1 n t2)`. [Tue Jan 9 10:50:14 2018] both are correct I think, it's just a matter of taste [Tue Jan 9 10:50:29 2018] I see [Tue Jan 9 10:51:08 2018] And changing between them also changes how the proof is made? [Tue Jan 9 10:51:17 2018] written* [Tue Jan 9 10:51:35 2018] You mean, between with an equality or without? [Tue Jan 9 10:51:42 2018] Fixpoint and Inductive [Tue Jan 9 10:51:46 2018] oh, right [Tue Jan 9 10:52:19 2018] Because I am trying it out on an old proven Lemma [Tue Jan 9 10:52:22 2018] Well in this case, it should not matter much. But having an Inductive allows you to perform an induction directly on it [Tue Jan 9 10:52:30 2018] that's often more natural [Tue Jan 9 10:52:51 2018] (you should be able to write the same induction principle for the Fixpoint version of course, it's just that you get it for free with the Inductive) [Tue Jan 9 10:52:52 2018] This for example: forall t k, Elem' k (Insert k t). [Tue Jan 9 10:53:27 2018] Which I did induction on the tree on [Tue Jan 9 10:53:43 2018] Sorry, -on [Tue Jan 9 11:08:23 2018] I get stuck here: https://i.imgur.com/PskEZvo.png [Tue Jan 9 11:09:56 2018] The hypothesis IHt1 should get you everything you need [Tue Jan 9 11:10:18 2018] If you use `inversion` on it, it should give you three subgoals which will be easy to solve [Tue Jan 9 11:10:42 2018] Ah, I thought it was wrong to do :) [Tue Jan 9 11:12:29 2018] I end up in the same situation in the third goal [Tue Jan 9 11:12:58 2018] Oh maybe.. [Tue Jan 9 11:13:14 2018] No :( [Tue Jan 9 11:13:20 2018] In the third goal you should have `Elem' k t0` in your hypotheses, shouldn't you? [Tue Jan 9 11:13:32 2018] I do, but goal is Elem' k t [Tue Jan 9 11:13:57 2018] How has the goal changed? In your image it's `Elem' k (Node3 ...)` [Tue Jan 9 11:14:04 2018] have you used `constructor`? [Tue Jan 9 11:14:25 2018] apply e_n3_left. [Tue Jan 9 11:14:33 2018] Oh [Tue Jan 9 11:14:40 2018] I see [Tue Jan 9 11:14:40 2018] Well, why this one? [Tue Jan 9 11:14:41 2018] ;D [Tue Jan 9 11:14:44 2018] ok x) [Tue Jan 9 11:15:18 2018] Thanks! [Tue Jan 9 11:18:22 2018] 16:53 < Cypi> Well in this case, it should not matter much. But having an Inductive allows you to perform an induction directly on it [Tue Jan 9 11:18:36 2018] feels like `functional induction` ought to deliver the same functionality [Tue Jan 9 11:30:20 2018] Cypi: I am not exactly what I am doing here. It works, but I don't have the overall idea [Tue Jan 9 11:34:20 2018] So I suppose I am doing case analysis on comparison ( ?= ), and right now I am at "Lt". For the Node2 case, it is easy to use the constructor, as it has to be left subtree because (k < n). [Tue Jan 9 11:38:31 2018] inversion IHt1 creates 2 additional subgoals, where I applied "e_n3_eq1", "e_n3_left" and "e_n3_middle" [Tue Jan 9 11:49:43 2018] johnw: pong [Tue Jan 9 12:40:03 2018] Does this make sense? I made a map function for trees. I want to prove: Lemma Elem_map : forall (f : nat -> nat) (k : nat), exists (t : Tree), + Elem' (f k) (tree_map f t). [Tue Jan 9 12:41:56 2018] Elem is a predicate defining a proposition about whether a key belongs to a tree [Tue Jan 9 12:42:37 2018] The only reason why I used exists is because the tree can be empty [Tue Jan 9 12:57:35 2018] gallais: when `functional induction` works well you’re probably right [Tue Jan 9 13:28:37 2018] jgross: I've forgotten now what that ping was for :) [Tue Jan 9 14:00:37 2018] Slight change: Lemma Elem_map' :forall (f : nat -> nat) (k : nat) (t : Tree), Elem' k t -> Elem' (f k) (tree_map f t). [Wed Jan 10 10:53:45 2018] can I prove in Coq that (exists x1, ..., exists xn, foo) <-> forall p: (exists x1, ..., exists xn), foo? (i.e., "extracting" the "rightmost" nested type from the existential) [Wed Jan 10 10:55:38 2018] if i get what you want to do, probably you can destruct the type. [Wed Jan 10 10:57:21 2018] Let's say n=1 for simplicity. What you want if I understand correctly is `(exists (x : T), foo) <-> (forall (p : T), foo)`, so if your types are not dependent, you want an equivalence between `T * foo` and `T -> foo`. That's not possible in general [Wed Jan 10 10:57:56 2018] I'm still learning Coq, I'd like to state this theorem, but I don't know how I can make this for an arbitraty number of nested "exists" clauses... I mean, I would need to match on the type of the second element to see if it is an existential as well [Wed Jan 10 10:59:00 2018] it's impossible to prove, or is it just not true in geral? (I'm trying to check this on the dependent case, foo may depend on the previous assumptions) [Wed Jan 10 11:00:01 2018] It's not true. Unless what you've written is not what you want [Wed Jan 10 11:00:28 2018] The left hand-side of your equivalence is basically a tuple with (n+1) elements, while the right hand-side is a function that takes a tuple with n elements and return 1 value [Wed Jan 10 11:03:10 2018] e.g., I'd like to show that ~(exists x: nat, exists y: nat, foo x y) is logically equivalent to ~(forall p: (exists x: nat, nat), foo (fst p) (snd p)), that I could curry the last item [Wed Jan 10 11:03:36 2018] (in this case, n = 2, but if possible I could show that for any n) [Wed Jan 10 11:05:27 2018] But it's not I think? Take for instance `foo x y := x = y`. In that case you mean to prove that `exists x, exists y, x = y` is equivalent to `forall (p : exists x, nat), fst p = snd p`, which is false [Wed Jan 10 11:05:39 2018] The first one is provable, while the second is simply false [Wed Jan 10 11:07:05 2018] lemme check that particular example here... if this is not true as you said, I'll have major problems with the calculus I'm trying to make :( [Wed Jan 10 11:07:43 2018] If you're talking about currying, maybe you mean something like: `(forall p: (exists x1, ..., exists xn, foo), T) <-> (forall p: (exists x1, ..., xn), foo -> T)` [Wed Jan 10 11:13:01 2018] oh, of course! [Wed Jan 10 11:13:15 2018] that isn't supposed to be a "forall", that's supposed to be another exists [Wed Jan 10 11:13:44 2018] Right, that would work too [Wed Jan 10 11:13:50 2018] so ~(exists x: nat, exists y: nat, foo x y) <-> ~(exists p: (exists x: nat, nat), foo (fst p) (snd p)) [Wed Jan 10 11:14:34 2018] That's certainly provable. But as you said, it's not very easy to express for any `n`. [Wed Jan 10 11:15:29 2018] I'm working on a dependent continuation-passing style calculus for my master's, I'd like to conjecture that such conversion is sound for any n, then I got curious if it would be provable in Coq [Wed Jan 10 11:18:26 2018] is it impossible, or just difficult? [Wed Jan 10 11:18:45 2018] just difficult (I'm trying to write something about one way to do it, I think) [Wed Jan 10 11:21:09 2018] So...I should try to do it to make sure it's reasonable, but I would start by defining a type of nested existentials (aka telescopes) of length n, something basically equivalent to `exists x1, ..., xn` [Wed Jan 10 11:21:44 2018] Then you need a function to extract the last Type in this telescope. Except that it can't be just a `Type`, since it might depend on the head of the Telescope... [Wed Jan 10 11:22:11 2018] If you have these ingredients, you can state what you want in terms of this kind of Telescopes [Wed Jan 10 11:24:21 2018] hm, I'll try that [Wed Jan 10 11:24:24 2018] thank you very much :) [Thu Jan 11 08:20:33 2018] Is it possible to prove (forall (A:Type) (a b: A), {a=b}+{~a=b}) -> False? [Thu Jan 11 08:20:54 2018] In other words, is there a type that has provably undecidable equality? [Thu Jan 11 08:21:08 2018] No, since Coq is consistent with classical axioms [Thu Jan 11 08:29:47 2018] Cypi, thank you [Thu Jan 11 08:30:20 2018] another question, if I have a function of type "forall (A:Type), A -> nat" then can I show that the function can not distinguish different objects of type A? [Thu Jan 11 08:31:30 2018] In the metatheory it's a parametricity result and you certainly can. But internally, I don't think so. That is, you won't be able to prove something like `forall A x y, f A x = f A y` [Thu Jan 11 08:33:06 2018] thanks again [Thu Jan 11 09:12:55 2018] hi. If I have a proof that a certain natural number exists, I can't use it in fixpoints for some reason related to proofs being in Prop and not Type that I don't fully understand. But could I write a program that searches for the number, turning my proof that the number exists into a proof that the program will terminate? Or would that run into the same typing problems? [Thu Jan 11 09:13:20 2018] I have no upper bound for the number unfortunately. [Thu Jan 11 09:35:38 2018] Migi32: unfortunately you can't do this [Thu Jan 11 09:35:46 2018] oh actually hmm hold on [Thu Jan 11 09:36:17 2018] well, i do know you can't use [~~exists n, P n] as a proof of termiantion to search for a number - but if you have actual exists, id have to consider [Thu Jan 11 09:37:05 2018] but fwiw the Prop thing is that you can't eliminate a value whose type is a Prop if the result of the elimination has a type which isn't a Prop [Thu Jan 11 09:37:29 2018] *except* for some special cases for single-constructor types and empty types iirc [Thu Jan 11 09:37:39 2018] this basically enforces proof irrelevance [Thu Jan 11 09:38:05 2018] but Qed marks terms opaque anyway so you can't really compute with proofs that use other proofs ended with Qed [Thu Jan 11 09:38:07 2018] it's kind of a pain [Thu Jan 11 09:38:26 2018] should i https://i.imgur.com/EXcbaYg.png [Thu Jan 11 09:38:32 2018] fuck wrong channel lmao [Thu Jan 11 09:39:46 2018] I'd fill out that question the same :) [Thu Jan 11 09:39:50 2018] heh [Thu Jan 11 09:40:16 2018] Migi32: in theory you should be able to rewrite the exists proof into a { | } though [Thu Jan 11 09:40:23 2018] unless the proof relies on axioms [Thu Jan 11 09:40:51 2018] hmm, it doesn't rely on axioms [Thu Jan 11 09:41:05 2018] or even if the proof relies on axioms, actually, as long as you don't eliminate them as part of determining thje nat [Thu Jan 11 09:41:11 2018] could you link me to the documentation about {|}? It's not really something I can google easily [Thu Jan 11 09:41:20 2018] right haha [Thu Jan 11 09:41:39 2018] it's technically called "sig" https://coq.inria.fr/library/Coq.Init.Specif.html [Thu Jan 11 09:41:55 2018] it's just exists but in Type [Thu Jan 11 09:42:26 2018] so you can eliminate it into Type, but on the other hand you cant eliminate Props into it [Thu Jan 11 09:42:31 2018] https://coq.inria.fr/library/Coq.Logic.ConstructiveEpsilon.html isn't this what you need to go from `exists n, P n` to `{n : nat | P n}`? [Thu Jan 11 09:42:44 2018] aha [Thu Jan 11 09:42:47 2018] probably :D [Thu Jan 11 09:42:50 2018] i forgot about that [Thu Jan 11 09:42:55 2018] Migi32: http://seb.mondet.org/blog/post/coqtests-01-subsets.html might help [Thu Jan 11 09:43:07 2018] I'll check out all of these things thanks [Thu Jan 11 09:43:10 2018] You do need P to be decidable, of course [Thu Jan 11 09:43:30 2018] ah, of course [Thu Jan 11 09:43:45 2018] well, i guess itd be silly to ask the original question if P wasnt decidable [Thu Jan 11 09:43:47 2018] :V [Thu Jan 11 09:45:24 2018] i remember struggling with an issue along these lines once, getting linked to ConstructiveEpsilon, browsing thru the code, and punching myself in the face when i saw how they did the thing [Thu Jan 11 09:46:47 2018] to be precise: you cant eliminate the recursive argument if it's a prop and you're resulting in a type - [Thu Jan 11 09:48:38 2018] buuuuuuuuuuuuuuuuuuuuut if you can decide externally in Type whether it's gonna be a leaf or a branch, then you CAN eliminate it *in the recursive argument* since that's a prop you can eliminate into [Thu Jan 11 09:49:36 2018] i.e. you cant do match rec_arg with O' => foo | S' rec_arg' => this_func rec_arg' end [Thu Jan 11 09:50:44 2018] but you *can* do match decide rec_arg with left done => foo | right notdone => this_func (match rec_arg with O' => contradiction_with_notdone | S' rec_arg' => rec_arg') end [Thu Jan 11 09:51:19 2018] well, of course decide can't do that based on rec_arg itself as an argument, but if you have another argument you're carrying with you that rec_arg is parameterized over, yadda yadda [Thu Jan 11 09:52:05 2018] e.g. rec_arg is a <= proof and you bring along the number so that you can compute whether the <= with the number is of the right form [Thu Jan 11 12:28:06 2018] aaah, so ConstructiveEpsilon implements Migi32’s idea to “search for some n such that P n”, right? I’ve just read the initial comment [Thu Jan 11 19:30:55 2018] hrm, how dangerous is it to write "Axiom external_foo: string -> string." and extract it to something in ocaml that's non-stateless? [Thu Jan 11 19:31:47 2018] obviously it's not a good idea, but as long as it's deterministic it doesn't seem immediately obviously wrong, either. [Thu Jan 11 22:33:28 2018] how about doing a module instead [Fri Jan 12 04:52:12 2018] dh_work: non-stateless but deterministic isn’t enough; if it’s non-stateless but observably pure you’re fine (so a mutable memoization cache is no problem) [Fri Jan 12 04:53:44 2018] dh_work: otherwise you’d be postulating the lie that external_foo is a pure function when it isn’t and hell would break lose [Fri Jan 12 04:55:07 2018] benzrf: an axiom here is just as sound, though a module might be more flexible (you can apply the module to an axiom but also to something else) [Fri Jan 12 06:19:46 2018] I have a premiss that looks like this: [Fri Jan 12 06:19:49 2018] IH : forall (a : A) (b : B), C = D -> E = F [Fri Jan 12 06:19:54 2018] how do I match it in Ltac? [Fri Jan 12 06:20:02 2018] I tried: [Fri Jan 12 06:20:33 2018] | [ IH : forall _ _, ?A -> ?B |- _ ] => [Fri Jan 12 06:20:50 2018] but I get "no matching clause" error [Fri Jan 12 09:00:08 2018] jstolarek: your thing looks about right, also against examples in http://adam.chlipala.net/cpdt/html/Cpdt.Match.html, so I’m wondering about (a) reusing `IH` might be bad (b) do `C`, `D`, `E`, or `F` use `a` or `b`? behavior in that case can be tricky [Fri Jan 12 09:01:10 2018] for debugging I’d start from `match goal with | [ forall _, _ ] => idtac.` and use bisection to see what introduces the error [Fri Jan 12 09:02:36 2018] and you might need something like `[ H : forall a b, ?A a b -> ?B a b |- _ ]` to make things work [Fri Jan 12 09:03:22 2018] jstolarek: meanwhile, I retract idea (a), shadowing must just work (I’ve never needed to explicitly freshen names for match goal) [Fri Jan 12 09:04:08 2018] jstolarek: on the other hand, any chance the tactic in the right-hand side fails somehow and makes `match goal` backtrack leading to a spurious error (not sure if this can happen, sorry) [Fri Jan 12 09:43:46 2018] pgiarrusso: for reasons I don't really understand the problem was caused by ?A and ?B [Fri Jan 12 09:44:03 2018] this is a form that works: [Fri Jan 12 09:44:14 2018] | [ IH : forall _ _ _, _ |- _ ] => [Fri Jan 12 09:44:45 2018] although it does not allow me to be precise by specifying unification variables to precisely match the premisses I still can achieve what I want [Fri Jan 12 09:45:00 2018] jstolarek, I think because ?A is something that doesn't use the forall variable then [Fri Jan 12 09:45:44 2018] I'm not sure because even my link from Chlipala gives confusing info [Fri Jan 12 09:46:23 2018] but that's the basic sort of issue [Fri Jan 12 09:47:46 2018] also, the general problem match goal would have to solve is higher-order unification, and I'm not sure what it does instead [Fri Jan 12 09:47:55 2018] jstolarek ^^ [Fri Jan 12 09:52:16 2018] it would be awkward to refer to ?A otherwise because there is nowhere to bound its free variables [Fri Jan 12 09:58:42 2018] lyxia: that's a good point [Fri Jan 12 10:24:04 2018] jstolarek: forall x, ?A x might help with that [Sat Jan 13 12:05:02 2018] Module U := FMapList.Make(String). Error: The field lt is missing in Coq.Strings.String. [Sat Jan 13 12:06:17 2018] Is there an ordered version of string in the standard library? [Sat Jan 13 13:02:51 2018] jmagnusj: there is not [Sat Jan 13 13:03:47 2018] rip [Sat Jan 13 13:05:36 2018] this is one of the things that motivated me to start on a real string library [Sat Jan 13 13:06:09 2018] (although the issue here is actually a real character library, the string part of that is easy) [Sat Jan 13 13:08:43 2018] and unrelatedly: pgiarrusso: yeah you'd think, but if it's deterministic, what actually goes wrong? since there's no body to examine you can't attempt to reason about what it does, and when it's deterministic it doesn't matter how many times it gets evaluated on any one argument [Sat Jan 13 13:10:10 2018] it violates parametricity, but in a subtle way: it's not clear to me that you can distinguish a function on strings that computes the result from the argument, and one that deterministically returns the same string for the same argument based on externally stored information, without a turing oracle. [Sat Jan 13 13:11:03 2018] e.g. your favorite cryptographic hash is a pure function on strings [Sat Jan 13 13:14:53 2018] I also tried integers of various types as keys with no better luck... these things don't exactly plop together like legos [Sat Jan 13 13:16:07 2018] Kind of makes it hard to start something unless you are really determined [Sat Jan 13 13:19:14 2018] Is it a fundamental problem of coq or just a problem with the standard library? [Sat Jan 13 13:19:37 2018] * bbl [Sat Jan 13 13:43:06 2018] fmaps from nat work [Sat Jan 13 13:43:12 2018] dunno about others, haven't tried [Sat Jan 13 13:44:09 2018] pgiarrusso: the case I was thinking of was to add import to a simple interpreter by providing an ocaml function that retrieved the contents of a file, and memoized it to make sure it was deterministic [Sat Jan 13 13:45:12 2018] the results might be different from run to run, but that's not ultimately different from compiling them into a separately-compiled source file [Sat Jan 13 13:47:11 2018] here's a case with fewer moving parts (but no useful application) though: a function that internally stores a hash code, and that caches its results so it always returns the same result for the same argument, but when given a new argument hashes it into the internal state and returns the new hash [Sat Jan 13 13:47:32 2018] so the results of hashing a given string are always the same but depend on which strings were hashed previously [Sat Jan 13 13:48:26 2018] what can this break, and (assuming cryptographic hashes) how can you distinguish it from a function that just hashes its argument? [Sat Jan 13 13:48:45 2018] I'm now curious :-) [Sat Jan 13 13:52:17 2018] so when you say "always the same" [Sat Jan 13 13:52:30 2018] you mean always the same in a given program run, not always the same across runs [Sat Jan 13 13:52:36 2018] right [Sat Jan 13 13:53:04 2018] sounds like it could break a whole fuckin lot [Sat Jan 13 13:53:19 2018] like? [Sat Jan 13 13:53:34 2018] coq believes that [swap (hash a, hash b) = (hash b, hash a)] [Sat Jan 13 13:54:06 2018] or if you extract to haskell, laziness creates major unpredictability [Sat Jan 13 13:54:19 2018] well i guess it was already pretty unpredictable [Sat Jan 13 13:55:03 2018] it doesn't break that; on any given run hash a = hash a [Sat Jan 13 13:55:34 2018] and keep in mind that different on different runs isn't distinguishable from different in different recompilations after someone changed the other source file that contains the implementation [Sat Jan 13 13:56:21 2018] so we're assuming that we treat the function as an opaque constant with no facts about it other than its type? [Sat Jan 13 14:00:07 2018] i suppose we could come up with, like, an extended calculus of [inductive] constructions where judgments are parameterized by a state and rules for deducing reduction equivalence change the state, and then see if the ordinary Co[I]C interprets soundly into it [Sat Jan 13 14:00:12 2018] sounds like a lot of work tho [Sat Jan 13 14:00:14 2018] :] [Sat Jan 13 14:00:54 2018] right, that's what Axiom does unless you add more axioms to give semantics [Sat Jan 13 14:01:08 2018] yeah, that sounds like work [Sat Jan 13 14:16:20 2018] it's still sort of an interesting question what that scenario would actually break, though. [Sat Jan 13 14:18:34 2018] on an unrelated topic: currently with strings you can write match s with | "abc"%string => ... [Sat Jan 13 14:18:45 2018] but the logic that comes out is a minor nightmare [Sat Jan 13 14:21:21 2018] which is partly because it unpacks the string but mostly because of the internal representation of Ascii [Sat Jan 13 14:23:12 2018] a better character type is necessary [Sat Jan 13 14:23:36 2018] however, for extracting to ocaml matching directly on strings like this is bad, because ocaml strings aren't cons-lists [Sat Jan 13 14:23:52 2018] and so it generates a horrible mess [Sat Jan 13 14:29:48 2018] is it worth trying to fix this with complex extraction logic, or would it be better to try to write notations for string matching that expand to equality tests? [Sat Jan 13 14:29:58 2018] both of these approaches have severe downsides :( [Sat Jan 13 14:30:08 2018] or just tell people not to match on strings? [Sat Jan 13 14:30:38 2018] it would be nice if coq's string match could extract to an ocaml string match, that is, match s with | "abc" -> ... [Sat Jan 13 14:30:43 2018] but that doesn't seem very likely to be possible. [Sat Jan 13 14:32:42 2018] (similarly, extracting string constants not as conses seems like a problem, but this is more likely to be cleaned up by the ocaml compiler) [Sat Jan 13 14:54:12 2018] hello. im looking into heterogeneous lists so i can have e.g. lists of things like record projections (where the codomain is different). besides somethign like the hlist in cpdt http://adam.chlipala.net/cpdt/html/Cpdt.DataStruct.html#lab57 are there other approaches for this? i recall something involving tuples that happened to be easier to use for some cases [Sat Jan 13 14:56:12 2018] * fluffles beaky [Sat Jan 13 14:57:47 2018] hello hodapp [Sat Jan 13 14:57:57 2018] you follow me everywhere >_> [Sat Jan 13 15:02:50 2018] beaky: Fixpoint hlist (l : list A) : Type := match l with [] => unit | h :: t => h * hlist t end. [Sat Jan 13 15:02:55 2018] for example: Record t { a : nat; b : list; }. then i want to have something like Definition t_projections := [a; b]. [Sat Jan 13 15:03:21 2018] ah thanks lyxia (i think that was the one i was trying to recall) [Sat Jan 13 20:04:24 2018] dh` dh_work: I was concerned about “deterministic but impure” for a different reason — your actual example that memoizes a file content looks fine, the hash example doesn’t [Sat Jan 13 20:05:04 2018] a counter is already a problem [Sat Jan 13 20:06:11 2018] Let `fresh_int` be defined in imperative pseudocode as `fresh_int () := set cell (1 + get cell); get cell` [Sat Jan 13 20:06:53 2018] if in Coq you have `fresh_int: Unit -> Nat` Coq believes that `fresh_int() = let _ = fresh_int() in fresh_int()` [Sat Jan 13 20:07:21 2018] I guess this is all clear [Sat Jan 13 20:07:33 2018] or it should be [Sat Jan 13 20:07:43 2018] but this function is impure yet 100% deterministic [Sat Jan 13 20:08:54 2018] I guess that’s not what you meant, but when you asked I didn’t know [Sat Jan 13 20:10:00 2018] for your example with cryptographic hashes, I thought it suffered from the same problem, but I’m not sure it dowes [Sat Jan 13 20:10:01 2018] *does [Sat Jan 13 20:14:14 2018] however, things compiling Coq assume reordering calls is semantics-preserving (which it isn’t here), so at the very least you could get miscompilations changing the actual result [Sat Jan 13 20:16:07 2018] to see such miscompilations spectacularly in action, we have to turn to buggy unsafe Haskell :-) [Sat Jan 13 20:16:23 2018] see https://github.com/haskell/bytestring/blob/master/Data/ByteString/Internal.hs#L566-L588 and links [Sat Jan 13 20:18:37 2018] benzrf: if you want state, wouldn’t you just use one of the N encodings of state into Coq (maybe one which is maintained though, unlike IIRC yNot)? [Sat Jan 13 20:43:29 2018] hmm [Sat Jan 13 20:43:44 2018] the hash example is fine in your first context, because it takes an arg [Sat Jan 13 20:44:49 2018] the second context (let x := hash 3 in let y := hash 5 = let y := hash 5 in let x := hash 3) is more interesting [Sat Jan 13 20:45:01 2018] it's still true [Sat Jan 13 20:45:11 2018] but the actual values depend on the order produced by the compiler [Sat Jan 13 20:47:00 2018] or rather, (let x := hash 3 in let y := hash 5 in (x, y) = let y := hash 5 in let x := hash 3 in (x, y)) is more interesting [Sat Jan 13 20:47:06 2018] s/is more interesting// [Sat Jan 13 20:49:46 2018] if you evaluate both expressions, you get the same value; if you evaluuate each one in isolation, you don't, but then you also can't compare them to discover that someting's different. [Sat Jan 13 20:50:39 2018] there's something very schroedinger about that [Sat Jan 13 21:13:26 2018] dh_work: I’d try using projections from exists c, hash 3 = c, then using hash 5, then checking the projected value matches hash 3. This is still likely to work, but it’s trickier [Sat Jan 13 21:15:15 2018] Actually, just take the actual result from hash 3 (say 42), prove that hash 3 = 42 (by computation, if that works?), and then throw away the proof to change evaluation order after extraction... uh, the proof by computation likely fails [Sat Jan 13 21:16:12 2018] OK, giving up, but if your idea is indeed safe it’s far from obvious why [Sat Jan 13 21:23:16 2018] pgiarrusso: im talking about verifying whether coq's conclusions are valid when extracting a parameter as a function of the sort dh` described [Sat Jan 13 21:24:52 2018] i.e. one that, in a given run of the program, will always return the same value for the same input, but that value won't be determined until the first time you ask, and the determination at that point will depend on how you've used the function prior [Sat Jan 13 21:27:36 2018] you can't prove the actual result, because the function's external to coq. [Sat Jan 13 21:28:14 2018] I'm pretty sure the exists thing will work; the extracted code must call hash 3 either before or after hash 5 [Sat Jan 13 21:29:16 2018] it's not safe, obviously, but it's not obvious how you'd construct something that fails. [Sat Jan 13 21:31:06 2018] it can't be something about the actual value since you can't prove anything about that; it would have to be some conclusion based on assumptions about functions that it violates. [Sat Jan 13 21:34:35 2018] (unrelated side question: does ocaml have an Either type? I can't find one in the docs) [Sat Jan 13 22:03:03 2018] dh_work: i guess, like [Sat Jan 13 22:03:24 2018] in this context, how should we give semantics to a statement like "hash 3 = 5 -> hash 4 = 6" [Sun Jan 14 02:25:49 2018] benzrf: right, that would do it, but you can't assert the premise except as an axiom so I'm not sure it's important [Sun Jan 14 02:26:47 2018] dh_work: then how should we give semantics to [forall n m, hash n = m -> hash n = m] [Sun Jan 14 02:27:03 2018] that's clearly provable - how do we interpret it [Sun Jan 14 02:27:22 2018] how is it provable when all you know about hash n is that it's a nat? [Sun Jan 14 02:27:30 2018] well, two things [Sun Jan 14 02:27:32 2018] oh wait, I misread [Sun Jan 14 02:27:35 2018] oh lol [Sun Jan 14 02:27:42 2018] well yeah actually im not sure this is problematic anyway nvm [Sun Jan 14 02:27:51 2018] but I don't think it's problematic [Sun Jan 14 02:28:02 2018] I read it as hash n = m -> hash m = n [Sun Jan 14 02:28:06 2018] hah [Sun Jan 14 02:29:56 2018] well, regardless [Sun Jan 14 02:30:09 2018] ugh, 6500 lines of ocaml in the past week, not counting adding stuff to the output code generation framework [Sun Jan 14 02:30:14 2018] no wonder my eyes are glazed over. [Sun Jan 14 02:30:26 2018] i don't think it's /useful/ to do this unless you can come up with a semantics to assign to these statements [Sun Jan 14 02:30:30 2018] (and yes I'm at work at 2:30am on saturday night too) [Sun Jan 14 02:30:37 2018] because the standard semantics only describe functions [Sun Jan 14 02:30:44 2018] it's not [Sun Jan 14 02:30:52 2018] well ok good :) [Sun Jan 14 02:30:58 2018] when I introduced the hash example I pointed out that it has no application :-) [Sun Jan 14 02:31:01 2018] woops [Sun Jan 14 02:31:12 2018] well yes, as long as you don't apply it you can't observe any difference [Sun Jan 14 02:31:14 2018] the thing that reads files for an interpreter's import statement has an application, but it's a lot more complicated to think about. [Sun Jan 14 02:31:14 2018] :> [Sun Jan 14 02:31:20 2018] heh [Sun Jan 14 02:34:10 2018] that one is not entirely aimless; one of the pieces of vaporware I have brewing is a verified c preprocessor (this is supposed to give the string library a workout, among other things) and how to load include files isn't obvious [Sun Jan 14 02:39:33 2018] it seems obvious to parameterize everything over a filesystem value input [Sun Jan 14 02:39:36 2018] what's the catch there [Sun Jan 14 03:11:06 2018] that it's basically the io monad and infests everything [Sun Jan 14 03:15:37 2018] and in addition to carrying it around, you also have to carry around predicates about it. [Sun Jan 14 03:16:21 2018] also while we're talking about subtle and not-so-subtle violations of parametricity, the io monad is not actually enough to model the outside world correctly. [Sun Jan 14 03:20:24 2018] e.g. you can write down "read_file (name: string) -> IO string", but it doesn't follow that "read_file foo >>= fun text1 => read_file foo >>= fun text2 => (text1, text2)" implies text1 = text2 [Sun Jan 14 03:20:33 2018] but in coqland that's implicitly true [Sun Jan 14 03:22:49 2018] if you unfold the monad it becomes fun world => let (world', text1) := read_file foo in let (world'', text2) := read_file foo in (world'', (text1, text2)) [Sun Jan 14 03:22:58 2018] and since read_file doesn't change the world... [Sun Jan 14 03:24:43 2018] erm [Sun Jan 14 03:24:51 2018] if you unfold the monad it becomes fun world => let (world', text1) := read_file world foo in let (world'', text2) := read_file world' foo in (world'', (text1, text2)) [Sun Jan 14 03:27:01 2018] I suppose if you don't state that read_file doesn't change the world it's safe [Sun Jan 14 03:27:59 2018] but it's still very similar to the hash example [Sun Jan 14 12:31:01 2018] dh`: it’s been shown that inlining the definition of the IO monad is unsafe — the unsafe rewritings are just ones that GHC never does [Sun Jan 14 12:33:08 2018] If you have `c <- read_char file`, then use `c` twice, and allow inlining `c`’s definition at the use site (reusing the same world), you duplicate effects — but GHC refuses to duplicate function calls in this scenario so everything’s fine; you’d need to give a linear type to the world to forbid this duplication [Sun Jan 14 13:14:31 2018] 03:27 I suppose if you don't state that read_file doesn't change the world it's safe [Sun Jan 14 13:14:38 2018] um yeah that's the whole point of RealWorld [Sun Jan 14 14:37:13 2018] in fact, the real world keeps changing, so stateBeforeRead = stateAfterRead would be a lie [Sun Jan 14 14:40:02 2018] it nonetheless violates parametricity in a similar way to the hash example [Sun Jan 14 14:42:25 2018] dh`: BTW, not sure why you mention parametricity here — we aren’t dealing with polymorphic functions [Sun Jan 14 14:44:14 2018] the new world value after read_file not depend only on the old world and the other argument [Sun Jan 14 14:44:24 2018] s/not/does not/\ [Sun Jan 14 14:44:36 2018] yeah, parametricity has nothing to do with this [Sun Jan 14 14:44:42 2018] our examples violate purity, but I think they’re all still parametric functions (if you can define parametricity for an effectful language, but we’ve learned how in the last decade) [Sun Jan 14 14:45:14 2018] there's something somewhere I don't understand then [Sun Jan 14 14:45:24 2018] parametricity tells you that abstract types (from either existentials or universals) create abstraction barriers [Sun Jan 14 14:45:50 2018] as a special case, it tells you that a pure function of type forall a. a -> a must be the identity (and other such things) [Sun Jan 14 14:46:14 2018] ah, I'm just using the wrong term [Sun Jan 14 14:46:17 2018] * goes off to think [Sun Jan 14 14:47:10 2018] oh, and also: the IO monad is unsafe if you unfold it because its functioning relies on the monad typing to prevent world values from being used more than once [Sun Jan 14 14:48:42 2018] that seems to become a very squirrelly concept in a proof environment [Sun Jan 14 14:54:22 2018] I should go reread the ynot papers with these issues in mind, and stick to talking about things I understand properly ;-) [Sun Jan 14 15:08:25 2018] dh`: keeping that monad abstract (say, with modules) might be good — but I’ve never read the ynot papers, so reading them is probably better than asking me :-) [Sun Jan 14 15:09:30 2018] dh`: also no worries, but I thought clarifying the miscommunication was useful [Sun Jan 14 15:10:32 2018] I *don’t* just stick to what I’m sure about (though I try to avoid overconfidence and will shut up to somebody with a clue) [Sun Jan 14 15:43:32 2018] I don't actually either, but I also prefer to avoid looking like an idiot in public when it's avoidable :-) [Mon Jan 15 06:34:17 2018] I have several equalities in the context. I would like to write a tactic that inverts all of them. however, any attempt of using repeat results in infinite loop (unsurprisingly). Are there any alternatives? [Mon Jan 15 06:34:42 2018] repeat match goal with | [H : ?P = ?R |- _] => inversion H; subst end [Mon Jan 15 06:35:05 2018] that's what I'd like to do [Mon Jan 15 08:56:25 2018] jstolarek: great question! you can clear the equality to avoid looping, but that can lose information when `inversion` doesn’t work well; `inverts` from Software Foundation LibTactics (originally from TLC) might work better [Mon Jan 15 08:57:04 2018] also, for scenarios where it works, `injection` is a much more predictable tactic than `inversion` [Mon Jan 15 08:57:21 2018] (`injection` can replace `inversion` for `Some a = Some b`) [Mon Jan 15 08:59:14 2018] jstolarek: I’ve seen good sources of “improved standard tactics” in proof scripts by Chlipala, by Chargeraud (SF’s LibTactics / TLC) [Mon Jan 15 08:59:53 2018] also found nice bits in the coq-stdpp library [Mon Jan 15 09:00:28 2018] (from Krebbers, who’s fully formalized C11 in Coq) [Mon Jan 15 09:01:26 2018] jstolarek: but to be sure, I said “great question” because I don’t yet have a full answer, so I use a mixture of the strategies I just mentioned — I still don’t have a *safe* tactic [Mon Jan 15 09:02:29 2018] I’m also not sure why `inversion` loses info in general — I often simplify/unfold aggressively before inverting (it’s as if `inversion` never required simplifications) [Mon Jan 15 14:45:53 2018] I'm trying to write a tactic t, that given some hypothesis H, does "pose proof (lemma H)"; this works well, but I'm trying to avoid non-termination of the tactic. The tactic does other things that manipulate the hypothesis (e.g. intuition), so it hard to know whether I have already did this "pose proof (lemma H)" step. What's the standard way in Ltac to make sure we don't apply a step twice in some tactic? [Mon Jan 15 15:14:49 2018] more precisely, lemma H produces some disjunction P1 \/ P2, then intuition will do a case analysis and create two subgoals [Mon Jan 15 15:15:33 2018] then the tactic will loop and invoke lemma H again, because it will see that P1 \/ P2 is not one of the hypothesis (only P1 would be on one branch, and only P2 would be on the other branch) [Mon Jan 15 15:15:38 2018] the whole tactic then does not terminate [Mon Jan 15 15:17:40 2018] I was thinking about adding some strings in my goal to mark the fact that I already applied this step, such as "applied lemma to H" [Mon Jan 15 15:18:06 2018] but I'm not sure how to convert a Coq term to a string in Ltac [Mon Jan 15 16:54:11 2018] my first question would be: if this should only be done once, why loop? [Mon Jan 15 17:42:54 2018] sudd: assuming there’s a reason to loop, can you use `match goal with | [ ?P1 \/ ?P2, ?P1 ] => fail; | [ ?P1 \/ ?P2, ?P2 ] => fail end` to detect what you describe explicitly? [Mon Jan 15 17:43:27 2018] or something like that [Mon Jan 15 17:45:51 2018] sudd: also, if you know what you want `intuition` to do, you might want to write the special case you need explicitly with `match goal`, that’ll be much faster and could lead you to more specific automation [Mon Jan 15 17:46:21 2018] here sth. like `match goal with | [ H: _ \/ _ ] => destruct H end` [Tue Jan 16 02:06:53 2018] dh_work: pgiarrusso: my general tactic looks like: repeat match goal with ... end; so this particular step that I want to apply only once is only one step among many other steps that "improve" the goal; the step where I apply "lemma" can be applied only thanks to other steps, and then from the conclusion of lemma I want to continue my tactic [Tue Jan 16 02:07:54 2018] dh_work: pgiarrusso: also "lemma" must be applied once per hypothesis "H" which is compatible with "lemma", but overall could be applied many times [Tue Jan 16 02:09:33 2018] pgiarrusso: intuition was an example, but the tactic I use does other kind of simplifications and it would be tedious to make a special case to avoid simplifying these kinds of hypotheses, since I'm invoking many personal or built-in tactics that may change them [Tue Jan 16 02:10:03 2018] sudd: I suspected you were looking for all possible hyps for lemma... [Tue Jan 16 02:10:18 2018] sudd: wait, what about `clear`? [Tue Jan 16 02:10:43 2018] sudd: `pose proof (lemma H); clear H` [Tue Jan 16 02:10:51 2018] it’s not always safe [Tue Jan 16 02:11:11 2018] but if it works for you *that* is the standard way to prevent looping [Tue Jan 16 02:11:16 2018] pgiarrusso: yes it's not safe in my case, because H is a much stronger property [Tue Jan 16 02:11:29 2018] sudd: can you change `lemma` to make it safe? [Tue Jan 16 02:12:04 2018] lemma is basically of the form: forall x, P x -> Q x [Tue Jan 16 02:12:25 2018] pgiarrusso: what I'm doing currently is using; mark "lemma"; pose proof (lemma H), and mark "lemma" will add some string s := "lemma": string to the context so that I know I have already applied lemma [Tue Jan 16 02:13:14 2018] the problem with this solution is that it only allows lemma to be applied once overall, instead of once per compatible hypothesis of the form "P _" [Tue Jan 16 02:13:51 2018] `lemma2: forall x, P x -> Q x /\ Hide (P x)`, where `Hide` is some identity function (or maybe a constructor) that does not get auto-unfolded and prevents applying `lemma2` again [Tue Jan 16 02:14:03 2018] where did I see Hide? Hm... let me check one place [Tue Jan 16 02:15:19 2018] pgiarrusso: but that would also make P x unusable for other tactics/auto and such right? [Tue Jan 16 02:16:27 2018] so, something like https://gitlab.mpi-sws.org/robbertkrebbers/coq-stdpp/blob/master/theories/tactics.v#L444 [Tue Jan 16 02:16:30 2018] isn't possible to make some string out of a term, that way I could use mark ("lemma" ++ to_string H1) and mark("lemma" ++ to_string H2) [Tue Jan 16 02:16:38 2018] well, yes, but see also unblock_goal... [Tue Jan 16 02:16:41 2018] and have different marks for different instances [Tue Jan 16 02:16:57 2018] OTOH, that file has `iter` which might be even better [Tue Jan 16 02:17:04 2018] if you can turn your hypotheses into a list [Tue Jan 16 02:17:37 2018] on your question: maybe, dunno — maybe it’s easier to make strings out of hypotheses names [Tue Jan 16 02:20:05 2018] I didn't figure out how yet but I'll keep looking :) thanks for the alternative solutions [Tue Jan 16 02:26:23 2018] pgiarrusso: or if perhaps I could create another variable name out of H or out of the variables that appear in H, and then just pose that variable (not necessarily of type string) in my context? [Tue Jan 16 02:27:45 2018] sudd: uh, maybe `fresh` helps? [Tue Jan 16 02:28:06 2018] it can take proposed names, though maybe it takes them as string? [Tue Jan 16 02:28:17 2018] oh wait, I’m silly [Tue Jan 16 02:28:32 2018] the point of `fresh` is that it’ll never conflict... [Tue Jan 16 02:30:26 2018] pgiarrusso: but if fresh can be implemented in Ltac then maybe I can take inspiration from that? or is it some built-in thing? [Tue Jan 16 02:35:20 2018] I have used `fresh`, not implemented it [Tue Jan 16 02:37:12 2018] https://coq.inria.fr/refman/ltac.html suggests it might be a builtin [Tue Jan 16 02:42:30 2018] sudd: but since you ask about “standard way”: I use that file and library (the author formalized the C11 spec) [Tue Jan 16 02:42:42 2018] Chlipala’s code (see https://jozefg.bitbucket.io/posts/2014-07-09-dissecting-crush.html and the CPDT chapter) [Tue Jan 16 02:45:24 2018] and from Software Foundations / the TLC library there are https://softwarefoundations.cis.upenn.edu/plf-current/UseTactics.html (intro) / https://softwarefoundations.cis.upenn.edu/plf-current/LibTactics.html (implementation) [Tue Jan 16 02:45:53 2018] thanks that's nice, I think I'll find what I need :) [Tue Jan 16 02:48:12 2018] sudd: for emphasis, looping over the hypotheses that fit `lemma` in one go, and applying that lemma to all in one pass, might be the best strategy; but I’m not sure how to get a list of hypotheses :-| [Tue Jan 16 02:50:12 2018] pgiarrusso: but what to do if the hypotheses that fit lemma can be generated after my other automation tactics? (and then from the result of lemma I can make some progress, and so on) [Tue Jan 16 02:52:33 2018] Uh, position markers might help: https://softwarefoundations.cis.upenn.edu/plf-current/LibTactics.html#lab450 [Tue Jan 16 02:53:38 2018] hypotheses are ordered (and *usually* the order is preserved, though it can be changed) [Tue Jan 16 02:54:10 2018] so if you add a mark after you’re done with a pass, you’ll find new hyps after the mark [Tue Jan 16 02:55:10 2018] ah good to know [Tue Jan 16 02:55:51 2018] I’m thinking of `gen_until_mark; < “block” the hyps in context that match lemma > ; intro_until_mark; < do a pass of the lemma on the unblocked hyps > ; < unblock hyps >` [Tue Jan 16 02:56:15 2018] not sure that works, but seems plausible? [Tue Jan 16 02:56:38 2018] well, insane but Ltac-plausible [Tue Jan 16 02:57:31 2018] but I’ve never done something like this [Tue Jan 16 02:57:34 2018] sudd: ^^ [Tue Jan 16 02:58:34 2018] (to be clear, I’m looking for an answer to learn what it is, not because I am actually an expert) [Tue Jan 16 02:59:36 2018] and also this stuff feels like programming in TeX [Tue Jan 16 02:59:55 2018] * does not find *TeX* the language very elegant [Tue Jan 16 03:02:05 2018] that could be a solution, I'll try to think about it; reconnecting later, thanks for your help! [Tue Jan 16 06:20:01 2018] pgiarrusso: I think I figured out a way to do what I want; I introduce some dummy type: Inductive Marked {T}: T -> string -> Type :=| Mark: forall t s, Marked t s. and then whenever I applied lemma to H, I do: pose proof (Mark H "applied lemma"), and that mark will stay in the context [Tue Jan 16 07:12:14 2018] pgiarrusso: thanks. I ended up doing a stupid thing, ie. writing several matches: one that matches only one hypothesis, another that matches two,... and so on up to six. This is horrible but works for me [Tue Jan 16 07:12:44 2018] I am now wondering if Ltac allows my to write a tactic that understands "as" suffix, eg: [Tue Jan 16 07:12:59 2018] myTactic X Y Z as H [Tue Jan 16 07:13:27 2018] I'd like H to be an argument to the tactic, just want to use "as" syntax since it is easier to read in the script [Tue Jan 16 08:10:16 2018] sudd: uh, sounds nice! [Tue Jan 16 08:12:36 2018] jstolarek: searching for “as” in the LibTactics link above finds “Tactic Notation "gen_eq" ":" constr(E) "as" ident(X) := gen_eq X: E.” [Tue Jan 16 08:13:00 2018] jstolarek: link: https://softwarefoundations.cis.upenn.edu/plf-current/LibTactics.html [Tue Jan 16 08:13:26 2018] I’m afraid I recommend cargo-culting :-| [Tue Jan 16 08:15:20 2018] also, the code in there seems often as horrible — Ltac 1 seems to range between TeX and PHP (Ltac2 might be a bit better), but at least that horror doesn’t affect correctness of completed proofs :-| [Tue Jan 16 10:15:55 2018] how can i prove "inord 1 != inord 2"? [Tue Jan 16 15:28:53 2018] what is the reasoning behind the restrictions on reservable names? [Tue Jan 16 15:29:07 2018] "it must have no trailing digits, quote, or _" [Tue Jan 16 15:35:34 2018] Ah. Read the docs a bit more closely: "The effect of the command is to automatically set the type of bound variables starting with ident (either ident itself or ident followed by one or more single quotes, underscore or digits)" [Tue Jan 16 18:10:34 2018] leah2: what’s inord? if it’s a data constructor, `intro H; inversion H` should be enough. `intro H; injection H` might also produce a goal that is easier to solve [Tue Jan 16 18:11:09 2018] (from ssreflect) [Wed Jan 17 03:42:28 2018] account add jabber gustav.behm@gmail.com [Wed Jan 17 03:42:56 2018] whoops, thanks irssi :) [Wed Jan 17 04:58:09 2018] pgiarrusso: ah, Tactic Notation, right! Haven't thought about that [Wed Jan 17 04:59:08 2018] "Ltac is like TeX - just barely usable enough to be indispensible" - B. Pierce, 2017 [Wed Jan 17 06:44:00 2018] jstolarek: thanks, stealing it! [Wed Jan 17 06:44:06 2018] * googles... [Wed Jan 17 06:44:10 2018] retweeting https://twitter.com/cattheory/status/920048352149958656 [Wed Jan 17 10:55:36 2018] what would be a good text book for learning coq in a small study group? [Wed Jan 17 10:55:49 2018] software foundations is probably the best chance. [Wed Jan 17 10:56:11 2018] thanks for your data point :) [Wed Jan 17 12:19:33 2018] jmagnusj: SF++ [Wed Jan 17 13:55:42 2018] pgiarrusso, thanks [Wed Jan 17 21:15:51 2018] constructive math is gr8 https://i.imgur.com/x75gCs0.png [Wed Jan 17 22:06:30 2018] heh [Wed Jan 17 22:07:06 2018] why would = be the negation of /= rather than the other way around? there must be a reason, but it's not obvious on casual contact [Wed Jan 17 22:15:29 2018] dh`: look closer, it's talking about inequivalence relations that properly witness a distinction [Wed Jan 17 22:16:54 2018] hmm actually it still seems strange that negating would give you equality [Wed Jan 17 22:16:58 2018] even if you have more info than neq [Wed Jan 17 22:17:53 2018] hmm, how about... [Wed Jan 17 22:18:27 2018] let's say we have [S := nat -> nat]; then we can define [apart x y := exists i, x i <> y i] [Wed Jan 17 22:19:21 2018] so: [~apart x y] -> [forall i, ~(x i <> y i)] -> [forall i, x i = y i] --(assuming funext)--> [x = y] [Wed Jan 17 22:20:28 2018] but of course we need markov's principle or something to go [x <> y] -> [apart x y] [Thu Jan 18 02:51:26 2018] benzrf dh` : that seems to be saying that since reals are infinite, you can’t give a finite witness that they’re equal, but you can more easily witness they’re unequal, or that inequality gives a contradiction [Thu Jan 18 02:54:44 2018] Also, “they’re the same sequence” as you use in your example is probably much too restrictive, since reals must be quotiented [Thu Jan 18 02:56:17 2018] OTOH, I’ve heard there are multiple pretty different constructive definitions of reals, many predating type theory/Coq [Thu Jan 18 03:43:06 2018] well, you can't have not (not eq) being the same as eq, because of excluded middle, but all else being ... the same ... I'd expect equality to be the base case [Thu Jan 18 03:43:54 2018] on the grounds that because an object is equal to itself, it's more primitive. or something like that. [Thu Jan 18 03:44:33 2018] this is not a piece of math I particularly claim to understand though. [Thu Jan 18 04:17:13 2018] dh` if you’re trying to justify reals when you don’t trust infinity, “equality of reals is primitive” should sound suspicious [Thu Jan 18 04:17:47 2018] also, “equality of reals” is probably a pretty complicated equivalence [Thu Jan 18 04:18:10 2018] if you defined reals with Cauchy sequences, say, two sequences for the same real could be wildly different [Thu Jan 18 04:18:44 2018] even decimal expansions of reals need some quotienting (because 1 = 0.99999....) [Thu Jan 18 04:28:48 2018] I dunno. every real is still equal to itself. [Thu Jan 18 04:33:42 2018] whereas any scheme for writing down reals (that aren't rationals) makes it problematic to show that any two are not equal [Thu Jan 18 04:33:58 2018] but maybe that's the point, a statement that two are not equal is stronger? [Thu Jan 18 04:34:00 2018] I dunno. [Thu Jan 18 04:34:07 2018] anyway the original link doesn't mention reals specifically [Thu Jan 18 04:39:03 2018] yeah, I feel like making the statement stronger (more constructive) was part of the point [Thu Jan 18 04:39:23 2018] dh`: ^^ [Thu Jan 18 04:39:37 2018] dh`: you’re right the link doesn’t mention reals, but it says “apartness” [Thu Jan 18 04:40:01 2018] and I think I’ve only seen apartness introduced for reals [Thu Jan 18 06:55:56 2018] Question: since Ltac scripts have side effects (backtracking, exceptions), is there any formal description of them? What is the Ltac monad? [Thu Jan 18 06:56:13 2018] Alternatively, is there a paper introducing Ltac? [Thu Jan 18 06:57:02 2018] I’m aware of Chap. 9 in the reference manual, but I don’t think it has a good answer [Thu Jan 18 06:57:41 2018] so I first complained about it (https://twitter.com/Blaisorblade/status/953958722165989376), then thought it’d be more constructive to ask here [Thu Jan 18 09:16:04 2018] Hello, friends! I've encountered a strange compilation error while solving exercises from IndProp.v chapter of Software Foundations. The error appears when I add `eqn:something` to my induction tactic. The minimal example reproducing it is provided here: https://pastebin.com/JQz9Rpse . [Thu Jan 18 09:16:45 2018] Could you, please, help me understand its meaning or find some workaround? [Thu Jan 18 09:21:20 2018] I don't understand it enough to explain it but the workaround is probably to not use eqn. [Thu Jan 18 09:25:38 2018] you could use fix and inversion [Thu Jan 18 09:27:35 2018] gnull: another way is remember (cons x a) as a'. induction H. [Thu Jan 18 09:28:16 2018] lyxia: Thank you, I haven't heard of fix before, but I'll study it. [Thu Jan 18 09:30:24 2018] lyxia: Great, the remember+induction option works for me. Thank you! [Thu Jan 18 11:25:05 2018] pgiarrusso, dh`: first of all, i didnt mean for S to be the reals [Thu Jan 18 11:25:37 2018] reals as sequences of nats is asinine, you should be using rationals or digits [Thu Jan 18 11:25:48 2018] well maybe its not asinine but i dont know of any particular construction based on it [Thu Jan 18 11:26:28 2018] yeah I didn’t really check “S = reals”, apartness set me off [Thu Jan 18 11:26:43 2018] secondly: 'apart' here means that we have a specific example of how they differ [Thu Jan 18 11:26:59 2018] sure [Thu Jan 18 11:27:25 2018] the key thing is that equality of nats is decidable [Thu Jan 18 11:27:36 2018] so apartness for nats is equivalent to not equal [Thu Jan 18 11:27:55 2018] then pushing not-apart inside the function, we can turn that into equality [Thu Jan 18 11:28:37 2018] but if we just have not-equal, we can't recover apartness since we'd need to do a search for a differing input and we can't do that without markov's principle [Thu Jan 18 11:29:21 2018] if you prefer, pick a domain that isn't recursively enumerable, and then we can't do it even *with* markov's principle [Thu Jan 18 11:29:27 2018] good point, apartness is stronger than inequality in constructive logic [Thu Jan 18 11:29:36 2018] and that’s why constructive people introduced it [Thu Jan 18 11:29:40 2018] right [Thu Jan 18 11:29:47 2018] well, that's just a particular case of apartness [Thu Jan 18 11:29:59 2018] what i pasted was talking about a more general concept [Thu Jan 18 11:30:40 2018] BTW, just realized S is homomorphic to the reals probably, since a natural can code a fraction (not a rational, hence homomorphic not isomorphic) [Thu Jan 18 11:30:56 2018] homomorphic as what kind of structure? [Thu Jan 18 11:31:08 2018] I think that needs set homomorphism [Thu Jan 18 11:31:18 2018] that's just a function [Thu Jan 18 11:31:48 2018] hm. Trying to say that fraction equivalence induces an equivalence on S [Thu Jan 18 11:32:07 2018] and if you quotient S with that equivalence, the result seems isomorphic to reals [Thu Jan 18 11:32:08 2018] an equivalence morphism, then [Thu Jan 18 11:32:47 2018] not sure what that is [Thu Jan 18 11:33:05 2018] a morphism of sets equipped with equivalence relations :] [Thu Jan 18 11:33:22 2018] ah, an arrow between setoids? [Thu Jan 18 11:33:35 2018] you’re right that “set homomorphism” is just a function [Thu Jan 18 11:33:37 2018] if you like [Thu Jan 18 11:33:43 2018] here's the page i was screenshotting btw https://ncatlab.org/nlab/show/apartness+relation [Thu Jan 18 11:33:45 2018] anyway, this is all a tangent [Thu Jan 18 11:34:56 2018] thanks for the link [Thu Jan 18 11:35:05 2018] :) [Thu Jan 18 18:17:16 2018] Hello, my goal is basically to use coq to model bitwise algebra according to this set of equations (https://pastebin.com/4B0ALHE6) plus others that might be neccessary [Thu Jan 18 18:18:01 2018] I'm not sure how to approach this because it isn't a ring or a group or anything and I'm not sure if it's neccessary to use a construction of actually binary in order to apply these equations [Thu Jan 18 18:18:41 2018] so my question is how do I go about this? [Thu Jan 18 18:31:27 2018] anonlastname: you could declare these equations as axioms or parameters [Thu Jan 18 18:33:31 2018] I considered doing that but I'm not sure what type the variables would represent [Thu Jan 18 18:33:53 2018] that could also be a parameter [Thu Jan 18 18:34:12 2018] or how exactly the operators would be defined [Thu Jan 18 18:35:15 2018] anonlastname: if you want to make sure those are exactly the only axioms used, make a fresh boolean type (e.g. Inductive mybool = mytrue | myfalse) and state all those equations as axioms [Thu Jan 18 18:36:12 2018] but given how many there are, you're probably better off defining the operators more concisely and proving that those statements follow [Thu Jan 18 18:36:17 2018] oh, wait, those are integers? [Thu Jan 18 18:36:26 2018] yes they are binary integers [Thu Jan 18 18:37:11 2018] hmm [Thu Jan 18 18:37:29 2018] They are not quite natural numbers though because you have to choose between 2s complement and having 'infinity' being defined [Thu Jan 18 18:37:39 2018] because ~0 is all ones [Thu Jan 18 18:38:07 2018] Are you asking how to implement those or is an axiomatic definition enough [Thu Jan 18 18:39:01 2018] I'm considering implementing it but I'm not sure if that's feasible [Thu Jan 18 18:39:18 2018] it's feasible to make your own integer types made of bits, just a pain. [Thu Jan 18 18:39:47 2018] Do you think that the standard library's binary can handle this? [Thu Jan 18 18:40:04 2018] I don't know; probably. [Thu Jan 18 18:40:08 2018] it looks like you're talking about 2-adic numbers [Thu Jan 18 18:40:18 2018] but if you specifically want to use only those definitions, you probably want your own type [Thu Jan 18 18:40:18 2018] Yes that's what they are called [Thu Jan 18 18:41:45 2018] they're easily defined coinductively as streams of digits, but equality might be annoying to work with. [Thu Jan 18 18:43:04 2018] the standard library's binary numbers are just integers [Thu Jan 18 18:43:46 2018] I would think it wouldn't be a big problem; for any finite number there's a finite number of bits required, so there are exactly two coinductive cases and I'd expect to be able to prove all that [Thu Jan 18 18:43:58 2018] but I haven't tried. [Thu Jan 18 18:44:20 2018] all the stuff like this I've done has been with integers of some specific size. [Thu Jan 18 18:44:41 2018] integers whose sizes are powers of two can be done fairly elegantly [Thu Jan 18 18:44:50 2018] I'd be able to do what I want to do with a finite model as well [Thu Jan 18 18:45:10 2018] because it is something that can be computed with C++ integers [Thu Jan 18 18:45:19 2018] dh_work: its not possible, iirc, to prove that the coinductive "naturals" are the sum of unit and nat [Thu Jan 18 18:45:32 2018] bleh. [Thu Jan 18 18:45:53 2018] think about it: there's no way to decide whether a given conat is infinity [Thu Jan 18 18:46:28 2018] anonlastname: If you just need the equations maybe you can use something like this? http://lpaste.net/361777 [Thu Jan 18 18:47:26 2018] coinductive types are kind of a pain from what ive seen, altho what ive seen aint much [Thu Jan 18 18:47:45 2018] I will give that a try. I didn't realize how to declare a type like that [Thu Jan 18 18:48:07 2018] I would think you could prove that forall n, exists k, n < 2^k [Thu Jan 18 18:48:08 2018] it seems like what I was looking for in that is capable of just rewriting equations [Thu Jan 18 18:48:31 2018] and then given the bound you can decide, because once you get past the bound it's either 0 or inf [Thu Jan 18 18:48:49 2018] what? [Thu Jan 18 18:48:54 2018] but I'm blathering [Thu Jan 18 18:48:55 2018] hold on [Thu Jan 18 18:48:57 2018] I should write it down [Thu Jan 18 18:49:00 2018] no, you can't prove that [Thu Jan 18 18:49:05 2018] it doesnt work in the infinity case [Thu Jan 18 18:49:43 2018] hrm, since inf is in the type, no i guess it's just not true [Thu Jan 18 18:49:47 2018] foo. [Thu Jan 18 18:50:29 2018] but it's kind of a mangy type to have an infinite list of bits, because you have infinitely many distinguishable infinite values that are all equivalent. [Thu Jan 18 18:50:45 2018] what? [Thu Jan 18 18:50:55 2018] hold on [Thu Jan 18 18:51:04 2018] nvm [Thu Jan 18 18:51:05 2018] maybe I'm not thinking about the same thing you're talking about [Thu Jan 18 18:52:12 2018] hm. but if you have an infinite string of bits that is a two's complement signed value, the type doesn't include infinity [Thu Jan 18 18:52:14 2018] newspaper cartoons explains the distinction between intensional and extensional equality https://www.cse.buffalo.edu//~rapaport/Mutts-20090105-intensionVsExtension.gif [Thu Jan 18 18:52:44 2018] heheh [Thu Jan 18 19:00:40 2018] hmm, actually doing it as a coinductive type seems to just not work [Thu Jan 18 21:20:37 2018] doing arbitrarily long bitstrings as an *inductive* type works fine [Thu Jan 18 21:20:49 2018] now I'm not sure what the issue was :-/ [Fri Jan 19 04:11:56 2018] so I spent considerably longer than I should have messing with bitwise representations of numbers [Fri Jan 19 04:12:10 2018] you'd need conduction to also allow infinite bytestrings... which probably you don't want to [Fri Jan 19 04:12:42 2018] definining [[ Inductive num := | zero | minusone | shift more b ]] works adequately but not nicely [Fri Jan 19 04:12:45 2018] well [Fri Jan 19 04:12:58 2018] you don't want infinity in your type, because then nothing works properly anyway [Fri Jan 19 04:12:58 2018] (have a separate constructor for infinity maybe?) [Fri Jan 19 04:14:08 2018] ah, not needed here... [Fri Jan 19 04:14:35 2018] looks like arbitrary precision bitstrings are enough for the question [Fri Jan 19 04:14:46 2018] the problem with this definition is that it contains degenerate values like shift zero false [Fri Jan 19 04:15:05 2018] and so you either need to normalize them away, carry around proofs tha they aren't present, or something like that. [Fri Jan 19 04:15:23 2018] I haven't been able to think of a way to avoid this that doesn't make worse problems :-/ [Fri Jan 19 04:16:37 2018] e.g. Inductive num' := | one | minustwo | shift more b. Inductive num := | zero | minusone | other (n: num') [Fri Jan 19 04:17:37 2018] it works, though, just kinda messy in places [Fri Jan 19 04:39:53 2018] maybe just pack those proofs together with subset types and write definitions with Program? Just lipstick on “carry around proofs” [Fri Jan 19 04:39:58 2018] but maybe helps? [Fri Jan 19 04:40:18 2018] or maybe Program’s mean to you and this makes things worse [Fri Jan 19 04:43:03 2018] but the case I’ve hit with blowup from Program is probably not that common [Fri Jan 19 07:58:23 2018] Hello all! I'm trying to define a function by recursion over an inductive predicate whose result is in Set. I'm trying to use tactics to do it, but in a case that I need to invert the predicate to use the inductive hypothesis, pattern matching restriction bytes me. Is there a way to solve this kind of problem? [Fri Jan 19 08:52:59 2018] rribeiro: what pattern matching restriction? You can’t match on Set, but you should match on your predicate [Fri Jan 19 08:53:37 2018] pgiarrusso: The problem is that I'm trying to build a certified function, so its type is a sumbool [Fri Jan 19 08:54:03 2018] And? [Fri Jan 19 08:54:29 2018] Self-contained complete examples of Coq code are best [Fri Jan 19 08:54:39 2018] Inversion would require case analysis on sort Set which is not allowed for [Fri Jan 19 08:54:39 2018] inductive definition in_regex. [Fri Jan 19 08:54:53 2018] Prepare a gist or pastie [Fri Jan 19 08:55:03 2018] Ok, I 'll do it [Fri Jan 19 08:55:14 2018] And include the actual error message please [Fri Jan 19 08:56:26 2018] dh`: should one add this sort of advice (maybe in some weakened form) to the topic? Or is it a bad idea? I wouldn’t know how to phrase it [Fri Jan 19 08:57:39 2018] dh`: this advice = minimized examples please for certain [Fri Jan 19 08:57:49 2018] *for certain questions [Fri Jan 19 09:01:16 2018] https://gist.github.com/rodrigogribeiro/e0e87eb8f0ed547ed5f4016a61f45dc9 [Fri Jan 19 09:02:12 2018] I asked in general because I thought that it was a general problem with a general solution [Fri Jan 19 10:40:52 2018] answered rribeiro on the gist [Fri Jan 19 10:45:18 2018] looks like the error message mentions case analysis on `Set` but the actual problem is, rribeiro was inverting a judgment in `Prop` to produce a result in `Set` [Fri Jan 19 10:45:23 2018] weird error [Fri Jan 19 10:48:27 2018] pgiarrusso: but it says "Inversion _would_ require case analysis on sort Set" [Fri Jan 19 10:50:19 2018] pgiarrusso: there is a typo in "unlike stuff in Prop", you obviously meant "... in Set" [Fri Jan 19 10:52:32 2018] anton-trunov: typo fixed [Fri Jan 19 10:52:43 2018] on *would*: so what? [Fri Jan 19 10:53:08 2018] well, it says you need this thing in Set, but it's not [Fri Jan 19 10:53:17 2018] no no no [Fri Jan 19 10:53:25 2018] I read the message as “to do what you ask, I (the inversion tactic) _would_ have to do case analysis on `Set`, which is forbidden” [Fri Jan 19 10:53:50 2018] it *could* say “in_regex would have to be in `Set` to allow case analysis”, but it doesn’t say that [Fri Jan 19 10:54:05 2018] but Set is not an inductive type, thus it does not make sense [Fri Jan 19 10:54:31 2018] but I agree that this is not the clearest error message in the world [Fri Jan 19 10:54:50 2018] agreed [Fri Jan 19 10:55:00 2018] wait, re-reading the error, it’s saying yet something else [Fri Jan 19 10:55:30 2018] “case analysis on sort Set” does not mean “case analysis on Set” (Set is indeed not inductive) [Fri Jan 19 10:55:53 2018] but I guess it must mean “the language construct case analysis on datatypes of sort Set” [Fri Jan 19 10:56:22 2018] and that construct cannot be applied to `in_regex` which is in Prop [Fri Jan 19 10:56:52 2018] I’m... verbosely agreeing, understanding what the message might actually mean (well, not sure), and I’m *more* scared [Fri Jan 19 10:56:58 2018] I understand it exactly like you just said [Fri Jan 19 10:57:14 2018] Another way to say it is “Coq does not allow case analysis on sort [Prop] when the goal is in not in [Prop]” [Fri Jan 19 11:14:18 2018] anton-trunov: yes, what you proposed is indeed clearer [Fri Jan 19 11:14:51 2018] and would not have misled the user into rribeiro’s question [Fri Jan 19 11:15:17 2018] that's not exactly my proposition, I read it some time ago in the stdlib :) [Fri Jan 19 13:36:17 2018] pgiarrussu: regarding the topic, possibly... but it also probably won't fit there [Fri Jan 19 13:36:37 2018] possibly we should have a channel faq page somewhere [Fri Jan 19 13:36:45 2018] s/su/so/ [Fri Jan 19 14:03:32 2018] dh` this reminds me, why is the Feit-Thomson link going to some weird french thing (is it on architecture?) [Fri Jan 19 14:05:21 2018] don't ask me, that link's been in there since I first came here :-) [Fri Jan 19 14:05:44 2018] yeah, it's been dead for a long time... [Fri Jan 19 14:44:54 2018] wondering who can change the topic [Fri Jan 19 14:45:25 2018] OK, only channel ops [Fri Jan 19 14:46:51 2018] johnw: could you remove or replace the dead Feit-Thompson link from the topic? [Fri Jan 19 14:48:02 2018] johnw also seems the only OP around [Fri Jan 19 14:48:37 2018] ah wait, guessing contrapumpkin and Cale might be alt-nicks of copumpkin and cale? [Fri Jan 19 14:48:52 2018] yeah I'm copumpkin [Fri Jan 19 14:48:56 2018] what's up? [Fri Jan 19 14:49:38 2018] or if there's a better link, I can put it back [Fri Jan 19 14:51:19 2018] contrapumpkin: thanks a lot! [Fri Jan 19 14:52:01 2018] wait, the proof is from 2012... https://www.msr-inria.fr/news/feit-thomson-proved-in-coq/ [Fri Jan 19 14:58:37 2018] heh, has it been in the channel topic since then? [Fri Jan 19 15:04:44 2018] dh`: CoInductive conat := coO CoInductive delayed (A : Set) := hold_on (next : delayed A) | done (result : A). CoFixpoint [Fri Jan 19 15:04:46 2018] oops [Fri Jan 19 15:04:48 2018] sorry wasnt done writing [Fri Jan 19 15:06:50 2018] CoInductive conat := coO | coS (pred : conat). [Fri Jan 19 15:06:52 2018] CoInductive delayed A := hold_on (next : delayed A) | done (result : A). [Fri Jan 19 15:06:59 2018] CoFixpoint timer {A} (process : delayed A) : conat := match process with hold_on _ next => coS (timer next) | done _ _ => coO end. [Fri Jan 19 15:08:03 2018] if we implement a suitable turing-complete interpreter as a cofixpoint that delays as necessary, we can time it; then, we'd be able to solve the halting problem if we had conat ~ nat + unit [Fri Jan 19 15:08:26 2018] oo [Fri Jan 19 15:08:32 2018] I need to think about that :-) [Fri Jan 19 15:09:56 2018] so making the type coinductive means pred can be infinitely long? [Fri Jan 19 15:11:56 2018] CoFixpoint omega := coS omega. [Fri Jan 19 15:12:08 2018] honestly tho u shouldve been able to intuit this from the fact that omega + 1 is not a discrete space [Fri Jan 19 15:12:10 2018] :] [Fri Jan 19 15:12:50 2018] "thou shouldst" :-p [Fri Jan 19 15:13:02 2018] oh wait, that was a 'u' for 'you' wasn't it, n/m [Fri Jan 19 15:13:21 2018] yeah [Fri Jan 19 15:13:28 2018] what did you think it was... [Fri Jan 19 15:13:58 2018] I dunno, the automated typo fixer read it as "thou should've" [Fri Jan 19 15:14:02 2018] hah [Fri Jan 19 15:14:24 2018] anyway, insert sarcastic remarks about wondering where my friend's college roommate U is [Fri Jan 19 15:14:38 2018] 🤔 [Fri Jan 19 15:14:52 2018] never forget: countable ≠ discrete [Fri Jan 19 15:16:25 2018] anyway I don't remember how we got onto conats last night [Fri Jan 19 15:16:49 2018] infinite bitstrings or something [Fri Jan 19 15:17:43 2018] wait, fuk, i just had a thought [Fri Jan 19 15:18:07 2018] does just having decidable equality tell us that [n <> omega -> finite n] [Fri Jan 19 15:18:24 2018] right, but somehow we went from arbitrarily large bitstrings for arbitrarily large integers to actually infinite ones, when that wasn't what the original question wanted [Fri Jan 19 15:18:32 2018] lol [Fri Jan 19 15:18:54 2018] You don't have decidable equality on conat, right? [Fri Jan 19 15:19:05 2018] well [Fri Jan 19 15:19:08 2018] now im thinking about it [Fri Jan 19 15:19:11 2018] but im almost certain you dont [Fri Jan 19 15:19:18 2018] you shouldn't, you have to sample infinitely much of it to see if two are really the same [Fri Jan 19 15:19:19 2018] hmmmmmmmmmmmmmm [Fri Jan 19 15:19:25 2018] dh`: oh, NOW you're convinced [Fri Jan 19 15:19:29 2018] I have the same intuition, yes [Fri Jan 19 15:19:50 2018] well yes, that's because last night half of what was being said was at cross-purposes [Fri Jan 19 15:20:15 2018] Having something that would tell you (n : conat) is either omega or the same as a nat would basically give you an equivalence between nat and conat I think [Fri Jan 19 15:20:30 2018] yes that would be problematic, BUT [Fri Jan 19 15:20:34 2018] 15:18 does just having decidable equality tell us that [n <> omega -> finite n] [Fri Jan 19 15:20:58 2018] I agree, it's the missing step x) [Fri Jan 19 15:21:42 2018] I dislike coinductives. It's obvious that there should be nothing else than omega and a finite number of applications of cS, but I'm not even sure you can prove it... [Fri Jan 19 15:21:58 2018] (even with decidable equality I mean) [Fri Jan 19 15:21:58 2018] of course you can't, that'd give you the equivalence :v [Fri Jan 19 15:22:30 2018] that probably requires reasoning about the object having been constructed decidably [Fri Jan 19 15:22:32 2018] as in [Fri Jan 19 15:22:49 2018] if you go off for an infinite amount of time you can build something that's not either finite or omega [Fri Jan 19 15:23:32 2018] well if we want to delve into this kind of thing we shuold probably clarify what kinds of equality we mean [Fri Jan 19 15:24:35 2018] anyway, I need to work. [Fri Jan 19 15:24:46 2018] I spent too much of last night on (finite) bitstring integers [Fri Jan 19 15:24:59 2018] I am too easily nerdsniped by such things. [Fri Jan 19 15:25:12 2018] and coq makes it so easy to spend hours fiddling with something like that [Fri Jan 19 15:26:38 2018] >:) [Fri Jan 19 15:28:24 2018] benzrf: agda copatterns are a somewhat understandable presentation of coinductives, nothing else makes enough sense to me [Fri Jan 19 15:28:49 2018] but TL;DR. in one step you can only do a *finite observation* [Fri Jan 19 15:29:01 2018] test if a conat is z or S (c: conat) [Fri Jan 19 15:29:33 2018] you can’t do an infinite number of steps in one go [Fri Jan 19 15:30:36 2018] well, certainly [Fri Jan 19 15:38:25 2018] ooh, this is quite interesting https://github.com/coq/coq/wiki/extensional_equality [Fri Jan 19 15:38:48 2018] i'd previously noticed, actually, that what it calls "instensional families" seemed a bit suspicious somehow in the context of stuff like univalence [Fri Jan 19 15:39:08 2018] *intensional [Fri Jan 19 15:41:10 2018] i think what i noticed was that if you somehow have univalence and canonicity then you could do [Inductive foo : Set -> Prop := foo_bool : foo bool | foo_sum : foo (unit + unit)] [Fri Jan 19 15:41:31 2018] er, fuck [Fri Jan 19 15:41:55 2018] i think what i noticed was that if you somehow have univalence and canonicity then you could do [Inductive is_bool : Set -> Prop := foo_bool : foo bool] and then prove [bool = unit + unit] and rewrite by that, and then what would that term normalize to? [Fri Jan 19 15:44:07 2018] benzrf: IIUC cubical type theory answers that question [Fri Jan 19 15:44:13 2018] but I don’t know the answer [Fri Jan 19 15:44:56 2018] the idea I do get is that to rewrite by a proof `p` that bool = unit + unit you need to *run* p back and forth to convert bools into unit + unit and viceversa [Fri Jan 19 15:45:13 2018] yeah, i know about that and its very neat [Fri Jan 19 15:45:20 2018] the problem here is that you cant do that because it's a phantom type [Fri Jan 19 15:45:30 2018] well, in any case, i think the basic cubical theory doesnt have an internalized mechanism for introducing new inductive families [Fri Jan 19 15:45:44 2018] and in particular i believe the canonicalization proof only applied to the theory w/ nats or something [Fri Jan 19 15:46:14 2018] then you know more than me [Fri Jan 19 15:47:10 2018] :> [Fri Jan 19 15:47:41 2018] In cubical it would normalize to something with their `glue` primitive I believe [Fri Jan 19 15:48:01 2018] o [Fri Jan 19 15:48:07 2018] well that's not quite "canonical" form is it? or [Fri Jan 19 15:48:56 2018] that seems an extended notion of canonical [Fri Jan 19 15:49:11 2018] Cypi: would “glue” be a sort of cast [Fri Jan 19 15:49:17 2018] ? [Fri Jan 19 15:49:30 2018] I'm not quite sure honestly [Fri Jan 19 15:49:33 2018] I was thinking something similar for the example on the wiki [Fri Jan 19 15:50:27 2018] benzrf: if `glue` is a cast, its argument would have to be canonical in the usual sense [Fri Jan 19 15:50:35 2018] that is, start with a constructor [Fri Jan 19 15:51:15 2018] this is similar to how HoTT adjoins new constructors to identity types [Fri Jan 19 15:51:25 2018] hm, I might be misspeaking [Fri Jan 19 15:52:52 2018] benzrf: in http://math.andrej.com/2013/08/28/the-elements-of-an-inductive-type/ Andrej Bauer disputes against > An inductive type contains exactly those elements that we obtain by repeatedly using the constructors. [Fri Jan 19 15:55:25 2018] so pgiarrusso have you checked out cubical at all or only know it by reputation as a compute-y theory into which hott can be interpreted [Fri Jan 19 15:55:44 2018] benzrf: the latter I’m afraid [Fri Jan 19 15:56:08 2018] I looked at some slides, they made some sense but didn’t stick [Fri Jan 19 15:56:36 2018] benzrf: re the Bauer post on HoTT and canonicity, if you’re familiar with freely generated algebraic structures (e.g. freely generated groups), you might have a better idea: freely generated groups have not just the generators but also elements adjoined by the group operations [Fri Jan 19 15:57:07 2018] benzrf: did I already say nonsense on cubical you noticed? apologies if so [Fri Jan 19 15:57:30 2018] I tried to mark speculation as such [Fri Jan 19 15:58:19 2018] no you didnt say nonsense afaict :) [Fri Jan 19 15:58:36 2018] you just didnt say much too specific so i thought it might be possible you hadnt looked into it much [Fri Jan 19 15:59:05 2018] in any case you should check it out because its fuckin neat [Fri Jan 19 16:02:24 2018] let’s say it’s on my reading list, \omega^1 lives in the future [Fri Jan 19 16:02:36 2018] kidding, but too much to do [Fri Jan 19 16:02:48 2018] got a good pointer though? [Fri Jan 19 16:12:20 2018] pointers are for C programmers [Fri Jan 19 16:13:34 2018] the original paper is good though (here it is with nicer formatting than on arxiv http://www.cse.chalmers.se/~simonhu/papers/cubicaltt.pdf) [Fri Jan 19 16:14:28 2018] well, slightly nicer [Fri Jan 19 16:24:40 2018] hey. I'm looking at ways to disable just the _ -> _ arrow notation. I know that disabling individual notations is something that's being considered for Coq, and e.g. is being worked on in https://github.com/coq/coq/pull/703 but I thought a decent stopgap solution for now would be to just create *another* notation on top of _ -> _ [Fri Jan 19 16:24:50 2018] to that end I made this: [Fri Jan 19 16:24:53 2018] Notation "'forall' ( '_' : A ), B" := (A -> B) [Fri Jan 19 16:24:53 2018] (at level 200, format "'forall' '(' '_' ':' A '),' B") : type_scope. [Fri Jan 19 16:25:47 2018] now checking (forall (_ : nat), bool) works okay, but unfortunately (forall (n : nat), bool) doesn't work. I thought about using "fa" instead of "forall", but that doesn't work either [Fri Jan 19 16:26:17 2018] can anybody think of a way of making this do what I intend? [Fri Jan 19 16:29:54 2018] o__o [Fri Jan 19 16:31:38 2018] it's for teaching, in case that's you wondering why on earth anybody would bother to do that :-) [Fri Jan 19 16:34:09 2018] how so? [Fri Jan 19 16:34:21 2018] unfold "how so?". [Fri Jan 19 16:35:35 2018] I didn't realize -> was a notation; that explains a number of oddities [Fri Jan 19 16:35:35 2018] I mean the idea is that you don't introduce syntactic sugar to students before they understand the structures behind the syntactic sugars. I'm trying to minimise the number of syntactic constructions for people to learn [Fri Jan 19 16:35:57 2018] also I keep wishing for a paper on the innards of notations so I can implement them elsewhere [Fri Jan 19 16:36:04 2018] dh_work: you can see how it's defined using Locate "_ -> _". [Fri Jan 19 16:36:15 2018] right, you have to think to look though [Fri Jan 19 16:36:23 2018] indeed, which is entirely my point :-) [Fri Jan 19 16:36:51 2018] sbp: i understand that reasoning, but i feel like this is part of that fallacy where you try to teach by loading the principles up front [Fri Jan 19 16:38:02 2018] I suppose it's just an alternative, but it's how I prefer to teach it. certainly many people learned about -> as a construction on its own and made good progress without thinking about how it all worked under the covers, myself included. but I want to teach it from a principles up front perspective, for better or worse [Fri Jan 19 16:40:06 2018] sbp: could `Notation "'forall' ( '_' : A ) , B" := (A -> B) (at level 200).` work? [Fri Jan 19 16:40:07 2018] idk, principles-up-front is extremely appealing to me, but ive started to believe that it's just not suited for how human brains work :( [Fri Jan 19 16:40:15 2018] (same as yours, just less quotes around punctuation) [Fri Jan 19 16:40:33 2018] it also depends on the students; it's one thing with upper-level grad students, and another with undergrads who aren't real solid on how to write proofs at all [Fri Jan 19 16:42:08 2018] Cypi: ah, Coq collapses that to forall ( _ : nat), bool, which probably indicates where the problem is: it really needs the space before _ otherwise there's a problem [Fri Jan 19 16:42:34 2018] benzrf: there are advantages. if you're teaching the history of logic, for example, you can link the structures with things like Meredith's condensed detachment, and compare it to Nicod's axioms and so on. I don't think that any one approach is the absolute way it must be done; people can gravitate towards the approach they like the most [Fri Jan 19 16:42:52 2018] Right, it does add a space. You don't need to write it yourself though, so I guess it's fine? [Fri Jan 19 16:43:03 2018] dh_work: absolutely [Fri Jan 19 16:43:30 2018] Cypi: that's a point, that's weird. so why does it work whereas mine didn't? [Fri Jan 19 16:43:47 2018] I have honestly no idea, notations are complicated x) [Fri Jan 19 16:43:52 2018] hehe, fair enough [Fri Jan 19 16:43:57 2018] thank you! [Fri Jan 19 16:44:08 2018] you want a format annotation [Fri Jan 19 16:44:24 2018] yeah, but my format annotation (see above, original query) broke it [Fri Jan 19 16:44:34 2018] oh woops [Fri Jan 19 16:44:36 2018] >.< [Fri Jan 19 16:44:43 2018] perhaps just adding a space, using two spaces, before the underscore would do it... [Fri Jan 19 16:45:17 2018] nope, two spaces before '_' doesn't work either [Fri Jan 19 16:45:36 2018] anyway Cypi's magic incantation seems to do the trick, very grateful [Fri Jan 19 16:46:33 2018] There will still be discrepancies between `forall (_ : nat), nat` and `forall (n : nat), n = n` (in the latter, Coq removes the parentheses when printing...) [Fri Jan 19 16:46:36 2018] but well. [Fri Jan 19 16:49:12 2018] hopefully precedence will be picked up more intuitively than a brand new syntax. I mean if you think that "nat, n" or ": nat," is an atomic part of the syntax then you've probably gotta go back quite a few steps anyway [Fri Jan 19 16:49:50 2018] I'll also try to avoid paren dropping as best I can. I won't avoid -> forever [Fri Jan 19 16:51:20 2018] and one last thing (maybe), you might want to add `right associativity` to the Notation. Take a look at `forall ( _ : nat), forall (_ : nat), nat` [Fri Jan 19 16:53:09 2018] oh yeah. that's okay though, the extra parens are fine [Fri Jan 19 16:53:35 2018] that's actually another common "what?" moment for people learning -> too [Fri Jan 19 16:53:50 2018] they're so used to everything being left associative that a -> b -> c meaning a -> (b -> c) can be a bit of a moment [Fri Jan 19 16:53:51 2018] yes [Fri Jan 19 16:54:23 2018] then they can learn about currying and why we do that instead of using the left associative \/ as an equivalent [Fri Jan 19 16:54:30 2018] or rather, that (a -> b) -> c isn't a -> b -> c [Fri Jan 19 16:54:45 2018] er, /\ even [Fri Jan 19 16:54:55 2018] which tends to come uup when people discover they can't write those types in ml [Sat Jan 20 00:24:29 2018] Is there a way to forget a piece of Ltac? Like I want to have `Ltac my_tactic := blah`, but then redefine it later with `Ltac my_tactic := blah`. I know I can use `Ltac my_tactic ::= blah` to redefine, but I don't want to do that because this is for examples in a literate coq file, basically, and I want to keep it consistent. [Sat Jan 20 00:24:58 2018] I wouldn't care too much, but if somebody copy / pastes the `Ltac my_tactic ::= blah` thing it fails if it isn't defined before >_< [Sat Jan 20 01:07:52 2018] Chobbes: you can use Sections [Sat Jan 20 01:08:10 2018] (or you could just add a comment to explain the `::=` or something like that) [Sat Jan 20 01:35:29 2018] or fix your literate tool to generate a different output file for each example [Sat Jan 20 11:50:29 2018] When using Program Fixpoints with measure functions I sometimes get obligations to proove that the measure really decreases which are unprovable because I get no hypotheses relating the left and right side of the goal inequality in any way. [Sat Jan 20 11:51:41 2018] https://www.irccloud.com/pastebin/Dcp63E1F/ [Sat Jan 20 11:52:58 2018] In this example the first obligation is one of those cases where I'm screwed [Sat Jan 20 11:54:14 2018] Any tricks to avoid this? [Sat Jan 20 12:33:36 2018] mgttlinger: why does it seem like cmpl d = 1 for all d [Sat Jan 20 12:35:04 2018] lyxia: Because I made a mistake there ;) but that does not change the problem of the mising hypotheses. If you change the recursive case in the measure function to S (cmpl x * cmpl x0) the same problem occurs. [Sat Jan 20 12:37:17 2018] Ok, right [Sat Jan 20 12:38:34 2018] mgttlinger: it seems to be because the recursive call of demo is hidden in flat_map [Sat Jan 20 12:39:52 2018] "demo e" you need some nonlocal reasoning to know that "e" will actually be instantiated only with elements of the lists [Sat Jan 20 12:41:55 2018] mgttlinger: try changing the type of "e" to also carry a proof that its measure is smaller than dp's [Sat Jan 20 12:43:23 2018] Hm that seems like a lot of pain given that my measure and my types are more complicated in my real case but I will try that. Thanks for your help. [Sat Jan 20 13:02:43 2018] another way is to write a different flat_map that passes a proof to the map function that the argument's In the original list [Sat Jan 20 13:03:28 2018] I had this same issue with folds a month ago and that worked nicely [Sat Jan 20 13:04:44 2018] ideally one would like to have a theorem of the form forall f xs, flat_map f xs -> f is only called on elements of xs [Sat Jan 20 13:04:56 2018] but there's no way to write that down [Sat Jan 20 13:05:34 2018] although hmm, you can write (and easily prove) forall f x xs, In x xs -> In (f x) (map f xs) and that might work for you [Sat Jan 20 13:05:56 2018] you might need <-> [Sat Jan 20 13:07:23 2018] although that won't work for flat_map, n/m. [Sat Jan 20 13:12:50 2018] also <-> is only true for injective functions... [Sat Jan 20 13:23:40 2018] mgttlinger: I’d also modify flat_map, but I don’t think you need to pass `In`; you can pass directly the needed hypothesis on the measure [Sat Jan 20 13:24:19 2018] that depends if you want a reusable flat_map' or not :-) [Sat Jan 20 13:24:50 2018] this issue is going to come up every time there are higher-order functions [Sat Jan 20 13:25:03 2018] and it occurs to me to wonder if there's a general solution [Sat Jan 20 13:25:20 2018] sized types are a general solution, but they’re tricky and not around in Coq [Sat Jan 20 13:26:06 2018] nah, a general solution for the problem of addressing the calls to f :-) [Sat Jan 20 13:26:40 2018] hm... wait, sorry, sized types help with structural recursion through higher-order functions [Sat Jan 20 13:26:57 2018] in my case I did not have lists, so I wouldn’t know how to use the design with `In` [Sat Jan 20 13:27:38 2018] (unless maybe you generalized that to W-types or something similarly datatype-polymorphic and probably not so usable) [Sat Jan 20 13:28:18 2018] your solution might help for a list library, though some details are unclear [Sat Jan 20 13:28:44 2018] I think having dependent forms of map and fold that provide proofs of In to f is a general solution, but it's not a tidy one. [Sat Jan 20 13:29:04 2018] well, it’s general for lists [Sat Jan 20 13:29:17 2018] not about structural recursion on other datatypes :-) [Sat Jan 20 13:29:49 2018] In is just as generalizable as map and fold are :-) [Sat Jan 20 13:29:50 2018] and generalizing In to other datatypes would have those problems [Sat Jan 20 13:29:53 2018] Maybe I'm to naive wouldnt the solution be to unfold the higher order function? Isn't that what the "normal" structural induction checker does? [Sat Jan 20 13:29:55 2018] and I think it's still sufficient in general [Sat Jan 20 13:30:26 2018] mgttlinger: so you *could* unfold the higher-order function, which I think structural induction checking does *not* do [Sat Jan 20 13:31:07 2018] e.g. when you're folding over a map, it calls f key value z, and so what you need is In key value map [Sat Jan 20 13:31:13 2018] But I can use map in "normal" fixpoints and the chercking is happy with that [Sat Jan 20 13:31:48 2018] map is fine when the map function doesn't involve a local recursive call [Sat Jan 20 13:32:01 2018] agreed with dh` [Sat Jan 20 13:32:09 2018] when it does, things get messy. [Sat Jan 20 13:32:26 2018] What does "local recursive" mean? [Sat Jan 20 13:32:35 2018] a recursive call to the function you're in. [Sat Jan 20 13:32:50 2018] But that works with map [Sat Jan 20 13:32:56 2018] Not IME. [Sat Jan 20 13:33:01 2018] not IME either [Sat Jan 20 13:33:14 2018] Wait, let me check my code [Sat Jan 20 13:34:06 2018] if you don't use Program Fixpoint it just flatly refuses to go, and if you do you get these proof headaches [Sat Jan 20 13:34:13 2018] dh`: so how do you use `In`? Do you prove that `In x xs -> x < xs` (for the appropriate `<`) [Sat Jan 20 13:34:19 2018] doh [Sat Jan 20 13:34:25 2018] dh`: ^^ [Sat Jan 20 13:36:04 2018] dh`: in my use-case (recursion over types) I agree I could generalize `In` but that sounds like defining a datatype of *contexts* for holes in types (like for zippers), which I’d rather not do :-) [Sat Jan 20 13:37:18 2018] Maybe I'm missunderstanding something but in general in normal structural recursive fixpoints higher order functions were no problem in my code. See: https://gist.github.com/mgttlinger/cede4fd8fe96aa7f7996341f878a8eb5#file-demo-v-L154-L167 [Sat Jan 20 13:37:24 2018] well [Sat Jan 20 13:37:34 2018] I was thinking about it in terms of containers [Sat Jan 20 13:37:51 2018] i suspect for folding over abstract syntax the In becomes both trivial and annoying. [Sat Jan 20 13:40:06 2018] mgttlinger: curious, maybe Vector is different for this [Sat Jan 20 13:41:16 2018] maybe, but how? the indexing by length shouldn’t help, should it? [Sat Jan 20 13:41:28 2018] mgttlinger: also confused; I agree that inlining would work there, but I didn’t expect Coq to do it [Sat Jan 20 13:41:55 2018] (Agda doesn’t do inlining and I hear its termination checker is more powerful than Coq usually) [Sat Jan 20 13:42:12 2018] also, inlining up to which point? Hm... [Sat Jan 20 13:43:14 2018] https://stackoverflow.com/questions/47082796/when-does-the-termination-checker-reduce-a-record-accessor [Sat Jan 20 13:43:36 2018] There Joachim Breitner sais that certain things are inlined by the termination checker [Sat Jan 20 13:44:18 2018] (the thing described there is btw also the solution to the problem which the above gist was created to showcase) [Sat Jan 20 13:48:25 2018] Unfolding the flat_map in my fixpoint with measure could also solve the issue I see there, right? So the question is: Why is that function not unfolded anymore when a measure function is used for termination checking? [Sat Jan 20 13:49:18 2018] various things seem to be different when you use a measure. I don't know why... [Sat Jan 20 13:50:40 2018] mgttlinger: I don’t know if this is intentional [Sat Jan 20 13:50:57 2018] speculating on why: inlining does not scale too well [Sat Jan 20 13:51:03 2018] and with a measure, it is not necessary [Sat Jan 20 13:51:56 2018] My current (very limited) experience with fixpoints with measure functions is that they only work in very simple cases and otherwise generate unproovable and/or horribly many obligations very quickly. [Sat Jan 20 13:52:01 2018] I mean, inlining this function is fine, inlining a bigger one is not, but should the checker only inline up to a size limit? That would be pretty unpredictable [Sat Jan 20 13:52:25 2018] mgttlinger: for “many obligations” I often find proof automation useful [Sat Jan 20 13:53:23 2018] Local Obligation Tactic := program_simpl; . [Sat Jan 20 13:53:34 2018] pgiarrusso: I found automation to get rather slow when the obligations go into the hundreds. [Sat Jan 20 13:53:45 2018] you could imagine giving hints to the termination checker, e.g {measure foo inlining fold} [Sat Jan 20 13:54:03 2018] that would be nice [Sat Jan 20 13:54:28 2018] mgttlinger: do you get a hundred obligation from *one* definition? `Program` seems to like smaller ones better [Sat Jan 20 13:55:01 2018] that would make this kind of thing possible to handle without using Program, probably. [Sat Jan 20 13:55:14 2018] Oh jeah from my fixpoint in question in my code I currently get 84 obligations and havethe cases aren't even implemented in the function yet [Sat Jan 20 13:55:30 2018] *halve [Sat Jan 20 13:55:31 2018] that sounds like your function is too big. [Sat Jan 20 13:56:00 2018] Well the alternative would be splitting it into a lot of mutual fixpoints. [Sat Jan 20 13:56:23 2018] because most of the cases recurse over the whole thing [Sat Jan 20 13:56:29 2018] the main function can pass itself to the subfunctions [Sat Jan 20 13:56:47 2018] see https://github.com/Blaisorblade/minidot/blob/silr/ecoop17/dsubsup_total_rec_monotone.v#L210 [Sat Jan 20 13:57:04 2018] But wouldn'T the termination checker then again be required to unfold that? [Sat Jan 20 13:57:24 2018] well, I’m passing a proof the measure is smaller [Sat Jan 20 13:58:31 2018] that code checks pretty fast, and the result has a manageable size [Sat Jan 20 13:59:08 2018] my experience has been that for large functions, splitting the guts of each case into separate Definitions makes the whole thing check much, much faster. [Sat Jan 20 13:59:14 2018] before splitting it, one lemma took 2 minutes to prove and generated goals that occupied 2 MB (when pretty-printed) [Sat Jan 20 13:59:16 2018] dh`: same [Sat Jan 20 13:59:55 2018] dh`: and Coq code from Robert Krebbers (who formalized C11 in Coq) follows the same pattern [Sat Jan 20 14:00:36 2018] mgttlinger: Coq tries to be lazy when unfolding functions to reduce the size of goals and terms, so splitting the function helps there [Sat Jan 20 14:00:55 2018] Ok, I'll try that then [Sat Jan 20 14:01:13 2018] Thanks for your help [Sat Jan 20 14:01:49 2018] mgttlinger: to check the result, you might want to `Admit Obligations.` and print the generated term [Sat Jan 20 14:02:22 2018] another problem I had was that `Program` makes a mess of combined pattern matches and wildcards [Sat Jan 20 14:03:22 2018] (I think Program’s pattern match compiler is *worse*) [Sat Jan 20 14:04:59 2018] What do you mean? [Sat Jan 20 14:08:55 2018] I wonder if you could write lemmas with a form something like this: Lemma map_f_in: forall f xs x', map (fun x {{ In x xs }} => x') xs. [Sat Jan 20 14:09:05 2018] without needing a stronger proof term language [Sat Jan 20 14:09:24 2018] where you can put the/a goal inside the higher-order term [Sat Jan 20 14:09:40 2018] I suppose probably not, should go off and think about it though [Sat Jan 20 14:12:35 2018] dh`: I did something similar to define me a usable induction priciple for nested inductive types (one constructor contains vector of the type) which gives you as induction hypothesis in that case that the property holds for every element in the vector already [Sat Jan 20 14:24:29 2018] also you could define a map that allows the function to only work on elements of the list [Sat Jan 20 14:24:54 2018] https://www.irccloud.com/pastebin/gkEs0y7F/ [Sat Jan 20 15:13:07 2018] Cypi: IIRC in that 2MB-generated definition there were duplicated copies of the handling for fallback cases in pattern matching [Sat Jan 20 16:43:48 2018] pgiarrusso: well, in Coq there will be duplicated copied anyway for now, no magic there. It's possible that Program made it so that these fallback cases could not be recovered when printing back, indeed. [Sat Jan 20 16:44:07 2018] (all `match` are always completely expanded internally) [Sat Jan 20 16:44:17 2018] (by "internally" I mean in the kernel) [Sat Jan 20 16:47:40 2018] Cypi: i spoke too early [Sat Jan 20 16:48:02 2018] but Megabytes of output comes from emacs, I didn't make it up [Sat Jan 20 16:48:28 2018] I had a match on *two* values [Sat Jan 20 16:49:05 2018] It's generally true that you don't want to look at what Program produces if possible x) [Sat Jan 20 16:49:30 2018] yeah, but I was defining a predicate, not a function [Sat Jan 20 16:49:34 2018] so I had to [Sat Jan 20 16:49:57 2018] I'm happy the proof took just 2 minutes [Sat Jan 20 16:50:12 2018] comments in the code claimed a step took hours [Sat Jan 20 16:50:24 2018] and admitted a lemma [Sat Jan 20 16:50:51 2018] a lemma claiming that the result of the definition satisfied indeed its definiting equation [Sat Jan 20 16:53:53 2018] the case where I found having additional definitions critical involved multiply nested matches where all but one or two of several cases were the same [Sat Jan 20 16:54:05 2018] I get the feeling there's something in there that's exponential in the number of match cases. [Sat Jan 20 17:02:03 2018] dh_work: that feels very familiar [Sat Jan 20 17:09:02 2018] dh_work: so, if you add a wildcard case, even with a single match, Program thinks it’s a good idea to *copy all the other branches* in the handling of the wildcard case [Sat Jan 20 17:14:55 2018] dh_work Cypi: so the cost of a wildcard pattern in `Program` is proportional to the number of overall cases considered [Sat Jan 20 17:16:37 2018] the wildcard case gets compiled to a branch with hypotheses that the scrutinee is not an instance of each of the other patterns [Sat Jan 20 17:17:14 2018] which might or might not have to do with the strange obligation you get that I discharge with `discriminate` because it asks me to show that yes, distinct branches of the datatype are distinct [Sat Jan 20 17:17:47 2018] Cypi: so I didn’t speak so early, I had just forgot the details that made me have this impression [Sat Jan 20 17:17:56 2018] [Sat Jan 20 17:50:57 2018] right, I know it expands each match to an independent copy of each case, eliminating wildcards [Sat Jan 20 17:52:24 2018] and the size of *that* is exponential in the depth of the matching, but I was only three deep or so and with less than 10 cases per layer that's still not that many cases total, by computer standards. [Sat Jan 20 17:57:46 2018] dh_work: I think I had to use `unfold_sub` or friends to get to 2 MB [Sat Jan 20 17:58:20 2018] dh_work: did you have functions, or predicates to use in goals? [Sat Jan 20 17:58:25 2018] in my case it wasn't "takes minutes", it was "takes long enough to be annoying" [Sat Jan 20 17:58:42 2018] it was one of my regexp matcher functions [Sat Jan 20 18:00:07 2018] well, good that you found a way around it [Sat Jan 20 18:01:08 2018] modulo it being a pointless exercise, yes :-) [Sat Jan 20 18:01:57 2018] also, it wasn't the function itself that was slow but any use of it in a proof. [Sat Jan 20 18:06:48 2018] yeah same here [Sat Jan 20 18:08:05 2018] luckily, I followed existing scripts, and they prove by induction an “unfolding lemma” for the predicate (stating the predicate satisfied its defining equation) [Sat Jan 20 18:13:52 2018] oh, as for the other thing I mentioned earlier about higher-order functions, it's rubbish [Sat Jan 20 18:14:09 2018] dh_work: uh? [Sat Jan 20 18:14:32 2018] in what ways? [Sat Jan 20 18:14:33 2018] coming up with a way to write down proofs about the arguments passed to higher-order functions [Sat Jan 20 18:14:57 2018] it's not necessarily an invalid idea, but it's equivalent to giving coq support for program points, and that's a big deal given that coq's specifically not designed that way. [Sat Jan 20 18:15:30 2018] “program points”? [Sat Jan 20 18:15:50 2018] are you talking about this? > 8:08 PM I wonder if you could write lemmas with a form something like this: Lemma map_f_in: forall f xs x', map (fun x {{ In x xs }} => x') xs. [Sat Jan 20 18:15:56 2018] yes [Sat Jan 20 18:16:16 2018] that's equivalent to reasoning about the program point before f is called [Sat Jan 20 18:16:23 2018] the `x’` part made no sense, and `map` isn’t a proposition [Sat Jan 20 18:16:42 2018] ah [Sat Jan 20 18:17:24 2018] the notation is rubbish too obviously [Sat Jan 20 18:17:45 2018] I don’t mind, I just didn’t get it and made up something [Sat Jan 20 18:18:32 2018] the idea was to use {{ }} to introduce a context to put a proposition in [Sat Jan 20 18:19:03 2018] because there x is in scope so you can write about it. [Sat Jan 20 18:19:25 2018] if you want me to get it, you should say that lemma in words [Sat Jan 20 18:19:32 2018] but you don’t have to of course :-) [Sat Jan 20 18:19:49 2018] I am fine about writing `map’ : forall (xs: List a), (f: forall (x: A), In x xs -> B) -> List B`, but apparently it’s not what you means [Sat Jan 20 18:19:50 2018] *meant [Sat Jan 20 18:19:59 2018] and I start to guess what you did mean: [Sat Jan 20 18:20:13 2018] whenever `f` is called, its argument `x` is such that `In x xs` exists [Sat Jan 20 18:21:56 2018] dh_work: if you embed Hoare logic in Coq (as many have done), you can probably type `map` that way [Sat Jan 20 18:21:58 2018] the way I intended it to be read is something like: for all f xs x', if you have "map (fun x => x') xs" then you can conclude In x xs, within the context of f where this is a well-formed statement [Sat Jan 20 18:22:54 2018] OK, but with `x` you mean the actual argument of `f`, not the object variable that `f` binds [Sat Jan 20 18:23:06 2018] still, I sort of get what you mean [Sat Jan 20 18:23:11 2018] yes, this is true for all f [Sat Jan 20 18:23:18 2018] because it's a property of map. [Sat Jan 20 18:24:08 2018] or is that not what you meant? [Sat Jan 20 18:24:32 2018] not really... [Sat Jan 20 18:24:47 2018] I think I got what you mean anyway [Sat Jan 20 18:25:15 2018] you mean that when `fun x => x’` gets called and `x` gets a value, then `In x xs` is true [Sat Jan 20 18:25:17 2018] anyway, yes you can write this down if you have hoare logic for coq terms, but is that a thing? it's easy (well, relatively) to work up hoare logic for some abstract syntax you have, but natively? [Sat Jan 20 18:25:32 2018] yes. [Sat Jan 20 18:25:40 2018] indeed, not for Coq terms [Sat Jan 20 18:26:02 2018] (and there shouldn't have been a loose f in the foralls) [Sat Jan 20 18:26:11 2018] that's what I thought [Sat Jan 20 18:26:43 2018] or, at least not that I know of [Sat Jan 20 18:26:47 2018] the best I’ve seen is http://iris-project.org/pdfs/2017-popl-proofmode-final.pdf [Sat Jan 20 18:26:50 2018] if that existed, it would more or less obsolete Program I think [Sat Jan 20 18:27:09 2018] where you get *tactics* for an Hoare logic embedded like that [Sat Jan 20 18:27:29 2018] well, Program does something a bit different [Sat Jan 20 18:27:35 2018] *but* [Sat Jan 20 18:27:57 2018] Program isn’t built-in, is it? There’s probably a plugin, but it’s not in the trusted core [Sat Jan 20 18:28:06 2018] so if you wanted you could write HoareProgram [Sat Jan 20 18:28:29 2018] the biggest annoyance would be picking the right encoding of state (because you want one, no?) [Sat Jan 20 18:29:03 2018] so you still would not quite have native functions, but functions in some State monad (or similar) [Sat Jan 20 18:29:09 2018] but otherwise I guess you could? [Sat Jan 20 18:29:17 2018] well, state is a different issue [Sat Jan 20 18:29:36 2018] or rather, a much bigger extension [Sat Jan 20 18:29:49 2018] does hoare logic without mutation make sense? [Sat Jan 20 18:29:57 2018] sure. [Sat Jan 20 18:30:08 2018] what we've just been talking about is an application, right? [Sat Jan 20 18:30:14 2018] no mutation in map... [Sat Jan 20 18:30:16 2018] OK, no clue. Then scratch state from what I said [Sat Jan 20 18:30:22 2018] very fair point [Sat Jan 20 18:31:49 2018] although actually [Sat Jan 20 18:31:58 2018] writing anything down about the uses of f is still a problem [Sat Jan 20 18:32:18 2018] OTOH, I mean, you can also just write map xs (f : {x | In x xs}) *today* with Program [Sat Jan 20 18:32:31 2018] it’s just a curried variant of the `f` I had in mind [Sat Jan 20 18:32:36 2018] you can write {P} map f xs {Q} but that doesn't get you anywhere, [Sat Jan 20 18:32:37 2018] *of the `map` [Sat Jan 20 18:32:45 2018] and if you write {P} f {Q} that's general statements of f [Sat Jan 20 18:33:02 2018] you'd need some syntax for hoare triples with negative occurrences of propositions [Sat Jan 20 18:33:33 2018] and that seems like it could get either weird or unsound (or both) very rapidly. [Sat Jan 20 18:33:37 2018] well, `map` gets a function `f` whose precondition includes “my argument is in `xs`) [Sat Jan 20 18:34:08 2018] how do you write down the statement that map can accept such functions? [Sat Jan 20 18:34:45 2018] let me check a second if Iris can do it [Sat Jan 20 18:34:47 2018] in the statement of map, we have the same problem as in coq where x isn't in scope and can't be addressed [Sat Jan 20 18:34:48 2018] or, a minute [Sat Jan 20 18:35:33 2018] dh_work: but we have talked about solutions when writing `map` [Sat Jan 20 18:35:44 2018] in Coq we’d need a new `map` [Sat Jan 20 18:36:08 2018] if we have Curry-style typing we don’t [Sat Jan 20 18:36:11 2018] all the solutions that work involving passing an explicitly proof [Sat Jan 20 18:36:17 2018] s/ly// [Sat Jan 20 18:36:29 2018] what about `{x | In x xs}` ? [Sat Jan 20 18:36:42 2018] because that proof can be manufactured easily enough inside map when making the call. [Sat Jan 20 18:36:50 2018] hmm. [Sat Jan 20 18:37:05 2018] but if you don’t want even that, let me check the Hoare logic approach [Sat Jan 20 18:37:12 2018] that probably works actually [Sat Jan 20 18:38:15 2018] so, map {t1 t2} (f: {x: In x xs) -> t2) (xs: list t1) : list t2 [Sat Jan 20 18:44:23 2018] what’s convenient with `{x: In x xs}` is that the proofs can be filled in via separate `Program` obligations [Sat Jan 20 18:44:58 2018] it does work, but requires Program [Sat Jan 20 18:45:10 2018] sure [Sat Jan 20 18:45:15 2018] and you can't refer to xs before binding it, so you can't write the arguments in the traditional order [Sat Jan 20 18:45:39 2018] Program Fixpoint map' {t1 t2} (xs: list t1) (f: {x | In x xs} -> t2) : list t2 := [Sat Jan 20 18:45:39 2018] match xs with [Sat Jan 20 18:45:39 2018] | [] => [] [Sat Jan 20 18:45:39 2018] | x :: more => (f x) :: map' more f [Sat Jan 20 18:45:39 2018] end. [Sat Jan 20 18:45:42 2018] should you really care, maybe a notation could help? [Sat Jan 20 18:45:50 2018] though I wouldn’t define such a notation [Sat Jan 20 18:46:28 2018] It generates two obligations, but they're both trivial; they correspond to the two cases of In. [Sat Jan 20 18:46:40 2018] :-) [Sat Jan 20 18:46:48 2018] meanwhile, I’ve just seen that Iris allows writing a specification of some higher-order function (like `map`) where the input `f` is restricted to satisfy some Hoare triple [Sat Jan 20 18:47:06 2018] now the question is whether this works for proving something like the original example that started this discussion [Sat Jan 20 18:47:11 2018] but I'd expect that it should. [Sat Jan 20 18:47:32 2018] that's the other way around [Sat Jan 20 18:47:50 2018] dh_work: page 32 of http://iris-project.org/tutorial-pdfs/iris-lecture-notes.pdf has such a specification, for `foldr` [Sat Jan 20 18:48:04 2018] although maybe it's sufficient [Sat Jan 20 18:48:27 2018] dh_work: well, if you only prove `foldr` correct for such a function, then you’re forced to use it accordingly [Sat Jan 20 18:48:44 2018] so I’d suspect it’s sufficient [Sat Jan 20 18:49:26 2018] in those notes, the base language is not typed per se, all the typing is done through the Hoare logic [Sat Jan 20 18:50:07 2018] on your doubts on soundness: that is a pretty fancy higher-order impredicative separation logic, and proving it sound requires some advanced techniques [Sat Jan 20 18:50:46 2018] > 12:33 AM you'd need some syntax for hoare triples with negative occurrences of propositions [Sat Jan 20 18:51:07 2018] I think that resembles concerns that are correct and that they had to fix [Sat Jan 20 18:52:04 2018] I need to read up more on iris before I can fully follow the example [Sat Jan 20 18:52:33 2018] honestly, I think me too [Sat Jan 20 18:52:47 2018] and I’ve had serious reasons to study it [Sat Jan 20 18:53:21 2018] regarding negative occurrences: somewhere deep down, they had to find a semantics for types similar to `Inductive T := Constructor (T -> T).` [Sat Jan 20 18:53:32 2018] and a semantics that preserves consistency [Sat Jan 20 18:53:53 2018] part of the trick is called guarded recursion, in case you heard it [Sat Jan 20 18:54:04 2018] the other part of the trick are step-indexed logical relations [Sat Jan 20 18:54:24 2018] but none of this is trivial [Sat Jan 20 18:55:10 2018] *anyway*, I’m learning on Iris and so I tend to mention it everywhere it can be relevant [Sat Jan 20 18:55:22 2018] I should be, it's on my list [Sat Jan 20 18:55:26 2018] (but so are about a million things) [Sat Jan 20 18:55:36 2018] homepage: http://iris-project.org/ [Sat Jan 20 18:55:46 2018] or see also the POPL’18 keynote on Youtube [Sat Jan 20 18:56:04 2018] though that one looks a bit more at a different aspect of Iris [Sat Jan 20 18:57:35 2018] well, remember, I'm ultimately a systems guy. coq is all very well but I'd rather have a framework that supports state and concurrency [Sat Jan 20 18:58:10 2018] state and concurrency are for piece of shit losers tbh [Sat Jan 20 18:58:14 2018] 😎 [Sat Jan 20 18:58:32 2018] because many of the problems I have that need dealing with involve both state and concurrency, like file systems [Sat Jan 20 18:59:26 2018] the real world is for losers [Sat Jan 20 18:59:37 2018] just pretend there's no such thing as computers [Sat Jan 20 19:01:29 2018] dh_work: Iris *is* for state and concurrency [Sat Jan 20 19:01:55 2018] in those lecture notes, the language they consider has both [Sat Jan 20 19:02:04 2018] fork and cas are primitives [Sat Jan 20 19:02:13 2018] it *is* an academic language [Sat Jan 20 19:02:21 2018] but they’re also working on Rust [Sat Jan 20 19:02:58 2018] and as far as academic things go, they have a bunch of somewhat realistic case studies [Sat Jan 20 19:03:19 2018] of course, other works using concurrent separation logic are more advanced and in use at Facebook [Sat Jan 20 19:03:32 2018] right [Sat Jan 20 19:03:43 2018] that's why iris was already on my list of stuff to look into [Sat Jan 20 19:04:55 2018] of course, if you don’t ask your separation logic checker to produce Coq proofs, the authors can focus on other aspects [Sat Jan 20 19:05:38 2018] but IIUC Iris can verify properties that other systems can’t [Sat Jan 20 19:06:39 2018] I’m not sure verifiers for C can show that some module works because some type is abstract so only that module can manipulate a certain structure [Sat Jan 20 19:06:52 2018] (but I don’t know) [Sat Jan 20 19:07:16 2018] anyway, I’m using Iris for different stuff, it just seems relevant [Sat Jan 20 19:07:26 2018] time to stop blathering though [Sat Jan 20 19:08:35 2018] a verifier for C ought to be written to use that assumption with the implicit or not so implicit condition that you also prove/check memory safety. [Sat Jan 20 19:08:45 2018] (otherwise you can't conclude anything useful about C code) [Sat Jan 20 19:10:01 2018] anyway what I really want is something with the interactivity of coq that similarly lets you write separable theorems about code elements, with as little hoare logic as possible. [Sat Jan 20 19:10:21 2018] IIUC separation logic can do safety, even automatically [Sat Jan 20 19:11:05 2018] safety for C involves proof obligations about array bounds, and also about uses of void pointers and so on [Sat Jan 20 19:11:05 2018] (“as an exercise, let’s automatically verify the libc of some BSD is safe”) [Sat Jan 20 19:11:25 2018] that would be nice to do! [Sat Jan 20 19:11:48 2018] as of the last I looked there's nothing like a toolset that can even think about it yet, though. [Sat Jan 20 19:11:57 2018] vst wants to be there, but they've still got a ways to go afaik [Sat Jan 20 19:12:19 2018] and if you want to prove that a malloc implementation is safe, that involves a lot of extra glop. [Sat Jan 20 19:13:04 2018] the ones in Coq aren’t so automated; external ones do better [Sat Jan 20 19:13:17 2018] what I said is close to something people actually do [Sat Jan 20 19:14:52 2018] this is close, not quite what I read though: http://www.eecs.qmul.ac.uk/~ddino/papers/nasa-infer.pdf [Sat Jan 20 19:18:00 2018] huh, hadn't seen that one, guess because it's proprietary [Sat Jan 20 19:20:22 2018] not sure it’s distinct from http://fbinfer.com/docs/hello-world.html#hello-world-c [Sat Jan 20 19:20:50 2018] anyway, Facebook Infer also uses bi-abduction, which is the core trick in that paper [Sat Jan 20 19:21:26 2018] if you want something with both automation and some user-control of specs in Coq, maybe Chlipala’s Bedrock is interesting? [Sat Jan 20 19:21:59 2018] Iris right now IIUC is focusing on support for manual proof for sophisticated invariants [Sat Jan 20 19:23:35 2018] well, ultimately I have multiple long-term goals [Sat Jan 20 19:24:08 2018] one is to verify (and fix as needed) existing C code [Sat Jan 20 19:24:57 2018] one is to be able to write new things that are fully verified and involve state and concurrency [Sat Jan 20 19:26:39 2018] and one is to deal with annoyances in existing toolsets, because that's how you get better ones. [Sat Jan 20 19:27:49 2018] or something like that. [Sat Jan 20 19:28:31 2018] at the moment, "work" is grad studenting which leaves little time for other projects, and the currently funded project isn't about verification at all. [Sat Jan 20 19:28:39 2018] so none of this is actually progressing much. [Sat Jan 20 19:32:32 2018] and the reason I'm in the office on saturday night is to work on that project, not to talk about verification :-/ [Sat Jan 20 21:15:58 2018] oh, something somewhat related, though definitely offtopic here: do you know if anyone has an existing program database or AST storage thingy that can be made to hold abstract syntax for something the size of a whole kernel? (so, millions of lines) [Sat Jan 20 23:17:08 2018] dh_work: seems like they’d have to compare with “CodeQuest: Scalable Source Code Queries with Datalog”, and looking through the citing articles also finds e.g. http://people.inf.elte.hu/kiss/14kor/oopsla13.pdf [Sat Jan 20 23:23:34 2018] thanks! [Sat Jan 20 23:23:46 2018] the last time I went looking for program database stuff I couldn't find much useful [Sat Jan 20 23:24:14 2018] I doubt anything with datalog is actually useful for storage, however scalable the query processing might be ;-) [Sat Jan 20 23:24:39 2018] but still, a couple seeds for searching vastly outperforms 0 [Sat Jan 20 23:28:53 2018] Michael Eichberg from Darmstadt Univ. confirmed Datalog and Prolog are pretty slow and they went to engineer their own things (and he’s also a systems guy), but I can’t find relevant work from him (though he might have better pointers) [Sun Jan 21 00:13:30 2018] there's a guy in our department who's done a chunk of work on making datalog faster [Sun Jan 21 03:28:18 2018] I've never had the impression datalog was much of a data *storage* engine though [Sun Jan 21 07:02:49 2018] dh`: I don’t really get datalog, but where do you put the facts? [Sun Jan 21 07:03:42 2018] if the facts are in memory you’re right, and I’m not quite sure [Sun Jan 21 07:04:41 2018] but the CodeQuest alternative using graphs seems to use Neo4j which I hear called “a graph database”, so I suppose that does do storage 😃 [Sun Jan 21 11:30:40 2018] yeah, me either. [Sun Jan 21 11:31:04 2018] neo4j is in fact a graph database, but it's terribly slow (and it's in java, which makes it a pain to either run or integrate with) [Sun Jan 21 11:42:45 2018] since high-level program representations are basically trees with occasional crosslinks rather than hard-core graphs, a graph database as such isn't entirely necessary... not that there are very many good tree databases. [Sun Jan 21 11:43:06 2018] one could probably misuse XML stores for it though. [Sun Jan 21 11:52:04 2018] the goal is basically to have something persistent that one can write multiple independent analysis passes against. and load code into incrementally... [Sun Jan 21 11:56:29 2018] and the immediate purpose is to detect and mitigate spectre gadgets in the kernel. [Sun Jan 21 12:54:39 2018] but do you need whole program analysis for Spectre? if not, I'd avoid the storage. Also, have you looked at existing analysis tools for the Linux kernel? coccinelle, sparse, etc.... [Sun Jan 21 12:59:21 2018] none of those store ASTs I think, maybe because parsing is slow enough to warrant it... storing annotated ASTs would be different of course [Sun Jan 21 13:00:17 2018] regarding tree/hierarchical databases: isn't that another name for OO dbs or key-value stores? [Sun Jan 21 13:03:15 2018] the problem is that it's nonlocal; you can make it modular, but you really need to crawl over the whole program, at which point storing the lot so you can update incrementally is worthwhile [Sun Jan 21 13:03:24 2018] (plus the long-term goal is to add other checks) [Sun Jan 21 13:03:43 2018] and re tree databases, sort of. [Sun Jan 21 13:06:35 2018] you can build a tree database with a key/value store (same as you can build a relational database) [Sun Jan 21 13:10:04 2018] When I destruct an inductive term, say T x1 x2 x3, and if this T is used in a match [Sun Jan 21 13:10:18 2018] why do I not get some equivalence between the old T x1 x2 x3 and the subterms of it [Sun Jan 21 13:14:10 2018] bollu: you can, with ` eqn:H` on destruct [Sun Jan 21 13:14:28 2018] look up the manual for the exact syntax though [Sun Jan 21 13:34:31 2018] pgiarrusso: neat! I wish the manual had exmples, I can't read the manual properly [Sun Jan 21 13:34:36 2018] because I'm still a noob :( [Sun Jan 21 13:50:10 2018] bollu: I don't like the manual, but I'm on the phone... I hope somebody else here can help you further, or maybe try out the syntax for a bit [Sun Jan 21 13:50:57 2018] I just forget if `destruct foo eqn:bar` is enough or some other word is needed in the middle [Sun Jan 21 14:07:12 2018] No I think thats all you have to do [Mon Jan 22 10:53:52 2018] I've run into Ltac silliness: [Mon Jan 22 10:54:18 2018] Ltac foo := refine (let bar := _ in _); clearbody bar. [Mon Jan 22 10:54:39 2018] results in "The variable bar was not found in the current environment" [Mon Jan 22 10:55:12 2018] that's becuase Ltac scope checker does not realize that after call to refine (....) "bar" will be in scope [Mon Jan 22 12:54:59 2018] pgiarrusso: hi [Mon Jan 22 13:04:18 2018] johnw: hi! another op already took care of my question :-) [Mon Jan 22 13:04:30 2018] ok, great [Mon Jan 22 13:05:55 2018] jstolarek: Ltac tries to guess whether `bar` is Ltac or Coq, but IIRC you can *override* the detection with `constr:bar` or `(bar)` something like that (the manual suggests `(bar)`) [Mon Jan 22 13:07:15 2018] jstolarek: hm, both `constr: bar` and `ltac: bar` exist and are IIRC relevant [Mon Jan 22 13:08:40 2018] so http://adam.chlipala.net/cpdt/html/Cpdt.Match.html recommends `constr:` in similar cases [Mon Jan 22 13:09:29 2018] yeah, it has to be constr:(bar) since 8.6 [Mon Jan 22 13:12:48 2018] jstolarek: ^^. also, comparing with CPDT, it seems the scope checker might be looking for `bar` in the Ltac environment. IIUC (from the design docs of Ltac 2) the heuristics in Ltac (that is, Ltac 1) are pretty fragile [Mon Jan 22 13:55:55 2018] probably you ought to make a fresh name anyway, and then it becomes an ltac var [Mon Jan 22 15:13:14 2018] good point ^^ [Tue Jan 23 11:24:57 2018] Does anyone here know whether the initial results about CiC (that all of its computational content lives in Fomega) translate to more modern dependent type systems as used in Coq and Agda (with things like inductive families)? [Tue Jan 23 12:43:11 2018] SharpGAF: sorry, but do you have a citation for the original result? I only know about CoC, which has no inductive families [Tue Jan 23 12:43:22 2018] pgiarrusso: http://repository.cmu.edu/cgi/viewcontent.cgi?article=2907&context=compsci [Tue Jan 23 12:43:37 2018] I think the full result is in Christine Paulin-Mohring's original paper [Tue Jan 23 12:43:50 2018] There are some restrictions on it that I don't fully understand [Tue Jan 23 12:43:57 2018] (I'm not sure if they correspond to positivity restrictions) [Tue Jan 23 12:47:00 2018] Thanks [Tue Jan 23 12:47:41 2018] I’m not sure how different inductive families are; I know [Tue Jan 23 12:47:46 2018] Sorry [Tue Jan 23 12:49:47 2018] SharpGAF: hm, are you asking if we can extract CiC? Not quite though, because they want to extract and preserve termination [Tue Jan 23 12:50:11 2018] So you’re looking for *typed* realizability of Coq... [Tue Jan 23 12:50:33 2018] The current extraction of CiC to ML loses types sometimes, sure… [Tue Jan 23 12:51:41 2018] I guess I'm wondering how minimal the trusted kernel can be, in some sense [Tue Jan 23 12:51:59 2018] I’d look at Haskell maybe, ML is much smaller than Fomega (modulo encodings) [Tue Jan 23 12:52:05 2018] Right, exactly [Tue Jan 23 12:52:11 2018] Hm... extraction to Haskell might he [Tue Jan 23 12:52:11 2018] *help [Tue Jan 23 12:52:26 2018] I think Haskell is also smaller, but more to the point I'm not sure how much work has been done on the extraction to Haskell vs. OCaml. [Tue Jan 23 12:52:42 2018] Core ML is much smaller than fomega (modulo encodings in the module system) [Tue Jan 23 12:52:59 2018] I'm not really looking to extract to either, to be clear (both are much too large to be considered trustworthy compared to Coq, even though Coq's kernel isn't the smallest ever). [Tue Jan 23 12:53:14 2018] I am more curious what parts are hard to translate [Tue Jan 23 12:53:27 2018] And whether the earlier result (translation to Fw) even applies today [Tue Jan 23 12:56:33 2018] Yeah, just trying to figure out what’s possible... thinking aloud here [Tue Jan 23 13:01:54 2018] I'm still a bit confused about what was actually proved in the initial paper… it seems like they can compute with their representations [Tue Jan 23 13:02:23 2018] So does that mean that termination of CiC terms (in 1989 anyway) is automatic by translation to Fw? [Tue Jan 23 13:03:25 2018] It's certainly not the case that termination of normalization in Coq today is obviously true… [Tue Jan 23 13:25:55 2018] that normalization proof makes indeed sense, though I haven't checked what 1989 did [Tue Jan 23 13:26:40 2018] It makes sense from CoC. From CiC, though, I know it's considered much harder. [Tue Jan 23 13:27:31 2018] I think the most recent proofs about consistency of CiC (e.g. by translation into ZFC + transfinite cardinals) do not imply strong normalization. [Tue Jan 23 17:04:02 2018] if you want to extract to something more obviously sound than ocaml you'll probably have to write most of it yourself :-/ [Tue Jan 23 17:08:24 2018] * throws shade on haskell by implying it's less sound than ocaml :-) [Tue Jan 23 17:08:53 2018] extracting to C-- might be interesting [Tue Jan 23 17:10:03 2018] Well, the advantage of extracting to something like Fomega (which I'm skeptical about at the moment) is that you can probably mechanize the proof that a Coq implementation is total [Tue Jan 23 17:10:43 2018] So then instead of trusting the extractor for arbitrary programs you'd just have to trust it for that one program, and then your kernel could do all its reduction in the extracted version of Fw (or whatever) [Wed Jan 24 00:01:25 2018] SharpGAF: consistency of CIC should require strong normalization: non terminating proofs are inconsistent [Wed Jan 24 00:06:48 2018] pgiarrusso: AFAIK the models that come closest to current Coq (like https://arxiv.org/pdf/1710.03912.pdf) do not imply SN… also, Coq itself is not SN on all terms (at least, not if you consider cbv a legal reduction strategy) [Wed Jan 24 00:06:54 2018] Though that last part is sort of a bug I think. [Wed Jan 24 00:07:09 2018] o.o [Wed Jan 24 00:07:51 2018] benzrf: Dumb stuff around guard conditions, I think it's mentioned in a few papers [Wed Jan 24 00:08:28 2018] benzrf: https://coq.inria.fr/files/adt-2fev10-barras.pdf [Wed Jan 24 08:08:18 2018] in coq why cant i use certain axioms as a hint, e.g. Axiom M : ∀p w, □p w → p w. Hint Resolve M says "Error: M cannot be used as a hint." [Wed Jan 24 09:40:18 2018] pgiarrusso: no [Wed Jan 24 09:42:52 2018] WN is enough [Wed Jan 24 10:47:39 2018] darktenaibre SharpGAF: more accurately, SN clearly implies consistency... while WN also works because it’s enough to have *one* way to normalize the proof? [Wed Jan 24 10:48:12 2018] that sounds fine, I had just never looked at a system where the difference matters [Wed Jan 24 10:49:17 2018] WN is enough if you also have Subject Reduction [Wed Jan 24 10:49:32 2018] (which Coq does not have either in some specific cases) [Wed Jan 24 10:50:05 2018] beaky: you might need a `Hint Extern`. I suspect that’s because (IIUC) `Resolve` wants `p` to be a constant, so the hint is only used for goals with that constant in head position [Wed Jan 24 10:50:14 2018] ah [Wed Jan 24 10:50:43 2018] also, do you want the hint to be used only when Box p is already around? Or unconditionally? [Wed Jan 24 10:51:03 2018] in the latter case the hint applies to every goal, which *might* slow down proof search [Wed Jan 24 10:51:11 2018] (or not if there’s no way to prove Box p) [Wed Jan 24 10:51:40 2018] beaky: but I’m not sure, I have vague recollections from discussions of hints in CPDT and/or SF (1st/2nd volume) [Wed Jan 24 10:52:11 2018] Cypi: but do you need Subject Reduction or just soundness? You only need the final value to have the right type, no? [Wed Jan 24 10:52:15 2018] yes i think ill go digging through those [Wed Jan 24 10:52:37 2018] beaky: specifically, they have chapters on proof search/automation you want to look at [Wed Jan 24 10:52:57 2018] see on Hint Resolve/Hint Extern [Wed Jan 24 10:55:27 2018] Cypi: I’ve heard subject reduction is lost with coinductive types, and IIRC the reason is semi-boring (and maybe doesn’t affect soundness) [Wed Jan 24 16:45:55 2018] how should you handle dependencies on external libraries: ship with the specific version of the library (assuming licenses are in order)? ad-hoc enforcement in a makefile or readme? [Wed Jan 24 16:58:54 2018] Use opam [Wed Jan 24 17:38:16 2018] minn: declare what you need in the build docs and let the person building it (or the packaging system) handle it [Wed Jan 24 17:38:34 2018] never ship copies of things with your code unless there's some really good reason [Wed Jan 24 17:38:52 2018] it causes you and everyone else trouble when that package gets updated. [Wed Jan 24 17:38:57 2018] especially if it gets updated for security bugs [Wed Jan 24 17:41:12 2018] that makes sense and is probably the best option in the absence of a package manager if opam is unavailable [Wed Jan 24 17:43:27 2018] also remember that if your thing gets used much it'll potentially get added to debian and other downstream packaging systems [Wed Jan 24 17:43:45 2018] don't do anything to make that hard :-) [Thu Jan 25 04:34:35 2018] Hello, channel! Is there a way to search for a lemma without requiring corresponding library? The Search command needs Require. [Thu Jan 25 05:18:52 2018] don't think so (besides the manual) [Thu Jan 25 05:45:01 2018] What would be the way to find right library? I googled for something called max_le_iff, online doc tells me it is in Coq.Structures.GenericMinMax library, MinMaxLogicalProperties module. But after requiring the library I still cannot use this MinMaxLogicalProperties.max_le_iff. On the other hand, I see how people use it like this: PeanoNat.Nat.max_le_iff. So how am I supposed to find this way of using max_le_iff? [Thu Jan 25 07:35:12 2018] ulysses: I used Locate [Thu Jan 25 07:50:34 2018] ulysses: MinMaxLogicalProperties is a functor, what we need to use is an instantiation of it. Since we are using it at type nat, look under the Init or Arith library. Loading Arith is sufficient to use Locate here. [Thu Jan 25 07:51:42 2018] ulysses: PeanoNat.Nat includes an instanciation of UsualMinMaxLogicalProperties which includes MinMaxLogicalProperties [Thu Jan 25 09:09:28 2018] lyxia: thanks a lot! now it is clear [Thu Jan 25 11:33:50 2018] Locate still doesn't find things that haven't been loaded into the session though, right? [Thu Jan 25 11:42:52 2018] Right [Thu Jan 25 11:43:19 2018] https://coq.inria.fr/distrib/current/stdlib/Coq.Structures.GenericMinMax.html is GenericMinMax really a "library" though? [Thu Jan 25 12:09:43 2018] that's debatable, depends what you mean by a library :-/ [Fri Jan 26 02:24:22 2018] My friend, who is likely dealing with some impostor syndrome, doesn't have much experience with the language but has some projects they've worked on. Do you guys know if there are any good heuristics they can use to figure out whether their code is GitHub-ready or if anyone could discuss their code with them in the future? [Fri Jan 26 04:17:00 2018] ilzolende: describe the project appropriately and nobody should object to putting it on github. Advertising it is another matter. [Fri Jan 26 04:18:11 2018] Also, what’s good style in Coq proofs is under debate in these years [Fri Jan 26 04:18:26 2018] Is there an easy way to see what is taking coq so long when evaluating a `Compute` statement? [Fri Jan 26 04:58:59 2018] My suspicion is that it is somehow related to my use of `EqDec` because when evaluating the expression by hand (aka in an interactive proof environement by repeatedly applying `unfold` and `simpl`) there are a few places where I don't get any further because `simpl` can't figure out that `p ==b p` is true although `EqDec` rquires the used relation to be an equivalence relation. [Fri Jan 26 10:12:05 2018] I've just run into some nonsense in Coq [Fri Jan 26 10:12:09 2018] I have: [Fri Jan 26 10:13:01 2018] refine ((fun P => let foo := _ (* refine this with tactics *) in ....) X). [Fri Jan 26 10:13:17 2018] where P is a binder for a proof term [Fri Jan 26 10:13:42 2018] for some reason that P is not visible when proving _ [Fri Jan 26 10:13:57 2018] but if I inline call to foo and get rid of let binding then P is visible [Fri Jan 26 18:51:05 2018] jstolarek: wouldn’t be the first time some tactic doesn’t like let... I run into similar problems with Program. Not that I get it [Fri Jan 26 23:18:10 2018] ilzolende: the only real reason *not* to post something on github is if it's ambitious and grandiose and at the same time half-baked and clueless [Fri Jan 26 23:18:36 2018] like the guys who post their new custom kernel that doesn't actually have anything much besides a splashscreen [Fri Jan 26 23:19:22 2018] it is certainly possible to do similar kinds of things in coq, but it's not real likely, because coq is fairly hard [Fri Jan 26 23:24:27 2018] I don't habitually post things in public until they've reached a certain doneness level, because it's like promoting vaporware [Sat Jan 27 00:50:41 2018] ilzolende: by “describe appropriately” I meant in particular “doesn’t have much experience with the language”. In particular, publishing *claims* exposes you to a small risk that the claim does not reflect what you actually proved [Sat Jan 27 00:50:55 2018] At least if stating the correct definitions is hard [Sat Jan 27 00:51:07 2018] Or the correct theorem statements [Sat Jan 27 01:08:31 2018] my experience though is that usually when people think their stuff isn't good enough (as opposed to not done enough) it's because they underestimate their skill level [Sat Jan 27 01:17:08 2018] friend is a perfectionist and has trouble assessing both quality and doneness, is there a good place for them to find someone who'd be willing to look over their code? i looked around and i could find some *tutorials* but the reddit contains basically no active discussion and so i wasn't sure where to look besides here [Sat Jan 27 01:21:24 2018] here's probably a good place to look, but dunno how many people are going to have time available for substantive reviews [Sat Jan 27 01:22:49 2018] as in, it's one thing to look at a lemma that won't go, another to go through a whole development, especially if it's something itself nontrivial. [Sat Jan 27 02:59:44 2018] ilzolende: I understand your friend, I’m a perfectionist myself (and I think perfectionism must be endemic in channels like this) [Sat Jan 27 03:00:46 2018] so SoundLogic is the friend i've been mentioning :) [Sat Jan 27 03:01:07 2018] Hello apparently nice people [Sat Jan 27 03:01:11 2018] Ah, welcome SoundLogic! [Sat Jan 27 03:02:21 2018] Style-wise, CPDT claims nobody knows good practices (well, Chlipala claims what he does has some cool ideas) [Sat Jan 27 03:03:20 2018] I like dependently typed languages. Proved code is good. [Sat Jan 27 03:04:07 2018] SoundLogic: :-D [Sat Jan 27 03:04:55 2018] Thanks for calling us nice! Personally, I feel Coq is a harsh judge, so it forces some humility [Sat Jan 27 03:05:54 2018] And I hear formalizing informal proofs often teaches you others are fallible too, and that’s OK, we’re all humans after all :-) [Sat Jan 27 03:06:14 2018] It is logic. Logic isn't harsh, it is *immutable*. [Sat Jan 27 03:06:55 2018] * has strong views on this [Sat Jan 27 03:07:07 2018] Sure, “harsh” was more about Coq’s effects on the users, not a complaint :-) [Sat Jan 27 03:07:13 2018] As indicated by my name :P [Sat Jan 27 03:08:07 2018] Anyway, what sort of thing have you worked on, if I may ask? [Sat Jan 27 03:09:50 2018] A fair bit of "get frustrated at the standard library, start reimplementing/generalizing a chunk". I like setoids. Been working most recently on a puzzle game. [Sat Jan 27 03:11:27 2018] I keep putting off figuring out how to setup proof general and some nice libraries though which has kiiinda hampered me a fair bit >_< [Sat Jan 27 03:13:30 2018] Poked around at trying to add more stuff to morphism signatures, but haven't figured out a satisfactory way to represent it. Which, uh, is also a snag I hit a lot >_> [Sat Jan 27 03:15:51 2018] I think perfectionism must be endemic in channels like this <-- it is probably a prereq for using coq :-) [Sat Jan 27 03:16:51 2018] the standard library has... weaknesses [Sat Jan 27 03:16:56 2018] Given how often I wind up glaring at coq for being insufficiently formal and precise... [Sat Jan 27 03:17:52 2018] Yes I really need to figure out how to install proof general and mathclasses and such but it keeps being confusing for windows machines and I keep putting it off [Sat Jan 27 03:20:56 2018] ilzolende keeps mentioning an old laptop I should maybe use but ¯\_(ツ)_/¯ [Sat Jan 27 03:21:44 2018] proof general doesn't seem to offer all that much over coqide unless you're a fairly heavy emacs user [Sat Jan 27 03:22:16 2018] I have not got around to setting it up, even though I am a fairly heavy emacs user. [Sat Jan 27 03:22:29 2018] Huh [Sat Jan 27 03:24:24 2018] Mathclasses looks good though I think, unless I'm missing something? [Sat Jan 27 03:26:03 2018] HoTT's truncation levels and such also look nice, despite my objections to the underlying principles [Sat Jan 27 03:27:12 2018] “Coq insufficiently formal” sounds weird, at least about the kernel; error messages, reference manual, and so on are all fair game [Sat Jan 27 03:27:26 2018] dh`: it’s now finally on MELPA [Sat Jan 27 03:27:31 2018] the manual's way too formal in most places :-/ [Sat Jan 27 03:27:57 2018] dh`: the tactics chapter is too formal *and* informal [Sat Jan 27 03:28:02 2018] yes! [Sat Jan 27 03:28:17 2018] as I might have mentioned, the description of the semantics is... well... [Sat Jan 27 03:28:19 2018] I should volunteer to rewrite the manual... if only I had time for that :( [Sat Jan 27 03:28:22 2018] a clusterfuck? [Sat Jan 27 03:28:40 2018] “rewrite the manual” is the sort of hybris that prevents completion [Sat Jan 27 03:29:18 2018] I hear they’re porting it to sphinx, so hopefully when they’re done they might accept contributions [Sat Jan 27 03:29:18 2018] I am rather unusual. I don't believe in referential transparency *or* side effects. My objections to HoTT are on the same grounds. [Sat Jan 27 03:30:09 2018] SoundLogic: I’ve stopped talking about “beliefs” in formal theories [Sat Jan 27 03:30:34 2018] yes, ultrafinitism exists, they have arguments, I don’t mind [Sat Jan 27 03:30:34 2018] pgiarrusso: well [Sat Jan 27 03:30:48 2018] when a document kind of wants major restructuring, what else would you call it? [Sat Jan 27 03:30:58 2018] "heavy editing"? [Sat Jan 27 03:31:24 2018] dh`: not objecting to the term [Sat Jan 27 03:31:30 2018] note also that I don't expect anyone to take this proposition seriously without evidence that I can write, which I don't think anyone here has [Sat Jan 27 03:31:33 2018] pgiarrusso: ultrafinitism ftw. And I mean it very literally. I don't think (non-extremely trivial) referential transparency or side effects as commonly viewed exist. [Sat Jan 27 03:32:13 2018] dh`: but since nobody’s paying you full-time for a couple years to rewrite the manual, we’ll have to settle for local patches to the most glaring issues or nothing [Sat Jan 27 03:32:47 2018] *also*, it’s somewhat unrealistic to outsource rewriting a manual to outsiders [Sat Jan 27 03:33:05 2018] not because *I* don’t take you seriously [Sat Jan 27 03:33:15 2018] well [Sat Jan 27 03:33:15 2018] but because I’m sure the authors have their own opinions [Sat Jan 27 03:33:24 2018] if one actually does it, one perforce ceases to be an outsider [Sat Jan 27 03:33:27 2018] but yeah [Sat Jan 27 03:33:31 2018] also, that manual is a *reference* manual [Sat Jan 27 03:33:40 2018] anyway, it isn't realistic [Sat Jan 27 03:34:12 2018] well, it's partly a reference manual, one of the things it needs is to have the parts that are user guide to be separated out. [Sat Jan 27 03:34:18 2018] (or that are trying to be user guide) [Sat Jan 27 03:34:25 2018] also not saying that you *should* do the local refactoring instead of the rewrite (I’d encourage you to) [Sat Jan 27 03:34:30 2018] dh`: fair point! [Sat Jan 27 03:34:36 2018] on the user guide vs reference [Sat Jan 27 03:35:00 2018] that is in fact the main reorganization that I think's needed [Sat Jan 27 03:35:35 2018] the other one is to systematize the ... formalism density somehow [Sat Jan 27 03:35:50 2018] Agree. If I tried (which I likely won’t), I’d start doing it chapter per-chapter using sections [Sat Jan 27 03:36:00 2018] “intro to tacticals” — “tacticals formalized” [Sat Jan 27 03:36:05 2018] I mean, I’ve only written papers [Sat Jan 27 03:36:08 2018] right now there are sections of the manual where you're going along fine and suddenly you need to be a logician to follow [Sat Jan 27 03:36:31 2018] but there’s a very successful style of papers which we know how to write [Sat Jan 27 03:36:42 2018] yes [Sat Jan 27 03:36:51 2018] Does anyone here know of a good tutorial for setting up coq libraries and the build stuff on windows? It seems rather confusing. [Sat Jan 27 03:36:51 2018] unfortunately, manuals are different from those [Sat Jan 27 03:36:53 2018] (for some definition of “we”, and it’s still hard to do, but we’ve tons of examples) [Sat Jan 27 03:37:08 2018] the haskell docs have the same kinds of problems (for the same set of reasons, I expect) [Sat Jan 27 03:37:28 2018] soundlogic: I don't. my first advice, unfortunately, would be "don't use windows" [Sat Jan 27 03:37:40 2018] which probably isn't at all helpful. [Sat Jan 27 03:37:40 2018] SoundLogic: “referential transparency does not exist” can’t possibly be a proposition; there’s lots to criticize about it, but none of the criticisms I know have that summary [Sat Jan 27 03:38:14 2018] SoundLogic: I also don’t know; I’ve seen people use opam for libraries, but not on Windows [Sat Jan 27 03:38:21 2018] maybe there’s some tutorial on opam for Windows? [Sat Jan 27 03:38:42 2018] SoundLogic: any chance of using a Linux virtual machine with a GUI? [Sat Jan 27 03:38:54 2018] and then opening a terminal and following tutorials? [Sat Jan 27 03:39:27 2018] I’m not sure what to refer you to, I think Real World OCaml’s tutorial might be one of your best chances to set up opam [Sat Jan 27 03:39:40 2018] well, actually, you don’t need that much, sorry [Sat Jan 27 03:40:28 2018] SoundLogic: anyway, using Linux will require you at least *some* knowledge about Linux shells (sh/bash) [Sat Jan 27 03:43:01 2018] I've done a couple of large manuals. it's not the same as writing papers; the goals are different [Sat Jan 27 03:43:22 2018] pgiarrusso: I hold rather extreme views. To speak less soundbiteish, the fact that you can swap (1+5) and 6 as "referentially transparent" is in my opinion design flaw. True leibniz equality is trivial beyond the point of usefulness. (1+5) and 6 are equivalent in certain setoids, but not all. [Sat Jan 27 03:44:32 2018] anyway I'm not sure I can help much with the manual *without* proposing a mass rewrite; it's difficult for me to work on details without a global plan. [Sat Jan 27 03:45:29 2018] something like I need to know where I'm going [Sat Jan 27 03:48:40 2018] or something like I have to account for where all the bits are expected to go before I can propose local changes that will be helpful [Sat Jan 27 03:49:15 2018] anyway, the last thing I need is more projects; i should stick to the string library. [Sat Jan 27 03:49:35 2018] So, I should probably setup a thing with linux then since it sounds like coq and windows do not mix well? [Sat Jan 27 03:54:08 2018] SoundLogic: on 1+5 vs 6, I see the confusion. But there's a difference between the number resulting from 1+5 (which is 6) and the syntax for 1+5, which is an AST [Sat Jan 27 03:55:11 2018] so I'd say it's not that you hold extreme views, it's that you'd like to read a book that clarifies the distinction, which is indeed usually only made in proof theory and programming language [Sat Jan 27 03:55:56 2018] pgiarrusso: There is a setoid they are equivilent on, and functions like successor, addition, subtraction, and so on respect that setoid. Functions like "get_memory_address" and "get_time_to_compute" don't. [Sat Jan 27 03:56:00 2018] proofs and types has an aside on that, but that book sometimes almost assumes you already know everything relevant and then adds a bit of insight [Sat Jan 27 03:56:37 2018] I wasn't refering to the AST [Sat Jan 27 03:56:48 2018] but you are [Sat Jan 27 03:57:14 2018] "get_memory_address" is not a thing about the AST [Sat Jan 27 03:57:32 2018] if you are computing, that's on a program [Sat Jan 27 03:57:53 2018] well, the 6 of a mathematician does not have a memory address [Sat Jan 27 03:58:30 2018] you should really check out TAPL to learn the standard language for what you have in mind [Sat Jan 27 03:58:42 2018] Benjamin Pierce's TAPL [Sat Jan 27 03:59:05 2018] The six natural number of a mathematician is implicitly parameterized by a zero and a successor for the signature. [Sat Jan 27 03:59:19 2018] you'll learn that all that you're saying is extremely well known in PL under the right terms [Sat Jan 27 03:59:35 2018] that's not the 6 of a mathematician, it's something else [Sat Jan 27 04:01:16 2018] something else? [Sat Jan 27 04:01:20 2018] the 6 of a usual mathematician is a certain thing in ZFC [Sat Jan 27 04:01:30 2018] *type theorist [Sat Jan 27 04:01:32 2018] the 6 of a type theory is something else [Sat Jan 27 04:01:32 2018] *type theorist [Sat Jan 27 04:01:32 2018] and it's what you define in Coq [Sat Jan 27 04:02:02 2018] anyway, gotta check in at an airport [Sat Jan 27 04:02:14 2018] but the core message stands [Sat Jan 27 04:02:35 2018] reading that book will improve and validate a corrected version of your beliefs [Sat Jan 27 04:02:57 2018] you can still formalize things differently, but I doubt you'll see the point [Sat Jan 27 04:04:02 2018] TAPL is a good text [Sat Jan 27 04:04:10 2018] Harper's PFPL is also good and has (or used to have) free drafts online [Sat Jan 27 04:04:38 2018] * goes and looks [Sat Jan 27 04:05:00 2018] relevant concepts: the distinction between object and meta-language, formalizing object languages with syntax, semantics [Sat Jan 27 04:05:24 2018] you'll need a semantics with a heap to define get_memory_address [Sat Jan 27 04:08:00 2018] (a simple set-theoretic denotational semantics might also help drive home the distinction between numbers in the object and meta-language) [Sat Jan 27 04:19:21 2018] pgiarrusso: my instinctive approch would be to say that the fact that the existance of stopwatches implies apartness and therefore inequality [Sat Jan 27 04:22:25 2018] anyway, once you talk about the programs 1+5 and 6, you can totally discuss whether one takes more execution time than the other or not (it typically does) [Sat Jan 27 04:23:13 2018] and whether 6 and 6 have the same memory address (which you can't even state, let alone answer, without writing down the actual semantics of the programming language) [Sat Jan 27 04:30:06 2018] The fact that you can't state it doesn't seem very relevant? In coq you can't pattern match over types or functions so you can't construct False by assuming univalence or function extensionality, but that doesn't make them the same, it just means that coq doesn't enable the construction of functions which don't respect certain setoids. [Sat Jan 27 04:31:52 2018] It is like the thing with private types for HITs. [Sat Jan 27 04:35:09 2018] SoundLogic: what I'm saying is that, once you fix a semantics, that becomes a precise statement you can prove or disprove [Sat Jan 27 04:35:27 2018] and I can fix different semantics that give a different results [Sat Jan 27 04:35:32 2018] *result [Sat Jan 27 04:36:11 2018] yes...? [Sat Jan 27 04:36:16 2018] if I use memoization, for instance, all copies of the value 6 will share the same address [Sat Jan 27 04:37:06 2018] Yes [Sat Jan 27 04:38:40 2018] viceversa, concepts that aren't formalized (at least in a sketch) aren't yet really math [Sat Jan 27 04:42:48 2018] I am completely in favor of being able to abstract out over things. "All the functions here respect the following" is really helpful, and I wish coq supported it more generally than just its "equivalent up to the following reduction laws". But working primarily within a certain collection of setoids doesn't make other functions stop existing, and I don't expect you to use any semantics that manage to make stopwatches stop [Sat Jan 27 04:42:48 2018] existing either. [Sat Jan 27 04:47:41 2018] pgiarrusso: This is a good book [Sat Jan 27 04:51:07 2018] SoundLogic: I must say, in constructive mathematics it makes more sense to talk about the “computation” inside 5 + 1 [Sat Jan 27 04:51:13 2018] in classical mathematics it doesn’t [Sat Jan 27 04:51:39 2018] but formalizing a language inside Coq lets you say most or all that you want to say [Sat Jan 27 04:51:53 2018] actually, TAPL’s good for doing the math on-paper [Sat Jan 27 04:52:20 2018] and Software Foundations (especially vol. 2) is good for the next step (doing it in Coq, though they cover MUCH less) [Sat Jan 27 04:52:50 2018] Formalizing a language inside C would also let me say things. None the less, there is a reason I prefer coq. [Sat Jan 27 04:54:37 2018] anyway, do check it out, I think you’ll like it [Sat Jan 27 04:54:47 2018] Flight’s leaving, so bye! [Sat Jan 27 04:55:20 2018] I'm reading it [Sat Jan 27 04:55:21 2018] Bye! [Sat Jan 27 06:53:16 2018] is there a way to change the automatic names that Coq generates using intros? if I do Goal bool -> bool. intros. for example, I get H : bool. if I want b : bool instead I can do intros b., but can I not use some command to force Coq to use "b" as its initial choice using intros. alone? I've tried the guide and SO and found nothing, though Idris can do this [Sat Jan 27 07:06:54 2018] sbp: the closest thing I know is the string argument of fresh [Sat Jan 27 07:07:07 2018] so you could write your own wrappers [Sat Jan 27 07:07:56 2018] maybe use Chargueraud's (IIRC) introv for inspiration (in e.g. Software Foundations) [Sat Jan 27 07:09:06 2018] sbp: but wait [Sat Jan 27 07:09:29 2018] in your example Goal: forall (b: bool), bool would work [Sat Jan 27 07:10:03 2018] or you could just name your function argument as usual [Sat Jan 27 07:10:20 2018] not sure which one you want [Sat Jan 27 07:19:46 2018] pgiarrusso: I knew about fresh, but I didn't know about introv. that's pretty interesting, but the idea is to have "upstream" decide your variable names for you. that's why I didn't use (b: bool) in the type, because it's pretty much just the same as using intros b [Sat Jan 27 07:20:12 2018] the idea is, imagine you're exporting some datatype as a library for others to use [Sat Jan 27 07:21:04 2018] you want them to be able to intros on your datatype without ending up with H H0 H1. they can use explicit names, but it's like unnecessary duplication of effort when you can have the author just do it once, at the point of Inductive creation, for all time [Sat Jan 27 07:21:28 2018] so I guess that's some motivation for me to tinker with Coq's source. adding this might be an interesting OCaml project ;) [Sat Jan 27 07:25:02 2018] what inspired me was the %name construct in Idris. example here: https://github.com/idris-lang/Idris-dev/blob/24f580d45455b3fee35d0e96e48415612e58aaed/libs/prelude/Prelude/List.idr#L30 [Sat Jan 27 07:31:54 2018] the annoying thing is in Coq, unlike Idris, adding such an hint will break clients [Sat Jan 27 07:32:54 2018] it'd be cooler to mix interactive editing and tactics [Sat Jan 27 09:44:57 2018] I'm trying to pass tactics as arguments, and can pass idtac, but not (idtac "hello"). using the Ltac EBNF from the manual, I've gotten this far: https://paste.rs/vrO, not sure what to try next/what the error means [Sat Jan 27 10:09:52 2018] disregard the above, solved the issue by grepping for examples in the coq source 'twice ltac:(idtac "hello")' works where 'twice (ltac:(idtac "hello"))' was failing [Sat Jan 27 11:42:21 2018] newbie question: i have installed coq using opam. When i do c-c c-enter on proof general, i get "coq process exited". How do i fix this? [Sat Jan 27 12:32:28 2018] because of the way we think about bools, it's rare in practice (IME anyway) to get H: bool [Sun Jan 28 10:27:56 2018] Is it true that coq has a small kernel? Is its codebase modular? How feasible would it be for me to separate the core language and make my own little IDE for coq? With my own syntax and editor, using just the core from coq and its type checker, nothing more? [Sun Jan 28 10:30:16 2018] srpx: Depends how you define "small," but fortunately the kernel in Coq is already (somewhat) isolated from the rest of the code. [Sun Jan 28 10:37:40 2018] srpx: https://github.com/coq/coq/tree/master/kernel is the kernel. The rest (outside of some shared library code) is theoretically optional. However, I think there are documented plugin APIs somewhere that people are supposed to be able to rely on being more stable than kernel internals. https://github.com/coq/coq/wiki/DevelopmentTutorial has a much better overview than I can give (I've mostly worked in the checker, which is kind of [Sun Jan 28 10:39:02 2018] Which is kind of? (Your message was cut) [Sun Jan 28 10:39:15 2018] SharpGAF . [Sun Jan 28 10:40:11 2018] kind of isolated from the rest of the code by design. [Sun Jan 28 10:40:42 2018] The checker is probably not what you want, since it both isn't interactive, and is very slow (though hopefully that can be fixed to some extent). [Sun Jan 28 10:48:59 2018] Hmmm. So that won’t work, I guess [Sun Jan 28 10:49:15 2018] Type checker is slow because of unification or something? [Sun Jan 28 10:54:26 2018] SharpGAF so, I’m trying to implement a browser for apps which instead of JavaScript, uses a language on which the browser can download proofs of certain properties of the apps it runs. For example, “for all sequence of use inputs, this game will never violate the zero sum of balances”. Problem is I’m not sure what language to use for that. Every language that has a type system powerful enough for that is a huge [Sun Jan 28 10:54:26 2018] project that I can’t just ship with a browser. I tried implementing my own core language but without inductive families it isn’t expressive enough in practice, and those are hard to implement. I’d use coqs core but you just said its checker is slow. Out of ideas [Sun Jan 28 11:06:22 2018] wait, why is Coq’s kernel slow? It’s used to check all proofs, no? [Sun Jan 28 11:07:38 2018] IIUC, Coq users use tactics to build proofs, and then they’re checked by the kernel [Sun Jan 28 11:08:00 2018] or does Coq use some faster checker during interactive use? [Sun Jan 28 11:09:39 2018] "fast enough to check one proof interactively" might still be "too slow to be worth gating page loads on checking an entire library of proofs" (I'm guessing motivations, don't know the exact runtimes involved) [Sun Jan 28 11:19:20 2018] srpx: Sorry, I realize that would be easy to read that way… the kernel is pretty fast (given what it's doing). The checker is a (sort of) separate implementation of the typechecker, so its slowness shouldn't affect you unless you want to use it. [Sun Jan 28 11:19:49 2018] Oh okay! Thanks for that clarification. [Sun Jan 28 11:20:26 2018] I definitely recommend using the Coq kernel over writing your own checker, unless you want that to be the research project :) [Sun Jan 28 11:21:45 2018] It is worth noting that Coq can actually run in the browser even for quite large developments (though that might not matter for what you're doing). [Sun Jan 28 11:36:03 2018] I’m aware, with coq.js, right? I’m more and more tending towards what you suggested, yes. I could use coqsSo, you’d say it is feasible to build a different surface language on top of coqs core? (I probably don’t need the tactics, most of the unification and more complex features, and I need an editor that understands the whole grammar) [Sun Jan 28 11:36:23 2018] I could use coqs core as a lib and build the browser in ocaml. * [Sun Jan 28 11:37:38 2018] (SharpGAF) [Sun Jan 28 11:45:27 2018] It's certainly *possible.* After all, most people interact with Coq primarily through Ltac, which isn't part of the kernel at all. [Sun Jan 28 11:46:03 2018] It would be a huge amount of work, but that would be the case whether or not you use Coq as the kernel. [Sun Jan 28 12:23:35 2018] I'm trying to prove "Goal forall b c : bool, andb b c = true -> b = true /\ c = true.", and am ending up with "true = false" as a subgoal; does that mean I'm trying to prove a nontheorem, or just applying the wrong tactics? [Sun Jan 28 12:24:19 2018] aweinstock: wrong tactics [Sun Jan 28 12:25:14 2018] aweinstock: unless you took a modified `andb`, but if it’s called and the theorem is true [Sun Jan 28 12:25:44 2018] I’ve gotten such things by using `destruct b` over `destruct b eqn:Hb`; the former can lose information [Sun Jan 28 12:25:53 2018] actually, wait [Sun Jan 28 12:26:02 2018] `destruct b` won’t lose anything [Sun Jan 28 12:26:06 2018] but `destruct t` will [Sun Jan 28 12:26:15 2018] standard andb from the standard library, was trying 'intros; destruct b,c,H; compute.' [Sun Jan 28 12:26:33 2018] ah, `destruct H` sounds like a problem [Sun Jan 28 12:27:04 2018] `destruct b, c; simpl; split; reflexivity` might be enough [Sun Jan 28 12:27:39 2018] aweinstock: ^^ [Sun Jan 28 12:28:33 2018] aweinstock: since `H`’s type is an indexed datatype, `destruct H` loses information, while `inversion H` or `dependent destruction H` are more appropriate [Sun Jan 28 12:28:52 2018] ah, my proposed tactics won’t work [Sun Jan 28 12:30:11 2018] because in 3 out of four cases `H` reduces to `false = true`; but adding `inversion H` should fix that [Sun Jan 28 12:30:33 2018] `destruct b, c; simpl; inversion H; split; reflexivity` [Sun Jan 28 12:31:19 2018] that works, thanks [Sun Jan 28 12:31:31 2018] what's the intuition behind how inversion differs from destruct? [Sun Jan 28 12:35:06 2018] aweinstock: inversion deduces equalities, destruct just eliminates [Sun Jan 28 12:35:31 2018] do you know the difference between indices and parameters for types? [Sun Jan 28 12:37:11 2018] I don't think I know the difference, is there a paper/section of the Coq manual that explains it? [Sun Jan 28 12:39:36 2018] aweinstock: Essentially, indices are "outputs" and parameters are "inputs". While every constructor in the inductive type takes the same parameter types and outputs the same index types, for indices the constructor gets to decide their values based on both parameters and constructor arguments. [Sun Jan 28 12:41:07 2018] aweinstock: to be more precise - when you make a declaration like [Inductive foo (t : Type) (a : nat) : forall (s : Type), list s -> Prop] [Sun Jan 28 12:41:33 2018] formally, coq understands everything before the : as a 'parameter' and everything afterward as an 'index' [Sun Jan 28 12:41:41 2018] that is, t and a are parameters, s and the list are indices [Sun Jan 28 12:41:45 2018] Oh right, yes, syntax :) [Sun Jan 28 12:42:26 2018] the 't' and 'a' are bound in the body of the declaration, and the result type of each constructor _must_ use them as its t and a [Sun Jan 28 12:43:03 2018] so for example, somehting like [bar : foo t 3 nat nil] would be invalid, because you used '3' instead of 'a' [Sun Jan 28 12:43:36 2018] on the other hand, 's' won't be bound in the declaration (that wouldnt make sense anyway since s is scoped to the body of the forall) [Sun Jan 28 12:43:56 2018] and in particular it can be determined however you like [Sun Jan 28 12:44:16 2018] if you've used haskell, all basic algebraic data type declarations have only parameters, no indices [Sun Jan 28 12:46:22 2018] I've used more haskell than dependently typed languages, so I probably just don't have intuition for indices yet then [Sun Jan 28 12:46:26 2018] yh [Sun Jan 28 12:46:38 2018] basically, indices are precisely what GADTs allow you to do that ADTs don' [Sun Jan 28 12:46:40 2018] t [Sun Jan 28 12:47:24 2018] the key thing about parameters is that, essentially, the type declaration is *parametric* over them [Sun Jan 28 12:47:51 2018] when you apply [Sun Jan 28 12:47:53 2018] er [Sun Jan 28 12:48:28 2018] if you have the types [foo t a s l] and [foo t b s l], the only difference between them is that 'a' gets swapped out for 'b' [Sun Jan 28 12:48:33 2018] in the types of each constructor [Sun Jan 28 12:50:04 2018] on the other hand, consider a type like this: [Inductive nice : nat -> Prop := three_is_nice : nice 3 | four_is_nice : nice 4] [Sun Jan 28 12:51:02 2018] since the 'nat' argument to the type constructor appears on the rhs of the :, it's an index, and we are free to determine it as we like in the types of our constructors [Sun Jan 28 12:51:20 2018] now [nice] is not 'parametric' in its first argument [Sun Jan 28 12:51:51 2018] [nice 2] and [nice 3] have /different sets of constructors/ [Sun Jan 28 12:53:49 2018] now when you [destruct] something, it creates subgoals for each constructor of the type (iirc) [Sun Jan 28 12:54:29 2018] and it clobbers some stuff and uh i dont remember the details [Sun Jan 28 12:55:04 2018] when you use [inversion], it examines what values you've given for the indices of the type, and intelligently figures out what constraints that causes [Sun Jan 28 12:56:11 2018] tangential thing that's worth knowing: when coq generates an induction principle, it puts the parameters of the type as arguments at the very beginning that then get used throughout the rest, whereas it puts the indices as arguments to each inductive case and the conclusion [Sun Jan 28 13:01:30 2018] e.g. https://i.imgur.com/RRrV34F.png [Sun Jan 28 13:01:39 2018] oops fuck [Sun Jan 28 13:02:07 2018] there we go https://i.imgur.com/pH6BXmh.png [Sun Jan 28 13:03:16 2018] oh yeah, and parameters are automatically added as arguments to the types of the constructors, but you cant match on them as subpatterns, or something? [Sun Jan 28 13:03:21 2018] i cant remember the detail [Sun Jan 28 13:03:34 2018] it gets a bit subtle [Sun Jan 28 13:03:55 2018] but if you examine some stdlib types like eq and le, youll find that theyve carefully chosen their arguments to be parameters or indices [Sun Jan 28 13:04:05 2018] in that example, is 'A' the parameter, and 'identity A' the index? [Sun Jan 28 13:04:10 2018] no - [Sun Jan 28 13:04:25 2018] the first type uses a parameter, the second type uses an inde [Sun Jan 28 13:04:27 2018] x [Sun Jan 28 13:05:25 2018] ack i forgot how hard to see coq's arrow highlighting is on this theme [Sun Jan 28 13:05:25 2018] so the "A" in "identity A" is a parameter, and the "A" in "identity' A" is an index [Sun Jan 28 13:05:37 2018] right [Sun Jan 28 13:05:50 2018] notice the differences in the generated induction principles too [Sun Jan 28 13:06:33 2018] also check this out https://i.imgur.com/0C3bh35.png [Sun Jan 28 13:06:41 2018] is this {the same thing as, related to} existentials in haskell-style GADTs? [Sun Jan 28 13:06:54 2018] somewhat [Sun Jan 28 13:06:58 2018] oh wait hmm [Sun Jan 28 13:07:08 2018] no i'd say it isn't [Sun Jan 28 13:07:22 2018] existentials in haskell are precisely when the arguments to the constructor *don't* show up in its result type [Sun Jan 28 13:07:37 2018] but this distinction is entirely regarding those result types and where they come from [Sun Jan 28 13:08:01 2018] for example: [Sun Jan 28 13:08:19 2018] this is totally fine: Inductive identity (A : Type) : Type := wrap : forall T, T -> identity A. [Sun Jan 28 13:08:41 2018] i have an existential type here and coq doesn't care - the important thing is just that i be parametric over A, it doesnt matter what else i do [Sun Jan 28 13:09:07 2018] the A can't come from a forall there because it has to come from the A bound above, but if i have other parameters that i use elsewhere, it doesnt matter [Sun Jan 28 13:09:58 2018] AFAIK, indices can either be thought of as a generalization of dependent sigma, or as a type level reification of the language's equality judgement together with dependent sigma. [Sun Jan 28 13:11:13 2018] SharpGAF: I think understanding that is a final exam question on inductive types :-) [Sun Jan 28 13:11:29 2018] though I think it sounds correct [Sun Jan 28 13:13:21 2018] to clarify, a constructor like `three_is_nice: nice 3` can be translated into `three_is_nice: forall n, n = 3 -> nice n` [Sun Jan 28 13:13:43 2018] so we see `n = 3` (which reifies equality) [Sun Jan 28 13:14:54 2018] a dependent sigma because we pack the `n = 3` witness (and we could pack more stuff if we had existentials) [Sun Jan 28 13:15:14 2018] it is often annoying that you can't use existentials there :-/ [Sun Jan 28 13:15:15 2018] aweinstock: that translation I showed is how Haskell GADTs (used to be) explained in the literature [Sun Jan 28 13:15:37 2018] dh`: isn’t it enough to bind more variables? [Sun Jan 28 13:15:54 2018] not always, no [Sun Jan 28 13:16:00 2018] `evens_are_nice: forall m, nice (2 * m)` [Sun Jan 28 13:16:17 2018] I don't have an example [Sun Jan 28 13:16:24 2018] every time I run into it, I end up having to rewrite :-) [Sun Jan 28 13:16:45 2018] which usually involves restructuring, not just introducing more stuff [Sun Jan 28 13:18:04 2018] dh`: maybe, but no clue what could be an example [Sun Jan 28 13:18:29 2018] I will try to remember to dump here the next time I run into this [Sun Jan 28 13:18:30 2018] except that you can’t bind variables that are too big for the target type [Sun Jan 28 13:18:42 2018] but that’s fixed by making the target larger [Sun Jan 28 13:18:52 2018] or, well, in Coq you don’t write universe levels really [Sun Jan 28 13:19:29 2018] so worst-case you produce unsatisfiable constraints and get trouble... [Sun Jan 28 13:20:03 2018] dh`: right, this is the *one thing* existentials can do and Coq can’t [Sun Jan 28 13:20:06 2018] suppose I wanted to have a prop SAT: expr -> Prop [Sun Jan 28 13:20:17 2018] weak existentials can be more impredicative [Sun Jan 28 13:21:19 2018] a natural way to write the constructor is as "isSAT: forall e, exists (a: assignment), Eval a e true -> SAT e [Sun Jan 28 13:21:43 2018] you can write something similar with forall, but it's a weaker property. [Sun Jan 28 13:23:03 2018] or at lest, i think it is. [Sun Jan 28 13:23:10 2018] I might have botched any piece of this ;-) [Sun Jan 28 13:25:06 2018] hm [Sun Jan 28 13:25:36 2018] OK, I think `isSAT: forall e a, Eval a e true -> SAT e` should be what you want [Sun Jan 28 13:25:45 2018] because that’s the type of isSAT [Sun Jan 28 13:25:56 2018] yes, that's at least legal [Sun Jan 28 13:26:32 2018] and it’s equivalent (at least in System F) to `isSAT: forall e, (exists a, Eval a e true) -> SAT e` [Sun Jan 28 13:26:55 2018] now, why would the latter not work? [Sun Jan 28 13:27:13 2018] with the right version of existentials [Sun Jan 28 13:27:24 2018] in what sense of not work? [Sun Jan 28 13:27:32 2018] well, be illegal [Sun Jan 28 13:27:39 2018] oh [Sun Jan 28 13:27:58 2018] or what is the problem with this, since it is what you want to write? [Sun Jan 28 13:28:05 2018] is that allowed in an inductive? [Sun Jan 28 13:28:11 2018] (I added parens and those matter) [Sun Jan 28 13:28:25 2018] right [Sun Jan 28 13:28:26 2018] I *am* wondering about size issues [Sun Jan 28 13:28:36 2018] but this one lives in `Prop` [Sun Jan 28 13:30:05 2018] one case which will fail is trying to store a `Type i` into a `Type i` with universe errors [Sun Jan 28 13:30:33 2018] and there you often need to replace the `Type i` you want to pack with some *code* for the `Type i` [Sun Jan 28 13:31:10 2018] or wait! [Sun Jan 28 13:31:33 2018] maybe `exists p: Prop, foo: Prop` is already illegal [Sun Jan 28 13:31:43 2018] that’s allowed in System F which has (weak) existentials [Sun Jan 28 13:32:03 2018] but it becomes inconsistent if you switch to sigma types/strong existentials [Sun Jan 28 13:32:17 2018] I think even for impredicative universes [Sun Jan 28 13:33:03 2018] But... now I’m confused [Sun Jan 28 13:33:15 2018] (also, I meant `(exists p: Prop, foo): Prop`) [Sun Jan 28 13:35:04 2018] it accepts the existential inside the parens, and it seems correct to have the parents [Sun Jan 28 13:35:14 2018] so maybe the solution to the problems I've run into is that [Sun Jan 28 13:36:41 2018] dh`: for this example, yes [Sun Jan 28 13:36:54 2018] I see why one might want `exists` to be closer to `forall` syntax [Sun Jan 28 13:37:02 2018] well, sort-of see [Sun Jan 28 13:37:17 2018] (except that would in fact be wrong) [Sun Jan 28 13:37:18 2018] also now I'm not sure (in this case) what the difference in meaning is when you remove the parens [Sun Jan 28 13:37:50 2018] it would allow the existential variable to appear in the SAT conclusion and that's obviously problematic, but it doesn't [Sun Jan 28 13:37:52 2018] well, the body of exists extends to the right as much as possible, just like forall [Sun Jan 28 13:38:00 2018] right [Sun Jan 28 13:38:09 2018] but that’s just not the right syntax [Sun Jan 28 13:41:23 2018] well yes, but the *statement* forall e, exists a, Eval a e true -> SAT e [Sun Jan 28 13:41:37 2018] that’s fine [Sun Jan 28 13:41:44 2018] can be written, and now I'm not sure how this is actually a different statement [Sun Jan 28 13:41:50 2018] which is probably because I'm being stupid [Sun Jan 28 13:41:59 2018] this is subtle [Sun Jan 28 13:42:30 2018] OK, so that statement can be written, yes, and it might even be true, for extra confusion [Sun Jan 28 13:42:58 2018] ah no [Sun Jan 28 13:43:19 2018] dh`: I hope `False` is an false Expression, yes? [Sun Jan 28 13:43:49 2018] well, not quite Coq’s `False`, call it `EFalse` [Sun Jan 28 13:44:30 2018] that statement says that for all expressions (including `EFalse`), there exists a specific assignment, such that if the assignment is true `e` is satisfiable [Sun Jan 28 13:44:47 2018] OK, so now I suspect this is a true but stupid statement [Sun Jan 28 13:45:21 2018] let’s prove it to explain it. Assume you have a SAT solver that decides whether `e` is satisfiable. [Sun Jan 28 13:46:11 2018] if `e` is unsatisfiable, for any assignment `a` the conclusion will be vacuously true (because `Eval a e true` is false) [Sun Jan 28 13:46:30 2018] if `e` is satisfied by `a`, pick assignment `a` as witness of the existential [Sun Jan 28 13:46:34 2018] in both cases, we’re done [Sun Jan 28 13:46:40 2018] so the statement holds [Sun Jan 28 13:46:50 2018] but is it interesting? I’d say no [Sun Jan 28 13:47:26 2018] `forall e, (exists a, Eval a true) -> SAT e`, instead, lets us show that `e` is satisfiable by providing a satisfying assignment [Sun Jan 28 13:47:27 2018] yes, well, both statements say that in english, is the problem. I'm writing it down to tinker with [Sun Jan 28 13:47:32 2018] that’s much more interesting [Sun Jan 28 13:47:51 2018] if both statements say that in English, you’re mistranslating them [Sun Jan 28 13:48:16 2018] but this is indeed pretty confusing [Sun Jan 28 13:48:38 2018] I am probably being stupid. [Sun Jan 28 13:48:42 2018] my head is boiled this weekend [Sat Feb 3 15:41:55 2018] Is there a way to anonymously refer to the term built via an ltac script? [Sat Feb 3 15:43:13 2018] concretely: I want to be able to instantiate a record field with something like {| SRmul_1_l := inline_ltac (intros; simpl; rewrite plus_rightzero; reflexivity.) |} [Sat Feb 3 15:43:48 2018] Wherever a Gallina term is expected, you can write `ltac:(some tactic)` [Sat Feb 3 15:43:57 2018] where `some tactic` is a Ltac tactic that solves the goal [Sat Feb 3 15:44:06 2018] right now, the best I can do is construct a proof term interactively via "Goal forall x, 1 * x = x. intros. simpl. rewrite plus_rightzero. reflexivity. Qed. Print Unnamed_thm" and inline it [Sat Feb 3 15:45:26 2018] trying it with ltac:(...) now [Sat Feb 3 15:51:50 2018] after "Definition foo : forall x, 1 * x = x := ltac:(intro x; simpl; rewrite plus_rightzero; reflexivity).", "{| SRmul_1_l := foo |}" works, but "{| SR_mul_1_l := ltac:(intro x; simpl; rewrite plus_rightzero; reflexivity) |}" fails with "Error: Found no subterm matching "?M707 + 0" in the current goal." [Sat Feb 3 15:52:23 2018] the span info for the "Error: Found no subterm matching "?M707 + 0" in the current goal." message points at the "rewrite plus_rightzero" term [Sat Feb 3 15:53:51 2018] adding "Set Ltac Debug." before the record definition didn't get it to dump more info [Sat Feb 3 15:57:15 2018] aweinstock: that means that in the term you are building you can’t rewrite with that lemma, there’s no instance of ??? + 0 [Sat Feb 3 15:57:43 2018] why do you expect the type of `SR_mul_1_l` to need such a rewrite? [Sat Feb 3 15:58:10 2018] aweinstock: in fact, it’s surprising it works inside `foo`, that makes no sense [Sat Feb 3 15:59:07 2018] I got it to work with "{| SRmul_1_l := fun x : nat => (fun (e : 1 * x = x) => e) ltac:(simpl; rewrite plus_rightzero; reflexivity); |}" [Sat Feb 3 15:59:25 2018] (basically just adding explicit binders to get the types unified correctly) [Sat Feb 3 16:00:17 2018] pgiarrusso: I'm trying to instantiate Ring_theory.semi_ring_theory for nat, and I want (forall x : nat, 1*x = x) inlined since it's such a trivial lemma [Sat Feb 3 16:01:49 2018] my guess as to why it didn't work before adding the binders but did afterwards was that it was trying to infer a type that referred to the semiring's parameters, but wasn't unifying them properly [Sat Feb 3 16:02:27 2018] is that a thing that makes sense to expect? (i.e. did I luck into a working solution, or did I get it for close to the right reason?) [Sat Feb 3 16:02:45 2018] aweinstock: wait, so `plus_rightzero` is here a lemma referred to multiplication? that was confusing [Sat Feb 3 16:03:24 2018] also, a lemma on a right *identiy* should say `x * 1 = x`, not talk about `1 * x` [Sat Feb 3 16:04:15 2018] pgiarrusso: (plus_rightzero : forall n, n + 0 = n) [Sat Feb 3 16:04:38 2018] aweinstock: so why is that relevant to `foo`’s type? no + in sight [Sat Feb 3 16:05:17 2018] aweinstock: to your question, I suspect plus_rightzero is overloaded over either canonical structures or typeclass instances, and resolution might be picking different instances... but the type you show suggests no overloading [Sat Feb 3 16:05:33 2018] it comes up after simpl does 1 step of reduction (from (1 * x = x) to (x + 0 = x)) [Sat Feb 3 16:05:54 2018] * is the Nat.mul from the standard library, defined by left-recursion on nats [Sat Feb 3 16:05:54 2018] Ah! Thanks. [Sat Feb 3 16:06:56 2018] aweinstock: OK... [Sat Feb 3 16:07:15 2018] maybe SR_mul_1_l is overloaded? [Sat Feb 3 16:07:36 2018] I confirmed that "SRmul_1_l := fun x : nat => ltac:(simpl; rewrite plus_rightzero; reflexivity)" fails where "SRmul_1_l := fun x : nat => (fun e : 1 * x = x => e) ltac:(simpl; rewrite plus_rightzero; reflexivity)" suceeds [Sat Feb 3 16:07:55 2018] aweinstock: makes sense, but which overload is unspecified [Sat Feb 3 16:08:26 2018] I’d expect a type annotation for the overall instance? but you’re not pasting a full command for `SRmul_1_l` [Sat Feb 3 16:08:52 2018] "Check Ring_theory.SRmul_1_l." gives "SRmul_1_l : forall (R : Type) (rO rI : R) (radd rmul : R -> R -> R) (req : R -> R -> Prop), semi_ring_theory rO rI radd rmul req -> forall n : R, req (rmul rI n) n" [Sat Feb 3 16:09:38 2018] aweinstock: and semi_ring_theory is the typeclass/structure you’re building [Sat Feb 3 16:09:57 2018] aweinstock: it looks like you’re trying something like `Definition foo := {| SRmul_1_l := ... |}` [Sat Feb 3 16:10:19 2018] while you’d need `Definition foo: semi_ring_theory := {| ... |}` [Sat Feb 3 16:10:57 2018] in the first case, Coq can’t know which semiring theory you’re trying to build, so doesn’t know to use multiplication, so `simpl` can’t produce an addition [Sat Feb 3 16:11:09 2018] (or maybe Coq guesses a different instance) [Sat Feb 3 16:11:17 2018] aweinstock: makes sense? [Sat Feb 3 16:11:29 2018] that would explain why your type annotations work around the problem [Sat Feb 3 16:11:43 2018] https://github.com/aweinstock314/coq-stuff/blob/master/softwareverification_homework1.v#L112-L123 [Sat Feb 3 16:12:42 2018] I'm passing the arguments to semi_ring_theory before starting the record definition, so I don't think that explanation addresses it? [Sat Feb 3 16:16:42 2018] aweinstock: Thanks for the link! Stumped then. This still looks like a type inference issue, but this looks like Coq being sillier than I’d have expected? [Sat Feb 3 16:17:21 2018] except that I don’t know if typechecking is done before running `Ltac`, which might interact with the problem [Sat Feb 3 16:18:22 2018] aweinstock: but any chance using `Program Definition` makes your life simpler? [Sat Feb 3 16:18:31 2018] so it's probably just some sort of phase issue between ltac/typecheck that's easily worked around then [Sat Feb 3 16:18:58 2018] I'm not sure, haven't heard of the `Program Definition` feature before [Sat Feb 3 16:20:34 2018] (found it in the manual and am reading about it, but I'm not sure what you were suggesting I replace with it) [Sat Feb 3 16:27:30 2018] If I'm understanding correctly, `Program Fixpoint` allows manually writing termination for proofs of some algorithms that might not be writeable with `Fixpoint`, which is good to know about for another thing I'm working on [Sat Feb 3 16:28:06 2018] (poset lattice fixpoint iteration, as used in dataflow algorithms for compilers) [Sat Feb 3 17:04:17 2018] unrelated question (about recovering information after branching on it to get a bool): in https://paste.rs/iBC, how can I find out what function the 'if/then/else' in H expands to? `Print Scopes.` only gave me IF_then_else, which doesn't look like its type unifies [Sat Feb 3 17:06:24 2018] (i.e. `Check fun (A : Set) (f : dec_eq A) (x y : A) => IF_then_else (f x y).` fails to typecheck) [Sat Feb 3 17:09:25 2018] I tried `Unset Printing Notations.`, and it still shows up as `H : eq (if f x y then true else false) true` [Sat Feb 3 17:12:24 2018] aweinstock: `Program Definition` is similar to `refine` and lets you fill in proofs in definitions more conveniently ... just write `_` and get a goal [Sat Feb 3 17:12:29 2018] instead of writing `ltac:(...)` [Sat Feb 3 17:13:53 2018] aweinstock: `if...then...else` is probably a primitive and has special behavior [Sat Feb 3 17:14:06 2018] the condition can have any type with two constructors [Sat Feb 3 17:14:14 2018] (IIRC) [Sat Feb 3 17:14:16 2018] w.r.t. the dec_eq question, I found it in figure 1.1, and the behaviour in 2.2.2 (coq manual) [Sat Feb 3 17:14:19 2018] no way to achieve that with a usual function [Sat Feb 3 17:15:13 2018] the https://paste.rs/iBC thing is a minimal repro of an issue I ran into in a larger proof for the poset_lattice project (antisymmetry for a free-lattice construct) [Sat Feb 3 17:17:43 2018] uh, `destruct f x y` should let you finish that proof [Sat Feb 3 17:18:01 2018] (if you wonder about that) [Sat Feb 3 17:18:31 2018] (aside: w.r.t. etiquette, should I be more explicit about numbering questions if I'm asking multiple unrelated questions asynchronously?) [Sat Feb 3 17:19:37 2018] gotta leave (for now?), see you, hope the above helps! [Sat Feb 3 17:20:46 2018] 'destruct f; [exact e | discriminate H]' solves the dec_eq thing, thanks! [Sat Feb 3 18:47:34 2018] aweinstock: uh, I meant `destruct (f x y)` :-|... amazed that `destruct f` works! [Sun Feb 4 18:40:16 2018] Does anybody know how to go about defining the order of a group? I have a definition of a group that only provides the 3 usual axioms [Sun Feb 4 18:42:29 2018] a bijection to Fin? [Sun Feb 4 21:04:31 2018] what kind of thing is your group? [Sun Feb 4 21:05:49 2018] because the size of the group should follow from the set it's a structuring of [Mon Feb 5 04:02:15 2018] hmm [Mon Feb 5 04:02:22 2018] I think I may have outsmarted myself [Mon Feb 5 04:02:37 2018] is there a clever way to fuse fold_right (fold_left ...) [or vice vera]? [Mon Feb 5 04:18:14 2018] seems so. hmm [Mon Feb 5 06:02:05 2018] Hello, I am a computer science student in my first year of studies. Yesterday I discovered Coq. I am reading this book on Geometric Algebra and I thought Coq might help me learn it if I tried to build up the theory in Coq. How feasible is this, and, are there any Coq libraries for Linear Algebra? [Mon Feb 5 07:18:02 2018] dh`: can you write fold_left as a fold_right? (Recommend googling the solution, there is one). That might be a (slow) way. Not sure if any fusion can do much better [Mon Feb 5 07:19:17 2018] fold_right id (fun x xs, (cons x) . xs) xs [Mon Feb 5 07:20:13 2018] Limeth: the mathematical components project has some algebra, so maybe linear algebra [Mon Feb 5 07:21:44 2018] Limeth: but most likely your project is too hard for now, you’d need lots of experience with both subjects to do your own formalization [Mon Feb 5 07:22:34 2018] Limeth: if you have significant time, you can start following a good Coq book (say, Software Foundations) [Mon Feb 5 07:32:05 2018] I've actually already started with the Software Foundations guide. My main goal is to create a geometric algebra library for Rust, but I thought trying to formalize parts of GA could be useful. But I might be getting ahead of myself. [Mon Feb 5 07:51:12 2018] statistically, you are — it’s a good thought, it’ll just take a while [Mon Feb 5 07:51:15 2018] Limeth: for me, the exercise on the pigeonhole principle was appropriately humbling — I’ve used it millions of times but I gave up formalizing its proof when I first worked through SF [Mon Feb 5 07:51:58 2018] http://math-comp.github.io/math-comp/ [Mon Feb 5 07:52:17 2018] Limeth: that’s the mathematical components homepage ^^ [Mon Feb 5 07:56:09 2018] Thanks for the link [Mon Feb 5 13:15:14 2018] pgiarrusso: by chaining lambdas or by reverse? neither seems very useful for fusion :-/ [Mon Feb 5 13:21:17 2018] dh`: yeah I realize... not sure if any of the papers on fusion handle left folds better [Mon Feb 5 13:24:29 2018] I was hoping to avoid having to dig in deeply :-) [Mon Feb 5 13:25:39 2018] I have a stack of string ops as folds now, with equivalence lemmas, but some of them are left folds and some right [Mon Feb 5 13:26:38 2018] also when scoping this I forgot about the way haskell laziness affects foldr [Mon Feb 5 13:27:39 2018] (as in, extracting to foldr is sometimes desirable for haskell, but virtually never for ocaml) [Mon Feb 5 13:34:26 2018] Hi, I'm sorry, stupid question. [Mon Feb 5 13:34:39 2018] I'm in the middle of an interactive proof, can I save a term for later? [Mon Feb 5 13:34:47 2018] Not _admit_, mind you. [Mon Feb 5 13:34:56 2018] It's just an f(x) where x is in the hypotesis. [Mon Feb 5 13:35:10 2018] I think that's what shelve is for, but I'm not sure how to use it [Mon Feb 5 13:35:50 2018] `shelve` will put the current goal on the shelf. You can then `Unshelve.` to get all the shelved goals back into focus [Mon Feb 5 13:36:11 2018] (there is probably a way to unshelve only one specific goal, maybe with `Focus`, I'm not sure) [Mon Feb 5 13:38:46 2018] thanks, but I don't want the current goal [Mon Feb 5 13:38:51 2018] let me rephrase [Mon Feb 5 13:39:03 2018] I have x:A, y:B, x:C in the hypotesis [Mon Feb 5 13:39:07 2018] my goal is foo [Mon Feb 5 13:39:20 2018] I can eval and print an f(x) [Mon Feb 5 13:39:27 2018] I'd like to store that, i.e. [Mon Feb 5 13:39:43 2018] Add an hypotesis w = f(x) : whatever [Mon Feb 5 13:39:43 2018] `pose proof (f(x))` ? [Mon Feb 5 13:39:52 2018] for later use [Mon Feb 5 13:40:07 2018] or `set (f(x))` depending if you want it opaque or transparent [Mon Feb 5 13:40:09 2018] "remember (f x) as w"? [Mon Feb 5 13:40:36 2018] Ah [Mon Feb 5 13:40:39 2018] fantastic [Mon Feb 5 13:40:41 2018] thank you all! [Mon Feb 5 17:22:40 2018] dh`: I tried to mention the laziness issue — even `find_first p xs` works as a fold_right only with laziness [Mon Feb 5 17:23:01 2018] maybe you want to use a CBN fold even in OCaml? [Mon Feb 5 17:23:14 2018] well [Mon Feb 5 17:23:20 2018] you don’t need laziness, thunks are enough [Mon Feb 5 17:23:21 2018] I'm mostly using the folds as proof tools [Mon Feb 5 17:23:59 2018] “mostly” [Mon Feb 5 17:24:19 2018] do these efficiency issues affect proof tools for some fancy reason? [Mon Feb 5 17:24:31 2018] so it doesn't matter if e.g. the one for find_first is inefficient [Mon Feb 5 17:25:01 2018] ah, you said *extracting* to foldr [Mon Feb 5 17:25:15 2018] right, for haskell [Mon Feb 5 17:25:41 2018] where fold versions exist, they can be dropped in for extraction if it seems desirable [Mon Feb 5 17:26:45 2018] I had two categories of fold versions, one that makes reasonably sensible ocaml output from fold_left, and one that doesn't. [Mon Feb 5 17:27:00 2018] but because of the haskell fold_right thing, there need to be three. [Mon Feb 5 17:27:22 2018] oh dear [Mon Feb 5 17:28:11 2018] so for example the fold version of case-insensitive string compare does not generate sensible output, no matter how you slice it. [Mon Feb 5 17:28:35 2018] because at least for the time being fold2 requires strings that are the same length, so it has to test the length of the strings up front [Mon Feb 5 17:29:23 2018] and that means two iterations over both strings instead of one. [Mon Feb 5 17:29:49 2018] but some of the other ones are fine except for being fold_right, which is almost never desirable in ocaml [Mon Feb 5 17:29:58 2018] and those are also just tagged "inefficient" [Mon Feb 5 17:43:54 2018] (this is not a big deal, it just means going through the whole mess again and rearranging the naming) [Mon Feb 5 21:53:39 2018] I was hoping someone could help me set up Proof General in Spacemacs. I installed Proof General, added two lines to my init.el file, and coq files open in the PG mode. I also added coq to my spacemacs layers, but then I'm getting a fail for that layer when I try to execute the configuration file. Does anyone know what the issue is? [Mon Feb 5 23:45:26 2018] michbad: the coq layer includes proof general, you don’t need both; but also, that layer requires the develop branch of spacemacs (last I saw) [Mon Feb 5 23:47:32 2018] pgiarrusso: I managed to get it to kind of work by changing the proof general path in a couple places. Weirdly, I get some of the keybindings described in the documentation, but not all of them. I might play around with it a little more, maybe the develop branch will help. [Mon Feb 5 23:49:29 2018] michbad: sounds like you installed proof general by hand? It’s on melpa now [Mon Feb 5 23:49:51 2018] I suspect you might want to save your changes and just add the coq layer [Mon Feb 5 23:50:42 2018] But I should paste my working .spacemacs for this [Mon Feb 5 23:51:01 2018] (Not now, but feel free to ping me) [Mon Feb 5 23:53:03 2018] pgiarrusso: I think I have the coq layer now: if I do `SPC m` or `,`, then I can execute a bunch of the commands. Thanks, I'll experiment and see what I can come up with. [Tue Feb 6 00:22:27 2018] michbad: if ESC autocompletes there’s a workaround! [Tue Feb 6 00:27:35 2018] pgiarrusso: Actually it does, what is it? [Tue Feb 6 00:29:13 2018] nevermind, i found it [Tue Feb 6 00:29:23 2018] https://github.com/syl20bnr/spacemacs/issues/8853#issuecomment-302706114 [Tue Feb 6 00:29:28 2018] Ah [Tue Feb 6 00:38:40 2018] pgiarrusso: Got it to work. Thanks for your help, I feel like I finally get some grasp of how to use it. :) [Tue Feb 6 10:27:18 2018] https://www.irccloud.com/pastebin/dMa7fP74/ [Tue Feb 6 10:27:23 2018] I hav ethis Ltac [Tue Feb 6 10:28:04 2018] and it matches a hypothes stating `false = xy` [Tue Feb 6 10:28:41 2018] in th egoal there is a `if xy then ... else ...` buried inside other things (without binders) [Tue Feb 6 10:29:09 2018] so as `Debug Ltac` telld me th efirst branch matches [Tue Feb 6 10:29:14 2018] but the rewrite fails [Tue Feb 6 10:30:41 2018] Does this sound familiar to anyone? If I try to do that rewrite by hand it also fails telling me that xy is nowhere in the goal [Tue Feb 6 10:30:55 2018] What does it say when it fails? Also, for debugging purposes I would try two things. 1) Just print `f` (with `idtac f`), then do the rewrite manually and see if it fails and why. 2) Replace `rewrite H` by `pattern f; rewrite H; simpl`. [Tue Feb 6 10:31:30 2018] (The tactic `pattern f` will change the goal so that it has the shape `P f`, hopefully it will make things easier for `rewrite`) [Tue Feb 6 13:30:34 2018] Cypi: Thanks for your help. When doing the rewrite by hand it sais "Error: Found no subterm matching "pure_in p (b_conj a1 a2)" in the current goal." But it is in the goal... `pattern f; rewrite; simpl` did the trick. Any insight as to why this could be necessary? [Tue Feb 6 13:36:14 2018] is it in the goal under an exists? (or worse, a lambda?) [Tue Feb 6 13:36:42 2018] No no binders involved [Tue Feb 6 13:36:59 2018] Just about 60 lines of expanded computation [Tue Feb 6 13:38:33 2018] What is the easiest way to construct finite sets and apply operations like union and intersect in Coq? I've search a bit online, but I wasn't able to find any clear examples on how to do this. I found Coq.Sets.Ensembles, but I was not sure on how best to use it to construct finite sets. [Tue Feb 6 13:43:38 2018] what are you trying to do with your sets? [Tue Feb 6 13:43:53 2018] if you're trying to use them as collections, you want the msets piece of the library [Tue Feb 6 13:44:20 2018] if you're trying to do set theory, then probably coq.sets [Tue Feb 6 13:49:50 2018] I am just trying to use them as collections, though I may try some set theory stuff later. [Tue Feb 6 13:50:15 2018] I'll check those sections of the library. [Tue Feb 6 13:51:05 2018] Are there any quick examples them that you know of? [Tue Feb 6 13:52:52 2018] MSets looks like it will work for what I want to try. [Tue Feb 6 14:50:37 2018] dh`: MSets ended up working well. Thanks! [Tue Feb 6 16:08:59 2018] * bows [Tue Feb 6 16:09:11 2018] set theory sets and container sets are quite different things [Tue Feb 6 16:21:55 2018] Cypi: your trick with `pattern`solved a lot of cases however I now have a case where `pattern`does not replace the term by the newly indtroduced lambda variable. Any tips on debugging that? [Tue Feb 6 17:12:10 2018] mgttlinger: any dependent types involved? [Tue Feb 6 17:12:42 2018] sometimes it’s ill-typed to replace a term [Tue Feb 6 17:13:28 2018] for instance, assume you have a length-indexed type `Vec A n`, where `cons` gives you a `Vec A (S n)` [Tue Feb 6 17:14:28 2018] argh, bad example [Tue Feb 6 17:15:47 2018] better: assume a predicate `tailEven: Vec A (S n) -> Prop`, and assumptions `xs : Vec A (S n)` and `H : tailEven xs` [Tue Feb 6 17:16:28 2018] if `m = S n`, I think you can’t replace `S n` by `m` in `xs` type, because `tailEven xs` is ill-typed if `xs : Vec A m` [Tue Feb 6 17:16:34 2018] mgttlinger: ^^ [Tue Feb 6 17:17:12 2018] caveat: I reconstructed this example on the spot and I might miss something, but I remember I have seen similar things discussed [Tue Feb 6 17:17:58 2018] crucially, I expect this could work if `m` were defined in the context through `m := S n` [Tue Feb 6 17:18:15 2018] but not if the replacement used just `Heq : m = S n` [Tue Feb 6 17:43:57 2018] Is there any way to get Coq's evaluation machinery to compute, but have it not unfold / descend into a particular function `foo` or its arguments? [Tue Feb 6 17:45:26 2018] I wan't something that's (intuitively) something like `cbv - [foo]` (I know that syntax means something different, though) [Tue Feb 6 17:46:07 2018] I was about to suggest `cbv -[foo]` though [Tue Feb 6 17:46:16 2018] but it will still reduce the arguments of the function [Tue Feb 6 17:47:54 2018] "the arguments of a function" is something vaguely defined anyway. So you might have to to that more manually [Tue Feb 6 17:48:16 2018] (you could do stuff like `remember (foo a b c) as tmp` and then unfold back `tmp` in the goal [Tue Feb 6 17:48:19 2018] ) [Tue Feb 6 17:48:34 2018] Cypi: could anishathalye `pattern` the function call? [Tue Feb 6 17:49:30 2018] Probably? But then you still have `P (foo a b c)` as a goal, so you still need either to make this more opaque (using `remember` for instance), or to disable beta-reduction [Tue Feb 6 17:49:45 2018] hmm. Disabling beta-reduction is not enough, it will still reduce a, b and c [Tue Feb 6 17:51:08 2018] * should study pattern [Tue Feb 6 17:51:54 2018] Cypi: but what about `cbn` or `simpl` after excluding the function? Arguments won’t be reduced then [Tue Feb 6 17:52:20 2018] I mean, if `cbn -[foo]` works, it shouldn’t have a need to reduce `foo`’s argument [Tue Feb 6 17:52:24 2018] *arguments [Tue Feb 6 17:52:26 2018] right? [Tue Feb 6 17:53:19 2018] I don't understand what you mean [Tue Feb 6 17:53:30 2018] `cbn -[foo]` will always work, it is just a reduction tactic [Tue Feb 6 17:53:48 2018] It will perform full strong reduction, except that `foo` will be considered opaque and never replaced by its definition [Tue Feb 6 18:53:56 2018] Oops, `cbv -[foo]` was exactly what I wanted. For some reason, I was confused. Thanks for your help Cypi and pgiarrusso! [Tue Feb 6 18:54:40 2018] Cypi: I just didn’t know if `cbn -[foo]` was valid syntax, I just guessed it [Tue Feb 6 18:54:51 2018] thanks for clarifying it does [Wed Feb 7 02:40:44 2018] pgiarrusso: as far as I can see the only dependent types involved are the hypotheses in context which are depenent by their very nature but everything else is at most paramterised over `Set` ad the expression I'm trying to `pattern` `rewrite` is an expression evaluating to a `bool` [Wed Feb 7 02:41:52 2018] which occurs in an `if` which I want coq to resolve due to having proff in context that the thing evaluates to true (false) [Wed Feb 7 02:43:15 2018] and all binders involved in this expresion are in the `else` branch of said `if`so this can't cause it [Wed Feb 7 02:45:04 2018] No clue then, except if `Unset Notations` (or what was it?) shows there was a binder hidden in your goal [Wed Feb 7 02:46:48 2018] Unset Printing Notations, I believe. [Wed Feb 7 02:47:01 2018] or Set Printing All. [Wed Feb 7 02:47:07 2018] or Unset Printing Implicits. [Wed Feb 7 02:47:14 2018] err, Set [Wed Feb 7 02:48:10 2018] johnw: Ok, that hint was helpful [Wed Feb 7 02:48:29 2018] Now I see why they are different [Wed Feb 7 02:49:30 2018] well they are equal after beta reductuion however [Wed Feb 7 02:51:59 2018] Then the question arises: why do the implicit arguments in the goal get beta reduced but in the argument in my pattern they dont and therefore are considered unequal [Wed Feb 7 02:52:24 2018] what's your example? [Wed Feb 7 02:53:32 2018] I have a rather large term in the goal which has an if then else structure having a term evaluating to bool [Wed Feb 7 02:53:44 2018] and simpl doesn't simplify it? [Wed Feb 7 02:53:53 2018] I have proof in context that this term evaluates to false [Wed Feb 7 02:54:23 2018] rewrite with that proof sais that the term is not in context [Wed Feb 7 02:54:41 2018] ( now visibly due to this missing beta reduction of impicits) [Wed Feb 7 02:54:57 2018] but in some cases pattern and then rewrite solved it [Wed Feb 7 02:55:02 2018] somehow [Wed Feb 7 02:55:23 2018] it's hard to say without seeing what you're seeing [Wed Feb 7 02:55:56 2018] Yes but any smaller example I tried to come up with didn't show that behaviour [Wed Feb 7 02:56:37 2018] I'll have another go at it knowing now that this missing beta reduction is causing it [Wed Feb 7 02:56:43 2018] can you prove that these two beta-equivalent terms are equal with an auxiliary lemma, and then rewrite with that? [Wed Feb 7 02:59:05 2018] probably unfold would do it given that it really is just a definition which doesn't get unfolded [Wed Feb 7 02:59:10 2018] let me try that [Wed Feb 7 03:05:25 2018] Ok, unfolding and then `pattern`cause pattern to max my CPU for at least the last 50 seconds... [Wed Feb 7 03:05:55 2018] hah, 50 seconds [Wed Feb 7 03:05:55 2018] Is there a way to see what coq is doing there? [Wed Feb 7 03:06:05 2018] I mean it's stil running [Wed Feb 7 03:06:07 2018] are you on a Mac or Linux? [Wed Feb 7 03:06:12 2018] Linux [Wed Feb 7 03:06:27 2018] hmm.. I don't know how to do stochastic profiilng on Linux [Wed Feb 7 03:06:30 2018] but i mean pattern previously was somwhat instant [Wed Feb 7 03:08:33 2018] i'm just used to Coq being crazy slow at unexpected times, I don't know what it's doing [Wed Feb 7 03:08:59 2018] these 10 minutes to me a good sign it may not end before I run out of patience [Wed Feb 7 03:09:02 2018] these days* [Wed Feb 7 03:09:10 2018] I'm by now being used to coq just doung weird stuff when `Programm` and `Typeclass` are used... [Wed Feb 7 03:09:55 2018] It's still trying to pattern... [Wed Feb 7 03:10:19 2018] gonna killit now... [Wed Feb 7 03:10:27 2018] ah nevermind [Wed Feb 7 03:10:35 2018] proces ran out of memory and killed itself [Wed Feb 7 03:11:13 2018] ah, a bug to be reported, if you can possibly shrink it! [Wed Feb 7 03:13:15 2018] The last time I thought coq taking forever to compute something it turned out that it triedto unfold my functions all the way [Wed Feb 7 03:13:26 2018] resulting in terms so large that the memory didn't suffice [Wed Feb 7 03:13:36 2018] which wasn't really a bug as such [Wed Feb 7 03:17:45 2018] Ok but at least now I have a clue as to why those rewrites didn't work in the first place [Wed Feb 7 03:18:00 2018] mgttlinger: maybe try to factor out pieces of the definition [Wed Feb 7 03:18:24 2018] doubly so if involved definitions are generated by `Program` [Wed Feb 7 03:19:08 2018] or by definitions that use `Program` and *pattern match* [Wed Feb 7 03:20:18 2018] Hmmmm yeah that function is ridiculous anyway... 35 lines of code generating 351 proof obligations [Wed Feb 7 03:21:03 2018] apart from 4 of those all can basicaly be proved by omega and congruence [Wed Feb 7 03:55:34 2018] I think I'm going insane with coq.... I have `is_true (f a1) \/ is_true (f a2)` in scope and I want to destruct that but coq tells me `Error: Case analysis on sort Type is not allowed for inductive definition [Wed Feb 7 03:55:34 2018] Logic.or.` [Wed Feb 7 03:56:04 2018] but `Logic.or` is `Prop -> Prop -> Prop` [Wed Feb 7 03:56:19 2018] and `is_true : bool -> Prop` [Wed Feb 7 04:02:32 2018] mgttlinger: your goal is in Type [Wed Feb 7 04:02:55 2018] Yes [Wed Feb 7 04:03:06 2018] and to build/prove something in Type (or Set), you cannot in general eliminate something in Prop [Wed Feb 7 04:03:30 2018] (basically, your computation cannot depend on the actual value of anything in Prop) [Wed Feb 7 04:03:45 2018] Ok [Wed Feb 7 04:04:03 2018] yeah that fixed it [Wed Feb 7 04:04:05 2018] Thanks [Wed Feb 7 04:21:52 2018] Can I force definitions to alwys e unfolded? [Wed Feb 7 04:22:16 2018] certain definitions that is [Wed Feb 7 04:22:30 2018] not all in general [Wed Feb 7 04:25:10 2018] maybe you want notations rather than new definitions? [Wed Feb 7 04:27:08 2018] cic: oh right that would work. [Wed Feb 7 04:27:25 2018] or maybe one could write a simple ltac line that's just a long rewrite and use that as a tactic later. that's not automatic, but maybe better than fully manual. [Wed Feb 7 04:28:19 2018] Well It's unfortunately not that simple [Wed Feb 7 04:28:35 2018] those definitions occur only in implicit arguments [Wed Feb 7 04:29:00 2018] and apparently only can be unfolded by my tactic if printin gof implicits is enabled [Wed Feb 7 04:36:21 2018] Printing should not change what can and cannot be unfolded [Wed Feb 7 04:36:26 2018] if it's the case, it's a bug [Wed Feb 7 04:37:21 2018] I just noticed if i put unfold commands into the obligation tactic and in an unsolved goal set implicit printing those are not unfolded [Wed Feb 7 04:37:36 2018] and if i set that before the whole thing they are unfolded in the unsolved goals [Wed Feb 7 04:38:11 2018] Unless I'm missing something to mee that seems like the printing changes the outcome [Wed Feb 7 04:38:28 2018] If you have a self-contained piece of code I can try and take a look at it [Wed Feb 7 04:38:45 2018] let me try to build something [Wed Feb 7 04:41:21 2018] Ok hat unfolding of those function was what was confusing rewrite before and needing a custom tactic from me to solve those `if`s [Wed Feb 7 04:42:11 2018] lesson learned: don't use definitions for type aliases [Wed Feb 7 04:53:43 2018] Cypi: I'm having trouble making a self contained example exhibiting the behaviour I'm experiencing... [Wed Feb 7 13:06:34 2018] I want to rename module N to M, but Module M := N duplicates instances in N... [Wed Feb 7 13:07:44 2018] So now instance resolution takes exponential time because it makes every choice twice [Wed Feb 7 13:08:03 2018] Is there some better way to rename modules? [Wed Feb 7 13:09:14 2018] If it helps, N is a module that I "Require Import"-ed. [Wed Feb 7 18:25:38 2018] lyxia: I’m thinking you should just import module N, not require it, and then require M (or maybe swap import and require in what I said) [Wed Feb 7 18:25:55 2018] *maybe*, just a guess [Wed Feb 7 18:26:25 2018] Which assumes you’re also Requiring M after the rename, otherwise I’m confused [Wed Feb 7 18:30:26 2018] Hm, unfortunately it seems even Require-ing the module pulls in its instances [Thu Feb 8 06:43:31 2018] Can I locally turn off warnings for overridden notations? [Thu Feb 8 06:44:37 2018] So I want those warnings turned off but only for one file [Thu Feb 8 06:45:31 2018] `Set Warnings "-notation-overridden".` [Thu Feb 8 06:47:39 2018] Ok, thanks that was easier than expected [Thu Feb 8 06:47:53 2018] :) [Thu Feb 8 06:49:34 2018] Ok but it doesn't do what I want. My description of the desired behaviour was wrong [Thu Feb 8 06:49:52 2018] I want no warnings for the notations defined in a single file. [Thu Feb 8 06:50:29 2018] With that flag set I get the warnings everywhere the file is imported [Thu Feb 8 06:56:55 2018] You can add turn this warning off before importing your file and then turn it on. [Thu Feb 8 06:57:13 2018] *s/add// [Thu Feb 8 06:58:28 2018] I import that file almost everywhere... [Thu Feb 8 06:59:41 2018] well I think I'm gonna live with those warnings then. Have done enough C++ to know how to ignore a bunch of warnings. [Thu Feb 8 06:59:44 2018] People usually just copy a set of commands across all the files of a project [Thu Feb 8 06:59:56 2018] It seems there is no better way as of now [Thu Feb 8 07:00:25 2018] I'd like to be proven wrong :) [Thu Feb 8 07:03:47 2018] Once I suggested a "horrendous hack" ;) in this (slightly) related coq-club thread: https://sympa.inria.fr/sympa/arc/coq-club/2017-02/msg00010.html [Thu Feb 8 12:53:10 2018] I want to rename module N to M, but Module M := N duplicates instances in N... [Thu Feb 8 12:53:25 2018] that seems like just a bug... [Thu Feb 8 12:59:06 2018] Would `Module M. Include N. End M.` work? [Thu Feb 8 13:19:00 2018] this makes me wonder about the interaction between instances and generative functors, though [Thu Feb 8 13:23:29 2018] I never did understand why haskell instances are unscopeable [Thu Feb 8 15:10:56 2018] Many Haskell libraries assume instances are unique [Thu Feb 8 16:33:48 2018] dh`: take two dictionaries based on two different orderings on the same type. You want them to have incompatible types so you don’t try to merge them together (because merging assumes they are both ordered the same way). SML uses generative functors, Haskell forbids having two different orderings on the same type. [Thu Feb 8 16:34:21 2018] dh`: but you can “copy” the type with `newtype` (which has no runtime overhead) and then give different instances [Thu Feb 8 16:35:02 2018] nothing bad happens if you define two different orderings on the same type within two separate scopes, though [Thu Feb 8 16:35:31 2018] there's no point where the two instances can intersect then. [Thu Feb 8 16:37:48 2018] (and outside both scopes it's not ordered at all) [Thu Feb 8 16:39:54 2018] Consider Data.Map, which are binary search trees. Operations expect an Ord instance, and if you don't use the same then things break. [Thu Feb 8 16:44:58 2018] hi [Thu Feb 8 16:45:14 2018] I want to prove False from (~P -> P) and (~P) [Thu Feb 8 16:46:30 2018] hackinghorn: what's the problem? [Thu Feb 8 16:47:08 2018] lyxia, how to prove it.. I tried "apply H1" where H1 is "~P -> P" but it doesnt work [Thu Feb 8 16:47:36 2018] it gives "Unable to unify "P" with "False"." [Thu Feb 8 16:48:25 2018] apply H expects the conclusion of H to match the goal. [Thu Feb 8 16:48:38 2018] Since your goal is False, you must use H : ??? -> False [Thu Feb 8 16:48:59 2018] Note that ~P = P -> False so you could use that [Thu Feb 8 16:50:47 2018] lyxia, oh yeahhh, i got it now [Thu Feb 8 16:50:53 2018] thankss [Thu Feb 8 17:18:42 2018] lyxia: ah, that's a good reason :- [Thu Feb 8 17:18:43 2018] ) [Thu Feb 8 17:19:56 2018] it seems like one could build things so that doesn't escape either, but they didn't [Thu Feb 8 17:36:50 2018] um, how to prove a disjunction [Thu Feb 8 17:37:42 2018] hackinghorn: use "left" or "right" to choose the side you want to prove [Thu Feb 8 17:38:38 2018] lyxia, ahh thankss [Thu Feb 8 18:23:30 2018] What are you guys using coq for? Academic? Professional? [Thu Feb 8 18:31:00 2018] there's not a whole lot of production deployments of verification yet [Thu Feb 8 18:32:30 2018] Why is that? [Thu Feb 8 18:32:41 2018] Companies love their unit tests? [Thu Feb 8 18:36:56 2018] it's still too hard and not scalable enough [Thu Feb 8 18:37:35 2018] the state of the art in 'real software' is programs on the order of 10000 lines [Thu Feb 8 18:37:59 2018] interesting production deployment targets tend to start at millions [Thu Feb 8 18:38:37 2018] I guess compcert is bigger than that, but compcert is also a very specific kind of thing that happens to fit well into the available models [Thu Feb 8 18:42:31 2018] Add CakeML, if it’s done [Thu Feb 8 18:42:55 2018] dh_work: but people do use (other forms of) verification in practice [Thu Feb 8 18:43:16 2018] including model checking and ATP and provers with more automation than Coq [Thu Feb 8 18:43:30 2018] actually, scratch the latter, they’re still too hard [Thu Feb 8 18:52:31 2018] I know MIT made a fully verified filesystem albiet I would still call that academic [Thu Feb 8 18:52:36 2018] https://github.com/mit-pdos/fscq [Thu Feb 8 18:53:38 2018] dh_work: When you say "not scalable enough" do you mean that it lacks tooling or that there aren't very many supporting libraries yet [Thu Feb 8 19:01:04 2018] fscq is a long way from a filesystem you'd want to use. [Thu Feb 8 19:01:41 2018] I mean if you want to try to write a 10-million-line project it'll take you multiple teams of phds working for years [Thu Feb 8 19:02:32 2018] it's also quite feasible to model your stuff in coq and prove theorems about it [Thu Feb 8 19:02:43 2018] Because of the heavy math involved? [Thu Feb 8 19:02:56 2018] to me it seems preferable to using a model checker, but that's probably just a matter of taste [Thu Feb 8 19:03:08 2018] Or should I say "mathematical mindset" [Thu Feb 8 19:03:46 2018] atlask: it's not heavy math for the most part, unless you're really trying to push the boundaries. but it's still basically just hard. [Thu Feb 8 19:04:18 2018] dh_work: I agree but why do you think it's so hard? [Thu Feb 8 19:04:41 2018] Because of the technological stack necessary to be productive? [Thu Feb 8 19:05:00 2018] why is it hard, or why do I think it's hard? [Thu Feb 8 19:05:04 2018] I don't think it's hard, tbh. [Thu Feb 8 19:05:09 2018] OMG [Thu Feb 8 19:05:31 2018] lol why do you think people think it's hard [Thu Feb 8 19:05:37 2018] I think it's not markedly different from ordinary programming, except that you have to actually write carefully instead of pumping out halfassed garbage [Thu Feb 8 19:05:50 2018] I think so too! [Thu Feb 8 19:06:16 2018] what makes it hard is that most people find *that* hard. [Thu Feb 8 19:06:25 2018] that and many people also find proofs hard in the first place. [Thu Feb 8 19:07:04 2018] In programming you're so used to relying on unsaid invariants, non-terminating programs, and so on. It _is_ hard x) [Thu Feb 8 19:07:12 2018] the level of proofs required for proving ordinary things about ordinary coq code isn't much past what people are supposed to learn in high school geometry; but few people actually learn that much in undergrad, let alone high school. [Thu Feb 8 19:07:41 2018] I honestly think its way more natural to reason about that writing a bunch of unit test ad infinitum until you "feel" like you've covered all the functionality [Thu Feb 8 19:08:24 2018] I'd classify the nontermination issues as annoyances, not significant sources of hardness, except when you run into a case where you can't manage to prove that your function is nonterminating because the tools aren't strong enough [Thu Feb 8 19:09:24 2018] dh_work: What do you use coq for? [Thu Feb 8 19:09:44 2018] I'm guessing at some uni? [Thu Feb 8 19:22:42 2018] dh_work: the amount of annoyance needed to prove pretty simple facts is... annoying [Thu Feb 8 19:23:08 2018] That’s after you move past “Coq’s too stupid” [Thu Feb 8 19:23:57 2018] Also, for lots of code idioms used in practice, we’ve only figured recently how to prove them correct (even on paper) [Thu Feb 8 19:24:38 2018] And by this I’m talking of all the separation logic proofs of the last 20 years, and the ongoing work on them [Thu Feb 8 19:29:09 2018] well yes, but all of that's in the can now [Thu Feb 8 19:29:33 2018] things are a lot closer to being ready for real deployments than they were just a few years abck [Thu Feb 8 19:31:15 2018] I haven't seen that level of annoyance, but maybe I'm not trying the right problems [Thu Feb 8 22:10:14 2018] https://pbs.twimg.com/media/DVjMjZrW0AAn68R.jpg [Thu Feb 8 23:29:24 2018] benzrf: hahaha where is that from [Thu Feb 8 23:33:09 2018] umm not sure [Thu Feb 8 23:33:13 2018] it was on twitter as u can guess from the url [Fri Feb 9 02:34:03 2018] <_xvilka_> hi! I know Coq as a proof assistant, but is it useful for problem solving? [Fri Feb 9 02:34:14 2018] <_xvilka_> for example I work on the problems on program analysis [Fri Feb 9 02:34:28 2018] <_xvilka_> and modern tools stick to SMT solvers [Fri Feb 9 02:34:49 2018] <_xvilka_> but at this point SMT solvers are still low level to effectively test hypotheses [Fri Feb 9 02:35:17 2018] <_xvilka_> so if I implement some foundation for particular set of the problems in program analysis [Fri Feb 9 02:35:32 2018] <_xvilka_> will be I able to check hypotheses? [Fri Feb 9 02:39:41 2018] _xvilka_: are you asking if you can implement some program analyzer in Coq from scratch by yourself? Conceptually yes, if you can make it terminating [Fri Feb 9 02:40:40 2018] but that might be hard [Fri Feb 9 02:41:38 2018] _xvilka_: I expect Coq still is lower-level than most SMT solvers, as long as somebody doesn’t reimplement an SMT solver in Ltac [Fri Feb 9 02:42:00 2018] * thinks of writing actual software in Ltac and runs away screaming [Fri Feb 9 02:46:16 2018] <_xvilka_> pgiarrusso: Coq as a core - surely yes, but if you provide a libraries, etc - can be quite high-level, can handle bigger abstractions than SMT, imho [Fri Feb 9 02:47:14 2018] agreed [Fri Feb 9 02:48:08 2018] I suspect for now Chlipala (and students) are almost the only one doing so at an automation level anywhere close to SMT [Fri Feb 9 02:48:47 2018] I’d maybe wait for Ltac2 or use some alternative before trying to write so much automation [Fri Feb 9 02:50:39 2018] <_xvilka_> ok, thx for the hint [Fri Feb 9 03:00:29 2018] _xvilka_: OTOH, as example for your thesis, the Iris people implemented a *program logic* (separation logic) in Coq (with correctness proofs), but without much automation — for now they simply provide tactics for separation logic proof rules [Fri Feb 9 03:00:58 2018] I expect an SMT solver can’t even remotely do that [Fri Feb 9 04:57:32 2018] benzrf, haha, I'm still laughing! [Fri Feb 9 05:09:54 2018] <_xvilka_> pgiarrusso: wow, thank you, didn't knew about this Iris project [Fri Feb 9 05:11:28 2018] _xvilka_: now just reimplement Facebook Infer on top of Iris and you're done! [Fri Feb 9 05:11:41 2018] <_xvilka_> "just" [Fri Feb 9 05:11:54 2018] yep! [Fri Feb 9 05:12:09 2018] since you mentioned SMT solvers [Fri Feb 9 05:13:23 2018] anyway not entirely serious for a bunch of reasons, what you prove with Iris seems stronger than what you autoprove with Infer (caveat: not an expert, might be nonsense) [Fri Feb 9 05:14:24 2018] <_xvilka_> pgiarrusso: point is not to prove, thats a whole another domain. My goal is to test hypotheses interactively, if they hold or not [Fri Feb 9 05:15:56 2018] <_xvilka_> more like a researcher helper tool [Fri Feb 9 05:16:08 2018] <_xvilka_> which can automate like 80% of work [Fri Feb 9 05:27:47 2018] _xvilka_: see QuickCheck/QuickChick/model checkers [Fri Feb 9 05:28:14 2018] or also, SmallCheck, which might be even closer to model checkers [Fri Feb 9 05:48:16 2018] <_xvilka_> ah, yes, I know QuickCheck [Fri Feb 9 05:49:18 2018] <_xvilka_> but I thought its purpose is entirely different [Fri Feb 9 06:01:01 2018] QuickCheck is similar to model checkers [Fri Feb 9 06:01:55 2018] if model checkers are not what you want, I’d guess you have more in mind than you’re saying [Fri Feb 9 06:02:07 2018] anyway, gotta go [Fri Feb 9 06:02:12 2018] _xvilka_: ^^ [Fri Feb 9 06:19:36 2018] <_xvilka_> thanks for your help [Fri Feb 9 06:42:13 2018] Is there a reduction tactic which takes as an argument the subexpression I wan reduced? [Fri Feb 9 06:44:03 2018] I tried different coq reduction tactics `cbn` `cbv` `simpl` but all of those unfold/reduce in a prolematic order resulting in a goal so large my machine runs out of memory making proofs very inconvenient [Fri Feb 9 06:51:01 2018] If you know of a subterm `t` that you want to reduce, you can something like `match goal with |- context C [t] => let t' := eval cbv in t in let gl := context C [ t' ] in change gl end` [Fri Feb 9 06:51:08 2018] it's a bit manual but it should work [Fri Feb 9 06:51:53 2018] alternatively, if the problem is just that there is a function `foo` that gets unfolded and you do not want it to unfold, you can try something like `cbv -[foo]`, or making `foo` opaque with the command `Opaque foo.` [Fri Feb 9 06:52:10 2018] So it depends on what you want to do exactly [Fri Feb 9 07:01:36 2018] Ok, I didn't know that `cbv` taks this kind of arguments. I'll see how far that takes me [Fri Feb 9 07:01:44 2018] Thanks again for your help [Fri Feb 9 07:03:23 2018] Some reduction tactics (probably `cbn` too) take flags as arguments to modulate which reductions are allowed. So you can say `cbv beta` to perform only beta-reduction for instance, or `cbv beta delta iota zeta.` to have full reduction. [Fri Feb 9 08:12:29 2018] Ok, I think I found why the goal becomes so huge [Fri Feb 9 08:13:08 2018] coq can't figure out that `forall (a : nat), a =? a = true` by itself [Fri Feb 9 08:13:31 2018] therefore `if` statements don't get resolved and both branches unfolded at multiple places [Fri Feb 9 08:15:31 2018] can I somehow add that lemma to the simplification mechanism or do I need to write my own simplification tactic for that? [Fri Feb 9 17:46:33 2018] mgttlinger: the general method I have settled on for these problems (simpl/cbv/etc unfolding too much) is "replace (term_that_exists) with (term_I_want) by (simpl; auto)" [Fri Feb 9 17:47:18 2018] for the a =? a thing, have you considered making a separate lemma on the original object that produces a reduced one for the a =? a case? [Fri Feb 9 17:47:38 2018] (that is, before feeding any of the other material in that would lead it to expand unboundedly) [Fri Feb 9 17:48:51 2018] e.g. if the original thing is "foo a b", make a "foo' a" and a lemma "foo a a = foo' a", or whatever like that [Fri Feb 9 17:49:28 2018] this may or may not make any sense depending on what you're doing :-)